Poettering: The Biggest Myths
Posted Jan 30, 2013 17:12 UTC (Wed) by rgmoore
(✭ supporter ✭
In reply to: Poettering: The Biggest Myths
Parent article: Poettering: The Biggest Myths
On the concern side, I worry about the extra time it's going to take to debug issues in large chunks of compiled code v. script
This seems like a misplaced worry to me. Consider your example of the perl scripts you debugged. You assumed correctly that any performance problems would be in the scripts rather than the compiled code (i.e. Perl itself). That's a reasonable assumption because your scripts were something you apparently put together in house, so it hadn't had much performance debugging effort. In contrast, Perl is used by millions of people all over the world, and any critical performance issues in it would have been noticed long before you got there. The same thing is true of the shell and standard shell functions when you're writing scripts in sh; you assume that the compiled code has been thoroughly debugged and had its performance problems worked out, so any residual problem must be in your script.
I would argue that systemd is going to be much closer to Perl, bash, etc. than it is to your hand-rolled monitoring scripts. Systemd is going to be doing performance critical tasks on tens or hundreds of millions of machines, so any critical problems are going to be found and fixed quickly. The equivalents of your scripts will be the systemd unit files, which can be much simpler and easier to debug than traditional scripts because they don't require a lot of implementation details.
to post comments)