7 ms·
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.
by 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 agoUnless those principles are merely the solution to problems that don't exist anymore like /usr separation ?
- Gormo 3y agoYes; the presumed obsolescence of a problem does not imply that remaining elements of its solution are "a mess".
- nunobrito 3y agoCall 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 agos/Linux/Unix MacOS is better though.
- tomrod 3y agoThis is a joke, right? MacOS is all over the place?
- rufugee 3y agoAgreed...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 agoAnd /Applications, and /System/Applications, even though if you open them in Finder, you'll see the two combined.
- reactordev 3y agoAnd ~/Applications, and /usr/bin, and /usr/local/bin, and homebrew, and Mac ports, tell me again how Mac is better?
- wraptile 3y agoI'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 agoThe 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 agoI'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 ago1. /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 agoYou 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 agoI'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 agoNix 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 agoMaking 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 agoThe 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 agoI 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 agoI 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 agoHomebrew 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 agoThey 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 agoI 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 agoYes, 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 agoDo 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 agoI'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 agoThere 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 agoThose 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 agoUnless you want Bluetooth audio without systemd, then you’re SOL
- matheusmoreira 3y agoNot 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 agovoid 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 agoOnly 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]