Atemu

Note that, while the Nix package manager can technically run on OpenBSD to some capacity, that doesn't mean packages in Nixpkgs are compatible with OpenBSD.

I can't comment on the current situation from first-hand experience but I can say that there is no support guarantee as there is for Linux and macOS and that there is no binary cache either. You have to build everything yourself and I'm not even sure we can build even basic packages such as hello on BSDs yet.

NixOS needs what is IMO the killer feature of Arch: the wiki.

NixOS has a killer feature which obviates a wiki for most such purposes: NixOS options. They document themselves!

You don't need to look up a wiki on how to install and enable i.e. paperless and all the other services it depends on, you simply set services.paperless.enable and NixOS configures everything for you internally.

The option tells you roughly what it does internally and the other options provide pointers for things you might want to tweak about it. The services.paperless.extraConfig option for example tells you how to configure it (pointing to upstream documentation in this case) and even gives an example on what you might want to do.

Another example is how to install Steam. In Arch, the wiki must tell you all the manual steps required to enable multilib, install the steam package, install 32bit dependencies, yada yada.

In NixOS, you simply set programs.steam.enable = true;. Off to your games.
You wanna customise the Steam package to add additional flags, pass env vars or add additional packages your weird Linux-native indie game needs? programs.steam.package tells you how to do that right in the place where you do it.
While you're looking for steam, you might also come across hardware.steam-hardware.enable which you need to set in order to make your Valve Index and Steam Controller work properly.
You wanna start Steam in a gamescope session right from the display-manager? programs.steam.gamescopeSession does it for you. No need to copy paste some snippet that you'll instantly forget about and maybe breaks in a few months. programs.steam.gamescopeSession is maintained upstream by NixOS, so if it breaks, someone will go and fix that and nobody needs to adjust any of their copy-pasta because they'll just update as they always do and it just starts working again.

None of this is perfect yet and the quality of documentation of NixOS options really varies but I think you get the idea here. I already rarely look at the NixOS wiki to configure my system because the system configuration tells me what I need to do already and this will only get better as options get refined.

the promise of being every bit as hackable as Arch

I don't think it makes that promise and I don't think it's true.

NixOS is about doing things "properly"; applying software engineering to software environment management.

Whipping up a quick hack is much more complicated and time intensive on NixOS than doing so on Arch because it's way more abstract. You can't just quickly replace some binary with your own compiled one, you need to use NixOS' systems to wire in the binary and build it with Nix to begin with.

Maintaining a system (even one with terrible hacks) is much simpler in NixOS however.

Nix (the package manager) does not depend on systemd in any capacity; just like apt, apk or Pacman do not depend on systemd.

NixOS currently uses systemd and cannot be ported without major restructuring. So far the enthusiasm to do that has been very limited. InitWare may be the path forward but that project seems to have stalled.
Note that NixOS also does not support any kernel other than Linux either.

Will the steps on https://codeberg.org/Kbin/kbin-core/wiki#admin-guide (but replacing the apt installs with adding packages in configuration.nix) just work

No, they will not. It's not about having packages available, it's about packaging it properly and configuring the system to accommodate it.

or is there a better, more reproducible way?

First you'll need to package kbin. This might actually be rather trivial since php does not involve a real build process AFAIK? See other PHP packages for inspiration.

Next you need to set up a module that internally declares a service and configures other services such as Redis or Nginx accordingly. Again, see other PHP modules for reference.

An alternative would be to use Docker/OCI containers to run kbin.

Question is whether you want that because that'd likely embed the secret into the .drv files.

What do you need that for?

Find ich on-topic und eine gute Frage ;)

In meiner Word-List gibt es 7776 Wörter und ich habe 6 davon, also 7776^6 Möglichkeiten. Entropie in bits ist der log2 der Möglichkeiten: 77.5 bits.

Ein Englisches Wort ist im Schnitt 7 Buchstaben lang; 6 Wörter also im Schnitt ca. 42. Es gibt also im Schnitt 42 Positionen, an denen das Zeichen durch ein Sonderzeichen ersetzt werden könnte und daher eine weitere Entropie von log2(42) = 5.39 bits.

An dieser Position wird eins von 32 Sonderzeichen eingesetzt, also nochmal 5 bits an Entropie.

I'd say anything that concerns the system (services, DEs, drivers, the kernel etc.) should be installed via the system package manager.

User apps and dev envs can be installed from anywhere else, including FlatPak, Nix or language package managers such as pip.

If you install anything that needs coreutils, libc, gtk, whatever Nix will install it automatically

That's not quite right. They will be installed (chances are you have coreutils installed right now) but only as in "it's in the Nix store"; they won't automatically appear in your PATH or other shared state directories. You'd have to explicitly install the coreutils package for that to happen. I do that on my mac for example because I want GNU coreutils rather than macOS' ancient modified BSD ones but, again, that's an explicit choice.

Some binaries may internally be wrapped to directly use Nixpkgs' coreutils rather than the system ones. One example I can think of is git-annex which checks for coreutils features at build time. Giving it different coreutils at runtime could cause trouble, so it always uses Nixpkgs coreutils via a wrapper.
That doesn't mean Nixpkgs' coreutils are "installed" into your system though, it's just prepended to git-annex' PATH. That's the beauty of Nix.

Manually.

There have been efforts to automate this partially but they've stalled.

found a comment claiming that there are 139 committers - but that comment is a few years old.

The current size of the Nixpkgs committers team is 197.

A key criteria for becoming a committer is to author a sizable number of PRs that go on to be approved through this process.

Not only that but also reviews and other community interactions.

You must be "known" among existing committers and have shown that you understand the "rules" of Nixpkgs; written and unwritten ones.

I didn’t see descriptions of any measures that would prevent committers from making whatever changes to nixpkgs they choose to.

That is correct. We could push any commit we wanted into Nixpkgs.

Others would (hopefully) notice though and there's a bot which tells you "nono, bad committer" when you push a commit without PR ;)

package hashes are not a cryptographically-secure proof of reproducibility - it is technically possible to tamper with binaries in some ways that don't change hashes

It's possible to tamper with the binary but not the source code. A substantial change in build recipe always causes a change in derivation hash. Malicious code must be introduced in source code form.

To tamper with binaries, you'd need access to Hydra; more specifically its signing key. Committers do not have that kind of access.

Personal reputations are at stake which I think is a solid motivator to act in good faith. I think if a malicious change did get in it would probably be caught quickly.

Well, that's the hope anyways. Thankfully, we haven't had this system abused yet but I'd be more comfortable if there was a better system in place. Especially w.r.t. removing inactive committers that haven't actually been part of the project for a long time.

Why did you link a kbin instance rather than just cross-posting?

my Fennec is having problem with googlw images

Interesting, mine isn't. My FP4 is running 4.19, so it shouldn't have the fix.

I use nightly though, so perhaps the fix is already in FF?