14 ms·

GoboLinux

283 points by haunter 3y ago

infotainment 3y ago
It's such a shame the ideas of GoboLinux never caught on in the mainstream Linux community. Linux's filesystem structure is a complete mess.
- Gormo 3y ago
  > Linux's filesystem structure is a complete mess. I don't think that's a valid claim. Something being organized on principles that are different from yours is not the same as it being disorganized in itself.
  - cassepipe 3y ago
    Unless those principles are merely the solution to problems that don't exist anymore like /usr separation ?
    - Gormo 3y ago
      Yes; the presumed obsolescence of a problem does not imply that remaining elements of its solution are "a mess".
      - nunobrito 3y ago
        Call it technical debt if you prefer: https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt Either way that old situation is a mess in my opinion, you are of course free to have yours.
        Gormo 3y ago
        > Call it technical debt if you prefer: https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt I don't prefer to call it that. In fact, it's almost the exact opposite of technical debt, which is generally the result of trying to change things too much, too quickly. Having stable conventions that account for edge cases that are addressed sufficiently to the point that we don't have to think about them is an asset, not debt, and the principle of Chesterton's Fence ought to always be applied when proposing changes that drastically alter long-established conventions.
- sedatk 3y ago
  s/Linux/Unix MacOS is better though.
  - tomrod 3y ago
    This is a joke, right? MacOS is all over the place?
    - rufugee 3y ago
      Agreed...I fail to see how macOS is an improvement. I mean, you have /Applications, but you also have /Library, ~/Library, and so on.
      - pavel_lishin 3y ago
        And /Applications, and /System/Applications, even though if you open them in Finder, you'll see the two combined.
        reactordev 3y ago
        And ~/Applications, and /usr/bin, and /usr/local/bin, and homebrew, and Mac ports, tell me again how Mac is better?
        sedatk 3y ago
        I just wasn’t aware of these issues. Let me rephrase it then: MacOS’ intentions were better. :)
        tomrod 3y ago
        Eh............................. maybe? :)
    - wraptile 3y ago
      I'd say that MacOS is even worse which is impressive given that Apple has the absolute control of the platform and seemingly infinite resources and could have refactored the mess at any point.
- discardedrefuse 3y ago
  The Windows Program Files style directories might make sense to you on a single user workstation. But on a multi-user server, its a security nightmare.
  - spoiler 3y ago
    I'm curious how bin is different from Program Files? Unless you mean stuff like configuration? I think user configuration would still reside somewhere under the user's home dir
    - discardedrefuse 3y ago
      1. /bin (and /sbin) were intended for programs that needed to be on a small / partition before the larger /usr, etc. partitions were mounted. These days, it mostly serves as a standard location for key programs like /bin/sh, although the original intent may still be relevant for e.g. installations on small embedded devices. 2. /sbin, as distinct from /bin, is for system management programs (not normally used by ordinary users) needed before /usr is mounted. 3. /usr/bin is for distribution-managed normal user programs. 4. There is a /usr/sbin with the same relationship to /usr/bin as /sbin has to /bin. 5. /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning. 6. /usr/local/sbin, as you can probably guess at this point, is to /usr/local/bin as /usr/sbin to /usr/bin. source: https://unix.stackexchange.com/a/8658 https://unix.stackexchange.com/a/8658
      - gertop 3y ago
        You said Program Files was a security nightmare compared to the Linux mess, that is what he was asking about. How is /bin safer than Program Files? None of the things you listed have any relevance to that question.
      - spoiler 3y ago
        I'm familiar with the intent behind the structure. I am mostly asking about the security implications you mentioned. One downside to Program Files type structure is that there's probably going to be some duplicate libraries lying around. However, as someone who's battled version skews due to clashing maintainer mindsets: that's been a much bigger pain in my ass than a few wasted kbs!
