Slashdot Mirror

The article is wrong. Systemd didn't change anything. Debian's config for systemd changed a default. Either option is a problem for people. But its not unreasonable to assume that users that want to have long running process know more about their systems and thus how to change them than users who want everything to stop when they logout. The change in default makes sense, and systemd is doing the right thing here.

What's a pain is the disruption caused by transitioning from a non-sensible default to a sensible default.

Your comment is wrong.

Debian didn't *intentionally* change the default. Systemd did. Debian failed to catch/care/notice/revert the change. This happened with Fedora as well (well, rawhide, Fedora's rolling unstable branch).

When you add in the systemd project's stated intent to make it more and more painful to NOT use the systemd defaults across the board (cf. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html), mincing words about distro-level deviations from upstream is not a very compelling response.

C'mon - what the hell is this shit? OMG - REALLY? Wow - there it is. Crazy.

Somebody needs to get Pottering a girlfriend or whatever. He's going nuts.

By now this has become a job for a squirrel. Or both.

C'mon - what the hell is this shit? OMG - REALLY? Wow - there it is. Crazy.

Somebody needs to get Pottering a girlfriend or whatever. He's going nuts.

By now this has become a job for a squirrel. Or both.

Can we please get an architecture document from the Linux core developers LIMITING the scope of SystemD?

SystemD is supposed to be the Init / Service Management Daemon,

Can we, instead, get a project rename from the systemd developers, so that there's a name for the suite of programs they maintain that's not the same as the name of the process-1 daemon in that suite? That might keep people from making "that doesn't belong in the init daemon!" arguments about "systemd" when the "that" in question is being done by another daemon in the suite.

The offending behavior appears to be behavior of the systemd-logind daemon, which is the daemon that...

and it should have no responsibilities related to managing user sessions.

...is "a system service that manages user logins".

That's Getty's Job, or SSHD's Job, for example, which is unrelated to what SystemD needs to be doing.

Actually, getty, on many UN*Xes, is 1) run by the init daemon and 2) execs the login shell without forking, so that it doesn't stay around for the duration of the session, which means that the job of terminating the session when it's finished belongs to, err, umm, the init daemon.

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Asserting that over and over doesn't make it true. Your argument seems to be that "With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally." Which this change doesn't even do.

Yes it does, because using systemd-run enables you to use resource management on the user run service. See https://www.freedesktop.org/so... for some options.

Also, it really is best practice to totally clean the user session at logout, only allowing explicitly permitted processes to continue to run.

That isn't a problem of course, even with the new systemd defaults. Just use systemd-run --user --scope screen and the process and all other processes started from screen will survive logout.

What the ... ?? Is this a troll? You can't be serious. C'mon - what the hell is this shit? OMG - REALLY? Wow - there it is. Crazy.

Somebody needs to get Pottering a girlfriend or whatever. He's going nuts. Who's paying that guy, anyway? Maybe a government job.

That isn't a problem of course, even with the new systemd defaults. Just use systemd-run --user --scope screen and the process and all other processes started from screen will survive logout.

What the ... ?? Is this a troll? You can't be serious. C'mon - what the hell is this shit? OMG - REALLY? Wow - there it is. Crazy.

Somebody needs to get Pottering a girlfriend or whatever. He's going nuts. Who's paying that guy, anyway? Maybe a government job.

So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?

So please name me just one example of technical rationale that this change is based on, that is not a bug in some other software? What you said is nothing but "we did it not because it's good, but because we can".

There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.

Didn't systemd already do this automatically? And these benefits (in case someone really wants) are not even related to killing background processes.

Yes, a slight change on a perfectly working convention because of a bug in another piece of software. As usual with systemd; and the "another piece of software" is GNOME as usual.

Fear not, people of Slashdot, because there is an option to maintain background processes, even after user disconnection.

But this option is not "on" by default. So, yeah, screen and tmux all of a sudden become useless, unless you fiddle with the knobs.

You are of course wrong. Probably because you never read the technical documentation on this but just relied on wrong hearsay.

Here is the relevant man-page:
https://www.freedesktop.org/so...

As you can see, even with the new defaults, it is trivial to make GNU screen or tmux keep running, even after logout, even with the new defaults settings. You just start them with "systemd-run --user --scope screen" and everything works as before (just a little better).

So, "screen" has always been a good way to ensure that processes don't get killed randomly by disconnections, logout or X crashes.
Then comes systemd and kills all your processes at logout, even when launched with screen.

"screen" will work exactly as it always have, even with the new defaults. You just start screen, either as a proper .service or as a transient service in its own scope using : "systemd-run --user -scope screen". This will make screen run in its own scope so it won't be destroyed when the users scope is purged at logout.

All programs started from "screen" will run in this scope and will therefore remain after logout too.

Use "systemd-cgls" to get an overview of where the new scope is attached.

The man-page is good to read if you want to understand how things work : https://www.freedesktop.org/so...

In short, don't go on hearsay but read the technical documentation.

For example I think the Linux (POSIX?) file system was written before they invented autocomplete, it's all TLAs like /var/usr/bin/lib/wtf.

In this case it's the file system hierarchy, not the file system. Personally, I think the argument for longer filenames is bogus. Using longer filenames isn't necessarily going to make their purpose any more clear, and for everything outside of the home folder, the novice user should probably not be touching that stuff, any more than they should be poking around in C:\Windows. Being user friendly is not a feature for things that are not intended for casual use. Autocomplete is an even worse argument: I'm not saving any keystrokes by typing /bi[TAB] versus /bin.

However, your example was somewhat poorly chosen in another sense, because while there is no call to make the names longer, at least one major distribution got rid of some of those top-level folders. Fedora likes to move fast and break things anyway, but in this case the historical justification for splitting up the binaries was, well, kind of ridiculous. Thompson and Ritchie created that particular issue a couple years before CP/M inflicted drive letters on us, but forty years later it's still a bug worth fixing. Most of today's code and systems will be pretty hoary in forty years, and I'm not sure I would consider it a virtue if it ran unmodified on my...hmm, well, whatever system exists at that time. One can always use emulation to provide old features, but most of the time I'd rather that not be happening at the OS level.

Given that Windows inherited both 8.3 filenames and drive letters from CP/M, it makes sense to talk about them in the same context. Drive letters are pretty harmless, but having "secret" 8.3 filenames and unremovable folders is probably something that needs to go. Linux definitely doesn't have those kind of problems.

There is a very small percentage of cases where systemd cannot make use of the scripts. You could check here to see if any of your problems are listed https://www.freedesktop.org/wi... Logging is one of the fantastic bits about systemd, its far more comprehensive than anything else. Its just a matter of learning about the new features and tools.

What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.

