Slashdot Mirror

And if I want to replace one of those 40 independent executables with my own, I just do so, right?

Yes you can certainly do that if you want to.

The documentation clearly describes their input and output, so that they truly ARE independent?

There is extensive documentation and further to that the code is available and open source. Another good way to get involved is write the docs. Documentation is very often lacking in virtually all open source projects.

They are a big mass with interdependent states.

What do you mean? There is no shared state and the fact that they are separate programs is part of what creates that separation of state dependence. Perhaps there is a misunderstanding here so can you provide an example of systemd executables that illustrates what you mean?

And there are no discernible pros to binary logs.

As the OP noted, you can simply use text mode if you prefer.

If you really dont like it then thats fine, that is the beauty of free software in that anybody can fork a project and do what they like. It just seems very suspicious when people get abusive toward others that are exercising that freedom, you were certainly free to fork the pre-systemd version and free to try to present a coherent argument to others to support your fork rather than the systemd fork. The problem is the systemd proponents went in one direction and rather that doing something and going in a different direction the systemd detractors followed the proponents and continued complaining and hurling abuse at them. A small group went off and developed devuan so this really should be a non-issue but the detractors still seem to be angrily following the systemd proponents like a bunch of hypnotized sheep rather than supporting the devuan folks (or various other non-systemd distributions).

That is true, when he started designing it, Lennart had Apple's launchd in mind.

I'm sure the systemd developers had those thoughts too when they started out. :-)

No, they didn't. You can see the documentation and ideas that were floating when systemd started. The concept is all about features, lots of them, and security is mainly mentioned as something the kernel will do. Minimalism isn't on the menu.

Contrast that with WebAssembly which takes years to add features that clearly need to be there (like access to the DOM), because they know it's better to do it right than half-assed.

Remote exploits in critical system services? I expect nothing less from the PulseAudio creator.

If you're not familiar with smoke any mirrors from the SystemD PR king, then perhaps these inherent flaws in his projects comes as a surprise to you. But for years a handful of people tried to put the brakes on Poettering and his cronies from hijacking Linux and turning it into his egotistical vision of desktop Unix.

We have failed.

"This is specifically wrong. systemd was designed to implement specific features, not to replace init. " - can you provide a link where that was said? Have you read this ? http://0pointer.de/blog/projec...

I've noticed the guys working for me just can't grasp the concept of this: systemctl start openvpn@server.service

That is an example of instantiated services which are a pretty handy feature.systemd.unit(5) documents this feature. If your 'guys' aren't into reading manuals for the tools they use, it's not that hard to figure out what's going on just reading the openvpn@.service file.

We use four different Linux distributions and six other UNIXes, so that small inconsistency turns into a big thing.

systemd is becoming standard, so there will be *fewer* inconsistencies between distros. One of the biggest drivers behind all the systemd hate seems to be resistance to learning new things, which is a shame because systemd is actually pretty cool.

That's funny given that it was primarily designed with servers in mind.

Not sure that's true. It was inspired by launchd from Apple (specifically this video). Personally I think launchd is cleaner, but that's partly because Apple has full control of the ecosystem.

it's has some overlap with macOS (but systemd does more).

In fact, systemd is completely, and unabashedly inspired by OSX, as can be seen in this blog post. Specifically, this video was inspiration for systemd. That is not necessarily a problem, it's good to share ideas around.

Hmmm, "launchd" is awfully close to the spelling of "systemd", should I be concerned and/or outraged?

Well, you definitely should not be surprised.

(I.e., Lennart likes the idea of launchd.)

This is sequential and not parallel.

Executing in sequence and running in parallel are two different thing. The processes are spawned as background tasks. Init does not wait for them to complete before spawning the next. That is how init works and any code trying to do the same thing will use a similar method to do it. Parallelism is driven by process allocation to a core by the kernel after the process is spawned. init does not wait for them to complete before starting the next one.

