Shepherd and Guille

Shepherd and Guille

[Wayne]

ahoy all,

   i have been researching GuixSD and Guille a bit, hoping to take the  
plunge soon.  the nice community here is definitely a big plus :)

   i came across the following article

https://davmac.wordpress.com/2018/10/26/on-the-vagaries-of-init-systems/

which raises some issues with the Shepherd init system (towards the  
end in the section "Robustness and failure modes"), in particular with  
its use of an interpreted and garbage collected language.  i was  
wondering if anyone here with knowledge about this would care to  
comment on the validity of these concerns?

   regardless, thanks for the work on GuixSD and company.

peace, w


-- 
https://waynedpj.ingiro.xyz

Re: Shepherd and Guille

[Vladimir Sedach]

> which raises some issues with the Shepherd init system (towards the
> end in the section "Robustness and failure modes"), in particular
> with  its use of an interpreted and garbage collected language.  i
> was  wondering if anyone here with knowledge about this would care to
> comment on the validity of these concerns?

I just skimmed it and it looks like the typical ignoramus FUD. The
author cannot even tell the difference between an interpreter and a
VM. Also amusing is this quote: "JITs can do amazing things, at least
in memory usage." I presume the author here is confusing JITs with
tracing or profile-directed run-time optimization (another mistake
common to people who do not understand dynamic language run-times).
Yes, those can indeed do amazing things in memory usage, namely using
up gigantic amounts of it.

There is about 50 years worth of applications in using dynamic
languages for systems programming (starting with BBN LISP/Interlisp).
The biggest problem is bounding garbage collection pauses. There are
various ways to do this (the simplest being to pre allocate memory).

As for handling running out of memory, the author could have answered
his own question by taking a minute to search through the Guile
sources:

gc-malloc.c:139   scm_report_out_of_memory ();

throw.c:639 throw_without_pre_unwind (scm_out_of_memory_key,
out_of_memory_args);

And indeed in NEWS:
Instead of aborting, failures to allocate memory will now raise an
unwind-only `out-of-memory' exception, and cause the corresponding
`catch' expression to run garbage collection in order to free up memory.

So you catch the exception and perform some appropriate action. Here
I am not exactly sure what the appropriate thing for an init system
to do would be - fail at starting a new service?

Vladimir

Re: Shepherd and Guille

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

I also gave it a quick read and I tend to agree with Vladimir: this
article comes off as a rant (like most other articles on this website according
to the author) with poor arguments and poor understanding of engineering and the
bigger picture of computing.

In my opinion, the style betrays the writing of someone who tries to sound
smarter and more knowledgeable than they really are.  The article is rather
hollow overall.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Shepherd and Guille

[Wayne]

Quoting Pierre Neidhardt <mail@ambrevar.xyz>:

> I also gave it a quick read and I tend to agree with Vladimir: this
> article comes off as a rant (like most other articles on this  
> website according
> to the author) with poor arguments and poor understanding of  
> engineering and the
> bigger picture of computing.
>
> In my opinion, the style betrays the writing of someone who tries to sound
> smarter and more knowledgeable than they really are.  The article is rather
> hollow overall.

thank you both Vladimir and Pierre for taking the time to respond.   
while i also thought that the article was not so well done, the point  
about using GC/JIT/etc. languages for "critical" software like init  
seemed somewhat worth investigating.  thus thanks again for your inputs.

peace, w

-- 
https://waynedpj.ingiro.xyz

Re: Shepherd and Guille

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]


> the point about using GC/JIT/etc. languages for "critical" software like init
> seemed somewhat worth investigating.

Actually, why?  I read this, and to me it sounded like the following reasoning:
"if it's critical, then it has to be a _systems_ language, i.e. C or C++ (or
rust?)".

The author seems to contradict himself and be very confused about this.  If
you read the Shepherd paragraph, compare:

> The decision to write important system-level software in non-memory-safe languages such as C and
> C++ has been criticised. 

