17 ms·

GoboLinux

315 points by frabert 6y ago

arexxbifs 6y ago
Wow, I'm usually very suspicious about "new takes" on Linux distros but this does look very cool indeed. And it comes with a simple WM as default rather than a DE? Double cool!
- oblio 6y ago
  It's not a new take. It's been around for more than a decade (18 years, actually).
  - AnIdiotOnTheNet 6y ago
    Yeah, I remember GoboLinux from when OSNews was still a happening place.
transfire 6y ago
Still my overall favorite distro. Just wish it would "take off" and become mainstream -- it really has the right ideas, particularly with regards to package management.
- ahnick 6y ago
  If you are against traditional package management, what is the argument for this approach over something like NixOS? This doesn't seem to do anything for trying to roll back to a previous known working state, which is probably my biggest issue with the way most mainstream linux distributions package management works today.
  - hisham_hm 6y ago
    They are contemporaries: GoboLinux is as old as Nix, and older than NixOS. There were other similar ideas around (GNU Stow), but I think Gobo was the first that went "let's make a full OS out of this". I would say Gobo and NixOS follow roughly the same philosophy, with Nix adding the functional aspect on top, which is pretty neat. But yes, one of the motivations for Gobo was to make it easy to revert versions of programs, with commands for enabling/disabling their symlinks, and even keeping multiple versions at the same time. We didn't do full-system snapshots, but handled it on a program-by-program basis, which was our main interest at the time (tinkering with the latest window manager!).
    - Ericson2314 6y ago
      https://github.com/NixOS/rfcs/pull/17 https://github.com/NixOS/rfcs/pull/17 proposes lots and lots of symlinks in a way that reminds me of GoboLinux :).
  - Mathnerd314 6y ago
    For handling rollbacks you can use a normal layout and an A/B partition scheme (https://source.android.com/devices/tech/ota/ab https://source.android.com/devices/tech/ota/ab) or apt-btrfs-snapshot. The problem with NixOS's approach is you have to rebuild the world on every small change, because the folder hash changes. GoboLinux's layout at least avoids the cascading rebuilds.
theastrowolfe 6y ago
First time reading about a distro like this. Looks pretty neat! Isn't this what /opt is for though?
- hisham_hm 6y ago
  Hi! One of the creators of the distro here! (Super surprised it made it to HN, someone just sent me a heads up!) > Isn't this what /opt is for though? Pretty much yes; the idea was "/opt all the things!" (well, before the all-the-things meme existed — it was a long time ago!) and use symlinks to make everything appear as if it was installed in the "regular" Unix places (so that we wouldn't have to patch/reconfigure every single program). GoboLinux has a long and cool story (I still use it!) but that's the tl;dr version of the motivation!
  - mikepurvis 6y ago
    Sounds a bit like how Homebrew works (or used to, anyway). Based on my experiences there, one of the big issues with just keeping all versions of everything is that you end up with problems when you're trying to build/use packages with a large pool of dependencies, especially when the dependencies are interlinked. We used to get problems like this when building ROS on homebrew where you'd have a bottled version of Gazebo (a robot simulator) which had been linked against specific versions of boost, python, opencv, whatever. And then a new version of one of those dependencies would come out, and something else in the tree would update ahead of Gazebo; now suddenly you've got Gazebo plugins which crash with ABI issues and you have to go spelunking to find out which binaries are linked to what and where the conflict is.
    - hisham_hm 6y ago
      > Sounds a bit like how Homebrew works (or used to, anyway). It's not by accident! In its original docs, Homebrew described itself as package management "the GoboLinux way". Given how Homebrew has become this super-popular tool, its success makes me proud of Gobo's legacy (and a bit vindicated from all the people who told us "this model is crazy, it will never be usable!" :) ) > keeping all versions of everything is that you end up with problems when you're trying to build/use packages with a large pool of dependencies Yes, it can be a pain! In recent years, we introduced Runner (https://gobolinux.org/runner.html https://gobolinux.org/runner.html) in GoboLinux as a way to address this kind of issue; a virtualization layer to present the expected dependencies at the right places.
LockAndLol 6y ago
From the FAQ > Is GoboLinux "ready"? > Yes, it is ready in the sense that you can, today, have a full operating system running 100% on GoboLinux, like many people around the world do. > Note, however, that it is neither a beginner-oriented distribution, or an end-user binary-oriented distribution like Ubuntu. To use GoboLinux today, the user is expected to be proficient with the command-line and willing to compile and configure their software. Yeah, nah. I recently watched a streamer try to compile some nvidia stuff for CUDA in order to use her DSLR camera at >18fps. A very nice reminder that it's never "just ./configure && sudo make install". Especially uninstalling stuff installed that way is a horrible pain. I used to create .deb's from it, but boy am I glad those days are over. Besides that, the motivation and sane folder names seem great.
- freedomben 6y ago
  I wouldn't say it's never "just ./configure && sudo make install". I compile a fair number of projects myself and (as long as deps are installed properly) it usually is just configure/install, on mainstream distros at least (Fedora, Ubuntu, Arch). No doubt though a lot of projects could do much better. I find anything needing GTK and Qt are often much harder, usually because the required packages aren't documented anywhere, or if they are it's for Ubuntu that's 4 years old. Nvidia and other things requiring proprietary are a nightmare. I will never buy another machine with an Nvidia card after the kernel 5.9 hell I've been through.
- hisham_hm 6y ago
  > Especially uninstalling stuff installed that way is a horrible pain. That was indeed one of the motivations for GoboLinux after tinkering with hand-compiled software a lot. Uninstalling is a mere "rm -rf /Programs/ProgramName" :)
ufo 6y ago
I have a friend that uses GoboLinux. It's not a mainstream distro but my friend did seem able to hook it to the overhead projector without problems, so it works well enough from at least that point of view :)
ufo 6y ago
By the way, if you scroll all the way down in the "Docs" page of the website there are links to older articles about the early history of Gobolinux. Some interesting discussions about the design of the Unix file system hierarchy.
floatingleaf 6y ago
This seems to be NixOS minus the Nix language, and traditional approach to package installation, configuration etc.
- forgotpwd16 6y ago
  The only similarity is the non-standard filesystem hierarchy but even how that comes to be differs conceptually.
