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
Remember when John killed a man and had sex with underage hookers? Oh wait, the two weren't connected by anything but name. kys
Seriously, not kidding.
It seems pretty well integrated to me, after they got rid of that barely usable sysvinit garbage.
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."
seriously people, couldn't one of you have stepped up, run unopposed and chucked that shit into the toilet?
I'm surprised anyone shows up. Theres a project secretary?????? What a laughingstock
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.
Easier just to write ./configure --without-debian
Most parts of systemd work well. The DNS resolver does not though.
Remember this situation next time you want to complain about a CEO's salary. While many salaries may be excessive, you will not get a CEO to work for the same salary (or anything close) as regular employees, for similar kinds of reasons.
I for one just hope they had the good sense not to vote for somebody orange.
Almost everyone on the project needs to be called a dumbass A LOT more often. That is all.
And then install a counterfeit OS
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
systemd has one issue: the users not reading the docs.
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)!
I don't understand why this is such a bad issue. Anyway, what does the Debian family do with all the money they earn from selling the Linux CDs?
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.
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.
They sentenced me to twenty years of boredom
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.
That's not true, because the most pervasive argument against systemd is hatred about Lennart Poettering's development style, and some vague handwaving about the "UNIX philosophy" to which the Linux kernel has never adhered at any stage.
Those who do not learn from commit history are doomed to regress it.
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
Yeah, Ian Murdock was depressed about the million bucks he had in the bank and killed himself. I don't know why his Tweets were deleted though. It's a mystery like why Building 7 collapsed.
Personally I think that Kashewgoo journalist guy from Saudi Arabia commited suicide too, by self dismemberment. Happens all the time, so sad. LOL
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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 options then become: ./configure
or ./configure --with-systemd
Also install consolekit
Also install a shim if the original project doesn't provide you the non-systemd functionality
Also you lose a bit of incompatible functionality
Also you need to maintain the old packages that have been depreciated in favour of systemd
One of the Red Hat maintainers said it well on their mailing list, you don't maintain 2 packages. You maintain 2 packages and create a management system for selecting between them which is under continuous development due to the changing demands of either original package. At some point you just make a decision and let another distribution fill the gap if needed. /paraphrased.
Maybe someday you will have all the mod points your heart desires
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/
Just switch to devuan.
devuan
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."
And by diverse, I mean 5 white dudes with various hair lengths and presence of facial hair. How's that Outreachy program that the SPI contributes Debian funds to going?
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.
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."
(same AC)
Yes, that would be possible.
But the main thing is that they are volunteers, and they have voted to not force (other) volunteers to do that.
Most of them prefer systemd, so at least it's logical to make that the default.
Then as for other init systems, if upstream supports those just fine, Debian maintainers generally carry over that support.
But if upstream does not, it would take them too much work to develop that themselves, or stall progress in the default configuration because of having to fix bugs involving minority init systems.
Who decided all that would be too much work? The same people who would then have to do that work. That seems fair.
Again, if someone wants to do the work, they are free to do so. It's just not forced upon everyone.
Of course it's a shame that makes Debian less universal as it used to be.
But as the project is inherently dependent on what upstream does, and what volunteers want to do, at least for me it's an obvious decision that we just have to accept.
The users who really really want a non-systemd system, can still try to use Debian, or if that's insufficient (at least I heard complaints about bug reports being rejected?), find a project run by people that _do_ want to do the work to fully support that, such as Devuan. Or if that's also insufficient, do the work for that themselves or pay someone to do it for them.
Personally I hope that Devuan will be successful and merge back into Debian the parts that are missing.
But the Devuan progress is dog slow, which does suggest that Debian's "too much work" decision wasn't without merit.
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.
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.
Yeah, that and an fundamentally inappropriate design. Oh, and multiple serious bugs often lasting very long due to refusal to fix them.
Debian supports sysvinit _scripts_, it does _not_ support not using SystemD. A huge number of packages indirectly depend on it. If it were merely optional, people would not have had to fork Devuan, you'd just see suggestions to run apt get remove systemd.
"Debian still support other init systems, but have decided to not make it mandatory for every single package to work with other init systems."
That means Debian doesn't support other init systems. Supporting an init system on Debian means that essentially all package can work with only that init system being installed. (Of course with the exceptions of the init system packages...)