3 ms·

The core idea is "do one thing and do it well". Implicated here is that these tools should have interoperable interfaces. These are very basic principles for go

The core idea is "do one thing and do it well". Implicated here is that these tools should have interoperable interfaces. These are very basic principles for good design in any programming. Unix implementation of this is cli programs, streams and files. The systemd ideology, and in general declarative or pointy-clicky-ad-hoc like in Windoes and MacOS, dumb down computers into appliancies. I don't want my computer, especially the very core of the userspace, to be an appliance. For most image editing I use bash and imagemagic. I guess you e.g. resize a batch of images by repeating the same clicky-click routine for each image? Clicky-click has it's uses, but e.g. in Blender I much rather use nodes instead of having thousands of buttons for all connection permutations. Nodes are quite unixy in their UI philosophy. Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. I'd love a modern and retought implementation of the unix philosophy.

kaba0 3y ago
cli programs are not interoperable. Binary streams are not an interface, it's the lack of one. I can't goddamn pipe the CPU temperature into my display manager's status bar without 3 different tools unmaintainable, easy-to-break invocations, that will break from something as innocuous as changing the locale. It's as much of an interface as randomly reading into the memory of another process.
- jampekka 3y ago
  That you can do it with 3 different tools means that they are interoperable. That you can do this without hacking into some huge codebase or waiting someone to implement this specific feature. /sys/class/thermal/thermal_zone0/temp gives you the temperature in ASCII. It's about as simple and interoperable as an interface gets. I like that I can check it in terminal with cat /sys/class/thermal/thermal_zone0/temp when needed. I really like that I can check a remote computer's CPU temperature by doing ssh some.remote.host -C cat /sys/class/thermal/thermal_zone0/temp. If you have the commands to show that in your status bar, you can easily extend a local one to a remote one. You prefer to wait for remotehosttemperaturetostatusbarctl to appear in the AppStore? Or write and debug thousand lines of dbus juggling in C? I do agree that cli programs should be more interoperable in general. E.g. have more structured inputs and outputs akin to JSON or something, conform better to e.g. the GNU command line parameter spec and read stdin and write stdout and log to stderr by default.
funcDropShadow 3y ago
> The systemd ideology, ... , dumb down computers into appliancies. > Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. Why are you sure, you're perceived limitations of systemd compared to sysvinit are based on systemd's shortcommings instead of yours? I don't want to attack you personally, but I've had this conversation lot's of times before. Most of the time, people just had no clue how systemd works. In my experience it simplified lots of use-cases. And I have yet to find a use-case that was possible with sysvinit, but is not with systemd.
- jampekka 3y ago
  I have some clue how systemd works and manage to configure it to run the services I need. But to be frank, I'm quite clueless as to what most of its million LoCs do. I'm quite sure there's not more than a handful of people who do. Sysvinit did so little that it's almost trivial to understand. It has simplified lots of use cases but my criticism is that it focuses too much on these cases and makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break.
  - pkkm 3y ago
    > Sysvinit did so little that it's almost trivial to understand. This is only an advantage if you take an extremely short-sighted view of complexity. Yes, sysvinit itself is very simple, but by that metric you may just as well replace the init with a single exec to a user or distro-provided program. That would be even simpler, right? Well, not if you think about systemic complexity rather than just the complexity of that one program. A modern Linux system will include the monitoring of daemons, auto-restart, parallelized dependency-based boot, and so on. A lot of people also want features such as starting a daemon only when a connection arrives or a device is plugged in, or automatically redirecting a program's output to the system log. This stuff is inherently complex, and that complexity has to go somewhere. sysvinit just says "not my problem", so every distro needed to ship lots of scripts to do these things. Every program that wanted to act as a daemon had to do a whole dance of double fork, setsid, environment variable sanitization, umask, managing a pidfile, etc. You'd have this error-prone logic repeated dozens of times in your system, in different programs, often written by people who aren't Linux experts. That's not systemic simplicity. systemd takes all of this complexity onto itself, and centralizes it into one place that is written by Linux experts. This lets many other programs be simpler. > Makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break. What use cases does it make difficult? How does it make things impossible to fix? Please give specifics, because my experience has been the opposite. When something breaks in a systemd system, I usually find good clues in the system journal and the fix can be a simple configuration change after googling the problem. It's a breath of fresh air compared to having to trace the workings of a hairball of distro-specific shell scripts.
pkkm 3y ago
> The core idea is "do one thing and do it well". The historical "unix philosophy" was specifically about small programs communicating over pipes via plain text. If you retroactively change it to "do one thing and do it well", then it becomes a meaningless truism. "One thing" is so vague that you could argue Photoshop does one thing too; every large piece of software uses some kind of modularity; and who would deliberately write a program to do its job badly? The devil is always in the details that such cliches don't help us decide: how broad should our definition of "one thing" be, what should be the unit of modularity (processes, classes, Python modules?), what is the communication interface between the modules. In the case of systemd, it's an umbrella project maintaining a bunch of medium-size C programs that communicate mostly over D-Bus, in ways that are extensively documented on systemd's website. I find it to be a big improvement in interoperability. Before systemd, most distros used the "simple" sysvinit in theory, but in practice sysvinit was so lacking in features and such a pain in the ass to program for that each distro usually shipped a bunch of helpers glued together with shell and Perl. So you would have to write distro-specific stuff, based on documentation that was less abundant than systemd's. That wasn't very good for interoperability. Can you elaborate on how systemd doesn't let you use your system as a general purpose computer? Because that sounds ridiculous on the surface. There are several ways in which systemd is more general and hackable than sysvinit, for example having targets instead of runlevels. And in practice, after the introduction of systemd I've only found it easier to look into things on my system and tinker with it. journalctl's log formatting and filtering is a very useful addition to grepping when you need to investigate a problem quickly, and systemd user services have made it trivial for me to run my short Python scripts as full-featured daemons that write to my system's log and can be monitored.
- jampekka 3y ago
  Figuring what is "the one thing" is the art. It's like factoring code in separate functions that work well together and with others. There are no strict rules, criteria or methods to attain it. Small programs communicating over pipes via plain text was/is the implementation. The philosophy is more general [1]. This one is more or less how I think of it: "Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools." "Medium sized" (systemd alone is around a million lines) C-programs are extremely difficult to debug or modify if you're not intimately familiar with the codebase. The code in them can't typically be used for any other purposes. Sysvinit as a program is very small, but the point is the protocol that allows multiple different kinds of programs to co-operate. Being able to glue things together with shell and Perl is a feature, not a bug. Journalctl is a good example of violating the UNIX philosophy. It contains its own binary format, its own grep, its own head and tail, etc. With /var/log files you don't have separate cat, grep or tail to examine files and directory listings. That is the UNIX point. And this is what I mean by general purpose. sysvinit had/has plenty of problems and systemd typically works better at least nowadays. I'm not singing any praises of sysvinit. But e.g. OpenRC manages initing without a million lines of code and taking control of more or less the whole OS. [1] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy

kaba0 3y ago

cli programs are not interoperable. Binary streams are not an interface, it's the lack of one. I can't goddamn pipe the CPU temperature into my display manager's status bar without 3 different tools unmaintainable, easy-to-break invocations, that will break from something as innocuous as changing the locale. It's as much of an interface as randomly reading into the memory of another process.

jampekka 3y ago
That you can do it with 3 different tools means that they are interoperable. That you can do this without hacking into some huge codebase or waiting someone to implement this specific feature. /sys/class/thermal/thermal_zone0/temp gives you the temperature in ASCII. It's about as simple and interoperable as an interface gets. I like that I can check it in terminal with cat /sys/class/thermal/thermal_zone0/temp when needed. I really like that I can check a remote computer's CPU temperature by doing ssh some.remote.host -C cat /sys/class/thermal/thermal_zone0/temp. If you have the commands to show that in your status bar, you can easily extend a local one to a remote one. You prefer to wait for remotehosttemperaturetostatusbarctl to appear in the AppStore? Or write and debug thousand lines of dbus juggling in C? I do agree that cli programs should be more interoperable in general. E.g. have more structured inputs and outputs akin to JSON or something, conform better to e.g. the GNU command line parameter spec and read stdin and write stdout and log to stderr by default.

funcDropShadow 3y ago

> The systemd ideology, ... , dumb down computers into appliancies. > Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. Why are you sure, you're perceived limitations of systemd compared to sysvinit are based on systemd's shortcommings instead of yours? I don't want to attack you personally, but I've had this conversation lot's of times before. Most of the time, people just had no clue how systemd works. In my experience it simplified lots of use-cases. And I have yet to find a use-case that was possible with sysvinit, but is not with systemd.

