19 ms·

Gobolinux : Redefining Linux filesystem hierarchy

329 points by cassepipe 5y ago

egberts1 5y ago
Mmmmm. 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 5y ago
  It's PascalCase, rather than camelCase, but I still agree with your point - capitalisation in a Linux file system just feels... weird!
  - pxc 5y ago
    I like initial caps for directory names and lowercase for filenames, which Linux desktop users are already accustomed to in their home folders. Caps leading command names is not great with case-sensitive filenames imo.
    - petre 5y ago
      I always change my home folders to a lowercase shorthened version and modify ~/.config/user-dirs.dirs. Of course, when you do an accidental rm -rf you're at disk to erase ~/work, but that's what regular backups are for. Expanding capitalisation to the whole filesystem hierarchy is a no go for me, it would only waste my time and further degrade my productivity. I also never liked Pascal, Java and C# specifically because of the weird capitalisation conventions which in my view makes the code look messy. PowerShell? Just call the exorcist.
  - nmz 5y ago
    FWIW I tend to put directories first character as Uppercase and files as lowercase. this is useful when sorting and also identifying what type of file something is (so long as its a file I created).
    - galaxyLogic 5y ago
      A file or folder can have a name with mixed uppercase and lowercase characters. That name would show in the directory listing. But it should be addressable case-insensitively. And it shouldn't be possible to create two or more separate files in the same directory which differ only by case.
      - nmz 5y ago
        Alas, in unix, there's {mkdir A a;touch A a} Which is sometimes useful, but I see what you're saying.
- Pxtl 5y ago
  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
  - galaxyLogic 5y ago
    So case-sensitive file-system was a historical mistake, and MS-DOS was ahead of its time.
    - Pxtl 5y ago
      Imho, yes. Well, except for the 8.3 thing. And the total path length limit. And the primitive security model. And the limits on having files named com and the like. But they were right on case-insensitive.
      - egberts1 5y ago
        not to mention uppercase COM1 or was that CON:?
cassepipe 5y ago
A response to inevitable critiques : https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html
- DarylZero 5y ago
  The obvious critique in 2021+ is "GoboLinux is a great concept but doesn't Nix make it obsolete?"
  - jiggunjer 5y ago
    Or docker.
    - lillecarl 5y ago
      Why is it that AppImages, snaps, flatpaks, Nix and every distro package manager is replaced by docker? Could it be that docker is missing something, maybe the Dockerfile isn't easily reproducible? Maybe the ephemeral status of all containers is quite some effort to work with? Maybe it's just not the one true answer to the question of software packaging.
      - jeroenhd 5y ago
        Identifying your dependencies is hard. The easy solution is not to care: develop on a machine, and ship the entire machine! That way, software with the Works On My Machine seal of approval can be pushed to production without trouble! I love Docker for the simplicity it offers, but the gigabytes of storage wasted on yet another slightly different version of Debian every time I pull a container irks me to no end. Sadly, it's the only way some software is distributed.
        goodpoint 5y ago
        Please tell me this is satire.
