One problem with distro packages is that you can only install one version.

This isn't technically true for all distros—Gentoo has a mechanism that will allow multiple package versions to be installed in parallel. I have multiple distro-packaged Python and Lua interpreter versions on my system, for instance. But it does require some extra work by the packager, so it isn't done universally for all packages.

It used to be much, much more difficult than it is today, but your experiences will still vary according to what type of printer you have. The problem is drivers. There are still printers out there that have no working Linux driver (mostly old, non-Postscript-supporting, with no Mac drivers either). Some will work with a generic driver, but some features aren't available. The more annoying case is the one where the manufacturer put out a driver once, many years ago, it doesn't work properly with modern versions of CUPS, and they can't be arsed to revise it.

But most printers these days will do basic one-sided 100%-size prints out of the box, and that's all many people need.

Some level of self-discharge happens over time with even a disconnected battery, but that does seem greater than expected. I'd suspect hardware issues, to be honest. Batteries are fickle little creatures that deteriorate over time no matter what you do. Maybe it's misreporting the amount of charge left to the OS.

One thing people reading this should remember is that you cannot guarantee all packages on a Gentoo system will be updated simultaneously. It just can't be done. Because several of the arches affected by this are old, slow, and less-used (32-bit PowerPC, anyone?), it's also impossible to test all combinations of USE flags for all arches in advance, so sooner or later someone will have something break in mid-compile. For this change, that could result in an unbootable system, or a badly broken one that can't continue the upgrade because, for example, Python is broken and so portage can't run.

The situation really is much more complicated than it would be on a binary distro whose package updates are atomic. Not intractable, but complicated.

That being said, even a completely borked update would not make the system unrecoverable—you boot from live media, copy a known-good toolchain from the install media for that architecture over the borked install, chroot in, and try again (possibly with USE flag tweaks) until you can get at least emerge --emptytree system or similar to run to completion. It's a major, major pain in the ass, though, and I can understand why the developers want to reduce the number of systems that have to be handled in that way to as few as possible.

So, Poettering wants to make life difficult for everyone using something other than his precious again by transitioning from the normal standard for IPC to something hardly anyone has ever heard of or uses that's based on JSON? Seriously? 🤢

Yup, called it: non-mandatory piece of software. Plus you have to have been dumb enough to deliberately forward the port at your router for the general-case attack, and you have to print something (which I do maybe twice a month) for any command injection to take place.

This does need to be patched, since there is some risk if you have CUPS running and another device on your LAN has already been compromised, but it's definitely not the earthshattering kaboom the discoverer misrepresented it as.

I can't think of anything except the kernel that is genuinely obligatory on all Linux systems, including embedded. Not glibc (musl). Not udev (mdev). Not systemd (OpenRC/runit/etc). My guess is that this is another exploit of something the reporter hasn't realized isn't mandatory because they're not familiar with non-mainstream distros. I suppose it could be a kernel issue that Android has specifically patched, but if that's it it'll be fixed in short order.

In other words, not exactly holding my breath.

