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

Comments

"Slashmirrored"

[Anonymous Coward]

So do we just mirror phoronix on slashdot, now?

Re: "Slashmirrored"

[SumDog]

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.

Re: "Slashmirrored"

[Desler]

Btw: Why is KDBUS code full with 'goto' calls ?

For the same reason the kernel uses them. Because they aren't mindless ideologues.

Re: "Slashmirrored"

[sjames]

Actually, overall I would prefer sticking with /etc/rc[1-5]. It is simple and functional.

All the new crap strikes me as some combination of fixing what's not broken and a solution desperately seeking a problem.

Re: "Slashmirrored"

[Sri Ramkrishna]

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.

Re: "Slashmirrored"

[modmans2ndcoming]

because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.

Re: "Slashmirrored"

[Desler]

Nope, it's because gotos are very nice for error handling over rats nests of if/else. Which is what its predominate use in the kernel is.

Re: "Slashmirrored"

[sjames]

All that was required was to either wake from sleep OR go through the usual rc[1-5] scripts.

Re: "Slashmirrored"

[sjames]

What makes you think I don't? Of course, that's on my own systems since once the pollution is allowed in, the old stuff doesn't work so well anymore.

Re: "Slashmirrored"

[sjames]

So what you're saying is that there is already a maintainer? Me not being from the universe with a bearded Spock, I figured I probably shouldn't kill anyone to take their place.

Re: "Slashmirrored"

[Mister Liberty]

Hi Theo!

Re: "Slashmirrored"

[armanox]

Don't tempt us. The users, admins, and engineers that have to keep these systems running are not happy.

Re: "Slashmirrored"

[JSG]

>> Gentoo can not be setup to use systemd too

Are you sure? My laptop begs to differ:
$uname -a
Linux jglaptop 3.12.6-gentoo #1 SMP PREEMPT Sat Dec 28 11:22:53 GMT 2013 x86_64 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux

and spits out things like this:

gerdesj@jglaptop:~$ systemctl status apache2
apache2.service - Apache Web Server
      Loaded: loaded (/etc/systemd/system/apache2.service; enabled)
      Active: active (running) since Sat 2013-12-28 12:18:03 GMT; 1 day 10h ago
    Process: 2719 ExecStart=/usr/sbin/apache2 $APACHE2_OPTS -k start (code=exited, status=0/SUCCESS)
  Main PID: 2796 (/usr/sbin/apach)
      CGroup: /system.slice/apache2.service
                      2796 /usr/sbin/apache2 -D INFO -D MANUAL -D SSL -D SUEXEC -D LANGUAGE -D PHP5 -D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D SECURITY -D PERL -k start
                      2797 /usr/sbin/apache2 -D INFO -D MANUAL -D SSL -D SUEXEC -D LANGUAGE -D PHP5 -D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D

Cheers
Jon

Re: "Slashmirrored"

[Anonymous Coward]

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.

Note that I'm not condemning this per se, but it does have far-reaching implications that honesty compels you to be aware of.

Re: "Slashmirrored"

[jcdr]

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.

Re: "Slashmirrored"

[chrylis]

Pretty obvious typo for "can now be".

Re: "Slashmirrored"

[whois]

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 of the second is that even people who don't need fast boot now are learning how the new stuff works.

And it sucks, but that doesn't mean it can't be improved and made as good as the old system or better.

Re: "Slashmirrored"

[loonycyborg]

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 reinvent wheels.

Re: "Slashmirrored"

[PlusFiveTroll]

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.

Re: "Slashmirrored"

[celle]

"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: "Slashmirrored"

[MikeBabcock]

I started using DJB's /service system back with qmail and quite liked it, then thought systemd might be something even better. Sadly, its not.

I find it quite frustrating that auto-restarting scripts that just run in their own directories can still be that much easier to configure than the default boot system.

Re: "Slashmirrored"

[MikeBabcock]

