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.
Sure, many systemd-opponents harbour fantasies like that.
Many systemd proponents harbour fantasies of it being the one true way of doing......anything and want to wave away the problems.
This, by the way, is Linus's take on kdbus and why it won't be seen in the kernel for some time to come, if ever:
http://lkml.iu.edu//hypermail/...
Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.
This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers.
Regardless of any other bullshit and hearsay, that is the policy of the kernel. When he says 'Kay', read any systemd developer. Oh, and no, it's not a joke and no he doesn't write the e-mails on the kernel mailing list for the goodness of his health.
Many systemd proponents harbour fantasies of it being the one true way of doing......anything and want to wave away the problems.
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.
This, by the way, is Linus's take on kdbus and why it won't be seen in the kernel for some time to come, if ever:
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.
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.
The whole point I was trying to make that looking back on sound on Linux in the days before ALSA and PA shouldn't be done with rose tinted glasses. Claiming that, like the OP does, that everything went backwards with the invention of ALSA and later PA is just absurd. Those where the bad days regarding sound on Linux. There is nothing to miss from those days, including ISA sound cards.
With ALSA and later PA there were actually people working on the Linux soundstack and developers that could coordinate bug fixing. And PA was a huge help for DE developers that where so tired of trying to maintain their own sound servers and dealing with really low level kernel stuff like drivers, when all they wanted to do was to develop for the desktop.