Lennart Poettering Announces the First Systemd Conference

jones_supa writes: Lennart Poettering, the creator of the controversial init system and service manager for Linux-based operating systems has announced the first systemd conference. The systemd.conf will take place November 5-7, in Berlin, Germany. systemd developers and hackers, DevOps professionals, and Linux distribution packagers will be able to attend various workshops, as well as to collaborate with their fellow developers and plan the future of the project. Attendees will also be able to participate in an extended hackfest event, as well as numerous presentations held by important names in the systemd project, including Poettering himself.

Comments

Obligatory

[pushing-robot]

https://www.youtube.com/watch?...

Re:Obligatory

[Camel Pilot]

Is this a clip from the last systemd conference?

Startup management subsystem

[QuietLagoon]

If a startup management subsystem needs its own conference, it is doing too much.

Re:Startup management subsystem

[TWX]

Then how are devs supposed to get sponsored vacations out of their benefactors?

I've noticed a trend- conferences that are paid-for by third-parties that sponsor the attendees, be they employers or charities or governments, are usually held in places where people want to go, while conferences that are paid for by the attendees themselves are usually held in less-desirable places or times (ie, winter in Minneapolis or summer in Phoenix). If the attendees are sponsored they go whole-hog, and if they pay themselves the venue tends to be the cheapest possible.

I wonder which Berlin is in November? I've never been there myself.

Re:Startup management subsystem

[EmperorArthur]

It does seem a bit much, but the systemd transition is a slow one. Many packages are still using init.d startup scripts, which means we can't take advantage of systemd's features with them.

Systemd isn't really a startup management subsystem. It's a full blown service manager. It can be set, at the user's choice, to restart services when there's a problem. It can provide detailed logs from each service.

The best part is the service descriptor files follow a standard. If all people did at this conference was convert package init scripts to systemd I would be ecstatic.

Re: Startup management subsystem

[Threni]

Doesn't Linus like it though?

Re: Startup management subsystem

[Anonymous Coward]

Linux already had a service manager. It was called inetd. No one used it because service managers are useless

Re:Startup management subsystem

[drinkypoo]

It does seem a bit much, but the systemd transition is a slow one. Many packages are still using init.d startup scripts, which means we can't take advantage of systemd's features with them.

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

Re:Startup management subsystem

[QuietLagoon]

Systemd isn't really a startup management subsystem. It's a full blown service manager.

OK...

.
If a service manager subsystem needs its own conference, it is doing too much.

Re:Startup management subsystem

[jedidiah]

You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.

Re: Startup management subsystem

[Anonymous Coward]

He didn't have a massive technical problem with it, as a init, at present.

He was wary of some of the personalities in charge though (him and Sievers has had some colorful exchanges on the LKML).

There is another kernel dev that don't seem to amused with Systemd though.

https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU

Re: Startup management subsystem

[phantomfive]

Here is what Linus himself had to say about it:

"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."

Re: Startup management subsystem

[gweihir]

Indeed, they are. At least those integrated into the system. I found that whenever I implement some service, I need special things for monitoring and restarting it anyways. It is really not hard doing your own service manager that then just gets started by init.

Re:Startup management subsystem

[Barsteward]

"If all people did at this conference was convert package init scripts to systemd I would be ecstatic." - that is happening all the time anyway because once they are all starting via systemd, the config files can be given to every distro that uses systemd because they will all work across all the distros unlike init scripts which you have to modify for that distros particular set up. You'll have to make noises to the individual companies that sell programs on linux to provide their own systemd config files.

Re:Startup management subsystem

[gweihir]

Fascinatingly, none of the self-destructiveness claimed by the systemd fanatics against the systemd opponents has ever manifested itself. Maybe it is just propaganda?

Re:Startup management subsystem

[bill_mcgonigle]

I tried to register for it, but the system said no tickets were available. I sent in a note about that and got a response saying that ticket availability wasn't in the plans and that I was stupid for wanting one.

Re:Startup management subsystem

[Barsteward]

the AC is one thats got the issue of pronouncing vague and empty comments and they don't require an answer, my response stands. All he has to so is search out the systemd webpage and read.

Re:Startup management subsystem

[DeVilla]

The best part is the service descriptor files follow a standard. If all people did at this conference was convert package init scripts to systemd I would be ecstatic.

Honest question (to who ever might know) ... are systemd service descriptor files distribution independent?

People will tell you init scripts can be and can point you to standards for writing them, but in practice it usually doesn't work out too well. Not in a way that takes advantage of the various features of any given system. Distributions tend to be unique in various ways.

I'm just wondering if systemd fixes that or if each distro is still going to have to roll their own because of distro unique conventions? And of course there's the corollary question, is the plan to fix this by forcing distributions to all behave the same? (e.g "You will do it this way because systemd will not allow anything else.")

Re:Startup management subsystem

[Barsteward]

its the systemd project, not just the service management program "systemd" - from the announcement

Call for Presentations We’d like to invite presentation proposals for systemd.conf 2015. We are looking for talks including, but not limited to the following topics: - Use Cases: systemd in today’s and tomorrow’s devices and applications, - systemd and containers, in the cloud and on servers, - systemd in distributions, - Embedded systemd, - systemd on the desktop, - Networking with systemd, - D-Bus and kdbus IPC systems, - and everything else related to systemd.

Re:Startup management subsystem

[drinkypoo]

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.

Of course you can. You know the PID of the init script, and you know PPIDs. What prevents you from doing that? Even a shell script could do it.

Re:Startup management subsystem

[Peter H.S.]

You could refute that trivially by clearly stating what problem it actually solves. Yet you chose not to do that.

systemd solves many old Linux problems; besides the technical ones like proper service management, it also solves the problem with fossilized development of subsystems like init and logging, and solves the old problem of lack of coordination between userland, kernel space, and the plumbing layer between.

systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated so system admins can turn on such security features just by adding a Boolean value in a text file. It also means that every iteration of systemd distros become ever more hardened per default, making ever more difficult for the the black hats to gain privilege escalation.

By dismissing every systemd feature and everything systemd does as "bad", systemd-opponents like you paint yourself and all your fellow travelers into an ever smaller corner, where "SysVinit/OpenRC" is the pinnacle of evolution without ever needing more features.

Good luck with that.

Re:Startup management subsystem

[invictusvoyd]

If a startup management subsystem needs its own conference, it is doing too much.

Correction : startup management system backed , propagated and funded by Redhat

Re:Startup management subsystem

[drinkypoo]

it also solves the problem with fossilized development of subsystems like init and logging,

Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.

systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated

You do realize that cgroups is a thing you diddle with very small commandline programs, right? And by making directories? These are things which could be done in init scripts. Most distributions use standard init script libraries where such initialization can take place. It didn't require a whole new daemon; at most, some minor changes to again one of the existing competing init daemons would have been a fine place to start. Not tying it to a specific log daemon is the really important part, though! A whole new init system would be a whole lot less odious without a whole new log daemon with serious design deficiencies — especially breaking the human-readability component of the Unix Way that made Linux (as an imitation of Unix) successful to begin with.

y dismissing every systemd feature and everything systemd does as "bad"

No, what is being dismissed as bad is the NIH attitude, the proven lack of maturity (in all senses) of the primary developer and maintainer and his code, and the dismissing of what is tried, tested, and therefore true as old, outdated, and obsolete.

Re:Startup management subsystem

[Barsteward]

"A distinction with no difference." - how little you know

Re:Startup management subsystem

[Barsteward]

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

Re:Startup management subsystem

[Barsteward]

"There is an issue with systemd though. No other system manager, be it launchd, or any other brand has network connectivity where it is set to receive data. With systemd being this huge blob of code, it wouldn't be far-fetched to see a remote root hole in it, which would cause widespread compromise." yuou need to read about it more until you understand it, it just looks like you've just been reading the inaccurate posts of the anti-mob

"Has systemd actually seen a code audit? With all this new, relatively untested code, it is only a matter of time before it is exploited." - its open source, go and do your own code audit. And its not that untested either.

"The reason I don't use systemd isn't fear of old code, but basic security practices. I don't seem to see any focus on security when it comes to systemd, and because of that, it is not an acceptable product when it comes to enterprise production systems." - just where do you get your information from?

Re: Startup management subsystem

[cyber-vandal]

Cold and full of Germans *hides*

Re:Startup management subsystem

[Barsteward]

read this to update yourself http://enotty.pipebreaker.pl/2...

Re: Startup management subsystem

[phantomfive]

Somewhere he expanded his answer (I can't find where) to say that, "people are using it, so it must have features people want." He doesn't like what he's seen of it, but he understands that it fills a use case people have. That's why he won't completely diss it.

Re:Startup management subsystem

[Anonymous Coward]

:)

You still have modify the systemd run files for a particular setup... they aren't all portable.

Re:Startup management subsystem

[Anonymous Coward]

There is nothing wrong with open source developers meeting up, talk and code.

No, there is not, but is that really what is going to take place?
I had the impression that it was going to be another circle wank.

You guys are dragging yourself down with all the negative attitudes towards developers making progress.

They are not making progress. They are making congress.

Re:Startup management subsystem

[Barsteward]

"Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those." if he used one of those then he'd be bringing baggage into the mix. He already had the bare bones of a new init written before it morphed in systemd. Nothing wrong with a clean slate now and again.

I think you need to read up about cgroups - https://en.wikipedia.org/wiki/... - or are you saying cgroups are a solution looking for a problem?

"Most distributions use standard init script libraries where such initialization can take place." -not really, you can't always transfer a script from one distro to another and expect it to work without modification which is another problem systemd has addressed

Re:Startup management subsystem

[invictusvoyd]

Thanks for the link , but that's still 70% Redhat . That is quite rare in other open source linux-world projects .

Re:Startup management subsystem

[squiggleslash]

If Poettering uses the same communication methods as everyone else for managing his highly used open source project, then systemd is doing this because it can only get ahead without feedback.

If, OTOH, Poettering goes so far as to organize a public conference on his project, then his project is "doing too much".

Did you ever think, perhaps, that the conference is a way to get commentary and feedback on a project that's thus far been fairly controversial (largely for ridiculous reasons by people who think sysv init is a good idea?)

Re:Startup management subsystem

[Peter H.S.]

it also solves the problem with fossilized development of subsystems like init and logging,

Not a problem, and also not actually a thing. Several competing init systems which didn't bring baggage with them already existed, but Lennart is a real NIH kind of guy so he didn't start with one of those. Stable init and log daemons are features, not bugs.

Yes, it is a "thing". The problem with the fossilization of the Linux plumbing layer meant that crucial progress was being held back. All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems. They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process.
Upstart was a nice pioneering effort, but not a good solution as it were. But there are still other problems; crond fx. Why can't it handle hibernation properly? Probably because it was made when Unix servers where hand grafted out of shell scripts an always on. But there is no "cron" upstream developer group that takes RFE's, and no coordination between the many fragmented crond forks and userland developers, making all new development practically impossible. It would have been freaking nice if crond could have been dragged into the modern world 10-15 years ago, but as of now, we have to use crond+at+whatever instead.

systemd, as init and process manager, actually takes on the coordination responsibility that lacked previously. It is way cool how "namespace" isolation and kernel Capabilities(7) are integrated

You do realize that cgroups is a thing you diddle with very small commandline programs, right?

You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly.
http://www.linuxfoundation.org...

The point is that system already comes with such an abstraction layer for capabilities, namespaces and cgroups, making it trivially easy for the admin to harness their power without coding, by simply setting the value "ProtectSystem=true" in the service file, or using similar features (see man systemd.exec). Better yet, distro maintainers can lock down the daemon per default, giving "out-of-the-box" security.

There is nothing else that even comes close to the power of systemd when it comes to such security integration. The systemd security framework for these kernel technologies are not only easy for humans to read and understand, but it is machine parsable and scalable too.

To my knowledge nobody in the non-systemd camp is even working on similar ideas, or even on an alternative cgroups single writer implementation.

  Not tying it to a specific log daemon is the really important part, though!

Which is _exactly_ what journald _doesn't_! You can use it together with any "syslog(3)" daemon. So if you have a legacy setup, you can use with journald and it will even enhance it by providing logging info syslog normally can't get.

Re:Startup management subsystem

[drinkypoo]

Did you ever think, perhaps, that the conference is a way to get commentary and feedback on a project that's thus far been fairly controversial

I think that's a great idea, but how many people do you think they're going to invite to speak who hail from the other camp? The "What the fuck are you doing to everything we love" camp? I'm betting it's going to be a big, fat goose egg. And even if not, we've seen how Lennart responds to critics, it's a big part of why so many of us dislike him so.

Re:Startup management subsystem

[Barsteward]

I think you are really tilting at windmills. Yes, there can be solutions and work arounds found for most if not all problems. I'd rather have a system that does it better without having to resort to scripts all over the place to make up for deficiencies in the system.

Re:Startup management subsystem

[Peter H.S.]

I wonder which Berlin is in November? I've never been there myself.

Berlin is always worth a visit. Late November in German cities are nice, since you will find small booths selling "Glühwein" and various food (like sausages) everywhere.
While Berlin is nice in the summer with its biergartens, trees and sailing on the Spree, they have top notch museums too, like everything in the "museumsinsel/ Museum Island".

Re:Startup management subsystem

[Barsteward]

the section "Employers with the most hackers" says 46% RedHat

Re:Startup management subsystem

[Barsteward]

You can always set up your own AntiSystemd or SysVinit conference to counter.

Re:Startup management subsystem

[mysidia]

If a startup management subsystem needs its own conference, it is doing too much. Reply to This

How come there's no OpenSSH conference?

Re: Startup management subsystem

[Anonymous Coward]

No, 'I may have ill feelings about the developer, but I'm judging their project on its own merits' is sanity that a lot of people need.

Re:Startup management subsystem

[DrJimbo]

I'd rather have a system that does it better without having to resort to scripts all over the place to make up for deficiencies in the system.

You seem to be making the tacit assumption that everything works perfectly. If I am debugging a system then I would much prefer to deal with scripts (usually all in one place or otherwise easily found) than have to try to debug C and C++ code and XML schema. See Theodore Ts'o comments that were linked to above.

It reminds of me dealing with Microsoft systems (many years ago from the NT days, maybe they have changed since then). *IF* everything works pefectly then it is fine but as soon as you are in the mode of tracking down problems then it becomes a nightmare. This is why I made the switch from Windows-NT to Linux when I was doing sysadmin at a university. If I wanted to use a system that was like that then I would use Windows. This tacit assumption that the system was designed perfectly so there is no need for any intervention is one of the reason people don't want to give up init scripts on their Linux systems and replace them with systemd.

Re:Startup management subsystem

[PPH]

When the init script terminates, the service daemon is running...

Unless the init script explicitly exits with an exit status that indicates an error condition. Same behavior as a daemon failing to start.

If the init script is SUFFICIENTLY simple, then a systemd run file can be created to run the daemon

They rarely are. A few on your laptop might be. But on production systems, scripts check the status of various resources and initialize them if nedded. And much of this is beyond the capability of systemd. So if systemd can't work with init scripts, just put it down and walk away.

Re:Startup management subsystem

[DeVilla]

Thanks for the reply. So I guess I'm not sure if that means systemd is implemented in a way to prevent deviations and differentiation or if it's just going to be the systemd team mandating "the right way" to make a Linux system.

Re:Startup management subsystem

[tlhIngan]

An init daemon could re-run the init script with the "status" option, and if that exited non-true then it could re-run it with the "start" option, and if that exited non-true then it could give up and interrupt the boot process. That systemd can't do this is not my problem. That systemd won't do this has caused us all problems.

Wow... that's inefficient. Polling to see if a service is running then restart it.