Boot up speed is incredible with /service (see http://cr.yp.to/daemontools.html) 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.

Re: "Slashmirrored"

[MikeBabcock]

That's the most ignorant thing I've read all day -- the vast majority of people using Linux are not kernel developers, and I'm quite certain they don't navel-gaze enough to think they are.

I'm quite literally nervous about moving client servers to systemd in the future and we've purposely held back because the old init system is predictable and easy to manage.

Re: "Slashmirrored"

[MikeBabcock]

Don't be a jerk just because you can. Try backing up and looking at a situation from all sides before you go mouthing off and maybe you'll come up with a rational response instead.

Re: "Slashmirrored"

[sjames]

Most tablets and such hibernate rather than rebooting these days and I never reboot my desktop machines (though unreliable power does so once or twice a year).

However, I do see the value for firing up instances and that others might value it as well. I don't see why not just have the rc system fire off all scripts with the same priority level at once. Then if desired, run a priority optimizer to fix the links up based on dependencies.

Re: "Slashmirrored"

[Sri Ramkrishna]

I assume you mean that Linux is being monolithic instead of following the Unix credo.

Re: "Slashmirrored"

[Sri Ramkrishna]

I fail to see what is ignorant about people writing features and wanting people to use them. You have companies like Red Hat whose job is to integrate them in a stable manner with some extra work to migrate to the new paradigm. How often do you touch your init system, honestly? I never touched mine in my 20 years of doing Unix systems. You need to read up about systemd and understand how it works and what it does. You fear change, but your level of risk is no different than integrating some new product from a vendor. If you decide to move to RHEL or some other enteprise linux,, you'll be covered. Now if you are winging it, then of course, you should take as long as you need to do it correctly. I suggest you read Lennart's series of documentation on system administrating systemd. You're not losing any functionality and gaining some.

Re:"Slashmirrored"

[codeusirae]

"So do we just mirror phoronix on slashdot, now?"

Since when is news about a LInux distro considered off-topic on slashdot ..

Re: "Slashmirrored"

[drinkypoo]

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.

Re: "Slashmirrored"

[Sri Ramkrishna]

How do you know the U.S. Dept of Energy isn't asking for this stuff in the first place?

Re: "Slashmirrored"

[dpilot]

It was kind of fun to see Linus' reaction when the systemd developers attempted to push binary logging into the kernel.

Maybe some kernel developers are pushing systemd, not all.

Re: "Slashmirrored"

[Sri Ramkrishna]

This is true, but a lot of systems folks have been looking forward to this.

Re: "Slashmirrored"

[unixisc]

How is BSD being influenced by the shadow? They have not adopted Systemd, don't support GNOME 3 (except OpenBSD), and are only adopting technology they consider suitable, not anything & everything.

As for Plan 9, there is an FOSS version of it called Inferno. You could try that out.

Re: "Slashmirrored"

[unixisc]

Theo? OpenBSD is the only BSD that supports GNOME3: even GhostBSD doesn't - and won't.

Re: "Slashmirrored"

[armanox]

Because until recently I was a network engineer to the DOE (contractor). And they don't like a lot of things in Linux - they disable iptables and selinux, for example. They also have no interest in Linux on the desktop, only in a server capacity. And that was fading when I left.

Disclaimer (probably required after that statement): I am a former federal contractor, and my opinions expressed here do not necessarily represent official opinion or policy of the United States Department of Energy or my former employer.

Re: "Slashmirrored"

[visualight]

There are no "choice problems". NONE. There is not one single distribution with a preponderance of devs who think choice is a problem.

Having choices is the POINT.

This is a case of someone in a long line of wheel re-inventors shutting the door behind him so no one else can come after.

Re: "Slashmirrored"

[Anonymous Coward]

The only people developing Plan9 today are 9front and Erik Quanstrom (9legacy), There is only one guy employed and Bell, part time, to accept patches, and he doesn't accept patches that add functionality or hardware support.

I have in-depth experience with this, as a former 9front developer. I left 9front because of the immature demeanor of the 9front development team (see #cat-v on freenode), and the technical infeasibility of adding shared memory or efficient IPC to Plan9. Pretty much all IPC is copied at least twice (four is common) in Plan9, and it gets worse quickly when you add layers of 9P servers.

While I love the namespace isolation (security and reusability by design) which simplifies a great many tasks, the constant 9P marshalling (the kernel implementation) renders Plan9 terminally deficient in performance.

I would like to see/build a Plan9-like system, where the filesystems are exposed to the OS via a more fuse like API, which would greatly improve performance and remove a large amount of the IPC bottleneck of Plan9. For example, a filesystem could be exported through another filesystem without invoking serialisation, unless network topology actually necessitated it.

I'm not going to post my identity here, because of the childish abuse I received from the 9front cult last time I voiced my opinion on these technical matters, though it is probably obvious to cinap_lenrek and aiju who I am, so I expect abuse anyway.

Re: "Slashmirrored"

[Anonymous Coward]

If you'd never touched sny initscripts within your past 20 years of unix then you should be the person who cares less about systemd at all.

But the way you comment and cheerlead about it shows big signs of agressive community work and massive manipulation of people.

They must love systemd regardless of the consequences.

I tell you - they don't have to. It's theor good right to not learn about it and to raise a voice against it.

I am sick of people forcing crap down our throath - first - and then having us wearing the shoe - afterwards. We did not ask for systemd , we don't want it and we don't need to explain it either. We also don't want to be put in a position where WE need to excuse us afterwards for things implemented by YOU.

Re: "Slashmirrored"

[Pseudonym]

Why is KDBUS code full with 'goto' calls ?

Without looking at the KDBUS code, there are typically two answers to that question.

1. It's the easiest (and arguably cleanest) way to model a state machine.
2. Linus doesn't want C++ in the kernel and it's the only way to do stack unwinding in C.

Re: "Slashmirrored"

[Pseudonym]

C++ automatic stack unwinding is even nicer, but you can't have C++ in the kernel because mindless ideologues.

Re: "Slashmirrored"

[YoungManKlaus]

> Btw: Why is KDBUS code full with 'goto' calls ?

checking https://github.com/gregkh/kdbus/blob/master/bus.c
because it makes more sense than a huge nested if/else structure. if it was oop you'd also do "if(bla) throw ex1; if(b) throw ex2; ..." and then handle the common exit operations in the finally block. Nothing else going on there.

Re: "Slashmirrored"

[drinkypoo]

Well, dependency management for one.

That's handled by the user. But a tool could be developed which would create all the symlinks for you, if that's too hard. A simpler one, I mean, besides all the ones which already exist.

And the idea that I want my device to always be in one of a very few number of discrete states for another.

Yes, that's what runlevels are for.

What if I want WiFi off and GPS on and the disk spun down based on the AC power state and the display sleep based on the media playback state and the BitCoin miner based on the combination of Internet connectivity and AC power states?

That's a job for another daemon, as it is now. There's still no reason for that daemon not to switch runlevels when power state is detected.

rc.d is pretty bad even at managing a small number of states, let alone the huge number of interdependent states available in modern systems with a slew of independently powered and managed subsystems.

Huge number of inderdependent states available in modern systems? Availble, yes. Used? No. Systems usually use about three different states, awake and a couple of sleep states. Some people use hibernate as well, so there's four. That's well within the reach of rc.d. Systemd already doesn't handle all of the possible states a computer can be in; the init system only has to care about the major ones.

Re: "Slashmirrored"

[jcdr]

http://www.phoronix.com/scan.php?page=news_item&px=MTQ5NzQ

Re: "Slashmirrored"

[Desler]

I'm not being a jerk. I'm simply stating that the person should actually do something rather than just blather on with empty threats. They aren't going anywhere and they know it.

Re: "Slashmirrored"

[chill]

They probably disable iptables because they don't use system-level firewalls on servers, regardless of the OS.

And they disable SELinux because they probably don't have anyone who understands how to use it, much less use it well. MAC is great for security, but requires a depth of knowledge of your systems that most places just don't have.

I've seen both actions at several government agencies for those exact reasons.

Re: "Slashmirrored"

[staalmannen]

There are several real Plan9 variants and they are all FOSS (LPL is OSI approved) 9atom: http://9atom.org/ 9front: https://code.google.com/p/plan9front/ 9legacy: http://www.9legacy.org/ and the real bell labs distro: http://plan9.bell-labs.com/plan9/

Re: "Slashmirrored"

[coolsnowmen]

haha, where is my +1 troll mod?

Re: "Slashmirrored"

[visualight]

"...It would be a miracle if they would vote against adopting upstart..."

Seems pretty set, unlike the dramatic phoronix headline. In any case, having a choice is not something anyone seems to have an issue with.

Re: "Slashmirrored"

[shaitand]

Admins want certain core systems needed to admin a box to be standardized. It's an init system, there is only so much benefit you can have from one over another and those benefits don't outweigh the problems of distributions all being different.

An admin should be able to log in to a box and perform basic administration without having to care what distro it is running.

Re: "Slashmirrored"

[shaitand]

"And they disable SELinux because they probably don't have anyone who understands how to use it, much less use it well. MAC is great for security, but requires a depth of knowledge of your systems that most places just don't have."

Not talking about government agencies but there certainly are a lot of people who don't understand SELinux, mostly because it is confusing as hell and poorly documented. But even if you do understand it, it is cumbersome, it never becomes a silent player that just works, and to get any real benefit out of it requires TONS of additional time and overhead in system configuration.

What I usually see is people leave it on until the first instance of cryptic failures that can be traced back to SELinux problems.

Re: "Slashmirrored"

[Sri Ramkrishna]

Yeah, most people find SELinux difficult to use. I can understand disabling it. That doesn't make the entire system bad.

Re: "Slashmirrored"

[shaitand]

I'd contend that the idea is good but the implementation is bad. That's probably because it was designed by a government agency for government use that parallels the screwed up government models for controls and access to information.

For a system that is single purpose and just sits there except at update time I use SELinux every time. Because everything that raises the security bar is a good thing. For a system with lots of activity I take a pass, SELinux just adds too much troubleshooting and configuration overhead. If you invest that time and effort across the board it is almost certainly costing you more than additional risk of not running SELinux.

At least as things stand now. If Linux were attacked with the frequency and in the same ways the windows platform is attacked SELinux might quickly become a painful fact of life. But I'd expect if that were the case someone would come along and develop something a bit more sane to work with.

Re: "Slashmirrored"

[MikeBabcock]

Its unnecessary. See AC response.

Re: "Slashmirrored"

[MikeBabcock]

I shouldn't need to read half as many words as I do to understand systemd and how it works. Let me give you a counter-example:

Using daemontools, each service has a directory in an arbitrary location that is symlinked to /service. Any directory with a symlink in /service will have its "run" script executed on startup if it exists. That script's output will be piped to the run script in the subdirectory log. If the run script exits, it will restart again in two seconds. To prevent automatic startup, create a file named "down" in that service's directory. Each service executed in this way is forked securely in its own memory space.

That's it.

Added functionality is provided by additional software meant to be called from within said run scripts, such as softlimit to impose memory or fd limits on processes, tcpserver to launch a program for each incoming connection (much like inetd) and envdir to create environment variables based on the contents of files in a directory. All of these things are optional and so configuring a new service without a reference manual is possible in just a minute or two.

Feel free to update me when a fully functional systemd script can be explained that simply.

Re: "Slashmirrored"

[MikeBabcock]

People leave Linux every day. Its not like we have 80% market share or anything. I know at least five people who tried and gave up on Linux this year alone. Its sad, but their own reasons were all perfectly valid.

The one constant in Linux promotion and usage is sysadmins. Angering that population is very bad PR, whether you think PR is worth anything or not.

Re: "Slashmirrored"

[Pseudonym]

Automatic stack unwinding in the kernel? Are you entirely insane?

Are you saying it would be worse than the goto-heavy manual stack unwinding it currently uses?

Re: "Slashmirrored"

[Pseudonym]

I understand how the kernel works technically (along with several dozen production OS kernels which are written in C++ with no problem). But more to the point, I understand that C++ is unsuitable because of how the Linux kernel works sociologically. Despite the "mindless ideologues" comment (which should have been clear was a facetious call-back to an ancestor comment), I'm perfectly fine with this.

Why, oh why?

[Anonymous Coward]

Why do we need in-kernel DBUS implementation. And please don't tell me about performance, lot's of software with much higher performance requirements is more than happy in userland...

Re:Why, oh why?

[armanox]

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.

Re:Why, oh why?

[fisted]

Because GNU!

Fortunately, the BSD world is much less insane.

Re: Why, oh why?

[Anonymous Coward]

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?

Re:Why, oh why?

[Anonymous Coward]

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.

Re:Why, oh why?

[Anonymous Coward]

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.

Just blocking this guy would prevent pulseaudio, systemd and avahi.

Re: Why, oh why?

[epyT-R]

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:Why, oh why?

[epyT-R]

Is OpenBSD really suitable for typical desktop uses? Does it perform well?

Re:Why, oh why?

[epyT-R]

I thought those vulnerabilities were vectors because IE6 ran with escalated privileges..

Re: Why, oh why?

[sjames]

Windows.

Re:Why, oh why?

[sjames]

I'm not convinced we need DBUS at all, much less in the kernel.

Re:Why, oh why?

[sjames]

The biggest audio performance boost I have gotten was when I killed pulseaudio so that everything would use ALSA.

Re:Why, oh why?

[jcdr]

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?

[Sri Ramkrishna]

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.

Re: Why, oh why?

[MichaelSmith]

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.

Re: Why, oh why?

[Sri Ramkrishna]

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?

[jcdr]

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.
 

Re:Why, oh why?

[Sri Ramkrishna]

We'll have Greg K-H talk to you personally. Without your sign off, it'll be unlikely Linus will integrate it without overriding your objections.

Re:Why, oh why?

[sjames]

So you believe I have no right to an opinion? Or just no right to express it?

Re:Why, oh why?

[sjames]

Argument from authority?

Re:Why, oh why?

[x_t0ken_407]

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.

Re:Why, oh why?

[Sri Ramkrishna]

You have every right to express it, but it won't change anything unless you happen to be a working on the kernel. You'll have to trust that they are doing the right thing.

Re:Why, oh why?

[sjames]

And you are just an Anonymous Coward.

Re:Why, oh why?

[x_t0ken_407]

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.

Re:Why, oh why?

[sjames]

So why all the sarcasm then?

Re: Why, oh why?

[armanox]

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

Re:Why, oh why?

[serviscope_minor]

Why do those features need a kernel dbus?

Re:Why, oh why?

[bzipitidoo]

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 say it is.

Whatever else, systemd goes against the UNIX principle of having lots of small pieces that each do one simple thing and do it well.

Re:Why, oh why?

[moderators_are_w*nke]

I thought the idea for a kernel dbus came out of Nokia's Maemo team originally?

Re: Why, oh why?

[Sri Ramkrishna]

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

Re:Why, oh why?

[Sri Ramkrishna]

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.

Re:Why, oh why?

[deconfliction]

KDbus ... A lot of this is driven by desktop projects, so things like smooth transition to a login screen ...

I'll bite- how does K/Dbus help with a smooth transition to a login screen?

Re: Why, oh why?

[jcdr]

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.

Re:Why, oh why?

[jcdr]

Yes, and also because he is not alone at wanting DBUS in the kernel.

Re:Why, oh why?

[sjames]

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?

Re:Why, oh why?

[kenshin33]

gentoo, or something gentoo based, like sabayon?

Re: Why, oh why?

[Sri Ramkrishna]

I posted the rationale with some links

Re:Why, oh why?

[broken_chaos]

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, so I expect KDBUS will end up being stable and usable. Unlike, for example, udev which has made about a half-dozen hard backwards-compatibility breaking changes in the past year or so.

Re: Why, oh why?

[Rutulian]

What do you mean by supported, and why do you think your laptops weren't?

Re:Why, oh why?

[armanox]

I was referring to systemd becoming the defacto standard. No idea on kdbus.

Re: Why, oh why?

[sjames]

That was much more useful, thank you.

Re:Why, oh why?

[x_t0ken_407]

Having been familiar with FreeBSD (and running it both as a server and a desktop at times before), it just felt like the natural transition to make. I was pleasantly surprised to find that KDE4 finally reached the same usability as on Linux, and I haven't really looked back since. The ONLY issue is that I can't also run it on a laptop, unless I don't care about sleep/hibernated. For that reason, my E6400 still runs Arch.

Re: Why, oh why?

[armanox]

Why weren't my laptops supported? Intel i8xx graphics in Linux hasn't worked for years. And the vesa driver is not a substitute. What used to run perfect died with the introduction (and requirement) of KMS. The D510 sucked since AMD dropped support for 'legacy' graphics in Linux, and the radeon driver doesn't cut it (not really the fault of Linux or the Distro maintainers, just a fact).

Supported meant an operating system, either Windows, OS X, or Linux, that was actively receiving patches and updates for the purpose of this discussion. There was a reason (I can't recall right now) that I couldn't use RHEL 5.x on the C400, which should have worked.

Re:Why, oh why?

[fisted]

he's already a BSD user, so why would he want to switch to a Linux distro which tries hard to be BSDish (see e.g. portage, openrc) (and in fact is as close to a BSD as it gets in the Linux world)?

Re:Why, oh why?

[Eythian]

That would make doing useful things with sound that much harder though. I like my per-application sound controls without having to screw around with config files.

Re: Why, oh why?

[Rutulian]

Uhhhh....
http://www.ubuntuupdates.org/package/xorg-edgers/precise/main/base/xserver-xorg-video-intel

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. It says 13.10 and beyond will be more of a pain, but 12.04 is supported now and will be until 2017.

Re:Why, oh why?

[MikeBabcock]

This, precisely. I haven't seen a good rationale for it either -- nor have I seen one to justify the huge mess that is systemd.

Re:Why, oh why?

[celle]

"I'll bite- how does K/Dbus help with a smooth transition to a login screen?"

      Absolutely nothing. The hardware is so fast the software could stop and take a leak during the transition and no human would notice due to short time of the incident. Like all the other changes in that linux dependent group(systemd, etc) all it really does is kill portability as applications that other systems currently use eventually use linux exclusively. Congratulations on becoming Microsoft. Linux seems in the same condition now as the US legal/ethically now vs US in the 80's. Steve Ballmer must be laughing his ass off.

Re:Why, oh why?

[multi io]

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:Why, oh why?

[jones_supa]

And you are just an Anonymous Coward.

Come on, man. Greg Kroah-Hartman is like the main wingman of Linus Torvalds.

Re:Why, oh why?

[celle]

"I've read the reasons for systemd. "

You win a cookie.

"Faster boots"

Drop an SSD in the box. Problem non-existent.

"cleaner, more flexible, better at handling dependencies"

Is it? Seems to add more complexity to me. Newer, buggy, does not support legacy, isn't portable, potential lock in source. Large monolithic program with binary interfaces and inerds versus human readable output and structure of the old system. Wow it's got something there. My response isn't to parent but in agreement and against those that thought these large binary systems were a good idea for a KISS system.

Re:Why, oh why?

[sjames]

And if he were to post an actual explanation here, it would be worth a few bazillion times more than an AC not actually making an argument.

Re:Why, oh why?

[celle]

"I killed pulseaudio so that everything would use ALSA."

    The second biggest was when I dump both and went back to OSS. On Linux and FreeBSD.

Re:Why, oh why?

[jcdr]

The /proc interface is a mess from the format point of view: there is no standard; each file can use his own formatting.
The /sys interface is a bit better, but not everything is into it, and the "cross linked tree" structure can be difficult to handle.

You can see the kernel as a process. Or you can see the various kernel threads as processes. Don't be limited by a such pointless wording issue. There always was a big requirement for communication between parts of the kernel and some applications. The "everything is a file" was a really good design decision that proved to be adequate in a lot of situations. But there is more and more others situations that need features that the "everything is a file" design can't provides efficiently. IPC is one of them.

Just look at the numbers of IPC that exists and there evolution to realize that a simple file is clearly not an appropriate solution. Now try to count how many formats are used for communication with the Linux kernel. There is certainly an advantage to reduce the number of them if a common protocol can handle them in a good way.

Re: Why, oh why?

[Sri Ramkrishna]

Sure, glad I could help. :)

Re:Why, oh why?

[Sique]

"Faster boots"

Drop an SSD in the box. Problem non-existent.

Spoken like one who never has seen more than his desktop PC.

There are systems which don't have any HD that can be sped up by replacing it with an SSD. Flash based appliances come to mind. They surely can make use of faster boot times. There are systems whose storage is on a multi terabyte NAS, which can't be replaced by an SSD (or do you volunteer to foot the bill?). There are systems which are just virtual machines, and whose HDs are wherever the virtual filesystems are placed. I am working with systems, which run several servers as separate virtual machines in QEMU because of real time issues, and being able to short the time for a restart of those machines really helps.

You are not the navel of the universe, and if you can speed up boot times just by replacing your HD with an SSD, it's fine. But it's only relevant for you. It's not a solution for anyone else.

Re:Why, oh why?

[Sri Ramkrishna]

I think Steve has other things to worry about. Anyways, Linux is evolving away from typical Unix mentality. We'll see how things come along.

Re:Why, oh why?

[Sri Ramkrishna]

Actually XP was a significant improvement over NT considering how many million LOC that was changed. Everybody expected it to fall over. But it didn't.

Re:Why, oh why?

[Sri Ramkrishna]

Or maybe, LInux is being used in ways that it was not intended (eg embedded devices) and it requires capabilities since it's being shipped in products. Linux is not just some sysadmin tool now. It's everywhere now, in your bluray,, stereo, phones, cars, and all of them require changes. Do you really want your stereo to take a long time to boot up when we could use a parallelizing boot start up that will make the customer experience better?

Re:Why, oh why?

[epyT-R]

Hm ok. That's why I chose linux for desktop use, as it's the focus of most of the OSS desktop projects.

Re:Why, oh why?

[epyT-R]

My only experience with freebsd was an ancient version 2.2.6, which I ran before switching to linux (I think to run a quake server). Obviously things have changed a lot since then. It ran well from what I remember, but it had very limited support for linux binaries as I couldn't get it to run the server, even with compat-linux installed.

Re:Why, oh why?

[dpilot]

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 recently reclassified as "won't work on", with the reasoning, "because now we have systemd."

There's still Slackware. I haven't moved yet, but I'm thinking...

Re: Why, oh why?

[epyT-R]

At least 3 and 3.5 offer you the source at all.This ensures that if/when things get bad enough, it will be forked.. However, if the OS is locked down, it won't matter what userland is open as it will be impossible to run self-compiled binaries without expensive licenses or unreliable software vulnerabilities.

Re:Why, oh why?

[kenshin33]

Well, he did say "switched to arch from fedora", Linux user was a fair assumption, hence gentoo (which if I remember correctly can run a *BSD kernel).
As to why would he wants to? I don't know (and I don't care). It was a simple suggestion.

Re:Why, oh why?

[kenshin33]

to each his own :). Isaid gentoo b/c, I use it (I don't even remember since when), still no systemd forced down my throat (KDE4 seems to not depend heavily on it, and frankly don't care for the desktop env, the only utility it has -for me- is keeping multiple windows open on the same screen, -heavy terminal user-)

