10 ms·

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 di

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?

duped 5y ago
I'd rather progA and progB package their own local versions of thelib.so unless they explicitly request to use a shared version globally. Shared libraries actually being shared is the exception and not the rule
- bern4444 5y ago
  This is very similar to how npm works. Each installed package has its own dependencies installed that are kept separate from other packages even if another package has the same dependency. For all the hate of npm and node_modules it’s wonderful to have this isolation
  - Fnoord 5y ago
    Python also has virtualenv, so what though? Like Docker, its a dependency nightmare, and a waste of space. Nix also wastes space, but it allows you to run separate versions of libraries and programs universally on the OS, and it allows you to rollback, plus it can be easily removed with a command (man nix-collect-garbage).
deleted 5y ago
[deleted]
oneplane 5y ago
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.
actinium226 5y ago
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.
- function_seven 5y ago
  Why not use hard links instead? Both ProgA and ProgB will have their own links to the same inode. Either one can delete their own link, but the library will still exist unless all programs using it delete their links.
- pjc50 5y ago
  This is roughly what Debian "alternatives" does, although it's not used for libraries.
potatoalienof13 5y ago
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.
- lelanthran 5y ago
  I think GP was asking what happens when you remove a package that has thelib.so as a dependency. Is thelib.so removed? Does the previous existing thelib.so used as a replacement?
  - pxc 5y ago
    With any normal package manager, no. You don't remove a package that has any remaining 'reverse dependencies' (a.k.a 'dependents'). Removing only one of many dependent packages just has no effect on the dependency.
    - usrbinbash 5y ago
      But if BOTH packA & packB come with the same libs, one of them HAS TO get symlinked in the system index. And they do not depend on one another, as each has to bring the same lib to the system, so logically, they can both be removed without breaking a dependency. But since there can be only ne symlink to the library (because the lib is searched by name in the index) the question remains: How is the package manager handling this for Gobolinux?
      - lmm 5y ago
        Why would two different packages have the same library in them? Surely for every library there's a single package for that library, and if multiple applications depend on that library then their packages would depend on that package.
      - pxc 5y ago
        I think it may not be handled automatically. Looks like you could use find /System/Index | RemoveBroken and then you'd have to use SymlinkProgram to enable another provider of the shared libraries. In a way this is inside-out from what Nix and Guix do, where their equivalent of the System Index (the Nix/Guix store) is the build target, and everything all symlinks point to that. That makes this kind of thing a little easier to deal with, at some other costs.
codedokode 5y ago
They have separate directories for libraries under /Program, so I guess the library gets installed into a separate directory only once.
infogulch 5y ago
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 https://gobolinux.org/at_a_glance.html ) ~] ls -l /System/Index/lib libgtk.so -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1 libgtk-1.2.so.0 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1 libgtk-1.2.so.0.9.1 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1 Also: ~] cat /etc/ld.so.conf /System/Index/lib 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.
- usrbinbash 5y ago
  I understand how and where they are installed. The question is, when 2 packages, pkgA & pkgB bring in the same library, call it "thelib.so" into the system, logically, only 1 of them can be refered to by the symlink in System/Index/lib. So we have both /Programs/pkgA/1.0/lib/thelib.so /Programs/pkgB/1.0/lib/thelib.so And lets say the symlink points to the file of pkgA: /System/Index/lib/thelib.so -> /Programs/pkgA/1.0/lib/thelib.so What happens now if I remove pkgA? If nothing changes, the symlink would be dangling, and pkgB would no longer function because the libraries are looked up in the index. My question is: how is the pkg management system resolving this?
  - infogulch 5y ago
    Ah so basically how does it track dependencies? Good question. Browsing the wiki it looks like its basically manual :/ but I could be mistaken. https://github.com/gobolinux/Documentation/wiki/Removing-programs https://github.com/gobolinux/Documentation/wiki/Removing-pro... https://github.com/gobolinux/Documentation/wiki/Understanding-and-maintaining-system-indices https://github.com/gobolinux/Documentation/wiki/Understandin...
  - infogulch 5y ago
codedokode 5y ago
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. [1] https://github.com/blueman-project/blueman/blob/fcef83a01c80bec3bbee731a162ce18a0f4c097a/blueman/main/NetConf.py#L365 https://github.com/blueman-project/blueman/blob/fcef83a01c80...
- thorawy88 5y ago
  This is a ridiculous thought ending argument. Other projects need to sit still so one project doesn’t have to change one line of code? Nonsense. Keep up or get forked (that’s not a euphemism for vulgarity). It’s not esoteric magic like it used to be.
- lloydatkinson 5y ago
  Why do none of them make a PR to change the original repo instead of maintaining forks?
- zaphirplane 5y ago
  it is be better for the program to amend path for itself to include both paths. Or probe for its location Rather than hardcore one or the other
  - Dylan16807 5y ago
    Hardcoding two locations is only marginally better than hardcoding one. (By probe I assume you mean probing a hardcoded list rather than something even more fragile and confusing.)
    - zaphirplane 5y ago
      Why ? If it’s in the path use that, else if in /sbin use that else in /bin use that Everyone happy
saghm 5y ago
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
alerighi 5y ago
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.

duped 5y ago

I'd rather progA and progB package their own local versions of thelib.so unless they explicitly request to use a shared version globally. Shared libraries actually being shared is the exception and not the rule

bern4444 5y ago
This is very similar to how npm works. Each installed package has its own dependencies installed that are kept separate from other packages even if another package has the same dependency. For all the hate of npm and node_modules it’s wonderful to have this isolation
- Fnoord 5y ago
  Python also has virtualenv, so what though? Like Docker, its a dependency nightmare, and a waste of space. Nix also wastes space, but it allows you to run separate versions of libraries and programs universally on the OS, and it allows you to rollback, plus it can be easily removed with a command (man nix-collect-garbage).

deleted 5y ago

[deleted]

oneplane 5y ago

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.

actinium226 5y ago

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.

function_seven 5y ago
Why not use hard links instead? Both ProgA and ProgB will have their own links to the same inode. Either one can delete their own link, but the library will still exist unless all programs using it delete their links.
pjc50 5y ago
This is roughly what Debian "alternatives" does, although it's not used for libraries.

potatoalienof13 5y ago

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.

lelanthran 5y ago
I think GP was asking what happens when you remove a package that has thelib.so as a dependency. Is thelib.so removed? Does the previous existing thelib.so used as a replacement?
- pxc 5y ago
  With any normal package manager, no. You don't remove a package that has any remaining 'reverse dependencies' (a.k.a 'dependents'). Removing only one of many dependent packages just has no effect on the dependency.
  - usrbinbash 5y ago
    But if BOTH packA & packB come with the same libs, one of them HAS TO get symlinked in the system index. And they do not depend on one another, as each has to bring the same lib to the system, so logically, they can both be removed without breaking a dependency. But since there can be only ne symlink to the library (because the lib is searched by name in the index) the question remains: How is the package manager handling this for Gobolinux?
    - lmm 5y ago
      Why would two different packages have the same library in them? Surely for every library there's a single package for that library, and if multiple applications depend on that library then their packages would depend on that package.
    - pxc 5y ago
      I think it may not be handled automatically. Looks like you could use find /System/Index | RemoveBroken and then you'd have to use SymlinkProgram to enable another provider of the shared libraries. In a way this is inside-out from what Nix and Guix do, where their equivalent of the System Index (the Nix/Guix store) is the build target, and everything all symlinks point to that. That makes this kind of thing a little easier to deal with, at some other costs.

codedokode 5y ago

They have separate directories for libraries under /Program, so I guess the library gets installed into a separate directory only once.

infogulch 5y ago

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 https://gobolinux.org/at_a_glance.html ) ~] ls -l /System/Index/lib libgtk.so -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1 libgtk-1.2.so.0 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1 libgtk-1.2.so.0.9.1 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1 Also: ~] cat /etc/ld.so.conf /System/Index/lib 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.

usrbinbash 5y ago
I understand how and where they are installed. The question is, when 2 packages, pkgA & pkgB bring in the same library, call it "thelib.so" into the system, logically, only 1 of them can be refered to by the symlink in System/Index/lib. So we have both /Programs/pkgA/1.0/lib/thelib.so /Programs/pkgB/1.0/lib/thelib.so And lets say the symlink points to the file of pkgA: /System/Index/lib/thelib.so -> /Programs/pkgA/1.0/lib/thelib.so What happens now if I remove pkgA? If nothing changes, the symlink would be dangling, and pkgB would no longer function because the libraries are looked up in the index. My question is: how is the pkg management system resolving this?
- infogulch 5y ago
  Ah so basically how does it track dependencies? Good question. Browsing the wiki it looks like its basically manual :/ but I could be mistaken. https://github.com/gobolinux/Documentation/wiki/Removing-programs https://github.com/gobolinux/Documentation/wiki/Removing-pro... https://github.com/gobolinux/Documentation/wiki/Understanding-and-maintaining-system-indices https://github.com/gobolinux/Documentation/wiki/Understandin...
- infogulch 5y ago

codedokode 5y ago

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. [1] https://github.com/blueman-project/blueman/blob/fcef83a01c80bec3bbee731a162ce18a0f4c097a/blueman/main/NetConf.py#L365 https://github.com/blueman-project/blueman/blob/fcef83a01c80...

thorawy88 5y ago
This is a ridiculous thought ending argument. Other projects need to sit still so one project doesn’t have to change one line of code? Nonsense. Keep up or get forked (that’s not a euphemism for vulgarity). It’s not esoteric magic like it used to be.
lloydatkinson 5y ago
Why do none of them make a PR to change the original repo instead of maintaining forks?
zaphirplane 5y ago
it is be better for the program to amend path for itself to include both paths. Or probe for its location Rather than hardcore one or the other
- Dylan16807 5y ago
  Hardcoding two locations is only marginally better than hardcoding one. (By probe I assume you mean probing a hardcoded list rather than something even more fragile and confusing.)
  - zaphirplane 5y ago
    Why ? If it’s in the path use that, else if in /sbin use that else in /bin use that Everyone happy

saghm 5y ago

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

alerighi 5y ago

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.