Systemd is a double edged sword. I started using FreeBSD in 1999, and Mandrake Linux in 2000ish. I switched to gentoo when it came out, because i like to tinker and see how things work (like or hate the distro it does make you learn a quite a bit).

Fast forward to 2018 and i manage around 500 Redhat servers here. About 150 are at RHEL7 (the others need to be upgraded). So learning systemd is a requirement, it is not going away. I like some points of it. I do like the jounrnalctl command and the ease of looking at logs, however being the hypocrite i am i despise the binary logs and non compatibility with most syslogging devices (i have had to explain lost logs during an audit with systemd and it was not pleasant).

From a end user standpoint systemd is great for my desktop. For the servers it is functional, server boot time does not matter to most administrators. On VM's both boot fast enough, on bare metal....some of our large servers take 5 to 7 minutes to post (thanks HP) so the OS taking 20 to 30 seconds longer to boot is not a big deal.

I follow the systemd mailing list to see what is going on, i think if the guys over there were not as abrasive in some of their answers things would be smoother, and more receptive to the needs of some of the users. I see a lot of features that are desktop specific and that seems to be where their development lies for the most part, desktops and servers are two different beasts.

I guess the infighting just sucks, i am not a fan of systemd simply because i like a simple OS with minimal features to accomplish my objectives, however it is here to stay and i am a Linux Admin so it is part of my job and i learned to use it and keep up with development.

I still use FreeBSD for all my home servers (except my docker swarm), old habits die hard.

Speaking of BSD and Docker... I'm learning FreeBSD for a little side-project but it seams its harder to get a good deterministic deployment pipeline with Jails than with Docker. Whats the best practice there?

I don't develop on FreeBSD either, its just for prod.

Unfortunately there is not really one. I always treated jails as VM's. You could create the jails on ZFS and do a send and receive, or use something like Jenkins to build and deploy. However jails are like LXC on Linux, not like docker.

You could use nanoBSD in the source tree to create a minimal mostly immutable image with your application. It will still be like a VM though and need deployed somewhere (this is how i run my DNS servers at home, they are about 120MB each and can run on pretty much any VM host (or bare metal)). But docker does have that market better (hence why i have a small swarm at home to play on).

There is also docker for FreeBSD, still in testing but works pretty good it you build your own native images. I build a memcached image and was running that for a while.

> large servers take 5 to 7 minutes to post (thanks HP)

IBM/Lenovo xSeries servers are the same. 5+ minutes to get through the boot process, due to all the hardware init and checking. That's with UEFI too. ;)

> i have had to explain lost logs during an audit

How did they get lost?

Somehow during a system crash (hardware failure) the journal logs were corrupt and could not be read, and application logging was not being forwarded to the syslog facility. Our logs were not send to a logging server at the time, they were backed up daily and stored on tape.

If it's not technically terrible, it's not technically terrible anymore.

All the initial "ooh and aah" factor of SystemD came from using the kernel's cgroups mechanism, which was a dumpster fire by itself--something dropped by google in the kernel for easier maintenance with the understanding that no one should be stupid enough to use it for something important...enter SystemD.

Apparently cgroups is in better nick these days (as is SystemD), but until the likes of Al Viro come around and give it a clean bill of health, I think I'll pass.

So no docker for you either?

cgroups are essential to properly limit daemons on baremetal servers without the overhead of containers (so more bang for bucks).

For example, you can make sure some poorly written python daemon will never use more than 50pct of the cpu or over 1 Gb of ram - and systemd services will nicely restart the daemon if\when that happens.

By not using systemd you are depriving yourself of essential tools in modern sysadmin (timers alone are worth switching to systems compared to cron anachronistic hacks)

You can use cgroups without systemd.

Them being released at similar times does not mean systemd implemented them, they exist completely separately to systemd.

Literally:

   mkdir /sys/fs/cgroup/memory/<groupname>;
   echo 100000000 > /sys/fs/cgroup/memory/<groupname>/memory.limit_in_bytes

is all you need for cgroups.

The grandparents comment was targeted at cgroups in general. You can’t use cgroups without cgroups. To add on that: IMHO, both systemd and docker made cgroups much more accessible to joe sysadmin and while they’re not a bulletproof security feature, having them (and capabilities, another kernel feature exposed by systemd) in wider use is generally a good thing.

> cgroups without cgroups.

I've been charring my brain to understand what you mean by this.

You don't need to have cgroups for all applications in order to use them.

And they don't need to be implemented by systemd specifically for them to be in use by other init's or tools.

SystemD existing (and being pushed so heavily) stymies the rise of such init systems.

The post I was referring to criticizes cgroups in general, regardless of how they are managed or used.

Sure, then you need to write scripts to monitor your daemons and their dependencies, and you may end up writing something likely worse than systemd that just suffers from the 'NIH' syndrome.

Adjusting to systemd took me a while, but I believe it was worth the effort, and I also believe most people who dislike systemd are just set in their old ways

Other way around there were daemons that previously managed cgroups and system NIHed a new implementation.

It is terrible technically. It does too many things (for no apparent reason) and it's every other month that we see some enormous exploit for it.

Hyperbole is not how you make technical arguments. Try some data:

https://www.cvedetails.com/vulnerability-list/vendor_id-7971...

There are 11 total from 2015: one arbitrary access, one which allows administrators to run a process as root rather than the intended user (CVE-2017-1000082), and some DoS opportunities. Not great and several great examples of why C should not be used but hardly “every other month”.

Now, it's hard to compare that it against other systems because it combines functionality which people used to have to use third-party tools for or roll themselves so you have to count that against every buggy init script or supervisor feature, apps whose developers never got around to adding the hardening features which systemd does use, etc.

The systemd developers "forget" to file a lot of the CVE bugs that should have been filed, so the CVE is incomplete in regards to the serious security issues that have affected systemd.

I still remember that time when systemd developers argued that a privilege-escalation bug systemd enabled was not really a bug. The criteria those developers* use to determine what merits a CVE filing doesn't quite match up with what you'd expect, so CVE count isn't a good metric for systemd security.

* Unfortunately, they aren't alone in their sloppy handling of security issues. Rust is also another project that is known to not file CVEs for serious bugs if they occur in previous releases.

So does the linux kernel as current, previous or even release candidates..

You can document this, right? The researcher who finds a problem should be able to request a CVE even if the upstream doesn't acknowledge it.

The theory is good. :)

Weirdly though, getting a CVE assigned can be a real PITA (and unsuccessful). The people who do the CVE assignment are generally overloaded, so lower impact/priority stuff often seems to get missed or not bothered with.

This hasn't been the case for a number of years, Mitre has seriously picked up their game, and you can talk to linux vendors such as Red Hat, Ubuntu and SuSE who also have blocks of CVE's assigned for things they shipped.

The alternative is DWF, which would be more popular if this was a more common problem.

> This hasn't been the case for a number of years ...

Thanks, that's really good news.

Sounds like a petty dictator pushing everyone to think and act the same; manipulating people until they give in because it takes too much effort to resist. He should consider a career in politics... I always get uncomfortable when I know people who pull stunts like that in RL and it is irritating when it dramatically affects an otherwise very good operating system. I use Void Linux just to avoid systemd, considering its long track record of horrific bugs and security issues.