Dagger replaced BuildKit (a lot of reasons for this). The BuiltKit API sucks compared to Dagger's, so I personally prefer the middleman, but that is no longer the case. See:
“They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees”
I don’t think you can get the SCT from a log without the log publishing it? That would defeat the purpose.
“Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).[4][3] At some point within the maximum merge delay, the log operator adds the certificate to their log.”
> I don’t think you can get the SCT from a log without the log publishing it?
Well you can, but only if the log cooperates.
That is, the SCT is merely a promise to add the certificate to the log by some particular deadline. Nothing technically stops the log from disregarding that promise. But if it does fail to log the certificate, the SCT itself is proof of its misbehavior.
And it's not enough to subvert a single log, because browsers require SCTs from multiple distinct operators in order to consider a certificate valid.
The SCT may be proof that a log was supposed to be issued, but browsers don't submit every SCT they see (did you know "anonymizing" proxies send CT log companies a sampling of all your TLS traffic? fun stuff!), so in practice these logs aren't audited. As far as multiple operators, almost all of them are based in the US, so just pray the USG doesn't want to target you.
Yes. Bad UI, cumbersome flows, too little automation, … plenty of flaws, but the business just keeps on running. Orders received, invoices written, documents shared, …
I guess experiences differ across companies and industries. I work in logistics. Logistics deals with messy processes and a messy reality all the time. A tiny fraction of that is due to buggy software. Some of it could be avoided with great software, but again: that we also didn’t have before LLMs
Orders missed/not fulfilled, invoices with the wrong amounts, wrong documents shared or shared with the wrong audience - all these and a bunch of more errors are still consistent with business not dying, yet that's definitely not the mythical 24/7 without a glitch
The LLM. And you can use an alternate LLM to antagonize the coding LLM.
You’re simply testing outputs. Make a spec but ultimately ungodly amounts of tests can be built quickly to ensure the program is outputting the right things.
That’s an interesting idea but not all locks are held for the duration of the statement. A lot of them take a less intrusive lock for the whole statement and take an exclusive lock for a very short time when they finish up.
Edit: Looking this up, I’m not sure this is correct.
simplified you can think of a statement outside of a transaction as starting an implicit transaction just for itself
and (normal) locks are in general hold until the end of the transaction (while also allowing re-entrance from subsequent queries on the same transaction)
practically
- there are edge cases (e.g. Advisory Locks, but in general you don't want to use them)
- you normally(^1) would want to run your pg migration as a single transaction (but there are edge cases). And in turn the OPs idea of pre-acquiring locks would be for the whole transaction anyway. Plus it was just a general idea, so the end result could be more like an "expect lock" statement maybe with some scan ahead ability then an "acquire lock".
(^1): Exceptions include certain operations which need to be in different transactions, and some painful situations where too much data is touched/changed/computed and you need a lot of very careful handling you common small-ish PG DB use-case isn't exposed to (and in turn a lot of "naive but often good enough" migration setups can't handle either...)
Oh you're right. And if I enable "ask to keep changes when closing documents," it asks me if I want to "revert changes" when I quit, not "delete." That even survives a force-quit, so on-disk the file was autosaved, but it still remembers that the changes are in an uncommitted state.
Weird thing is with the setting disabled, quitting TextEdit with multiple new docs open asks if I want to "delete and quit," but Numbers only lets me "save and quit." Even if I press that, Numbers reopens those in a still-uncommitted state. So from all the CSVs I've opened in Numbers and messed with, I have literally 100 pending docs and can only get rid of them by clicking through every single one.
However I don’t think anything using BuildKit is as fine grained as Bazel.
reply