See also
45 Likes
Note that it also replaces NixOS modules with a more package-like approach.
Maybe I should consider porting my setup (also package-like) on top of that…
9 Likes
This is really interesting! For me, modules often feel clumsy: when it works, it works magically, but when it fails, it fails spectacularly 
Also I always miss .override(Attrs) when dealing with modules. The package-like services and the “infusion” interface seem like very nice alternatives.
FYI here are the slides:
7 Likes
Ah, thanks for the link! Personally I find systemd solves far more problems than it causes, and some of those slides still feel like they’re seeing some grand conspiracy where there isn’t one, but nonetheless it looks like very interesting work: systemd is still a bit heavy for the low-end of the embedded space, and the alternative to the module system is definitely intriguing!
9 Likes
I don’t have any strong opinions on systemd vs other init systems, but I am super interested in the alternative to the NixOS module system. I hadn’t heard of infuse.nix before, I’m going to have to experiment with it in my own configuration. Really awesome project!
8 Likes
Very interesting talk! If you search for infuse here on discourse it has been mentioned before with examples, the author is here as amjoseph.
3 Likes
This talk is outstanding. The infuse operator shows a lot of promise for composability, and also would help with the problem of not being able to instantiate multiple copies of a module unless the module supports it. The example of just how much more simple nested overrideAttrs gets is quite impressive too.
I really hope we can take some of these changes even if we’re still partially stuck on systemd - it eliminates vast swaths of boilerplate required to do complex things with nixpkgs.
6 Likes
Even the terminology is simpler to understand and explain - __input and __output are easier to intuitively understand than args vs attrs for new users.
4 Likes
By this talk, I think @amjoseph is nowhere. I hope he found a new home already.
Notes I have for him:
- What you think about nickel?
- created to be Nix with type and maybe someday replace nix
- Modules has “override options”, but packages aren’t modules
- check Aux Foundation and drv-parts (that now was merged with dream2nix) to packages as modules
- But I think infusion would be easier to integrate with nixpkgs.
- There were other attempts to use S6 before, for embedded (???) and docker, have you tested it?
- S6-init can be replaced by S6-svc as PID 1 after boot, at least s6-rc used to states something like that, it works?
- S6-rc is ready? Last time I checked (2 years ago), S6-svc was ready but s6-rc wasn’t, may break your expectation with stable interface.
- Have you played with Skabus (skarnet dbus)?
- Great work, I always hoped to something like that.
1 Like
Also there is a massive muti year thread here on discourse that I can’t find rn about alternatives to systemd but its interesting that no one so far has tried this. I may be wrong of course. Does that mean most users are kind of more devops/packaging oriented instead? I mean this in the way archlinux spawned lost of distros based on it. Yes the declarative nature of nix makes it that every user distro builds his world around it… sorry something is itching me about this amjoseph situation and this project and infuse. Or I just may be too open about my naive assumptions. Again really inspiring talk!
1 Like
What «this»? There multiple non-NixOS Linux+Nixpkgs systems setups lying around on the net.
2 Likes
Oh I see, yeah I was thinking of this thread
1 Like
Not exactly true, not-os/systemd-compat.nix at 79ff6e6fe0b64bf8b8d38363b2bb0dea0cd5a686 · cleverca22/not-os · GitHub for example also lacks systemd support but still apparently boots.
However, sixos claims to support a more full-fledged desktop environment. And as it took him two years already, I’m not surprised that not many others have spent that kind of effort. Especially given the mass rebuilds involved (though some shared infra could alleviate?)
2 Likes
There are nuances about how much effort all that actually takes, why it is hard to report correctly, and why it does not typically end up with a direct NixOS competitor.
Basically, a few weeks is enough to have an OK GUI working environment without the parts you want to throw away. Guess how I know. There are a few feasible tricks how to reuse some parts of code from NixOS (e.g. I still use some configs generated by NixOS code) to speed things up.
Then of course infuse is separately a very cool thing and it took effort to design and implement, and probably quite a lot. I am a cheapskate, I use makeExtensible.
And then the point is — if you have detailed tastes, getting something to a level where customising it «properly» is easier than forking is a huge amount of work, and anything between «works for me» and «properly cusomisable» is not that much better than «works for me» for the next opinionated user.
Oh, and speaking of rebuilds — for most approaches those are cheap. The expensive stuff is compilation of executables — I use Nixpkgs and the binary cache for those. Whatever I do to generate configs has some overhead but not in the same class as compiling LibreOffice or Chromium or even wxWidgets.
4 Likes
Very interesting! How does this fit into the bigger scope of user configuration? Can this be combined with Home manager or what would be the intended mechanism to configure users?
1 Like
this is amazing. I wonder if there’s a way sixos can compromise and reuse packages from nixpkgs with systemd dependencies (mostly udev?) anyway to avoid massive compilation. That can help with adoption imo.
Just watched this yesterday, and I’m very impressed! infuse is very elegant, and the bootloader that allows actual verified full-disk encryption is an amazing USP. I’m itching to get this onto my Macbook2,1 as a replacement for Parabola.
2 Likes