Slashdot Mirror
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.
Say what you want, systemd already whack too much havoc for Linux and I do not wish to see yet another systemd brick inside the Linux Kernel
Well, don't forget while we're waiting, really important shit got added to the kernel.
After all, what good is a Linux distro without XBox One controller force feedback support.
On a desktop/laptop I would trade 1G of space any day of the week to have whatever random input things I plug in just work...
Come as you are, do what you must, be who you will.
KDBUS is just another IPC mechanism, and while it might need a little more work before going mainline, its not some evil systemd plot to take over the world. I think its time some of you put down the tin foil hat, take a deep breath, calm down and look at it as the IPC interface that it is.
DBUS is used by lots of none systemd projects as a user space IPC currently, moving it to the kernel will help with performance, and potentially security. If some of you stopping look at every thing systemd tinted glasses you might start reacting like rational adults.
The issue of systemd and the kernal needed to be down/up-graded in lock step will probably turn into an none issue on the server side. That kernel/systemd version will not just be introduced as an update to RHEL etc, it will be held back for a major version change. So any hardware regression issues will only hit when doing an OS re-install which is always a risk, the kernel/systemd lock step will make no difference here.
And since the systemd-opponents party line is is that binary log files are always bad, they won't make such an alternative.
I'm not even going to get into a pro/anti systemd argument becauser that's actually not relevant here, but this is why people get annoyed with the systemd folks, because of the mindless zealotry/ignorance. No offence, but solutions to this have existed for YEARS and have been implemeted in plenty of other systems.
You have a text based log file, which just works with everything. You also have a separate binary index which indexes the textual log file. You get the benefit of fast lookup if you use the index and it will just work no another machine if the original tanks and you don't have the right version of systemd on the new machine.
There are more than "text-only sysV style log files" and "opaque windows style binary ones". The systemd folks pretending that this dichotomy are the only options is just plain annoying.
SJW n. One who posts facts.