I think the tricky part is if they start cranking up the intensity to counter it being scanned sequentially over a larger area...
First, what is the fail-safe in case the scanning mechanism fails? I.e. is the intensity safe if the beam becomes stationary? Or does it guarantee it goes dark when not properly scanning?
Second, what is the safe intensity limit for the brief visits to each target pixel area? As the scanned area increases, you need higher intensity to maintain the same visual brightness with a shorter exposure for any one spot. At some limit, is the pixel to area ratio too low and this intensity too great?
Third, does the optical path through the cornea and lens have any hot-spot where you have to also worry about peak flux with this projection technique?
I think you could use AI for this if you do it properly as a sort of adversarial coding project. Have it build tests to break the code. Don't give it the job of making a test suite that passes.
I think people higher up are warning against a naive mistake, which is asking one agent to write both the product and the test suite. Here, making things up and cheating becomes a problem of quality theater...
Totally agree. My point is simply that this aligns with existing roles.
The QA role (regardless of whether it's performed by an AI or a human) typically involves breaking tests, not writing them. (This applies more to unit tests, integration tests blur this line.)
For me QA is tasked with making sure that the product functions as intended. that means coming up with clever test suites to explore the spaces that the developers didn't think to, making sure the coverage for operational problems is adequate, and also long term tracking of performance and memory utilization.
this doesn't sound like your model, and I'm unclear what it means to break a test. maybe test automation, in which case, sure that seems fair game for AI, but that not where the real meat is.
That largely aligns with my view. I think in a large enough codebase (roughly the size QA becomes necessary/relevant) it becomes impossible/infeasible to guarantee correctness. I think the line "clever test suites" highlights the distinction.
In my mind, tests are everyone's responsibility, but the goal differs. A regular developer adds features and should be writing tests to prove their code functions as intended. QA does not add features, so their goal is finding holes in code added by others.
It's the adversarial relationship mentioned by a parent:
> Have [QA] build tests to break the code. Don't give [QA] the job of making a test suite that passes.
> For me QA is tasked with making sure that the product functions as intended. that means coming up with clever test suites to explore the spaces that the developers didn't think to, making sure the coverage for operational problems is adequate, and also long term tracking of performance and memory utilization.
This pretty much. My last job didn't really have QA so I did the next best thing which is writing a bunch of integration tests for the use cases that matters for the product. They were not an indication for correctness, but more like a canary to warn me if I break something while developing. Bugs reported by consumers usually warn me of area not well covered.
QA would play the same whole. They shouldn't need to check for code correctness, their most useful task is to surface bugs that breaks the product requirements (performance, security, business logic,...). And for that, having knowledge of the implementation is unnecessary. In the above example of writing integration tests, I took care of only using the public interface of the modules.
I tried to spelunk this thread and couldn't find the topic I want to see explored.
I don't really have the crypto chops to declare a fact here, but I have a speculation or intuition. In this day of supply chain worries, I think a proper signing algorithm should not be signing this tower of hashes, or not just this tower.
It should incorporate a canonical stream of all the actual commit content. It is the integrity of this content from the author's working copy that they can and should attest, not some derived byproduct of the storage scheme. Edit: Of course, I mean a secure hash of this stream, not a signature including a copy of the entire content!
My intuition is that the content-addressable store is used to reconstitute the commit content, but the verification should be over the original content, not the internal addressing of the store.
Wouldn't this make it harder to do these exploits? You would have to find alternate content that simultaneously produces collisions in the internal addressing hashes and for the overall canonical stream hash.
If you also carry size info alongside each hash, would this also make it much more difficult to produce useful collisions?
You'd be surprised how many doctors and scientists would drink, smoke, and use other drugs in spite of being fully versed in what this does to their patients.
Or how many medical professionals continue to be medical professionals while knowing it has an elevated risk of suicide.
Reproduction also causes some pretty intense biophysical changes which may well alter personality. It is silly to act like it is just due to reasoning...
Unless I'm really misunderstanding, this is just "footgun of timestamp without timezone and implicit coercion"?
The only purpose of the naive timestamp is to defer a necessary step of converting a sort of nominal prototype or template to a real moment on the timeline. Until you pin them down, they don't really represent moments.
It's like having a NULL in the timezone slot. I think it should mean "unknown, anything goes on a per-value basis!", rather than treating it like some polymorphic type that gets magically parameterized at runtime.
IMHO, it is a mistake of the standard and PostgreSQL authors to try to enable such sloppy thinking by users and applications. Ordering relations shouldn't even be implemented on naive timestamps. It should be a type error, not a trigger for implicit coercion.
Perhaps it should even be a domain over text or some composite type that represents the partially populated time info. Require explicit mutation to populate the missing bits and allow conversion to a well-defined moment.
I think a sane application should only use the timezone-aware timestamp for storage, and explicitly manage its own "timestamp templates" and conversions before trying to do comparisons on the timeline.
Edit to add: I think you can say the same about timeline versus some timestamp-with-timezone strings. Make it more explicit that the ordered type is normalized moments. Make sure there is a normalizable external representation like ISO timestamps.
Make it clear that other representations are not stable. E.g. any legal timezone that could have its definitions change over time is not a stable concept to use in a representation of a moment. It is also effectively naive unless it includes another version parameter to state which version of the legal definition is intended.
>AT TIME ZONE 'UTC' converts the data type from timestamptz to timestamp
surprising and a foot gun. Asking for at a timezone stripping the timezone makes no sense to me. Having `AT TIME ZONE 'UTC'` produce a timestamptz at +0:00 seems not insane.
Yes, the SQL syntax is full of misnomers. I agree it should have more hazard tape around it.
The type qualifier "with timezone" doesn't mean it stores a timezone with it! It means the input is interpreted with timezone offset, producing an unambiguous moment on the timeline. You can then compare all such values with a total ordering. But, these stored values do not preserve any offset/locale information. You can't ask "what was the offset of this timestamp when it was input?" That denormalized locale information is stripped when it is interpreted.
The naive type (without timezone) really means that the timezone information is absent and the interpretation is to be deferred. You have to supply timezone information before it can be resolved to the timeline. This is what the implicit coercion is doing in PostgreSQL, mixing in either the session or server timezone offset.
The above is further complicated in that PostgreSQL will supply an implicit (session or server) timezone during interpretation of the input for timestamp with time zone. And conversely, it will ignore timezone or offset even if present in the input for a naive timestamp! I think both of these would be better off handled as type/input errors in a strict mode.
The poorly named "(ts)::timestamptz at time zone 'tz'" construct is the inverse of the input transform that takes a naive timestamp and the given timezone to produce the known moment.
The other sad bit is that all of this is naive about the difference between UTC, TAI, and Unix time standards. There is ambiguity in postulating any future time, since the exact presence of leap seconds is not yet determined.
Right up there with responsibility/culpability/liability laundering. These are things being shrugged off and externalized.
And the complement is credit/provenance laundering. These are things being misappropriated.
The grift often does both of these with the same sleight of hand, and this is what gets accelerated with the new tools and cavalier culture around everything.
It pains me to think about the important ones like varying on session cookie and authorization headers, and how badly some middleware can confuse things.
We generate custom content for a given authentication context. We definitely want caching at the user agent, but we want the cache keyed by the authenticated identity. Otherwise something like logging out and logging in as a different identity can produce monstrously confused results when an SPA or similar mixes some cached and some fresh responses into one page.
Wait a second, if you decided to become intermediary in the protocol then you are supposed to add value, not take away the features that already exists.
Although its not clear from the article itself, my gut feeling is that some big enough client arm twisted them to support it before they sign the contract again
Implementing the HTTP/1.1 caching mechanism at the proxy server is delightfully simple if you just ignore it entirely. But if you decide to do some caching on your own, you better implement the semantics in the way the clients and the servers expect it to be. Which is not simple at all if you're doing the caching to eke some performance improvements.
First, what is the fail-safe in case the scanning mechanism fails? I.e. is the intensity safe if the beam becomes stationary? Or does it guarantee it goes dark when not properly scanning?
Second, what is the safe intensity limit for the brief visits to each target pixel area? As the scanned area increases, you need higher intensity to maintain the same visual brightness with a shorter exposure for any one spot. At some limit, is the pixel to area ratio too low and this intensity too great?
Third, does the optical path through the cornea and lens have any hot-spot where you have to also worry about peak flux with this projection technique?
reply