SysV init replacements are a superset of init's features, so the use cases are broadly the same, however the environment has changed quite a bit:

It would be truer to say the perception has changed.

hotplugging of various devices is far more common, changing networks, and so on. We're also seeing a rise in containerized applications and virtualization. Computer systems are becoming very complex, so we must decide where that complexity should be located.

Complexity is relative. They are no more or less complex than they ever have been. All you are speaking of is context.

The obvious choice for this type of task is to abstract the common functionality into a shared library. There is not really any way to do that and keep init small: the complexity must exist somewhere,

This is an argument to justify the existence of systemd, not one that is a design limitation of init. i.e. you haven't considered *how* to achieve this in init by breaking down the complexity.

and it makes no sense to have init exist simply to kick off the "real" service manager.

Why? Do you propose changing from systemd to something else when the use cases change again? Seems completely appropriate for init to start a service manager (or a runlevel manager) that can compartmentalise different type of services appropriate to the context of the system.

So the question is not really "what use cases are there?", but "what should init do?",

Exactly what it does. All of the functionality you speak of should be handled by something else. If an input controller from a touch screen fails, it doesn't mean init should manage input controller functionality.

and again, the consensus for the last couple decades is to move functionality from scripts to the service manager, instead of relying on each and every script to do things correctly.

No argument from me that rc scripts are used incorrectly - you are arguing about how inits *support* functionality is used incorrectly.

The most basic task seems to be dependency resolution: it's simpler to add markup to a script that tells the manager what it needs than to write dozens of lines of code trying to figure out if ServiceA and InterfaceB are up.

So instead you are talking about writing thousands of line of code to do that. You are saying that the kernel should start a service manager instead of a process manager.

I don't disagree about the issue, I disagree with the proposed solution. What you are arguing is that because people didn't use init properly in the first place which accumulated all of this technical debt, the proposal is to solve that by introducing even more technical debt.

I'd be in favour of a campaign to reduce that technical debt because it will make for efficient fast systems.

Starting services in parallel is another obvious improvement. Socket activation is also beneficial.

The article you link to shows a misunderstanding of how init works. It only talks about rc script functionality of init - not init functionality. Everything that systemd subjectively shows started in parallel can be started in parallel by init as well.

Init/inittab was intentionally simple. I

I've just read the source of the Linux/BSD sysvinit package. Unless I am reading it wrong, it uses a simple for loop to iterate through the inittab entries. This is sequential and not parallel.

SysV init replacements are a superset of init's features, so the use cases are broadly the same, however the environment has changed quite a bit: hotplugging of various devices is far more common, changing networks, and so on. We're also seeing a rise in containerized applications and virtualization. Computer systems are becoming very complex, so we must decide where that complexity should be located. The obvious choice for this type of task is to abstract the common functionality into a shared library. There is not really any way to do that and keep init small: the complexity must exist somewhere, and it makes no sense to have init exist simply to kick off the "real" service manager.

So the question is not really "what use cases are there?", but "what should init do?", and again, the consensus for the last couple decades is to move functionality from scripts to the service manager, instead of relying on each and every script to do things correctly. The most basic task seems to be dependency resolution: it's simpler to add markup to a script that tells the manager what it needs than to write dozens of lines of code trying to figure out if ServiceA and InterfaceB are up. Starting services in parallel is another obvious improvement. Socket activation is also beneficial.

Init/inittab was intentionally simple. It will start processes for you -- unless they have dependencies. It will restart processes for you -- blindly, and it will block any other tasks while it does so. I'd be willing to bet most of the SysV init scripts written re-implement some feature that inittab provides. Frankly I don't know why you would try to argue that 7k lines of code ought to be good enough for anyone.