And that's the problem with the init scripts - they make the whole thing less efficient. If a process spawns another process, that parent gets notification by default when something happens to its child. See SIGCHLD - the kernel sends it to the parent of a child process when the child process exits or terminates.

And with that, init is notified. In fact, even SysVInit has to do this - as PID 1, it's the parent of all processes - if a child process exits or terminates after its parent has terminate, init adopts the child process, and it gets the SIGCHLD. It then quietly reaps the zombie process.

FYI - SysVInit is also a service manager - it's perfectly capable of restarting processes when they quit, even rate limiting start up - if a process dies too many times in a minute, it'll be disabled for 5 minutes. Of course, few services in Linux actually USE the fact that init can restart processes automatically.

Re:Startup management subsystem

[gweihir]

And actually no need for any development, as it is finished and works reliably. Apparently, systemd fanatics do not understand these concepts. But how could they, none of either is to be found in the object of their worship.

Re:Startup management subsystem

[drinkypoo]

Wow... that's inefficient. Polling to see if a service is running then restart it.

Wow... that's something that every other operating system's service manager can handle.

And that's the problem with the init scripts - they make the whole thing less efficient. If a process spawns another process, that parent gets notification by default when something happens to its child.

OK, so exec the daemon from your script, whatever. It's not a problem for me. However, not doing this gives you a chance to do more stuff when the daemon dies...

Re:Startup management subsystem

[jeremyp]

You seem to be making the tacit assumption that everything works
perfectly. If I am debugging a system then I would much prefer
to deal with scripts (usually all in one place or otherwise easily
found) than have to try to debug C and C++ code and XML schema.
See
Theodore Ts'o comments that were linked to above.

Isn't that an argument that everything should be written in shell script?

Re:Startup management subsystem

[Peter H.S.]

And actually no need for any development, as it is finished and works reliably. Apparently, systemd fanatics do not understand these concepts. But how could they, none of either is to be found in the object of their worship.

I think your attitude is rather typical for a segment of systemd-opponents that takes refuge in denial.
But good for you that you think the non-systemd Linux stack doesn't need any developers, technology progress and new code, because that is exactly what that attitude is getting you.

Re:Startup management subsystem

[DrJimbo]

Isn't that an argument that everything should be written in shell script?

I don't think so. There are many many things that are better off *not* written in shell script, even for sysadmins. Compilers and interpreters come to mind.

I think it is more of an argument for using the right tool for the job. And the right tool will depend very heavily on the role you are playing. I think this is partly why there is such strong disagreement over the value of systemd. From a purely user perspective where everything is assumed to be working properly (or it is someone else's problem) then it is great. The same can be said of Microsoft offerings. But if you are coming at it from the sysadmin side then you might want something that is easier to understand and debug and fix. The init system has to have a lot of glue because it has to start up services from a lot of different code bases. There is a lot in favor of having this glue in a simple language that is easier to understand and fix. Systemd makes more sense for commodity, user-oriented devices. It makes very little sense on servers.

IIRC, this is similar to what Linus said about systemd. He said that as a user he liked it and didn't have problems with it but he did run into problems when interacting with the systemd developers.

Re:Startup management subsystem

[gweihir]

And there you are twisting what I said to the extreme, like the typical dishonest propaganda shill you are. Because lying is all you have.

Re:Startup management subsystem

[Barsteward]

"You seem to be making the tacit assumption that everything works perfectly." - i said "better" not perfect as that is impossible.
Ted Ts'o comments are fine but i don't get the "they don't listen" bit, if they didn't you wouldn't still be able to start your binaries with your current init scripts or have logs forwarded to syslog etc.

Re:Startup management subsystem

[ookaze]

It actually says 7.1 % Red Hat, can't you even read correctly?

Re:Startup management subsystem

[deek]

From what I've read, systemd has seen a number of code audits. Not only from numerous individuals, but from Redhat as well. Redhat also regularly run it through code analysis software.

The network connectivity in systemd is a simple inetd-like setup. No network data is processed by systemd code. It only listens on the port, starts up the service and hands it the socket. Yeah, you could argue that you may as well use inetd instead, but then you're missing out on the features that systemd provides for managing services.

If there's a way to attack systemd, I'd be quite confident that its simple network code will not provide a vector.

Also, systemd isn't a huge blob of code. It's actually a suite of programs; the init system being just one component. It's a common misconception.

Re: Startup management subsystem

[morgauxo]

Which coming from him probably means he is being sincere about not hating it. Since when has Linus Torvalds been known to be PASSIVE aggressive when it comes to his opinions on software?

Re:Startup management subsystem

[drinkypoo]

Isn't that an argument that everything should be written in shell script?

It's an argument that everything which reasonably can and should be written in a shell script (that is, without compromising security or performance) should be. A shitload of what makes a modern Linux go is just scripting. Sadly, many of them are python scripts; shell scripting will do the jobs they do without exception, but people jumped on the new shiny (like they did with perl, as well) and that results in a system where you have to understand three scripting languages to maintain it, not just one. Clearly scripting is not a panacea. You have to understand what you are doing.

People often argue that shell scripts are slow, but they aren't if you have free memory, because process creation is cheap on Unix. Creating new shells, firing off all those inlines, is as cheap as thread creation on Windows. It's not a problem these days, when RAM is basically free.

Everything which can reasonably be implemented as a very small shell script absolutely should be. Anything which legitimately needs to be written in C absolutely should be. The right tool, not just a random tool.

Re:Startup management subsystem

[drinkypoo]

All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems.

You're missing the point, deliberately I hope because the alternative is too pathetic to contemplate. Those init systems were in use at the time because you could swap between them freely. Systemd deliberately breaks that state of affairs and that is what is primarily wrong with it.

They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process.

Proper responsibility? No, you have that wrong. They did everything they had to do.

You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly.

Oh great, more influence of systemd shitting up my Linux. Just want I wanted to hear about. So instead of a simple, working interface to cgroups, they want to make it harder to use. Why would you do that? Just to make systemd look more useful? You make it harder to do what they do in a script so that people like me can't say "but a script could do that"?

To my knowledge nobody in the non-systemd camp is even working on similar ideas, or even on an alternative cgroups single writer implementation.

What the fuck does "writer" mean here?

Re:Startup management subsystem

[Peter H.S.]

All the init-systems in use at the time where just "slightly improved SysVinit" style init-systems.

You're missing the point, deliberately I hope because the alternative is too pathetic to contemplate. Those init systems were in use at the time because you could swap between them freely. Systemd deliberately breaks that state of affairs and that is what is primarily wrong with it.

It is trivially easy for upstream projects to make their daemon support both systemd and SysVinit, in fact, if they don't change anything then everything is as before, with distros providing both scripts or service files. The whole point with systemd is exactly it is backwards compatible with SysVinit, even though it is quite different.

You could never easily switch between between SysVinit and other similar inits, simply because there never existed init-agnostic scripts nor distro-agnostic scripts. You simply can't use OpenRC scripts on SysVinit.

They all relied on executable config scripts to manage daemons, and none of them tried to step up an take proper responsibility for the boot and init process.

Proper responsibility? No, you have that wrong. They did everything they had to do.

I strongly disagree. SysVinits "simplicity" was exactly because it left all complexity to others to fix. I won't dwell with PID problems, daemonizations or other classic criticisms of SysVinit, some dating 30 years back, but show one example:

As you know, daemons need special (root) privileges in order to access port-numbers below 1024. This is for security reasons. The backside of this is that the daemon then needs high privileges to run. Enter setuid and similar Posix syscalls; they have basically been demonstrated to be impossible to use in a safe manner, and have provided decades of remote exploits of Linux for the same reason.
Then came Capabilities which meant setuid root programs could be ditched for that, but Capabilites still means the Daemon can freely talk through low port numbers, so spammers have for years exploited this to install spamming smtp servers on exploited hosts or serve malware from port 80.

systemd on the other hand, can give the daemon a low port-number through a socket so that all such low port-number privileges can be completely dropped; even if the daemon is exploited, it can't send spam through a low port number.
Much more secure, and it even makes things much less complicated for the daemon writers.
With SysVinit, all the daemons had to implement code dropping privileges, which meant 1000's of different, bug-filled and often insecure code implementations. With systemd, the daemons can let systemd take care of all that. I think that is the right approach; daemon writers want to make awesome programs that does things that interest them, not fiddle with hard to understand low-level system programming. In any case, it is bound to make things much more secure.

You are probably thinking of the old cgroups interface, but that is being deprecated in the near future in favor of the "single writer"/"unified hierarchy" that requires a writer that abstract away the kernel cgroup API so userland doesn't use it directly.

Oh great, more influence of systemd shitting up my Linux. Just want I wanted to hear about. So instead of a simple, working interface to cgroups, they want to make it harder to use. Why would you do that? Just to make systemd look more useful? You make it harder to do what they do in a script so that people like me can't say "but a script could do that"?

It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.

The main problems are security and bugs in allowing multiple controllers/writers. It just didn't work since there are too many ways to get in

Re:Startup management subsystem

[drinkypoo]

IIRC, this is similar to what Linus said about systemd. He said that as a user he liked it and didn't have problems with it but he did run into problems when interacting with the systemd developers.

What he said is that he didn't personally care about it, that he understands that some people have use cases where it makes sense... and that he understands that the developers are a bit of a problem. Not that he liked it... or doesn't like it. It's unlikely to have affected him substantially yet, except for rejecting bad patches

Re: Startup management subsystem

[segedunum]

Theodore is not the only kernel person to have issues with systemd, and in particular the kdbus component systemd proponents don't think should need questioned.

Re:Startup management subsystem

[segedunum]

You really haven't the slightest idea what you're talking about, do you?

This reminds me of that Spinal Tap scene: "But.....it goes all the way up to eleven".

Re:Startup management subsystem

[segedunum]

Isn't that an argument that everything should be written in shell script?

No.

Re:Startup management subsystem

[segedunum]

Ted Ts'o comments are fine but i don't get the "they don't listen" bit, if they didn't you wouldn't still be able to start your binaries with your current init scripts or have logs forwarded to syslog etc.

Because......that has nothing to do with systemd's benevolent and great leadership? Stuff works that has already worked......because it does.

Re:Startup management subsystem

[segedunum]

It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.

Alas, the net effect of it is that the single interface to it is through systemd and dbus, and Lennart claims in that passive aggressive way, as you do, that it is the 'cgroup maintainer' who wants this. However, this 'change' has been bandied around for at least a couple of years now largely because it looks as though they thought kdbus would get a free pass into the kernel. We all know that's what this means.

Re:Startup management subsystem

[Peter H.S.]

It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.

Alas, the net effect of it is that the single interface to it is through systemd and dbus, and Lennart claims in that passive aggressive way, as you do, that it is the 'cgroup maintainer' who wants this. However, this 'change' has been bandied around for at least a couple of years now largely because it looks as though they thought kdbus would get a free pass into the kernel. We all know that's what this means.

You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd. You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.

Nor is systemd the "single interface" to the new cgroups API. Anybody can make their own cgroups "writer" since it is a kernel feature. Just because systemd takes advantage of kernel features doesn't mean anybody else can't.

Seriously, you guys who for some reason don't like systemd (I don't care why) should stop spreading misinformation that really hurt your own cause.

Perhaps it feels good to tell a narrative how systemd usurps everything and makes all other development impossible and that in the future only systemd will be able to use the new cgroups API, but this will only discourage any non-systemd development.

The systemd-opponents seems too busy in burning all bridges, both behind and in front, dismissing technology just because systemd happens to use it; cgroups, dbus, kdbus , Capabilities(7), dynamic device handling (udev), service management, declarative text config files etc. is all bad because systemd uses them.

It really leaves very little room for non-systemd developers, and basically means that non-systemd distros will completely stagnate with obsolete technology.

kdbus is great technology, especially for the non-systemd distros. If you think otherwise you haven't studied the project. Same with the new cgroups interface. There are some really good opportunities there too for the non-systemd distros to make something interesting with that, that could attract commercial developers.

The negative campaign against systemd have been an utter failure from the start. You guys should have concentrated on positive contributions in alternative development years ago. And you should have the cool, dispassionate look on systemd that would enable you to steal and copy every good idea from that project.

Re:Startup management subsystem

[segedunum]

You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd.

That's Lennart speaking there. Claim everyone is misinformed when a raw nerve is touched. Lennart has clearly stated that he sees systemd as the one way of configuring cgroups in userspace and kdbus is the way that will effectively be locked in as the interface between kernel and userspace. Can't possibly have competing ways of doing this.

You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.

Bollocks. I find a lot of kernel developers who have issues with it though. See, easy this isn't it?

kdbus is great technology, especially for the non-systemd distros.

Kernel developers who have attempted to review the code have stated otherwise, and kdbus is simply not going to be merged until those concerns are addressed. What happens is things go silent, a patch is pushed to Linus with no changes and the mailing list thread kicks off again with the response "But it does this in userspace, so this is how it has to be and of course, putting it into the kernel will automatically make it go faster, because, you know, KERNEL!". There are a litany of huge issues with it too numerous to discuss here.

Using the Spinal Tap line of "But it goes all the way up to eleven" to any argument is all the systemd proponents have. It's quite sad that we're going to spend a great number of years of pain over this thing until it has to be dumped. Just wait until the security holes start getting found as well (you can drive a coach and horses through docker), but that's a whole other can of worms.

Re:Startup management subsystem

[Peter H.S.]

You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd.

That's Lennart speaking there. Claim everyone is misinformed when a raw nerve is touched. Lennart has clearly stated that he sees systemd as the one way of configuring cgroups in userspace and kdbus is the way that will effectively be locked in as the interface between kernel and userspace. Can't possibly have competing ways of doing this.

It seems you haven't understood the basics of this. Let me clarify:
1. On systemd-distros it is systemd that will be the sole cgroups writer, and the sole owner of the shared bus as setup on kdbus. Poettering are only stating the obvious about this, because realistically that is the only working option.

2. Non-systemd distros can make their own cgroups writer or mechanism for controlling kdbus. They are free to do so, and the API's they use will be stable kernel API's. systemd doesn't in any way prevent them for making their own software for controlling cgroups and kdbus.

This is the way it is supposed to be; everyone makes their own stack. This is what gives competition, not the rather strange assertion that systemd developers somehow should make a independent cgroups writer that works on all Linux distros.

As I said, cgroups and to a lesser extent kdbus, are tremendous opportunities for the non-systemd distros to make their own stack (I am thinking containers mostly) that might even attract both capital and paid developers.

You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.

Bollocks. I find a lot of kernel developers who have issues with it though. See, easy this isn't it?

Really, I challenge you to find even single kernel developer who thinks the old cgroups API is secure, and who doesn't agree on Tejun's proposal as the only way forward. AFAIK, both Al Viro and Andy Lutomirski discussed this recently on LKML.

kdbus is great technology, especially for the non-systemd distros.

Kernel developers who have attempted to review the code have stated otherwise, and kdbus is simply not going to be merged until those concerns are addressed. What happens is things go silent, a patch is pushed to Linus with no changes and the mailing list thread kicks off again with the response "But it does this in userspace, so this is how it has to be and of course, putting it into the kernel will automatically make it go faster, because, you know, KERNEL!". There are a litany of huge issues with it too numerous to discuss here.

Most of it is just the usual LKML noise when something important is merged, people want to test even the basic assertions of everything. Don't take it too seriously if eg. Al Viro says that some code is bad. His standard is that at best, all code sucks badly, with most codes being even worse than that.

It looks like the usual Linux kernel process works fine, with kdbus being improved really well from every round of patches on LKML, especially the two first rounds.
You will find that all actionable kdbus criticism is being dealt with, Greg KH is a seriously experienced kernel developer who doesn't shy away from technical problems.

