5 ms·

As a former hater of systemd it surprises me that people still have this disdain of systemd especially due to the so called "Unix philosophy", which in the Linu

by 0dayz 11mo ago

As a former hater of systemd it surprises me that people still have this disdain of systemd especially due to the so called "Unix philosophy", which in the Linux world mainly survives due to GNU writing GNUtils a rewriting of the Unix commands. I remember embracing systemd funny enough due to when I was running alpine as my server and I had to write my own r script and boy did that quickly make me remember the awful times on freebsd debugging sh.

general1465 11mo ago
Same for me, I remember trying to configure cron to run a task periodically and it just did not budge. No error but also did not work. Systemd was working on first attempt with basic debugging when timer will be triggered again and what is the log of executed process after it has been triggered. Also manually triggering something to test if command is correct? Awesome.
- shevy-java 11mo ago
  That seems to me a complaint about cron. I always used ruby to schedule tasks instead. One does not need cron or systemd for scheduling tasks.
  - jraph 11mo ago
    What tool do you use to schedule tasks? Have you written your own Cron in Ruby?
  - KetoManx64 11mo ago
    How would I best schedule a task across a couple dozen Linux servers using ansible without cron or systemd timers?
- imiric 11mo ago
  This is precisely why it is valid to say that systemd doesn't align with the Unix philosophy, and yet it's also valid that many people such as yourself like it. I don't want my init system to replace cron. I don't want it to manage logging. I don't want it to have any debugging capabilities. All of these things can be done with other programs, arguably in a much more flexible and robust way. An init system should do one thing (well): manage system services. Within that context, it should start services on boot, keep them running in the background, and allow the user to create, stop, and start services. That's it. And it could be argued that even those responsibilities are too broad for a single program. So I understand that you and many others like that systemd provides solutions to all of these tasks in an integrated way. But you should also understand that this does in fact go against the Unix philosophy, of small, independent, but composable programs with a single responsibility. It "proposes" alternatives to many other tools for no particular reason, until users are effectively using GNU/systemd/Linux. And, yes, I know that technically systemd is not a monolith and is composed of many programs, but that is a moot point. It is a single project, maintained by a strongly opinionated team, and given the importance of it, most distros go all-in, so users are strongly recommended, if not forced, to use all of its programs. In many cases it's not even possible to use one individual systemd program idependently from another. This is why systemd is seen as a kraken that takes over the entire system if you do decide to use one part of it.
  - jraph 11mo ago
    > go against the Unix philosophy The Unix philosophy is not an end goal neither. It's not even something well defined. Everyone seems to have their own view on what it is. I personally take the "everything is a file" and "do one thing well and be composable" rules as a guideline, an ideal to consider when designing stuff, but not as a strict thing to adhere. It might be something that's nice to have in some contexts and something that's useless or even counter productive in others. What I mean is that I take "does not follow the Unix philosophy" as something to look into to find potential improvements or design issues, but not as blocker or a counterpoint in itself. To me, the Unix philosophy discussion is quite moot. Those discussions are often very vague. I don't care much that systemd follows the Unix philosophy or not. I'm more interested in what actual problems this does cause in practice. You do, however, point out something practical here: > An init system should do one thing (well): manage system services I suppose one could consider that to manage system services well, you have to manage "everything". I also suppose systemd's scope is way bigger than "managing services", they do want to "fix/figure it all". It seems reasonable to me not to agree with any of these things. I do believe the uniformisation systemd causes is a good thing, but I absolutely understand that the big scope can be seen as an issue, and I almost fully agree with your last paragraph. I would object to the statement that systemd is not a monolith and is composed of many programs is a moot point: this modularity still means that you can replace individual systemd programs with your own implementations if needs be… … as long as you provide the expected features / APIs, yes, you are totally forced into this indeed. systemd is a de facto API. It brings / forces standardization at the cost of diversity. It broadens the standardization that comes with UNIX/POSIX and XDG. I'm sure this can be criticized in a few ways: the API design, the scope, the featureset, the way the project is lead… The alternative to systemd is non-existent standardization and each alternative designs stuff its own way on their side. For the better and for the worse. I can see how systemd can be criticized for when we are in "the better" cases. I personally easily see the worse side where several projects (for instance desktop environments) would each have to implement features that come with systemd. And programs on top of these environments now have to implement APIs of each desktop environment to be well integrated. This is more work for everyone. I guess this is a diversity vs efficiency balance to strike and we don't all see it at the same place. I suppose another alternative would be to have different people working on different implementations that are then grouped in some common "system core" package or set of standards that everyone adopts. I'd probably be happy with that, if this is at all possible.
shevy-java 11mo ago
This shows a lack of understanding. I'll skip repeating the issues with regard to systemd here, so instead on just a few points you mentioned. - You claim that the Unix philosophy only survives to the GNUtils. Well, that shows to me a lack of understanding what the philosophy is about. Everything is a file is similar to the OOP approach of everything is an object. I recommend watching Ken Thompson when he was young here: https://www.youtube.com/watch?v=tc4ROCJYbm0 https://www.youtube.com/watch?v=tc4ROCJYbm0 It does not capture all the UNIX philosophy but it does extend on the reasons why that philosophy works well. The philosophy is bigger than that of course but it helps serve as a counter-argument. - The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd? You mention as example FreeBSD debugging a shell script. Well, others use proper languages such as ruby or python. Everything that can be done via systemd I can do without it too and, in fact, have been doing so. Ruby essentially runs my system as the primary layer on everything (granted, it runs Linux, and thus mostly C, and ruby is at the end of the day a syntactic wrapper over C). I never understood why systemd would matter. I read the advertisement of the systemd devs - none of this applied to my use cases, so I never "embraced" systemd, simply because I never needed it. I did point out the increased complexity of it as a negative trade-off and this has been true til this day. - Former "hater" also implies that criticism is not based on rationale and logic. This is not the case either. It's funny to me how the pro-systemd camp isn't really able to come up with compelling arguments on their own.
- jraph 11mo ago
  > This shows a lack of understanding. I would say your comment either shows a lack of understanding, or that you completely missed the point. > The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd? Of course, you can write the service itself in Python or Ruby or whatever regardless the service manager. The point is that with systemd, or upstart, or other service managers like this that make things more declarative (launchd?), you don't have to write a script to manage the service at all. On systemd, you declare which services yours depend on, how to run it, which user should be used to run your service, and many things are handled for you, including many security mechanisms you don't need to think about and provide further config for this stuff that would be a mess to handle with the traditional way of writing a custom rc script per service. The problem is not being able to write in languages like ruby or python. It's to have to write something at all. systemd makes many things declarative that were historically procedural, potentially painful to debug, code. This eases distro maintenance and I suppose is one of the top reasons most distros adopted it. wrt the Unix philosophy, discussions about it related to systemd are often (always?) too abstract to be useful, I'd suggest talking about specific problematic points.
windward 11mo ago
It's funny how many people fall in love with the Unix philosophy because they enjoy using an OS with a macrokernel that ships with awk, tar, and find, which they operate with useless uses of cat.
- hagbard_c 11mo ago
  Macrokernel or microkernel or a grain of salt, whatever kernel you use does not matter when it comes to seeing the advantages of 'the *nix philosophy'. As to the 'useless uses of cat' these often make the pipe easier to grasp because the first step is always the same: cat something|filter step 1|filter step 2|filter step 3 instead of filter step 1 something|filter step 2|filter step 3 especially when confronted with filters which need their input to be fed in different ways filter step 1 < something filter step 1 -i something filter something step 1 cat something|filter step 1 It may be less 'pure' to use cat as the first step in a pipe but who cares?
  - windward 11mo ago
    Oh I don't care: I do it all the time when I compose cli commands. But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file? I think it's a good example of when it's worth straying from the philosophy.
    - hagbard_c 11mo ago
      > But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file? Yes, it 'prints' the file to stdout which is consumed by the pipe and turned into the input for the next command in the pipeline. It doesn't matter whether you're only 'printing' a single file or a bunch of them.
      - windward 11mo ago
        And it numbers empty lines (-b) and non-empty lines (-n) and the end of lines (-E) and elides empty lines (-s) and search-and-replaces tabs (-T) and nonprinting characters (-v)
