Posted
by
timothy
on Sunday December 29, 2013 @04:18PM
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."

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.

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.

Sorry to double reply, but systemd would be a lot more acceptable if it and it's project leaders would be just a bit more conservative (especially in dependencies) and a bit more open to porting to non-Linux systems. As it stands, I hope that failing prompts Debian to pick upstart.

Since rc scripts are currently universal, it makes sense to consider them a gold standard even after moving to an alternative init. In other words, any new init needs to consider support for scripts dropped into init.d and linked

I agreed with you until Windows 8 came along and could cold boot to GUI in less than 3 seconds. I would still agree for servers. Boot up speed doesn't matter if you never shut down, but the market is changing.

Boot speed matters if you spinup and shutdown instances all the time. It also matters on the desktop, both markets are larger than the "pure server" market. So you can either maintain two boot sequences for different purposes or you can put all your attention into the new sequence. The advantage o

Even on fast SSDs I've never seen 8 cold boot it in 3 seconds. 9-12ish maybe. Add in windows networking and it's much slower. Also Windows delays a lot of tasks so you are to the GUI but your actual services are not running yet. In the server market your boot speed is highly dependent on network resource dependencies with varying delays.

Boot up speed is incredible with/service (see http://cr.yp.to/daemontools.html [cr.yp.to]) and dependencies aren't hard to wire into those scripts at all. What kills me is that systemd is so much more complex for no gain over something so simple as an auto-restarting shell script.

The unneeded complexity, moreover, does not befit a Unix. If you want one of those, you need to steer clear of most everything the freedesktop crowd, most notably mister Poettering, come up with. Otherwise, what you get is a sort of linux in windows-like sauce, compatible with nobody like a good little redmond product. If that's what you want, go for it. But software developed for this environment will no longer play well with other Unices. In fact, it is no longer a Unix, certainly not in spirit.

It seems to me that it removes unneeded complexity too. Like no longer having to have initscripts in bash which is a fully featured programming language. Most of them consist of boilerplate and most people don't have complete understanding what exactly it does. Naturally it leads to more bugs. I don't believe systemd adds any new complexity but more like moves it from individual initscripts and special purpose utilities to common base. I think it leads to less work for everyone because you don't have to rei

You realize that a lot of systemd is supported by kernel developers. These things just don't get integrated by accident. The kernel has features, kernel devs want them used. If you want classic Unix, go head over to the BSD world.

I am a user, an admin of a few systems, and an engineer of a numbers of systems.And I am really very happy by the KDBUS and systemd move.

Not only there are technically good, but I hope that others concurrent projects will fork this common code base and start talking together what will be valuable to merge, instead of creating a yet another pointless unconnected project that will never gain enough audience to change anything but increasing the number of choice problems for a lot of distributions.

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.

Amen to that. I was mildly irritated when I first saw systemd take over Fedora (I forget what release it was), so I moved to Arch Linux -- which I figured I could count on to be the Unix-like system I always loved and forever adhere to the K.I.S.S. philosophy...then they ALSO shoved systemd down our throats. Have been using FreeBSD on the desktop [where practical] ever since; it was already what I used on my servers.

Gentoo is currently pushing over to systemd. About a month ago they set stable keywords for gnome-3.8 and systemd, so that pretty much everyone who uses any gnome software, not just the gnome desktop, got pushed to systemd as well.

There is not any official word, but that was what happened. It's still possible to run an OpenRC system, but it takes a fair amount of work. The forums still have systemd migration problems, a month later.

There was an item on the Gentoo Bugzilla for upstart, but that was recent

Can't speak of OpenBSD, but I currently use FreeBSD + KDE4 on my gaming desktop (when I'm not gaming), and it's phenomenal. More stable than Arch Linux ever ran on this machine, but I suppose I can't speak much to performance since pretty much anything should run very well on this beast.

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.

Honestly, I was happy with KDE 3 + compiz. And still am on some days (TDE is great!). I was not happy that I had to move my old work laptops (Dell C400 and D510, I needed the serial ports) back to Windows because they're no longer supported in Linux (and I was required to run 'supported and up to date' software and such by workplace requirements at the time).

If you're telling me it doesn't work (don't have one to verify myself), fine, sounds like it needs a bug report. KMS has nothing to do with anything. Using an older AMD driver doesn't preclude you from using a new and updated distribution. Ubuntu has had "nvidia-legacy" packages for similar reasons for years. Not sure why you don't like the radeon driver, but https://launchpad.net/~makson96/+archive/fglrx [launchpad.net]. It

We don't need in-kernel DBUS. Userland can run such things just fine. Is there a "need for speed" and prompt response? Well, so raise priority of the userland dbus daemon then. Right up to real-time priority if need be. That works for jack, which have real-time constraints that can be hard to meet. It works for robot control software. So surely a userland approach will work for something as benign as dbus.

You can even run a linux system without any dbus at all - it is definitely not needed in the kernel.

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.

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.

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.

Because, you're arguing in the wrong place. Join LKML and ask there. Declarative statements like yours will likely be met with some amount of sarcasm because nobody here answering you are involved in kernel development. Also, it's a personal weakness. The sarcasm that is.

Someone COULD have offered a rationale for DBUS (or at least some benefit they believe it offers) or it's inclusion in the kernel. They might have even convinced me making wrangling with LKML unnecessary. Apparently, nobody on/. has one. It would be rude to just bust in on LKML without at least attempting to gain some background first, eh?

Tell me, was HAL the right thing? They seem to have changed their minds and abandoned it.

I've read the reasons for systemd. Faster boots, cleaner, more flexible, better at handling dependencies. Did I miss anything? Now, the reasons against systemd would seem to be that it adds dependencies, especially dependencies on systemd of other system tools such as dbus, it's more fragile, it certainly isn't as well tested, and it may not be so good at managing dependencies and being flexible as it proponents s

Lennart Poettering, nothing he touches is easy to remove once it has a foothold. And it seems everyone who packages it is drinking the same coolaid. Sometime I wonder if packaging tools should have a 'shit can list' that allows packages to be block per developer.

KDBUS sounds okay to me. Apparently it, in a lot of people's views, boils down to "DBUS done right" -- the protocol is completely different under-the-hood, and will be (or is intended to be, if the userspace side people don't fuck it up like they constantly do to udev) supported in userspace by a translation layer for old-DBUS programs.

Further, the kernel devs have a habit (substantially creditable to Linus Torvalds) of doing a lot of things right, and making sure they don't break anything in the process, s

Canonical is innocent - it's Red Hat's doing. Just like Pulseaudio and a million other innovations (some good, some less then good). But Red Hat has had a hand in most of the desktop development that people see.

KDbus is being done by Greg K-H of Linux Foundation. There are some good reasons for having a kernel bus. The first rev was killed, but the second rev is being worked on. Linus has already signed off on getting this integrated. It's just a matter of working out the details. A lot of this is driven by desktop projects, so things like smooth transition to a login screen, wayland, application sandboxing are good reasons to have it.

Developers have no ideas of the real requirements and demands of systems engineers, administrators, network specialisty or users.

For proprietary code managed by dummies, maybe. But the Linux community developers count a lot of systems engineers, administrators, network specialists, and users that are code in the kernel precisely because there want to make it better at handling there real requirements and demands. You are free to do the same if you think that you can improve Linux for your need.

A sandbox would be a good idea. If I install software to interface to a printer, or read a spreadsheet I should reasonably expect that the software should only be permitted to what it claims to do. A good, working sandbox for drivers and applications would be good for the user and a significant advantage over windows.

Most of those people are hired and paid by Red Hat to code what Red Hat envision.

What happens right now is the biggest and most agressive consolidations process since the existance of Linux.

systemd and jounald as coreOS that consolidates all we had known. Logging, inetd, sysvinit, timed, udevd, ipc etc.

Gnome3 for dumb people as main Desktop dealing a lot with systems.
Kernel that now implemented kdbus to explicitly communicate to systemd.

Wayland to replace X11 to work close to Gnome3.

All a big consolidation!

linux (kdbus) -> systemd -> wayland / gnome3

What remains from what we know ? Nothing!

I am not against consolidation but I am against this sort of agressive behaviour!

In 2-3 years nothing remains that reminds of Linux to be Unix related.
Even worse there are talks to have some sort of iPhone or Android like package mechanism to place apps with all deps (libs etc) in a sandbox within an apps directory. Even systemd already provides dealing with that.

What kind of OS is that?

What's wrong with a sandbox? For application developers it is now easier to target only one platform "Linux" regardless of distribution. Are you telling me you never ran into a problem when you ran across a tool or application and find out that the only packages available are for Ubuntu, and you had to go and compile the thing yourself? Then spend about 2 hours because it didn't quite work right. Come on...

Why is this NOT another example of kernel bloat, and the opposite direcion they should be heading (ie getting user stuff out of the kernel)? Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication. The "huge performance improvement" is only for those processes that shouldn't be abusing this anyway.

At first, this sounds like the kernel developers have raided LP's [wikipedia.org] "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".

There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.

No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.

I find ssh_agent very useful. That's why I stuck it in my.bashrc like a sane person. There's no need for a bunch of unremovable crap when a couple lines in a script can take care of it for people who want it.

Can someone please step up and write a sane rc.d based init system so we can consign Systemd to the trashcan of history.

Seriously? BSD has had such a system forever. Linux used to have a "sane" init scripts system (admittedly for some subjective definition of "sane") until very recently. Debian's system used clean Bourne shell compatible scripts. This meant/bin/sh could be a symlink to/bin/dash. Dash is a very lightweight shell without all the Bash overhead. It is about 1/10 the size of Bash. Bash is an excellent interactive shell, and a very valuable scripting shell, but Dash is excellent to have where you don't need a vast profusion of features but you are interested in performance.