Re:Why, oh why?

[kenshin33]

I didn't know, I removed everything gnome 2 years ago. I switched full time to kde (always had both installed). If and when kde will require that too, I'll switch to something else (enlightenment may be, since it was my 1st choice years ago).

Re:Why, oh why?

[sjames]

You must really hate audio. That or you're deaf.

Re:Why, oh why?

[ArsonSmith]

http://xkcd.com/927/

Re: Why, oh why?

[armanox]

It doesn't work for most of the i8xx chips, and this is a well known flaw. Marked as won't fix since they've the chips is too old to care about. It broke when they changed the driver to support KMS.

FGLRX doesn't have a legacy driver that works with newer kernels. Radeon works well for a lot of things, but simply doesn't (or didn't when I cared) work as well (I think it may have been power management? Did they ever fix that? I remember the last time I used it (more recent card, HD 5770 and then on HD 7750) power management simply was non existent and the fans ran at 100%). Regardless, I don't still work at that position, and have to use Windows on the issued laptop (which has FirePro graphics...more AMD joy).

Re: Why, oh why?

[armanox]

Sandboxing isn't a bad thing. A lot of commercial software for Linux does this (I think that's what we install to /opt for....) to insure that the needed libraries are present - it's also what allows them to run correctly on newer Linux installs. But, people forget that, and then complain when $application doesn't run after the system has been updated.

Re:Why, oh why?

[armanox]

GNOME 3 and KDE 4 have been interesting journeys. And like most software, it was not very good in the early phase. GNOME 3 is getting better, just not my preferred cup of tea. KDE 4 is getting a little crazy and starting to taste like the lemon in the tea is sour.

I too would like to know what's been abandoned. GTK 2.x can be installed along 3.x without any conflict (in my experience). As far as moving to Qt, I know the LXDE project decided to move to Qt and merge with RazorQt, but beyond that I have no idea.

And Sri, since you are involved with the GNOME project, I want to take a minute and thank you for responding to (and putting up with) the comments and remarks from us. I don't reject everything you guys do, but I'm not the biggest fan either. With that said, I am not doing development work, but do understand what goes into it (have done dev work in the past when I was a contractor). I do hope to see my doubts proven wrong about the future of Linux in general. Until then, I'll keep vocal.

Re:Why, oh why?

[kernelpanicked]

I'm just gonna leave this here.

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

Re:Why, oh why?

[Barsteward]

why don't you use "http://www.linuxfromscratch.org/"

Re:Why, oh why?

[Barsteward]

You could also post an explanation for your stance

Re:Why, oh why?

[serviscope_minor]

I think you may have replied to the wrong post. None of your points answer the question which is why these things can't be done in userland.

