systemd goes out of its way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault. And because of systemd, we're finally starting to get a level of integration that previously only appeared in proprietary operating systems.http://islinuxaboutchoice.com
So, basically you're advocating for a walled garden approach, then you link to a novelty domain that points to a Red Hat mailing list discussion where some person rants like a demagogue in a disjointed fashion that doesn't prove jack shit.
Quite impressive.
Linux is good at evolutionary changes, but not nearly as good at escaping local maxima via large-scale cross-project changes. Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames.
Or because Linux userland developers have historically been bad at cathedrals? The bazaar has always been more suited to the Linux community, and makes Linux distinct and refreshing compared to BSDs (which are an example of cathedral done right, by the way).
I've also found that well-articulated and well-founded arguments about problems in systemd don't tend to last long, because systemd will fix them. I'd encourage people who see a legitimate technical problem with systemd to go discuss it on the systemd mailing list; you might be surprised how quickly it gets fixed, if it has substance.
If the systemd team's insistence on not taking patches for alternative libcs, Lennart's circular argument on why you should adopt systemd because of systemd-logind being tightly coupled and hard to reimplement (https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...), the recent Kay Sievers controversy and other issues are anything to show, it is that the systemd team very much have their own convictions that are at odds with anyone else.
> So, basically you're advocating for a walled garden approach
You can get integration without a walled garden. There are no walls on the systemd garden; there's just a well-maintained garden that attracts an increasing number of people. You don't need walls to keep people in when you have sufficiently compelling technology that they want to stay.
And you didn't actually respond to anything in the mailing list post about "choice", other than its tone. There's a key point to be learned from that post: just because a alternatives exist doesn't mean they all have to be equally well supported by every Linux distribution. Linux distributions, as one of their primary functions, make choices for the user: they select a set of components and make those components work well together. systemd helps there, by providing a set of components that integrate quite well, and by getting rid of some of the zero-value differences between distributions (/etc/hostname versus /etc/HOSTNAME versus /etc/sysconfig/..., for instance).
> Or because Linux userland developers have historically been bad at cathedrals? The bazaar has always been more suited to the Linux community, and makes Linux distinct and refreshing compared to BSDs (which are an example of cathedral done right, by the way).
I actually agree with this, but I don't see how it's a response to what I said. Linux, in not using the cathedral method, has a hard time making major changes to escape local maxima, and when such changes do happen it's typically through the focused efforts of a small group dedicated to fixing a particular class of issues. For instance, the Linux kernel is a bazaar, but major new subsystems are not typically developed collaboratively from scratch, they're provided in a functional initial form and then evolved from there. And when it finally comes time to replace them, they're typically replaced as a unit rather than incrementally evolved.
And personally, I wouldn't mind seeing Linux distributions learn something about organization from the BSDs, not least of which by requiring that all packages appear in the same version control system side-by-side on the same server.
> If the systemd team's insistence on not taking patches for alternative libcs
systemd refuses to work around bugs in other software unless absolutely necessary; when that software is FOSS, it can be fixed rather than worked around. And systemd does have some patches to handle less capable libc implementations, such as definitions of system calls that libc implementations might not have. On the other hand, it seems quite reasonable to require functions like asprintf rather than reimplementing them, especially for an init system specifically designed for Linux.
> Lennart's circular argument on why you should adopt systemd because of systemd-logind being tightly coupled and hard to reimplement
logind needs cgroups. PID 1 needs to manage cgroups. There's a solution that works today, providing features that desktop environments need, for which alternatives do not yet exist. And if you're not a fan of that solution, there are people working right now to create an alternative solution using cgmanager.
> the recent Kay Sievers controversy
In which kernel developers ranted about a bug in systemd that had already been fixed before the discussion ever started, and proposed childish kernel patches like "if PID 1 is named systemd, panic()"...
> the systemd team very much have their own convictions that are at odds with anyone else
Per my previous comment: 'Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames.'
Yes, the systemd team is trying to make large-scale changes to the way Linux works. That necessarily puts them at odds with the way Linux currently works. That doesn't make them wrong: Linux is not yet perfect and could use further improvement. (It doesn't make them inherently right, either.)
There are no walls on the systemd garden; there's just a well-maintained garden that attracts an increasing number of people. You don't need walls to keep people in when you have sufficiently compelling technology that they want to stay.
The rationale for adopting systemd, is, I'm afraid more complex than simply "sufficiently compelling technology". It is the result of a variety of factors.
Just because a alternatives exist doesn't mean they all have to be equally well supported by every Linux distribution.
No one is saying that.
systemd helps there, by providing a set of components that integrate quite well, and by getting rid of some of the zero-value differences between distributions (/etc/hostname versus /etc/HOSTNAME versus /etc/sysconfig/..., for instance).
I have nothing against systemd's imposed standard configuration files, although ultimately they're not particularly meaningful (and thank heavens for that, I'm hoping it'll last...). /etc/hostname has been a Debian standard for years now that most other distros went to, even before systemd.
Linux, in not using the cathedral method, has a hard time making major changes to escape local maxima, and when such changes do happen it's typically through the focused efforts of a small group dedicated to fixing a particular class of issues.
The use of a bazaar is a good thing. It creates a decentralized system of autonomous channels. A community of thriving subcommunities, a marketplace of ideas where distribution maintainers are free to pick from a variety of flavors for their distros.
And personally, I wouldn't mind seeing Linux distributions learn something about organization from the BSDs, not least of which by requiring that all packages appear in the same version control system side-by-side on the same server.
So essentially you want a ports system? I have nothing against ports collections, but packaging models that involve strict separation of duties are not bad, either.
systemd refuses to work around bugs in other software unless absolutely necessary; when that software is FOSS, it can be fixed rather than worked around.
Yet evidently systemd cannot apply these same principles to itself.
logind needs cgroups. PID 1 needs to manage cgroups. There's a solution that works today, providing features that desktop environments need, for which alternatives do not yet exist. And if you're not a fan of that solution, there are people working right now to create an alternative solution using cgmanager.
It's good that alternative solutions are being made, but once again it's circular reasoning. You're using the premise to justify itself.
Yes, the systemd team is trying to make large-scale changes to the way Linux works. That necessarily puts them at odds with the way Linux currently works. That doesn't make them wrong: Linux is not yet perfect and could use further improvement. (It doesn't make them inherently right, either.)
And when you have such a huge undertaking in place, you don't just tell other people to "sit down and shut the fuck up". Finally, striving for perfection is a vapid sentiment. If this is what is considered "further improvement", then perhaps we need to rethink our needs entirely.
So, basically you're advocating for a walled garden approach, then you link to a novelty domain that points to a Red Hat mailing list discussion where some person rants like a demagogue in a disjointed fashion that doesn't prove jack shit.
Quite impressive.
Linux is good at evolutionary changes, but not nearly as good at escaping local maxima via large-scale cross-project changes. Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames.
Or because Linux userland developers have historically been bad at cathedrals? The bazaar has always been more suited to the Linux community, and makes Linux distinct and refreshing compared to BSDs (which are an example of cathedral done right, by the way).
I've also found that well-articulated and well-founded arguments about problems in systemd don't tend to last long, because systemd will fix them. I'd encourage people who see a legitimate technical problem with systemd to go discuss it on the systemd mailing list; you might be surprised how quickly it gets fixed, if it has substance.
If the systemd team's insistence on not taking patches for alternative libcs, Lennart's circular argument on why you should adopt systemd because of systemd-logind being tightly coupled and hard to reimplement (https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...), the recent Kay Sievers controversy and other issues are anything to show, it is that the systemd team very much have their own convictions that are at odds with anyone else.