[HN Gopher] Gobolinux : Redefining Linux filesystem hierarchy
___________________________________________________________________
Gobolinux : Redefining Linux filesystem hierarchy
Author : cassepipe
Score : 218 points
Date : 2021-12-28 15:50 UTC (7 hours ago)
(HTM) web link (gobolinux.org)
(TXT) w3m dump (gobolinux.org)
| rwoerz wrote:
| I hope that they will refrain from "optimizing" the new structure
| in every major release... Looking at you, Windows!
| DHowett wrote:
| I'm struggling to figure out exactly which directory structure
| Windows has changed every major release -- are you referring to
| when "Documents and Settings" was renamed to "Users" with the
| release of Windows Vista in 2006? Or perhaps you are talking
| about when they added "Program Files (x86)" with the
| introduction of 64-bit support in Windows XP, dating back to
| 2001...
|
| I believe it used to default to installing Windows NT to
| C:\WINNT... but that was almost certainly longer ago than
| you're suggesting. To be fair, the Desktop also used to live at
| C:\WINDOWS\Desktop, but there are some pretty good reasons why
| it doesn't any longer.
| dark-star wrote:
| In Win9x, it was c:\windows\desktop etc., before windows
| became multi-user, when it moved to
| c:\windows\profiles\xxx\desktop and later to
| C:\Users\xxx\Desktop. But only on US installations, in
| international versions it was c:\benutzer\xxx\desktop or
| whatever the translation of "users" was. That is until
| windows 7 (I think) when they moved to the English name for
| all systems, and had the UI (Explorer) translate it, which
| led to strange issues that Explorer shows
| "C:\Benutzer\x\Desktop" while the command prompt shows
| "C:\Users\x\Desktop"
|
| On some versions it was also "C:\Documents and
| Settings\\...", it is so convoluted that even I don't
| remember all the specifics, but yes, it was a total mess,
| especially on non-english installations
| MadcapJake wrote:
| When did ProgramData and AppData become a thing? Is there a
| guide somewhere about what should be placed in each folder?
| Local, LocalLow, Roaming? Seems like there are several
| competing conventions.
| wbkang wrote:
| ProgramData is the global application storage. AppData has
| been there since at least XP. Local is intended to be
| specific to this computer whereas roaming is something that
| is user specific that can be available across machines.
|
| The closest thing I can find is this
| https://docs.microsoft.com/en-
| us/windows/win32/shell/knownfo...
| jopsen wrote:
| Compared to the XDG directory specification that MSDN
| link is garbage.
|
| Just my personal opinion.
| dragonwriter wrote:
| Sometime before 2008 (and, since the change isn't the kind
| MS tends to do during a major OS version lifecycle,
| probably with or prior to the release of Vista in 2007)
| though the documentation on it (not just when it happened,
| but how to use them best) seems to be well-obscured. But
| here's a post originally from 2008 covering Windows Vista
| which is the least-bad coverage of ProgramData/AppData I
| can find:
|
| https://techcommunity.microsoft.com/t5/windows-blog-
| archive/...
|
| (My personal recollection is that it is much earlier, at
| least back to XP, but I could be wrong, so I'll go with
| what I can find documented.)
| egberts1 wrote:
| Mmmmm.
|
| Only beef I have is the CamelCase of GoboLinux CLIs.
|
| We all can do without shifting the shift keys as much as
| possible.
|
| Unless the ultimate goal is for 100% GUI mouse-click operation,
| which it does not appear to be.
|
| I sense a tinge of hostility toward typists in general.
| GordonS wrote:
| It's PascalCase, rather than camelCase, but I still agree with
| your point - capitalisation in a Linux file system just
| feels... weird!
| pxc wrote:
| I like initial caps for directory names and lowercase for
| filenames, which Linux desktop users are already accustomed
| to in their home folders.
|
| Caps leading command names is not great with case-sensitive
| filenames imo.
| r3trohack3r wrote:
| This is a neat idea - and not without precedent.
|
| Installing each package into it's own directory, and maintaining
| symlinks into that directory structure, was an approach explored
| for large system installations in the 90s and 00s.
|
| NIST depot, Xheir, CMU, and Nix all did this in varying ways. The
| advantage of this approach was that packages could be installed
| once on an NFS, scoped by version/configuration, and mounted into
| the filesystem of every work station on a campus. The
| workstations then just needed to maintain references to the files
| on the NFS for their particular software configurations. There is
| also some interesting exploration of composable configuration
| templates that allow workstations to inherit and extend a
| particular configuration (i.e. the physics department might have
| a base template).
|
| Nix is easily the most successful in this space. It even uses
| something similar to the NFS approach! It can maintain a remote
| cache of observed configurations to pull from instead of redoing
| work.
|
| Reading these LISA papers is a lot of fun. If you work in system
| administration (i.e. maintaining an Artifactory instance for your
| company) and have a day to spare - I'd very much recommend
| reading them, starting with the Nix paper!
|
| To get you started:
|
| Nix - https://www.usenix.org/conference/lisa-04/nix-safe-and-
| polic...
|
| Depot Lite - https://www.usenix.org/conference/lisa-viii/depot-
| lite-mecha...
| rackjack wrote:
| What is a LISA paper?
| dsr_ wrote:
| Large Installations Systems Administration, a now defunct
| conference.
| rackjack wrote:
| Thanks.
| pxc wrote:
| Nix is great! But GoboLinux is actually a few years older than
| Nix, isn't it? First release in 2003. :)
|
| Interestingly, GoboLinux Runners are basically the same concept
| as NixOS' FHSUserEnvs, where user namespaces are used to mount
| a subset of the existing shared libraries and other
| dependencies to make them visible (and the only ones visible)
| to a running program in a compatible way. This spares them some
| of the filesystem overhead of running a full OS container with
| its own package manager. So there's a bit of further
| convergence there, too.
|
| I love the cleanliness and legibility of the GoboLinux file
| hierarchy, and I think the simple, Mac-ish app bundling
| approach it takes is something many users might like and prefer
| over the rough edges of Nix or the complexity of Flatpak.
|
| A GoboLinux-like presentation could be great for a stable,
| impure NixOS downstream some day.
|
| Thanks for the link to the Depot Lite paper! I'd never heard of
| it.
| chris_wot wrote:
| That's kind of funny, because Microsoft do something similar
| with WinSxS. Only worse.
|
| What they do is store packages in the winsxs folder. They then
| do an NTFS hard link to where the component is installed,
| usually system32.
|
| If you ever used Vista and Windows 7 and started to run out of
| disk space over time, that's because Microsoft never used to
| remove the old components after they were updated. In Windows
| 7, the initial plan after SP1 was to allow people to use a
| special switch on DISM.exe to remove old service pack files.
|
| Microsoft removed the idea of service packs and instead did
| continuous patching with rollups. It seems to taken them quite
| some time before they twigged to the fact that the old updates
| were using up a lot of disk space, because a _long_ time later
| (almost at the end of the Windows 7 lifecycle) they added a
| Windows update to the disk cleanup wizard. Even worse, it would
| only remove the components after you rebooted but before you
| could login to Windows. If you ran it, it could sometimes take
| literally hours to get the computer to finish removing files
| from the component store.
| dark-star wrote:
| Wait, when did we come to the point where "working in system
| administration" is considered synonymous to "maintaining an
| Artifactory instance"?
| dagw wrote:
| About 3-5 years ago, give or take.
| bachmeier wrote:
| Long ago (maybe 15 years) I tried Gobolinux and thought it was a
| better approach for the typical Linux convert from Windows. I
| believe it was the lack of software, relative to Debian, Ubuntu,
| or Fedora, that kept me from running it.
| usrbinbash wrote:
| This is actually a neat idea, and I am saying that as the
| archetypical, grumpy _" I like my sys the way it is, thank you
| very much!"_ - kinda guy.
|
| A lot of the directory structure of POSIX systems is completely
| obsolete in the 21st century. The difference between sbin and
| bin? Historical, for the most part, and irrelevant in the age of
| rescue systems.
|
| One question that is nagging at my mind with this: What if two
| programs require the same lib, how is this resolved?
|
| Because, when I install progA, the lib is symlinked into the
| index, so when I now install progB, the lib is installed again if
| I understood correctly. Storage is irrelevant, the pkg manager
| sees there is a symlink, so it stays in place, all is well.
|
| But now I remove progA, so what happens? progB is still present,
| still requires the lib, it is also still installed, but now the
| symlink, which refered to /Programs/progA/libs/thelib.so is
| broken. How is this situation handled?
| potatoalienof13 wrote:
| As far as I can tell, the package manager handles dependencies,
| like most other package managers. Packages can declare
| dependencies on other packages, and the package manager
| installs each dependency only once globally.
| lelanthran wrote:
| I think GP was asking what happens when you remove a package
| that has thelib.so as a dependency. Is thelib.so removed?
| Does the previous existing thelib.so used as a replacement?
| pxc wrote:
| With any normal package manager, no. You don't remove a
| package that has _any_ remaining 'reverse dependencies'
| (a.k.a 'dependents'). Removing only one of many dependent
| packages just has no effect on the dependency.
| usrbinbash wrote:
| But if BOTH packA & packB come with the same libs, one of
| them HAS TO get symlinked in the system index. And they
| do not depend on one another, as each has to bring the
| same lib to the system, so logically, they can both be
| removed without breaking a dependency.
|
| But since there can be only ne symlink to the library
| (because the lib is searched by name in the index) the
| question remains: How is the package manager handling
| this for Gobolinux?
| duped wrote:
| This seems completely backwards, is it not that packA and
| packB have symlinks to the system index?
| pxc wrote:
| I think it may not be handled automatically.
|
| Looks like you could use find
| /System/Index | RemoveBroken
|
| and then you'd have to use SymlinkProgram to enable
| another provider of the shared libraries.
|
| In a way this is inside-out from what Nix and Guix do,
| where their equivalent of the System Index (the Nix/Guix
| store) is the build target, and everything all symlinks
| point to that. That makes this kind of thing a little
| easier to deal with, at some other costs.
| codedokode wrote:
| Sbin and bin separation actually causes problems with
| portability. A certain bluetooth-related utility wants to run
| iptables command [1] which can usually be found in `/sbin`. But
| `/sbin` is not in the PATH so they have hardcoded
| `/sbin/iptables` into the source. Now distributions that have
| iptables in `/usr/sbin` have to patch the program.
|
| So it would be better if either there were no `/sbin` or if it
| was always in the PATH.
|
| [1] https://github.com/blueman-
| project/blueman/blob/fcef83a01c80...
| thorawy88 wrote:
| codedokode wrote:
| They have separate directories for libraries under /Program, so
| I guess the library gets installed into a separate directory
| only once.
| infogulch wrote:
| I think libs are installed in /Programs too, and everything is
| versioned, and all libraries are linked to a central
| /System/Index/lib directory, which is referenced by ld by
| default: ( See https://gobolinux.org/at_a_glance.html )
| ~] ls -l /System/Index/lib libgtk.so ->
| /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
| libgtk-1.2.so.0 ->
| /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
| libgtk-1.2.so.0.9.1 ->
| /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
|
| Also: ~] cat /etc/ld.so.conf
| /System/Index/lib
|
| I guess it's up to the package manager or application to
| reference the version of the library at the correct
| specificity. And then it's up to the package manager to GC libs
| that aren't referenced anymore.
|
| Personally I think it would have been interesting to version
| the system index itself, like
| /System/Index/Current|1.0|myappenv|etc/lib|bin|etc, and each
| app is chrooted into their own system index by default.
| usrbinbash wrote:
| I understand how and where they are installed.
|
| The question is, when 2 packages, pkgA & pkgB bring in the
| same library, call it "thelib.so" into the system, logically,
| only 1 of them can be refered to by the symlink in
| System/Index/lib.
|
| So we have both
| /Programs/pkgA/1.0/lib/thelib.so
| /Programs/pkgB/1.0/lib/thelib.so
|
| And lets say the symlink points to the file of pkgA:
| /System/Index/lib/thelib.so ->
| /Programs/pkgA/1.0/lib/thelib.so
|
| What happens now if I remove pkgA? If nothing changes, the
| symlink would be dangling, and pkgB would no longer function
| because the libraries are looked up in the index.
|
| My question is: how is the pkg management system resolving
| this?
| infogulch wrote:
| Ah so basically how does it track dependencies? Good
| question. Browsing the wiki it looks like its basically
| manual :/ but I could be mistaken.
|
| https://github.com/gobolinux/Documentation/wiki/Removing-
| pro...
|
| https://github.com/gobolinux/Documentation/wiki/Understandi
| n...
| infogulch wrote:
| I explained it because your example makes me think you
| don't understand how and where packages are installed.
| Libraries are installed independently, but your example
| looks like the library thelib.so is installed inside pkgA
| which is only related to thelib.so because pkgA is the
| first package that depends on thelib.so, but this is
| incorrect, instead you'd have:
| /System/Index/lib/thelib.so ->
| /Programs/thelib/1.0/thelib.so
|
| And /Programs/pkgA/lib/thelib.so would never exist at all.
| oneplane wrote:
| I think they just intend to duplicate everything, but I'm not
| sure. One of the biggest issues with 'improved' systems is that
| even when they are actually a whole lot better, it makes it
| nearly impossible to reason about the system or the state of
| the system using filesystem primitives or other first
| principles.
|
| Take journals in systemd for example, they are better than
| plaintext log files in some cases, but now you are stuck with a
| format that needs to be interpreted and parsed before it is
| useful.
|
| That doesn't mean improvements shouldn't be done, but every
| step that is a big change often also makes it impossible to do
| some basic things that used to be possible for decades. This is
| similar to analog radio (i.e. only requiring a diode, tunable
| capacitor and a coil to receive audio! - no power supply
| needed!) vs. DAB. DAB has a lot of improvements over the base
| feature, as well as a whole lot of new features. But it is no
| longer possible to simply receive the radio waves and get
| audio.
|
| In a way you lose simplicity to gain sophistication. Sometimes
| we get sophisticated simplicity where a complex problem was
| solved in a very neat and elegant way that can be reasoned
| about with ease, but most times it isn't the case and that
| makes me (and a whole lot of other people it seems) wonder how
| we can get the improvement without losing the simplicity.
|
| For the very simple "the filesystem is the database" concept,
| this might actually be possible, all we really get is a well-
| known structure and versioning with symlinks, similar to the
| alternatives system used in Debian. But then we get /Programs
| which is capitalised which looks nice but mixed capitalisation
| seems too much of a "they are doing it, thus so are we" thing,
| while on a filesystem level there isn't any gain. Same with
| spaces in names or dashes. For visual representation that is
| nice, but everything else it sucks.
|
| I would take out the capitalisation and add some sort of
| unionfs/aufs/overlayfs hooking (symlink into a bundled
| filesystem would be one way) so from the system's perspective
| it's still a single filesystem tree but you add the option to
| get all those newfangled distribution methods in there as well.
| The problem we still haven't solved is versioning, but since it
| is arbitrary at this point /programs (or just call it /apps)
| could just contain <shortname>/<versionstring> for the
| application name and then version of the application. If you
| then dump in a version that comes from a docker image, flatpak,
| some weird weine-dxvk-steam construction or something else you
| symlink it in as a <versionstring> and then it's no longer the
| problem of the distro.
|
| There is still the issue of partitioning off parts of the
| system you don't want to be touched or want to have safe; a RO-
| snapshot plus user-overrides could work, but you might end up
| with a huge RO-snapshot that needs to be entirely replaced, and
| then a billion override mounts on top of that...
|
| As simple as Gobolinux presents it, this only seems to be
| useful for a single distro with a single distribution point,
| which is no longer where we are. Even FreeBSD is past that and
| that's not even Linux.
| codedokode wrote:
| The problem is not with capitalisation, the problem is that
| Linux filesystems are case-sensitive and require you to type
| the name with exact case.
| bayindirh wrote:
| I don't honestly understand why a case sensitive file
| system is a problem. I think a case insensitive system is
| counterintuitive.
| codedokode wrote:
| Because case insensitive filesystem doesn't require you
| to press Shift key when typing a command. Typing `ls
| /Program` requires one keypress more than `ls /program`.
| Also, it is easier to remember just a name rather than
| remember how exactly it is spelled.
| bayindirh wrote:
| I think the utility of a real case-sensitive file system
| cannot be nullified with an "I need to press shift!"
| argument.
|
| Apple's APFS will create the folder as "Programs" if you
| use "mkdir Programs", and will give you an error when you
| try to create "programs". You can navigate with any case
| combination, but it just plays along like the
| capitalization you entered is present. It feels like a
| hack tbh.
|
| Another thing I noticed that I never notice that I'm
| pressing shift while capitalizing. It's not a deal-
| breaker issue for me (while this might sound like "it
| works for me", I'm sure that I'm not alone in that).
|
| Case insensitive systems created a lot of problems down
| the road. Esp. due to popularity of Windows. Program
| porting is a pain, using macOS with real case-sensitive
| mode is again a pain for some scenarios. It also
| encourages sloppy programming practices and "I don't case
| as long as it works" ism.
| greiskul wrote:
| If you are manually typing a command, then the shell
| could do this work instead of the file system, right?
| That's what the shell is for, to be the bridge between
| humans and the computer right. In a perfect system, you
| would type ls /p, and one of the suggestions of the tab
| completion would be /Program.
| bayindirh wrote:
| Bash normally doesn't do that, but there are a lot of
| options available for both Bash and ZSH, which can do
| much more than just "case insensitive matching".
| rickbad68 wrote:
| A case sensitive filesystem doesn't require you to hit
| shift either if you just call the directory "programs".
| Also, there are many ways to save your pinky from moving
| the huge distance to the shift-key other than an
| arbitrary restriction on all file names in the file
| system..
| pxc wrote:
| I personally find the combination of case-sensitive
| filesystems with case-sensitive or smart-cased
| autocompletions pretty comfy.
|
| Most shells can be configured to behave that way, and Fish
| works that way by default.
| actinium226 wrote:
| Perhaps a new concept of a "symlink with backups" could be
| introduced.
|
| You install ProgA and the lib is symlinked into the index You
| install ProgB and the index's symlink to ProgA's lib gets some
| information added to it along the lines of "if the symlink to
| ProgA/lib is broken, try ProgB/lib"
|
| Then when you uninstall ProbA the fallback symlink is
| activated.
|
| At some point you would want to clean up the dangling primary
| link but maybe the best time to do it is immedately. i.e. the
| first time the primary fails you make the backup the new
| primary and now there's no backup, i.e. it looks the way it
| would look if you had only ever installed ProgB.
| pjc50 wrote:
| This is roughly what Debian "alternatives" does, although
| it's not used for libraries.
| function_seven wrote:
| Why not use hard links instead? Both ProgA and ProgB will
| have their own links to the same inode. Either one can delete
| their own link, but the library will still exist unless all
| programs using it delete their links.
| [deleted]
| saghm wrote:
| I think for shared libraries, the convention is to have the
| major version number of the API in the name (e.g. foo.so,
| foo2.so) and then to put any ABI changes as a trailing
| extension (e.g. foo.so.2, foo.so.3, foo2.so.2, foo2.so.3). It's
| kind of a hack, but it makes sure that you can link
| unambiguously to one if you need it.
|
| EDIT: didn't realize you were talking about Gobo specifically;
| not sure how they deal with this, but theoretically a similar
| strategy seems like it could work
| duped wrote:
| I'd rather progA and progB package their own local versions of
| thelib.so unless they explicitly request to use a shared
| version globally.
|
| Shared libraries actually being shared is the exception and not
| the rule
| bern4444 wrote:
| This is very similar to how npm works. Each installed package
| has its own dependencies installed that are kept separate
| from other packages even if another package has the same
| dependency.
|
| For all the hate of npm and node_modules it's wonderful to
| have this isolation
| syntax-rules wrote:
| This is a really excellent way to manage packages in a system, I
| ran lots of systems a long time ago this way because of Dan
| Bernstein https://cr.yp.to/slashpackage/management.html
| pshirshov wrote:
| It would be nice if they mix it with Nix. It makes little sense
| _not_ to use Nix, despite its numerous shortcomings.
| transfire wrote:
| Gobo was ahead of its time, in a way. Unfortunately mainstream
| distros have yet to really learn its lessons.
| W0lf wrote:
| I think this approach is very similar to how Android is handling
| the different apps where each gets installed into its own
| dedicated path directory. (I may be wrong though, cant remember
| since the last time I've looked into the AOSP)
| justaguy37 wrote:
| Can the package system be installed within another distro, much
| like Nix is able to be run without NixOS?
| [deleted]
| GekkePrutser wrote:
| Cool, sounds a bit like how NixOS does things.
|
| It's not for me I think (nor is Nix), but that's the nice thing
| about Linux, everyone can do things their own way. I mostly use
| FreeBSD anyway.
| Ericson2314 wrote:
| We'll get you with NixOS/kFreeBSD someday :D
| pxc wrote:
| It hurts me how close we could be to a single, cross-platform
| module system for Nix.
|
| It's theoretically closer than ever, thanks to stuff like
| nix-processmgmt and Initware for the BSDs, but it feels like
| something that keeps coming close only to fade away :'(
|
| But Nix can absolutely do it, and it could be so extremely
| good!
| cassepipe wrote:
| A response to inevitable critiques :
| https://gobolinux.org/doc/articles/clueless.html
| conexions wrote:
| In my mind the principal reason for the current hierarchy is
| read/write usage. With /etc and /usr it is possible after
| installation and configuration to set one or both as Read Only.
| With /var and /home you have the directories that should be
| Read/Write on a running system. This allows you to mount each
| of those directories on a different partition with different
| settings or even different filesystems depending on how you
| want to optimize/secure your application.
|
| Now admittedly actually doing this is pretty rare in these
| days, but I still like having the option. I believe he does
| address this talking about "union mounts" and "overlay
| filesystems". I'm really not too familiar with either or how
| production ready they are, but it may address my concerns.
| laurent92 wrote:
| > Now admittedly actually doing this is pretty rare in these
| day
|
| It's pretty frequent! When Atlassian launched their Cloud
| offerings in 2013, they installed Confluence and Jira on
| their own servers (1.5GB each), one per customer, and set
| /bin and /etc as read-only.
|
| Then they mounted /etc and /bin from the network. 1.5GB saved
| per instance!
|
| So it makes sense not because you can set them as read-only,
| but because you can mount them separately.
| DarylZero wrote:
| The obvious critique in 2021+ is "GoboLinux is a great concept
| but doesn't Nix make it obsolete?"
| bantunes wrote:
| I was going to reply saying Gobo came first, but they're both
| from 2003!
| DarylZero wrote:
| I thought Gobo came first. I remember installing it ~2003.
| Didn't hear about Nix until years later and when I did it
| reminded of that old Gobo install.
| carlhjerpe wrote:
| GoboLinux uses patchelf just like Nix but you don't have to
| learn the convoluted undebuggable mess of Nixlang (I run
| NixOS on all my machines, it's a love-hate relationship)
| nusaru wrote:
| I've only tried Nix once or twice, and I'm left wondering:
| why don't they use a scripting language? Is part of the
| appeal that the Nix language is a functional language?
| danieldk wrote:
| _why don 't they use a scripting language_
|
| Reproducibility. You need a pure (side effect-free)
| language to ensure that a package expression always
| evaluates to the same value [1]. If you have a non-pure
| language, external factors (e.g. environment variables or
| a server returning a different response) can
| influence/change what a package expression evaluates to.
|
| [1] That said, Nix was not completely free of side-
| effects either. Though this is one of the issues that Nix
| Flakes attempt to solve.
| junon wrote:
| Lua fits that bill perfectly.
| CyberShadow wrote:
| You can use pretty much any Turing complete language to
| achieve this constraint, as long as its inputs and
| execution are deterministic. The language itself doesn't
| have to be purely functional.
| soraminazuki wrote:
| It's mostly about using the right tool for the right job.
| The Nix language is used for large scale configuration,
| not scripting. Anything that requires scripting is
| offloaded to Bash. As a result of that, Nix resembles
| JSON but with variables and lambdas to make writing
| complex configurations easier. The competitor of the Nix
| language is not Bash or Python, it's JSON and YAML.
| stelonix wrote:
| A friend uses YAML in that way. Each entry is valid JS
| code. The result is you have a mixed declarative-
| imperative configuration language. It's very powerful and
| I have found a few uses too. The best part is that the
| evaluator is at most 30 lines of code.
| ImprobableTruth wrote:
| ... and how do you ensure that it's execution is
| deterministic?
| CyberShadow wrote:
| Most programming languages are already generally
| deterministic.
|
| Pick any programming language. Now, remove access to I/O
| (except standard input and output), networking, time,
| random number generators, threads, OS syscalls, etc.
|
| Given an input, the program will always generate the same
| output, i.e. it is deterministic. However, the program is
| still allowed to have global mutable state; the state is
| just encapsulated to the program's memory and execution
| time.
|
| A trivial example is Brainfuck. It is most certainly not
| a functional programming language, but it is
| deterministic.
| Filligree wrote:
| The obvious choice is Haskell. It's a pity they didn't
| use that.
| renox wrote:
| Given that the alternative of Nix use a Lisp instead I'm
| not that sure of the 'obviousness' here..
| otabdeveloper4 wrote:
| The Nix language is just JSON + lambda functions +
| variables. And nothing more. If you know modern
| JavaScript then you already know the Nix language.
|
| The problem is Nixpkgs, the largest Nix program. Nix-the-
| language doesn't lend itself too well to programming in
| the large. It's a bit like writing a large JavaScript SPA
| without frameworks or strict coding standards.
| darau1 wrote:
| > tried Nix once or twice
|
| me too. I broke my system a bunch of times, and
| eventually just gave up. I remembered the other day that
| I have a _lot_ of programs installed with it that I don
| 't even want to think about updating. rofi changed it's
| configuration file format recently, and that was tied up
| in nix. I am too lazy to fight with it for now, so I've
| just disabled my config file. It bothers me every time I
| use it.
| carlhjerpe wrote:
| NixOS is the only system I'm yet to break, and I've been
| using it at home for 2 years and at work full-time for a
| couple months.
|
| If the system evaluates it'll most likely work, if it
| doesn't you roll back a generation.
|
| I have an Ubuntu container around if I quickly wanna mess
| with something.
| darau1 wrote:
| I'm positive it works. My problem was that figuring out
| why something went wrong was too time consuming, or
| difficult. I'm sure I could figure it out, but the
| problem again is time.
| pxc wrote:
| As a longtime Nix user with very little prior FP
| experience (1/4 of one course in college doing a few
| exercises in Haskell), I think the Nix language is
| actually very well-suited to task.
|
| The biggest difficulty comes from the fact that it is a
| dynamic, weakly-typed language, which can lead error
| messages in configuration to point you toward library
| code rather than your config file. This is a pitfall
| shared by many of the languages that are commonly
| suggested as replacements or alternatives.
|
| There's been work to solve this by adding gradual typing
| (like in Typescript) to Nix, whose most promising
| iteration atm is (imo) a Nix-like language called Nickel,
| which is almost ready for preview by the community.
|
| The other, more minor, issue is tooling, which is being
| addressed by emerging LSP work for Nix.
|
| (Scripting is done in Nixpkgs, mostly via Bash.)
|
| The beauty of Nixlang, imo, is that for simple use cases
| it really feels like a dead simple configuration
| language, which is only possible with a declarative
| language.
|
| The functional character and Nix's laziness were
| important in the early design of Nix. The latter may
| still give Nix some nice performance characteristics. But
| since the initial Nix design, Nix has become eager in
| some places, and Guix is implemented as a lazy DSL
| embedded in an eager language, so I guess we could
| implement something like Nix on top of an eager scripting
| language.
|
| Imperative scripting languages might not be as well
| suited for the kinds of overrides that Nixpkgs and NixOS
| use, afaict. But imo aside from its novelty, the Nix
| language is nice to use because it's really simple and
| totally declarative, which is what you expect from a
| configuration language.
| rekado wrote:
| I don't know what people consider "eager" in Guix. In the
| `package` DSL all input fields are thunked, so they are
| not eagerly resolved. You don't need all values of your
| language to have lazy semantics --- delaying evaluation
| of some values is enough. Just because Guile Scheme is no
| lazily evaluated by default does not mean that "Guix is
| eager" is a useful statement.
| pxc wrote:
| Thanks for the correction!
|
| > You don't need all values of your language to have lazy
| semantics
|
| Once upon a time (no longer, I think), Nix was 'maximally
| lazy', so I think historically at least, there has been a
| question of how essential laziness is to the design of
| package managers in the functional paradigm. Since then I
| guess we've seen what you describe (some targeted
| laziness) is all that's required in both DSLs.
|
| I've edited my comment above to better reflect Guix's
| design and stop spreading the 'Guix is eager' meme. :)
| ratorx wrote:
| I'm a fan of the NixOS module style typing. It feels like
| the right compromise for something like Nix. Domain
| specific type system is also helpful for documentation.
| E.g. in NixOS, the types and the docs live together and
| benefit each other. Giving that better support in the
| language and building editor tooling around it seems like
| the way to go.
|
| There's an open RFC/PR to bring NixOS style modules to
| Nixpkgs for package management (with derivations being
| the primitive).
| carlhjerpe wrote:
| So everything has to be pure and side-effect free, I'm
| not into the history and when you're not doing too much
| Voodoo it looks like what you'd want a configuration file
| to look like.
|
| But the downside is that debugging is impossble.
|
| Guix uses guile, which is a Lisp so we could accomplish
| the same with other languages.
| pshirshov wrote:
| The purpose of Nix is reliable declarative configuration.
| Gobo seems to be significantly less declarative than Nix.
| carlhjerpe wrote:
| Who are you to define the purpose of Nix? Many people use
| Nix as an imperative package manager too. So no, the
| purpose of Nix is not reliable declarative configuration,
| it's more than that.
|
| Here's the paper from Eelco Dolstra (founder of the Nix
| project) https://edolstra.github.io/pubs/nspfssd-
| lisa2004-final.pdf
|
| I don't see him mentioning configuration an awful lot in
| there, it seems to be mostly about dependencies and
| multiple versions of things.
| pxc wrote:
| But where's the _sport_ in debugging an error message
| within 300 lines of the cause?
| jiggunjer wrote:
| Or docker.
| carlhjerpe wrote:
| Why is it that AppImages, snaps, flatpaks, Nix and every
| distro package manager is replaced by docker?
|
| Could it be that docker is missing something, maybe the
| Dockerfile isn't easily reproducible? Maybe the ephemeral
| status of all containers is quite some effort to work with?
|
| Maybe it's just not the one true answer to the question of
| software packaging.
| jeroenhd wrote:
| Identifying your dependencies is hard. The easy solution
| is not to care: develop on a machine, and ship the entire
| machine! That way, software with the Works On My Machine
| seal of approval can be pushed to production without
| trouble!
|
| I love Docker for the simplicity it offers, but the
| gigabytes of storage wasted on yet another slightly
| different version of Debian every time I pull a container
| irks me to no end. Sadly, it's the only way some software
| is distributed.
| goodpoint wrote:
| Please tell me this is satire.
| jeroenhd wrote:
| First part is, second part isn't :)
| piaste wrote:
| > Why is it that AppImages, snaps, flatpaks, Nix and
| every distro package manager is replaced by docker?
|
| Where are you seeing distros using docker for
| containerization? If anything, I'd say Flatpak is the one
| you're most likely to find installed in a 2021
| workstation linux.
|
| Docker's killing features are the same as they always
| were: usability and ecosystem. 'docker run thingamajig'
| is simple and DockerHub is very likely to have
| thingamajig in its repos.
|
| Of the ones you listed, I'd say flatpak is the only one
| that compares favorably to Docker on both aspects
| ('flatpak install thingamajig'). And since flatpak is
| more designed for desktop applications, it's actually the
| one gaining ground. Docker or other containerd-based
| solutions should remain the preferred choice for servers,
| since they're designed for that.
|
| Nix is vastly less user friendly. Snaps, last I checked,
| still don't have an open-source repository
| implementation, meaning that Canonical has absolute
| control over them. I don't know much about AppImage, but
| AFAICT it's just a file format and not a full package
| manager.
| codedokode wrote:
| Docker (in my opinion) is a poor solution for distributing
| apps. It resembles a quick hack rather than a solid,
| scalable, future-proof solution. The problem is: you need
| to deploy an application with all required libraries with
| specific versions and build options. Obviously, a proper
| solution would be a package manager which would read the
| declarative, non-executable configuration file and install
| or build necessary dependencies.
|
| Another problem is that you want to run an application on
| differen platforms, not only Linux. Again the proper
| solution would be to write a cross-paltform application and
| install it using a cross-platform package manager.
|
| Docker doesn't offer a proper solution; instead it suggests
| that you create a virtual machine, install a whole
| operating system (without a kernel) there and then write a
| bash script that will download and build dependencies. As
| docker image configuration file is an executable script, it
| means that it cannot be processed with automated tools; it
| can only be read by a human.
|
| Also, docker requires a daemon running as a root. This
| increases potential attack surface.
|
| Docker is not good for desktop applications because it
| doesn't have portals which can restrict access to DBus,
| audio daemons, file system etc.
| cxr wrote:
| Previously:
|
| > > _How does GoboLinux compare to Nix & Guix these days? Why
| would one use the former vs the latter?_
|
| > _This blogpost has a comparison of Gobolinux and Nix:_
|
| > _http://sandervanderburg.blogs_
|
| <https://news.ycombinator.com/item?id=13189792>
| k__ wrote:
| TL;DR NixOS uses hashes based on all dependencies that go
| into a package build and GoboLinux uses version numbers.
| Which makes Gobo easier to use, but less secure.
| egberts1 wrote:
| SanderVanderburg.blogs is down.
| pxc wrote:
| GoboLinux is more impure and more compatible with processes
| that people are used to. Imo it will take an impure,
| downstream distro of NixOS to really make GoboLinux
| 'obsolete'. Something where, in a pinch, you can just
| ./configure && make
|
| without grokking Nix, and have it work. Or where you can
| install Linuxbrew and Pkgsrc and have them just work, as
| additional, non-sandboxed escape hatches.
|
| And such a downstream system could benefit from mimicking
| GoboLinux in a few ways, imo.
| marcodiego wrote:
| Cool! I thought it was no longer maintained. Although it
| influenced the distro landscape much less than it could, things
| have changed enough so that I have mostly a "don't care" feeling
| about gobolinux.
|
| Most end users rarely interact directly with the filesystem, so a
| different hierarchy won't impact many people. Installing up-to-
| date packages that do not threaten the stability of your system
| is easy with flatpaks/snaps; it is even possible to install GNOME
| Software add-ons to handle them. If you want to install "system-
| software" that is not possible with snaps or flatpaks, there's
| always Nix, Guix or homebrew. All that without considering
| AppImages, of course.
|
| So... gobolinux is a great idea. But it fixes problems that are
| much smaller today.
| codedokode wrote:
| Starting directory names with capital letter is not a good idea.
| While that might look nice, it requires more keypresses when
| typing it in the terminal. So /apps or /soft would be better than
| /Programs.
|
| It is convenient in case-insensitive filesystems like those used
| in Windows or Mac, but not in Linux. By the way it would be
| better if Linux also switched to case-insensitive filesystem, or
| even a filesystem where similar looking characters from different
| alphabets are considered the same. So that A is always A no
| matter what alphabet is used.
|
| Also I don't like the way they hide classic directories like
| /bin. Instead, they should just not create these directories;
| well-written programs should not require their presence.
| forty wrote:
| Case insensitivity is a mess as soon as you start looking
| outside of ASCII.
| codedokode wrote:
| But I don't think that it is an unsolvable task. If you
| simply use Unicode-aware version of "to lowercase" function,
| it will be better than what we have today. But of course
| there is a place for improvement (dealing with accented
| letters in European languages, dealing with combining
| characters, different alphabets like Hiragana/Katakana etc).
| forty wrote:
| Hum... I think simpler is better, and having each letter be
| what they are only seems much simpler than having to guess
| if the file system is going to decide my new file name is
| equivalent to another existing file name and overide it
| rather than creating a new one (for example).
| codedokode wrote:
| It is "simple" for a programmer who doesn't want to learn
| Unicode and prefers working with bytes instead of
| letters, but inconvenient for a user. More keypresses,
| easier to make a mistake when typing.
|
| I cannot imagine a situation where you need two files
| whose names differ only in case.
| forty wrote:
| Since it's relevant and funny, I'll quote the famous rant
| of Linus Torvalds on the topic (it was because of issues
| it caused with Git, but I assume it still means it's
| unlikely Linux will ever follow this path ^^)
|
| "The true horrors of HFS+ are not in how it's not a great
| filesystem, but in how it's actively designed to be a bad
| filesystem by people who thought they had good ideas.
| The case insensitivity is just a horribly bad idea, and
| Apple could have pushed fixing it. They didn't. Instead,
| they doubled down on a bad idea, and actively extended it
| - very very badly - to unicode. And it's not even UTF-8,
| it's UCS2 I think. Ok, so NTFS did some of
| the same. But apple really took it to the next level with
| HFS+. There's some excuse for case
| insensitivity in a legacy model ("We didn't know
| better"). But people who think unicode equivalency
| comparisons are a good idea in a filesystem shouldn't be
| allowed to play in that space. Give them some paste, and
| let them sit in a corner eating it. They'll be happy, and
| they won't be messing up your system. And
| then picking NFD normalization - and making it visible,
| and actively converting correct unicode into that
| absolutely horrible format, that's just inexcusable. Even
| the people who think normalization is a good thing admit
| that NFD is a bad format, and certainly not for data
| exchange. It's not even "paste-eater" quality thinking.
| It's actually actively corrupting user data. By design.
| Christ. And Apple let these monkeys work on
| their filesystem? Seriously?"
| akho wrote:
| Case-insensitive ASCII filenames are best filenames.
|
| Also, please, no whitespace in filenames. Allowing linebreaks
| is just insane.
| forty wrote:
| I wouldn't mind but there are a bunch of people in this
| world who have no idea what those ASCII symbols even mean,
| and who might prefer using symbols they understand ^^
| tambourine_man wrote:
| I think bash autocomplete can be configured to be case
| insensitive
| potatoalienof13 wrote:
| The response by one of the devs to the first problem is "In
| fact, the concerns on typing-friendliness always comes up in
| discussions about the GoboLinux tree. 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." [0]
|
| The response to your second problem is that not all programs
| are well written, and they cannot afford to patch every poorly-
| written program.
|
| [0] https://gobolinux.org/doc/articles/clueless.html
| michael-ax wrote:
| in other words, they haven't thought to make the damn name
| and case-sensitivity preferences configurable. how odd is
| that.
| klysm wrote:
| I don't want to have to reconfigure a shell when it could
| just be lowercase.
| pxc wrote:
| I hear you, but I also think tab completion is one of the
| basic amenities we should expect shell users to avail
| themselves of in 2021. And distro-makers can even pre-
| configure them for their users. I can understand why a
| distro maker might not be interested in accommodating users
| who don't want to use decent tab completion with smart
| casing.
| asperous wrote:
| From the faq it sounds like the purpose is to differentiate the
| gobolinux top level folders from the hidden compatibility
| folders, which makes sense to me.
___________________________________________________________________
(page generated 2021-12-28 23:00 UTC)