cesaref

I think back in the day (say the late 80s) it became apparent to those in charge that this new IT thing was going to be very important in the workplace, and that it was going to be important to train up people to operate computers.

Given those in charge were probably one finger typists if that, and befuddled by technology, they would collectively have decided that computers should be standardised so that learnt skills would be transferrable, and therefore they probably imposed ideas like standardised keyboard layouts.

Of course it turned out that the next generation were totally capable of operating computers without any formal training, were totally fine with different operating systems, different keyboard layouts, different applications etc, and so there was probably lots of wasted effort solving a non-existent problem.

It used to be quite normal to add a low level random signal to inputs when writing DSP code so as to avoid dropping into subnormal territory. Careful analysis of the algorithm would identify any points where this was also necessary (e.g. feedback paths when running delays).

Obviously those lucky/unlucky enough to be writing 56k fixed precision code wouldn't have this concern, but other ones instead :)

I think flush to zero is probably the preferred strategy these days.

How on earth do you survive with just one big box of cables? I've got mine sorted into plastic storage boxes with labels, so things like 'Firewire' or 'Monitor' or 'SCSI' can get me to a particular box to sort through. I recently needed a SCSI-2 terminator to connect a CD-ROM drive to a 1990s sampler, and my box came up trumps. It's so pleasing when you find stuff like that...

I noticed he mentioned that his game was running at 50hz - that's true if an Amiga is running on PAL, but if it's a US machine it'll be 60hz when running with NTSC.

Back in the day, most Amiga games were made in Europe, so were tuned for 50Hz refresh, and played 'normally' over here. At 60hz, they would feel wrong, and likewise, US games could feel sluggish and unsatisfying.

Locking the machine to the monitor refresh rate in this way was a curse but also a blessing. It allowed the machines to drive a standard television in various regions, although the image was somewhat blurry, but also the use of dedicated monitors once you started taking it seriously. This reduced the price point and allowed lots of kids to convince their parents to get one :) The higher resolution modes just didn't work out though, so lots of stuff targeted the 320x256 resolution.

The surprise benefit was also that the amiga could genlock to a TV signal and used to overlay onto a video feed, leading to many interesting cheap graphics overlay capabilities which were otherwise totally unobtainable by small TV channels or enthusiasts.

Those were happy days.

'the only language where 90% of the world's memory safety vulnerabilities have occurred in the last 50 years'

Let's assume this is true, and ignoring the fact that it's not possible for more than 1 language to have >50% of the vulnerabilities, we are left pondering what proportion of the worlds software is written in C. If it's >90%, then C is safer than average :)

All information is ephemeral, but I don't honestly think that argument holds much weight here.

I'm currently listening to a record which was pressed before I was born, and that will outlast me. My CDs were ripped around 2000 to a drive and i've streamed then since. I've still got the CDs though, and the last time I played one it worked fine on my 1989 vintage transport.

I think i'm good.

Ah, of course. Interesting.

Unless that site collects personal information, it's fine isn't it? This isn't about where stuff is hosted, it's about privacy.

Yeah, there were two busses, and the bigger ones were certainly rather impressive. I built a PDP-11/23 out of spare bits gifted from a university physics department in the late 80s, and it was awesome, but nothing like an 11/70 or anything like that!

Is it only me that would have expected curl_getenv() to have an assert that it's argument isn't NULL?

I know this doesn't stop runtime problems in release builds, but i'd have thought this sort of simple precondition check would help users find problems in their library useage.

It's not going to stop you passing a non-terminated string, or other such invalid input though, which is I guess more the point, that it's totally possible in C to produce good looking but actually invalid arguments that can't be spotted at runtime without UB (out of bounds access etc).

Edit: Actually thinking about this more, I guess the problem is that you are likely linking against a release library implementation, so it's not possible to add a precondition without introducing a runtime overhead, which is probably more likely what we are talking about with this case.

I think the history of this is that these operations were common with assembly programmers, so when C came along, these were included in the language to allow these developers to feel they weren't leaving lots of performance behind.

Look at the addressing modes for the PDP-11 in https://en.wikipedia.org/wiki/PDP-11_architecture and you'll see you can write (R0)+ to read the contents of the location pointed to by R0, and then increment R0 afterwards (so a post increment).

Back in the day, compilers were simple and optimisations weren't that common, so folding two statements into one and working out that there were no dependencies would have been tough with single pass compilers.

You could argue that without such instructions, C wouldn't have been embraced quite so enthusiastically for systems programming, and the world would have looked rather different.

I'm interested in the implications for the open source movement, specifically about security concerns. Anyone know is there has been a study about how well Claude Code works on closed source (but decompiled) source?

On the subject of the weights and measures to check that a pint is a pint, I remember the father of a friend of mine at university who was responsible for the weights and measures for Staffordshire. I think he was the undersheriff or something like that, and that the official pint was part of the collection.

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 older Tektronix TDS540 series did this, but at much lower rates as was common in those days though. Internally there are differential feeds from the very beautiful hybrid ceramic input boards to 4 DACs, with some clever switching so that a single input can be sampled by all 4 DACs with a suitable offset to create 4x the sample rate when running with all 4 inputs.

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.

I failed to find this on my skim, my bad :(

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.

Just out of interest, why aren't they cross compiling RISC-V? I thought that was common practice when targeting lower performing hardware. It seems odd to me that the build cycle on the target hardware is a metric that matters.

Nobody misses the terrible optical mouse with the blue metal mouse mat though! You are right, the keyboards were great.

The way I read it, the prefix to the > indicates which file descriptor to redirect, and there is just a default that means no indicated file descriptor means stdout.

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.

Except it has a taste. I think finding something with just the colour and no taste would be a better example of this.

Most of the effort when writing a compiler is handling incorrect code, and reporting sensible error messages. Compiling known good code is a great start though.

Just out of interest, what's the current 'state of the art' for a chip that is hardened to survive launch and any length of time in orbit?

This has reminded me that in System 7, the code for the window was a system resource (resource forks contained all sorts of code, icons, text dictionaries etc). Anyhow, if you dropped an updated window resource into your system with the correct resource id, you could change this default behaviour. A friend of mine wrote a round window for a clock app, and made a copy with resedit in the system, and a reboot later, all windows were round.

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

The problem with articles like this is that they read a little like justifying a decision that has already been made. I've a feeling that if it was written in C++/Rust/Go/whatever, it would also be possible to justify that decision with similar reasoning.

I'm interested in why SSDs would struggle with condensation. What aspect of the design is prone to issues? I routinely repair old computer boards, replace leaky capacitors, that sort of thing, and have cleaned boards with IPA and rinsed in tap water without any issues to anything for many years.

I think that's an over-simplification. There was pressure on the language to ensure that data structures were compatible with C structs, so avoiding the vtable with simple classes was a win for moving data between these languages.

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.

I don't see the weight reduction being very significant.

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.

There's the C2PA standard which has picked up momentum recently to I guess help resolve some of the issues.

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.

Ok, i'll turn the sarcasm detector up a notch :)

The UK has 1/5th of the population of the US, and 12x the population of Minnesota.

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.

I think the point is that the API doesn't specify that the returned integers are positive, or are monotonically increasing, then it's fine for the service to return any unique integer.

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.