[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The ๐ Shepherd gets a service collection
From: |
Maxim Cournoyer |
Subject: |
Re: The ๐ Shepherd gets a service collection |
Date: |
Tue, 14 Mar 2023 08:20:07 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Ludo!
Ludovic Courtรจs <ludo@gnu.org> writes:
> Hello Guix!
>
> I pushed some changes yesterday that confirm that the Shepherd paves the
> way for init system innovation, synergistic cross-domain fertilization,
> and delimited continuations:
>
>
> https://git.savannah.gnu.org/cgit/shepherd.git/log/?id=31d21fa083872d500c016b6b3b2587d25510702d
>
> 31d21fa * Add REPL service.
> cd6f3fb * comm: Add 'open-server-socket'.
> c64804f * Add resource monitoring service.
>
> These new services are built into shepherd, allowing users to control it
> and to fiddle with it. The REPL is functional but of course a bit
> bumpy: youโd better know what youโre doing.
>
> I imagine we could develop more convenient services like this, such as a
> basic command scheduler similar to the โatโ command, and a syslogd
> implementation. The latter could be nice for a couple of reasons:
> logging would happen from the start and till the end (an improvement
> over the external syslogd process), and it could let us provide a nicer
> user interface to view logs (taking inspiration from that of
> โjournalctlโ).
>
> Thoughts? Ideas?
While I also find the journalctl interface to be convenient, the
underlying database logs is costly in terms of storage and complexity (I
remember comparing it to a simple, non-compressed text file, and to my
surprise the later used less space even the systemd logs are supposed to
be compressed, if I remember correctly). I think it had to do with all
the keys having to be stored for each message, even when they don't
contain anything useful.
It'd be nice if Shepherd didn't end up with that same caveat, should
database logs be implemented.
Thanks for improving Shepherd!
--
Maxim