SoylentNews is people
SoylentNews
Edit: The link.
There were lots of good titles for this submission, as in "Breaking news: Poettering clueless?" to finally disprove Betteridge's law, or "systemd surprisingly not as good as advertised" or "Breaking new: systemd broken" or "Poettering censors critics after epic fail".
Systemd implementation of "rm -rf .*" will follow ".." to upper directory and erase /
How to reproduce:
# mkdir -p /foo/dir{1,2}
# touch /foo/.bar{1,2}
# cat /etc/tmpfiles.d/test.conf
R! /foo/.* - - - - -
Reboot.
After the issue was fixed, finally Poettering added this gem of wisdom:
I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
The answer to this question, as many clarified for him, obviously is a loud "NO!". After being told a couple of times in no uncertain terms, the thread was closed for non-developers
poettering locked and limited conversation to collaborators 4 hours ago
for which I proposed the "freedom-of-speech" department (although I admit it is a weak proposal).
(Score: 3, Interesting) by Marand on Tuesday April 18 2017, @03:45AM (4 children)
Also to be clear I don't want systemd anymore . . . I loved it back when I thought it was meant only to be an async startup solution though. Siiiiiigh
That's more or less my feeling about it as well. I like the idea of alternative inits with different strengths, and I would have been fine with systemd as another drop-in replacement for sysv init with a different set of goals. I had a bad feeling about it from the start, though. Partly due to its heritage (Pulseaudio has been nothing but unnecessary pain for linux) and partly because even early on it was being used to absorb other things like logging, instead of playing nice with other parts of the system.
I was also suspicious about the insane amount of FUD being slung around and used to justify the switch. One argument that seemed to come up any time someone questioned systemd's purpose was that we needed it to save us from the horrors of using bourne shell scripts during boot, which was complete bullshit. You can use anything for init, so if that were really the goal it would have been easier to write a unit file interpreter and put a #!/bin/unit_interpreter shebang at the start of any unit files used during init. The interpreter could parse the file and turn it into proper startup/shutdown/etc. You could have the best of both worlds: a simpler, shell-free syntax for basic tasks; and full scripting/programming languages for init "scripts" that don't neatly fit the unit file niche.
I believe that path could have also been used to replace the underlying init in a smoother way as well. Make a replacement init that sends next-gen compatible init "scripts" whatever new commands you want, while the legacy ones get sent the start/stop/reload/etc. commands, eventually phasing out the old completely. Along the way, the unit-interpreter could be used to phase out most of the shell scripts, leaving only the ones that specifically need the flexibility. Maybe even have this init-ng start out in legacy runlevel mode and eventually flip a switch so that it uses its own replacement concept? Dunno, this is off-the-cuff rambling so I haven't put that much thought into it. Point is, the big goals — "parallel booting" and "no shell scripts" — could have been achieved in a way that didn't throw the baby out with the bathwater. (I think that's the saying, at least...)
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @04:42AM (2 children)
And nothing forbids doing something like:
With init-scripts loading all the functions required, and script_done triggering them. To some point sysv scripts were migrating towards this, using a set of common functions and comments (common in many places: blocks read by tools to do things, or to show defaults and options without putting them as active directives), so unless you needed total control, it was a simple template.
But the whole point of systemd is replacing what exists and making sure there is no way to switch back or even "to the side". Bluntly: eliminate choice.
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @02:00PM
And crazily enough, that is to some degree what BSDs use.
One central script file defining the basic tasks, and the various daemon/services(ugh...) files that source said script file.
Sadly RH and Debian clung to the AT&T way...
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @02:15PM
Talking about eliminating choice.
http://www.islinuxaboutchoice.com/ [islinuxaboutchoice.com]
That domain is assigned to Emmanuele Bassi (ebassi), one of the bigger resident assholes at Gnome.
And it links to an email written by Adam Jackson (Ajax), a prominent developer at Red Hat and Fedora.
In effect, there are big name people involved with Linux user space that do not want there to be choice. Because choice complicates their life. They want one, canonical (heh), Linux distro. And how they plan to achieve this is by tightly interlocking the DE to the plumbing.
In recent years Gnome has pushed out various projects, Among them XDG-app/Flatpak and OSTree, that go way beyond the considerations of a desktop environment. Along with this you have the tight coupling of Gnome and systemd, that itself is a massive blob of formerly loosely coupled Freedesktop projects. And if you pay attention you will notice that most of this is being showcased and first implemented on Fedora.
And frankly this has nothing to with users best interests.
Ebassi have in the past made clear statements that he considers users idiots that best belong in a padded cell.
What is going on is development for developers. Every change done is not to make user life easier, if it does that is an unconsidered side effect.
And this very attitude is why desktop Linux never happens, even though the kernel shows up in all manner of places.
Because Unlike Ajax, Ebassi, Poettering, and a whole bunch of others, Torvalds holds the kernel develops to one simple principle "do not break user space". Thus any change to the kernel that affects an exposed API, syscall, or similar, can't change the behavior of it, official or de-facto, compared to how it was when it was first introduced.
The one fear is that when Torvalds decides to step down, GregKH takes over. This because he is currently in charge of maintaining the stable kernel versions. And he appears to be a close ally of the very people that make Linux user space a eternally broken churn of code.
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @10:13PM
> throw the baby out with the bathwater. (I think that's the saying, at least...)
Yes, that is correct usage.