It's one of those materials that has an almost complete list of superb properties, with one overwhelming downside. It's cheap, abundantly available, completely fireproof and can be woven into fireproof cloth, adds enormous structural strength to concrete in small quantities, very resistant to a wide range of chemical attacks. It's just that the dust causes horrific cancers. See also CFCs, leaded petrol, etc, which have the same 'very cheap, superb in their intended use, but the negative outweighs all positives'.

One of the 'niche industrial applications' was the production of pump gaskets in high-temperature scenarios, especially when pumping corrosive liquids. We've a range of superalloys that are 'suitable' for these applications - something like inconel is an absolute bastard to form into shapes, but once you've done so it lasts a long time. But you still need something with similar properties when screwing the bits together. For a long time, there was no suitable synthetic replacement for asbestos in that kind of usage.

If you know that the asbestos is there, have suitable PPE and procedures, then IMHO it's far from the worst industrial material to work with. It's pretty inert, doesn't catch fire or explode, and isn't one of the many exciting chemicals where a single droplet on your skin would be sufficient to kill you. What is inappropriate is using it as a general-purpose building material, which is how it was used for so long, and where it was able to cause so much suffering for so many people.

For something that doesn't run continuously, like eg. a refrigerator, then an average daily usage is more useful, no? "This product draws 1.5 kW with a duty cycle of 0.08" doesn't really help when comparing efficiencies of potential purchases, you'd need to convert it to electricity consumed in a set period anyway.

Assuming you had a pretty decent monitor and graphics output in the 90s, it may have been 800x600, but more likely 640x480, and you'd have been using the standard issue bitmap font with no anti-aliasing, blitted to screen using software rendering. Probably in a single colour, too.

Alas, the problem with that is that it doesn't scale. On xterm a 4K monitor, I can watch Vim redrawing the screen, paging through logs is painful. Use Kitty for the same, it's instant, I can flip through tabs and split screens too, and have niceties like anti-aliased fonts and transparency if I want them.

Some people spend a lot of time in the terminal, so I can't fault them for taking the time to make a nice working environment and sharing that work with others.

Writing in ASM is not too bad provided that there's no operating system getting in the way. If you're on some old 8-bit microcomputer where you're free to read directly from the input buffers and write directly to the screen framebuffer, or if you're doing embedded where it's all memory-mapped IO anyway, then great. Very easy, makes a lot of sense. For games, that era basically ended with DOS, and VGA-compatible cards that you could just write bits to and have them appear on screen.

Now, you have to display things on the screen by telling the graphics driver to do it, and so a lot of your assembly is just going to be arranging all of your data according to your platform's C calling convention and then making syscalls, plus other tedious-but-essential requirements like making sure the stack is aligned whenever you make a jump. You might as well write macros to do that since you'll be doing it a lot, and if you've written macros to do it then you might as well be using C instead, since most of C's keywords and syntax map very closely to the ASM that would be generated by macros.

A shame - you do learn a lot by having to tell the computer exactly what you want it to do - but I couldn't recommend it for any non-trivial task any more. Maybe a wee bit of assembly here-and-there when you've some very specific data alignment or timing-sensitive requirement.

A bit like when we renamed all the master/slave terminology using different phrasing that's frankly more useful a lot of the time, I think it's about time we got rid of this "child" task nonsense. I suggest "subtask". Then we can reword these books into something that no-one can make stupid jokes about any more, like "how to keep your subs in line" and "how to punish your subs when they've misbehaved".

In which case, the job becomes transferring the bottled samples into sample tubes in trays so that the machine can process them, and usually adding a barcode to each sample tube. The sample tubes need to be kept immaculate as well - some of the things that we test water for, like pesticides, are only present in miniscule concentrations. Might not actually save a great deal of time, and you need to buy and maintain a very expensive automated sampler.

When I used to work in the water industry, we were usually able to get PhD-qualified research chemists to do all this mind-numbing laboratory work. There's a bit of a surplus of qualified chemists compared to the number of chemist jobs available, so you got absurdly over-qualified people applying for these roles.

Cheaper for now, since venture capitalist cash is paying to keep those extremely expensive servers running. The AI experiments at my work (automatically generating documentation) have got about an 80% reject rate - sometimes they're not right, sometimes they're not even wrong - and it's not really an improvement on time having to review it all versus just doing the work.

No doubt there are places where AI makes sense; a lot of those places seem to be in enhancing the output of someone who is already very skilled. So let's see how "cheaper" works out.

After cutting it straight on the worktop without a chopping board, too. Fuck your knives, fuck your surfaces, fuck cleaning up afterwards.

I still have a Rage 128 hanging around as a 'temporary head' for installing headless servers. Many happy nights playing Thief: The Dark Project with it, and now it's only good for rendering a TTY at a barely acceptable resolution. And soon, not even that. Goodbye, little e-waste :-(

Yeah, reminds me of the original Gameboy. Weak hardware, terrible screen, great battery life, awesome first-party support, stupidly robust. Sold a hundred million or so. Up against the Game Gear and Atari Lynx, which although basically miniature consoles, had an unquenchable hunger for batteries and crap games. Complete turkeys. All of Nintendo's other, very successful, handhelds continue the same idea; yes, a Switch is really underpowered compared to the newest Playstation, but that's not it's niche.

Yes; you can pack more powerful hardware into the space that a Deck, or a Switch, or even your phone, takes up. But is the amount of fun you get from that device increased in reasonable proportion to its increased cost?

That's nuts.

Moved over from Mint to Arch for gaming, which has some additional benefits:

• more up-to-date kernel and more up-to-date Mesa, which brings very noticeable improvements in frame rates - in Elden Ring for example, 45 fps outside in Mint to 60 fps outside on Arch

• my desktop soundcard isn't recognised properly by PulseAudio but is by PipeWire. It's hard to be sure that PulseAudio is completely gone when you uninstall it then reinstall something else. Arch, I just installed what I wanted in the first place

• some utility programmes, like CoreCtrl for graphics card fan and power tweaking, and emulators like RPCS3, are the Arch repositories but not the Mint ones. Much easier to keep them up-to-date

• for a gaming machine, no more 'mystery services' that I don't know what they are. I quite like having everything quite stripped back for a gaming machine. On Arch, I know what everything does because I installed it. That's not the case on Mint.

Obviously, I installed the Cinnamon desktop as my GUI choice - there's certain things about Mint that are tremendous and worth sticking to.