On Sun, 17 Jan 2016 15:19:43 +0100, Tom H <tomh0...@gmail.com> wrote: >Johann (I can't think of the other "fanboi" to whom you're referring) >has argued in the past for the removal of rc.local and sysvinit >compatibility.
People like him should be silenced on development mailing lists. They don't care about the common sysadmin at all. >Let's assume that Lennart removes support for them as >well as for "EnvironmentFile=", will it really be something that'll be >worth getting upset about? It is worth getting upset when people try to "educate" me in a field that doesn't need educating. It just triggers childhood aversions, and I am surely not the only one. >For EnvironmentFile, does it really matter whether you edit a file >under "/etc/default/" or under "/etc/systemd/system/"? As I said >up-thread, I'm wouldn't like setting up nfs without "EnvironmentFile=" >but it's something that'll just take a little longer initially, >whether I'm using config management or not. And then it'll be the >same, since I only change these files at setup. Being forced to change things as a systadmin just for the sake of change is always bad. People not caring about backwards compatibility do not care about their users. "Gut feeling" is an important instrument in the seasoned sysadmin's life, and when the gut feeling says "this should be a variable here" and you can't do it because the darn system doesn't support variables, it leaves you with a bad feeling. And I don't want to have bad feelings during my work. It's not only my work, it's my passion. And it hurts to have it made worse by people not caring about my passion. This is the case for systemd, and, sadly, has become the case for Debian in the last year or so. >For rc.local, does it really matter whether you edit "/etc/rc.local" >or a file under "/etc/systemd/system/"? It matters if I have had rc.local on hundreds of systems for decades and now need to change every one of them. I don't care so much how configuration works in new installs (where I only need to change the installation automatism), but if rc.local has been ticking away in existing installs without the need for configuration management, this change is unnecessary and means to have implementation and testing and rollout and change management, which can easily amount to at least half a work day even on a single big installation. > Personally, even if I've used >rc.local when in a hurry, I've always made a point of creating a >sysvinit script, upstart job, or systemd service unit later. Yes. rc.local is not something I care about. Removing the support for /etc/default files just for the sake of educating people to do things "right" and "in the correct systemd way" is outright evil. >There's residual anger at systemd because it more or less snookered >distros and users into adopting it, ... and now uses its leverage to force people into doing things their way by slowly removing compatibility features. This is rearing its ugly head, destroys trust and makes me feel that systemd should be forked as soon as possible so that removed features can be patched in again. But I fear that systemd upsteam will promptly engage into "educating" the people who dared to fork about that it is a bad idea to fork systemd by starting needless refactoring in the code so that the compatibility patches in the forked code don't apply as nicely, thus causing lots of unnecessary work. How did we allow these people to gain this much power over us? Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834