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:
(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.
Federated Git has been a thing ever since git was conceived: