SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
SoylentNews
https://lists.debian.org/debian-devel/2014/11/msg00174.html
Joey Hess has apparently left Debian after 18 years, stating that the Debian Constitution is leading Debian in "very unhealthy directions".
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Anyone can make an omelet with eggs. The trick is to make one with none.
(Score: 2) by Marand on Saturday November 08 2014, @12:44PM
Does anyone here have any insight on why this happened? A quick search turned up some general disgruntledness that seems to be related to how Debian policy has been used during the "init wars" going on -- both with the technical committee's close vote on defaulting to systemd and the current vote to force non-systemd compatibility -- but it it wasn't clear what parts pissed him off.
Is he pissed about the vote to require non-systemd compatibility? Or is he just sick of how the entire thing has gone? Or is it something else entirely?
(Score: 2) by NoMaster on Saturday November 08 2014, @01:20PM
Have a read of the links in this message [debian.org] from the posted thread.
Short answer: systemd, but not like you may think.
Live free or fuck off and take your naïve Libertarian fantasies with you...
(Score: 0) by Anonymous Coward on Saturday November 08 2014, @02:01PM
I skimmed bits of the messages linked by above. He seems to be saying systemd is the fact on the ground, and so debian must go with it - it makes debian packagers' task manageable. A short-sighted view, in my opinion.
Then he found the tone of systemd opponents' messages offensive, and faults the debian constitution for it. He found the kitchen too hot, and so he's getting out.
I don't know how much weight he pulls in debian project, though.
(Score: 1) by quixote on Saturday November 08 2014, @03:22PM
I skimmed them too, and saw something about Gnome requiring systemd. And since that's such a major desktop manager (Is it? Still?) Debian has no choice but to go with the flow.
It'd be a huge shame if something like Gnome, who apparently lost their minds years ago when they came out with 3, managed to splinter Debian on their way down.
(Score: 0) by Anonymous Coward on Saturday November 08 2014, @04:28PM
Gnome will be directly integrating with systemD in the next few releases. It plans on using it's handling of cgroups to provide sandboxing for all running applications.
(Score: 0) by Anonymous Coward on Saturday November 08 2014, @10:38PM
The way things are going, the Linux kernel will be directly integrated with systemd a few releases after that.
(Score: 4, Interesting) by fritsd on Saturday November 08 2014, @03:34PM
I've been trying to read the debian-vote mailing list on the systemd issue, and the following is only my own interpretation: please, read the discussion for yourself.
Joey Hess commented at one point that he didn't like that the discussion became mired in "legalese" (my interpretation remember!!), that the discussion was about formalities of the
voting process and who can change an amendment on which day etc. etc.
And the timing was bad, just before the Jessie freeze. (Ian Jackson agreed and apologized he hadn't called for a vote half a year ago).
I'll try to find the relevant mail..
here's the one about the timing
https://lists.debian.org/debian-vote/2014/10/msg00023.html [debian.org]
and
https://lists.debian.org/debian-vote/2014/10/msg00128.html [debian.org]
I found it!!
https://lists.debian.org/debian-vote/2014/10/msg00260.html [debian.org]
"So if the project makes a "position statement about issues of the day",
it's not actually making a technical decision, but just a (nonbinding)
statement. A statement that the TC has decided will override their
(binding) decision.
Well, at least I've found yet another reason to perfer to not vote on
this GR: It's too darn complicated to understand the procedural hacking
that's going on."
It's sad that this systemd has become so polarizing, but I have an intuition (yes, I am indeed talking out of my ass here--well spotted!) that it's a very important issue for the continued "universality" of Linux.
Remember that it was the Debian project that decided, against "common sense", that the root shell should be changed so some obscure minimal shell (dash), so that init scripts were forced to not depend on "bashisms" and to keep
Debian strictly compatible with any POSIX correct shell scripts.
This year we learned that that decision means that Debian is much easier to secure against the Shellshock attack. But it takes smart people to figure out that something will become a problem before it is an *immanent* problem.
In my opinion, systemd is a problem for Linux, but not an *immanent* problem. But I spent 3 days rebuilding separate packages and downgrading my installation just to get rid of it. It's really much more "infectious" than it seems.
My problem is that I don't actually understand many of the related issues.
Has anyone wondered why we actually *need* D-Bus? It is a complicated program. What is its purpose, what are the trade-offs? Any program on the computer can try to connect to D-Bus and if it manages to produce the correct byte sequence, it is believed to be authorized to do certain admin tasks like shutdown or suspend.
This is what I did to deinstall systemd on a partial-Wheezy partial-Jessie partial-Sid system:
rebuild libpulse0 without the libsystemd-journal dependency (surprise surprise)
rebuild dbus without the libsystemd-journal dependency
major surgery to get rid of libsystemd-daemon0 and libpam-systemd:
get rid of policykit colord accountsservice gvfs-daemons gnome samba kde libpam-systemd and cups
(I use LXDE after I gave up on KDE so I can do without gnome and KDE)
later on, downgrade-reinstall samba and cups so that you can print again.
It's all going much too far...
(Score: 2) by tonyPick on Saturday November 08 2014, @03:58PM
Has anyone wondered why we actually *need* D-Bus?
Uh, wait, D-Bus?
I'm not the biggest fan of D-Bus[1] but we certainly need something like D-Bus, and D-Bus wins the "Better than Corba and DCOP" award that puts it into most systems. Certainly we need a common, well known, IPC mechanism and D-Bus won. D-Bus is a dependency of systemd, but the two are (or should be) fairly distinct.
Now kdbus I'm less convinced by, since using D-Bus to co-ordinate acquisition of system specific resources seems to solve the problem kdbus aims at with much less risk/issue, and since kdbus is only ever going to be a Linux specific that leaves the current solution the only reliable multi platform approach. I could be persuaded otherwise, however this should be somewhat separate from the whole systemd argument, even if practically it's not, since systemd wants/needs this stuff in place.
[1] I've spent a fair bit of time coding apps that use it, and I'm of the opinion that when the guy who wrote it sobers up, he'll be very embarrassed. However most of the Qt/Gtk abstractions seem to hide as much of the madness as they can, and there are moments when I almost like it. At least for some of the simple use cases.
(Score: 1) by fritsd on Saturday November 08 2014, @04:32PM
"D-Bus is a dependency of systemd, but the two are (or should be) fairly distinct."
It is my understanding that Lennart Poettering said that the systemd project intends to absorb dbus (can't find where I read that now). That might make it more difficult in the near future to recompile D-Bus without systemd depencencies.
When I tried to get rid of systemd, I read the D-Bus documentation (wire protocol etc.) on the freedesktop.org site. I wasn't impressed; it doesn't seem very "settled down" yet, if you know what I mean. Of course "Use the Source, Luke!" but for something that all Linux systems are going to require from now on it seemed a bit experimental. And why are there two different ones, anyway (--system and --session)? Doesn't that imply that it's one solution for two unrelated problems?
(I'm not impressed with the programmer-friendliness of System V IPC either, for the record, so if you say so, I'm sure D-bus is a lot better).
(Score: 2) by CRCulver on Saturday November 08 2014, @05:45PM
DBus has been mainstream on Linux installations now for a decade. On my Nokia N900, a device developed half a decade ago whose software is antiquated now, not at all bleeding-edge, DBus provided a number of useful benefits such as running commands automatically on network up (allowing me to e.g. run scripts to automatically log in to public or academic wifi instead of having to always type manually). Even Emacs has had D-Bus integration since 2007 and there are plenty of useful applications for it (such as automatically toggling Gnus's online status or notifying the user of an Emacs development when the Emacs window is not presently visible).
(Score: 1) by fritsd on Sunday November 09 2014, @11:03PM
You know, I find it very valuable to read comments such as yours that show the positive side of all of that newfangled shit ;-)
I can imagine that your mobile phone is a lot cheaper if it switches to university Wifi when it gets into range of the hotspot!
Could you explain to us in small words how that actually works? I'm imagining something like this:
- the kernel gets some kind of trigger from the Wifi hardware
- the kernel creates a network interface and gives it a name
- the kernel notifies (some kind of user-space daemon like udev?) that a new network interface has become available?
or does the kernel just create the device inode and udevd watches /dev for changes?
^-- kernel side
============
v-- userspace
- something creates the device inode in /dev and udevd gives it the correct permissions and user/group
(??? profit [ please fill in ])
- "running commands automatically on network up"
How does that work with DBus? Is it the case that udev pushes a DBus message "new network device is available", and you have a service listening on DBus "when a new network device becomes available, start DHCP or pump or ifup or pppd whatever"?
I'd imagine that the bringing up of the network interface is done by a root process, and the notification "your wifi is now on and pointing to XYZ" is done by your user's window manager process.
Your example of Gnus is a use case of IPC between some kind of notification agent and the window manager and mail user agent or news user agent, I believe. In the old days I remember that a crappy drawing of a mailbox inverted its background whenever I had new mail. That sounds like a similar use-case as your example. I'm quite sure it was more than 2 decades ago :-(. All three programs would have the same user privileges and belong to the same log-in session.
How did the IPC work then in the times of the crudely drawn X Windows American mailbox icon? I forgot :-( Was it something complicated with MIT-SHM?
In the different use-case of "notifications by the system of events meaningful to a logged in user with a GUI" we could make a list:
- tell the user sitting at the console that a DVD has been inserted in the DVD drive
- tell the user sitting at the console that a USB mass storage device has been inserted
- tell the user sitting at the console that network activity is now faster and cheaper
- tell the user sitting at the console that the laptop battery is getting empty
I don't see why we'd need an encrypted bus for that because it's notifications from a "privileged" program to an end-user program (the window manager?)
And then there's the different use-case of "system actions the logged in user wants to do which are usually allowed by the system":
- tell the system to eject the Shrek DVD
- tell the system to umount the USB mass storage device (or maybe it's mounted by the user anyway)
- tell the system to suspend
- tell the system to reboot
- tell the system to shutdown
If the user tries those actions, then the system call gets done or rejected depending on the privileges of the (effective) UID and GID and SELinux security context of the user, amirite?
If the user tells D-Bus to do those actions, then those actions get done if the correct byte sequence is issued by anyone to the dbus daemon. There's a small difference, I think. The listeners on the system D-Bus must already have the privilege to do all those actions, but how can they really tell if they were issued by a privileged user? (In this context I mean "privileged" as in: logged in on the console and not an X terminal, with physical access to the computer).
Some days I wish I was a lot smarter...
(Score: 2) by FatPhil on Sunday November 09 2014, @12:29AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by VLM on Sunday November 09 2014, @12:20PM
we certainly need something like D-Bus
Who's this "we"?
I checked
http://www.freedesktop.org/wiki/Software/DbusProjects/ [freedesktop.org]
and there's nothing on that list I want my DB servers or web servers running.
Also my desktops don't use any of that stuff.
(Score: 2) by tonyPick on Sunday November 09 2014, @01:44PM
Also my desktops don't use any of that stuff.
What, not even udevd? Or the replacements like eudev, or uselessd, which AIUI also rely on a dbus implementation? You're creating static device nodes?
(Score: 2) by VLM on Sunday November 09 2014, @02:10PM
You're creating static device nodes?
Hmm dynamic devices are kinda nice although basically useless in the modern era.
It certainly wasn't a "real" problem even in the olden days when we did have static devices and we actually plugged in old fashioned USB flash drives and stuff like that.
(Score: 2) by hubie on Saturday November 08 2014, @05:13PM
I don't really follow these things, so forgive my ignorance if this is well known, but why is it against common sense to keep out bash-isms and keep it POSIX-compliant? That sounds like a pretty good idea to me.
(Score: 1) by fritsd on Saturday November 08 2014, @07:38PM
The counter argument would be "but that involves extra work, and it works fine now, with all the bashisms, so why change it for some abstract notion of compliancy"
(Score: 2) by Marand on Sunday November 09 2014, @12:13AM
Remember that it was the Debian project that decided, against "common sense", that the root shell should be changed so some obscure minimal shell (dash), so that init scripts were forced to not depend on "bashisms" and to keep
Debian strictly compatible with any POSIX correct shell scripts.
Debian's TC decisions are usually a clear consensus, though. Major changes like that get approached cautiously, like Ents of the Linux world. This has been different, as I mentioned in this reply [soylentnews.org].
In my opinion, systemd is a problem for Linux, but not an *immanent* problem. But I spent 3 days rebuilding separate packages and downgrading my installation just to get rid of it. It's really much more "infectious" than it seems.
The problem I have is that it wants to take over init and logging and tie everything together. Some pieces of it don't bother me, or are at least tolerable, as long as they keep their tendrils out of init. I've been giving some of those parts a reluctant trial because of some software having dependencies on systemd's login service, though I'm still using systemd-shim to keep my init and logging non-systemd. Having systemd-logind has basically had no impact on my everyday use, other than some annoyingly verbose console vomit any time I drop to console and log in.
Like dbus, systemd does seem to provide some useful features for certain software, and it doesn't need to be your init to do so.
This is what I did to deinstall systemd on a partial-Wheezy partial-Jessie partial-Sid system:
rebuild libpulse0 without the libsystemd-journal dependency (surprise surprise)
rebuild dbus without the libsystemd-journal dependency
major surgery to get rid of libsystemd-daemon0 and libpam-systemd:
get rid of policykit colord accountsservice gvfs-daemons gnome samba kde libpam-systemd and cups
(I use LXDE after I gave up on KDE so I can do without gnome and KDE)
later on, downgrade-reinstall samba and cups so that you can print again.
It's worth noting that, unless it's just the principle of it for you, you can generally leave the libsystemd* type dependencies. They don't actually force systemd itself to install. They're just used to allow other parts of the system to interact with systemd if it's present, and otherwise don't matter beyond using a bit of space.
You can also still use KDE without any part of systemd installed, though I believe you lose some USB automount related stuff and maybe some power management related bits. Not KDE's fault, though; upower and udisks started relying on systemd, and there isn't anything KDE can do about it.
It's all going much too far...
Definitely. Though the same thing happened with dbus, udev, and some other parts of what is now a standard Linux system. When I started using Linux, neither thing existed, but they've both provided sufficient benefits to be considered tolerable. Some of the things systemd does could fall in the same category, and if they were approached in any other way (rather than requiring basically full system control), it would probably be far less contentious.
(Score: 2) by choose another one on Saturday November 08 2014, @04:45PM
I would suggest looking at this message (don't think it's been linked to before):
https://lists.debian.org/debian-user/2014/10/msg01058.html [debian.org]
and this one:
https://lists.debian.org/debian-user/2014/09/msg01897.html [debian.org]
My summary would be that as a developer he felt the devs & technical committee had put a lot of time and effort into fully evaluating and coming to a technical decision, only to have a general resolution / policy proposed that would override the technical decision (on the basis of the opinion of people who hadn't participated in the original technical discussion) a matter of weeks before a release / freeze, then to see the whole thing descend into arguments over legalese, and then escalate to threats.
Some devs and techies are very intolerant of legalese - I can understand that, if I have to spend more time reading the contract than doing the work, I conclude you probably don't want me to do the work, and if you threaten me then it's definite. If I wanted to spend all my time on legal aspects of corporate constitution I would have been a lawyer.
Users of distributions need to think carefully - if your distribution takes a technical direction you don't like, then there are others, you can find a new distro. Or you could decide to call your developers names, and collectively try and override their technical decisions. You could show less respect than I've seen from any commercial software boss who is actually writing paychecks for the devs. Then you don't have to find a new distro, instead you have to find a new set of devs, to work for you, for free. Good luck.
(Score: 3, Insightful) by Marand on Saturday November 08 2014, @11:50PM
My summary would be that as a developer he felt the devs & technical committee had put a lot of time and effort into fully evaluating and coming to a technical decision, only to have a general resolution / policy proposed that would override the technical decision (on the basis of the opinion of people who hadn't participated in the original technical discussion) a matter of weeks before a release / freeze, then to see the whole thing descend into arguments over legalese, and then escalate to threats.
Some devs and techies are very intolerant of legalese - I can understand that, if I have to spend more time reading the contract than doing the work, I conclude you probably don't want me to do the work, and if you threaten me then it's definite. If I wanted to spend all my time on legal aspects of corporate constitution I would have been a lawyer.
After reading the links in your comment and the ones in fritsd's post, the impression I get is that, at a basic level, this is essentially "the developers have spoken, and you are not developers, so you should do as we say. How dare you question our judgment?!" Same sort of thing that has been happening in GNOME since forever, except that Debian (perhaps unintentionally) provided a way to fight the decision and now people are pissed about that and claiming it isn't what it was intended to be used for.
Thing is, everything I remember of that TC decision looked like some kind of surreal joke. The TC itself was abruptly proposed to bypass a more tempered (and more Debian-like) approach to choosing which init and when to support that was already in the process of being set up, for one. Then, because of how the vote itself was set up, the split vote ended up resulting in a massive change instead of a decision to wait. One would think that the init should be important enough to not be changed over a split decision broken by a single vote. The fact that the TC itself couldn't reach anything even close to consensus should have been a clear indication that the decision needed to be postponed until the next release, because none of the proposed replacements were a clear enough improvement.
Users of distributions need to think carefully - if your distribution takes a technical direction you don't like, then there are others, you can find a new distro. Or you could decide to call your developers names, and collectively try and override their technical decisions. You could show less respect than I've seen from any commercial software boss who is actually writing paychecks for the devs. Then you don't have to find a new distro, instead you have to find a new set of devs, to work for you, for free. Good luck.
I wonder if the entire tone and reaction would have been milder if the abruptly called vote hadn't happened, and the original approach had instead been taken. There still would have been vitriol on all sides, but the GR itself probably never would have happened, since there wouldn't be a TC vote to need overriding.
Personally, I appreciate the work they do and normally respect their decisions even when I don't agree with their changes, but the way this one has been handled on both sides just stinks. It was a pissing match between the systemd and upstart proponents, and anybody that suggested anything else basically got told to butt out. I don't love systemd, but my problem wasn't that it won, it was how it won. I would have felt the same about Upstart or even OpenRC (which I have no issues with) winning.
As for losing devs over it, it sucks, but maybe this is the kind of shake-up Debian needs. This whole thing has brought to light various types of agenda-based policy abuse that never really happened before. Perhaps policy will change/improve and Debian will end up stronger for it.
(Score: 2) by Marand on Sunday November 09 2014, @12:27AM
Addition to comment based on something I found:
This post [debian.org] by him seems to indicate he was bothered by the TC voting farce, too. So, I'm not sure if the combination finally pushed him over, or if he's backing the decision even though he disagrees with it because he feels it shouldn't be contradicted, and thus angered by the GR fighting it.
(Score: 2) by choose another one on Sunday November 09 2014, @09:20PM
With respect, I think you are reading it wrong. His previous posts indicate that he backed and respected the previous TC decision process and felt it was inappropriate for someone to try and overrule all the effort that went into that by appealing to a different forum, and doing it 2 weeks before release freeze. He also believed it was an abuse of process:
https://lists.debian.org/debian-vote/2014/10/msg00246.html [debian.org]
I don't know what his position is on systemd itself, and I'm not sure it matters. I have had stand up rows with PHBs for trying to micromanage and override technical decisions at incredibly stupid points in the development cycle, after they had not wanted to be involved in all the technical discussions leading to the decision. It wouldn't have mattered which side of the decision I was on, if I even took a side - I would back my technical team's right to make their technical decisions at the right point in the development cycle and have them respected. In exactly the same way, I would _not_ (and would _not_ back a developer who wanted to) go to the PHB a day before quarter accounts deadline to suggest that the revenue recognition model is wrong (whether I thought it was or not).
The comment you have linked is not at all about the TC default-systemd vote, it is about more recent discussions on how the init system should be selected on upgrade. His point seems to be that this was all already resolved by consensus with all the relevant init package maintainers, but then someone stepped in and made it political, together with statements that he (see https://lists.debian.org/debian-ctte/2014/11/msg00047.html) [debian.org] interpreted as overriding the current work on upgrade path. I don't think it is a coincidence that the same person was also behind the GR, and consider it entirely possible that breakdown in relations between those two people has lead to this resignation. Interestingly it appears to be not the only recent TC resignation...
(Score: 2) by Marand on Sunday November 09 2014, @11:56PM
You're right, I missed that it was a follow-up TC vote instead of discussion about the original one. That puts things back where my longer post left them: the whole thing still stinks.
I can understand him (and others) being pissed that people want to undermine the TC decision, but I also still think that the way the vote was handled in the first place fueled that fire. This was an odd thing for Debian: a distro that cautiously approaches sweeping changes has jumped head first into this one, despite problems, lack of maturity in the solutions, and a lack of consensus in the TC.
It's also looking like either Debian's policies or its people aren't holding up well when faced with contentious decisions. Hopefully the end result is that things end up better, with a stronger Debian. If not, though, there will still be other options. Not that I wish ill on the project or its members. Not at all, in fact. I've generally had good interactions with Debian and KDE folk (which is one of many reasons I still use Debian+KDE), so it's kind of a shame that this crap is happening. Still, maybe a shake-up will be good in the long-term, either for Debian or for something new that may come from it.