top | item 7639534

(no title)

hellerbarde | 12 years ago

I understand what you mean. I had the same awe when I first started on Arch and really got to know all the bits and pieces. When I transitioned to systemd, I had to go through that again. It was actually very similar to what I did the first time around and I suggest you give it a shot too. systemd, while seemingly monolithic is actually a really cool suite of tools. The thing we need to keep in mind is that it's _not_ sysvinit, and it's not trying to be. It's trying to be a project that does more than that and does it transparently on all systems. You might like it :)

As a general point for everyone: Just because it's _also_ an init system doesn't mean it's not allowed to provide the binaries for doing a whole lot of other stuff. :)

discuss

order

vertex-four|12 years ago

The problem is that it's a suite of tools that are all developed under the same umbrella, by the same people, with the same ideas, and the same gatekeepers. It's rather difficult to fully replace parts of it, especially as the formal API to it is defined by systemd, and we're seeing more and more tools integrate with all that.

Why can't we have an independent organisation that defines a spec for all the relevant APIs and tools for managing a system, and systemd just be one implementation of that spec? Actually, it could be a suite of specs, so people could pick and choose which ones solve their problems, and build alternatives for others.

hellerbarde|12 years ago

Hmmm... I pondered this for a bit, and I arrived here:

> [...] by the same people, with the same ideas, and the same gatekeepers [...]

Isn't this exactly what made the Linux Kernel great? A consistent vision.

I agree with you on a few points though, the systemd team should be more cooperative and start being conservative on the API changes. If the API is defined clearly, it shouldn't be hard to make proper replacements for parts of it.

I disagree strongly that there should be an independent Organisation to define that spec, because that would quickly be overrun by bikeshedding and all the other problems stemming from design by comittee. Very often in the Open Source world, specs have been defined by the first people arriving at the scene, so to speak. It all works over dbus, no? That is a fairly simple protocol to implement. I think it's an elegant IPC solution.

Anyway. cheers!