addie

Ah, that sounds a bit unfortunate. I've run AMD CPUs on Linux desktops with Bulldozer / Piledriver / Ryzen 7, my current laptop is a Ryzen 7 as well, never run into that at all. Hopefully the Arch wiki will sort you out. If not that, the third option would be 'install Linux on an M-series Mac' - don't know how feasible it is at the moment, and paying the 'Mac premium for hardware and software integration and then overwriting the software' doesn't make a lot of sense to me.

No, it really is that simple. I've got Cinnamon installed since I prefer it for everyday; also, Gnome3 on Wayland for gaming (I've three monitors with different refresh rates, which doesn't work as you'd hope on X11). Log out, change desktop, log in again. No problems at all, except for more packages to update.

My choice as well. I do my C++ development in Vim, and the keyboard shortcuts for switching tabs were the best I'd found. The easy screen-splitting is great when manipulating virtual machines, or having a man page open when working on scripts.

I was bewildered by this myself. The developers who were famous for their walking simulators but who fired all their staff a few years back (keeping the studio founders) have taken over a project where the original developers were dismissed amid some damaging-sounding rumours and budget overruns. Hardsuit Labs presumably had completed most of the initial writing work and concept art - their 'tech demos' looked pretty convincing, even though that kind of thing is very carefully managed - but must have still been a long way from anything that could be released. A mystery. See how it goes - still a year away, anyway.

Yeah; if I was picking the aspects of Ubuntu where they were making a mistake, 'minimal default install but easy to download more' would not be what I'd have selected - that actually sounds a good thing. Having too much out-of-date crud was starting to be a problem. 'Everything is a snap, which runs like a three-legged dog even on a powerful machine, and causes me disk space issues on less powerful ones too' - that's a problem. 'Keeping on messing with Firefox, and replacing my ppa version with an out of date snap, which means I've changed my works machine over to Mint to avoid their nonsense?' - that's a problem.

Means it has positive polarity, fixed modality, and fire triplicity. Don't you know nothing?

Do it. I did it years ago, never looked back, and it's only gotten better since then - Proton has been off like an absolute rocket lately, and publishers considering the Steam Deck a 'first class' target should mean an end to them bundling the broken anticheat that stops 100% compatibility.

Advised against in the late 90s since it was a pretty common habit from the dawn of computing through till the early 90s, and they'd finally realised it wasn't the best of ideas, even if it was very very fast.

The number of times that Windows has been pwn3d by 'legacy' formats - images, font files, crazy stuff - that it's attempted to parse for thumbnails is pretty crazy. There's a lot of programmers writing unsafe code out there.

... email conversation with Sensible Software legend Stoo Cambridge, and ...

Nice that the solution for this is so trivial, if you want it. Always a bit of a security concern though with these venerable old file formats (and certainly, no modern machine wants the colour palette in interleaved bitplanes) where the loading technique was generally 'map it into memory, and treat it like a struct'. ILBM isn't as complicated as eg. TIFF, but buffer overruns and pointer shenanigans in dusty code is something to be wary of - I wouldn't want this enabled by default

Don't think so in this case - we were all expecting him to be assassinated somehow, and the old 'sushi dinner with a nice cup of tea after' wasn't very likely. Should have had a sweepstake on his life expectancy - guessing 60 days would have been pretty impressive.

Witcher 2, before they patched in the tutorial mission. (Which is still not very good as a tutorial.) Enjoy getting a shitkicking in the very first fight, since you've no idea of the controls.

Once the kernel has loaded itself, it needs to start up userspace as well. This is usually (perhaps exclusively) done by starting an 'init' program as process number 1, which then starts up all the other userspace programs: systemd is no different in that regard. It solves a variety of problems that traditional inits have, though:

• rather than having near-incomprehensible shell scripts to start, stop, etc. all your programmes and services, it uses INI-style service files which are merely fiddly. They're kept in a few logical places, not 'everywhere'

• starting and stopping services is done with simple, consistent commands - systemctl enable tomcat will start the Tomcat webserver at next boot; start, restart, stop and disable do basically what you think. Shell scripts are... less predictable, especially between distros.

• rather than having to inspect all of your scripts and work out what order they start in, SystemD just lets you declare what they depend on, and it works it out for you - much simpler, much more robust.

• rather than needing a separate tool to manage scheduled events (usually a chron-like, like anachron), SystemD just lets you write a 'timer' with the same syntax as its service files. They can be set to only trigger based on other events, like start-up, so you can do once-an-hour database snapshots (but only if the DB is running) very easily. That's painful with traditional inits.

• also manages disk and network mounts, so you don't need a separate tool for those, and you can trigger other events off of them as well. That was also painful in older inits.

• and power events too, if you want to trigger other tasks before sleep or when your laptop wakes up. (Again, was painful before.)

• log files all in one place and controlled in the same way and accessed with one tool - again, traditional inits aren't like that.

• (advanced usages) works well with cgroups, so if you're looking to limit the CPU time on a web service and make sure that it only uses its share of memory, that's dead easy. Very difficult with traditional init.

You can get a reasonable idea of what systemd is doing with a systemctl status at the command line; shows you the overall system status, with a nice tree view of what's running and what caused it to start. Getting that kind of overview on a eg. SysV init is much less simple.

Administrators and devops generally love it; it's very simple and straightforward and consistent and predictable. Certain devs dislike it, due to the original author, or feelings of overreach and complexity (although it's much simpler than learning everything that it replaces), or because they're attached to Bash scripts. (You can trigger Bash scripts with SystemD if you like, but they're not 'in control'.)