I consider sodium-ion as an extension of lithium-ion because they’re made by the same folks with similar processes. They are still early, but very much in the process of being ramped and will be incredibly useful for stationary storage: lower density, but better durability. Another real technology that Form will have to compete with.
It was a then-important optimization to do the most common operations with macros since calling a function for every getc()/putc() would have slowed I/O down too much.
That's why there is also fgetc()/fputc() -- they're the same as getc()/putc() but they're always defined as functions so calling them generated less code at the callsite at the expense of always requiring a function call. A classic speed-vs-space tradeoff.
But, yeah, it was a mistake that it originally used a "char" to store the file descriptor. Back then it was typical to limit processes to 20 open files ( https://github.com/dspinellis/unix-history-repo/blob/Researc... ) so a "char" I'm sure felt like plenty.
> The creator of MINIX, Andrew Tanenbaum, asked the community to choose between Stevie and Elvis to be adopted as the main text editor for their OS. Elvis was chosen and it's the default text editor on MINIX until today.
Up to now I have been using elvis exclusively, rather than vim, both on Windows and Linux - I never saw the need to switch, since elvis does everything I need. I just retired it last month, when I upgraded some systems to the latest release of Debian Bookworm and the elvis graphic interface started crashing the whole X windows manager. I have the source code, but I don't have the patience to recompile and debug it.
It's not a tube, it's an overground line. As evidenced by this Network Southeast livery.. on a tube train that's an overground train that goes entirely underground https://m.youtube.com/watch?v=MhUDyX4DKXQ
The Waterloo and City was transferred to London Underground in 1994, as part of the privatisation (or not in this case) of British Rail.
As the only way to get trains on and off the line involves craning them out of the depot[1], they did retain their Network South East livery for about a decade after formally becoming an Underground line though, until repainted at an off line overhaul.
[1] There used to be a lift that could take a carriage at a time to surface tracks, but the Eurostar extension at Waterloo did for that.
A few months ago I happened to install Debian/unstable on a G4 mini. ppc32 is no longer a supported architecture -- purely "what you get is what you get".
Still, the process was mostly painless. Everything I needed worked out of the box.
This is the exact same transition process 68k went through for most platforms it was on. Just left it in the build process and as packages were unable to be built for the arch they just delisted them from the builder until core packages no longer functioned; at which point total support was removed:
I’m pretty sure most large storage operations (U-Haul, extra space, etc) have per unit door sensors which work in concert with customer check in/out to verify authorized openings.
I have never encountered anything like this at storage units from a wide scale of corporate ownership, different levels of newness, and different levels of affluence in the area. Not saying they don't exist but I've never seen any reasonably priced storage units that bother with this level of tracking.
I'm pretty sure they don't: source I've helped move people's stuff in and out of a couple of different places. My experience is very limited, so if you have more data points where you have seen such things, please share.
I can speak for U-Haul specifically because I have used them and a customer can see the sensors in their unit. The sensors are deactivated when a customer checks in.
The local storage operation I use has exactly that. If you do not "badge in" and open a door - the alarm goes off. When the manager was showing me the unit he said "Hey, an alarm is going to go off when I open this door - don't be surprised" and explained the system.
Yup! My local U-Haul has a sign in/out system. In the main office there's a monitor/giant TV that shows a map of the facility, including alerts for all doors currently open and authorized.
If I don't sign in, as soon as I try to roll my door up the alarms are going to go off. If I don't sign out after closing the door and leaving, the next time I try to sign in I will be denied entry until I speak to a manager and be yelled at about signing out when I leave.
> in that case, a compiler still must set something up to fulfil the main `noexcept` promise - call `std::terminate()`
This is actually something that has been more of a problem in clang than gcc due to LLVM IR limitations... but that is being fixed (or maybe is already?) There was a presentation about it at the 2023 LLVM Developer's meeting which was recently published on their youtube channel https://www.youtube.com/watch?v=DMUeTaIe1CU
The short version (as I understand) is that you don't really need to produce any code to call std::terminate, all you need is tell the linker it needs to leave a hole in the table which maps %rip to the required unwind actions. If the unwinder doesn't know what to do, it will call std::terminate per the standard.
IR didn't have a way of expressing this "hole", though, so instead clang was forced to emit an explicit "handler" to do the std::terminate call
In MSVC we've also pretty heavily optimized the whole function case such that we no longer have a literal try/catch block around it (I think there is a single bit in our per function unwind info that the unwinder checks and kills the program if it encounters while unwinding). One extra branch but no increase in the unwind metadata size
The inlining case was always the hard problem to solve though
Don't expect it to do much, but it's fascinating if you're interested in OS history.