I use git primarily via cli also, the text editor integration (with helix) highlights information such as what lines haven’t been committed and makes it easier to access other files in the repo, the fish integration tells me if there’s files that haven’t been committed or commits that haven’t been pushed without having to run git status

As much as I hate GitHub, for in-person projects involving multiple people I usually end up having no choice since they usually think GitHub is the most important programming tool ever and nothing I do is going to convince them to create an account on something that’s not GitHub.

For personal stuff I use Forgejo and disable everything except the code view, so I have a quick way to show people stuff I’m doing (for career reasons).

If I was doing a project with multiple people and actually got to chose the platform I would probably use Forgejo or Codeberg and make use of the project management features.

Pijul looks interesting but the ecosystem is very lacking and it doesn’t integrate well with Guix which I base a lot of my workflows around, so until this improves switching to pijul creates more problems than it fixes. The only other VCS and frontend I’m familiar with is GitLab which I don’t use anymore self-hosted since Forgejo is more performant and the main version randomly deleted all my repos and changed all sorts of stuff.

cgit also looks interesting, I might look into it.

I considered using pijul but everything in Nix/Guix is oriented around git as are the plugins for my text editor and CLI, and there aren’t good self-hosted web frontends that I can use to put pijul projects on my linkedin profile or whatever. I want to switch to it but the ecosystem surrounding it needs to actually exist first.

I own an M1 Air running Asahi Linux because I heard very good things about the laptop when I got it and it was a reasonable price. I don’t have a Framework to test alongside it so I don’t know how it compares with the latest x86 chips. The M1 touchpad is awesome, aesthetics are great with it being light and the material being a lot more durable than my HP Envy laptop that kept getting random dents, doesn’t have the hinge misalignment issue, screen is also good. Battery life and performance is great on macOS, not as impressive on Linux (performance is still good aside from missing hardware processing support for certain things, I do end up bottlenecking it when compiling Rust programs), lack of fan noise is nice but also bad for cooling, with Linux it tends to get warm and throttle. Asahi Linux is very impressive but still missing microphone support and doesn’t support FDE which is extremely precarious, harder to use alternative distros to Fedora Workstation. Repairability is shit, the keyboard is also shit.

The newer M* models don’t have good Asahi Linux support and look overpriced and I don’t even know if the Air line still offers 16GB RAM models which is a must have (32GB is better). At this point in time if my Macbook were to randomly die my next laptop probably won’t be a Macbook (unless I replace it with another used M1), also I wouldn’t recommend it to most people right now because of issues with Asahi Linux being under development like the two I pointed out earlier.

A lot of people say it’s good although personally it hasn’t been a huge improvement for me, I’m guessing there’s certain hardware-software integration in macOS and software optimizations that contributes to the battery life that isn’t happening in Linux. It’s dying less quickly than my HP laptop though. I also tend to not close stuff so that may be a problem.

x86 isn’t open either and a lot of people like the M1’s efficiency (I’m an Asahi Linux user)

I have not maintained any packages before but I am very interested in learning how, I shall look into this.

The easiest way to learn this is to download the Guix source code and look in the gnu/packages directory to see how other programs are packaged and look at the official packaging guides/build system options/guix import options/guix refresh (updates package definitions)/contributor guides (if you want to set up the local Guix repo copy more correctly) in the documentation - gnu/packages also has certain files for running guix import in if a program you’re contributing needs dependencies that can be guix-imported. Simple things are easy to package, so are binaries if you’re just doing it for yourself and need something quickly (I think nonguix has a binary build system specifically for that as well), it’s programs that have a ton of libraries (especially with Python and Node.js) that are the problem since there’s no internet during the build process so running the project package manager won’t work.

I vaguely remember this was the originally used in Hurd? if so that is cool.

Yes, Guix System works with Hurd as well although I don’t see any reason to use it since it’s in an incomplete state and there are more interesting OS projects being developed like RedoxOS or Genode.

I have been wanting to set up upasfs this may be the push I need to finally get around to doing that.

Guix Home (and Guix System) has a services section in the documentation that has configuration options for certain things including email so I would suggest looking at that. (The Guix Home services also work on foreign distros.)

I will try installing it as a package manager

That’s the best approach to learning Guix IMO, especially using Guix Home. Once you have it fully set up on your current distro with Guix Home, you can copy your configuration to a Guix System install later on and replicate your current user setup really quickly. You can also return to your distro package manager quickly if you decide you don’t like it.

One other thing I forgot to mention is that Guix works weirdly with non-POSIX shells like fish and nushell so you might need to modify the configuration to automatically add the necessary environment variables or it will end up being stuck on an outdated Guix version randomly which will cause weird issues when you install/search packages or run guix pull.

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.

Meanwhile my university has a large CS program yet uses Windows for everything, even the fucking Unix class requires Windows/macOS exclusive software. I have no idea how we are ranked top 100 for CS

Fedora is a good middle ground, it’s what Asahi Linux uses as its official distro