- jauntywundrkind 3y ago
  /opt and /srv (and or /usr/local/opt if that's your preference) grant many of the nicities of managing your stuff piece by piece like gobolinux. From a distro sense everything makes sense. dpkg -S this-file will tell me quickly why a /usr file is there. The distro is supposed to paint the picture for you. What are the parts you think are the worst messes?
  - pxc 3y ago
    > /srv ? What do you have in mind? I don't recall that being for applications https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.htm...
- soraminazuki 3y ago
  Nix is becoming increasingly popular though. It's an improvement over the GoboLinux model, which requires manual maintenance of version directories (e.g., /Programs/Xorg/7.0). Nix does away with that by choosing the install path of packages based on the hash of their build recipes.
  - lproven 3y ago
    Making it automatable is not an unambiguous improvement, though. Losing human readability, when that was the primary Gobo design goal, is a fearfully high price to pay, as I explained upthread: https://news.ycombinator.com/item?id=39536496 https://news.ycombinator.com/item?id=39536496
    - soraminazuki 3y ago
      The automatic naming of paths is a critical feature of Nix. Without it, Nix expressions can’t exist. One of the most remarkable features of Nix is that package build recipes, or derivations, in Nix speak, can be treated like any other value in a programming language. It’s possible to reuse and modify existing derivations in Nix expressions without causing conflicts. That’s only possible because different derivations are assigned different paths. If Nix copied GoboLinux and treated packages with differing build recipes as the same, it would lose its declarative and reproducible nature. Also, there’s no actual use case for Nix store paths with the hashes stripped out. The actual path can easily be derived from whatever is at the root of the dependency. Things like Nix expressions, the result symlink, the system environment in /run/sw/current-system, and PATH. Those are “human readable.” From there, you can get the actual store paths. It doesn’t matter that they’re prefixed with a hash because they still have human readable names at the end, allowing you tell what they contain. It’s similar to inspecting memory. You don’t want to start by examining raw bytes in memory dumps. It’s far more easier and meaningful to start by chasing variables instead.
      - lproven 3y ago
        I think that you misunderstand me, and I suspect that you have not read my other comments in this thread. E.g. https://news.ycombinator.com/item?id=39539010 https://news.ycombinator.com/item?id=39539010 What I am saying is that choosing this flat directory store, one that is very hard for humans to read, parse and navigate, is on its own a major disincentive for many people. The traditional and lavishly-documented Unix filesystem layout is comforting and familiar to hundreds of thousands of people (at a very conservative estimate!) and throwing it away was a poorly-considered move that on its own will make many people refuse to even consider Nix and its kin. If a project decides to replace it then it needs multiple compelling reasons, and just "search paths will sort it" and "this keeps pathnames short" is not good enough. What I am suggesting is that if automatic directory name management (via hashes or whatever) were combined with a more human-readable tree, this type of tool would have a much better chance of success. Even if it were less efficient. Even if it were more work for the developers. The benefits of the Nix approach are only compelling to a relatively small number of people and the price is too high for many. That's why after over 20 years, adoption is minimal. That's why work continues on Debian and all the other traditional distros. That's why since Nix was invented in 2003 (AFAIK) we have had AppImage and Snap and Flatpak. Because this stuff is too hard for ordinary folks. This is why functional languages as a whole have made so little impact on mainstream computing. They bring great benefits for those smart enough to understand them, but for the rest of us, for ordinary dumb jocks like me, it's too hard. http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html http://steve-yegge.blogspot.com/2010/12/haskell-researchers-... The same goes for Lisp's prefix notation, and for Forth's and Postscript's postfix notation and Reverse Polish Notation in general. After coming up on 40 years in the industry, I am convinced that some of this stuff really does have compelling advantages, but it's not compelling enough which is why tens of $millions are being spent on inferior tools such as Flatpak. And under the hood, Flatpak uses Ostree, and Ostree uses Git, and TBH I reckon about 1% of 1% of the thousands of people using Git and anything related to it actually understand how it works. This kind of thing is just too complicated for ordinary minds. https://xkcd.com/1597/ https://xkcd.com/1597/ Computers are not for computer scientists. Computers should be for everyone. The goal of making this stuff easier to understand is more important than the goal of making it better in some theoretical way.
- trws 3y ago
  I agree, but I’m happy to see that Nix, Guix, and the one I do the most work on Spack are starting to gain some traction since they all do basically this. Making it work is not always trivial though, and making it work efficiently is harder. Only in the last few years have I felt like we’re finally getting to the point where this is actually a maintainable model for the majority of software distribution. Here’s hoping it gets the rest of the way!
  - nerdponx 3y ago
    Homebrew has been doing it for a long time. It's not known for being fast, but without profiling the application I'm hesitant to blame the file layout.
  - lproven 3y ago
    They are, yes, but there is a very important core difference here that I think is not mentioned. The big cost about Nix/Guix that puts people off is that it eliminates a human-readable filesystem. The traditional layout is gone or empty, replaced by a tonne of folders under `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash` and you have to just... *trust* that your path and so on will work and stuff will just get found somehow. You have to let go of navigating your own filesystem. That's just too much for a lot of people. The filesystem layout is one of Unix's defining characteristics. Whereas Gobo's goal is the opposite: yes, let us discard the traditional filesystem layout, but let's do it by making it more human readable instead. You can work out where things are without knowing. There's better isolation. It's like semantic versioning, applied to the filesystem: a semantic filesystem layout, where folder names encapsulate versioning info and are more meaningful than the old 1970s reduce-typing-effort-at-all-costs approach. Nix says ignore paths, ignore directories, you don't need them, we'll manage that for you. Gobo says forget traditional paths, here are some better ones that you will find easier and more useful. For me, that's an attractive proposition. In real life, it seems that both were too much for most people. My suggestion would be: why not merge them? Try to bring the advantages of Gobo -- readable, meaningful directory paths -- to a version of Nix. Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree: /gonix/apps/gui/productivity/images/krita/5.1/ /gonix/apps/console/shell/bash/5.2/ /gonix/apps/programming/compilers/fpc/3.1/ /gonix/libraries/c/glibc/2.39 /gonix/apps/console/editors/vim/9.1 I am totally making these up, you understand, they're merely illustrative examples.
- silisili 3y ago
  I think /home and /tmp are the only ones that consistently make any sense currently. The rest seems a grab bag of putting whatever you want wherever you want.
  - lproven 3y ago
    Yes, it pretty much is. The Unix filesystem layout was bodged together on the fly as Dennis and Ken got more disk drives to attach to their elderly DEC PDP computers. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
  - palata 3y ago
    Do you think this reflects the reality of Linux distros, or does that reflect your understanding of them? Would you say that `/usr/bin` or `/usr/lib` are completely random and no two distros use those paths?
    - silisili 3y ago
      I've been using Linux for a loooong time. Sure, you notice trends, but it's still not clear cut what goes where. On my current system, /lib and /usr/lib both link to /lib64. So I guess the distinction between the three wasn't clear to someone else, either. Some configs are in /etc, some are in /var. Some third party stuff puts bins in /opt.
  - mmh0000 3y ago
    There is a standard that most Linux distributions follow, the FHS. https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...
- matheusmoreira 3y ago
  Those ideas certainly inspired me. GoboLinux is the first project I saw that showed me that on Linux you actually can do whatever you want.
  - hsbauauvhabzb 3y ago
    Unless you want Bluetooth audio without systemd, then you’re SOL
    - matheusmoreira 3y ago
      Not really. There is nothing about systemd that makes bluetooth or audio its exclusive purview. You just have to put in the effort to make it happen. Gotta figure out how they did it and do it too. It's not gonna happen without somebody making it happen. Be somebody. Systemd is influential because the people making it often are those somebodies but the fact is anyone can be that somebody, you don't need their blessing or that of some standards body to make anything. I went as far as getting rid of libc. Made a lisp that runs directly on top of Linux using nothing but system calls. It can do anything other software can do: I run strace on a program, my lisp can do what it does if it just replicates those system calls, doesn't matter if it's simple I/O or mounting disks. I want to eventually boot Linux directly into it.
    - michaelmrose 3y ago
      void linux which opted for runit over systemd has bluetooth configurable via bluetoothctl or blueman-applet so seems this is a thing. That said bluetooth is kind of flaky. You may get a better result with a device that has a usb dongle. Logitech models reportedly work. The Corsair unit I just bought works well for instance. Leitner works despite having crap audio over usb.
    - freedomben 3y ago
      Only if you want somebody else to do it for you. Everything is open and hackable on Linux so you can make it work without systemd. Thus far this hasn't been a priority for others, but that doesn't mean it can't be done
- deleted 3y ago
  [deleted]
myself248 3y ago
It's so sensible it makes me weep. Deduplicating multiple copies of a library can be done by the filesystem if you consider it really necessary, it is after all a file-level redundancy and should be solved at that level.
hsnewman 3y ago
This is reminiscent of the IBM AS/400 filesystem, my question is how resiliant is the filesystem?
Winse 3y ago
This reminds me a little of the original idea of a new winfs for longhorn from Microsoft except this seems like something that may become useful someday. Some interesting ideas...though shared object dependencies may be a problem...though I didn't take a very close look at they handle this. Perhaps all shared resources go into a specific location? Or perhaps everything is statically compiled? dunno ... anyway there is a reason behind our lovely file system mess. Kind of reminds me of https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... though in open source land you definitely can take a risk like this.
vrinsd 3y ago
The GoboLinux guys really did "intelligently" come up with a filesystem layout that's humanly understandable. I personally find the old-school UNIX conventions we use fairly arcane given we no longer have 8.3 type limits imposed by lack of storage space, >1GB file-size issues, etc. I ran GoboLinux 012-015 for a few years on a server that I used for hosting version control software and for the most part it kicked ass. What was a bit of a stumbling point is that if you needed a package that didn't readily exist, you'd have to create the recipe. The language for creating GoboLinux recipes is perfectly understandable, the issue was often one package would depend on a dozen or a few dozen libraries and you'd spend a lot of time chasing that down, getting the versioning for those libraries right, THEN finding a URL for those libraries/packages, and THEN creating the recipe. I eventually moved over to Debian and I still cringe and config files in "/etc" maybe the binary was put in "/usr/bin" or "/usr/local/bin". I'm in the camp that finds systemd annoying and kind of like an octopus (you'll often resort to using a find command to locate the associated .service file, you can't rely on them being in once place, the CLI isn't really intuitive) in contrast Gobo had a very simple set of scripts to manage services and it was very easy to work with. But, the convinience of just being able to 'apt get' what you need or 'dpkg -i <blah.deb>' outweighs the much more sane and intelligence behind GoboLinux. These days the number of Linux distributions people support has dropped from the myraid of options it used to be to now almost always including Debian (or Ubuntu) by default so you it's unlikely you can't get a package or some program installed, even if it outside the repositories. macOS definitely does something similar to GoboLinux and it makes working with macOS on the CLI (at least prior to the current versions which are fairly user-hostile) pretty easy -- your pen drive will be located in /Volumes, configuration files for a program under ~/Library, etc.
- yjftsjthsd-h 3y ago
  > you'll often resort to using a find command to locate the associated .service file, you can't rely on them being in once place, the CLI isn't really intuitive FWIW, if the service is loaded you can just `systemctl status foo` and it'll tell you starting on the second line of output exactly what file(s) are in play, ex. # systemctl status getty@tty1.service ● getty@tty1.service - Getty on tty1 Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled) => /lib/systemd/system/getty@.service
nektro 3y ago
what I wish nixos was, wow this is awesome
Waterluvian 3y ago
Ignorantly: is this how MacOS kind of works? It always felt incredibly good how applications were always just this one “file” you’d drag and drop and manage. Nothing makes me feel dumber than trying to figure out where the heck anything is or gets placed in my Ubuntu machine.
- bombcar 3y ago
  Bundles on macOS are/were a really good idea, but applications will still spurt some juice in weird random locations, usually in ~/Library. Fun comes when you have things like minecraft launchers that contain everything and all the worlds and saves inside the bundle.
  - Klonoar 3y ago
    The trick of shoving everything inside the bundle (including write things) no longer works if you're codesigned - there was always a note in the docs (buried, as usual) that while it might work it wasn't guaranteed to always work. Sure enough, as of a recent release it'll invalidate your signature if you've distributed it codesigned and write into the bundle.
    - nusl 3y ago
      If I wrote programs for Mac, this is one of the things that would really piss me off. Then, I'd write to ~/Library because I'm not gonna spend the time to figure out how to make it work with codesigning, if at all possible.
      - Klonoar 3y ago
        But like... why? If you wrote for Mac, you'd also probably follow the news and updates from Apple, which didn't exactly hide the direction they've been pushing things in. You also _should_ write to a third party folder, preferably `~/Library/Application\ Support`. It's what it's for, after all.
