5 ms·

> Red Hat creating huge mess throughout linux with systemd for years Care to elaborate on the 'mess' created? I highly doubt you even used it yourself, sounds

> Red Hat creating huge mess throughout linux with systemd for years Care to elaborate on the 'mess' created? I highly doubt you even used it yourself, sounds like something you've heard and are repeating for some cheap karma. The init scripts used before were the real mess, if you ask me. It's getting really tiring to hear these systemd rants with no good reasons to back them up. I guess ranting against systemd is the cool thing to do, just like calling Apple users sheep once was, there's no need for facts, just hyperbole.

holydude 9y ago
Systemd is / was inspired by solaris smf to some extent. It is not that bad but the execution was rather poor.
- JdeBP 9y ago
  Actually, it was SystemXVI that was inspired by the SMF. * https://github.com/ServiceManager/ServiceManager/ https://github.com/ServiceManager/ServiceManager/ (https://news.ycombinator.com/item?id=10212770 https://news.ycombinator.com/item?id=10212770)
deleted 9y ago
[deleted]
binaryapparatus 9y ago
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.
- enraged_camel 9y ago
  Maybe you could explain it for us mere mortals.
  - AnonymousPlanet 9y ago
    I think what he is alluding to are basically two things: experience with software design (how to avoid overengineering to make maintenance and debugging easier) and experience wrt. dealing with dependent projects. The systemd team's track record on both has been quite abysmal.
  - binaryapparatus 9y ago
    As AnonymousPlanet said, scope of systemd and number of bad decisions (or good decisions with horrible implementation) is way too big to discuss here. Linux is no longer secure or reliable system it used to be. Engineering results and outcomes are bad from just about any angle you can take. 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.
    - mtmail 9y ago
      > is way too big to discuss here. 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'.
      - binaryapparatus 9y ago
        Downvotes are really interesting in a sense they provide me with perspective that some people don't even read what is the main point I am making. Systemd discussion is data point, not the main point for me. 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.
- Fnoord 9y ago
  You couldn't care less about karma? If you're downvoted it is because your post is downright rude, and full with fallacies: argumentum ad verecundiam (stating your irrelevant age and experience, stating you lived before the internet existed), argumentum ad hominem (calling a random person on the internet whom you don't know a kid), non sequitur (none of what you wrote directly supports your claim). 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.
  - llukas 9y ago
    > 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.
    - posguy 9y ago
      At what point did OP focus on boot speed? Systemd has a bundle of other useful properties, like simple unit files and handling the entire boot process. 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!
- AsyncAwait 9y ago
  > I've been here before internet existed. You better believe I know what I am talking about. 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.
- 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...
thg 9y ago
Not the OP. While systemd isn't all bad and in some ways for sure an improvement over init (not that that is hard), there are also very questionable architectural decisions that have been made in systemd. Next up you have the attitude of the two lead developers, Lennart Poettering and Kay Sievers and the way they handle community interaction and bug reports. If it doesn't fit into their rather limited view of how you should use your system and you break it, it's most likely not a bug they're going to bother fixing. https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Last but not least, systemd is forcefully being pushed down our throats. Not with well-reasoned technical arguments, but with mostly emotional arguments about what they think is best for everyone. And since more and more of independent functionality is being integrated into and replaced by systemd, it becomes constantly more tedious to maintain software without hooking also into systemd.
JdeBP 9y ago
It's probably equally as tiring for the people reading this to see you drag up the old false dichotomy of "init scripts used before". The world was not van Smoorenburg rc before systemd came along. (This especially ironic given that we are on a page discussing Solaris, for goodness sake!) If you want other people to try avoiding tired old fallacies, set a good example and avoid them yourself too. * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

holydude 9y ago

Systemd is / was inspired by solaris smf to some extent. It is not that bad but the execution was rather poor.

JdeBP 9y ago
Actually, it was SystemXVI that was inspired by the SMF. * https://github.com/ServiceManager/ServiceManager/ https://github.com/ServiceManager/ServiceManager/ (https://news.ycombinator.com/item?id=10212770 https://news.ycombinator.com/item?id=10212770)

deleted 9y ago

[deleted]

binaryapparatus 9y ago

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.

enraged_camel 9y ago
Maybe you could explain it for us mere mortals.
- AnonymousPlanet 9y ago
  I think what he is alluding to are basically two things: experience with software design (how to avoid overengineering to make maintenance and debugging easier) and experience wrt. dealing with dependent projects. The systemd team's track record on both has been quite abysmal.
- binaryapparatus 9y ago
  As AnonymousPlanet said, scope of systemd and number of bad decisions (or good decisions with horrible implementation) is way too big to discuss here. Linux is no longer secure or reliable system it used to be. Engineering results and outcomes are bad from just about any angle you can take. 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.
  - mtmail 9y ago
    > is way too big to discuss here. 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'.
    - binaryapparatus 9y ago
      Downvotes are really interesting in a sense they provide me with perspective that some people don't even read what is the main point I am making. Systemd discussion is data point, not the main point for me. 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.
Fnoord 9y ago
You couldn't care less about karma? If you're downvoted it is because your post is downright rude, and full with fallacies: argumentum ad verecundiam (stating your irrelevant age and experience, stating you lived before the internet existed), argumentum ad hominem (calling a random person on the internet whom you don't know a kid), non sequitur (none of what you wrote directly supports your claim). 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.
- llukas 9y ago
  > 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.
  - posguy 9y ago
    At what point did OP focus on boot speed? Systemd has a bundle of other useful properties, like simple unit files and handling the entire boot process. 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!
AsyncAwait 9y ago
> I've been here before internet existed. You better believe I know what I am talking about. 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.
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...

thg 9y ago

Not the OP. While systemd isn't all bad and in some ways for sure an improvement over init (not that that is hard), there are also very questionable architectural decisions that have been made in systemd. Next up you have the attitude of the two lead developers, Lennart Poettering and Kay Sievers and the way they handle community interaction and bug reports. If it doesn't fit into their rather limited view of how you should use your system and you break it, it's most likely not a bug they're going to bother fixing. https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Last but not least, systemd is forcefully being pushed down our throats. Not with well-reasoned technical arguments, but with mostly emotional arguments about what they think is best for everyone. And since more and more of independent functionality is being integrated into and replaced by systemd, it becomes constantly more tedious to maintain software without hooking also into systemd.

JdeBP 9y ago

It's probably equally as tiring for the people reading this to see you drag up the old false dichotomy of "init scripts used before". The world was not van Smoorenburg rc before systemd came along. (This especially ironic given that we are on a page discussing Solaris, for goodness sake!) If you want other people to try avoiding tired old fallacies, set a good example and avoid them yourself too. * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/