I am 46 years old, with over 25 years of programming and system administration experience. I've been here before internet existed. You better believe I know what I am talking about.
I couldn't care less about karma kid.
I couldn't care less about karma kid.
My explanation about the systemd hate is that it isn't for technical reasons; its cultural ones. Specifically, people dislike change. Especially older people don't want to relearn fundaments which have been reliably stable throughout the years. Young people, OTOH, lack that connection and are more open to change provided they agree with the rationale.
Nice way of saying that young people need to redo errors of the old.
As for systemd - I'd wouldn't mind if it was executed properly. Booting speed is worst argument you can do for systemd - with ubiquitous SSD it doesn't really matter.
If you do want to talk boot speed, compare a sysv install versus a systemd install on an 850 Pro. There are a notable few seconds of difference!
Doesn't mean for one hot second I think I can just puff my chest up about a topic and blow people off when they ask a perfectly good question.
For me the jury is still out on systemd. My biggest concern is it seems to be slowly taking over everything and thus violating the core unix philosophy of "do one thing really well". It feels like systemd was started to "improve startup times" for desktop users so they'd be happy. Meanwhile servers were sort of forgotten about and many of the complexities added by systemd make getting things done harder for day-to-day system admins. I've made some unit's myself and I like the many options I have but honestly it's not a daily job. Writing three lines of bash in /etc/init.d was way quicker and easier to rationalize about in the heat of "getting shit done".
All this said I have been using systemd on my machines for a while now, at first I would back it out the second I created a new install image but now I'm trying hard to learn it and understand.
Again... the Jury is still out in my mind.
The unix core philosophy of "do one thing really well" is such a cliche though. "Do one thing really well", yet using a monolithic kernel (Linux, Solaris, *BSD). Microkernels like OpenVMS and GNU Hurd allow one to restart (including hot patching) a part of the kernel. The same is true for running something like Qubes. Apart from the kernel debate there's tons of monolithic software. Software statically linked on a commercial UNIX? You bet. Plus you use a full-blown DE, a web browser, Emacs. Vi? Sure, Vi. Yet people use Vim with all kind of plugins.
The larger attack surface, reduced "git 'r done"'ess when you're in the midst of a hot outage, and increased complexity to trace what happens give me concerns. Some touched upon in this StackExchange [1] conversation thread, but lots of good threads elsewhere on the Net along these and other lines. Personally, I'd rather see the entire idea of "booting" be looked at again.
The reason sysadmins value the "git 'r done" aspect of System V init is because servers are not booted frequently. But init scripts are changed more frequently than servers are booted, and business application teams forbid booting the server more than utterly, absolutely, necessary; and the sysadmins wanting to boot to test a modification to the init script doesn't count. Dev/QA/Pre-prod change control environments help, devops-based source control discipline helps, but the next time a server is booted is always at least a "sideways-glancing-to-see-what-breaks" moment for many a sysadmin. When the startup sequence breaks somewhere, it becomes a hot outage, and especially if correcting it requires application-specific domain expertise, outside the OS. In the middle of such a hot outage, the ability to get closer to the problem domain within the shell script is appreciated. Systemd's init compatibility indirection layer helps, and hopefully, some thought in the future is given to streamlining this layer.
The entire notion of "booting" has rubbed me the wrong way for an increasing amount of time, though. Microkernels tried to address this, but they never caught on. Solaris and AIX try to address this, and Linux is exploring this, with their live kernel migration features, but they don't really do much to help higher up the stack. The best I can do to mitigate this itch for the time being is highly-available three-node clusters, and regularly moving the application to one of the opposite nodes, booting the inactive node, and testing changes to that boot, and the aforementioned devops-orientation and source control. Having an OS that lets me "re-home" a running application Tandem-Kernel-like/VMWare-Live-Migration-like, to a newly-"booted" state of the OS though, would be the bees' knees.
[1] https://security.stackexchange.com/questions/167721/what-are...
So all you have is using your age as an appeal to authority? Pretty sad. All that's telling me is that you're used to doing things a certain way and are now upset that your knowledge is being uprooted and you need to learn something new. Otherwise you'll use facts instead of insults to push your argument.
If you belong to the silent but great majority (lol) of users that enjoy and cherish systemd -- just carry on by all means.
If anything there is A LOT of aggression any time somebody says anything 'unwelcome' about systemd.
Can you point to an article or blog post pointing out the bad decisions?
> If anything there is A LOT of aggression any time somebody says anything 'unwelcome' about systemd.
The downvotes came when you stated your age, "believe I know what I am talking about" instead of listing arguments and calling the parent poster 'kid'.
Parent poster did clearly state I am making it all up and that I have zero experience with systemd. Cultural differences? English is not my main language but I prefer clearly stating what is what, not really skilled in underhand 'polite' underhand attack. 'Politely' saying you are lying = fine, responding that I may be too ancient or experienced to even be able to explain all the falacies = bad. Gotcha.
Cliche but I am pointing at the moon and people are yelling at the finger. So be it.