Submitted by “GoboLinux is a unique distribution in many ways. It’s built from scratch following the Linux From Scratch procedure and uses custom boot scripts, personalized directory structure, and a simple yet comprehensive source-based dependency-resolving package management system. GoboLinux is perhaps best known for its alternate filesystem hierarchy. Unlike Linux’s traditional Filesystem hierarchy, where a program has bits and pieces scattered in several places like /etc, /usr/bin, and /usr/share, each program gets its own directory tree under GoboLinux.”
Gobolinux team is doing great job. They are creative and taking new stand. GL is making average users’ life easier by a simplified directory structure, almost similar to Mac installations.
geeks, don’t bash GL for slow performance, breaking filesystem tradition, only symlinks etc etc. Don’t be envious because you didn’t get this idea of filesystem before. The whole purpose of gobolinux is to remove scarey part of intricate linux mechanisms from the mind of new users. I think Ubuntu guys should learn something from GL instead of putting old wine in new bottle….
Edited 2007-02-15 15:35
I keep thinking about it, and Ubuntu could actually go that route in the future. There are three options as I see it:
1. Repackage everything. Horrible Long Process…
2. Rewrite dpkg to handle it (since dpkg is underneath every package management piece on Debian and Ubuntu). Only problem is that it’s a very integral part of the Distro… convincing people to change it wouldn’t be fun.
3. Write a wrapper around dpkg to monitor reads and writes and instead put the files in the appropriate places. Downside is that this may be too difficult to do reliably.
The upside to trying to implement a filesystem like this on Ubuntu (and/or Debian) is that you really can do it in steps, there’s no reason you have to convert it all at once because the existing POSIX filesystem is still there on Gobo, just hidden away.
The best part about the gobo way of handling things is the ease of running multiple versions of libraries and programs, something that is cludgy right now on *nix systems unless you manually install the software yourself (/etc/apache and /etc/apache2 anyone?).
To change the default version of a program that gets ran when you type a command is done just by changing a symlink… The “update-alternatives” command in Debian based systems basically does this now (try installing vim-tiny and vim-full… now which one does the “vim” command actually run?)
I think Debian/Ubuntu has it right with the packaging system and Gobo has it right with the file system, I would love to see them combined.
The best part about the gobo way of handling things is the ease of running multiple versions of libraries and programs, something that is cludgy right now on *nix systems unless you manually install the software yourself (/etc/apache and /etc/apache2 anyone?).
Debian (and obviously also its derivatives) has been able to do this for ages via dpkg-divert.
http://www.debian-administration.org/articles/118
Personally, I remain unconvinced of the potential advantages of breaking the filesystem hierarchy standard.
Reminds me of the program stow. With this you can install to /usr/local/stow/MyAppName(/bin,/libs etc) then run stow to create or remove symlinks in /usr/local/. Of course basing the package management and whole system around it seems neater – at least easier to keep updated.
Reminds me of the program stow. With this you can install to /usr/local/stow/MyAppName(/bin,/libs etc) then run stow to create or remove symlinks in /usr/local/. Of course basing the package management and whole system around it seems neater – at least easier to keep updated.
That's probably because GoboLinux makes heavy use of stow, or at least it did up to some point. I didn't RTFA so I don't know how things are looking today on that regard.
GoboLinux never used stow. With that said it does use a mechanism that can be compared to Stow – or Stow can be compared to GoboLinux, whichever you want.
This project has been around for some time. I installed a copy of this on one of my comp’s and it seemed to work ok, but that was a long time ago (maybe two years). I followed the porject for a while but then it went dormant for a long time, no updates, new releases, etc..
I’m happy to see these guys are grinding away at this again, time to download a copy and start following this project again.
If these guys could get some financial backing and more developers i really think this could be the new Ubuntu / Suse to enter the market.
…it won’t get any good software support from independent vendors, just because of not being LSB compliant. It’s really sad, because it appears to be a great way of doing things in the desktop arena.
Let’s just wait and hope for the best.
— Anything below this is the edit —
Hummm wait, I won’t modify the upper part of the post but, I didn’t really check to see if it was LSB compliant or not, simply assumed, so, please ignore this message if anyone finds out it is LSB compliant in anyway.
I should really think more before writing…
Edited 2007-02-15 16:02
This seems neat. I can’t say that I understand it fully though.
It seems that you can effectively change the current version of your programs by changing the symlink “current” for any given program.
That seems fine for executing the program but what about installing another one that needs to link against it, is that another symlink you need to change for the libraries?
The article seems to claim that running multiple versions of a program are easier with Gobo, but I remain skeptical. What about program settings that are stored in your home directory. I’m just thinking of nedit, when it went to 5.5 I upgraded my settings and saved them. What if I didn’t like 5.5, still had 5.4 installed and wanted to use 5.4? Too late, I don’t have a ~/.nedit5.5 and ~/.nedit5.4, I just have a ~/.nedit directory.
I’m not saying that other distros can handle this, I’m just saying that you will always run into issues when you have more than one version of a program installed. Or programs that use other programs like web browsers running java applets and such.
I don’t think this will solve many problems, but I do think the layout and the idea is great. I have been hurt before by programs that assume you’re using one distro or another and look for something in /usr/bin instead of /usr/local/bin. I think its great that this system solves it by pointing all bin directories to the same place. When choosing a distro I tend to say with something in the top 10 at distrowatch for compatibility things. I’ve been using gentoo and its starting to fall off…now at number 12, but then if you combine it and sabayon at number 10 it would be number 4.
but then if you combine it and sabayon at number 10 it would be number 4.
You know, this is also true for most other linux distros. So in the end, if you were to count like that, gentoo would probably not be number 4.
while it may not make it simpler to run multiple versions of programs (this because user space programs that store setting do not version their settings. something gobo cant fix), it makes it a whole lot simpler to avoid dependency hell…
iirc, RPM and similar goes ape if you try to have more then one version of a package installed. and if said package is a library that breaks from older versions (redone interfaces and all that stuff) your more or less screwed if you try to install a program that needs said lib version but breaks a whole lot of the others.
gobo allows for multiple versions to be installed side by side. hell, i think some have even had multiple versions of glibc or similar installed at the same time…
The idea of installing apps to their own directories isn’t GoboLinux specific. ZeroInstall and Klik do the same thing, and are theoretically even easier for newbies to use (plus compiling from source as GoboLinux prefers takes too long for most users to be willing to deal with it).
But the idea of GoboLinux is great: build a distro around one innovative method of software installation. Foresight Linux has also spurred interest in the Conary package management system.
So I think what projects like AutoPackage and ZeroInstall really need if they want to take off is to start their own distros, instead of trying to convince all the other distros to adopt their tools. That would undoubtedly be the most effective marketing and testing tool they could come up with.
there is a ever growing collection of precompiled programs. and after the first compile, you can have the system create a binary package of the compile for future use iirc. this simply by wrapping up the resulting folder structure into a archive.
and said wrapped up structure can then be passed back to the community
Don’t get me wrong, I think the ability to make GoboLinux binaries (app-folder-style) is a fantastic feature, but it still buys into the basic concept of packaging a program that I thought GoboLinux was supposed to be avoiding! As such, it seems it is appropriate to call it the “non-preferred” method of installation on Gobo, because any community-created collection of binaries is hardly going to be better than any repository system.
Of course, if it were possible for app developers to make GoboLinux binaries without having to have GoboLinux installed themselves, then we’d have something to talk about. Because that’s the real advantage that cross-platform tools like AutoPackage and ZeroInstall bring to the table.
So basically, I think the ideal situation is to have one’s own distro in addition to maintaining cross-distro support. Then we might see some big-time adoption of these new installation schemes.
One of the problems with package systems is that if I just extract an archive to a bunch of directories, the package manager has no database entry for it.
With Gobo, if I extract it to /programs/firefox, there is no need for the package manager to have a separate entry for it.
This means if I want to use apt, I can find the application when I am done.
If I want to also use AutoPackage or ZeroInstall along side apt, I still have a database of what is installed
The beauty of it is that you don’t have to have everyone conform to using the same method of packaging software.
repository systems don’t solve everything, but they are still useful and there is no reason they need to be considered “non-preferred”.
You’re right, it’s a beautiful system from the user-end perspective. My point was, when will/how can we get the original application developers to start packaging their apps in this way, instead of just providing source tarballs? Until they do that, the selection of easy-to-install software for Linux will continue be artificially limited.
“My point was, when will/how can we get the original application developers to start packaging their apps in this way, instead of just providing source tarballs?”
Personally, I think adopting the Gobo file system right out the gate is a large step.
I think FHS (http://www.pathname.com/fhs/) really has no specific place for graphical (desktop) applications.
The closest thing to it is probably /opt.
Currently software seems to end up an one of 4 or 5 places, I think the best path to success would be really sitting down and deciding where applications like Firefox, Gimp, XMMS, etc. belong and ensuring that this is clearly pointed out in the FHS standard.
I think if people want to stick the configs for ftpd or sshd in /etc/ that is fine, but there is no need for libraries or configs specific to gimp to reside in any place other than /programs/gimp/, /opt/gimp/, or what ever is decided on by the FHS committee.
I am also under the belief that if the distro shipped with gimp or if you installed it, that does not necessarily mean it needs to reside in a different location.
Everybody follows FHS, or they would not be considered LSB compliant. The problem is that the specification is so painstakingly vague that you can stick your binaries just about anywhere on the disk and still comply.
FHS is really designed for system files and servers, it has never been updated to address the fact that there are actually people using Linux as a desktop/workstation. The problem is that getting the UNIX purists that actually have say in the specification to agree that a /programs or /applications folder is needed would take an act of god.
you may find it interesting then that gobo was originally started as a system to allow user(s) (specifically the creator) to install linux programs under their home directory no matter what linux distro they happend to be using.
this version still exist (but i think its getting slightly dated) and can even be used under cygwin (but only to do source based installed).
and gobo isnt about avoiding packaging afaik. its about avoiding a package manager database that can go corrupted and stop working (there is a reason why rpm have a “rebuild database” command line switch).
hell, the iso even comes with a tool to roll your own livecd ones you know what programs you want to have available. and yes, the iso is a livecd itself.
So I think what projects like AutoPackage and ZeroInstall really need if they want to take off is to start their own distros
I think both projects would count that as a failure. The aim is to be cross-distro, not create another one! We should be able to get packages that install to whatever the underlying system is. It’s just good architecture.
I’d certainly like to see more interop between Gobo and Zero Install (time is just limited). Presumably you could use a Zero Install feed in place of a Gobo recipe without too much trouble.
Don’t know if it would work the other way; do Gobo binaries contain hard-coded paths (like “/Program/Joe/3.1/”)?
As I said in my above comment, there’s no reason cross-compatibility would need to be thrown out just because an AutoPackage- or Zero Install-specific distro exists. I think the combination of distro support and cross-platform capabilities would be the perfect one-two punch.
…come to think of it, Debian’s apt has had success with exactly that model…
Also, about Zero Install integration into GoboLinux: it would probably be doable, but would require serious reworking of the GoboLinux folder hierarchy to the point where it wouldn’t really be GoboLinux anymore. Zero Install installs shared libraries in separate folders from the programs that use them, so that the minimum amount of redundancy is necessary (of course, multiple versions of libraries are still possible, and are automatically assigned to whatever programs need them). Also, Zero Install uses a funky hash-based folder naming scheme which is quite different from GoboLinux’s straightforward name-based approach.
If you haven’t already, check out the article on Zero Install that was posted a month ago:
http://www.osnews.com/story.php/16956/Decentralised-Installation-Sy…
Edited 2007-02-15 21:03
You can use the Zero Install feed format without any of the funky hash stuff if you want. It just lists versions, where to get them, what they depend on, etc.
Here’s an example of a program with several available versions, all of which require the ROX-Lib library (View Source to see the XML):
http://0install.net/2007/interfaces/0publish-gui.xml
D’oh! You’re the same guy who wrote that article on Zero Install, aren’t you?
iirc, there is someone playing around with having Zero Install play nice with gobo. dont know its present status…
afaik, gobo binaries only contain hardcoded paths if the original source did so. as in, gobo tries to avoid having to modify the source. thats why the compile environment is a chroot, as it use the original “make install” stage to find out what files go where when creating the symlinks later on.
there is a ongoing debate on the mailinglist ever so often about allowing gentoo like compile stuff, but gets shot down because one wants to keep the binaries as generic as can be done.
thats also why the gobohide kernel addon is used to hide a symlinked legacy tree. there are some binaries that have hardcoded paths, and rather then try to sniff them out a legacy tree is created for them.
and why do the hiding kernel side rather then file browser side like apple does? are you aware of the number of file browsers available for use in a linux environment?
” and why do the hiding kernel side rather then file browser side like apple does? are you aware of the number of file browsers available for use in a linux environment?”
You answered your own question, that’s exactly the reason
In Gobolinux, thanks to GoboHide, you see the same filesystem regardless of the filebrowser or shell you are using.
hmm, i guess i forgot to add “,may you ask” to that first part…
oops!
heh, no biggie. its my own fault for not writing it more clearly.
Congratulations to the 152562 linux distribution
Edited 2007-02-15 16:25
with a little innovative (in linux world, but not in Mac) directory structure. I have to say that this distro has the worst color scheme choice among other distro!
dont like it, change it? while it have a similar file system to a mac, its not a mac, so your not locked into whatever apple say a mac is supposed to look like
What most people seem to want when they consider a new distro (or OS) is plenty of software choices easily available / installable. That’s the problem of small distros like Gobo, their software repositories are much more limited, like also the availability of documentation, support etc.
For getting more popular being LSB compatible or not might not be so big an issue. For example, I think that Gobo could get more popular if it officially supported GNOME (and GNOME software) besides of of its official choice of KDE as a desktop environment. (I’m one of those people who just prefer GNOME over KDE.)
Then again, maybe Gobo Linux is doing just fine like it is, and is not even aiming to become a very big distro. More users and developers would never hurt though.
there is work going on to support gnome, but afaik there is a mess of circular dependencies and whatsnot that makes this less then trivial compared to kde.
http://gobo.kundor.org/wiki/Gnome_on_GoboLinux