[gobolinux-users] Idea for Gobolinux binary distribution

[Rayne Van-Dunem]

Good points. A few questions:

1) Is the "third-party application" older than the "distro software
repository" model? Considering that most Linux distros retain various
measures of similarity and compatibility with the legacy Unixes (Unix being
a system from the 1960's), I've always wondered if the software repository
model is inherited from Unix as much as, say, X11.

2) The main reason why I came up with this idea was because of how Mac users
(on Digg, for example) always make an event out of some new application for
their "platform", or if there's a fresh, optimized rebuild of Firefox for
Mac that is "twice as fast", or something like that. Same goes for Gentoo
users, who also have third-party support, but have the most Macuser-like
character ( "wow! this optimized binary is blazing
fast!"<http://www.funroll-loops.org/>).
Debian also has much more extensive, and sometimes corporate, third-party
support (due to their slow release cycle), but their DFSG prevents the
distro from taking in most third-party apps.

I mean, when I talk about third-party applications, I'm not necessarily
referring to non-free, proprietary software. Of course, most people tend to
associate them with someone like Adobe or Real Mac Software or Microsoft, as
they are among the most notable software houses, but that's far from my aim
since their software is made for specific platforms, some of which they care
for more than others; plus, non-FOSS software runs against the overall
interests of most Linux distributions. Rather, I'm referring to people who
take out of their free time to create a FOSS application for Linux,
especially for a specific distribution of Linux. Often, its those apps (like
Kuroo, a KDE-based graphical frontend for Portage on Gentoo) which fit
better into the mold of a specific distribution than the cross-platform ones
(like Firefox).

I think that if they, who are statedly not part of the overall distribution
maintenance, can develop an application that works specifically for or with
that distribution, and others are notified about this (say, through Digg),
it makes the distribution look and feel more like a complete operating
system with more to offer than just another distribution with a GUI that's
used by over 300 others. For instance, Ubuntu (around Hoary and Badger) felt
extremely constricted because of how the availability of apps (Firefox, for
example) moved dog-slowly; it left a bad taste in my mouth before I went
back to Windows. However, beginning later this year, I began to see third
party sites (such as  EasyUbuntu) which were dedicated to making third-party
non-reposited apps available to the Ubuntu-using public (instead of the
rabid Ubuntu advocacy that had been present for quite a number of years); my
respect for Ubuntu was finally, though partially, restored. For *once*, it
was being supported by other people than just the Ubuntu Foundation.

So, to sum it up: more third-party application development and support, more
street cred for the distro.

Now, you may be right about how third party installs can't be seen as being
as trustworthy as a distro repository install. This is made known to me, as
a rule, every time I install a Firefox extension from someplace other than
addons.mozilla.org. However, I think that third parties can be valuable to
the distro because they can provide better or more foresighted solutions and
applications which often aren't present in the distro at its present state.
Yet, there have to be bridges for active dialogue between the third party
developers and the distro developers: make the app or plugin available to
the repository, or, if it can't be put in there for any reason, provide a
link from the distro site or server to the alternate repository (plus, the
third party devs *have* to be familiar with and actively engaging this
distro).

That last thing you mentioned, about the all-in-one binary, might be a very
agreeable solution, especially for desktop environments/window managers; in
fact, I think it would be good from a low-key distro's standpoint if they
don't plan to make any major modifications to the overall intercafe of the
DE (such as the addition of distro-specific applications or manhandling the
interface in order to get your corporate brand across).

Speaking of all-in-one's, I'm wondering if there is any initiative in the
Linux world for better XUL support. If Mac OS X could bring in Java as a
"first-class citizen" API/toolkit, why can't Linux bring in XUL with similar
embrace? It's gaining greater tread as a development platform (not just from
Mozilla, mind you, but also from the developers of Songbird and Democracy
Player, which make *heavy* use of XUL), it has the attention of web
developers (everyone and their mother has some Firefox extension, or
Greasemonkey userscript, or Stylish CSS hack, and so forth), and Firefox is
currently the star app from this platform. But Firefox - or any other XUL
app - on any existing platform - be it Windows, Mac, or Linux - runs slow
(with memory leaks every 10th tab) due to its Java-like cross-platformism,
which doesn't take into account the native toolkit(s) used on each platform
- Mac with Cocoa, Linux without or GTK+, or Windows with MFC. XULRunner may
allow for better portability of other XUL apps, but it won't solve the
problem of non-integration into the GUI. I mean, should a XUL toolkit for
X11 (or, if possible, a different windowing system) be developed separately
from Qt and GTK+? It would immensely help for and improve the Firefox - or
IceWeasel - user experience on most Unix-like systems.

