deleted by creator

Active GuixSD user.

Our application catalog is much smaller than many other distros simply because we don’t have the userbase large enough to surface the volunteers necessary to support it. So you will have to learn to write your own packages eventually

That said, if you know your way around functional languages (in this case, scheme), it’s probably the easiest time I’ve ever had writing a package. Everything that goes into the script is known at the time the script is written, so weird extrinsic problems don’t really occur after you’ve written the package.

Some stuff that you and the guix maintainers may not have the time to support will also get updated more slowly.

Luckily flatpak exists, and is a godsend for the new wave of read-only (functional/ostree-based) OSs.

Biggest appeal for me was having all my configuration in one place (and documented) so if I forget I did something in 6 months, it’s always staring at me in my home or system config file. You can accomplish the same thing by being diligent with say, script files, but it’s drop-dead easy to just maintain a system and home descriptor file and keep editing that.

Set aside a few weekends and mess around distro hopping. Think of it as a small scientific study. Use what you determine to be the most comfortable with.

I suggest being clever in your partitioning keeping /home and any other areas personal to their own partition if not their own disks. If you want to experiment you lose nothing by wiping / and installing something else. Also, you should decide on an effective backup strategy.

I put about 150 hours into NixOS before I was really “done” setting everything up. (Of course, it was completely usable way before that.)

The biggest advantage to me is that that was the last time I will have set anything up. If my laptop or PC or both get thrown into an incinerator tomorrow, I will go buy replacement hardware and will have my exact same setup done in less than 10 minutes.

I used to have serious anxiety about losing my setup with Arch - over the years a lot of config amasses, and sure you can back up your dotfiles, but you better do that after every change, and don’t forget to manually track your changes to /etc, /usr, and so on.

Right now, I am enjoying the most seamless development setup I’ve ever had. That being said, you will have a BAD time unless you embrace nix shells for development (at which point the pip/venv stuff becomes easy, too)

You are right, it’s a steep learning curve and you will have to invest some time initially, but it frees you up in the long run

I went from Arch to NixOS, so I can offer a bit there.

You definitely won’t want to rely on it until you know a good amount and get comfortable. Things can be made to work, but knowing how to get it done is the main thing most of the time.

Regarding package availability, it’s just a matter of a few oddly esoteric incantations and version controlled code, usually. Binaries are another story but still possible, and python is a special case of that.

It has been an annoyance for me, but I’ve also learned a lot by getting things to work. If you use any niche python stuff you’re bound to run into something. A bunch is already packaged and works fine, though. Either way there’s a bit of extra nuance, which is more to learn.

You don’t have to start with NixOS and can feel it out using nix on any distro. It can be hard to tell if someone will vibe with it. All that said, it could be more than you’re looking to get into, but you can ease into it if you’re interested.

Question: What are you developing?

With that said, NixOS would probably be fine, if not better than fine. From what I can tell, I don’t think Guix would be a good idea - the packages appear out of date, according to their package manager. They’re still on Python 3.10.

However, I might recommend Debian Testing to you for your purposes. Most of the time, packages are pretty recent, maybe a few months old at the most (sometimes just a few weeks), but you still get most of the stability of regular Debian. The only asterisk is when the freeze happens. I think apt may have gotten some updates as well.

I’ve been using it on my desktop PC for over two-and-a-half years. I will say I have grown a bit weary of it, as it gets so many updates and software changes so fast. On my laptop, I went with stable and plan to switch or stable on my desktop once Trixie gets stable.

In brief, Testing isn’t bad. I’d almost recommend a development VM.

As a Gentoo user:

If setup correctly, absolutely.

Otherwise, it’s a nightmare.

I’d say in most case, you’d want to pick something simple to get you up and running, as well as to set a baseline.

If it’s work related, I wouldn’t go anywhere near anything that isn’t based on Debian, Ubuntu, or Red Hat.

I use nixos for dev all the time, personally I think it’s great

What I would suggest however is to install the nix package manager on another distro, learn how it works that way and then switch when you’re comfortable only using nix

Flakes are absolutely incredible for development and I think every project beyond scrappy scripts should use them.

