4 ms·

I already have a Swiss army knife program that manages my life, makes sandwiches, and takes my dog to the groomer. It's called Emacs. I don't need another.

zeveb 7y ago
And Emacs uses a nice, simple, sane, universal configuration file format (S-expressions) while systemd uses .ini files (on Unix!), JSON, binary and no doubt something else somewhere else. Hmmm, maybe it'd be worthwhile to just make emacs PID 1.
- deleted 7y ago
  [deleted]
- throwaway17_17 7y ago
  I think the use of .ini files is exceptionally appropriate for systemd. The developers are at there most transparent here, it is essentially them saying “we want to be Windows, we want to be the ones who control your system, we make the decisions and you should be thankful that insightful, expert, never ever ever wrong developers like us grace you with this software.” (Obvious fake quote, is obvious) I know the sarcasm is heavy there, but the attitude of the developers of systemd seems to be honestly geared in this direction. So, Of course they use .ini files on Unix, because they want the same sort of mono monster, one true path OS that Windows has.
  - kazinator 7y ago
    > we want to be Windows You mean, we want to be nice Windows, before the Registry?
  - CameronNemo 7y ago
    Fwiw systemd definitely does not use ini files. It uses some weird scripting language that looks sort of like ini but has logical operators, clear statements, and the ability to assign multiple values to one key.
- rauhl 7y ago
  > a nice, simple, sane, universal configuration file format (S-expressions) In particular, this bit from the article sounds like hand-rolled, informally-specified canonical S-expressions[0]: > It is recommended to bring the record into ‘normalized’ form (i.e. all objects should contain their fields sorted alphabetically by their key) before storing it there, though this is not required nor enforced. It really is true that those who do not understand Lisp are doomed to reinvent it. 0: https://people.csail.mit.edu/rivest/Sexp.txt https://people.csail.mit.edu/rivest/Sexp.txt
- zdw 7y ago
  Unsurprisingly, this has been tried: https://www.informatimago.com/linux/emacs-on-user-mode-linux.html https://www.informatimago.com/linux/emacs-on-user-mode-linux...
- kazinator 7y ago
  > systemd uses .ini files (on Unix!) So does Linus Torvald's git version control utility.
  - dsmithatx 7y ago
    I believe it is actually the TOML format which was obviously inspired by .ini files. TOML has a formal standard while ini files have no formal standard being the big difference.
    - zaarn 7y ago
      Git does not use TOML, even if it looks very similar. You can check the syntax in "man git-config", but is definitely has a few syntax differences to TOML (especially the "[section "subsection"]" part) There is no formal git-config standard other than what's deployed in git.
- catalogia 7y ago
  There is also GNU Shepherd, an init system which uses Guile (a scheme dialect.) https://en.wikipedia.org/wiki/GNU_Guix#GNU_Shepherd_Init_system https://en.wikipedia.org/wiki/GNU_Guix#GNU_Shepherd_Init_sys...
Steltek 7y ago
I like to think of systemd as a family of related projects meant to absorb all the triviality in a Linux system and push it to the mental background. I've long since stopped caring about anacron (and meticulously managed cron job stdout and exit codes), writing init.d scripts, log rotation, and so on. PAM mount (and PAM in general) is more of the same: an unapproachable mess of various generations of junk for different purposes. This isn't coming from some Linux newcomer: I've used Linux for 20+ years starting with floppy-only 386s. That said, JSON? Pick a format and stick with it. Camel-cased ini files wasn't my first choice but consistency matters more at this point.
- superkuh 7y ago
  You think systemd timers have less triviality than cron jobs? That's pretty hard to take seriously. Setting up a cron job is a 1 line 10 second thing. Setting up a systemd timer means creating two 10 line config files from scratch than invoking a long system call before it starts up.
  - rakoo 7y ago
    And then your cron job fails, but you don't know when, nor how. So you need to log it. And then your cron job runs again, because the first instance didn't finish in time. So you need to protect agains parallel execution. And then your cron job doesn't run, because your machine was off when it was supposed to. So you need to track when it was supposed to run, and run it. And on and on and on. Systemd timers manages all this bookkeeping stuff so you can focus on one thing only: what your script needs to do.
    - zrm 7y ago
      > And then your cron job fails, but you don't know when, nor how. So you need to log it. Which it already does. Success on Unix/Linux is silent and any output from a cron job gets emailed by default. > And then your cron job runs again, because the first instance didn't finish in time. So you need to protect agains parallel execution. So you use flock(1) with --timeout equal to the launch interval. Assuming parallel execution is actually undesired; maybe you want it. Suppose you have a job to gzip the day's data, and if it takes 30 hours to do it, you still want to run tomorrow's job on time because tomorrow's job is running on a different day's data. > And then your cron job doesn't run, because your machine was off when it was supposed to. So you need to track when it was supposed to run, and run it. What do you propose to do instead if the machine is powered off? If it's supposed to run once a day and the machine is unplugged for three days, should it immediately run three times as soon as you turn it back on? Should it run once, but then run again only an hour later at the time scheduled for today, thereby still running twice in the same day? If the launch arguments take today's date, which day do you pass? You still have to specify what you want one way or another. It's not clear how specifying it in a shell script is any worse than specifying it in a unit file, and it can certainly be better, because arbitrary code can solve arbitrary problems. Unit files are limited to specific directives unless you want to rely on unit files calling shell scripts, and in that case why do I want to write a unit file and a shell script instead of only writing a shell script?
distantsounds 7y ago
Yeah, if only it was a competent text editor. I guess that's why vi exists.
_pmf_ 7y ago
> I don't need another. That's for Lennart Poettering to decide[0]. [0] I don't make the rules
mdaniel 7y ago
> A lightweight systemd replacement written in Emacs lisp https://github.com/a-schaefers/systemE#readme https://github.com/a-schaefers/systemE#readme

zeveb 7y ago

And Emacs uses a nice, simple, sane, universal configuration file format (S-expressions) while systemd uses .ini files (on Unix!), JSON, binary and no doubt something else somewhere else. Hmmm, maybe it'd be worthwhile to just make emacs PID 1.

deleted 7y ago
[deleted]
throwaway17_17 7y ago
I think the use of .ini files is exceptionally appropriate for systemd. The developers are at there most transparent here, it is essentially them saying “we want to be Windows, we want to be the ones who control your system, we make the decisions and you should be thankful that insightful, expert, never ever ever wrong developers like us grace you with this software.” (Obvious fake quote, is obvious) I know the sarcasm is heavy there, but the attitude of the developers of systemd seems to be honestly geared in this direction. So, Of course they use .ini files on Unix, because they want the same sort of mono monster, one true path OS that Windows has.
- kazinator 7y ago
  > we want to be Windows You mean, we want to be nice Windows, before the Registry?
- CameronNemo 7y ago
  Fwiw systemd definitely does not use ini files. It uses some weird scripting language that looks sort of like ini but has logical operators, clear statements, and the ability to assign multiple values to one key.
rauhl 7y ago
> a nice, simple, sane, universal configuration file format (S-expressions) In particular, this bit from the article sounds like hand-rolled, informally-specified canonical S-expressions[0]: > It is recommended to bring the record into ‘normalized’ form (i.e. all objects should contain their fields sorted alphabetically by their key) before storing it there, though this is not required nor enforced. It really is true that those who do not understand Lisp are doomed to reinvent it. 0: https://people.csail.mit.edu/rivest/Sexp.txt https://people.csail.mit.edu/rivest/Sexp.txt
zdw 7y ago
Unsurprisingly, this has been tried: https://www.informatimago.com/linux/emacs-on-user-mode-linux.html https://www.informatimago.com/linux/emacs-on-user-mode-linux...
kazinator 7y ago
> systemd uses .ini files (on Unix!) So does Linus Torvald's git version control utility.
- dsmithatx 7y ago
  I believe it is actually the TOML format which was obviously inspired by .ini files. TOML has a formal standard while ini files have no formal standard being the big difference.
  - zaarn 7y ago
    Git does not use TOML, even if it looks very similar. You can check the syntax in "man git-config", but is definitely has a few syntax differences to TOML (especially the "[section "subsection"]" part) There is no formal git-config standard other than what's deployed in git.
catalogia 7y ago
There is also GNU Shepherd, an init system which uses Guile (a scheme dialect.) https://en.wikipedia.org/wiki/GNU_Guix#GNU_Shepherd_Init_system https://en.wikipedia.org/wiki/GNU_Guix#GNU_Shepherd_Init_sys...

Steltek 7y ago

I like to think of systemd as a family of related projects meant to absorb all the triviality in a Linux system and push it to the mental background. I've long since stopped caring about anacron (and meticulously managed cron job stdout and exit codes), writing init.d scripts, log rotation, and so on. PAM mount (and PAM in general) is more of the same: an unapproachable mess of various generations of junk for different purposes. This isn't coming from some Linux newcomer: I've used Linux for 20+ years starting with floppy-only 386s. That said, JSON? Pick a format and stick with it. Camel-cased ini files wasn't my first choice but consistency matters more at this point.

superkuh 7y ago
You think systemd timers have less triviality than cron jobs? That's pretty hard to take seriously. Setting up a cron job is a 1 line 10 second thing. Setting up a systemd timer means creating two 10 line config files from scratch than invoking a long system call before it starts up.
- rakoo 7y ago
  And then your cron job fails, but you don't know when, nor how. So you need to log it. And then your cron job runs again, because the first instance didn't finish in time. So you need to protect agains parallel execution. And then your cron job doesn't run, because your machine was off when it was supposed to. So you need to track when it was supposed to run, and run it. And on and on and on. Systemd timers manages all this bookkeeping stuff so you can focus on one thing only: what your script needs to do.
  - zrm 7y ago
    > And then your cron job fails, but you don't know when, nor how. So you need to log it. Which it already does. Success on Unix/Linux is silent and any output from a cron job gets emailed by default. > And then your cron job runs again, because the first instance didn't finish in time. So you need to protect agains parallel execution. So you use flock(1) with --timeout equal to the launch interval. Assuming parallel execution is actually undesired; maybe you want it. Suppose you have a job to gzip the day's data, and if it takes 30 hours to do it, you still want to run tomorrow's job on time because tomorrow's job is running on a different day's data. > And then your cron job doesn't run, because your machine was off when it was supposed to. So you need to track when it was supposed to run, and run it. What do you propose to do instead if the machine is powered off? If it's supposed to run once a day and the machine is unplugged for three days, should it immediately run three times as soon as you turn it back on? Should it run once, but then run again only an hour later at the time scheduled for today, thereby still running twice in the same day? If the launch arguments take today's date, which day do you pass? You still have to specify what you want one way or another. It's not clear how specifying it in a shell script is any worse than specifying it in a unit file, and it can certainly be better, because arbitrary code can solve arbitrary problems. Unit files are limited to specific directives unless you want to rely on unit files calling shell scripts, and in that case why do I want to write a unit file and a shell script instead of only writing a shell script?

distantsounds 7y ago

Yeah, if only it was a competent text editor. I guess that's why vi exists.

_pmf_ 7y ago

> I don't need another. That's for Lennart Poettering to decide[0]. [0] I don't make the rules

mdaniel 7y ago

> A lightweight systemd replacement written in Emacs lisp https://github.com/a-schaefers/systemE#readme https://github.com/a-schaefers/systemE#readme