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

KDBus - another systemd brick on the wall

[Anonymous Coward]

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

... KDBUS is aimed to be a new kernel IPC mechanism inspired by D-Bus. KDBUS is being sought after by systemd ...

Re:KDBus - another systemd brick on the wall

[geekmux]

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

... KDBUS is aimed to be a new kernel IPC mechanism inspired by D-Bus. KDBUS is being sought after by systemd ...

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.

Re:KDBus - another systemd brick on the wall

[RalphSleigh]

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

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

because it regresses on a very import/expensive piece of software, perhaps? Not everyone runs a fucking desktop you know.

Re:KDBus - another systemd brick on the wall

[ledow]

Seasoned programmers that "know their stuff" that have been told to keep their un-maintained junk out of the kernel before now? And in no polite terms?

"Worked beautifully" resulting in many unbootable (or, worse, variably bootable) systems over the years. It's far from perfect (I'm not expecting perfect, but it's far from it).

Though I don't doubt that there are entire swathes of people happy with it, that there is so much opposition is not only indicative that it's far-from-perfect, but that many people may be avoiding using it altogether?

I'm by no means a stick-in-the-mud when it comes to new stuff but systemd still appears a backward step and even the DISCUSSION of systemd generating such heat is indicative of underlying problems that aren't being addressed (even if those problems are entirely political, which I doubt).

And I agree that there's little competition but things like upstart were in fact the middle-ground. Systemd has a huge headstart, but also keeps hitting political brick-walls in its race to be default and little is done to appease or even acknowledge the criticisms

"We know better" is not the basis of any argument for either side. But "We're never going to change either" is just head-banging nonsense. I don't think anyone is opposed to change on the SysVInit side (the very existence of upstart and a variety of other projects), they just don't think this is the right change. However, the systemd crowd are very much in the "We know best, so you need to get onboard" arena.

And when you're dealing with critical areas like even being able to boot a kernel, you need to dial back to the users and say "What do you need?", not "This is all you'll ever be given, deal with it"

Re:KDBus - another systemd brick on the wall

[serviscope_minor]

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.

Re:KDBus - another systemd brick on the wall

[ckatko]

>XBox One controller force feedback support.

You mean the de facto standard controller for PC gaming these days?

1) People complain about poor driver support in Linux every year. It's been getting better. This is an example.

2) Adding feedback to Xbox controllers is a minor change compared to adding an entire, new IPC interface for systemd.

3) Kernel changes are not a zero-sum game. Just because some kid in college wants his controller to work and submits a patch, doesn't mean Linus cries himself to sleep instead of doing his usual work.

4) Are you against making Linux a more robust gaming machine?

Re:KDBus - another systemd brick on the wall

[serviscope_minor]

Did you actually read my post which was about a very specific point about binary versus text versus INDEXED text log files and decide to post an irrelevant rant on complete nonsequiteurs, or did you decided to post the nonsequiteurs without reading my post.

You really are uniformed about systemd's journal; its structure and layout and API have been fully documented and is stable. That means you can read any journal with any systemd version.

Well if so, that's new. It never used to be the case that the binary format was stable. So, I'm going to ask you to provide a link to the description of the binary structure.

The current journal file format, which is basically an appended text file with index, is a great compromise between having unstructured, unindexed text logs with no meta-data, and running a full sql-server.

Jesus fucking H. Christ on a stick what is wrong with you? I specifically went into detail about how noisy the pro-systemd people like you insist on a dichotomy between unstructured text files and binary file formats. There is no fucking dichotomy you moron. If you actually read my sodding post instead of going off on a rant then you would actually become marginally more informed and stop spouting the same old shit repeatedly.

Please stop the Phoronix shouting!

[Anonymous Coward]

The original announcement from Linus says: No earth-shattering new features come to mind. Yet Phoronix and now also Slashdot are shouting: "numerous features!", and then listing a few things which will not matter for most users. Can we please not follow this Phoronix shouting mentality and stay a bit more realistic and neutral?

Poettering thinks he's the next Linus

[Viol8]

Saidly too many people are believing this delusion. I can't help thinking thats one reason why systemd is taking over - its not that its any good , its who wrote it. Which is mystifying given what a POS PulseAudio was/is.

Oh grow up

[Anonymous Coward]

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.

Re:Oh grow up

[Anonymous Coward]

Nice try lennart. system and kdbus have prven again and again that they are NOT ready for real world use. systemd has dozens of zero day remote root exploits and kdbus is sure to expose many more.