“I was impressed by the way GoboLinux handled. This distribution clearly has a well-defined identity of its own, and the authors’ philosophy shows in every detail of the system. The system is fast, without a grain of bloat in it.” GoboLinux’ most defining feature is its filesystem layout, which does not follow the Free Standards Group’s Filesystem Hierarchy Standard, but is more like OSX’ layout.
I like the file system hierarchy they are using, very logical. If they get Gnome on there, maybe I’ll switch!
EDIT: The contrib repos have Gnome, but its version 2.4
Edited 2005-11-03 20:38
i have been following this distro for some time and from what i recall there are some info on installing gnome from source in the wiki. enjoy…
the problem realy seems to be that gnome is like a gordian knot or whatever its called. basicly there are libs that need other libs all over the place, connections going back and forth in all kinds of directions.
kde seems to be much cleaner that way and therefor simpler to get working.
Yes it is. Gnome has had this problem for a while. And I believe it’s high up on the list for things to change in 3.0…
Gtk 3.0 is, I think, supposed to take on a lot of the gnome libs that aren’t really gnome libs anyway (stuff that’s not related to gnome, but was written for it). For one, gtk 3.0 is supposed to absorb libglade.
I’d never expect anyone to manually install gnome or KDE though… It’s just too much work when other people have made installers for you to use…
what version of KDE is in those screenshots! i havent seen kde look that bad since the 2.x days.
According to their packages list in version 012 it is using KDE 3.4.0. Also most of the those screenshots are really old.
Edited 2005-11-03 20:44
I have been saying that about the directory structure for a while, it is nice to see someone come up with a proof of concept on this.
I wonder how difficult it would be to get Autopackage running on this distro, that could be interesting.
I think the 2 combined could have the potential to challenge Ubuntu or Gentoo on the desktop.
well if autopackage can be told to put stuff in the right place under gobo i belive it may work.
the path should be /programs/”name of app”/”version of app”/
then symlinkprogram should be called on said path…
problem realy is that autopackage and gobo duplicates a lot of effort as autopackage have its own internal removal tool.
but under gobo this is not needed as the filesystem itself is the “package manager”. but i guess as long as the autopackage manager can see that the app have been removed using gobo tools or even just deleted then stuff will be fine. i just hope we dont get sillyness like one can see in windows where a app have been deleted but still show up in the add/remove tool and so on…
Autopackage works based on the correct, working, efficient, logical, bin+share+lib+man+etc system. Here’s an example spec for an autopackage:
[Meta]
#I removed this section to save a page
.
[BuildPrepare]
./configure –prefix=$build_root DYNAMIC
make install
[Imports]
echo ‘*’ | import
[Prepare]
# Dependency checking
require @gnupg.org/libgcrypt 11
require @gtk.org/gtk 2.6
[Install]
# Put your installation script here
installExe bin/ejourn
installExe bin/ejourn-gui
installLib lib/libejourn.so
copyFiles share/ejourn $PREFIX/share
echo “Type ejourn-gui to run the program!”
Notice the install? All autopackage ends up doing with this is making $PREFIX a variable for the program. You then insert code (provided on their site) into your program to dynamically find $PREFIX. It does some other things with linking I believe, but those are totally hidden from the developer, packager, and etc.
Autopackage works. It works on anything. It doesn’t ask users to install a new system, it doesn’t even ask them to manually download it (an autopackage will install autopackage if it’s gone).
I don’t think they’re intentionally duplicating work. I’ve never much cared for Gobo, but I really like what autopackage is doing … it’s VERY cool to publish one binary package and source.
correct, maybe…
working, even windows works (most of the time)
efficient, maybe (again)
logical, upto a point and as long as you stay away from discussions about the proper use of /share, /opt and similar…
looks to me like gobo would be better of putting some extra code into installpackage that can parse the dependency part of the .package and then just dump the rest into the proper dirs. that is if it can figure out what version number to use
i naver said that they have intentionaly duplicated work, only that autopackage and gobo manger for one have duplicated features (sorry if i was unclear on this). while its fine for autopackage to have its own remove system under most other distros it will be redundant under gobo as long as it plays nice with the gobo way of handling apps.
if it cant play nice then it needs to be sandboxed to hell and back, just like the missbehaving compiles. and at that point one may as well just take the .package apart using a gobo tool rather then let autopackage manage it.
sorry if its a bit borglike…
Correct, yes, the standard supports it
.
Working, yes, it’s very nice to be able to move packages into whatever root I choose for them. It’s also nice to be able to look at what’s in a dir and guess what nature it is (although that doesn’t always work out).
Efficient, well I guess anything for this is really efficient.
The proper use of /opt has nothing to do with it. The question is, the proper use of bin/sbin/etc/share/lib. Whatever $PREFIX is doesn’t matter, that’s for distributors to argue over.
I see no reason to change it. Sure, put stuff in /programs, but /programs better have bin, etc, share, lib, sbin in it…
under each versioned app dir these dirs are recreated, alltho im not sure about sbin as its more about seperating root tools from normal user tools.
but hey, dont like the distro, dont use the distro
I’m not sure I like this idea. It resembles DOS/Windows/OS/2 too closely. And Windows, as we know, has too great a problem with malware, owing to it’s crappy directory structure. Count me out.
i realy dont see how this is more risky towards malware then the classical unix structure. or for that matter how the windows way makes it easyer for malware.
more info please…
the file structure makes autopackages pretty redundant anyway no ?
Interesting that this appears presently. I am currently working on my own distro and I am having an internal debate with myself. I’m using central programs store like Gobo, but I can’t decide if I should just drop in an ‘/app’ directory or go the extra distance like Gobo. Any insights, recommendations?
BTW, the reasons I’m not using Gobo are as follows:
1) I’m not a big fan of capitalization.
2) The system Scripts are overly abstracted.
3) Manager and installer are klunky.
4) Gobohide breaks frequently.
5) MPlayer would not compile.
It’s really too bad. Gobo is so *close* to being a great distro.
T.
I see that zsh is configured with case-insensitivity and tab-completion, which would more than deal with any of my objections to capitalization.
1) tab-complete is your friend. but yes, its something thats talked about frequently.
2) sorry, dont know about that one
3) manager was introdused in 012, no wonder its klunky. as for installer, i have a feel that it will see improvements as things move along…
4) heh, tell the kernel people to slow down their release frequenzy
basicly gobohide does something similar to what a rootkit does to hide so im not surprised that it breaks often.
5) hmm, cant recall that being reported before. i hope you where using the recipie and not compiling it freehand
still, good luck with that distro your working on
1) As said zsh is configured to recognize capitalization, so that isn’t any problems (at least not for me)
2) Could you elaborate?
3) As for manager, it’s new, so it’s no wonder it’s not “the best tool out there” – yet. I can’t see what you mean about the installer though.
4) Even if it breaks often, it’s always taken care of within a couple of days in the latest kernel recipe (compilation package, sort of)
5) I have compiled MPlayer without problems on my GoboLinux machine.
1) As said zsh is configured to recognize capitalization, so that isn’t any problems (at least not for me)
Not a big deal. Just a preference. This isn’t something that keeps me from Gobo, just adds to it.
2) Could you elaborate?
Some of the scripts like Compile take an approach of assumption about how to do things. And you just feed it clues to help it out. For some things that makes it real easy, but for others it then becomes harder, as it adds additional complexity to learn how to feed it the right clues. Pluse a new layer of tools you must learn.
3) As for manager, it’s new, so it’s no wonder it’s not “the best tool out there” – yet. I can’t see what you mean about the installer though.
The install has a strange interface (I was using the text one b/c the graphic one bombed altogether) I kept hitting the wrong key b/c it’s not the standard tab/enter form.
4) Even if it breaks often, it’s always taken care of within a couple of days in the latest kernel recipe (compilation package, sort of)
Sure. But it seems fragile.
5) I have compiled MPlayer without problems on my GoboLinux machine.
Wish it were the same for me. I might be using it still right now, but that was the tipping point. I did “Compile MPlayer” and it failed. Because of #2 I wasn’t sure how to proceed. I wanted to watch a clip and had to reboot into Debain. I never went back.
if you had taken your time to check around a bit rather then go straight for compile and then give up you would have found that there are binary versions of mplayer available as an official package. hell, i think it even comes on the cd…
so it sounds more like an excuse to look down on gobo and push debian then anything else…
“so it sounds more like an excuse to look down on gobo and push debian then anything else…”
Er…No, I’m not trying to push anything. I’m just telling you what happened. I’ve been looking for an alternative to Debian which is why I tried Gobo AGAIN — I actually LIKE Gobo all-in-all, though there are a few things I like to see differnt.
And I looked on the packages list on the website and did not see MPlayer –that was the first thing I did. But you are right it is there, I simply overlooked it. That’s too bad
Might have saved me some trouble. (Although the compile did fail). Well, come 013 I’ll probably give it another go. And we’ll see how it goes then. 13 is a lucky number right? 
ah, sorry about that flamie post then.
good luck next time.
Too many hacks, not thought out enough. From what I can tell, the sole focus was on the filesystem layout when the creator designed the distro, and apparently he didn’t bother to make anything else better (app management, UI, etc.), much the same as SymphonyOS.
I’m sure this post is going to get rated down; I just wanted to put forth an alternative view.
-bytecoder
You won’t get modded down for that. But it would be helpful if you pointed out the hacks so the rest of us can better understand your comment.
It’s a wonder I haven’t already; it’s happened before.
Off the top of my head:
1) the giant mess of links
2) the old fs layout is still present along with the new (either pick one or the other, not both!)
3) old fs layout is required for some tasks (as far as I can tell, there is no /dev equivalent in the new layout)
-bytecoder
1) well there are inventigations into alternatives. like say unionfs. still, using ls -l helps in figuring out those links.
2) hey, even os x have that old fs layout there. only that os x hides it on the file manager level, while gobo have to use a kernel module to do so. this to enable it to play nice with all the diffrent file managers out there.
3) the dev tree us mounted under /system and symlinked to the / iirc…
1) There is no mess of links. Executables all have links in /System/Links/Executables, libs in /System/Links/Libraries,… you get the point. There’s an exception and that is that settings are linked in /System/Settings.
2) There is not a chance that a small dist like that would have the possibility to patch every program that has hard coded paths in it. I do not even think that a larger dist would have that possibility. The old one is hidden from the user and is never used; it’s only there for compability reasons
3) /System/Kernel/Devices, there’s an equivalent for everything.
Mmm, personally I don’t mod down on the content of the post (it’s your opinion wether I agree or not is irrelevant) but on the form: if it’s insulting, then I mod down.
Now on your post about the giant mess of links, either you get a mess of:
a) directories with very long PATH, LD_LIBRARY_PATH, etc.
b) files within directories: with everything in a few select location, which is the current ‘normal Linux way’.
c) links as in Gobo Linux way.
So either way it’s a mess, which is ‘normal’: there are many, many applications so somehow they must be organised..
I think that c) is better than b) for applications, for shared libraries, I don’t know how they’re handled on Gobo and it’s always the hard part..
app management is inherent with the new dir structure.
every app is contained within a versioned dir below a named dir. remove the named dir and all versions go away, remove only the version dir and that version goes away.
ui was never a part of the gobo plan. this isnt a gui desktop distro. this is a console distro that can allso run kde or any other generic desktop on top.
basicly this distro wasnt an attempt at making a more user friendly distro. it was just a linux from scratch based on earlyer work done with managing rootless install inside a users home dir. one that was able to handle both source and binary installs inside the same system.
basicly gobolinux isnt aimed at all users, only at those that may find this diffrent dir enviroment more efficient to work in then the classical unix one.
Actually, I don’t think it was intended to be more userfriendly (at least not in the traditional sense of the term), rather it was meant to give users more control over their system. Nothing is ever installed without the user’s express permission, and that includes dependancies. There are no black-box package managers.
Gobo has come a long way since I first heard about it. Heres to the future!
Yes, you are right. I’ve never considered the directory structure something that should be considered newbie friendly, but really for the power user that likes to know where everything is.
app management is inherent with the new dir structure.
every app is contained within a versioned dir below a named dir. remove the named dir and all versions go away, remove only the version dir and that version goes away.
Why do the programs have to be in a specific directory? Why can’t I manage my programs with my file manager? A folder is, after all, a list. Why do I have to move preferences separately from the application when I transfer it to another computer? Why do I have to deal with dependencies, even when apps are installed manually?
-bytecoder
Why do you have to put gasolin in your car, why do you have to check airpressure in the tyres, why do you have to a spare tyre and so on.
Anyway – having to deal with deps when installing manually is quite logical.
If the application relies on a dynamic compiled library, and you are installing manually, then the application won’t work unless you manually take care of the dependency.
You could install binary package, statically linked, but that solution has other drawbacks.
without separate directories you’ll have all binaries in /bin /usr/bin etc and you’d need a package manager to know where all files for a program recides. With separate directories you don’t. It’s another way to handle programs, if you don’t like it don’t use it. I like it and I use it.
ui was never a part of the gobo plan. this isnt a gui desktop distro. this is a console distro that can allso run kde or any other generic desktop on top.
The UI ties in deeply with filesystem layout and application management; ignoring it simply screws you over.
-bytecoder
Sounds like your a UI lover. I’m sure they can/have/will utilise GUI apps for you to do magical things without you knowing – kinda like all the other distros/Oss. What Gobo has done from what I see is simplify the experience for those at the CL level. Package managers are nice but have limitations too. This approach should allow for both ways. Delete folders/files and managers. I dont see how their “screwing” anyone over.
Sounds like your a UI lover. I’m sure they can/have/will utilise GUI apps for you to do magical things without you knowing – kinda like all the other distros/Oss.
Well, I would hope so, since I wouldn’t be able to use a computer without a User Interface
It seems you don’t know the full power of a GUI, though, but I guess you’ll figure it out eventually.
Package managers are nice but have limitations too.
I disagree. Package managers are most certainly not ‘nice.’
This approach should allow for both ways. Delete folders/files and managers.
See my post above for the problems with gobo’s approach.
I dont see how their “screwing” anyone over.
They’re screwing themselves over for not exploiting the full potential of the system.
-bytecoder
They’re screwing themselves over for not exploiting the full potential of the system.
Could you please elaborate?
Too many hacks, not thought out enough. From what I can tell, the sole focus was on the filesystem layout when the creator designed the distro, and apparently he didn’t bother to make anything else better (app management, UI, etc.), much the same as SymphonyOS.
I’m sure this post is going to get rated down; I just wanted to put forth an alternative view.
-bytecoder
Why are you always the first to criticize everything (lol, I’m not saying there is anything wrong with criticism, but seriously, almost every story I read here this guy is criticizing what the story is about)? Could you provide some examples on what is wrong with the distro?
Do they install complete apps with all their dependencies inside the app’s dir or is there some kind of shared lib directory with each needed version of a lib installed inside it’s version directory whith each program using the version it requires without multiplying the same lib?
I want to try something out and i am curious to see if it is already implemented…
System/Links/Libraries/ contains links (hard links?) to all the Programs/{some app}/{version}/lib/ contents. So there is still a central lookup if needed (usually needed).
T.
its shared libs all the way.
/programs/”app or lib”/”version”/
then its all symlinked into diffrent areas under /system that again is used as a basis for symlinking the classical dirs under / (to help with compatiblity for cranky apps).
so GOBOLinux only has one version of each lib installed is this correct?
If this is the case, how do programs manage the deletion of a lib?
I mean:
The first app using a certain lib installs it on /programs/”lib”/”version”/.
If three more programs use it, how does the system do to assure the lib is only deletable when only the last app using it is being deleted?
I know some ppl wont like me asking stuff here but at the same time, this is extra information for the readers right?
Thanks for the previous replies
if you mean by use of removepackage or a similar tool then i cant realy comment. but there is no safeguard against someone with superuser access manualy a lib. but hey, does any distro, or os for that matter, have that?
I played with it for a while. The recipes are easy enough. But there’s two major problems. You have to manually figure the minimum dependencies or the script will just pick up what you have (yes the automess is next to impossible to parse), and you still need (I think) a dependency management tool. The lack of Gnome was somewhat of a bummer too, but as always it’s more of a bitch to build than KDE.
One bit in favor of gobo way is that the old way is not intuitive, and many have created directory structures that don’t properly work the old way. Some directories were meant to be strictly mounted off a network, but standard applications have tied those directories down to local mounts with links, filesystem or filedata, into the local directory tree. A newer way like gobo is an answer to progress. The old way was what could be down back then, and the new way is what we can do now.
This is such a nice Unique distro…
Just read this link and this might answer some questions and explains why the Distro is like that in the first place…
<li>
http://www.gobolinux.org/index.php?lang=en_US&page=doc/articles/clu…
<li>
looking forward to using this distro and will give it a go myself… maybe a little bit of tweaking might get this push through the desktop…
when uninstalling a program, will it leave a lib unharmed if it is being used by another program as well?
Will the lib uninstall only when the last program using it is being deleted and no other programs are using it?
That’s what i ment to ask… You know, if the system wont break when you uninstall a program which shares a lib with others…
Gobolinux *is* a great distro right now. i installed version .11 some time ago and everything worked perfectly, Compile is cool and so Manager.
Gobolinux just needs some developers/packagers love… (latest GNOME & KDE to start with)
kudos to gobo, i appreciate his work on this indie distro
OK, let’s forget about the naming conventions and capitalization and look at what we have here:
All packages live completely in their own subversioned sudirectories of /Programs. Applications are installed separate from their shared libraries and live in different directories under /Programs. Links to all binaries in all packages are in /System/Links/Executables, all libraries in all packages are linked from /System/Links/Libraries, etc. The legacy UNIX tree links to the appropriate locations in /System/Links.
Basically, we have a traditional UNIX hierarchy that links to a condensed UNIX hierarchy that links to monolithic package directories. As long as the appropriate links are created when a package directory is added and destroyed when directories are removed, and as long as the correct versions of shared library packages are installed alongside dependant application packages, everything is business as usual.
There isn’t really any additional simplicity here. You can’t just extract a binary package tarball (from slackware, or from the upstream maintainer, for example) into the appropriate directory, and you can’t blindly remove package directories. You still must use the provided package management tools and the specially created packages and recipes to properly manage the links that keep the system coherent. And I still don’t completely understand what keeps me from installing (for example) Netkit-Base without LibPNG (which provides needed shared libraries) if there is no “database-oriented package management system” under the hood.
The procedure of package management (add/remove/upgrade packages) from the user’s prospective is more or less unchanged, the dependence on specially created packages is on par at best, and the ease of package development is probably worse. The only difference is that the packages actually live in their own directories, even if the system actually accesses these package files through more traditionally organized links.
So Gobolinux appears to me to be an exercise in abstracting an appfolder-type filesystem hierarchy from a UNIX-type package management model. As opposed to sticking with a standardized hierarchy and core library/header specifications, an agreement which can foster real breakthroughs in package management and compatibility, Gobolinux sacrifices cross-distribution compatibility for the sake of a superficial abstraction of the filesystem hierarchy.
pkgsrc, the ports-system of NetBSD has a feature called pkgviews which resebles this a lot. In fact I think darwinports has it also. Packages get installed in directories like /pkgroot/pkg/ver and symlinked to the appropriate directories. This is a big improvement that all packaging systems should adopt. The improvements include easier package management and simultaneous install of different package versions.
Then there’s the problem with binary packages. autoconf & friends set program and library paths as compile-time variables which get hardcoded to the binary programs. Thus a package that has been compiled to the normal directory layout wont work if it’s put into a directory like /pkgroot/pkg/ver. It should work, if there are symlinks where it expects. Unfortunately this, for now, means that the traditional UNIX-hierarchy has to be available.
All the similar systems that I’ve read about add *only* one level of indirection. So what butters was saying about links to links is *not* true. These days normal libraries are installed in a file which has the version number as part of the filename. These are linked to from the names without versionnumbers. E.g. libc.so -> libc.so.2.9.
If we could only get a directory structure like /pkgroot/pkgname/pkgversion included in some standard, so that everyone (even the BSDs and commercial UNIXes) would support it, binary packages could be compiled with these paths hardcoded and then linked to the traditonal or modern file-system-hierarchy.
…that it lets you put your own packages without fear of dependency problems.
1) CompileProgram is a really nice script: you can use upstream tarballs for installing programs. If the program use autotools, it is usually correctly compiled and installed. It is much better than dh-make or checkinstall (the equivalent tools in Debian) because you can use it even for libs without fear of dependency problems with other programs. Libraries are usually more forgiving than the usual distro package management program makes them to appear. That one package is compiled for version 1.2.5 doesn’t means that it won’t work with 1.2.24.
2) Installing binary packages (for example installing the propietary CAD program CyCAS, or just programs compiled for debian or fedora) and have them as “first-class citizens” in your filesystem is overly easy. Just put the contents in a properly named subdirectory in /Programs and run SymlinkProgram program-dir-name
3) It’s ideal for tinkering. You can follow the boot process easily, and install/deinstall apps is also posible without “helper programs” (although InstallPackage/CompilaProgram/SymlinkProgram are there to help :-).
Basically it’s a distro for advanced users, but it’s quite nice.
I’m using it since version 005 days in my secondary machine (my primary machine has debian) and what I love most is the easyness of using upstream tarballs.
As always, it’s about choice. There are some tasks that are easier with GoboLinux. And it’s good it’s there for you.
…that it lets you put your own packages without fear of dependency problems
I disagree, this is an advantage of GNU tarballs in fact. I have the exact same advantage without using Gobo. Package management dependancies are more restrictive in order to keep the OS consistent for average users.
1) CompileProgram is a really nice script: you can use upstream tarballs for installing programs
Same for any source based distro.
It is much better than dh-make or checkinstall … because you can use it even for libs without fear of dependency problems with other programs
Didn’t know checkinstall do not work with libs. Anyway, I use paco which is based on the same concept, and it works well. I never experienced any dependancy problem, because these are raleted to binary distro package managers. You can install several versions of libs without problem on Linux anyway.
2) Installing binary packages … and have them as “first-class citizens” in your filesystem is overly easy
Same on my system, I put them all in /opt (standard FS hierarchy) or /opt/<app> and has no problem with them.
3) It’s ideal for tinkering. You can follow the boot process easily, and install/deinstall apps is also posible without “helper programs”
Same on my system. Except the deinstall part which needs helper programs if you want to be sure to do it cleanly.
I don’t see any advantage compared to my near FHS system, but it’s good it’s there.
What I find most disappointing, is people who shout that this was best and all (because it was like OSX), and now, most still say : “I will try it when …”.
I almost forgot: I miss this two things a lot when working in other distros:
1) To know what packages are installed, you only have to do an “ls /Programs”. To know how to call a program, you only have to do a “ls /Programs/Current/bin”.
2) To know which package installed an executable, you only have to do a “which exe-name” (which is a script that does a real which and then follows synlinks). It’s a lot faster than the usual “dpkg -S `which exe-name`” of debian)
I know that this is only matters for CL users, but those are the primary target of GoboLinux :-).
Just for the record :-).
Gobo linux is not so much of a progress. It’s just another way of not addressing the problem of what libs the OS should provide and what libs the application should be packaged with.
File structure is easier to understand. Fine, but so what ? As long as each new application that you install is in effect potentially modifying the system capabilities (new libs or new lib versions), it is threatening system stability.
The OS should come with a set list of libs and capabilities and applications provide whatever else they need on a private basis.
If it is it sounds great.