Let me share some wealth of knowledge with you about systemd in the real world. I urge you (and anyone else) "not having a problem" with systemd to please read this actual bug (which a colleague of mine has experienced on bare-metal systems running Debian). Respectfully, read all the replies (there aren't that many). This bug contains a gold mine of insights (into thought processes, beliefs, and actual usability concerns) that should make any worthwhile systems administrator (or developer, for that matter) start shake uncontrollably followed by an outburst of "Are you fucking kidding me?!?!"

Now ask yourself if this is really what you want re-inventing and controlling everything. If you choose "yes", that's OK (really!), but I choose "no".

Here's one of a few discussions

Also google on: systemd degraded btrfs

The hell of it is that once it dropped to the emergency shell, simply entering the needed mount command by hand mounted it right up. Had it been a script based system, I could just stuff the mount command in as an imperitive and moved on to the next issue.

This is interesting. How about issue the mount command? If it is complete enough to succeed then it will succeed. Otherwise it will fail. That was obvious enough that SysV init got it right. Note how "let the admin decide" wasn't apparently even a consideration.

Since that wasn't the only issue, I found a way to mostly defang systemd in Jessie (Debian) so I left it at that. I fave the Devuan beta downloading now. I may very well go that route.

The issue isn't Skype, the issue is Linux.

Linux changed out from under it.

Linux failed in three ways:

1. It failed to maintain the ability to run 32 bit binaries on 64 bit systems

2. It failed to maintain a binary compatible runtime environment

3. It failed to maintain a uniquely identifiable machine ID; mostly, this was the deprecation of libhal, which was deprecated in 2008 https://lists.freedesktop.org/... and which is no longer supported

Yes, it's annoying that it requires the ability to uniquely identify your machine, just like the Adobe content management plugin for Flash needed to play Amazon and Google Play videos that are pulled down from those "stores" requires the same thing, to verify the CMS key on the back end server to permit decryption of the DRM'ed content.

Too bad, so sad: Their toys: play by their rules, or you can't play with their toys.

For simple wifi stuff, wicd is a nice lightweight solution.

The most ironic part of the whole thing is that the problems described here as justification for systemd's awful interface naming are all things that should be taken care of by a higher level tool such as network-manager.

So it's how long, about 8 years, since AMD announced it's going open source with its GPU drivers?

They did say it's going to take a while to fully shelve Catalyst, and I could understood if the new open source drivers didn't fully support 5+ years old GPUs due to various transition periods etc. But really?!

This is the open source driver status. Looks pretty good to me. Regarding the new driver, it is part of their mixed open source and closed source strategy: The kernel module is open, AMD provides the closed source user space that that should provide the latest and greatest features, while the community provides user space part as open source that might have to catch up a little performance wise.

Have you tried the nouveau drivers recently? I replaced some legacy nvidia drivers with the open source ones, and was pleasantly surprised.

As long as reclocking your card is supported, you should give it a try.

And out comes the ad hominem! The standard arguement in favor of systemd is; 'everyone else are idiots and every way else is stupid'. Why? 'Because systemd said so!'

Why don't you spend some time and get to know the tools that systemd introduces.

For the same reason that you, and everyone else, don't spend the time to learn about the convoluted set of tools that I have developed for my specific needs. They're unneeded, irrelevant, and uninteresting wastes of time.

You may find you like it.

What I've found is that I dislike it intensely. I dislike impediments to system administration, broken workflows and having to relearn even the most basic and rudimentary things that were not broken in the first place. Using your logic, I should probably just learn to use Windows. Actually...

You can still configure it to log to the places you're used to.

I can recompile my system form source too, but neither one is a viable option from a usability standpoint.

And the nic name changes have nothing to do with systemd.

Really? Well then where do they come from? systemd seems to have decided and implemented it.

But, you keep right on with the ad hominem name calling. Don't answer the legitimate questioning of the systemd authority. Ignore the citations and provide not even a vaguely cogent argument. 'Everyone is an idiot and systemd is the only way forward.'

While the initial version of systemd-resolvd didn't honor rfc5452 due to it beeing a stub resolver, it has since v223: https://lists.freedesktop.org/...

* systemd-resolved now implements RFC5452 to improve resilience against
cache poisoning. Additionally, source port randomization is enabled
by default to further protect against DNS spoofing attacks.

Intel has already published open source Vulkan support in a new Mesa branch: https://cgit.freedesktop.org/m...

Nvidia also has Linux Vulkan support in its newest beta driver.

AMD... uh... has a beta driver for Windows. Not even an announcement of Linux support. Yeah, so much for AMD having an insurmountable lead or anything.

Lots of other filesystems support extended attributes

Unfortunately, FAT32 is not among them. In theory, Windows may support them technically, but Wikipedia's article about extended attributes gives no indication of how it is supported or what other operating systems support Microsoft's implementation. And FAT is the only removable media file system I'm aware of that 1. can be formatted by software included with Windows and 2. can be read and written by Windows, OS X, and free software.

there's a freedesktop standard

I found it. It involves setting the user.mime_type attribute. But traditional methods still need to be used for files stored on FAT32 media (usually USB flash drives or SD cards) or processed by attribute-unaware applications. Or is it recommended to amend major GNU/Linux distributions' inclusion criteria to exclude attribute-unaware applications?

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

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

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

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

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

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

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

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

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

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

https://bugs.freedesktop.org/s... is certainly one of the issues. But there are other situations which *do* cause log data loss. Google shows up plenty with little effort.

NFS filesystems fail to be mounted at boot. Why? I have no bloody clue. There's nothing in the logs.

Unlikely. If there was an error running the mount command, it was definitely recorded in the log. Did you use journalctl -u nfs or journalctl -b?

With sysvinit I could boot to an interactive shell in the late initramfs and step through every script by hand, and pinpoint exactly where something was failing

You can get a debug shell in systemd. The process is just a little bit different,
http://freedesktop.org/wiki/So...

With systemd, even with correctly configured systems, I still experience occasional unrecoverable hangs at boot as it screws up its nondeterministic boot ordering and waits forever on something or other (who knows what it might be).

I'm sorry, but that's bulls**t. If your system is randomly hanging, then it's not configured correctly. While the boot sequence of systemd can be characterized as non-deterministic, it is not random. If services are hanging because dependencies have not been met, then you need to specify your dependencies properly.

Another thing, is the broken compatibility with what came before. Example: I edit /etc/nfsidmap.conf to configure NFSv4 id mapping. Previously I'd reload/restart the nfs-common service with 'service' or 'invoke-rc.d'. Job done. What's the systemd equivalent?

Since you should be using a >3.5 kernel, nothing. The rpc idmapper has been replaced with the nfsidmap system call in the kernel. So there is no need to start/restart an idmapper service.

Yes, it's partly me lacking familiarity with the new way of doing things;

Understatement. Have you read any of the systemd docs or transition/setup guides available? There are a ton. Just do it.

There is no virus other then proof of concept for Linux.

Of course there is.

The official way wayland proposes clipboards to be implemented is via "data sharing".

There, there is not even real distinction between copy+paste and drag+drop. All data is offered by the origin client via "wl_data_source::offer". The only actual param this accepts is the MIME type. Drag&drop isn't distinguishable from copy paste or just simply when the user selects something. In fact, one can distinguish between drag&drop by listening for additional events, but still the only "real" distinguish factor is the MIME type. And also the only real one you could use for talking about the selection for middle click usage later on. You would have to get registered at IANA for this case only or violate the RFC's.

The wayland protocol doesn't even mention middle click pasting. Note that it mentions drag+drop and (normal) copy+paste multiple times.

And lastly, I know that weston doesn't support it. Yes, weston isn't intended to be the best compositor of all times, but still, it means that I can't use middle click pasting for weston-terminal. That's a big minus against actually using that program. And weston-terminal is much more sophisticated than xterm. But even xterm has middle click paste. Sorry to say but I'd rather use xterm than weston-terminal.

You misspelled "systemd". "Relational Database" is slated to become one of its new features for next year's release.

It's been a 'feature' since the beginning: journald - the new syslog database management system. Moderate speed and nonzero scalability finally put syslog on the DBMS map.

The convenient binary file format ensures security by preventing the unwashed from viewing logs with only a cat, head, tail, or less.

You misspelled "systemd". "Relational Database" is slated to become one of its new features for next year's release.

It's been a 'feature' since the beginning: journald - the new syslog database management system. Moderate speed and nonzero scalability finally put syslog on the DBMS map.

The convenient binary file format ensures security by preventing the unwashed from viewing logs with only a cat, head, tail, or less.

It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.

Unless you mean that Linux is not compatible with your system, you're wrong. Now I'm pretty sure you're clueless or at least inexperienced.

Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have /dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried.

So you're definitely clueless. You don't understand what you're talking about. You are in an unprivileged container, but you STILL need a privileged manager in this container, and that manager is systemd. That doesn't mean everything else is privileged. Your system just won't work without a privileged equivalent to PID 1.
prctl is not a systemd prerequisite. Nothing prevents you from using /dev as a tmpfs (you can even lock its size) and you won't have access to CG as systemd will take care of them.
Basically, having your prerequisites doesn't prevent you from running a systemd in a OS container or force you to remove systemd features, as that's not what you're asking for. You're asking for an unprivileged container, which doesn't mean at all that the systemd inside the container has to have anything removed.
Now, nothing prevents you from running systemd containers with sth else than systemd, you'll just lose eveything systemd brings to the table in the process.

Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.

This doesn't make sense: you want systemd within a OS container without systemd dependencies. Use sth else, then! No one is stopping you, you can still use your sysvinit + init scripts, you're on your own anyway with your custom needs.

Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.

You are making a bad impression of yourself actually, what you wrote shows you don't know what you're doing, or what is really asked of you.

I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.

You still show you don't even understand what you're reading.
Apparently you try to use /dev as tmpfs yourself, which you don't need to do and shouldn't do, as systemd is already managing that for all your services.
And they're not talking about dropping mknod unsupported, but about dropping the CAPABILITY being unsupported. Which makes perfect sense, as in devtmpfs, the kernel is making the nodes in your /dev, which you should not touch. But in a container, the /dev is isolated from the base OS, and you have to be able to make nodes in it one way or another, and this is by using a process that have the CAP_MKNOD capability. That's because everything in your container is unprivileged. Or else you will have an empty /dev, so a container that won't work with a Linux kernel. As I said earlier, you don't understand what was asked of you in a unprivileged container, which is exactly what systemd will provide to you. But you have to understand the link you've given to know that.

Actually, the degraded option does NOT work for BTRFS or at least hasn't when I've tried it. I still ended up in the shell. I checked the changelog for systemd from present back to the date of that report and there is no mention of it at all. Once in the shell, mount -odegraded / will work just fine. If systemd' wasn't too mind-bogglingly stupid to just try the mount command nobody would have to get out of bed at 3AM just to type that. But if I just rip systemd out and use the supposedly old and broken down sysV init, it works every time. If systemd had a sane configuration, I'd just poke that mount commend in as an explicit action and it would just work, but in all of that tangled spaghetti just below the surface, there appears to be no way to do that.

For md devices, they get around the problem by having a regular old script in the initrd go ahead and assemble the RAID before systemd gets a chance to get the vapors and refuse.

Mainframes certainly DO cost 100x more than (for example), a supermicro server.

Sure, networks do go down, but in those cases, you're either dual homed or no amount of non-stop can help you. Again, take the 90% solution or be prepared to start paying a lot more. I did say it should be in a good datecenter with backup power. If that fails, again, no amount of non-stop can help you.

When opponents to sth have to lie through their teeth, hoping that noone will go read and understand their links, they're immediately disqualified in my view.
You clearly are not qualified to understand what you're talking about, but at least you made the work to fool people that won't ever read the links provided because they're not qualified either. Unfortunately for you, some people will read them. And they'll see your lies, which explains why you posted as AC.

Let's run down the list of "why":

- Systemd contains an unchecked null reference pointer that segfaults PID 1.
Lennart Poettering states he won't fix it
https://bugs.freedesktop.org/s...

No, systemd doesn't have such a thing, and LP never said what you're saying. The link show a very non civil hater (the systemd devs kept their cool), that wants the devs to tackle at high priority an unsupported setup, which became badly handled by systemd because of a kernel change. One thing that is legitimate, is that systemd should at least gracefully quit when in such an unsupported setup. Which has been done and fixed by the systemd devs. They asked for a patch from the guys who insist on using an unsupported setup, and of course, never got anyhting, and had to do it themselves. Classic "the setup you told me won't work, that's what I want to use, or systemd is crap". Why a sysadmin would do that, I can't understand.

- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...

Another big lie, systemd has nothing to do with this problem, it's only Gnome Shell that is the problem in some distro setups, and that was introduced because users were locked out of their desktop. To sum it up, Gnome-shell made a kludge to remove the security systemd provides, so as not to lockup users.

- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it.
https://bugzilla.opensuse.org/...
https://utcc.utoronto.ca/~cks/...

Yet, the true sysadmins that reported it managed to provide logs and debug the systemd-208 version, which is the version we're talking about here, which is an arbitrary version that some distros took as a supported one in their distro. LP never said anything of what you're lying about here, especially as what you say makes no sense when PID one segfaults, then the core deump is important, and that's one of the thing that has been provided by competent sysadmins, not by incompetent whiners. This bug has been fixed in the 208 version used by this distro, using true debug means recommended by systemd devs or distro maintainers, not your nonsense. The upgrade was also fixed by the distros, as they were in charge of supporting the version, with the help of systemd devs.
And yes, it happened once with a systemd version, that it crashed on live updating itself.

- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...

Actually that's not true at all, it will boot just fine. It's just a clueless user there that tuned his laptop with an antiquated configuration that is static instead of dynamic, and perhaps that's Debian's fault. There must be a long timeout, but eventually, he would have arrived to emergency console.
Systemd is dynamic if you use its native tools, not if you use the compatibility static tools of Debian. But it boots

Forgive me for asking but, what is systemd's main benefit? If i don't mind that my system boots up slower and in a sequential order, how does that affect the systemd's benefits for other users?

The primary benefit of systemd is that it is init done right. That means you no longer need to use executable shell scripts in order to run daemons, but can use simple text config files. SysVinit shell scripts are hard to parse for both humans and machines, while systemd .service text config files are easy to parse for both machines and people.

Integrated service management: Want to restart and important service if it crashed, but only if it crash with an abnormal exit code and hasn't been re-started the last 5 minutes. That stuff is trivial to do in systemd with only changing a simple config line in a text file. With OpenRC/SysVinite etc. , it requires endless hacking to make something similar work.

Reliable killing a process and all its sub-processes. systemd can do that because it tracks every process with cgroups, non-systemd distros can't.

Security: If SysVinit had stepped up and taken responsibility for handing out low port numbers to services so they didn't need privilege dropping code like systemd does, we could have avoided two decades of remote exploits of Linux because of wrong use of setuid in daemons. It is better to have one secure implementation of privilege dropping code made by security experts instead of letting each and every daemon try to do it.

Security: systemd can "jail"/"contain" all running services since it provides an easy to use "API" for several low level kernel security features like "Capabilities" and "Namespaces".
So the service developers, the distro-maintainers, or even the system administrator can add "NoNewPrivileges" to a service config file. That means, that even if the service is exploited, the attacker can't get escalate privileges by then exploiting another service (A typical pattern).

Extremely easy resource management like limiting a service to only X amount of memory, or CPU resources, or bandwith etc. It can do that because of cgroups integration. A single; "MemoryLimit=1G" or similar added to the service file will make things work.

There are even more good reasons. I recommend the systemd homepage, especially the "The systemd for Administrators Blog Series" for and end users perspective.

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

In short, for me systemd is the best thing that have happened to Linux since package management. I really like it, Good stuff that makes Linux more secure and easier to use, for both newbies and experienced admins. It also has the best man page documentation and CLI tools I have seen for many, many years. Take fx. "man systemd.index" ; that will give you an overview of each and every "man-page" related to systemd. Very nice.

I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.

With documentation like that I tend to wonder whether idiot is the correct term, or whether malice should be assumed.

Taking an AC on Slashdot as your source, I wonder whether idiotic is the correct term, or whether malice should be assumed.
A real concerned developer would have already started there http://www.freedesktop.org/wik... and looked at "Documentation for Developers".

You cannot help people being suspicious with the scope of systemd. As you put it out, there is some good in rewriting software, drop antique flaws. But if you consider the many things systemd is actually replacing, it is kind of off putting.

If you hit a problem, then you'll have to debug it. And debugging issues with systemd provided tools looked to me as annoying as handle MS Windows crash.

Aside from bugs, obviously some regressions are to be expected. But they should be limited. If not, the software should not even be put in production. NetworkManager was a nightmare (cf. https://yeupou.wordpress.com/2... ). /etc/dhcp/dhclient-*-hooks.d/ were ignored. NetworkManager proposed it's own /etc/NetworkManager/dispatcher.d/ . But to have something portable (ie working without NetworkManager), the only option was to write such hooks in /etc/network/if-up.d and /etc/network/if-down.d. But even these were not properly handled by NetworkManager calling themselves from a script in /etc/NetworkManager/dispatcher.d/
What does it have to do with systemd? Well, systemd-networkd was put in production without ifup/ifdown http://xmodulo.com/switch-from...
Add to that "Predictable Network Interface Names" http://www.freedesktop.org/wik... and you get the feeling that someone is toying with your system. Silently, suddenly I no longer had some eth0 and eth1. Because they felt I could have problem "it might very well happen that 'eth0' on one boot ends up being 'eth1' on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.". To avoid that, I lost eth0 and eth1, as if this did not have serious implications either. They decided "the classic naming scheme for network interfaces applied by the kernel" is no good for them and changed it. They have plenty of good ideas.

That one example among other. I repeat myself , you cannot help people being suspicious with the scope of systemd. We can see they thought about a lot of stuff and have lot of good ideas. Nonetheless, the amount of changes they are implementing is overwhelming. And they change many things that are not broke in first place.
There is absolutely no middle ground. Right now, it is with systemd and all it claims as it's territory or completely without. It is bound to divide.

If you're allergic to trimming your neckbeard and running a modern init, just switch to *BSD where they adopted the features that people are whining about decades ago. ;)

Haters hate, but do they know why? Do they have a choice? Do they have Free Will, or were they born unable to tell the difference between choosing software they want to run, and being forced to run software that... they chose?

Let's run down the list of "why":

- Systemd contains an unchecked null reference pointer that segfaults PID 1.
Lennart Poettering states he won't fix it
https://bugs.freedesktop.org/s...

- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...

- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it.
https://bugzilla.opensuse.org/...
https://utcc.utoronto.ca/~cks/...

- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...

- Systemd distros can not boot if using certain DNS servers
https://bugs.debian.org/cgi-bi...

- Systemd distros can not boot if using certain NTP servers
https://github.com/systemd/sys...

- Enabling the kernel "debug" command line option results in boot storage being filled with thousands of dmesg log entries per second from Systemd, and a non-booting system results
https://bugs.freedesktop.org/s...

- Systemd disables SysRq keys to ensure data loss after any of the many many instances it is coded to fail under
https://lists.debian.org/debia...

If you're allergic to trimming your neckbeard and running a modern init, just switch to *BSD where they adopted the features that people are whining about decades ago. ;)

Haters hate, but do they know why? Do they have a choice? Do they have Free Will, or were they born unable to tell the difference between choosing software they want to run, and being forced to run software that... they chose?

Let's run down the list of "why":

- Systemd contains an unchecked null reference pointer that segfaults PID 1.
Lennart Poettering states he won't fix it
https://bugs.freedesktop.org/s...

- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...

- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it.
https://bugzilla.opensuse.org/...
https://utcc.utoronto.ca/~cks/...

- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...

- Systemd distros can not boot if using certain DNS servers
https://bugs.debian.org/cgi-bi...

- Systemd distros can not boot if using certain NTP servers
https://github.com/systemd/sys...

- Enabling the kernel "debug" command line option results in boot storage being filled with thousands of dmesg log entries per second from Systemd, and a non-booting system results
https://bugs.freedesktop.org/s...

- Systemd disables SysRq keys to ensure data loss after any of the many many instances it is coded to fail under
https://lists.debian.org/debia...

10 years ago, Intel was hinting at a massively parallel future (80 core processor rumored in development at the time)

I think the 80 core processor Intel was developing at the time eventually turned in to the Knights Corner aka Xeon Phi chip. Originally Intel developed this tech for the Larrabee project, which was intended to be a discrete GPU built out of a huge number of X86 cores. The thought was if you threw enough X86 cores at the problem, even software rendering on all those cores would be fast. As projects like llvmpipe and OpenSWR have shown, given a huge number of X86 cores this isn't as crazy of an idea as it initially sounds... but still a little crazy :) Ultimately Intel cancelled that project and decided to use that tech for super computing instead of graphics. A result of this is Intel retained the "Gen" design for their graphics core, which is a more traditional GPU design.

It would be fixed by the users if the game engine and the graphics driver were open source.

There already are open source graphics drivers, nouveau for nVidia and the radeon drivers for ATi/AMD. There are also plenty of open source game engines and even if there weren't, users could build them. Additionally even using the SDKs for proprietary game engines and the profiling tools is more than enough to isolate performance bottlenecks. If there is a problem with the engine it isn't going to be difficult to identify where it is stalling and discuss with the author (particularly when it is Valve that has an interest in their engine running well on Linux).

Vulkan will improve the situation dramatically, since the situation has gotten so bad that the closed source people can barely manage it.

The resource management that is done currently in the OpenGL (and DirectX = 11) drivers still needs to be done but now that onus falls on the application and/or engine developer.

It would be fixed by the users if the game engine and the graphics driver were open source.

There already are open source graphics drivers, nouveau for nVidia and the radeon drivers for ATi/AMD. There are also plenty of open source game engines and even if there weren't, users could build them. Additionally even using the SDKs for proprietary game engines and the profiling tools is more than enough to isolate performance bottlenecks. If there is a problem with the engine it isn't going to be difficult to identify where it is stalling and discuss with the author (particularly when it is Valve that has an interest in their engine running well on Linux).

Vulkan will improve the situation dramatically, since the situation has gotten so bad that the closed source people can barely manage it.

The resource management that is done currently in the OpenGL (and DirectX = 11) drivers still needs to be done but now that onus falls on the application and/or engine developer.

http://www.freedesktop.org/sof...

If it doesn't do anything interesting then just start the daemon from systemd.

uPower predates Systemd. I do not know if MATE was using uPower prior to its integration with Systemd. If so, this is an example of a standalone susbsystem (uPower) utilized by other userland software (MATE) that has been taken over by Systemd, thus forcing SystemD as a dependency for that userland software which used to function wihtout it.

UPower is not part of systemd. http://upower.freedesktop.org/

journalctl "pipe" [current tool of your choice]

configure system to forward all logs to syslog or rsyslog for the status quo

Journalctl is well worth getting to know http://www.freedesktop.org/sof...

i just found this, it would seem like a good idea for you to discuss your review. http://www.freedesktop.org/wik...

Time synchronisation is in systemd already:

http://lists.freedesktop.org/a...

And it uses SNTP, not NTP.

Once upon a time, if something failed, you booted in single-user mode.

...which means yet another reboot, which may or may not replicate the problem and allow debugging.

And you got a shell, not the "One True and Non-Replaceable Shell". Systemd takes away the flexibility to configure things optimally for your specific needs.

Per the documentation, the "login shell" that everyone complains about is just a controller command that runs /bin/sh by default, or any other command presented.

If systemd offered plug-in loggers and one of them happened to be a binary log database, that would be OK. But systemd's designers apparently lack the skills to make a simple and flexible system.

Also per documentation, the default journal is not the only option. You can also send output to syslog, kmsg, the console, or a socket.

Can't comment. I haven't had much to do with anything beyond the man pages.

Clearly you haven't bothered to read those much, either.

Well, in this case, it's that there was no "trial mode" for people to gradually evaluate, find bugs in, and accept/reject. Instead all of the sudden the familiar, functional (if imperfect) systems were all gone and systemd ruled everything. Since systemd isn't as flexible as what it replaced, you couldn't fall back to the old stuff in cases where it failed to satisfy or as an emergency solution.

Systemd was apparently around for a year before the first distro adopted it. There's been plenty of time to review and comment, but so far all of the discussion seems to be just criticism by folks who clearly haven't bothered to read the documentation for the things they complain about.

OK. But the rate at which you "close bugs" is a meaningless metric. Were the bugs closed because repairs had been made or were they simply marked "WONTFIX"?

Again, that's no different from any other software project.

If your system is so fragile that a single server being down is that critical, maybe you need to re-evaluate your architecture.

I never said it was fragile. I said that it must be 100% operational. I work on a very particular kind of high-end processing system, running a few dozen specialized servers. There's an array of video processors, a separate array of audio processors, a number of systems just for I/O, and a small (by the vendor's standards) HPC system. Some of it runs Linux, some runs Windows, and the whole thing has to be able to be brought online in 15 minutes.

Again, you don't get to assume what my requirements are.

For those of us to whom such things are essential, we have clusters, failovers, and other HA constructs so that the loss of a single machine doesn't hold the whole operation prisoner.

All of those options are expensive, and require additional infrastructure and upkeep, as well as additional engineering to make it all work in the first place. It also increases the price tag on every system we build.

Yes, faster boot times are nice, but even at its worst, a Linux system boots significantly faster than Windows. You don't have the machine being thrashed by massive software updates and disk-burning virus checks on reboot.

Instead the system waits for fsck every month, refuses to move until it's tried to initialize every NIC on the system, won't start X until the sound system is ready, and let's not even discuss the wait if a NFS mount is unavailable. Yes, you can also install a virus scanner or configure your system to look for updates at every boot.

The real problem is serialized startup. If systemd makes it easier to run things in parallel, that's a good thing. Upstart did well for that, too.

Once upon a time, if something failed, you booted in single-user mode.

...which means yet another reboot, which may or may not replicate the problem and allow debugging.

And you got a shell, not the "One True and Non-Replaceable Shell". Systemd takes away the flexibility to configure things optimally for your specific needs.

Per the documentation, the "login shell" that everyone complains about is just a controller command that runs /bin/sh by default, or any other command presented.

If systemd offered plug-in loggers and one of them happened to be a binary log database, that would be OK. But systemd's designers apparently lack the skills to make a simple and flexible system.

Also per documentation, the default journal is not the only option. You can also send output to syslog, kmsg, the console, or a socket.

Can't comment. I haven't had much to do with anything beyond the man pages.

Clearly you haven't bothered to read those much, either.

Well, in this case, it's that there was no "trial mode" for people to gradually evaluate, find bugs in, and accept/reject. Instead all of the sudden the familiar, functional (if imperfect) systems were all gone and systemd ruled everything. Since systemd isn't as flexible as what it replaced, you couldn't fall back to the old stuff in cases where it failed to satisfy or as an emergency solution.

Systemd was apparently around for a year before the first distro adopted it. There's been plenty of time to review and comment, but so far all of the discussion seems to be just criticism by folks who clearly haven't bothered to read the documentation for the things they complain about.

OK. But the rate at which you "close bugs" is a meaningless metric. Were the bugs closed because repairs had been made or were they simply marked "WONTFIX"?

Again, that's no different from any other software project.

If your system is so fragile that a single server being down is that critical, maybe you need to re-evaluate your architecture.

I never said it was fragile. I said that it must be 100% operational. I work on a very particular kind of high-end processing system, running a few dozen specialized servers. There's an array of video processors, a separate array of audio processors, a number of systems just for I/O, and a small (by the vendor's standards) HPC system. Some of it runs Linux, some runs Windows, and the whole thing has to be able to be brought online in 15 minutes.

