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!
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T924b170304d49c32-M03b8cee20fbd97207bc288ae
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