You can specify all your dependencies (compiler, libraries, cli tools, environment variables etc) in your nix flake, then run nix develop and it’ll make you an isolated shell with all that stuff

(For example, I don’t have go, rust or dotnet installed but when I cd into one of my projects directors it installs them to a temporary shell and catches them until I clean up)

The flake also generates a lock file which specifies every version of every dependency with a git rev and a hash, meaning if you check flake and lock into git, anyone else who clones that project and uses the flake gets the exact same system you were using

ive used gentoo a lot, a big downside is the amount of time spent compiling, if you need to install a lot of softwares frequently it could be difficult. (though you can use --binpkg options to install binaries and some packages have a packagename-bin variant, and flatpaks + appimages are a thing) if your software needs rarely change than it can be fairly painless.

the customization and speed are rivaled by almost nothing except for something like LFS. the package availability is great. you can also use custom patches easily as well as disable or enable specific software features (USE flags) . you can choose what packages stay at stable versions, testing versions, or even bleeding edge (-9999 version tags)

for a more “standard” distro, i would recommend artix. it’s an arch based distro with your choice of init system (as a gentoo fan ill recommend openrc). i used the graphical installer to get it setup and it was a breeze. due to not being source based, and having access to the AUR you can quickly install any package you want.

ive had it in my laptop for years and have been recently using it on my main pc for about a month.

additionally regardless of distro (besides immutable ones), id recommend installing timeshift for backups, it actually doesn’t require btrfs! ive used it with both ext4 and F2FS and doing a quick backup before an update has definitely saved me a few headaches.

feel free to ask me any follow up questions

All of the cool development-related Nix things like pinning a project to known-good library versions (for regression tests or otherwise) don’t really need you to run NixOS. If you like NixOS then it’s a perfectly usable distro for development work, but all of the powers come from Nix itself, and that can be installed anywhere you feel comfortable with.

The only real pro of running full NixOS is that everything you work on will test a relatively uncommon *nix setup by its nature. Things like developer-only scripts with hardcoded #!/bin/bash shebangs are more likely to break on NixOS than they would on a conventional Linux distro with Nix installed. That’s something potentially worth fixing as it might also hurt the developer experience on *BSD/Mac systems.

Gentoo is its own thing. You can bump packages yourself a lot of the time with a few commands. Or have the package manager install directly from upstream source control, if that’s your bag. Or you can hold on to older package versions for periods ranging from months to years, by stashing ebuilds in a local repository. At the same time, portage has reached the point where it bends over backwards to keep you from breaking stuff by accident. If you’ve done your setup right and use primarily stable keywords, breaking changes are very rare. And you’re free to install things outside the protection of the package manager, or package things yourself if you don’t mind working with bash scripting.

The tradeoff for all of this is that you have to spend a fair amount of time setting up and configuring stuff, and a fair amount of time compiling software if you want a USE flag combination other than what’s on the binhost. It also helps to spend time learning the ins and outs of the portage/ebuild ecosystem if you’re going to do anything unusual.

As for the proprietary nvidia drivers specifically, Gentoo currently has versions 390.157, 470.256.02, 525.147.05, 535.183.01, and four different 550+ available, which should cover most hardware of the past several years.

If you want to see whether certain software has been packaged without installing Gentoo, the best place to check is gpo.zugaina.org. The search function isn’t all that bright, but it’s the only site I know of that indexes all the official overlays and the Gentoo bugzilla along with the main repository.

I use Guix Home on my laptop (on top of Asahi Fedora Remix) and started trying to use Guix System on my server a while ago. Here’s some points I have:

