I'm not trying to be snarky here; but systemd is hosted on freedesktop.org,
is it not? That is its primary place of development as well, no?
Admittedly, I've always associated systemd as a project as part of this
nebulous "effort" to bring linux on the desktop forward. I also assumed
that's why they went to the trouble to integrate systemd into dbus so heavily.
I have read some of Lennart's essays -- but I generally strongly disagree
with his conclusions, so I haven't been paying attention for a while. I
think his solutions are over complicated and rely on too much impenetrable
technology to actually save me any time. The arguments have been made
elsewhere, so I won't go into it that deeply, but I think departure from
the "unix way" is folly and will only make administration more difficult.
As far as getting used to it goes; this is still unix. I can still
install whatever initd I like after the fact. Which I do. Yes, this
means I have to do more work than I would have to do if I relied on vendor
packages, but we generally use custom packages for all our critical services
anyways. Since we're going to have to deal with it whether or not we're
using systemd, and we're already rolling out a non-standard initd to our
distributions, we don't feel we have to make any investment in learning
systemd.
Freedesktop provides hosting for systemd, but it is not really a project under their banner.
I won't go into it that deeply, but I think departure from the "unix way" is folly and will only make administration more difficult.
"There is nothing more gray, stultifying, and dreary than a life lived inside a theory." --Jaron Lanier
Unix as a design philosophy is dead, or it is in serious need of a revamp in order to cope with the realities of modern systems. The complexities of modern software call for parts that function together as an integrated whole and are designed to work with each other -- not parts that fulfill one limited task and abdicate all further responsibility. It's time to let go of the 1970s conception of the Unix way if we want to build Linux into a modern system.
In fact both the dominant desktop Unix -- Mac OS X -- and the dominant proprietary server Unix -- Solaris -- employ an advanced init system similar in many respects to systemd. So there is already established precedent in the Unix realm for what Lennart is doing for Linux with systemd.
And again, there is overwhelming support for it in the Linux community, so much so that support for non-systemd configurations is already drying up in a variety of third-party upstreams. Systemd is the path of least resistance.
> Unix as a design philosophy is dead, or it is in serious need of a revamp in order to cope with the realities of modern systems.
Oh, you young whippersnapper, there is still so much in the world for you to learn.
IT is the poster child of the NIH syndrome. No other knowledge area suffers from it as much as IT does. For a system design paradigm to have survived 50+ years in this environment, it must be quite good.
Settling on dbus for IPC is about as bad as settling with CORBA would have been ten years ago. Settling with a simp!e Unix socket following the everything-is-a-file paradigm is just as correct today as it was in the sixties.
dbus provides useful abstractions -- like broadcast/multicast -- that are lacking in the traditional Unix IPC mechanisms and are cumbersome and slow to implement.
That's a big part of why it's superseding almost every other IPC mechanism out there for critical system messages, and why it's going into the kernel.
I have read some of Lennart's essays -- but I generally strongly disagree with his conclusions, so I haven't been paying attention for a while. I think his solutions are over complicated and rely on too much impenetrable technology to actually save me any time. The arguments have been made elsewhere, so I won't go into it that deeply, but I think departure from the "unix way" is folly and will only make administration more difficult.
As far as getting used to it goes; this is still unix. I can still install whatever initd I like after the fact. Which I do. Yes, this means I have to do more work than I would have to do if I relied on vendor packages, but we generally use custom packages for all our critical services anyways. Since we're going to have to deal with it whether or not we're using systemd, and we're already rolling out a non-standard initd to our distributions, we don't feel we have to make any investment in learning systemd.