Shared publicly  - 
Some people are confused. And others are confused and write about it, like for example in this "Linux Future" posting.

I really like how "FLOS" uses "D-Bus" but no "sockets"... I wonder what how he thinks D-Bus transfers its data... Also, udev uses dbus now, as he claims. That's news to the udev maintainers though... I also like how he touts that FHS was UNIX even though only Linuxes adopted it and the actual true UNIXes never bothered with this. Also nice that he claims the usr-merge was non-UNIX, even though the real UNIXes Solaris and AIX did it years ago. Then, "loginctl ignores the old UNIX ways". Ahem, and I thought with logind we brought back multi-seat from the good old UNIX times and made it a first class citizen again.

This ongoing claim that systemd was "monolithic" and in that regard not UNIX, is slowly getting boring. systemd is a suite of various tools and daemons, written to work nicely together, living in a single repo. We copied that scheme actually from the BSDs, where they also develop and maintain their stuff much closer together and keep it in a single CVS.

The guy really confuses "How Linux did it traditionally" with "UNIX" even though the development of systemd and what he calls "FLOS" which he alludes to be non-UNIX comes much closer to how the real UNIXes are developed.

The whole discussion might even be interesting, if it mattered at all whether something was UNIX or not. Turns out it doesn't really, unless your religion is UNIX.
Some time ago I came across yet another angry discussion[1] about systemd, and have been reading and thinking a great deal about the design of Systemd, and what it says about Linux. I've come to reali...
Jürgen “tante” Geuter's profile photoWolfgang Walter's profile photoPaul Eberhart's profile photoVíctor Daniel's profile photo
I learned a nice word for those people at ELC barcelona: 'unixbeards'
+Koen Kooi that might even be appropriate, if they wouldn't actually confuse Linux with UNIX... I propose "confusobeards" instead.

I also have the slight suspicion that many of the "confusobeards" are too young to even have a beard. Their style of writing and behaviour suggests they are younger and given that their information about UNIX is quite distant from reality suggests they actually never came in contact with a real UNIX...
Well, the matter really became complicated, and blaming anyone for being uninformed does not help. This is one of the better posts, as it tries to be balanced. (Although the post needs clarification)
What I find truly amazing is how many different definitions of the "UNIX Philosophy"(tm) exist. Is there actually some kind of formal definition made by someone somewhere?
Great post. But I can't help myself. I'll be an ass and point out most of the big BSDs have switched/are switching to SVN. Woo hoo! Nothing like being current!
"What I find truly amazing is how many different definitions of the "UNIX Philosophy"(tm) exist. " that 's for the same reasons you find different versions of christianity, islam, judaism etc.. because it is a dogma.
Not sure why I even bothered to reply to it .... sigh.
+Dan Hansen Oh, that post really is embarassing :-/
Why is designing stuff the "UNIX way" even a priority to some? Designing a the best possible solution for a problem should instead be the ultimate goal, not holding on to a dogma even if it makes no sense in a certain situation.
By the way, everyone who has problems with the XDG stuff should please join the development teams and help (and then learn quickly why some decisions were made the way they are).
IMO "Unix way" was the one that has saved posix open source OS projects from total annihilation in 90. Situation is better now, but not that good to reinvent old mistakes, +Matthias Klumpp 
+Oleksii Shevchuk If a concept has proven to be good, you have to justify why you're doing it differently and not using the existing good practice. But if there are good reasons for not using an existing concept, I can't see why it is bad.
(I think you're right, btw. although I never experienced these times :P)
Eh, let that guy try to write a worm to get a complete inventory of a hundred boxes (including RAM, disk, peripherals, and expansion cards) with different configs located in 6 time zones into a CSV. He'll soon appreciate the usefulness of APIs he can talk to, and curse the places where it doesn't exist.

After the first half-dozen regex-based parsers to scrape the data from the command-line tools' output, you start to curse the so-called "Unix Way". I mean, seriously, the tool already knows how to pull the data together into a structure, why do I need to parse thirty different homespun text formats to get at it?
The only think I'm worried about losing in the future is text configuration and shell scripting, and you have to admit systemd is a little light on the two -- not that I'm complaining mind you, the kernel can't be configured with text files either. Maybe systemd is the userspace kernel?
Ryan : In what way you are losing text configuration and shell scripting ? I frecuently hear this argument too, never made much sense to me either.
+Ryan McDougall systemd exclusively uses text files for configuration. Short ones, which you edit with your favourite editor. Not sure how you came to the conclusion we wouldn't use any. What do you think we'd use instead?

And who told you that "shell scripting" was going away? We just don't boot the system anymore with shell scripts, but that should not stop users/administrators from using shell scripts as much as they want. And heck, we use shell scripts all the time ourselves, and why wouldn't we? We just don't think they are the best choice for a quick, reliable, robust, introspectable, easy, simple boot. And that's why we didn't pick it for the project. But you know, the systemd tarball includes a number of shell scripts for various purposes, to build things, test things, install things, and a ton of other things.

Also, the kernel is also configured with text files. You build it with configuration from a text file, and much of the runtime configuration is done via text files like the sysctl.conf snippets, or udev rules or whatnot.
+Lennart Poettering the well documented, all-in-one-place and all-in-same-format config files are what convinced me that I didn't want to use a distro without systemd. So yeah, thanks for that.
Lennart: Those text files are systemd configuration, not system configuration, so the data model is tied to the implementation. Perhaps it always has been this way in practice, as it's been a long time since /etc/passwd stored passwords.

The shell scripting isn't disappearing from linux forever, it's just disappearing from the boot; I for one am happy to pay this cost for boot times and modern features -- it's just a shame boot is no longer shell-script accessible.

The kernel is not runtime configured with next files -- you have to compile it and once you do through that huge step it's mostly locked down. I think this is what people like about scripts and text -- edit and restart and your changes come to life. Compiling C (no matter how easy you try to make it) will never be this simple.

Lastly, don't shoot the messenger, I'm quite happy with my modernization. Lennart we've been drinking at FOSDEM, and if I didn't kill you then you must believe I have no intention of killing you now. :D
+Koen Kooi
I've always used "gnubeards", but maybe we can compromise with "gnu/unix beards".

+Ryan McDougall systemd has a full SysV compatibility mode. You can use Shell scripts if you want to. It's just that it comes with a large amount of tradeoffs, and thus the team behind systemd does not recommend it.
Heh, this thing really will go on forever.

Systemd is a bunch of old plumbing level concepts done right (init, inetd, syslog, etc.). People don't get it, it's new, it's different, so, since it doesn't feel right, it must be wrong. Besides, living in this state of cognitive dissonance - i.e. thinking of oneself as a Great Guru while being unable to grasp the simplest re-invention of what has been there for ages - makes for an uncomfortable feeling that needs compensation.

So let's define UNIX in a way where I can still understand everything without re-learning to handle the new tools that implement the same old concepts, just in a slightly improved way.

'Unixbeards'? 'Stalebeards' feels more appropriate.
+Ryan McDougall so if "the kernel is not runtime configured with next[sic] files", what do all those sysctl.d text files that allow you to  configure the kernel at runtime do...?

But more seriously, lamenting that the "boot is no longer shell script accessible" is really missing the point. If you've got something simpler to understand (discounting the "conversion" factor), which is easily overridden, permanently, from the packaging-system provided defaults, which allows you to drop in a shell script wrapped in a simple unit if you so wish, then why is the boot any less "shell script accessible"? Just because the whole system is not a mess of boiler plate shell glue, doesn't make it less accessible. Of course it might mean that people actually have to learn how to use shell scripting properly rather than just copy+paste in a monkey see, monkey do way, but that is really orthogonal to the accessibility argument.
Listen, Lennart, systemd is great. period. I've been waiting for such a tool for a long time, it removes the first level of fragmentation among distros (just having unified way of starting services is that good). So stop waisting time on reading rants and focus and making it even better .) The only problem with systemD is it takes quite a while to force and really learn all the key points (too much of great documentation).
In trying to follow this discussion, I came across these rather provocative claims:

This made me curious about the 9p plumber project.  Is D-bus based on this code?  Does anyone have any idea why this guy is claiming that D-bus is technologically inferior to plumber?  Why the cgroups code is so badly written?
By the last sentence of your post you seem to be in violent agreement with the OP…
systemd implements basically the exact same idea I had 10 years ago for an ideal boot system, with many improvements. I'm glad someone else did it, sometimes procrastination pays off ;-)
+Lennart Poettering could you write one of your helpful "Systemd for Admins" pieces on using shell scripting with systemd? 

I think a lot of people share +Ryan McDougall's concern that systemd is somehow inimical to the use of traditional shell scripting tools. From my limited experience that's not true: I start scripts from .service files and services from scripts with no problems all. But I'm sure I could do more and better with your help.

Shell scripting is great, but it's like duct tape. I don't think the view that making an init system out of shell is like making an aircraft carrier out of duct tape means you hate shell (or duct tape). I just think people need to be given concrete examples to see that's true.
+Jon Dowland: The article seems somewhat religious. As in: include what you like, ignore parts that you don't. E.g. talking about /usr split is not UNIX, then defending this by defining Solaris as "odd duckling". Also funny is liking Plan9 because it is planned, saying ad-hoc is bad, while at the same time promoting "Build a prototype as soon as possible.". Seems incoherent.
Hi there.. reading all this is so much fun .. and sad at the same time 8)

It would be even more fun when people would use the energy they use to start discussions about the (pros and) cons of one system vs. the other for developing alternatives or improving some stuff they really care and like.. If somebody does not like one software/distribution/way of doing things he is free to use (and hopefully support) another software/..

But it is really sad that - in every public discussion about systemd - I only see people loving/defending it or people hating it from the bottom of their hearts.. 8(

Blaming the author that he does not really understand/know what the Unix philosophy may or may not be, does not help. If you focus on the real issue he may have, you end up with a guy who can not do stuff the way he was doing it before. Why? Because everything has changed..And it was easier to add a user to some "camera" group to let him access some hardware.. So the discussion as I see it is in fact something like "things were easier in the past" vs. "things have improved"..

systemd improved a lot of things (at least for me). People just need to understand that improving the usability of a systemd enabled system is an ongoing process. I use systemd since v15. So removing the need of appending .service when starting a unit already was a great improvement in usability for me 8) But I still can't do anything I could do with the old fashioned init-scripts..! Do I miss them? No! Not at all 8) Do I get blamed for the systemd integration in our systems? Every single day! Do I care? Yes.. but I just fix the issues that arise. Sometimes I do not like the new way - But I know everything is still under development 8) Maybe the day will come, when I complain how stupid and ugly systemd is.. 8) That will be the day when you guys break things I really care about 8)..

From a Systems Engineer point of view I would love to see a version of systemd with long-term support. So that I do not need to change too much when I just want to get rid of some bugs.. It is sometimes hard to defend every change in the system and brief others about the changes made without starting a discussion like this one 8)
+Marius Tolzmann: Do you see anything specific in the referenced article?

Also best not to assume I/people only 'defend'; though +Colin Guthrie does the 95% of the work (for Mageia), I did switch various %configure2_5x things to use systemd. The development version of Mageia has not used ConsoleKit for a while now. Plus every now and then we get hit by bugs, etc.

If you follow the systemd mailing list, a complaint of a missing dependency / systemd bloat turned into a patch which changes a Python script into C. Seeing things like this make me question people who say that the systemd mailing list is bad.
+Olav Vitters as I understand the referenced article, it is about tons of frustrating issues the author may have with newer systems and especially those running systemd 8) The article is not helpful at all. It just describes issues and at the end it is full of (partly) wrong conclusions.. 8) But this is just my interpretation of the content 8)

I did not mean "only" defend.. I myself always need to "defend" my decision to use systemd in our systems among my colleagues for some time now.. It is not always easy to discuss issues they have with systemd.. I am totally pro systemd - just to be clear.

What I see is that in the comments section of the article many people agree with the author. It is just my personal guess that they agree to the "things used to be easier" content.. People in general don't like changes, i think.. 8) And many people like to complain about changes they do not like.. 8) Most of the time this is not constructional (?) and does not help at all.. But please do not forget that not everybody can be a pro in system administration.

If development goes as fast as it does in systemd (and replacing init scripts, adding logind, adding journald, adding seats, adding whatever feature you can think of in only 2 years is quiet fast) some people just can not follow.. and If someone was used to add people to some 'camera' group to give them remote access to whatever, he gets "pissed" if by default only some active session gets access to it and the old way does not work anymore.. This is just human 8) What I missed in some discussion in the past was just some insight like "Hey! This article is somehow embarrassing, but..  hmm.. ..maybe he got a point (somewhere). Maybe all this stuff is not as intuitive for a 'normal' user as it used to be.." But all this can't be solved by (systemd) developers/maintainers - I guess.

What I tried to say: If someone is already "pissed", it does not help to tell him in detail that he does not understand what he is talking about.. Sometimes it may help to mention that he is wrong and invite him to state his issues in an appropriate way on the mailing list or somewhere else and that there are people to help him to get over it 8) Things change. 8)

BTW the mailing list is great. And I personally liked the patch that changed systemd-analyze into a C program, too. And I can confirm that everybody who asks nicely always gets a competent answer to any issue they have.

And in general I agree with nearly every decision that was made during the systemd development process till now. And I like the way +Lennart Poettering tries to explain all changes made and their background in the many blog posts..
+Jon Dowland Oops, terribly sorry about that confusion.  The last sentence is strictly the opinion of the comment writer, and self-declared kernel hacker, viro.  I have no idea, which is why I was asking for someone more knowledgeable to comment.  What I should have said is "why is he also claiming cgroups is so badly written?".  Normally I ignore unsubstantiated opinions like this, but the writer claims to be a kernel hacker, so presumably has looked at the code.  We use ubuntu on our systems, and when I first read about systemd I did comment on the ubuntu-devel-discuss that it would probably be more sensible to abandon upstart and switch to systemd unless there were compelling technical reasons not to do so.  No technical reasons were offered other than the blather Shuttleworth repeats in this article:

OTOH, having choice is good until the dust has settled.  Most of the criticisms of Upstart I've seen, e.g. it's nearly impossible to figure out what the actual sequence of service initializations is from the /etc/init conf files were all things I brought up years ago on the unbuntu-devel-discuss list.
Add a comment...