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.
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.
Yeah I really need my init system to worry about DNS caching. Also why is traceroute considered legacy now? It did one thing well for decades but had to be scrapped for showpath? What was the point? Was the effort worth it? Was anything gained? Thank god Slackware is still sane and usable.
Only the State obtains its revenue by coercion. - Murray Rothbard
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
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.
systemd? Never heard of it! Does it replace Emacs?
No, it is the one object that is able to absorb Emacs
Works like Debian without the systemd.
https://devuan.org/
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.'"