Slashdot Mirror
Kernel DBus Now Boots With Systemd On Fedora
An anonymous reader writes "Red Hat developers doing some holiday hacking have managed to get a bootable system with systemd + KDBUS on Fedora 20. KDBUS is a new DBus implementation for the Linux kernel that provides greater security and better performance than the DBus daemon in user-space. Systemd in turn interfaces with KDBUS for user-space interaction. Testing was done on Fedora 20 but the systemd + KDBUS configuration should work on any modern distribution when using the newest code."
What kind of OS is that?
An OS ready for the radiant fascist/socialist future where the user has no control over the computer driven devices he supposedly owns.
My first experience with systemd was on OpenSUSE. Although it seems like a good idea, it seems to add some unneeded complexity. /etc/init.d/someservice restart now redirect to systemctl, with no real output. Oh I have to run status to see if it succeeded. Now I have to use journalctl to see why it failed.
I'm all for dependency based init systems, but I feel Gentoo got that right with OpenRC. It gets rid of all that rc1,2,3,4,5 crap while keeping the /etc/init.d/ structure we're familiar with.
Gentoo can not be setup to use systemd too. I guess it's now the future; better get use to it.
Andrew S. Tanenbaum had a point about Linux not being micro kernel.
This is getting crazy: moving perfectly fine userland systems to the kernel.
Isn't the kernel large enough already?
Bram Stolk http://stolk.org/tlctc/
I like Gentoo's OpenRC. Much better than SystemD.
I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.
It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.
Surely, all you really need is something like fvwm2 or something right? I mean, two bars, some extra stuff, and you're good right? The only thing is that you don't have compiz effects. But otherwise, you'll probably have a pretty useful desktop with full control.
Comparing a KDBUS to a JPEG or a PNG decoders ?
Try instead to compare the Linux KDBUS code to the Linux TCP/IP stack...
Seriously, the Linux kernel is only bloated by the fact that it need thousands of drivers to handle decades of hardware diarrhea that released incompatibles devices as fast rate. Certainly not by the KDBUS code.
http://lwn.net/Articles/551969/
Linus is okay with it. Have to worry about Al Viro. :-)
Here is an updated talk by Greg K-H that he gave on KDbus, he posted this about 3 days ago. https://github.com/gregkh/presentation-kdbus
Let's stop all the FUD, and educate yourself on the reasons behind on this.
"go head over to the BSD world."
I already have. As a Linux user from very near it's beginning(93-94) and dumping Windows completely over it's shenanigans in the early 2000s. I'm now seeing Linux become Windows. Unfortunately BSD is affected by the influence of the shadow(guess the reference) as well(applications and support systems). Guess Plan9 if it's developers would stop treating it as their personal toy and expand it's application support to something a wider audience could actually use...
I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.
What's wrong with /proc and /sys for kernel and hardware configuration tasks? It's easy and twekable, you can poke around in it without writing a program first, and it conforms to "everything is a file".
It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.
IPC is between processes, not between a process and the kernel.
because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.
It would if it were used as it is intended. That is to say, sleep and hibernate states ought to themselves be runlevels. I have never been able to puzzle out why this is not so already.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Modern systems often aren't a single purpose hardware server any more. Mobile devices that have to switch on services like GPS, several networking modems, voice over IP, hotplug hardware and start/stop associated services and such will make you have to run numerous daemons that control just restarting the one small group of services and hardware for every corner case you can imagine if you keep using RC scripts.
Even servers often have nested dependencies these days. You'd want the system to restart a failing middleware application in the correct sequence after you've fixed the filesystem on the storage that ran out of space that caused it to remount r/o on all your web server platform VMs. Try doing a bunch of init.d scripts for that. Either you custom write a script to do it remotely just for your app, or you have the systemd-like control that will just figure out what to do all by itself.
Yes, it adds complexity to very simple single use systems, but it makes dealing with all the glue you have to do to get dependencies on other services and corner cases so much easier. I used to think it was a solution looking for a problem too, until I found out that I could now stop worrying about getting my systems up again after I just solved the single cause of all the problems that got them down in the middle of the night.
I was promised a flying car. Where is my flying car?
I'm just gonna leave this here.
https://plus.google.com/111049168280159033135/posts/4KJxFY8VvT1
Ubuntu: If at first you don't succeed, blindly slap a sudo in front of it