SoylentNews is people
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.
In Tulsa, Oklahoma, it is against the law to open a soda bottle without
the supervision of a licensed engineer.
(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.