pjmlp 11mo ago
A philosophy that GNU doesn't follow even, those haters would be having a fun time with AT&T UNIX System 6 command line experience.
tsoukase 11mo ago
Forget Unix philosophy. The Linux philosophy suggests the monolithic kernel and, therefore, monolithic userland. Systemd fits perfectly, was pushed more or less openly by Linus himself and won. In Linux we don't want a million scripts but large binaries.

by 0dayz 11mo ago

general1465 11mo ago

Same for me, I remember trying to configure cron to run a task periodically and it just did not budge. No error but also did not work. Systemd was working on first attempt with basic debugging when timer will be triggered again and what is the log of executed process after it has been triggered. Also manually triggering something to test if command is correct? Awesome.

shevy-java 11mo ago
That seems to me a complaint about cron. I always used ruby to schedule tasks instead. One does not need cron or systemd for scheduling tasks.
- jraph 11mo ago
  What tool do you use to schedule tasks? Have you written your own Cron in Ruby?
- KetoManx64 11mo ago
  How would I best schedule a task across a couple dozen Linux servers using ansible without cron or systemd timers?
imiric 11mo ago
This is precisely why it is valid to say that systemd doesn't align with the Unix philosophy, and yet it's also valid that many people such as yourself like it. I don't want my init system to replace cron. I don't want it to manage logging. I don't want it to have any debugging capabilities. All of these things can be done with other programs, arguably in a much more flexible and robust way. An init system should do one thing (well): manage system services. Within that context, it should start services on boot, keep them running in the background, and allow the user to create, stop, and start services. That's it. And it could be argued that even those responsibilities are too broad for a single program. So I understand that you and many others like that systemd provides solutions to all of these tasks in an integrated way. But you should also understand that this does in fact go against the Unix philosophy, of small, independent, but composable programs with a single responsibility. It "proposes" alternatives to many other tools for no particular reason, until users are effectively using GNU/systemd/Linux. And, yes, I know that technically systemd is not a monolith and is composed of many programs, but that is a moot point. It is a single project, maintained by a strongly opinionated team, and given the importance of it, most distros go all-in, so users are strongly recommended, if not forced, to use all of its programs. In many cases it's not even possible to use one individual systemd program idependently from another. This is why systemd is seen as a kraken that takes over the entire system if you do decide to use one part of it.
- jraph 11mo ago
  > go against the Unix philosophy The Unix philosophy is not an end goal neither. It's not even something well defined. Everyone seems to have their own view on what it is. I personally take the "everything is a file" and "do one thing well and be composable" rules as a guideline, an ideal to consider when designing stuff, but not as a strict thing to adhere. It might be something that's nice to have in some contexts and something that's useless or even counter productive in others. What I mean is that I take "does not follow the Unix philosophy" as something to look into to find potential improvements or design issues, but not as blocker or a counterpoint in itself. To me, the Unix philosophy discussion is quite moot. Those discussions are often very vague. I don't care much that systemd follows the Unix philosophy or not. I'm more interested in what actual problems this does cause in practice. You do, however, point out something practical here: > An init system should do one thing (well): manage system services I suppose one could consider that to manage system services well, you have to manage "everything". I also suppose systemd's scope is way bigger than "managing services", they do want to "fix/figure it all". It seems reasonable to me not to agree with any of these things. I do believe the uniformisation systemd causes is a good thing, but I absolutely understand that the big scope can be seen as an issue, and I almost fully agree with your last paragraph. I would object to the statement that systemd is not a monolith and is composed of many programs is a moot point: this modularity still means that you can replace individual systemd programs with your own implementations if needs be… … as long as you provide the expected features / APIs, yes, you are totally forced into this indeed. systemd is a de facto API. It brings / forces standardization at the cost of diversity. It broadens the standardization that comes with UNIX/POSIX and XDG. I'm sure this can be criticized in a few ways: the API design, the scope, the featureset, the way the project is lead… The alternative to systemd is non-existent standardization and each alternative designs stuff its own way on their side. For the better and for the worse. I can see how systemd can be criticized for when we are in "the better" cases. I personally easily see the worse side where several projects (for instance desktop environments) would each have to implement features that come with systemd. And programs on top of these environments now have to implement APIs of each desktop environment to be well integrated. This is more work for everyone. I guess this is a diversity vs efficiency balance to strike and we don't all see it at the same place. I suppose another alternative would be to have different people working on different implementations that are then grouped in some common "system core" package or set of standards that everyone adopts. I'd probably be happy with that, if this is at all possible.

