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

[Anonymous Coward]

My lib/modules/4.0XX folder went down from 1G+ to about 136MB after I decided fuck it and remove ALL the joystick, touchpad, bluetooth, controller (PS2 etc) drivers.

Granted, there were some other things in there too, probably some debug function that added mass of code. But it's not like this is a new situation.

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

[Anonymous Coward]

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.

Something really bad and weird did happen, systemd was installed. That's just one of many alerts your system is sending to inform you of that problem.

Re:KDBus - another systemd brick on the wall

[kthreadd]

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?

Why do you downgrade your kernel?

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

[kthreadd]

Most users will run the combination of kernel and systemd which their GNU/Linux distribution ships. If your application does not work with that kernel then why don't you run an older distribution until the problem has been fixed? At the least running a newer kernel should be your goto solution before downgrading to an unsupported version.

Re: KDBus - another systemd brick on the wall

[Anonymous Coward]

Tell that to your computing security group and see how they react, dumbass.

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

[kthreadd]

I'm sure they'll agree that running a newer kernel that solves the problem temporarily until the distro has backported the fix is a better idea than running an ancient kernel which lacks the proper capabilities to support the userland.

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

[fuzzyfuzzyfungus]

This wouldn't be the kernel's problem; but it might be kind of neat to make the package manager aware of the hotplug process; in order to allow largely automated hunting of the repositories for the appropriate modules for a newly inserted device; but the amount of space saved may just not be enough to be worth the trouble. It'd arguably be more elegant than preloading more or less everything, or having the user grovel around with VID/PID combinations looking for helpful advice on Google; but storage tends to be cheaper than any human labor you'd want touching important software...

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

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.

Sure, many systemd-opponents harbour fantasies like that. Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design, that the systemd design is bad and that the code is bad, it puzzles them that despite all this, systemd have worked beautifully for so many years.

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.

It is one of the hilarious facts that the solely negative campaign the systemd-opponents have waged against systemd, belittling it and its developers, that this has also prevented that any competitive alternative could be developed. By being unable to make a cool assessment of systemd, recognizing its many strong points, you can't even begin to formulate an alternative strategy that can convince technical minded people outside the very small circle of systemd-opponents.

Re:KDBus - another systemd brick on the wall

[segedunum]

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.

Re:KDBus - another systemd brick on the wall

[segedunum]

Ahhhh, yes, it's out of context. Where do I keep hearing that one?

Re:KDBus - another systemd brick on the wall

[Qzukk]

may just not be enough to be worth the trouble

Can you do it faster than on windows, where I plug a usb printer in and it spins for minutes searching windows update for a driver? I don't know how long it actually takes, since when I did this last week, it took me less time as a human to go to google, search for the printer, download the driver, cancel windows update and install the driver by hand.

Re: KDBus - another systemd brick on the wall

[Anonymous Coward]

Hahaha. Thanks for the joke.

Re:KDBus - another systemd brick on the wall

[jbolden]

Or even better to have desktop / workstation distributions that are tweaked that for that use. So for example mainly support server applications in developer modes rather than being tweaked for large numbers of users, or have much the ability to shift security levels up and down easily to see if what security feature is introducing a bug in interprocess communications. Caldera, Mandrake, Corel Linux / Xandros...

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

136MB? That's a lot. Only 11MB here.

$ du -s -h /lib/modules/4.0.0+/
11M /lib/modules/4.0.0+/

Re:KDBus - another systemd brick on the wall

[jbolden]

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

Actually there is. Systemd does lots of things that run at very low levels and thus performance matters. Processes that run multiple times per second aren't scripted in Unix. Unix has always accepted that you use a high level scripting language to tie together low level binary function, not that you script the whole system. What you are asking for is a design like what you see in LISP machines where the scripting languages are designed to degrade into very fast code so that it is safe to script almost the entire OS. Readying your criticism of systemd it would apply equally well to the kernel or to many of the standard libraries on Linux.

The kind of operating system you really want doesn't exist anymore on hardware What you really want is a LISP machine. Quite literally the essential binary part of the operating system was a few hundred assembly language functions and everything else scripted. I think where you do see this is in cloud computing. Many of the web based systems and IaaS manipulations are scriptable easily changeable and modular.

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.

Systemd itself allows for that, but not system admins. It is modular for developers. So what you would need is say 6-15 guys who change systemd over into a meta process management system with a scriptable configuration system. The question is whether you would use such a thing? And I don't think most of the system admins who object to systemd would. Where I do see potential users is in the embedded space as systemd makes it way into complex embedded systems. Once it is developed for embedded Linux though, it could be used by other distributions. I'd guess you are talking the years 2025-35 is when that becomes available in a mainstream way.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

Stop using XP. It's much faster now.

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

[jbolden]

Wow wish I could mod you up. Your last paragraph is spot on.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

It isn't the UNIX way... its the windows way with svchost.exe & binary logs... and we all know how well that works.

Wow, so you mean it will be the worlds most popular operating system with 90% market share? I suppose things could be worse!

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

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?

Kay Sievers _is_ a seasoned programmer. He maintained udev alone for many, many years. What he and Linus disagreed upon was whether you should fix broken kernel features or not. Kay thought you should, Linus disagreed. Rather typical LKML discussion in my opinion, but blown out in all proportions by the systemd-haters because they wrongly think that Linus don't like systemd nor its programmers because of this.

"Worked beautifully" resulting in many unbootable (or, worse, variably bootable) systems over the years.

Pure rubbish. Sure Sysadmins running with broken fstabs was caught by surprise (who really reads the release notes or study a major piece of new software like systemd before upgrading the servers).

That systemd refuses to boot with disk setups that doesn't work, is because it does right thing to avoid raid array wipe-outs and silent data loss, and because it respect how the sysadmin have configured the system. SysVinit just ignored what fstab told it and bumbled along with the boot.

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.

I think the systemd-opponents are deeply split about this; the BSD-Linux users want OpenRC because that is close to BSD and hates systemd because it means work for BSD, the traditionalists want SysVinit forever "because it isn't broken and systemd doesn't provide new features...". Nobody wants Upstart.

Almost nobody is working on an init-system that basically isn't a SysVinit variant. Considering how small a minority the systemd-opponents are, then any sub-set of this group is positively tiny.

It is worth pointing out again, that the negative campaign against systemd, also have stifled any development of any meaningful competition; if systemd is overall bad in every aspect, why even bother developing an alternative? It is so much easier to take refuge in paranoid conspiracy fantasies on how systemd won over every major Linux distro, by dark cabals working behind the scene.

Re:KDBus - another systemd brick on the wall

[Blaskowicz]

I loved Windows Server 2003 Enterprise Edition, it was a perfect OS for running games. DirectX 9, sound, joystick input (I had to extract the .inf file for the Xbox 360 controller and feed it to device manager), even wifi and the semi-poor support to run DOS games.
It was a slightly improved version of Windows XP with graphical effects turned off and ctrl-alt-del as the log in.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

When he says 'Kay', read any systemd developer.

Why? He did not say any systemd developer. This is just setting up a strawman.

Re:KDBus - another systemd brick on the wall

[Blaskowicz]

A desktop distros even starts lots of crap such as cups, samba etc. just in case you need it. (even avahi daemon which you perhaps never need)

I went to some lengthes to disable avahi daemon, but the rest is useful. A quite illiterate user had success sharing a folder on the network by right-clicking on it (which was that easy in Windows 95, but grew more complex over time). That's a pretty big success for a linux desktop, and the user did it to watch video on a set top box and it worked. I was impressed to see that.

Re:KDBus - another systemd brick on the wall

[G-forze]

storage tends to be cheaper than any human labor you'd want touching important software...

Especially when it is other peoples' storage.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

> Using cgroups and other kernel-provided features, it's able to provide functionality that we don't have elsewhere. [...] 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

No reason at all... except nobody aside from the systemd people has managed to actually do it.

It's like complaining that someone used cement to build a skyscraper and saying "there's no reason it couldn't be done with wood". Yeah, in theory there is no reason why it couldn't. In theory, you could do everything systemd could do with shell scripts. In practice though, nobody has. Wonder why that is...

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

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.

Re:KDBus - another systemd brick on the wall

[Khyber]

"What he and Linus disagreed upon was whether you should fix broken kernel features or not. Kay thought you should, Linus disagreed."

And it's exactly because of this that I can hardlock just about any Linux machine with five simple steps, and I'm not even a serious hacker. I don't even need admin priv to do it.

Linus is too fucking incompetent for his own good.

Re: KDBus - another systemd brick on the wall

[Khyber]

" If your application does not work with that kernel then why don't you run an older distribution until the problem has been fixed?"

Yep, you'd be waiting YEARS AND YEARS to get any fucking thing fixed on Linux.

Re:KDBus - another systemd brick on the wall

[tobiasly]

Can you do it faster than on windows, where I plug a usb printer in and it spins for minutes searching windows update for a driver?

The best part is when you then plug the device into a different USB port and it goes through the whole minutes-long process again.

Re:KDBus - another systemd brick on the wall

[segedunum]

What he and Linus disagreed upon was whether you should fix broken kernel features or not. Kay thought you should, Linus disagreed.

I don't know whether you're being this fucking stupid on purpose, but this shit needs shooting down and it currently is on the Linux kernel developer's mailing list. Existing and expected behaviour from the kernel does not get altered. EVER. Userspace does not get something different. That was made abundantly clear.

Who the fuck are you or Kay Sievers to tell kernel developers what flags they will now suddenly pass as debug that have been used forever? I'm afraid this attitude problem is going to get shot down in a very public way, as it is currently doing, by the kernel developers.

Re:KDBus - another systemd brick on the wall

[segedunum]

