Re: The "Unix Philosophy 2020" document

[Jeff]

30.11.2019, 16:48, "Casper Ti. Vector" :
> See also this design:
> .

since scheme was mentioned in that article:
an init/supervisor written entirely in (Guile) Scheme already
exists (http://www.gnu.org/software/shepherd/):

The GNU Daemon Shepherd or GNU Shepherd,
formerly known as GNU dmd, is a service manager that looks
after the herd of system services. It provides a replacement for
the service-managing capabilities of SysV-init (or any other init)
with a both powerful and beautiful dependency-based system with
a convenient interface. It is intended for use on GNU/Hurd, but it is
supposed to work on every POSIX-like system where Guile is available.
In particular, it is used as PID 1 by GNU Guix.

this is also not entirely off topic here since it is used as process #1,
daemon supervisor and "service manager".

Re: The "Unix Philosophy 2020" document

[Casper Ti. Vector]

On Sat, Nov 30, 2019 at 04:01:40PM +0100, Jeff wrote:
> a useful command interpreter should provide some builtins IMO.
> this is much more efficient and avoids excessive exec chaining
> (analoguous to single combined utils for several tasks vs the
> "one task one tool" approach). there might be a very good reason
> shells provide builtin "cd", "umask", "(u)limit" etc ...
> 
> i dunno if such builtins would be possible with execline, too.

See also this design:
.
(BTW, that post contributed to the formation of the UP2020 document.)

As was noted by Laurent, language flamewars are off-topic here.
However, I guess discussions on interesting ideas like nosh builtins
are still within the margin of acceptability, as long as we focus on
novel yet feasible chainloading implementions instead of blanket
declarations like "language X is better/worse than language Y".

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: The "Unix Philosophy 2020" document

[Casper Ti. Vector]

On Sat, Nov 30, 2019 at 01:29:35PM +, Laurent Bercot wrote:
> [...] Here, I'd like to hear *less* about systemd,
> and more about better designs.

I do not mean to bad-mouth nosh, but I find it really necessary to note
that after skimming through `move-to-control-group.cpp', I feel quite
concerned about the coding style of nosh -- the kind of style that
significantly affects maintainability, which is largely independent of
the language used.

To put it bluntly, I think The nosh codebase is undeniably and
dramatically better than the systemd codebase, but obviously inferior to
codebase of most other daemontools-ish software we are fairly familiar
with.  I really find certain aspects of nosh enlightening, eg. the way
"builtins" are supported by the `nosh' interpreter [1], so I intend this
comment to be not pure blaming, but an (not so humble) appeal to push
nosh closer to perfection.

[1] 

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Jeff]

30.11.2019, 11:15, "Laurent Bercot" :
> This is very interesting. I thought that having a s6- prefix was a *good*
> thing, because I valued clarity above everything, and especially above
> terseness. I understand the advantages of having commands named "sv" and
> "chpst", but I believed, in my naïveté, that it wasn't a good idea for a
> specialized package to tread on a large namespace; and to me the s6-
> prefix would help users recognize exactly the domain of the command
> they're using, and then they could abstract it away and focus on the
> real command name.

totally agreed, Laurent.

using a dedicated namespace prefix like "s6-" is a very good idea.
this avoids nameclashes (i. e. overwriting on installation) with similar
utilities of other supervision suites and frees Laurent from the task
of coming up with proper AND unique command names. consider
nameclashes of several "init" program for example.

the solution here could be a simple symlink to the original s6 tool without
the prefix if you prefer (maybe even located in an other dir than /bin).

> The number of executables is a choice; I like to have more, smaller,
> executables than less, bigger ones. One function, one tool. It makes
> code easier to write; this is not really for historical reasons, it's a
> design choice. Personally, it's easier for me to remember several
> process state change command names than all the options to chpst.
> whenever I use chpst, I always need to check the doc; when I use
> something like softlimit or setuidgid, I may need to check the doc for
> specific options, but I always remember which command I want and its
> general syntax. So, I suppose it comes down to individual preference
> there.

using a single combined tool is more efficient since it avoids wasteful further
exec chaining steps, though.

> Would a generic "s6" command, that takes alternative syntax and rewrites
> itself into "internal" commands, help? It could emulate runit syntax,
> among other things.
>
> s6 runsv ... -> s6-supervise ...
> s6 sv ... -> s6-svc ...
> s6 chpst ... -> various s6-prefixed process state change commands
>
> My plan is for the future s6-frontend package to include such a
> one-stop-shop command that controls various aspects of an s6
> installation,
> but if this command can help with s6 adoption, I can work on it much
> earlier than the rest of the s6-frontend functionality.
>
> Or, if you have other ideas that could help with easier assimilation of
> the s6 commands, I'm very open to suggestions.

Busy/ToyBox style ?

> Would entirely removing s6's dependency on execline help clear that
> misunderstanding and help with s6 adoption? This could be made possible
> by:
> - duplicating el_semicolon() functionality in s6-ftrig-listen.c
> (it's not elegant, but clearing the dep may be worth it)
> - adding an alternative '?' processor directive to s6-log, that spawns
> the processor using /bin/sh instead of execlineb. (The '!' directive
> would still be there; processor invocations using '!' would just fail
> if execline is not installed.)

sounds not too bad, IMO. though i personally can live without it,
especially since the other suites also provide loggers (without any
execline deps of course), he can use dt encore's "multilog" utility.

> s6-rc, however, absolutely cannot do without execline, since it uses
> autogenerated execline scripts.

could you document the way s6-rc works (i. e. its architecture) somewhere ?
or are users requested to follow your C code to find out how it works
exactly ?

> But s6-rc is a different beast, that
> requires a lot more involvement than s6 anyway, and that isn't needed
> at all if we're just talking about runit-like functionality.

indeed.

Re: runit patches to fix compiler warnings on RHEL 7

[Jeff]

>>  chpst is a monster of a program and at least with runscripts written in
>>  execline it's generally easier to understand 3-4 process state
>>  manipulators than a pile of chpst options.
>
> this is more complicated to use, though.

it is even unnecessary, inefficient, and wasteful.

why exec chaining into several different utils where doing all the
requested process state changes in one go by using the same
utility to achieve them would suffice ?

Re: runit patches to fix compiler warnings on RHEL 7

[Jeff]

30.11.2019, 01:22, "Colin Booth" :
>>  2) runit has manpages. s6 has HTML. :(
> Yeah, this sucks. I know Laurent isn't going to do it but I've been
> meaning to take some time off and dedicate it to rewriting all of the
> documentation into something that an compile into both mandoc and html.

what about writing the docs in Perl's POD format or Markdown ?
it is easy to convert POD to html AND manpages (pod2(html,man))
and to deliver the generated docs in the source releases.

>>  3) s6 executables are somehow worse named than runit's. This may be
>> highly subjective, but I can recall and recognize the runit commands
>> far easier than the s6 ones. Possibly it's the "s6-" prefix getting
>> in the way of my brain pattern matching on visual appearance of glyph
>> sequences.
>> This point is exacerbated by #2 and the number of s6 executables.
>> Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
>> s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
>> historical reasons, but sti

totally agreed.

> chpst is a monster of a program and at least with runscripts written in
> execline it's generally easier to understand 3-4 process state
> manipulators than a pile of chpst options.

this is more complicated to use, though.
therefore i personally prefer perp's approach of providing both:
the single process state manipulators and their combination into one
single tool ("run..." vs "runtool").

>>  Brainstorming possible ways forward:
>>
>>  A) Gerrit Pape becomes more active in maintianing runit, at least
>> acknowledging patches posted here.
>>  B) Somebody else steps in as (co-)maintainer.
>>  C) We get a dumping ground (wiki or somesuch) for patches to allow
>> - contributors to publish their patches (after discussing them here)
>> - users to easily find and download patches they'd be interested in
>> - Gerrit Pape to review and apply patches at his leisure when he
>>   feels like making a new release.
>>  D) The maintainers of distros shipping runit work out a patch-sharing
>> scheme among them.

runit is dead, i recommend against using it at all, the only tools of interest
this supervision suite provides are "chpst" and "utmpset"
(though the latter is indeed not as powerful as it should to make it really
useful).

besides waking up to poll for rundir changes shutting it down really
sucks since it has problems closing the log files properly, i have not seen
this with any of daemontools encore, perp, and s6.

consider switching, daemontools encore and perp were not meant to run
as process #1, but they can be supervised by (Busy,Toy)Box- or SysV init easily.

daemontools encore's "svscan" utility wakes up to poll the rundir for changes
frequently, though, unlike s6 and perp it does not provide any option to only
do this on request (maybe by just listing for a given signal).

so the final conclusion and recommendation here is:
stop using runit for supervision (and as process #1) and switch to s6.

Re: The "Unix Philosophy 2020" document

[Laurent Bercot]

 Friendly reminder that:

 - systemd discussion, even criticism, is off-topic, unless it's a deep
technical analysis of a part of systemd and whether or not implementing
equivalent functionality would be relevant to supervision systems. If 
you
want to rant against systemd, it's certainly a healthy urge, but you 
have

*the whole Web* to do so. Here, I'd like to hear *less* about systemd,
and more about better designs.

 - language flamewars are also off-topic.
   * At software writing time, there are good, objective reasons to use 
a

given language more than another, but this is a design discussion that
needs to happen *at that time*; once the software has been written, it's
too late for constructive criticism, and only noise remains.
   * At software usage time, the language the software is written in is
obviously a factor in deciding whether or not to use the software, but
that choice belongs to the user and it's a personal choice. I don't like
C++ for low-level software, so I don't use nosh; but if someone has
different preferences from mine, it's not my place to tell them what to 
use,

and neither is it yours.

--
 Laurent

Re: The "Unix Philosophy 2020" document

[Jeff]

> this sounds even more funny with regard to the posting's title
> "Unix Philosophy 2020(!!!)".

C++ is the perfect language to implement systemd in btw,
though even prof. dr. L. Poettering abstained from doing so.

will we see a C++ rewrite of our favourite "init framework"
(the "master of the cgroups") ?

or is it just too early since our beloved friend and every admin's
darling is still not "feature complete" (or even stable :-) after all ?

let's wait and see what pleasant suprises christmas eve may bring ...

Re: The "Unix Philosophy 2020" document

[Jeff]

> why C++ btw ?
>
> i don't see any benefit in not using C in the first place,
> since when does one write Unix system tools in C++ ?
>
> is it the added "advantage" of bloated binaries and additional
> lib dependencies ?

this sounds even more funny with regard to the posting's title
"Unix Philosophy 2020(!!!)".
:-(

Re: The "Unix Philosophy 2020" document

[Jeff]

>>  Macros and/or helper functions (again cf. [1]; they can be factored into
>>  a mini-library in nosh) can also be used to reduce boilerplate like
>>  > const int error(errno);
>>  > std::fprintf(stderr, ..., std::strerror(error));
>>  > throw EXIT_FAILURE;
>>  which can be easily observed after the attached patch is applied.
>
> The first chunk in the patch is incorrect, and the new code should be
> (in other words, swap the `ENOENT == error' and the `const int' lines)
>>  if (!self_cgroup) {
>>  if (ENOENT == error) return; // This is what we'll see on a BSD.
>>  const int error(errno);
>>  std::fprintf(stderr, "%s: FATAL: %s: %s\n", prog, "/proc/self/cgroup", 
>> std::strerror(error));
>>  throw EXIT_FAILURE;
  ^^ using an exception here looks like a 
REALLY brilliant idea to me
>>  }

why C++ btw ?

i don't see any benefit in not using C in the first place,
since when does one write Unix system tools in C++ ?

is it the added "advantage" of bloated binaries and additional
lib dependencies ?

s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

As a relatively new convert to supervision software, my reasons for
preferring runit over s6 are, in order of priority:


Hi Jan,

Thank you a lot for this feedback. This is very useful UX return.
Let me address the points one by one.



1) Debian ships with a working and maintained runit-init package. It
   provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
   Debian packages. s6-linux-init and s6-rc are not packaged in Debian.


I hear you. Unfortunately, I have no control over what Debian does.
Debian isn't even able to ship a not-broken execline package, so I'm at
a loss on what to do with them. I'm working on a version of execline 
that

they *might* accept to package correctly, but it's doubtful as long as
the people in charge are prejudiced against the "lots of small binaries
in /bin" approach. :(



2) runit has manpages. s6 has HTML. :(


This is far from the first time I hear this, so it would be foolish to
ignore it, but I *really* have a hard time understanding how in 2019 
it's

so difficult for people to launch a browser to read a web page. I just
can't get it. Launching a browser and reading a web page is something 
that
we all do, every day, even the least computer-savvy ones among us, and 
for
the life of me I can't fathom how this is *not* a friendly user 
interface.
HTML even has the advantages of hyperlinks, so you can jump around in 
the

documentation as needed, which you can't do with man pages!

Do you work offline? don't you have access to a web browser? do you like
reading stuff in a terminal *better*? (Text-based web browsers still
exist, if you do.)

It really stumps me. I did learn "man" too, 25 years ago, before the
Web existed. It was nice when man pages were all we had. But a couple of
years later, we had something that seems unarguably better to me, and
I see exactly zero reason to go back, apart from the force of habit of
typing "man".

Nevertheless, if people like man pages, they should have man pages, so
it's been a few years that I have appealed to the community for this.
I'm not going to learn nroff, ever, but we have a relatively large user
community, so they could probably contribute man pages, right? We've had
a few people who seemed interested, some of them even started thinking
about it *really hard*. And one of them even wrote a tool to convert
text into nroff, à la markdown (but simpler). But when it was about 
doing

the actual work of writing the man pages (even if all the material is
already here, in the HTML doc)? You guessed it: crickets.

So, yeah, I want s6 to be accessible, but I figure that if people
really wanted man pages, they'd write man pages ¯\_(ツ)_/¯ Or maybe I was
wrong all along and the spirit of Open Source really is "If the one 
person
doing the work doesn't do exactly what I want, then I'm just gonna sit 
on

my ass and blame them".

If I'm sounding a bit jaded, it's because I am.



3) s6 executables are somehow worse named than runit's. This may be
   highly subjective, but I can recall and recognize the runit commands
   far easier than the s6 ones. Possibly it's the "s6-" prefix getting
   in the way of my brain pattern matching on visual appearance of glyph
   sequences.
   This point is exacerbated by #2 and the number of s6 executables.
   Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
   s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
   historical reasons, but still.


This is very interesting. I thought that having a s6- prefix was a 
*good*

thing, because I valued clarity above everything, and especially above
terseness. I understand the advantages of having commands named "sv" and
"chpst", but I believed, in my naïveté, that it wasn't a good idea for a
specialized package to tread on a large namespace; and to me the s6-
prefix would help users recognize exactly the domain of the command
they're using, and then they could abstract it away and focus on the
real command name.
Now you're saying that the s6- prefix *impedes* your pattern recognition
and detracts you from easily mapping the command name to its 
functionality;

that having it is worse UI than not having it. I had not heard this
before, but it quite makes sense.

The number of executables is a choice; I like to have more, smaller,
executables than less, bigger ones. One function, one tool. It makes
code easier to write; this is not really for historical reasons, it's a
design choice. Personally, it's easier for me to remember several
process state change command names than all the options to chpst.
whenever I use chpst, I always need to check the doc; when I use
something like softlimit or setuidgid, I may need to check the doc for
specific options, but I always remember which command I want and its
general syntax. So, I suppose it comes down to individual preference
there.

Would a generic "s6" command, that takes alternative syntax and rewrites
itself into "internal" commands, help? It could emulate runit syntax,