Yes. 1.5, if my mind serves correctly. Later on, LSB tried to do something similar for sysvinit using initscript headers that were interpreted by an external insserv program, but these proved to be far more fragile compared to rcorder(8).
This is a disingenuous presentation, though I would not expect any different from a systemd proponent, or opponent, for that matter. I wrote about the follies of systemd debates here: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Whether or not it is easier to maintain cannot really be objectively gauged. As for declarative configuration, I will grant that. systemd is not the first to do this on Linux, though. eINIT was, though it used XML as its configuration language (similar to launchd and SMF in fact, though not as verbose). eINIT also had the benefit of a modular plugin-based architecture, a property also shared by finit and initng.
Change does not imply progress. This should go without saying.
No, a lot of objectors simply come from having different opinions on process management and general software architectures. That said, there is a contingent who did approve of the old approaches, yes. I dislike sysvinit, but I can understand them. Serial execution with a concretely defined boot sequence that is easy to reason about can be a benefit to some. In contrast, the systemd approach eschews any definition of "boot process" or "boot sequence" that can be specifically intervened in by order, instead taking the philosophy that specifying a unit's dependencies and relative order to a target/synchronization point is enough, the rest being handled by internal transaction and job semantics.
systemd most certainly is monolithic. It is also modular, but to a partial extent. System generators and various auxiliaries (journald, but also some of the more minor tooling) cannot be disabled at build time. Certain things like Plymouth communication are also explicitly done at runtime.
launchd as a whole is still a much smaller system than systemd, at the end of the day. This is because launchd has a concretely defined purpose. systemd has little in the way of that other than vague descriptions that ultimately amount to being "as much as possible between the kernel and base libs+utils".
I don't think anyone really considers sysvinit to "follow Unix". In fact, I'd say sysvinit is more of a historical accident than anything. An actual example of a service manager that follows the Unix philosophy would probably be daemontools and its derivatives (s6, perp, nosh, daemontools-encore and runit).
When I first started using Linux, I found SysV init very intimidating (along with the rest of the system). When I eventually stumbled upon Slackware, and then FreeBSD, I was euphoric about how simple it was to configure system startup.
Which, I guess, is why the BSDs feel a lot less pressure to replace their init/rc system than Linux distros.
Slackware, Gentoo/Funtoo, CRUX, PCLinuxOS and all its derivatives. Then some more niche ones like Alpine Linux (which also eschews a lot of the GNU base system for alternatives) and Void Linux.
A lot of people conveniently ignore that the shirt was actually made by a female friend of his named Elly Prizeman. The situation all of a sudden becomes completely different when you factor in that fact.
I was aware of that but didn't mention it because it's not relevant to the question of whether that was a good wardrobe choice when representing you and your colleagues’ professional work for international media coverage.
I completely condemn such nonsense as a bunch of vitriolic people driving a distribution maintainer away from their position all because of their indirect affiliation with a controversial project.
Such actions are why I identify with neither the systemd opponents nor the proponents. Unfortunately, it does dilute arguments against systemd, because of immediate associations with fools who attack people and scream fallacies (even though the non-systemd camp is an amorphous blob more than anything). This in turn gives moral high ground to the proponents and any attempt at debate devolves into the same dead ends and non-arguments between equally clueless factions.
Yet as much as the entire display is abominable, it is sadly also completely predictable. For all the good things the systemd crew have done, their ideas are disruptive, in that they're trying to mold a cathedral out of what has been a rather adamantly bazaar-based community for over two decades now. Contrary to popular belief, simply developing your tools in one repository doesn't magically make you "more like the BSDs" - there's far more to the BSDs than that, and every time I see someone make that argument, I twitch.
We're in the midst of an unprecedented schism. But, for what it's worth, this isn't an issue with "open source". No, it's an issue with the Linux community in particular. It is particularly dysfunctional. I have no idea why Linux attracts so much drama and carnage amongst its constituents, but it does.
I'm pretty disappointed in all sides here. The people who attack systemd and its developers on completely false premises, and the people who are convinced it's the be all and the end all, and have been living under a sysvinit-based rock their entire lives. It's just so exhausting. It really is.
I don't know how this will end. But the irony is intense: an attempt at distro unification has led to a big divide. The best thing we can hope for is people doing a bunch of new experimentation in Unix process management. Projects like Epoch and nosh are up and coming. Hopefully we'll see more.
> I have no idea why Linux attracts so much drama and carnage amongst its constituents, but it does.
It starts right from the top, just like the similar situation in the Rails community.
When your founder and leader behaves a certain way, it gives everyone in the community license to act like that.
Edit: I seem to have touched a nerve here. My apology to anyone my comment offended.
Nonetheless, I stand by the idea that the culture of a company or open source is heavily influenced by the behavior of those at the top. How could it not be?
As an example of the other end of the spectrum, when I worked at Adobe it was a remarkably courteous place where people treated each other with respect even when they disagreed. I really appreciated that, and I think a good part of it came directly from Adobe founders John Warnock and Chuck Geschke.
But then by this logic, OpenBSD should also be a dysfunctional mess. It's not. It has almost the same number of contributors per 6-month release cycle that systemd alone gets in only about 3 months, yet it is a remarkably productive project.
No, I do not think Linus is at fault here. I think a more likely explanation is that (GNU/)Linux is the go to alternative operating system, and it gets a lot of cocky newbies who think they're special for using a Unix-like operating system.
I don't know, BSD seems to attract a lot of people who seem self-congratulatory that they're not using Linux, just like how MacOS has been the Anti-Windows since circa 1995.
My theory is that it's straight-up due to how many people use Linux compared to other non-Windows OSes and the fact the average people have more say (or think they do) compared to The One Apple Way. Any large group will have assholes, and the number of assholes is a simple percentage of the total.
My personal experience is that BSD people by and large care about Linux mostly out of necessity, but nonetheless they're still knowledgeable about both. Mostly they're angry whenever the Linux community feels the need to reinvent yet another square wheel (as was mocked in the OpenBSD 5.2 release song), because it slows them from doing their own innovations and necessitates them to emulate Linux's interfaces.
In contrast, a disturbingly large number of Linux users remain willfully ignorant about other Unices and, worse, they attack them without knowing the first thing about them.
But yes, Linux users are dominant, so more idiots overall.
So because BSD attracts people who seem self-congratulatory that they are not using Linux it begets a productive non-asshole environment?
The parent poster was stating that OpenBSD also has a strongly opinionated leader at the top (Theo de Raadt) who has been known to rant and rave like the best, yet unlike the Linux community the OpenBSD community as a whole does not behave like that and ships functioning code quickly and efficiently.
Is that the same Theo who threw a tantrum because nobody notified him ahead of time of some OpenSSL vulnerability after he specifically declined an invitation to be on the cross-distro security mailing list where such notifications get posted?
At best, people are imitating what they think Linus is doing. But most people miss out on just how rare Linus's rants are, how deserving his targets are when he does let loose and how much they should've known better, and most people aren't as authoritative as Linus.
> ...how deserving his targets are when he does let loose...
I think I see the problem here.
I don't follow the Linux community that deeply but I've read one of his rants which was belittling and insulting to a volunteer maintainer and the context behind it didn't justify the abuse in my opinion. If you don't appreciate their code, get rid of them. They're probably not trying to intentionally screw up. And if they are, tell them it's not working out and stop working with them.
P.S. Would be interesting if "Gaming is misogynistic" folks decide to focus on the Linux community. I can almost see the headlines: "Linux users are dead!"
So you're saying that a "my way or the highway" policy is more polite and better for the health of the project and developer community than the occasional bit of colorful language? It seems to me that the former is a much bigger insult in an "actions speak louder than words" kind of way, especially coming from people for whom the primary concern is producing working code, not politics.
1. I'm not complaining about colorful language. There's a difference between that and insulting people.
> I don't understand why it's so hard to fucking understand how Linus' behavior is abhorrent.
> wtallis, you've got to be the biggest fucking idiot to not understand how Linus' behavior is abhorrent.
See the difference?
2. I'm not familiar with the way the Linux kernel contributions are managed. I assumed from what I've heard that Linus is in charge and can reject patches. If that is the case, than a "my way or the highway" policy is the current policy. I may be wrong in this regard so please feel free to clear up any misunderstanding I may have.
For Linux, the "your patches will not be accepted" responses comes approximately after you've ignored a dozen or so Linus rants, each of which will generally first come after you've ignored advice and suggestions from dozens of other people and still insisted on submitting broken stuff. Probably, if you manage to get "banned", at least one rant about you will have featured on HN or Reddit.
Rejecting patches happens often, and usually for mundane reasons. Rejecting people is extreme, and something that's only happened a very, very few times. Off the top of my head I can only remember Kay Sievers [1]. Even then he left the door open ("Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers").
It's hard to get Linus to rant at you in the first place. It is many times as hard to get him to refuse to deal with your code. Basically, you have to persistently be submitting code that the kernel team considers total junk and persistently refuse to acknowledge or deal with the suggestions given.
For your first point, the difference will only ever be very small when the topic of discussion is something that is inherently associated with a particular person, such as a patch with a specific submitter. The phrasing of the former example is more passive-aggressive, but usually no less targeted.
For your second point, you said:
"If you don't appreciate their code, get rid of them. [...] tell them it's not working out and stop working with them."
That implies more than just rejecting bad patches, it implies rejecting the developer himself. That's extremely rare. The Linux kernel developers are very forgiving of mistakes: your patches will get rejected if they're bad, but they'll still get looked at until you establish a really bad track record of not learning from your mistakes.
> I think some people are just irrationally upset about perceived threats to something that is very important to them.
Some opponents of systemd seem to think that a move to systemd is an irreversible move in the wrong direction -- that once a distro moves to systemd, there's no going back, because systemd is large, complex, and monolithic, unlike the simple and modular SysV init system. If one is strongly attached to Debian, and feels that the distro is moving irreversibly in the wrong direction, I can see why one would strongly oppose such a move.
The elephant in the room here is that this is behavior that is largely people imitating Linus's "personal style". Although he doesn't resort to death wishes, the tone he's famous to setting on mailing lists pretty much inevitably leads to other people thinking "this is OK".
> Unfortunately, it does dilute arguments against systemd, because of immediate associations with fools who attack people and scream fallacies (even though the non-systemd camp is an amorphous blob more than anything). This in turn gives moral high ground to the proponents and any attempt at debate devolves into the same dead ends and non-arguments between equally clueless factions.
This is a time honored way to destroy your opponents in politics even if their argument is better, more consistent, and logical. Associate them with radicals that glom onto any side with sufficient numbers. It works and frustrates those that come by their beliefs honestly. It is truly sad when this happens and is allowed to obscure a discussion.
ANTINEWS is the best kind of NEWS. And you don't just lose things, come on. Our recent support for running a system instance of systemd/uselessd without taking over init (as early and rudimentary as it still may be) is a good thing. Cross-libc is another. A couple of things from main.c were refactored into independent tools.
This is still a giant WIP and it's quite experimental. We make this perfectly clear in the wiki that it's not ready for system integration or daily use, and there's still a long way to go (including some more radical ideas) before we ever think of making a stable release.
uselessd is about sticking to processes. Did we not make that clear? If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality. Device activation can still be accomplished through (e)udev. We're device node manager-agnostic. We made this clear.
No, you're not screwed. I think you completely ignored the fact that we intend on being portable. This is still early, again, but nonetheless we do compile on FreeBSD and Debian GNU/Hurd and some of the tools (like systemd-delta) actually run properly.
To be honest, we haven't tested the systemd-fsck unit. We mostly removed the binary due to being something that used libudev and looked like it belonged to a shell script more than anything. You can still force fscks through other means (tune2fs for ext2/3/4, etc.) We'll be sorting this out.
It sounds like this project offends your personal ideological sensibilities, as you totally misunderstand its purpose and fail to realize it's a WIP and unstable.
By the way, I liked the jab about choice. I wish we all voted for the same political party, too.
> If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality.
Without being pid 1, that dedicated supervisor needs supervision. Now you have duplicated functionality.
At the same time, said supervisor runs into all kinds of extra problems to ensure proper cleanup of misbehaving services. Supervisord for example is a perfect example of a process monitor is easy to make lose track of the services it's supposed to monitor (I'm not trusting it again). Systemd's use of cgroups for this is for good reason: it's a hard problem to sort out.
You may end up with something usable, but a lot of the Systemd decisions are the ways they are because the alternatives were severely broken. And yes, that includes supervisord and monit.
E.g. here's an example from the Monit website:
check process apache with pidfile /var/run/httpd.pid
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
This seems innocent enough. Certainly it's better than "just" plain old SysV init. But it is still fundamentally broken.
I've lost count of the number of times the Apache init scripts fails to bring Apache reliably up or down, for a variety of reasons, and the assumption that the pid-file will actually contain the pid of Apache or an invalid pid is fundamentally broken (the number of times I've found the pid-space has rolled over quickly enough to cause problems? Not huge, but far from zero), as is the assumption that there won't be other Apache processes in various unpleasant states whose pid is not in the pid file, but which will prevent a restart.
The problem is that Monit is fairly representative for process managers in this respect, most of which makes the (broken) assumption that the init scripts start, stop and restart actions will work reliably, and/or that the pid file contains sane content, and/or that you have a reliable way to kill a process based on holding onto a pid. I've yet to encounter a system where any of those assumptions are true, though you may need to scale up a bit before you start seeing enough of those failures to care.
So the suggestion of using something like monit or supervisord without addressing the amount of functionality you lose if you do makes me question if you understand the purpose of the pieces you are tearing out and/or whether you have put any thought into how users can regain that functionality without ending up making the same tradeoffs systemd does after all.
I'm all for getting something more modular than systemd, but ultimately I think few people will be well served by giving up on the substantial improvements systemd is bringing.
You can run uselessd with or without being PID1. The two modes have different implications, obviously. The latter choice will mean a separation of system manager and service manager. cgroupfs monitoring works properly in both cases.
PID files and SysV initscripts are broken. We're well aware and this has been common knowledge for a long time. What I meant was that you can still get more potential from a dedicated program that tries to focus and solve cases in one specific areas. Making a distinction between the init part and the manager/supervisor part is one of our longer term goals with uselessd, beginning with version 5. It's a trade-off.
We understand what we're doing, and we do not deny the presence of warts. When we announce that we're stable and ready for system integration, then we can really talk. As it stands now, this is all preliminary pondering.
Off the top of my head: __compar_fn_t (just a typedef), strndupa(), parse_printf_format(), canonicalize_file_name(), the GLOB_BRACE flag, implicitly included headers, error.h (also in uClibc)...
