15 ms·
Being a developer and being an admin are completely different jobs. A admin needs to know a dozen languages and codes in bash most of the time, they have a han
by monochr 12y ago
Being a developer and being an admin are completely different jobs.
A admin needs to know a dozen languages and codes in bash most of the time, they have a hand written folder with glued in scraps next to their terminal which explains why they did what, how and why. This folder has entries like "reboot three times, do an rain dance and run godHelpYou.bash as root" because that's the only way that you've found out how the libraries actually talk to each other.
For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system.
From this point of view devs look like a tribe of monkeys building a shit pyramid over your village. They just keep flinging more shit at the top thinking they are the greatest ever monkeys. When the shit pyramid collapses and buries everything you know and love under a few meters of shit, probably killing someone in the process, these monkeys just shrug say a few words about how that was the best shit pyramid anyone had ever build and start making a new one one or two valleys over.
- andor 12y agoFor people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system. For the developers, on the other hand, it might mean that some use case that is important for the admin is simply not yet implemented. The solution, as so often, is... drumroll to report a bug! Developers care about their users. Just talk to them. Also, admins should realize that "reducing complexity" is a goal that they share with the developers. systemd is all about reducing complexity by implementing functionality the right way, on the right layer. For example, with systemd it's way easier to write a daemon, because it takes care of * daemonizing: just stay in foreground * logging: just output to stdout/stderr. journald will collect everything, and if you want, forward it to a classic syslog service * startup: no more shell scripts required, just a simple service file * supervision: just add "Restart=on-failure" to your service file. It also supports software watchdogs.
- monochr 12y agoDifferent people have different definitions of complexity. For me having a single point of failure is complexity, for most people a centralized single process handling as much as possible is simplicity. Neither is right or wrong.
- icebraining 12y agosystemd is not implemented as a single process.
- bza 12y agoWhether a system is tightly coupled is independent of whether it's implemented as a single process. Objections to systemd as monolithic, as constituting a single point of failure, etc. are based on its being a tightly coupled set of components.
- icebraining 12y agoThat systemd is tightly coupled is a valid objection, but "single process" has a specific meaning in this context and it implies a much worse design, with every component potentially taking down PID1. As far as I know, this is not the case in systemd.
- wbl 12y agoAnd what happens when that single file doesn't work? The one time I had to deploy a custom service using systemd, there was no feedback as to why it wasn't working with service start. No error message, no guidance on how to debug online, no indication of where to look. By contrast adding it to a shell script just worked.
- pas 12y agoYou can strace pid1 too. If start-via-systemd doesn't work, hack around it with a script and report it as a bug or write to the mailing list.