Re: package/sharing improvement proposal

D. J. Bernstein writes:
> What exactly do you mean by ``read-only''? Why is it a useful concept?
> Is /etc/resolv.conf ``read-only''? What problem is being solved here?

 To mount a filesystem read-only: To use an option available in some
kernels, that prevents users as well as the superuser from creating
files or opening regular files from writing in that filesystem, and more
generally performing any operation that would lead to modification of
data or metadata in that filesystem.
 The Linux kernel offers that mechanism with the mount() system call ;
I honestly haven't checked whether other OSes do, but I would be
surprised if that was uncommon.

 It is a useful concept because it can give guarantees. As long as the
kernel enforces the "read-only" attribute (by making open(), link()
and friends fail if they would modify the filesystem), we have the
guarantee that no userland program, even run as root, will cause
trouble on that filesystem. (Of course, a misbehaving "dd" can still
wreak havoc on the disk, but "dd" invocation is rare on production
systems.)
 Once the boot process of my system is working to the point of
mounting other filesystems, I like to mount my root fs read-only.
That way, I have the guarantee that no matter what happens with
my processes, the system will _always_ work to the point of mounting
other filesystems.

 "Is /etc/resolv.conf read-only ?" hasn't much meaning : /etc/resolv.conf
isn't a filesystem. But it may be desirable to have /etc/resolv.conf
on a read-only filesystem (most probably the root filesystem), because:
1. on a working system, there is no reason for /etc/resolv.conf to change
2./ if /etc/resolv.conf is accidentally modified, things may break.
So the answer to your question, as I understand it, is yes.
On my server, / is read-only, and /etc/resolv.conf belongs to it.

 What problem is being solved by supervise ?
 Apart from svc, which is added comfort - but just that: comfort. There
is no real *need* for svc - supervise doesn't solve any problem. Programs
aren't supposed to die unexpectedly, and respawning is trivial with a
one-line shell script.
 If you wrote supervise, it's because the world isn't ideal: programs
may die. supervise (more precisely: an uninterrupted supervision chain
from process 1 to supervise) is just added reliability to a system.
 Mounting filesystems read-only when possible is another step towards
the same goal: adding reliability to a system.

-- 
 Ska