[GoLUG] Mailing list, long term.

[Kyle Terrien]

On Wed, Aug 20, 2025 at 06:36:04PM -0400, Steve Litt wrote:
> 
> On Wed, 20 Aug 2025 13:13:23 -0700
> Ron <ron at bclug.ca> wrote:
> 
> > Steve Litt wrote on 2025-08-17 20:21:
> > > 
> > > I investigated a heck of a lot more alternatives than the systemd 
> > > people did. They investigated sysvinit and upstart, and called it a 
> > > day.  
> > 
> > Citation on what they investigated?
> 
> https://0pointer.de/blog/projects/the-biggest-myths.html
> 
> upstart and sysvinit are mentioned, runit and OpenRC are strangely
> absent. This is one of hundreds or citations that adopted this same
> false choice, but it's as easy for you to look up these 2011 to 2016
> pro-systemd discussions as it is for me.

I semi-regularly think about how runit and OpenRC are never mentioned
in the comparisons and systemd promotion material.  It’s too bad.

> > And yet multiple teams of Linux experts at Canonical, RedHat, etc.
> > were looking to replace it.
> > 
> > Who are we to think has greater knowledge on the topic?
> 
> Me. Seriously. The inability to distinguish between PID1 and the
> service manager/supervisor shows them to be either idiots, or
> for-profit Linux companies wanting to profit from the
> hypercomplexification of Linux.

I have asked Red Hat people why they didn’t delegate the service
manager to a separate process, and the response was that such a design
would break inheritance of SELinux and cgroup contexts.  A service
manager would need all the privileges in order to setup SELinux and
cgroup contexts of services.

Now, I don’t understand all the reasons why separating a service
manager from PID 1 is permanently incompatible with SELinux and cgroup
inheritance.  One would think that one could run a service manager in
a super-privileged context.  However, I have never written a service
manager, so there are many things about the problem domain I do not
yet understand.

I do, however, believe there are better ways to do security than the
current incarnation of SELinux.  (AppArmor is pretty good, and usually
services run in containers anyways nowadays.)  In general, if the
security tools prevent a better and more secure design from
developing, then usually a better security architecture is required.

-- 
[*] Kyle Terrien
    Terrenus => from the Earth, to the Cloud
    https://terren.us/

Dilexisti justitiam, et odisti iniquitatem.  -- Psalmus 44:8