<edef>
i just take a lot of notes on my own takes on things, and form my own models of them
<Irenes[m]>
for sure
<edef>
at some point a concept tends to click, and i take a lot of stream-of-thought notes about what variations are possible
<edef>
and then i ramble about it to a select set of disciples who then tell me about all the real-world things
<Irenes[m]>
haha
<Irenes[m]>
see, the thing with that is you're in danger of people respecting you so much that they don't question you
<Irenes[m]>
I'm joking, mostly, I just pinged off the word "disciple"
<Irenes[m]>
but yeah that sounds like a good strategy :)
<edef>
this is why i try to remain as abjectly ridiculous as possible
<Irenes[m]>
excellent
<MichaelRaskin>
Earlier in the same channel: «<qyliss> In regards to expression integrity and stuff, that's an area I believe e»
<MichaelRaskin>
def is looking into, and so I won't be for at least a while to avoid duplicating work, becau
<MichaelRaskin>
se I trust her judgement there
<MichaelRaskin>
So, the risk _is_ there
<edef>
i suppose
<qyliss>
I did not mean I will do whatever she says without questioning it :P
<edef>
qyliss is generally rather inquisitive about why my ideas work
<Irenes[m]>
I would love to hear random musings about expression integrity
<edef>
we've got several layers of problems
<edef>
for starters, we sign derivation outputs, but we don't even record what inputs they were built from
<edef>
so it's impossible to ascertain where we started getting compromised
<edef>
there's some work happening on having non-repudiable build logs by adisbladis (i think the project is called trustix now), using Google Trillian
<edef>
i'm somewhat skeptical of the complexity of Trillian being worth having in the TCB, but i suspect the data will be useful in its own right
<edef>
but we could at least have a start to things with non-repudiable build signatures, and improve by recording the concrete build inputs
<Irenes[m]>
yeah I mean I think when you choose to use a Google project, you're making the choice that you want to get the benefits of their security and privacy audits, and as a trade-off you accept the risk that they'll cancel it tomorrow.
<edef>
i have some work going on a reimplementation of the Nix builder that lets me run builds under gVisor so that build hosts become easier to trust
<edef>
because currently shared build hosts are fairly hard to trust
<Irenes[m]>
ooh, nice
<Irenes[m]>
yeah, agreed, building is by definition running third-party code
<edef>
my intention was at least initially to make it work with arbitrary OCI runtimes
<Irenes[m]>
makes sense
<adisbladis>
edef: Part of the project is properly evaluating other solutions. The real work on this will begin soon (probably in the next couple of weeks).
<Irenes[m]>
huh. I had not previously heard of gVisor but that seems like an excellent approach.
<adisbladis>
I'm not 100% decided on Trillian :)
<Irenes[m]>
I mean I think it's... you do want a Merkle tree
<Irenes[m]>
and public mirroring
<adisbladis>
Absolutely
<Irenes[m]>
I'm not aware of very many frameworks designed for doing that. I guess you could publish a git repo but there are a lot of pitfalls since git isn't quite designed for that.
<colemickens>
surprised at gvisor. kata always seemed more appealing to me
<adisbladis>
Anyway, I should really be sleeping now...
<Irenes[m]>
good night then
<adisbladis>
colemickens: It depends on what you want
<adisbladis>
Kata is full Qemu, no?
<adisbladis>
While gVisor is closer to Linux containers
<adisbladis>
The overhead of Kata is probably way too high to be a viable Nix sandbox
<colemickens>
Where's the threshold at?
<adisbladis>
Just wildly speculating here
<Irenes[m]>
this sounds like a "don't guess, measure" thing
<colemickens>
I grok the difference, was deep in the k8s space, but I'm not sure I buy it.
<adisbladis>
colemickens: consider this expression: pkgs.writeText "somename" "somecontents"
<Irenes[m]>
I'm going to take a guess that the official Nix build farm is always running at full capacity, so the way to quantify the cost would be in terms of how much longer each build cycle would take.
<adisbladis>
Under the hoods that using runCommand which in turn is using stdenv.mkDerivation
* colemickens
also realistically knows next to nothing about nix, so please don't waste too much time on me, mostly just curious here
<adisbladis>
You wouldn't want to spin up a full VM to just write a text file
<Irenes[m]>
colemickens: I personally think your questions are useful
<adisbladis>
The nix sandbox already has some overhead (iirc ~15-20ms mark)
<colemickens>
Kata aims for <100ms startup time?
<Irenes[m]>
you ask different things than people with experience in this topic will ask. that's worthwhile. plus, you may not be the only person wondering, this channel has plenty of bystanders.
<colemickens>
(I think, I'm googling here :P)
<adisbladis>
colemickens: Which is quite high
<adisbladis>
edef: Are you targeting gvisor only or OCI?
<Irenes[m]>
hm... but these approaches go beyond just startup time overhead, surely
<Irenes[m]>
they also are going to have overhead wrt execution speed
<colemickens>
Irenes: :) thank you. I don't feel too shy, the Nix community/communities are exceedinly pleasant and kind but its a lurking though in my head.
<Irenes[m]>
for sure, very much understood
<adisbladis>
Because based on my admittedly low knowledge of gvisor/kata it seems like gvisor is the reasonable default
<adisbladis>
But if OCI was targeted you could make the sandboxing configurable
<qyliss>
gvisor isn't really close to Linux containers at all AIUI
* colemickens
wonders if there's an rvisor :P
<adisbladis>
qyliss: I meant in terms of performance penalty
<qyliss>
oh, right
<colemickens>
well it's an OCI runtime
<qyliss>
sure but so is firecracker i think
<colemickens>
lol, I cna't remember which pieces are OCI or CRI, but yeah, some firecracker/kata-y component can play a similar role. But with more overhead
<qyliss>
I'd expect QEMU to outperform gvisor by a long shot, at least if you could keep it running.
<qyliss>
Or even snapshot/restore?
<adisbladis>
qyliss: Interesting proposal :)
<qyliss>
Have you read "My VM is lighter than your container"?
<Irenes[m]>
yeah snapshot/restore seems more desirable than keeping it running
<Irenes[m]>
it shouldn't cost too much to, like, rent some compute time on GCP or AWS and just run some benchmarks to measure startup times of different container engines
<colemickens>
surely some Cloud Native companies have doen so
<Irenes[m]>
although of course that's already within the platform's isolation stuff so it won't be the same as performance on bare metal
<colemickens>
basically what I'm hearing is Spectrum should be a CNCF project
<colemickens>
I didn't know that gvisor could leverage kvm?
<qyliss>
Oh, yes, it can
<tazjin>
the target number I've heard thrown around for gvisor startup time is ~5ms
<colemickens>
that would be interesting, especially if it meant a path to supporting non-kvm clients via plain-gvisor or a more secure variant for those who are kvm-inclined.
<qyliss>
5ms is incredible
<Irenes[m]>
oh wow
<Irenes[m]>
if it's 5ms you literally could use it even for trivial builds like somebody mentioned above
<qyliss>
Yeah!
<qyliss>
An exec is 2-3, isn't it?
<Irenes[m]>
I would think so
<Irenes[m]>
I'd be surprised if it's much faster than that
<Irenes[m]>
but I haven't checked in years so who knows
<tazjin>
I can't find the source for the 5ms atm (it's been a long day), but I think it was also dependent on whether you needed the gofer (filesystem proxy) which slows things down somewhat
andi- has quit [Remote host closed the connection]
andi- has joined #spectrum
cole-h has quit [Quit: Goodbye]
edrex has quit [*.net *.split]
edrex has joined #spectrum
<Profpatsch>
Last time I benchmarked, an exec on my laptop was something in the ballpark of 5ms
<Profpatsch>
Well, “benchmarked”
<Profpatsch>
In the sense of “put a few marks on a bench”
Irenes[m] has quit [Quit: killed]
danielrf[m] has quit [Quit: killed]
colemickens has quit [Quit: killed]
vladimir-lu[m] has quit [Quit: killed]
edrex has quit [Quit: killed]
thefloweringash has quit [Quit: killed]
colemickens has joined #spectrum
thefloweringash has joined #spectrum
danielrf[m] has joined #spectrum
edrex has joined #spectrum
Irenes[m] has joined #spectrum
vladimir-lu[m] has joined #spectrum
JosephineSk has joined #spectrum
JosephineSk has quit [Client Quit]
<MichaelRaskin>
adisbladis: it sounds like if there are problems, you want to check integrity of all the recent logs (so it is not like with filtering by domain in CT). So most of the Trillian is likely to be less useful for you… Maybe a daily request to an external timestamping service could be useful, though.
<edef>
< adisbladis> The overhead of Kata is probably way too high to be a viable Nix sandbox
<edef>
firecracker/crosvm are suitable and interesting
<edef>
and yes, snapshotting already-booted VMs and such could be interesting (although i would enjoy having ASLR enabled and such)
<edef>
tazjin: we probably want to run one global 9p server for filesystem access
<edef>
tazjin: since we have a pretty constrained rootfs
<edef>
< adisbladis> edef: Are you targeting gvisor only or OCI?
<edef>
adisbladis: i was interested in targeting arbitrary OCI, but there's kind of a split rn because gVisor doesn't support bind mounts
<edef>
i suspect the way this'll end is that i write a custom 9p server to replace the gofer, that just serves from a Nix store backend and has corresponding limitations
<edef>
which should be much lower complexity
<MichaelRaskin>
rust-9p seems to be reasonably small
<MichaelRaskin>
Single 9p server — but what about fault isolation?
<DrWhax>
edef: ohai!
<qyliss>
Profpatsch: oh _that's_ where benchmarking comes from
<qyliss>
edef: does gvisor do virtio-fs?
<MichaelRaskin>
If it provides the kernel calls, maybe it doesn't need to?
<qyliss>
It doesn't implement its own file systems
<qyliss>
But, you're right gvisor itself wouldn't actually implement that
<qyliss>
Google also have a Rust 9p server that's part of crosvm (but I think can be standalone)
* edef
ruffles DrWhax's hair
<edef>
so the gofer is just a Go 9p server
<edef>
the implementation looks very obnoxiously structured though
<edef>
MichaelRaskin: i'm fairly confident we can write a 9p server that doesn't crash or have memory safety bugs
<hyperfekt>
MichaelRaskin: i would argue that even though the TCB may be larger i think there's a very real possibility that KVM is as safe as Xen at this point because it gets orders of magnitude more attention, considering that all the cloud providers use it. afaik all of the ITL' posts were about qemu+KVM vs Xen instead of KVM vs Xen
<hyperfekt>
i love how everyone is in agreement about how declarative OS should work instead, it just needs someone building it. i hope that grants for qyliss keep flowing after this one is through
<hyperfekt>
<edef> ironically my SSD dying might have eaten my design notes <MichaelRaskin> The only copy of your design notes?? <edef> i was redesigning how backup systems should work! < this was extremely funny and extremely relatable
<hyperfekt>
<adisbladis> You wouldn't want to spin up a full VM to just write a text file < disagree
<hyperfekt>
qyliss: i love that lightvm paper. horizon2020 funding is in almost all the good places, i adore the EU now
<hyperfekt>
i think one of the main challenges worth solving is KVMfork
cole-h has joined #spectrum
<hyperfekt>
making running VMs almost entirely CoW in combination with LightVM-esque work in KVM has a very real chance of making being able to replace fork and exec with forking/execing into a new VM
<hyperfekt>
and if noone else will do this work i will
<Profpatsch>
The main thing I like about the EU, how it allows for long-term goals that reach over the 4 year horizon most politicians have
<Profpatsch>
Also last bastion of social democracies and all that.
<MichaelRaskin>
hyperfekt: I would not overestimate the agreement, to be honest. The detailed design discussion I tried to start has not yet occured, but any time any discussion happens I see more and more differences in detailed goals.
<MichaelRaskin>
hyperfekt: H2020 is basically _all_ of coordinated EU research funding. There are actually quite a few country-level-funded great projects, but they are worse at advertising so that's why you won't hear about them.
<MichaelRaskin>
I think most H2020 projects are still shorter than one French presidential term, technically speaking.
<MichaelRaskin>
hyperfekt: What would be a use case for KVMfork?
<hyperfekt>
MichaelRaskin: mostly removing the Linux kernel from the TCB
<hyperfekt>
or in other words making processes an actual security boundary
<MichaelRaskin>
That's not a usecase
<MichaelRaskin>
Sigh
<MichaelRaskin>
You are describing a nonfunctional requirement, that is not a usecase
<hyperfekt>
the usecase is: i want to run programs without them taking over my computer, and i don't want it to be slow
<MichaelRaskin>
Why would you need KVMfork for _that_?
<MichaelRaskin>
Isn't «just spin one more CrosVM» exactly what SpectrumOS aims to make easy?
<hyperfekt>
> don't want it to be slow
<MichaelRaskin>
Sure, _my_ current system with NS jailing does have the parts of Linux kernel nobody truly believes in in the TCB
<hyperfekt>
SpectrumOS is intended to be application level
<MichaelRaskin>
So what?
<hyperfekt>
exploits compromise an entire application instead of just their process
<MichaelRaskin>
Well, processes inside an application will need to communicate and communicate a lot
<MichaelRaskin>
They use the kernel to somewhat prevent some kinds of interaction from happenning
<MichaelRaskin>
And they usually need pretty detailed policies.
<hyperfekt>
think image previews in your file manager, tabs in your browser. there are lots of cases where some part of an application will deal with untrusted input
<MichaelRaskin>
Tabs in my browser: what tabs? They are different browser instances…
<MichaelRaskin>
(And to make it fast, I would prefer something like spawning pre-suspended empty images with a browser just loaded, not forking a dirty-ish image)
<hyperfekt>
congratulations, make it an iframe then
<MichaelRaskin>
iframes have many more «Web is garbage» problems where perfectly running limited-interaction logic between iframe and surroundings works exactly as specified but iframe gains something by abusing this logic
<hyperfekt>
MichaelRaskin: forking a running VM and loading a suspended image is the exact same problem
<MichaelRaskin>
No
<MichaelRaskin>
Because fork would be expected to be much more flexible
<MichaelRaskin>
Basically, if we are talking of a Linux VM, I guess s2disk should be pretty fast to resume from if «disk» is actually some data that the host caches
<MichaelRaskin>
But creation of a suspended s2disk image includes an expensive «barrier» step.
<MichaelRaskin>
(Which would not be acceptable for fork)
<hyperfekt>
s2disk isn't fast, assuming all the data is already available to the guest and no context switches are necessary you still have to memcpy, which takes ~60ms / GB
<hyperfekt>
that number differs in concrete of course but the order of magnitude is what matters
<hyperfekt>
so i was admittedly talking about a different kind of suspension
<MichaelRaskin>
Actually, given that resume is pretty well-defined and unchanging, making it friends with page deduplication/CoW does sound nice
<MichaelRaskin>
(That doesn't make initial suspend cheap, so it should be easier than true KVMfork)
<hyperfekt>
yeah, just run KSM over it
<MichaelRaskin>
Just how many KSM's are there in Linux
<hyperfekt>
the main problem with image snapshots (be they because of suspension or fork) is dealing with connections to rest of the system and randomness
<hyperfekt>
the forking/snapshotting itself should be relatively easy in comparison
<hyperfekt>
that's why i said it's the same problem
<MichaelRaskin>
s2d at least does expect hardware to be a mess on resume
<MichaelRaskin>
Good question what is the fastest way to establish a network link here
<MichaelRaskin>
Never measured how much DHCP between VMs over emulated network takes at minimum
<MichaelRaskin>
hyperfekt: if you want randomness to matter, there is of course also the direct definitional conflict with ASLR etc.
<hyperfekt>
i mean it does share that problem with fork
<MichaelRaskin>
Yes
<MichaelRaskin>
Note also that if you are actually executing something independent enough to run separately, you do not need fork
<MichaelRaskin>
You use clone that basically promises you that you crash if your next action is not exec
<hyperfekt>
sure, but i really want to execute things that are not independent enough in their own VM
<hyperfekt>
if we make exec the boundary we're back to applications, that's just spectrum really
<MichaelRaskin>
Well, SpectrumOS is not even close to well-defined
<MichaelRaskin>
Because, for example, without solving any interesting problems I see how to make an editor be isolated from the network but allowed to run git push
<MichaelRaskin>
Application is not a well-defined concept, after all
<MichaelRaskin>
And if you want to go _actually_ lower (Firefox workers?), then you are in for the real problem
<MichaelRaskin>
It's like ITL's comments on XSA's
<hyperfekt>
the way i see it objcap is the way to go with that
<MichaelRaskin>
Basically, you are either rewriting a web browser from scratch (good luck, I will still be here when you give up and come back), or you are trying to write the communication layer allowing you to specify what are the allowable kinds of communications between all these forked components
<hyperfekt>
as a quick sketch, there needs to be a general rule that git is allowed to access its working directory and the network
<hyperfekt>
MichaelRaskin: chromium already supports strict site isolation. i only need to have cross vm pipes / sockets
<hyperfekt>
and if not i just share memory
<MichaelRaskin>
But then are these per-site components not covered by Atom-calls-git style implementation?
<hyperfekt>
essentially any form of IPC the kernel currently mediates the VM manager then mediates
<MichaelRaskin>
Exactly, but you really want to have more limited cross-VM IPC than on-system
<hyperfekt>
on-system?
<MichaelRaskin>
inside a single Linux kernel controlled system
<MichaelRaskin>
Basically Qubes relies on Xen _but also_ makes sure most of the Xen features are impossible to trigger. There is a reason for that.
<MichaelRaskin>
You do not trust Linux kernel _exactly because_ it needs to support too many things.
<hyperfekt>
that's where you plug in objcap. no more global name system
<hyperfekt>
oh that's what you mean
<hyperfekt>
you can hardly support all kinds of IPC without implementing them. but i'd rather reimplement them and trust that impl than trust the entire linux kernel lol
<MichaelRaskin>
I mean, look at the critical CVE's in Linux, just not having any exotic rarely used drivers (be it SCTP or special FS'es) accessible already improves security a lot
<Shell>
hey, one day I'll be able to do SCTP over the internet. just after IPv6 finishes deployment. :p
<hyperfekt>
agreed, but it's nowhere near good.
<MichaelRaskin>
Shell: you already can
<hyperfekt>
that's the entire reason things like qubes exist instead of everyone just running a single VM on top of the host
<MichaelRaskin>
hyperfekt: I predict that by OS kernel standards first five years of your reimplementation of all kinds of IPC will be really bad.
<hyperfekt>
doubt
<MichaelRaskin>
That is if you read up on all the problems all the kernels ever had, otherwise it will be horrible instead
<Shell>
MichaelRaskin: ehh, I meant the non-UDP-tunneled version
<MichaelRaskin>
Shell: I think you can run it over IP if you do not have any NATs on the route, no?
<MichaelRaskin>
hyperfekt: well, if we are talking about the inside of a VM in the first place, you can basically configure out of the Linux kernel almost everything except what you intend to build…
<hyperfekt>
not really? try compiling the kernel with only the files for IPC left
<hyperfekt>
it does so much more, and it does it badly. if the linux kernel was a minimal thing that was only its IPC mechanisms that'd be great
<MichaelRaskin>
It actually does the things it does quite well, but mixes too many of them together
<MichaelRaskin>
But what thing you cannot configure out of the kernel that will not have any corresponding part in whatever you plan?
<hyperfekt>
the question is less what i can configure away and more if any application will run like that
<MichaelRaskin>
If it doesn't, and you want a VM per PID, you will end up having _something_ as a replacement
<hyperfekt>
the linux kernel
<hyperfekt>
as a library
<MichaelRaskin>
You know, syscalls that do not serve any interaction between the process and things external to process have already been converted to VDSO
<hyperfekt>
the thing is that a considerable part of what i need to replace has already been implemented with more care by cpu manufacturers
<MichaelRaskin>
You will still need to manage access, also CPU manufacturers applying more care than Linux kernel developers does not sound plausible.
<nixbitcoin>
Is it possible to reserve a localhost port to a service or user?
<MichaelRaskin>
What are you willing to trust? I guess some LSMs could provide that, and then you could just use socket activation (not necessarily with systemd, xinetd had it decades before)
<nixbitcoin>
SELinux makes it possible via port-labelling
<nixbitcoin>
But I don't think it's possible to deploy SELinux only for that task
<MichaelRaskin>
I guess you could iptables the port into a VM that runs SELinux
<nixbitcoin>
There must be an easy way to only give a specific user permission to open a listening connection on a specific port
<qyliss>
nixbitcoin: this is something I would like to address
<qyliss>
Access to resources should be explicitly defined in a central place in top-level configuration
<qyliss>
and ports on hardware interfaces are resources
<MichaelRaskin>
That central place — that sounds like server Spectrum?
<nixbitcoin>
Is it possible to define access to resources in top-level NixOS configurations?
<qyliss>
no
<nixbitcoin>
Is that something only MAC can do?
<qyliss>
MichaelRaskin: yeah, exactly
<qyliss>
MAC?
<nixbitcoin>
Mandatory access control like SELinux
<qyliss>
You could have systemd bind to the port and then use socket activation
<qyliss>
But in Spectrum, isolation units would just not have access to hardware interface ports, so no need for any of that.
<nixbitcoin>
Does spectrum handle networking similar to Qubes with NetVM's?
<qyliss>
That's the plan.
<qyliss>
Right now it doesn't handle networking at all.
<nixbitcoin>
Haha, it's a baby
<qyliss>
yes :)
<nixbitcoin>
But it will grow mighty and strong
<qyliss>
I hope so!
<Shell>
hey, the most secure operating system is one that doesn't talk to anything :p
<MichaelRaskin>
Frankly, from some of the discussions here, I'd hope it would not «grow» as continuous process, but rather experience a couple of resets. Low-level tools will stay, but composition will have to be rethought after some practical experience
<qyliss>
Yes, that would make sense
<MichaelRaskin>
Shell: including CPU, and SpectrumOS is arguably in this state as an OS
<Shell>
also some stuff that I came across in Keyframe which amounted to "build the system I'm trying to build, don't spend effort making parts of it do things that don't make sense for the intended use case of the finished system or it'll never get done".
<qyliss>
I've been thinking that I want there to be some sort of core Spectrum stuff, which could be used for a server, or for somebody like MichaelRaskin who doesn't want whatever overall product I end up with
<qyliss>
And I want that to be a thing that people are encouraged to use to create new things
<qyliss>
And then there will also be what is essentially "Alyssa's Spectrum Distribution", which has everything all set up and working properly.
<MichaelRaskin>
… hopefully also on setups you have never seen
<qyliss>
yes!
<qyliss>
I think the distinction between mechanism and policy is extremely important
<qyliss>
It's why I like the kernel, and why I dislike GNOME and systemd
<qyliss>
NixOS attracted me by being basically "build your own operating system"
<MichaelRaskin>
«And always remember, that your high-level mechanism is inherently a policy for using your low-level mechanisms»
<qyliss>
The policy was almost entirely up to me. No other operating system offered that, and in fact they couldn't have.
<qyliss>
Right now I think there's some conflict in the Nixpkgs world because the distinction between mechanism and policy is not well defined
<qyliss>
Where my argument is "hey, we're enforcing policy here where there's no need to"
<Shell>
nixos suffers from that, I think? you get a bunch of random really generic modules and then you get things like the mail server stuff where they try and force you to implement it in a specific way.
<nixbitcoin>
Can you define the difference between mechanism and policy?
<qyliss>
And the counterargument is "well, the policy is fine. it's not hurting anybody to create some empty directories"
<qyliss>
And we're both right.
<qyliss>
nixbitcoin: mechanism is where I give you a tool you can use however you want, and policy is where I tell you you have to use the tool in the ways I thought of
<qyliss>
Shell: I think it's important to have layers.
<qyliss>
I'd much rather have NixOS provide generic modules, and then have a layer on top that adds policy and configures the modules in a nice way together, than to just have modules that work for one person's use case
<MichaelRaskin>
I think I have participated in a discussion on #-chat where one of the participants said something I couldn't reliably distinguish from a claim of non-existence of mechanisms
<qyliss>
(A lot of this is also just design failure in how NixOS provides services)
<MichaelRaskin>
And then also a lot of modules making some thing encapsulated and nonoverridable
<Shell>
qyliss: yeah, that's my point.
<qyliss>
There's a lot of value in being able to just say "mail server = on", but there's also lots of value in being able to manually configure just Dovecot to do some weird thing
<qyliss>
And those are different enough that they probably shouldn't be part of the same thing
<MichaelRaskin>
Well, the former definitely could be a published default config for the latter, couldn't it?
<qyliss>
Yes, but that needs to be maintained, etc.
<MichaelRaskin>
Well, the former needs to be maintained in any case, if it has to ever send something.
<qyliss>
And without a strict separation it's too easy to start merging the two.
<MichaelRaskin>
I did not mean the same file
<qyliss>
Yeah, I don't think they should even be next to each other.
<qyliss>
They should be in different "layers", for want of a better term.
<MichaelRaskin>
Well, if one has layers in the first place
<qyliss>
The point I'm trying to make is that one needs layers.
<MichaelRaskin>
Well, in some cases one can do fine without formalising layers. stdenv is definitely a layer, even if it is not fully separated
<Shell>
NixOS is not succeeding without formalised layers, at all.
<MichaelRaskin>
It's on Nixpkgs level though
<MichaelRaskin>
Nixpkgs is mostly fine
<Shell>
nixpkgs is a different matter and needs them significantly less, tbh.
<MichaelRaskin>
I kind of has them ad-hoc, though.
<Shell>
there's not a lot of policy to be had in nixpkgs, short of "build this stuff without features".
nixbitcoin is now known as nixbitcoindev
<qyliss>
Nixpkgs is mostly fine
<qyliss>
It has a bunch of problems but only a few of them are fundamental, and it's getting by fine even with them
<qyliss>
NixOS is... not
* Shell
is a fan of svanderburg's recent writings on functional system configuration. it's a lot less academic than Disnix et al and solves a lot of problems that NixOS doesn't.
<MichaelRaskin>
Maybe if port-nix-darwin-to-Linux catches up we can stop caring.
<MichaelRaskin>
I guess first catches on then catches up
<Profpatsch>
lol, how do I actually fetch the vm_tools/p9 repo into cargo without having to fetch the whole platform2 repo every time
<MichaelRaskin>
Shell: I found them boring, but only because I already more or less structure some parts of my system like that
<Profpatsch>
Guess I’ll just vendor ¯\_(*)_/¯
<Shell>
MichaelRaskin: I found it exciting because it was suddenly very clear to me how to use this to build systems (collections of services) that can be configured in both single-machine configuration and a distributed system configuration, which is useful for my work.
<MichaelRaskin>
Shell: I guess you saw more novelty there!
<Shell>
mhm
<Shell>
I was at the "NixOS has problems for what I'm doing" stage for quite some time but hadn't really worked out a clear way to fix it.
<MichaelRaskin>
Indeed.
<FireFly>
Shell: hmm, do you have a link or reference to said recent writings on functional system configuration?