How Debian Almost Failed to Elect a Project Leader (lwn.net) 86
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.
This (Score:1, Troll)
From the same dipshit group that voted for systemd by default.
Re: (Score:1)
I thought this was a spam or AI generated post. holyshit, you're msmash? One of the biggest submitters to Slashdot? No matter this place is tits up.
Re: (Score:2)
Re: (Score:2, Funny)
systemd? Never heard of it! Does it replace Emacs?
Re:This (Score:5, Funny)
systemd? Never heard of it! Does it replace Emacs?
No, it is the one object that is able to absorb Emacs
Re:This (Score:5, Insightful)
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.
Less flexible, less reliable (Score:5, Interesting)
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.
Re: (Score:2)
Thanks for the info. I was wondering why you needed to be root to run traceroute now. I started using Slackware in 1996 and got away from Linux in the early 00s. My personal server runs OpenBSD so I missed the recent shit show that Linux has turned into. Now I use Ubuntu at my job and its the Windows 10 of Linux.
Use the full path (Score:3)
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
Re: I blame systemd (Score:3)
Seriously, all that fucking noise...
Intelligent criticism often sounds like noise to those too stupid to understand it.
systemd (Score:3)
Re:systemd (Score:5, Interesting)
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?
Re: (Score:3, Insightful)
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
Re: (Score:1)
"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.
Re: (Score:1)
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
Re: (Score:1)
I notice your calm response has gathered a -2 Troll rating.
I don't have points at the moment, but I'd mod you up if I could.
Re: (Score:2, Troll)
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.
Re: (Score:1)
I do that on every Debian installation: I just put in sysVinit. Debian still supports that and you get rid of a ton of problems if you do it.
Re: (Score:2)
Re: (Score:2)
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.
init replace + kitchen sink (journald sucks) (Score:1)
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.
Re:systemd (Score:5, Insightful)
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.
Re: (Score:1)
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.
Re: (Score:1)
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
Re: (Score:2)
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
Re: (Score:1)
False. You're suggestion is good except ignores the economies of making it optional. Packages which do depend on systemd do so because the alternate has been dropped or they are looking to expand functionality. Take Gnome for example, one of the few packages that actually depend on systemd. It depends on systemd for power management, event management, and session management. It does so in ways that consolekit is no longer able to.
So along comes distro project leader making a decision on what to do. The opti
Re: (Score:2)
Actually I highly doubt there's any drama what so ever.
Really?
Re: (Score:1)
Really. Go have a look at the mailing lists. In the top of the project level for Debian there are no dramatic discussions about systemd. At their level they fully support the implementation and have unwavering for the best part of since the decision was made to adopt it.
Use Devuan (Score:5, Informative)
Works like Debian without the systemd.
https://devuan.org/
Re: (Score:3)
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.
I for one ... (Score:2, Flamebait)
It could be a great opportunity (Score:2)
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)!
Why not spend more money on a good CEO? (Score:1)
Re: (Score:2)
You can still install Debian without the systemd atrocity. Works pretty well.
Holding out for something better. (Score:2)
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.
Re: (Score:2)
I think just covering expenses would go a long way towards helping things out, it doesn't really need to a be "paid" position. Ie, reimburse for plane flights, hotel costs, conference fees. It starts to get problematic if the payment is for "time" though especially if no one else is being paid for time. Debian would lose a lot of its distinctiveness if it went with a CEO model or the like.
Re: (Score:3)
The 5 also self-identify as 9 different minority groups.
Job share (Score:3)
How about a job share? Ajit Pai and Boris Johnson.