- jwells89 3y ago
docandrew 3y ago
I ran Gobo for a while and really enjoyed some of their ideas. It was started by Hisham Muhammad, the author of htop. It’s a shame that it didn’t get more traction. We probably wouldn’t have needed Docker or any of the gazillion package managers that are proliferating today if it had.
- geenat 3y ago
  > We probably wouldn’t have needed Docker or any of the gazillion package managers that are proliferating today if it had. 100% feel this way too. So much of the reason why we use containers is just not spreading crap all over the filesystem. It's why single binary distributables made popular by Golang are such a winner, ex: Caddy.
  - discardedrefuse 3y ago
    You might be interested in Fedora's Atomic desktops. They are immutable OS's where you don't spread crap all over the filesystem. Instead you rely on flatpaks, containers (toolbox or distrobox), and single binaries (if you got them). https://fedoraproject.org/atomic-desktops/ https://fedoraproject.org/atomic-desktops/
    - geenat 3y ago
      Been keeping an eye on it. Would be far more excited about GoboLinux though, to be honest. > the filesystem is the database is such an epiphany for GoboLinux, truly atomic.
- Cloudef 3y ago
  Its been succeeded by nix and guix, theres reason you are increasingly seeing flake.nix in open source projects
  - pantantrant 3y ago
    Both aren't that reproducible, I keep running into sha256 hash nondeterminism when upgrading packages on nixos from source after not updating for a while and guix may be better at this.
yazzku 3y ago
Well, that does seem a lot more sane than what exists today. What is the catch?
- LargoLasskhyfv 3y ago
  The cargo-culting of the commons.
- pantantrant 3y ago
  I tried it and I'd rather # make install to install a program and # make -n install | xargs rm -rf to uninstall a program.
  - lproven 3y ago
    This comment is the second time you've said this, so clearly, you think it's important. You also said it here: https://news.ycombinator.com/item?id=39533554 https://news.ycombinator.com/item?id=39533554 I honestly don't see the connection. The idea of Gobo was to replace the cryptic Unix filesystem hierarchy with something clearer and more human-readable, and in so doing, replace a whole bunch of things that package managers do, making them almost unnecessary. Your point doesn't address this at all. You're talking about building from source instead of using a package manager, as far as I can see? But compiling from source still puts the resultant binaries somewhere in the existing Unix filesystem layout. It doesn't matter where the binaries come from. This isn't about where they come from -- it's about where they go.
op00to 3y ago
I did this back in ~2004 when I was hosting diskless workstations. It was a major pita to maintain on my own!
meatjuice 3y ago
I hope it isn’t just a re-invention of NixOS (or worse).
- ufo 3y ago
  Actually predates NixOS, by a couple of months.
  - transfire 3y ago
    I don’t think NixOS was actually usable back then either. It was still more an idea and few people had heard of it.
- yjftsjthsd-h 3y ago
  Neither is a re-invention of the other; they happen to do things that are partially similar, but also totally different. NixOS uses the /nix/store structure to allow it to pin everything to everything in service of its goal of absolute reproducibility/determinism. GoboLinux restructured the filesystem in order to be "nicer" (very loosely speaking). The result is that (IMO) nix is more technically elegant, and Gobo is a lot friendlier to work with. (I type this from a NixOS machine and with love in my heart for both)
- Qwertious 3y ago
  NixOS and GoboLinux were both started in 2003; if they haven't compared notes by now then they never will.
  - lproven 3y ago
    Linux is what made Unix into a mainstream consumer OS. It came along 22 years after Unix itself. It's never too late. Remember that Windows itself was a flop until version 3, and that -- Windows 3.0, in 1990 -- was the little snowball rolling down a mountain that brought multitasking multimedia networked GUI computers to the mainstream. And thereby created the mainstream marketplace of x86-32 computers: the substrate that allowed Linux to grow. (DOS made so little use of the 80386 that an 80286 PC was adequate, and after 5 years the 386 made little inroads into the mass market -- they were too expensive, even after the 1989 budget-model 80386, the 386SX. But Windows 3 ran much better on a 386 than a 286, and soon after Windows came along, the 286 was dead.)
tdoggette 3y ago
> Through a mapping of traditional paths into their GoboLinux counterparts, we transparently retain compatibility with the Unix legacy. [...] There is no rocket science to this: /bin is a link to /System/Index/bin. And as a matter of fact, so is /usr/bin. And /usr/sbin... all "binaries" directories map to the same place. Amusingly, this makes us even more compatible than some more standard-looking distributions. In GoboLinux, all standard paths work for all files, while other distros may struggle with incompatibilites such as scripts breaking when they refer to /usr/bin/foo when the file is actually in /usr/local/bin/foo.
krick 3y ago
This is such an obvious solution. Kinda crazy that the whole world uses Debian and such, while this exists since 2002 (it's older than Ubuntu). I mean, yeah, I didn't switch to NixOS despite it being "obviously better" too, but it feels like there must have been much less friction 22 years ago to adopt better design. (Maybe capitalized directory names are to blame, they are disgusting.)
- docandrew 3y ago
  I seem to recall that Gobo turned on case-insensitive shell tab-completions by default so in practice it was a non-issue.
- segfaltnh 3y ago
  The real issue is case sensitive file systems. When do you actually want two files with the same name in different cases? That's not a human-centric design choice, Mac and Windows got this one right.
  - krick 3y ago
    The real issue is somebody popularized this absolutely nonsensical idea that filesystems could be case-insensitive. They cannot. "A", "a" and "а" (Cyrillic) are different characters with different codepoints, whether you like it or not. Deal with it.
  - mirpa 3y ago
    You can go around case sensitivity in user facing applications by using fuzzy search. Even command line tools can use Tab for autocompletion. Case for case sensitivity is not in ability to have two files which differ in case, but simplicity of underlying code that has to deal with paths.
russfink 3y ago
What if two bin files have the same name but are different? What does /System/Index/bin do with that? E.g., “uninstall.sh”.
- discardedrefuse 3y ago
  And why would they mix packaged managed binaries with local user compiled binaries.
  - ufo 3y ago
    That way users can get all the package-manager goodness for stuff they compiled locally. And also because Gobolinux lets people install more than one version of the same package.
  - soraminazuki 3y ago
    You've fundamentally misunderstood how GoboLinux works. The whole point of these kind of distros is to avoid mixing packages into a single common directory. Each version of each software are installed in separate directories in /Programs so that they won't cause conflicts with each other. Then for convenience, a single version of each software will be symlinked into /System/Index. This is way more meaningful than the /bin & /usr/bin split that distros are increasingly moving away from because multiple versions of the same software or forks can coexist on the same system. This model also makes /usr/local unnecessary.
    - discardedrefuse 3y ago
      Thanks. I appreciate the correction.
- lucasvr_br 3y ago
  The dependency map of the program you're running states which one takes precedence and gets mapped (overlay-mounted, to be more precise) to /System/Index/bin. So, a dependency map that contains "Foo = 1.0" would cause Foo/1.0/bin/uninstall.sh to be the one mapped to /System/Index/bin.
discardedrefuse 3y ago
Someone decided to shoehorn Windows Program Files into Linux? Yikes. Jokes aside, this completely ignores the fact that there is a reason for /usr/bin and /usr/local/bin and /etc and the sbin directories. A lot of it has to do with permissions. If you've ever been a member of a multi-user server you might understand. I will grant you tho; a lot of people never bother learning and just shove binaries where ever they can get it to work first. In case anyone wants to know. Here is a good explanation: https://unix.stackexchange.com/a/8658 https://unix.stackexchange.com/a/8658
- throwanem 3y ago
  Nothing in that answer from 2011 even mentions permissions, and most of what it does discuss was pretty outdated even then.
  - discardedrefuse 3y ago
    I thought it was implied that bin vs sbin is a permissions thing. What is outdated in that link? I use Fedora 39 Atomic and, as far as I can tell, even it follows these conventions (and even added /var/userlocal for themselves).
    - throwanem 3y ago
      Strictly, the difference between /bin and /sbin versus their siblings in /usr has to do with what you can fit on the RK05 disk pack that the system boots from. If it comes up too broken to mount the DECtape (or if you're lucky and your institution's not cheap, the second RK05) where /usr lives, you'd better be able to fix it with whatever's in /, because until you do that's all you've got. Hence keeping some binaries there, but not too many; your root volume is only a couple megabytes large. Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup. I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr. I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout conventions. Even I'm not old enough to have actually worked with such systems, although I don't miss it by much, and am certainly old enough to have studied a great deal more about them than some. edit: If you're really interested in the topic, then you should certainly spend some time with Rob Landley's collection of historical documents [1], which Google is apparently no longer competent to find based on their content - some of this I was actually looking for in the course of composing this reply, and only found it when I happened to search the name on a mailing list message linked in another reply here. So much for "information wants to be free" - apparently on today's Internet there's no money left in making information able to be found. [1] https://landley.net/history/mirror/index.html https://landley.net/history/mirror/index.html
Linda231 3y ago
[dead]
vitarnixofntrnt 3y ago
[dead]
JNRowe 3y ago
For people -- admittedly, like me -- who have a strong knee-jerk reaction to GoboLinux's design the twenty year old "I am not clueless"¹ document contains a fair amount of interesting background and reasoning on the concepts. I don't think I've overcome the reaction entirely, but it isn't so strong anymore ;) ¹ https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html
- Sammi 3y ago
  The writing has some of the same feel as the writing for HTMX or Tailwind. Paraphrasing: "Yes we know this is different. Yes it is very simple. You may not be used to it, but it is easier to understand and work with. You don't have to use this. We like this and we are happy."
