<{^_^}>
#26067 (by copumpkin, 2 years ago, open): Make a service abstraction layer
__monty__ has quit [Quit: leaving]
<gchristensen>
on one hand ... yes
<gchristensen>
on the other hand, it would make it hard to take advantage of systemd properly
<gchristensen>
on the third hand, it would be really good to find a way to make "nixos on wsl" work
<LnL>
you might be able to get there by replacing the systemd implementation using disabledModules
<LnL>
some of the problems of the abstraction layer remain however, since whatever you replace it with probably won't behave exactly the same
Drakonis has joined #nixos-dev
<gchristensen>
I wonder what it means to be "NixOS" on "WSL" minus systemd.
<gchristensen>
maybe a nix-wsl would be sufficient, like nix-darwin
<gchristensen>
ghuntley: is it wrong to say "whistle"?
<infinisil>
gchristensen: What systemd functionality are you thinking of that you couldn't take advantage of?
<infinisil>
I'm not trying to say there is none, I'm just interesting in thinking how we could abstract them
<qyliss>
I plan on getting s6 support in NixOS
<samueldr>
dependencies in services, tmpfiles
<qyliss>
I haven't had time to work on it for a while
<qyliss>
But I'd like it to happen and do want to put the work in
<samueldr>
not that those don't exist elsewhere, but making an abstraction layer means "dumbing" down to the most common features generally
<infinisil>
Nice
<samueldr>
and conversely, anything else having nice features systemd doesn't have means those features can't be part of the abstraction layer
<samueldr>
and the abstracted features can also differ in subtly incompatible ways
<qyliss>
You could still expose those outside the abstraction
<infinisil>
Hm yeah..
<qyliss>
Use the abstraction 80/20
<samueldr>
yes, exactly
<qyliss>
It's not going to be perfect, sure.
<Drakonis>
doesn't nix have this exact same situation with osx support?
<qyliss>
Or even musl support
<samueldr>
at that point it's a balancing act
<qyliss>
Not every package works with musl or Darwin out of the box, but lots do
<Drakonis>
you can't use more linux features because osx support is a thing
<gchristensen>
at that point, might as well just pretend to be the systemd thing
<samueldr>
drakonis: not really, nix on macOS doesn't aim to build a _system_
<samueldr>
it integrates with the system through nix-darwin, though that's external
<infinisil>
qyliss: But the things outside the abstraction can't be used to implement necessary functionality. Only to give extra bonuses, like maybe a bit more sandboxing or so
<qyliss>
Yeah
<infinisil>
So it's not terribly useful imo
<qyliss>
But I'd hope necessary functionality could be abstracted
* infinisil
nods
<qyliss>
Gentoo manages to support two inits
<qyliss>
I haven't looked into how.
<qyliss>
But you can choose OpenRC or systemd
<Drakonis>
qyliss: its all compiled
<Drakonis>
systemd support is mostly documented
<Drakonis>
but the default assumption is still openrc
<samueldr>
imo supporting more inits is good because of the general "monocultures are annoying" issue
<Drakonis>
i ran systemd on gentoo once, it was mostly annoying
<qyliss>
that too
<qyliss>
I'm not saying it's going to be as convenient an experience as using systemd
<gchristensen>
on the other hand, monoculture has benefits
<Drakonis>
monoculture has its benefits like tightly coupling with kernel features
<LnL>
gchristensen: that's a different story, but I would assume wsl needs a little more then what nix-darwin does since there's no host distro?
<samueldr>
abstracting away could (maybe?) allow launchd integration to flourish better
<gchristensen>
abstracting away could also make it much more difficult to add and secure services
<infinisil>
samueldr: Ohhh
<gchristensen>
it has pros and cons
<infinisil>
samueldr: I remember launchd being a pain
<LnL>
gchristensen: pulling apart the nixos base modules from the rest might be feasible
<Drakonis>
adding and securing modules can always be done directly
<Drakonis>
by avoiding the abstraction
<infinisil>
gchristensen: If all inits default to fully sandboxed by default, I don't think that should be a problem
<gchristensen>
how do you abstract away AmbientCapabilities, PermissionsStartOnly, etc.
<gchristensen>
at somelevel, systemd unit files *are* the abstraction
<LnL>
don't?
<LnL>
the abstraction can generate stuff that works with every implementtation, but with modules the implementation details can still be overridden/extended
<infinisil>
NixOS might have a pretty good advantage with our tests in getting multiple inits supported :D
<clever>
LnL: one issue ive had with running nixos services in docker, is that it assumes users exist, and sudo works
<clever>
postgres refuses to run as "root" (even if its in docker)
<clever>
and the postStart requires a working sudo to drop root
<LnL>
right, but that's complicated stuff which can't be defined with the common abstraction primitives
<infinisil>
clever: Where is the user created?
<infinisil>
Ah I was blind
<infinisil>
nvm
<clever>
LnL: we would need both the user creation logic, and the service backend, to work on say both systemd+linux and launchd+darwin
<clever>
then you could just load postgresql.nix on a mac and it just work
<clever>
and then runit and docker could have an alternative implementation, that creates passwd at build time, and lacks the tools to modify it at runtime
<Profpatsch>
andi-: nlewo does that
<infinisil>
We'd be kicking dockers butt if we get this working on linux, darwin and wsl
<clever>
Profpatsch: running nix-build on that default.nix (after applying the nixpkgs patch) will generate a docker image that contains the entire monitoring framework from iohk
noonien has quit [Quit: Connection closed for inactivity]
<Drakonis>
Profpatsch: run it with podman instead of docker
orivej has quit [Ping timeout: 268 seconds]
webster23 has joined #nixos-dev
orivej has joined #nixos-dev
<gchristensen>
ghuntley: I'm getting the impression from the office hours that we should prioritize implementation of the "adding people to a read only team" a bit higher
<andi->
just read-only or the triage thingy?
<gchristensen>
well the RFC was for read-only, but triage might be more appropriate for maintainerns
<samueldr>
I'm on the case of the sd image being too big; blocking the advancing of the unstable channel
<samueldr>
found the change that made the image a bit bigger, #64575
<samueldr>
maybe we can factor out something for those, that they can rely on?
<worldofpeace>
are there still concerns about clousure size even if the module is enabled for x environments?
<samueldr>
not really, AFAIK it's expected that graphical environments are a bit heavier by default
<samueldr>
and portals are (I think) likely to be a good feature overall
<worldofpeace>
well TBH it's a larger issue that would have to be dealt with outside of this one
<samueldr>
yeah
<worldofpeace>
yes portals give firefox native filechoosers
<samueldr>
even without appimage or such, one dumb thing I ...
<samueldr>
yes that
<worldofpeace>
but we need to set the env var
<samueldr>
I like how it leaves desktop environment things to a protocol instead of built into the software
<worldofpeace>
++
<samueldr>
I was a user of ROX-Filer and the "DE" around if in the past, and I would have killed at the time to have all load/save dialogs work like the ROX ones
<worldofpeace>
and this is for qt as well I think
<samueldr>
started an eval on trunk-combined, hopefully everything's green
<worldofpeace>
assuming we'll switch to conditioning on xserver after that's moved
<samueldr>
you can do it whenever :)
<samueldr>
it's already checked out a revision, and anyway as long as it's implemented so the sd image doesn't have the portals enabled, it shouldn't change a thing