Översättning saknas! Den här sidan har inte blivit översatt än. Därför visas den nedan oöversatt, på engelska. Hjälp med översättningar tas tacksamt emot! Översätt sidan och skicka översättningen till gobolinux-www (snabel-a) lists.gobolinux.org så kommer vi lägga upp den här (självklart med erkännande till den som översatt texten! :-) ).
GoboLinux is a Linux distribution that features a new filesystem organization, which departs from the traditional Unix heritage of Linux systems. Basically, this means that it is not based in directories such as /usr and /etc. The main idea of the alternative hierarchy is to store all files belonging to an application in its own separate subtree; therefore we have directories such as /Programs/FooPlayer/1.0/lib.
To allow the system to find these files, they are logically grouped in directories such as /System/Links/Executables, which, you guessed it, contains symbolic links to all executable files inside the Programs hierarchy.
To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).
No. In fact, it was motivated to fulfill the needs of users who prefer to install applications from the original source packages instead of relying on the distribution. That is the main reason why each application gets its own directory: so you can install it from source there and then remove it with an "rm -rf". So, you see, GoboLinux was designed focusing the experienced user who doesn't like things to be automagical. Our scripts merely automate procedures, but they don't "make decisions", and whenever they have to, they ask first.
The binary package collection was created as a way to avoid duplication of effort between users. The Compile project was created to store "compilation rules" of the original source packages of the applications, given that there is no single standard on how to compile apps on Linux. We do not wish to estabilish a "packaging standard" such as RPM. We think that there is no real need for "packages" if the original .tar.gz is properly made. For instance, when an application uses the GNU AutoTools (autoconf, automake...), compiling for GoboLinux is trivial; for non-trivial cases, Compile takes care of accumulating the necessary knowledge on how to compile things.
However, given the more logical directory tree, GoboLinux is often considered a more conceptually friendly distribution, as its structure is more logical and less hindered by historical limitations. But we do not target beginners as a specific goal (at least not in short or mid term).
Yes, it is ready in the sense that you can, today, have a full operating system running 100% on GoboLinux, like many people around the world do.
This can be split in two questions, one about the status of the GoboLinux tools, and one about the availability of packages.
GoboLinux relies on a series of tools that automate various tasks, such as generation, installation and removal of packages, and most importantly, maintainance of the symbolic links that keep the system consistent. These tools are fairly stable, as they are a few years old by now.
Another important issue when using a distribution is the availability of packages, ie, software that you can download in binary form and install in it straight away. In this aspect, GoboLinux still lags behind other estabilished distributions, as we don't have a large community of developers and we are not based on another distribution as many distros are, so we don't have another pool of packages to base ourselves from. We have, however, all packages needed to get a running system (all packages that are part of "Linux From Scratch" and "Beyond Linux From Scratch" projects, for example), plus many others, such as KDE and all related packages, and the list just won't stop growing. Also, we have an even larger set of compilation recipes for use with the GoboLinux Compile tool, which allows one to create packages from source.
The concept was created by Hisham Muhammad. The first version of GoboLinux was created by Hisham and André Detsch.
GoboLinux has matured over a period of two years. Initially it started as a way to install programs cleanly inside a regular user account at the University (since we didn't have the real Linux tree available anyway, it was an opportunity to redesign the tree).
One day, after The Great Filesystem Crash in Hisham's computer, he had to reinstall the whole system. That's when the idea came to use, in the new system, only the alternative tree (which in the pre-crash system, already held about 80% of all installed software). André was also considering reinstalling his Linux system, so they gathered one weekend at his house, and ran the entire Linux From Scratch procedure, changing it to use the alternative directory tree. The result was jokingly named GoboLinux, and as it usually happens, the name stuck.
From its inception (described in the previous answer) on, we started getting more and more users, many of which, in the true spirit of Free Software, also became contributors the project. As in every project, people come and go, so it's impossible to list all names here, but check out the dev team page.
Our first goal is to have a system that we enjoy using, that won't get destroyed by package managing software that tries to administrate our machine for us. Most Linux distributions try to make life easier to the novice user, but this way they are making life much harder for the more seasoned user. We don't claim that GoboLinux is easier, only that it "makes more sense". However, people who use it say that it is indeed easier to administrate, given that it lets you understand your system better (if you are willing to understand it).
As they say, "world domination is just a secondary goal". :)
The short answer: theoretically yes, but no, we never measured it (to know why "theoretically", read "the long answer").
The long answer: the actual impact of the use of symbolic links is probably lower than you think. In a regular Linux distribution, libraries are already accessed through symbolic links. In GoboLinux, our links point directly to the actual file, so there is really one level of indirection to reach a library.
For example, take libc.so.6. It is in /lib, which is a link to /System/Links/Libraries, but the actual file is in /Programs/Glibc/Current, where Current is a link to 2.2.3, and inside Glibc's lib directory you have that libc.so.6 is in fact a link to libc-2.2.3.so. That's a lot of links right? However, libraries are acessed like this: the directory /System/Links/Libraries (which is not a link) is the only one stored in ldconfig's configuration (and LD_LIBRARY_PATH). There libc.so.6 points directly to /Programs/Glibc/2.2.3/lib/libc-2.2.3.so (no links in this whole path). So we have exactly one level of indirection, just as in regular Linux distributions. You may *see* a lot of links, but they are there mostly to ease the system's management.
Applications are also compiled with the --prefix set to their "homes" at /Programs/App/version, so when a program looks for a datafile it does not go through links. Reaching executables involves going through one link, but, unlike regular Linux distributions it does not have to search through items of a PATH (and any modern filesystem's tree structuring of a directory is probably more optimized than the shell's traversal through elements of $PATH. Of course, there's always the shell's hash, but then, there's always the filesystem cache).
We persuade them to cope with the GoboLinux tree with compilation options whenever possible. However, there are many programs that can't cope completely, featuring hardcoded paths in their sources and whatnot. Ultimately any free software can be patched to cope, but we don't have enough manpower for such a task and maintain it afterwards. It would be, at the very least, a big hassle, so we generally like to reduce the applied patches to the minimum. At least /bin, /lib and /sbin are critical. We have made tests in a chrooted environment and it's funny to see all the weird things that happen when those are missing.
/Depot is a "free area" to store your documents, such as media files, downloaded stuff, etc. You can think of it as a "community area", a "home for all users" (some UNIX systems have a /pub directory for this purpose). GoboLinux as a system ignores the contents of /Depot it only exists to encourage users to store their random files under a single place and keep the rest of the system clean.
/Files, on the other hand, is a standard GoboLinux directory. Inside it, there are directories such as Fonts and Plugins, where shared files that are required by applications but not necessarily part of them are kept.
Apart from Fibo, his loyal servant, no one who saw him survived to tell the story. Beyond that, we never risked digging any deeper into the subject.
Of course not. :-) You may disregard the two questions above -- they are just one of the many internal jokes in the GoboLinux world. Gobo does not exis-- uh, what's that? AAAAAHHHH!!!! ;-) just kidding