usrbinbash 5y ago
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]
GekkePrutser 5y ago
Cool, sounds a bit like how NixOS does things. 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 5y ago
  We'll get you with NixOS/kFreeBSD someday :D
  - pxc 5y ago
    It hurts me how close we could be to a single, cross-platform module system for Nix, because I know how awesome it would be. It's theoretically closer than ever, thanks to stuff like nix-processmgmt and Initware for the BSDs, but it feels like something that keeps coming close only to fade away :'( But Nix can absolutely do it, and it could be so extremely good! (There's lots of progress in the Nix world to enjoy and celebrate, as usual, but it's just that type of project that makes you think of all kinds of crazy new things it could do)
    - Ericson2314 5y ago
      Amen, yeah it does hurt. I am wondering if we should do some sort of course source to get some basic smoke test cross-compiled VMs for multiple kernels up and running. Just get over that hump, and I think it's all down hill and will work with our usual nixpkgs crowd-sourcing. What do you think?
      - pxc 5y ago
        I'm not sure what course source means, but I'm down to work on this. I don't really know much about other Unix-likes but I'm willing to stumble through it! What do you want to start with? FreeBSD + Initware (so that we can reuse the existing NixOS systemd service file generation stuff?) I think I'll try messing around with them a little on their own to get a feel for what they need in order to run
bachmeier 5y ago
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.
transfire 5y ago
Gobo was ahead of its time, in a way. Unfortunately mainstream distros have yet to really learn its lessons.
- brnt 5y ago
  I think that ultimately, very few users care about the file layout outside of ~, and perhaps not even that.
pshirshov 5y ago
It would be nice if they mix it with Nix. It makes little sense _not_ to use Nix, despite its numerous shortcomings.
- galaxyLogic 5y ago
  Mix it with Nix. That's the slogan!
rwoerz 5y ago
I hope that they will refrain from "optimizing" the new structure in every major release... Looking at you, Windows!
- DHowett 5y ago
  I'm struggling to figure out exactly which directory structure Windows has changed every major release -- are you referring to when "Documents and Settings" was renamed to "Users" with the release of Windows Vista in 2006? Or perhaps you are talking about when they added "Program Files (x86)" with the introduction of 64-bit support in Windows XP, dating back to 2001... I believe it used to default to installing Windows NT to C:\WINNT... but that was almost certainly longer ago than you're suggesting. To be fair, the Desktop also used to live at C:\WINDOWS\Desktop, but there are some pretty good reasons why it doesn't any longer.
  - MadcapJake 5y ago
    When did ProgramData and AppData become a thing? Is there a guide somewhere about what should be placed in each folder? Local, LocalLow, Roaming? Seems like there are several competing conventions.
    - wbkang 5y ago
      ProgramData is the global application storage. AppData has been there since at least XP. Local is intended to be specific to this computer whereas roaming is something that is user specific that can be available across machines. The closest thing I can find is this https://docs.microsoft.com/en-us/windows/win32/shell/knownfolderid https://docs.microsoft.com/en-us/windows/win32/shell/knownfo...
      - jopsen 5y ago
        Compared to the XDG directory specification that MSDN link is garbage. Just my personal opinion.
    - dragonwriter 5y ago
deleted 5y ago
[deleted]
justaguy37 5y ago
Can the package system be installed within another distro, much like Nix is able to be run without NixOS?
- lproven 5y ago
  Yes. They call it "rootless". It runs inside your home directory.
marcodiego 5y ago
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.
r3trohack3r 5y ago
This is a neat idea - and not without precedent. 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-policy-free-system-software-deployment https://www.usenix.org/conference/lisa-04/nix-safe-and-polic... Depot Lite - https://www.usenix.org/conference/lisa-viii/depot-lite-mechanism-managing-software https://www.usenix.org/conference/lisa-viii/depot-lite-mecha...
- dark-star 5y ago
  Wait, when did we come to the point where "working in system administration" is considered synonymous to "maintaining an Artifactory instance"?
  - dagw 5y ago
    About 3-5 years ago, give or take.
  - r3trohack3r 5y ago
    At least in my previous jobs, maintaining the artifactory instance included maintaining package integrity in the repositories. Answering questions about shadowing in Java, unpublishing in Node, upstream timelines for patched debs, and tracking deprecation was part of that the job - and the teams worked to make machines do as much of that job as possible. Packages bootstrap filesystems for installations. We’ve parted out system administration at scale - multiple paths you can take.
syntax-rules 5y ago
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 https://cr.yp.to/slashpackage/management.html
codedokode 5y ago
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.
- tambourine_man 5y ago
  I think bash autocomplete can be configured to be case insensitive
- forty 5y ago
  Case insensitivity is a mess as soon as you start looking outside of ASCII.
  - codedokode 5y ago
    But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today. But of course there is a place for improvement (dealing with accented letters in European languages, dealing with combining characters, different alphabets like Hiragana/Katakana etc).
    - forty 5y ago
      Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).
      - 5y ago
W0lf 5y ago
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)
Pxtl 5y ago
Seeing those files with capitalized filenames, please tell me they're using a case-insensitive filesystem. I hate capitals on case-sensitive filesystems.
zuj 5y ago
Naive question, isn't gobo, nix and other systems trying to make a tag based file systems at the end? https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies#choice-of-hash-function https://www.nayuki.io/page/designing-better-file-organizatio...
- Rygian 5y ago
  What leads you to think that? Everything remains in a hierarchical structure (or a few, if you consider the symlinks). The notion of tags does away with a hierarchy.
- nayuki 5y ago
  I do see GoboLinux simulating some aspects of tagging, based on reading https://gobolinux.org/at_a_glance.html https://gobolinux.org/at_a_glance.html and https://github.com/gobolinux/Documentation/wiki/What-makes-GoboLinux-unique%3F https://github.com/gobolinux/Documentation/wiki/What-makes-G... . Their documentation gives examples of primary files stored at locations like: /Programs/Bash/4.4/bin/bash /Programs/Netkit-Base/0.17/bin/ping /Programs/LibPNG/1.2.5/lib/libpng.so.3 /Programs/Glibc/2.24/include/stdio.h 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): /System/Index/bin/bash /System/Index/bin/ping /System/Index/lib/libpng.so.3 /System/Index/include/stdio.h 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).
ggm 5y ago
depot is 1994. Stow comes from depot. Fri Jun 7 12:13:33 1996 Bob Glickstein <bobg@hiro.zanshin.com> * Created stow, formerly "depot."
- a-dub 5y ago
  made me think of stow too.
drdec 5y ago
Can third party software be installed on GoboLinux? How does that work?
Apofis 5y ago
How's this different from FlatPak?
- lproven 5y ago
  Er... In every way? Flatpak is an app packaging system, distro-neutral. GoboLinux is a distro and a new, different way of organizing the Unix filesystem. Flatpak contains conventional (or at least similar) filesystem layouts inside app packages. Gobo replaces the contents of apps as well as the whole filesystem. Flatpak requires runtime infrastructure on the distro you wish to use. Gobo is a distro. Flatpak is distro-neutral; Gobo replaces other distros. Flatpack puts all apps in its own hierarchy deep inside /var and manages it itself. Gobo does not have a /var, or a /bin or /usr or anything else. Flatpak could be run on Gobo. Gobo could not be run on Flatpak, because Flatpak is for apps.
  - Apofis 5y ago
    I'm confused how Gobo's app directory structure is different from the structure Flatpak uses internally. Please elaborate.
    - lproven 5y ago
      I do not know how familiar you are with Flatpak, what it is and what it is for, and Gobo, what it is and what it is for. So this is a very broad request and could take tens of pages. Flatpak installs apps on any distro which has or has had Flatpak support installed on it. It does this by unpacking apps into its own directory trees. Apps go into: `/var/lib/flatpak/exports/share/applications` Inside there are more complex trees, so for instance, to reply, I just installed Sublime Text, and it is in: `/var/lib/flatpak/app/com.sublimetext.three/current/active` Inside that is a `files` folder. Inside that we see an encapsulated version of a traditional xNix filesystem: total 40 drwxr-xr-x 8 root root 4096 Jan 5 12:30 . drwxr-xr-x 4 root root 4096 Jan 5 12:30 .. drwxr-xr-x 2 root root 4096 Jan 1 1970 bin drwxr-xr-x 4 root root 4096 Jan 5 12:30 extra drwxr-xr-x 2 root root 4096 Jan 1 1970 lib -rw-r--r-- 2 root root 4817 Jan 5 12:30 manifest.json -rw-r--r-- 1 root root 0 Jan 5 12:30 .ref drwxr-xr-x 6 root root 4096 Jan 1 1970 share drwxr-xr-x 2 root root 4096 Jan 1 1970 sublime_merge drwxr-xr-x 2 root root 4096 Jan 1 1970 utils In here are traditional xNix dirs called `/bin` and `/lib` and so on. Flatpak is a wrapper around traditional xNix directory layout. It encapsulates them inside a layout it manages, allowing apps to be transported between different distros by having their own layout inside a private tree, but it's a fairly conventional xNix tree. With me so far? The conventional xNix layout has globally-shared folders, segregated by functional roles: this subtree is for sysadmin stuff, this subtree is for all users; this subtree is on the main disk and is needed for boot, this one is not essential for boot and is only used in multiuser mode, this subtree is auxiliary additions later, this one is local to this network node only, and so on. This was needed in the 1970s with very small disks that could not hold the entire OS. `/usr` was originally for home directories but some of the people using the OS were also simulatenously writing the OS. Stuff in their home directory became essential to the system. So it got fossilised into place meaning that a new `/home` tree was added later. The Mac and Windows conceptual model is different. It says, each app lives in a separate tree of its own, and we will put only files expected to be shared with other apps into system-global locations. So the OS itself is in `\OS\` and all the components of the app Bar by Foo Corp get put into `\apps\foo\bar`. Any shared libraries get copied into `\OS\libs\` so that other apps could use them. Later this was found to be a mistake and so `\app\Foo\bar\libs` was added for a known good copy. Gobo discards the traditional xNix model of global shared folders containing binaries from multiple sources, and segregates them in a Mac and DOS-like model. There is no real `/bin` or `/lib` folders. Instead, there are new trees: Programs, Users, System, Data, Mount etc. Inside Programs is a tree for each app, and inside that, for each version of that app. xNix: the files containing the components of each apps are split up and put in the system-global dirs for that type of component. Apps do not have their own dir. Config is in the config tree, libraries are in the libs tree, binaries are in the binaries tree, etc. Flatpak manages its own version of the global OS layout, one per app, inside the Flatpak tree. Apps are not put into the OS global dirs but each has its own private version of the OS-global tree inside its own dir tree inside the Flatpak tree. DOS, Windows: the OS lives in its own tree. Each app has its own subtree in the Apps tree and copies only shared components into OS-managed shared folders. Mac OS X: the OS lives in simplified xNix tree. Apps live entirely in their own private shared tree, one per app, with an OS-mandated layout. Gobo: the Mac OS X concept is extended to the OS itself. The OS' components are in private, versioned folders inside an OS-mandated tree, with the traditional xNix layout hidden. For legacy apps that expect trad xNix dirs, they are there but populated only with symlinks and the OS hides them from the user. Flatpak adapts the xNix model and encapsulates private versions of it. OS X keeps some of the xNix model for the OS only and enforces a new private-dir-tree model upon apps. Gobo takes the app model of OS X and applies it to the entire OS, and only fakes the trad xNix model to make it easier to port legacy code.
