"Even the linux die-hards have essentially grasped the necessity of systemd (Even though they're going to hate on it for awhile longer)"
The questions are:
* How much of that needs to go in PID 1?
* How much is required to go together? To what extent can the system be made more modular and separable?
* What allowances are going to be made for legacy operation modes?
The concerns I've got are too much being put into highly critical process space while issues are shouted down and/or disparaged. My sense is that the systemd ship is going to encounter the rest-of-linux ship and both are going to be significantly changed. It's quite likely that some key personnel on both sides will get ejected in the process. I'm not happy with the present course and state of affairs.
I've been using it in my Linux distro for at least a year. It works fine-- quicker startup, handles hotplug correctly, rational management of services, and easy to add new ones.
I'm sorry, there is no nice way to say this, but the systemd truther crowd is a lot like the Obama birth certificate crowd, or the anti-vaxxer crowd. Repeating the same discredited arguments over and over. And for the most part, composed of people who have no experience in what they're talking about, so why should their opinion even matter?
Lennart's only mistake was to be bad at public relations and rather blunt about what he said in public. (I, on the other hand, can afford to be blunt because I'm just an anonymous guy, not a project manager).
The "it works for me" fails to address those for whom it hasn't worked. Which includes, I'll note, any number of people who might generally be considered somewhat past beginner status with Linux: Alan Cox, Ted T'so, Bruce Perens, John Goerzen, among many others: http://www.reddit.com/r/linux/comments/2dgy45/if_systemd_is_...
Equating them to Donald Trump and a mob of Koch-backed disinformation shills isn't simply wrong, but trolling, of the level of Donald Trump and a mob of Koch-backed disinformation shills.
I'll note once again that the focus on insults and lack of addressing specific points and issues really cheapens the case for systemd, and its proponents.
If I've established that someone isn't exercising good faith, I'll change course. Particularly if they spout disproved statements on exceptionally well-established points (scientific or similar topics, generally). There's enough genuine grounds for disagreement on the systemd debate (though yes, there's FUD as well) that blanket dismissals strike me as inappropriate.
That said, yes, refuting frequently-raised points gets tedious.
additionally, for the vast majority linux systems that are actually embedded, BSD needs a solution for that.
There is such an emphasis on consistency, that a solid OpenBSD administrator, who last worked on OpenBSD in 2004, and then, 20 versions later, (OpenBSD releases a new major version, along with a full set of architecture releases and binary packages every six months, like clockwork) - would have zero problem understanding all of the system concepts. A few things have changed/updated/evolved, but a couple hours with the man pages would bring them right up to date.
OpenBSD is about very gradual evolution, not revolution.
My sense is that OpenBSD is not designed for Watches, Tablets, or SmartPhones. It is a world class Server, Firewall, Router, networking device, networking appliance operating system, and it's unlikely to ever lose that focus.
I'm pretty confident that we won't see anything like systemd confusing everyone on OpenBSD as long as Theo continues his steady management at the helm. Systemd actually serves some pretty important functions on systems that have a lot of dynamic services going up and down with dependencies, particularly on low-power devices, and on systems that require rapid parallel process initiation - so I'm not hating on systemd here, just appreciating the consistency that we find in OpenBSD.
To make a concrete example, look at ifconfig and ip (from iproute2 I guess?) on Linux. ifconfig was used to be the one tool to rule them all, everybody knew it, everybody used it. At some point somebody decided they need a new tool, so now there are two, and the other is said to be deprecated. The fun thing is that ifconfig still mostly works, and you find lots of documentation/tutorials/wikis telling you to use it. But at some point you might bump into some really weird issue which turns out to be because the tool you're using is.. well, deprecated. I did have such a problem myself (related to IPv6, years ago) and it wasn't much fun, because the tool looked like it's got support for the thing I was trying to do, but it would just silently and weirdly fail...
In the OpenBSD land, a network interface is a network interface. You use ifconfig. IPv6 or not. Wireless or not. The same tool everybody knew has been evolved to support the new stuff. The developers are careful about needlessly changing the user facing part of a tool in a way that would require him to re-learn it or another tool. Of course, sometimes changes are inevitable, and these changes are usually documented in the upgrade guide (and the page which documents changes to the -current branch). So there are few surprises.
Sometimes the underlying tool might change entirely to another implementation, yet the user facing parts are made for most part finger-compatible with the old tool. For example, mandoc(1) has replaced historical tools like man(1), apropos(1), etc. And sendmail has been replaced by smtpd, but smtpd still provides newaliases and makemap.
So they don't push shiny new poorly tested tools and tell everyone to relearn everything all the time because shiny new features (and the old tool was cranky and nobody wanted to fix it).
It was irritating at first but ip is a better, more capable tool.
http://serverfault.com/questions/458628/should-i-quit-using-...
Re- ifconfig/infiniband - this is ironic - because when I google "configure infiniband linux" - every page I come up with only mentions ifconfig, and never ip.
(though, ifconfig is just used to display the interfaces, and it's usually other commands like ib that seem to be used to configure the infiniband interfaces)
It's also working on a set of Systemd shims as a replacement for systemd: http://www.phoronix.com/scan.php?page=news_item&px=MTc4MjQ
The only problem is that systemd is a bad piece ("piece"? Or rater "lot"?) of software.
That said, the proposed idea doesn't sound like something that is trivial at all, but rather pretty bug-prone. There already are de facto event engines for certain areas like device hotplugging (formerly HAL and now udev on Linux, devd on FreeBSD), whereas for a lot of other events in Linux software a typical way is to subscribe on an application's D-Bus interface and wait for signals.
Indeed, OS X's notify API looks precisely like a message queue from my brief observations.
But then there's certain events and classes of events (such as "network is up/network is down") that could have literally over a dozen meanings. I'm not sure how a practical centralized event broker could be anything more than a glorified message bus? Otherwise, encapsulating highly multi-faceted and non-deterministic system states into generic events sounds like bugs galore.
Not dbus? Because that + the notify api sounds... a lot like dbus.