This would have been in the late 80s - i've no idea if it was still in use, but i've a feeling that the law hadn't necessarily moved on, so I guess the official measure could have been required if challenged in court.

The calibration procedure on the scope fiddles with the time alignment to get the different DACs correctly offset so that the combined signal is correct.

The hybrid ceramic input boards in their metal cases are a thing of beauty, fragile (don't ask how I know), but beautiful.

Interesting that it's mandated as native - i'm really not sure the logic behind this (i've worked in the embedded world where such stuff is not only normal, but the only choice). I'll do some digging and see if I can find the thought process behind this.

So, >foo is the same as 1>foo

If you want to get really into the weeds, I think 2>>&1 will create a file called 1, append to a file descriptor makes no sense (or maybe, truncate to a file descriptor makes no sense is maybe what I mean), but why this is the case is probably an oversight 50 years ago in sh, although i'd be surprised if this was codified anywhere, or relied upon in scripts.

It was a very flexible and hackable system, very fragile, and no security whatsoever, but lots of fun!

Of course these days with LTO the whole performance space is somewhat blurred since de-virtualisation can happen across whole applications at link time, and so the presumed performance cost can disappear (even if it wasn't actually a performance issue in reality). It's tough to create hard and fast rules in this case.

If we take a Tesla model 3, I believe it weighs 1611kg, and the motor shows up at 80kg if you google it (no idea if this is correct). This YASA motor by comparison weighs 14kg. So, this would drop the vehicle weight by 66kg out of 1611, so that's a 4% saving.

https://www.bbc.co.uk/rd/blog/2024-03-c2pa-verification-news...

I believe various cameras support this, e.g. https://www.canon-europe.com/press-centre/press-releases/202...

`C2PA Authenticity: Integrated support for the C2PA standard for photo authenticity verification – initially available exclusively for registered news agencies.`

Sounds like it's limited to some users for now, I guess this will change in the future.

Going too far won't really help, since the scene being photographed can be manipulated or staged, which sounds more likely to be a concern rather than the hardware being hacked.

The last school shooting was the Dunblane Massacre in 1996, which led to gun law changes, removing rights to have handguns and various semi-automatic weapons.

I'm not sure how many occurred before then, but the total number of mass shootings in the UK is low. Check out https://en.wikipedia.org/wiki/List_of_mass_shootings_in_the_... to get a feel for how rare this sort of attack is in any setting here in the UK.

So for the last 25 years we've had no school shootings. I believe the US as a whole has had >300 shootings so far this year, with >300 victims.

If a client application makes an assumption about this, then their engineers will accept this as being their bad and will fix it.

I'd defend this as being pragmatic - minimising disruption to clients instead of the more 'correct' solution of changing the API. I'm hoping that they managed to roll out the new API update alongside the old one and avoid a 'big bang' API change with this. Sometimes this isn't possible, but it's great when that works out.

By the mid 80s, it was maybe more typical to buy a dedicated CRT monitor, and the computer connected via composite, or maybe even an RGB feed to the monitor, allowing higher resolution and much improved quality.

For the well healed, this route also led to the holy grail, a trinitron tube!

At each of these changes, the aesthetic of the display technology changed, but probably the best memories come from the original blurry stuff as the magical moment of actually getting something out of a home computer.