[HN Gopher] Guix System First Impressions as a Nix User
___________________________________________________________________
Guix System First Impressions as a Nix User
Author : todsacerdoti
Score : 130 points
Date : 2026-01-31 11:22 UTC (11 hours ago)
(HTM) web link (nemin.hu)
(TXT) w3m dump (nemin.hu)
| uriahlight wrote:
| With respect, the author sounds too fickle for me to ascribe
| value to their "first impressions" of a distro.
| hazebooth wrote:
| seems like they have pretty clear goals in mind. if they were
| changing distributions haphazardly id otherwise agree, but to
| me it reads that they're refining their taste.
| 6ak74rfy wrote:
| I didn't read any fickleness in the post. Sure, they tried
| multiple distros - who hasn't - and that too over ten years.
| user3939382 wrote:
| Modern GPU drivers are a nightmare for open source. Wifi no
| better but slightly less critical. Power management. Forget Linux
| this should be the year of the NetBSD desktop but we can't have
| nice architectures bc of economics in computing. The whole
| scenario makes sense but the emergent result sucks.
| bayindirh wrote:
| > Modern GPU drivers are a nightmare for open source.
|
| Modern NVIDIA drviers. Let me fix that for you.
|
| Intel and AMD has their full stack in mainline already, and AMD
| made great effort to enable their cards fully under open source
| drivers, as their agreements and law allows. You can even use
| HDCP without exposing sensitive parts, if you want.
|
| Intel also works completely fine.
|
| However, NVIDIA's shenanigans and HDMI forum's v2.1
| protectionism is something else completely.
| gf000 wrote:
| Modern NVIDIA drivers for their more recent cards are
| actually okay, again.
| bayindirh wrote:
| Well, they might work, but they are far from OK.
| - An open source kernel module which talks with the card.
| - A set of closed source GLX libraries for acceleration
| support. - A signed and encrypted firmware which
| only works with this closed source driver package to enable
| the card.
|
| Nouveau drivers are intentionally crippled with a _special_
| firmware which enables the card to show a desktop, with
| abysmal performance and feature set.
|
| Nothing is OK about that.
| gf000 wrote:
| Well, amd drivers sucked a whole lot (fglrx anyone?)
| before AMD made them open-source. And on every other
| front it's the same, as basically every other
| manufacturer. There is no such thing as open hardware.
| bayindirh wrote:
| I have used fglrx for a very long time, and have some
| adventures with it. I even knew people from the
| development team, actually.
|
| Well, having a driver agnostic closed source firmware is
| pretty different from an end-to-end closed chain with a
| driver-authenticating firmware.
|
| Also, while fglrx had some serious problems, they didn't
| wait two years to fix DVI DPMS issues like the green
| company.
|
| Yes, neither are open hardware at the end of the day, but
| we have almost infinite number of colors and infinite
| shades of gray. Like everything else, this is a spectrum.
|
| As I aforementioned, I'd love to have completely free
| hardware, but the world's reality works differently for
| many right and many wrong reasons. I'd prefer to use most
| open one I can get, in this case.
| gf000 wrote:
| I agree with you on principle.
|
| But at the same time (adding more shades of color), part
| of the reason why Nvidia remained closed source for
| longer was precisely because they were supporting all the
| same features on both windows and Linux, while amd's
| Linux was (is?) always lagging behind. For ML use cases
| basically the only choice was Nvidia.
|
| (Nonetheless, I was very happy with my amd card, and now
| I'm very happy with a semi-modern Nvidia card)
| anthk wrote:
| AMD cards need propietary firmware.
| bayindirh wrote:
| Yes, that's a problem if you want a fully free-software
| powered system. However, considering how we had firmware
| since forever, this is a compromise I can _personally_
| accept, for now.
|
| Having a completely Free Software firmware would be great,
| but I'm not sure barrier to this is as low as Free Software
| since there's involvement of IP blocks, regulation, misuse
| of general purpose hardware (like radios) and whatnot.
|
| I really support an end-to-end Free Software system, but we
| have some road to go, and not all problems are technical in
| that regard.
| drowsspa wrote:
| Honestly back when I was still in college one and a half
| decade ago, it was quite clear the whole Nvidia-only ML and
| AI libraries weren't a good idea
| plagiarist wrote:
| I went with AMD for compatibility playing games, but AFAICT
| AMD ROCm is not in a great state for computation. Why can't I
| have both?
|
| That's something like what they're describing as "a
| nightmare," isn't it? "As agreements and law allows," is part
| of the nightmare. Under a modern OS, it should not be
| difficult to have the full capability of the hundreds or
| thousands of dollars worth of hardware you paid for.
| 6ak74rfy wrote:
| I've had a passing curiosity about Guix, so it was good to read
| this report.
|
| One thing I didn't find is Guix on servers. I am all-in on NixOS
| for both my daily driver desktop and couple of servers, and
| adding more of either will be simple modifications to my flake
| repository. I really appreciate that simplicity and consistency.
| Does Guix offer that?
|
| The other thing is package availability: it's amazing on Nix.
| Plus, they remain relatively fresh on the unstable channel. How's
| that on Guix?
| uncletaco wrote:
| Guix on servers is ok. I run Guix in my homelab.
|
| The vast majority of what you'd want in a Guix server can be
| found in the services section and parts of the documentation
| that lay out how to build services. But it doesn't have as many
| services available as nix.
| wasting_time wrote:
| For servers you might want to try 'guix deploy':
|
| https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...
| k__ wrote:
| How do you deploy NixOS to your servers?
|
| I started a project with nixos-anywhere, deploy-rs, and
| compose2nix. However, I struggle a bit with secret management.
| drdaeman wrote:
| There are plenty of options: nix-sops, or nix-age, or
| whatever you would like - past the overall idea the
| implementation details are purely a matter of taste how you
| fancy things to be. Key idea is to have encrypted secrets in
| the store, decrypted at runtime using machine-specific
| credentials (host SSH keys are a typical option to repurpose,
| or you can set up something else). For local management you
| also encrypt to the "developer" keys (under the hood data is
| symmetrically encrypted with a random key and that key is
| encrypted to every key you have - machines and humans).
|
| Alternatively, you can set up a secrets service (like a
| password manager/vault) and source from that. Difference is
| where the secrets live (encrypted store or networked service,
| with all the consequences of every approach), commonality is
| that they're fetched at runtime, before your programs start.
|
| I'm currently using deploy-rs, but if I'd redo my stuff (and
| the only reason I don't is that I'm pretty much overwhelmed
| by life) I'd probably go with plain vanilla nixos-rebuild
| --target-host and skip any additional layers (that introduce
| extra complexity and fragility).
|
| Just a crude and somewhat haphazard summary but hope it
| helps.
| diarrhea wrote:
| I have been using nixos-rebuild with target host and it has
| been totally fine.
|
| The only thing I have not solved is password-protected sudo
| on the target host. I deploy using a dedicated user, which
| has passwordless sudo set up to work. Seems like a
| necessary evil.
| matrss wrote:
| > I deploy using a dedicated user, which has passwordless
| sudo set up to work.
|
| IMO there is no point in doing that over just using root,
| maybe unless you have multiple administrators and do it
| for audit purposes.
|
| Anyway, what you can do is have a dedicated deployment
| key that is only allowed to execute a subset of commands
| (via the command= option in authorized_keys). I've used
| it to only allow starting the nixos-upgrade.service (and
| some other not necessarily required things), which then
| pulls updates from a predefined location.
| VTimofeenko wrote:
| I'd recommend sticking with deploy-rs. Saved me quite a few
| hours through its magic rollback which aborted an upgrade
| that borked VPN.
| 6ak74rfy wrote:
| nixos-anywhere to create, deploy-rs to deploy. sops-nix for
| secrets. Works great.
| embedding-shape wrote:
| I seemingly went what I consider simple, others might
| consider barebones: I have a Makefile, define all the hosts
| there, and then use scp to copy over all files into the right
| hosts, and then run `nixos-rebuild switch` on them once
| copied over. Some have extra "restart-service-X" as some
| services have their configuration managed outside NixOS (but
| still in my source repository) so those as well are scp'd
| into the right place, then the service restarted after the
| nixos-rebuild switch. Otherwise it's all .nix files and
| service-specific configuration files.
| majoe wrote:
| I struggled with remote deployment + secret management, too.
| Like a lot of folks, my nix-config grew over the years as I
| added secrets management, user management etc ad hoc.
|
| I recently found clan.nix [1] and am quite pleased. It's kind
| of a framework for writing nixos configurations with a focus
| on multiple devices. It bundles secrets management and remote
| deployment into a convenient CLI.
|
| It has the concept of "services", which are e.g. used for
| user management and VPNs. Services define roles, which can be
| assigned to machines, e.g. the wireguard service has a
| controller and a peer role. That feels like the right
| abstraction and it was very easy to set up a VPN with
| zerotier like that, something I struggled doing myself in the
| past.
|
| It's a rather young project, but I converted my nix-config
| repo after a short evaluation phase to use clan. It's worth
| taking a look for sure.
|
| [1]: https://clan.lol/
| c0balt wrote:
| I would strongly recommend sops-nix[0]. Pair this with ssh-
| to-age/ssh-to-gpg for the keys for each server. We are
| using this at $work for multiple servers, one notable
| advantages is that it works in teams (for multiple people)
| and git (and also gitops).
|
| For remote installations nixos-anywhere is great. deploy-rs
| or colemna is fine, nixos-rebuild with `--target-host` is
| also working well for us however.
|
| [0]: https://github.com/Mic92/sops-nix/issues
| linschn wrote:
| The scheme syntax gets a while to get used to if you are not
| familiar with it, and in the end having a real programming
| language is quite awesome, you can do lots of fun stuff like
| programmatically create a file or dir for every user of a
| certain group, etc.
|
| Take a look at this
|
| https://guix-hosting.com/docs/tuto/getting-started.html
|
| To see how one can use macros to redefine the syntax to get an
| imperative-like syntax for defining services.
|
| Disclaimer: i run guix-hosting.com
| c0balt wrote:
| > programmatically create a file or dir for every user of a
| certain group
|
| To be fair here, NixOS module system also makes this a
| breeze. Whether via `systemd.tmpfiles` or via generated
| scripts.
|
| It might be nicer to have some more DSL capabilities in nix
| though.
| gurjeet wrote:
| TLDR: ... I'm getting a comparable experience to NixOS, with all
| the usual pros a declarative environment brings and without
| having to put up with Nixlang.
| oasisaimlessly wrote:
| Instead, put up with a flavor of Scheme that looks suspiciously
| like Nix with some extra parentheses...
| eikenberry wrote:
| How the errors/debugging compare? From what I've read this is
| the main pain point with Nix where a more mature language
| like Guile should have a much better experience here. The
| article touches on this but I'd be curious of a more
| extensive comparison about this aspect.
| kkfx wrote:
| My issue with Guix coming from NixOS is the missing first-class
| zfs support for root, crypto included, RustDesk, few other common
| services who are hard to package.
|
| Guix potential target IMVHO should be desktop power users, not
| HPC, NixOS while mostly developed for embedded systems (Anduril)
| or servers in general still take care of desktops, Guix
| apparently not and that's a big issue... Nowadays outside
| academia I doubt there are many GNU/Linux users who deploy on
| plain ext4...
| akshitgaur2005 wrote:
| See this config for an example guix config with zfs -
| https://codeberg.org/hako/Testament/
| autumn-antlers wrote:
| > Guix channels in use:
|
| > - guix (additional patches are used locally for root on ZFS
| support)
|
| i'm hopeful too, but think it may not be so simple (yet) >u<
| here's a more precise link
|
| https://codeberg.org/guix/guix/pulls/1917#issuecomment-69760.
| ..
| kkfx wrote:
| Thanks! A very nice set of configs. I've done something
| similar for NixOS and my LAN but never advanced at such point
| in Guix.
| blm126 wrote:
| For desktop usage, I would be absolutely shocked if ext4 isn't
| the most common filesystem by a pretty wide margin. Its the
| default on Ubuntu, Debian, and Mint. Those are the 3 leading
| desktop distros.
|
| No one is going to write a blog post titled "Why I just used
| the default filesystem in the installer" but that is what most
| people do. Things like btrfs and zfs are useful, complicated
| technologies that are fun to write about, fun to read about,
| and fun to experiment with. I'd be careful about assuming that
| leads to more general use, though. Its a lot like Guix and
| NixOS, in fact. They get all the attention in a forum like
| this. Ubuntu is what gets all the people, though.
| kkfx wrote:
| You have a statistical point of view that doesn't go into
| detail enough: yes, Debian, Ubuntu, Mint are mainstream
| distros and use ext by default. The vast majority of their
| users are also mainstream users and would never approach
| declarative distros, which are alien to them.
|
| Those who choose going declarative instead are people with
| operations knowledge, who understand the value of a system
| ready to be built, modified, and rebuilt with minimal effort
| thanks to the IaC built into the OS, who understand the value
| of their data and therefore babysit them properly. The
| average user of Debian, Ubuntu, Mint today doesn't even have
| a backup, uses someone else's cloud. If they run experiments,
| they waste storage with Docker, or use manually managed VPSs;
| they don't own a complete infrastructure, let alone a modern
| one.
|
| So thinking about them for Guix means never letting it take
| off, because those users will never be Guix users. ZFS is the
| opposite of complicated; it's what you need to live
| comfortably when you know how to use it, which unfortunately
| isn't mainstream, and declarative distros do the same.
|
| NixOS succeeds despite the indigestible Nix language because
| it offers what's needed to be comfortable to those who know.
| Guix remains niche not because of GNU philosophy but because
| it doesn't do the same, not offering what those coming from
| operations are looking for and they are the most potential
| realist target users.
| eikenberry wrote:
| Ext4 is still very popular as a solid, no frills filesystem.
| Btrfs is the primary alternative and still suffers from a poor
| reputation from their years of filesystem corruption bugs and
| hard to diagnose errors. ZFS and XFS only makes sense for
| beefier servers and all other filesystems have niche use cases
| or are still under development.
| kkfx wrote:
| I don't consider myself a "believer" in anything, but as a
| sysadmin, if I see a deploy with ext4, I classify it as a
| newbie's choice or someone stuck in the 80s. It's not a
| matter of conviction; it's simply about managing your data:
|
| - Transferable snapshots (zfs send) mean very low-cost
| backups and restores, and serious desktop users don't want to
| be down for half a day because a disk failed.
|
| - A pool means effective low-cost RAID, and anyone in 2026
| who isn't looking for at least a mirror for their desktop
| either doesn't care about their data or lacks the expertise
| to understand its purpose.
|
| ZFS is the first real progress in storage since the 80s. It's
| the most natural choice for anyone who wants to manage their
| digital information. Unfortunately, many in the GNU/Linux
| world are stuck in another era and don't understand it. They
| are mostly developers whose data is on someone else's cloud,
| not on their own hardware. If they do personal backups, they
| do them halfway, without a proven restore strategy. They are
| average users, even if more skilled than average, who don't
| believe in disk failures or bit rot because they haven't
| experienced it personally, or if they have, they haven't
| stopped to think about the incident.
|
| If you want to try out services and keep your desktop clean,
| you need a small, backup-able volume that can be sent to
| other machines eg. a home server, to be discarded once
| testing is done. If you want to efficiently manage storage
| because when something breaks, you don't want to spend a day
| manually reinstalling the OS and copying files by hand,
| you'll want ZFS with appropriate snapshots, whether managed
| with ZnapZend or something else doesn't really matter.
|
| Unfortunately, those without operations experience don't
| care, don't understand. The possibility of their computer
| breaking isn't something they consider because in their
| experience it hasn't happened yet, or it's an exceptional
| event as exceptional that doesn't need automation. The idea
| of having an OS installed for 10 years, always clean, because
| every rebuild is a fresh-install and storage is managed
| complementarily, is alien to them. But the reality is that
| it's possible, and those who still understand operations
| really value it.
|
| Those who don't understand it will hardly choose Guix or
| NixOS; they are people who play with Docker, sticking to
| "mainstream" distros like Fedora, Ubuntu, Mint, Arch. Those
| who choose declarative distros truly want to configure their
| infrastructure in text, IaC built-in into the OS, and truly
| have resilience, so their infrastructure must be able to
| resurrect from its configuration plus backups quickly and
| with minimal effort, because when something goes wrong, I
| have other things to think about than playing with the FLOSS
| toy of the moment.
| chias wrote:
| I would certainly feel that way about an ext2 system. But
| ext4 was released in 2006
| dietr1ch wrote:
| > merely pulling in Nixpkgs is an effort, due to the repository
| being massive.
|
| I've embraced daily shallow clone/fetches and the burden is now
| mostly just the 2GB of disk space.
|
| It's a bit annoying though that git doesn't make it easier. No
| one would shallow clone later screw up and download every commit
| anyway, I feel shallow clone repos should be set up with a
| different configuration that fully-embraces shallow history (not
| that the configuration options even exist today AFAIK).
| dietr1ch wrote:
| I just tried 2hrs and it only uses 375M git
| clone \ --single-branch \ --shallow-
| since '-2 hours' \ --origin 'upstream' \
| gh:NixOS/nixpkgs
|
| What's annoying later is that you MUST remember to always use
| shallow fetch and hard resets into upstream/$BRANCH
| git fetch \ --shallow-since '-2 hours' \
| upstream \ master nixos-unstable
| aidenn0 wrote:
| I have a non-shallow clone and the .git directory is less
| than 3GB.
| dietr1ch wrote:
| Oh, maybe I had a full clone on my laptop before I started
| doing shallow fetches, but since fetching takes quite a
| while I've been using a shallow clone on my workstation.
| bsimpson wrote:
| I've only been doing this for a few weeks, so too early to tell
| if it's a good setup, but I added a GitHub Action that rebases
| my personal fork atop nixpkgs-weekly. I'm hoping that will help
| keep me from having a stale-by-default personal nixpkgs. (I use
| a personal nixpkgs to stage PRs waiting to be merged upstream.)
|
| https://github.com/appsforartists/nixpkgs/commit/769a72d3a6f...
| shevy-java wrote:
| I understand his enthusiasm with NixOS but:
|
| > With Nix, however, it was a matter of just describing a few
| packages in a shell and boom, Ruby in one folder, no Ruby (and
| thus no mess) everywhere else.
|
| This approach was already done by GoboLinux in 2005. And even
| GoboLinux was by far not the first - versioned AppDirs existed
| for a long time before; even perl stow enabled that. NixOS just
| uses a modified variant e. g. via hashed directory names. But I
| already adopted a similar scheme as GoboLinux did soon after I
| switched to Linux in 2005 (well 2004 but mostly 2005 as I was
| still a big noob in 2004 really).
|
| > I started adding shell.nix files to all my little projects
|
| I appreciate that NixOS brought good ideas to Linux here; having
| reliable snapshots is good. If a user has a problem, someone else
| might have solved it already, so you could "jump" from snapshot
| to snapshot. No more need for StackOverflow. The HiveMind took
| over.
|
| But with all its pros, the thing I hate by far the most in NixOS
| is .. nix. I think the language is ugly beyond comparison; only
| shell scripts are uglier. I instead opted for a less
| sophisticated solution in that ruby acts as the ultimate glue to
| whatever underlying operating system is used. What I would like
| is a NixOS variant that is simpler to use - and doesn't come with
| nix. Why can't I use ruby instead? Or simple config files? I am
| very used to simple yaml files; all my system description is
| stored in simple yaml files. Since +20 years. That approach works
| very well (ruby expands these to any target destination; for
| instance, I have aliases for e. g. bash, but these are stored in
| yaml files and from that ruby then generates any desired target
| format, such as also cmder on Windows and so forth).
|
| > In fact GNU forked Nix fairly early and made their own spin
| called Guix, whose big innovation is that, instead of using the
| unwieldy Nix-language, it uses Scheme.
|
| I am glad to not be the only one to dislike nix, but boy ...
| scheme? Aka Lisp? Seriously???
|
| Young people use lisp? I somehow doubt that.
| (cons* (channel (name 'nonguix) (url
| "https://gitlab.com/nonguix/nonguix")
|
| Erm, no thanks.
|
| Why would users know what cons* does, anyway? That's stupid.
|
| YAML files exist for a reason. Keep. Things. Simple. (I know, I
| know, many use YAML files in a complex manner with gazillion
| nested indentation. Well, they are using it in a wrong way, then
| they complain about how bad yaml is.)
|
| > Since the code is pretty much just Scheme and the different
| mechanisms available are fairly well documented (see caveat
| below), the barrier to entry is much lower than with Nix in my
| opinion.
|
| Can't evaluate this. To me it seems as if NixOS may have changed,
| but Nix was always a big barrier. I decided to not want to
| overcome it, since I did not want to be stuck with a horrible
| language I don't want to use.
| k__ wrote:
| I used both Guix and Nix and found both their languages okay
| for the use-case.
|
| Nix was slightly better, since it's easier to format
| automatically than Lisp.
| anthk wrote:
| >Easier to format automatically than Lisp
|
| You wish. Emacs did that for free since the 80's.
| AreShoesFeet000 wrote:
| I am young (29). I like computers because they are essentially
| something hacky. There's nothing more hacky than Lisp IMO. I
| will never complain about Lisp. I just like it.
| microtonal wrote:
| _This approach was already done by GoboLinux in 2005. And even
| GoboLinux was by far not the first - versioned AppDirs existed
| for a long time before; even perl stow enabled that. NixOS just
| uses a modified variant e. g. via hashed directory names. But I
| already adopted a similar scheme as GoboLinux did soon after I
| switched to Linux in 2005 (well 2004 but mostly 2005 as I was
| still a big noob in 2004 really)._
|
| Nix already existed in 2003. Besides that Nix store directories
| are more ingenious than versioned application directories (or
| hashed directories), the hash in the output path is the hash of
| the normalized derivation used to build the output path (well,
| in most cases, let's keep it simple). Derivations work
| similarly (also using hashes). Moreover, since a derivation can
| contain other derivations as an input, the Nix store represents
| hash/Merkle trees.
|
| This makes it very powerful, because you can see which parts of
| the tree need to be rebuilt as a result of one derivation
| changing.
|
| _But with all its pros, the thing I hate by far the most in
| NixOS is .. nix._
|
| I think it depends on your background. I did some Haskell at
| some point in my live and I like Nix. It is a very simple,
| clean, lazy, functional programming language. The primary thing
| I'm missing is static typing.
|
| _I instead opted for a less sophisticated solution in that
| ruby acts as the ultimate glue to whatever underlying operating
| system is used. What I would like is a NixOS variant that is
| simpler to use - and doesn 't come with nix. Why can't I use
| ruby instead?_
|
| Because what nixpkgs does is not easily expressible/doable in
| Ruby. First, the package set is one huge expression in the end.
| That might seem weird, but it allows for a lot of powerful
| things like overlays. However, for performance reasons this
| requires lazy evaluation. Also other powerful abstractions
| require lazy evaluations (e.g. because there are some infinite
| recursions in nixpkgs).
|
| Second, the Nix packaging model requires a purity (though this
| gap was only properly closed with flakes). You have to be able
| to rely on the fact that evaluating an expression evaluates to
| the same result. Otherwise a lot of things would break (like
| substitution from binary caches).
|
| Third, things like overlays rely on fixed points, which can be
| done easily in a lazy functional language.
|
| ---
|
| Having used Nix for 8 years now, I have a long list of
| criticisms as well though :).
| hombre_fatal wrote:
| Bikeshedding over the language is a huge waste of time, too.
|
| I haven't written a line of Nix since I started using it, yet
| it defines three of my systems. I just read diffs that an LLM
| created when editing my config.
|
| Making a big deal about the language substrate feels like
| someone still trying to argue over vim vs emacs. It's trivial
| and uninteresting.
| aidenn0 wrote:
| > I am lucky enough to live in a household with fiber-optic
| internet, that merely shrugs at bandwidth of up to a gigabyte per
| second...
|
| Probably a typo, unless the author really has 8gigabit network
| peter_d_sherman wrote:
| >"But NixOS isn't the only _declarative distro_ out there. In
| fact GNU forked Nix fairly early and made their own spin called
| Guix, whose big innovation is that, instead of using the unwieldy
| Nix-language, it uses Scheme. Specifically Guile Scheme... "
|
| I'd be curious if a list exists of _all declarative Linux
| distros_ out there, along with the configuration language (Nix,
| Scheme, etc.)
|
| I'd also be curious as to how easy it would be to convert Scheme
| to the Nix language or vice-versa, in other words, it seems to me
| that there might be a "parent language" (for lack of a better
| term) out there for all lisplike and functional programming
| language (a subset of Haskell, F#, or some other functional
| programming language perhaps) that sort of might act as an
| intermediary conversion step (again, for lack of a better term!)
| between one functional or lisplike programming language and
| another...
|
| Probably unrelated (but maybe somewhat related!) -- consider
| Pandoc... Pandoc is a Haskell program that basically uses a
| document tree structure to convert between one type of document
| format and another... maybe in terms of programming languages
| you'd call that an AST, an Abstract Syntax Tree... so maybe
| there's some kind of simplified AST (or something like that) out
| there that works as the base tree for all functional and lisp-
| like programming language (yes, lisp/lisplikes sort of preserve
| its/their own tree; their own AST -- via their intrinsic data
| structure, and that would seem to be true about functional
| programming languages too... so what is the base tree/AST of all
| of these, that all languages in this family can "map on to" (for
| lack of better terminology), that could be used (with AI / LLM's)
| as an "Intermediary Language" or "Intermediary Data Structure"
| (choose your terminology) to allow easily converting between one
| and the other?
|
| Anyway, if we had that or something like that, then Nix
| configurations could (in theory) be easily converted to Guix, and
| vice-versa, automatically, as could any other Linux configured by
| a functional and/or lisplike language...
|
| That, and I found the article very interesting!
|
| I may have to try Guix in the future!
___________________________________________________________________
(page generated 2026-01-31 23:00 UTC)