Because the projects I want to contribute to are on Github, not some other forge. Also, I don’t want to create accounts on dozens of forges; each with their own settings and whatever; I also don’t want to have to put contributors to my projects through that, so if I want external contributors, Github is pretty much my only choice.

I don’t like it but until federation between forges is a thing, Github it is.

IIRC it puts a user owned directory inside the root. I have no clue what the total implications are in respect to privacy and security.

None.

The last time I looked the NIX solution to secure boot keys was to disable secure boot

Are we talking about Nix or NixOS here now? These are entirely different things.

Nix on non-NixOS does not care whether that OS can do secure boot or not.

As for NixOS: https://github.com/nix-community/lanzaboote

(Not sure what you’d actually want to achieve with “secure” boot as it doesn’t protect you against anything on its own.)

The idea of leaving it up to the user to figure out keys and self signing was a giant red flag for me.

The current support for secure boot in NixOS is rather experimental still. It’s the same as any other distro that hasn’t applied to RedHat to get their shim signed with a M$-trusted key, so I don’t really see your point here.

That aspect is also being worked on as we speak.

I didn’t care to figure out Keytool on my own to boot into UEFI and try to change them by force. That knocked NIX off my list of complete distros to run.

That’s your ignorance’s fault, not any distro’s. If you can’t be bothered to plug in your own keys, you limit yourself to the set of distros that are indirectly officially approved by M$.

I also ran arch for a few weeks once and am now extremely skeptical of any distro that presents anything that hints at “you figure it out yourself” complications for basic function. After Arch I went to Gentoo back when the Sakaki guide still worked and that was much more my style. I had something that just works, and made extra complications much more approachable. Specifically, I found documented entry points on things I didn’t understand, approached in ways I found useful.

If you need your hand held, the Nix ecosystem won’t be for you. It’s not really approachable by people who can’t research things in its current state.

Nothing wrong with that but Nix just isn’t at the point where mere mortals can reasonably be expected to be able to use it.

If I can stow all of my dotfiles, why would I use home-manager to handle them instead? In most cases it’s just going to be harder to configure anything, and you also need to rebuild your home every time you want to update a config.

Yes, yes indeed. That’s why my dotfiles are still in a git repo (don’t get the point of stow), not in home-manager.

If you do in fact need home-manager’s features for some of your dotfiles though, it can effectively act as a stow superset for the rest.

What benefits does it have over just using a shell script?

Declarative stateless configuration rather than imperative stateful configuration.

With a bash script, you’d have to meticulously craft together the i3config file using shell script syntax and remember to run that every time you change something. home-manager just does all of that for you with high-level data types and frameworks specifically made for that purpose.

that ties into another problem I’ve had when messing around with home-manager: the only source of options I found was mynixos. So to configure anything I had to first guess potential keywords to search for the option I’m interested in.

Yeah, it’s not great. https://search.nixos.org/options? is really useful for NixOS.

You have to either use your browser’s dumb search on https://nix-community.github.io/home-manager/options.xhtml or your pager’s dumb search in man home-configuration.nix.

Can you give me some examples, what issues will I face running MX + nix that I wouldn’t if I ran nixos?

All the issues which declarative immutable stateless system configuration solves such as atomic updates, configuration rollback in case you messed something up and trivial recovery. I’m sure I’m forgetting some since I’m so used to having them.

The main problem was getting started from 0, so I’m considering writing a post about it when I get a bit more comfortable. Trying to learn nix declarative package management from the nix manual is a bad idea, and almost all of the resources are on nixos. A quickstart guide with a few commands and examples would’ve had me up and running in 10 minutes instead of days.

Yeah, docs are a pain point. If you think that section is bad (I think so too), everyone will thank you for rewriting it. Feel free to shoot a PR to Nixpkgs and ping a few people from the docs team if you’re motivated.

Yet I never see it mentioned, while even beginner threads are being spammed with nixos recommendations.

I don’t get it either. NixOS is the best thing since sliced bread for a certain kind of person (experienced hacker who has felt the pain points which NixOS relieves) but I’d never recommend it to an inexperienced user in its current state.