Again, you don't get to assume what my requirements are.

For those of us to whom such things are essential, we have clusters, failovers, and other HA constructs so that the loss of a single machine doesn't hold the whole operation prisoner.

All of those options are expensive, and require additional infrastructure and upkeep, as well as additional engineering to make it all work in the first place. It also increases the price tag on every system we build.

Yes, faster boot times are nice, but even at its worst, a Linux system boots significantly faster than Windows. You don't have the machine being thrashed by massive software updates and disk-burning virus checks on reboot.

Instead the system waits for fsck every month, refuses to move until it's tried to initialize every NIC on the system, won't start X until the sound system is ready, and let's not even discuss the wait if a NFS mount is unavailable. Yes, you can also install a virus scanner or configure your system to look for updates at every boot.

The real problem is serialized startup. If systemd makes it easier to run things in parallel, that's a good thing. Upstart did well for that, too.

As a sysadmin, I think it's to make my life miserable. As a user, I think it's because nobody gives a damn about logs for a system that's working.

After a quick search for the relevant document, it seems the default for stderr is to inherit settings, presumably from some kind of hierarchy that I don't know enough about to comment on. By default, then, I'd guess the top level discards logs.

From an architecture standpoint, that makes sense. On my work-related systems, I could just configure the top level, and get logs everywhere, or configure it for only the services that my system actually cares about. On the nearly-a-kiosk preconfigured laptop I gave to my mother, I don't need it to waste time or disk space recording logs that nobody will ever read. If I have to troubleshoot the machine, I'll turn on logging then.