nonguix VS dhall-lang

I use the nonguix channel for non-free stuff https://gitlab.com/nonguix/nonguix. It has the mainline linux kernel (instead of the free linux-libre), proprietary drivers and a bunch of other proprietary stuff.

Guix has these things called "channels" containing package definitions. They're actually just git repositories. nonguix was made to have nonfree stuff. It has a lot of stuff including the mainline linux kernel.

https://gitlab.com/nonguix/nonguix you can use non free software if you need to. But the project itself is a gnu project and as such should not encourage users to use non free software.

I think Guix approach is good, community helps with open-source packages, some third-party manages the non-free channels. And they are as easy to use

https://gitlab.com/nonguix/nonguix

There are flatpacks, snaps, appimages, PPAs, channels... why would you except a linux distro maintainer to work for free for a billion dollar company? Testing and maintain their software

My background consists of using/developing Guix, openSUSE/SUSE as well of OBS. I'm a co-maintainer at nonguix, where we provide non-free software which is not allowed at upstream Guix. We even run our own little build service, called Cuirass. This softwore is developed mostly by https://www.reddit.com/user/mothacehe/ :)

$ guix describe Generation 22 May 15 2022 19:02:44 (current) guix 9860c90 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9860c90e8e5362e0e843efbd45f4563b9746a196 guix-gaming-games 9924ad0 repository URL: https://gitlab.com/guix-gaming-channels/games.git branch: master commit: 9924ad0a66f98ea1b538761fd49521acf4f689a3 flat 094746c repository URL: https://github.com/flatwhatson/guix-channel.git branch: master commit: 094746c1e2e90f2df1e598ab1fd0abb4d75ce84d nonguix 1de0c32 repository URL: https://gitlab.com/nonguix/nonguix branch: master commit: 1de0c32142c54bc73af5556d5e45c77152b31f0f

Thanks for the link. Although I was just planning to follow the steps in the https://gitlab.com/nonguix/nonguix repo.

You'll want to read about "channels" which are additional software repositories you can include in Guix from anywhere, There are other channels, but the main one for non-free is https://gitlab.com/nonguix/nonguix

Even GNU Guix System (which is a fully libre, FSF approved distro) can be used to install non-free packages. All you have to do is add the nonguix repository.

Fail to see how this is any different than Dhall (https://dhall-lang.org/) other than it produces plists too.

Kubernetes config is a decent example. I had ChatGPT generate a representative silly example -- the content doesn't matter so much as the structure:

https://gist.github.com/cstrahan/528b00cd5c3a22e3d8f057bb1a7...

Now consider 100s (if not 1000s) of such files.

I haven't given Pkl an in depth look yet, but I can say that the Industry Standard™ of "simple YAML" + string substitution (with delicate, error prone indentation -- since YAML is indentation sensitive) is easily beat by any of:

- https://jsonnet.org/

- https://nickel-lang.org/

- https://nixos.org/manual/nix/stable/language/index.html

- https://dhall-lang.org/

- (insert many more here, probably including Pkl)

There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that.

Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area.

Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful.

Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not.

[1]: https://stackoverflow.com/a/1732454/223424

[2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

[3]: https://dhall-lang.org/

Dhall: Dhall is a programmable configuration language that combines features like JSON, functions, types, and import capabilities. Its style leans towards functional programming, so if you're familiar with functional-style languages such as Haskell, you might find Dhall to be quite intuitive.

I've been thinking along these lines but more 'strongly validated' than statically typed in the sense that you'd be better off being able to load the entire config and then produce a list of problems (and should be able to offer good editor support if done correctly).

Though https://dhall-lang.org/ demonstrates that you can statically type quite a lot of configuration to great advantage, which appears to be programmatically embeddable in multiple languages per https://docs.dhall-lang.org/howtos/How-to-integrate-Dhall.ht...

> Where practical is in the sense of an engineer (or in their terms, a CS practitioner),

Configuration processing. E.g. I'd like my yamls to be decidable, though I'd settle for guaranteed to halt[1].

[1] https://dhall-lang.org/

Maybe you'd like jsonnet: https://jsonnet.org/

I find it particularly useful for configurations that often have repeated boilerplate, like ansible playbooks or deploying a bunch of "similar-but" services to kubernetes (with https://tanka.dev).

Dhall is also quite interesting, with some tradeoffs: https://dhall-lang.org/

A few years ago I did a small comparison by re-implementing one of my simpler ansible playbooks: https://github.com/retzkek/ansible-dhall-jsonnet

And to checkout Dhall: https://dhall-lang.org/