Forgot your password?
typodupeerror
Operating Systems Red Hat Software Linux

Kernel DBus Now Boots With Systemd On Fedora 341

Posted by timothy
from the trying-new-things dept.
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."
This discussion has been archived. No new comments can be posted.

Kernel DBus Now Boots With Systemd On Fedora

Comments Filter:
  • Re: Why, oh why? (Score:2, Interesting)

    by epyT-R (613989) on Sunday December 29, 2013 @04:52PM (#45813425)

    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.

  • Re: "Slashmirrored" (Score:5, Interesting)

    by SumDog (466607) on Sunday December 29, 2013 @04:54PM (#45813431) Homepage Journal

    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.

  • Listen to A.S.T. (Score:3, Interesting)

    by Bram Stolk (24781) on Sunday December 29, 2013 @04:54PM (#45813437) Homepage

    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?

  • Re:More Bloat ? (Score:4, Interesting)

    by SumDog (466607) on Sunday December 29, 2013 @04:58PM (#45813461) Homepage Journal

    I like Gentoo's OpenRC. Much better than SystemD.

  • Re:Why, oh why? (Score:4, Interesting)

    by jcdr (178250) on Sunday December 29, 2013 @05:28PM (#45813617)

    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.

  • Re: Why, oh why? (Score:4, Interesting)

    by Sri Ramkrishna (1856) <.moc.liamg. .ta. .anhsirkmar.marirs.> on Sunday December 29, 2013 @06:03PM (#45813827)
    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.
  • Re:Why, oh why? (Score:3, Interesting)

    by jcdr (178250) on Sunday December 29, 2013 @06:04PM (#45813845)

    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.
     

  • by Sri Ramkrishna (1856) <.moc.liamg. .ta. .anhsirkmar.marirs.> on Sunday December 29, 2013 @07:07PM (#45814229)
    Too much navel gazing about change. Here is the reason behind kdbus. Primarily it's for application sandboxing and making sure that a bad actor does not do something bad to something else. As GNU/Linux gets more popular, we want to be able to make sure that we can contain bad actors as much as possible. It's also a step in the direction to have a universal app spec instead of having to have each distro package the same damn app. I miean, how much duplicate work do you want to do? It makes it easier for people who write apps to have GNU/Linux as a target instead of having to pick the most popular distro at that point of time.

    http://lwn.net/Articles/551969/ [lwn.net]

    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 [github.com]

    Let's stop all the FUD, and educate yourself on the reasons behind on this.

  • Re: "Slashmirrored" (Score:3, Interesting)

    by celle (906675) on Sunday December 29, 2013 @08:36PM (#45814791)

    "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...

  • Re:Why, oh why? (Score:4, Interesting)

    by multi io (640409) <olaf.klischat@googlemail.com> on Sunday December 29, 2013 @09:21PM (#45815029)

    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.

  • Re: "Slashmirrored" (Score:3, Interesting)

    by drinkypoo (153816) <martin.espinoza@gmail.com> on Sunday December 29, 2013 @10:13PM (#45815305) Homepage Journal

    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.

  • by dutchwhizzman (817898) on Monday December 30, 2013 @02:37AM (#45816371)

    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.

  • Re:Why, oh why? (Score:3, Interesting)

    by kernelpanicked (882802) on Monday December 30, 2013 @03:37AM (#45816529)

    I'm just gonna leave this here.

    https://plus.google.com/111049168280159033135/posts/4KJxFY8VvT1 [google.com]

There are worse things in life than death. Have you ever spent an evening with an insurance salesman? -- Woody Allen

Working...