[gobolinux-users] Great Work! Some comments, questions, and suggestions

Joshua Sako jginsu at gmail.com
Sun Dec 17 23:34:09 UTC 2006


Hello,

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 
irritating.

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:

[Required]
libFoomatic

[Recommended]
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:
Addons
Minor fixes (spelling errors, pixmaps, etc).
Multiple disk installs.

Addons
-------
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.

Minor fixes
-----------
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 
user's system.

That's all I have, really. Great work on the system! It's very nice!


More information about the gobolinux-users mailing list