Re: OT: Saving GNU/Linux FOSS in the age of Android and iOS
On Friday 04 November 2011 17:07:08 Bill Cox wrote:
> That was an excellent reply. I'll try to simplify my argument to your
> 3 points in the future.
Your original message was well worded, so please don't feel constrained by my
need to summarise everything.
> I've looked at Klick and the author's new project, and various other
> projects. I think Zero Install has the most complete vision, and some
> code, users and experience. The current state of Zero Install
> unfortunately has various limitations. For example, it only addresses
> ease of installation, not how to find packages.
This is relatively easy to overcome in comparison to the technical issues
already solved by the project.
> It does not address the need for developers to share libraries with each
> other. It's only for installing applications you can run directly.
I imagine that there are fewer benefits in only deploying libraries, despite
the fact that this would be useful for people just wanting to save time
building packages from source. Naturally, moving in this direction results in
taking on more of a role of a traditional package/dependency manager which
the project developers might want to avoid. That's why I think it is natural
to grow existing package/dependency management systems in the direction of
providing conveniently installed applications in the way you would like.
[...]
> They leave the job of building a cross-linux installable package to the
> user, though they have a helpful wiki. Basically you have to compile all
> your depended libraries from source on some old linux distro and link
> statically. It's not exactly an ideal solution. However, I think they have
> many of the right ideas.
Build process automation is where existing solutions can help out a lot,
potentially. Nobody should be left to build tens of different components
using a special (and quite possibly manual) process, just to produce a
package for something. There are similar issues with embedded systems
deployment where the choices available have traditionally been to either use
an inferior build automation system and hope everything builds and runs, or
to do everything yourself in order to ensure that it works.
[...]
> I agree. There's no technical reason I can see why such a system
> couldn't run on servers like we have at my work running Debian Lenny,
> which would allow people to run a lot of apps without bugging our IT
> guy.
There's always an argument about the behaviour of applications (whether it
does bad stuff on the network, for example), but this is where end-users
could be usefully liberated. In some environments the end-user either gets an
ancient version of an application installed after some time from a system
package, or they have to install everything from source, even though a more
recent version may have been packaged independently for their distribution.
[Interesting ideas that I'll have to read again and digest]
> All good points. Thanks for the discussion. I am in fact interested
> in building or helping to build a new cross-platform packager and
> package installer. The first application I would like to support is a
> new cross platform text-to-speech engine I'm helping develop. The
> output of the packager could be .deb and .rpm files, to take advantage
> of the systems already there in the different distros, but the
> binaries would be portable between Linux distros as much as possible.
> I might be able to work with the Zero Install community, but it
> remains to be seen. Frankly the greatest risk factor in such a
> project is me. It's a huge project. I'd rather join a project and
> help it succeed.
I guess we could see what has already been done in, say, Debian. I've played
around with some different ideas related to debootstrap and fakechroot/chroot
(and also User Mode Linux). That may seem like overkill - replicating a
complete system, even a minimal one, just to install libraries and
applications as a non-root user seems like a waste of space - but I can't see
any really good ways of shoehorning existing packages into other locations
than those they were built for.
Paul
Reply to: