...small sites, useless for production
written about 2 years ago
After seeing so many big distros switching to this *experiment* I'm getting scared.
Tonnes of bug reports, many unnoticed, most of them unfixed. This is not entirely upstream's fault, I know, but something so under-documented and unmaintainable as systemd cries for mis-configuration and mis-use.
Stuff that Just Worked[tm] before suddenly becomes a matter of I-have-to-keep-an-eye-on-that. Taking on tasks that are best left to expert systems (like why exactly is timedated part of systemd now?) is rarely a good idea. Pair that with sheer incompetence (I'm in no way calling ntp.org competent but at least they have an idea about the complexity of time keeping) and you will see how systemd is a failed experiment.
Sure, I can file bug reports for all the little nuisances, and I'm doing so, but it's a time consuming job that is especially hindered when you realised that you have twice the knowledge about this particular subject than the guy the bug report was assigned to.
Ok, I can also just not file a bug report if I get that impression and send patches to the upstream project directly but how with a code base like this? Is this a secret game of spot-the-comments or if-you-can't-figure-out-how-this-works-you-suck.
Anyway back to my original rant, systemd is obviously designed to create problems where there have been no problems before. A big example of NIH syndrome, not even upstart caused so much trouble after a short test run.
It is unfortunate that, as a *user* and risk manager for my company, I have to wave goodbye to opensuse and recommend debian for new installations. On the other hand, as a coder and script kiddie, I welcome this new playground. LOOOOADS of work to be done and hence a GREAT chance of getting commits in :)
1 out of 4 users found the following review helpful.
Did this review help you?