> Date: Sun, 7 Aug 2016 11:58:35 -0800
> From: Britton Kerin <britton.kerin_AT_gmail.com>
>
> On Sun, Aug 7, 2016 at 11:12 AM, Kurt Van Dijck
> <dev.kurt_AT_vandijck-laurijssen.be> wrote:
> >> Date: Fri, 5 Aug 2016 13:34:31 +0200
> >> From: Hadrien LACOUR <hadrien.lacour_AT_openmailbox.org>
> >>
> >> On Fri, Aug 05, 2016 at 08:26:42AM -0300, Marc Collin wrote:
> >> > I got introduced to s6-rc [0] lately.
> >> > Do you guys have any experience with it?
> >> >
> >> > [0] http://skarnet.org/software/s6-rc/
> >> >
> >>
> >> When I compared daemontools, runit and this one, I thought it was the best.
> >> Nice comparison: http://skarnet.org/software/s6-rc/why.html
> >
> >
> > Based on these findings, I wrote rund [0], inspired by sinit.
> > It addresses my concerns, and performs better than systemd for booting,
> > footprint, RAM usage, monitoring, modification by regular programmers,
> > and operator intervention.
>
> How do you handle udev problems? I loathe systemd on account of
> it's lack of modularity (all in one process mainly for political takeover
> reasons) and idiotic binary logging. I'm not sure you're right about it
> being unreasonable to try to abstract the dependency stuff but it sure
> should not all be in the same pid.
look for 'eudev', a fork of .. udev.
This works fine, and I haven't found problems yet (I use Slackware).
For embedded systems, there's no real 'eudev' specific problem.
In the end, eudev is equally to configure as udev, I don't really
like it anyway.
I also have built systems with alternate device management daemons,
but getting Xorg to catch up with USB mouses requires patching Xorg
itself then...
>
> I'm still running it though, because it doesn't seem actually broken at
> the moment and it seems like getting rid of it would probably break
> hardware via udev.
As long as you stick with the defaults, it indeed 'seems to work'.
I had the opportunity to try it for an embedded system, and the defaults
didn't fit the requirements, so we had to change predefined services.
Ever tried to mount block devices in /var/log, choosing the block device
to use in run-time, depending on the available devices during boot?
This clearly wasn't in the systemd's developers heads.
Although it is explained in simple words: log to usb when possible,
else log to internal flash.
Kind regards,
Kurt
Received on Mon Aug 08 2016 - 00:00:54 CEST