Kdbus will really will provide several layers of extra security since LSM's like SELinux can hook into the system from the kernel and not in the much less secure userspace. You also gain kernel guarantee for the message marshalling.

That is exactly because dbus is extremely slow when it comes to data transport.

The point is that many developers, especially embedded and IVI (and DE's like Gnome and KDE) are interested in using the same framework for both control and data. Having side channels to dbus in order to gain speed for data means maintaining proprietary frameworks that has to duplicate much of what dbus does anyway.
This will also be a great help regarding sandboxing of applications.
See more here:
https://lkml.org/lkml/2015/3/9...

Oh so you miss the days of manually setting sound card jumpers to set DMA and IRQ with certain software only accepting a subset of these, and you miss how each and every program fought over access to the sound card, and how there was no system sound daemon that worked across the different DE's so each DE had its own shitty sound daemon, and in those days where you really had to know what chipset your sound card used because so many chipsets was unsupported or had quite broken drivers. And don't get me started on that shitty company behind OSS that started to close source their stuff in order to extort money from Linux users and distros.

PA is great stuff that solved many real world problems with sound on Linux.

This is not about "one true way", but I genuinely don't see no interesting alternative to systemd. After having tried the benefits of systemd-journald with collated, structured and indexed log files, there is no way I ever will go back to using unstructured, un-indexed text log files scattered all over the system.

And since the systemd-opponents party line is is that binary log files are always bad, they won't make such an alternative.

No it is not, I actually read the LKML at the moment, and I can assure that Linus is positive regarding Kdbus and its design goal and that it will be merged once he is confident that potential security problems have been fixed.

They will. Sure there will be lots of sparing and harsh word duels, and not everybody will be happy, but that is how the process works for any major kernel feature. In the end the process tend to produce good enough results.

Having used Linux audio from before PA came into existence, and having used PA from the beginning, I can assure that PA was a major step forward in fixing Linux audio. With PA sound on Linux actually began to work. Sure it exposed a lot of kernel bugs (drivers) and ALSA bugs in the beginning, and some distros and software got the implementation wrong, but it lead to the first coordinated bug fixing effort between drivers, ALSA and user space. PA was always rock solid for me, and while it had some bugs, but far the most serious and numerous was in the drivers and in ALSA layer.

Even those who smugly announce they don't use PA benefit from all the work the PA, ALSA and kernel developers did together.

Kay Sievers _is_ a seasoned programmer. He maintained udev alone for many, many years. What he and Linus disagreed upon was whether you should fix broken kernel features or not. Kay thought you should, Linus disagreed. Rather typical LKML discussion in my opinion, but blown out in all proportions by the systemd-haters because they wrongly think that Linus don't like systemd nor its programmers because of this.

Pure rubbish. Sure Sysadmins running with broken fstabs was caught by surprise (who really reads the release notes or study a major piece of new software like systemd before upgrading the servers).

That systemd refuses to boot with disk setups that doesn't work, is because it does right thing to avoid raid array wipe-outs and silent data loss, and because it respect how the sysadmin have configured the system. SysVinit just ignored what fstab told it and bumbled along with the boot.

I think the systemd-opponents are deeply split about this; the BSD-Linux users want OpenRC because that is close to BSD and hates systemd because it means work for BSD, the traditionalists want SysVinit forever "because it isn't broken and systemd doesn't provide new features...". Nobody wants Upstart.

Almost nobody is working on an init-system that basically isn't a SysVinit variant. Considering how small a minority the systemd-opponents are, then any sub-set of this group is positively tiny.

It is worth pointing out again, that the negative campaign against systemd, also have stifled any development of any meaningful competition; if systemd is overall bad in every aspect, why even bother developing an alternative? It is so much easier to take refuge in paranoid conspiracy fantasies on how systemd won over every major Linux distro, by dark cabals working behind the scene.

Well, Kdbus is more than just simple IPC, it is also provide a control framework with policies etc. just like dbus does.

What the tin-foil brigade don't understand, that any non-dbus compatible IPC will be a major problem for all non-systemd distros and BSD variants, since it per default will be Linux only, and in reality a systemd-only affair, since only systemd distros will have the developer manpower to implement and support the necessary userspace libraries.

With Kdbus, userland can just continue to use legacy dbus code that works across all Linux and BSD distros. And the non-systemd distros can use kdbus too by only providing a minimal mechanism that initiates Kdbus at boot.

All in all, the non-systemd distros should really cheer for Kdbus in the kernel, since any other alternative will swamp them with work.

systemd is great stuff, only a tiny but vocal minority disagree with this. Keep your SysVinit for the next 30 years if you please, the rest of us wants systemd.

Linus Torvalds have long signalled that he wants kdbus in the kernel. What he is waiting for is the usual kernel process to work. At the moment the technical debate is about allowing certain kinds of meta-data to be transported around. The broader problem is that most kernel developers have very little experience with user space system glue like dbus, and you have to understand dbus in order to understand kdbus, so the review process will take some time. Nothing really unusual about this however, sometimes it takes a long time before features are accepted into the kernel.

Sure, many systemd-opponents harbour fantasies like that. Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design, that the systemd design is bad and that the code is bad, it puzzles them that despite all this, systemd have worked beautifully for so many years.

But the brutal and inescapable fact is that systemd is coded and designed by top notch, seasoned Linux programmers that really knows their stuff well, and that systemd also work really well and solves so many old problems.

It is one of the hilarious facts that the solely negative campaign the systemd-opponents have waged against systemd, belittling it and its developers, that this has also prevented that any competitive alternative could be developed. By being unable to make a cool assessment of systemd, recognizing its many strong points, you can't even begin to formulate an alternative strategy that can convince technical minded people outside the very small circle of systemd-opponents.

A typical misunderstanding by people quoting a systemd-devel mail out of context. They don't intent to keep the kernel and systemd in lock step for every release. They haven't done before so why should they do it in the future. What they do want to do is require kdbus kernels in the future, and that will bumb the minimum kernel version from 3.8 (or whatever) to 4.2 (or whatever).

At the time when such an edition hits stable distros, there will be no problems with downgrading to a previous kdbus enabled kernel.

Also remember that systemd follows the same pattern as the kernel development with bleeding edge releases and long term stable releases. Nobody is forcing anybody to use the newest systemd available, use a long term stable version (208, 215 etc) if you please.

Well, SysVinit systems aren't magic either, if there is a kernel-GPU bug or similar low level error, systems may hang forever without any useful output, and without rootfs there isn't any logging done.

But did you try VT9 etc.? Was crash shell enabled? I find that systemd with initramfs like Dracut is a breeze to debug when it comes to boot problems; stuff like "rd.break=pre-mount" is great if there are serious rootfs problems, or appending "1" or "emergency" to the kernel cmd-line. This is a good start page about debugging systemd machines:
http://freedesktop.org/wiki/So...

Playing around with a systemd-nspawn OS container is also a good way of simulating various boot errors and how to recover from them.

All in all, systemd is a great improvement when it comes to boot problems, not at least because there can be full logging from initramfs already.

systemd code is both thoroughly tested and audited. In fact, Red Hat has a professional security audit team that actively audit systemd code, this is more than can be said for OpenRC or SysVinit or any other systemd alternative.

They also have integrated Coverty static code checking and good coding guidelines to ensure maximum security.

systemd have been used by distros since 2011 (It predates the Linux kernel 3.0 series) and some of its code like udev goes back to 2003. It is much better tested than most other Linux software.

It is pretty close to 4 years since the Fedora 15 was released with systemd:
LibreOffice was 3.3.2 (4.4 now)
Apache was 2.2 (now 2.4)
Kernel was 2.6.38 (4.0 now).

It is absurd to suggest that systemd isn't proven and tested in the wild for a long period.

Also note that some systemd code like udev, existed even before the systemd project was announced, so at least part of the systemd code is much older than 5 years (udev was released in 2003).

This won't work at all. One of the most basic requirements of teaching is that your teaching level correspond to those you teach; aim to high and you loose them because they don't understand, aim to low and you loose them because they are bored. Having one "super teacher" yapping one-way lectures from a giant screen without the "teacher" knowing what his pupils can, is simply a lost cause when it comes to engaging and teaching the pupils.

And why the giant screen? Why not having each pupil following an individual course on individual screens instead of forcing everybody to follow the same course. And why the classroom at all if its only function is to supervise discipline among the inmates/pupils.

(Why not just strap the pupils to a chair in their home and force feed them lectures through Occulus rift headsets and noise-cancelling headphones; it is easy to motive the pupils through reinforcement stimuli like tasing them gently if they have wrong answers. This will be very cheap and is guaranteed to produce marvellous results.)

Well, I know SysVinit (including variations like Slackware uses) and Upstart. Both are pitiful when compared with systemd, especially killing processes and handling PID's. And all the service management tools you can tack on top I know of like Monit and S6 are painfully labour intensive to use and lacks fundamental features. (Monit has pretty graphs though).

Any init-system without integrated resource management like cgroups and easy to use service monitoring and easy to use security frameworks using namespaces and capabilities, are hopelessly nobbled when compared to systemd.

Just the fact that systemd uses structured plain text files for service and daemon configuration is a huge win compared to using script files, that are basically executable config files that mixes code and config options in one unstructured lump that are hard to parse for both humans and machines.

IMHO, most people criticising systemd haven't really bothered up upon its design or why it is designed the way it is, but rely on third party blogs and random forum comments. There really are good technical decisions behinds its design:

Take the logging system; if you want "metal-to-metal" logging, that is from before rootfs is mounted to potentially after it is dismounted, and you want to collate all logging messages, no matter how and when they are generated, you will end up with a design like systemd's "journal".

All other existing Linux logging facilities have logging gaps and are unable to create collated logfiles from the entire boot and shutdown process.

systemd really solves many old Linux problems in one go, not at least the problem with the partially fossilized plumbing system: eg. cron was made with the assumption that computer was always on. This is a problem when most Linux devices these days runs on batteries and frequently are suspended or shut down.

But there is not central cron-developer group, there are only fragmented forks of ancient abandonware versions of eg. Vixie-cron, so cron can't be fixed, nor can there ever be a new cron version that fixes any problems that will make it incompatible with cron. cron is simply doomed to permanent fossilisation.

Getting systemd-timers is so nice in that they not only fixes old cron problems, but also makes it possible to change future implementations of it. It is simply great that there is a central developer hub that can take RFE's and patches for this.

I am really not aware of any "sophomoric mistakes" regarding systemd's design; it is small, modular, lean on resources, fast, stable, have lots of great features that are very easy to use.

IMHO nothing else on Linux even come close to all the features systemd have, which is why all major distros have chosen to use it.