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
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?
I hear that due to some KMS changes, AGP on SMP is currently broken.
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.
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.
Hopefully the open source community will review kdbus code very carefully and perform security testing before adopting this.
Pulseaudio-style bugs and instability could be very bad in the kernel.
It's possible that Michael Larabel didn't get his facts wrong this time, but he has a history of (a) sloppy reporting and (b) completely ignoring requests for making corrections. Considering the number of times his mistake was pointed out in this one case (https://twitter.com/phoronix/status/575005596501590016, http://www.phoronix.com/forums/showthread.php?115543-An-LGPL-Licensed-Larrabee-Inspired-GPGPU-Processor/page2), I think he does it on purpose just to fuck with people.
Because of serious design flaws introducing security, privacy and slow code issues. KDBUS is a good idea but badly implemented, sending a message is 5-10 lines of code. And you send thousands per second.
Custom electronics and digital signage for your business: www.evcircuits.com
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.
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.'"
Oh so you miss the days of manually setting sound card jumpers to set DMA and IRQ
What? I say, what, son? That shit went away with ISA, and it had nothing whatsoever to do with pulseaudio. Nothing. Pulseaudio did nothing to mitigate that because none of those issues went away if you still have that hardware, because pulseaudio does not handle that part of the audio system. Do you know anything about the software we are now discussing?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"