shevy-java 11mo ago

This shows a lack of understanding. I'll skip repeating the issues with regard to systemd here, so instead on just a few points you mentioned. - You claim that the Unix philosophy only survives to the GNUtils. Well, that shows to me a lack of understanding what the philosophy is about. Everything is a file is similar to the OOP approach of everything is an object. I recommend watching Ken Thompson when he was young here: https://www.youtube.com/watch?v=tc4ROCJYbm0 https://www.youtube.com/watch?v=tc4ROCJYbm0 It does not capture all the UNIX philosophy but it does extend on the reasons why that philosophy works well. The philosophy is bigger than that of course but it helps serve as a counter-argument. - The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd? You mention as example FreeBSD debugging a shell script. Well, others use proper languages such as ruby or python. Everything that can be done via systemd I can do without it too and, in fact, have been doing so. Ruby essentially runs my system as the primary layer on everything (granted, it runs Linux, and thus mostly C, and ruby is at the end of the day a syntactic wrapper over C). I never understood why systemd would matter. I read the advertisement of the systemd devs - none of this applied to my use cases, so I never "embraced" systemd, simply because I never needed it. I did point out the increased complexity of it as a negative trade-off and this has been true til this day. - Former "hater" also implies that criticism is not based on rationale and logic. This is not the case either. It's funny to me how the pro-systemd camp isn't really able to come up with compelling arguments on their own.

jraph 11mo ago
> This shows a lack of understanding. I would say your comment either shows a lack of understanding, or that you completely missed the point. > The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd? Of course, you can write the service itself in Python or Ruby or whatever regardless the service manager. The point is that with systemd, or upstart, or other service managers like this that make things more declarative (launchd?), you don't have to write a script to manage the service at all. On systemd, you declare which services yours depend on, how to run it, which user should be used to run your service, and many things are handled for you, including many security mechanisms you don't need to think about and provide further config for this stuff that would be a mess to handle with the traditional way of writing a custom rc script per service. The problem is not being able to write in languages like ruby or python. It's to have to write something at all. systemd makes many things declarative that were historically procedural, potentially painful to debug, code. This eases distro maintenance and I suppose is one of the top reasons most distros adopted it. wrt the Unix philosophy, discussions about it related to systemd are often (always?) too abstract to be useful, I'd suggest talking about specific problematic points.

windward 11mo ago

It's funny how many people fall in love with the Unix philosophy because they enjoy using an OS with a macrokernel that ships with awk, tar, and find, which they operate with useless uses of cat.

hagbard_c 11mo ago
Macrokernel or microkernel or a grain of salt, whatever kernel you use does not matter when it comes to seeing the advantages of 'the *nix philosophy'. As to the 'useless uses of cat' these often make the pipe easier to grasp because the first step is always the same: cat something|filter step 1|filter step 2|filter step 3 instead of filter step 1 something|filter step 2|filter step 3 especially when confronted with filters which need their input to be fed in different ways filter step 1 < something filter step 1 -i something filter something step 1 cat something|filter step 1 It may be less 'pure' to use cat as the first step in a pipe but who cares?
- windward 11mo ago
  Oh I don't care: I do it all the time when I compose cli commands. But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file? I think it's a good example of when it's worth straying from the philosophy.
  - hagbard_c 11mo ago
    > But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file? Yes, it 'prints' the file to stdout which is consumed by the pipe and turned into the input for the next command in the pipeline. It doesn't matter whether you're only 'printing' a single file or a bunch of them.
    - windward 11mo ago
      And it numbers empty lines (-b) and non-empty lines (-n) and the end of lines (-E) and elides empty lines (-s) and search-and-replaces tabs (-T) and nonprinting characters (-v)

pjmlp 11mo ago

A philosophy that GNU doesn't follow even, those haters would be having a fun time with AT&T UNIX System 6 command line experience.

tsoukase 11mo ago

Forget Unix philosophy. The Linux philosophy suggests the monolithic kernel and, therefore, monolithic userland. Systemd fits perfectly, was pushed more or less openly by Linus himself and won. In Linux we don't want a million scripts but large binaries.