It tends to get your software out there and used faster if you bootstrap the packaging

It’s fine to provide some sort of “official” binary package in some common format such as a Flatpak, Appimage or even just a plain old tarball but trying to package something for many different distros is insanity IMHO.

My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix.

it’s easy on most distros

It all depends on what you’re used to and how cursed the project’s build process is.
For sane build systems, I find it much easier to package for Nix now that I know its intricacies. I wouldn’t want to go back to weirdly sourced bash scripts without proper structured data types or any sort of abstractions or mechanism for extremely common patterns.

On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.

It’s the same for NixOS. When I encounter something that somehow isn’t packaged in Nixpkgs yet, I usually start out by simply packaging it in my local nixpkgs checkout.
There are handy tools to generate the little boilerplate there is and, if the package uses a reasonably standard build system, it usually only takes adding the dependencies and one or two tweaks to have a working package that is then also ready for submission to upstream Nixpkgs.

Federated Git has been a thing ever since git was conceived:

git send-email

Github is unfortunately the premier platform for collaborating with others to build FOSS. Until alternative forges support federation, any other forge is usually a dead end.

Currently it takes ~50 minutes to recompile the kernel. Are there any tutorials what drivers to disable to speed up this process?

Step 1: Buy a faster CPU.

The only thing you could do is ccache but that’s just a cache and can get invalidated whenever.

After doing that I will try to compile it with -O3 and LTO.

Don’t use -O3, especially when your goal is to harden. It has no measurable benefit beyond measurement bias due to memory layout changes and some of its optimisations may produce wrong code which is a big no-no if your goal is to harden.

install ClaimAV

Are you planning to host a file share for Windows system or what are you trying to achieve using ClamAV?

install flatpak versions for every non open-source app

You’re going to such lengths and even consider snake oil in order to “harden” your system and then you’re telling me you want to run proprietary (often known malicious) software on it?

What are you trying to achieve here? What do you want to protect against whom? Create a proper threat model before you wildly apply “hardening” that is likely ineffective at protecting against the threats that actually matter to you.

I also want to have SELinux.

Good luck with that. Distros with proper SELinux setups (i.e. Android, Redhat) employ teams of people to write SELinux rules for them.

I won’t discourage you from learning SELinux but know that setting up SELinux for your entire system when the distro does not support it already is not something you can realistically achieve on your own.

it uses a weird combination of your system libraries, installing its own libraries into your system on its own without informing your primary package manager, and using some specific library versions separate from your system libraries for some apps.

That is not at all true.

There is one explicit case where “system libraries” are used by Nix programs and that is graphics drivers. This is not done outside of NixOS as it does not trivially work there; it’s still an open problem. We can discuss about the reasons for this impurity’s existance and its intricacies but all that is important here that this impurity is the sole exception, not the norm.

Apart from that, Nix will never under any circumstances load (much less modify) libraries of any kind from any global path; system-controlled, user-controlled or otherwise. That’d be contrary to the fundamental principles of Nix.

It will always use “specific library versions separate from your system libraries” aka. the explicitly and exhaustively precisely declared dependencies in the Nix store. That’s the whole point of it.

I’d recommend you read up on Nix again and revise your opinion once you understand what it actually does because it’s clear that whatever source you had for information on Nix was entirely wrong.

I mean, you could, sure.

As a next sensible step though, I’d start firefox from the CLI with more verbose logs enabled.

A modem is a sort of “adapter” between physical mediums and protocols and sometimes also a router. It speaks DSL, fibre, cable etc. on one end and Ethernet on the other.

A wireless access point is similar in that is also is an “adapter” between mediums but it’s an adapter between physical and wireless. It effectively connects wireless devices to your physical Ethernet network (allowing communication in both directions) and never does any routing.

What you are typically provided by an ISP is an all-in one box that contains modem, router, switch, firewall, wireless access point, DHCP server, DNS resolver and more things in one device. For a home network, I wouldn’t want most of these to be separate devices either but at least wireless should be separate because the point of connection for the modem is likely not the location where you need the WiFi signal the most.