Just some more thoughts.

Rayne

On 10/17/06, kenneth marken < k-marken at online.no> wrote:
>
> Rayne Van-Dunem wrote:
> > I remember that, besides the file system heirarchy, one of the biggest
> > debates concerning the majority of Linux distributions revolves around
> > the installation of non-reposited third party (and distro-agnostic)
> > application packages. Of course, you already have several projects
> > which are committed to a metapackage solution, but the verbal sludge
> > slung between Autopackage and the major distros (including the Ubuntu
> > Forums, if I can recall directly) is old news.
> >
>
> isnt the biggest issue here the collection of libs alongside the app, vs
> having libs as seperate packages? ok, so autopackage can handle both
> things. but in the end you either have to design a distro around
> autopackage or you have to keep two seperate databases of installed apps
> in sync.
>
> but then i have never realy payed much attention to the whole
> autopackage thing.
>
> > However, I just wanted to put out to the mailing list an idea that
> > I've been having for quite a while concerning binary compilation and
> > distribution. Dunno if the devs would try this out, but here goes:
> >
> > Mac OS X (to which Gobo has been likened in some aspects) is known,
> > among other things, for its binary format (.dmg). However, I've
> > realized, by reading and re-reading the Wikipedia article, that ".dmg"
> > isn't actually a binary format, but more like an application
> > equivalent or akin to a virtual "LiveCD". The actual application's
> > binary form "Blank.app" is inside of the .dmg (or "disk image"); the
> > .dmg, when downloaded, is "mounted" as a virtual disk drive inside
> > Finder, and serves the primary task of transporting the inside binary
> > from point A to point B.
> >
> > My suggestion is this: can a system that does the same thing be
> > developed for GoboLinux?
> >
>
> sure, and i belive it have been talked about before, both here on the
> list and on the forum. in either case i think the consensus is that you
> end up with a union mount or similar thats just as "ugly" as the
> /system/links solution ;)
>
> all in all, the effort just isnt worth it at this stage.
>
> > Here's what I'm thinking: A user can download Firefox.livecd from the
> > Gobolinux site or a third-party Gobolinux mirror by clicking on the
> > link and downloading it from the web browser. Then an application like
> > Manager will pop-up and show you the virtual LiveCD that you've just
> > downloaded with all the files that came along inside it. However, you
> > can have the choice of running the application in the virtual LiveCD
> > without installing it by virtually-mounting the LiveCD. Then Manager
> > will run the virtual LiveCD's recipes so that it will run just like a
> > LiveCD (or LiveUSB, which I'd definately prefer) for as long as you
> > have the LiveCD in Manager. Once you tire of it, you can just drag the
> > LiveCD out of Manager and Trash it (or whatever else you many want to
> > do with it). You can copy it, send it flying through the Internet's
> > tubes to fellow Gobo-using friends (pending if they can clean up the
> > clogs first :-P ), post it to your site, *anything*, and they'll be
> > able to run the .livecd file with similar ease.
> >
> > Just an idea. Plus, major inspiration for it came from
> > Portable-Apps.org and the growing number of USB-portable apps for
> > Windows and Mac (as well as the number of bootable LiveUSBs with Linux
> > distributions; but what about portable USB apps for a Linux
> > distribution?).
> >
>
> ill take a fully bootable livecd or liveusb distro over just the apps
> any day. this because then you can use any computer without the need for
> a compatible os ;) in effect you have your fav os in your pocket,
> complete with a desktop if you combo a livecd with a usb stick that you
> store the home folder on.
>
> the problem with the software repository style of most linux or bsd
> distros out there isnt that its hard to use. what it is a alien way of
> thinking compared to what windows and mac users are used to. rather then
> going to download.com, snapfiles or tucows, they have a allready
> prepared list of software sitting on their desktop. and with that comes
> added security.
>
> remember, with closed source software like what you get from third party
> suppliers you not only have to trust your os supplier, but the software
> site and the programmers of whatever software your downloading.
>
> with a software repository run by the distro, you can trust that any
> software you get from there. this added on top of the general benefits
> of open source.
>
> this as long as we are talking allready compiled software atleast as
> someone working for the distro will most of the time have had to compile
> it.
>
> gobolinux recipies are in a gray area as they pull the source from the
> original programmers distrobution site. so by compiling from recipie
> your betting that noone have stuffed anything into the source between
> the time of the recipies creations and the current compile.
>
> but back to the original point. that windows and mac are supplied by
> downloadable third party software do not say that this is the best way
> of doing things. and people that have problems with the linux and bsd
> ways of supplying programs most of the time are veteran users of windows
> or mac. and old habbits die hard.
>
> thats allso why running desktop usability studies can be troublesome.
> you get more errors from a windows veteran in front of a mac for the
> first time or vice versa then you do with someone thats a relative
> newbie at both. this is because over time you learn habbits and ways of
> thinking that may not apply to the new desktop. and when people error,
> they are more likely to complain about the computer then themselfs. this
> even tho the computer is just a dumb machine that does a series of
> instructions over and over just like they are given.
>
> but then i put this on the shoulders of jobs and gates as they keep
> saying that the computer is for everyone, and is as simple as turning on
> the tv. sorry, but the computer is one of the most complex devices that
> the human race have so far created.
>
> in many ways, the holy grale of a computer interface will be one that is
> learning and interactive. more like a secretary then a machine. one that
> over time learns the users habbits and quirks and adapts. one where you
> dont talk about software or files but just ask the "secretary" to do a
> task and the task becomes done.
>
> but the one big difference between a real human and a computer is that a
> real human can review the task given and question its correctness. a
> computer may simulate doing this via dialogs or similar, but in reality
> is more the original programmer trying to outguess what tasks the user
> will want to try to do, and what will then be harmfull to the system and
> the user files.
>
> we all know the old story about people sorting the file types into
> diffrent folders i hope. ie, binarys in one, libs in another and so on.
>
> the fix i see is a database overload. the filesystem as one big database
> where the folders are just preset searches. on top of that you stack
> databases for librarys and similar, and a "smart install" that can forgo
> installing more then one copy of the same library file and similar so
> that updates goes quick.
>
> in many ways, the gobo way with its versioned programs and lib folder,
> its /system/links and similar is this without the databases.
>
> the only way i can see helping the windows and mac old hats in an
> enviroment like this is to introduce "collection" binary packages.
> packages that basicly wrap up multiple other binary packages into one.
> and that will check to see if any of those packages are installed before
> installing its own. that way you can have a single package for the whole
> program and libs, but retain the "ease" of upgrade that you have with
> shared libs.
>
> ugh, looks like i got into a bit of a rant. i see problems and benifits
> from both software install systems (the classical third party inatall
> files, and the software repository like most linux distros use). and i
> dont think changing the gobo software install system will help much as
> its more a culture issue then a software issue right now.
> _______________________________________________
> gobolinux-users mailing list
> gobolinux-users at lists.gobolinux.org
> http://lists.gobolinux.org/mailman/listinfo/gobolinux-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gobolinux.org/pipermail/gobolinux-users/attachments/20061017/ab4c7a67/attachment-0001.htm