Here [ubuntu.com] we learn that most of the performance benefit seen in Ubuntu 6.10 was due, not to Upstart, but simply by switching from Bash to Dash in the init scripts.

Redhat decided it was "too hard" to make their init scripts Bourne shell clean. They all reference/bin/sh in the shebang line, but they lie. They rely on Bash features. As a result, rather than do what Debian showed could readily be done, Redhat established and has adopted Systemd as the Only Supported Init System.

Now that Debian is caving in to systemd, it seems safe to say we can forget the fantasy of Systemd being relegated to any kind of "trashcan". Quite the contrary, as far as linux is concerned, it is the init script system that will be trashcanned.

There are honest pros and cons for the move. The pros are pretty compelling (and I say that as a holdout from the beginning). Linux is in many ways about monolithic solutions. This is just one of those ways.

For those who have doubts, not just about Systemd but about other monolithic consolidations and discarding many time tested and good working systems, there is still a refuge: BSD. That may change, but for now BSD is not jumping on all this stuff (quoting the AC near the top: Wayland, Gnome3, Pulseaudio, Systemd, Journald, "Alienating [subsuming] Udev"). BSD is still all about the Unix Philosophy [wikipedia.org], as expressed by Mike Gancarz.

It is really an embarrassment of riches that BOTH Linux and BSD are prospering as freely available systems.

The corruption of GNOME and other opensource projects by tying it specifically to Linux comes with this; it represents giving up on being cross-platform, giving up on the BSDs and other Unices, and giving up on openness. No thanks.

You, sir, are a confused person. The protocol is open and free for any other OS to implement, and will remain so.

If the BSDs are left in the dust, it's because they're lacking the manpower to do the things a new GUI needs. This was not a big problem for GNOME 2, which is architecturally more than a decade old. But things have changed.

I can understand if people disagree with the path the GNOME developers have chosen because it does not fit with their ideals - but you have to understand that these developers are not your serfs you can command. There are still plenty of GUI environments with modest requirements of the OS, and while they may not do the same things you can choose from any of them as you wish. So quit the whining.

Then we should turn away from GNOME3. Because they're taking compatibility lightly. Because they're wrongheaded. We should make sure that no distros ship GNOME3 or systemd as default. Sure, they're not serfs, they're just people promoting an inferiour solution that damages Unix.

There's already a D-Bus implementation available on BSD and other Unices. The API is documented [freedesktop.org] and anyone has the freedom to implement it any way they want, userspace, kernelspace or outerspace.

I fail to see how one more implementation, more specfically the Linux kernel one, has anything to do with giving up on anything.

You forgot that Linux was created precisely because there was no truly open UNIX running on a PC a his time. Even 386BSD arrived after Linux started to gain a growing community. The Linux community always tried a lot of different approach, and this is the reason why it is do dominant today.

But I agree that Linux is more and more a norm by itself and that his UNIX part is slowly mutating into a simple compatibility interface layer. I am not even surprised about that since UNIX was created at his time for har

In other words, Linux isn't being engineered anymore, it's being driven by the masses.

You can use your own conclusion, but Linux was always driven by the masses of engineers that work on it. There is no other kernel project with so much authors. And this is precisely what make it so successful.

Now if you think that Linux is not a good engineering work, a lot of peoples will be more than happy to learn from you how to make it even better.

D-Bus is still portable across multiple free Unices and even Windows. The standalone daemon isn't going away anytime soon, and I can't see the multitude of projects depending on it giving up cross-platform compatibility.

In-kernel IPC reduces context switching and other related overheads. I'm not sure exactly how much of a performance gain this gives D-Bus clients and the system as a whole but if someone wants to spend their Christmas playing around and seeing if something is better then great! And that

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?

That word does not mean what you think it means. In fact, kernel dbus is probably the most microkernel-ish feature I've seen added to the Linux kernel (although I haven't been paying close attention).

A microkernel is defined as a kernel composed of a large number of very loosely coupled modules, with an absolute minimum of functionality in the modules that are loaded initially or by the bootloader. Because of this, microkernels tend to have slightly greater overhead (both processing and memory) than compara

I agree that Linux isn't a microkernel, but I don't think adding an IPC framework like KDBUS to Linux makes it bloated compared to a microkernel. I believe that an IPC system is the one thing that all microkernels include. Including an IPC framework in the kernel should help move other functionality from the kernel to standalone user space process that expose services over IPC.

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.

The really really stupid thing is that desktop isn't even the reason why Linux. Obviously no server needs dbus let alone kdbus, and plenty of desktops don't either. Yes, it's amusing that I get a popup when I plug in a USB stick, but is that essential functionality? Sure, some very simple form of event multicast would be good, but is this it?