Ericson2314 6y ago
Ah, I remember 7 years ago trying to decide whether I'd switch to GoboLinux or Nix. I choose the latter and don't regret for a moment, but I'll continue respect GoboLinux and have the found memory. I think the big difference is: - Nix: the filesytem is rarely the right datastructure (I agree) other things are needed. - Nix: Store and Nix too is more freeform, package / distro norms provided by higher layers (Nixpkgs, NixOS)
- diomedes 6y ago
  I've been using NixOS for 2 years now, my general impression is that even if Nix isn't the popular solution, it'll probably inspire the right way of doing things for the next years. It might not look like much, but representing the whole system's dependencies as a Graph database, then using a purely functional language to define such database has happily prevented me from shooting myself in the foot many times over the past year.
  - freedomben 6y ago
    Have you tried any of the containerized distros? I haven't tried Nix but want to. Just wondering if you can compare/contrast NixOS with something like Fedora Silverblue or Fedora CoreOS.
    - arsfeld 6y ago
      I used both and even though their purpose is very similar (have an "immutable" system tree that you create and switch into it), the day to day is very different. Silverblue is still pretty much imperative, you install/remove RPM packages and that's it, you use Flatpak for everything else. NixOS you have to describe your entire system in a programming language. NixOS gives you so much more freedom to do what you want, but you have to work for it, learn a language, learn it's constructs, etc. I enjoy both though, feels like the right direction to go, you just need to choose how you want to interact with your OS.
    - Ericson2314 6y ago
      I haven't tried, but I get the sense that those are more about cleaning up the run time than the build process. At least the flatpak/snap world also is kind of anti-integrative in that everything is vendoring everything else. I personally think containerization is just too much a PITA to use for software that doesn't live in a bubble, e.g. desktop software. The capabilities revolution (Capsicum or CloudABI) would be more secure and easier to program with, so we just need to force our way there, and then everything will take care of itself.
foxyv 6y ago
Wow, this model addresses a lot of the issues I have with different Linux distributions. Mainly, finding where the heck it installed that program in the maze of file/folder locations. Sometimes it's etc, opt, var/lib, bin, usr/bin, apps... Gwahhhhh! Then, you go to modify the configuration, and it turns out that the configuration file is being copied and generated from a different location. It's endless misdirection which changes in each distribution based on the package manager. I think I may try out Gobo the next chance I get. This is pretty cool.
- freedomben 6y ago
  FHS and distros that follow it aren't perfect, but it does make a big difference. I prefer Fedora-based and Arch-based flavors for that reason. It's usually pretty easy to find stuff. Backtrack used to do something like this and while it was easier compared to a lot of other debian/ubuntu based things, I still ran into some pain points. A great command to keep handy is ls -la `which <program>` That will usually find you the binary right away, and if it's a symlink or something you'll see it in the ls output. It's especially useful to me because (generally speaking) I put stuff I build myself in ~/bin rather than `/usr/local/bin` so I can quickly tell if I'm using my own build or the package manager's. Edit: FHS == Filesystem Hierarchy Standard - https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
  - LMYahooTFY 6y ago
    Thank you, that's informative and you and GP have made me feel better about this particular aspect of learning Linux.
    - freedomben 6y ago
      My pleasure! It can feel brutal at first to learn Linux, especially with so much choice out there (aka fragmentation?), but honestly it's the best thing I ever did for myself both personal and career-wise. Can't recommend at least basic Linux proficiency enough if you are in a technology sector especially.
tomw1808 6y ago
Might be a really stupid question, it's late here, be gentle: but why not just dockerize all applications and let them bring their own libraries etc by default? Wouldn't address similar issues with "everything neat and tidy"?
- freedomben 6y ago
  Take a look at Fedora Silverblue, or on the server Fedora CoreOS (FCOS)/RHEL CoreOS (RHCOS) if you want to see serious mainstream effort at it (no shade at the other projects whatsoever btw, I think this is cool). I don't currently run Silverblue full time but I could see myself doing so in the future. Regarding docker containerization specifically (or a different OCI-compliant runtime like Podman), it gets very hard because of things like video and sound (Pipewire should help immensely), but also there are lots of apps that you want to have uncontainered access. Like Vim becomes a lot less useful to me if it's filesystem is contained.
- LaGrange 6y ago
  Well, for starters, GoboLinux is far older than Docker. It's built on similar (sometimes identical) tools to what Docker uses, though.
- ogre_codes 6y ago
  I don't know how well Docker works with X11, but just the fact that it would be nearly impossible to make global settings changes would be frustrating as hell. Having a full Gnome install on every app, a full KDE install on every app. Having to install a given theme into every single docker container. Maybe I'm missing something. I'm not even sure how this could make sense.
  - SulfurHexaFluri 6y ago
    You wouldn't use docker, Flatpak would be the choice for containerized gui applications. I'm not an expert but it looks like the kde and gnome env gets shared between flatpak applications.
    - 6y ago
0xbadcafebee 6y ago
We did something like this 20 years ago at a company I worked for. It's effectively pointless, and there are better, more modern methods. Here's why. First of all, the filesystem isn't a database, it's a hierarchical index of files. It has a couple fancy features specific to managing files. Trying to force it to do more than that will result in pain, and eventually building something else around it. But the filesystem isn't even the biggest limiting factor. Managing both the build-time and run-time dependencies of software is more complex than a filesystem can handle. To execute an application in an operating system, there must be one "environment", which is a combination of a kernel, an OS's environment and resources, and a set of applications and dependencies. The dependencies are set at build time and run time, and can't be interchanged at will without causing instability (if it works at all). You can juggle symlinks around all you want, but it doesn't result in any useful functionality other than looking at a bunch of differently versioned files that are not - cannot - be in use. The applications themselves can be programmed to interact with multiple versions of dependencies, but if they are not already built to do so, you cannot force them to. This underlying limitation is what forces an application environment to depend on a static tree of files. It doesn't matter how many versions of a dependency you have installed, you can only use one at a time, as each application allows you to. That's why you can only install one version of a package, and why we don't have trees of versioned file hierarchies for the dependencies. They'd be pointless. You can only use the files you can use. All popular Linux distributions today know this. They have worked along with the Linux Filesystem Hierarchy Standard over the past 26 years, and understand these issues well. Distros may implement it differently, but mostly they conform to it, because they know nothing else really makes a difference. At the end of the day, the current standard (when properly used) is as simple and effective as we can get. Some software developers (cough Systemd cough) basically don't give a shit about the standard, and generally make the users' and distros' lives harder. This is the one place where the distros could make a difference, by forcing a structure that makes more sense. But enforcement is haphazard, so some apps can force really stupid file structures on distros, and people wonder why the filesystem is so confusing. So you may ask, what's a better solution? The answer is containers (or really, chroot environments, but that's what a container is). I have a longer post which goes into more detail about why package management literally cannot solve any other problem than it already does, and why containers are the only "advancement" without radically redefining application development: https://gist.github.com/peterwwillis/e96854532f471c739983c0bba7608834 https://gist.github.com/peterwwillis/e96854532f471c739983c0b...
cassepipe 6y ago
I have been waiting to try that one for a long time. I always found it annoying that the linux filesystem is not self-explanatory. I have been given unsatisfactory explanations about it so many times but could never understand the rationale between the /bin, /usr/bin, /usr/local/ etc. Turns out it is just historical cruft : (oops can't find the link) I am so glad I switched to Linux but I really miss Window's 'Program files' directory.
- cycomanic 6y ago
  I find the complains funny, for one you should really never need to care where certain programs are installed (and I don't remember the last time I had to). Moreover you can always run which executable and it tells you the location of the executable. It's also funny how Windows is supposedly better, there is at least program files and program files (x86) some programs still just install into C: (I think python used to do that), and there are the different windows folders. Let's not forget the myriad of places where programs drop data. And because Windows has no proper package management, you actually need to where things are.
  - cassepipe 6y ago
    > I find the complains funny, for one you should really never need to care where certain programs are installed Well Linux is not a walled garden with a company that takes care of everything behind the scenes so it should be easy for a beginner to wrap its head around a system and understand at least its logic. It's good not to have to rely on specialists for simple things.
    - cycomanic 6y ago
      I really don't understand what you mean. A beginner should be able to sit in front of the linux machine and just understand everything without needing to do any background reading? And to what level does that apply? Should the user understand everything? Also why is a directory system of /Firefox /Chrome /Gimp ... easier? Where do libraries sit in this system (is that easy to understand?)? How do I determine if I build something what library I'm going to use ... I think the perception of a certain way being easier is largely based on what one is used to. I certainly am always lost when I sit in front of a windows machine. Just the other day I was trying to get ctypes to find a library and ended up just ending lots of things to LIB or PATH (I'm sure there are better way to do things). BTW I was asked by a windows user for help. This is not a dig at windows, just my argument that filesystem layouts are largely conventions (even though often for good reasons) and yes one has to invest some time to understand them. Edit: For someone who wants to understand how Linux works and many things work together I highly recommend giving linux from scratch a try. Most people fall into the trap of just copy pasting the commands (I was one of them as well), so you probably want to build a couple of times, and try to update your system. Hopefully you run into a couple of roadblocks, which force you to thing a bit more about what you are doing and is were the learning experience comes from IMO.
sitzkrieg 6y ago
the file system as a database for files... what a novel concept
- cassepipe 6y ago
  Does it need to be novel to be a good idea ?
- johnisgood 6y ago
  That is funny though because GoboLinux is 18 years old.
cassepipe 6y ago
Is it based on the work of any other distro or its own thing ? What init system has it got ?
- lucasvr_br 6y ago
  Hi! It isn't derived from any other distro; it's built from scratch using its own file system arrangement. The most recent release comes with GoboLinux' own init system, although we have been running some experiments with systemd as well.
  - cassepipe 6y ago
    Thanks. What's the name of the init system ? Any reason not to use Void's runit ? Any reason to switch to systemd ? (I am truly unopinionated on init systems,not trying to start a flame war, juste curious)
deleted 6y ago
[deleted]
siraben 6y ago
How does GoboLinux distinguish between packages of the same version compiled under different environments, or compilers, flags etc.? In Nix such changes cause the resulting build to be prefixed in /nix/store with a different hash.
- einpoklum 6y ago
  I'll venture a guess: It doesn't need to. All of the "first-class citizen" packages, which are visible to everyone, were built in the same environment, just like in other distros. Alternative versions should just be held separately. ... but come to think of it - that means that you can't just put your package in /programs/MyApp/12.3.4 - because if you switch your system to that version your dependencies may well break. Hmm.
- ignaloidas 6y ago
  It's all compile on machine, there's no package repository, only a Recipe one.
dang 6y ago
If curious see also 2017 https://news.ycombinator.com/item?id=14925743 https://news.ycombinator.com/item?id=14925743 2016 https://news.ycombinator.com/item?id=13188522 https://news.ycombinator.com/item?id=13188522 2014 https://news.ycombinator.com/item?id=7722690 https://news.ycombinator.com/item?id=7722690 2010 https://news.ycombinator.com/item?id=1735532 https://news.ycombinator.com/item?id=1735532
eeZah7Ux 6y ago
"each program resides in its own directory, such as /Programs/LibX11/1.6.9 and /Programs/GCC/9.2.0." Brings back some memories from the old days of using windows. Thanks, I'll pass. FHS exists for many reasons.
xolve 6y ago
I used to think it would be a holy mess of symlinks. Spinned up live image in a VM and pleasantly surprised. For compatibility there are traditional /bin but its a symlink to /System/Index/bin, which contains links to actual executables in respective /Programs directory. I wonder why its such a niche distro, with time this should have caught on and be more popular!
- amelius 6y ago
  > For compatibility there are traditional /bin but its a symlink to /System/Index/bin Then why does the readme say: > cd / > ls Programs Users System Data Mount Are they hiding directories?
  - Blikkentrekker 6y ago
    Yes, they are. There is a kernel module that ensures that listing hides, but files can still be accessed by their path. I'm not sure to what level this is an absolute disaster.
    - amelius 6y ago
      For starters, I guess that an rsync of / will not backup the entire system then.
      - Blikkentrekker 6y ago
        Yes, quite a bit of software is written around the assumption that what does not show up with a listing truly not exist, — Including, I would assume, rather security sensitive software.
        isr 6y ago
        The kernel module that hides the standard dirs under / is entirely optional, and is only there for aesthetic purposes. If you don't want it, don't load it. Absolutely nothing in gobolinux requires that kernel module to be running. Again, its just purely for aesthetic purposes.
Saint_Genet 6y ago
Is finding applications on the fs a big problem people actually have?
- hnarn 6y ago
  I read the "At a glance" documentation and came upon 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. This just feels wrong to me. I appreciate that Linux is all about choice, but I really wouldn't want this.
  - aktuel 6y ago
    Why?
- drdaeman 6y ago
  It's not about finding applications, it's more about the ability to have multiple versions of the same package installed and used concurrently. Best you can have with FHS is something like /usr/bin/python3.8 vs /usr/bin/python3.9, and this requires package maintainers to manually support this. Most packages don't do this, so if you happen to need - just a random example - an ancient Firefox version installed separately, "traditional" solutions like rpm or dpkg won't really help you. Plus, a different organization of the filesystem, where everything that belongs to a package is stored under the same base path, rather than being spread across the whole FS. I don't really remember GoboLinux ideas, but IIRC they had something about leveraging use of the filesystem as a part of package manager.
  - SulfurHexaFluri 6y ago
    The better way to do this is to use flatpak. The sandboxing will be a major benefit for your ancient firefox version as well.
- kelnos 6y ago
  Yeah, I don't think that's a problem I ever run into. Also they claim: > Say goodbye to the old problem of having the package manager complain that libXYZ is not installed even though you can see that it is there. That is... also a problem I have never had. I like the idea of GoboLinux just for giving a new take on something more streamlined (because yes, the FHS and de-facto systems before it have accumulated a lot of cruft), but I think it would be more productive for the GoboLinux folks to advocate for their system based on its own merits, not on semi-imagined faults of the more common system. Being able to have multiple versions of programs and their dependencies (which would help avoid dependency hell) installed is a big thing! That alone is a really nice benefit of GoboLinux's system.
enriquto 6y ago
Please, a fork of GoboLinux called gobolinux without the silly mixed-case directory names.
- kelnos 6y ago
  It feels really petty and bike-shed-y to focus on this, but this was my first thought too when I saw the sample directory listings.
  - enriquto 6y ago
    I agree, but the whole gobolinux idea is the epitome of bike-shed-y! You just rename things and the behavior is 100% identical as before.
- mixmastamyk 6y ago
  I think I'd prefer that as well. However it is easy to configure a modern shell for case-insensitive completion.
  - enriquto 6y ago
    Completion is not an issue. The problem is that upper case just looks ugly. Like huge fluorescent decals on an otherwise streamlined matte black road bike. They put a lot of effort to create an über-elegant naming scheme, and then they spoil it for no reason.
- knolax 6y ago
  First thing I thought of too. Mixed cases when all the directory names are single words seems completely unecessary.
  - kazinator 6y ago
    End users are used to mixed-case system directory names. C:\Windows\System32 C:\Users\bob\Downloads
einpoklum 6y ago
Have a look at the FAQ: https://gobolinux.org/faq.html https://gobolinux.org/faq.html It says: > To use GoboLinux today, the user is expected to be proficient with the command-line and willing to compile and configure their software. If I need to compile and configure my software myself, then this is not really a distribution IMHO.
- TheCraiggers 6y ago
  So you don't consider Gentoo or Slack distributions?
  - kelnos 6y ago
    You don't really "compile stuff yourself" on Gentoo. There's still a package manager, and it does all the building and installing for you. Yes, compilation happens as a result of the user invoking the package manager, but there's a huge usability difference between "emerge foo", and download foo.tar.gz -> unpack -> configure/build/install -> track updates and repeat as needed. I would call the latter "compiling foo yourself", but not the former.
    - ignaloidas 6y ago
      It is similar on GoboLinux as well. There is a Recipe repository that contains build scripts that you invoke with Compile, which automatically compiles and installs the package.
  - einpoklum 6y ago
    What kelnos said... I respect Gentoo fine (have not tried Slack TBH); and a distribution can very well be compilation-based - but that doesn't mean that I have to sort things out manually. That's what packagers and distribution maintainers are for. Gobo seems to tell you that I need to do that work myself.
    - isr 6y ago
      One of the "first-class-links" on the top of the homepage explains their build-from-source manager: https://gobolinux.org/recipes.html https://gobolinux.org/recipes.html Might have been a good idea to just click on that, first? FWIW, they used to have a very nice rootless install of their compile framework, allowing you to use gobolinux within your home dir, within another distro.
snicker7 6y ago
How does this compare to Guix/Nix?
netsec_burn 6y ago
Security guy here. I had the chance to look over this project and try it out today. I have no less than 5 ways to acquire root privileges from an unprivileged user in the 15 minutes I looked at it. Has anyone audited this distro in the past 10 years?
- arc-in-space 6y ago
  Ugh. Any specific examples, just for the record, for someone who doesn't care enough to try the system?
- sieste 6y ago
  Thanks security guy. For reference, how many ways to break in do you find per 15 minutes when looking into other distros?
  - netsec_burn 6y ago
    Depends on their popularity. For Ubuntu, Debian, RHEL, Mint, MX Linux, etc. it took me 10 years to find a single LPE. Special case Linux distros, like those for audio editing or signal processing, have about 1-3 LPE's in the first 30 min to an hour I look at them. And GoboLinux.. broken permissions, broken trust of library load paths, root SUIDs with 5 LPE issues at a glance of the source. They even gave some regular binaries root privileges because why not. I didn't look into the root services running or writable paths because I assumed those would be vulnerable too. The question is not if you can get root, but how many ways there are to get root. I was running GoboLinux in a 15 minute session, and once it expired I didn't start a new one. I'll come back to it and do a more comprehensive audit. I haven't released any zerodays I've found, ever, but recently I was thinking about making a blog. This might be some good material.
    - sieste 6y ago
      Thanks, good to know that this is not the norm. Yes please do a more comprehensive audit. And start a blog.
    - adamcstephens 6y ago
kazinator 6y ago
Gobo likes the classic, four-month-old TXR from 2009. https://github.com/gobolinux/Recipes/blob/master/TXR/025/Recipe https://github.com/gobolinux/Recipes/blob/master/TXR/025/Rec... They jumped on it shortly after I made the project public with version 9, picking up version 13. They updated to 18 and then one more time to 25 and that was it. Guess I just don't make `em like I used to.
donatj 6y ago
It's interesting and crazy to me that Gobo is still going. I played with it back in highschool in like 2004.
sally1620 6y ago
Is there a WSL version of this?

315 points by frabert 6y ago

Wow, I'm usually very suspicious about "new takes" on Linux distros but this does look very cool indeed. And it comes with a simple WM as default rather than a DE? Double cool!

oblio 6y ago
It's not a new take. It's been around for more than a decade (18 years, actually).
- AnIdiotOnTheNet 6y ago
  Yeah, I remember GoboLinux from when OSNews was still a happening place.

transfire 6y ago

Still my overall favorite distro. Just wish it would "take off" and become mainstream -- it really has the right ideas, particularly with regards to package management.

ahnick 6y ago
If you are against traditional package management, what is the argument for this approach over something like NixOS? This doesn't seem to do anything for trying to roll back to a previous known working state, which is probably my biggest issue with the way most mainstream linux distributions package management works today.
- hisham_hm 6y ago
  They are contemporaries: GoboLinux is as old as Nix, and older than NixOS. There were other similar ideas around (GNU Stow), but I think Gobo was the first that went "let's make a full OS out of this". I would say Gobo and NixOS follow roughly the same philosophy, with Nix adding the functional aspect on top, which is pretty neat. But yes, one of the motivations for Gobo was to make it easy to revert versions of programs, with commands for enabling/disabling their symlinks, and even keeping multiple versions at the same time. We didn't do full-system snapshots, but handled it on a program-by-program basis, which was our main interest at the time (tinkering with the latest window manager!).
  - Ericson2314 6y ago
    https://github.com/NixOS/rfcs/pull/17 https://github.com/NixOS/rfcs/pull/17 proposes lots and lots of symlinks in a way that reminds me of GoboLinux :).
- Mathnerd314 6y ago
  For handling rollbacks you can use a normal layout and an A/B partition scheme (https://source.android.com/devices/tech/ota/ab https://source.android.com/devices/tech/ota/ab) or apt-btrfs-snapshot. The problem with NixOS's approach is you have to rebuild the world on every small change, because the folder hash changes. GoboLinux's layout at least avoids the cascading rebuilds.

theastrowolfe 6y ago

First time reading about a distro like this. Looks pretty neat! Isn't this what /opt is for though?

hisham_hm 6y ago
Hi! One of the creators of the distro here! (Super surprised it made it to HN, someone just sent me a heads up!) > Isn't this what /opt is for though? Pretty much yes; the idea was "/opt all the things!" (well, before the all-the-things meme existed — it was a long time ago!) and use symlinks to make everything appear as if it was installed in the "regular" Unix places (so that we wouldn't have to patch/reconfigure every single program). GoboLinux has a long and cool story (I still use it!) but that's the tl;dr version of the motivation!
- mikepurvis 6y ago
  Sounds a bit like how Homebrew works (or used to, anyway). Based on my experiences there, one of the big issues with just keeping all versions of everything is that you end up with problems when you're trying to build/use packages with a large pool of dependencies, especially when the dependencies are interlinked. We used to get problems like this when building ROS on homebrew where you'd have a bottled version of Gazebo (a robot simulator) which had been linked against specific versions of boost, python, opencv, whatever. And then a new version of one of those dependencies would come out, and something else in the tree would update ahead of Gazebo; now suddenly you've got Gazebo plugins which crash with ABI issues and you have to go spelunking to find out which binaries are linked to what and where the conflict is.
  - hisham_hm 6y ago
    > Sounds a bit like how Homebrew works (or used to, anyway). It's not by accident! In its original docs, Homebrew described itself as package management "the GoboLinux way". Given how Homebrew has become this super-popular tool, its success makes me proud of Gobo's legacy (and a bit vindicated from all the people who told us "this model is crazy, it will never be usable!" :) ) > keeping all versions of everything is that you end up with problems when you're trying to build/use packages with a large pool of dependencies Yes, it can be a pain! In recent years, we introduced Runner (https://gobolinux.org/runner.html https://gobolinux.org/runner.html) in GoboLinux as a way to address this kind of issue; a virtualization layer to present the expected dependencies at the right places.

LockAndLol 6y ago

From the FAQ > Is GoboLinux "ready"? > Yes, it is ready in the sense that you can, today, have a full operating system running 100% on GoboLinux, like many people around the world do. > Note, however, that it is neither a beginner-oriented distribution, or an end-user binary-oriented distribution like Ubuntu. To use GoboLinux today, the user is expected to be proficient with the command-line and willing to compile and configure their software. Yeah, nah. I recently watched a streamer try to compile some nvidia stuff for CUDA in order to use her DSLR camera at >18fps. A very nice reminder that it's never "just ./configure && sudo make install". Especially uninstalling stuff installed that way is a horrible pain. I used to create .deb's from it, but boy am I glad those days are over. Besides that, the motivation and sane folder names seem great.

freedomben 6y ago
I wouldn't say it's never "just ./configure && sudo make install". I compile a fair number of projects myself and (as long as deps are installed properly) it usually is just configure/install, on mainstream distros at least (Fedora, Ubuntu, Arch). No doubt though a lot of projects could do much better. I find anything needing GTK and Qt are often much harder, usually because the required packages aren't documented anywhere, or if they are it's for Ubuntu that's 4 years old. Nvidia and other things requiring proprietary are a nightmare. I will never buy another machine with an Nvidia card after the kernel 5.9 hell I've been through.
hisham_hm 6y ago
> Especially uninstalling stuff installed that way is a horrible pain. That was indeed one of the motivations for GoboLinux after tinkering with hand-compiled software a lot. Uninstalling is a mere "rm -rf /Programs/ProgramName" :)

ufo 6y ago

I have a friend that uses GoboLinux. It's not a mainstream distro but my friend did seem able to hook it to the overhead projector without problems, so it works well enough from at least that point of view :)

ufo 6y ago

By the way, if you scroll all the way down in the "Docs" page of the website there are links to older articles about the early history of Gobolinux. Some interesting discussions about the design of the Unix file system hierarchy.

floatingleaf 6y ago

This seems to be NixOS minus the Nix language, and traditional approach to package installation, configuration etc.

forgotpwd16 6y ago
The only similarity is the non-standard filesystem hierarchy but even how that comes to be differs conceptually.

Ericson2314 6y ago

Ah, I remember 7 years ago trying to decide whether I'd switch to GoboLinux or Nix. I choose the latter and don't regret for a moment, but I'll continue respect GoboLinux and have the found memory. I think the big difference is: - Nix: the filesytem is rarely the right datastructure (I agree) other things are needed. - Nix: Store and Nix too is more freeform, package / distro norms provided by higher layers (Nixpkgs, NixOS)

diomedes 6y ago
I've been using NixOS for 2 years now, my general impression is that even if Nix isn't the popular solution, it'll probably inspire the right way of doing things for the next years. It might not look like much, but representing the whole system's dependencies as a Graph database, then using a purely functional language to define such database has happily prevented me from shooting myself in the foot many times over the past year.
- freedomben 6y ago
  Have you tried any of the containerized distros? I haven't tried Nix but want to. Just wondering if you can compare/contrast NixOS with something like Fedora Silverblue or Fedora CoreOS.
  - arsfeld 6y ago
    I used both and even though their purpose is very similar (have an "immutable" system tree that you create and switch into it), the day to day is very different. Silverblue is still pretty much imperative, you install/remove RPM packages and that's it, you use Flatpak for everything else. NixOS you have to describe your entire system in a programming language. NixOS gives you so much more freedom to do what you want, but you have to work for it, learn a language, learn it's constructs, etc. I enjoy both though, feels like the right direction to go, you just need to choose how you want to interact with your OS.
  - Ericson2314 6y ago
    I haven't tried, but I get the sense that those are more about cleaning up the run time than the build process. At least the flatpak/snap world also is kind of anti-integrative in that everything is vendoring everything else. I personally think containerization is just too much a PITA to use for software that doesn't live in a bubble, e.g. desktop software. The capabilities revolution (Capsicum or CloudABI) would be more secure and easier to program with, so we just need to force our way there, and then everything will take care of itself.

foxyv 6y ago

Wow, this model addresses a lot of the issues I have with different Linux distributions. Mainly, finding where the heck it installed that program in the maze of file/folder locations. Sometimes it's etc, opt, var/lib, bin, usr/bin, apps... Gwahhhhh! Then, you go to modify the configuration, and it turns out that the configuration file is being copied and generated from a different location. It's endless misdirection which changes in each distribution based on the package manager. I think I may try out Gobo the next chance I get. This is pretty cool.

freedomben 6y ago
FHS and distros that follow it aren't perfect, but it does make a big difference. I prefer Fedora-based and Arch-based flavors for that reason. It's usually pretty easy to find stuff. Backtrack used to do something like this and while it was easier compared to a lot of other debian/ubuntu based things, I still ran into some pain points. A great command to keep handy is ls -la `which <program>` That will usually find you the binary right away, and if it's a symlink or something you'll see it in the ls output. It's especially useful to me because (generally speaking) I put stuff I build myself in ~/bin rather than `/usr/local/bin` so I can quickly tell if I'm using my own build or the package manager's. Edit: FHS == Filesystem Hierarchy Standard - https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
- LMYahooTFY 6y ago
  Thank you, that's informative and you and GP have made me feel better about this particular aspect of learning Linux.
  - freedomben 6y ago
    My pleasure! It can feel brutal at first to learn Linux, especially with so much choice out there (aka fragmentation?), but honestly it's the best thing I ever did for myself both personal and career-wise. Can't recommend at least basic Linux proficiency enough if you are in a technology sector especially.

tomw1808 6y ago

Might be a really stupid question, it's late here, be gentle: but why not just dockerize all applications and let them bring their own libraries etc by default? Wouldn't address similar issues with "everything neat and tidy"?

freedomben 6y ago
Take a look at Fedora Silverblue, or on the server Fedora CoreOS (FCOS)/RHEL CoreOS (RHCOS) if you want to see serious mainstream effort at it (no shade at the other projects whatsoever btw, I think this is cool). I don't currently run Silverblue full time but I could see myself doing so in the future. Regarding docker containerization specifically (or a different OCI-compliant runtime like Podman), it gets very hard because of things like video and sound (Pipewire should help immensely), but also there are lots of apps that you want to have uncontainered access. Like Vim becomes a lot less useful to me if it's filesystem is contained.
LaGrange 6y ago
Well, for starters, GoboLinux is far older than Docker. It's built on similar (sometimes identical) tools to what Docker uses, though.
ogre_codes 6y ago
I don't know how well Docker works with X11, but just the fact that it would be nearly impossible to make global settings changes would be frustrating as hell. Having a full Gnome install on every app, a full KDE install on every app. Having to install a given theme into every single docker container. Maybe I'm missing something. I'm not even sure how this could make sense.
- SulfurHexaFluri 6y ago
  You wouldn't use docker, Flatpak would be the choice for containerized gui applications. I'm not an expert but it looks like the kde and gnome env gets shared between flatpak applications.
  - 6y ago

0xbadcafebee 6y ago

We did something like this 20 years ago at a company I worked for. It's effectively pointless, and there are better, more modern methods. Here's why. First of all, the filesystem isn't a database, it's a hierarchical index of files. It has a couple fancy features specific to managing files. Trying to force it to do more than that will result in pain, and eventually building something else around it. But the filesystem isn't even the biggest limiting factor. Managing both the build-time and run-time dependencies of software is more complex than a filesystem can handle. To execute an application in an operating system, there must be one "environment", which is a combination of a kernel, an OS's environment and resources, and a set of applications and dependencies. The dependencies are set at build time and run time, and can't be interchanged at will without causing instability (if it works at all). You can juggle symlinks around all you want, but it doesn't result in any useful functionality other than looking at a bunch of differently versioned files that are not - cannot - be in use. The applications themselves can be programmed to interact with multiple versions of dependencies, but if they are not already built to do so, you cannot force them to. This underlying limitation is what forces an application environment to depend on a static tree of files. It doesn't matter how many versions of a dependency you have installed, you can only use one at a time, as each application allows you to. That's why you can only install one version of a package, and why we don't have trees of versioned file hierarchies for the dependencies. They'd be pointless. You can only use the files you can use. All popular Linux distributions today know this. They have worked along with the Linux Filesystem Hierarchy Standard over the past 26 years, and understand these issues well. Distros may implement it differently, but mostly they conform to it, because they know nothing else really makes a difference. At the end of the day, the current standard (when properly used) is as simple and effective as we can get. Some software developers (cough Systemd cough) basically don't give a shit about the standard, and generally make the users' and distros' lives harder. This is the one place where the distros could make a difference, by forcing a structure that makes more sense. But enforcement is haphazard, so some apps can force really stupid file structures on distros, and people wonder why the filesystem is so confusing. So you may ask, what's a better solution? The answer is containers (or really, chroot environments, but that's what a container is). I have a longer post which goes into more detail about why package management literally cannot solve any other problem than it already does, and why containers are the only "advancement" without radically redefining application development: https://gist.github.com/peterwwillis/e96854532f471c739983c0bba7608834 https://gist.github.com/peterwwillis/e96854532f471c739983c0b...

cassepipe 6y ago

I have been waiting to try that one for a long time. I always found it annoying that the linux filesystem is not self-explanatory. I have been given unsatisfactory explanations about it so many times but could never understand the rationale between the /bin, /usr/bin, /usr/local/ etc. Turns out it is just historical cruft : (oops can't find the link) I am so glad I switched to Linux but I really miss Window's 'Program files' directory.

cycomanic 6y ago
I find the complains funny, for one you should really never need to care where certain programs are installed (and I don't remember the last time I had to). Moreover you can always run which executable and it tells you the location of the executable. It's also funny how Windows is supposedly better, there is at least program files and program files (x86) some programs still just install into C: (I think python used to do that), and there are the different windows folders. Let's not forget the myriad of places where programs drop data. And because Windows has no proper package management, you actually need to where things are.
- cassepipe 6y ago
  > I find the complains funny, for one you should really never need to care where certain programs are installed Well Linux is not a walled garden with a company that takes care of everything behind the scenes so it should be easy for a beginner to wrap its head around a system and understand at least its logic. It's good not to have to rely on specialists for simple things.
  - cycomanic 6y ago
    I really don't understand what you mean. A beginner should be able to sit in front of the linux machine and just understand everything without needing to do any background reading? And to what level does that apply? Should the user understand everything? Also why is a directory system of /Firefox /Chrome /Gimp ... easier? Where do libraries sit in this system (is that easy to understand?)? How do I determine if I build something what library I'm going to use ... I think the perception of a certain way being easier is largely based on what one is used to. I certainly am always lost when I sit in front of a windows machine. Just the other day I was trying to get ctypes to find a library and ended up just ending lots of things to LIB or PATH (I'm sure there are better way to do things). BTW I was asked by a windows user for help. This is not a dig at windows, just my argument that filesystem layouts are largely conventions (even though often for good reasons) and yes one has to invest some time to understand them. Edit: For someone who wants to understand how Linux works and many things work together I highly recommend giving linux from scratch a try. Most people fall into the trap of just copy pasting the commands (I was one of them as well), so you probably want to build a couple of times, and try to update your system. Hopefully you run into a couple of roadblocks, which force you to thing a bit more about what you are doing and is were the learning experience comes from IMO.

sitzkrieg 6y ago

the file system as a database for files... what a novel concept

cassepipe 6y ago
Does it need to be novel to be a good idea ?
johnisgood 6y ago
That is funny though because GoboLinux is 18 years old.

cassepipe 6y ago

Is it based on the work of any other distro or its own thing ? What init system has it got ?

lucasvr_br 6y ago
Hi! It isn't derived from any other distro; it's built from scratch using its own file system arrangement. The most recent release comes with GoboLinux' own init system, although we have been running some experiments with systemd as well.
- cassepipe 6y ago
  Thanks. What's the name of the init system ? Any reason not to use Void's runit ? Any reason to switch to systemd ? (I am truly unopinionated on init systems,not trying to start a flame war, juste curious)

deleted 6y ago

[deleted]

siraben 6y ago

How does GoboLinux distinguish between packages of the same version compiled under different environments, or compilers, flags etc.? In Nix such changes cause the resulting build to be prefixed in /nix/store with a different hash.

einpoklum 6y ago
I'll venture a guess: It doesn't need to. All of the "first-class citizen" packages, which are visible to everyone, were built in the same environment, just like in other distros. Alternative versions should just be held separately. ... but come to think of it - that means that you can't just put your package in /programs/MyApp/12.3.4 - because if you switch your system to that version your dependencies may well break. Hmm.
ignaloidas 6y ago
It's all compile on machine, there's no package repository, only a Recipe one.

dang 6y ago

If curious see also 2017 https://news.ycombinator.com/item?id=14925743 https://news.ycombinator.com/item?id=14925743 2016 https://news.ycombinator.com/item?id=13188522 https://news.ycombinator.com/item?id=13188522 2014 https://news.ycombinator.com/item?id=7722690 https://news.ycombinator.com/item?id=7722690 2010 https://news.ycombinator.com/item?id=1735532 https://news.ycombinator.com/item?id=1735532

eeZah7Ux 6y ago

"each program resides in its own directory, such as /Programs/LibX11/1.6.9 and /Programs/GCC/9.2.0." Brings back some memories from the old days of using windows. Thanks, I'll pass. FHS exists for many reasons.

xolve 6y ago

I used to think it would be a holy mess of symlinks. Spinned up live image in a VM and pleasantly surprised. For compatibility there are traditional /bin but its a symlink to /System/Index/bin, which contains links to actual executables in respective /Programs directory. I wonder why its such a niche distro, with time this should have caught on and be more popular!

amelius 6y ago
> For compatibility there are traditional /bin but its a symlink to /System/Index/bin Then why does the readme say: > cd / > ls Programs Users System Data Mount Are they hiding directories?
- Blikkentrekker 6y ago
  Yes, they are. There is a kernel module that ensures that listing hides, but files can still be accessed by their path. I'm not sure to what level this is an absolute disaster.
  - amelius 6y ago
    For starters, I guess that an rsync of / will not backup the entire system then.
    - Blikkentrekker 6y ago
      Yes, quite a bit of software is written around the assumption that what does not show up with a listing truly not exist, — Including, I would assume, rather security sensitive software.
      - isr 6y ago
        The kernel module that hides the standard dirs under / is entirely optional, and is only there for aesthetic purposes. If you don't want it, don't load it. Absolutely nothing in gobolinux requires that kernel module to be running. Again, its just purely for aesthetic purposes.

Saint_Genet 6y ago

Is finding applications on the fs a big problem people actually have?

hnarn 6y ago
I read the "At a glance" documentation and came upon 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. This just feels wrong to me. I appreciate that Linux is all about choice, but I really wouldn't want this.
- aktuel 6y ago
  Why?
drdaeman 6y ago
It's not about finding applications, it's more about the ability to have multiple versions of the same package installed and used concurrently. Best you can have with FHS is something like /usr/bin/python3.8 vs /usr/bin/python3.9, and this requires package maintainers to manually support this. Most packages don't do this, so if you happen to need - just a random example - an ancient Firefox version installed separately, "traditional" solutions like rpm or dpkg won't really help you. Plus, a different organization of the filesystem, where everything that belongs to a package is stored under the same base path, rather than being spread across the whole FS. I don't really remember GoboLinux ideas, but IIRC they had something about leveraging use of the filesystem as a part of package manager.
- SulfurHexaFluri 6y ago
  The better way to do this is to use flatpak. The sandboxing will be a major benefit for your ancient firefox version as well.
kelnos 6y ago
Yeah, I don't think that's a problem I ever run into. Also they claim: > Say goodbye to the old problem of having the package manager complain that libXYZ is not installed even though you can see that it is there. That is... also a problem I have never had. I like the idea of GoboLinux just for giving a new take on something more streamlined (because yes, the FHS and de-facto systems before it have accumulated a lot of cruft), but I think it would be more productive for the GoboLinux folks to advocate for their system based on its own merits, not on semi-imagined faults of the more common system. Being able to have multiple versions of programs and their dependencies (which would help avoid dependency hell) installed is a big thing! That alone is a really nice benefit of GoboLinux's system.

enriquto 6y ago

Please, a fork of GoboLinux called gobolinux without the silly mixed-case directory names.

kelnos 6y ago
It feels really petty and bike-shed-y to focus on this, but this was my first thought too when I saw the sample directory listings.
- enriquto 6y ago
  I agree, but the whole gobolinux idea is the epitome of bike-shed-y! You just rename things and the behavior is 100% identical as before.
mixmastamyk 6y ago
I think I'd prefer that as well. However it is easy to configure a modern shell for case-insensitive completion.
- enriquto 6y ago
  Completion is not an issue. The problem is that upper case just looks ugly. Like huge fluorescent decals on an otherwise streamlined matte black road bike. They put a lot of effort to create an über-elegant naming scheme, and then they spoil it for no reason.
knolax 6y ago
First thing I thought of too. Mixed cases when all the directory names are single words seems completely unecessary.
- kazinator 6y ago
  End users are used to mixed-case system directory names. C:\Windows\System32 C:\Users\bob\Downloads

einpoklum 6y ago

Have a look at the FAQ: https://gobolinux.org/faq.html https://gobolinux.org/faq.html It says: > To use GoboLinux today, the user is expected to be proficient with the command-line and willing to compile and configure their software. If I need to compile and configure my software myself, then this is not really a distribution IMHO.

TheCraiggers 6y ago
So you don't consider Gentoo or Slack distributions?
- kelnos 6y ago
  You don't really "compile stuff yourself" on Gentoo. There's still a package manager, and it does all the building and installing for you. Yes, compilation happens as a result of the user invoking the package manager, but there's a huge usability difference between "emerge foo", and download foo.tar.gz -> unpack -> configure/build/install -> track updates and repeat as needed. I would call the latter "compiling foo yourself", but not the former.
  - ignaloidas 6y ago
    It is similar on GoboLinux as well. There is a Recipe repository that contains build scripts that you invoke with Compile, which automatically compiles and installs the package.
- einpoklum 6y ago
  What kelnos said... I respect Gentoo fine (have not tried Slack TBH); and a distribution can very well be compilation-based - but that doesn't mean that I have to sort things out manually. That's what packagers and distribution maintainers are for. Gobo seems to tell you that I need to do that work myself.
  - isr 6y ago
    One of the "first-class-links" on the top of the homepage explains their build-from-source manager: https://gobolinux.org/recipes.html https://gobolinux.org/recipes.html Might have been a good idea to just click on that, first? FWIW, they used to have a very nice rootless install of their compile framework, allowing you to use gobolinux within your home dir, within another distro.

snicker7 6y ago

How does this compare to Guix/Nix?

netsec_burn 6y ago

Security guy here. I had the chance to look over this project and try it out today. I have no less than 5 ways to acquire root privileges from an unprivileged user in the 15 minutes I looked at it. Has anyone audited this distro in the past 10 years?

arc-in-space 6y ago
Ugh. Any specific examples, just for the record, for someone who doesn't care enough to try the system?
sieste 6y ago
Thanks security guy. For reference, how many ways to break in do you find per 15 minutes when looking into other distros?
- netsec_burn 6y ago
  Depends on their popularity. For Ubuntu, Debian, RHEL, Mint, MX Linux, etc. it took me 10 years to find a single LPE. Special case Linux distros, like those for audio editing or signal processing, have about 1-3 LPE's in the first 30 min to an hour I look at them. And GoboLinux.. broken permissions, broken trust of library load paths, root SUIDs with 5 LPE issues at a glance of the source. They even gave some regular binaries root privileges because why not. I didn't look into the root services running or writable paths because I assumed those would be vulnerable too. The question is not if you can get root, but how many ways there are to get root. I was running GoboLinux in a 15 minute session, and once it expired I didn't start a new one. I'll come back to it and do a more comprehensive audit. I haven't released any zerodays I've found, ever, but recently I was thinking about making a blog. This might be some good material.
  - sieste 6y ago
    Thanks, good to know that this is not the norm. Yes please do a more comprehensive audit. And start a blog.
  - adamcstephens 6y ago

kazinator 6y ago

Gobo likes the classic, four-month-old TXR from 2009. https://github.com/gobolinux/Recipes/blob/master/TXR/025/Recipe https://github.com/gobolinux/Recipes/blob/master/TXR/025/Rec... They jumped on it shortly after I made the project public with version 9, picking up version 13. They updated to 18 and then one more time to 25 and that was it. Guess I just don't make `em like I used to.

donatj 6y ago

It's interesting and crazy to me that Gobo is still going. I played with it back in highschool in like 2004.

sally1620 6y ago

Is there a WSL version of this?