Re: The "Unix Philosophy 2020" document

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

Re: The "Unix Philosophy 2020" document

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

Re: The "Unix Philosophy 2020" document

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

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

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

Re: runit patches to fix compiler warnings on RHEL 7

>>  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

Re: runit patches to fix compiler warnings on RHEL 7

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.

Re: The "Unix Philosophy 2020" document

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

Re: The "Unix Philosophy 2020" document

> 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

Re: The "Unix Philosophy 2020" document

> 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

Re: The "Unix Philosophy 2020" document

>>  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

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

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