software - multiple version installs (any distro developers here?)

Sean Lynch seanl at literati.org
Tue Aug 23 14:56:39 PDT 2016


On Wed, Aug 17, 2016 at 3:38 AM John Newman <jnn at synfin.org> wrote:

>
> > On Aug 17, 2016, at 3:12 AM, Tom <tom at vondein.org> wrote:
> >
> >> On Wed, Aug 17, 2016 at 01:30:17PM +1000, Zenaan Harkness wrote:
> >> A major distro heading that way (e.g. Debian) might encourage developers
> >> to increase the configurability of their own software perhaps?
> >
> > Developers != distro|package maintainers, and free software should be
> > portable and not distro specific. So, developers wouldn't have anything
> to
> > do here, only maintainers.
> >
> >> Ahah! Yes so we need a new default packaging/ installation format to be
> >> supported by RPM and DPKG, to support the better way, e.g.:
> >
> > https://xkcd.com/927/  :)
> >
> >> So look into /var/lib/dpkg/info - that's heading for 9K files on my
> >> system - and this is a relatively fresh install (<12months)!
> >>
> >> That's not human friendly.
> >
> > Because humans are not the intended audience for this stuff.
> > Use dpkg -l [| less or the like].
> >
> >> The point is just multiple versions parallel installs, that's all.
> >
> > There are already solutions for this, e.g. look at PC-BSDs packages.
> > Or use a container. Or compile yourself and
>
> Docker might be a little big for every binary in the system ;).  I tend to
> agree that the base system is ok without being a bunch of symlinks, but
> doing something like this for /usr/local does work great on OSX with
> homebrew (which is written in ruby btw)
>

 +1 for Homebrew on Macs, but then you're using a Mac ;-)

There's also Nix and its GNU NIH copy Guix, which can be installed in your
homedir or /usr/local on most Unix-like systems. They both have the added
advantage of having any number of separate "profiles" (i.e. symlink farms)
for building packages, doing day-to-day stuff, etc. And since they modify
the system monotonically, you can always roll back packages (but not any
non-versioned state) semi-atomically, take snapshots (which you could do
with ZFS anyway), etc.

"Docker for everything" is not a totally off the wall idea. Not
specifically docker but namespaces & cgroups for making software that's
used to Unix-like discretionary access controls and make it act more like
object-capability software. You'd need a UI or shell or something for
expressing what capabilities to pass along, for example something that
interprets annotated filenames, converts them to filenames in the process's
own namespace, and handles mounting the files into the process's namespace.
Of course, then you're probably just reinventing SELinux or something,
though I do think there's potential there to make the user interface a
little less obtuse than SELinux policies.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 3336 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20160823/e1fb0dfd/attachment-0002.txt>


More information about the cypherpunks mailing list