Hacker News Reader

systemd has a number of features which are of interest to server operators, especially those who use containers, which may well be many of us before long.

Running systemd as pid 1 does not imply running a desktop environment.

I have plenty of VPS customers running systemd as pid 1 in 512MiB RAM.

Running systemd as pid 1 doesn't imply having every single binary and subsystem of systemd running.

I would encourage you to try it before deciding it's something you won't find useful.

Avoiding it looks like it's going to be significant effort and you'd want to know for sure that you're justified in that before embarking on that course of action.

Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

Actually, I find it's funny how anti-systemd people nowadays claim that "systemd is a init for desktop systems" since Gnome adopt something unrelated to the _init_ part of systemd that is the systemd-logind (that actually is a substitute of ConsoleKit that was deprecated god knows how many years ago). systemd has lots of features that makes sense on servers too. You may or may not need these features on your server, but systemd (as a init system) is still a better init system than sysvinit.

Actually, systemd is pretty awesome for servers. I wrote a simple program that outputs to stdout and ran it under systemd.

  * it automatically cares about starting it
  * it automatically puts the programs stdout into the journal (from which I can filter the output of my specific program without having to syslog() everything)
  * it allows me to run the program as user with one line in the INI unit file
  * it allows to make the users home directory read-only (or even inaccessible), so in case someone takes over, there is only so much they can break
  * it can create a private /tmp for my program

Actually, for desktops I don't care but for servers systemd is pretty awesome.

You hit on some of the points that won me over when I first started using systemd. Writing services is easy and logging their output is a breeze. Not having to fret with supervisor processes or daemonizing code shifts some of the complexity out of the application and into the init process[1] where I'd argue process management ought to live.

Given that targeting sysvinit for all the various sysvinit-compatible systems out there can be an exercise in frustration (OpenRC, Debian, the *BSDs, all of whom have subtly different flavors for starting and stopping processes) better left to individual maintainers, it's nice that I can write a unit file and pretty much have it work on any system that's running systemd.

[1] I'm aware that some people might argue additional complexity doesn't belong in an init. That's fine. You're probably right.

And if there is a situation where your program is acting wonky, what non-systemd command can you use from the shell prompt to debug and reproduce exactly what systemd is doing?

> Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the nix ecosystem, I can't help but think that boat sailed long ago.

I was hugely resistant to systemd when Arch first switched, but I learned to appreciate it (the simplicity of unit files won me over). This came about a year and a half into my journey with Arch Linux when I was still learning that the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.

Though, journalctl still annoys me.

Sure, I can understand some of the hate directed to systemd simply on the merit that it does* do things differently--but it's hard to believe that the vitriol and insults from the anti-systemd camp are likely to help anyone's cause.

Personally, I like it, it works, I've not encountered the stability issues or other bits of weirdness some folks seem to insist regularly occurs (maybe it's distro-specific), but I'm also OK with being a statistical outlier. Or perhaps the anti-systemd crowd is disproportionately noisy.

> Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the \*nix ecosystem, I can't help but think that boat sailed long ago.

This is what I say when people complain that systemd "isn't Unix". Neither are package managers, but I don't see anybody saying we should revert to passing around tarballs that unpack onto root (other than Patrick Volkerding).

> [...] the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.

I'm thinking about putting together a talk about exactly this, tentatively titled "MacGyver-Driven Development". It's my response to people who respond to any criticism with "Yeah, but then you can just put some tools on top of it": relying on tools only adds another dependency that makes your system more fragile and resistant to change.

The proper way to develop is to keep what you do as small and environment-agnostic as possible. That way, when tides do change, you don't have to fight them or work hard to embrace them; you can just go with the flow, and just change the few parts that touched the changing dependency.

> "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

Even if this claim were actually true -- what's wrong about that? Why should someone move to a new immature system if his current one works perfectly for him? If an Apache server works perfectly for me why should I invest time and effort to switch to nginx just to get the same thing?

