At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size.
There are problems with that idea:
* Red Hat is backing Systemd and this is the only thing Lennart seems to work on. You'll be in the quagmire of always trying to catch up on new shitty features and broken compatibility. * Systemd was 250K+ LoC last I checked * Systemd's source code is poorly documented at best. * Systemd has a overly clever design that makes it difficult to grok.
I'm not saying that Systemd shouldn't be replaced, I'm saying that you need to discard the original.
by Anonymous Coward writes:
on Monday July 03, 2017 @06:42AM (#54733623)
It's worse than that. The community didn't have any say in it, it just got rammed down everyones throats; its revealed that linux has started to follow the cathedral model as vendors like Redhat gain more and more exclusive control over it. At this point its worth asking who controls linux, the community built out of tends of thousands of projects that come together, or a few corporate entities?
At this point its worth asking who controls linux, the community built out of tends of thousands of projects that come together, or a few corporate entities?
For a while now, the corps. Whoever is paying the salaries of developers is in control. Look at the concept of budgeting. Its not necessarily about how to wisely spend money, its also about control. Control by determining how much in the way of resources get allocated to some idea. To prioritize idea. To ensure that work is following the plan developed by senior management, not some plan developed by a consensus of engineers.
Didn't some analysis of commits a while back show most Linux development is corp
The problem with systemd (Score:5, Insightful)
That's a problem with Systemd. It's a pretty decent idea with a sub-par execution and a crappy way of dealing with an inherent problem.
Idea: centralized place to optimize startup, management and interconnectivity of all kinds of services.
Problem: some services in their standard form don't quite fit that model.
Solution: let's rewrite them and include as parts of systemd.
The crap part: while the originals were made by experts in that field, the replacements are made by a group of wannabe experts on everything
Re: (Score:5, Informative)
At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size.
There are problems with that idea:
* Red Hat is backing Systemd and this is the only thing Lennart seems to work on. You'll be in the quagmire of always trying to catch up on new shitty features and broken compatibility.
* Systemd was 250K+ LoC last I checked
* Systemd's source code is poorly documented at best.
* Systemd has a overly clever design that makes it difficult to grok.
I'm not saying that Systemd shouldn't be replaced, I'm saying that you need to discard the original.
Re: (Score:2)
So the product is open source but not open spec.
Re: The problem with systemd (Score:5, Interesting)
It's worse than that. The community didn't have any say in it, it just got rammed down everyones throats; its revealed that linux has started to follow the cathedral model as vendors like Redhat gain more and more exclusive control over it. At this point its worth asking who controls linux, the community built out of tends of thousands of projects that come together, or a few corporate entities?
Corps control Linux, not hobbyists (Score:3)
At this point its worth asking who controls linux, the community built out of tends of thousands of projects that come together, or a few corporate entities?
For a while now, the corps. Whoever is paying the salaries of developers is in control. Look at the concept of budgeting. Its not necessarily about how to wisely spend money, its also about control. Control by determining how much in the way of resources get allocated to some idea. To prioritize idea. To ensure that work is following the plan developed by senior management, not some plan developed by a consensus of engineers.
Didn't some analysis of commits a while back show most Linux development is corp