jampekka 3y ago
I have some clue how systemd works and manage to configure it to run the services I need. But to be frank, I'm quite clueless as to what most of its million LoCs do. I'm quite sure there's not more than a handful of people who do. Sysvinit did so little that it's almost trivial to understand. It has simplified lots of use cases but my criticism is that it focuses too much on these cases and makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break.
- pkkm 3y ago
  > Sysvinit did so little that it's almost trivial to understand. This is only an advantage if you take an extremely short-sighted view of complexity. Yes, sysvinit itself is very simple, but by that metric you may just as well replace the init with a single exec to a user or distro-provided program. That would be even simpler, right? Well, not if you think about systemic complexity rather than just the complexity of that one program. A modern Linux system will include the monitoring of daemons, auto-restart, parallelized dependency-based boot, and so on. A lot of people also want features such as starting a daemon only when a connection arrives or a device is plugged in, or automatically redirecting a program's output to the system log. This stuff is inherently complex, and that complexity has to go somewhere. sysvinit just says "not my problem", so every distro needed to ship lots of scripts to do these things. Every program that wanted to act as a daemon had to do a whole dance of double fork, setsid, environment variable sanitization, umask, managing a pidfile, etc. You'd have this error-prone logic repeated dozens of times in your system, in different programs, often written by people who aren't Linux experts. That's not systemic simplicity. systemd takes all of this complexity onto itself, and centralizes it into one place that is written by Linux experts. This lets many other programs be simpler. > Makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break. What use cases does it make difficult? How does it make things impossible to fix? Please give specifics, because my experience has been the opposite. When something breaks in a systemd system, I usually find good clues in the system journal and the fix can be a simple configuration change after googling the problem. It's a breath of fresh air compared to having to trace the workings of a hairball of distro-specific shell scripts.

pkkm 3y ago

> The core idea is "do one thing and do it well". The historical "unix philosophy" was specifically about small programs communicating over pipes via plain text. If you retroactively change it to "do one thing and do it well", then it becomes a meaningless truism. "One thing" is so vague that you could argue Photoshop does one thing too; every large piece of software uses some kind of modularity; and who would deliberately write a program to do its job badly? The devil is always in the details that such cliches don't help us decide: how broad should our definition of "one thing" be, what should be the unit of modularity (processes, classes, Python modules?), what is the communication interface between the modules. In the case of systemd, it's an umbrella project maintaining a bunch of medium-size C programs that communicate mostly over D-Bus, in ways that are extensively documented on systemd's website. I find it to be a big improvement in interoperability. Before systemd, most distros used the "simple" sysvinit in theory, but in practice sysvinit was so lacking in features and such a pain in the ass to program for that each distro usually shipped a bunch of helpers glued together with shell and Perl. So you would have to write distro-specific stuff, based on documentation that was less abundant than systemd's. That wasn't very good for interoperability. Can you elaborate on how systemd doesn't let you use your system as a general purpose computer? Because that sounds ridiculous on the surface. There are several ways in which systemd is more general and hackable than sysvinit, for example having targets instead of runlevels. And in practice, after the introduction of systemd I've only found it easier to look into things on my system and tinker with it. journalctl's log formatting and filtering is a very useful addition to grepping when you need to investigate a problem quickly, and systemd user services have made it trivial for me to run my short Python scripts as full-featured daemons that write to my system's log and can be monitored.

jampekka 3y ago
Figuring what is "the one thing" is the art. It's like factoring code in separate functions that work well together and with others. There are no strict rules, criteria or methods to attain it. Small programs communicating over pipes via plain text was/is the implementation. The philosophy is more general [1]. This one is more or less how I think of it: "Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools." "Medium sized" (systemd alone is around a million lines) C-programs are extremely difficult to debug or modify if you're not intimately familiar with the codebase. The code in them can't typically be used for any other purposes. Sysvinit as a program is very small, but the point is the protocol that allows multiple different kinds of programs to co-operate. Being able to glue things together with shell and Perl is a feature, not a bug. Journalctl is a good example of violating the UNIX philosophy. It contains its own binary format, its own grep, its own head and tail, etc. With /var/log files you don't have separate cat, grep or tail to examine files and directory listings. That is the UNIX point. And this is what I mean by general purpose. sysvinit had/has plenty of problems and systemd typically works better at least nowadays. I'm not singing any praises of sysvinit. But e.g. OpenRC manages initing without a million lines of code and taking control of more or less the whole OS. [1] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy