Slashdot Mirror

I'm sure RedHat wouldn't mind taking over exclusive maintenance of the kernel. Maybe they have a developer or two that are finished working on certain mature projects. I guess they'd rather have them as kernel developers than what they are doing right now.

Just kidding (maybe)

You're honestly trying to tell me that RedHat can't change the systemd configuration (or code) to match their desires?

Won't, sadly, and for the record... https://bugzilla.redhat.com/show_bug.cgi?id=1304078:

Jóhann B. Guðmundsson 2016-02-02 16:42:09 EST

This got closed as WONTFIX upstream no need to carry on with this here...

Fedora's policy of trying to stay close to upstream is about 15% to blame, and the rest is simply what distros will end up doing: taking the easy path. This is why centralization is a bad thing... It's going from the Bazaar back to the Cathedral in terms of lack of meaningful ability to influence. The "systemd cabal" is exactly that.

The second issue is that Linux is really a fragmented market ....

(I'm no proponent but,) Did you see what systemd wants to achieve?

ROFLMAO. http://0pointer.net/blog/revis...

I am dying inside. LOL Read your words then read that link then read your words again. You just can't make this shit up.

Apparently so. See http://0pointer.net/blog/revis... .

why is this modded troll?
Lennart the great mastermind has announced it on his blog: http://0pointer.net/blog/revis...

It's also in maintaining distinct management tools, configuration analysis, and configuration tools for DHCP, NTP, the new binary logging, space for logging of kernel booting, and whatever other components of the one man band have been added lately. systemd, and especially its core developer Lennart Pottering, are attempting to create a "stateless Linux", and the ramifications are spilling over into other parts of the system.

Quoting from the b log at http://0pointer.net/blog/proje...

> A Stateless System goes one step further: a system like this never stores /etc or /var on persistent storage, but always comes up with pristine vendor state.

That is a _huge_ shift in system management, and directly violates the file system hierarchy where host specific configurations are stored in /etc or persistent data in /var/lib. They're basically taking all the daemon specific parameters from /etc and putting them in /run, and they're going to run into most of the same problems but in unfamiliar layouts. Every component that stores history in /var/lib or configuration in /etc will have to be rewritten, including long-standing conventions such as /etc/hosts, /etc/resolv.conf, and /etc/nsswitch.conf.

He talks about it more here. I will quote him without giving any of my own commentary:

The design of systemd as a suite of integrated tools that each have their individual purposes but when used together are more than just the sum of the parts, that's pretty much at the core of UNIX philosophy.

I would say that he misunderstands the essence, the substance and possibly even the purpose of the UNIX philosophy... but I think he actually does understand. I think he's simply being disingenuous, twisting the definition to meet his desires. It's clear that this is a man who believes that he knows what's good and what's not.

This blog post from last September lays out in perfect clarity how dismissive he is of contrary points of view:

The toolbox approach of classic Linux distributions is fantastic for people who want to put together their individual system, nicely adjusted to exactly what they need. However, this is not really how many of today's Linux systems are built, installed or updated. If you build any kind of embedded device, a server system, or even user systems, you frequently do your work based on complete system images, that are linearly versioned. You build these images somewhere, and then you replicate them atomically to a larger number of systems. On these systems, you don't install or remove packages, you get a defined set of files, and besides installing or updating the system there are no ways how to change the set of tools you get.

[Emphasis mine]

So the toolkit approach is not useful for someone who's deploying large numbers of commodity servers? This defies logic. It implies that somehow it's better to use commodity servers built using Lennart's toolkit than to have the capability to define one's own toolkit to build your own purpose-built standard image.

He's ignoring logic here in order to serve his own agenda, which of course consists of being smarter and sleeker and better than some crufty old Linux with 20 years of barnacles on its hull.

Init on Linux emphatically is ugly, but it's the product of a very large number of people coping with a very large set of circumstances, and finding a solution that is decidedly imperfect, but can be made to address most of the hundreds of thousands of peculiar and unique use cases in the world today.

Quoth Poettering:

The Linux model is the one where you have everything split up, and have different maintainers, different coding styles, different release cycles, different maintenance statuses. Much of the Linux userspace used to be pretty badly maintained, if at all. You had completely different styles, the commands worked differently – in the most superficial level, some used -h for help, and others ––help. It’s not uniform.

This really is the essence of it. When you get right down to it, he's just pissed at having to deal with other people's half-assed implementations of everything, and having to make all the bits work to a purpose. It's just too... democratic. I suspect he feels the same way George W. Bush did when he famously quipped that if he really were a dictator, he'd get a lot more done.

And that's really the essence of the problem. No matter how good systemd turns out to be, it's effectively less than a dozen core committers (the top 10 committers have submitted over 90% of the code) dictating how your modular system is going to run. They want a single group (themselves) and a single philosophy (theirs) to occupy pretty much the entire space between the kernel and userland. And that is not the Linux way of doing things.

/vmlinuz /boot/bzImage /sbin/systemd /usr/bin/emacs -> /sbin/systemd

You think I'm kidding... Here, in Lennart's own words:

http://0pointer.net/blog/revis...

If you want to know the impetus behind systemd, why not go to source. Lennart lays out the problems he was trying to solve and the design process on his blog. Specifically, the intro post and biggest myths rundown would a solid positive case for the approach and technology.

If you want to know the impetus behind systemd, why not go to source. Lennart lays out the problems he was trying to solve and the design process on his blog. Specifically, the intro post and biggest myths rundown would a solid positive case for the approach and technology.

Apple is not the developer of CUPS. Apple bought CUPS back in 2007 and hired its main developer.

So... the guy that works on it is hired by Apple, and the project is owned and financed by Apple. Isn't that essentially the same as Apple develops CUPS?

No. If Apple had developed it, it would not have had any command-line interface except for XML files and the "defaults" program, its interfaces would have been proprietary to Apple, and it would have been even more confusingly documented. It would never have become widely adopted across the Unix world, partly because Apple would not have chosen GPLv2. Instead, Lennart Poettering would have been so in awe of it that he would have created his own unstable version of it, which would immediately have been adopted across the Linux distributions to the exclusion of any other printing system, because Lennart is the best programmer and all crashes are everybody else's fault. It would have stabilized when he got bored and started copying another Apple innovation. Like, say, launchd.

CUPS was widely used before Apple bought it. Apple can't turn it into an Apple-like program without causing a user revolt, so it's still very much like how it was before Apple bought it.

Nope, I just read the article, and clicked through to others, and couldn't figure out the purpose of this.

I did find this article, where Poettering mentioned "The systemd cabal .... recently met in Berlin." I know it's not nice to make fun of non-native speakers, but calling it a cabal makes it sound so sinister.

Did you read the article? He wants to embrace and extinguish the distros too.

Nope, I just read the article, and clicked through to others, and couldn't figure out the purpose of this.

I did find this article, where Poettering mentioned "The systemd cabal .... recently met in Berlin." I know it's not nice to make fun of non-native speakers, but calling it a cabal makes it sound so sinister.

I'm not talking about *init systems* - systemd was never "just an init system". Remember, it's absorbed stuff like network management and system authentication. That kind of feature often requries linking to (L)GPL code, and you can trigger the GPL's requirements depending on how you do that.

So Poettering wants to move all those function calls to (k)dbus. In his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

That's exactly my point. I'm suggesting the goal is to avoid making a derivative work. The GPL describes various ways to recognise a project as having "derived" from covered code, and linking copyleft and proprietary code together is one of them. (with some variation depending on if we are talking GPL or LGPL).

Remember that one of Poettering's goals is, in his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

The point is if I want to do (for example) some sort of user authentication, I may have to link against libpam.so. This is something that would be reasonably commoon in embedded systems, and linking covered code into your embedded device (and having to distribute libpam.so with your product) could easily be a derivative work. (details matter, ask your lawyer about specific projecs).

Once absorbed into Poettering's project, you avoid all that risk because you don't interface with the system features directly and instead use "local RPC". This changes the project from being a potentially infringing derivative work into something that merely uses the tool. Merely using a tool that is licenced under the GPL is explicitly excempted, as the GPL only coveres redistribution and not use. ("GPL is not an EULA") This is a major change in legal status for your typical embedded device, which often wants a minimal OS to host their embedded app. They would also really like to avoid having to deal with the handling anything GPL. Changing to "local RPC" for all system interaction neatly fixes that problem.

We don't run across this pattern with traditional RPL tools, because it's bad for performance to needlessly serialize everything when you could simply call a function directly.