[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [olpc-software] On installing software
- From: Mike Hearn <mike plan99 net>
- To: David Zeuthen <davidz redhat com>
- Cc: olpc-software redhat com
- Subject: Re: [olpc-software] On installing software
- Date: Tue, 28 Mar 2006 21:30:23 +0100
OK, so here are some more thoughts :)
Firstly a couple of cosmetic issues - why LaptopSoftwareManager instead
of a more generic name? It might be useful elsewhere (though I
appreciate that this raises interesting political issues). The ".app"
extension is already in use by MacOS X and ROX Filer, and people who
wish to distribute cross-platform software on the same media might find
that a bit annoying. A wider name might be better as you could use such
bundles for themes, screensavers, wallpaper packs, etc - stuff that is
"software" but not an application. Maybe .software .bundle .box etc?
I question /usr/local instead of /usr for software :) Historically
installing "non distro stuff" to /usr has prompted massive flamewars,
IMHO out of all proportion to its importance, given that it's just a
file path. Nonetheless this involves adapting possibly large numbers of
programs and even libraries. Why not use /usr - the daemon doing the
symlinking can ensure nothing is overwritten or modified, and it solves
the problem of needing to modify lots of software.
PINs? Why PINs over more easily remembered passwords? :)
The problem of malware, stopping programs installing software themselves
etc is a ridiculously deep one .... why would a program need to trigger
the installation of another program if it can just include the malware
itself, for instance? Why not just screw around with the .bashrc or the
session manager or gconf? To prevent applications installing other
applications (which might be a desirable feature in some cases!) I don't
think we need any user interaction - DBUS security policy can be used to
say things like "Nautilus can whitelist apps, the 'Manage 3rd Party
Software' applet can whitelist apps, nothing else can". X security can
stop programs trying to "remote control" other apps (though there are
other possible attacks).
File conflicts are a tricky problem but one that's important to deal
with IMHO, given that there would be no sysadmins around to fix things
when they go splat :) My proposal involved a "stack" of software, but
that's more an artifact of how union mounts work than anything else. If
you look at the files that actually need to be linked to /usr/local then
they are only files important for desktop integration - icons, menu
entries, online help and so on. The applications private files don't
matter. In many cases the actual file names on disk don't matter either,
for instance .desktop files can be totally randomized and GNOME doesn't
care. So the daemon could easily randomize some filenames as they are
symlinked to reduce the problem of conflicts. Library sonames are a much
harder issue, but that's what the platform is for. And executables
probably don't matter as their name is only meaningful to humans for
end-user apps, so they could be tagged with -1 -2 -3 etc by the daemon
(or not symlinked at all, and then the user has to tab complete the path
to the appdir).
On dependencies - I'm not sure duplicating package manager dependency
checking logic in such a daemon would be a good idea. There are several
models of dependency checking, some radically different to others. For
instance autopackage has a very rich dependency checking API, which
scans the system looking for clues as to what interfaces are actually
implemented autoconf-style. That's very different to something like
dpkg! One way to solve this is to say that OLPC apps cannot have
[library] dependencies at all, this is what MacOS X does and it's end
users love it as it's so simple. On the other hand this can be
inefficient and we have tighter efficiency constraints and more modular
What to do about dependencies is connected to how appdirs are
distributed. You suggest a .app.tar.gz format, but:
a] IMHO .tar.gz is a poor archive format :) You can't randomly seek to a
given file like you can with .zip, and gzip is not good compression
compared to LZMA.
b] You'd end up redefining RPM/dpkg but using META-INF entries instead
of headers/whatever dpkg uses (in fact .debs are tarballs aren't they?),
and not gain much.
c] Such a thing would be OLPC specific, reducing the efficiencies of the
mass market and making it harder for Joe Linux Developer to contribute
(he'd need to take time to develop a package for a platform he probably
I think there's nothing wrong with representing apps as appdirs
internally, and that'd be quite convenient. And when you know you're
swapping stuff with another OLPC laptop user you can of course just
transfer the appdir directly. I'm less convinced it's the right format
for general purpose distribution. Apple took this approach and ended up
with piles of hacks (internet enabled dmgs, safe content, etc) and they
don't have to worry about a fragmented distro space or dependencies!
Nowadays much of Apples own software comes in their .pkg format, which
is a simplistic equivalent to RPM.
So what I'd propose is some intermediate format that is recognised as an
AppDir, then converted to an _actual_ expanded appdir as it's being
installed by LaptopSoftwareManager. That appdir can then be moved
around, deleted, shared over the network, sent to other users etc as is
wanted. The intermediate format could be anything - rpm, deb,
autopackage, zip file, tarball .... this email is a bit long already but
here are what I think the selection criteria should be:
* Already existing. Seriously, a container for software is not a very
complex thing, the hard parts are how to manage its interaction with
other containers and what's inside the container :) Any new format would
have to reinvent most of that, so there'd need to be a clearly
* IMHO they should work for users of "normal" Linux distributions too.
It's just a gut feeling but I think there would be more software usable
on the laptop if developers can simply be told "do what you normally do,
but faster and with fewer resources" rather than requiring them to set
up VMs, complex SDKs, etc. That means maximizing their return on
investment, eg, the more users can hit with their work the better.
* It should be easy to evolve as eg, better compression algorithms are
invented, the platform is modified, mistakes are made and must be worked
* Should be nice for end users and developers, have nice tools and GUIs etc.
I'd argue that autopackage meets all those criteria, no surprises there,
but it could be argued that other formats would too.
[Date Prev][Date Next] [Thread Prev][Thread Next]