[HN Gopher] GoboLinux
___________________________________________________________________
GoboLinux
Author : haunter
Score : 245 points
Date : 2024-02-28 01:15 UTC (21 hours ago)
(HTM) web link (www.gobolinux.org)
(TXT) w3m dump (www.gobolinux.org)
| Waterluvian wrote:
| Ignorantly: is this how MacOS kind of works? It always felt
| incredibly good how applications were always just this one "file"
| you'd drag and drop and manage.
|
| Nothing makes me feel dumber than trying to figure out where the
| heck anything is or gets placed in my Ubuntu machine.
| bombcar wrote:
| Bundles on macOS are/were a really good idea, but applications
| will still spurt some juice in weird random locations, usually
| in ~/Library.
|
| Fun comes when you have things like minecraft launchers that
| contain everything and all the worlds and saves inside the
| bundle.
| Klonoar wrote:
| The trick of shoving everything inside the bundle (including
| write things) no longer works if you're codesigned - there
| was always a note in the docs (buried, as usual) that while
| it might work it wasn't guaranteed to always work. Sure
| enough, as of a recent release it'll invalidate your
| signature if you've distributed it codesigned and write into
| the bundle.
| nusl wrote:
| If I wrote programs for Mac, this is one of the things that
| would really piss me off. Then, I'd write to ~/Library
| because I'm not gonna spend the time to figure out how to
| make it work with codesigning, if at all possible.
| Klonoar wrote:
| But like... why? If you wrote for Mac, you'd also
| probably follow the news and updates from Apple, which
| didn't exactly hide the direction they've been pushing
| things in.
|
| You also _should_ write to a third party folder,
| preferably `~/Library/Application\ Support`. It's what
| it's for, after all.
| jwells89 wrote:
| > Nothing makes me feel dumber than trying to figure out where
| the heck anything is or gets placed in my Ubuntu machine.
|
| And this is made somewhat worse by Linux file managers trying
| to hide any part of the filesystem that's not your home folder
| or mounted drives.
|
| I get why it's done, the directory structure of your average
| Linux install is an absolute maze that's sometimes confusing
| even for the technically inclined, let alone the home users
| targeted by major distributions. It's ultimately treating the
| symptom and not the cause, though, and I think more Linux
| distributions should give serious thought to modernizations of
| their filesystem structures (as Gobo has).
|
| It's tempting to play with this myself. My goals would be to
| come up with a structure that's reasonably self-explanatory,
| guides novices away from the dragons, and allows file managers
| to hide very little (maybe nothing) without consequence.
| Qwertious wrote:
| You know what's fun? Finding a random non-computer-person and
| asking them what each FHS directory is for.
|
| "dev" is obviously for developers. "run" is where the apps
| are located. "bin" is the recycle bin.
| Waterluvian wrote:
| I always start by deleting the opt(tonal) directory to tidy
| things up.
| op00to wrote:
| I like to put my important files in the Terribly
| iMportant Place. Some times they go to the VARy Terribly
| iMportant Place.
| out-of-ideas wrote:
| lol, your non-computer-persons know what a developer is?
| nice!
| throwaway11460 wrote:
| Everybody knows about the rich lunatics that make
| computers do stuff nowadays.
| yjftsjthsd-h wrote:
| Why would a random non-computer person know or care about
| that kind of internal detail? It's like asking people about
| random files in system32.
| nmz wrote:
| Why would they not? we all have to use computers.
| Secretaries used to be able to code, such a thing is not
| possible nowadays as programmers create more and more
| obscurity.
|
| Corporate jargon is how companies hide away
| inefficiencies and illegalities. Now, jargon is usually
| not that, but most of the time it is. The same way
| programmers said a kilobyte is 1024 bytes (seriously?)
|
| To add to your point, yes, do ask a random person what
| notepad.exe doe vs what vi or emacs does.
| op00to wrote:
| Querying the rpm database in Fedora is simple. Can you not do
| the same with dpkg?
| matheusmoreira wrote:
| Why are you downvoted? That is the solution. Every package
| manager has this feature. One can list the files owned by any
| package on any Linux system, doesn't matter if it's Arch
| Linux or Termux.
| MenhirMike wrote:
| > It always felt incredibly good how applications were always
| just this one "file"
|
| While I agree with that in principle, in practice that's not
| true for a lot of applications that put a lot of stuff into
| ~/Library and /Library, and it's not unusual to see multi-step
| manual instructions on how to uninstall some apps on macOS.
| (Especially important if those apps add Login items) Windows'
| Add/Remove Programs at least gives a central space to trigger
| an uninstall, and most apps stick to it properly.
| card_zero wrote:
| Classic Mac OS, then. I assume /Library is something that
| appeared around the year 2000 after they threw in the towel
| and turned into Unix.
| xcrunner529 wrote:
| Yes they write config and user data there (like /etc in
| Linux) that is separate and custom from the program itself.
| Makes sense to me.
| wly_cdgr wrote:
| Wow, I absolutely hate this about Mac
| card_zero wrote:
| I respect your curious preference, but my theory of mind is
| failing me on this one. You like dependencies, or moving
| files by typing, or perhaps even both?
| wly_cdgr wrote:
| Heh. Yes and yes and in general I like to see the guts and
| be free to easily fiddle with them. The Mac way is the
| software equivalent of how you can't open their hardware
| easily, which I also loathe. To me a love of Apple is one
| of the surest signs that a person is not a real
| hacker/programmer but is just in this industry for the $.
| "I just want to get shit done" ...no you just want to make
| money. There are exceptions but they are rare.
| docandrew wrote:
| I ran Gobo for a while and really enjoyed some of their ideas. It
| was started by Hisham Muhammad, the author of htop.
|
| It's a shame that it didn't get more traction. We probably
| wouldn't have needed Docker or any of the gazillion package
| managers that are proliferating today if it had.
| geenat wrote:
| > We probably wouldn't have needed Docker or any of the
| gazillion package managers that are proliferating today if it
| had.
|
| 100% feel this way too. So much of the reason why we use
| containers is just not spreading crap all over the filesystem.
| It's why single binary distributables made popular by Golang
| are such a winner, ex: Caddy.
| depingus wrote:
| You might be interested in Fedora's Atomic desktops. They are
| immutable OS's where you don't spread crap all over the
| filesystem. Instead you rely on flatpaks, containers (toolbox
| or distrobox), and single binaries (if you got them).
|
| https://fedoraproject.org/atomic-desktops/
| geenat wrote:
| Been keeping an eye on it. Would be far more excited about
| GoboLinux though, to be honest.
|
| > the filesystem is the database
|
| is such an epiphany for GoboLinux, truly atomic.
| Cloudef wrote:
| Its been succeeded by nix and guix, theres reason you are
| increasingly seeing flake.nix in open source projects
| pantantrant wrote:
| Both aren't that reproducible, I keep running into sha256
| hash nondeterminism when upgrading packages on nixos from
| source after not updating for a while and guix may be better
| at this.
| Cloudef wrote:
| Are you using channels or flakes? Channels are non-
| deterministic as your nixpkgs essentially changes
| completely. Flakes always are deterministic as long as your
| binary cache is valid or the network hasn't bitrotten, or
| you managed to escape the nix sandbox somehow (or used
| --impure). Guix is much newer than nix so it has less pain
| points, but IIRC guix has no flakes equivalent which is
| kind of deal breaker to me personally.
|
| Of course nix also has one quite big issue, and that it is
| input addressed rather than content addressed, but its
| moving towards content addressed model which will reduce
| rebuilds and resource use https://nixos.wiki/wiki/Ca-
| derivations
| guytv wrote:
| Was a linux distro that's "source based" (i.e. no package
| manager) even a viable choice for real world server / desktop
| setup?
| BirAdam wrote:
| I am not aware of any Linux distribution that has no package
| manager (except for LFS, which isn't a distribution per se).
| Source-based systems typically have some kind of package
| manager. Gentoo: portage, GoboLinux: Compile, Slackware:
| pkgtools + sbo, Sourcer/SourceMage: sorcery, Lunar: lin,
| CRUX: pkgutils, and so on.
|
| Edit, additionally, yes. Such distributions are suitable for
| essentially any task for which any other distribution is
| suitable. The primary caution that I would offer anyone when
| venturing away from RHEL/Debian is how much you trust
| whatever organization to still be around in five years. If
| you're comfortable managing everything yourself, pick
| whatever; otherwise, it's "safest" to choose something that
| either contractually will still be around (RHEL), or is
| governed in a way that ensures some continuity (Debian).
| yazzku wrote:
| Well, that does seem a lot more sane than what exists today. What
| is the catch?
| LargoLasskhyfv wrote:
| The cargo-culting of the commons.
| pantantrant wrote:
| I tried it and I'd rather # make install to install a program
| and # make -n install | xargs rm -rf to uninstall a program.
| lproven wrote:
| This comment is the second time you've said this, so clearly,
| you think it's important.
|
| You also said it here:
| https://news.ycombinator.com/item?id=39533554
|
| I honestly don't see the connection.
|
| The idea of Gobo was to replace the cryptic Unix filesystem
| hierarchy with something clearer and more human-readable, and
| in so doing, replace a whole bunch of things that package
| managers do, making them almost unnecessary.
|
| Your point doesn't address this at all. You're talking about
| building from source instead of using a package manager, as
| far as I can see?
|
| But compiling from source still puts the resultant binaries
| somewhere in the existing Unix filesystem layout. It doesn't
| matter where the binaries come from. This isn't about where
| they come from -- it's about where they go.
| infotainment wrote:
| 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.
| sedatk wrote:
| s/Linux/Unix
|
| MacOS is better though.
| tomrod wrote:
| This is a joke, right? MacOS is all over the place?
| rufugee wrote:
| Agreed...I fail to see how macOS is an improvement. I mean,
| you have /Applications, but you also have /Library,
| ~/Library, and so on.
| pavel_lishin wrote:
| And /Applications, and /System/Applications, even though
| if you open them in Finder, you'll see the two combined.
| reactordev wrote:
| And ~/Applications, and /usr/bin, and /usr/local/bin, and
| homebrew, and Mac ports, tell me again how Mac is better?
| sedatk wrote:
| I just wasn't aware of these issues. Let me rephrase it
| then: MacOS' intentions were better. :)
| tomrod wrote:
| Eh............................. maybe? :)
| wraptile wrote:
| I'd say that MacOS is even worse which is impressive given
| that Apple has the absolute control of the platform and
| seemingly infinite resources and could have refactored the
| mess at any point.
| graemep wrote:
| I would guess the RoI of refactoring (especially on a
| consumer OS) is pretty low though.
|
| The average person never sees this stuff. Linux is widely
| used as a server OS and it still has taken a long time
| for new appraoches to get traction.
| jxdxbx wrote:
| I think the basic file system exposed to users in the
| Finder is pretty simple. /Applications, app bundles, etc.
|
| The Unix under the hood is just standard stuff and Apples
| hides away detritus like .plist files. And sandboxed apps
| have their own little stub filesystems too.
|
| Anyway I like the idea of GoboLinux a lot but kind of think
| GUIX, just abstracting it away might be the right approach.
| 29athrowaway wrote:
| macOS has pros and cons.
|
| The external monitor fiasco is a dealbreaker for me.
| nusl wrote:
| External monitor fiasco? Limitations on monitor count by
| CPU?
| gigatexal wrote:
| non pro versions of the M chip only support one external
| monitor... which is just silly
| nusl wrote:
| Yeah it's pretty silly. I guess Apple looked at their
| market and figured something out that met the majority of
| use cases, but not having that freedom is very
| frustrating.
| lproven wrote:
| I think it's instructive to consider the history of the
| M1 Macs here.
|
| In many ways they are essentially a sort of iPad with a
| keyboard and a USB port or 2 instead of an iPad or Apple
| Lightning connector.
|
| The GPU is very closely coupled to the CPU inside the
| SoC, as is the RAM and the soldered-in flash nonvolatile
| storage.
|
| You can't just boot them off USB. You can't just plug in
| extra drives. You can't add more memory or bigger SSDs
| without extremely elaborate desoldering of BGA parts.
|
| These are not "PCs with an Arm ISA chip". They're a whole
| computer, disks and all, in a single closed package,
| without all the buses and connectors of COTS x86 kit --
| which is _why_ they are so much faster.
| fragmede wrote:
| You can choose to complain that it so doesn't support it
| natively, or you can just buy the aftermarket hardware
| that _does_ support it and get on with your dual-head,
| non-pro life. Or upgrade your monitor to a single curved
| 5k ultra wide monitor, which is better than dual-head,
| imo.
| gigatexal wrote:
| What are these hardware hacks you suggest?
| lproven wrote:
| Add a USB display, broadly.
|
| https://www.macworld.com/article/675869/how-to-connect-
| two-o...
|
| https://apple.stackexchange.com/questions/463371/how-to-
| supp...
|
| DisplayLink is a standard for connecting GPUs over USB.
| It's slow but it kinda sorta works -- I have an ancient
| DisplayLink 7" USB display. Works great on Windows, and I
| could have a tiny second screen with a console prompt on
| it, or Task Manager or something, when working on the
| move on a laptop.
| fragmede wrote:
| over USB-3 it's a _lot_ better than "slow but it kinda
| sorta works", like drive a 4k display reasonably well
| kind of good.
| Gud wrote:
| FreeBSD doesn't have as big mess of a file system as many
| Linux distributions do, in my opinion.
| lproven wrote:
| It is 100% as complicated and guided by historical
| principles that are, 50 years later, almost totally
| arbitrary.
|
| I use both. I see no improvement whatsoever in the BSD
| approach.
| Gud wrote:
| It's a mess, but at least they have the decency to
| install 3rd party software under /usr/local
| vogon_laureate wrote:
| I like that userland is kept separate from base as much
| as possible, but agree it could be even better. I do
| think the BSDs have more coherency than Linux on the
| whole. Would be nice if we could simplify things down
| even further, but I suspect it just becomes one giant
| bikeshedding exercise, which is probably why it's easier
| to just cling on to hier
| https://man.freebsd.org/cgi/man.cgi?hier
| depingus wrote:
| The Windows Program Files style directories might make sense to
| you on a single user workstation. But on a multi-user server,
| its a security nightmare.
| spoiler wrote:
| I'm curious how bin is different from Program Files?
|
| Unless you mean stuff like configuration? I think user
| configuration would still reside somewhere under the user's
| home dir
| depingus wrote:
| 1. /bin (and /sbin) were intended for programs that needed
| to be on a small / partition before the larger /usr, etc.
| partitions were mounted. These days, it mostly serves as a
| standard location for key programs like /bin/sh, although
| the original intent may still be relevant for e.g.
| installations on small embedded devices.
|
| 2. /sbin, as distinct from /bin, is for system management
| programs (not normally used by ordinary users) needed
| before /usr is mounted.
|
| 3. /usr/bin is for distribution-managed normal user
| programs.
|
| 4. There is a /usr/sbin with the same relationship to
| /usr/bin as /sbin has to /bin.
|
| 5. /usr/local/bin is for normal user programs not managed
| by the distribution package manager, e.g. locally compiled
| packages. You should not install them into /usr/bin because
| future distribution upgrades may modify or delete them
| without warning.
|
| 6. /usr/local/sbin, as you can probably guess at this
| point, is to /usr/local/bin as /usr/sbin to /usr/bin.
|
| source: https://unix.stackexchange.com/a/8658
| gertop wrote:
| You said Program Files was a security nightmare compared
| to the Linux mess, that is what he was asking about. How
| is /bin safer than Program Files? None of the things you
| listed have any relevance to that question.
| spoiler wrote:
| I'm familiar with the intent behind the structure. I am
| mostly asking about the security implications you
| mentioned.
|
| One downside to Program Files type structure is that
| there's probably going to be some duplicate libraries
| lying around. However, as someone who's battled version
| skews due to clashing maintainer mindsets: that's been a
| much bigger pain in my ass than a few wasted kbs!
| soraminazuki wrote:
| Just to be clear, GoboLinux works nothing like Program
| Files. Packages still depend on each other and aren't
| self contained.
| em500 wrote:
| The main historical reason why some root level
| directories were moved to /usr (which was originally the
| user directory like today's /home) is that Thompson and
| Ritchie's first hard disk for the operating system was
| full. The rest seems to be mostly retcons and backronyms.
|
| source: http://lists.busybox.net/pipermail/busybox/2010-D
| ecember/074...
| bbanyc wrote:
| At one point I stumbled onto a document from circa 1990
| laying out a fairly coherent rationale - / was always a
| filesystem on the local machine while /usr could be a
| site-wide NFS share across many machines. Thus you got
| things like splitting off architecture-independent
| /usr/share from binary /usr/lib (because if you have a
| few different kinds of workstations, you'd want one /usr
| per architecture but /usr/share could be site-wide) and
| creating /sbin from binaries that had been in /etc from
| day one. Oh and they came up with /var (also possibly a
| network share) so /usr could be mounted read-only.
|
| An interesting idea, but I have to figure the majority of
| Unix sites kept /usr on the local machine like always.
| hnlmorg wrote:
| Those distinctions are more of a relic these days. If you
| take a look at a look at the inodes themselves you'll see
| that they're just symlinked back to /bin in a lot of
| Linux distros.
|
| BSDs still make the distinction but Linux moved on a
| while ago.
| lproven wrote:
| This is a relatively recent thing, called the Usr Merge.
|
| https://www.freedesktop.org/wiki/Software/systemd/TheCase
| For...
| hnlmorg wrote:
| It's a lot older than the edit date of that document.
| ArchLinux, for example, made the change somewhere in the
| region of 10 years ago.
|
| I can't find an exact date but here's a stack overflow
| discussion about the topic from 2016:
| https://unix.stackexchange.com/questions/266517/why-is-
| bin-a...
| michaelmrose wrote:
| More precisely /bin /sbin /usr/sbin all links pointing to
| /usr/bin yes but /usr/local is still of relevance and
| /opt although it really feels like opt (which doesn't
| have a great semantic meaning and would be better suited
| for something under /usr/local
|
| similarly /lib and /lib64 are pointers to /usr/lib
|
| It might be interesting in a vm to remove those symlinks
| and see what breaks. Presumably a lot.
| jauntywundrkind wrote:
| /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 wrote:
| > /srv
|
| ? What do you have in mind? I don't recall that being for
| applications
|
| https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.htm.
| ..
| soraminazuki wrote:
| Nix is becoming increasingly popular though. It's an
| improvement over the GoboLinux model, which requires manual
| maintenance of version directories (e.g., /Programs/Xorg/7.0).
| Nix does away with that by choosing the install path of
| packages based on the hash of their build recipes.
| lproven wrote:
| Making it automatable is not an unambiguous improvement,
| though.
|
| Losing human readability, when that was _the_ primary Gobo
| design goal, is a fearfully high price to pay, as I explained
| upthread:
|
| https://news.ycombinator.com/item?id=39536496
| soraminazuki wrote:
| The automatic naming of paths is a critical feature of Nix.
| Without it, Nix expressions can't exist. One of the most
| remarkable features of Nix is that package build recipes,
| or derivations, in Nix speak, can be treated like any other
| value in a programming language. It's possible to reuse and
| modify existing derivations in Nix expressions without
| causing conflicts. That's only possible because different
| derivations are assigned different paths. If Nix copied
| GoboLinux and treated packages with differing build recipes
| as the same, it would lose its declarative and reproducible
| nature.
|
| Also, there's no actual use case for Nix store paths with
| the hashes stripped out. The actual path can easily be
| derived from whatever is at the root of the dependency.
| Things like Nix expressions, the result symlink, the system
| environment in /run/sw/current-system, and PATH. Those are
| "human readable." From there, you can get the actual store
| paths. It doesn't matter that they're prefixed with a hash
| because they still have human readable names at the end,
| allowing you tell what they contain.
| trws wrote:
| I agree, but I'm happy to see that Nix, Guix, and the one I do
| the most work on Spack are starting to gain some traction since
| they all do basically this. Making it work is not always
| trivial though, and making it work _efficiently_ is harder.
| Only in the last few years have I felt like we're finally
| getting to the point where this is actually a maintainable
| model for the majority of software distribution. Here's hoping
| it gets the rest of the way!
| nerdponx wrote:
| Homebrew has been doing it for a long time. It's not known
| for being _fast_ , but without profiling the application I'm
| hesitant to blame the file layout.
| lproven wrote:
| They are, yes, but there is a very important core difference
| here that I think is not mentioned.
|
| The big cost about Nix/Guix that puts people off is that it
| eliminates a human-readable filesystem. The traditional
| layout is gone or empty, replaced by a tonne of folders under
| `/nix/` called stuff like `240-572-9837wfgjh234098672-_bash`
| and you have to just... *trust* that your path and so on will
| work and stuff will just get found somehow.
|
| You have to let go of navigating your own filesystem.
|
| That's just too much for a lot of people. The filesystem
| layout _is_ one of Unix 's defining characteristics.
|
| Whereas Gobo's goal is the opposite: yes, let us discard the
| traditional filesystem layout, but let's do it by making it
| _more_ human readable instead.
|
| You can work out where things are without knowing. There's
| better isolation. It's like semantic versioning, applied to
| the filesystem: a semantic filesystem layout, where folder
| names encapsulate versioning info and are _more_ meaningful
| than the old 1970s reduce-typing-effort-at-all-costs
| approach.
|
| Nix says ignore paths, ignore directories, you don't need
| them, we'll manage that for you.
|
| Gobo says forget traditional paths, here are some better ones
| that you will find easier and more useful.
|
| For me, that's an attractive proposition.
|
| In real life, it seems that _both_ were too much for most
| people.
|
| My suggestion would be: why not merge them? Try to bring the
| advantages of Gobo -- readable, meaningful directory paths --
| to a version of Nix.
|
| Instead of a flat directory tree with hashes, a consistent
| algorithm that categorises apps and puts them in a tree:
|
| /gonix/apps/gui/productivity/images/krita/5.1/
|
| /gonix/apps/console/shell/bash/5.2/
|
| /gonix/apps/programming/compilers/fpc/3.1/
|
| /gonix/libraries/c/glibc/2.39
|
| /gonix/apps/console/editors/vim/9.1
|
| I am totally making these up, you understand, they're merely
| illustrative examples.
| dannymi wrote:
| >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.
|
| Not really trust. Nix and Guix are not magic.
|
| You can still use ldd to figure out what (now exact!)
| library anything is gonna use. Guix and Nix use the rpath
| feature.
|
| And your profile directory in Guix is a normal directory
| called $HOME/.guix-profile . Currently, it has "bin" and
| "share" and "sbin" and "libexec" and "lib" and so on in
| there. That is what the end user uses. Entries in those do
| link to /gnu/store/xyz/bin/xyz (using regular symlinks),
| yes.
|
| >Instead of a flat directory tree with hashes, a consistent
| algorithm that categorises apps and puts them in a tree:
|
| One hash represents all the dependencies of that package,
| too.
|
| One directory name in Guix's /gnu/store encodes both the
| direct sources and all the dependencies, all the way up to
| a bootstrap root (the latter of about 250 Bytes of binary).
| If any of the dependencies of bash changes, the hash will
| change, too. That also means that you will have multiple
| /gnu/store/*-bash-5.1.16 in there in a normal system.
|
| But in your proposed case, you'd have to introduce some
| magical things which figure out and STORE the dependencies
| somehow differently in the background. Guix doesn't do
| that. It stores that in the file system, the end (as in
| directly in the file system, not as in "the system database
| blob is in file /foo"). No magical extra store.
|
| That said, it would be possible to only change the guix
| profile layout to be what you suggest, and then still have
| symlinks to /gnu/store/<hash>-xyz in there. Probably like 5
| h of work, and end user programs most likely will work on
| the first try. Patches welcome.
|
| See guix/profiles.scm for what creates the profile. %user-
| profile-directory is $HOME/.guix-profile . profile-
| derivation is the function you want to change.
|
| You can also use guix on top of whatever other Linux
| distribution and try it out like that. The package manager
| (which makes the profiles) also supports containers--so you
| can safely try out whether your change works.
| lproven wrote:
| > Not really trust. Nix and Guix are not magic.
|
| Did I say they were? I didn't mean to.
|
| I've researched Nix. I've written about it. Nix people
| contacted me to thank me for doing so.
|
| https://www.theregister.com/2022/12/13/nixos_2211_raccoon
| /
|
| https://www.theregister.com/2021/12/03/nixos_linux_os_des
| ign...
|
| The reader comments I get is that a non-human-readable
| filesytem (or only marginally so, by ignoring the hashes
| and looking in the new single-level hierarchy for
| recognisable fragments of names) is just too high.
|
| They don't have enough of a problem with how things are
| to choose a whole new method with this very high price.
|
| (Which is the same reason Plan 9 flopped, as I have both
| written about and spoken publicly at FOSDEM about this
| month.)
|
| https://fosdem.org/2024/schedule/event/fosdem-2024-3095-o
| ne-...
|
| https://www.theregister.com/2024/02/21/successor_to_unix_
| pla...
|
| > You can still use ldd
|
| I submit that this is rocket science to the majority of
| Linux users and is not a sufficient answer.
|
| > And your profile directory in Guix is a normal
| directory
|
| I confess I've not looked at Guix yet.
|
| But saying that, I don't think having a normal homedir
| isolated in a partition full of alien weirdness is
| enough, TBH.
|
| > One hash represents all the dependencies of that
| package, too.
|
| I am not sure that _I_ understand what this means, but is
| there any reason this could not be combined with my
| proposal?
|
| > That said, it would be possible to only change the guix
| profile layout to be what you suggest
|
| Interesting. Suboptimal but interesting. Would make it a
| little less intimidating, I suspect.
|
| > You can also use guix on top of whatever other Linux
| distribution
|
| Again, as I said, for most of us, it's a very cognitively
| expensive extra step to solve a problem we simply don't
| have.
| dgfitz wrote:
| > I submit that this is rocket science to the majority of
| Linux users and is not a sufficient answer.
|
| That can't be true, can it? I guess it depends on the
| definition of "users."
| lproven wrote:
| It absolutely 100% can be true.
|
| As an example: Windows Services for Linux 2 used a
| special init daemon to interact with the host OS.
|
| That meant no systemd. That meant that the `systemctl`
| program wasn't there.
|
| This baffled legions, armies, of wannabe sysadmins.
|
| https://stackoverflow.com/questions/55579342/why-systemd-
| is-...
|
| https://superuser.com/questions/1785697/systemd-in-wsl-
| on-wi...
|
| https://github.com/microsoft/WSL/issues/9477
|
| https://askubuntu.com/questions/1132230/unable-to-run-
| any-sy...
|
| People on the whole have _no idea_ how this stuff works,
| and they just copy magic incantations from StackOverflow
| to get stuff to happen. If that doesn 't work, then this
| OS is broken. The end.
|
| For these guys, WSL was broken.
|
| Result:
|
| MS hired Lennart Poettering.
|
| https://www.theregister.com/2022/07/07/lennart_poettering
| _re...
|
| He "fixed" it. Systemd now works in WSL2. All those
| guides for noobs now work. Everyone is happy.
|
| In a world where tools like Flatpak and Snap are
| proliferating and it's driving deep divisions between
| Linux distros, if you think the average person struggling
| with Linux is going to use `ldd` to work out where the
| dependencies for something live, I'm afraid you are a
| deep guru who lives on a different plane of existence.
|
| We now have widely-used packaging systems which simply
| embed an apps entire dependency tree into a package to
| avoid people having to work out the difference between
| `apt` and `rpm`. Thousands of terabytes of disk are being
| burned to make this stuff go away.
|
| Yes, this is too hard. _Way_ too hard.
| dgfitz wrote:
| You make a compelling argument.
|
| > I'm afraid you are a deep guru who lives on a different
| plane of existence.
|
| I'll take that as an amusing tip of the cap, I hope that
| is how it was intended. I don't know if I consider myself
| a deep guru, but if something doesn't run when I expect
| it to, I do tend to reach for ldd pretty quickly.
| allan-a wrote:
| > 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
|
| This is a nice illustrative example that works well when
| the only difference between software packages is semantic
| versions. The reality is that there can be many variants of
| packages and using something like a hash of package inputs
| is very practical. Take for example a library called GDAL,
| which has an insane amount of configure flags. It is quite
| common for scientific software to be tuned and package
| maintainers cannot supply a one-size-fits-all solution.
| lproven wrote:
| OK. For clarity, I am not anti-hash or anything.
|
| For instance, we could still embed the hash in the
| directory name, in much the same way that many Linux
| programs use build numbers.
|
| /gonix/apps/console/editors/vim/9.1~246dea34451dbdda21
|
| The core things that I'm getting at here are:
|
| 1. Put the human-readable part _first_ because humans see
| that first.
|
| 2. Retain hierarchical layouts. For humans this makes
| things more manageable and accessible, while for
| programs, as long as it's computationally-parseable the
| impact is negligible.
|
| 3. Lean in to the hierarchy. If it's necessary to
| duplicate slightly different versions of dependencies for
| different programs, then put them inside that program's
| hierarchy. That's one of its reasons for existing.
|
| 4. Embed the hash anywhere a simple regex can find it, no
| problem; tab-completion can sort that out.
|
| All I am trying to suggest is that a
| Nix/Guix/successor/replacement type tool could focus more
| on ordinary joes who find it hard to remember the
| difference between `/bin` and `/usr/bin` as it is, and
| make stuff human-readable _first_ and machine-readable
| _second_.
| tgamblin wrote:
| FWIW this is what Spack _does_ , and it uses a store
| layout like nix/guix. here are some chunks of the spack
| install tree path. All you _really_ need is the hash, but
| we provide a bit more. $ spack find -p
| ... cmake@3.27.9
| ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cma
| ke-3.27.9-x6g5fl54kgt4nqmgnajrtfycivokap2p
| cmake@3.27.9 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x4bznyafesvpdbp
| lqhmnwwvy2zj5fdzs coreutils@9.3
| ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cor
| eutils-9.3-vlwyg7d3ysxfoom3erl6ai4yy7fuf2jn
| curl@8.4.0 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-
| clang-15.0.0/curl-8.4.0-zjz6twa32vxnevika34kkrxjwo27z6vj
| curl@8.6.0 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-
| clang-15.0.0/curl-8.6.0-da5tk7aqaqp6zdligjmahzwohzut65qc
| diffutils@3.9 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-clang-15.0.0/diffutils-3.9-lau4vo7zlsktmb
| hyn3pf3x72nxhihsaq double-conversion@3.3.0
| ~/spack/opt/spack/darwin-sonoma-m1/apple-
| clang-15.0.0/double-
| conversion-3.3.0-zihvj7vzedapjprk76awr7qied3k45n6
| emacs@29.2 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-
| clang-15.0.0/emacs-29.2-x5v4wdhp4vfsuxquadackqckdvxrppwi
| expat@2.5.0 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-
| clang-15.0.0/expat-2.5.0-hmdysf6hcrzuhcxu7fkecpvskzxecgps
| findutils@4.9.0 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-clang-15.0.0/findutils-4.9.0-atynmdjhdjpb
| 2ipurlk7cxtdep77m7mu fish@3.6.1
| ~/spack/opt/spack/darwin-sonoma-m1/apple-
| clang-15.0.0/fish-3.6.1-sg3ws3rmbfgdfyhvjnhd5agepguj4yf2
| flex@2.6.3 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-
| clang-15.0.0/flex-2.6.3-quw6ammnjxfutqtqcifvjfsp5nyqpeab
| freetype@2.11.1 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-clang-15.0.0/freetype-2.11.1-ue2ofutkkawt
| zvcl47pqts4lasm5lgha gawk@5.2.2
| ~/spack/opt/spack/darwin-sonoma-m1/apple-
| clang-15.0.0/gawk-5.2.2-jld7vb24rls64nbzkyxcp4alluyedfzv
| gdbm@1.23 ~/spack/opt/spack/darwin-
| sonoma-m1/apple-
| clang-15.0.0/gdbm-1.23-amtpuskagocirjhffgqrjas3bfbnzixi
| ...
|
| You can also customize the install tree paths[1] with
| format strings; the default is: config:
| install_tree: root: $spack/opt/spack
| projections: all: "{architecture}/{compiler
| .name}-{compiler.version}/{name}-{version}-{hash}"
|
| One reason `nix` uses `/nix/HASH` is because it results
| in shorter paths and avoids issues with long paths. We
| use sbang[2] to avoid the most common one -- that long
| shebangs don't work on some OS's (notably, most linux
| distros).
|
| [1] https://spack.readthedocs.io/en/latest/config_yaml.ht
| ml#conf...
|
| [2] https://github.com/spack/sbang
| Lurkki wrote:
| With Nix /run/current-system/sw/ is basically the /usr of
| mutable FHS distros, with the difference that it's all
| read-only symlinks. So you can still look at the layout of
| your active system.
| silisili wrote:
| I think /home and /tmp are the only ones that consistently make
| any sense currently. The rest seems a grab bag of putting
| whatever you want wherever you want.
| palata wrote:
| Do you think this reflects the reality of Linux distros, or
| does that reflect your understanding of them? Would you say
| that `/usr/bin` or `/usr/lib` are completely random and no
| two distros use those paths?
| silisili wrote:
| I've been using Linux for a loooong time. Sure, you notice
| trends, but it's still not clear cut what goes where. On my
| current system, /lib and /usr/lib both link to /lib64. So I
| guess the distinction between the three wasn't clear to
| someone else, either. Some configs are in /etc, some are in
| /var. Some third party stuff puts bins in /opt.
| mmh0000 wrote:
| There is a standard that most Linux distributions follow, the
| FHS.
|
| https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar.
| ..
| lproven wrote:
| Yes, it pretty much is.
|
| The Unix filesystem layout was bodged together on the fly as
| Dennis and Ken got more disk drives to attach to their
| elderly DEC PDP computers.
|
| http://lists.busybox.net/pipermail/busybox/2010-December/074.
| ..
| matheusmoreira wrote:
| Those ideas certainly inspired me. GoboLinux is the first
| project I saw that showed me that on Linux you actually can do
| whatever you want.
| hsbauauvhabzb wrote:
| Unless you want Bluetooth audio without systemd, then you're
| SOL
| freedomben wrote:
| Only if you want somebody else to do it for you. Everything
| is open and hackable on Linux so you can make it work
| without systemd. Thus far this hasn't been a priority for
| others, but that doesn't mean it can't be done
| matheusmoreira wrote:
| Not really. There is nothing about systemd that makes
| bluetooth or audio its exclusive purview. You just have to
| put in the effort to make it happen. Gotta figure out how
| they did it and do it too.
|
| It's not gonna happen without _somebody_ making it happen.
| Be somebody. Systemd is influential because the people
| making it often are those somebodies but the fact is
| _anyone_ can be that somebody, you don 't need their
| blessing or that of some standards body to make anything.
|
| I went as far as getting rid of _libc_. Made a lisp that
| runs directly on top of Linux using nothing but system
| calls. It can do anything other software can do: I run
| strace on a program, my lisp can do what it does if it just
| replicates those system calls, doesn 't matter if it's
| simple I/O or mounting disks. I want to eventually boot
| Linux directly into it.
| michaelmrose wrote:
| void linux which opted for runit over systemd has bluetooth
| configurable via bluetoothctl or blueman-applet so seems
| this is a thing. That said bluetooth is kind of flaky.
|
| You may get a better result with a device that has a usb
| dongle. Logitech models reportedly work. The Corsair unit I
| just bought works well for instance.
|
| Leitner works despite having crap audio over usb.
| Gormo wrote:
| > 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 wrote:
| Unless those principles are merely the solution to problems
| that don't exist anymore like /usr separation ?
| Gormo wrote:
| Yes; the presumed obsolescence of a problem does not imply
| that remaining elements of its solution are "a mess".
| op00to wrote:
| I did this back in ~2004 when I was hosting diskless
| workstations. It was a major pita to maintain on my own!
| meatjuice wrote:
| I hope it isn't just a re-invention of NixOS (or worse).
| ufo wrote:
| Actually predates NixOS, by a couple of months.
| transfire wrote:
| I don't think NixOS was actually usable back then either. It
| was still more an idea and few people had heard of it.
| yjftsjthsd-h wrote:
| Neither is a re-invention of the other; they happen to do
| things that are partially similar, but also totally different.
| NixOS uses the /nix/store structure to allow it to pin
| everything to everything in service of its goal of absolute
| reproducibility/determinism. GoboLinux restructured the
| filesystem in order to be "nicer" (very loosely speaking). The
| result is that (IMO) nix is more _technically_ elegant, and
| Gobo is a lot friendlier to work with. (I type this from a
| NixOS machine and with love in my heart for both)
| Qwertious wrote:
| NixOS and GoboLinux were both started in 2003; if they haven't
| compared notes by now then they never will.
| lproven wrote:
| Linux is what made Unix into a mainstream consumer OS.
|
| It came along 22 years after Unix itself.
|
| It's never too late.
|
| Remember that Windows itself was a flop until version 3, and
| that -- Windows 3.0, in 1990 -- was the little snowball
| rolling down a mountain that brought multitasking multimedia
| networked GUI computers to the mainstream.
|
| And thereby created the mainstream marketplace of x86-32
| computers: the substrate that allowed Linux to grow.
|
| (DOS made so little use of the 80386 that an 80286 PC was
| adequate, and after 5 years the 386 made little inroads into
| the mass market -- they were too expensive, even after the
| 1989 budget-model 80386, the 386SX. But Windows 3 ran much
| better on a 386 than a 286, and soon after Windows came
| along, the 286 was dead.)
| tdoggette wrote:
| > Through a mapping of traditional paths into their GoboLinux
| counterparts, we transparently retain compatibility with the Unix
| legacy. [...] There is no rocket science to this: /bin is a link
| to /System/Index/bin. And as a matter of fact, so is /usr/bin.
| And /usr/sbin... all "binaries" directories map to the same
| place. Amusingly, this makes us even more compatible than some
| more standard-looking distributions. In GoboLinux, all standard
| paths work for all files, while other distros may struggle with
| incompatibilites such as scripts breaking when they refer to
| /usr/bin/foo when the file is actually in /usr/local/bin/foo.
| russfink wrote:
| What if two bin files have the same name but are different? What
| does /System/Index/bin do with that? E.g., "uninstall.sh".
| depingus wrote:
| And why would they mix packaged managed binaries with local
| user compiled binaries.
| ufo wrote:
| That way users can get all the package-manager goodness for
| stuff they compiled locally. And also because Gobolinux lets
| people install more than one version of the same package.
| soraminazuki wrote:
| You've fundamentally misunderstood how GoboLinux works. The
| _whole point_ of these kind of distros is to avoid mixing
| packages into a single common directory. Each version of each
| software are installed in _separate_ directories in
| /Programs so that they won't cause conflicts with each other.
| Then for convenience, a single version of each software will
| be symlinked into /System/Index.
|
| This is way more meaningful than the /bin & /usr/bin split
| that distros are increasingly moving away from because
| multiple versions of the same software or forks can coexist
| on the same system. This model also makes /usr/local
| unnecessary.
| depingus wrote:
| Thanks. I appreciate the correction.
| lucasvr_br wrote:
| The dependency map of the program you're running states which
| one takes precedence and gets mapped (overlay-mounted, to be
| more precise) to /System/Index/bin.
|
| So, a dependency map that contains "Foo = 1.0" would cause
| Foo/1.0/bin/uninstall.sh to be the one mapped to
| /System/Index/bin.
| depingus wrote:
| Someone decided to shoehorn Windows Program Files into Linux?
| Yikes.
|
| Jokes aside, this completely ignores the fact that there is a
| reason for /usr/bin and /usr/local/bin and /etc and the sbin
| directories. A lot of it has to do with permissions. If you've
| ever been a member of a multi-user server you might understand.
|
| I will grant you tho; a lot of people never bother learning and
| just shove binaries where ever they can get it to work first.
|
| In case anyone wants to know. Here is a good explanation:
|
| https://unix.stackexchange.com/a/8658
| throwanem wrote:
| Nothing in that answer from 2011 even mentions permissions, and
| most of what it does discuss was pretty outdated even then.
| depingus wrote:
| I thought it was implied that bin vs sbin is a permissions
| thing. What is outdated in that link? I use Fedora 39 Atomic
| and, as far as I can tell, even it follows these conventions
| (and even added /var/userlocal for themselves).
| throwanem wrote:
| Strictly, the difference between /bin and /sbin versus
| their siblings in /usr has to do with what you can fit on
| the RK05 disk pack that the system boots from. If it comes
| up too broken to mount the DECtape (or if you're lucky and
| your institution's not cheap, the second RK05) where /usr
| lives, you'd better be able to fix it with whatever's in /,
| because until you do that's all you've got. Hence keeping
| some binaries there, but not too many; your root volume is
| only a couple megabytes large.
|
| Too, if /usr is on tape, that's a lot slower in random
| access than even a contemporary disk, which matters because
| you also don't have enough core memory to avoid paging
| binaries - so even things you might not need to fix a
| broken system still may be worth putting in /bin if you can
| afford the space, if they're frequently enough used to be
| worth the speedup.
|
| I believe the difference between /bin and /sbin per se had
| to do with dynamic versus static linking, with /sbin
| reserved for statically linked versions of binaries
| critical to bring up or repair a system - after all, if
| something in /bin is linked against libraries in /usr/lib,
| then you still won't be using it if you can't mount /usr.
|
| I'm not so sure about that part, though; it's been a very
| long time since any of this mattered at all to how Unix is
| operated in practice, and it is really only of interest to
| those curious about how the constraints of early hardware
| informed the evolution of historical filesystem layout
| conventions. Even _I 'm_ not old enough to have actually
| worked with such systems, although I don't miss it by much,
| and am certainly old enough to have studied a great deal
| more about them than some.
|
| _edit:_ If you 're really interested in the topic, then
| you should certainly spend some time with Rob Landley's
| collection of historical documents [1], which Google is
| apparently no longer competent to find based on their
| content - some of this I was actually looking for in the
| course of composing this reply, and only found it when I
| happened to search the name on a mailing list message
| linked in another reply here. So much for "information
| wants to be free" - apparently on today's Internet there's
| no money left in making information able to be _found._
|
| [1] https://landley.net/history/mirror/index.html
| ufo wrote:
| Sorry, I'm not sure if I get your point. Separating /usr and
| /usr/local doesn't have to do with permissions; it's just that
| package manager wouldn't be able to deal with users installing
| files into /usr and overwriting the package manager's stuff.
| The whole point of Gobolinux is to avoid this sort of problem.
| Because each package gets its own directory instead of all
| being stored in a central location, there's no risk of one
| package stepping on another package's toes, and it's also
| possible to install multiple versions of the same package.
| depingus wrote:
| Yes, /usr/bin and /usr/local/bin is for the package manager
| vs user compiled. The link I posted mentioned it. But
| separating bin from sbin is more of a permissions thing. I
| suppose you could set permissions individually on each
| Program folder, but that seems like a pain. The multiple
| versions thing is pretty nice tho.
| ufo wrote:
| In all the distros I know, bin and sbin have the same
| permissions.
| usr1106 wrote:
| But sbin is not always in an ordinary user's PATH. They
| were permitted to run something, but it does not run
| without an absolute path.
|
| (I don't remember in which distro it's in PATH and in
| which it isn't.)
| ufo wrote:
| That's just for convenience though. Users can edit their
| own PATH as they see fit.
| yjftsjthsd-h wrote:
| > Jokes aside, this completely ignores the fact that there is a
| reason for /usr/bin and /usr/local/bin and /etc and the sbin
| directories. A lot of it has to do with permissions. If you've
| ever been a member of a multi-user server you might understand.
|
| I've _administered_ multi-user servers and I can only guess at
| what you mean. Like... I 've seen distros that default non-
| admin users to not having sbin directories in their PATH, but
| even then it's not like that's a _security_ thing, it just
| makes your path a little cleaner. What security benefit do you
| see to the different directories?
|
| (In fairness, I can see _non-security_ reasons to split things
| up - the traditional reason is that /bin is local, /usr is on
| NFS and shared between every machine in the lab, and /usr/local
| is non-packaged software built from source. But none of that is
| a security argument.)
| naruhodo wrote:
| Someone else linked this[1] as well. You might benefit from
| reading it.
|
| [1] https://gobolinux.org/doc/articles/clueless.html "I am not
| clueless"
| krick wrote:
| This is such an obvious solution. Kinda crazy that the whole
| world uses Debian and such, while this exists since 2002 (it's
| older than Ubuntu). I mean, yeah, I didn't switch to NixOS
| despite it being "obviously better" too, but it feels like there
| must have been much less friction 22 years ago to adopt better
| design. (Maybe capitalized directory names are to blame, they are
| disgusting.)
| docandrew wrote:
| I seem to recall that Gobo turned on case-insensitive shell
| tab-completions by default so in practice it was a non-issue.
| segfaltnh wrote:
| The real issue is case sensitive file systems. When do you
| actually want two files with the same name in different cases?
| That's not a human-centric design choice, Mac and Windows got
| this one right.
| mirpa wrote:
| You can go around case sensitivity in user facing
| applications by using fuzzy search. Even command line tools
| can use Tab for autocompletion. Case for case sensitivity is
| not in ability to have two files which differ in case, but
| simplicity of underlying code that has to deal with paths.
| pantantrant wrote:
| I've tried GoboLinux, I think it's better to just # make install
| and to uninstall, # make -n install | xargs rm -rf or Solus
| Linux's package manager. (Currently using CachyOS on a comfy HP
| Envy Move with a comfy Lenovo Wireless Keyboard and Mouse combo,
| my shameless plug.)
| JNRowe wrote:
| For people -- admittedly, like me -- who have a strong knee-jerk
| reaction to GoboLinux's design the _twenty year old_ "I am not
| clueless"1 document contains a fair amount of interesting
| background and reasoning on the concepts. I don't think I've
| overcome the reaction entirely, but it isn't so strong anymore ;)
|
| 1 https://gobolinux.org/doc/articles/clueless.html
| Sammi wrote:
| The writing has some of the same feel as the writing for HTMX
| or Tailwind.
|
| Paraphrasing: "Yes we know this is different. Yes it is very
| simple. You may not be used to it, but it is easier to
| understand and work with. You don't have to use this. We like
| this and we are happy."
| Hackbraten wrote:
| From the linked article:
|
| > make all programs relocatable - I would love to see that, but
| that would either mean: rewrite every app in the world to use
| `libprefix`
|
| I'm curious about what they mean by `libprefix`. A web search
| doesn't turn up any useful results.
| lproven wrote:
| https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LI.
| ..
|
| ...?
| saghm wrote:
| I can't help but wonder how much of the kneejerk reaction is
| due to "cosmetic" parts of the design rather than the
| functional parts. For example, I notice that a lot of my
| initial reaction is based on the capitalization; "Programs"
| with a capital "P" (probably unfairly) evokes an emotional
| response due to reminding me of the Windows "Program Files"
| naming, and (perhaps slightly more fairly) I'd probably find it
| mildly infuriating to type "LibX11" rather than "libx11". Even
| though Linux filesystems are generally case insensitive, I
| imagine that package names would still be unique across casing,
| and it seems pretty likely that a Linux distribution focused on
| making the filesystem hierarchy more user-friendly wouldn't end
| up putting a second directory on the root that differs only by
| case. As silly as it is to verbalize, I genuinely think my
| initial reaction would be less strong if the naming convention
| examples were "/packages/libx11/1.6.9" and
| "/packages/gcc/9.2.0", and I don't think the benefits would be
| diminished at all by naming things like this.
| grodriguez100 wrote:
| > Even though Linux filesystems are generally case
| insensitive
|
| Linux filesystems are generally case sensitive.
| saghm wrote:
| Oops, you're right, I always mix up the terms for those; I
| did mean sensitive though, which I hope was possible to
| figure out from what I said after.
| cassepipe wrote:
| I didn't even notice. My brain went directly for the
| correct meaning.
| ElijahLynn wrote:
| It would be helpful to update your comment.
| a_gnostic wrote:
| Your brain is case insensiteve :)
| nmz wrote:
| It's a positive in my view, sorting by characters actually
| yields a difference between what is a directory and isn't.
| donatj wrote:
| I am honestly kind of shocked every time I see Gobo come up on
| here that it's still going. I played with it back in highschool
| 20+ years ago and thought it was an interesting oddity.
|
| It's frankly kind of inspiring that they've stuck with it.
| solarized wrote:
| Hey, just a heads up: capitalizing the first directory's name?
| Not cool. It feels like extra work when navigating paths, you
| know? Pressing shift along with a letter or number every time?
| Total drag, especially for everyday command line use.
| pxc wrote:
| I like it as a convention that indicates at a glance whether
| something is a directory or just a regular file. Also, any
| shell can do case-insensitive completion for you. Fish does it
| out of the box.
| solarized wrote:
| I mean, fish isn't the only shell out there. Why bother
| installing another shell instead of just sticking with bash
| for normal navigation? Ah, sorry, classic distro discussion.
| Everyone has the freedom to choose whatever distros they
| prefer.
| gattilorenz wrote:
| The message you replied to said "any shell can do case-
| insensitive completion for you", not that you should use
| fish.
|
| Whether literally _any_ shell can, I don 't know. With zsh,
| bash and tcsh it is certainly possible.
| yjftsjthsd-h wrote:
| I think fish was just an example that does it by default;
| if you want bash to do the same, just set
| set completion-ignore-case on
|
| in your .inputrc
| ufo wrote:
| The capital letters are to avoid clashing with FSH/legacy
| directories.
| vvanpo wrote:
| From the article linked above:
|
| > To that, I can only respond that, in a properly configured
| shell like the one that comes by default with GoboLinux, typing
| /Programs takes the exact same number of keystrokes as typing
| /usr: slash, lowercase p, Tab.
| justsomehnguy wrote:
| > Not cool. It feels like extra work when navigating paths, you
| know? Pressing shift along with a letter or number every time?
|
| You know why it never bothers me when I navigate in PowerShell
| (or cmd.exe for that matter)?
|
| Because the shell is _helpful_ for me and don 't try to force
| me to conserve precious ticks and memory of PDP-11 lacking any
| usability.
|
| It's always amusing to hear 'case sensitivity rUl3z!' fans who
| totally miss what it's just the result of the constraints of
| the original systems. It's not a feature.
|
| More so, it's explicitly addressed:
|
| >> To that, I can only respond that, _in a properly configured
| shell_ like the one that comes by default with GoboLinux,
| typing /Programs takes the exact same number of keystrokes as
| typing /usr: slash, lowercase p, Tab.
|
| >> https://gobolinux.org/doc/articles/clueless.html
|
| Just 'set completion-ignore-case On' and have your life
| immensively better. Why? Because you now would need one less
| Shift keystroke per every filename starting with capitalised
| letter _even if you don 't use GoboLinux_.
|
| Or continue like it's still 1977, why not, your VT100, your
| rules.
|
| EDIT: oh, noticed this later:
|
| > Why bother installing another shell instead of just sticking
| with bash for normal navigation?
|
| Yes, you don't even bother _to know your own shell_.
| ivanjermakov wrote:
| Not cool. I get Windows vibes from it.
| fodkodrasz wrote:
| Hey poliverzum, how you doing?
|
| (He was a local GoboLinux fan, but went off the map. Hope he's
| fine.)
| sylware wrote:
| Some very bad closed source applications will expect way to much
| from the user system: the steam client, where your get bash
| scripts instead of sh scripts, a hard debian/ubuntu file layout
| with the linux mount userland container requirement (windows
| 10?), and GNU-only niche options of many commands. Not to mention
| many 32bits libraries. It seems they are still in control of
| their ABI though (probably using the .symver directive of
| binutils gas).
|
| That to say the least, the current mess is being forced down or
| throat by steam, unless your distros don't play video games.
| transfire wrote:
| I miss you, Gobo.
| Leynos wrote:
| Sounds like PC-BSD... Er... I mean TrueOS
| edpichler wrote:
| This project can potentially reduce a lot of our cognitive load.
| I hope it succeeds.
|
| edit: Now I see it's a 20-year project.
| froh wrote:
| a slow rolling 20 year old project
|
| https://github.com/gobolinux/Recipes/commits/master/
| zzbn00 wrote:
| The documentation mentions GNU stow:
|
| https://www.gnu.org/software/stow/manual/stow.html
|
| This was very useful in early 2000s running shared linux machines
| with a diverse set of software for scientific applications.
| toastal wrote:
| What makes folks thing landing pages like this should require
| JavaScript? Nothing here would _need_ the dynamic capabilities of
| a scripting language, yet accessibility & SEO are hurt in the
| process.
| riddley wrote:
| There's an old adage about hammers and nails... I forget the
| details.
| soerxpso wrote:
| You can read the 20 lines of JS that they use. It's for drawing
| the parallax lines in the background and for the fade-in
| effect, which can't be accomplished with plain CSS. There's no
| detriment to SEO or to accessibility, unless the specific
| disability you have is that you're allergic to JavaScript.
| SomeoneFromCA wrote:
| Is not this like it is done in Android?
| 0dayz wrote:
| What I would love gobolinux to do is similar to nix which is to
| make it possible for any distro to get gobolinux like folder
| structure.
| lproven wrote:
| You can run Gobo inside your /home directory if you want.
|
| https://gobolinux.org/index.php?lang=tr_TR&page=rootless
| nmz wrote:
| This is absolutely perfect for sdf/tilde then.
| account-5 wrote:
| Can someone way cleverer than me explain why, or if, this is
| better than things like snap/flatpaks as well as distros like
| nixos?
|
| This seems, at face value without a deep understanding, to be the
| simplest way to do it. Again the caveat is my lack of knowledge.
| akvadrako wrote:
| Do you mean just putting each app in it's own folder? That just
| isn't enough for isolation and could be massively wasteful,
| depending how far you take it.
|
| Flatpak and NixOS are more complex because it's worth it. For
| example, they don't duplicate exact versions of dependencies on
| disk.
| palata wrote:
| > For example, they don't duplicate exact versions of
| dependencies on disk.
|
| Doesn't feel like GoboLinux would either, does it?
| Gormo wrote:
| Flatpak's complexity is also a product of trying to function
| as a single solution to two different problems. Runtime
| isolation and packaging/distribution are different things,
| and there is no compelling reason for them to be conflated
| together. How you sandbox the execution of your applications
| should not be dependent on any particular filesystem layout
| or package format, nor vice versa.
|
| FreeBSD does a good job with this: applications are installed
| into a standard Unix filesystem with conventional packages
| and the ports collection. Isolation is then implemented via
| jails.
|
| The Linux equivalent of using standalone isolation layers,
| like firejail, on top of standard distro packaging, is far
| superior to Flatpak.
| nmz wrote:
| You are aware that windows has each app on its own folder in
| program\ files and its completely fine. ext4 supports an
| insane amount of files, so much so that unless you're doing
| something really out there, you're never going to reach the
| limit.
| charcircuit wrote:
| snaps and flatpaks are focused more distribution and are
| "sandboxed" (quotes because their are security issues with
| them). NixOS breaks compatibility with existing programs unlike
| gobo, but NixOS's package repository is exponentially better
| maintained where gobo's is incomplete and years out of date.
|
| All of these are all still behind how Android stores apps. On
| Android each application can be distributed using a single file
| that is easy to distribute. Each application is properly
| sandboxed. Each application gets its own directory. And
| something all of the other things mentioned here are missing,
| each application gets its own subdirectories in the app's
| directory for storing its state (there are different ones for
| each user).
| account-5 wrote:
| This makes sense. If there's one thing windows can do better
| than Linux it's portable applications. The vast majority of
| my daily drivers on windows can run from my memory stick on
| any system without installation. Though this is not the same
| as what you're taking about.
| 1970-01-01 wrote:
| Never mentioned is how this is a Windows 95 concept. They really
| should do this, I don't give bonus points for ignorance.
|
| https://en.wikipedia.org/wiki/Program_Files#History
| aidenn0 wrote:
| They cite NeXT (which predates Win95).
| 1970-01-01 wrote:
| https://wiki.gobolinux.org/Overview/The-GoboLinux-
| Way/index....
|
| Yes, they cite that among other UNIX like OSes while
| completely ignoring the most successful implementation of
| their idea, (by several orders of magnitude) Windows. I don't
| find that cute, I find it ignorant.
| myself248 wrote:
| It's so sensible it makes me weep. Deduplicating multiple copies
| of a library can be done by the filesystem if you consider it
| really necessary, it is after all a file-level redundancy and
| should be solved at that level.
| hsnewman wrote:
| This is reminiscent of the IBM AS/400 filesystem, my question is
| how resiliant is the filesystem?
| Winse wrote:
| This reminds me a little of the original idea of a new winfs for
| longhorn from Microsoft except this seems like something that may
| become useful someday. Some interesting ideas...though shared
| object dependencies may be a problem...though I didn't take a
| very close look at they handle this. Perhaps all shared resources
| go into a specific location? Or perhaps everything is statically
| compiled? dunno ... anyway there is a reason behind our lovely
| file system mess. Kind of reminds me of
| https://www.joelonsoftware.com/2000/04/06/things-you-should-...
| though in open source land you definitely can take a risk like
| this.
| vrinsd wrote:
| The GoboLinux guys really did "intelligently" come up with a
| filesystem layout that's humanly understandable. I personally
| find the old-school UNIX conventions we use fairly arcane given
| we no longer have 8.3 type limits imposed by lack of storage
| space, >1GB file-size issues, etc.
|
| I ran GoboLinux 012-015 for a few years on a server that I used
| for hosting version control software and for the most part it
| kicked ass.
|
| What was a bit of a stumbling point is that if you needed a
| package that didn't readily exist, you'd have to create the
| recipe. The language for creating GoboLinux recipes is perfectly
| understandable, the issue was often one package would depend on a
| dozen or a few dozen libraries and you'd spend a lot of time
| chasing that down, getting the versioning for those libraries
| right, THEN finding a URL for those libraries/packages, and THEN
| creating the recipe.
|
| I eventually moved over to Debian and I still cringe and config
| files in "/etc" maybe the binary was put in "/usr/bin" or
| "/usr/local/bin".
|
| I'm in the camp that finds systemd annoying and kind of like an
| octopus (you'll often resort to using a find command to locate
| the associated .service file, you can't rely on them being in
| once place, the CLI isn't really intuitive) in contrast Gobo had
| a very simple set of scripts to manage services and it was very
| easy to work with.
|
| But, the convinience of just being able to 'apt get' what you
| need or 'dpkg -i <blah.deb>' outweighs the much more sane and
| intelligence behind GoboLinux. These days the number of Linux
| distributions people support has dropped from the myraid of
| options it used to be to now almost always including Debian (or
| Ubuntu) by default so you it's unlikely you can't get a package
| or some program installed, even if it outside the repositories.
|
| macOS definitely does something similar to GoboLinux and it makes
| working with macOS on the CLI (at least prior to the current
| versions which are fairly user-hostile) pretty easy -- your pen
| drive will be located in /Volumes, configuration files for a
| program under ~/Library, etc.
___________________________________________________________________
(page generated 2024-02-28 23:02 UTC)