4 ms·

Counting empty lines and comments is hardly the way to make your point. The mariadb unit file you linked to is only 34 actual lines, the mysql unit file only 22

by vacri 10y ago

Counting empty lines and comments is hardly the way to make your point. The mariadb unit file you linked to is only 34 actual lines, the mysql unit file only 22, percona 23. And if you're writing your own unit files rather than ones for public consumption, you probably won't include lines like "Documentation=" and some other minor args.

JdeBP 10y ago
Actually, counting lines, whether empty, comment, or otherwise, very much is the way to make the point. The reality of actual service units that people write is not anything like the picture that was being painted. You erroneously think that the point is that short is good and long is bad, rather than what it actually is, which is learn the subject and don't make facile arguments based upon rubbish numbers plucked from thin air. Actually looking at reality and counting, rather than pulling the number 7 from a hat, is part of that point. I recommend reading the design of the Mewburn rc system, http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-side.html http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... , and some of the entries in the systemd House of Horror. This whole "It's just writing 7 lines and it's easy!" argument falls apart when one looks at the reality of short service units that are either grossly wrong or turn out to be underpinned by the very things that their lengths are being compared to (which also means that it is still those rc scripts that are being used and maintained by software authors -- from 1997 in the example of apachectl), real world service units that are not short, other systems of long standing that are equally concise, and -- yes -- the reality that people include commentary for maintainability. One of the amusing things about this argument that is of particular relevance to the Devuan release is that back when Devuan was announced someone put up a "fork Fedora" WWW page criticizing the Devuan people, with a systemd service unit side by side with a van Smoorenburg rc script. It is sad to note that few people observed that the systemd unit described just one service, whereas the van Smoorenburg rc script ran two. Since you are on the subject of commentary, I invite you to observe which of the twain included comments and which did not, as well, and determine what point the "fork Fedora" people were in fact demonstrating. (-:
- mdekkers 10y ago
  Thank you for putting this argument across so succinctly and with such good research behind it. Everytime I hear the arguments in favor of systemd, I wonder when these people actually come down from their ivory towers to do some real life work, where the rubber meets the road. The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle? systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window. The systemd people should be made to work building and maintaining a real-life backend environment for a while.

by vacri 10y ago

JdeBP 10y ago

Actually, counting lines, whether empty, comment, or otherwise, very much is the way to make the point. The reality of actual service units that people write is not anything like the picture that was being painted. You erroneously think that the point is that short is good and long is bad, rather than what it actually is, which is learn the subject and don't make facile arguments based upon rubbish numbers plucked from thin air. Actually looking at reality and counting, rather than pulling the number 7 from a hat, is part of that point. I recommend reading the design of the Mewburn rc system, http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-side.html http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... , and some of the entries in the systemd House of Horror. This whole "It's just writing 7 lines and it's easy!" argument falls apart when one looks at the reality of short service units that are either grossly wrong or turn out to be underpinned by the very things that their lengths are being compared to (which also means that it is still those rc scripts that are being used and maintained by software authors -- from 1997 in the example of apachectl), real world service units that are not short, other systems of long standing that are equally concise, and -- yes -- the reality that people include commentary for maintainability. One of the amusing things about this argument that is of particular relevance to the Devuan release is that back when Devuan was announced someone put up a "fork Fedora" WWW page criticizing the Devuan people, with a systemd service unit side by side with a van Smoorenburg rc script. It is sad to note that few people observed that the systemd unit described just one service, whereas the van Smoorenburg rc script ran two. Since you are on the subject of commentary, I invite you to observe which of the twain included comments and which did not, as well, and determine what point the "fork Fedora" people were in fact demonstrating. (-:

mdekkers 10y ago
Thank you for putting this argument across so succinctly and with such good research behind it. Everytime I hear the arguments in favor of systemd, I wonder when these people actually come down from their ivory towers to do some real life work, where the rubber meets the road. The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle? systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window. The systemd people should be made to work building and maintaining a real-life backend environment for a while.