dartharva 5y ago
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? 1. https://gobolinux.org/compile.html https://gobolinux.org/compile.html
- bb010g 5y ago
  If it's like Nixpkgs, community members just submit packages as they start using them and maintain them.
KSPAtlas 5y ago
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?)
lproven 5y ago
Glad to see Gobo getting some attention. 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.

329 points by cassepipe 5y ago

Mmmmm. 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 5y ago
It's PascalCase, rather than camelCase, but I still agree with your point - capitalisation in a Linux file system just feels... weird!
- pxc 5y ago
  I like initial caps for directory names and lowercase for filenames, which Linux desktop users are already accustomed to in their home folders. Caps leading command names is not great with case-sensitive filenames imo.
  - petre 5y ago
    I always change my home folders to a lowercase shorthened version and modify ~/.config/user-dirs.dirs. Of course, when you do an accidental rm -rf you're at disk to erase ~/work, but that's what regular backups are for. Expanding capitalisation to the whole filesystem hierarchy is a no go for me, it would only waste my time and further degrade my productivity. I also never liked Pascal, Java and C# specifically because of the weird capitalisation conventions which in my view makes the code look messy. PowerShell? Just call the exorcist.
- nmz 5y ago
  FWIW I tend to put directories first character as Uppercase and files as lowercase. this is useful when sorting and also identifying what type of file something is (so long as its a file I created).
  - galaxyLogic 5y ago
    A file or folder can have a name with mixed uppercase and lowercase characters. That name would show in the directory listing. But it should be addressable case-insensitively. And it shouldn't be possible to create two or more separate files in the same directory which differ only by case.
    - nmz 5y ago
      Alas, in unix, there's {mkdir A a;touch A a} Which is sometimes useful, but I see what you're saying.
Pxtl 5y ago
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
- galaxyLogic 5y ago
  So case-sensitive file-system was a historical mistake, and MS-DOS was ahead of its time.
  - Pxtl 5y ago
    Imho, yes. Well, except for the 8.3 thing. And the total path length limit. And the primitive security model. And the limits on having files named com and the like. But they were right on case-insensitive.
    - egberts1 5y ago
      not to mention uppercase COM1 or was that CON:?

cassepipe 5y ago

A response to inevitable critiques : https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html

