You are not logged in.
Anyway, you will need some tool, that will update all the symlink stuff to make this sandboxed layout usable (i.e. to resolve ambiguities between two versions of the same program or library).
Yes, Gobolinux have a package format and a installer (a bunch of simple scripts). But no need of a manager, neither a database, as I said. The installer create some symlinks to make binaries and libraries available to PATH and ld.conf. There are no ambiguities between two versions, every program resides in /Programs/PNAME/PVERSION, and your prefered version is symlinked to /Programs/PNAME/Current.
freakcode wrote:Funny enough is that OS X, which doesn't follow the Unix hierarchy standard so close, is regarded as fully Unix compatible and marketed using the Unix trademark
I'd appreciate some links on this topic. IMO, Apple products are more 'marketed' and 'claim to be', than they really 'are'.
See "Unix certitification": http://www.apple.com/macosx/technology/unix.html. See also http://www.google.com.br/search?q=Apple … =firefox-a.
But I'm just pointing how funny it is that Linux systems are so conservative in many aspects, one of those sticking to FHS, and in the end it means nothing because Linux isn't even Unix certified.
Linux filesystem layout represents the concept of a solid, environment, where all components are (or at least can be) tightly integrated and you don't need to worry about _how_ your (and your distro-mate's), say, python is going to find, say tcl interpreter, _what version_ of tcl he finds and etc. You just either have tcl in your environment or not. And the same for bash, java, alsa, vim and so on. You seldom use several versions of one tool at a time. You just use the tool.
But what about the other side of the coin? In Gobolinux and OSX I have executables in 200 directories spread across the system, and libraries in other 200 different directories. "That's hardly KISS." How can I easily get a list of all the executables on my system? In the traditional Unix approach, essential system executables are in /bin, user executables are in /usr/bin, libraries are in /usr/lib. Simple. smile (Just trying to point out that things aren't as cut and dry as they may appear to be)
Getting a list of the executables in your system is easy as "ls /System/Links/Executables". In fact, it's even simpler because can't exist redundant names in different paths (think about having pidgin in both /usr/bin and /usr/local/bin. What's being called when you run 'pidgin'? Why there are TWO different binaries with the same name? That shouldn't be allowed).
Doesn't matter where the binaries live, you have this system directory that acts as an index to all your executables for all your system. Also, it doesn't matter much if the package follows the FHS layout (/bin, /share, etc.) or uses a different layout (like Firefox, or Adobe AIR). Provided you can create a link into /System/Links/Executables, it's all fine. Now compare this with having 6 different binaries directories in your $PATH (/bin, /sbin/ /usr/bin/, /usr/sbin, /usr/local/bin, /usr/local/sbin, not counting any /opt mess you might encounter). If you think outside the box a bit, you will agree that this is hardly KISS.
I suggest trying the Gobolinux live CD and seeing the real thing working, or reading their Wiki before posting, some of your doubts are already explained there. Good to see this thread getting interest, I'm sure it might raise some good ideas even to Arch along the way.
Last edited by freakcode (2008-10-02 17:55:35)
Offline
I'd like to chime in and point out that GoboLinux is quite conservative comparing to alternatives like http://nixos.org/index.html. NixOS IMHO a *very* interesting Linux based system, which is based on idioms not found elsewhere. Despite being quite experimental, common linux software is able to function properly http://nixos.org/nixos/screenshots/nixos-kde.png. I hope that one day it will become stable.
Offline
This discussion reminds me: IMO the biggest drawback of Linux is the practical impossibility to release a universal installer that would work in all distros (I think somebody has already mentioned that). And this is due to the incompatibility between different package managers. I think that Linux will never attract enough attention from commercial developers if they need to either open source their product for the community to build the packages or they have to make several installers/packages themselves (.deb, .rpm, etc.)
arch(3) adj amused because you think you understand something better than other people ;P
Offline
I don't think that's actually so true: those commercial developers could as well focus on the mainstream distros, depending on the target endusers, i.e. CentOS for server, Ubuntu for desktop (not sure those are actually the most used ones, it's just an example). I don't think commercial companies would even go look for distros like Gobolinux, so I don't think the latter does any damage.
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
feels like what windows did to organize their programming, though is not completely try, but yeah, for most linux/unix system with a package manager would be a plain. since the stuff that make a program run are all over the people, it will be like impossible to uninstall a program without a script. The way Gobolinux did seem logical, however I don't know how efficient would it be compare to the others.
Offline
I think that Linux will never attract enough attention from commercial developers if they need to either open source their product for the community to build the packages or they have to make several installers/packages themselves (.deb, .rpm, etc.)
What kind of commercial developers are you talking about? If about those crapy-shareware-makers - linux just doesn't need them.
And there _are_ many commercial (or just proprietary or not completely opensource) products for linux from serious vendors. Some of them stick to specific distros (oracle), some use custom installers, that rely only on general-across-all-distros features (maple), some release packages for all wide-spread distros (skype). Also note, that having a .deb or .rpm binary package - it's easy to make a PKGBUILD, that makes a valid arch package, so, that's not a problem - when the vendor of proprietary software provides package only for some distros.
Offline
See "Unix certitification": http://www.apple.com/macosx/technology/unix.html.
Lol. Just another PR trick by Apple in action, as I thought. Linux itself cannot be certified, since certification can apply only to a specific distro. And, I suppose, among the distro-vendors only Red Hat and SuSE can afford it (or would you like to sponsor Arch certification?). Funny, that they just don't need it.
But no need of a manager
Well, and how would you call a program, that switches symlinks from one version program to another and makes specific version of the program current (or there isn't such functionality in gobo?)? Still some kind of manager.
Well, I'm not a troll or a "man in the box". I'm just trying to find out, what possibilities does gobo provide and how useful are they.
For now I see, that gobo way allows to install different versions of programs alongside while having one version being current. In its present form it seems kind of a useless feature for me, unless there is some extra functionality in top of it.
And I suppose, that holy wars about whether specific FS organization way is KISS or not just make no sence.
Offline
@finferflu: I didn't mean that Gobolinux is harmful in any way. It was more like an off-topic rant.
@Mr.Cat: You have some valid points. You must admit that the process is more complicated than on Windows/MacOSX which is all I meant to say. I know it CAN be done - it's just unnecessarily more complicated.
Well - actually it's not totally off-topic - since this complication I was talking about derives from the Unix tradition of spreading a package's files all over the place (as opposed to putting everything in one directory like in Windows/MacOS/Gobolinux) which leads to the necessity of a package manager which leads to the different package formats etc. etc.
Not trying to say that Linux is bad (I'm using it myself, hello!) - just pointing out where it is unperfect.
arch(3) adj amused because you think you understand something better than other people ;P
Offline
Lol. Just another PR trick by Apple in action, as I thought. Linux itself cannot be certified, since certification can apply only to a specific distro. And, I suppose, among the distro-vendors only Red Hat and SuSE can afford it (or would you like to sponsor Arch certification?). Funny, that they just don't need it.
Trick or not, it's a fact. So, again, if all distros follow common standards like FHS, and can't be certified as a whole, why are following standards anyway? That's what I was pointing out. There's enough room to be innovative and not stick so close to arcane standards, and yet, be Unix compatible and even get a certification.
JeremyTheWicked wrote:I think that Linux will never attract enough attention from commercial developers if they need to either open source their product for the community to build the packages or they have to make several installers/packages themselves (.deb, .rpm, etc.)
What kind of commercial developers are you talking about? If about those crapy-shareware-makers - linux just doesn't need them.
That's your opinion. There are people who would kill to have Photoshop, AutoCAD, et al for Linux. But they can't, because developing and shipping for Linux is just not simple.
And there _are_ many commercial (or just proprietary or not completely opensource) products for linux from serious vendors. Some of them stick to specific distros (oracle), some use custom installers, that rely only on general-across-all-distros features (maple), some release packages for all wide-spread distros (skype). Also note, that having a .deb or .rpm binary package - it's easy to make a PKGBUILD, that makes a valid arch package, so, that's not a problem - when the vendor of proprietary software provides package only for some distros.
Yes, there are vendors shipping for various distros. The problem is that this comes with a burden, they need to ship to a least common denominator. See how Skype for Windows or Mac is years beyond Skype for Linux, despite Windows and Mac being vastly different than, say, Mac and Linux.
I don't know if you know, but what killed UNIX was the incompatiblity war between versions (BSD vs. SysV). Some vendors focused on one, others on another, and in the end you had a hard time to support UNIX at all so they forget about it and focused on the ones that gave more guarantees to develop and ship products easily (e.g.: Windows). We have a gazillion distros, but none of them is making easier to attract software producers by simplyfing the shipping process - instead, they ADD complexity to the shipping process by creating another abstraction, like a package manager. The only movements we see towards this are endemic (like SuSE one-click-installers, or apt:// on Ubuntu, etc.). There is no one standing up to make shipping easy for Linux as a whole (despite Gobolinux working out FHS). So in the end, producers will either go to other platforms (see how OS X is gaining traction. Wonder why?), or they will focus only on one distro and forget about the rest (you can already see people shipping installers only for RPMs and DEBs, like Adobe AIR. Vendor lock-in in Linux? If you can come up with a PKGBUILD for Adobe AIR, I'd pay you a beer).
But let's avoid talking about those side-effects and personal opinions, let's stay on topic (Gobolinux's FS layout), advantages and drawbacks.
Well - actually it's not totally off-topic - since this complication I was talking about derives from the Unix tradition of spreading a package's files all over the place (as opposed to putting everything in one directory like in Windows/MacOS/Gobolinux) which leads to the necessity of a package manager which leads to the different package formats etc. etc.
That's the point Jeremy.
Last edited by freakcode (2008-10-03 18:33:48)
Offline
I would be totally behind /System/Links/XXX if one could guarantee that it's always up-to-date with what you actually have in your /Programs - but since it's just a simple symlink farm, I could see a bunch of links getting out of date pretty quick if you didn't rely on a package-manager of SOME sort or another. I wouldn't want a bunch of stale links lying around.
Offline
It isn't KISS at all
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
--------------------------------------------------------------------------------------------------------------
But if they tell you that I've lost my mind, maybe it's not gone just a little hard to find...
Offline
I would be totally behind /System/Links/XXX if one could guarantee that it's always up-to-date with what you actually have in your /Programs - but since it's just a simple symlink farm, I could see a bunch of links getting out of date pretty quick if you didn't rely on a package-manager of SOME sort or another. I wouldn't want a bunch of stale links lying around.
The problem with maintaing links up-to-date is that, in the first place, you don't need to maintain links up-do-date. Symlinks are just pointers to real files in /Programs. If it's broken, it means the real file is gone, and it's package is now invalid. /System/Links act as a package index itself - that's why we say there's no need of a "package manager", keeping files in sync with an internal database that is just a representation of the actual system, and where inconsistencies may occur. Of course, you still need an installer to create those symlinks in the first place (and Gobolinux provides a script for that). But then again, it's just an installer and a simple package format, like is the case with OS X .dmg one.
See http://www.gobolinux.org/index.php?page=at_a_glance ("How can this possibly work").
Last edited by freakcode (2008-10-03 19:09:00)
Offline
The problem with maintaing links up-to-date is that, in the first place, you don't need to maintain links up-do-date. Symlinks are just pointers to real files in /Programs. If it's broken, it means the real file is gone, and it's package is now invalid.
What if I didn't want libfoo-3.0 anymore? Do I have to go and manually remove all the symlinks in /System/Links? It's not as simple as just running rm -r /Programs/libfoo/3.0/, because then a bunch of broken symlinks exist in my system, and I don't like that. It's not clean.
See http://www.gobolinux.org/index.php?page=at_a_glance ("How can this possibly work").
I saw the at-a-glance page the first time you linked it - I don't think it solves my problem here.
Another important property of link-based indexing is that any references to non-existing files automatically become broken links, and therefore inactive. This makes it easy to spot and fix problems and, most importantly, ensures that the the index is always in sync with the actual functional state of the system.
I don't want broken links in my system that I have to hunt out and find. As soon as there's a broken link, the "index" is no longer "in sync" because it points to something that doesn't exist anymore. THIS is my problem.
Offline
Gobolinux page wrote:Another important property of link-based indexing is that any references to non-existing files automatically become broken links, and therefore inactive. This makes it easy to spot and fix problems and, most importantly, ensures that the the index is always in sync with the actual functional state of the system.
I don't want broken links in my system that I have to hunt out and find. As soon as there's a broken link, the "index" is no longer "in sync" because it points to something that doesn't exist anymore. THIS is my problem.
Once a symlink points to an inexistent file (let's say, /Programs/Foo/1.0/bin/foo), it can be checked and safely removed. This is perfectly scriptable, so I don't see a reason why this should be done by hand if you wish to do so. They even have some GUI tool that shows this: http://gobolinux.org/index.php?page=manager.
In my previous post, when said that you "don't need to keep symlinks up-to-date", I was stating that you don't need to bother maintaing symlinks. You either create it when you install a package, or remove it when you uninstall. If something breaks in between, it means the package (/Programs/Foo/...) is now in an inconsistent state. Your problem is not the symlink, is the package not being in /Programs anymore.
EDIT: This text is also great for giving a hint of how and why some things are done in Gobolinux: http://www.gobolinux.org/index.php?page … s/clueless
Last edited by freakcode (2008-10-03 22:07:24)
Offline
I thinks that GoboLinux is trying to innovate the LInux file system, but in a Windows and Mac mixed style.
Any way, I don't think that it is a great idea, because Linux FS is very consolidated and mostly of the users are agree with the current configurations. Maybe, newbies will appreciate this feature, but not advanced one
Marvin Ortega
Maryan Linux Project founder
Maryan Linux -Arch edition developer
Offline
That's your opinion. There are people who would kill to have Photoshop, AutoCAD, et al for Linux. But they can't, because developing and shipping for Linux is just not simple.
I don't think that Autodesk and Adobe don't provide AutoCAD and Photoshop for Linux just because of shipment complexity.
I suppose, software vendors are attracted not by shipment options but by user community. Linux is still more suitable (and very much more wide-spread) for servers and embedded systems, than for home pcs and workstations. So, Autodesk, Adobe and many other vendors won't gain much from Linux versions of their products.
If you can come up with a PKGBUILD for Adobe AIR, I'd pay you a beer
Is there anything wrong with AIR? There might be some problems on x86_64 (AFAIK, Adobe doesn't like Linux x86_64 for some reason), but what's wrong with i686?
like SuSE one-click-installers, or apt:// on Ubuntu, etc.
Well, do you think, there should be something like that for Arch AUR?
You must admit that the process is more complicated than on Windows/MacOSX which is all I meant to say.
No, I won't. )) I don't have development experience for Mac, but for me it's not easier to make a windows installer than, for example, a PKGBUILD.
Last edited by Mr.Cat (2008-10-07 00:01:47)
Offline
This may even be better than the Gnu Stow.
http://xstow.sourceforge.net/
http://sourceforge.net/project/showfile … _id=629101
I'm going to be testing it for a project that I'm working on privately. I hope it will help in my situation.
Xavian-Anderson Macpherson
Shingoshi
Offline
Please do not bump really old posts. This one was only three months old, so you are getting better...
Online