On 1/23/21 6:59 PM, Yasha Karant wrote:
Does in fact SystemD provide for encapsulation and isolation, as in a
proper OO design and implementation? Could not a "proper" sysadmin
interface be constructed to configure SystemD, rather than the
"hodgepodge" of what seem to many as arbitrary and capricious
incantations? These questions are not posed as divisive or derisive,
but instead requesting information.
Hrm. That's an interesting question. I may need to think about that more.
My initial response is that it could be tweaked to allow that to a
point. I can configure $application1 to be set into a kernel cgroup such
that I can constrain it and isolate it in terms of both resources and
things it can talk to. However, there are still some level of kernel,
cpu, memory, disk, logging requirements that will require $application1
to interact with the low level services.
However, when I think about how various services work then there needs
to be a lot of communication between applications. For instance, I've
got a bunch of machines at work that use the big Nvidia GPU's. One of
our researchers has code he's developing that sometimes will dead-lock
the GPU's. The only way we've been able to get it unstuck is a reboot.
And because we have had issues with the bleeding-edge development NVidia
drivers, we've found that it's best to purge the drivers on shutdown,
then reinstall fresh. Well, I don't want to do that manually. So when I
tell a system to reboot, I wrote systemd code to ensure that the driver
is purged before shutdown.
When the server starts, my systemd code checks for nvidia. If it is
there (a power or hard reset didn't run the code on shutdown), then it
yanks the driver and reboots. When it starts up and it isn't there, it
waits on network. Then it waits for DNS services. Then it fetches the
latest driver in our repo. Then it builds the driver and installs it.
Then it verifies the driver is successful in loading the GPU. Only then
does it finish the boot process.
In that one systemd script alone, I'm talking to a half dozen services,
the kernel, and hardware. Could I shove all of that into hard isolation
and encapsulation? Um...I'm not sure. There has to be a communication
layer that breaks that isolation somewhere.
Could I do that without systemd? Absolutely. I did similar stuff like
that long before systemd with scripts that were WAY longer and WAY
gnarlier because I had to write all the test cases for failure and
waiting myself instead of just telling systemd "Hey, let me know when
this service is working."
And that's just not even talking about Desktop... When you get into the
fancy notifications that you've received an email, or the music changed
to a new track, or that there was a security alert, or that you have
packages to be updated, or yadda yadda yadda the list goes on when you
talk about Desktop level notifications. Everything that the UI has to do
for all those fancy shiny integrations... I don't think it really could
be isolated. Although if you allow for systemd to handle all
communication then isolate the rest then yeah...that's kinda the point. :-)
Maybe someone who still gets down into the internals regularly might be
able to answer better and more clearly then I did. Hopefully I didn't
ramble too much! :-D
Oh, also. To your point about a better language choice potentially
solving some of these issues (I snipped it). I will say it's been ~15
years since I last did anything with language theory. I'm not someone
who can really argue for or against these things. However, I do know
that part of the drive for people to write more Rust code in the Linux
kernel itself is to use Rusts type safety / memory clean up / ect as a
measure against some of the issues that have occurred because of the C
foundation. I'm not arguing for or against, just saying that this
conversation is on going. Similar for Go, but ohh...I've got some love
and hate for Go and will spare you that rambling rant! :-D
~Stack~