- Hackbraten 3y ago
  From the linked article: > make all programs relocatable - I would love to see that, but that would either mean: rewrite every app in the world to use `libprefix` I’m curious about what they mean by `libprefix`. A web search doesn’t turn up any useful results.
  - lproven 3y ago
    https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LIBRARY_PREFIX.html https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LI... ...?
- saghm 3y ago
  I can't help but wonder how much of the kneejerk reaction is due to "cosmetic" parts of the design rather than the functional parts. For example, I notice that a lot of my initial reaction is based on the capitalization; "Programs" with a capital "P" (probably unfairly) evokes an emotional response due to reminding me of the Windows "Program Files" naming, and (perhaps slightly more fairly) I'd probably find it mildly infuriating to type "LibX11" rather than "libx11". Even though Linux filesystems are generally case insensitive, I imagine that package names would still be unique across casing, and it seems pretty likely that a Linux distribution focused on making the filesystem hierarchy more user-friendly wouldn't end up putting a second directory on the root that differs only by case. As silly as it is to verbalize, I genuinely think my initial reaction would be less strong if the naming convention examples were "/packages/libx11/1.6.9" and "/packages/gcc/9.2.0", and I don't think the benefits would be diminished at all by naming things like this.
donatj 3y ago
I am honestly kind of shocked every time I see Gobo come up on here that it's still going. I played with it back in highschool 20+ years ago and thought it was an interesting oddity. It's frankly kind of inspiring that they've stuck with it.
solarized 3y ago
Hey, just a heads up: capitalizing the first directory's name? Not cool. It feels like extra work when navigating paths, you know? Pressing shift along with a letter or number every time? Total drag, especially for everyday command line use.
- pxc 3y ago
  I like it as a convention that indicates at a glance whether something is a directory or just a regular file. Also, any shell can do case-insensitive completion for you. Fish does it out of the box.
  - solarized 3y ago
    I mean, fish isn't the only shell out there. Why bother installing another shell instead of just sticking with bash for normal navigation? Ah, sorry, classic distro discussion. Everyone has the freedom to choose whatever distros they prefer.
    - yjftsjthsd-h 3y ago
      I think fish was just an example that does it by default; if you want bash to do the same, just set set completion-ignore-case on in your .inputrc
    - gattilorenz 3y ago
      The message you replied to said "any shell can do case-insensitive completion for you", not that you should use fish. Whether literally any shell can, I don't know. With zsh, bash and tcsh it is certainly possible.
- ufo 3y ago
  The capital letters are to avoid clashing with FSH/legacy directories.
- vvanpo 3y ago
  From the article linked above: > 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.
fodkodrasz 3y ago
Hey poliverzum, how you doing? (He was a local GoboLinux fan, but went off the map. Hope he's fine.)
sylware 3y ago
Some very bad closed source applications will expect way to much from the user system: the steam client, where your get bash scripts instead of sh scripts, a hard debian/ubuntu file layout with the linux mount userland container requirement (windows 10?), and GNU-only niche options of many commands. Not to mention many 32bits libraries. It seems they are still in control of their ABI though (probably using the .symver directive of binutils gas). That to say the least, the current mess is being forced down or throat by steam, unless your distros don't play video games.
- prmoustache 3y ago
  I'd say most people don't play games and among those that use linux most would not use any proprietary apps anyway. And among the population of gamers, I am pretty sure a large majority have a dedicated gaming rig.
  - sylware 3y ago
    If steam was technically less horrible, more distros would be able to run games way more easily and mechanically more elf/linux users would play games. Because fullfilling all the nasty tantrums of steam is really a pain. Most native games have lesser requirements than steam.
transfire 3y ago
I miss you, Gobo.
Leynos 3y ago
Sounds like PC-BSD... Er... I mean TrueOS
edpichler 3y ago
This project can potentially reduce a lot of our cognitive load. I hope it succeeds. edit: Now I see it's a 20-year project.
- deleted 3y ago
  [deleted]
- froh 3y ago
  a slow rolling 20 year old project https://github.com/gobolinux/Recipes/commits/master/ https://github.com/gobolinux/Recipes/commits/master/
zzbn00 3y ago
The documentation mentions GNU stow: https://www.gnu.org/software/stow/manual/stow.html https://www.gnu.org/software/stow/manual/stow.html This was very useful in early 2000s running shared linux machines with a diverse set of software for scientific applications.
toastal 3y ago
What makes folks thing landing pages like this should require JavaScript? Nothing here would need the dynamic capabilities of a scripting language, yet accessibility & SEO are hurt in the process.
- riddley 3y ago
  There's an old adage about hammers and nails... I forget the details.
- soerxpso 3y ago
  You can read the 20 lines of JS that they use. It's for drawing the parallax lines in the background and for the fade-in effect, which can't be accomplished with plain CSS. There's no detriment to SEO or to accessibility, unless the specific disability you have is that you're allergic to JavaScript.
SomeoneFromCA 3y ago
Is not this like it is done in Android?
0dayz 3y ago
What I would love gobolinux to do is similar to nix which is to make it possible for any distro to get gobolinux like folder structure.
- lproven 3y ago
  You can run Gobo inside your /home directory if you want. https://gobolinux.org/index.php?lang=tr_TR&page=rootless https://gobolinux.org/index.php?lang=tr_TR&page=rootless
  - nmz 3y ago
    This is absolutely perfect for sdf/tilde then.
account-5 3y ago
Can someone way cleverer than me explain why, or if, this is better than things like snap/flatpaks as well as distros like nixos? This seems, at face value without a deep understanding, to be the simplest way to do it. Again the caveat is my lack of knowledge.
- akvadrako 3y ago
  Do you mean just putting each app in it's own folder? That just isn't enough for isolation and could be massively wasteful, depending how far you take it. Flatpak and NixOS are more complex because it's worth it. For example, they don't duplicate exact versions of dependencies on disk.
  - Gormo 3y ago
    Flatpak's complexity is also a product of trying to function as a single solution to two different problems. Runtime isolation and packaging/distribution are different things, and there is no compelling reason for them to be conflated together. How you sandbox the execution of your applications should not be dependent on any particular filesystem layout or package format, nor vice versa. FreeBSD does a good job with this: applications are installed into a standard Unix filesystem with conventional packages and the ports collection. Isolation is then implemented via jails. The Linux equivalent of using standalone isolation layers, like firejail, on top of standard distro packaging, is far superior to Flatpak.
  - nmz 3y ago
    You are aware that windows has each app on its own folder in program\ files and its completely fine. ext4 supports an insane amount of files, so much so that unless you're doing something really out there, you're never going to reach the limit.
  - palata 3y ago
    > For example, they don't duplicate exact versions of dependencies on disk. Doesn't feel like GoboLinux would either, does it?
- charcircuit 3y ago
1970-01-01 3y ago
Never mentioned is how this is a Windows 95 concept. They really should do this, I don't give bonus points for ignorance. https://en.wikipedia.org/wiki/Program_Files#History https://en.wikipedia.org/wiki/Program_Files#History
- aidenn0 3y ago
  They cite NeXT (which predates Win95).
  - 1970-01-01 3y ago
    https://wiki.gobolinux.org/Overview/The-GoboLinux-Way/index.html#influences-and-roots https://wiki.gobolinux.org/Overview/The-GoboLinux-Way/index.... Yes, they cite that among other UNIX like OSes while completely ignoring the most successful implementation of their idea, (by several orders of magnitude) Windows. I don't find that cute, I find it ignorant.

283 points by haunter 3y ago

It's such a shame the ideas of GoboLinux never caught on in the mainstream Linux community. Linux's filesystem structure is a complete mess.

Gormo 3y ago
> Linux's filesystem structure is a complete mess. I don't think that's a valid claim. Something being organized on principles that are different from yours is not the same as it being disorganized in itself.
- cassepipe 3y ago
  Unless those principles are merely the solution to problems that don't exist anymore like /usr separation ?
  - Gormo 3y ago
    Yes; the presumed obsolescence of a problem does not imply that remaining elements of its solution are "a mess".
    - nunobrito 3y ago
      Call it technical debt if you prefer: https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt Either way that old situation is a mess in my opinion, you are of course free to have yours.
      - Gormo 3y ago
        > Call it technical debt if you prefer: https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt I don't prefer to call it that. In fact, it's almost the exact opposite of technical debt, which is generally the result of trying to change things too much, too quickly. Having stable conventions that account for edge cases that are addressed sufficiently to the point that we don't have to think about them is an asset, not debt, and the principle of Chesterton's Fence ought to always be applied when proposing changes that drastically alter long-established conventions.
sedatk 3y ago
s/Linux/Unix MacOS is better though.
- tomrod 3y ago
  This is a joke, right? MacOS is all over the place?
  - rufugee 3y ago
    Agreed...I fail to see how macOS is an improvement. I mean, you have /Applications, but you also have /Library, ~/Library, and so on.
    - pavel_lishin 3y ago
      And /Applications, and /System/Applications, even though if you open them in Finder, you'll see the two combined.
      - reactordev 3y ago
        And ~/Applications, and /usr/bin, and /usr/local/bin, and homebrew, and Mac ports, tell me again how Mac is better?
        sedatk 3y ago
        I just wasn’t aware of these issues. Let me rephrase it then: MacOS’ intentions were better. :)
        tomrod 3y ago
        Eh............................. maybe? :)
  - wraptile 3y ago
    I'd say that MacOS is even worse which is impressive given that Apple has the absolute control of the platform and seemingly infinite resources and could have refactored the mess at any point.
