SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 13 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.
Kindness is a language which the deaf can hear and the blind can read.
-- Mark Twain
(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...