4 ms·
I think the systemd complaints really boil down to two very real problems: 1. The authors of systemd aren't dealing with criticism well. They've allowed it to
by steventhedev 12y ago
I think the systemd complaints really boil down to two very real problems:
1. The authors of systemd aren't dealing with criticism well. They've allowed it to turn into a PR nightmare. Agree or disagree with them on specific issues, but they've allowed this to grow out of hand. There are nearly daily popular posts on HN, Reddit, etc. Most of these are bikeshed arguments, but if you have so many bikesheds that it becomes a daily issue on news aggregators, then you have yourself a culture problem.
2. Perhaps as a result of the above, there haven't been any limitations of the scope of systemd. This means that there is a lot of feature creep as stuff gets added in, and criticism gets swept away without considering it.
Unfortunately, I don't see an easy way to fix the culture problem. But it needs to be addressed.
EDIT: formatting
- click170 12y agoPosts like yours are one of the first steps. At this point we need to address the culture problem and the people contributing to it instead of focusing on the distracting fallout. I've tried to keep an open mind about all things systemd but after finally reading some of the exchanges people have with the systemd folks, I'm surprised systemd isn't more widely rejected as a viable alternative simply because of the attitude of some of the people currently maintaining it. You can't be an butthole to folks trying to offer valid criticisms and expect those same people take your project seriously. That just does not inspire confidence, it inspires skepticism and distrust. I wonder if it's simply a critical mass problem, if once enough devs get peeved they will fork systemd and lead it the way they see fit sans any caustic contributions or contributors.
- Cyther606 12y agoIt has been forked [1]. > uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design He could use better marketing, but I think removing the kitchen sink aspect of systemd and keeping the service file syntax is a step in the right direction. [1] http://uselessd.darknedgy.net http://uselessd.darknedgy.net