<story><title>Gobolinux : Redefining Linux filesystem hierarchy</title><url>https://gobolinux.org/</url></story><parent_chain><item><author>usrbinbash</author><text>This is actually a neat idea, and I am saying that as the archetypical, grumpy &lt;i&gt;&amp;quot;I like my sys the way it is, thank you very much!&amp;quot;&lt;/i&gt; - kinda guy.&lt;p&gt;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.&lt;p&gt;One question that is nagging at my mind with this: What if two programs require the same lib, how is this resolved?&lt;p&gt;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.&lt;p&gt;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 &amp;#x2F;Programs&amp;#x2F;progA&amp;#x2F;libs&amp;#x2F;thelib.so is broken. How is this situation handled?</text></item></parent_chain><comment><author>infogulch</author><text>I think libs are installed in &amp;#x2F;Programs too, and everything is versioned, and all libraries are linked to a central &amp;#x2F;System&amp;#x2F;Index&amp;#x2F;lib directory, which is referenced by ld by default: ( See &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gobolinux.org&amp;#x2F;at_a_glance.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gobolinux.org&amp;#x2F;at_a_glance.html&lt;/a&gt; )&lt;p&gt;&lt;pre&gt;&lt;code&gt;    ~] ls -l &amp;#x2F;System&amp;#x2F;Index&amp;#x2F;lib
    libgtk.so           -&amp;gt; &amp;#x2F;Programs&amp;#x2F;GTK+&amp;#x2F;1.2.10&amp;#x2F;lib&amp;#x2F;libgtk-1.2.so.0.9.1
    libgtk-1.2.so.0     -&amp;gt; &amp;#x2F;Programs&amp;#x2F;GTK+&amp;#x2F;1.2.10&amp;#x2F;lib&amp;#x2F;libgtk-1.2.so.0.9.1
    libgtk-1.2.so.0.9.1 -&amp;gt; &amp;#x2F;Programs&amp;#x2F;GTK+&amp;#x2F;1.2.10&amp;#x2F;lib&amp;#x2F;libgtk-1.2.so.0.9.1
&lt;/code&gt;&lt;/pre&gt;
Also:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    ~] cat &amp;#x2F;etc&amp;#x2F;ld.so.conf
    &amp;#x2F;System&amp;#x2F;Index&amp;#x2F;lib
&lt;/code&gt;&lt;/pre&gt;
I guess it&amp;#x27;s up to the package manager or application to reference the version of the library at the correct specificity. And then it&amp;#x27;s up to the package manager to GC libs that aren&amp;#x27;t referenced anymore.&lt;p&gt;Personally I think it would have been interesting to version the system index itself, like &amp;#x2F;System&amp;#x2F;Index&amp;#x2F;Current|1.0|myappenv|etc&amp;#x2F;lib|bin|etc, and each app is chrooted into their own system index by default.</text></comment>
<story><title>Gobolinux : Redefining Linux filesystem hierarchy</title><url>https://gobolinux.org/</url></story><parent_chain><item><author>usrbinbash</author><text>This is actually a neat idea, and I am saying that as the archetypical, grumpy &lt;i&gt;&amp;quot;I like my sys the way it is, thank you very much!&amp;quot;&lt;/i&gt; - kinda guy.&lt;p&gt;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.&lt;p&gt;One question that is nagging at my mind with this: What if two programs require the same lib, how is this resolved?&lt;p&gt;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.&lt;p&gt;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 &amp;#x2F;Programs&amp;#x2F;progA&amp;#x2F;libs&amp;#x2F;thelib.so is broken. How is this situation handled?</text></item></parent_chain><comment><author>codedokode</author><text>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 `&amp;#x2F;sbin`. But `&amp;#x2F;sbin` is not in the PATH so they have hardcoded `&amp;#x2F;sbin&amp;#x2F;iptables` into the source. Now distributions that have iptables in `&amp;#x2F;usr&amp;#x2F;sbin` have to patch the program.&lt;p&gt;So it would be better if either there were no `&amp;#x2F;sbin` or if it was always in the PATH.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;blueman-project&amp;#x2F;blueman&amp;#x2F;blob&amp;#x2F;fcef83a01c80bec3bbee731a162ce18a0f4c097a&amp;#x2F;blueman&amp;#x2F;main&amp;#x2F;NetConf.py#L365&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;blueman-project&amp;#x2F;blueman&amp;#x2F;blob&amp;#x2F;fcef83a01c80...&lt;/a&gt;</text></comment>