3 ms·

Okay so correct me if I am wrong: the original root structure is still there just hidden with this Gobohide thing. (I do not like this - turn off immediately).

Okay so correct me if I am wrong: the original root structure is still there just hidden with this Gobohide thing. (I do not like this - turn off immediately). You download tarballs into Programs and unpack and configure make install there, it 'just works'TM somehow, (I like this - sort of). I think 'Couldn't you create a script which creates a load of symlinks (for any distro), put it in a folder on your desktop?' Okay,.. help me here - what problem are we trying to solve again? I like the nice view of the applications we have, but just thinking quite often packages have their own symlinks for like lib.so.2-->lib.so.3 will this have symlinks to symlinks to... so now thinking is it really worth the effort for a nice view of the applications? What else do I get?

ufo 9y ago
That thing about the bunch of symlinks actually reflects how Gobolinux was first created :). Onde of the devs didnt havê root access in their university lab computer so they came up with this alternate organization that let them install everything they needed inside a directory in their home folder. He grew fond of that folder organization and later on grouped up with some friends to find out what would happen if they made a custom distro where everything used the alternate organization. As for what benefit this brings... One big one is that it makes it very easy to mix together programs installed via the package manager and programs you compiled from source by hand. There is no need for an alternate /use/local hierarchy. Similarly it it better at handling those situations where you might want to install multiple versions of some software. It can create different versions of that virtual root filesystem but with symlinks that point to different versions in each one. The end result is similar to what you would get with chroot and other "container" tech but in a quite elegant way.
- cr0sh 9y ago
  There's also the fact - if I understand it correctly - that the filesystem in Gobo -is- the "package database"; if it is in the filesystem, it's installed and can be looked up easily by the system. Or browsed manually. It's also friendly to manual installs; once you install things manually, it's now a part of the package database! That's the one thing I hate about package managers - if you need to install from source, the manager has no clue about it; in fact, you can have multiple versions installed - a new version "from source" and an old version from a real package via the manager! It's also possible for the manager to uninstall stuff it knows about - along with part of the stuff of the new version, depending on various things. I ran into that earlier when I had to upgrade and munge my Ubuntu system to get TensorFlow to work properly with Python 3 and some other stuff and crap I forget about; long story short, I can no longer perform an upgrade to my system (I'm on 14.04 too!) - the tool b0rks hard when I try, and I honestly don't recall enough to return my system back to working status (I also had to install a major upgrade to gcc - which necessitated upgrades to other things, new manual symlinks, hours of swearing). This was all needed for the Udacity Self-Driving Car Engineer Nanodegree because of their system requirements for code and such (had I been running 16.04, it would have been easier - most likely - but that was also fraught with potential issues, which is why I didn't pursue it). Looking back on things, I probably shoulda used a container or VM, or built a new machine, but I was pressed for time. I was assured in the beginning, before the class started, that what I had would work - like many things in the course, this wasn't true (I'm not saying they lied or misrepresented stuff - my cohort was only the second cohort from November, and so I am a part of the "guinea pig" crowd as they debug the new course - paying beta tester, if you will). A system like Gobo might have been useful for this...
deleted 9y ago
[deleted]
aclsid 9y ago
On Mac OS X, it has been considered that putting an application folder/icon in the trash (even if some other stuff might happen in the process), was a superior approach to Add/Remove Programs or find package name/uninstall with package manager approach of most distros. So maybe you are a die hard fan of old ways, but it clearly is a mess and not user friendly at all. Just look at why the LSB was created and more importantly, why nobody is following it 100%. If that does not seem like a problem to you I don't know what to tell you. As for the root structure, they do mention in the article that it is optional. It can be turned off by disabling the kernel extension.

ufo 9y ago

That thing about the bunch of symlinks actually reflects how Gobolinux was first created :). Onde of the devs didnt havê root access in their university lab computer so they came up with this alternate organization that let them install everything they needed inside a directory in their home folder. He grew fond of that folder organization and later on grouped up with some friends to find out what would happen if they made a custom distro where everything used the alternate organization. As for what benefit this brings... One big one is that it makes it very easy to mix together programs installed via the package manager and programs you compiled from source by hand. There is no need for an alternate /use/local hierarchy. Similarly it it better at handling those situations where you might want to install multiple versions of some software. It can create different versions of that virtual root filesystem but with symlinks that point to different versions in each one. The end result is similar to what you would get with chroot and other "container" tech but in a quite elegant way.

cr0sh 9y ago
There's also the fact - if I understand it correctly - that the filesystem in Gobo -is- the "package database"; if it is in the filesystem, it's installed and can be looked up easily by the system. Or browsed manually. It's also friendly to manual installs; once you install things manually, it's now a part of the package database! That's the one thing I hate about package managers - if you need to install from source, the manager has no clue about it; in fact, you can have multiple versions installed - a new version "from source" and an old version from a real package via the manager! It's also possible for the manager to uninstall stuff it knows about - along with part of the stuff of the new version, depending on various things. I ran into that earlier when I had to upgrade and munge my Ubuntu system to get TensorFlow to work properly with Python 3 and some other stuff and crap I forget about; long story short, I can no longer perform an upgrade to my system (I'm on 14.04 too!) - the tool b0rks hard when I try, and I honestly don't recall enough to return my system back to working status (I also had to install a major upgrade to gcc - which necessitated upgrades to other things, new manual symlinks, hours of swearing). This was all needed for the Udacity Self-Driving Car Engineer Nanodegree because of their system requirements for code and such (had I been running 16.04, it would have been easier - most likely - but that was also fraught with potential issues, which is why I didn't pursue it). Looking back on things, I probably shoulda used a container or VM, or built a new machine, but I was pressed for time. I was assured in the beginning, before the class started, that what I had would work - like many things in the course, this wasn't true (I'm not saying they lied or misrepresented stuff - my cohort was only the second cohort from November, and so I am a part of the "guinea pig" crowd as they debug the new course - paying beta tester, if you will). A system like Gobo might have been useful for this...

deleted 9y ago

[deleted]

aclsid 9y ago

On Mac OS X, it has been considered that putting an application folder/icon in the trash (even if some other stuff might happen in the process), was a superior approach to Add/Remove Programs or find package name/uninstall with package manager approach of most distros. So maybe you are a die hard fan of old ways, but it clearly is a mess and not user friendly at all. Just look at why the LSB was created and more importantly, why nobody is following it 100%. If that does not seem like a problem to you I don't know what to tell you. As for the root structure, they do mention in the article that it is optional. It can be turned off by disabling the kernel extension.