Hi Thierry,
Sorry, I'm catching the discussion a bit late. I think you should study
the design of GNU Guix.
It solves your dll problem by using content-addressable storage. For
example, my fish links to:
ldd (which fish ) | grep libc
libc.so.6 =>
/gnu/store/mprrfhb2cq6dwsxf6pgj1zmjincd4x5h-glibc-2.41/lib/../lib/libc.so.6
whereas my bash links to:
ldd (which bash ) | grep libc
libc.so.6 =>
/gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/libc.so.6
because I updated the former when I updated my home environment, and I
have yet to update my whole system.
The hash before the package name is the hash of (the source-code + the
hash of all the dependencies) so that if any bit changes, deep down in the
dependency of your compiler's compiler, your hash changes as
well.
The way this works seamlessly is by creating a bunch of symlinks in your
PATH, it is ugly, and I think Plan 9 style user namespace would be
immensely better.
To address your second point about building privilege, guix solves this
by building software in a completely isolated container (this is for
reproducibility as well as security). This build is managed by a build
daemon that was recently made rootless
https://hpc.guix.info/blog/2025/03/build-daemon-drops-its-privileges/
still, the container machinery has many ugly edge cases, and under Plan
9 those would be handled by namespacing.
All-in-all, I think GNU Guix is the cleanest Linux distro out there (no
systemd, by the way), and while it is not as clean as Plan 9, that's
mainly because it lacks most of the affordance of Plan 9's kernel w.r.t.
namespaces.
<[email protected]> writes:
> I stumbled upon this by accident, but I think it is also one example
> showing that both Plan9 and Nix are a good solution, because "simple",
> to complex problems leading to too many features in one kernel.
>
> Cgroups stands for "Control groups", and is a feature implemented in
> the Linux kernel and that aims to allow a policy of resources usage
> (CPU, memory and so on) for a group of processes.
>
> It rings at least two bells for me:
>
> 1) From the Wikipedia page: "Both versions of cgroup act through
> a pseudo-filesystem": the Plan9 principle to push the Unix underlying
> principle of "a lot of things appear as files" to its completeness
> has invaded a lot of Unix kernels as can be seen here. One can add
> that the concept of namespaces is a simple way of setting a define
> set of resources to processes;
>
> 2) The problem is still that there is only one kernel, with features
> that are supposed to fit them (processes) all. Instead of trying to
> handle the complexity in one kernel, the solution to keep a
> kernel simple but with running different kernels on different cores
> seem far simpler.
>
> On a related thread of thought (comparing Unix and Plan9), having to
> update an Unix node I faced once again the "dll hell" (the dynamically
> shared libraries on Unix are only slightly better than the dll hell on
> Windows, since, contrary to what was/is advertised, the naming of the
> libraries or the administration of third party softwares generally
> involve, to play it safe, when one wants to upgrade some software
> depending on some shared libraries, to upgrade all the programs using
> this shared library because the packaging system insists that
> only one version of the dso exist on the system---mainly because to
> keep track of some "package" installed, since different versions would
> try to put some files at the very same place, there is only one
> version allowed.
>
> When a browser depends on gazillions of shared libraries,
> even upgrading one tiny thing in a corner leads to hours or even days
> of rebuilding...
>
> But this nuisance is not the problem I wanted to discuss. The problem
> at foot is that, generally, external software is added in root reserved
> directories.
>
> So, whether you run everything as root, including
> compiling, to avoid having to type the password other and other
> again when installing; or you compile as an unprivileged user and
> promote to root only when installing---but then the process halts at
> every installation to ask for the password.
>
> I know that one solution is to build everything in an unprivileged
> sandbox. But it takes time to get it right, and to use the packages
> created one has to be sure that everything fits the outside the
> sandbox environment.
>
> So I asked myself if there was some mean to do the reverse from
> "starting as unprivileged and then promoting": starting as root and then
> degrading to unprivileged, emerging back to root only when needed (hence
> without having the burden to give a password).
>
> The only possible answer I was able to think of, would imply the
> (Unix) sticky bits on some programs (whatever program having to
> deal with configuration, compilation or even a special shell or
> compilation script that will propagate "nobody" or "joe" to what
> it calls and doing everything except installation).
>
> Now, comparing to Plan9 / Nix: I could imagine running a core with
> lower privileges: a "vulcan" (typically a compilation/building core).
> But would then be some sense in using the file modes to indicate this
> kind of restricted privileges for a program? Or, when such programs
> are binded in the namespace, offered by some server, accessing/exec'ing
> the programs will launch automatically a dedicated CPU core, with lower
> privileges?
>
> If someone has thoughts about these subjects, or can point me to
> existing related papers, I will with gratitude read these contributions!
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M4225b7025cbe89281dcdc203
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
