Re: OT: Saving GNU/Linux FOSS in the age of Android and iOS
That was an excellent reply. I'll try to simplify my argument to your
3 points in the future.
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. It does not address
the need for developers to share libraries with each other. It's only
for installing applications you can run directly. While it works on
Windows and Mac to some extent, it's a lot like git in that much of it
is script based and assumes you're running on a GNU/Linux system. I
would prefer better cross-platform support and an architecture more
like mercurial (as opposed to git) which uses cross platform tools and
avoids GNU/Linux scripts. 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.
> One major pitfall of many of these approaches is that an end-user without
> administrative privileges is often excluded even from installing applications
> made available in this way. I have investigated various approaches involving
> actual Debian packages and fakechroot in order to empower non-root users, and
> I think that such considerations would have to be part of any eventual
> solution.
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.
> To an extent a chroot solution will only get you so far, in my experience, as
> there can be other factors that make libraries incompatible. And I guess that
> initiatives such as LSB only go so far to preserve binary library
> compatibility, anyway. It also seems to me that build tools have become more
> in conflict with packaging tools over time, but I'm sure there are many
> people with Debian packaging experience who can relate more detailed
> experiences about such matters than I can.
Now in reality, I doubt any of my specific ideas are going to be the
bases of any sort of solution, so I don't want to debate my
theoretical solution too much. However, I was thinking that when
packaged, the version and hash code of every library and file used by
the application would be recorded. The application would specify what
depended libraries it was picky about keeping the same, and which
could be upgraded, probably with the default no-work option being that
everything had to be exactly the same. So, by default, you'd get the
maximum disk bloat, but minimum library compatibility problems. If
you're smart, you probably specify that you have some flexibility in
your Qt library, X windows, Python interpreter, Java JVM, etc, so you
don't bloat the disk with hundreds of megabytes of obsolete libraries.
If users run into problems, they would have the ability to switch any
or all of an applications depended libraries to the version used
originally. This sort of thing could also be useful if the user
wanted to use a non-standard version of a major library like GTK+. It
would be awesome to be able to select which branch or fork your system
uses by default. You should also be able to use the version provided
by the distro through the existing native package system.
> On the subject of finding applications:
>
>> We need a cross-distro App Center, where software can be published
>> with zero or minimal review, and then run on any GNU/Linux platform.
>> There has been efforts in this direction recently. The Zero Install
>> guys are making good progress, for example. There was a meeting
>> recently where various distros discussed a cross-platform package
>> installer, but it ended in everyone agreeing to continue with business
>> as usual with a band-aid on top that wont make any difference.
>
> I think Zero Install is an interesting solution, but I also think that it
> would be beneficial to leverage existing packages. Here, we need to separate
> the orthogonal concerns of packaging, distribution and installation. As I
> noted above, if it merely becomes possible for an unprivileged user to
> install proper Debian packages in a sandbox, then significant benefits are
> already gained: in many cases, the alternative to such users is a build from
> source of a hierarchy of dependencies or to use an inferior solution like
> easy_install (the Python package installer), which means that they are
> already missing out on existing distribution facilities without even
> considering the universe of unpackaged software.
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.
Bill
Reply to: