This is an easy criticism to make. What's no so easy is to actually implement what's needed for a modern system and still achieve what you seem to be asking for. Modern systems are unbelievably complex beasts.
> An improvement would be something with modern syntax, sparse features, and good docs.
This is getting pretty silly and it just looks like you're reaching for anything to criticize here.
What does "modern syntax" mean and why would it be an improvement on the INI-like syntax of systemd configuration?
What earth does "sparse features" mean? You don't want to support everything that a modern system requires? (Take modern system to mean everything from containerized servers to desktops to laptops to a mobile phone. All places where systemd has its place.)
You don't think systemd has "good docs"? IME Systemd has unbelievably good reference documentation for any type of Free Software (in the Unix style of man pages, no less!).
Perhaps tutorial-like documentation is somewhat lacking, but the "systemd for Administrators"[1] blog series is pretty good IMO. (Though, granted, a bit out of date, perhaps.)
[1] http://0pointer.de/blog/projects/systemd-for-admins-1.html
The original author of Upstart basically admitted (to his credit!) that systemd's model is superior after Upstart had been in out in the wild for a few years.
I have a python webapp hosted inside uwsgi reverse proxied by nginx, adding `RuntimeDirectory=mycoolapp` to the unit file automatically creates and destroys `/run/mycoolapp` every time the unit starts and stops. I just plop my socket file inside the runtime directory (which is automatically created with the correct uid/gid based on the user/group the unit runs as) and fly away, I don't have to manage some directory inside /var/ and deal with an rpm scriplet to ensure the correct owner/group are set on it after install.
It's all the little things that systemd does that really make one appreciate it, they add up.
It's definitely wrong to think that upstart was overlooked when it came to the Debian hoo-hah, furthermore. Upstart was one of the four major contenders, and one of the two front-runners.
man -k systemd
There is extensive and well written documentation for all aspects of systemd so I'm going to call BS on your post. Also, the syntax is consistent and documented. It is infinitely simpler than sysvinit. Either you're trolling, or know very little about systemd. Note that I'm a fan, but far from an apologist.
What are the command-line options that are available to that tool? Without looking in the source code.
>Note that I'm a fan, but far from an apologist.
An apologist is merely someone who offers a defense of something. It comes from the greek word ἀπολογία, "speaking in defense". Thus you are an apologist, even though you're not dogmatic.
I just want to point out here that just because an English word comes from some Greek word, that doesn't mean the English word actually means that today. You are correct about "apologist" (according to Wiktionary at any rate), it just means someone who speaks in defense of something, but there are other words where the meaning has changed over time. English is a language that is defined by its popular usage, and this can change over time so a word may not mean the same thing today as it did just 100 years ago.
A good example is the word "pathetic". According to Wiktionary, it comes from Greek:
'παθητικός (pathētikós, “subject to feeling, capable of feeling, impassioned”), from παθητός (pathētós, “one who has suffered, subject to suffering”), from πάσχω (páskhō, “to suffer”).'
Obviously, those don't bear that much resemblance to the current popular meaning, which is:
'1.Arousing pity, sympathy, or compassion.' or '2.Arousing scornful pity or contempt, often due to miserable inadequacy.'
In fact, other European languages like German have this same word (I believe this is called a "cognate"; I am not a linguist), from the same root, but their meaning is entirely different and they get confused when they learn English and encounter this word since we use it in such a different manner.
TL;DR: Greek or Latin roots are interesting from a historical and linguistic perspective, but they're no guarantee of the current definition of an English word.
A cognate is simply a pair of words from the same stem (origin); it doesn't matter if their meaning is still the same. The opposite term is "false cognate", which refers to words that sound alike and mean something similar but stem from different roots.
Regardless of origin (so cognate or not), if two words in different languages sound alike but have different meaning, they're called false friends.
</pedant>
While not the greatest example of documentation, it's not completely horrible. It accepts a single parameter which is the seed (yes, I looked at the source). I imagine it was an oversight for a very simple program with a singular purpose and which isn't meant to be called manually. It's not great, but it doesn't carry the same weight with me as if there were multiple possible or required arguments, or even a single optional one. Perhaps there are examples like that, I don't know.
It's hard for me to get worked up about the level of documentation of systemd compared to SysVinit, when things like OpenBSD exist that achieve such a high level of quality that they are both utterly shamed, and appear relatively similar in their mediocrity.
Especially since the ultimate destination for that value is a root owned 600 perm file.
$ systemctl cat systemd-random-seed
# /usr/lib/systemd/system/systemd-random-seed.service
[...]
ExecStart=/usr/lib/systemd/systemd-random-seed load
ExecStop=/usr/lib/systemd/systemd-random-seed save
[...]
Now try to do a retrospective to figure out how the mistake was made, so it doesn't happen again
What? It doesn't affect my point in any way. I looked at multiple other man pages for services before posting, and noted that of the ones I checked, they all listed options for the service and/or command. I stand by other other portion of my comment (whether you interpreted them as I meant, or in some more negative light that might induce the negativity I feel from this reply).
I noted my reasoning on why I didn't find your example entirely compelling, but also noted that there could well be other examples that fit the criteria of what I considered more problematic.
I still believe the man pages are lacking quite a bit with respect to OpenBSD equivalents.
Look at the docs for something like systemd-service or -exec or -tmpfiles, etc. You found one that as bad. I'm sure you can find a few more. Now find docs for some random 1000 line shell scripts that aren't the code. At least there is a very obvious and consistent way to set the ulimit for my services, even if they don't support pam_limits via systemd, or an obvious way to extend the start script without hacking up the init file, etc. Please allow me to rephrase and say the documentation overall is so far ahead of th documentation for any implementation of init scripts and sysvinit it isn't funny. And this is coming from someone who spent most of his career as a UNIX / Linux SysAdmin.
Nah, it wasn't meant as a retort. It was merely an aside that I thought you might find interesting. And apparently you did :)
* https://bugs.pcbsd.org/issues/13566
* https://bugs.pcbsd.org/issues/13565
* https://bugs.pcbsd.org/issues/13564
* https://bugs.pcbsd.org/issues/13563
On the subject of systemd doco:
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
As long as you are prepared for the rest of the world to call BS on what you say here, as well. (-:
It's only "extensive and well written" if one sets the bar for those two quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the words that come to mind are "acceptable" and "mediocre". As someone else has already mentioned here, and as people have pointed out passim over the years, the expected as the norm quality of doco for the BSD world is noticeably a higher standard than in the Linux world.
But it's not the BSD world alone where the norm is higher. The norm for the commercial Unices is and was higher, too. A case in point:
I wrote https://news.ycombinator.com/item?id=11629824 a little while ago. Checking my recollection, I referred to several manual pages for the rlogin command. The HP-UX and Solaris manual pages for rlogin actually had whole subsections about escape sequences, beginning with the general notion then proceeding to specifics of the various individual sequences. The HP-UX manual even proceeds to discuss how to send the escape character onwards, and how to send escape sequences across a daisy-chain of rlogin sessions -- something that still applies to SSH today.
The Linux rlogin manual has 1 paragraph, doesn't mention that there's actually a general concept behind the specifics that it lists, doesn't discuss how to escape the escape character, and doesn't discuss daisy-chaining.
If you're just about to point to your Linux ssh manual as a counterexample and observe the treatment that it gives escape characters, as good as that of the HP-UX doco, then scroll to the bottom of the page and enjoy the fact that you're reading BSD doco written by BSD people. (-:
For my money, runit gets the nod for modern syntax, sparse feature ... docs are coming along ;)
For me was great and rewarding, a nice learning experience, about livecd's initialization and linux in general at the time.
I don't feel like I could have accomplished the same experience trying to do the same with systemd (with my age and knowledge and resources at the time).
Still more difficult, being a Debian user, where systemd is not in the same shape than RHEL based distros, and documentation is out of sync, or missed in blogs...
What you propose reminds me to openrc or the gentoo dependency based init system.
I Love too the BSD/Slackware/busybox init style (single script init). But I'm a scripting mad.
One of my reasons to live, of and for, opensource, is the ethics and freedom behind it. Other one was being more K.I.S.S. on my system interactions than with MS based products.
I feel capital interests hurts some things very hard to obtain, in voluntary groups of people, using guerrilla warfare, and without any care.
Eventually I've deployed some Debian stable (Jessie) systems with sysvinit this same year, and I'm grateful that people in Debian did that option possible.
I'm not sure if a third, or a new option with modern syntax and sparse features as you say, could be better than the years we've been moving the world using sysvinit or upstart or others... but we, the tech people, seem to like new things!
Totally agree about the docs care, specially when there are distributors involved.
When there are changes in opensource, there should be a lot of more care IMHO than in closed products, and this is not always the case.
Unfortunately people, by brain nature, is driven a lot by media and marketing, two weapons of venture capital techs. And if service providers insert X and media inserts X, people who did never maintain a critical and complex deployments using X and did integrate a lot of things with them, starts talking about the smell of the clouds.
What implementation do you suggest, to reach what you propose? I think is not easy :)
My main feature request could be: reliable and malleable (not easy too).
> An improvement would be something with modern syntax, sparse features, and good docs.
Loved your tower of babel mess definition, upvoted just by that comparison.
Have a nice day.
* 1. System 5 rc
* 2. upstart
* 3. systemd
* 4. "third, new, option"
The "Uselessd Guy" critiqued the thinking that underlies this strange way of counting to three that is being employed here, in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ .
See also https://news.ycombinator.com/item?id=11641426 on this very page.
For those with OpenBSD habits, there is a compatibility shim in the nosh toolset that translates to native nosh mechanisms.
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Linux Kernel. Git. $torvaldsinitsystem ?
You'll know there are too many dependencies on systemd when people who don't want it (Devuan, Slackware, openBSD) can't boot a decent system without it. I don't think we're in danger of that: people who don't want systemd don't need it.
Git did start as a tool, and has been extended, a lot.
The same than the kernel booting was extended across the years to cover usage cases.
If he writes pid 1 code by itself, to get rid of a issue, as he did with the kernel and with git, we will call it the Linus pid 1. But as others said, maybe he doesn't has personally annoying issues with this.
I'm not sure where this tendency of Red Had for taking over the ecosystem comes from. The only rational basis for it I can think of is they wanting Linux to stay complex, so they can sell support. But it's way more likely it comes simply by them hiring a big number of developers, and not having enough in-house problems to solve - after that they must lead, not follow (for marketing reasons), so they must push their solution onto everybody.
Within Linux. Systemd is explicitly anti-portability across Unixes, and encourages dependencies on it that make life increasingly hard for the BSDs, OS X, etc.
So, yeah, if you zoom out a little from Linux, systemd fits right in with the UNIX wars.
So in the end, because of compatibility shims on both sites - and that our software build systems have evolved to support multiple init systems, its largely a moot point.
Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
It could be that they both benefit from building complex systems and believe honestly that such systems are the optimal solution from their own perspective. This requires no bad faith or conspiracy theories.
Its simultaneously possible that such a complex solution is sub optimal for other parties.
They are under no obligation to build a solution that is best for other parties and others are under no obligation to adopt or like such solutions.
Its entirely possible for two parties to disagree without either being evil.
But then i start reading and seeing the guy name others from seemingly unrelated projects, thanking them for their efforts.
But lo and behold, once i start running the bloggers name, and the names he mentions, they all come up as Red Hat employees.
No it doesn't. Different OSS projects already compete with each other in many details of design and implementation. They try to win over users or mindshare instead of dollars. Some with financial backing also have dollars in mind. Even lock-in is approximated by things that many apps depend on but are too big to change without risking a break.
Let systemd try to take over whatever it wants. It is still LGPL licensed, so I can do whatever I want with it as well. Those writing it can do whatever they want - nobody has forced any distro to adopt systemd bseides Red Hat themselves, insofar as it was their project principally so of course their own distro used it.
Arch, Suse, Debian, Ubuntu... all game to use it under consensus. I personally think there is no better outcome than well engineered and linked software seeing uniform adoption to let the ecosystem move on to bigger problems. The degree to which systemd's pervasiveness has enabled the vast simplification and feature richness of so many disparate aspects of development on the platform only reinforces that belief - the ease of writing and shipping service, socket, requires, triggers, timer, mount, etc files. The ubiquitous availability of a session dbus. udev pervasiveness, cgroups already being there and setup, there is so much feature richness systemd gives everyone up the stack to claim shell scripts and grit were better is to say you should never stop reinventing the wheel to build the cart until the wheel is cast from solid gold.
Because they're willing to fund the work.
As for conflicting: i think you have missed server years of conflict, never mind that you can only ever have one process as pid1 on a unix setup.
And if something like your session tracker depends on pid1 being systemd, you get conflict.
An improvement would be something with modern syntax, sparse features, and good docs.