On Wed, Oct 22, 2014 at 4:43 PM, Rich Kulawiec <rsk@gsp.org> wrote:
On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote:
The people that like systemd (like myself) have wisely learned that the people that hate systemd, hate it mostly because it's different from what came before and don't want to change.
That's an entirely unfair characterization.
Some of us, including a lot of people on this list, have been pushing the envelope on change for decades. We've run alpha software on beta hardware, cobbled together networks with duct tape, and burned a lot of midnight oil while making innumerable mistakes and learning from them.
Speaking for myself, after migrating through far too many Unix and Linux distributions to count, starting with Research Unix v6, my entire professional career has been *constant* change. I suspect that the same is true of everyone else who's been doing this for a while. Anyone who doesn't embrace change as a way of life probably isn't on this list; they're somewhere else, maintaining Cobol written during the Nixon administration.
Been there, done that, got the T-shirt.
My problem with systemd is not that it's a change: it's just one more out of tens of thousands and so, in that sense, it's really not a big deal. My problem with it is that I think it's a bad change, one not in keeping with the "software tools" philosophy that has served us ridiculously well for a very long time and -- so far -- has not been shown itself to be in need of replacement.
A Leatherman pocket multitool is highly useful: I've had one for years. It's great. Until you need two screwdrivers at the same time...at which point it becomes obvious why serious mechanics/craftsmen carry around a toolbox with dozens of tools and why glomming all of those into one supertool would be A Very Bad Move.
I carry a Leatherman too, and indeed it is a very useful tool. But it's useful in the real world because physical tools have mass, and there's only so much mass that a person wants to carry around with them all of the time. In all other respects the tools on a Leatherman are far less superior than a tool purposely designed for a task. Software doesn't have mass so your analogy doesn't quite work. systemd is a tool designed to get the system to a state where "real work" can be done. NTP servers, DHCP clients, consoles, aren't the real work of a system, or at least I hope not, because that would be boring to me. I'm not going to justify everything that the systemd developers have done here, but I've been convinced that the functions that they have moved into systemd have been justified because it'll make systems work better and more robustly.
Similarly, the monolithic (and ever-expanding) nature of systemd is a strategic design error. That's probably not obvious to people who measure their experience in years instead of decades -- it wouldn't have been obvious to me back in the day either. But it's pretty clear from here, and dismissing it as "hey you kids get off my lawn" geezer whining is not going to advance the discussion.
You may have been in the "biz" longer than I have, but not by as much as you think. I didn't "immediately" see the value of systemd, but it didn't take me long. Your arguments still come off as appeal to tradition. It was impolite to call it old geezer whining was impolite but that doesn't change the nature of your argument.
It would be better, I think, to pull out a copy of Kernighan and Plauger's book -- which is rather brief, actually -- read it cover-to-cover, and then consider carefully whether the myriad-and-steadily-increasing number of functions being subsumed by systemd should actually be in one program.
It's been a while since I've read it, but ISTR that the modularity that K&P speak of refers to procedures and functions, they didn't seem especially afraid of "big" programs. And from what I've seen the systemd code is properly modularized in the sense that K&P use. Speaking of which, did you know that sysvinit has no unit tests (or tests of any other kind)? And since every init script is code (even though many people treat it like configuration data) why don't they have unit tests either? systemd has an extensive test suite, that gives me some reassurance that bugs, once found, won't be reintroduced. And I'm sure that if we went through the Elements of Programming Style point by point there is much more in systemd's favor.
If that doesn't suffice, then I suspect it will only require waiting a little while until a demonstration of why monolithic integration is a bad idea will be provided by someone who is at this moment studying the large-and-growing attack surface presented by systemd.
I hope I'm wrong about that. I'm probably not.
Software is software. I'm sure that bugs (including security bugs) will be found. Film at 11. Nothing new here. -- Jeff Ollie