rwmj

Libvirt listens on ports 16509 and 16514 out of the box, in reference to ZX81 BASIC where the program starts at (address) 16509 and the first byte in a REM statement (commonly used to store machine code) is 16514.

I managed to get that easter egg into libvirt - it listens on ports 16509 and 16514 (https://libvirt.org/remote.html).

I have to imagine that their legal team is a smooth, well oiled machine. The technical side on the other hand ...

That article was fascinating, thanks for sharing it. I wonder if all banks use the same "bank Python" or if they all forked it in different ways?

And now if you try to get a bug fixed or a new feature in GMail, it simply can't be done at all. Problem solved!

Wikipedia search turns up this game from 1982: https://www.mobygames.com/game/52384/controller/ Quite graphically advanced for the time.

Heathrow ATC (for the ZX Spectrum) was one that I played extensively back in the day: https://spectrumcomputing.co.uk/entry/10530 I wonder if there are earlier examples of popular ATC games? They're simpler than flight simulators so you'd think there would be more of them.

Edit: playable version - https://archive.org/details/zx_Heathrow_International_Air_Tr...

I actually think the participate XOR vote behaviour of Slashdot was a great feature! It stops people pettily downvoting comments that don't agree with them on the same discussion.

As an aside I once went on a tour of the museums of Amsterdam with an expert guide (paid for by the company I was visiting). It was fantastic! A completely different experience from being a regular tourist. I learned far more about Amsterdam and the art than I could possibly have done on my own.

But prompting an AI adds nothing. Journalism is about research, interviewing the people involved, finding new facts, and then presenting that to your audience in a way they can understand. Getting an AI to write about something is just diluting the signal for future researchers.

You'd know that if you'd done any research at all.

Compare this to Jeff Guo (NPR) or Henry van Dyck (Veritasium) or my contact at the WSJ. They all investigated this story, interviewed key people (more people were interviewed for the Veritasium video than appeared), and fact-checked everything with subject matter experts. The NPR story took about 3 months of work and the Veritasium video took 5 months. I was interviewed in total for over 6 hours across all of them.

These are real journalists who worked on these stories and they produced novel work and new findings. I have huge respect for them, especially after being involved with it and seeing what work it took to add something new to the story. At the same time they managed to tell that story to a lay audience which is another skill in itself.

I read parts of it, being first hand involved in all this, and it seems like it was written by AI to me. If you used an AI to write it or help with it, why not just admit to it?

The number that stuck out was 200K lines of code. Can you expand on why so much code had to be written and which parts were the longest (time and/or code) and hardest bits?

Interesting! It uses (the Linux equivalent of) NBD. However as Chris says in the article that's not really an alternative to NFS since you can't share files meaningfully.

But they're going to try anyway.

https://archive.ph/UyksP

https://archive.ph/i9R37

Those techniques are implemented by default in Fedora & Debian. You have to opt out if for some reason you don't want to use them. So almost all C software compiled in these two major distros are using all of them. (Likely in other distros too, but I'm less familiar with how they configure their compilers).

Fedora will soon implement shadow stacks across the entire C codebase: https://discussion.fedoraproject.org/t/f45-change-proposal-e...

Major OS vendors have added loads of hardening to their C compilers. Not bounds checking specifically (because even if the overhead was only 20% that would be too high) but tons of other stuff such as: stack canaries, control flow integrity, hardened string functions, ASLR, zeroing uninitialized auto variables, forced warnings, linker hardening. These are added as standard in all decent Linux distros today. Probably Windows too, I've no idea. There's a good summary here: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...

There are also bounds checking options for major C compilers so if you want to use it, you can, eg. -fbounds-safety or the various sanitize options in Clang.

The alternative is you use a compiler that adds bounds checking. It's possible to do this with C, with fine object granularity (even separate stack objects), and even preserve compatibility with existing non-bounds checked library code / system calls. When I did it back in 1996 there was a large overhead to doing that, but compilers can do much better these days. And anyway you have to compare the overhead to the cost of designing and building your own small run CPU and eshewing mainstream processors, which is also huge.

https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html

If you walk through a town shouting racist stuff you'll get arrested too, and rightly so.

I'm trying to work out what this means. The "millions" employed at Meta?

However you can do what Airbus do and formally prove your C code and use a formally proven toolchain like compcert to compile it. Or you can take a performance hit and add bounds checking to the C code[1]. Aircraft systems are probably the best chance that CHERI has, and that's pretty niche, small runs and very expensive, and still better solved in software.

[1] I literally wrote the paper on this back in 1996: https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html

ARM and Microsoft don't "care" enough to do anything beyond a bit of token research. Maybe there will be some extremely niche chips one day, or maybe not because the problem can be solved 90% as well in software on ordinary hardware.

The problems with CHERI are not whether it's technically good or not, it's organizational. It's an academic project that requires everyone to boil the ocean. They tried to get ARM interested and that didn't go anywhere and now they're trying to get RISC-V interested. But they haven't addressed any of the problems of why manufacturers would ever make a complex and completely incompatible chip for a problem that they (the manufacturers) don't have and don't care about, that can probably be solved 90% as well in software.

Rivos was competitive. Sadly bought by Meta and "disappeared" into the company.

is what every company that didn't understand disruption said.

There's zero chance CHERI will go anywhere, I wouldn't worry about it.

Krste wasn't even saying anything controversial. It's obvious that manufacturers will use the cheapest (free) least legally entangled option, and that this adoption will happen first amongst those with the tightest margins. And - Clayton's law[1] - it will eventually extend to the rest of the market (albeit over a very long time).

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

In the UK you pay income tax on the initial price; then if you hold the shares before selling capital gains tax on any gains. However CGT is a much lower rate than income tax so I guess it could be a bit advantageous. But you have to factor that against the risk of holding a single company's shares (also the company you work for), against selling and buying into the whole market.