Re:Why, oh why?

[Barsteward]

Can you post a rationale as to why not? I'm interested to find out why you think it should not be included. Until then it sort of sounds like "we didn;t need it in Linux 1.0, why do we need it now".

Re:Why, oh why?

[sjames]

My stance is what does it do that a unix socket and/or netlink can't do for me now?

Throw in a dash of XKCD 927

Re:Why, oh why?

[Barsteward]

You could say the same for watches, cars, planes etc. things move on and usually forward. These sort of criticisms through lots of these postings say more about the posters being stuck in his/her comfort zone and getting older.

I don;t think i've read a reasonable post saying why its a good or bad idea, just a load of opinions that aren't backed up.

Re:Why, oh why?

[Barsteward]

http://www.linuxfromscratch.org/ will make you happy

Re:Why, oh why?

[sjames]

The principle of parsimony as applied to software. The Linux kernel has always been served well by the principle of keeping things in userspace when they can be in userspace. The kernel is not a place where you want to expand the attack surface unless there is a very compelling reason to do so.

Given that, it really is more a question of "what can DBUS do for me" and "Why does it need to live in the kernel to do that".

In the case of the many services the Linux kernel includes that something like Minix doesn't, the reason was performance and stability. Those proved to be good reasons. Even there, Linux eventually grew support for Filesystems in USErspace. Yes, FUSE does sometimes remind us of the stability argument for filesystems in the kernel.

Re:Why, oh why?

[Barsteward]

KDBUS only works within the local machine whereas the other systems talk to other machines. So maybe it makes sense not to mix the messaging, Andriod may also take it on board and drop their specific system

Re:Why, oh why?

[dpilot]

By the way, it took me about a week to work up the proper package.mask file, but I'm running OK without systemd now.

What's annoying is that I kind of like what systemd is doing, I just really dislike the way it's packaged, and the way they're forcing it down everyone's throats.

Re:Why, oh why?

[jcdr]

Exactly. A new standard is not the solution.
Putting DBUS in the kernel has the merit of making an existing good and long established standard available to a wider range of communication demand.

Re: Why, oh why?

[jcdr]

Sorry but your "finding" really don't match with the reality: http://lwn.net/Articles/551969/

Re:Why, oh why?

[jcdr]

Take a look at the reality:

linux$ for i in $(find ./ -mindepth 1 -maxdepth 1 -type d); do r=$(find ./$i -type f -iname "*.c" -print0 | wc -c --files0-from=- | tail -1 | cu)); printf "%16d\t%s\n" $r $i; done | sort -rn
              176570632 ./drivers
                39285154 ./arch
                25360678 ./fs
                16726520 ./sound
                16270981 ./net
                  4178246 ./kernel
                  2149028 ./mm
                  1321702 ./security
                  1196376 ./crypto
                  1138780 ./tools
                  1061679 ./lib
                    789517 ./scripts
                    518658 ./block
                    224637 ./Documentation
                    185020 ./ipc
                    132264 ./virt
                      73918 ./init
                      42353 ./samples
                      12747 ./usr
                        6731 ./firmware
                              0 ./.tmp_versions
                              0 ./include
                              0 ./.git

The fact that modules are optional make the Linux kernel no so monolithic. It also use a lot of kernel threads that can be more or less see as services in a microkernel architecture. You can argue that is't not as fun as a microkernel, but if you want to do with microkernel services all what Linux do, you will probably end up with the same order of code quantity.

Re:Why, oh why?

[Bill_the_Engineer]

During the Automotive Linux Summit Greg Kroah-Hartman talked about the progress of kdbus.

He did a really poor job justifying the need for kdbus since he talked about QNX type messaging on Linux and how that was already provided by the SIMPL API in which Greg said "works well". Within that same article it is mentioned that the speed increase to D-BUS could be accomplished without moving it to the kernel. He did say that being in the kernel allowed for the order of messages to be guaranteed but it's debatable if message ordering is justification enough.

I don't really see this as something to get too upset about. Like most experimental things within the kernel, you can simply choose to recompile the kernel without kdbus. If Red Hat can live with the additional overhead within kernel space (even with the use of bloom filters to help with message classification and delivery) and support it then it probably won't make much of a negative impact. Red Hat is Gnome based and their architectural decisions are biased towards it anyways.

Re:Why, oh why?

[sjames]

Neither unix sockets nor netlink talk to other machines.

Re: Why, oh why?

[Sri Ramkrishna]

NIH indicates there was a solution before in the desktop/kernel space that met their needs. Even if you have a security hole, the whole point is that it is sandboxed. This puts the onus on the application writer to fix the problem not the distro. The distro is not a scalable solution.

Re:Why, oh why?

[x_t0ken_407]

To qualify this, I had been an avid Arch user since about '09-'10. Loved it's minimalism and the rc.conf file. Loved how (similar to FreeBSD) I only installed what I needed, and all apps were the vanilla upstream version.

One day, I found myself in need of a quick install to my gaming PC which had been running W7 exclusively -- i.e., get it into a condition where they could do the basics (web, email, etc.). I had the latest (at the time) Fedora iso and figured I'd just get that installed really quick so that the user could be back up ASAP (I normally recommend Mandriva/Mageia to newcomers). Upon attempting to complete some menial task, I realized that the entire underlying system had changed. I couldn't 'chkconfig -- list' , I couldn't 'service [svc] restart'. I got pissed. I then recalled why I stopped using Fedora in the first play a couple years previously: shit changes too damn much. I found myself trying to quickly learn systemd to get this system operable for the moment, but then as soon as I had the time, I reinstalled with Arch which I figured would ALWAYS hold themselves to the higher (IMHO) standard and the KISS/Unix philosophy. Not 2 months after the above adventure, I learned about the Arch dev's planned init obselecense in favor of systemd. There were HUGE arguments on the mailing lists because of the decision, and -- while I'm very open-minded and would be willing to try new things given (a) adequate reasoning behind the decision for the new "thing" and (b) I'm grateful for the time/effort put in by the devs -- I was VERY put off by the Arch devs stance of "this is what it is, no discussion, if you don't like it then fuck off". When they began censoring dissenting opinions, I knew it was time to "vote" with my feet and go to a system that fits my needs -- sadly, Arch no longer fit that.

