Installing each package into it's own directory, and maintaining symlinks into that directory structure, was an approach explored for large system installations in the 90s and 00s.
NIST depot, Xheir, CMU, and Nix all did this in varying ways. The advantage of this approach was that packages could be installed once on an NFS, scoped by version/configuration, and mounted into the filesystem of every work station on a campus. The workstations then just needed to maintain references to the files on the NFS for their particular software configurations. There is also some interesting exploration of composable configuration templates that allow workstations to inherit and extend a particular configuration (i.e. the physics department might have a base template).
Nix is easily the most successful in this space. It even uses something similar to the NFS approach! It can maintain a remote cache of observed configurations to pull from instead of redoing work.
Reading these LISA papers is a lot of fun. If you work in system administration (i.e. maintaining an Artifactory instance for your company) and have a day to spare - I'd very much recommend reading them, starting with the Nix paper!
Nix is great! But GoboLinux is actually a few years older than Nix, isn't it? First release in 2003. :)
Interestingly, GoboLinux Runners are basically the same concept as NixOS' FHSUserEnvs, where user namespaces are used to mount a subset of the existing shared libraries and other dependencies to make them visible (and the only ones visible) to a running program in a compatible way. This spares them some of the filesystem overhead of running a full OS container with its own package manager. So there's a bit of further convergence there, too.
I love the cleanliness and legibility of the GoboLinux file hierarchy, and I think the simple, Mac-ish app bundling approach it takes is something many users might like and prefer over the rough edges of Nix or the complexity of Flatpak.
A GoboLinux-like presentation could be great for a stable, impure NixOS downstream some day.
Thanks for the link to the Depot Lite paper! I'd never heard of it.
That’s kind of funny, because Microsoft do something similar with WinSxS. Only worse.
What they do is store packages in the winsxs folder. They then do an NTFS hard link to where the component is installed, usually system32.
If you ever used Vista and Windows 7 and started to run out of disk space over time, that’s because Microsoft never used to remove the old components after they were updated. In Windows 7, the initial plan after SP1 was to allow people to use a special switch on DISM.exe to remove old service pack files.
Microsoft removed the idea of service packs and instead did continuous patching with rollups. It seems to taken them quite some time before they twigged to the fact that the old updates were using up a lot of disk space, because a long time later (almost at the end of the Windows 7 lifecycle) they added a Windows update to the disk cleanup wizard. Even worse, it would only remove the components after you rebooted but before you could login to Windows. If you ran it, it could sometimes take literally hours to get the computer to finish removing files from the component store.
This is actually a neat idea, and I am saying that as the archetypical, grumpy "I like my sys the way it is, thank you very much!" - kinda guy.
A lot of the directory structure of POSIX systems is completely obsolete in the 21st century. The difference between sbin and bin? Historical, for the most part, and irrelevant in the age of rescue systems.
One question that is nagging at my mind with this: What if two programs require the same lib, how is this resolved?
Because, when I install progA, the lib is symlinked into the index, so when I now install progB, the lib is installed again if I understood correctly. Storage is irrelevant, the pkg manager sees there is a symlink, so it stays in place, all is well.
But now I remove progA, so what happens? progB is still present, still requires the lib, it is also still installed, but now the symlink, which refered to /Programs/progA/libs/thelib.so is broken. How is this situation handled?
I think libs are installed in /Programs too, and everything is versioned, and all libraries are linked to a central /System/Index/lib directory, which is referenced by ld by default: ( See https://gobolinux.org/at_a_glance.html )
I guess it's up to the package manager or application to reference the version of the library at the correct specificity. And then it's up to the package manager to GC libs that aren't referenced anymore.
Personally I think it would have been interesting to version the system index itself, like /System/Index/Current|1.0|myappenv|etc/lib|bin|etc, and each app is chrooted into their own system index by default.
Sbin and bin separation actually causes problems with portability. A certain bluetooth-related utility wants to run iptables command [1] which can usually be found in `/sbin`. But `/sbin` is not in the PATH so they have hardcoded `/sbin/iptables` into the source. Now distributions that have iptables in `/usr/sbin` have to patch the program.
So it would be better if either there were no `/sbin` or if it was always in the PATH.
Well in a lot of new distributions /bin, /sbin and /usr/sbin are symlinks to /usr/bin.
The historical difference is that in /sbin there are binaries meant to be executed by root, and thus they were not be put in the path of non root users (Debian still do that), so you don't get binaries that you can't run in your path (these days it's stupid since you may want to use sudo and thus have them in path only for the shell autocomplete to work properly).
By the way I prefer how things are nowadays, otherwise you get the same confusion that I have every time I use Windows or macOS that you either have an infinite PATH variable or have to specify the full path every time.
Yes, the package manager can make symlinks, but at that point what is the difference?
Also having everything in /usr/bin has the good side effect of avoiding that by mistakes someone creates a program that has the same name of one of the thousands of programs that are in the repository of a distribution, to avoid confusion to the user that can launch a program or another depending on who comes first in the path.
I think for shared libraries, the convention is to have the major version number of the API in the name (e.g. foo.so, foo2.so) and then to put any ABI changes as a trailing extension (e.g. foo.so.2, foo.so.3, foo2.so.2, foo2.so.3). It's kind of a hack, but it makes sure that you can link unambiguously to one if you need it.
EDIT: didn't realize you were talking about Gobo specifically; not sure how they deal with this, but theoretically a similar strategy seems like it could work
As far as I can tell, the package manager handles dependencies, like most other package managers. Packages can declare dependencies on other packages, and the package manager installs each dependency only once globally.
I think they just intend to duplicate everything, but I'm not sure.
One of the biggest issues with 'improved' systems is that even when they are actually a whole lot better, it makes it nearly impossible to reason about the system or the state of the system using filesystem primitives or other first principles.
Take journals in systemd for example, they are better than plaintext log files in some cases, but now you are stuck with a format that needs to be interpreted and parsed before it is useful.
That doesn't mean improvements shouldn't be done, but every step that is a big change often also makes it impossible to do some basic things that used to be possible for decades. This is similar to analog radio (i.e. only requiring a diode, tunable capacitor and a coil to receive audio! - no power supply needed!) vs. DAB. DAB has a lot of improvements over the base feature, as well as a whole lot of new features. But it is no longer possible to simply receive the radio waves and get audio.
In a way you lose simplicity to gain sophistication. Sometimes we get sophisticated simplicity where a complex problem was solved in a very neat and elegant way that can be reasoned about with ease, but most times it isn't the case and that makes me (and a whole lot of other people it seems) wonder how we can get the improvement without losing the simplicity.
For the very simple "the filesystem is the database" concept, this might actually be possible, all we really get is a well-known structure and versioning with symlinks, similar to the alternatives system used in Debian. But then we get /Programs which is capitalised which looks nice but mixed capitalisation seems too much of a "they are doing it, thus so are we" thing, while on a filesystem level there isn't any gain. Same with spaces in names or dashes. For visual representation that is nice, but everything else it sucks.
I would take out the capitalisation and add some sort of unionfs/aufs/overlayfs hooking (symlink into a bundled filesystem would be one way) so from the system's perspective it's still a single filesystem tree but you add the option to get all those newfangled distribution methods in there as well. The problem we still haven't solved is versioning, but since it is arbitrary at this point /programs (or just call it /apps) could just contain <shortname>/<versionstring> for the application name and then version of the application. If you then dump in a version that comes from a docker image, flatpak, some weird weine-dxvk-steam construction or something else you symlink it in as a <versionstring> and then it's no longer the problem of the distro.
There is still the issue of partitioning off parts of the system you don't want to be touched or want to have safe; a RO-snapshot plus user-overrides could work, but you might end up with a huge RO-snapshot that needs to be entirely replaced, and then a billion override mounts on top of that...
As simple as Gobolinux presents it, this only seems to be useful for a single distro with a single distribution point, which is no longer where we are. Even FreeBSD is past that and that's not even Linux.
Perhaps a new concept of a "symlink with backups" could be introduced.
You install ProgA and the lib is symlinked into the index
You install ProgB and the index's symlink to ProgA's lib gets some information added to it along the lines of "if the symlink to ProgA/lib is broken, try ProgB/lib"
Then when you uninstall ProbA the fallback symlink is activated.
At some point you would want to clean up the dangling primary link but maybe the best time to do it is immedately. i.e. the first time the primary fails you make the backup the new primary and now there's no backup, i.e. it looks the way it would look if you had only ever installed ProgB.
In my mind the principal reason for the current hierarchy is read/write usage.
With /etc and /usr it is possible after installation and configuration to set one or both as Read Only. With /var and /home you have the directories that should be Read/Write on a running system. This allows you to mount each of those directories on a different partition with different settings or even different filesystems depending on how you want to optimize/secure your application.
Now admittedly actually doing this is pretty rare in these days, but I still like having the option. I believe he does address this talking about "union mounts" and "overlay filesystems". I'm really not too familiar with either or how production ready they are, but it may address my concerns.
Honestly, now that Apple has proven you can run a POSIX OS on a case-insensitive filesystem, I'd think any "let's clean up the directory structure" project should be leveraging that work and going full case-insensitive. Case sensitivity should be avoided for anything outside of passwords and base64 and the like
Cool! I thought it was no longer maintained. Although it influenced the distro landscape much less than it could, things have changed enough so that I have mostly a "don't care" feeling about gobolinux.
Most end users rarely interact directly with the filesystem, so a different hierarchy won't impact many people. Installing up-to-date packages that do not threaten the stability of your system is easy with flatpaks/snaps; it is even possible to install GNOME Software add-ons to handle them. If you want to install "system-software" that is not possible with snaps or flatpaks, there's always Nix, Guix or homebrew. All that without considering AppImages, of course.
So... gobolinux is a great idea. But it fixes problems that are much smaller today.
It's going to need a lot more "Recipes" for packages in "Compile" (1) for GoboLinux to get mainstream. As it stands now, a lot of users are going to have to manually build/install many of their required programs to make them work. Is there a dedicated team out there making those recipes for different programs or do they just hope maintainers will take notice and do it themselves?
This is a really excellent way to manage packages in a system, I ran lots of systems a long time ago this way because of Dan Bernstein https://cr.yp.to/slashpackage/management.html
Long ago (maybe 15 years) I tried Gobolinux and thought it was a better approach for the typical Linux convert from Windows. I believe it was the lack of software, relative to Debian, Ubuntu, or Fedora, that kept me from running it.
Some people are asking how it compares to some cross-distro package managers.
The answer is, it doesn't – but it does seem to me that it would be very cool to see Gobo contain support for Flatpak, Snap and AppImage.
This would alleviate its shortage of apps somewhat. Keep the distro simple, and just don't package apps: outsource that to the cross-distro package formats.
Secondly, ISTM that Gobo would be a natural fit for a desktop that already treats certain specially-structured directories _as_ apps. I only know of 2 of these: GNUstep, which uses essentially the same `.app` bundles as macOS, and the ROX Desktop, which has !AppDirs that are closely modelled on Acorn's RISC OS. This, incidentally, is the internal format of AppImage.
The above paths have the format of "/Programs/<PackageName>/<VersionNumber>/<TraditionalDirectory>/<FileName>". GoboLinux presumably scans every package directory and adds symbolic links to "/System/Index/<TraditionalDirectory>/<FileName>", like the following example (respectively):
The primary file locations make it easy to handle one package at a time, cleanly adding and removing entire packages. The indexed view makes it easy to find files (binaries, libraries, includes, man pages, etc.) by name without worrying about what packages they belong to.
Generally speaking, tagging can be half-simulated using hierarchies and (hard/soft) links. But a tag-based system would be cleaner and not prioritize one retrieval method over another. Here is an illustration of how I might rephrase GoboLinux's package storage and retrieval system in terms of tags:
Blob("... binary data of bash executable ..."), with hash = 9e19e455.
Blob("... binary data of ping executable ..."), with hash = 28224f5b.
Blob("... binary data of libpng.so library ..."), with hash = 6243c115.
Blob("... binary data of stdio.h C code ..."), with hash = d0335126.
Tag(packageName="Bash", version="4.4", target=9e19e455).
Tag(packageName="Netkit-Base", Version="0.17", target=28224f5b).
Tag(packageName="LibPNG", version="1.2.5", target=6243c115).
Tag(packageName="Glibc", version="2.24", target=d0335126).
Tag(traditionalDirectory="bin", fileName="bash", target=9e19e455).
Tag(traditionalDirectory="bin", fileName="ping", target=28224f5b).
Tag(traditionalDirectory="lib", fileName="libpng.so.3", target=6243c115).
Tag(traditionalDirectory="include", fileName="stdio.h", target=d0335126).
Starting directory names with capital letter is not a good idea. While that might look nice, it requires more keypresses when typing it in the terminal. So /apps or /soft would be better than /Programs.
It is convenient in case-insensitive filesystems like those used in Windows or Mac, but not in Linux. By the way it would be better if Linux also switched to case-insensitive filesystem, or even a filesystem where similar looking characters from different alphabets are considered the same. So that A is always A no matter what alphabet is used.
Also I don't like the way they hide classic directories like /bin. Instead, they should just not create these directories; well-written programs should not require their presence.
The response by one of the devs to the first problem is "In fact, the concerns on typing-friendliness always comes up in discussions about the GoboLinux tree. To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab." [0]
The response to your second problem is that not all programs are well written, and they cannot afford to patch every poorly-written program.
From the faq it sounds like the purpose is to differentiate the gobolinux top level folders from the hidden compatibility folders, which makes sense to me.
I think this approach is very similar to how Android is handling the different apps where each gets installed into its own dedicated path directory. (I may be wrong though, cant remember since the last time I‘ve looked into the AOSP)
I have a Gobo VM set up, but I have to warn you, in the latest ISO the package manager is broken, it requires a loopback device, which isnt present in the install (why?)
Seeing those files with capitalized filenames, please tell me they're using a case-insensitive filesystem. I hate capitals on case-sensitive filesystems.
[+] [-] r3trohack3r|4 years ago|reply
Installing each package into it's own directory, and maintaining symlinks into that directory structure, was an approach explored for large system installations in the 90s and 00s.
NIST depot, Xheir, CMU, and Nix all did this in varying ways. The advantage of this approach was that packages could be installed once on an NFS, scoped by version/configuration, and mounted into the filesystem of every work station on a campus. The workstations then just needed to maintain references to the files on the NFS for their particular software configurations. There is also some interesting exploration of composable configuration templates that allow workstations to inherit and extend a particular configuration (i.e. the physics department might have a base template).
Nix is easily the most successful in this space. It even uses something similar to the NFS approach! It can maintain a remote cache of observed configurations to pull from instead of redoing work.
Reading these LISA papers is a lot of fun. If you work in system administration (i.e. maintaining an Artifactory instance for your company) and have a day to spare - I'd very much recommend reading them, starting with the Nix paper!
To get you started:
Nix - https://www.usenix.org/conference/lisa-04/nix-safe-and-polic...
Depot Lite - https://www.usenix.org/conference/lisa-viii/depot-lite-mecha...
[+] [-] pxc|4 years ago|reply
Interestingly, GoboLinux Runners are basically the same concept as NixOS' FHSUserEnvs, where user namespaces are used to mount a subset of the existing shared libraries and other dependencies to make them visible (and the only ones visible) to a running program in a compatible way. This spares them some of the filesystem overhead of running a full OS container with its own package manager. So there's a bit of further convergence there, too.
I love the cleanliness and legibility of the GoboLinux file hierarchy, and I think the simple, Mac-ish app bundling approach it takes is something many users might like and prefer over the rough edges of Nix or the complexity of Flatpak.
A GoboLinux-like presentation could be great for a stable, impure NixOS downstream some day.
Thanks for the link to the Depot Lite paper! I'd never heard of it.
[+] [-] chris_wot|4 years ago|reply
What they do is store packages in the winsxs folder. They then do an NTFS hard link to where the component is installed, usually system32.
If you ever used Vista and Windows 7 and started to run out of disk space over time, that’s because Microsoft never used to remove the old components after they were updated. In Windows 7, the initial plan after SP1 was to allow people to use a special switch on DISM.exe to remove old service pack files.
Microsoft removed the idea of service packs and instead did continuous patching with rollups. It seems to taken them quite some time before they twigged to the fact that the old updates were using up a lot of disk space, because a long time later (almost at the end of the Windows 7 lifecycle) they added a Windows update to the disk cleanup wizard. Even worse, it would only remove the components after you rebooted but before you could login to Windows. If you ran it, it could sometimes take literally hours to get the computer to finish removing files from the component store.
[+] [-] usrbinbash|4 years ago|reply
A lot of the directory structure of POSIX systems is completely obsolete in the 21st century. The difference between sbin and bin? Historical, for the most part, and irrelevant in the age of rescue systems.
One question that is nagging at my mind with this: What if two programs require the same lib, how is this resolved?
Because, when I install progA, the lib is symlinked into the index, so when I now install progB, the lib is installed again if I understood correctly. Storage is irrelevant, the pkg manager sees there is a symlink, so it stays in place, all is well.
But now I remove progA, so what happens? progB is still present, still requires the lib, it is also still installed, but now the symlink, which refered to /Programs/progA/libs/thelib.so is broken. How is this situation handled?
[+] [-] infogulch|4 years ago|reply
Personally I think it would have been interesting to version the system index itself, like /System/Index/Current|1.0|myappenv|etc/lib|bin|etc, and each app is chrooted into their own system index by default.
[+] [-] codedokode|4 years ago|reply
So it would be better if either there were no `/sbin` or if it was always in the PATH.
[1] https://github.com/blueman-project/blueman/blob/fcef83a01c80...
[+] [-] alerighi|4 years ago|reply
The historical difference is that in /sbin there are binaries meant to be executed by root, and thus they were not be put in the path of non root users (Debian still do that), so you don't get binaries that you can't run in your path (these days it's stupid since you may want to use sudo and thus have them in path only for the shell autocomplete to work properly).
By the way I prefer how things are nowadays, otherwise you get the same confusion that I have every time I use Windows or macOS that you either have an infinite PATH variable or have to specify the full path every time.
Yes, the package manager can make symlinks, but at that point what is the difference?
Also having everything in /usr/bin has the good side effect of avoiding that by mistakes someone creates a program that has the same name of one of the thousands of programs that are in the repository of a distribution, to avoid confusion to the user that can launch a program or another depending on who comes first in the path.
[+] [-] saghm|4 years ago|reply
EDIT: didn't realize you were talking about Gobo specifically; not sure how they deal with this, but theoretically a similar strategy seems like it could work
[+] [-] duped|4 years ago|reply
Shared libraries actually being shared is the exception and not the rule
[+] [-] codedokode|4 years ago|reply
[+] [-] potatoalienof13|4 years ago|reply
[+] [-] oneplane|4 years ago|reply
Take journals in systemd for example, they are better than plaintext log files in some cases, but now you are stuck with a format that needs to be interpreted and parsed before it is useful.
That doesn't mean improvements shouldn't be done, but every step that is a big change often also makes it impossible to do some basic things that used to be possible for decades. This is similar to analog radio (i.e. only requiring a diode, tunable capacitor and a coil to receive audio! - no power supply needed!) vs. DAB. DAB has a lot of improvements over the base feature, as well as a whole lot of new features. But it is no longer possible to simply receive the radio waves and get audio.
In a way you lose simplicity to gain sophistication. Sometimes we get sophisticated simplicity where a complex problem was solved in a very neat and elegant way that can be reasoned about with ease, but most times it isn't the case and that makes me (and a whole lot of other people it seems) wonder how we can get the improvement without losing the simplicity.
For the very simple "the filesystem is the database" concept, this might actually be possible, all we really get is a well-known structure and versioning with symlinks, similar to the alternatives system used in Debian. But then we get /Programs which is capitalised which looks nice but mixed capitalisation seems too much of a "they are doing it, thus so are we" thing, while on a filesystem level there isn't any gain. Same with spaces in names or dashes. For visual representation that is nice, but everything else it sucks.
I would take out the capitalisation and add some sort of unionfs/aufs/overlayfs hooking (symlink into a bundled filesystem would be one way) so from the system's perspective it's still a single filesystem tree but you add the option to get all those newfangled distribution methods in there as well. The problem we still haven't solved is versioning, but since it is arbitrary at this point /programs (or just call it /apps) could just contain <shortname>/<versionstring> for the application name and then version of the application. If you then dump in a version that comes from a docker image, flatpak, some weird weine-dxvk-steam construction or something else you symlink it in as a <versionstring> and then it's no longer the problem of the distro.
There is still the issue of partitioning off parts of the system you don't want to be touched or want to have safe; a RO-snapshot plus user-overrides could work, but you might end up with a huge RO-snapshot that needs to be entirely replaced, and then a billion override mounts on top of that...
As simple as Gobolinux presents it, this only seems to be useful for a single distro with a single distribution point, which is no longer where we are. Even FreeBSD is past that and that's not even Linux.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] actinium226|4 years ago|reply
You install ProgA and the lib is symlinked into the index You install ProgB and the index's symlink to ProgA's lib gets some information added to it along the lines of "if the symlink to ProgA/lib is broken, try ProgB/lib"
Then when you uninstall ProbA the fallback symlink is activated.
At some point you would want to clean up the dangling primary link but maybe the best time to do it is immedately. i.e. the first time the primary fails you make the backup the new primary and now there's no backup, i.e. it looks the way it would look if you had only ever installed ProgB.
[+] [-] cassepipe|4 years ago|reply
[+] [-] DarylZero|4 years ago|reply
[+] [-] conexions|4 years ago|reply
Now admittedly actually doing this is pretty rare in these days, but I still like having the option. I believe he does address this talking about "union mounts" and "overlay filesystems". I'm really not too familiar with either or how production ready they are, but it may address my concerns.
[+] [-] egberts1|4 years ago|reply
Only beef I have is the CamelCase of GoboLinux CLIs.
We all can do without shifting the shift keys as much as possible.
Unless the ultimate goal is for 100% GUI mouse-click operation, which it does not appear to be.
I sense a tinge of hostility toward typists in general.
[+] [-] GordonS|4 years ago|reply
[+] [-] Pxtl|4 years ago|reply
[+] [-] marcodiego|4 years ago|reply
Most end users rarely interact directly with the filesystem, so a different hierarchy won't impact many people. Installing up-to-date packages that do not threaten the stability of your system is easy with flatpaks/snaps; it is even possible to install GNOME Software add-ons to handle them. If you want to install "system-software" that is not possible with snaps or flatpaks, there's always Nix, Guix or homebrew. All that without considering AppImages, of course.
So... gobolinux is a great idea. But it fixes problems that are much smaller today.
[+] [-] dartharva|4 years ago|reply
1. https://gobolinux.org/compile.html
[+] [-] bb010g|4 years ago|reply
[+] [-] syntax-rules|4 years ago|reply
[+] [-] GekkePrutser|4 years ago|reply
It's not for me I think (nor is Nix), but that's the nice thing about Linux, everyone can do things their own way. I mostly use FreeBSD anyway.
[+] [-] Ericson2314|4 years ago|reply
[+] [-] bachmeier|4 years ago|reply
[+] [-] transfire|4 years ago|reply
[+] [-] brnt|4 years ago|reply
[+] [-] lproven|4 years ago|reply
Some people are asking how it compares to some cross-distro package managers.
The answer is, it doesn't – but it does seem to me that it would be very cool to see Gobo contain support for Flatpak, Snap and AppImage.
This would alleviate its shortage of apps somewhat. Keep the distro simple, and just don't package apps: outsource that to the cross-distro package formats.
Secondly, ISTM that Gobo would be a natural fit for a desktop that already treats certain specially-structured directories _as_ apps. I only know of 2 of these: GNUstep, which uses essentially the same `.app` bundles as macOS, and the ROX Desktop, which has !AppDirs that are closely modelled on Acorn's RISC OS. This, incidentally, is the internal format of AppImage.
[+] [-] zuj|4 years ago|reply
https://www.nayuki.io/page/designing-better-file-organizatio...
[+] [-] Rygian|4 years ago|reply
Everything remains in a hierarchical structure (or a few, if you consider the symlinks).
The notion of tags does away with a hierarchy.
[+] [-] nayuki|4 years ago|reply
Their documentation gives examples of primary files stored at locations like:
The above paths have the format of "/Programs/<PackageName>/<VersionNumber>/<TraditionalDirectory>/<FileName>". GoboLinux presumably scans every package directory and adds symbolic links to "/System/Index/<TraditionalDirectory>/<FileName>", like the following example (respectively): The primary file locations make it easy to handle one package at a time, cleanly adding and removing entire packages. The indexed view makes it easy to find files (binaries, libraries, includes, man pages, etc.) by name without worrying about what packages they belong to.Generally speaking, tagging can be half-simulated using hierarchies and (hard/soft) links. But a tag-based system would be cleaner and not prioritize one retrieval method over another. Here is an illustration of how I might rephrase GoboLinux's package storage and retrieval system in terms of tags:
[+] [-] pshirshov|4 years ago|reply
[+] [-] galaxyLogic|4 years ago|reply
[+] [-] codedokode|4 years ago|reply
It is convenient in case-insensitive filesystems like those used in Windows or Mac, but not in Linux. By the way it would be better if Linux also switched to case-insensitive filesystem, or even a filesystem where similar looking characters from different alphabets are considered the same. So that A is always A no matter what alphabet is used.
Also I don't like the way they hide classic directories like /bin. Instead, they should just not create these directories; well-written programs should not require their presence.
[+] [-] potatoalienof13|4 years ago|reply
The response to your second problem is that not all programs are well written, and they cannot afford to patch every poorly-written program.
[0] https://gobolinux.org/doc/articles/clueless.html
[+] [-] asperous|4 years ago|reply
[+] [-] forty|4 years ago|reply
[+] [-] tambourine_man|4 years ago|reply
[+] [-] nmz|4 years ago|reply
[+] [-] W0lf|4 years ago|reply
[+] [-] drdec|4 years ago|reply
[+] [-] ggm|4 years ago|reply
[+] [-] a-dub|4 years ago|reply
[+] [-] justaguy37|4 years ago|reply
[+] [-] lproven|4 years ago|reply
They call it "rootless". It runs inside your home directory.
[+] [-] KSPAtlas|4 years ago|reply
[+] [-] Pxtl|4 years ago|reply