RTFM! ;-) (I've always wanted to say that. I don't think I've ever actually said it - in referencing the actual man pages.
http://www.freedesktop.org/sof...

Fedora's got a good bit of documentation on it that goes beyond just the man pages:
https://fedoraproject.org/wiki...

I'm generally a Lubuntu user so:
https://wiki.ubuntu.com/system...
https://wiki.ubuntu.com/System...

That last link is really pretty good - it doesn't look like it, judging by the URL, but it's pretty good at giving some info. From the second link, the one to the Fedora site, there's a link on that page that's actually pretty good. It's worth a read and it's explaining why they, the Fedora project, are going (went) with systemd. I'll save you the time and add a direct link to that as well.
http://0pointer.de/blog/projec...

I paid for my copy, it's paper, but this site claims that is Creative Commons and has a link to both the book and the web code examples, it appears to be legit so I'm going to go ahead and link it. It's the 2015 (9th Edition) Linux Bible. I own a copy, as mentioned, in dead tree format and have been happy with it as both a browse/read and reference book. It has some information about systemd in it as well. You can download the copy and code examples, free of charge, at this site:
http://appnee.com/linux-bible-...

A quick look says that it's the same as my paper book so I'm assuming that the content is the same.

Keep in mind, I'm not a systemd aficionado or anything. I've just never had cause to hate it like everyone says I should. So, I did a bunch of reading and I've done a bunch of thinking, some poking and testing, and haven't had a problem with it. I learned a few new commands, they've come in handy, and I'm pretty happy with it - so far.

User phantomfive (here on this site) has been doing a code review of it. I believe he's at section 12 now. That might be worth a read. You can get to his account easily enough by simply changing the URL. This should work: http://slashdot.org/~phantomfi... and you can get to his journal from there. The navigation will be on the left but I suspect you know that.

If you need stuff to "just work please and thank you" then, well, my experience has been that it just works. I, too, am no expert and have been learning more and more as I go - that's exactly why I switched to using Linux exclusively. I simply wasn't learning anything any more. I was stagnant and, well, there wasn't much more to learn about Windows. I'd already done the MVP thing, I'd been awarded the award multiple years in a row in several categories. I gave up my participation, burned out really, and just paid for my own damned MSDN subscription. So, it's been serving that purpose nicely for a while now. I'm getting older, to the point where it's time for me to legitimately worry about maintaining cognitive functions. I'd become lethargic, a passive consumer, and was not happy with that state of affairs. Thus, the switch and the ensuing switch to using it exclusively because I found that, even dual booting, I'd still just boot to Linux and I rebooted so seldom that I was often in the middle of something and needing to return to Windows to finish it. So, Linux it is... I had managed Unix just fine, so off I went... It's been a fun ride.

As an interesting (to me) aside: It's amazing how quickly things become normal. I had the opportunity to sit in front of a Windows 10 system for a brief spell. I was lost for a while. I've also had one occasion to sit in front of a more familiar Windows 7 system and, still, I was lost. I'd actually f

This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.

An init system shouldn't be doing that stuff. You know how sometimes people complain that "systemd is monolithic?" That is what they are talking about: you can't get that stuff separately from your init system.

Then people saying that are wrong, as this functionality is not in the init system. It is in several parts (so not monolithic), logind being one, and logind is assisted in the task by dbus and systemd init, which themselves are assisted by the Linux kernel.
This assistance and dependencies are necessary to assure a minimum of security.

why not do some research before typing? Don't rely on what any poster says. Try here as a start http://0pointer.de/blog/projec...

If you don't like systemd, use Freebsd. systems without cannot be considered Linux, developers should remove compatabilty for non-systemd Linux asap. "systemd... not just an init system anymore, but the basic userspace building block to build an OS from" "building a simple OS based on systemd will involve much fewer packages than a traditional Linux did. Fewer packages makes it easier to build your system, gets rid of interdependencies and of much of the different behaviour of every component involved." Source: http://0pointer.de/blog/projec...

This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.

An init system shouldn't be doing that stuff. You know how sometimes people complain that "systemd is monolithic?" That is what they are talking about: you can't get that stuff separately from your init system.

The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

The Biggest Myths

[2013]

You're beta testing this bullshit.

Then you are in damn good company.

Much of the debate about systemd is academic at this point because here's a truth that you'll discover in Debian 8, Ubuntu 15.04, and just about every other major distro around: systemd is here.

Debian 8: Linux's most reliable distro makes its biggest change since 1993 [May 1, 2015]

Red Hat is the inventor and primary booster of systemd, so the best distros for playing with it are Red Hat Enterprise Linux, RHEL clones like CentOS and Scientific Linux, and of course good ole Fedora Linux, which always ships with the latest, greatest, and bleeding-edgiest.

Understanding and using Systemd

systemd is not an init system. It's a service manager. Mischaracterization makes your opinions seem ignorant.

Nothing more hilarious than "correcting" someone and getting it wrong!

Don't take it from me - cure your ignorance by reading what Lennart wrote about his init system at the early stages:
http://0pointer.de/blog/projec...

Instead of just making things up why don't you read what was written at the time - it's still on the internet
http://0pointer.de/blog/projec...

"are systemd service descriptor files distribution independent?" see Point 21 here, it might answer your question. http://0pointer.de/blog/projec...

You should be able to take advantage of all of systemd's features whether the daemon is designed to be run from an init script or not, and even whether it is run from an init script or not. If not, there is either something deeply wrong with you (incompetence) or deeply wrong with systemd (poor design.)

Yeah.... http://0pointer.de/blog/projec...
See the part where it's talking about forking vs non forking.

Key features like dependency management, whether a service terminated with an error condition, and what to do when a service terminates are things that you CAN NOT DO if all you have is an init script.

I've used it in production for five years (5!) now. Just because Debian is slow to adopt new technology doesn't mean that it's untested. People have used systemd in real-world production systems on other distributions since 2010, and has been around for a couple of years before that.

Really, that long? Funny, because according to the systemd Wikipedia page the initial release was March 30th, 2010. The Wikipedia page itself wasn't started until August 2010, and Poettering's systemd announcement, where he mentions having an "experimental" init to compete with upstart (which had been around years before systemd) is dated April 30th, 2010.

That means that, no, it wasn't around a "couple years before" 2010, and wasn't added to any distro repositories until a year later, so your claim to have been using it on "production systems" for "five years now" is just as much bullshit as the claim that systemd existed years before 2010.

The only way you've been using systemd in production that long is if you're from the future and using systemd-timetraveld.

So, what systemd things have access to the network?

PID 1
http://0pointer.de/blog/projec...

You're clearly getting recalcritant in your dotage. SysV init was unportable (esp. between distros) and unmaintainable, and founded upon bad hacks like pidfiles. Systemd is fundamentally not about faster boot, that's just a strawman you've set up. The road to systemd began with a need for process tracking. To work well, this has to be done in cooperation with the kernel, and such projects have a long history: cgroups are merely the most recent / most successful. I'd give you a history lesson, gramps, but you should probably either give this one up for want of intellect, or get it from the horse's mouth.

Right now systemd can already be used as a drop-in replacement for Upstart and sysvinit (at least as long as there aren't too many native upstart services yet. Thankfully most distributions don't carry too many native Upstart services yet.)

Somehow he didn't recognize that "easy to replace" is a virtue of good software design, even though he benefited from it.

Thanks, that's interesting. I always thought one of the strengths of Linux was that the OS was highly separated from the GUI.

Don't believe him, what he says is demonstrably untrue. Both KDE and Gnome runs just fine on non-systemd distros and on BSD. This couldn't happen if they somehow where totally dependent on systemd.

The real story is that systemd provides some very needed OS infrastructure that Desktop Environments (DE's) like KDE and XFCE needs. The old non-systemd infrastructure that DE's could use instead, like ConsoleKit (CK), hasn't been maintained for years. The DE developers have warned the non-systemd distros for years that they needed to maintain CK, or that things would stop working, but they were ignored.

So Gnome, KDE, XFCE etc. still have support for non-systemd distros that are using eg., CK's login API, but things are beginning to fall apart since nobody have bothered to maintain that for years.

The point is that that Gnome and KDE played no role in why all major Linux distros have shifted to systemd. The simple fact is, that systemd simply is light-years ahead of any competing init-system; integrated groups support so each and every process can be controlled regarding resources, no more hard to write and debug shell scripts to start daemons (executable config files; who thought that was a good idea?), integrated kernel Capabilities(7) to provide defence in depth for all running daemons etc.

Read here for more reason to what systemd can and why it was developed:
http://0pointer.de/blog/projec...

You should not use it. Developers should use it. If you're an end-user use what comes with your distribution.

You're looking for a reason to be afraid and/or outraged. You must be, because almost all of the Linux distros have seen sufficient technical advantages to systemd to switch to it. If you haven't heard about these technical reasons, you're self-selecting against this information. It's okay, everyone does it, but in this case the majority of technical experts are for systemd, and that's prima facie evidence that the opposing information is lower-quality. Be aware of what your influences are.

http://0pointer.de/blog/projects/why.html

https://wiki.debian.org/Debate/initsystem/systemd

Init is a misnomer; we're talking about the thing that starts and manages services and runlevels. Init is part of that. As a service manager, sysvinit fails badly. Starting a service on linux involves double-forking and writing your process number to a file, and hoping that file is still accurate when you want to kill the process. See here for an example. All of those steps must be implemented by every service, and the logic for doing so is duplicated across every service — hopefully correctly. There are quite a few things that can cause the pidfile not to be accurate, at which point init can't do anything with it. Also, because sysvinit is just a collection of scripts, [a] they're all run in sequence, and [b] when problems happen, the script exits with a non-zero return value. If you need anything more than a non-zero return value you'd better roll it yourself.

Cgroups were invented to fix this, because you need kernel cooperation to track processes accurately. Systemd was invented to manage services using cgroups, and is heavily influenced by OSX's service manager. For a more thorough investigation about the rationale behind systemd's features, collectively and severally, please see Poettering's blog (https://0pointer.de/).

Sysvinit is really good for people that need to script every aspect of their OS. Some of these people are sysadmins who think that scripting is actually their job. Some of these people think that scripting is what Unix is all about. These people are generally bad programmers who forget that Unix is also about cleaning up scripts and rewriting them in C. Init scripts are easier to debug, but most other OSes seem to get by without anyone needing to debug init scripts.

Also, if you've ever worked with chroots, check out systemd's containers; they are a major feature and quite nice to use.

You should not use it. Developers should use it. If you're an end-user use what comes with your distribution.

You're looking for a reason to be afraid and/or outraged. You must be, because almost all of the Linux distros have seen sufficient technical advantages to systemd to switch to it. If you haven't heard about these technical reasons, you're self-selecting against this information. It's okay, everyone does it, but in this case the majority of technical experts are for systemd, and that's prima facie evidence that the opposing information is lower-quality. Be aware of what your influences are.

http://0pointer.de/blog/projects/why.html

https://wiki.debian.org/Debate/initsystem/systemd

Init is a misnomer; we're talking about the thing that starts and manages services and runlevels. Init is part of that. As a service manager, sysvinit fails badly. Starting a service on linux involves double-forking and writing your process number to a file, and hoping that file is still accurate when you want to kill the process. See here for an example. All of those steps must be implemented by every service, and the logic for doing so is duplicated across every service — hopefully correctly. There are quite a few things that can cause the pidfile not to be accurate, at which point init can't do anything with it. Also, because sysvinit is just a collection of scripts, [a] they're all run in sequence, and [b] when problems happen, the script exits with a non-zero return value. If you need anything more than a non-zero return value you'd better roll it yourself.

Cgroups were invented to fix this, because you need kernel cooperation to track processes accurately. Systemd was invented to manage services using cgroups, and is heavily influenced by OSX's service manager. For a more thorough investigation about the rationale behind systemd's features, collectively and severally, please see Poettering's blog (https://0pointer.de/).

Sysvinit is really good for people that need to script every aspect of their OS. Some of these people are sysadmins who think that scripting is actually their job. Some of these people think that scripting is what Unix is all about. These people are generally bad programmers who forget that Unix is also about cleaning up scripts and rewriting them in C. Init scripts are easier to debug, but most other OSes seem to get by without anyone needing to debug init scripts.

Also, if you've ever worked with chroots, check out systemd's containers; they are a major feature and quite nice to use.

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.

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.

its mainly down to ignorance of what systemd does, can do and doesn't do. most of the negative posts about systemd are based on some trolls misinformation (either deliberate or just plainly ignorant because they haven't done any research) . its "change" and change makes a small amount of people wet themselves and they cry louder than people who are not against change. here's a page to read that had to be created to try and cut through the crap spouted on these forums http://0pointer.de/blog/projec...

Upstart has serious, known design flaws that cannot and will not be fixed. It will not be adopted for real technical reasons. Shouting slogans doesn't change the technical issues.

See: http://0pointer.de/blog/projec...

SysV is the weird monster that this thing is finally saving me from. You can't force me to keep using that old crap, and you can't force systemd not to replace it for me.

Ok so reading the slides they're planning on doing network management (byebye NetworkManager), Local DNS cache (yes please), mDNS responder, LLMNR responder, DNSSEC verification, NTP, sandboxing services and applications, OS/App/Container image formats, stateless systems, atomic node initialisations and updates and more. That is freaking awesome. Not only does it bring Linux distributions closer together.. it also takes the distributions as a whole to a new level. Instead of a kernel + some packages the future will bring us a true (GNU/)Linux/systemd operating system. I can understand this may seem scary to some but personally I really think this is awesome.

Why do they need to reimplement all these things?

I use unbound for DNS, and it's great. It provides caching, DNSSEC, and more. It's a mature, stable project. Why rewrite it?

Same with NTP. Why do they need to sprinkle SysD dust on it? We already have NTP.

I hate NetworkManager, and I'm sure I'll hate whatever SysD project rewrites it. My desktop has a static place in the network. I don't need some bloatware screwing with all my network settings and crashing all the time.

This is one thing I don't like about systemd. All the selling points (e.g. almost everything at http://0pointer.de/blog/projects/why.html) seem to be either:

• Things I do not want or need, or
• Things I already have, that are reimplemented "the systemd way."

Another troubling thing is that I've never seen a good description of what "the systemd way" is, or what the grand vision is. It seems to be nebulous, constantly shifting, and constantly expanding with no clear boundaries.

Some people dislike systemd because they can see where it is headed. Here is your sign.

Skimming that pdf is insightful. It promises magic unicorns from systemd, and raves on about using it to "build products" (what f*ing products and for whom?) and "the next generation OS". Such rhetoric is typical of GNOME-world megalomaniacs, those that force-fed us that new UI of early Gnome3. I distrust it immensely.

Tablets, phones, and quite a lot of embedded systems runs Linux.

Thanks, but I'd be surprise if that happened.

1. You may have noticed that the "story" submitter is Jaromil, so I suspect (extrapolating from experience) he's accompanied by his sock puppet army (do they imitate the NSA with forum flooding and FUD techniques, or does the NSA imitate them?)
2. I've always suspected that the NSA is actively involved in ceasing this opportunity to divide Debian, if not celebrating the number of senior Debian developers who have left due to the number of personal attacks and threats they've recieved from the "anti-systemd" "campaign"

Jaromil does some excellent graphic work - but his musical ability is more autistic than artistic, allowing for a broad spectrum of tastes... and his "software accomplishments" is less than truthful (his hasciicam program lacks truthful attributions to it's true basis, and his Dyneobolic distro is just one of very many "respins". Not a patch on Knoppix - which is the work of one person , or a shadow of Mint and other Debian derivatives. There have been many Debian fork attempts...

Some vaguely related trivia regarding your pseudonym. Unix was a joke name chosen by the developers of Multix - the operating system that was intended to "do everything", when their funding was cut. Eunuchs/Unix was the result. Linux was the name given to Linux Torvalds to create a non-Unix compatible kernel.

apt-get install sysvinit-core

Some people dislike systemd because they can see where it is headed. Here is your sign.

Skimming that pdf is insightful. It promises magic unicorns from systemd, and raves on about using it to "build products" (what f*ing products and for whom?) and "the next generation OS". Such rhetoric is typical of GNOME-world megalomaniacs, those that force-fed us that new UI of early Gnome3. I distrust it immensely.

general push back against something new, read this page to see what nonsense is thrown at systemd http://0pointer.de/blog/projec..., you can skip most of the trolls in these systemd forums as most of them are just regurgitating nonsense that they haven't checked out against the facts

Some people dislike systemd because they can see where it is headed. Here is your sign.

The goals of systemd

Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.

That's not even necessary - to close source it - since they can just end up as the only source of signed Linux binaries that run on a critical mass of manufacturer's computers, which require it on their UEFI Secure Boot systems. This is one of the goals of systemd. As outline their own presentation.

Never mind that with systemd, it goes beyond init. systemd as a project are sprouting tentacles everywhere, and projects closer to the user (Gnome for instance) is strongly encouraged to latch on.

This kind of tight coupling is unheard of in Linux history.

Yes, but it's required for the goals of systemd, which include being able to have signed binaries and control of the OS from the firmware all the way up to to user programs and everything, like an Apple walled garden or Windows 8 on secure boot. If you don't believe that's the goal, feel free to check out the Presentation on a perspective systemd for yourself, especially page 6 and the last page.

Nothing like that happened. It was introduced in the form of launchd a decade ago by Apple. Some people from the Linux community started to port it over. RedHat supported it. Ubuntu disagreed and Gentoo disagreed both creating alternatives. Their alternatives ran into problems and systemd pulled ahead quickly. It got adopted by a standard and then distributions started picking it up. Debian being one of the last.

Sorry, but this "just ain't so". On April 10 2010, in his article entitled "Rethinking PID 1", Poetering wrote:

Facts are facts, and we can't bend them to suit our purpose, or make up history as we go along.

Odd that of all possible choices, systemd developers chose almost
always a way that is exactly the same or very similar to what Debian does.
For example, I don't see stuff like /etc/sysconfig, while I do see things
like /etc/hostname etc.

Everybody else has /etc/hostname too, sorry to pop your fanspiracy.

Let me quote from the
biggest myths:

Now, as it turns out, more frequently than not we actually adopted schemes
that where Debianisms, rather than Fedoraisms/Redhatisms as best supported
scheme by systemd. For example, systems running systemd now generally store
their hostname in /etc/hostname, something that used to be specific to Debian
and now is used across distributions.

Maybe the example was too subtle, but for sure there are some things from /etc/sysconfig that are gone from Red Hat, and are substituted by
Debian-style configuration.

Sorry, redhat has had /etc/hostname since the 90s. As for /etc/sysconfig, I have a systemd distro from the RedHat family, and it still has /etc/sysconfig too.

You quote the least important part of that passage, and I think it has a very different flavor when the whole thing is quoted:

One goal of systemd is to unify the dispersed Linux landscape a bit. We try to get rid of many of the more pointless differences of the various distributions in various areas of the core OS. As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration. This is never exclusive though, distributions can continue to deviate from that if they wish, however, if they end-up using the well-supported default their work becomes much easier and they might gain a feature or two. Now, as it turns out, more frequently than not we actually adopted schemes that where Debianisms, rather than Fedoraisms/Redhatisms as best supported scheme by systemd. For example, systems running systemd now generally store their hostname in /etc/hostname, something that used to be specific to Debian and now is used across distributions.

So "more frequently than not" isn't the same as "almost always," /etc/hostname was probably a clumsy example since RH already had that file, which is read as configuration by other programs, but not usually what is setting it. But the point is that they have an agenda of pushing towards consistent configuration, and to do that by setting defaults. Because those are often the easiest to standardize on. They don't go into the why. I would speculate that since RH is perceived as being behind systemd already, and Debian fans won't complain as much about Debianisms as RH-isms, it is simply more down-hill to standardize in that direction. Because where these differences exist, all the variants have been proven to work, so the difficulty of adoption is the more critical thing.

It certainly undercuts the RH-ism complaint, the only problem is that it is standardization that the complainers are against. They don't want the distros to get locked into having the same setup as each other. What really destroys the complaint though is that these are only defaults, not requirements. I would not be at all surprised if a future Debian wants to move away from the Debianisms because they're hated by users as RH-isms as soon as somebody says, "well we can't change it because it is standardized."

None of the involved parties are trying to make standardization required, and they're not trying to choose the best configuration system either. That is why it is going to be hard to stop them from improving defaults.

That's far too reductionist. For a start, there are many sysv-compatible init implementations that do parallel boot; upstart does it, Mandriva's pinit does it. There's a whole subset of LSB that exists exclusively to provide a way for sysv initscripts to represent dependencies *precisely in order to enable parallel init* - see https://wiki.debian.org/LSBIni... for a good write-up of that.

Secondly, insofar as systemd is intended to improve boot speeds, it wasn't actually just about implementing simple parallelization of sysv-style services using dependencies. If you read http://0pointer.de/blog/projec... it talks a lot about parallelization but it's actually talking about making *more* parallelization possible, not just *implementing* parallelization: the big idea Lennart had back then was the idea that you don't actually have to completely start up a service in order to start up another service that 'requires' it, if you can create the socket it listens on before it's ready, then queue up any requests and pass them on to the service once it's actually done starting up. Lennart was clearly really excited about this idea at the time, but if you look at systemd these days, it's a really pretty small corner of all the things it does.

All the way through the first part of that first post, Lennart is really talking about making more parallelization possible, he's not simply talking about implementing inter-service dependencies.

These days systemd does an awful lot more, and it really isn't just about making boot faster any more. Even in the very first post, once you get past the first half, it starts talking about improved capabilities. I find startup speed the least interesting thing about systemd, really, I'm much more interested in the improved capabilities for units and especially in the improved logging journald provides.

Odd that of all possible choices, systemd developers chose almost always a way that is exactly the same or very similar to what Debian does. For example, I don't see stuff like /etc/sysconfig, while I do see things like /etc/hostname etc.

Everybody else has /etc/hostname too, sorry to pop your fanspiracy.

Let me quote from the biggest myths:

Now, as it turns out, more frequently than not we actually adopted schemes that where Debianisms, rather than Fedoraisms/Redhatisms as best supported scheme by systemd. For example, systems running systemd now generally store their hostname in /etc/hostname, something that used to be specific to Debian and now is used across distributions.

Maybe the example was too subtle, but for sure there are some things from /etc/sysconfig that are gone from Red Hat, and are substituted by Debian-style configuration.

Running Debian in lxc has nothing to do with systemd's nspawn. The post you're replying to is a complete non sequitur.

There's a few different ways to do chroots, most of which are functionally equivalent. Systemd's cgroup functionality promises to be more secure in the long run (not necessarily the current implementation), and it does seem to have an advantage in simplicity. The other side of the coin is making complicated things possible, and while I've never had to do anything complicated with a chroot, you do have lots of flexibility in putting one together the "normal" way. Mostly I think that is rope to hang yourself with, but you never know. However, one thing that is specifically enabled by systemd is the ability to start a container based on a network request, which is possible with other solutions but not necessarily easy or all that useful (in the event that latency is a factor).

captcha: contain

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.

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/