Torvalds: No Opinion On Systemd

An anonymous reader writes:Linux creator Linus Torvalds is well-known for his strong opinions on many technical things. But when it comes to systemd, the init system that has caused a fair degree of angst in the Linux world, Torvalds is neutral. "When it comes to systemd, you may expect me to have lots of colorful opinions, and I just don't," Torvalds says. "I don't personally mind systemd, and in fact my main desktop and laptop both run it." Torvalds added, "I think many of the 'original ideals' of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation. There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at some level, but I think it's also clear that it doesn't really describe most of reality."

Comments

well said!

[BrianBeaudoin]

I approve of this message.

Simple set of pipelined utilties!

[CajunArson]

It sounds great in theory but...
1. If you really buy that principle and want to enforce it religiously, then please never use a web browser again (even Lynx!), not to mention any other complex program that isn't formed from a bunch of small "do one thing well!" utilities that are executed in a pipeline.

2. Please tear up your Richard Stallman fanclub cards because what little software he's written has mostly been Emacs and Emacs is the anti-UNIX based on the "pure" UNIX philosophy.

That't the issue: Every single person who hates SystemD because "UNIX PHILOSOPHY!!" has no problem violating that philosophy to actually get things done in a whole bunch of other areas. That's not even bringing up the fact that SystemD is.. wait for it... built from a bunch of individual utilities that can actually be used by non-systemd programs.

Re:Simple set of pipelined utilties!

[slack_justyb]

The complaint is that the process at PID 1 should be simple.

That's just passing the buck. What you don't do in PID 1, needs to be done by PID 2 or 3 or 4...

One has to understand that system start up is a complex task. Systemd, sysvinit, launchd, and what-not are just a matter of optics, no matter which one you choose, you are only changing how you look at the problem, you aren't making the problem any easier. That's the important thing to remember, that all of these inits are just different views on how to solve the problem. No matter how many times you break the process up (into PID 4 through 380), it's still a complex task that needs to get done.

That said, sysvinit comes with the idea that you're going to have a lot of people looking inward at what's been done historically, they're going to make really useful tools, and the expectation is that those that follow will use those tools. That's nice and there is a real benefit for that, but that's not what vendors are going after, that's not what third-parties want, and that's not what end-consumers want. The only people that sysvinit caters to any more is developers and neck-breads. Vendors are going to write their own tools for start up. Third-parties are going to package up the process into something that can be simply delivered to the customer. Standard end-users just don't give a shit so long as the screen comes up. Heck, even server admins won't really care so long as management can still log in. There just isn't clientele for the old way. That's not to say that the old way isn't useful, but honestly you are asking a bunch of Pepsi drinkers to switch over to Coke for just the sake of "it is easier to make."

SystemD puts all the cards closer together, this allows smaller teams to do useful stuff, and let's face it, the number of people writing kernel, sub-system, and start up code is only going to keep dropping. The hotness is much, much higher up. Vendors like systemd because it works better than script->call program in their deployment cycle. Now they can use systemd reporting to bubble back up into the UI as oppose to writing to some arcane log file. No one can defend the old log files, they seriously were so confusing that there are companies that you can hire and tools that you can buy that can turn your log file into something easier to read. That's just indefensible. I'm not saying that systemd is some magical power that's turned a turd into gold (starting up a system is still a pain in the ass), but it serves a wider group that more than likely (as all the neck-beards die off from old age) will be maintaining this whole thing in the longer term and simplifies something that has gone from, "it was good and easy" to "holy crap! The log file is 23MB!!" Back when we were starting up an FTP server and that's about it, it was great, but now that every sub-system from the kernel feels a need to write to the log on top of everything else that you vendor starts up, it's just a flipping mess.

It's important to remember the Unix way, but systems have gotten so complex we just don't do it that way in reality anymore.

Re:Yes, pipelined utilities, like the logs

[Peter H.S.]

The logging is a perfect example. Why do I have to learn a new program (journalctl) just to read the system logs? What if I had to learn the syntax of a new program to read the logs of every program that I used? That would suck. If openvpn and mysql and httpd and sshd all had their own little program that I had to use to read their logs, I would give up using Unix.
I already have a program to read all logs, more or less. And I already have a program that searches all the logs, egrep. Yes, I had to learn egrep syntax, but now that I know it, I can do almost any search imaginable of any program's logs. Except systemd.

Sometimes new stuff is actually much better than then old stuff. I was skeptical about binary logs until I actually tried it. The advantages of a indexed journal is overwhelmingly positive. "journalctl" is an extremely powerful logfilter exactly because of the indexed and structured logs.
Systemd's journal also collects all logs in the same place, so no need to use "last" to read the binary "wtmp" log files, or locate .xsessionerrors and what not; everything goes into the journal.

Also, all the usual text tools like grep, tee, sed etc. all works with the journal by the standard Unix concept of piping. "journalctl" simply enhances the Unix text tools.

Give "journalctl" a serious spin someday; you may like it.