discardedrefuse 3y ago
The Windows Program Files style directories might make sense to you on a single user workstation. But on a multi-user server, its a security nightmare.
- spoiler 3y ago
  I'm curious how bin is different from Program Files? Unless you mean stuff like configuration? I think user configuration would still reside somewhere under the user's home dir
  - discardedrefuse 3y ago
    1. /bin (and /sbin) were intended for programs that needed to be on a small / partition before the larger /usr, etc. partitions were mounted. These days, it mostly serves as a standard location for key programs like /bin/sh, although the original intent may still be relevant for e.g. installations on small embedded devices. 2. /sbin, as distinct from /bin, is for system management programs (not normally used by ordinary users) needed before /usr is mounted. 3. /usr/bin is for distribution-managed normal user programs. 4. There is a /usr/sbin with the same relationship to /usr/bin as /sbin has to /bin. 5. /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning. 6. /usr/local/sbin, as you can probably guess at this point, is to /usr/local/bin as /usr/sbin to /usr/bin. source: https://unix.stackexchange.com/a/8658 https://unix.stackexchange.com/a/8658
    - gertop 3y ago
      You said Program Files was a security nightmare compared to the Linux mess, that is what he was asking about. How is /bin safer than Program Files? None of the things you listed have any relevance to that question.
    - spoiler 3y ago
      I'm familiar with the intent behind the structure. I am mostly asking about the security implications you mentioned. One downside to Program Files type structure is that there's probably going to be some duplicate libraries lying around. However, as someone who's battled version skews due to clashing maintainer mindsets: that's been a much bigger pain in my ass than a few wasted kbs!
jauntywundrkind 3y ago
/opt and /srv (and or /usr/local/opt if that's your preference) grant many of the nicities of managing your stuff piece by piece like gobolinux. From a distro sense everything makes sense. dpkg -S this-file will tell me quickly why a /usr file is there. The distro is supposed to paint the picture for you. What are the parts you think are the worst messes?
- pxc 3y ago
  > /srv ? What do you have in mind? I don't recall that being for applications https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.htm...
soraminazuki 3y ago
Nix is becoming increasingly popular though. It's an improvement over the GoboLinux model, which requires manual maintenance of version directories (e.g., /Programs/Xorg/7.0). Nix does away with that by choosing the install path of packages based on the hash of their build recipes.
- lproven 3y ago
  Making it automatable is not an unambiguous improvement, though. Losing human readability, when that was the primary Gobo design goal, is a fearfully high price to pay, as I explained upthread: https://news.ycombinator.com/item?id=39536496 https://news.ycombinator.com/item?id=39536496
  - soraminazuki 3y ago
    The automatic naming of paths is a critical feature of Nix. Without it, Nix expressions can’t exist. One of the most remarkable features of Nix is that package build recipes, or derivations, in Nix speak, can be treated like any other value in a programming language. It’s possible to reuse and modify existing derivations in Nix expressions without causing conflicts. That’s only possible because different derivations are assigned different paths. If Nix copied GoboLinux and treated packages with differing build recipes as the same, it would lose its declarative and reproducible nature. Also, there’s no actual use case for Nix store paths with the hashes stripped out. The actual path can easily be derived from whatever is at the root of the dependency. Things like Nix expressions, the result symlink, the system environment in /run/sw/current-system, and PATH. Those are “human readable.” From there, you can get the actual store paths. It doesn’t matter that they’re prefixed with a hash because they still have human readable names at the end, allowing you tell what they contain. It’s similar to inspecting memory. You don’t want to start by examining raw bytes in memory dumps. It’s far more easier and meaningful to start by chasing variables instead.
    - lproven 3y ago
      I think that you misunderstand me, and I suspect that you have not read my other comments in this thread. E.g. https://news.ycombinator.com/item?id=39539010 https://news.ycombinator.com/item?id=39539010 What I am saying is that choosing this flat directory store, one that is very hard for humans to read, parse and navigate, is on its own a major disincentive for many people. The traditional and lavishly-documented Unix filesystem layout is comforting and familiar to hundreds of thousands of people (at a very conservative estimate!) and throwing it away was a poorly-considered move that on its own will make many people refuse to even consider Nix and its kin. If a project decides to replace it then it needs multiple compelling reasons, and just "search paths will sort it" and "this keeps pathnames short" is not good enough. What I am suggesting is that if automatic directory name management (via hashes or whatever) were combined with a more human-readable tree, this type of tool would have a much better chance of success. Even if it were less efficient. Even if it were more work for the developers. The benefits of the Nix approach are only compelling to a relatively small number of people and the price is too high for many. That's why after over 20 years, adoption is minimal. That's why work continues on Debian and all the other traditional distros. That's why since Nix was invented in 2003 (AFAIK) we have had AppImage and Snap and Flatpak. Because this stuff is too hard for ordinary folks. This is why functional languages as a whole have made so little impact on mainstream computing. They bring great benefits for those smart enough to understand them, but for the rest of us, for ordinary dumb jocks like me, it's too hard. http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html http://steve-yegge.blogspot.com/2010/12/haskell-researchers-... The same goes for Lisp's prefix notation, and for Forth's and Postscript's postfix notation and Reverse Polish Notation in general. After coming up on 40 years in the industry, I am convinced that some of this stuff really does have compelling advantages, but it's not compelling enough which is why tens of $millions are being spent on inferior tools such as Flatpak. And under the hood, Flatpak uses Ostree, and Ostree uses Git, and TBH I reckon about 1% of 1% of the thousands of people using Git and anything related to it actually understand how it works. This kind of thing is just too complicated for ordinary minds. https://xkcd.com/1597/ https://xkcd.com/1597/ Computers are not for computer scientists. Computers should be for everyone. The goal of making this stuff easier to understand is more important than the goal of making it better in some theoretical way.
trws 3y ago
I agree, but I’m happy to see that Nix, Guix, and the one I do the most work on Spack are starting to gain some traction since they all do basically this. Making it work is not always trivial though, and making it work efficiently is harder. Only in the last few years have I felt like we’re finally getting to the point where this is actually a maintainable model for the majority of software distribution. Here’s hoping it gets the rest of the way!
- nerdponx 3y ago
  Homebrew has been doing it for a long time. It's not known for being fast, but without profiling the application I'm hesitant to blame the file layout.
- lproven 3y ago
  They are, yes, but there is a very important core difference here that I think is not mentioned. The big cost about Nix/Guix that puts people off is that it eliminates a human-readable filesystem. The traditional layout is gone or empty, replaced by a tonne of folders under `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash` and you have to just... *trust* that your path and so on will work and stuff will just get found somehow. You have to let go of navigating your own filesystem. That's just too much for a lot of people. The filesystem layout is one of Unix's defining characteristics. Whereas Gobo's goal is the opposite: yes, let us discard the traditional filesystem layout, but let's do it by making it more human readable instead. You can work out where things are without knowing. There's better isolation. It's like semantic versioning, applied to the filesystem: a semantic filesystem layout, where folder names encapsulate versioning info and are more meaningful than the old 1970s reduce-typing-effort-at-all-costs approach. Nix says ignore paths, ignore directories, you don't need them, we'll manage that for you. Gobo says forget traditional paths, here are some better ones that you will find easier and more useful. For me, that's an attractive proposition. In real life, it seems that both were too much for most people. My suggestion would be: why not merge them? Try to bring the advantages of Gobo -- readable, meaningful directory paths -- to a version of Nix. Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree: /gonix/apps/gui/productivity/images/krita/5.1/ /gonix/apps/console/shell/bash/5.2/ /gonix/apps/programming/compilers/fpc/3.1/ /gonix/libraries/c/glibc/2.39 /gonix/apps/console/editors/vim/9.1 I am totally making these up, you understand, they're merely illustrative examples.
silisili 3y ago
I think /home and /tmp are the only ones that consistently make any sense currently. The rest seems a grab bag of putting whatever you want wherever you want.
- lproven 3y ago
  Yes, it pretty much is. The Unix filesystem layout was bodged together on the fly as Dennis and Ken got more disk drives to attach to their elderly DEC PDP computers. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
- palata 3y ago
  Do you think this reflects the reality of Linux distros, or does that reflect your understanding of them? Would you say that `/usr/bin` or `/usr/lib` are completely random and no two distros use those paths?
  - silisili 3y ago
    I've been using Linux for a loooong time. Sure, you notice trends, but it's still not clear cut what goes where. On my current system, /lib and /usr/lib both link to /lib64. So I guess the distinction between the three wasn't clear to someone else, either. Some configs are in /etc, some are in /var. Some third party stuff puts bins in /opt.
- mmh0000 3y ago
  There is a standard that most Linux distributions follow, the FHS. https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...
matheusmoreira 3y ago
Those ideas certainly inspired me. GoboLinux is the first project I saw that showed me that on Linux you actually can do whatever you want.
- hsbauauvhabzb 3y ago
  Unless you want Bluetooth audio without systemd, then you’re SOL
  - matheusmoreira 3y ago
    Not really. There is nothing about systemd that makes bluetooth or audio its exclusive purview. You just have to put in the effort to make it happen. Gotta figure out how they did it and do it too. It's not gonna happen without somebody making it happen. Be somebody. Systemd is influential because the people making it often are those somebodies but the fact is anyone can be that somebody, you don't need their blessing or that of some standards body to make anything. I went as far as getting rid of libc. Made a lisp that runs directly on top of Linux using nothing but system calls. It can do anything other software can do: I run strace on a program, my lisp can do what it does if it just replicates those system calls, doesn't matter if it's simple I/O or mounting disks. I want to eventually boot Linux directly into it.
  - michaelmrose 3y ago
    void linux which opted for runit over systemd has bluetooth configurable via bluetoothctl or blueman-applet so seems this is a thing. That said bluetooth is kind of flaky. You may get a better result with a device that has a usb dongle. Logitech models reportedly work. The Corsair unit I just bought works well for instance. Leitner works despite having crap audio over usb.
  - freedomben 3y ago
    Only if you want somebody else to do it for you. Everything is open and hackable on Linux so you can make it work without systemd. Thus far this hasn't been a priority for others, but that doesn't mean it can't be done
deleted 3y ago
[deleted]

myself248 3y ago

It's so sensible it makes me weep. Deduplicating multiple copies of a library can be done by the filesystem if you consider it really necessary, it is after all a file-level redundancy and should be solved at that level.

hsnewman 3y ago

This is reminiscent of the IBM AS/400 filesystem, my question is how resiliant is the filesystem?

Winse 3y ago

This reminds me a little of the original idea of a new winfs for longhorn from Microsoft except this seems like something that may become useful someday. Some interesting ideas...though shared object dependencies may be a problem...though I didn't take a very close look at they handle this. Perhaps all shared resources go into a specific location? Or perhaps everything is statically compiled? dunno ... anyway there is a reason behind our lovely file system mess. Kind of reminds me of https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... though in open source land you definitely can take a risk like this.

vrinsd 3y ago

The GoboLinux guys really did "intelligently" come up with a filesystem layout that's humanly understandable. I personally find the old-school UNIX conventions we use fairly arcane given we no longer have 8.3 type limits imposed by lack of storage space, >1GB file-size issues, etc. I ran GoboLinux 012-015 for a few years on a server that I used for hosting version control software and for the most part it kicked ass. What was a bit of a stumbling point is that if you needed a package that didn't readily exist, you'd have to create the recipe. The language for creating GoboLinux recipes is perfectly understandable, the issue was often one package would depend on a dozen or a few dozen libraries and you'd spend a lot of time chasing that down, getting the versioning for those libraries right, THEN finding a URL for those libraries/packages, and THEN creating the recipe. I eventually moved over to Debian and I still cringe and config files in "/etc" maybe the binary was put in "/usr/bin" or "/usr/local/bin". I'm in the camp that finds systemd annoying and kind of like an octopus (you'll often resort to using a find command to locate the associated .service file, you can't rely on them being in once place, the CLI isn't really intuitive) in contrast Gobo had a very simple set of scripts to manage services and it was very easy to work with. But, the convinience of just being able to 'apt get' what you need or 'dpkg -i <blah.deb>' outweighs the much more sane and intelligence behind GoboLinux. These days the number of Linux distributions people support has dropped from the myraid of options it used to be to now almost always including Debian (or Ubuntu) by default so you it's unlikely you can't get a package or some program installed, even if it outside the repositories. macOS definitely does something similar to GoboLinux and it makes working with macOS on the CLI (at least prior to the current versions which are fairly user-hostile) pretty easy -- your pen drive will be located in /Volumes, configuration files for a program under ~/Library, etc.

yjftsjthsd-h 3y ago
> you'll often resort to using a find command to locate the associated .service file, you can't rely on them being in once place, the CLI isn't really intuitive FWIW, if the service is loaded you can just `systemctl status foo` and it'll tell you starting on the second line of output exactly what file(s) are in play, ex. # systemctl status getty@tty1.service ● getty@tty1.service - Getty on tty1 Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled) => /lib/systemd/system/getty@.service

nektro 3y ago

what I wish nixos was, wow this is awesome

Waterluvian 3y ago

Ignorantly: is this how MacOS kind of works? It always felt incredibly good how applications were always just this one “file” you’d drag and drop and manage. Nothing makes me feel dumber than trying to figure out where the heck anything is or gets placed in my Ubuntu machine.

bombcar 3y ago
Bundles on macOS are/were a really good idea, but applications will still spurt some juice in weird random locations, usually in ~/Library. Fun comes when you have things like minecraft launchers that contain everything and all the worlds and saves inside the bundle.
- Klonoar 3y ago
  The trick of shoving everything inside the bundle (including write things) no longer works if you're codesigned - there was always a note in the docs (buried, as usual) that while it might work it wasn't guaranteed to always work. Sure enough, as of a recent release it'll invalidate your signature if you've distributed it codesigned and write into the bundle.
  - nusl 3y ago
    If I wrote programs for Mac, this is one of the things that would really piss me off. Then, I'd write to ~/Library because I'm not gonna spend the time to figure out how to make it work with codesigning, if at all possible.
    - Klonoar 3y ago
      But like... why? If you wrote for Mac, you'd also probably follow the news and updates from Apple, which didn't exactly hide the direction they've been pushing things in. You also _should_ write to a third party folder, preferably `~/Library/Application\ Support`. It's what it's for, after all.
jwells89 3y ago

docandrew 3y ago

I ran Gobo for a while and really enjoyed some of their ideas. It was started by Hisham Muhammad, the author of htop. It’s a shame that it didn’t get more traction. We probably wouldn’t have needed Docker or any of the gazillion package managers that are proliferating today if it had.

geenat 3y ago
> We probably wouldn’t have needed Docker or any of the gazillion package managers that are proliferating today if it had. 100% feel this way too. So much of the reason why we use containers is just not spreading crap all over the filesystem. It's why single binary distributables made popular by Golang are such a winner, ex: Caddy.
- discardedrefuse 3y ago
  You might be interested in Fedora's Atomic desktops. They are immutable OS's where you don't spread crap all over the filesystem. Instead you rely on flatpaks, containers (toolbox or distrobox), and single binaries (if you got them). https://fedoraproject.org/atomic-desktops/ https://fedoraproject.org/atomic-desktops/
  - geenat 3y ago
    Been keeping an eye on it. Would be far more excited about GoboLinux though, to be honest. > the filesystem is the database is such an epiphany for GoboLinux, truly atomic.
Cloudef 3y ago
Its been succeeded by nix and guix, theres reason you are increasingly seeing flake.nix in open source projects
- pantantrant 3y ago
  Both aren't that reproducible, I keep running into sha256 hash nondeterminism when upgrading packages on nixos from source after not updating for a while and guix may be better at this.

yazzku 3y ago

Well, that does seem a lot more sane than what exists today. What is the catch?

LargoLasskhyfv 3y ago
The cargo-culting of the commons.
pantantrant 3y ago
I tried it and I'd rather # make install to install a program and # make -n install | xargs rm -rf to uninstall a program.
- lproven 3y ago
  This comment is the second time you've said this, so clearly, you think it's important. You also said it here: https://news.ycombinator.com/item?id=39533554 https://news.ycombinator.com/item?id=39533554 I honestly don't see the connection. The idea of Gobo was to replace the cryptic Unix filesystem hierarchy with something clearer and more human-readable, and in so doing, replace a whole bunch of things that package managers do, making them almost unnecessary. Your point doesn't address this at all. You're talking about building from source instead of using a package manager, as far as I can see? But compiling from source still puts the resultant binaries somewhere in the existing Unix filesystem layout. It doesn't matter where the binaries come from. This isn't about where they come from -- it's about where they go.

op00to 3y ago

I did this back in ~2004 when I was hosting diskless workstations. It was a major pita to maintain on my own!

meatjuice 3y ago

I hope it isn’t just a re-invention of NixOS (or worse).

ufo 3y ago
Actually predates NixOS, by a couple of months.
- transfire 3y ago
  I don’t think NixOS was actually usable back then either. It was still more an idea and few people had heard of it.
yjftsjthsd-h 3y ago
Neither is a re-invention of the other; they happen to do things that are partially similar, but also totally different. NixOS uses the /nix/store structure to allow it to pin everything to everything in service of its goal of absolute reproducibility/determinism. GoboLinux restructured the filesystem in order to be "nicer" (very loosely speaking). The result is that (IMO) nix is more technically elegant, and Gobo is a lot friendlier to work with. (I type this from a NixOS machine and with love in my heart for both)
Qwertious 3y ago
NixOS and GoboLinux were both started in 2003; if they haven't compared notes by now then they never will.
- lproven 3y ago
  Linux is what made Unix into a mainstream consumer OS. It came along 22 years after Unix itself. It's never too late. Remember that Windows itself was a flop until version 3, and that -- Windows 3.0, in 1990 -- was the little snowball rolling down a mountain that brought multitasking multimedia networked GUI computers to the mainstream. And thereby created the mainstream marketplace of x86-32 computers: the substrate that allowed Linux to grow. (DOS made so little use of the 80386 that an 80286 PC was adequate, and after 5 years the 386 made little inroads into the mass market -- they were too expensive, even after the 1989 budget-model 80386, the 386SX. But Windows 3 ran much better on a 386 than a 286, and soon after Windows came along, the 286 was dead.)

tdoggette 3y ago

> Through a mapping of traditional paths into their GoboLinux counterparts, we transparently retain compatibility with the Unix legacy. [...] There is no rocket science to this: /bin is a link to /System/Index/bin. And as a matter of fact, so is /usr/bin. And /usr/sbin... all "binaries" directories map to the same place. Amusingly, this makes us even more compatible than some more standard-looking distributions. In GoboLinux, all standard paths work for all files, while other distros may struggle with incompatibilites such as scripts breaking when they refer to /usr/bin/foo when the file is actually in /usr/local/bin/foo.

krick 3y ago

This is such an obvious solution. Kinda crazy that the whole world uses Debian and such, while this exists since 2002 (it's older than Ubuntu). I mean, yeah, I didn't switch to NixOS despite it being "obviously better" too, but it feels like there must have been much less friction 22 years ago to adopt better design. (Maybe capitalized directory names are to blame, they are disgusting.)

docandrew 3y ago
I seem to recall that Gobo turned on case-insensitive shell tab-completions by default so in practice it was a non-issue.
segfaltnh 3y ago
The real issue is case sensitive file systems. When do you actually want two files with the same name in different cases? That's not a human-centric design choice, Mac and Windows got this one right.
- krick 3y ago
  The real issue is somebody popularized this absolutely nonsensical idea that filesystems could be case-insensitive. They cannot. "A", "a" and "а" (Cyrillic) are different characters with different codepoints, whether you like it or not. Deal with it.
- mirpa 3y ago
  You can go around case sensitivity in user facing applications by using fuzzy search. Even command line tools can use Tab for autocompletion. Case for case sensitivity is not in ability to have two files which differ in case, but simplicity of underlying code that has to deal with paths.

russfink 3y ago

What if two bin files have the same name but are different? What does /System/Index/bin do with that? E.g., “uninstall.sh”.

discardedrefuse 3y ago
And why would they mix packaged managed binaries with local user compiled binaries.
- ufo 3y ago
  That way users can get all the package-manager goodness for stuff they compiled locally. And also because Gobolinux lets people install more than one version of the same package.
- soraminazuki 3y ago
  You've fundamentally misunderstood how GoboLinux works. The whole point of these kind of distros is to avoid mixing packages into a single common directory. Each version of each software are installed in separate directories in /Programs so that they won't cause conflicts with each other. Then for convenience, a single version of each software will be symlinked into /System/Index. This is way more meaningful than the /bin & /usr/bin split that distros are increasingly moving away from because multiple versions of the same software or forks can coexist on the same system. This model also makes /usr/local unnecessary.
  - discardedrefuse 3y ago
    Thanks. I appreciate the correction.
lucasvr_br 3y ago
The dependency map of the program you're running states which one takes precedence and gets mapped (overlay-mounted, to be more precise) to /System/Index/bin. So, a dependency map that contains "Foo = 1.0" would cause Foo/1.0/bin/uninstall.sh to be the one mapped to /System/Index/bin.

discardedrefuse 3y ago

Someone decided to shoehorn Windows Program Files into Linux? Yikes. Jokes aside, this completely ignores the fact that there is a reason for /usr/bin and /usr/local/bin and /etc and the sbin directories. A lot of it has to do with permissions. If you've ever been a member of a multi-user server you might understand. I will grant you tho; a lot of people never bother learning and just shove binaries where ever they can get it to work first. In case anyone wants to know. Here is a good explanation: https://unix.stackexchange.com/a/8658 https://unix.stackexchange.com/a/8658

throwanem 3y ago
Nothing in that answer from 2011 even mentions permissions, and most of what it does discuss was pretty outdated even then.
- discardedrefuse 3y ago
  I thought it was implied that bin vs sbin is a permissions thing. What is outdated in that link? I use Fedora 39 Atomic and, as far as I can tell, even it follows these conventions (and even added /var/userlocal for themselves).
  - throwanem 3y ago
    Strictly, the difference between /bin and /sbin versus their siblings in /usr has to do with what you can fit on the RK05 disk pack that the system boots from. If it comes up too broken to mount the DECtape (or if you're lucky and your institution's not cheap, the second RK05) where /usr lives, you'd better be able to fix it with whatever's in /, because until you do that's all you've got. Hence keeping some binaries there, but not too many; your root volume is only a couple megabytes large. Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup. I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr. I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout conventions. Even I'm not old enough to have actually worked with such systems, although I don't miss it by much, and am certainly old enough to have studied a great deal more about them than some. edit: If you're really interested in the topic, then you should certainly spend some time with Rob Landley's collection of historical documents [1], which Google is apparently no longer competent to find based on their content - some of this I was actually looking for in the course of composing this reply, and only found it when I happened to search the name on a mailing list message linked in another reply here. So much for "information wants to be free" - apparently on today's Internet there's no money left in making information able to be found. [1] https://landley.net/history/mirror/index.html https://landley.net/history/mirror/index.html

Linda231 3y ago

[dead]

vitarnixofntrnt 3y ago

[dead]

JNRowe 3y ago

For people -- admittedly, like me -- who have a strong knee-jerk reaction to GoboLinux's design the twenty year old "I am not clueless"¹ document contains a fair amount of interesting background and reasoning on the concepts. I don't think I've overcome the reaction entirely, but it isn't so strong anymore ;) ¹ https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html

Sammi 3y ago
The writing has some of the same feel as the writing for HTMX or Tailwind. Paraphrasing: "Yes we know this is different. Yes it is very simple. You may not be used to it, but it is easier to understand and work with. You don't have to use this. We like this and we are happy."
Hackbraten 3y ago
From the linked article: > make all programs relocatable - I would love to see that, but that would either mean: rewrite every app in the world to use `libprefix` I’m curious about what they mean by `libprefix`. A web search doesn’t turn up any useful results.
- lproven 3y ago
  https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LIBRARY_PREFIX.html https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LI... ...?
saghm 3y ago
I can't help but wonder how much of the kneejerk reaction is due to "cosmetic" parts of the design rather than the functional parts. For example, I notice that a lot of my initial reaction is based on the capitalization; "Programs" with a capital "P" (probably unfairly) evokes an emotional response due to reminding me of the Windows "Program Files" naming, and (perhaps slightly more fairly) I'd probably find it mildly infuriating to type "LibX11" rather than "libx11". Even though Linux filesystems are generally case insensitive, I imagine that package names would still be unique across casing, and it seems pretty likely that a Linux distribution focused on making the filesystem hierarchy more user-friendly wouldn't end up putting a second directory on the root that differs only by case. As silly as it is to verbalize, I genuinely think my initial reaction would be less strong if the naming convention examples were "/packages/libx11/1.6.9" and "/packages/gcc/9.2.0", and I don't think the benefits would be diminished at all by naming things like this.

donatj 3y ago

I am honestly kind of shocked every time I see Gobo come up on here that it's still going. I played with it back in highschool 20+ years ago and thought it was an interesting oddity. It's frankly kind of inspiring that they've stuck with it.

solarized 3y ago

Hey, just a heads up: capitalizing the first directory's name? Not cool. It feels like extra work when navigating paths, you know? Pressing shift along with a letter or number every time? Total drag, especially for everyday command line use.

pxc 3y ago
I like it as a convention that indicates at a glance whether something is a directory or just a regular file. Also, any shell can do case-insensitive completion for you. Fish does it out of the box.
- solarized 3y ago
  I mean, fish isn't the only shell out there. Why bother installing another shell instead of just sticking with bash for normal navigation? Ah, sorry, classic distro discussion. Everyone has the freedom to choose whatever distros they prefer.
  - yjftsjthsd-h 3y ago
    I think fish was just an example that does it by default; if you want bash to do the same, just set set completion-ignore-case on in your .inputrc
  - gattilorenz 3y ago
    The message you replied to said "any shell can do case-insensitive completion for you", not that you should use fish. Whether literally any shell can, I don't know. With zsh, bash and tcsh it is certainly possible.
ufo 3y ago
The capital letters are to avoid clashing with FSH/legacy directories.
vvanpo 3y ago
From the article linked above: > 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.

fodkodrasz 3y ago

Hey poliverzum, how you doing? (He was a local GoboLinux fan, but went off the map. Hope he's fine.)

sylware 3y ago

Some very bad closed source applications will expect way to much from the user system: the steam client, where your get bash scripts instead of sh scripts, a hard debian/ubuntu file layout with the linux mount userland container requirement (windows 10?), and GNU-only niche options of many commands. Not to mention many 32bits libraries. It seems they are still in control of their ABI though (probably using the .symver directive of binutils gas). That to say the least, the current mess is being forced down or throat by steam, unless your distros don't play video games.

prmoustache 3y ago
I'd say most people don't play games and among those that use linux most would not use any proprietary apps anyway. And among the population of gamers, I am pretty sure a large majority have a dedicated gaming rig.
- sylware 3y ago
  If steam was technically less horrible, more distros would be able to run games way more easily and mechanically more elf/linux users would play games. Because fullfilling all the nasty tantrums of steam is really a pain. Most native games have lesser requirements than steam.

transfire 3y ago

I miss you, Gobo.

Leynos 3y ago

Sounds like PC-BSD... Er... I mean TrueOS

edpichler 3y ago

This project can potentially reduce a lot of our cognitive load. I hope it succeeds. edit: Now I see it's a 20-year project.

deleted 3y ago
[deleted]
froh 3y ago
a slow rolling 20 year old project https://github.com/gobolinux/Recipes/commits/master/ https://github.com/gobolinux/Recipes/commits/master/

zzbn00 3y ago

The documentation mentions GNU stow: https://www.gnu.org/software/stow/manual/stow.html https://www.gnu.org/software/stow/manual/stow.html This was very useful in early 2000s running shared linux machines with a diverse set of software for scientific applications.

toastal 3y ago

What makes folks thing landing pages like this should require JavaScript? Nothing here would need the dynamic capabilities of a scripting language, yet accessibility & SEO are hurt in the process.

riddley 3y ago
There's an old adage about hammers and nails... I forget the details.
soerxpso 3y ago
You can read the 20 lines of JS that they use. It's for drawing the parallax lines in the background and for the fade-in effect, which can't be accomplished with plain CSS. There's no detriment to SEO or to accessibility, unless the specific disability you have is that you're allergic to JavaScript.

SomeoneFromCA 3y ago

Is not this like it is done in Android?

0dayz 3y ago

What I would love gobolinux to do is similar to nix which is to make it possible for any distro to get gobolinux like folder structure.

lproven 3y ago
You can run Gobo inside your /home directory if you want. https://gobolinux.org/index.php?lang=tr_TR&page=rootless https://gobolinux.org/index.php?lang=tr_TR&page=rootless
- nmz 3y ago
  This is absolutely perfect for sdf/tilde then.

account-5 3y ago

Can someone way cleverer than me explain why, or if, this is better than things like snap/flatpaks as well as distros like nixos? This seems, at face value without a deep understanding, to be the simplest way to do it. Again the caveat is my lack of knowledge.

akvadrako 3y ago
Do you mean just putting each app in it's own folder? That just isn't enough for isolation and could be massively wasteful, depending how far you take it. Flatpak and NixOS are more complex because it's worth it. For example, they don't duplicate exact versions of dependencies on disk.
- Gormo 3y ago
  Flatpak's complexity is also a product of trying to function as a single solution to two different problems. Runtime isolation and packaging/distribution are different things, and there is no compelling reason for them to be conflated together. How you sandbox the execution of your applications should not be dependent on any particular filesystem layout or package format, nor vice versa. FreeBSD does a good job with this: applications are installed into a standard Unix filesystem with conventional packages and the ports collection. Isolation is then implemented via jails. The Linux equivalent of using standalone isolation layers, like firejail, on top of standard distro packaging, is far superior to Flatpak.
- nmz 3y ago
  You are aware that windows has each app on its own folder in program\ files and its completely fine. ext4 supports an insane amount of files, so much so that unless you're doing something really out there, you're never going to reach the limit.
- palata 3y ago
  > For example, they don't duplicate exact versions of dependencies on disk. Doesn't feel like GoboLinux would either, does it?
charcircuit 3y ago

1970-01-01 3y ago

Never mentioned is how this is a Windows 95 concept. They really should do this, I don't give bonus points for ignorance. https://en.wikipedia.org/wiki/Program_Files#History https://en.wikipedia.org/wiki/Program_Files#History

aidenn0 3y ago
They cite NeXT (which predates Win95).
- 1970-01-01 3y ago
  https://wiki.gobolinux.org/Overview/The-GoboLinux-Way/index.html#influences-and-roots https://wiki.gobolinux.org/Overview/The-GoboLinux-Way/index.... Yes, they cite that among other UNIX like OSes while completely ignoring the most successful implementation of their idea, (by several orders of magnitude) Windows. I don't find that cute, I find it ignorant.