Linux 4.1 Bringing Many Changes, But No KDBUS

An anonymous reader writes: The first release candidate of Linux 4.1 is now available. Linus noted, "The merge window is pretty normal in terms of what got merged too. Just eyeballing the size, it looks like this is going to fit right in — while 4.0 was a bit smaller than usual, 4.1 seems to be smack dab in the middle of the normal range for the last couple of years." There are numerous new features in Linux 4.1, like Xbox One controller force feedback support, better Wacom tablet support, Intel Atom SoC performance improvements, Radeon DisplayPort MST support, EXT4 file-system encryption, ChromeOS Lightbar support, and ACPI for 64-bit ARM, among other additions. However, KDBUS wasn't accepted for Linux 4.1.

Comments

Wounded Not Dead

[Terry95]

The Linux ecosystem is already severely wounded, possibly mortally so, by systemd's attempted coup. The operating system loses most all practical advantages because of this malware - I will literally go so far as to say if I have to have Linux with systemd I don't want Linux. I might as well just run Windows. They are both black boxes of unknown function and unrepairable, not to mention unfindable, vulnerabilities. So why bother with the down sides of Linux if it has no up side?

At this point I am evaluating BSD vs Windows 10; BSD is winning. Hopefully Linus will never allow these evil monsters to commit their viruses to the kernel. That will be game over for Linux.

Re:Wounded Not Dead

[squiggleslash]

There's nothing stopping you from running Linux with SysV Init. You won't be able to use modern versions of GNOME (but who does?), and you won't be able use the major distros, but if that's what you want, by all means go for it. Linux (in terms of what we're talking about here - ie the thing called "Linux" that has a version number of 4.1) is only one component of the operating system, and doesn't have SystemD as part of it.

But bear in mind that SysV Init has been straining at the seams now for around two decades, probably more. When it was written it was rare for a Unix system to fail to boot for any reason other than a hardware fault or disk corruption. The notion a minor misconfiguration of a networking script could take down a machine was unthinkable back then.

Bear in mind SysV init was never upgraded to take into account changing usage. Take a look at /etc/inittab. Try and find a man page that still describes the format. Ask yourself why it exists. Ask yourself why, bearing in mind it does, inetd is a completely different, unrelated, system. Ask yourself why sshd exists and why those connections aren't managed by inetd or init.

Bear in mind that Linux the kernel has had some major security and process management systems now for over half a decade that SysV init is incapable of using - and always will be. That those security and process management systems, if used, significantly improve both the security and reliability of Linux based operating systems by making it easier to, amongst other things, truly sandbox processes in a way superior to BSD's jails feature. Ask yourself why we should be prevented from using them simply because the operating system's daemon management system doesn't support anything the AT&T kernels didn't support in 1983..

Bear in mind that SysV Init's faults are so obvious to people who actually build operating systems that SystemD isn't even the first try at this, that Upstart was considered "very nearly there" as a suitable replacement, and that the real debate was between SystemD and Upstart, not SystemD and SysV init.

Finally bear in mind that SystemD is a true superset of SysV Init in terms of functionality. This isn't the Wayland/Mir "Let's throw the baby out with the bathwater because there's too much spaghetti code" nonsense, there's nothing you can do with SysV Init that can't be done with SystemD. Except it's much, much, harder now to hose your configuration so badly that it's not going to come up because an NFS share wasn't available when you rebooted your computer.