DarylZero 5y ago
The obvious critique in 2021+ is "GoboLinux is a great concept but doesn't Nix make it obsolete?"
- jiggunjer 5y ago
  Or docker.
  - lillecarl 5y ago
    Why is it that AppImages, snaps, flatpaks, Nix and every distro package manager is replaced by docker? Could it be that docker is missing something, maybe the Dockerfile isn't easily reproducible? Maybe the ephemeral status of all containers is quite some effort to work with? Maybe it's just not the one true answer to the question of software packaging.
    - jeroenhd 5y ago
      Identifying your dependencies is hard. The easy solution is not to care: develop on a machine, and ship the entire machine! That way, software with the Works On My Machine seal of approval can be pushed to production without trouble! I love Docker for the simplicity it offers, but the gigabytes of storage wasted on yet another slightly different version of Debian every time I pull a container irks me to no end. Sadly, it's the only way some software is distributed.
      - goodpoint 5y ago
        Please tell me this is satire.

usrbinbash 5y ago

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]

GekkePrutser 5y ago

Cool, sounds a bit like how NixOS does things. 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 5y ago
We'll get you with NixOS/kFreeBSD someday :D
- pxc 5y ago
  It hurts me how close we could be to a single, cross-platform module system for Nix, because I know how awesome it would be. It's theoretically closer than ever, thanks to stuff like nix-processmgmt and Initware for the BSDs, but it feels like something that keeps coming close only to fade away :'( But Nix can absolutely do it, and it could be so extremely good! (There's lots of progress in the Nix world to enjoy and celebrate, as usual, but it's just that type of project that makes you think of all kinds of crazy new things it could do)
  - Ericson2314 5y ago
    Amen, yeah it does hurt. I am wondering if we should do some sort of course source to get some basic smoke test cross-compiled VMs for multiple kernels up and running. Just get over that hump, and I think it's all down hill and will work with our usual nixpkgs crowd-sourcing. What do you think?
    - pxc 5y ago
      I'm not sure what course source means, but I'm down to work on this. I don't really know much about other Unix-likes but I'm willing to stumble through it! What do you want to start with? FreeBSD + Initware (so that we can reuse the existing NixOS systemd service file generation stuff?) I think I'll try messing around with them a little on their own to get a feel for what they need in order to run

bachmeier 5y ago

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.

transfire 5y ago

Gobo was ahead of its time, in a way. Unfortunately mainstream distros have yet to really learn its lessons.

brnt 5y ago
I think that ultimately, very few users care about the file layout outside of ~, and perhaps not even that.

pshirshov 5y ago

It would be nice if they mix it with Nix. It makes little sense _not_ to use Nix, despite its numerous shortcomings.

galaxyLogic 5y ago
Mix it with Nix. That's the slogan!

rwoerz 5y ago

I hope that they will refrain from "optimizing" the new structure in every major release... Looking at you, Windows!

DHowett 5y ago
I'm struggling to figure out exactly which directory structure Windows has changed every major release -- are you referring to when "Documents and Settings" was renamed to "Users" with the release of Windows Vista in 2006? Or perhaps you are talking about when they added "Program Files (x86)" with the introduction of 64-bit support in Windows XP, dating back to 2001... I believe it used to default to installing Windows NT to C:\WINNT... but that was almost certainly longer ago than you're suggesting. To be fair, the Desktop also used to live at C:\WINDOWS\Desktop, but there are some pretty good reasons why it doesn't any longer.
- MadcapJake 5y ago
  When did ProgramData and AppData become a thing? Is there a guide somewhere about what should be placed in each folder? Local, LocalLow, Roaming? Seems like there are several competing conventions.
  - wbkang 5y ago
    ProgramData is the global application storage. AppData has been there since at least XP. Local is intended to be specific to this computer whereas roaming is something that is user specific that can be available across machines. The closest thing I can find is this https://docs.microsoft.com/en-us/windows/win32/shell/knownfolderid https://docs.microsoft.com/en-us/windows/win32/shell/knownfo...
    - jopsen 5y ago
      Compared to the XDG directory specification that MSDN link is garbage. Just my personal opinion.
  - dragonwriter 5y ago

deleted 5y ago

[deleted]

justaguy37 5y ago

Can the package system be installed within another distro, much like Nix is able to be run without NixOS?

lproven 5y ago
Yes. They call it "rootless". It runs inside your home directory.

marcodiego 5y ago

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.

r3trohack3r 5y ago

This is a neat idea - and not without precedent. 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-policy-free-system-software-deployment https://www.usenix.org/conference/lisa-04/nix-safe-and-polic... Depot Lite - https://www.usenix.org/conference/lisa-viii/depot-lite-mechanism-managing-software https://www.usenix.org/conference/lisa-viii/depot-lite-mecha...

dark-star 5y ago
Wait, when did we come to the point where "working in system administration" is considered synonymous to "maintaining an Artifactory instance"?
- dagw 5y ago
  About 3-5 years ago, give or take.
- r3trohack3r 5y ago
  At least in my previous jobs, maintaining the artifactory instance included maintaining package integrity in the repositories. Answering questions about shadowing in Java, unpublishing in Node, upstream timelines for patched debs, and tracking deprecation was part of that the job - and the teams worked to make machines do as much of that job as possible. Packages bootstrap filesystems for installations. We’ve parted out system administration at scale - multiple paths you can take.

syntax-rules 5y ago

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 https://cr.yp.to/slashpackage/management.html

codedokode 5y ago

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.

tambourine_man 5y ago
I think bash autocomplete can be configured to be case insensitive
forty 5y ago
Case insensitivity is a mess as soon as you start looking outside of ASCII.
- codedokode 5y ago
  But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today. But of course there is a place for improvement (dealing with accented letters in European languages, dealing with combining characters, different alphabets like Hiragana/Katakana etc).
  - forty 5y ago
    Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).
    - 5y ago

