<pie_>
IdleBot_5e50c57d: sweet this looks promising, ive been wondering about something like thia
<pie_>
this
<IdleBot_5e50c57d>
I do not actually have dependent services in my system, but the composition of system parts has some similarities
<pie_>
whew, long article, need to read it properly at some point
<pie_>
is this much different than what we do with the module system and systemd?
<pie_>
which of course, uses the module system, and systemd
<pie_>
ok he does make some comparisons at the end
<pie_>
eg "For example, with NixOS, it is not possible to create multiple instances of system services which the process management conventions described in this blog post can."
<lejonet1>
pie_: yeah, because the module system in use by NixOS assumes that each module enables one service, and its non-trivial to "on-the-fly" (aka in your own systems configuration.nix or so) to replicate and create duplicates of services
<lejonet1>
(unless the module in question takes care of that, i.e. like in the ceph module)
<pie_>
sounds like something that could use some work
lejonet1 is now known as lejonet
<lejonet>
Yeah
<IdleBot_5e50c57d>
The system is actually much closer to Nixpkgs than to NixOS. NixOS has this global mutable shared state accessed by distributed modules. Nixpkgs is whoever needs something, gets passed a reference, and can also request a modified version
<qyliss>
Yeah, I don't see a lot in NixOS worth saving
<lejonet>
NixOS have a lot of implicit assumptions that fit desktop/laptop situations
<qyliss>
Nixpkgs, on the other hand, despite some flaws, is pretty great.
<lejonet>
Like, one module, one service, which doesn't always hold that true in server situations
<lejonet>
qyliss: agreed
<IdleBot_5e50c57d>
Well, this holds for some styles of VM deployments
<IdleBot_5e50c57d>
It is like with systemd: all computers are either for viewing web pages, or for serving web pages from an orchestrated VM/container deployment
<lejonet>
Yeah, but to adapt to server environments, you usually need a bit more generality, like the ability to configure n-services of a certain type (i.e. you might have different DNS servers for different networks, but use one server for it, as one example)
<IdleBot_5e50c57d>
A lot of NixOS low-level code is worth either rescuing from NixOS or saving in isolated form (I actually do tyhe latter in my system, it is not that hard)
<IdleBot_5e50c57d>
Nah, just put more containers
<lejonet>
:P that is the modern way, yes
<IdleBot_5e50c57d>
Containers are not even expensive, though
<lejonet>
Very true
<lejonet>
But your orchestration system might not be adapted for that
<IdleBot_5e50c57d>
It is a shame NixOS uses systemd so throughly, because SpectrumOS motto is apparently "Nah, just spin up more VMs"
<IdleBot_5e50c57d>
But this case study in "real programmers can write a monolith application split into 50 processes" called systemd
<lejonet>
Yeah, it would've been nice with a bit more init agnosticism, but it also simplifies some things when it comes to design decisions, to just have to care about how systemd does things
<IdleBot_5e50c57d>
BTW I was at the networkd sprint. Learned a bit about what is going on with NixOS tests, as long as we use Nixpkgs and Nixpkgs end-to-end tests for LibreOffice will not get accepted except as a NixOS tests, that is useful involvement
<IdleBot_5e50c57d>
I wonder how all the systemd-networkd effort will go... Because there is a risk of breaking too much in the process of the migration
<lejonet>
Well, regardless of what I think about networkd, its kindof made for the situation that NixOS presents to it, when there is a "god object" or similar entity that knows about all the abstraction layers for a interface
<lejonet>
and that then can generate all the neccessary in-between steps between the physical interface and the uppermost abstraction
<IdleBot_5e50c57d>
The problem with systemd is that it is (sometimes) very bad design, and always a high-change-rate design
<IdleBot_5e50c57d>
Even if you ignore the monolith implementation and a ton of other stuff, just taking its interface design is already not so good
<lejonet>
Yeah, I personally don't like systemd that much, even if I accept and appreciate its functionality as a init-system (the cgroup and namespace integration is quite nice)
<IdleBot_5e50c57d>
Cgroup integration? You mean this thing that makes it completely impossible in the current systemd design to handle vsftpd misconfiguration reports correctly?
<lejonet>
There is always going to be cases that it breaks, but in general, as pointed out in sanders post, the cgroup and namespace integration makes it a lot harder for a process to "escape" from the control of the initsystem
<lejonet>
Any system that tries to be as general as possible, is always going to break some special cases (I'm deliberately not writting corner-cases, because unlike corner-cases, special cases aren't that hard to think of nor are they "accidental")
<lejonet>
Case in point: systemd is Good Enough(TM) for many situations, which is probably why it has been adopted quite broadly. Doesn't mean its the best or a panacea to solve all problems tho
<IdleBot_5e50c57d>
> all computers are either for viewing web pages, or for serving web pages from an orchestrated VM/container deployment
<IdleBot_5e50c57d>
And it is not that hard to be a good enough init system for a desktop use case if you do not care about configurability or not having regressions: remember sysvinit does not even have state tracking, and things still work fine
<IdleBot_5e50c57d>
So you just need enough buy-in from a single large server distro...
<lejonet>
Yes, there was a element of lobbyism to it too
<lejonet>
I think one of the reason for widespread adoption, is the fact that systemd claims (I write claim because it can always be debated on how well and such they do it) to do stuff like automatic resource management, cgroups, automatic "sandboxing", namespacing and their Private* things, and have various other services "integrated" (logind, resolved, etc etc) so you "only" have to configure "one thing for
<lejonet>
everything". The fact that the reality isn't as simple with it as it would seem, is a different story
<IdleBot_5e50c57d>
You only need to configure this one thing, and then you are not allowed to configure any other thing anyway
<lejonet>
Yeah
<IdleBot_5e50c57d>
(having one more framebuffer fit; this time I actually learned how to kick nouveau to get a proper resolution on external VGA) I wonder if that makes me more or less likely to be able to use Wayland somehow