[HN Gopher] GoboLinux
___________________________________________________________________
GoboLinux
Author : frabert
Score : 211 points
Date : 2021-02-02 15:41 UTC (7 hours ago)
(HTM) web link (www.gobolinux.org)
(TXT) w3m dump (www.gobolinux.org)
| ufo wrote:
| 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.
| sitzkrieg wrote:
| the file system as a database for files... what a novel concept
| cassepipe wrote:
| Does it need to be novel to be a good idea ?
| johnisgood wrote:
| That is funny though because GoboLinux is 18 years old.
| xolve wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| snicker7 wrote:
| How does this compare to Guix/Nix?
| transfire wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| https://github.com/NixOS/rfcs/pull/17 proposes lots and
| lots of symlinks in a way that reminds me of GoboLinux :).
| Mathnerd314 wrote:
| For handling rollbacks you can use a normal layout and an A/B
| partition scheme
| (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.
| cassepipe wrote:
| Is it based on the work of any other distro or its own thing ?
| What init system has it got ?
| lucasvr_br wrote:
| 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.
| foxyv wrote:
| 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.
| Blikkentrekker wrote:
| In almost any system, finding out where what files belong to a
| package is a trivial operation for the package manager to list.
|
| The idea that a package is "installed somewhere" rather than
| "installed" and has files that "belong to it" seems to be a
| _Windows_ -ism in mentality, where it is common to start
| applications by navigating to the folder they are installed in,
| and starting an execution there from an absolute path.
|
| Many packages' files consist of nothing more than adding more
| fonts to the system, it seems a bad idea to me, to have all
| that in a per-package folder, rather than simply in
| `/usr/share/fonts`, and have the package manager track what
| file therein belongs to what package.
| fiddlerwoaroof wrote:
| /bin and /usr/bin make less sense these days since the root
| partition is usually big enough to boot and to hold all the
| programs the system needs. But it's important to have somewhere
| outside the package-manager's control for manually installed
| binaries. Most installers default to directories like
| /opt/foo/bin and I tend to put user-built programs into
| /usr/local/bin.
| mindslight wrote:
| /bin and /usr/bin would actually make plenty of sense these
| days - the new root partition is called initrd and gets
| hidden by pivot_root.
| freedomben wrote:
| 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
| forgotpwd16 wrote:
| Interestingly Arch address multiple bin directories mess by
| symlinking /bin, /sbin, and /usr/sbin to /usr/bin. Stali, an
| experimental distro (originally a suckless.org project), goes
| that a bit further by symlinking /sbin to /bin and /usr to /.
| pkaye wrote:
| Its the same in Ubuntu and Centos with symlinks of the bin
| directories.
| stonesweep wrote:
| Big picture, this is known as "the usr merge" which has
| been happening for probably a decade, each distro is
| approaching it at their own speed as they're not all
| _exactly_ identical in their FHS layout (some distros add
| a bit of this and that on top).
|
| You can read about it at a meta level over here, each
| distro has it's own wiki/working page if you Google
| around: https://www.freedesktop.org/wiki/Software/systemd
| /TheCaseFor...
| stonesweep wrote:
| trivia: `which` is not the _same_ which on all distros - on
| Ubuntu for example it 's a super simple shell script named
| `which` which supports one single param (-a), not the
| compiled binary that you have on say Arch - and the features
| are different between them - I can't for example run `which
| --skip-tilde which` on Ubuntu, invalid usage.
|
| Many scripters who need wide compatibility of "which" fall
| back to the builtins `type` and `command` as they resolve any
| bash aliases set and give you a more truthful (sic) output
| than relying on `which` and bash is bash on all platforms:
| # command -v which /usr/bin/which # type
| which which is hashed (/usr/bin/which)
|
| $0.02 for your next adventure down the `which` rabbit hole.
| :)
| akira2501 wrote:
| It can also be a shell builtin:
| akira@akira:~ which which which: shell built-in
| command
| stonesweep wrote:
| Very true, I missed that thanks - to illustrate how that
| could be important (to the scripter):
| kaneda@tetsuo:~ which type kaneda@tetsuo:~
| type type type is a shell builtin
| kaneda@tetsuo:~ command -v type type
|
| This was on Ubuntu, the which script doesn't resolve type
| or command silently, while on say Arch it's verbose
| ("can't find type in (paths ... ...)" so even a failure-
| to-find emits differently for the `which` crowd.
| LMYahooTFY wrote:
| Thank you, that's informative and you and GP have made me
| feel better about this particular aspect of learning Linux.
| freedomben wrote:
| 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.
| Fnoord wrote:
| > 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.
|
| FTA you linked:
|
| > Most Linux distributions follow the Filesystem Hierarchy
| Standard and declare it their own policy to maintain FHS
| compliance. GoboLinux and NixOS provide examples of
| intentionally non-compliant filesystem implementations.
|
| Debian and Ubuntu adhere to FHS; they're not more difficult
| in this regard than Arch or Fedora (or distributions based on
| these). GoboLinux and NixOS don't because they serve a higher
| goal. GoboLinux for user-friendliness/explorability and has
| backwards compatibility (which is hidden via optional kernel
| extension), NixOS aims to solve dependency hell (among
| various other goals). Learning curves are an obvious
| drawback.
|
| > ls -la `which <program>`
|
| Backticks should be avoided; use ls -la $(which <program>)
| instead (avoid the $ in Fish).
| meddlepal wrote:
| The FHS really only makes sense when you use Linux as
| traditionally intended as a multi-user system.
|
| Most uses of Linux are single-user, running as a server, or
| even more just a container.
| sergeykish wrote:
| FHS makes sense from a system developer standpoint --
| entire system is a project /lib for
| libraries /usr/include for C includes /etc
| for configs
| freedomben wrote:
| I'm not sure I agree that most uses of Linux are single-
| user. I know this (likely) isn't what you meant, but at a
| minimum most every system, even containers, will have at
| least two users: root and the non-privileged user account.
| It may not be two _humans_ but it is two users. On my
| current desktop (where I 'm the only human user) I have 53
| entries in /etc/passwd. Each have different permissions and
| access to resources.
|
| But even if you consider the above to be a single-user
| setup (which is reasonable) I still think there's value in
| consistency. I personally get a ton of value from having
| CentOS and RHEL systems being laid out the same as my
| Fedora Laptop and Desktop system, and having all that
| knowledge transfer both ways. Being able to add a user to a
| "single user" setup too is very useful. It would suck if
| adding a second user required completely changing
| everything about the filesystem.
| johnisgood wrote:
| I ran across it ages ago. I think you could use something like
| GNU Stow to achieve the same thing unless I am missing
| something. You install programs to ~/.local/pkg, then you link
| it to ~/.local/{bin,etc,include,lib,man,share,var}. Unless of
| course it is an Electron app.
|
| I use zpkg to handle this, it has been made specifically for
| this use case.
| ploxiln wrote:
| GoboLinux install layout is a cool concept.
|
| However, it's not hard to figure out where files were
| installed, and what files are from. The package manager keeps
| track of all of that, and you can ask it. Example for debian or
| ubuntu: # list all files from package
| dpkq-query -L <package> dpkg-query -L <package> | grep
| bin/ # see just commands # find what package a file
| is from dpkg-query -S /path/to/some/thing
|
| I use equivalent commands in Archlinux (pacman ...) and they
| certainly exist for redhat/fedora but I'm not familiar with
| those.
|
| For stuff not installed as packages, hopefully it's either in a
| single directory in /opt, or among a small collection of stuff
| spread in /usr/local, or in a self-contained directory in your
| home folder.
| Aissen wrote:
| I have now memorized all commands (and stopped switching
| distros), but I used to regularly look at this rosetta stone
| of package management commands:
|
| https://wiki.archlinux.org/index.php/Pacman/Rosetta
| curt15 wrote:
| That of course assumes that the post-install scripts don't
| move files around. Mac OS has a similar utility called
| "pkgutil" which supposedly tracks all files belong to
| programs that come as "pkg" files -- typically system
| utilities that don't make sense to ship as clickable bundles.
| But the pkgutil database is often useless. For example, the
| MacGPG installer used to "install" its files under
| "/tmp/private", but that was simply a temporary install
| directory which was immediately moved by a postinstall script
| to an untracked location.
| colechristensen wrote:
| RPM-based distros (redhat, etc.) # List all
| files from q package rpm -ql <package> #
| Where did file come from rpm -qf <path>
| antx wrote:
| And just because I have to be THAT guy, with Arch linux you
| use pacman -Ql and pacman -Qo to do the same.
|
| Also, man! Do I love the Arch wiki:
|
| https://wiki.archlinux.org/index.php/Pacman/Rosetta
| floatingleaf wrote:
| This seems to be NixOS minus the Nix language, and traditional
| approach to package installation, configuration etc.
| forgotpwd16 wrote:
| The only similarity is the non-standard filesystem hierarchy
| but even how that comes to be differs conceptually.
| siraben wrote:
| 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 wrote:
| 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.
| LockAndLol wrote:
| 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 wrote:
| 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 wrote:
| > 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" :)
| Ericson2314 wrote:
| 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)
| monoideism wrote:
| I'd like to try NixOS, but from what I've seen, there are still
| a lot of issues trying to run it as a daily driver on a laptop.
|
| Has that been your experience?
|
| With Ubuntu, Debian, and even Arch, it's pretty much install
| and go.
|
| Also, it requires significant disk space, which I usually don't
| have on my laptops.
| miloignis wrote:
| I've been using it as the daily driver on my laptop for a few
| years, and it's been great! Using it in general is a steepish
| learning curve, but I think it's very worth it. Having
| rollbacks for every upgrade just makes me sleep better, and
| it's saved my bacon more than once. Being able to customize
| the packages running on my system in a safe and reproducible
| way is great as well. It's also helped me do research, it's
| easy for me to build different versions of a package with
| different patches and compare their performance, etc.
| kevincox wrote:
| Same. Rollbacks are awesome. Not only rollback in the boot
| menu, but also just keeping your OS configs in Git. It is
| so nice that I can mess with my configs without concern,
| then when I am done I can diff them too see what I changed,
| continue messing to clean them up a bit, then commit (or
| reset if the experiment didn't work out). When I used Arch
| I would edit a handful of configs trying to set up
| something new or tweak a setting and I could not get back.
| I would need to take notes or just try my best (I have
| force-reinstalled packages countless times).
|
| I'm also waiting for the parts of my new desktop to come in
| and I'm excited that all it takes is cloning my config repo
| and applying to get to exactly the same setup. With Arch I
| would have reinstalled to clear the cruft that has
| accumulated, however with NixOS I can just audit my configs
| to see an entire list of cruft and easily undo it by
| removing lines.
| X6S1x6Okd1st wrote:
| Tbh I'd recommend trying nix on top of another distro or on
| top of OSX first.
|
| If you just want the ability to install arbitrary versions of
| packages along side each other/have painless roll backs/bake
| config files into your install you can do that there.
|
| Once you get comfy with nix on top of another distro then
| think about whether you want that approach with the entire
| stack.
| johnvaluk wrote:
| I run NixOS on a variety of laptops as my daily driver. While
| there's initially a steep learning curve, the time is well
| spent developing a reproducible configuration that you can
| quickly install on a new machine. I adapt the same
| configuration to generate a custom ISO that I write to a USB
| drive so I can boot into a familiar environment in a few
| minutes on almost any machine (running in RAM if there's
| enough room). It doubles as an installer (as does any NixOS
| installation). This approach is also handy for booting
| ephemeral servers on any hardware (DNS, DHCP, etc.).
|
| One of my hobbies is recycling older machines. I've installed
| NixOS on Chromebooks with 16GB internal drives. It's possible
| if you remember to garbage collect after each successful
| upgrade (and stick to 64-bit machines).
|
| I tend to treat my laptops as disposable and keep my
| important data on a file server so I don't rely on local disk
| space.
| monoideism wrote:
| > I tend to treat my laptops as disposable and keep my
| important data on a file server so I don't rely on local
| disk space.
|
| I do the same, except I use an extensive dotfiles, config,
| and bootstrap script repo[0].
|
| So I like the idea of Nix for that reason. It's going to be
| hard to let go of Debian/Ubuntu, but I'd really like to
| have a perfectly reproducible environment like Nix.
|
| Thanks for your reply.
|
| 0. however, I also unfortunately have to use Windows
| sometimes,so I dual boot, and that takes up significant
| room on my smallish laptop drive
| aidenn0 wrote:
| I've been using it for almost 3 years on my laptop with no
| issues. As far as disk-space 50GB is generally enough if you
| collect the garbage periodically (my workstation is using a
| bit over 100GB after almost 2 years of running NixOS, but I
| don't think I've _ever_ done garbage collection on it).
| chpatrick wrote:
| I've had pretty much no problem on my ThinkPad. It always
| depends on how custom your setup is.
| amelius wrote:
| I'd love to use Nix, but I'm using a lot of embedded devices
| which are tied to specific Linux releases (e.g. NVidia Jetson
| <-> Ubuntu). Trying to get e.g. a GPU to work on these systems
| with Nix is probably going to be a bad idea.
| diomedes wrote:
| 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 wrote:
| 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 wrote:
| 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.
| arexxbifs wrote:
| 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 wrote:
| It's not a new take. It's been around for more than a decade
| (18 years, actually).
| AnIdiotOnTheNet wrote:
| Yeah, I remember GoboLinux from when OSNews was still a
| happening place.
| theastrowolfe wrote:
| First time reading about a distro like this. Looks pretty neat!
| Isn't this what /opt is for though?
| hisham_hm wrote:
| 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 wrote:
| 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 wrote:
| > 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) in GoboLinux as
| a way to address this kind of issue; a virtualization layer
| to present the expected dependencies at the right places.
| mikepurvis wrote:
| > In recent years, we introduced Runner
| (https://gobolinux.org/runner.html)
|
| Clever. Seems like it's essentially a way to "pause" the
| rolling distro at a known-good point, and then use that
| environment to build whatever high-level stuff it is with
| your set of frozen dependencies-- this would definitely
| do the thing, and would have been very helpful for the
| ROS on Homebrew effort.
|
| OTOH, how different is this from Debian Sid as the
| rolling release that is occasionally broken when a new
| low level dep comes in, with the supported releases of
| Debian, Ubuntu, and others as the shared pause-points? I
| think ultimately I find it easier putting the work of
| finding a set of interoperable versions of things onto my
| distro maintainer (and in exchange knowing that if I want
| the cutting edge I'll have to do my own backport or go to
| PPAs), rather than taking on that work myself and hoping
| for the best or risking getting stuck with a bunch of
| super-old stuff and no clear migration path forward.
| chairmanwow1 wrote:
| Honestly, I have never really grokked dynamic linking. As
| far as I understand it, it was birthed whenever disk space
| was a huge limiting factor so it was better to share
| dependencies between programs. But, golang's model of
| hermetic builds sits much better with me.
|
| I want to produce an executable asset that has everything
| necessary to run, regardless of the wacky local environment
| that it's being executed in. I have lost so much time
| trying to debug environment related issues because (at
| least in my experience), debugging them requires a deep
| system knowledge of the dependencies and how Foo
| tool/program/framework is expecting them to be.
| eeZah7Ux wrote:
| "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.
| enriquto wrote:
| Please, a fork of GoboLinux called gobolinux without the silly
| mixed-case directory names.
| kelnos wrote:
| 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 wrote:
| 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 wrote:
| I think I'd prefer that as well. However it is easy to
| configure a modern shell for case-insensitive completion.
| enriquto wrote:
| 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 uber-elegant naming scheme, and then they spoil
| it for no reason.
| ufo wrote:
| 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 :)
| tomw1808 wrote:
| 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"?
| LaGrange wrote:
| Well, for starters, GoboLinux is far older than Docker. It's
| built on similar (sometimes identical) tools to what Docker
| uses, though.
| ogre_codes wrote:
| 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.
| freedomben wrote:
| 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.
| [deleted]
| dang wrote:
| If curious see also
|
| 2017 https://news.ycombinator.com/item?id=14925743
|
| 2016 https://news.ycombinator.com/item?id=13188522
|
| 2014 https://news.ycombinator.com/item?id=7722690
|
| 2010 https://news.ycombinator.com/item?id=1735532
| einpoklum wrote:
| Have a look at the FAQ: 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 wrote:
| So you don't consider Gentoo or Slack distributions?
| kelnos wrote:
| 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.
| 0xbadcafebee wrote:
| 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/e96854532f471c739983c0b...
| ahnick wrote:
| Based on your experience then, do you feel something like
| Fedora Silverblue will ultimately be more successful than a
| NixOS approach?
| Saint_Genet wrote:
| Is finding applications on the fs a big problem people actually
| have?
| drdaeman wrote:
| 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.
| hnarn wrote:
| 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 wrote:
| Why?
| kelnos wrote:
| 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.
| cassepipe wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| netsec_burn wrote:
| 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?
| sieste wrote:
| Thanks security guy. For reference, how many ways to break in
| do you find per 15 minutes when looking into other distros?
| arc-in-space wrote:
| Ugh. Any specific examples, just for the record, for someone
| who doesn't care enough to try the system?
___________________________________________________________________
(page generated 2021-02-02 23:00 UTC)