Slashdot Mirror
How Debian Almost Failed to Elect a Project Leader (lwn.net)
Five candidates now are running to be Debian's project leader for the coming year. But earlier this week, Slashdot reader Seven Spirals shared LWN's story about what a difficult election it's been:
This year, the call for nominations was duly sent out by project secretary Kurt Roeckx on March 3. But, as of March 10, no eligible candidates had put their names forward... There is nobody there to do any campaigning.
This being Debian, the constitution naturally describes what is to happen in this situation: the nomination period is extended for another week... Should this deadline also pass without candidates, it will be extended for another week; this loop will repeat indefinitely until somebody gives in and submits their name... In the absence of a project leader, the chair of the technical committee and the project secretary are empowered to make decisions -- as long as they are able to agree on what those decisions should be. Since Debian developers are famously an agreeable and non-argumentative bunch, there should be no problem with that aspect of things...
One might well wonder, though, why there seems to be nobody who wants to take the helm of this project for a year. The fact that it is an unpaid position requiring a lot of time and travel might have something to do with it. If that were indeed to prove to be part of the problem, Debian might eventually have to consider doing what a number of similar organizations have done and create a paid position to do this work.
This being Debian, the constitution naturally describes what is to happen in this situation: the nomination period is extended for another week... Should this deadline also pass without candidates, it will be extended for another week; this loop will repeat indefinitely until somebody gives in and submits their name... In the absence of a project leader, the chair of the technical committee and the project secretary are empowered to make decisions -- as long as they are able to agree on what those decisions should be. Since Debian developers are famously an agreeable and non-argumentative bunch, there should be no problem with that aspect of things...
One might well wonder, though, why there seems to be nobody who wants to take the helm of this project for a year. The fact that it is an unpaid position requiring a lot of time and travel might have something to do with it. If that were indeed to prove to be part of the problem, Debian might eventually have to consider doing what a number of similar organizations have done and create a paid position to do this work.
From the same dipshit group that voted for systemd by default.
Only the State obtains its revenue by coercion. - Murray Rothbard
Whether you like or hate systemd, it must be a pain to deal with all the drama and hate surrounding it when all you want to do is put out a decent distro. I am sure there are people saying, "You don't install systemd on the bios in Debian? Dumbasses!" Who wants to deal with that kind of negativity?
"First they came for the slanderers and i said nothing."
Whether you like or hate systemd, it must be a pain to deal with all the drama and hate surrounding it when all you want to do is put out a decent distro.
If it really is such a corrosive issue that reaches everyone then wouldn't it make sense to make it optional, if only to prevent hardship on your packaging teams?
My understanding is that most packages simply need to be rebuilt using ./configure --without-systemd. Would it not be worth making a set of "without systemd" packages to quell the drama and hate?
Anons need not reply. Questions end with a question mark.
I for one just hope they had the good sense not to vote for somebody orange.
The main purpose of systemd -- beyond being an init system -- is to be a common collection of utilities which software authors can lazily depend on being present. That's why it gobbles up so many seemingly unrelated things: so that having a dependency on a given systemd version can guarantee the presence of particular versions of all those utilities.
Most packages can still work without systemd, but probably in a less-well-tested way, and a distro has to make all supported packages work well. That's a whole lot of work. And the very reason that so many distros have adopted systemd is that it reduces their workload so they can get more done with fewer volunteers. They're not going to see much point to using a workload-reducing project to increase their workload.
Hence it's left to the people who really care about disliking systemd to do the work of maintaining non-systemd variants like devunan.
This space intentionally left blank
What this situation actually tells us is that they've been able to get a CEO to work for free. 5 volunteers for it, in fact. Turns out there are people willing to do a ton of work for free just for the glory of getting to call their self boss.
This space intentionally left blank
Another way to look at it is that the position is an excellent opportunity, especially for someone who is involved with Open Source ecosystem studies or something similar. Imagine having the position of DPL on your résumé (CV)!
Gentoo and Funtoo handle it easily, but apparently "it's too hard to support other init systems" has been the go-to excuse for all the other distros to force it down everyone's throats.
Use distros that support other init systems, and refuse the others, and the systemd stupidity will eventually sort itself out.
"people who really care about disliking systemd"
The reason they dislike systemd is NOT because "they care about disliking systemd". Its because they dislike the horrible way systemd is designed and works.
Hey, it sounds like a paid position is actually on the table -- but only if nobody volunteers. This is just the year everyone decided to hold out for a better offer.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Comparing "man showpath" with "man traceroute", we find that showpath can do a lot less than traceroute can - it has far fewer options.
One might also notice that unlike traceroute, showpath tries a bunch of ports and hopes - the results of showpath might be similar to reality, the results are often right, often not. Traceroute uses one and the results it provides are correct. (Or in case of error, traceroute indicates an error, as opposed to false results).
So by now I'm sure you see why traceroute had to be replaced by showpath - to make it dumber and less reliable.
Actually the best I can tell, those who wanted to replace traceroute never bothered to check the docs after they heard about a "problem" with tracert which doesn't actually exist. The excuse for getting rid of traceroute is that "you have to be root to run traceroute", but that simply isn't true. There are in fact TWO different ways that non-root users can run traceroute. Like ping, normally it's installed setuid, which allows any user to run a small program as if they were root. You wouldn't want large, complex programs to run setuid in case of security bugs in them, but for small, simple programs it's fine. If you don't want to set it setuid, any user can still run it and it'll do the same udp trick that showpath does. Showpath is literally a small subset of traceroute's functionality. It's not so much replacing one with another, but rather "take away all of the most commonly used options for traceroute and leave only showpath remaining". Genius.
Seems like a better approach would be to replace systemd with something better. Make fork it, maybe start from scratch. Replace the existing functionality to the point where most stuff works, start adding support for the new system to apps.
If it really is better it should quickly gain support and replace systemd.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
You can still install Debian without the systemd atrocity. Works pretty well.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Seriously, all that fucking noise...
Intelligent criticism often sounds like noise to those too stupid to understand it.
The main purpose of systemd -- beyond being an init system [...]
This is the problem right here. This.
init.d may have sucked, and systemd may have been a better system, but expanding it beyond that was just fucking stupid.
Or, if you want to "improve" other components of an OS, make them loosely coupled to your init system. Fucking journald which (a) does not have an ACID file format, and (b) can't send logging to a remote system so I still have to run rsyslogd on my servers anyway is a case in point.
Works like Debian without the systemd.
https://devuan.org/
Debian still support other init systems, but have decided to not make it mandatory for every single package to work with other init systems.
So that is the same with Gentoo, in which some packages also DO require systemd, which are uninstallable if you don't have that.
Though yes I assume with Gentoo you have more packages available, as you can often easily compile out the systemd requirement at will.
As Debian is not a build-from-source distro, they would have to build several variants of packages to support multiple init systems.
That's why it's harder for Debian than for Gentoo, and why the majority of volunteers that develop Debian, have decided they do not want to make that a requirement.
If a volunteer wants to support multiple init systems in their packages, they are still free to do so.
Most packages can still work without systemd, but probably in a less-well-tested way, and a distro has to make all supported packages work well. That's a whole lot of work. And the very reason that so many distros have adopted systemd is that it reduces their workload so they can get more done with fewer volunteers. They're not going to see much point to using a workload-reducing project to increase their workload.
The reason so many packages depend upon systemd is that the major distributions (redhate and debian) adopted it. If Debian hadn't done so, then it would never have become so prevalent. It's a bed of their own making.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Actually I highly doubt there's any drama what so ever.
Really?
"First they came for the slanderers and i said nothing."
You may be able to to run ping and traceroute without being root by typing "/usr/sbin/ping" or "/use/sbin/traceroute".
Use "which traceroute" to find out if it's in sbin, which won't be in the PATH for a normal user.
Ping and traceroute used to use raw sockets by default, which isn't allowed for normal users. Now it uses UDP by default so non-root users can use it (with the full path if needed).
Current traceroute has the"-I" option to use old-style icmp. It's often installed setuid, meaning normal users can run it even with -I and it behaves as though they were root. You can check with:
ll /usr/sbin/ping /usr/sbin/ping
Which may return:
-r-s--x--x 1 root bin 40960 Aug 24 1998
The "s" means it is set uid.
So you can:
Use the full path and it will probably work (using UDP).
Use -I to traceroute any host you can ping, if it's setuid or you are root.
Showpath does away with these choices and just does udp only, which often works fine.
The 5 also self-identify as 9 different minority groups.
There's been two semi legitimate complaints that I've heard about systemd.
The first is that the systemd process needs more memory then the older init system. I don't think that it's that much of an issue mostly because embedded systems that constrained can still use the older init system which is better suited for those environments. Plus systems that heavily constrained in hardware typically aren't going need the overhead and complexity that's introduced by server/desktop systems, the very complexity that systemd addresses.
The second is that there were comments about systemd crashing. I don't know how true they were (I've never personally need it, and I handle a couple thousand RHEL boxes). These are more legitimate as the systemd init process does need to be as bug free as humanly possible, though from what I've seen it has been working well.
That said, I'm quite liking systemd overall. I know, I'm a heretic. :)
Although that's true it's effectively impossible to avoid installing libsystemd0 (if you care about that). In current Debian stable it's also very hard on a desktop system to avoid installing the systemd package even if you use sysvinit as your init system (it gets brought in via policykit-1 which depends on libpam-systemd and which is depended on indirectly by the big desktop metapackages). In testing and unstable you can manage to only have elogind instead of systemd.
It wouldn't be that hard to provide alternative versions of the small number of "important" packages which depend on either libpam-systemd or systemd itself (I'm talking about things like gdm3, gnome-settings-daemon, lightdm, network-manager and policykit here). There aren't many of them (there are also a few packages which are uninteresting and have a hard depend which I'd be less fussed about.)
Slightly further up the difficulty scale is libsystemd0; it might perhaps be possible to replace that with a safe do-nothing shim if you really cared about it (eg because you want to reduce the potential security attack surface).
Ultimately, I think Debian should have worked harder to support multiple init systems. A requirement for packages above a certain importance level to support sysvinit in addition to systemd and to provide installable alternatives which don't create dependencies on systemd packages (other than perhaps libsystemd0) would have assuaged most people's concerns for very little effort.
How about a job share? Ajit Pai and Boris Johnson.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
At the moment I don't mind some cruft being in there as long as it does not get in the way. I would like to get rid of udev, it creates more problems than it solves. But I can live with it.
For desktop I use fvwm, still the best WM in for me.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.