• The declarative configuration system is fucking awesome and makes Debian feel like the stone age. It does have a high learning curve though but it is definitely worth it.
• When deciding between Nix vs Guix, I ended up settling on Guix because Nix seemed more focused on marketing and cutting corners to make a working product faster and Guix seemed more like a community project with better ideological goals behind it. However, I have hardly used Nix so take this with a grain of salt. Also, Nix has a lot more packages and is closer to being production-ready and in a business setting I would probably choose Nix for the project instead because of that, it also is compatible with macOS and Guix isn’t.
• The Guix package manager is source-based and the repos are committed to 100% free software which I really like compared to Nix which just throws binaries in their repos. However, this means that they need to package everything to work within their ecosystem as if they are packaging for an entirely different OS, and this is often very time-consuming, especially for packages with hundreds of dependencies. Combine that with the community being very small and niche, and repo under-maintenance is a very serious problem. Many core packages are outdated, which also seems like a security hazard. If you’re expecting to use a bunch of new Rust-hype programs or something that isn’t mainstream, they probably aren’t there (you may find them in an obscure third party repo however). Some core libraries made significant changes to their build process when they updated that haven’t made their way to Guix so they may be stuck on an old version until someone decides to update it. If there’s a package you need, expect to either package it yourself or download it with a different package manager like Nix or Flatpak.
• Most modern hardware requires proprietary blobs and you’ll need the nonfree Linux kernel from the nonguix repo. SystemCrafters has an installer image that comes with that IIRC.
• You may be interested in an “Erase Your Darlings” system configuration (do not save filesystem state to disk except for files/folders explicitly opted-in, requires even more upfront configuration but helps ensure reproducability). Nix has that built in. Guix doesn’t, but if you fuck around enough with the partitioning you can get it to work. I have a setup with BTRFS and subvolumes that took me a week to figure out and I had to do some hacky setting to make it work correctly with Grub. Also it’s more difficult to do when you don’t know how Guix’s file structure is laid out or are unfamiliar with the tooling and configuration language, there aren’t really any good tutorials on the internet for it either so lmk if you need any help (it doesn’t have disk encryption however since it is on a VM).
• If you want to make sure your system stays pinned to specific software versions, the way I do that is I have a channel.scm which has the channels like normal. Using the just command runner, I have a Justfile in the directory where I store my configuration. just update runs guix time-machine pointing to the channel.scm which pulls the repo’s updates then after the -- has the command that prints the channels with the specific commit to channel.scm.lock. For every other guix command, such as the reconfigure command, it uses guix time-machine pointing to channel.scm.lock then the command I want after --.
• Flakes is probably the most hyped feature about Nix, which instead of using a central repo for all software lets each project turn their git repo into a source for the package manager which can point to other repos it depends on. Guix doesn’t really have this feature, but since its main goal is creating an ecosystem of completely free software, I would argue that the centralized approach is better for this project since it helps GNU achieve this goal and provides guarantees about the freedom of the software and the packaging quality. Guix also makes it easy to create your own repo for packages or turn your project into a repo for a package, but it can’t refer to packages outside of the repos that are listed as sources on your local setup so it isn’t really flexible like Flakes.
• It also uses Shepherd for its init system which uses the same configuration language as the rest of the system. Compared to systemd I am not sure which is principally better, however it provides an additional roadblock to packaging software since most stuff is designed around systemd-based distros.
• This project is niche and has very few resources for help aside from the documentation, the source code (there seems to be quite a bit of undocumented stuff so you’ll probably end up browsing it sooner or later), IRC/mailing lists, SystemCrafters, and a few random blogs or git repos. ChatGPT fucking sucks at Guile and it spits out code that is about 80% incorrect so actually learn Guile and don’t use ChatGPT (sometimes it gets the parenthesis wrong too which is kindof hilarious).
• Setting up Emacs, a local SMTP server connected to your email for git, and a CLI password manager will probably be helpful.
• Have a copy of Guix cloned on your computer so you can browse around and see how stuff works (especially packages and services). It’s the same language as the system configuration language which is helpful. The documentation also has a guide to set it up for contributing which you may be interested in at some point.
• The contribution process is weird, it uses a lot of command line tools which I kindof like but it also has a learning curve which doesn’t help with the contributor shortage. Also it seems like a lot of patch requests get ignored and in some cases how to contribute is confusing. I was trying to contribute a Rust program once but it added hundreds of libraries and when I submitted it months ago it got ignored so I don’t know how I am supposed to contribute these sort of programs and the mailing list/IRC didn’t give me much advice either.
• For finding packages, there’s https://toys.whereis.みんな/ which shows stuff from nonguix and other repos you’ll probably want.
• For making your own packages, the guix import feature can be helpful and works nicely with Rust, especially if the program you want is in crates.io in which you can put it in your packages repo very quickly.
• For using Guix for software projects, there aren’t a ton of libraries packaged so you’ll need to see if your language is supported by guix import. The Node.js ecosystem is allergic to FOSS so it might not work very well with Guix (there are barely any Electron programs packaged outside of nonguix also).
• guix profile and guix home are confusingly different. One uses imperative install commands and the other uses a declarative configuration and they install into different directories, so if you remove a program from home but it’s still there it may still be installed in profile.
• Most packages should be installed using guix home and don’t need to be installed systemwide. It also provides powerful containerization/environment management tools to isolate installs efficiently.
• For server stuff, Shepherd has a sandboxing feature I’ve experimented with a tiny bit that isn’t well documented (if at all), I haven’t tested it in a while though but with it you don’t really need to containerize stuff. I haven’t figured out how do manage the networking correctly but there’s probably ways to do that as well.
• For servers, trying to package Node projects that aren’t in a single binary sucks.
• For desktop usage, I would recommend installing Guix Home on your current distro first and experimenting with that before doing a full system install (which is what I’m doing right now since being on a Macbook adds additional complications). You can do the same thing with Nix home-manager also.
• Guix and SELinux don’t really get along, on Fedora you may need to disable it (I don’t know how to use it correctly with Guix) which weakens security (which on Linux security kindof sucks). This is a problem with Nix as well.

