cesaref

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.

Back in the 80s, as the home computer revolution got going, computers were typically wired up to small, cheap, portable TVs as a display device. These TVs used shadow masks, and the computer video output was typically modulated to a TV signal, and the TV was 'tuned' to the computer. All of this added large amounts of blur and distortion even before the signal was displayed on the TV.

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.

brew install grep?

There are exceptions - here in the UK we have the RI: https://www.rigb.org/

The Christmas lectures are probably the most famous thing they do, and these have definitely moved in a more 'child' focussed direction. If you were attending the Christmas lectures in the 1850s however, the audience would have been middle class victorioans, and you'd have had Michael Faraday telling you about electricity, forces, chemistry etc.

https://en.wikipedia.org/wiki/Royal_Institution_Christmas_Le...

I would recommend attending one of their lectures if you happen to find yourself in London, just to be in the building, and to sit in the lecture theatre!

They are vitamin C to the mixture, which is actually what is developing the film. There's a commercial developer (Xtol) made by Kodak which is I believe vitamin C based, and it's a very good developer.

It would be interesting to know if the caffeine in the red bull is making a significant contribution I guess, otherwise the jagerbomb isn't really doing that much I think.

so how do you get a privately owned train car and get it to the tracks or etc?

I think you wait in a remote bit of Nevada for a train to pass, and trigger a rock fall which causes the driver to slam on the brakes and bring the train to a stop just short of the rockfall.

Then, you and your posse jump out from behind some rocks and fire your revolvers in the air, and the driver sticks his hands up. There's much celebration, and back slapping as you discover the train also happens to have a massive amount of gold bullion on board.

The rest is a bit blurry, can't remember seeing what you then do, but it probably involves filing down the serial numbers on the frame or something like that?