To be exact, OpenRC was developed to be run on top of sysV init, and still can be. (Many distros had their own "on top of sysV" things, but most of them stopped being maintained as systemd became common. OpenRC started its life as Gentoo's "on top of sysV", but was then cleaned up and made distro-agnostic.)

s6 is apparently a daemontools-like process supervisor that can be run as an init or in company with some other init.

Gentoo's comparison of init systems lists Artix as the preferred service file supplier for s6 (although that may be outdated), so I expect it is or was used extensively by that distro.

Or, if you can't find any of those other settings, try decreasing the font size by 1 pt or 1-2 px (not sure what unit KDE6 uses for font sizes) and see if that works better with the new font's letter widths and kerning.

Nor does Forth (which used to be a common choice for "first thing to bootstrap on this new chip architecture we have no real OS for yet"). Alas, they're just not popular languages these days.

Actually, I don't think you could break a system in quite this way in Gentoo these days. Portage generally doesn't remove packages during upgrades (certainly not unrelated ones that would break the depgraph!). It would have exited with (in this case) a message about version conflicts before changing any packages and left it for the user to sort out. Modern versions of portage do a pretty good job of keeping you from shooting yourself in the foot by accident, while leaving you with a lot of leeway for doing so on purpose.

Assume anything you can buy has a shelf life and set a yearly reminder on your calendar to copy forward stuff more than five or so years old, if those files are of significant value to you. Or for the documents, print them out—paper has better longevity than any consumer-available electronic storage.

That being said, quality optical discs are probably the best option in terms of price to longevity ratio for the average person right now. Just keep in mind that they are not guaranteed to last forever and do need to be recopied from time to time.

(I have yet to have a DVD fail on me, but I keep them in hard plastic jewel cases in climate-controlled conditions, and I've probably just been lucky.)

I prefer Claws Mail. It does what I need it to.

It was a legitimate but extremely rare concern with some early printers, yes (Wikipedia points out a particular early laser model from Xerox, plus an experimental machine from 1959, as printers that have legit caught on fire, but also points out that there is no known report of one of the old industrial-sized line or drum printers ever catching fire from friction despite it being a hypothesized failure mode). Thing is, those printers were, I believe, all obsolete by the time the Linux kernel was written. So the "on fire" error message is not likely to have been congruent with reality for any machine actually running Linux.

We're talking about a kernel whose user-visible error messages have historically included things like "lp0 on fire" . . .

There's an old joke from a couple of decades ago about what operating systems would be like if they were airlines:

Linux Airlines

Disgruntled employees of all the other OS airlines decide to start their own airline. They build the planes, ticket counters, and pave the runways themselves. They charge a small fee to cover the cost of printing the ticket, but you can also download and print the ticket yourself. When you board the plane, you are given a seat, four bolts, a wrench and a copy of the seat-HOWTO.html. Once settled, the fully adjustable seat is very comfortable, the plane leaves and arrives on time without a single problem, the in-flight meal is wonderful. You try to tell customers of the other airlines about the great trip, but all they can say is, “You had to do what with the seat?”

Gentoo is still very much a "You had to do what with the seat?" distro, while most others have retired that concept to varying degrees, at the cost of the seats being less easy to perform unusual adjustments on.

Assuming that it works out, yes, this might fix the problem. On the other hand, I remember gcj, which kind of quietly vanished after a while, so I prefer to reserve judgement until gcc's Rust implementation is ready for production use.

One detail about Rust in the kernel that often gets overlooked: the Linux kernel supports arches to which Rust has never been ported. Most of these are marginal (hppa, alpha, m68k—itanium was also on this list), but there are people out there who still use them and may be concerned about their future. As long as Rust remains in device drivers only this isn't a major issue, but if it penetrates further into the kernel, these arches will have to be desupported.

(Gentoo has a special profile "feature" called "wd40" for these arches, which is how I was aware of their lack of Rust support. It's interesting to look at the number and types of packages it masks. Lotta python there, and it looks like gnome is effectively a no-go.)

Large organizations always have politics—it's human nature. 1700 people is quite a large organization. Therefore, the kernel maintainers have politics. The presence of politics always means that some people will get stomped on unfairly.

This is all business as usual, in other words, and it will not go away. At best, you can shift the culture of the group and the politics along with it, but that takes time and effort and people-handling.

For files? An unholy amalgam of snake, kebab and dot, depending on what exactly I'm trying to convey. (I still have much-ported files around with DOS 8.3 filenames, so they're truncated scream case (SCREAMIN.NAM), but I don't actively name files like that anymore.) The important thing is to separate the words/sections while using characters that are valid without escapes in both ext4 and vfat if at all possible.

For variable names, camel or Pascal case (depending on language convention) if I think anyone else is going to read it. Flat case for code I don't think anyone else is ever going to see (don't do this—it has left teethmarks in my ass from time to time and will do the same to you).