Anyway, the point is that having a shared bus kernel IPC is a good thing that non-systemd distros could benefit from. Instead they try to trash talk it, pretending it isn't good and doesn't solve any problems. In short, repeating the same total failure tactic as they used against systemd and PulseAudio.
So kdbus seems to be yet another technology that are "taboo" for the anti-systemd crowd. Their loss really.

Using the Spinal Tap line of "But it goes all the way up to eleven" to any argument is all the systemd proponents have. It's quite sad that we're going to spend a great number of years of pai

Re:Startup management subsystem

[ookaze]

From a purely user perspective where
everything is assumed to be working properly (or it is someone else's
problem) then it is great. The same can be said of Microsoft
offerings.

Wrong! You just assumed that Microsoft offerings are assumed to work properly, which is just plain false.
MS offerings need lots of glue from the start to work correctly temporarily.

But if you are coming at it from the sysadmin side then
you might want something that is easier to understand and debug and
fix. The init system has to have a lot of glue because it has to
start up services from a lot of different code bases. There is a lot
in favor of having this glue in a simple language that is easier to
understand and fix. Systemd makes more sense for commodity,
user-oriented devices. It makes very little sense on servers.

Wrong again! I come from mostly a sysadmin side, and systemd crushes shell scripts and sysvinit in every single way.
And this on every workload, from embedded to clusters/HPC going through servers and desktops.
There is just no good thing today on Linux about shell scripts as boot system, and this was true 15+ years ago already.
Systemd is better precisely because sysadmins want sth easier to understand and debug and fix.
I still use shell scripts for booting my Live CD, but very little is done in them, before I switch root FS and launch systemd.
Once systemd is debugged and fix, it's debugged and fixed for every single units you have. While with shell scripts, you know a tuning/debugging nightmare is coming for every single one you add.
Shell scripts are just not reliable at all, few admin even know how to restart a service properly with them, leading to tools like "service" which don't solve every problems like race conditions.

Re:Startup management subsystem

[ookaze]

Proper responsibility? No, you have that wrong. They did everything they had to do.

I strongly disagree. SysVinits "simplicity" was exactly because it left all complexity to others to fix. I won't dwell with PID problems, daemonizations or other classic criticisms of SysVinit, some dating 30 years back, but show one example:

As you know, daemons need special (root) privileges in order to access port-numbers below 1024. This is for security reasons. The backside of this is that the daemon then needs high privileges to run. Enter setuid and similar Posix syscalls; they have basically been demonstrated to be impossible to use in a safe manner, and have provided decades of remote exploits of Linux for the same reason.
Then came Capabilities which meant setuid root programs could be ditched for that, but Capabilites still means the Daemon can freely talk through low port numbers, so spammers have for years exploited this to install spamming smtp servers on exploited hosts or serve malware from port 80.

systemd on the other hand, can give the daemon a low port-number through a socket so that all such low port-number privileges can be completely dropped; even if the daemon is exploited, it can't send spam through a low port number.
Much more secure, and it even makes things much less complicated for the daemon writers.

I can attest to that.
systemd is just a life saver, and I have a recent example of this.
Every year, at summer time, I see loads of attacks on HTTP servers, and often mine are compromised one way or another, and I have to react quickly, and sometimes there is no fix in time. This summer was no exception, with an attack on my drupal web site, which was successful in trying to launch lots of mails from my server, as I had not updated drupal to the latest version.
But now, my HTTP server is protected by systemd via its unit file: it can't tamper with my system or data, everything is protected by systemd, capabilities are very tight, and it couldn't even send the emails as everything failed (but that's more credit to the Web Server that drops privilege). Basically, only legitimate actions work.
So it was much less headaches than with other init systems, and I wasn't in emergency mode this time, I just watched all the attempt ultimately fail, even though the attacker thought they succeeded.
For the security alone, there is just no way a decent sysadmin would stay with shells scripts.

Re:Startup management subsystem

[segedunum]

Most of it is just the usual LKML noise when something important is merged

No, it isn't.

Re:Startup management subsystem

[Peter H.S.]

Most of it is just the usual LKML noise when something important is merged

No, it isn't.

Yes it is. Seen it so many times over the decades, even Alan Cox said on G+ that it was just business as usual, with kdbus standing a good chance of being merged when the raised criticism was dealt with.

First, you must remember that several of the "noise makers" aren't kernel developers at all. Everyone can write to the LKML, though that doesn't mean they are taking seriously.

Secondly, new important things are often put through the grinder; that is how it works on LKML. But it doesn't mean that all raised criticism is valid either; much depend on the defense of the existing code too.

Until now the kdbus developers have either incorporated actionable criticism into code/design/documentation changes, or defended their stance very well. Kdbus have clearly benefited from this process and is now being "beta tested" by end-users too. So when it finally gets merged, it will "land running" so to speak, with more than usual real world testing and userland code.

Re:Looks like you guys lost

[walterbyrd]

> Learn from your mistakes.

By that you must mean: stop using Linux and learn FreeBSD.

systemd is for cows.

[Anonymous Coward]

You are all cows. Cows say moo. MOOOOOOOOO! MOOOOOOOOO! Moo cows MOOOOOOOO! Moo say the cows. YOU COWS!!

Re:Looks like you guys lost

[Anonymous Coward]

I do have a FreeBSD VM that I occasionally fire up.

Sadly, FreeBSD still has a very, very long way to go before it reaches the maturity level of Linux.

The other day I unpacked a new box, and had Fedora loaded, fully configured, and running on it in less than two hours.

By comparison, because the FreeBSD base install is so bare, and because the ports collection has to be installed by compiling from source, it took over a day to reach the same comparable level of configuration, and service, on this VM.

I really like some aspects of FreeBSD, and I wish that, some day, it will be a viable alternative to the systemd abomination. Sadly, this day is yet to come.

Free speech zone

[phantomfive]

Is there a 'free speech zone' where we can go to protest?

Re:Free speech zone

[Barsteward]

I guess you could always offer to be a guest speaker and point out the errors of systemd

Re:Free speech zone

[phantomfive]

They will not invite someone to speak on that, but that is something I'm working on.

In brief, the good:
* Systemd makes it easier for distro maintainers to write startup scripts, which is something a lot of them wanted.

The bad:
* Poor understanding of interfaces by the lead developers.
* Poor understanding of portability by the lead developers.
* Poor understanding of separation of concerns.
* Scope creep (there is no reason Gnome should depend on systemd).
* Binary files are a symptom of idiocy......more specifically, binary/text is not something that should be decided by the init system.

Re:Free speech zone

[Peter H.S.]

>* Scope creep (there is no reason Gnome should depend on systemd).

Gnome doesn't depend on systemd as such, but on the systemd-logind API. Until recently (perhaps it still does) it also supported the old ConsolKit API as alternative even though CK had been dead for +1½ year with no upstream bug fixing or security support, and no one bothered to maintain it anyway.

The problem seems to be that the systemd-opponents really don't understand how Open Source software works and being developed, something that requires coordination, and positive contributions with either code, documentation, or money.

Claiming that the systemd developers are incompetent and doesn't understand software development will get you nowhere. You have to employ your superior knowledge into actual competing projects in order to be taken seriously. But that is the problem isn't it? The total lack of effort by the systemd-opponents to actually create something useful.

Re:Free speech zone

[phantomfive]

Yes it does. You can't separate logind from systemd (although that would be good software engineering, if they were separable). The systemd-logind API is deeply integrated into systemd. It shouldn't be, but it is.

The problem seems to be that the systemd-opponents really don't understand how Open Source software works and being developed, something that requires coordination, and positive contributions with either code, documentation, or money.

The problem seems to be that you didn't read any of my posts that I linked to earlier. From what you've written, it doesn't even seem like you understand systemd very well. Yet somehow you are a huge proponent of systemd. I don't know. What do you like about it? That's a serious question.

Re:Free speech zone

[Peter H.S.]

Yes it does. You can't separate logind from systemd (although that would be good software engineering, if they were separable). The systemd-logind API is deeply integrated into systemd. It shouldn't be, but it is.

You are misinformed. CK2 and systemd-shim are alternative implementations of the systemd-logind API (or at least the subset of the API Gnome/KDE actually need). The CK2 developers abandoned the old CK API in favor of the systemd API, simply because the systemd-logind API developed by Lennart Poettering is much nicer

There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project. You simply can't get the same features such as multi-seat without such integration.

The problem seems to be that you didn't read any of my posts that I linked to earlier. From what you've written, it doesn't even seem like you understand systemd very well. Yet somehow you are a huge proponent of systemd. I don't know. What do you like about it? That's a serious question.

systemd is a massive security increase compared to any other init-system out there, simple because it integrates Namespace isolation, Cgroups and Capabilities(7).

Daemon service files are in structured text format, instead of spaghetti code in executable files like Sysvinit/OpenRC.

Daemon service management vastly superior to anything else on Linux/Unix.

Re:Free speech zone

[drinkypoo]

You simply can't get the same features such as multi-seat without such integration.

There was multi-seat X before there was systemd. How can it be that you can't have multi-seat without such integration?

Re:Free speech zone

[Barsteward]

"Systemd makes it easier for distro maintainers to write startup scripts, which is something a lot of them wanted" - don't you mean configuration files like unit, target and service files? Why would they be using startup scripts, one of the main points was to get rid of scripts.

"Poor understanding of interfaces by the lead developers." - thats a new one - where did you get that from, give us some backup to see what you mean.
"Poor understanding of portability by the lead developers." - portable to where? its a linux system.
"Poor understanding of separation of concerns." - eh? expand, please
"Scope creep (there is no reason Gnome should depend on systemd)." - thats Gnomes problem, LP issued a library to allow Gnome to avoid using logind but GNOME decided not to use it.
"Binary files are a symptom of idiocy......more specifically, binary/text is not something that should be decided by the init system." only the journal has an element of binary and as a journal, it shits all over syslog/rsyslog with better content. Don't try the "corruption" argument as ALL file types can be made unreadable when corrupted.

I think you need to read the Systemd Biggest Myths page.

Re:Free speech zone

[phantomfive]

There are actual good technical reasons why systemd is made like it is and why systemd-logind is part of the systemd project.

There are no good technical reasons. Having a window manager depend on a particular startup manager is poor design, there's no way around that.

You are misinformed. CK2 and systemd-shim are alternative implementations of the systemd-logind API (or at least the subset of the API Gnome/KDE actually need).

I discuss that here. If you think I am misinformed, I will look into it more deeply.

Re:Free speech zone

[phantomfive]

I've already linked to pages explaining these, but you obviously didn't read them.

"Poor understanding of interfaces by the lead developers." - thats a new one - where did you get that from, give us some backup to see what you mean.

This link discusses it

"Poor understanding of portability by the lead developers." - portable to where? its a linux system.

Exactly lol. Linux only. Not portable. This link goes into more detail.

"Scope creep (there is no reason Gnome should depend on systemd)." - thats Gnomes problem, LP issued a library to allow Gnome to avoid using logind but GNOME decided not to use it.

Lennart actively pushed Gnome to use systemd, the forum threads are still available if you want to find them.

only the journal has an element of binary and as a journal, it shits all over syslog/rsyslog with better content.

If the init system dictates what logging system you must use, then that's poor design. Also, corrupt binary logs are harder to read than corrupt text logs.

I think you need to read the Systemd Biggest Myths page.

It's full of self-contradictions. This post addresses the point, quoting Lennart with his own words. The "biggest myths" page is an example of what Karl Marx referred to as the dialectic (which to Marx meant BS, rather than an approach to the truth).

Re:Free speech zone

[Peter H.S.]

There are no good technical reasons. Having a window manager depend on a particular startup manager is poor design, there's no way around that.

The DE's really do depend on the OS layers below, there is no way around that. And systemd is exactly such an OS layer, or plumbing system if you like. It is exactly meant to provide service to userland programs like Gnome/KDE/LXQt. And having multi-seat capabilites and proper session management really require deep OS integration like cgroups.

It is poor design _not_ to provide such a unified and coherent OS layer for userland.

I discuss that here. If you think I am misinformed, I will look into it more deeply.

You are. Check out CK2, or the history of Ubuntu's shim. It was originally Canonical who was handed over the CK project, but they apparently thought the same as the CK2 maintainer, that the CK API sucked and Poettering's logind API didn't, and therefore cloned it into "systemd-shim" instead.

Sure, none of the API alternatives are full replacements since that would require a level of kernel and system integration only systemd provides, so no multi-seat etc. But the latest I read from Gnome's Olav Vitter's was that they would try to support the subset of features that the alternatives could support.
So in the future Gnome will support the systemd-API, not the CK API, just like CK2, systemBSD's logind etc does.

The latter of course depend on somebody doing some actual work instead of just complaining or spreading misinformation.

Re:Free speech zone

[Peter H.S.]

You simply can't get the same features such as multi-seat without such integration.

There was multi-seat X before there was systemd. How can it be that you can't have multi-seat without such integration?

multi-seat X haven't worked securely for decades. The main problem is actual in the Linux kernel, especially the way it handles devices in a multi-user environment. That is the same reason that while it has been possible to run root-less X on Linux for many years, it wasn't safe in a multi-user environment until systemd made it possible.
There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).

That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.

Re:Free speech zone

[phantomfive]

ok, so now I'm interested. You are clearly a strong proponent of systemd (some might even say 'fanboy'). What is it about systemd that you like so much? What are the features that really help you? What inspires your advocacy?

Re:Free speech zone

[Peter H.S.]

ok, so now I'm interested. You are clearly a strong proponent of systemd (some might even say 'fanboy'). What is it about systemd that you like so much? What are the features that really help you? What inspires your advocacy?

Not really a fan boy. Actually I don't care at all what other people use as init-system. I am cool with Slackware going their own way, and I respect P. Volkerding's Linux vision, even though it isn't the same as mine.

The main reasons why I am going into the systemd debate was that I frankly was tired of all the stupid misinformation spread about it. Some of it deliberate lies, but most often it is misinformation copied from some swivel-eyed loony and then repeated again and again until people take it as truth.

My favorite example on this was the often repeated claim that Gnome had "hard dependencies on systemd" and these where "pushed/forced" into Gnome by Poettering. Just because Gnome support systemd for session management, doesn't mean it can't support an alternative too.