W0lf 5y ago

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)

Pxtl 5y ago

Seeing those files with capitalized filenames, please tell me they're using a case-insensitive filesystem. I hate capitals on case-sensitive filesystems.

zuj 5y ago

Naive question, isn't gobo, nix and other systems trying to make a tag based file systems at the end? https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies#choice-of-hash-function https://www.nayuki.io/page/designing-better-file-organizatio...

Rygian 5y ago
What leads you to think that? Everything remains in a hierarchical structure (or a few, if you consider the symlinks). The notion of tags does away with a hierarchy.
nayuki 5y ago
I do see GoboLinux simulating some aspects of tagging, based on reading https://gobolinux.org/at_a_glance.html https://gobolinux.org/at_a_glance.html and https://github.com/gobolinux/Documentation/wiki/What-makes-GoboLinux-unique%3F https://github.com/gobolinux/Documentation/wiki/What-makes-G... . Their documentation gives examples of primary files stored at locations like: /Programs/Bash/4.4/bin/bash /Programs/Netkit-Base/0.17/bin/ping /Programs/LibPNG/1.2.5/lib/libpng.so.3 /Programs/Glibc/2.24/include/stdio.h 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): /System/Index/bin/bash /System/Index/bin/ping /System/Index/lib/libpng.so.3 /System/Index/include/stdio.h 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).

ggm 5y ago

depot is 1994. Stow comes from depot. Fri Jun 7 12:13:33 1996 Bob Glickstein <bobg@hiro.zanshin.com> * Created stow, formerly "depot."

a-dub 5y ago
made me think of stow too.

drdec 5y ago

Can third party software be installed on GoboLinux? How does that work?

Apofis 5y ago

How's this different from FlatPak?

