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.
QOTD:
"My life is a soap opera, but who gets the movie rights?"
(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.