GNU Shepherd 0.10.2 Service Manager Fixes Some Long-Standing Issues

[mb_q]

Lisp is not a problem, R is Scheme with (f ... ...) simply written as f(..., ...) plus some basic operators and nobody complains it is unreadable; even proper lisp is way better than yaml.

The advantage of systemd, however, is that configuration is declarative rather than executable; one won't get a .service file that calculates Ackermann function to establish service name, neither has to worry about internal API stability, bugs, abuse of undocumented behaviours, etc.

[archkde]

Then write one. With more stanzas and logic (like other service, device or mountpoint dependencies, ordering, logging and resource thresholds, capabilities, permissions etc). With defaults being overridable by drop-ins, reliable service termination and cleanup (watch the timeouts), preparing the environment (runtime directories), security hardening (syscall filtering, various bind/overmounting), respawn rate limiting, fallbacks etc.

I have not looked at Shepherd closely enough to know whether these are implemented in an easy-to-use way (service dependencies seem to be there though). But the poster I replied to compared this negatively to init scripts as well, in which all of these are extremely hard to do as well.

And then create the second service with all of that.

I guess you would end up writing this all over and over again in this funny language for yourself, for every service with little or no code reuse (until you'll learn to create some kind of modules or whatever there is supported, if any...).

This part is definitely not true. Scheme is a full programming language, where you can just factor out the common parts into functions.

[blackiwid]

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Kernighan’s law

Your example is stupid, you compare lisp to a oneliner of a very ugly language. I am not sure but "objective" sounds like OOP, so you mix in that garbage on top, while lisp has the capability to use some sort of OOP on top it's not a big element of lisp.

Now I would agree that scheme uses to much $#@ signs in the code, which as example in emacs-lisp are way less common and often actually optional.

But you can get syntax highlighting that is pretty useful in lisp but not very in this one liner. you can format lisp code easily. And in good ides (semi-)automatically. It doesn't even have function parameters but uses weird %_[0] syntax.

So why would you show a much more cryptic language to proof that the less cryptic lisp language is bad? You proof the opposite that lisp is much more readable and sane than pearl.

You seem to make the argument that if you add a bowl of salt into your dish, that it's bad therefor it must be bad to have a small pinch in it, too, which is not true, it's always about the dosage of the poison if it's bad or good.

I mean pearl just has a few ugly things where you see it's a bash language not a real full programming language. besides the ugly parameters as list instead of names, you also have no real boolean values, just everything that is not 0 is more or less true.

(defun foo (a b c)
    (if a b c))

(foo t "bar" "baz")

sub foo {
  if ($_[0]){
    return ($_[1])
  }
  else{
    return ($_[2])
  }
}

foo (1)​

But I don't really see a big problem with the code of lisp, if you know the syntax rules the code is easily to read and in no way you have to use oneliners even with pearl you don't have to. But having the option of anonymous functions and such stuff is good.

You also skip over the problems of the most used alternative OOP languages, that create a lot of binding and with the average quality of the average programmer you get to a point where the massive coupling makes projects nearly unmanageable. I rather think 10 mins to understand the code, than to have 1mio files I have to switch around because in OOP everything is spread between 100 different classes for theoretical reusability that in 99% of the cases never get used anyway.

I am more concert with spamming stupid words like "return", "elseif" code that not respect DRY principle much, while with lisp you pretty much can create code that is 0% dry. And I know usually people not include writing 5 times in a code "elseif" but it's repeating yourself you would not have to use this words 20 times if you had good enough functions to assume that. Heck even the spamming of commatas in lists [1, 2, 3, 4, 5]

annoys the shit out of me, when it's obviously unnecessary a parser can know that if you have 2 numbers with a space in between that it's a different value.

Also having anonymous functions and throw away block based variable keeps you from context switching you stay in the logic of the program not have to switch to natural language so much forth and back to come up with good function/variable names. It's like coding with all 5 minutes somebody calls you and interrupts you from your real task.

[blackiwid]

sorry forgot the "bar" "baz" parameters in the pearl example.

[gotar]

(until you'll learn to create some kind of modules or whatever there is supported)

This part is definitely not true. Scheme is a full programming language, where you can just factor out the common parts into functions.

I've restored my words you've apparently ignored.

So, you're telling me that with Shepherd I need to trust the real code run in init1 context? Any random software vendor can load whatever functions he likes and rewrite all my system even before his actual service is being started? I've always been careful running SysV init scripts bundled with software, but this was usually not so hard to trace, because - well, nobody even tried to put some complicated stuff into these shell scripts. And if someone did, I made my own ones.

Apparently the Shepherd has the worst of both worlds - it's not declarative, one have to do coding, but the language is obscure (so it's not so trivial as in sh) and the higher-order functions are ...unknown or convoluted at least, while the system architecture makes user to trust vendor. So vintage thinking... so GNU/NIH syndrome.

[gotar]

Your example is stupid, you compare lisp to a oneliner of a very ugly language.

It was me, comparing very ugly language (lisp) to the beauty of perl. You're right, I shouldn't have abominated perl this way...

Now I would agree that scheme uses to much $#@ signs in the code, which as example in emacs-lisp are way less common and often actually optional.

But you can get syntax highlighting that is pretty useful in lisp but not very in this one liner. you can format lisp code easily.

And this syntax highlighing would explain me what the hell this "$#@" means in init-script?!
You imply that with Shepherd I need some syntax highlighing highly lisp-specialized editor just to set my system up?!

And in good ides (semi-)automatically. It doesn't even have function parameters but uses weird %_[0] syntax.

That's just like perl.

So why would you show a much more cryptic language to proof that the less cryptic lisp language is bad?

Because noone sane writes feature-complete service manager and init-scripts in perl?

But I don't really see a big problem with the code of lisp, if you know the syntax rules the code is easily to read and in no way you have to use oneliners even with pearl you don't have to. But having the option of anonymous functions and such stuff is good.

For init-script?!

[blackiwid]

And this syntax highlighing would explain me what the hell this "$#@" means in init-script?!

Lisp people think this signs make the code more readable, I kind of disagree. Some if not most of it is just optional aka convention to add this signs but it's not needed. I am not sure the # might be optional but in the example on the website are no @ and no $ so you made that up.

You imply that with Shepherd I need some syntax highlighing highly lisp-specialized editor just to set my system up?!

"setup your system" do you edit init scripts when you install a distribution? I do that extremely seldom and most of the time on a running system to add something.
So yes you either use tramp with emacs from a remote machine or you have a local emacs running otherwise you only copy/paste.

The discussion is similar to logfiles, without a good editor it's a pain in the ass to even look through it, there the systemd tools with the binary files stuff is better. Both solutions have pros and cons. Yes it's for developers.

You will run into herd nearly exclusive in guix anyway and then you love lisp most likely otherwise you would not have chosen that distribution.

That's just like perl.

No I talked about pearl you don't do that in lisp.

Because noone sane writes feature-complete service manager and init-scripts in perl?

You can think that of initscripts but I would strongly disagree with service managers, you want to give normal developers that don't have 10 times as much time to write some C code more power of the machine. Before I learned lisp/emacs the whole system is "opensource" was more a theoretical thing I know theoretically I could dig into everything, but I knew that every attempt could be extremely time consuming and needed a lot of learning, even finding the correct place in the code that would matter... having a compiling setup are extreme big barriers to change functionality.

You whine about having to write some code for init scripts / init files, but alre ok to change C code for your init system and having a complicated compiler setup on your pc. needing a good Editor/ide or not even needing but making it a lot more comfortable is nothing against a compiling setup.
[/QUOTE]