And I'm by no means a zealot and though I advocate Linux and *BSD, I'm of the opinion that people should use what works best for them, be that Windows, Ubuntu, OSX or anything else (3 of my personally most-hated OS's). Though I'll suggest that Linux can do anything those can and more, I'll never try to convince someone that they should use X operating system just because everyone is different and has specific things they like in a system, and it'll almost assuredly be different than what I like.

Gentoo does in fact seem like something I'd like to work with and I've had the desire to retry an install (my only attempt was way back when I was still a newcomer to linux...needless to say I was overwhelmed), and I had a co-worker who advocated and swore by it. I've always found it to be a Linux for BSD users, haha -- if I'm not mistaken, a lot of it's philosophy was based on FreeBSD, yes?

Re:Why, oh why?

[x_t0ken_407]

My understanding is that KDE will not ever require systemd (I forget where, but I saw a discussion on this by the devs). I think their stance was that they'll always strive to be cross-platform.

Re:Why, oh why?

[x_t0ken_407]

How up-to-date are the apps? Comparable to FreeBSD? I always thought about giving another *BSD a shot, but FreeBSD has always been rock-solid for me.

Re:Why, oh why?

[cerberusss]

IPC is between processes, not between a process and the kernel.

What a weird thing to say. Kernel support has been present since the early (SysV) days of IPC. Do you think that was wrong?

Re:Why, oh why?

[dpilot]

http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

"Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely."

Is it possible to be udev-free with current kernels? Gentoo did fork eudev a while back, but at the moment it appears that Gentoo is solidly into the systemd camp, so I don't know what the fate of eudev will be. Static /dev was a pain, too.

Re:Why, oh why?

[sjames]

He would still be arguing from authority unless he gave an actual justification for his view.

Re:Why, oh why?

[cupantae]

The explanation linked by the ArchWiki article on systemd is very good:
Read this forum post.

As an Arch user, I hated systemd at first, for much the same reasons as already stated: the confusing and opaque nature of debugging. I'm now a convert, and I have been ever since I worked out how to do everything I used to be able to do. I now believe people's resistance is just growing pains. Give it a shot; it's easy and good.

Re:Why, oh why?

[x_t0ken_407]

I still use Arch on my laptop, so I've given it a shot. Even so, I still prefer the old rc.conf configuration and plaintext log files to systemd.

Re:Why, oh why?

[multi io]

The /proc interface is a mess from the format point of view: there is no standard; each file can use his own formatting.

That doesn't matter much in this case; the /proc filesystem is very hardware-dependent and highly system-specific anyway, and the files are mostly read-only. There's generally exactly one program or library/API that reads a particular /proc file, and that program/API is how everything else in the system gets that piece of information; this is not like generic "configuration files" in userspace which would potentially be read AND WRITTEN by dozens of processes.

Re:Why, oh why?

[multi io]

IPC is between processes, not between a process and the kernel.

What a weird thing to say. Kernel support has been present since the early (SysV) days of IPC. Do you think that was wrong?

The kernel provides the IPC mechanisms, but they're mostly used for communication between (userspace) processes, not between processes and the kernel.

Re:Why, oh why?

[jcdr]

Sorry but I strongly disagree with you point of view.

A lot of networks settings for example are still into /proc/net. There are not hardware dependent and a lot of them can be acceded in write mode. A lot of different programs or library use them, especially if you build routers like I have do in a early workplace. Just look at how many API and codes exists to simply do a DNS query...

The /proc interface will stay almost forever because it is too deeply part of the UNIX history, but it really a mess after decades of erratic evolution, especially in the Linux kernel that initially put almost anything into it before trying others ways.

More Bloat ?

[fluffy99]

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.

Re:More Bloat ?

[Anonymous Coward]

Seems like the primary use of D-BUS is for the desktop components,

Desktop Bus - I think there's a clue in the name.

which already abuse/overuse inter-process communication.

It's wasted on my desktop, I use the shell as a filemanager and login to a mail server over ssh to get my email. Seems dbus, ssh_agent and other bullshit should always be optional even on the desktop.

The "huge performance improvement" is only for those processes that shouldn't be abusing this anyway.

In typical "because fuck you!" style; Systemd relies on dbus for ipc and on ipc for halt, reboot etc. Can someone please step up and write a sane rc.d based init system so we can consign Systemd to the trashcan of history.

Re: More Bloat ?

[Anonymous Coward]

I don't like the behaviour and social limitations of Poettering.

Go to youtube and search for 'datenwolf'. You see how insulting Poettering hijacked the speach of that poor guy.

Later on he came up totally drunk, keeping a bottle of alcoholics in his hand and pissing off the audience.

Sorry! I don't want software written by said person. Even if it would start solving starving in the world.

Re:More Bloat ?

[SumDog]

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

Re:More Bloat ?

[profplump]

"sane" and "rc.d" are mutually exclusive requirements. Maybe systemd is not the answer, but we know from decades of experience how bad rc.d is.

Re:More Bloat ?

[sjames]

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.

Re:More Bloat ?

[fnj]

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 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, as expressed by Mike Gancarz.

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

Re: More Bloat ?

[Sri Ramkrishna]

You should see what happens when Linus is in your talk. Same damn thing, albeit without the drinking. The guy was all over X guys over some stuff he had a pet peeve about.

Re:More Bloat ?

[jcdr]

Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication.

DBUS is already used on a number of embedded projects since many years.

Re:More Bloat ?

[jcdr]

Good luck if you try for example to use Bluetooth or Avahi without D-BUS...

Re: More Bloat ?

[Anonymous Coward]

It was not 'my' talk. It was the talk of a guy called datenwolf. I stepped over that video because I was pointed towards it by someone else. About Linus Torvalds. You truly don't want to compare Torvalds with Poettering do you ? The one brought us Linux and the other crap! And yes being drunk vs. not being drunk gives a different perspective towards the situation. Don't forget! It's people, users and admins like us who made Linux mainstream by using the word! We can quickly change that!

Re:More Bloat ?

[salahx]

hHe short version: http://lwn.net/Articles/551969/

At first, this sounds like the kernel developers have raided LP's "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.

Re: More Bloat ?

[Sri Ramkrishna]

I am just saying that this behavior is not surprising in FOSS

Re:More Bloat ?

[celle]

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

        Contaminating Unix wide standards with Linux specific shit isn't a good idea, especially for the rest that don't want it and have no use for it. See the GCC and the Linux specific junk in the C/C++ standards. Nothing but headaches.

Re:More Bloat ?

[drinkypoo]

Contaminating Unix wide standards with Linux specific shit isn't a good idea, especially for the rest that don't want it and have no use for it.

You propose that Linux avoid progress. Your proposal has been rejected. Eventually, all the proprietary Unixes alive today will die and there will be only Linux, *BSD, and perhaps any other Unixlikes which will be invented between now and then and which don't suck.

Re:More Bloat ?

[loonycyborg]

Yes. Many complain about 'shocking attitude' of systemd developers. I tried to test it by checking original statements and didn't find anything shocking. They're about as professional as any other project's developers. So this is yet another lie it seems.. I wish there was less pointless trolling and more productive work.

Re:More Bloat ?

[ald_a]

Indeed. No one in the unix world should care about a fast boot (why do you need to reboot your machine in the first place). I guess Redhat guys (especially Lennart), has lots of spare time in his hands and manages to bloat on the least problematic part of a distribution. Did any of you guys had problems with systemv?
Why tie Gnome, dbus etc to systemd? You can't nowadays install Gnome without systemd. I find this approach a shameful thing in the Linux history.

Just my 2 cents.

Re:More Bloat ?

[fnj]

AC is an ignorant child, but it's worth pointing out the truth of it for other readers.

Dash is Posix 1003.2 compliant. It minimally extends the Bourne shell, the brilliant honorary patriarch of all shells. Regarding it as contributing to fragmentation amounts to clinical insanity, or pure ignorance. On the other hand you could make a case that Bash does so contribute with all its extensions achieved through much bloat, but I DON'T make that case.

If you cannot write an at least Posix clean shell script, if not Bourne shell clean, you are worthless as anything more than a pushbutton admin.

The one criticism of Bash that I do have is that you cannot optionally set it to flag all extension use as a warning or error. As a result we have a world full of scripts with a shebang line of /bin/sh, which cannot run properly unless /bin/sh is a symlink to Bash. The least service a script writer can do to the user is either (1) make the shebang line /usr/bin/env bash, or (2) with the shebang line /bin/sh, make sure and test that the script is Posix clean.

So this is the thing killing portability

[Improv]

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.

Re:So this is the thing killing portability

[AceJohnny]

Portability also means giving up on system-specific optimizations and features. Some people have decided that Linux's market share means it's time to bank on those optimizations. Why not?

Re:So this is the thing killing portability

[olau]

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.

Re:So this is the thing killing portability

[Jah-Wren Ryel]

you have to understand that these developers are not your serfs you can command

Ugh, I hate that sort of extremist straw-man. The developers are working on public projects, that means they are subject to both public praise and public criticism. It is a package deal.

Re:So this is the thing killing portability

[Improv]

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.

Re:So this is the thing killing portability

[Flammon]

There's already a D-Bus implementation available on BSD and other Unices. The API is documented 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.

Re:So this is the thing killing portability

[Sri Ramkrishna]

Linux is not Unix. It has gone way off the POSIX standard for some time now.

Re:So this is the thing killing portability

[fnj]

I don't see giving up on openness, but yes, it represents a cavalier kiss-off to BSD. Developer privilege. And it is user privilege to turn one's back on this.

Re:So this is the thing killing portability

[Sri Ramkrishna]

What will you do?

Re:So this is the thing killing portability

[DeSigna]

What?

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's part of the benefit of OSS.

Re:So this is the thing killing portability

[jcdr]

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 hardware and application that are really out of the focus of the today market needs. The fact that the UNIX API last so long prove that it was a very good design, but this design don't include today hardware and application that was just pure fiction when it was created.

Re:So this is the thing killing portability

[celle]

"The protocol is open and free for any other OS to implement, and will remain so."

        But who says they want to or should have to deal with it. Just because it's there doesn't mean anyone wants it.

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

        A new GUI? A new GUI, a new pretty to go with all the pretty we already have collected over the last twenty years that does the same fucking thing! It's just reinventing the wheel as superficially as possible for a completely superficial culture. If there's a god, save us from a new GUI that's the same as the old GUI.

      And as for the BSD being left in the dust you might want to look at your critical infrastructure.

Re:So this is the thing killing portability

[celle]

"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 hardware and application that are really out of the focus of the today market needs. The fact that the UNIX API last so long prove that it was a very good design, but this design don't include today hardware and application that was just pure fiction when it was created."

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

Re:So this is the thing killing portability

[jcdr]

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.

Re:So this is the thing killing portability

[rubycodez]

Linux is the standard, the UNIX(tm) are dying off.

Re:So this is the thing killing portability

[Barsteward]

" A new GUI? A new GUI, a new pretty to go with all the pretty we already have collected over the last twenty years that does the same fucking thing! It's just reinventing the wheel as superficially as possible for a completely superficial culture. "

Get over it, there is only ever going to be small changes to a GUI, there isn't really anywhere else for it to go unless they can plug the computer into your brain and the GUI becomes controlled by your thoughts. I think you have unrealistic ideals on this point

" If there's a god," - no such luck

Re:So this is the thing killing portability

[Barsteward]

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

I'm afraid thats the problem with armchair critics, they snipe from the safety of the sidelines

Re:So this is the thing killing portability

[fa2k]

anyone has the freedom to implement it any way they want, userspace, kernelspace or [the Cloud].

FTFY...shudder

Re:So this is the thing killing portability

[jcdr]

Sorry if it's hurt your sensibility: this was not my intention.

I thought it was a correct response to the "Linux isn't being engineered anymore" statement.

Re:So this is the thing killing portability

[Urkki]

What?

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.

"D-Bus Is portable", but seems headed down the road of practical unportability (barring complete rewrite and parallel maintenance of critical parts of a complex software stack). This seems to be a package deal, systemd + kernel DBus. Seems very much like Embrace, Extend, Extinguish: Integrate to Linux kernel, create growing ecosystem which depends on the new features of the Kernel version of DBus, abandon non-Linux kernel versions of DBus.

I truly hope I am wrong, but for now I will steer clear of systemd and any Linux distro which is going to use it. For me Linux comes with a bit of ideological baggage (you know, openness, freedom), and I'll not touch this particular bit of it until I am comfortable it is not going to shove something down my throat. And if it turns out to be difficult, then that more-or-less proves that my concern was valid.

(Yes, I'm the AC above.)

Re:So this is the thing killing portability

[Barsteward]

i was sort of agreeing with you not criticizing your comment

Re:So this is the thing killing portability

[Sri Ramkrishna]

Indeed, and it is making it's own reality.

Re:So this is the thing killing portability

[rubycodez]

and another thing, BSD is true Unix, though it is not Unix(tm). Unix(tm) is just some needlessly complicated system V's that promote vendor lock-in, by vendors who hijacked the Unix name.

Listen to A.S.T.

[Bram Stolk]

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:Listen to A.S.T.

[Anonymous Coward]

Please not use the words "fine" and "dbus" in one sentence without a negation. Thanks.

Re:Listen to A.S.T.

[Anonymous Coward]

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 comparable monolithic kernels, while (ideally) making up for this in flexibility and ease of debugging. Modularity in ring 0 is a double-edged sword: there are few protections against screwing everything up in a monolithic system (although Linux is now more like a hybrid, with an emphasis on supporting both static and dynamic modules, and it's been decades since a single minor change in some static module has caused some unrelated module to do something silly like scribble all over my disk), but it's almost always easier and faster to write non-modular systems in ring 0 (particularly early in the process, when many of the basic facilities need to be implemented and debugged for the first time -- it's extremely difficult to debug module loading in a microkernel when something like printing messages to the screen are in a separate module). In a sense, the microkernel-vs-monolithic debate mirrors object orientation vs procedural programming debates of the past (and both are fairly moot -- it's a decision about which much ink and many pixels have been spilled, and in the end, the decision is one that probably should be based upon the requirements for the particular project. An atmel device with 500 bytes of ram doesn't need a microkernel; a system intended for something fairly exotic like transparent heterogenous distributed computing can benefit greatly from it).

As for whether or not this is a good idea -- I'm in agreement that it's a bad idea, but primarily because of poor past experience with userland dbus implementations. I've used many distributions over the past fifteen years, and I've never had dbus work properly out of the box on any system that wasn't either debian-based or red hat based (and most of the distros I use on a regular basis are neither). If the developers working on top-10 distributions can't get it working properly and consistently and only the top two distributions can (for the sake of argument, I'm considering all debian-derivatives to be debian and all red hat derivatives to be red hat), then it's something that I don't trust to work in any kind of fringe situation, and it's not something I'd trust in kernel space except in the most well-tested situations (say, running a ten year old stable implementation on ten year old best-selling consumer hardware after five or six years of heavy automated testing). Much like some other systems being pushed by canonical (PulseAudio, systemd), dbus seems like it was released far too early and really isn't ready for prime time. Back in 2003, I'd expect and tolerate this kind of cavalier behavior from mainline distributions (remember Fedora Core 2's problems with ejecting CDs and then keeping them registered as mounted?), but Linux is now a perfectly reasonable desktop OS for most situations and enterprise-grade linux is big business, so shipping with completely broken non-solutions to already-solved problems (PulseAudio, which completely randomizes mixer settings on startup, etc.) seems unforgivably irresponsible.

Re:Listen to A.S.T.

[sirambrose]

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.

Re:Listen to A.S.T.

[Bram Stolk]

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

From wikipedia:
Traditional operating system functions, such as device drivers, protocol stacks and file systems, are removed from the microkernel to run in user space.

Re:Listen to A.S.T.

[Guy Harris]

That word does not mean what you think it means.

Nor does it mean what you think it means.

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.

If by "kernel" you mean code running in kernel space, so that the modules run in privileged mode, that's a kernel with loadable modules, and is not necessarily a microkernel. Bram Stolk's response has a better definition of a microkernel.

Too much navel gazing

[Sri Ramkrishna]

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/

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.

Re:Too much navel gazing

[Anonymous Coward]

> 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

Last update time on that repo is 7 months ago. ( https://github.com/gregkh/presentation-kdbus/commits/master ) Did you fail to update your copy-pasted talking points?

Re:Too much navel gazing

[celle]

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

        So linux standard base is dead, right?

Re:Too much navel gazing

[Sri Ramkrishna]

Or it could be modified to include this. Nothing says the standard has to remain the same for all of eternity.

Re:104 minutes?

[jcdr]

You maybe have a service sending a lot of DBUS messages, because usually a dbus-daemon is very very low in processing time.

root# uptime
  00:18:50 up 17 days, 10:15, 9 users, load average: 0.25, 0.35, 0.39
root# ps -C dbus-daemon fw
    PID TTY STAT TIME COMMAND
  4616 ? Ss 0:12 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
  2508 ? Ss 0:04 /usr/bin/dbus-daemon --system

why not use binder

[GodWasAnAlien]

why not give up on dbus, and just use binder, which is already supported in the kernel?

Personally, I _do not want_ this.

While, we are at it, I do not want do-everything daemons like upstart or systemd. These monolithic programs of undefined scope are poor examples of software engineering, and not needed.

Re:why not use binder

[mab]

Binder is "weird", Kroah-Hartman said. It came from BeOS and its developers were from academia. It was developed and used on systems without the System V IPC APIs available and, via Palm and Danger, came to Android. It is "kind of like D-Bus", and some (including him) would argue that Android should have used D-Bus, but it didn't. It has a large user-space library that must be used to perform IPC with binder.

Binder has a number of serious security issues when used outside of an Android environment, he said, so he stressed that it should never be used by other Linux-based systems.

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

Re:why not use binder

[Ash Vince]

Binder is "weird", Kroah-Hartman said. It came from BeOS and its developers were from academia. It was developed and used on systems without the System V IPC APIs available and, via Palm and Danger, came to Android. It is "kind of like D-Bus", and some (including him) would argue that Android should have used D-Bus, but it didn't. It has a large user-space library that must be used to perform IPC with binder.

Binder has a number of serious security issues when used outside of an Android environment, he said, so he stressed that it should never be used by other Linux-based systems.

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

What does he know anyway. If he knew more about kernel development he would be more offensive like Linus :)

Re:104 minutes?

[PlusFiveTroll]

strace -p $PID_OF_DBUS_DAEMON

As for your network, it's probably something related to this http://avahi.org/

The stupid thing is

[markhahn]

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?

Everything LP touches seems to epitomize rebellion against, or ignorance of, the *nix/OSS philosophy (you know, modularity, loosely joined, liberal-in-what-you-accept, etc). systemd is the USSR of rc systems. pulse only remains because apps can still bypass it.

Start working on HURD

[Anonymous Coward]

If you don't like how Linux is evolving, you can always help with GNU HURD. It is an opportunity to mold that system in the way you see fit.

Re:Start working on HURD

[rubycodez]

Linux exists soley because HURD has been such a dismal failure, the FSF can't manage something as complicated as the building of a kernel

Re:Start working on HURD

[unixisc]

HURD needs to be redone from scratch by a totally different team using a forked Minix3 as their basis, and building all the HURD servers on top of it. Main work would be the driver support

Re:Start working on HURD

[staalmannen]

I would rather see it based on Genode OS and the L4 microkernel

Re:Start working on HURD

[unixisc]

L4 was already tried. Reason I suggested Minix is that it is already designed around Unix - not sure about Genode or L4.

Re:Start working on HURD

[rubycodez]

don't insult the Minix man and team, Minix is a fully functional operating system that can run real world software, for example Apache server with Perl or Python wares

A team that needs an OS to "build their OS" to run on top of it doesn't know how to make an OS

Re:104 minutes?

[MikeBabcock]

Diagnosing such issues is a pain though; and one of the reasons I dislike dbus :/

re: Note that I'm not condemning this per se

[codeusirae]

"Note that I'm not condemning this per se"

It's understandable why you would want to remain anonymous ...

Re:104 minutes?

[jcdr]

There is DBUS tools to inspect the messages bus. Probably that your issue will be nothing different with an other IPC.

Re:104 minutes?

[MikeBabcock]

Lets just leave it at there's a reason people have had to write things like this:
http://www.webos-internals.org/wiki/Introspecting_Dbus

ps avx; /var/log/*, ipcs and netstat -apn are all much cleaner.

Dido?

[jabberw0k]

Dido, the British singer-songwriter ("White Flag," "Life for Rent")? -- or did you mean, "ditto"

parse TFA

[mynamestolen]

can someone please parse the English for me (first line of TFA): "Open-source developers this week achieved a pleasant late Christmas present for Fedora users of having a working system with using the in-development Linux kernel DBus implementation (KDBUS) paired with the latest systemd code can now yield a booting system."

As a naive user, I'd be wary if they can't even write in English.

waking up requires special cases, so does moving

[dutchwhizzman]

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:waking up requires special cases, so does movin

[sjames]

Same sequence as start for a runlevel, only do restart instead of start.

Re:waking up requires special cases, so does movin

[sjames]

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 in rc[1-5].d to be first class citizens. Ideally, it would auto-generate init.d scripts so that legacy scripts using /etc/init.d/service [start|stop|status] would continue to just work. As opposed to the current case where that is considered to be a 'problem' that needs some sort of remedy.

That compatability should be retained until nobody is using rc scripts anymore (read as "for years to come").

Right now, systemd feels like it will have all of the charm of Gnome3, complete with it's "our way or screw you" attitude that has people avoiding it in droves. Init is too important to hand over to that.

Getting to know the BSD user community

[bain_online]

I guess i stlll don't know who the other two people are.

Re:Getting to know the BSD user community

[fisted]

Well that'd be me, and your mum. I talked her into BSD the other day.

Re:104 minutes?

[jcdr]

Standard package of dbus should already contain the dbus-monitor and dbus-send commands.
If you want an easy tool, try D-Feet https://wiki.gnome.org/action/show/Apps/DFeet?action=show&redirect=DFeet.

ps and netstat only show the current state. You need very different others tools to modify the state or to dynamically monitor the state transitions. From this point of vire, DBus if far more generic, coherent and cleaner than a lot of others tools.

Re:Avahi?

[jcdr]

I actually found Avahi extremely well implemented. It work exactly as expected and I never have identified any problem with it.

I am afraid that the future will make your dbus-free system more and more challenging. I do a lot of embedded system and the dbus-deamon is so critically important that nothing will work without it.

Boot times

[Larry_Dillon]

You're absolutely correct that Windows presents the Desktop before the system is actually ready to do anything. It gives the illusion of faster booting.