14 Jun
2024
14 Jun
'24
12:54 a.m.
On Thu, Jun 13, 2024 at 2:39 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
On Thursday, June 13th, 2024 at 9:47 AM, Arrigo
Triulzi via TUHS <tuhs(a)tuhs.org> wrote:
I agree about the lack of choice, but I think the reasoning here shows
a bit of an impedance mismatch between what systemd is, and what
people think that it should be. In particular, it left merely being an
"init system" behind a long time ago, and is now the all-singing,
all-dancing service and resource management platform for the system.
That's not a terrible thing to have, if the goal of your system is to
be able to, well, run services and manage resources. But is systemd,
as an expression of that idea, a good thing? I don't really think so.
My arguments here tend to be somewhat vague, but I do believe that
there is valid criticism beyond just, "It's new! It's different! I
hate it!!" Portability is a good argument.
Where I think many of the arguments against systemd break down is by
dismissing the real problems that it solves; off the top of my head,
this may include automatically restarting dependent services when a
daemon crashes and is restarted. But again, just because a tool solves
a real problem doesn't mean that it's a good tool, or even a good tool
for solving that problem. I suspect much of the rush to systemd is
driven less by enthusiasm for how it does things, and more for it
being the only thing out there that solves some problem that the
distro maintainers consider important (ie, that they get asked about
frequently).
On 13 Jun 2024, at 17:39, Clem Cole clemc(a)ccc.com
wrote:
Part of what irks me is the lack of choice. Just like many outlets will use GNU
extensions to otherwise POSIX components, leaving the rest of the world out in the rain,
several bits of the Linux ecosystem have backed systemd as the one true way and are
hobbled if even usable at all with other init systems out there. User software
shouldn't have any attachment to a particular init system, it isn't meant to
provide "services" beyond run this script at this time based on the conditions
of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize
operating environments. I've seen it said elsewhere that the amount of surface area
being shoved into PID 1 can only lead to disaster. IMO systemd, was >>not<< a net
positive - it falls so many of these tests WRT to good programming and good ideas.
Binary logs, ’nuff said.
Good sysadmins live & die by grep and being able to visually detect departures from
the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal
window now.
Yours disgusted since v1 of that abomination. Are there any known attempts in the modern age to roll
Linux with something resembling research/BSD init?
Alpine Linux may come closest? And of course the BSDs still exist.
That would be a nice counter to the proliferation of
systemd. Even if it doesn't make a dent in the actual uptake, at least it'd
feel cathartic to have an alternative in the opposite direction.
There are still some Linux distributions that don't ship with systemd,
but I think they're just delaying the inevitable.
On a more meta point, there are big differences between production
server systems, user-oriented systems, and research systems. Systemd
feels very much like it comes from the first of those, to me; very
mainframe-y.
- Dan C.