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.
I hear that due to some KMS changes, AGP on SMP is currently broken.
Which is good. Systemd has already stated they will hard depend on it and equally a systemd bump will require a bump of the kernel.
For those that are on systemd then finding themselves in a situation where an upgrade/downgrade of either the kernel or systemd (oh I don't know... due to a issue) renders the system unbootable is worrying...
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.
A previous poster linked to a post by Eric Biederman that should be required reading for this Slashdot thread. I'm not sure which part to quote, because the whole thing is pretty damning: Kdbus needs meaningful review
On one hand, the post (and lack of kdbus in kernel 4.1) seem to indicate that you are correct, and the process is working. OTOH, Eric argues that:
This post was from last week.
Yeah, I don't know. I've been using Linux for 20 years, and of course it's steadily become much more usable. My experience with PA was that it implemented some very useful features, but was not rock solid.
When I tried to configure PA to use a sample rate over 100KHz last year, it consistently brought down the entire system. This was on a very capable machine, and high sample rates should be a basic use case for PA. I didn't dig into the cause, but it was PA itself that thrashed the CPU, so it seems unlikely that particular defect was caused by the layers underneath.
Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design,
We have seen this proven true with pulseaudio.
that the systemd design is bad and that the code is bad,
Which should surprise nobody
it puzzles them that despite all this, systemd have worked beautifully for so many years.
Which it hasn't, and many slashdotters have given examples in this and other systemd-related threads, which you have willfully ignored because they don't fit the narrative you swallowed.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Please note that PA is for consumer audio, that means general purpose desktop and sound server use.
You know what's different about consumer and pro audio? Nothing. As it turns out, consumers also want high-fidelity audio, and they want to be able to mix multiple streams. The only difference lies in what the industry is willing to sell us.
It works great for that and doesn't drain batteries and so on.
Actually, pulseaudio has notably drained batteries in the past, because shitcode.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"Working" is not a very high bar to meet when you're talking about something as simple as an init system. init systems are not at all hard to write. They start programs according to rules and restart them if they quit or crash. Read a config file, fork() off your children, then use waitpid()/waitid() with W_NOHANG in a loop to handle terminations. The sysvinit code used by all Linux distros until SystemD reared its ugly head had been floating around has been effectively without a maintainer for probably decades. And that was fine because the code was so damn simple any competent coder could clone it in his sleep if necessary.
So SystemD's cloning sysvinit is not particularly impressive. Dumping everything and the kitchen sink into the same source tree is also not particularly impressive. Not supporting any OSes other than Linux because it would cramp their brogrammer style is another thing that makes them look bad.
I don't know if SystemD will ultimately crash and burn. I can't predict the future. But, if these clowns keep going as they are, good chance.