And in fact, Gnome did exactly that, despite that ConsolKit was dead and unsupported upstreams, they still supported it years afterwards, while pleading on various blogs and mailing lists (including Debian's) that some should either maintain CK or make an alternative. Nobody did that and the non-systemd camp can only blame themselves for that.

Perhaps one of the reasons why nobody started to make an alternative could be that so many people claimed that Gnome had hard dependencies on systemd, making it look like Gnome only cared for systemd support, so why bother. A self fulfilling prophecy.

I have been a Linux user since Slackware came on 40 floppies. I like Linux, I like the technical progress it has experienced since, and I actually remember technical discussions before year 2000 on the problems with SysVinit, and syslog and the lack of coordination of the Linux plumbing layer.

To me systemd was an answer to my prayers with what I didn't like with Linux: SysVinit (it is only simple when doing simple things, and it is only simple because it outsources complexities into daemons etc, the complexities are still there.), service management; new and inconsistent tools among each distro, and lets not forget the time wasted on grafting some service management system on top. Logging too. I had high hopes for Rsyslog when they started in 2005, and while I really respect their work, they didn't solve several of the problems they set out to solve (perhaps not incidentally many of the same problems systemd have actually solved). The reason wasn't lack of will, but total lack of coordination in Linux between userland, the OS layer (where Rsyslog belongs) and kernel.

I have always played with new tech, including ones I didn't have a need for at the moment. So when systemd came out, I actually sat down one afternoon and just started to read, and read the documentation. I then started to play around with it. It really convinced me how good systemd was, and how much potential it has.

systemd is different, and it really does require some serious studying in order to use it. You just can't wing it, even if you have loads SysVinit/Upstart experience.

There are several technical things I like about systemd and I find superior to similar solutions, especially security. But perhaps what I really like about _using_ systemd is how much the developers care for the end users. It is in the small details like awesome bash-completion, sane defaults, how everything us documented in the man-pages, there is even a manpage containing a list of all the systemd man-pages (man systemd.index ) and a reverse list of every file, config option, CLI option etc (man systemd.directives) and overview pages like "man bootup" that shows and explain the boot process. And the way they abstract away all the difficult bits into simple declarative statements that goes into structured text files. And tools like "systemd-delta" that instantly gives an overview of changed service files.

Re:Free speech zone

[phantomfive]

My advice to you is to stop running with the anti-systemd pack; they won't help pay your bills if getting a new job is difficult because your skills are outdated, and since 100% of all commercial distros are going systemd, that is core skill to master.

I can read code. When systemd writes good code, I'll support it.

Re:Free speech zone

[Peter H.S.]

My advice to you is to stop running with the anti-systemd pack; they won't help pay your bills if getting a new job is difficult because your skills are outdated, and since 100% of all commercial distros are going systemd, that is core skill to master.

I can read code. When systemd writes good code, I'll support it.

Don't give me that crap; the systemd developers are proficient and experienced Linux developers. Poettering has a CS degree and has coded Linux for +10 years now, he really knows his stuff. I have yet to see a single named OSS developer with the proper domain knowledge saying systemd is badly coded. What the systemd developers are doing is seriously hardcore too, from OS containers to session management. Btw, if you are looking for code documentation, don't just stare at the code, read the man pages too (like man sd_notify) and the systemd homepage too; it also contains developer information.

As I said, I have seen many people commit professional suicide before, refusing to learn new stuff. I guess people burn out and wants to stop the world.

Not studying systemd is simply professional suicide when it comes to Linux. Sure there will be SysVinit/Upstart gigs for years to come, but the choices will be fewer, the pay lower for every year, and suddenly you are out of work and have no experience with modern Linux management or development. Good luck telling the prospective employer at a job interview, that you "refuse to learn systemd, because you don't like the coding style/Once read a blog post claiming it wasn't designed the Unix way etc."

Re:Free speech zone

[geggam]

Dont lose the init script skills. When systemd hits those enterprise stacks with software from long since gone vendors someone will have to support it.

It is going to be interesting to watch. I currently work at a Fortune 100 and the only groups even remotely close to adopting systemd / rhel7 are in R n D ... the stable money maker systems wont convert or even think about it for a few years.... if ever.

Re:Free speech zone

[phantomfive]

Don't give me that crap;

STFU? Anyone can insult, it doesn't make your point stronger.

Poettering has a CS degree and has coded Linux for +10 years now,

So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic.

Then sometimes he makes amusing rookie mistakes. So that's where he is as a programmer: good code, poor design.

Not studying systemd is simply professional suicide when it comes to Linux.

Thanks, I appreciate the concern. I don't make money based on my ability to use whatever software, I make my money designing good software. Although I've spent plenty of time studying systemd, so my career is safe.

btw, that points to the difference between people who like systemd, and people who don't. Those who favor it tend to look at the features, and say they are decent. Those who dislike it tend to look at the design, and say, "that's kind of wonky." A person can hold both opinions, they are not logically inconsistent. Unit files clearly fill a need people have.

Re:Free speech zone

[Peter H.S.]

SysVinit style scripts will hang around for at least a decade more.

Enterprise systemd adaptation will probably be slow in the beginning. Still, it is interesting that RHEL 7.2 will be rebased on systemd 219 simply because customers are demanding newer OS container support and systemd networking.

While some shops never upgrade (I once found a MicroSoft Xenix (Unix) server at a customer a decade after it was deprecated), I think systemd's security features and OS container technology will make it dominate every aspect of the future enterprise market.

Re:Free speech zone

[Peter H.S.]

So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic.

You will find he has read all the classic Unix books, and unlike most others actually studied Unix variants and Unix code beside Linux.

All the systemd tools are made with regards to classic Unix philosophy, they only do one thing and they do it it well, they aren't chatty when scripted, doesn't report success (error code 0) as default, aren't interactive, etc. You often see Poettering quoting directly or indirectly from Ken Thomson et al. on the systemd mailing list. systemd closely follows classic Unix tradition where it actually makes sense.

You are severely underestimating his abilities; making a program like Pulseaudio, a middle-ware layer between the kernel/ALSA stack and userspace, was insanely difficult, but an instant success that solved many real world problems that especially DE developers had, and that made it default on all major Linux distros early on.

Yeah, I know some people likes to claim that PA doesn't work on their broken distro, but the fact is that no one has ever even tried to replicate what PA does, even now where all the ALSA/kernel driver bugs have been shaken out.

The fact is that PA was both well done and brilliantly pulled off. And it wasn't a "lets rewrite everything from scratch, including every sound card driver in the kernel" solution, but a solution that maximized existing work and with a smooth transition with no "flag day".

Same with systemd; using Fedora the transition from Upstart to systemd was really smooth; no "flag day" where either only systemd or sysvinit scripts worked, all the usual commands like telinit or "shutdown -h now" still worked, and all the SysVinit scripts worked too.
It really is impressive how smooth the technical transition to systemd went on RHEL, Fedora, Suse, Arch and Debian, despite it replacing several different init-systems and rather different environments.

Then sometimes he makes amusing rookie mistakes. So that's where he is as a programmer: good code, poor design.

systemd is really portable across architectures, which is the important bit for Linux. That you can't easily port it to BSD is totally irrelevant : systemd is GPL/LGPL so it can't be close sourced and therefore it will never be adopted by BSD since close sourcing software is what pays their developers.

Anyway, you can't port BSD system software to directly Linux either; it isn't made that way, neither are official system software from Unices like Solaris. The "Unix wars" are over; Linux and Open source won, the proprietary Unices have been delegated to tiny niche domains. It makes no sense whatsoever to make systemd portable to SCO Unix, or AIX.

I saw an interesting comment from Poettering regarding OpenSSL code pre-Heartbleed; he found it abysmal. And it is exactly "Heartbleed" style bugs they want to avoid, where someone drops a turd of a patch into the repo that circumvent security measures, just so some proprietary close source Unix can avoid upgrading its libraries.

Anyway, I think you are severely underestimating his abilities as software architect; he has at least 3 major projects under his belt that now all are part of every major Linux distro. Two of those projects so inherently hard that many developers had given up trying to solve the problems.

Re:Free speech zone

[phantomfive]

Wow fanboy, is there anything Lennart can't do? Is there anything he touches that isn't "brilliant?"

Seriously, you are handicapped because you don't understand architecture, so you can only repeat things you've heard. It's hard to have a reasonable discussion with you on this topic, because you lack the necessary skills. That's ok, not everyone needs to be a programmer.

Here is an example you should be able to understand, though. Your response will show whether you blindly worship at the feet of systemd devs, or if you are capable of thinking. As you know, there were some problems with cron, it didn't handle sleep very well, for example. When you have that problem, is the answer to rewrite cron completely, or to fix cron?

Re:Free speech zone

[Peter H.S.]

Wow fanboy, is there anything Lennart can't do? Is there anything he touches that isn't "brilliant?"

I think the point is that he undeniable have a extremely successful Linux developer career and have now designed and implemented three major Linux subsystems of considerably complexity that is used on all major Linux distros. He really tackled extremely difficult problems head on and actually solved them.

The way he enabled systemd to be backwards compatible while still making radical changes in functionality is worth a close study for every developer group that wants their software adopted in Linux. No "flag day" at all.

All in all I would say his ability to design and architect software and being a project leader is way, way above average, and pretty much proven by his track record.

Here is an example you should be able to understand, though. Your response will show whether you blindly worship at the feet of systemd devs, or if you are capable of thinking. As you know, there were some problems with cron, it didn't handle sleep very well, for example. When you have that problem, is the answer to rewrite cron completely, or to fix cron?

You can't fix cron on Linux, this is why its core problems haven't been solved for +10-15 years. The reasons for this fossilization of an important part of the Linux plumbing system are the usual:

1. The lack of upstream: There is no upstream "cron" developer group that fixes bugs or take RFE's.

2. The recursive problem: "cron" is a collection of fragmented projects often almost abandon ware, bound together with some ancient syntax and a little Posix compliance. If you deviate from that, you new cron version won't be backwards compatible so developers/projects won't support it and distros won't use it.

3. The lack of coordination: There is no or very little cooperation between Linux distros. There are no central decision makers in Linux, that can work towards deprecation of obsolete standards and plan new ones. The latter has its upsides too, but it does mean that sometimes things can't be changed in Linux. In this case working towards a modern cron, even if it meant it wasn't completely backwards compatible.

4. Legacy setups: Deviate from classic cron and userland legacy programs and their work flow may break. Paying customers don't like that, and it means userland won't ship with any cron scripts that uses the new features.

Sure, you can make "cron-like" programs like fcron that fixes some of the problems. But first, it isn't cron, only cron-like, so lots of people will reject it. While it works on many distro's, AFAIK, it isn't default on many. In short, fcron and similar solutions will suffer from the 4 points above. No upstream project can ship a daemon with fcron-specfic scripts.

Another thing is that even improvements of cron tends just to be basic improvements of the most glaring errors. Forget for a moment the archaic "crontabs" behavior and similar: Why can't I schedule cron jobs based on inotify detecting a file change? Or when a certain disk is attached, or schedule a program _not_ to run if certain conditions are met like battery level, another program is running, a certain error-message is written in the log, or similar conditional and non-calendar based scheduling?

"cron" is based on certain assumption like calendar/time scheduling. At what point can you extent cron so it adopts new concepts while still being cron? That is the problem, because you really can't; if you fix cron, it won't be cron anymore. "cron" on Linux have for all intents and purposes been fossilized into a state from which it can never really change.

Re:Free speech zone

[Eunuchswear]

just wanted to run a service
i wrote with the ulimit for the number of available files set to be a larger than
default value?

you know it took me a fucking day to figure out how, and it still required a reboot
after install?

You need to upgrade your goole-fu, or just "man systemd.exec".

LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=,
              LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=,
              LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=,
              LimitRTTIME=
                      These settings control various resource limits for executed
                      processes. See setrlimit(2) for details. Use the string infinity to
                      configure no limit on a specific resource.

i gave up on trying to enable coredumps

How hard did you try? https://wiki.archlinux.org/index.php/Core_dump

systemd's default behavior is to generate core dumps for all processes in /var/lib/systemd/coredump. This behavior can be overridden by creating a configuration snippet in the /etc/systemd/coredump.conf.d/ directory with the following content[1][2]: /etc/systemd/coredump.conf.d/custom.conf

[Coredump]
Storage=none

Re:Free speech zone

[ookaze]

I've already linked to pages explaining these, but you obviously didn't read them.

"Poor understanding of interfaces by the lead developers." - thats a new one - where did you get that from, give us some backup to see what you mean.

This link discusses it

So your backup is sth you wrote. Let me get this straight: you're some kind of genius, everything you say is the truth, right?
You are proven wrong just by Gnome adopting systemd-logind API instead of the ConsoleKit one that everyone involved agree was very bad, and systemd-logind API far better. The most obvious giveaway is that you have nothing to say about this interface and what is bad about it, you just write "it's bad".
You thus have nothing to say and have no case, until you find sth bad about the interface. Same for the other DBUS interfaces.

"Poor understanding of portability by the lead developers." - portable to where? its a linux system.

Exactly lol. Linux only. Not portable. This link goes into more detail.

You don't even understand what portable means, even in the nonsense you've written in your journal.
The portability discussed there is between hardware architecture, and systemd is perfectly portable (at least between x86, x86_64 and ARM, the one I've tested), and it's sth very well understood by systemd developers.
You're talking about compatibility between OS, which is nonsense in this case because the problem here is not that the systemd developers can't handle autotools, it's that systemd uses Linux specific API. These API have to be implemented at the kernel level for the most part, which is sth systemd developers don't want to do, and I can't blame them.

"Scope creep (there is no reason Gnome should depend on systemd)." - thats Gnomes problem, LP issued a library to allow Gnome to avoid using logind but GNOME decided not to use it.

Lennart actively pushed Gnome to use systemd, the forum threads are still available if you want to find them.

Repeating again the same misinformation. Gnome doesn't use systemd, some Gnome component use the systemd-logind API, can't you understand the difference?

only the journal has an element of binary and as a journal, it shits all over syslog/rsyslog with better content.

If the init system dictates what logging system you must use, then that's poor design. Also, corrupt binary logs are harder to read than corrupt text logs.

Fortunately, systemd does'nt dictate what logging system you must use.
And no, corrupt binary logs are not harder to read than corrupt text logs: both are unreadable. Only the non corrupted parts are perfectly readable in both cases.

Re:Free speech zone

[Barsteward]

"I can read code. When systemd writes good code, I'll support it." - can you provide us with your code reviews or just point out the "bad" code?

Re:Free speech zone

[Barsteward]

I read them but they are just a load of meaningless diatribes but i see you say that LP is a fine programmer producing readable code and has skill.

"Exactly lol. Linux only. Not portable. " - yes, thats the point. until the other OSs implement things like cgroups, it has zero chance of being portable.

"Lennart actively pushed Gnome to use systemd, the forum threads are still available if you want to find them." - he provided them with a library to avoid logind. So were you offering to maintain the unmaintained ConsoleKit for Gnome to use?

"If the init system dictates what logging system you must use, then that's poor design. " - i don't see why other than its another vague way of trying to damn the far better logging system.

"Also, corrupt binary logs are harder to read than corrupt text logs." - grasping at straws, if a file is completely splattered with binary zeroes then it is unreadable no matter what format it was before.

"It's full of self-contradictions" - only because you cherry picked phrases from the answers and didn't give the full context

"The "biggest myths" page is an example of what Karl Marx referred to as the dialectic (which to Marx meant BS, rather than an approach to the truth)." - Dictionary definition of "dialectic" - discussion and reasoning by dialogue as a method of intellectual investigation; specifically : the Socratic techniques of exposing false beliefs and eliciting truth" and that describes the Myths page perfectly

Re:Free speech zone

[Shark]

You have to employ your superior knowledge into actual competing projects in order to be taken seriously.

OpenRC already exists, does everything we want it to do and (more importantly) nothing we *don't* want it to do.

As such our superior knowledge can be spent in direct and vocal opposition to systemd because everything it claims to solve are issues none of its opponents consider to be actual problems.

Re:Free speech zone

[drinkypoo]

There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).

You can't do it through a capabilities interface, even?

That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.

Why would it need to be married to the init daemon? That's the part that's unclear. cgroups permit management of process groups no matter how, why, or when they were created, or who created them. It doesn't matter if init starts the process, any other daemon could have done that job.

Re:Free speech zone

[Peter H.S.]

OpenRC already exists, does everything we want it to do and (more importantly) nothing we *don't* want it to do.

Well, it is good to know that OpenRC is "finished" and won't get any new features in the future. Of course parallel boot have been inherently broken on OpenRC for the last 4 years which is why it isn't default and marked "experimental" and still no fix in sight. But who boots their pc anyway, or need service management, or OS containers, or ....

As such our superior knowledge can be spent in direct and vocal opposition to systemd because everything it claims to solve are issues none of its opponents consider to be actual problems.

You are just a tiny minority that have been kicked out of all major Linux distros. In the near future 80-90% of all new Linux installations will be systemd based; from supercomputers, smartphones, IVI and other embedded, to desktops and servers.

Being toxic assholes thread jumping every systemd-thread will at best only get you a shrug from the grown ups that actually make Linux software, while at worst, upstream projects may quickly find a good excuse to dump non-systemd support.

Since the anti-systemd crowd have scared away almost all Linux developers and aren't endearing themselves to upstream projects either, and have been kicked out of all major distros, maybe it is time for a little self reflection on why you lot have lost all the battles and the war too?

Maybe spewing hate against systemd isn't a winning tactic? Maybe it was a bad idea from the start and even worse now that you have to beg for mercy in order to have your non-systemd distros supported from upstream in the future?

You lot have radicalized yourself into an extreme and negative position, so please understand if the rest of the Linux community start to give you the cold shoulder.

Re:Free speech zone

[phantomfive]

You don't even understand what portable means, even in the nonsense you've written in your journal. The portability discussed there is between hardware architecture, and systemd is perfectly portable (at least between x86, x86_64 and ARM, the one I've tested), and it's sth very well understood by systemd developers.

I think I understand what "portable" means.

You're talking about compatibility between OS, which is nonsense in this case because the problem here is not that the systemd developers can't handle autotools, it's that systemd uses Linux specific API. These API have to be implemented at the kernel level for the most part, which is sth systemd developers don't want to do, and I can't blame them.

You don't understand how to make things portable. I'm sorry, if you don't understand how to do it, that's your problem.

Re:Free speech zone

[phantomfive]

I see.

Is there anything you don't like about systemd, or is all you can do defend it? Are you blinded into thinking that everything about it is good?

Re:Free speech zone

[Peter H.S.]

There isn't a "revoke privileges" kernel feature either despite years of trying (it is a hard problem).

You can't do it through a capabilities interface, even?

No, it is different from dropping privileges. Here is a short explanation. In this case the user case is being able to use revoke on devices:
https://lwn.net/Articles/54653...

The Linux kernel simply have limitations when it comes to device handling, especially when it comes to security.

That means userspace have to have a sophisticated session manager like logind with kernel integration in order to keep the multi-seat sessions safe.

Why would it need to be married to the init daemon? That's the part that's unclear. cgroups permit management of process groups no matter how, why, or when they were created, or who created them. It doesn't matter if init starts the process, any other daemon could have done that job.

Because cgroups track all processes that are initiated, this is why systemd can track and kill all processes and its subprocesses reliably. It also provides process isolation needed for security (and user sessions).
Cgroups is therefore extremely tightly integrated into the systemd-daemon.

Here is a quote from the mailing list where Poettering explains:

"Well, logind talks to systemd to manage user sessions and user
processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted."
http://lists.freedesktop.org/a...

Things will get even more complicated with the new cgroup API, since that only allows one "writer" on the system, and that writer is supposed to abstract away the low level API so it doesn't expose "kernel knobs" anymore.

There are also the usual reasons for why it really can be limiting to freeze internal API's, and over the time some stuff have moved into "logind" and other stuff out, which wouldn't have been possible if the API had been frozen.

But as said, even if the API was frozen, logind would still require session and cgroups management, and nothing outside systemd really provides that.

systemd really provides a lot of external API's that are frozen and stable, but logind isn't one of them.

Personally I don't see the need either. It has been quite clear for years that the non-systemd distros needed to develop and maintain their own software stack. Both Gnome and KDE developers have repeatedly pleaded for this over the years.

Re:Free speech zone

[phantomfive]

ok, I'll ask you what I asked the other guy, is there anything you don't like about systemd, or do you like everything about it? Are you capable of thinking critically, or are you just another apologist?

Re:Free speech zone

[Peter H.S.]

I see.

  Is there anything you don't like about systemd, or is all you can do defend it? Are you blinded into thinking that everything about it is good?

Most of it is in the details, like systemctl having the action command as the first thing instead of the last like this:

"systemctl /stop/ example.service"

The reason is probably globbing so you can expand a lot of service files one after another, but still, using Bash the workflow isn't perfect since I used to recall the previous command from the stack with ctrl+r and then edited the action command. I haven't found an easy workaround yet. "^start^status" kind of work but is cumbersome and can't be recalled, only the expanded command.

It is also hard to keep track of systemd progress since things are developed with quite some speed.

From a more philosophical standpoint, I wished that systemd actually had something that even remotely looked like competition. It is really good for software projects to have competition; it enables projects to "steal" good ideas from each other and not sag behind in features.
Not having competition may lead to complacency and stagnation.

But I was completely wrong in my assertion that such a competition would arise from the non-systemd distros. I even fear for those distros ability to even maintain existing stuff when the commercial distros stops maintaining their non-systemd software stacks.

Re:Free speech zone

[phantomfive]

Well, that's something anyway. Good job.

Re:Looks like you guys lost

[gweihir]

This fight is not over. From all the error-reports on the mailing-lists of the distros that have started using systemd, at the moment the only thing the opponents need to do is watch the fireworks and occasionally remind people that there are superior init systems and service managers.

We will see how this plays out. I expect there will be some rather quiet reversal in several distros in the not too distant future. And if not, there is no real need to have a Linux kernel under a GNU system. I also see no really serious problems keeping SYSVinit going. The only hurdle seems to be udev, but there is eudev and if that does not work out, I never really had any need of udev in the first place. Overall, it probably cost me more time than it saved. I may just go back to ultra-reliable static device files.

Re:Looks like you guys lost

[Anonymous Coward]

FreeBSD has had its new binary package system for over 2 years now.

pkg install kde4

done.

Also, if you want a Fedora like experience, use PCBSD (FreeBSD + gui installer and a full set of packages by default)

I just attended the sysvinit conference...

[Anonymous Coward]

Haha only joking because that'd be like a grep conference and who needs a junket for a small tool that does one thing well?

Re:I just attended the sysvinit conference...

[gweihir]

What, tools that any competent sysadmin can actually understand and customize? We cannot have that!

Huh?

[Anonymous Coward]

Lennart Poettering Announces the First Systemd Conference

That stupid thing hasn't collapsed under its own weight yet?

Re:Huh?

[gweihir]

Giants collapse slowly. Or rather bloated monsters do.

Re:Huh?

[JustAnotherOldGuy]

C'mon, this shindig will be the perfect place to showcase systemd's conference-room booking module.

Re:Looks like you guys lost

[Anonymous Coward]

But... FreeBSD by far makes the best server OS, with OpenBSD a close second. I've seen FreeBSD servers run circles around Linux servers running on identical hardware. FreeBSD has an uncanny ability to handle loads that bring Linux to its knees. Were I to run my own business, I have often said it would be Free/OpenBSD on the servers and Linux on the desktop. I've seen this setup before and it works a treat.

Re:Ah, Berlin

[smoothnorman]

"least amusing"? aww... for certain forms of 'amusing' it's quite ...amusing; might take a little careful exploration. https://en.wikipedia.org/wiki/...

Re:Looks like you guys lost

[loonycyborg]

stop using Linux and learn FreeBSD.

Maybe after it switches to launchd..

So where is this years GrepCon and BashCon?

[tlolczyk]

Two utilities that are much more important then systemD. I really try to. if not like systemd, at least get along with it. yet the more time goes by the more negative my opinion gets. It really reminds me off all the problems we went through with pulseaudio.

Re:Looks like you guys lost

[Barsteward]

"From all the error-reports on the mailing-lists of the distros that have started using systemd," - can you name any system that does not have any bug reports?

" I expect there will be some rather quiet reversal in several distros in the not too distant future." - just don't hold your breath

"And if not, there is no real need to have a Linux kernel under a GNU system. " - thats true, you could install the modular Hurd kernel instead of the monolithic Linux kernel.

"I also see no really serious problems keeping SYSVinit going." - thats good then everyone can be happy.

Re:Ah, Berlin

[drinkypoo]

A binary file avoids the need to have a bloated text parsing engine.

It doesn't do that, because all the data is interpreted by humans as text, and has to be presented to them as such. It also has to be understood as text, so if the journal processing tools do any of the things that systemd proponents claim they do, they will need a "bloated" text parsing engine.

We are systemd

[ArcadeMan]

We are systemd. Lower your MBR protection and surrender your init system. We will add your daemons, libraries, and utilities to our own. Your code will adapt to service us. Resistance is futile.

Re:We are systemd

[marcello_dl]

You almost fully summarized the philosophy expressed in Pid Eins blog, it is missing one minor point that the borg would express as:
"If you do not like borg, build an alternate borg yourself"

Re: Piss off systemd

[drinkypoo]

Ah, but with every single major distro adopting it, you better quit crying and get used to it, buddy!

They changed to systemd, they can change away just as well. Oh sure, the systemd cancer has spread to many daemons, but it can be excised from them as well. (Ironically, the daemons need exorcism...)

We don't need more systemd hate!

[loony]

all we need is a nice little bomb... We know when and where they will be - take out their leaders and we can move on to something useful!

Re:We don't need more systemd hate!

[mccalli]

If only we had something we could schedule the explosion with...

Re:We don't need more systemd hate!

[amiga3D]

Sounds like a job for Cron.

Re:We don't need more systemd hate!

[ard]

No, not funny. Go write a better init replacement yourself then, no need to even joke about violence.

Re:We don't need more systemd hate!

[swillden]

Sounds like a job for Cron.

Better yet, systemd/Timers: https://wiki.archlinux.org/ind...

Re: We don't need more systemd hate!

[Anonymous Coward]

1: humor is subjective. Black humor most of all. ( iow, I thought it was funny)
2: we had something better. We HAVE something better. Do you see perk progs heaping HATE on Python? No, be cause nobody's forcing them to leave a viable current design for something worse. Systemd is worse, and we're all getting tired of pointing that out and it having no effect: the zombie train toward systemd just keeps motoring along.

Re:We don't need more systemd hate!

[Microlith]

I agree. Whenever someone makes a technical decision I don't like, rather than presenting counter-arguments and alternative solutions, I resort to jokes about murder and terrorism!

Re:We don't need more systemd hate!

[JustAnotherOldGuy]

If only we had something we could schedule the explosion with...

Easy- just use systemd's built-in crontab module to do that.

Re:We don't need more systemd hate!

[Shark]

OpenRC already exists, why would we go and write a new one?

Re:People who like systemd

[Barsteward]

"Of those, I've asked around, and I haven't found any DevOps people who like systemd." - maybe your circle of devops is very limited in number.

I'm sure that if a significant number of credible DevOps (and not the few trolls that make the most noise based on lack of knowledge) voiced valid technical reasons not to use it, Redhat et al would have dropped it.

Some DevOps must be getting worried that more automation of some tasks in their job descriptions are going to be career limiting and the number of DevOps may be cut in an organisation as the work load drops.

Re:People who like systemd

[phantomfive]

I'm sure that if a significant number of credible DevOps (and not the few trolls that make the most noise based on lack of knowledge) voiced valid technical reasons not to use it, Redhat et al would have dropped it.

You're sure? That's all you have? The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps.

"Of those, I've asked around, and I haven't found any DevOps people who like systemd." - maybe your circle of devops is very limited in number.

Indeed, I don't have the resources to do a full survey of DevOps professionals. I can only ask the people I know.

If you are DevOps, or even know of someone in DevOps who uses systemd, I would be interested in hearing your experience. If you're talking from ignorance, then you're boring.

Re:Looks like you guys lost

[arth1]

I am currently porting multiple RHEL 5/6 servers over to other distros without systemd. Going to RHEL7 is just not a viable option for us.
Similar for workstations, where we have stopped ordering Dell N systems with Red Hat, and instead order them with Ubuntu (which we then wipe out - Ubuntu just because it's the cheapest option).

We have multiple in-house daemons, devices and mounts that need to start, stop, and yes, crash without an overseer interfering. Not handing off control is a must. Humanly readable logging is a must. No chance of a buggy startup process taking out the entire startup is a must. Not having buggy software auto-restarted is a must - if we wanted that, we'd use inittab. That we don't mean that we don't.

The amount of red hat subscriptions we have has gone down by around half since RHEL7 was releaseds. This is not a coincidence. Red Hat seems to still be on the cloud bandwagon and thinks that we'll eventually buy their cloud services. Sorry, but disregarding your customers' explicit requirements does not make that exceedingly likely.

Even IBM has abandoned ship, and gotten out of the business of selling RH systems. That this occurred when RH switched to systemd is not only a coincidence. They saw the devil on the wall and pulled out of the certified midrange market at the right time.

Re:Ah, Berlin

[Barsteward]

oh dear, an attempt at personal insults - is that the best you can do?

The comments on here ..

[nickweller]

The comments on here, a classic example of just how badly slashdot has gone to the shits ..

Re:The comments on here ..

[drinkypoo]

The comments on here, a classic example of just how badly slashdot has gone to the shits ..

We thank you for your ironically illustrative contribution. Sadly, we cannot pay you for your efforts, except in raspberries.

Re: Piss off systemd

[Barsteward]

Just wait until "kdbus" is in the kernel.....

Re:Ah, Berlin

[Peter H.S.]

Berlin is way cool; music, culture, food, drink, world class museums, world history; Berlin has it all.

Re: Piss off systemd

[gweihir]

I agree to that. Nothing important is dependent on systemd, except maybe udev. But even that can be replaced with reasonable effort if there is enough motivation. And Gentoo already has a replacement with eudev. Trying an "embrace and extend" move on Linux is ultimately futile. Sure, you can make a lot of people waste a lot of time, but that is it.

Re:Looks like you guys lost

[gweihir]

You know, for a known systemd-shill, you are being exceptionally lazy here. Methinks all this reflection of my arguments is because you have nothing of your own.

BDSM convention

[LaughingRadish]

It seems to me that a systemd conference wouldn't be much different from a BDSM convention.

Re:BDSM convention

[drinkypoo]

It seems to me that a systemd conference wouldn't be much different from a BDSM convention.

The BDSM convention will have a higher percentage of protected sex, and nearly everyone getting screwed will be doing so consensually. Most of them will have a good sense of humor about what they are doing, heavy D/S tops aside.

Re:BDSM convention

[TeknoHog]

Did you just misspell "BSD"? *ducks*

Re:BDSM convention

[nerdonamotorcycle]

Big difference: BDSM is all about consent, while systemd was shoved down everyone's throat while everyone's safewords got ignored.

they announced it?

[rccorkum]

Bitchfest 2015? oh wait I run a system without systemd by user choice and plan to stay that way, hugs his Slackware servers. enjoy that conference of conformity and obedience.and I must be in a good mood I didn't go for the obvious pun based on WHERE the conference is being held.

Re:Looks like you guys lost

[tudorxpopescu]

And what is stopping you from using your stuff the old way with RHEL7? Having init scripts for your daemons that you just copy, etc? Using the old method of logging? Buggy startup process taking out the entire startup, you see that a lot? Hasn't happened for me yet in RHEL7. I'm not saying you should necessarily like systemd, but you can pretty much ignore it and go about your business. Sounds to me like there's more going on behind the scenes than what you're saying, or you're deluding yourself...

Re:People who like systemd

[tudorxpopescu]

The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps.

I am pretty sure those distros who started this spend more money paying systemd developers than they save from writing easier startup scripts.

Re:People who like systemd

[Barsteward]

"You're sure? That's all you have? The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps." - you mean configuration files, not startup scripts. That may or may not be the distros reasons for it but i doubt it. I'm sure they have the staff capable of taking a bash script, copying it and changing a line or two in it for it to work in sysvinit if they wished to, it would be easier than installing systemd.

"Indeed, I don't have the resources to do a full survey of DevOps professionals. I can only ask the people I know." - i wasn't suggesting you do so. I was suggesting the internet would have been ablaze with structured factual comments from these "devops", letters to Redhat etc. a bit like the Devuan guys who put their money where their mouth was and are making their own way without systemd.

"If you are DevOps, or even know of someone in DevOps who uses systemd" it doesn't matter whether i am or not, my point is about the lack of "all these DevOps" that everyone (that is anti-systemd posters) refers to. It should be a large movement capable of stopping systemd developing if they actually existed

Re:Ah, Berlin

[Anonymous Coward]

If you do things in binary, you only need to create text, you don't need to parse it. When a human needs to see something that is stored in binary, you convert it to text and show them, which is a far simpler thing to do than parsing text. When they need to change the binary data, rather than have them type text and then parse that text, you give them simple things like checkboxes and radio buttons and drop-down menus, which the software then reads as simple binary data, and stores as simple binary data.

I really don't get the fetish for text file configuration that Linux has. Every time I need to configure something, I have to learn the syntax of a new configuration file. It's never just "it's text, just type," despite what people seem to think. The ones I hated the most were init scripts that were common a few years ago which every source on the internet said "they're just like shell scripts," but they clearly weren't as there were commands in there about dependancies and somehow the same script managed starting a service and stopping it, but no one had documented the syntax anywhere because they thought it was too easy, and as a result, it was an init system I never used. ...but nearly all text configurations suck, e.g. if you want to change a setting for which there isn't an example, you then have to spend hours reading the manual and testing ideas to figure out how to type something up which the software will parse as commands to make it do what you want. If the software had a GUI configuration tool like virtually every piece of modern software has, you could just look through a few logically-named tabs until you found the option you need, then just check the box beside it.

If Linux were to lose all text configuration files tomorrow, it might actually be the year of the Linux desktop. They're holding it back by making it relatively inaccessible to anyone who doesn't have hours to waste figuring out how to make their computer do trivial things, like running a server. Yes, running a server is a trivial thing when it isn't overcomplicated to hell as it often is in Linux. In Windows, one merely runs an application and configures it via the GUI. In Linux, it would cost them less time to simply go to work and earn the money necessary to buy a copy of Windows. The only reason to use Linux is if you have the skills to sort through bullshit, and so you can make Windows do things that you can't make Windows do. If you just want to be a normal computer user, and indeed, expecting a computer to do things that computers can do is perfectly normal, then it isn't worth the effort. No one expects the process of setting up a smart TV to watch netflix to be difficult just because that's an advanced feature of a television. Similarly, configuring servers and daemons also shouldn't be difficult. Every piece of software should have a GUI configuration tool, but I think it doesn't happen because the GUI is too difficult to use. Writing a piece of software to open a port and exchange data is trivial by comparison, and so a lot of the people writing these daemons simply don't know how to write a GUI configuration tool for their software. ...and bitch about the registry all you want, but the reality is that having a standardized way to store program settings, so that anyone (the GUI, other software, and humans) can easily modify them, is a good thing. It's essentially just like the many text configurations in Linux, that allow you to change settings that no one has bothered to expose via the GUI yet, except that it is a standardized format, so when you need to change it, there's no question of what to do when your string variable needs to contain quotation marks. It isn't done dozens of different ways depending on what software's settings you're modifying, it's done the same way no matter what.

Re:People who like systemd

[drinkypoo]

The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps." -

you mean configuration files, not startup scripts.

No, no he does not, and there is no obvious reason how you might come to that conclusion except deep ignorance. The configuration files for the programs differ little when systemd is involved. The startup scripts are intended to go away, and be replaced by unit files, which are indeed easier to write than init scripts as they are simply a collection of variables. They are organized into sections segregated by square brackets like a windows ini file, but AFAICT the names of the variables are all globally unique anyway (corrections welcome) so you could reasonably just stuff a unit file into a script that would suck it into the environment and then do stuff based on the unit file to implement a really dumb shell script that would be more difficult to customize than what we have now — init scripts which can implement as much functionality as desired.

I was suggesting the internet would have been ablaze with structured factual comments from these "devops", letters to Redhat etc. a bit like the Devuan guys who put their money where their mouth was and are making their own way without systemd.

DevOps doesn't mean much, I share your skepticism of overuse of the term. It's from Agile, and may or may not have useful meaning outside of Agile-land... which itself may or may not have useful meaning.

On the other hand, I keep hearing that systems administrators who use cloud services and are thus "administering" umpty-hojillions of "machines" enjoy systemd because reasons, but I never see a citation for that, either.

It should be a large movement capable of stopping systemd developing if they actually existed

You can't stop systemd from developing, especially since it had corporate backing. And for people who don't follow every distribution's MLs, systemd sort of snuck up on us. We didn't imagine that debian would convert to systemd, for fuck's sake. Statistically nobody even imagined that until it was happening. Who would have ever thought that the one time Debian moved quickly on something, it would be something contentious?

Re:People who like systemd

[phantomfive]

"The distros are using systemd because it makes writing startup scripts easier. They take up fewer lines. That's about it. It has nothing to do with DevOps." - you mean configuration files, not startup scripts. That may or may not be the distros reasons for it but i doubt it. I'm sure they have the staff capable of taking a bash script, copying it and changing a line or two in it for it to work in sysvinit if they wished to,

That is the reason Debian adopted systemd. You don't have to doubt, they've been public about their decision: it makes writing init files easier. I've written at length on this topic.

Crossed-Fingers

[VonSkippy]

Does it make me an evil person hoping a very small and precisely targeted asteroid hits the convention center at that time?

Re:Crossed-Fingers

[tihokibertron]

Slackware not good enough for you?

Systemd don't need no stinken' conference?

[nickweller]

@QuietLagoon: "If a startup management subsystem needs its own conference, it is doing too much." ref

That has to be the dumbest statement I have read on any technical forum - ever !

I suppose if he didn't organize a conference, people like you would complain that he was dictating to Linux developers.

Re:Systemd don't need no stinken' conference?

[grcumb]

@QuietLagoon: "If a startup management subsystem needs its own conference, it is doing too much." ref

That has to be the dumbest statement I have read on any technical forum - ever !

This from the guy who couldn't even find the 'Quote Parent' button.

Re:Looks like you guys lost

[Barsteward]

yep, i'm getting lazy. it gets boring reading the same old inaccurate crap about systemd.

You didn't make any arguments to answer, you just made some vague comments and predictions with no substance that suits your opinion. Now who is getting lazy or have you run out of anti-systemd comments that haven't been refuted?

i've got no problem with people who do not like systemd (in the same way i don't like liver) but when they come out with crap and lies to justify it then it gets tedious.

Re:Ah, Berlin

[drinkypoo]

I really don't get the fetish for text file configuration that Linux has.

And that's why you, and people like you, persist in trying to ruin Linux. You don't understand why it's successful.

The ones I hated the most were init scripts that were common a few years ago which every source on the internet said "they're just like shell scripts," but they clearly weren't as there were commands in there about dependancies and somehow the same script managed starting a service and stopping it, but no one had documented the syntax anywhere because they thought it was too easy, and as a result, it was an init system I never used.

Just admit it: you don't understand shell scripts. Once you admit that, life will become a lot easier. You'll pick up a book on the subject, perhaps, or you'll read some websites. Then you'll learn how to read the scripts, and figure out where they're getting those "commands" that don't appear in the filesystem, not even when you use find instead of which. You'll see that they source a library at the top of the init script, and you'll follow up and read that library and you'll figure out how those variables at the top of the script which handle dependencies work. And then you'll see that there is really no need for systemd; cgroups support could have been added to those shell scripts, for example.

but nearly all text configurations suck, e.g. if you want to change a setting for which there isn't an example, you then have to spend hours reading the manual and testing ideas to figure out how to type something up which the software will parse as commands to make it do what you want. If the software had a GUI configuration tool like virtually every piece of modern software has, you could just look through a few logically-named tabs until you found the option you need, then just check the box beside it

Binary configuration files don't solve this problem! They don't magically make GUI configuration dialogs appear! Many Unix programs have complicated configuration files with no GUI to configure them because what they do is complicated, and a GUI capable of fully configuring them would also be very complicated. You're not going to automagically get GUI config tools for all those programs. If you outlawed ASCII, human-readable config files tomorrow, what you would actually have is a hodgepodge of different binary configuration file formats, each with their own inscrutable command-line tool for manipulating them.

It's also worth noting that many if not most windows programs have text configuration files! So, are you trolling, or do you really not understand that this is not the point of contention? It's over binary log files, not config files! Even systemd has ASCII configuration files! For now, anyway...

Re:Ah, Berlin

[smoothnorman]

i really don't want to support Poettering because i don't like the direction systemd has taken. but it's comments exactly like this that make me want to defend him. go with the childish ad hominem statements and lose your argument.

You're naming a conference systemd.conf?

[Culture20]

That's like naming a software project OpenOffice.org. It's just asking for some level of confusion just to be cute (okay, oo.org was an attempt to alleviate confusion about .org vs .com domain name, but you get my drift). Call it what it is: the Great systemd Con.

systemd is great

[rainer_d]

Brings new users to FreeBSD and in a while the developers will have figured out something similar for FreeBSD that actually works.

Re:Piss off systemd

[Anonymous Coward]

Systemd conference -- you're going whether you want to or not.

systemd is the best init system for FreeBSD.

[Anonymous Coward]

systemd has proven itself to be the best init system for FreeBSD.

The use of systemd by default in Debian, along with pretty much every other major Linux distro (sorry, Slackware, you're a relic; Gentoo, you're impractical) has driven away the best Linux admins and developers there are.

These are the men and women who run important servers that must fully boot each and every time. They're the people who develop critical software that always needs to work. The kinds of bugs that systemd has shown to have just aren't acceptable for these users.

After seeing the quality standards of so many Linux distros drop to unacceptable levels all thanks to systemd, these people have been forced to find better alternatives.

FreeBSD, and to a lesser extent OpenBSD, have been where they've fled. These are robust systems that are often equal in capability to Linux, but with much greater stability, and a team of developers who have their priorities straight. They will not compromise their software like so many Linux distros have done.

FreeBSD now boasts some of the best sysadmins and users among its ranks. It's seeing more and more use by people who know what they're doing, and who are doing very demanding work.

The future is brighter than ever for FreeBSD, while the future is looking dimmer and dimmer for Linux. It didn't have to be this way; Linux would still be a perfectly fine option for these users, had so many distros not been infected by systemd.

Historians will note that it wasn't Microsoft or SCO or any other external attacker that destroyed Linux. The Linux distros destroyed themselves, and their usability, by including systemd.

Re:systemd is the best init system for FreeBSD.

[TeknoHog]

The use of systemd by default in Debian, along with pretty much every other major Linux distro (sorry, Slackware, you're a relic; Gentoo, you're impractical) has driven away the best Linux admins and developers there are.

That's some interesting logic. So, most Linux distros are going down the drain because they use systemd, and I quite agree with that. And then those that don't use systemd, they are also doomed by definition?

I used NetBSD for a while around 2002, and I loved the pure Unix way after using all these Fisher-Price Linux distros. However, it was seriously lacking in hardware support and software availability. Fortunately, I soon discovered Gentoo that combined everything that was great in both Linux and BSD, by modelling after BSD Ports but using the Linux kernel and GNU userland. So it's strange getting such a comment from the BSD camp, while Gentoo is one of the closest to BSD style of all Linux distros.

Re:systemd is the best init system for FreeBSD.

[JSG]

"(sorry, Slackware, you're a relic; Gentoo, you're impractical)"

Sorry AC , you don't get it: It doesn't matter whether 1 or 1 billion people use a distro, they are exercising their choice - their ability to choose what they want. That is the most powerful aspect of free software whether it be Gentoo, Slack, Yggdrasil (my first), *BSD or whatever.

YOU GET A FUCKING CHOICE OF WHAT OS TO PUT ON YOUR COMPUTER.

Your insinuation that FreeBSD will somehow slide into the breech to replace Linux is almost as laughable as this being the year of Linux on the Desktop.

BTW I use Gentoo quite a lot (50 odd systems) and they all have pid 1 == systemd ...

Cheers
Jon

Re:systemd is the best init system for FreeBSD.

[Anonymous Coward]

The problem is many people WANT A FUCKING CHOICE OF WHAT INIT SYSTEM TO PUT ON THEIR COMPUTER TOO. Freedom to choose a component or other operating system is a good thing and should be maintained.

Many people pushing systemd are trying to eliminate choice though, and that's where things go wrong. They resort to nasty SJW tactics against those who resist having their choices stripped away. It's a mindfuck to see systemd pushers who claim to value freedom but don't see a problem in striving for a systemd monoculture.

Re:systemd is the best init system for FreeBSD.

[pi_rules]

Personally I'm toying with the idea (literally testing stuff in VMs) of moving my stuff to FreeBSD or OpenBSD because of systemd wiggling into most Linux distros. I've been using Linux for about 18 years, so I have some knowledge of the inner workings, and I've generally been a Debian guy but moved to Ubuntu 3 years ago for rather trivial reasons.

When Unbutu comitted to systemd I figured I'd go back to Debian on the servers (leaving desktop-ish things to Ubuntu) but with Debian throwing in the towel my servers might move to FreeBSD... and I'll start toying with OpenBSD for the firewall.

Re:systemd is the best init system for FreeBSD.

[Eunuchswear]

The problem is many people WANT A FUCKING CHOICE OF WHAT INIT SYSTEM TO PUT ON THEIR COMPUTER TOO.

Hey, buddy, I have news for you, with Debian Jessie: YOU HAVE A FUCKING CHOICE OF WHAT INIT SYSTEM YOU PUT ON YOUR COMPUTER.

You DIDN'T USED TO, sysvinit was essential. Now you have a choice, install sysvinit, upstart, systemd or OpenRC as you wish.

Re:systemd is the best init system for FreeBSD.

[morgauxo]

"Gentoo, you're impractical"

Gentoo isn't really as impractical as it sounds.

Most admins will naturally keep the software installed on their servers pretty spartan. Less software installed means less software to compile. For a server updating may seem long to someone who started with binary packaged Linux distros some time in the 20-teens but if you already lived through downloading binary packages over the slower internet connections we had before that it really isn't that bad.

On the desktop... certain things like Gnome, KDE or LibreOffice can take over a day to build. Fortunately... new builds of those things don't come that often.

This still may sound pretty bad but consider this... It's all automated. It isn't like you have to sit there and babysit it. Just run it in a screen session. You can keep using your computer just like normal while updates are building. Most of the time I don't even notice the difference. But.. if you really need the CPU for other things you can always nice the build down. It may take longer but it is out of sight, out of mind running in a screen session so who really cares?

So.. why bother? Sometimes people make fun of Gentoo users for being overly obsessed with optimization. Yes.. that is one advantage, you can optimize everything and make it run a lot nicer, especially on older hardware. That's not a bad thing!

But.. I like it more for the customization. Every program with optional support for any particular file format or compatibility with another program that I like to use automatically gets built with that support.

Also... no dependency hell. Binary distros have gotten a lot better over the years I must admit but.. when you do start installing things from outside your distro's repository.. it can get pretty difficult. If you've ever had apt-get attempt to uninstall half your system because some library update conflicts with something you installed from another repo you will understand what I am talking about. With Gentoo these things "just work"!

Since it's desktops, not servers where people are more likely to install a lot of random stuff and therefore run into dependency issues I think it's the desktop that Gentoo is most advantageous for, not the server. Once one tries to advance beyond just using the default applications that come with the distro I actually think Gentoo is the best desktop Linux out there!

I'm not selling any KoolAide though. I don't think Gentoo is THE best distro possible. I would like to see something that mixes binary and source base a bit better. It would be nice if.. when none of my Use flags or compiler options depart from the norm Gentoo would just download a binary. Maybe users could even set up a P2P network of trusted friends which shares the build load, copying binaries between users with similar use and compiler flags. Another feature might be an emerge command that automatically downloads a generic binary for immediate use but simultaneously begins building the customized one to replace it in the background.

Maybe I'm describing Arch? I haven't tried that yet.

Oh, yah... I think it's great that Gentoo supports Systemd without ditching Openrc. I have no particular hate for Systemd although some things do concern me. Whatever problems it solves they are not ones that have affected me personally.

I think it's a shame that Gnome and Kde seem to be set for requiring Systemd. I use neither myself currently although I am concerned that I may be forced to install them in the future depending on how remote display ends up working out in Wayland. I will not be surprised if this means I am forced to use Systemd.

It seems like, contrary to how Linux software developed in the past more and more is being written specifically to work with either Gnome or KDE rather than being written to just work with Linux in general. Were it not for this I would think that their reliance on Systemd is only their own problem. It is already difficult to find a decent DVD-burner front-end that works without either installed for example.

Re:systemd is the best init system for FreeBSD.

[paulatz]

Learning systemd is much easier than porting a gazillion machines to *BSD, I literally did it in one afternoon. You have to RTFM though, which may be hard on your ego.

Re:systemd is the best init system for FreeBSD.

[Eunuchswear]

The problem is many people WANT A FUCKING CHOICE OF WHAT INIT SYSTEM TO PUT ON THEIR COMPUTER TOO. Freedom to choose a component or other operating system is a good thing and should be maintained.

Then use Debian Jessie. YOU HAVE A FUCKING CHOICE OF WHAT INIT SYSTEM TO PUT ON YOUR COMPUTER.

Any vendors at the conference should be wary

[Jailbrekr]

They'll let you set up your booth and start selling your wares, but out of nowhere they'll just up and take over, thinking they can sell your pop and water better.

Re:Piss off systemd

[Microlith]

I love it when anonymous cowards make emotional, knee-jerk reactions to things like this. It shows how truly hollow most of the opposition to systemd is.

Re: Piss off systemd

[Microlith]

Yeah, it'll be so terrible because... because...

Can you explain why this is a bad thing? Or is this another purely emotional "I don't like it!" tantrum?

Re:People who like systemd

[Barsteward]

"The configuration files for the programs differ little when systemd is involved." who is talking about them? I'm talking about systemd config files to start services etc

"The startup scripts are intended to go away, and be replaced by unit files, which are indeed easier to write than init scripts as they are simply a collection of variables." - they have gone but systemd allows you to still run them if you wish to configure it so. you have a very simplistic idea of a unit file if you think they are just full of variables

"They are organized into sections segregated by square brackets like a windows ini file, but AFAICT the names of the variables are all globally unique anyway (corrections welcome) so you could reasonably just stuff a unit file into a script that would suck it into the environment and then do stuff based on the unit file to implement a really dumb shell script that would be more difficult to customize than what we have now — init scripts which can implement as much functionality as desired." I know what the configuration files look like and there is bugger all chance of putting an execute bit on it and it working as a sysvinit run script. Again, there is more to unit files than "variables"

systemd unit file definition "A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd, a temporary system state snapshot, a resource management slice or a group of externally created processes. "

Too complicated for an init system

[fozzmeister]

So Systemd is so complicated it needs a conference... That should be a point of shame for an init system not something to be proud of...

Binary logs...

[Alomex]

I've been doing software development over many years and in many capacities. One of the hard earned lessons from that is: always use text logs and configuration files in some type of XML-like extensible tag format. If space gets to be an issue, archive old logs using a standard compression package.

Every time I made this choice programmers would complain about the waste of space, until the first real big crash happened, everything was unusable, yet the logs could still be grep'ed and the error easily found. This is the first time they would see the benefits.

The second was when new fields were added, yet the old log libraries still worked. They would simply not read the unknown tags but could still process known ones.
 

Re:Binary logs...

[JSG]

"One of the hard earned lessons from that is: always use " A BATTERY BACKED RAID CONTROLLER and UPS, a decent SAN etc etc - FTFY.

"I've been doing software development over many years" - Shows. Sorry for being blunt but you did not major in sysadmin. Your logs should not be on the failing system in the first place if they are important.

You should only worry about your log format as a parameter not a life choice.

Re:Binary logs...

[Zan Lynx]

Compressed log files? Binary files, unrecoverable if they experience data corruption.

XML like tags? Structured data tagging. Also markers for resync in case of data corruption.

In fact, not very different from the systemd journal.

Re:Binary logs...

[Eunuchswear]

One of the hard earned lessons from that is: always use text logs and configuration files in some type of XML-like extensible tag format.

"always use configuration files in some type of XML-like extensible tag format."

That's the lesson you learned? "XML-like"?

Bleurgh.

Re:People who like systemd

[Barsteward]

This seems to say more than what you think were the reasons for adoption. https://wiki.debian.org/Debate...

The critical question...

[JustAnotherOldGuy]

The critical question that must be asked is, "Is systemd webscale?"

Re:Piss off systemd

[Anonymous Coward]

Whew, it's a good thing that you're posting your full real name, "Microlith", and not some sort of a pseudonym! Otherwise we'd have to think that you're posting anonymously, like some sort of a coward.

That aside, the problems with systemd are well-known. There's nothing "knee-jerk" about standing against it.

We really shouldn't have to rehash the problems with systemd each and every time it comes up. We know what the problems are. Its philosophy is backward. Its architecture is full of bad ideas (binary logging being a huge one). Its implementation and the integration of it with distros, especially Debian, has been rife with severe problems. Many, many people have had many hours of time wasted fixing utterly stupid problems caused by systemd. Other software developed by many of the same people, notably PulseAudio and Avahi, have caused similar severe problems for most of their users. It has been forced upon unwilling victims, which in the case of Debian has caused significant damage to the social structure of the project. It has caused many Linux users and admins to lose trust in the major Linux distros that have switched to it. And that's just a high level overview of just some of its problems!

We're past the point of identifying problems with it. We know what they are, and we know that there are too many of them. We also know that some of them are impossible to fix. You can't "fix" binary logging. You just have to get rid of it completely! That's essentially the only way that systemd as a whole can be "fixed": by totally discarding it.

Until the major Linux distros get their shit together and stop using systemd, it just won't be an option for many long-time Linux users. These users aren't in a position to deal with the problems that systemd has caused. They need software that's robust and reliable to an extent that systemd has so far not been able to come anywhere close to. So these people are moving, or have moved, their workstations and servers to the *BSDs, to Solaris, and some have even moved to Windows. You know things are bad when staunch Linux supports have come to the conclusion that Windows is actually a better option!

Re:thank you systemd

[Barsteward]

Does that mean you went to www.linuxfromscratch.org and downloaded and compiled it all? thats the only way your "how I want my system to work (not how some other person thinks it should...)" would work in reality.

Re: Piss off systemd

[Barsteward]

I've not got a problem with it, its sounds like it might be good but needs a lot of stress testing once it near inclusion. i was just altering the anti-mob to the next thing to be anti about. :o)

Re:Piss off systemd

[Anonymous Coward]

Actually, Debian should have been forked to include systemd, not forked to exclude it!

That's the whole point of forking. You fork, do experimental stuff like integrate systemd in this fork, and then throw the fork away when it becomes clear that the idea was a dumb one.

When done sensibly like that, the source is left unaffected by experimentation that proves to be disastrous.

Debian users could have continued to use a stable, sane, reliable, trustworthy system, like they've been accustomed to for a couple of decades now.

Those who want newfangled and unproven doodads and curiosities could have used the systemd fork of Debian. When they got bored, or suffered from one failure after another, they could always limp back to Debian.

systemd is my fault

[Earthquake Retrofit]

I may be somewhat more susceptible to guilt than most. Something happened to me a few years ago at the Z-80 Lounge in San Francisco. It was a day before my birthday. This guy I had never seen before sat down next to me and told me he needed my help. 'Okay' I said. If I had something else to do I wouldn't have been there in the first place.

'I need you to prevent something horrible from happening in the future, Steve.' He then nodded at the TV. There was a game on and along the bottom of the screen was a stock ticker. After reading from his tablet for a moment he said, 'Jackson is gonna score on a third-down pass in a minute.'

We watched three plays and sure enough, he was right. He proceeded to call the next series exactly. 'Nice trick.' I said, 'But this broadcast must be delayed.'

'That stock ticker isn't though, is it? Check your timepiece. The market closes in ten minutes.' He then showed me the closing price for both exchanges and bought me another stout.

It must have been a wild day on Wall Street because prices were feverishly swinging up and down. But he got the final numbers, right down to the penny. 'I'm from the future.' he said.

Now you hear all sorts of crazy talk at the Z-80 Lounge. And San Francisco IS the golden cultural capital in the hearts of hippie hackers everywhere. So I figured he hacked my tablet. "You have to stop it. It's called system..." But just then, a big hand clamped over his mouth and two big guys in suits grabbed him and dragged him out so I never knew until now what he was talking about.

Sorry.

Re:People who like systemd

[phantomfive]

That web page is actually a disappointment. It is more like a list of every feature in systemd, as if it's trying to overwhelm you with data. It is highly unlikely that Debian switched because they liked every systemd feature equally, but that web page doesn't make clear which features they liked. Most likely there was a killer feature that made them want systemd.

And that is true, once you start digging in the forums, you find that they didn't like every feature equally, they liked simplicity of writing unit files over init scripts. That was the killer feature.

Re:Interesting

[dwywit]

I thought it was part of the philosophy - you're free to inspect, modify, and re-distribute the code....so why is it now a bad thing for there to be lots of options for users to choose from?

You're absolutely right about the documentation.

Re:Ah, Berlin

[dwywit]

Let's not forget the Techno-viking.

Hey, now THAT'S an interesting analogy - maybe systemd IS the techno-viking, bouncing and stuttering its way into the mainstream, with a series of incomprehensible yet hypnotic dance moves.

Re:Looks like you guys lost

[Dutch Gun]

Maturity isn't really about age, but of total development hours. Popularity matters, because it helps to attract contributing developers, and more can be done in a shorter amount of time. Because of it's popularity, I think it's probably fair to say that Linux has matured faster than FreeBSD. As a counter-example, GNU/Hurd has been in development for fifteen years and is still not ready for prime time at version 0.6.

Re: Piss off systemd

[JSG]

"And Gentoo already has a replacement with eudev."

As with everything in Gentoo - it's all about choice. I've taken the liberty of ditching OpenRC and gone systemd everywhere I run a Gentoo box - laptops, servers etc etc. I run around 50 systems on Gentoo mostly servers. Wifey gets Arch on her laptop because compilation time.

One big gain is not having to write my own custom init scripts and simply scrape another distro's effort if it isn't available in Portage. The only thing I really dislike with systemd is: systemctl . Why put the bit that you will want to edit in the middle? It's particularly ironic given that LP is German and they slap the verbs at the end of a sentence. Perhaps that wasn't his input.

That's _my_ choice, you can make yours as you like.

Cheers
Jon

Re:People who like systemd

[Peter H.S.]

On the other hand, I keep hearing that systems administrators who use cloud services and are thus "administering" umpty-hojillions of "machines" enjoy systemd because reasons, but I never see a citation for that, either.

"Spotify", the music streaming service directly voiced their support for systemd on the Debian mailing list when they discussed switching to systemd.
https://lists.debian.org/debia...
Spotify have doubled the number of paying customers to 20 million (75 million users in total) since then.

Pantheon were running 500.000 systemd units in 2013:
https://pantheon.io/blog/panth...

Here is how they used systemd to patch Heartbleed without rebooting (they were running 5000 nginx instances on one box):
https://pantheon.io/blog/how-w...

And for people who don't follow every distribution's MLs, systemd sort of snuck up on us. We didn't imagine that debian would convert to systemd, for fuck's sake. Statistically nobody even imagined that until it was happening. Who would have ever thought that the one time Debian moved quickly on something, it would be something contentious?

Debian was an early systemd adopter, it just wasn't the default init-system.

I think it was pretty clear that SysVinit was dead years ago (last I looked they haven't released for 5 years, probably because the developers doesn't even have a build and test system, so only way to test a patch is to boot with it. RH and later Debian had been defacto Upstream for SysVinit for years).

Upstart was never going to be an option for Debian as long as Canonical insisted on the CLA. This left systemd as the only serious and mature init-system and Debian developers had long worked towards it being the new default init-system when some people suddenly started to make noise about it, which lead to the CTTE decision, which lead to the GR that showed how overwhelming the systemd support was among Debian Developers.

The point is that Debian had long been on its way to become a systemd distro, what the Debian Developers decided on the GR was to keep status quo and continue to work towards systemd. It was never a sudden decision, it had been years in the making.

Re:Ah, Berlin

[Dutch Gun]

I really don't get the fetish for text file configuration that Linux has.

Text is attractive because it's a least-common-denominator and *universal* format. However inconvenient it may be to parse and organize, you can write a reasonably simple script to do it, and you can pipe it through just about any command to transform or process it in whatever way you want. With text, you never have to worry about a black box of a file, because it's always human-readable, and thus more amenable to hacking.

The downside for log files is that text-based formats are incredibly inefficient as backing stores for any substantial amount of data. And as a configuration format, it's incredibly difficult to write front-end configuration software for scripts, although less so with regular formats like json or xml. Once the configuration is in a script, automated management of that configuration pretty much goes out the window - you're essentially committed to maintaining scripts by hand. This is not a problem for system administrators or advanced users, but horrible for normal users and GUI systems.

There are legitimate points on both sides, and which side you come down on may depend on your primary use case.

Re:Interesting

[JSG]

Care to really quantify that, based on real experience? Here's my ha'p'orth.

Linux kernel: You get the source and quite a lot of info on what each option does in menuconfig or whatever.
Mailer daemons (for example): Postfix, Exim and Sendmail are very well documented, have excellent mailing lists. Masses of examples across the web and shed loads of forums and postings
Samba, BIND, KDE, Gnome, Apache, nginx, HA Proxy, Elastic Search, Hadoop, Postgres, MariaDB, libvirtd, Xorg, NetworkManager, FreeCAD, LibreCAD, LibreOffice, OpenOffice, Evolution, Krita, Scribus ...... blimey the list goes on and on and on. Anyway they all have really good docs and a massive support organisation.

Do you really think that a distro needs to do anymore than note down what they do that is "different"?

limit anonymous posts when systemd is the subject

[cmurf]

I think any systemd related slashdot article ought to come with a number or time limit for anonymous coward posts. They all just seem to rile themselves up to ad homs and then talk of death and misery and then it just upends the whole conversation.

The name is a bit funny

[sjukfan]

I admit I enjoy wordplay like systemd.conf, but since systemd uses binary log files shouldn't the conference be called systemd.bin?

Re:The name is a bit funny

[TeknoHog]

It's a wonder the name is human readable at all.

Re:Interesting

[thegarbz]

Clearly the answer is to split every distro in two allowing people the choice of SysVinit and Systemd :-)

Re:Piss off systemd

[grcumb]

Systemd conference -- you're going whether you want to or not.

Oh for fuck sakes, you neckbeards never give up, do you?

First off, it's not a conference at all. We're just putting a few hundred people into the same room and giving talks. Just because you think that's a conference doesn't make it one. It's actually a confluence, which is something completely different that we just made up right now.

Second, nobody's forcing you to go. We're just relocating your office there for the week. If you have a problem with that, take it up with your boss. We didn't force anyone to move; we only changed the location of the building you're presently occupying.

Third, it's not one conference at all. It's just a collection of independent sessions in which a sentence is started in one session

and finished in another. But they're complete

ly independent of one another.

And why do you hate Dear Lead—er, Lennart so much? I find his work inspiring, a triumph of the will... if you will. His Kamp—er, his struggle— has been an inspiration for everyone who loves the discipline and honour of coding in der recht*cough*sorry in the Right Way. It's merely historical necessity that you unterprogrammers must be dealt with. No mercy for the dirty hippies! You cannot continue harming the purity of the FatherCode! Hail SystemD! Lebensraum for SystemD!

Re:Ah, Berlin

[grcumb]

The least amusing city in the world.

Perhaps, but just wait till we announce the Reichstag bonfire and hippie roast! SystemD über alles!

Re: Piss off systemd

[Anonymous Coward]

Nice systemd rant... Too bad we're talking about kdbus.

Re:Looks like you guys lost

[arth1]

Maturity isn't really about age, but of total development hours.

No, post-release runtime factors in heavily.

Popularity matters, because it helps to attract contributing developers, and more can be done in a shorter amount of time.

On the contrary, development time goes up with the number of developers. The scope and complexity of the project can increase, which may or may not be a good thing. In the Unix-like world, it often isn't. Backwards compatibility and dependency avoidance are more important.

Re:Looks like you guys lost

[Dutch Gun]

When you're trying to create a general-purpose operating system, especially one that runs on common commodity hardware, the scope and complexity of your project is already largely decided. There's no such thing as a "simple" operating system nowadays, unless you're willing to discard quite a few features most developers and users take for granted.

Development time goes up with the number of developers.

I'm guessing you can't have really meant that literally. A simple thought experiment makes it clear that the optimal development number for any project is not one programmer.

What I'm guessing you're referring to the assertion (assuming you're talking about the mythical man-month) that development time is extended when adding new programmers to an already late project. It really doesn't apply to general development-team scaling, because even if efficiency per developer goes down with larger teams, it doesn't reduce it to negative gains.

More developers mean a lot of would-be-nice-to-have tasks get implemented, instead of just the absolutely-must-have tasks. If you want to call this "additional complexity", that's fine. The rest of the world call them "features".

Re:Looks like you guys lost

[fahrbot-bot]

Maturity isn't really about age, but of total development hours. Popularity matters, because it helps to attract contributing developers, and more can be done in a shorter amount of time. Because of it's popularity, I think it's probably fair to say that Linux has matured faster than FreeBSD.

You forget that for the entirety of time from 1977 and 1991, there was no Linux, just BSD (excluding AT&T versions) so all the development time was spent on BSD, from which FreeBSD comes. In addition, FreeBSD supports Linux Binary Compatibility - with exceptions, of course. There is also a lot of cross pollination between Linux and the BSDs now.

In some sense you're comparing apples with somewhat different apples and I think it's fair to leave it as a "to each their own" kind of thing and YMMV.

Re: Piss off systemd

[gweihir]

As long as there _is_ choice, I have absolutely no issue with people using systemd. The problem is that on my current main distro (Debian) it looks like that choice will be going away. And that is just not acceptable.

Trolling for Facts

[drinkypoo]

It's a fact that systemd proponents abuse moderation to support systemd. It is my assumption that they do this because they know systemd is shit, and that they are shit, and they can't handle the scrutiny.

Re:Interesting

[ruir]

Oh yeah, because sysvinit will take a lot of work porting to...I guess in the last 20 years we lived in some alternate reality.

Re:Piss off systemd

[ruir]

Alas, finally a comment with some sanity.

Re:Interesting

[slashways]

The classical UNIX philosophy is one daemon one goal, perfectly implemented, fully secured and full documented. Systemd breaks this view and takes the windows 7 and before concept. We know that results of this second philosophy: One software that does everything, using a quick and dirty implementation, with an incomplete, and erroneous documentation, and the security is done in a fully procrastination way... Are you sure that systemd can really escape this second philosophy? In my opinion it can’t. I’m still using the slackware distribution, and I hope they will stay away from systemd.

oh, wait, I see they already are...

[Thud457]

be a terrible shame if somebody added ISIS to the guest list...

Re:oh, wait, I see they already are...

[morgauxo]

That much evil in one place at the same time... What are you thinking?

Re:Looks like you guys lost

[gweihir]

Indeed. Completely characteristic fro almost all pro-systemd propaganda. These people seem all to be working from the same instruction manual.

Re:People who like systemd

[geggam]

https://pantheon.io/blog/panth...

Here is how they used systemd to patch Heartbleed without rebooting (they were running 5000 nginx instances on one box):
https://pantheon.io/blog/how-w...

restarting process / containers and counting processes as servers but claiming to not reboot is cheating.

If you call a container a server and restart the container process you rebooted it. If you count processes as servers... well... its not.

Re:Piss off systemd

[Barsteward]

the post was not worth a point by point rebuttal, its just the same drivel that has been rebutted many times before

Re: Piss off systemd

[Eunuchswear]

The problem is that on my current main distro (Debian) it looks like that choice will be going away.

It does? How? Where?

Re:Interesting

[Eunuchswear]

If I want to set up a Debian 8 system, giving it a reasonable amount of effort and within a reasonable period of time, then I'm forced into using systemd.

Sure, in theory I could potentially waste a whole lot of my time and expend a whole lot of energy trying to use Debian 8 with some other init system.

Because it takes days to type

# apt-get install sysvinit-core sysvinit sysvinit-utils
# apt-get remove --purge --auto-remove systemd

Re:People who like systemd

[Peter H.S.]

restarting process / containers and counting processes as servers but claiming to not reboot is cheating.

If you call a container a server and restart the container process you rebooted it. If you count processes as servers... well... its not.

At no point did they restart any OS containers or even physical servers, only the affected services. That meant all other services where available for their customers the whole time. Even for socket activated services that used SSL, connections where available all the time thanks to systemd buffering request on the socket.

They don't call processes "servers", since they run OS containers, not Google style process containers, so each OS containers have a number of running processes. Yeah, "container" can mean a lot of things.

Re:Cue Admiral Ackbar!

[Eunuchswear]

So, you're wishing for Stormtroopers to descend on a systemd conference.

That's being held in Berlin.

Maybe time to brush up on your history and stop watching so much Star Wars.

Re: Piss off systemd

[macs4all]

systemd is somewhat like the Windows registry. Monoliths fuck your shit up for no good reason.

Not to defend systemd; but...

isn't the script run by initd a form of "monolithic" construction? If the script is broken, system doesn't boot, right?

If something happens with cron, some processes don't get launched. Etc.

Re: Piss off systemd

[Barsteward]

He was asking about "kdbus" - your response indicates your level of comprehension (lack thereof) and makes the rest of your post worthless (not even a good troll).

Re:Looks like you guys lost

[Barsteward]

you've just proved you don't know anything about systemd

Re:Can't wait for Miguel

[olau]

Miguel de Icaza is not on Linux. He left several years ago.

Re: Piss off systemd

[gweihir]

Some research required. Or you will remain dumb...

Re: Piss off systemd

[Eunuchswear]

Ah, just FUD spreading as usual.

Re:People who like systemd

[Barsteward]

Its only a disappointment because it doesn't agree with you.

Re: Piss off systemd

[mrex]

"One big gain is not having to write my own custom init scripts"

Is this really a big problem for people?! I hear this all the time. Init scripts are shell scripts. They're really simple. I can't even conceive of how one could manage to develop a UNIX daemon and not the shell script to manage its execution.

Dr. Evil's plan for world domination succeeds!

[amoreperfectvacuum]

It's good to see the nefarious plans of evil genius succeed! Lennart Poettering has succeeded in taking total control of all linux implementations! .... ne hah hah...(evil laugh).

Re: Piss off systemd

[PPH]

Can you explain why this is a bad thing?

Because we all watched Windows nearly go down in flames with their monolithic registry architecture. Trivially easy to attack when adding any compromised service requires write access and can just play havoc in there. And even after that fiasco, all the Windows admins moving over to Linux systems blubbered about why Linux doesn't have a registry.

Well, folks. Here it is.

Re: Piss off systemd

[jcoy42]

From the debian release notes for Jessie:

Jessie ships with systemd-sysv as default init system. This package is installed automatically on upgrades.

It then details steps you can take to prevent systemd-sysv from being installed but with the note

(!) Caution Be advised that some packages may have degraded behavior or may be lacking features under a non-default init system.

I read that as saying while you don't have to use systemd, don't expect everything to work if you don't. And once things stop working, the choice pretty much goes away. It's not FUD, that's where it looks like things are headed.

Nuke it.

[BlackPignouf]

Nuke it from orbit, it's the only way to be sure!

Re: Piss off systemd

[Eunuchswear]

And once things stop working, the choice pretty much goes away.

You wanted a choice, you got it.

It's not systemd's problem if other init systems can't do everything systemd can do.

You still haven't demonstrated that "the choice goes away".

Re:Interesting

[segedunum]

You're either trolling or you've genuinely no idea how systemd actually works.

Re:Piss off systemd

[segedunum]

the post was not worth a point by point rebuttal, its just the same drivel that has been rebutted many times before

That's exactly the sentence you're going to hear repeated by Lennart at a systemd conference, ad nauseum.

Re: Piss off systemd

[segedunum]

kdbus will never be put into the kernel. Those proposing it have been asked what they need to provide and they've done nothing but stall, hoping that the argument "Oh, it does this in userspace!" will suffice.

Re:Interesting

[Eunuchswear]

You're either trolling or you've genuinely no idea how Debian actually works.

Those are the commands needed to convert a Debian Jessie system with pid 1 == /lib/systemd/systemd to a Debian Jessie system with pid 1 == /sbin/init and the sysvinit scripts.

Replacing sysvinit with upstart is left as an exercise for the reader.

Re:Looks like you guys lost

[el_chicano]

[regarding FreeBSD's package manager]

Yes, and it'd be nice if it wasn't so hidden.

http://lmgtfy.com/?q=does+freebsd+have+a+package+manager

Yes, the first link returned by a Google search is an absolutely brilliant place to hide information!

[Looks at first link]

Man, who would have ever thought of looking in the FreeBSD documentation for information about FreeBSD?

[head explodes]

Re:Looks like you guys lost

[el_chicano]

More developers mean a lot of would-be-nice-to-have tasks get implemented, instead of just the absolutely-must-have tasks. If you want to call this "additional complexity", that's fine. The rest of the world call them "features".

Nope, if the would-be-nice-to-have "features" make the system less stable or harder to use some of us call would call them "bugs".

Please speak for only yourself and don't pretend you speak for the "rest of the world". We are perfectly capable of speaking for ourselves.

k thx bye

Re: Piss off systemd

[macs4all]

Nobody forgot this shit. If it was better now, I would say it is. It's not.

Linux is the natural flight to quality and BSD is awesome as well. Windows is death knell.

I won't argue ONE BIT (haha) about EVERYTHING you say about the Windows Registry (and trying to troubleshoot Windows problems). Been there, done that. Printed my OWN T-Shirt. Multiple times. I hate, hate HATE the Windows Registry. Even though I haven't personally been hosed by it for a long time. It still scares me every time I type "Regedit", even if it's just to look at something.

And I really don't have an opinion on systemd, because I don't run Linux. However, I would really like to know if you have an opinion on OS X's Open-Sourced launchd; which is somewhat similar in purpose and scope to systemd (but I think came before systemd). Apple has literally millions of copies of launchd in the field, and has been using it since OS X 10.4 (Tiger), which was launched (no pun) a decade ago. And I haven't heard any real horror stories about it. And I see that FreeBSD has adopted it as well. And launchd has normal, ordinary Logs...

Re:Ah, Berlin

[ookaze]

Text is attractive because it's a least-common-denominator and *universal* format. However inconvenient it may be to parse and organize, you can write a reasonably simple script to do it, and you can pipe it through just about any command to transform or process it in whatever way you want. With text, you never have to worry about a black box of a file, because it's always human-readable, and thus more amenable to hacking.

Which is why lots of good Unix tools have a way to export some meaningful data from binary format to text, tools as different as compression tools, databases, document processors, ...
Even the systemd journal has such a tool.

The downside for log files is that text-based formats are incredibly inefficient as backing stores for any substantial amount of data. And as a configuration format, it's incredibly difficult to write front-end configuration software for scripts, although less so with regular formats like json or xml. Once the configuration is in a script, automated management of that configuration pretty much goes out the window - you're essentially committed to maintaining scripts by hand. This is not a problem for system administrators or advanced users, but horrible for normal users and GUI systems.

There are legitimate points on both sides, and which side you come down on may depend on your primary use case.

I agree with everything except the part where you say it is not a problem for system administrators. It is a huge problem for sysadmins on the contrary, mostly because syadmin time is not infinite. And every single time a sysadmin has to update a system component related to these specialised scripts, he has to get back the knowledge of the script, to be able to migrate it. If you have done sysadmin work, you know that even your own scripts written long ago need you to relearn what you have done to be migrated correctly, so it's even worse when you have to parse others'.
This is the most common problems the old sysadmins have when migrating to systemd actually, all the custom scripts they don't master at all and that take lots of time mastering before they can be adapted.
I had to do that for systemd, for example tackle the apachectl or mysql start scripts, sth which is not fun to do at all.
This is the main problem syaadmins face when migrating, we all fear this, and this is caused by the fact that lots of complexity was actualy hidden in shell scripts, the thing that systemd opponents call "simple".
So to me, systemd opponents are either lazy or very bad sysadmins, or no sysadmin at all, who balk at the difficulty of having to labor in complex shell scripts.
You can see that all the complaints are about people migrating their systems, not people starting from scratch on systemd distros.

And contrary to lots of false beliefs spread, people like me that hate sysvinit and shell scripts since more than a decade are actually the most proficient with them. In work environment, most sysadmins I work with have no clue at even how everything works, especially shell scripts.
I had no problem understanding the shell scripts I talked about above for example. I'm sure systemd proponents are more proficient with shell scripts than the opponents anyway, it's a skill needed to migrate. And 15+ years of not using shell scripts for boot didn't lower my knowledge of them, syadmins use shell scripts for lots of things not related to boot.

Re: Piss off systemd

[ookaze]

"One big gain is not having to write my own custom init scripts"

Is this really a big problem for people?! I hear this all the time. Init scripts are shell scripts. They're really simple. I can't even conceive of how one could manage to develop a UNIX daemon and not the shell script to manage its execution.

Init shell scripts are not really simple, that's why you don't understand the problem. They require lots of work and maintenance, which was invisible to users, especially in Linux distributions.
The same people that repeat that shell scripts are simple and work perfectly, usually know this, and they know that as soon as distro sysadmins stop maintaining them, the work will be on these users shoulders. So they spread lies, but lies won't make the work. So this was a lost battle from the start.
There's a reason sysadmins were writing their own custom init scripts, and custom scripts means you have to maintain them when the system updates, so you have to register every single one of them and look for regression. This is lots of work.
And no, good daemons need no shell scripts to manage their execution, and it is nonsense to do that. Even sysvinit has a very basic daemon management feature, that nobody used because it was too basic. Shell scripts have none and can't do daemon management properly, efficiently or securely.

Re:Interesting

[ookaze]

The classical UNIX philosophy is one daemon one goal, perfectly implemented, fully secured and full documented. Systemd breaks this view and takes the windows 7 and before concept.

We know that results of this second philosophy: One software that does everything, using a quick and dirty implementation, with an incomplete, and erroneous documentation, and the security is done in a fully procrastination way...
Are you sure that systemd can really escape this second philosophy? In my opinion it can’t. I’m still using the slackware distribution, and I hope they will stay away from systemd.

Your premise about systemd is already wrong from the start, because you don't even know what you're talking about. No wonder then that everything else you say is plain wrong.
systemd has nothing to do with Windows 7 and before, it's based on Linux specific kernel features, so you mean Linux takes Windows 7 and before concepts?
systemd opponents love making fools of themselves, it's pathetic really. Don't you know the systemd proponents are mostly proficient people, not stupid enough to believe such nonsense?

But, we need that old home

[deepclutch]

What is this man plotting? Is he working for NSA? By committing a genuine code, they can have different plans. We need that old system. Eudev,uselessd - what happened to those projects?