vs.

> my concern is that it’s written in Guile, an interpreted (or
> bytecode-interpreted) language with garbage collection – and

Why is it a concern now that the author just said doing the other way around is
criticized?  Argumentation is completely lacking.

> I see both the “interpreted” and “garbage collection” parts as undesirable for system-level software
> (especially for a potential init). 

Why?  How are the two related?  The author might be confabulating between kernel
and system-level.

> Interpreted software will be less efficient (if not in actual speed, since
> I’ll acknowledge that JITs can do amazing things, at least in memory usage)

So if not actual speed, then what is less efficient?  The author does not say...

Actually the more I read it, the more it sounds like a complete heap of
non-sense :D

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Shepherd and Guille

[Vladimir Sedach]

> thank you both Vladimir and Pierre for taking the time to respond.
> while i also thought that the article was not so well done, the point
> about using GC/JIT/etc. languages for "critical" software like init
> seemed somewhat worth investigating.  thus thanks again for your
> inputs.

Sorry, I should have given more details when mentioning BBN Lisp.

These investigations have already been done in the 1970s.

There were several operating systems built at Xerox PARC, in
Smalltalk and in INTERLISP, for various kinds of hardware (including
PCs with Intel microprocessors¹). There was the ZetaLisp based series
of operating system originating out of MIT. Takashi Chikayama²
implemented micro-controller Lisp systems on Intel processors starting
in 1976.³

Since that work in the 1970s, the only unsolved problem for using
dynamic languages in systems programming has been designing a hard
real-time garbage collector, and that has been solved in 2003 at
IBM.⁴


¹ https://oneofus.la/have-emacs-will-hack/2012-01-11-the-personal-computer-you-havent-heard-of.html
² http://www.logos.ic.i.u-tokyo.ac.jp/~chik/
³ http://www.softwarepreservation.org/projects/LISP/utilisp/utilisp/IPSJ-JIP1303003.pdf
⁴ https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon03Metronome.pdf

Re: Shepherd and Guille

[Maxim Cournoyer]

Vladimir Sedach <vas@oneofus.la> writes:

[...]

> Since that work in the 1970s, the only unsolved problem for using
> dynamic languages in systems programming has been designing a hard
> real-time garbage collector, and that has been solved in 2003 at
> IBM.⁴
>
> ¹ https://oneofus.la/have-emacs-will-hack/2012-01-11-the-personal-computer-you-havent-heard-of.html
> ² http://www.logos.ic.i.u-tokyo.ac.jp/~chik/
> ³ http://www.softwarepreservation.org/projects/LISP/utilisp/utilisp/IPSJ-JIP1303003.pdf
> ⁴ https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon03Metronome.pdf

Interesting links! Thanks for sharing.

Maxim

Re: Shepherd and Guille

[Wayne]

Quoting Maxim Cournoyer <maxim.cournoyer@gmail.com>:

> Vladimir Sedach <vas@oneofus.la> writes:
>
> [...]
>
>> Since that work in the 1970s, the only unsolved problem for using
>> dynamic languages in systems programming has been designing a hard
>> real-time garbage collector, and that has been solved in 2003 at
>> IBM.⁴
>>
>> ¹  
>> https://oneofus.la/have-emacs-will-hack/2012-01-11-the-personal-computer-you-havent-heard-of.html
>> ² http://www.logos.ic.i.u-tokyo.ac.jp/~chik/
>> ³  
>> http://www.softwarepreservation.org/projects/LISP/utilisp/utilisp/IPSJ-JIP1303003.pdf
>> ⁴  
>> https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon03Metronome.pdf
>
> Interesting links! Thanks for sharing.
>
> Maxim

100% ditto. thanks again Pierre and Vladimir for the thorough and  
informative replies: lots to chew on that increases my interest in  
Guile and GuixSD.

peace, w

-- 
https://waynedpj.ingiro.xyz