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.

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.

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.

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 into trouble. Another problem was that userspace directly had access to the low level API and various kernel knobs; again, a security problem, but it also meant that nothing could be changed without breaking userspace.

Basically the single entity that are allowed to directly interface with cgroups and the kernel knobs exposed that way. Userspace is meant to use the high level API provided by this writer. There can only be one such writer on a system in the future, on systemd distros this writer will be systemd since it already handles cgroups.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

systemd is seriously good stuff with awesome technology. It is not that I haven't experienced resistance to change over the years in tech: networking guys who trash talked twisted pair ethernet ("It got no collision detection, it will never scale"), tcp/ip ("It isn't an OSI stack, it will never scale, use ATM/whatever instead"), OO-programming, desktop GUI's. I have seen people clinging to DOS, Win 3.11WfG, OS/2 (which was a nice OS) whatever technology long after it was obsolete, ranting about how the new stuff was bad.

Mind you, I am not talking about end users, but allegedly professionals who where making a living in tech. In the end they all ejected themselves out of the tech industry because the old gigs dried up and their skills where obsolete.

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.

Even if your present Linux job doesn't seem to require systemd, some day the boss will come and say; "We need RHEL 7.3 with systemd because of OS containers, and we need it yesterday".

The smart ones of you colleagues have foreseen that scenario, and secretly boned up on systemd, so they can say "Yes sir! Can do! I am a systemd expert, so how about a promotion and bonus?".

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

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.

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

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.

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.

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.