To address your points:

The Debian/Fedora based ones seem to be fairly slow to update and so they have out of date packages, which sometimes is ok, but sometimes if they are too out of date I have to compile it from scratch.

Fedora is way more up-to-date than Guix is. Also Guix is source-based so it may end up compiling stuff from source automatically. You can install Nix though if you need it which looks a lot more up-to-date.

I end up spending a lot of time configuring stuff that isn’t built in

You’ll be spending a lot of time configuring stuff with Guix as well. However the declarative style makes it a lot easier to track and maintain.

having stuff randomly be broken after an update

Libcamera broke pretty recently on my Guix install which broke a ton of programs although it might be fixed now. If that happens though you can revert to your previous configuration or pin the repo to an older version until it gets resolved. Normally packages are checked when they are updated though to ensure they don’t break stuff.

I don’t have a lot of time to mess around with configuring stuff all the time.

You’ll need to spend a lot of time learning stuff since there’s very few tutorials on the internet.

Ideally I’m looking for a distro that works well with my old-ish hardware (with NVIDIA support unfortunately)

IDK if nonguix supports NVIDIA or not but it might be a problem.

if the library is designed to use like ‘pip’ or ‘bun.sh’ or some built in package manager

You can still use other package managers, but you can’t use them to package the program specifically for Guix. You may have luck using guix import instead however. Also bun.sh is an example of a non-mainstream program that probably isn’t in the Guix repos.

Gentoo user here. It can be great for dev as you have everything that is required to build the software you’re running assuming you’re trying to produce something using the same base. Ie C++ with Qt for KDE etc.

It’s also a lot easier to build your own repo and packages with than any dev setup I’ve seen, it’s literally just a text file.

It does take a while to compile. However you need opinions to use it… Otherwise you will just have useflags enabled on everything. It does require a bit of understanding of how linux is built but the guide does most of the work for you, and it’s easy to install on an existing system. If you’re using btrfs you can install it on a subvolume and try it out easy.

However I used it during the 00s and 20s… But not the 10s. The difference is that software is moving way too fast for distributions to keep up with, so you will definitely want to build your own ebuilds at some point. Emerge / portage can sometimes cause issues upgrading too. But nothing a btrfs snapshot can’t save you from.

You answered the most important question when another person asked it.

You aren’t developing anything, so a distribution for development wouldn’t be necessary. If it were, it would be the distribution closest to the target environment.

You’re learning, and anything is fine. Someone said Debian testing, that’s a good choice. You just want stuff to work and spend the barest minimum amount of time fiddling around with your environment so probably not Linux at all.

You’ll find that the overwhelming majority of support materials in every language you listed will use windows or can be effectively used in windows. If you really need the Unix environment, they will probably first have examples in macos.

So maybe consider using windows or macos.

You’re not going to have an easier time learning2code on some esoteric distribution.

How about docker/podman container?