Nixpkgs: Support non-Linux kernels in NixOS

[boomshroom]

Nix itself supports many platforms including FreeBSD and Darwin, however NixOS is Linux exclusive. In the olden days, if someone wanted to try out FreeBSD, they'd have to install the whole system and dual-boot, but with NixOS, it's conceivable that one would be able to install multiple kernels into the same OS installation and switch between them at boot. While Linux applications wouldn't work on, say, GNU HURD, the Nix store would allow multiple versions of the same application where each is compiled for a different kernel. If I'm not mistaken, this already happens for people who share their nix-store between OS installations.

Naturally, porting all of NixOS to alternate kernels would be a monumental task, but I would like to at least throw the idea out there if someone decides to start pursuing it.

Obviously, this would require removing all Linux specific utilities from the core of NixOS, or at least making them optional. The biggest dependency that I can think of is Systemd. Which would make the first step of this task be to make NixOS services agnostic to the init process.

Known tasks. (To be updated with more specifics.)

• [ ] Remove dependency on Systemd.
  
  
  
  • [ ] Rewrite services to be init-agnostic.
  
  
  • [ ] Add kernel-agnostic init options to Nixpkgs.
  
  
• [ ] Improve package compatibility across more systems.
  
  
  
  • [ ] Make sure all core utilities are available for desired kernel or can be replaced by one that is.
  
  
• [ ] Provide build instructions for kernels other than Linux. (Already exists for GNU HURD)
• [ ] Provide configuration.nix switch for selecting kernels.

(I'm certain the tasks should be broken up smaller, but this is what I can think of right now.)

What do you think? Is this worth pursuing? Is this even feasible?

[AndersonTorres]

Well, I have purposed it some time ago, as a Google Summer of Code project. We have an "unofficial" repository for GSOC ideas [1], and one of them was creating NixOS versions using kFreeBSD instead of Linux.
Also, there was a small discussion in the mail list about making NixOS init-agnostic (today we are strongly tied to systemd).

P.S.: As a sidestep project, I am working alone and slowly porting Nix to NetBSD.

1 - https://github.com/teh/gsoc

[7c6f434c]

There are some attempts to abstract out some parts of services, but they always die out (partially because people wanting to use something other than systemd stop using NixOS, even if they still use Nix on some other system).

I think you should just use the existing functionality for converting systemd services to runner scripts until that becomes the biggest problem (hopefully at that point you will have more leverage and more understanding).

Adding build scripts for other kernels (probably some BSDs) sounds like something that is likely to be merged just because it is one more package with little global impact; and if turns out to be harder than you think, this part is a hard dependency of the entire project.

I am not completely sure what is your plan for the basic stdenv on top of BSD kernels, you need some minimal things even to boot. Do you have some cross-building plan in yout mind? Or do you want to bootstrap on real FreeBSD/OpenBSD/NetBSD installations and then update bootstrap tools in the same way as it happens on NixOS/Linux?

Once you have (2) and (2.1) being minimal non-Linux environment, you should be able to easily write some expressions generating minimal boot scripts. Services can be taken from NixOS via runner script export and also launched from the boot scripts. Then you will know what you need for integration.

My personal opinion is that the only thing that you want to modify on NixOS side is the bootloader config generation: currently NixOS assumes it is the only Nix-based OS in existence, which is already not completely literally true; if there was a way to have multiple profiles like system and to provide bootloader configuration parts that can be assembled together…

[boomshroom]

There are some attempts to abstract out some parts of services, but they always die out (partially because people wanting to use something other than systemd stop using NixOS, even if they still use Nix on some other system).

I suppose that's one advantage to doing it like this, as I don't care as much about systemd and it's inclusion in NixOS won't make me stop using it, but having the system tied to something like systemd means that it doesn't feel like Nix is reaching its full potential.

I think you should just use the existing functionality for converting systemd services to runner scripts until that becomes the biggest problem (hopefully at that point you will have more leverage and more understanding).

That seams useful, though I seam to have some trouble finding that so could read more.

As for the bootstrap problem, one possibility could be to build upon the existing build-vm option of nixos-switch. That said, I initially imagined that getting a bootstrapped system would be simpler than getting the core environment to work on FreeBSD.

[7c6f434c]

Well, maybe I would be more willing to consider extending NixOS if I could dual-boot it easier (testing X.org drver config in VM on a notebook is a bit too complicated for my liking).

As for taking stuff from NixOS, I currently use the following code (Linux-based system with packages only from NixPkgs, hand-written bootscripts):

{pkgs, nixos}:
{
  serviceScript = name: config:
    (builtins.getAttr name (nixos {configuration = config;}).config.systemd.services).runner;

  etcSelect = filename: config:
    let
      nixosInstance = nixos {configuration = config;};
      selected = (pkgs.lib.filterAttrs (k: v: v.target == filename) nixosInstance.config.environment.etc);
        source = (builtins.getAttr (builtins.head (builtins.attrNames selected)) selected).source;
    in (if pkgs.lib.isString source then source else source.outPath);
}

Unfortunately, some services neither put their configs in /etc/ not provide any way to access the config path from the outside via attributes.

As for bootstrap, I meant bootstrapping environment for not-currently-supported kernels.

[0xABAB]

This should be a project, not just an issue, because the task is huge.

[zarelit]

This issue depends on this one: https://github.com/NixOS/nixpkgs/issues/26067

[ghost]

Is there an enumeration of the linux specific features nix(pkgs) depends on somewhere?

Is there any nix language tooling that could help with the porting? I don't really have anything specific in mind with this, but perhaps searching nixpkgs for pieces of code that depend on a feature that needs to be replaced or something?

Is there a meta issue somewhere for collecting issues related to decreasing software lock-in?

Also, say we were to get another OS like say OpenBSD working somehow, how much of nixpkgs would still compile and run? What I mean to ask is, is there any merit to attempting a port instead of a rewrite? Of course I would prefer a port, but I'm wondering if it could even work.

[SRGOM]

I know this is a wishful post but I feel it's more likely and better if there were a BSD distro with systemd... I'd hate for systemd services from Nix to go away... (and doubling effort for multiple init services would probably be hard...)

[vcunat]

Systemd on non-Linux might be a pretty tough project by itself, I suspect.

[AndersonTorres]

Systemd on non-Linux might be a pretty tough project by itself, I suspect.

Yes, it is:

https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[pleappleappleap]

This is still important to me.