[gobolinux-users] Great Work! Some comments, questions, and suggestions
jginsu at gmail.com
Sun Dec 17 23:34:09 UTC 2006
I've downloaded and took a look at GoboLinux through the LiveCD and must
say I'm impressed. I like it a lot! That said, I have a few questions,
comments, and suggestions (I hope this is the right place to posit them).
GoboLinux seems to use the original Init system. Is there any plans to
try out and possibly transition to Ubuntu's new events-based Init
system, Upstart? I've not had the occasion to use it myself, but after
reading through the docs, I like the design a lot.
Autotools is byzantine, arcane, and overcomplicated, so a lot of
projects are switching to other systems. I noticed that Compile has the
ability to use different "modes" for just such an occasion, but there is
a distinct lack of a cmake mode. Is this something that will be added in
future, considering that the entirety of the KDE software stack will use
it for now on?
I noticed some things about the LiveCD that were odd. KDE uses the (ugh)
ARTS sound daemon. This is irritating for many reasons (hopefully it'll
be dead by KDE4), but they can be mitigated greatly by having the daemon
use ALSA as a back end. I have this setup on my actual desktop. But on
the LiveCD if you try to tell KDE to use ALSA in KConfig for the sound
system, it complains that the file doesn't exist. I mucked about with
the permissions a bit, but could not find the reason (the links were all
correct). Someone should probably look into this; it's extrodinarily
Although I didn't look very far in, it doesn't seem like the installer
will preserve a user's /home directory when installing. This is
something that Mepis does, and it's _wonderful_. It'd be trivially more
difficult for GoboLinux, since you'd not only have to look for /home but
also /Users, and it greatly improves usability.
It might be desirable to alter the Dependency file format to allow for
dependencies that are required, and those which are recommended.
Ideally, a description following the dependency would be nice as well,
so users could see what functionality is missing. For example:
libPork "Adds the delicious taste of summer ham to Foo."
Regarding the way software is installed... I was thinking it might be a
good idea to add a Patches type in addition to the regular installation.
This would be useful in specific instances where it doesn't make sense
to install the ENTIRE application all over again. I can think of three
use-cases where this would be true:
Minor fixes (spelling errors, pixmaps, etc).
Multiple disk installs.
Let's consider an application like, say, The Ur-Quan Masters. UQM comes
with a set of music files generated from the original game. However,
there have been remixes of the original music also added. As it is now,
for people to chose which they want there would have to be two packages,
one with the original music files and one with the official remixes.
Worse, you'd get a huge amount of resource duplication if a user decided
to to install both!
If, instead, the remixes were considered an addon patch, there would
only be one install package. The patch package would do whatever is
neccissary to install the remixes, avoiding the unnessiary duplication
of all the other code and resources.
It doesn't make much sense to install a whole new version of a program
just to fix some minor aesthetic issue. In addition, there are classes
of programs where it simply doesn't make sense to keep an older version
around at all. One such class are online game clients; the game server
should, quite rightly, patch an obsolete client that attempts to connect
or, failing that, simply refuse to connect.
Mult. Disk Installs
Once more a game-related thing (seeing a pattern?), sometimes programs
are distributed on multiple disks. It'd sure be nice to have the
"install" disk be an install package that then daisychains a series of
patch packages on each disk to copy the entirety of the program onto the
That's all I have, really. Great work on the system! It's very nice!
More information about the gobolinux-users