Rather typical LKML discussion in my opinion, but blown out in all proportions by the systemd-haters because they wrongly think that Linus don't like systemd nor its programmers because of this.

No it wasn't. Linus made his views on when this stuff will get merged, if ever, abundantly clear. It's not blown out of all proportion. That's what was written.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

So: no Kraft Dinner for you!

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

[Ol Olsoc]

Sure, many systemd-opponents harbour fantasies like that. Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design, that the systemd design is bad and that the code is bad, it puzzles them that despite all this, systemd have worked beautifully for so many years.

You missed one. "Anyone who stands up for systemd doesn't know anything bout Linux. Because if they knew anything about Linux, they would hate systemd." Its a rinse and repeat situation.

But as you've noted, many have graduated to the systemdpocalypse mode, of saying "Just you wait! You'll see! You'll see!" mode.

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

[ckatko]

DO NOT try Server 2012. It's pathetic for a typical user--Metro interface aside.

WiFi is disabled by default. Sleep/hibernation is disabled and cannot be re-enabled (so much for taking demo laptops to clients! Thanks, Microsoft for making my job easier!).

And I just learned this today, apparently many free versions of software will refuse to install unless you buy them because they use the OS ID to tell whether you're a business or consumer. Businesses have to pay.

Re:KDBus - another systemd brick on the wall

[squiggleslash]

SystemD doesn't in any way resemble the "Windows way", stop being ridiculous.

As for the kernel and SystemD being linked, I don't see a problem as long as the distro makers recognize that and bundle the two together. Kernels are always installed with a group of support files that they hard depend upon, notably the modules. As long as multiple versions of the kernel-dependent SystemD can be installed, and grub is set up properly to ensure each kernel points at the right version, there shouldn't be an issue.

If there ever is, it means a problem with that distro.

Re:KDBus - another systemd brick on the wall

[squiggleslash]

Maybe you're hearing it a lot because you're participating in a group that keeps quoting stuff out of context in order to try to make something look bad. I'm not trying to be mean, but that's a good sign that you're arguing not in good faith, but because of gut feel about something. If SystemD was bad, you wouldn't need the out-of-context stuff, as it'd be easy to point at things that exist, and say "Look, here, that's a problem."

Re:KDBus - another systemd brick on the wall

[Lumpy]

I love those free coffee breaks that windows give me!

Re:KDBus - another systemd brick on the wall

[Blaskowicz]

Yes, most noticeably antivirus software.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

Windows users cannot complain about anything.

Re:KDBus - another systemd brick on the wall

[drinkypoo]

Stop using XP. It's much faster now.

Bullshit. It's much, much slower now, not least because the subset of printer drivers included is pathetic. What's pathetic about the list of supported printers that extremely common printers supported with precisely the same drivers that they have already shipped plus just a different PPD are not included. But it also takes much longer to hit windows update and find your printer driver than it did on XP.

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

[sjames]

Actually, it's quite common in the world of machines that might be vaguely important to something to keep the old kernel around when doing an upgrade. That way if some subtle bug shows up weeks later, you have an immediate path to recovery. That is, the ability to get back to a known good kernel.

Jumping forward doesn't do that for you, since the newer kernel will also be untested and probably contains the same bug introduced in the version you had a problem with.

Nobody who values stability in a server wants a monolithic glueball.

Re:KDBus - another systemd brick on the wall

[drinkypoo]

SystemD doesn't in any way resemble the "Windows way", stop being ridiculous.

Yes, it absolutely does. It ties functionality together in a way which is designed to be difficult to tease apart specifically because of NIH.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

Every thing I hear about SystemD, the words are mixed into this song in my head.
Blob

Re:KDBus - another systemd brick on the wall

[Eunuchswear]

I think the systemd-opponents are deeply split about this; the BSD-Linux users want OpenRC because that is close to BSD and hates systemd because it means work for BSD, the traditionalists want SysVinit forever "because it isn't broken and systemd doesn't provide new features...". Nobody wants Upstart.

That wasn't exactly what happened in the Devian CTTE vote though, was it? 4 people wanted systemd, or upstart or even openrc rather than sysvinit. 3 people wanted upstart, or systemd, or openrc rather than sysvinit and one person wanted sysvinit, or anything but systemd.

Oddly the only person who wanted sysvinit was Ian, who up till then everyone had seen as a pro-upstart Canonical mole.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

"When he says 'Kay', read any systemd developer. "

If he meant all systemd developers he would have written that. Perhaps you think Linus doesn't know what he is saying, or lacks the ability to be accurate in what he writes?

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

A funny thing happens when you keep quoting things out of context in a public forum. You tend to hear people telling you you are quoting out of context quite often. :-)

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

[Peter H.S.]

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.

Really, please show me a non-systemd Linux distro that doesn't use scripts for setting up daemons and boot, thereby mixing code and config statements in one unstructured code lump that are hard to parse for both humans and machines. And does it provides high level API abstractions for cgroups and kernel capabilities so SA's can use them for all daemons just by adding a simple key/value line in a text config file?

I am well aware that SysVinit and endless variations like it such as OpenRC exist. But they don't provide any meaningful competition to the many features that systemd provides. You may be happy with SysVinit and its many limitations, but I and so many others aren't.

If you don't recognize how superior systemd is to existing alternatives, you also say that no new development is necessary for the non-systemd distros in order to stay competitive. I would like to see some real competition to systemd, but it doesn't happen, seemingly because the systemd-opponents have dug into their own grave claiming that everything existing is good enough and systemd is just bad. Shrug.

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.

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. At worst you may miss out certain extra meta-information fields that have been added later, but nothing essential will be missed (and it will be information that any text based syslog implementation won't have anyway).

The systemd journal is designed to be read on other machines, and it does it exceedingly well, like reading from nspawn OS containers, etc.

Plain text log files have been a problem for Linux for decades, and many projects, including Rsyslog was started exactly to overcome the many limitations with both the syslog interface and the plain text log files.
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.

If the non-systemd distros have a better idea, then great, let them implement it, but I fear the usual answer will be that text logs are the final word in logging, and that no new development is needed.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

Practically nobody was using Upstart on Debian at that time according to popcon. That the Upstart maintainer voted for his own project was natural, but among the rank and file DD's the support for systemd was strong, while the fact that there was a Upstart CLA made it unacceptable for many others. I think it was only Debian's affinity with Canonical that even made it an alternative at all.

I think Ian simply cooked off in some major rage fit. He wasn't entirely rational about this issue after that.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

i think you are misreading it. No-one is denying Kay was wrong. Kay made a mistake in HIS interpretation of what should happen, he was shouted at and put back in his box. He was not the first in the whole development of the kernel that has had a strip torn off him for doing something wrong. If Kay didn;t learn the lesson, they you may have a case so unless you can point to other mistakes by Kay on the list, you are winding yourself up for nothing.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

it is blown out of all proportion because Linus shouts at everyone, not just Kay Severs. If we follow your interpretation of being moaned at for one mistake then nothing would get into the kernel.

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

[fuzzyfuzzyfungus]

I'm no expert; but my off-the-cuff assumption would be that it could be made quite fast:

At least with Debian and derivatives, you have a locally stored cache of package data(not the packages themselves, but their metadata). Searching that is pretty fast unless you have a lot of repositories or a brutally slow storage system.

The obvious(and probably flawed in some less obvious way that I'm not thinking through) extension would be to add the VID/PID combinations (or device classes, for class drivers) to which a driver package applies to the existing metadata about the package. You might also have a 'driver package vs. 'non-driver package' distinction to reduce the search space). During the hotplug process, if nothing suitable is already available, apt-cache search for the VID/PID pair would be run, and a match downloaded, if available(the amount of security prompting would obviously be a matter of configuration: sometimes it would be desireable that admin authorization always be required, sometimes it would be better if downloads from already-blessed repositories are acceptable, depends on the use case).

The local search would be reasonably fast, barring very slow storage, the download and install obviously depending on the size of the driver and the speed of the connection. In the not-terribly-valuable opinion of a layman, it seems like it could be reasonably quick.

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?

Re:KDBus - another systemd brick on the wall

[fuzzyfuzzyfungus]

Very true; though (on the whole) the end user has made the same choice when they'd either have to buy more hardware or spend more for software and/or make do with fewer features.

Even situations that are highly cost sensitive and have customers who bear the entire cost of the extra hardware or the extra software engineering (like embedded systems) have seen a fair amount of hardware growth. Cortex-M0 or a bunch of extra squeezing to get it into an 8 or 16 bit micro?

Re:KDBus - another systemd brick on the wall

[jones_supa]

The best part is when you then plug the device into a different USB port and it goes through the whole minutes-long process again.

While I am a Windows man these days, I often belly laugh when that happens. Why the heck does it do that? It happens even with simple memory sticks if they are inserted into an USB port in which they have not been before.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

Did you actually read my post which was about a very specific point about binary versus text versus INDEXED text log files

systemd's journal is a basically a textfile that uses another line delimiter and have an index. Try "strings" on it, or a hex editor.

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.

Here is is the systemd interface and portability chart. Notice sd_journal and the journal file format:
http://www.freedesktop.org/wik...

Here is the file format;
http://www.freedesktop.org/wik...

There are loads of other developer information about accessing the journal with Python language bindings etc.

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.

Well, you are not the first person to think about how to extend text logs with some kind of index, and it would be nice if it could have microprecision timestamps, and monotonic timestamps like the journal does. The problem is that is unworkable.

As I said, several projects have tried to fix this without any luck for the last couple of decades.
Another problem with such a solution is that standard Linux text tools like grep, tee, sort etc. won't work with such a solution where the index isn't part of the text file, and metadata like microsecond time stamps tend to make the log lines unreadable long.

With systemd's journal all standard text tools work with the index and metadata, so you can grep monotonic timestamps by a simple pipe.

If it was possible to have indexed, and structured plain text log files that didn't require a special "translator" in order for the standard Linux text tools to work, it would have been implemented a decade ago.

Re:KDBus - another systemd brick on the wall

[Barsteward]

"caused occasional instability and breakage, and consumed resources unnecessarily", Virtually every program written has done that due to some bug or other so that comment of yours makes the rest of your post baseless and not worth replying to.

Re:KDBus - another systemd brick on the wall

[Barsteward]

so test it first and if it doesn;t work, don't upgrade

Re:KDBus - another systemd brick on the wall

[Barsteward]

unfortunately with the posters who hate systemd, only seem to have vague ideas of why they hate it because the hate is usually based on misinformation

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

"After all, what good is a Linux distro without XBox One controller force feedback support."

Well... the ONLY real thing Windows right now is better to is gaming, so if we want the complete world domination (which we btw. already got thru Android) we need to improve gaming support on Linux.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

> If it was possible to have indexed, and structured plain text log files that didn't require a special "translator" in order for the standard Linux text tools to work, it would have been implemented a decade ago.

Or, you know, pretty much noone really cares about having indexed and structured log files. Separating into log files based on hostname and application name has worked really well for me for ages. And, because you're still going to have a human write the log messages, you're still going to have to eyeball the output at some point.

Re:KDBus - another systemd brick on the wall

[theburp]

I've written an init that started daemons and programs without shell scripts. It also started in parallel and handled dependencies. No scripts, just around 700 lines of Lua and a single config file. Could boot to login prompt in 4 seconds on an 800MHz i.MX53. This **** isn't rocket science.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

Rather typical LKML discussion in my opinion, but blown out in all proportions by the systemd-haters because they wrongly think that Linus don't like systemd nor its programmers because of this.

No it wasn't. Linus made his views on when this stuff will get merged, if ever, abundantly clear. It's not blown out of all proportion. That's what was written.

You don't seem to have experienced many LKML flame fests before, so I think you will be sadly disappointed when Linus merges kdbus.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

Sure it is possible and has been done before. My point is that no distros seem to use such a init-system and that no other init-system have anywhere near all the nice features that systemd has.

Re:KDBus - another systemd brick on the wall

[reikae]

I'm curious about this. What are those five steps?

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

My theory:

- Checking Windows Update for drivers (if you disable this it typically goes faster)
- Verifying signatures of existing drivers when they are checked to see if it matches the hardware (64-bit windows require signed drivers)

Re:KDBus - another systemd brick on the wall

[Drumhellar]

Windows tracks USB devices by serial number, so you can have settings for a specific device persist. However, device serial numbers are an optional part of the USB spec, and in the absence of serial numbers, it tracks devices by connection. This allows you to have multiple identical devices with different configuration settings. If it didn't track devices without serial numbers by connection, it would create issues when, say, the devices aren't plugged in in the same order, and the wrong settings get applied to the wrong device, or when the computer boots, the devices aren't necessarily enumerated in the same order each time, so the wrong settings would be applied to the wrong devices. So, when you plug in a device that has been plugged into other ports, and Windows treats it as a new device, it is because it lacks a serial number. It is less than ideal, but the alternatives are worse.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

Or, you know, pretty much noone really cares about having indexed and structured log files. Separating into log files based on hostname and application name has worked really well for me for ages. And, because you're still going to have a human write the log messages, you're still going to have to eyeball the output at some point.

Great that syslog works for your usercase. I doesn't for me and so many others. There is an entire industry build around the need to beat syslog files into some sort of structure and give them an index so you can do number crunching on them.

These days log files grows so fast and is so important for business decisions that only machine parsing can do the job properly. The journal is excellent in that regard too.

Another problem with text log files are their limited ability to incorporate much meta-data, since that makes the log lines unreadably long. So having full microsecond precision and monotonic timestamps is a problem.

Yes, at some point a Mark I eyeball is going to look at a tiny subset of the data, but these isn't a problem either with systemd's journal; all the usual standard Linux text tools work through piping. And there are language bindings up the yazoo so you can manipulate it the journal files directly with Python scripts etc. It is so easy to extract the data that you need.

Personally I find syslog text files pretty hostile to newbies; unless they grep well and know a variation or two of regex, they are bound to just plow through the logs trying to identify some error. Really, many of them even resort to editors for reading log files. And the DE developers can't make a distro agnostic GUI log viewer better than "less" because there is no stable text log API. With systemd's journal they can because it has a stable API and language bindings etc.

With journalctl it is so easy to make even powerful extractions like; just show me logfiles generated the last 5 minutes (journalctl --since -5m) or all errors with syslog level "warning" and above created since this boot (journalctl -b -p warning). There is tab completion of every command option and every journal field and ususally even of the values of those fields. No need to memorise obscure arguments and subsystem names.

Re:KDBus - another systemd brick on the wall

[Khyber]

Make swapfile
encrypt swap
put swap in as loop
Memory overflow
hardlock, the end.

And it's been sitting there for at LEAST a decade. Still hasn't been fixed despite many others like myself making note of it and submitting reports.

Someone else even wrote a nice little blurb about it - http://spiralofhope.com/how-to... Though that one uses a slightly different method (but similar to mine.)

Re: KDBus - another systemd brick on the wall

[Anonymous Coward]

Anyone who values stability should test things before upgrading, or at least use a modern deployment system where it's trivial to roll back the server to a working state. Tools like Puppet solved this problem years ago. Very few problems only depends on your kernel. It's not uncommon for example for new kernel features to require userland components that is not installed because some admin thought that "it's a server - let's install as little as possible."

Re:KDBus - another systemd brick on the wall

[geekmux]

"After all, what good is a Linux distro without XBox One controller force feedback support."

Well... the ONLY real thing Windows right now is better to is gaming, so if we want the complete world domination (which we btw. already got thru Android) we need to improve gaming support on Linux.

Yes, that's it! Gaming!

That must be the reason I don't see Linux taking over the corporate desktop...you know, 'cause of all that native 3D graphic support you need to render Excel spreadsheets..

Re:KDBus - another systemd brick on the wall

[squiggleslash]

Yes, it absolutely does. It ties functionality together in a way which is designed to be difficult to tease apart specifically because of NIH.

That's not a helpful reply. SystemD does not resemble "The Windows way". It's a long time coming fix to something that's been considered creaky and crappy now for about 20 years. It integrates things that shouldn't have been separate in the first place. Is it really the "Unix way" for instance to handle login shell sessions only if they come in via serial ports or the framebuffer/USB keyboard, but not via TCP sockets?

It's tying functionality together because it's the same functionality, and it shouldn't be replicated in three different places, managed by eleven different daemons, with 871 different security models.

Windows way? No. It doesn't resemble Windows even slightly.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

And it's exactly because of this that I can hardlock just about any Linux machine with five simple steps, and I'm not even a serious hacker. I don't even need admin priv to do it.

lemme guess, fork bomb which any properly configured system easily defeats and which works on any posixy system?

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

> These days log files grows so fast and is so important for business decisions that only machine parsing can do the job properly. ... Another problem with text log files are their limited ability to incorporate much meta-data, since that makes the log lines unreadably long. So having full microsecond precision and monotonic timestamps is a problem.

*sings* One of these things is not like the other. One of these things just does not belong. */sings*

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

Gentoo uses OpenRC. On my desktop, Grub2->KDM login screen time with OpenRC is half that of Grub2->Whatever_Login_Manager_Kubuntu_15.04_uses with systemd.

The trick is to turn on rc_parallel.

Again, I'm just not seeing the big win of systemd over OpenRC. :) OpenRC can contain managed processes in cgroups and insure that they are all killed when the service is stopped. It does correct parallel startup. It comes with a large library of pre-canned functions that mean that in many cases you just have to specify your service's deps to have a working init script.

I mean, I guess OpenRC doesn't have a built-in HTTP server and QR-code generator. So, there's that...

Re: KDBus - another systemd brick on the wall

[sjames]

Sure, testing is important. But if you believe that your testing will catch 100% of subtle bugs, you are delusional. That's why the ability to roll back fast is a good thing. Tools like Puppet work better if you can get the server to boot and not all subtle bugs leave the server in that state.

Special snowflake software that throws a tantrum if some other component version is even one sub minor version different is not wanted here.

Re:KDBus - another systemd brick on the wall

[richcoder]

...After all, what good is a Linux distro without XBox One controller force feedback support.

That's just salty logic. Should the person working on controller support be blocked by someone adding KDBUS?

Re: KDBus - another systemd brick on the wall

[Anonymous Coward]

What I don't get is why keeping the kernel is so important. If it breaks then roll back the entire userland too. We have snapshots. There are so many things that can go wrong when you're running a modern Linux distro on top of a three year old kernel.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

"There is an entire industry build around the need to beat syslog files into some sort of structure and give them an index so you can do number crunching on them."

Yes, and most of that existing industry will have to rewrite everything from scratch without file format compatibility.

Also, systemd doesn't magically structure log files. It only structures the least interesting parts. What most syslog processing do is parse the log data itself, which is highly application specific, and which is completely opaque to systemd just as it is to syslog.

"Another problem with text log files are their limited ability to incorporate much meta-data, since that makes the log lines unreadably long. So having full microsecond precision and monotonic timestamps is a problem."

Really? Here's the microsecond monotonic timestamp on my current box: 242841.31760194. That's 15 bytes. A 64-bit binary timestamp is 16 bytes. The text version is shorter! And given that the vast majority of usages do not require microsecond resolution (which isn't even really accurate, anyhow), the text approach would lead to substantially _smaller_ files.

I'm neither pro- or anti-systemd. On the one hand, I've actually looked at the systemd code. It's actually very well-written AFAICT. I'm not saying I agree with the way it's structured or how they keep re-writing subsystems (e.g. event loop library, ntp service, etc), but all things considered it's an overall improvement in code quality for the myriad things it replaces. OTOH, systemd doesn't provide anything that I've ever cared about. Process and log management is the least of my concerns. Plus, I have to worry about portability, so the marginal conveniences systemd provides are of little benefit to me.

But from what I can tell, most pro-systemd proponents aren't actually developers of system-level components. They tend to work on high-level applications--e.g. web applications. These people have an exaggerated perspective of the apparent benefit of systemd. The exception to this observation are desktop component integrators and developers. Systemd's process management is much more important in those cases.

By comparison, the anti-systemd people do have much more legitimate complaints about increases in complexity for their scenarios. Particularly wrt journald. But I tend to think these issues are also slightly exaggerated. And, anyhow, at the end of the day open source has one abiding rule--he who writes the code writes the rules. The systemd people have written a better system. It's not as useful as people make it out to be, but it is more useful as a general matter. So stop complaining and get to writing the alternative if it really matters that much to you.

BTW, Linux will soon get process descriptor support. From my perspective of implementing low-level network daemons and services this is far and away the more elegant building block for re-imagining process management in Unix compared to cgroups.

Re:KDBus - another systemd brick on the wall

[Khyber]

Not even close. Infinite loop eating memory until the kernel hardlocks.

Re:KDBus - another systemd brick on the wall

[drinkypoo]

Is it really the "Unix way" for instance to handle login shell sessions only if they come in via serial ports or the framebuffer/USB keyboard, but not via TCP sockets?

Yes, to a degree. It absolutely is. Remember, a single program should do one thing, and do it well, and either pipes or scripting should be used to get to the next step. It doesn't matter whether you log in through a getty or through a ssh daemon or through a telnet daemon launched from inetd, you're still going to go through /bin/login. So yes, that is the Unix way, which you willfully do not understand for the purposes of supporting systemd.

Re: KDBus - another systemd brick on the wall

[sjames]

Well, the kernel is fairly important don't you think?

Given a choice between rolling back everything including fixes to critical bugs, I'd sooner roll my init system back to SysV. In fact, I did.

Re:KDBus - another systemd brick on the wall

[drinkypoo]

You just seem to parrot the party line propaganda from the tin-foil hat systemd-haters.

Unlike systemd developers, I listen to users.

It takes some time to really understand how systemd works.

That is much of what is wrong with systemd. It only takes a few moments to understand how sysvinit works.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

So you're able to activate a system swap file without being root? Please tell me how you do that because if I try that I get permission denied.

If you're concerned about a high-memory app/user, use a cgroup to limit them.

This doesn't sound like the big problem you make it out to be.

Re:KDBus - another systemd brick on the wall

[fisted]

SysVinit and endless variations like it such as OpenRC

OpenRC is a variant of the BSD rc mechanism, you pleb, which exactly avoids

mixing code and config statements

this.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

sysvinit is crude and simple because it pushes all complexity out of init into userspace and because it offers no worthwhile init functionality. That is why Linux endured decades of remote exploits since SysVinit wouldn't take responsibility for dropping daemon privileges or do socket activation like systemd does, so daemons didn't have to use complex and error prone privilege dropping code just to get a port below 1024.

With systemd and new style daemons you can just avoid all that crap in the daemons. Much better to have one central place for security code made by experts than each and every daemon needs to compensate for the abysmal lack of functionality and security features of SysVinit.

I don't care if some people think that SysVinit is the best init system ever made and that it has no errors and can't be improved and Linux should use it forever and ever. We happen to be a lot of people who don't see it that way, which is why we like systemd and chooses distros that support that.

Re: KDBus - another systemd brick on the wall

[Anonymous Coward]

That is the big problem. A lot of systemd and Kdbus opponents voiced out very good technical concerns. Just that the proponents seems to be too technically incompetent to understand these concerns.

You just have to read Greg replies on linux kernel archives on kdbus. Some of his replies are hilarious. Did you read the part when people pointed out a bad set of codes and guess what his replies? Oh he overlooked it and it can be replaced by a simple single mutex. Does reply like this inspired confidence about a set of codes that is supposedly really for the linux kernel? I think a lot of programmers has been sacked for less.

Re:KDBus - another systemd brick on the wall

[pem]

Virtually every program written has ["caused occasional instability and breakage, and consumed resources unnecessarily"]

Yes and "virtually every program" is something that the user voluntarily and directly starts. Avahi, pulseaudio, and systemd... aren't. Which makes it exceptionally frustrating for both users and developers when there is a problem, both from a standpoint of not knowing where the problem came from, and from the standpoint of finding an alternate program to use instead.

Which is why systems programmers should be held to a higher standard than applications programmers. Their mistakes should be fewer and should also be rectified more quickly.

so that comment of yours makes the rest of your post baseless and not worth replying to.

"There are lots of incompetent programmers so it's no fair pointing out that systemd is written by an incompetent programmer."

Is that really what you meant to write?

Re:KDBus - another systemd brick on the wall

[Qzukk]

This was Windows 7.

As a bonus, the guy who loaned the printer to me told me (afterwards) that there's a driver that works perfectly fine already in Windows if I navigate through the manufacturer listing and select it by hand.

Re:KDBus - another systemd brick on the wall

[Peter H.S.]

Yes, and most of that existing industry will have to rewrite everything from scratch without file format compatibility.

journald has excellent export capacity, it is trivial to convert everything into JSON or similar industry standards without tedious data massaging. Unlike the many slightly varying syslog implementation with deviating output, journald output is always predictable since has a stable API and is structured around fields. This is a massive win for everybody, especially those who needs to put their logs into full DB's (for legal or whatever reasons).

"Another problem with text log files are their limited ability to incorporate much meta-data, since that makes the log lines unreadably long. So having full microsecond precision and monotonic timestamps is a problem."

Really? Here's the microsecond monotonic timestamp on my current box: 242841.31760194. That's 15 bytes. A 64-bit binary timestamp is 16 bytes. The text version is shorter! And given that the vast majority of usages do not require microsecond resolution (which isn't even really accurate, anyhow), the text approach would lead to substantially _smaller_ files.

Adding full microsecond precision and monotonic timestamps and wall time timestamps + all the other interesting meta-data and the log message itself, are making the text log entries extremely long and unfriendly to read for humans. With journald you only see such meta-data info if you ask for it. Much better solution. And if you are concerned about log sizes, journald has transparent compression. With text logs you need to unpack or use specialised tools to manipulate them if compressed.

Plain text logs sucks for so many reasons, their only redeeming feature seems to be you don't need to pipe them through a tool in order to read them.
I have much respect for the Rsyslog developers, and I remember how I hoped they would fix the most of the glaring syslog problems when they started out a decade ago and in their own way tried to solve the problems that journald does. They partially failed, not because they weren't good, but because changing certain stuff in Linux userland is extremely hard.

Re:KDBus - another systemd brick on the wall

[billcopc]

As someone who does a fair bit of fiddling with init systems and other boot-time fun (I do lots of appliance-style builds), I whole-heartedly agree with you. SystemD is a solution to a non-existent problem. Classic init is elegantly simple and works perfectly fine, with the bonus that it won't make your system unbootable if you happen to swap in a new (or rescue) kernel.

Myself, I *want* SystemD to crash and burn, just for the lost hours trying to troubleshoot this unwelcome and unnecessary complication. I don't use it in my appliances, but when I have to debug someone else's bricked servers, SystemD and udev are disproportionately at fault for so much unwarranted downtime. I mean, sure, I get paid regardless, but I'd much rather not see this cruft in our beloved free OS.

Re:KDBus - another systemd brick on the wall

[Ducho_CWB]

Why does Windows not recognize my USB device as the same device if I plug it into a different port?
http://blogs.msdn.com/b/oldnew...

Re:KDBus - another systemd brick on the wall

[jones_supa]

Thanks for the explanation. There seems to be a motivation to do so then.

Re: KDBus - another systemd brick on the wall

[Anonymous Coward]

Then you'll be happy that you'll be able to do that once the kernel has kdbus support, just don't roll back to a kernel before it got that.

Re: KDBus - another systemd brick on the wall

[Anonymous Coward]

Here's the answer, straight from the horse's mouth:
http://blogs.msdn.com/b/oldnewthing/archive/2004/11/10/255047.aspx

Summary: some USB device manufacturers misunderstood the spec; the alternatives to the current behaviour would be worse.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

you cant do that without "admin priv"

Re:KDBus - another systemd brick on the wall

[reikae]

I haven't tried this myself, but others are saying you need root to do this. If that's the case I'd say it's a serious issue if this is something that an admin would normally do; a superuser going out of his way to lock a system will find a million ways to do it.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

or, and I know this is crazy but stay with me, the distro could go online when a new device is found and download the driver automagically.

Re:KDBus - another systemd brick on the wall

[Trogre]

Are you just making stuff up?

The method you have described requires root ('admin') access and can only really be described as a misconfiguration rather than an attack.

Re: KDBus - another systemd brick on the wall

[sjames]

Be able to roll back to SysV, naturally, it has few hard dependencies.

If you mean systemd, the developers have said they intend the dependency to be lock-step with the kernel.

Re:KDBus - another systemd brick on the wall

[Electricity Likes Me]

Actually the thing journalctl does really well is the ability to log onto a machine and run journalctl -f and get every log the machine is running on the local console immediately. It's a boon when you're doing remote logging because you don't get stuck with issues like buffering causing your logs to come in big unwieldy bursts.

Re:KDBus - another systemd brick on the wall

[spuk]

Could you give some pointer to this "process descriptor support"? I'm curious.

Re:KDBus - another systemd brick on the wall

[Anonymous Coward]

FYI the avahi-deamon 100% cpu bug as seen on ubuntu from 2010-2014 (maybe more) happens when another computer on the network sends a null packet through Bonjour. There are Bonjour clients for Windows so you can't just blame the Macs, and who knows maybe it is other avahis on the network sending the bad packets.

On a busy university network this takes less than 5 minutes to trigger. Every Ubuntu install we did for many years jumped up to 100% CPU use within a few minutes of installation. Purging avahi-deamon didn't work as then all the desktop packages would want to uninstall themselves as well. We got really fast at commenting out the respawn directive in the upstart init file and shutting down the service. There was an ubuntu ticket open for it in launchpad with no developer feedback anywhere in sight.

Fucking incredible.

Re:KDBus - another systemd brick on the wall

[stooo]

>> Thanks, Microsoft for making my job easier
Or you could use Linux...

Re:KDBus - another systemd brick on the wall

[rdnetto]

I've found avahi works quite well for local/P2P name resolution (at least, much more reliably than SAMBA + winbind). Now admittedly I started using it long after it had stabilized, but I would like to know what you were using instead.

Re:KDBus - another systemd brick on the wall

[hitmark]

Best i can tell, because it take into account the whole USB address tree when linking a device to a driver.

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.

Re:Please stop the Phoronix shouting!

[jandrese]

EXT4 encryption seems like a pretty good bullet point, especially with the TrueCrypt situation. I hope it's not fatally flawed in some way. Caveat: I have not looked at it yet.

Re:Please stop the Phoronix shouting!

[Anonymous Coward]

They may even benchmark the mp3-encoding performance with controller feature and get different figures which are within error margin. Last time I read a Phoronix article, it was benchmarking filesystems with mp3-encoding speed test.

Re:Please stop the Phoronix shouting!

[Anonymous Coward]

Just use LUKS?

I like the idea of filesystem encryption vs. block device level too, but metadata can be damning. ls ~/secrestuff... hmmmm.... you must let me know the key to the file super-secret-seditious-stuff.txt, or off to Guantanamo you go. A bit less plausible deniablilty (although a luks header will give you away that you have encrypted data, you can deny having seditious documents. And, you can use cryptsetup without luks to improve this a bit-- no header, just a blob of random data).

Wounded Not Dead

[Terry95]

The Linux ecosystem is already severely wounded, possibly mortally so, by systemd's attempted coup. The operating system loses most all practical advantages because of this malware - I will literally go so far as to say if I have to have Linux with systemd I don't want Linux. I might as well just run Windows. They are both black boxes of unknown function and unrepairable, not to mention unfindable, vulnerabilities. So why bother with the down sides of Linux if it has no up side?

At this point I am evaluating BSD vs Windows 10; BSD is winning. Hopefully Linus will never allow these evil monsters to commit their viruses to the kernel. That will be game over for Linux.

Re:Wounded Not Dead

[Anonymous Coward]

We still have Gentoo, Void Linux and Slackware. I recommend giving Void a try

Re:Wounded Not Dead

[Truekaiser]

Because systemD is being pushed by red-hat. And red-hat makes money, no their 'entire' business model is selling support.
So would they want a piece of software that you can use yourself correctly? No, they want a piece of software that is so arcane and labyrinth ridden that you have to pay them to tell you how to use it.
right now the majority of the systemD dev's in the kernel area that are pushing for this are outnumbered and Linus won't allow it in because the only advantage and reason they can come up with that is now buzzwords are the speed improvements simply from having it run in kernel space. But gkh got a coup done in the kernel dev committee or what ever it's called and pushed through a standards of conduct, i bet he is practically salivating in anticipation for the next time linus goes on a rant and he can use it to censor him or kick him out.

Re:Wounded Not Dead

[jbolden]

RedHat has had their own kernel for a quarter century. They don't need Linus' permission to introduce change into their kernel.

Re:Wounded Not Dead

[Khyber]

"The upsides of Linux in 2015 are in spaces like huge range of software, IaaS, supercomputing "

Supercomputing? HAH!

Linux is so fucking weak that it can't even support my super-server with 12 GPUs PER BOX.

Yet, some how, Windows Server 2008 works just fine with ALL TWELVE, rolling Hyper-V and RemoteFX, delivering native performance REMOTELY.

Pretty sad a nearly decade old server OS rips the shit out of Linux in hardware support AND in usability.

Re:Wounded Not Dead

[squiggleslash]

There's nothing stopping you from running Linux with SysV Init. You won't be able to use modern versions of GNOME (but who does?), and you won't be able use the major distros, but if that's what you want, by all means go for it. Linux (in terms of what we're talking about here - ie the thing called "Linux" that has a version number of 4.1) is only one component of the operating system, and doesn't have SystemD as part of it.

But bear in mind that SysV Init has been straining at the seams now for around two decades, probably more. When it was written it was rare for a Unix system to fail to boot for any reason other than a hardware fault or disk corruption. The notion a minor misconfiguration of a networking script could take down a machine was unthinkable back then.

Bear in mind SysV init was never upgraded to take into account changing usage. Take a look at /etc/inittab. Try and find a man page that still describes the format. Ask yourself why it exists. Ask yourself why, bearing in mind it does, inetd is a completely different, unrelated, system. Ask yourself why sshd exists and why those connections aren't managed by inetd or init.

Bear in mind that Linux the kernel has had some major security and process management systems now for over half a decade that SysV init is incapable of using - and always will be. That those security and process management systems, if used, significantly improve both the security and reliability of Linux based operating systems by making it easier to, amongst other things, truly sandbox processes in a way superior to BSD's jails feature. Ask yourself why we should be prevented from using them simply because the operating system's daemon management system doesn't support anything the AT&T kernels didn't support in 1983..

Bear in mind that SysV Init's faults are so obvious to people who actually build operating systems that SystemD isn't even the first try at this, that Upstart was considered "very nearly there" as a suitable replacement, and that the real debate was between SystemD and Upstart, not SystemD and SysV init.

Finally bear in mind that SystemD is a true superset of SysV Init in terms of functionality. This isn't the Wayland/Mir "Let's throw the baby out with the bathwater because there's too much spaghetti code" nonsense, there's nothing you can do with SysV Init that can't be done with SystemD. Except it's much, much, harder now to hose your configuration so badly that it's not going to come up because an NFS share wasn't available when you rebooted your computer.

Re:Wounded Not Dead

[jbolden]

Supercomputing? HAH!Linux is so fucking weak that it can't even support my super-server with 12 GPUs PER BOX.

http://www.top500.org/statisti...

In 2011 Cray deployed a Linux supercomputer with 9600 GPUs and from that point on Linux has been able to handle essentially infinitely many. I think you may want to read up a bit.

Re:Wounded Not Dead

[Anonymous Coward]

Just curious (posting as AC because mod points spent): How you put 12GPUs on a single box? Multiple motherboards?

Re:Wounded Not Dead

[drinkypoo]

But bear in mind that SysV Init has been straining at the seams now for around two decades, probably more.

Only because people keep trying to shove things into init that don't belong there.

Bear in mind SysV init was never upgraded to take into account changing usage.

It didn't need it.

Take a look at /etc/inittab. Try and find a man page that still describes the format.

On debian, you would use 'man inittab'.

Nobody should have continued reading your comment beyond this point, because it's clearly ignorant at best.

Re:Wounded Not Dead

[Khyber]

Yea, which is why just about any Linux distro, down to CentOS, horks when it sees more than 4.

Let me know when that infinite-gpu support hits mainstream and doesn't rely upon proprietary code to work.

Re:Wounded Not Dead

[Khyber]

Multiple modes linked using a customized backplane to present everything as a single component. 8 CPUs? Seen as a single 192-thread processor. 12 GPUs? Seen as a single 37,000+ GPU core unit.

Re:Wounded Not Dead

[Anonymous Coward]

stop talking sense, its too hard for some of the anti-systemd'ers to understand.

Re:Wounded Not Dead

[Anonymous Coward]

Let me know when that infinite-gpu doesn't rely upon proprietary code to work on Windows.

Re:Wounded Not Dead

[Khyber]

Hyper-V and RemoteFX are open source, so looks like you just fucked yourself, Charlie.

Re:Wounded Not Dead

[Barsteward]

"Only because people keep trying to shove things into init that don't belong there" - that must be because those "shoved things" are needed for some reason

"It didn't need it." - it obviously does hence the emergence of replacements like Launchd, upstart, systemd

You must be lucky on Debian. opensuse doesn;t have it

iuser@opensuse:~> man inittab
No manual entry for inittab

Re:Wounded Not Dead

[Anonymous Coward]

Yea, which is why just about any Linux distro, down to CentOS, horks when it sees more than 4.

Weird, since some of our compute nodes and several test workstations have 8 gpus each, and one of our vendors is sending us a system with double the slot count for testing. So far they've been pretty straightforward to setup.

Re:Wounded Not Dead

[Khyber]

I hope your vendor bothered to check the architectural limitations of the processor you're using. The old Xeon E7 CPUs had a nasty problem where you could run 2CPU/4GPU or 4CPU/2GPU but you could not run 4CPU/4GPU. The E5v2s have the same problem, requiring multiple linked nodes in order to get around the issue.

Re:Wounded Not Dead

[Etcetera]

Because systemD is being pushed by red-hat. And red-hat makes money, no their 'entire' business model is selling support.
So would they want a piece of software that you can use yourself correctly? No, they want a piece of software that is so arcane and labyrinth ridden that you have to pay them to tell you how to use it.

I can't say this is fair. Was RH's support level going down? They were doing fine with init processes that were composed of shell scripts too.

From what I've heard, there's serious debate *within* RH about systemd as well; not everyone's been on-board with it internally.

I think a lot of this can be blamed squarely on Fedora leadership... Over the course of about 3 years between Fedora 14 and Fedora 19, it feels like all the sysadmins looking product stability in the project got replaced with developers looking for new/shiny problems to solve with some new Big Idea. Hence systemd, RPM spec file churn, UsrTmpfs, and other monstrosities.

Re:Wounded Not Dead

[Anonymous Coward]

OpenSuse is systemd, you asshat. Of course it doesn't carry the inittab manual. Meanwhile it's good we have these things called search engines:

http://www.manpages.info/linux/init.8.html

Re:Wounded Not Dead

[drinkypoo]

"Only because people keep trying to shove things into init that don't belong there" - that must be because those "shoved things" are needed for some reason

The question is whether they need to be in PID 1, or in a process PID 1 can't live without, and the answer is no, that is not the Unix way. That is the Windows way.

"It didn't need it." - it obviously does hence the emergence of replacements like Launchd, upstart, systemd

Launchd is not Linux software. Launchd is universally hated by all those with experience with it, so that is a self-defeating argument, thanks for using it. Please bring up SMF next. upstart does not have the interlocking web of requirements that systemd does.

You must be lucky on Debian.

It's not luck, it's foresight. I use it only for servers, so none of the software I run depends on systemd, and I have pinned systemd back so that it can't be installed even if I upgrade. And I am still running wheezy, and will keep doing that right up until Devuan becomes viable, or I give up and jump to something else.

My desktop is still running Ubuntu on the rare occasion that I boot into Linux any more. All the fighting and bullshit since systemd became a thing has kept me pretty solidly in Windows 7, about 95% of the time. In fact, I finally went so far as to pay for a Windows 7 license because windows "just works" while various forces keep breaking my Linux. Literally the only thing that works better on Linux any more is driver support. If I want to use my scanner, which I got cheap because Canon abandoned support from it from their driver for Windows 7 and later even though they are still using the same protocol, I have to boot Linux. But that's not Microsoft's fault, it's Canon's. I know of no scanner manufacturer which is not a complete fucking piece of shit about this.

Re:Wounded Not Dead

[Tetch]

On debian, you would use 'man inittab'

I hardly think Debian's inittab man page constitutes adequate documentation of the content, function and format of the damn thing. I've read it, and am not much the wiser.

I was trying to find out why the default runlevel in Squeeze is 2, and starts whatever GUI desktop you have installed, although runlevels 3, 4 and 5 are also available but do nothing different from 2. I'd have liked a clear description of how to tweak the file so the system starts multiuser but with just a dumb terminal console at first, only switching to GUI desktop if runlevel gets changed to, say, 3. Fat chance.

It's like doing 'man bash' in the hope of finding out what the bash syntax for a compound condition 'if' statement is :-) ... round brackets or square ones ? .... one set, or two ? .... 'elsf' or 'else if' ? .... 'fi' or 'endif' ? ...... These vaguely Algol-like languages just blur one into another after a while .... sh, csh, ksh, bash, dash, zsh, whatever that was on HPUX, etc., etc. .... anyway, as any fule kno, you search the web for that, only resorting to the man page if you have a burning desire to learn about arcane line discipline handling of weird escape characters.

AGP not working with SMP

[jones_supa]

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

Re:AGP not working with SMP

[Anonymous Coward]

AGP in 2015? WTF? What is wrong with you neckbeards, throw your old shit out.

Re:AGP not working with SMP

[Anonymous Coward]

That's a pretty rare configuration. Multi-core x86 processors only appeared well after PCI-E had taken hold. (Athlon64 was released in 2005.)

I've never personally seen a dual CPU on an x86 non-server box, although I find the idea intriguing. Mmm... dual Athlon MP...

Re:AGP not working with SMP

[TheRaven64]

Multi-core x86 processors only appeared well after PCI-E had taken hold

True, but SMP systems are older. I used a dual P3-700 for years, which I picked up cheaply on eBay because not many people searched for 'duel processor' (I think eBay now does some phonetic matching in their search). Before that, the ABit BP6 (1999) was quite popular. It ran two Celerons, so you could get a dual-processor machine for cheaper than a single-processor one (though you needed to run Windows NT or *NIX to be able to use the second one, as XP was the first SMP-capable consumer OS from MS). The 300MHz Celerons overclocked to 450MHz by bumping the FSB from 66MHz to 100MHz, making it quite competitive with the P2 (the L2 cache in the Celeron was half the size, but twice the speed, and the core was the same).

Re:AGP not working with SMP

[TheRaven64]

And it turns out that people were still launching boards with AGP in 2010. You can probably still buy one...

Re:AGP not working with SMP

[ckatko]

Sure, nobody likes what you wrote anyway, but to clarify:

If you had RTFA, the guy who raised the issue is running an arcade machine. A perfect example of how old hardware is used.

Furthermore, there are plenty of older chipsets that have internal AGP cards.

Re:AGP not working with SMP

[Anonymous Coward]

AGP in 2015? WTF? What is wrong with you neckbeards, throw your old shit out.

Kind of throws away the advantage of Linux working great with older hardware.

Re:AGP not working with SMP

[billcopc]

That board was launched in 2007, but I agree it was a bit of a WTF even at that time. Anyone still buying an AGP card in 2007 was paying top-dollar for inferior performance, since the entire GPU industry had moved to PCI-E, and what few AGP cards they did release were little more than a regular card with an AGP-PCI bridge chip that sucked the life out of it.

Re:AGP not working with SMP

[TheRaven64]

There were probably some people with very expensive AGP cards that were needed for some custom display hardware. I used a PCI (not PCIe) graphics card for a while because it was the only thing that could drive a small LCD monitor that I'd bought cheaply.

Re:AGP not working with SMP

[Anonymous Coward]

So, how was the duel with the processors? Any processor duel videos I could watch?

Re:AGP not working with SMP

[TheRaven64]

Sadly, both processors lost to the dust, in the end. Back around 2005, there were a lot of people who couldn't spell dual though, and 'duel processor' machines were going for about half what people were paying people who could spell for 'dual processor' machines on eBay. It was an object lesson in the financial value of learning to spell...

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.

Re:Poettering thinks he's the next Linus

[kthreadd]

1. PulseAudio was good. The initial packaging in some distributions were however questionable.
2. Systemd is good, and the quality of it has nothing to do with PulseAudio.

Why?

[Anonymous Coward]

The article doesn't state why KDBUS was rejected. Like everyone else, I consider systemd to be vile, but what techical reservations does Lignus have?

Re:Why?

[Peter H.S.]

The article doesn't state why KDBUS was rejected. Like everyone else, I consider systemd to be vile, but what techical reservations does Lignus have?

systemd is great stuff, only a tiny but vocal minority disagree with this. Keep your SysVinit for the next 30 years if you please, the rest of us wants systemd.

Linus Torvalds have long signalled that he wants kdbus in the kernel. What he is waiting for is the usual kernel process to work. At the moment the technical debate is about allowing certain kinds of meta-data to be transported around. The broader problem is that most kernel developers have very little experience with user space system glue like dbus, and you have to understand dbus in order to understand kdbus, so the review process will take some time. Nothing really unusual about this however, sometimes it takes a long time before features are accepted into the kernel.

Re:Why?

[Anonymous Coward]

Hmm. Sysvinit starts processes. Systemd are the processes - childish, broken, buggy, incomplete imitations thereof. Get it?

Re:Why?

[bouldin]

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.

Re:Why?

[guruevi]

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.

Re:Why?

[segedunum]

Linus Torvalds have long signalled that he wants kdbus in the kernel.

No he hasn't you liar. I'm afraid this propaganda ain't going to have any effect whatsoever on his views.

Re:Why?

[Peter H.S.]

Having used Linux audio from before ALSA came into existence, and having used PA from the beginning, I can assure that PA was a major step backwards in fixing Linux audio

Oh so you miss the days of manually setting sound card jumpers to set DMA and IRQ with certain software only accepting a subset of these, and you miss how each and every program fought over access to the sound card, and how there was no system sound daemon that worked across the different DE's so each DE had its own shitty sound daemon, and in those days where you really had to know what chipset your sound card used because so many chipsets was unsupported or had quite broken drivers. And don't get me started on that shitty company behind OSS that started to close source their stuff in order to extort money from Linux users and distros.

PA is great stuff that solved many real world problems with sound on Linux.

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?

[Anonymous Coward]

After reading the closed systemd bug related to using debug on the kernel y can only say that kay and lennart are morons and systemd is sh! t

Re:Why?

[DenaliPrime]

Just from looking the LKML, it appears there were some issues that the usual suspects involving code quality (Linus, Greg K-H) were arguing over. The fun and excitements starts at http://article.gmane.org/gmane....

Re:Why?

[Ol Olsoc]

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

And there you have it. Perhaps much of PulseAudio's "problems" are a case of shooting the messenger. It fixed many things for me with my audio needs.

Re:Why?

[Peter H.S.]

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. It works great for that and doesn't drain batteries and so on. For specialized use or Pro audio where latency is king ALSA directly or jackd. No PA expert but if the driver/hardware doesn't support sampling above 96 kHz you should expect problems. +100kHz really is an unusual user case.

Re:Why?

[Peter H.S.]

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.

You are interpreting this much too hard. Every time a new important kernel features come you have these kind of statements. The point being that some reviewers set the standard to "perfect" to begin with. That way nothing will be merged, so from now on people have to battle out the details until Linus is satisfied. Eg. Linus has personally stated that some of the criticism that Biederman repeats are wrong (about caps metadata in an exchange with Lutomirski).

All in all this is business as usual, and the kdbus developers have been very very quick to change anything specific that has been pointed out as problematic. That they are eager to get things merged is just how such things work, same with reviewers that says "hold your horses".

There are pretty good odds on that kdbus will be merged into mainline in not so far a future when things have been trashed out on lkml a while.

Re:Why?

[Anonymous Coward]

I don't think its a loud minority, I think this release of debian is going to show that the loud minority is in fact the systemd people. They've shutdown debate, filtered out from the forums anyone not positive to the change and rigged voting to dilute the anti-systemd sentament.

With a stable target now Jessie is released all the alternative forks can move forward. People are either holding off upgrading until a smooth transition from wheezy is available or have started migrating to *bsd in disgust of the systemd shenanigans. After all its only so often you can say 'suckitup or go away' before everyone just goes away.

Whats left is another redhat derivative and since systemd seems to be a response to their inability to maintain their own sysinit init scripts properly I have no faith in their ability to maintain their systemd code. Atleast with sysinit I could fix it myself.

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.

Re:Why?

[drinkypoo]

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?

Re:Why?

[bouldin]

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. It works great for that and doesn't drain batteries and so on. For specialized use or Pro audio where latency is king ALSA directly or jackd. No PA expert but if the driver/hardware doesn't support sampling above 96 kHz you should expect problems. +100kHz really is an unusual user case.

Well, this was on a high-end consumer soundcard (that most definitely supported the sample rate). There is a healthy and growing demand for higher sample rate tracks (e.g. hdtracks.com seems to be doing well).

I should try again with a recent version of PA to see if it has the same problems. IIRC, even 96 KHz seemed to stress PA.

Re:Why?

[Peter H.S.]

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.

Re:Why?

[Anonymous Coward]

all we get from you, is your troll ignorance

Re:Why?

[Anonymous Coward]

can you point to something where he says kdbus will never be pulled into the kernel?

Re:Why?

[Anonymous Coward]

Just read the discussion on lkml with subject "[GIT PULL] kdbus for 4.1-rc1", it has all the details.

Re:Why?

[Barsteward]

"Actually, pulseaudio has notably drained batteries [launchpad.net] in the past, because shitcode." - bloody hell, software has bugs. How would have thought it?

Re:Why?

[Peter H.S.]

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.

This not about spending money or HiFi, but on what you use the audio system for. On consumer audio you want low cpu and battery drain and accept the tiny latency associated with this; that a music stream start 20ms second later doesn't matter. It is also important that features such as streaming, bluetooth head sets integration etc. works out of the box etc.

With Pro audio latency is king. cpu and battery drain means nothing.

PA can provide both things, by suspending out if your need shift from consumer audio (PA) to Pro audio using jackd. No need to dedicate your box to either; they can both work for whenever people need different solutions.

Actually, pulseaudio has notably drained batteries in the past, because shitcode.

A bug from 2007 on Ubuntu that famously fouled up their PA implementation, hardly a serious complaint. This 2012 shows how PA even beat Androids audio stack (Audioflinger) regarding CPU and poweruse.
http://arunraghavan.net/2012/0...

There are several such benchmarks that shows how good PA is in this regard.

Re:Why?

[Anonymous Coward]

> Keep your SysVinit for the next 30 years if you please, the rest of us wants systemd.

I will keep using OpenRC until a worthy successor comes along. My experience with systemd in Kubuntu 15.04 is pretty much the opposite of what I was promised: Boot takes twice as long, and shutdown immediately sends SIGKILL to all processes, rather than waiting for a second or two [I mean, really? Isn't one of systemd's big things that it can keep track of everything it has started?! Why not wait until everything has shut down? You *know* when this has happened, so it can *still* be done as quickly as possible.] for things to write shit to disk. (BTW, systemd's way *DOES* cause data loss. Have fun losing the last five or so seconds of your work, or your KDE session state on shutdown!).

It's a damn shame that systemd proponents keep framing this as a binary world, when there are a couple other really good alternatives that are battle tested.

Re:Why?

[Peter H.S.]

Linus Torvalds have long signalled that he wants kdbus in the kernel.

No he hasn't you liar. I'm afraid this propaganda ain't going to have any effect whatsoever on his views.

Have you even read the lkml? Linus is deep into discussion of the code and even defended kdbus design decisions. He would never do that if he didn't intend to merge it as some point when enough people thought it was good enough.

Also notice how Linus appeared in the first kdbus patch threads. He didn't comment on the code, so the only reason he mailed was to signal to everybody that he followed this, and this was just business as usual.

Sure, the kdbus maintainers will have to do a good enough job in fixing problems before it is merged, but as it looks now, this doesn't seem to be a problem.

kdbus is good stuff that can benefit everybody, and while it isn't a shining-new general purpose IPC that some kernel developers want, it does solve real world problems, and that is exactly what Linus think his kernel is all about.

Re:Why?

[Anonymous Coward]

What? No, you were talking about a world that's pre Plug-And-Play, which would be the early-to-mid-1990's. Remember that Linux's first relase was in 1993.

I ran (and run) multiple ALSA applications without issue by using DMIX.

TBH, the only thing PA has done for me was to add large, widely variable latency to my audio output, and -when I actually had the network audio component activated- go berzerk and swamp my LAN with UDP junk. (Yes, this actually *was* a bug in Pulseaudio. SIGKILLing PA a few times re-inserted the software's brain.)

Re:Why?

[Anonymous Coward]

> PA can provide both [high-latency audio and low-latency audio], by [allowing the user to shut off PA when] your need[s] shift from [unpredictably-variable-latency audio] (PA) to [low, predictable latency] audio using jackd.

FTFY.

If you have to shut down software and use something else to get a particular feature, the software you shut down DOESN'T PROVIDE THAT FEATURE.

Re:Why?

[Anonymous Coward]

Can you point to something where he explicitly says that he *WANTS* kdbus in the kernel?

Not blocking a code merge is not the same as *wanting* something in your project.

Or to put it another way: Not diswanting is not the same as wanting.

Re:Why?

[Barsteward]

of course it is. if he stated he didn't want it, he would say something otherwise they'd be taking up his time unnecessarily, LT is actually looking at the code and commenting. They'd probably stop developing it if he said "No". Just have a look at the kernel and git messages to see he is participating

Re:Why?

[Anonymous Coward]

You don't need to worry about doing that with ALSA anymore. ALSA even handles native inter-application sound mixing and volume controls out of the box. You don't need PulseAudio anymore, it's just an added layer of bloat that worsens your audio quality.

Re:Why?

[bouldin]

PA can provide both things, by suspending out if your need shift from consumer audio (PA) to Pro audio using jackd. No need to dedicate your box to either; they can both work for whenever people need different solutions.

Are you really saying that a feature of pulseaudio is the ability to disable pulseaudio and use something else?

I see a lot of posts complaining about anti-systemd zealotry here, but clearly there is a lot of zealotry all around. I can't recall any other topic in Linux history that has been this divisive, and that is part of the problem.

Re:Why?

[Peter H.S.]

PA can provide both things, by suspending out if your need shift from consumer audio (PA) to Pro audio using jackd. No need to dedicate your box to either; they can both work for whenever people need different solutions.

Are you really saying that a feature of pulseaudio is the ability to disable pulseaudio and use something else?

Yes I do. It is great that you can use exactly the program you need, even if their usage normally are orthogonal. Please note that PA doesn't disable itself, it just automatically suspend until needed again. PA and jackd where made for different reasons and solves different problems.

I see a lot of posts complaining about anti-systemd zealotry here, but clearly there is a lot of zealotry all around. I can't recall any other topic in Linux history that has been this divisive, and that is part of the problem.

Well, some people thought they could stop the systemd progress by waging a negative campaign against it and its developers. That of course was a predictable failure.

Personally I don't care whatever init system people run. Even if I find e.g. SysVinit inferior to systemd I have no problem with people using it, and they owe me no explanation for doing so.

Systemd-opponents don't agree upon what they do like, they can only agree on what they don't like. This make their tactics so rabid and aggressive when attacking systemd, its developers, the distros that uses it and even its users. They simply don't have a positive alternative they can agree upon, so they are left with negative attacks.

Re:Why?

[segedunum]

Linus has already stated, and I've provided the very message, where he has point blank told Greg that this needs to be tested in distribution kernels before it ever gets anywhere near mainline.

If you're choosing not to see that then there's not much we can do here.

Re:Why?

[Anonymous Coward]

"Actually, pulseaudio has notably drained batteries [launchpad.net] in the past, because shitcode." - bloody hell, software has bugs. How would have thought it?

Bloody hell, some software has far more bugs than others. Who'd a' thought it?

Your implication that all software is similarly buggy is laughable. Some software is junk. Some isn't.

Re:Why?

[Anonymous Coward]

I'm afraid the one with the rose-tinted glasses are you. For one, I never claimed ALSA was a step backward, I said I have been using Linux audio since before it. I said that pulseaudio was a major step backwards, one that just like many other sorts of Lennartware causes complete mayhem with your system while not solving the problem it's purported to in the first place.

I find your lack of reading comprehension quite disturbing, because you could not possibly be intentionally disingenuous and obtuse, now could you?

Losing

[Anonymous Coward]

After 25 years of progress you can't see that we are losing territory to the fascists? We are losing the war.

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.

Re:Oh grow up

[segedunum]

DBUS is so amateur hour it's seriously embarrassing for open source software.

Re:Oh grow up

[Antique Geekmeister]

Mr. Pottering can spell better than that. But I'm afraid that many of the systemd features are being written by people who spell that badly and with such poor grasp of synax. The poster also seems to have no idea of how often development kernels are run in older or slightly out of date to bring new features, especially hardware drivers, into critical, high performance environments. So the "lockstep" systemd and kernel requirements become a much larger issue, because systemd components have become locked to the major systemd release as well.

Re:Oh grow up

[Too Much Noise]

If some of you stopping look at every thing systemd tinted glasses you might start reacting like rational adults.

Funny you should say that, AC. I'll wait (not holding my breath though) for the rational, adult answer of G H-K to this message and a timeline for addressing the issues it raised:

http://lkml.iu.edu/hypermail/l...

To quote the last part:

Not that this complaint is not in any sense new you have been ignoring people who try to bring up meaningful issues for a long time. The fact that when people bring up uncomfortable points about the kdbus code they get routingely blown off certainly contributes to the lack of meaningful review as it is not rewarding to work with someone who does not listen to criticism. At this point the strongest possible language and the strongest possible push back are being used because everything else is routinely swept under the rug.

So, feel free to engage in that rational discussion anytime now.

Re: Oh grow up

[Anonymous Coward]

Windows is even used by much more users. It is the best software out there. Why waste your time on Linux?

You don't need the exact numbers of windows desktops vs Linux to tell u that do you?

The more users, the better to it is.

Re:Oh grow up

[Anonymous Coward]

You seem to be ignoring the technical issues with DBUS and KDBUS.

Just the whole metadata scheme is brainded enough to warrant blocking the whole things. It needs *way* more reviewing, and perhaps some serious redisign.

Re:Oh grow up

[Peter H.S.]

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.

Well, Kdbus is more than just simple IPC, it is also provide a control framework with policies etc. just like dbus does.

What the tin-foil brigade don't understand, that any non-dbus compatible IPC will be a major problem for all non-systemd distros and BSD variants, since it per default will be Linux only, and in reality a systemd-only affair, since only systemd distros will have the developer manpower to implement and support the necessary userspace libraries.

With Kdbus, userland can just continue to use legacy dbus code that works across all Linux and BSD distros. And the non-systemd distros can use kdbus too by only providing a minimal mechanism that initiates Kdbus at boot.

All in all, the non-systemd distros should really cheer for Kdbus in the kernel, since any other alternative will swamp them with work.

Re:Oh grow up

[DarkOx]

moving it to the kernel will help with performance, and potentially security.

Performance likely, because data can actually be shoveled between processes with probably greater concurrency than with a third user land context in the mix.

Security I don't see how, moving it in the kernel is an improvement. You add all the risks associated with being able to step all over systemically important data structures to a "process" that by definition has to communicate with a largish number of less trusted processes. If you limit who/what is allowed to talk to dbus with a firewall like solution you make dbus less useful as an IPC channel.

  The kernel team tends to be made up of really well qualified people and have more discipline than other OSS projects so in that sense the code quality might go up, but there are probably better ways to accomplish that than merging a project into the kernel!

The performance considerations might be a justification but I have never really seen DBUS as a high performance IPC channel anyway. Maybe I am just badly misinformed on its planned usecases. I thought it was for deriving simple short messages like "A new input device is a available" not shoveling megabytes of data between processes. We have fifo pipes and UNIX sockets for that, and if latency is an issue there is always shared memory.

Re:Oh grow up

[Dog-Cow]

Read the entire LKML thread. You are wrong, but I don't feel like regurgitating several dozen emails in a slashdot post to illustrate why. The link is in the Phoronix article.

Re:Oh grow up

[Anonymous Coward]

I think you've failed to see the point, and grow up all in one post :-)

Re: Oh grow up

[Anonymous Coward]

The more users, the more sheep.

Honestly, I'm not trying to be insulting to either sheep or people, but when you sound like one of the herd, it makes me cringe.

Re:Oh grow up

[Peter H.S.]

Security I don't see how, moving it in the kernel is an improvement. You add all the risks associated with being able to step all over systemically important data structures to a "process" that by definition has to communicate with a largish number of less trusted processes. If you limit who/what is allowed to talk to dbus with a firewall like solution you make dbus less useful as an IPC channel.

Kdbus will really will provide several layers of extra security since LSM's like SELinux can hook into the system from the kernel and not in the much less secure userspace. You also gain kernel guarantee for the message marshalling.

The performance considerations might be a justification but I have never really seen DBUS as a high performance IPC channel anyway.

That is exactly because dbus is extremely slow when it comes to data transport.

    Maybe I am just badly misinformed on its planned usecases. I thought it was for deriving simple short messages like "A new input device is a available" not shoveling megabytes of data between processes. We have fifo pipes and UNIX sockets for that, and if latency is an issue there is always shared memory.

The point is that many developers, especially embedded and IVI (and DE's like Gnome and KDE) are interested in using the same framework for both control and data. Having side channels to dbus in order to gain speed for data means maintaining proprietary frameworks that has to duplicate much of what dbus does anyway.
This will also be a great help regarding sandboxing of applications.
See more here:
https://lkml.org/lkml/2015/3/9...

Re:Oh grow up

[Anonymous Coward]

seems to me that the most important tidbit from that post is:

> Did I miss anything else here? Are there any technical reasons I'm
> forgetting about for why this can't be pulled in as-is for this merge
> window?

****The code has not been meaningfully or properly reviewed.****

Re:Oh grow up

[ckatko]

As a programmer, KDBUS (or any proper IPC system for Linux) sounds really useful.

Here is a write-up on DBUS vs KDBUS for those who are interested.

To sum up: D-Bus is great for sending control messages ("change volume") but not for lots of data (audio streams), it's not available at boot-time (a serious problem if you need to talk to it!), and it's got security flaws. KDBUS is the incremental solution to these problems. A kernel space message sending system that all programs can use at boot to talk to each other.

Re:Oh grow up

[Anonymous Coward]

I agree. As a person who has worked with messaging and object serialization for years, the kernel should provide basic, facilities, which it does. KDBUS is a bad idea.

Re:Oh grow up

[Anonymous Coward]

Last I recall, the kernel is independent of the dist. Why should RedHat be special? That kernel specifically, is version locked to an external program, and vice-versa, is insane. Especially since not all major dists have implemented said program that the kernel would, presumably, be locked to.

I have my own grievances on systemd, but the moment I'm forced into using a specific 'dev manager', and 'initialization' system because of the linux kernel version, is the day I move to *BSD, and never look back!

Re:Oh grow up

[Eunuchswear]

systemd has dozens of zero day remote root exploits

Name one, boring troll.

Re:Oh grow up

[DarkOx]

Thanks for the link very interesting, and helpful. I am not sure I fully buy the security argument, mainly because most of the time I don't see the LSMs themselves adding much value; but the points about DOS resistance and keeping the work load in the senders own timeslice being generally desirable makes sense.

Re:Oh grow up

[Barsteward]

BSD have been working on this... https://github.com/freebsd/ope...

WE DO NOT BREAK USERSPACE?

[Anonymous Coward]

I thought one maxim of the linux kernel was WE DO NOT BREAK USERSPACE.

https://lkml.org/lkml/2012/12/23/75

I cheerished that one, because it meant that I could change kernels without having to care about the userspace applications and libraries.

Now that get flushed down the toilet. That is not linux but lindows thinking.

So fuck systemd, I totally hate it. If Mr. Poettering is bored, then I might suggest he might go back to PulseAudio, which is not in a stellar working condition either.

Re:WE DO NOT BREAK USERSPACE?

[Anonymous Coward]

With "breaking userspace" Linus means the kernel-userspace interface. If userspace components (such as SystemD) are shuffled around, that's a different thing. But do you have some proof that the interface that kernel provides to userspace has actually been broken somehow?

Re:WE DO NOT BREAK USERSPACE?

[Anonymous Coward]

I thought one maxim of the linux kernel was WE DO NOT BREAK USERSPACE.

And the second part goes WE DO NOT FIX USERSPACE EITHER, FUCK YOU NOTHING IS WRONG

STOP LINKING TO PHORONIX

[Theovon]

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.

Re:STOP LINKING TO PHORONIX

[jones_supa]

history of (a) sloppy reporting and (b) completely ignoring requests for making corrections.

So 100% Slashdot-compatible? ;)

Re:Linux 4.2 - merge with Windows!

[Anonymous Coward]

The Windows kernel is actually much more modular than Linux.

ChromeOS Lightbar support should not be in kernel

[iamacat]

For all the noise about systemd, we are totally ignoring the fact that it's the Linux kernel that is the most egregious violation of UNIX modular philosophy. ChromeOS Lightbar has no place in main kernel distribution. System should at least provide enough of a stable binary interface for users to get a binary from outside developer and use it for a couple years. It's not crazy for a non-critical driver like this run in userspace, where a crash is less likely to bring down the whole system.

Anyone interested in learning system programming, or getting their pet gadget to work with Linux, should be able to maintain the project without having to convince Linus Torvalds to take it on or make monthly patches to accommodate ever changing kernel interface. For that matter, someone should be able to write a new kernel and have it work with a decent subset of Linux drivers. In the meantime, core Linux maintainers can focus on fundamental projects like kdbus rather than making LED lights on one particular laptop blink.

99 of the 100 fastest supercomputers in the world

[raymorris]

> Supercomputing? HAH!

Of the top 100 supercomputers in the world, 99 run Linux.

Userspace bleeding into the kernel

[Anonymous Coward]

Someone needs to explain to me how this form of IPC is distinct and better than those already available. Shared memory, memory mapping, pipe, and named pipes have been sufficient for all of the object serialization, and message handling systems I have ever worked with. These facilities are very generic. It seems to me user space is bleeding too deeply into the kernel. The direct dependency of systemd to the kernel revision is horrendous design.

Tme to fire up work on HURD

[Anonymous Coward]

Since Linux is turning into Windows, we might as well start concentrating on the GNU HURD.

Pottering did what Microsoft could not

[Anonymous Coward]

That is, drive a stake into the heart of Linux to kill it. UNIX work-alike, no longer.