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 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...

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?

To successfully perform dumping, you have to have access to excess supply capable of disrupting that market.

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.

Or how many medical professionals continue to be medical professionals while knowing it has an elevated risk of suicide.

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.

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.

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.

If you assume the file arrives ahead of time, can be indexed, and that this is worthwhile because we want to support multiple pattern matched retrievals, then sure it makes sense to consider indexed query schemes and upper/lower bounds. Each query could be faster as an inference if it doesn't have to re-scan the whole file.

But I don't think anybody, in good faith, can pretend that any LLM can digest a file faster than grep can. Particularly, if you admit the vector processing dedicated to doing the convolution kernel(s), you should also admit similar hardware could run a vectorized grep.

The right thickness marine layer can make the sky seem dim but it's like one massive UV diffuser from horizon to horizon.

Engineering often continues until the concepts and theories are developed into safe, practical methods. "If you stay within these parameters, you can confidently expect these results." The reliability can be codified and reproduced without going from first principles on every application of it.

It's not clear to me that the current AI fad is really developing such reproducible, safe methods. "If you stay within these parameters, you might get these results. Or a teapot. Or some subtly misleading fabrication."

You have to do full due diligence to validate every result. There is safe usage where the hard work was done up front so that day to day practice can skip to boring and reliable application.

The exceptions were mostly hardware graphics accelerators in some labs, when my Linux PC had to do it in software. And I got myself a surplus DEC Multia (alpha) that was really fast with Linux for natively compiled code, beating my contemporary 486DX3-100. But, the PC was still faster for web browsing, because running Netscape on alpha meant doing x86 emulation!

Likewise, my ~90 MHz Pentium MMX laptop with Linux was faster at regular dev work on my work-supplied Sun Ultra workstation in the late 90s. (Edit: Hmm, I am not sure about this laptop anymore, it might have been 166 MHz??)

Due to my positive experiences, I was an aggressive early adopter (and frequent beta tester) of nearly every Linux ecosystem frontier for decades. E.g. 2D accelerators, 3D accelerators, SMP, large file support, gigabit ethernet, wireless ethernet, power management, virtualization, 64 bit architectures, SCSI/SATA/Firewire/e-SATA/NVME, hardware and MD-RAID, ext2/ext3/xfs/btrfs, ...

It wasn't until mid 1992 that distros started to exist, and I'd say it took a bit of time for those to be complete enough to be usable for someone with a goal other than smoke-testing the kernel on their PC.

I can say for certain that I, a complete newbie, was able to boot SLS Linux floppies in early 1993, and within a couple months I was installing Slackware to HDD.

I have limited tolerance to take demeaning workload that I know "the boss" could do himself. I think my pride and satisfaction is in my intellectual contribution, not my ability to relay messages nor do repetitive slop work.

But the real revulsion is being a scapegoat. I will not rubber stamp and take responsibility for things not under my control. I have limited capacity to review and sign off work I've delegated to someone else. It is usually easier for me to do it myself and know it inside-out than to delegate and then review enough to have the requisite confidence in the result.

When the new plan is to increase throughput via delegation to these generators, I can't possibly review to my standards. So, I refuse to accept any of it as my work.

It also freaks me out a bit to think of the collective mess that is developing across society, with so many people apparently ready and willing to shovel and rubber-stamp. I think the "move fast and break everything" cult is going too far.

But, primarily, I just need to protect my own sanity and live to my own standards. And hope that I can back away far enough to avoid some of the splash damage when entropy catches up...