lproven 5y ago
Er... In every way? Flatpak is an app packaging system, distro-neutral. GoboLinux is a distro and a new, different way of organizing the Unix filesystem. Flatpak contains conventional (or at least similar) filesystem layouts inside app packages. Gobo replaces the contents of apps as well as the whole filesystem. Flatpak requires runtime infrastructure on the distro you wish to use. Gobo is a distro. Flatpak is distro-neutral; Gobo replaces other distros. Flatpack puts all apps in its own hierarchy deep inside /var and manages it itself. Gobo does not have a /var, or a /bin or /usr or anything else. Flatpak could be run on Gobo. Gobo could not be run on Flatpak, because Flatpak is for apps.
- Apofis 5y ago
  I'm confused how Gobo's app directory structure is different from the structure Flatpak uses internally. Please elaborate.
  - lproven 5y ago
    I do not know how familiar you are with Flatpak, what it is and what it is for, and Gobo, what it is and what it is for. So this is a very broad request and could take tens of pages. Flatpak installs apps on any distro which has or has had Flatpak support installed on it. It does this by unpacking apps into its own directory trees. Apps go into: `/var/lib/flatpak/exports/share/applications` Inside there are more complex trees, so for instance, to reply, I just installed Sublime Text, and it is in: `/var/lib/flatpak/app/com.sublimetext.three/current/active` Inside that is a `files` folder. Inside that we see an encapsulated version of a traditional xNix filesystem: total 40 drwxr-xr-x 8 root root 4096 Jan 5 12:30 . drwxr-xr-x 4 root root 4096 Jan 5 12:30 .. drwxr-xr-x 2 root root 4096 Jan 1 1970 bin drwxr-xr-x 4 root root 4096 Jan 5 12:30 extra drwxr-xr-x 2 root root 4096 Jan 1 1970 lib -rw-r--r-- 2 root root 4817 Jan 5 12:30 manifest.json -rw-r--r-- 1 root root 0 Jan 5 12:30 .ref drwxr-xr-x 6 root root 4096 Jan 1 1970 share drwxr-xr-x 2 root root 4096 Jan 1 1970 sublime_merge drwxr-xr-x 2 root root 4096 Jan 1 1970 utils In here are traditional xNix dirs called `/bin` and `/lib` and so on. Flatpak is a wrapper around traditional xNix directory layout. It encapsulates them inside a layout it manages, allowing apps to be transported between different distros by having their own layout inside a private tree, but it's a fairly conventional xNix tree. With me so far? The conventional xNix layout has globally-shared folders, segregated by functional roles: this subtree is for sysadmin stuff, this subtree is for all users; this subtree is on the main disk and is needed for boot, this one is not essential for boot and is only used in multiuser mode, this subtree is auxiliary additions later, this one is local to this network node only, and so on. This was needed in the 1970s with very small disks that could not hold the entire OS. `/usr` was originally for home directories but some of the people using the OS were also simulatenously writing the OS. Stuff in their home directory became essential to the system. So it got fossilised into place meaning that a new `/home` tree was added later. The Mac and Windows conceptual model is different. It says, each app lives in a separate tree of its own, and we will put only files expected to be shared with other apps into system-global locations. So the OS itself is in `\OS\` and all the components of the app Bar by Foo Corp get put into `\apps\foo\bar`. Any shared libraries get copied into `\OS\libs\` so that other apps could use them. Later this was found to be a mistake and so `\app\Foo\bar\libs` was added for a known good copy. Gobo discards the traditional xNix model of global shared folders containing binaries from multiple sources, and segregates them in a Mac and DOS-like model. There is no real `/bin` or `/lib` folders. Instead, there are new trees: Programs, Users, System, Data, Mount etc. Inside Programs is a tree for each app, and inside that, for each version of that app. xNix: the files containing the components of each apps are split up and put in the system-global dirs for that type of component. Apps do not have their own dir. Config is in the config tree, libraries are in the libs tree, binaries are in the binaries tree, etc. Flatpak manages its own version of the global OS layout, one per app, inside the Flatpak tree. Apps are not put into the OS global dirs but each has its own private version of the OS-global tree inside its own dir tree inside the Flatpak tree. DOS, Windows: the OS lives in its own tree. Each app has its own subtree in the Apps tree and copies only shared components into OS-managed shared folders. Mac OS X: the OS lives in simplified xNix tree. Apps live entirely in their own private shared tree, one per app, with an OS-mandated layout. Gobo: the Mac OS X concept is extended to the OS itself. The OS' components are in private, versioned folders inside an OS-mandated tree, with the traditional xNix layout hidden. For legacy apps that expect trad xNix dirs, they are there but populated only with symlinks and the OS hides them from the user. Flatpak adapts the xNix model and encapsulates private versions of it. OS X keeps some of the xNix model for the OS only and enforces a new private-dir-tree model upon apps. Gobo takes the app model of OS X and applies it to the entire OS, and only fakes the trad xNix model to make it easier to port legacy code.

dartharva 5y ago

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? 1. https://gobolinux.org/compile.html https://gobolinux.org/compile.html

bb010g 5y ago
If it's like Nixpkgs, community members just submit packages as they start using them and maintain them.

KSPAtlas 5y ago

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?)

lproven 5y ago

Glad to see Gobo getting some attention. 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.