Note that Nix is not a full-blown programming language, it’s an expression language. The end result of an expression is always data and side-effects are not possible; you can’t do network requests or write to arbitrary files. There is no such thing as a variable in Nix either, only constants. You can think of it like JSON with (pure) functions and an additional data type (~package).

From a user perspective, it’s really not very different from any of the other 100s of weird configuration syntaxes you’ve surely come across in your Linux journey.

My nixos-config is a bit more complex because I like to reap the benefits that abstraction but here’s a simpler section that is representative of how a typical NixOS desktop config would look like:

https://github.com/Atemu/nixos-config/blob/ee2d85dc3665ae3cad463a3eb132f806651fe436/modules/desktop/module.nix#L16-L77

(Though note that even this is slightly more complex than what you’d do when starting out; ignore the LADSPA_PATH and tablet conditional for now.)

I can reassure you that it does not encroach on anything the “host” distro package manager does and does not cause conflicts with it.

At runtime, it only ever touches things in `/nix; it’s self-contained.

The only time Nix needs to interact with the host distro in any way is during install where it must place a little glue in your system configuration for things like PATH, bash completions or the nix-daemon to work as expected.

If you maintain upstream software and do not have an interest in learning and using Nix, please don’t put the burden of packaging software in Nix onto yourself. Nobody in their right mind would expect you to package anything for a dozen distros; that’s not how distros are supposed to work.

Leave it to someone who is interested to package your software in Nixpkgs. Your “job” is to make your software better and provide a sane way to build your software that packagers can rely on (i.e. no assumptions where things are or are supposed to go, document your dependencies and build processes).

If you do want to go the extra mile, offer your help in assisting packaging in the appropriate channels. You know the technical details of your software and Nix users how Nix packaging works but the reverse mostly isn’t true, so cross-pollination can be super helpful here.
Even just things like testing that your software works as you expect when the packaging is touched in some way (i.e. an update) is incredibly helpful. (If saw a package update PR with the upstream maintainer’s approval stating that it works as they expect, I’d merge immediately.)

If packaging for Nix is a burden for you, please just open an issue on Nixpkgs with links to your packaging/build documentation and let someone else do it for you.
As a Nixpkgs committer, I’d much rather have someone invested in Nix build and maintain a package than an upstream maintainer who somehow feels obligated to do so but has no experience or actual interest as the former is more likely to produce good code and keep maintaining the package.

There may also be purple protective cases.

You’re looking for a wireless access point then, not a modem.

Nothing I host is internet-accessible. Everything is accessible to me via Tailscale though.

My setup already goes quite a bit beyond basic file hosting.

There is no self hosted service I could imagine to need that I’d expect not to be able to host due to CPU constraints. I think I’ll run into RAM constraints first; it’s already at 3GiB after boot.

That’s impressive.

Yeah, you really don’t need a lot of CPU power for selfhosting.

It’s a J4105, forgot to mention that.

What do you use the system for? And services like PiHole or media server?

Oh, sorry, forgot to add that bit.

It’s mainly a NAS housing my git-annex repos that I access via SSH.

I also host a few HTTP services on it:

https://github.com/Atemu/nixos-config/blob/ee2d85dc3665ae3cad463a3eb132f806651fe436/configs/SOTERIA/default.nix#L57-L75

The services I use most here are Paperless and Piped.

Mealie will be added to that list as soon as the upstream PR lands which might be later this evening.

My Immich module is almost ready to go but the Immich app has a major bug preventing me from using it properly, so that’s on hold for now.

I do want to set up Jellyfin in the not too distant future. The machine should handle that just fine with its iGPU as Intel’s Quicksync is quite good and I probably won’t even need transcoding for most cases either.

I probably won’t be able to get around setting up Nextcloud for much longer. I haven’t looked into it much but I already know it’s a beast. What I primarily want from it is calendar and contact synchronisation but I’d also like to have the ability to share files or documents with mere mortals such as my SO or family.
The NixOS module hopefully abstracts away most of the complexity here but still…

Could you leave journalctl -f running while Firefox is starting? Anything interesting happening right after initiating the start and/or before it actually starts?

I for one am still waiting for paperless-ngnxn2-next-3.0_hypr.