I consider a fork a good idea because it would split Debian development into a safe area of old-fashioned reliable technology, and a testing area of new technologies like systemd. If those new technologies have proven their reliability _then_ the moment has come to think about exchanging old stuff. It is too risky to throw a reliable system overboard and to force all people into an immature new technology.

I wonder what's the problem with the systemd proponents. If other people prefer SystemV why don't they simply let them go?

> If other people prefer SystemV why don't they simply let them go?

You are free to fork Debian and modify it as you wish.

Compare that mentality to trying to get a big new subsystem into the kernel.

Torvalds is likely to require you to hammer out all the details and debugging in a separate tree. This even more so if it is replacing a tested, stable and maintained subsystem.

As such, it is the Systemd proponents that should be doing a fork. And run it alongside stable for a time to demonstrate that it works. Then people can move over at their own pace.

I'll look into that. Thanks!

Your log files are binary already. What do you think 'cat' is, other then a binary log reader?

Binary log files are as easy to read as ASCII with the right translator. Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII.

The problem is, people think they'll be able to understand corrupt ASCII logs, but in reality basically never deal with them. They deal with truncated logs - which, well guess what, can be handled just as easily as for binary logs.

Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd. Especially when the hot thing in syslog management is usually to stream everything into a database of some kind to make it easy to search!

EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.

> Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII.

The advantage of human-readable logs is that the semantics and rules of the language it's written in serve as a built-in forward error-correction measure. It's easy to see that the string "the qu()&!`8zwn fox jumps over the la" is a corruption and truncation of "the quick brown fox jumps over the lazy old dog", especially if you're already used to seeing the original string under normal operation. By comparison, it's much harder to tell whether or not an arbitrary byte string is corrupt, and journald does not make use of any forward error-correction measures to assist in this.

> Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd.

If I'm using journald in this configuration, then why does journald need to exist at all? It's literally dead weight, and adds another point of failure to my logging facility.

> EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.

When compressed log corruption recovery is a concern, tools like parchive [1] are used instead of gzip/zcat.

[1] https://en.wikipedia.org/wiki/Parchive

Good points. As for compression: I think most people compress logs post-rotation. So you'll be unlikely to have a corrupted compressed log. Either the file will be compressed, then then original removed, or compression will fail, and the original will remain untouched.

It's more of an issue with whatever is written to disk by running processes. As you point out, it's debatable whether or not unicode/ascii vs "binary" is a sensible distinction ... I'd say taking a hex-editor to a mangled but mostly ascii text file is easier than some (any) binary format, but perhaps you know of some easy-to-use tool that will take a file-description and give you back data? Things like figuring out integer encoding and offset for timestamps across different files etc... is much easier with a rather redundant ascii timestamp than some binary number?

If your filesytem eats your files... well then that's a different problem.

Exactly my point: this isn't a complex database format. It's a tagged binary format, written in an append only fashion. So you're only going to lose data if the tool decides to write bad data, but that's just as true of a text log format - your logs are useless if all those numbers don't actually relate to the values they claim to.

So any tool which can read a journald journal can happily do so until it hits hard corruption - which is about as well as you ever do with syslog. I'll gladly trade an unlikely and really narrow recovery profile, for smaller, easily machine readable, well-defined log files (in the sense that, to write an entry, someone wrote down the exact struct somewhere, and had to keep using it that way. No regex's which fail in some case which happens once every 1 million lines of log file). Especially since the compatibility layer is just "forward text logs to syslog".

Reference: http://www.freedesktop.org/wiki/Software/systemd/journal-fil...

Fair enough. But you still then need to fit an additional tool into your recovery image. As long as it is possible to do with a small static binary that can be expected to be available (say built into a version of busybox) I don't have a great problem with it.

> A fork, or an alternative init system, could be a good solution.

I consider this a good idea. Servers and desktops are two different things so why not have two different Debian versions?

This way Debian Server could be kept small and simple while the systemd developers could continue without any restrictions. If they go too far then we could use the Debian server and add our own desktops to it.

A lot of the components mentioned are actually optional and you can build systemd without them or disable them at runtime. I'm guessing this idea that this idea that systemd is targeted for the desktop is from the logind kerfuffle with GNOME and friends but it's actually an optional component. If anything though systemd is more targeted towards server market.

This. SystemD means you can boot the system without needing a shell installed at all which is what Debian has been proposing moving towards for a very minimal server image.

Ok, somebody has clearly jumped the shark!

Fine. There speaks nothing against Debian Desktop for servers by admins who prefer systemd. I am current happy Debian user myself, and I would use such a system for my desktop.

However regarding servers I agree with the Unix veterans that Unix(-like) systems should be faithful to the KISS philosophy which made Unix so great. The IT world has become very complex, and we should not make it more complex than necessary. Debian and its derived distris took over the server world, and (AFAIK) it accomplished that with SystemV not with systemd. So SystemV is not that bad.

> However regarding servers I agree with the Unix veterans that Unix(-like) systems should be faithful to the KISS philosophy which made Unix so great.

Unit files are surprisingly powerful and simple and follow KISS quite well (they're easier to maintain). systemd is also not quite as monolithic as some are wont to believe.

> Debian and its derived distris took over the server world, and (AFAIK) it accomplished that with SystemV not with systemd. So SystemV is not that bad.

This just seems disingenuous. It's almost like arguing we didn't need nginx because the web server market was won by Apache, not nginx.

systemd has its warts, I won't deny that, but it seems that most of those opposed to it are opposed strictly on the merit that it's new and different.

In the total sum, systemd and it's declarative unit files, is more KISS than all the services coming with their own shell scripts, their own log handling, their own daemonization etc.

http://www.freedesktop.org/software/systemd/man/daemon.html

You're spreading FUD.

So I can imagine having very different init systems for desktops and servers if this means that the server won't be encumbered by a number subsystems which are of no use to it.

systemd is about choice ;-) Only use the subsystems that you need. For example, if you'd want to save some memory and time, you could use systemd-networkd instead of shell scripts and dhclient.

systemd is used in constrained environments like phones and embedded systems because it's fast and solves problems (e.g. watchdog chaining).

Someone disagreeing with you doesn't mean they are stupid, evil and part of a grand conspiracy to destroy everything you love. They just have different priorities. Why is this so hard for people to understand?

Because a lot of people are speaking very authoritatively, yet with little content, about systemd. They raise objections based on partial or inaccurate information. Various bans on discussion are happening precisely because it's apparent that a number of people are no longer interested in useful discussion, so much as creating chaos until they get their way.

Manifestly described by the idea that people without time to interact with Debian, are going to instead launch their own Linux distro.

If partial or inaccurate information about a subject was the criteria for not talking about it then Torvalds should have shut up about kernels and let Minix be the default for everything. Read the exchange between him and Tanenbaum and tell me it doesn't sound like two douche bags flame baiting each other with Torvalds sounding like he has no idea what he's talking about: http://oreilly.com/catalog/opensources/book/appa.html

The whole point of free licenses is to let half educated monkeys type away on keyboards because every so often you end up with Apache or Linux out of it, of course you also get pulse-audio and systemd but no system is perfect. If people like it more than Debian it will replace Debian, like Ubuntu nearly did before they went with unity and a whole bunch of other terrible decisions, if they don't it will die, and if it sticks around as a project with some users, like every other debian derivative, it will be a wonderful resource to find bugs.

In which case we don't need to debate who's spreading FUD.

But people who want to take part in a debate should expect be held to account for the things they say, and in the case of systemd a lot of people are spreading a lot of misinformation. That's forgivable, I make stupid mistakes and misremember things all the time, but it's sure starting to seem like there's a very casual disregard for the truth and with it, any possibility of solid debate.

Not to mention the usual crowd of trolls who are just happy to have something that'll start an argument.

which phones use systemd?

Most notably http://jolla.com/ but I think Tizen will use systemd as well.

Wish I could upvote this a thousand times.