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~