Debian Technical Committee overrides systemd change
27 points by gnyeki
27 points by gnyeki
Incidentally this looks like it's just breaking things in arch right now.
Neither the systemd package nor the alsa-utils package seems to have any relevant patches applied. And...
$ ls -l /var/lock
lrwxrwxrwx 1 root root 11 Oct 12 12:21 /var/lock -> ../run/lock/
$ ls -ld /run/lock
drwxr-xr-x 4 root root 160 Oct 21 10:22 /run/lock/
$ alsactl dump-state
alsactl: state_lock:168: file /var/lib/alsa/asound.state lock error: Permission denied
..."though it made him shudder to think of allowing unprivileged programs to fill up a directory"
Has Poettering never heard of quotas? Will they next move to not letting people log in, because of the trouble users can cause? Do they not have an acceptable contingency for /run filling up? If not, that should be the solution to the problem.
Full quote:
(by taking over the dir, the distros can easily make their own choices regarding ownership/access mode of the dir btw. i.e. make this world-writable or writable by some group, though it makes me shudder that you open up another dir to be filled uncontrolled by otherwise unpriv programs. in upstream systemd at least we try very hard to get away from uncontrolled dirs that are shared by multiple mostly unpriv users. For example we finally were able to add /tmp/ quota mgmt on tmpfs to logind to close one of the last gaps there (i.e. unpriv users cannot DoS the system by taking unbounded space there). Congratulations if Debian opens that door again, and introduces /run/lock/ again as a dir where arbitrary stuff – i.e. any user in 'callout' at least – can dump gigabytes of data making the system crash by consuming everything free in /run/.)
https://github.com/systemd/systemd/issues/38563#issuecomment-3242751978
Edit: Quota support for tmpfs was introduced in linux-6.6.
I often see the kind of criticism levelled at systemd that essentially boils down to assuming the systemd developers are either ignorant or incompetent. As this quote shows, and as is my view from having followed the project for quite some time, that just isn't true.
People may disagree with the philosophy behind systemd's design, or come to the view that it's not suitable for their particular use case, and that is their prerogative, but there is a tonne of careful consideration that goes into its design and implementation. I think critics would do well to be more precise in their critique.
What is the design philosophy that leads to this change? I can't find one. Not in that bug report. Not in the original description of the change. I can't find a CVE cited. I think this comes down to them not liking something that is disordered but broadly accepted for many years. They prefer to satisfy their own fetish for order, without any real value. I'd love to be disabused but after reading dozens of similar discussions I have to find an example of anything written down before a change was made that would lead anyone else to predict the change that was made.
They prefer to satisfy their own fetish for order, without any real value.
This is outright a silly thing to say, and says a lot more about you to me than it does about systemd developers. If you don't like the decisions systemd makes, just don't use it. You don't have to spend your days making up people in your head to get angry at.
You don't have to spend your days replying to me if you don't want to engage with my entire comment, including the clear question I asked. Please move along.
I did want to engage, because I think it is toxic that in the open source world people can act as childish and entitled as you are without anyone calling them out on it. Grow up.
There's nothing entitled about wanting and expecting known and consistent behavior to remain known and consistent, and wanting and expecting any move away from that to be documented with clear reasoning.
Remember, the Linux distros have been and are currently being taken from the communities. They're almost all corporate now, and even Debian is led by people who don't care about Debian's own "Reasons to use Debian" as much as they care about popularity contests.
systemd says they're going to force changes on everyone, whether you want them or not, and there's nothing wrong with people pointing out that it's shitty. There's also nothing wrong with pointing out the lack of public discussion, the lack of explanation and rationale, the lack of acknowledgement that this is really done by fiat and they're not interested in community feedback.
Calling someone's actions childish when they're expressing discontent is, well, childish. There's nothing that dvogel said that a reasonable person would consider toxic or entitled. Please don't be toxic yourself.
Calling someone's actions childish when they're expressing discontent
Lmao come on be serious. When you express discontent with open source software you don't like do you normally go on the internet and basically say the authors have a mental illness?
The rest of your comment is somehow more nonsensical and not really worth responding to.
Anecdotal: I've had programs (electron based) which like to fill up the /run/user/UID directory, I appreciate that it only requires logging out then in again, as opposed to a full system restart (As I don't want to be taking random shots at files, since I don't know if a given file is in use or not, so I find relogging/restarting more practical than random deleting)
If I had to guess, I'd say that the decisions are made on some mailing list related to systemd development.
Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. The specification was not so much finished as abandoned after FHS 3.0 was released—though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results.
Meanwhile, in the absence of a current standard, systemd has spun off its
file-hierarchydocumentation to the Linux Userspace API (UAPI) Group as a specification.
[...] Fedora's search for an FHS successor.
Wow. I was completely unaware of FHS being considered obsolete! I always saw it as the ideal configuration most distros (except, of course, the likes of NixOS, Guix, Gobolinux) tried to adhere to with varying success or convenience. Even NixOS and Guix have utilities like buildFHSUserEnv or --emulate-fhs to emulate FHS.
I suspect its just the branding that would probably go obsolete. Any successor would still stay close the spec as much as possible. Can someone more knowledgeable shed some light on this?
Author here: The Finding a successor to the FHS article goes into this a bit -- the FHS is increasingly outdated, and that's causing problems. There is allegedly an effort to do an FHS 4.0 but that seems stalled, and the systemd/UAPI folks have put forward a spec, but that spec is much less detailed than the FHS. (e.g., the FHS specifies what commands should be found under /bin, whereas UAPI's spec doesn't get to that level of detail).
The lack of an up-to-date FHS means that there's going to be increasing drift between mainstream distributions that have to make these decisions on the fly and diverge more and more. That's a problem for anybody writing applications for Linux, which is why the FHS existed in the first place.
UAPI's spec might solve some of that, but it's going to be heavily influenced by the way systemd wants to do things. Whether that's a problem or not is really up to the observer... I would say that I agree with the reasoning from the systemd folks on the underlying change that sparked this story, but it was not well-coordinated with distributions.
Thank you! The linked article was insightful.
The distros that use systemd anyway, i.e., the mainstream ones, may probably fall in line for UAPI spec too, sooner or later.
I have a very shallow understanding of what has been going on... I'd like to understand, in broadest terms, the politics of init systems. Can you explain briefly or give pointers to some good explanations out there? What I must/need to understand from the perspective of an end-user; and what can be learnt from the apprehension of the community regarding corporate influence, or politics of/amongst FOSS developers/maintainers in general.
I think this story both has not a lot to do with "init system politics" more generally and is not as big a story as they make it sound in the title.
Here's my attempt at summarizing what's went on:
All in all, I think this is pretty much "working as intended". Upstream gets to move forward with removing legacy cruft, debian can scratch its own itch and keep its users happy until the impacted software projects switch to the more modern flock.
Author here: Apologies if the title implied more than what went on, but it's not common for the TC to have to override maintainers. It's not unheard of by any means, but it's rare, and I thought pretty noteworthy. And I didn't want to put the focus on maintainer but on the technical effect. Anyway, it was meant to be descriptive, not inflammatory. If this had been on ... other publications it probably would've been something like "Debian TC slams maintainer" or some thing.
I'd like to know if there's a statistic for TC decisions to override maintainers from its establishment; how many were related to systemd, compared to any other package; and whether this is a meaningful measure.
Thanks for the technical rundown. This case is as unremarkable as you put it. My question was more about the climate rather than the weather. How has systemd been faring throughout all its history, compared to the rest?
Is there a parallel than can be drawn, e.g. with Signal vs Matrix vs XMPP protocols, regarding backwards compatibility and feature rollout that breaks compatibility, technical pros and cons of centralization vs decentralization/federation, vertically and horizontally along the stack? How about X11 vs Wayland? Can any big-picture conclusions be drawn from all of these?