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

[Anonymous Coward]

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

How much longer can non-systemd hold out (with gnome/kde swallowing it ...)? how long until it is wrapped in that behemoth that is PID1.
It isn't the UNIX way... its the windows way with svchost.exe & binary logs... and we all know how well that works.
Not only that but Systemd has shown to be hostile to that which it has assimilated...

https://lkml.org/lkml/2015/4/15/104

> To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side.

Thats plenty clear, isnt it? As soond as kdbus is merged into kernel,
systemd will depend on it, and then if I need to go back to older kernel,
I have to downgrade systemd as well?

http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdAndSyslog
Anyone who works with systemd soon comes to realize that systemd just doesn't like syslog very much. In fact systemd is so unhappy with syslog that it invented its own logging mechanism (in the form of journald). This is not news. What people who don't have to look deeply into the situation often don't realize is that systemd's dislike is sufficiently deep that systemd just doesn't interact very well with syslog.

I won't say that bugs and glitches 'abound', because I've only run into two issues so far (although both issues are relatively severe). One was that systemd mis-filed kernel messages under the syslog 'user' facility instead of the 'kernel' one; this bug made it past testing and into RHEL 7 / CentOS 7. The other is that sometimes on boot, randomly, systemd will barf up a significant chunk of old journal messages (sometimes very old) and re-send them to syslog. If you don't scroll back far enough while watching syslog logs, this can lead you to believe that something really bad and weird has happened.

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

[ledow]

Systemd is one of those thing that people know will end in disaster. Sure, it works at the moment. But a personality will jump into it, or a bug will catch up with their design, or something else. And it will all come crashing down.

What bugs me about systemd is not the idea behind systemd. It's the implementation. Using cgroups and other kernel-provided features, it's able to provide functionality that we don't have elsewhere. But rather than break-down that functionality and make each part replaceable, and use "old" methods to do some things while they are replaced with "new" methods.

It's the all-or-nothing nature of systemd that I hate. There's no reason it can't be done in some other way. There's no reason that, even at a base level, you can't write scripts that do the same as it does - for all functions, but also for parts of the functions. As such, it's not modular, not changeable, it's just a lump of code that you accept having complete control of your machine or not. And I don't.

Honestly, I'm waiting for the crash-and-burn moment at which someone steps up, gives us the same features, using predictable, modular code or even scripts, and we can put in the bits we like and leave out the bits we don't like and replace any bit and NOBODY will know or care that we've done that.

Re:KDBus - another systemd brick on the wall

[oobayly]

I know, it's almost like you'd want a distro to have different versions to suit server vs desktop usage.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

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.

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

[drinkypoo]

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.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

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

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.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

But the brutal and inescapable fact is that systemd is coded and designed by top notch, seasoned Linux programmers that really knows their stuff well, and that systemd also work really well and solves so many old problems.

Since you resorted to an ad hominem argument, I'll follow this up. The initiator of systemd is Lennart Poettering, who was also responsible for the pulseaudio and avahi projects. I discovered pulseaudio when Ubuntu implemented it ~7 years ago, and my audio randomly started breaking. A release or two later (6+ months) it was fixed, and audio worked the same as it had before, except that I've noticed pulseaudio occasionally using a few percent of my CPU. Avahi is apparently a service that allows me to make printers connected to my computer available to other computers on the network, which I've never used - but I've still noticed it occasionally at the top of "top" in CPU usage. I'm using a laptop: when a process advertising non-existent printers is sometimes the number one drain on my battery, that's a problem.

So the head programmer of systemd has previously been responsible for projects that did nothing of any benefit to me, caused occasional instability and breakage, and consumed resources unnecessarily. That doesn't tell me that he's a "top notch, seasoned Linux programmer". It tells me that he's a poor architect, probably an indifferent programmer - but very, very good at politicking to get projects incorporated into distros when they shouldn't be. Why should I think that systemd is any different?

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?

Re:Please stop the Phoronix shouting!

[discord5]

Yet Phoronix and now also Slashdot are shouting: "numerous features!

Just wait until they benchmark that xbox controller force feedback. They'll have useful graphs such as "Bootup time with and without xbox controller (lower is better)", "Strenght of feedback on odd and even numbered seconds (higher is better)", and the ever so important "Adbucks generated by pointless benchmarks on an xbox conroller (higher is better)".

Hell, I can't wait to see the graphs on that last one.

AGP not working with SMP

[jones_supa]

I hear that due to some KMS changes, AGP on SMP is currently broken.

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:Why?

[bouldin]

Hopefully the open source community will review kdbus code very carefully and perform security testing before adopting this.

They will. Sure there will be lots of sparing and harsh word duels, and not everybody will be happy, but that is how the process works for any major kernel feature. In the end the process tend to produce good enough results.

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:

• Kdbus code is nowhere near ready for a merge, it hasn't been reviewed, and in fact may need major reworking before it can be used or reviewed.
• Kdbus authors are pushing the merge very aggressively, and have made a habit of ignoring criticism and refusing to take steps necessary to even make the code reviewable.

This post was from last week.

Having used Linux audio from before PA came into existence, and having used PA from the beginning, I can assure that PA was a major step forward in fixing Linux audio. With PA sound on Linux actually began to work. Sure it exposed a lot of kernel bugs (drivers) and ALSA bugs in the beginning, and some distros and software got the implementation wrong, but it lead to the first coordinated bug fixing effort between drivers, ALSA and user space. PA was always rock solid for me, and while it had some bugs, but far the most serious and numerous was in the drivers and in ALSA layer.

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.

Re:Why?

[drinkypoo]

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.