3 ms·

LOL I'm older and have 35 years of experience in the technology. Doesn't mean for one hot second I think I can just puff my chest up about a topic and blow peo

by kator 9y ago

LOL I'm older and have 35 years of experience in the technology. 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.

Fnoord 9y ago
Glad to read there's people with such long experience who still have an open mind and are willing to unlearn and relearn. It isn't easy as you age to keep that spirit alive. 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.
yourapostasy 9y ago
> 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". 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-the-security-implications-of-systemd-compared-to-systemv-init https://security.stackexchange.com/questions/167721/what-are...

by kator 9y ago

Fnoord 9y ago

Glad to read there's people with such long experience who still have an open mind and are willing to unlearn and relearn. It isn't easy as you age to keep that spirit alive. 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.

yourapostasy 9y ago

> 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". 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-the-security-implications-of-systemd-compared-to-systemv-init https://security.stackexchange.com/questions/167721/what-are...