> His gripes on Pike's comment and industry mimicked my own.
Yeah I always found it funny that many of the ex-fishworks people don't like Pike's 2000 paper, which is essentially the same complaint as theirs but different specifics [s/(Unix|Windows)/Linux/ s/Plan 9/Illumos/]. As I think both are interesting, a set up the right direction, and not quite radical enough, I'm especially inclined to see the similarities.
> He's way overstating how much people ignore the system level...
I'm a huge fan of Galois too, I think there is a legitimate complaint that most of industry only look this far down the stack where they must, e.g.. embedded systems or real-time where desktop hardware and a mainstream linux won't do. From reading many of your past posts, I get the sense we both think different operating systems, or even hardware, should (eventually) get used all over. I get why for projects due in a year go the path of real resistance, but I think the economic argument that e.g. Google should be designed something post-unix for 15 years is pretty rock solid. And yet I don't see them or anybody else (since Midori was cancelled) doing that.
> Come on, now. Try to avoid that trap.
First of all, to be clear I responding to the OP more than what I linked. That I interpreted as infrastructure around Unix (or Windows? Haven't read up on OpenStack), not OS work or something lower level. Looking at innovation on the whole stack, I consider nix* more "silver ductape" than "silver bullet"---it made personally using Unix tolerable :).
> compatibility/legacy
So yes nix changes the way unix is administered---and if you use it without changing your ways you will miss most the benefit. At the same time nixpkgs demonstrates that it is feasible to shoehorn-in software that wasn't designed for this with few--no modifications. I think enterprise has sunk more money into their devs' Java monstrosities than ops' perl scripts, but I could be wrong here.
Also if your are running some "pre-cloud" "pre-container" "ancient" setup---on a heterogeneous pile of old desktops in a closet even!---I think nix* would actually allow one to change well than some more popular technologies.
> production worthiness, security
I don't think anybody as really audited the nix* ecosystem to the degree that some users would require, but people do use it in production.
> talent to aid deployment/support
So Nix has great fundamentals with a crappy user interface. Now maybe i am a masochistic idealist, but I think that's better than the reverse because it's easier to rewrite a misdesigned UI than misdesigned foundation.
> That's great if implemented well
It is. Sandboxing for security is a little WIP, but assuming enterprise users wouldn't install things willy-nilly, the real risk is more shitty software than malicious software, and Nix for a long time has been fully capable of dealing with the former. [And by shitty software I mean the thing being packaged. I don't know how one would fuck up the packaging itself: that either works and properly encapsulates things or doesn't work.]
> I'm barely in the debate but lean against systemd
I am completely out of the debate, but do note NixOS doesn't need systemd (or Linux!) for any fundamental reason. Indeed if we had better CI and better delegation on code review and merging PRs (my biggest gripes with nix*), I'd have expected somebody to have fixed this by now.
My personal goal (which I think is common in the community) is all the features, none of the policy. Support all distros' init etc decisions; support Linux Darwin, BSDs, Windows + MSYS2; and so on. [I actually think the Joyent people should be all over NixOS as a way to make moving between Unices painless, but they have gone with lx-branded zones for that.]
"which is essentially the same complaint as theirs but different specifics [s/(Unix|Windows)/Linux/ s/Plan 9/Illumos/]"
That's funny.
"I get the sense we both think different operating systems, or even hardware, should (eventually) get used all over. I get why for projects due in a year go the path of real resistance, but I think the economic argument that e.g. Google should be designed something post-unix for 15 years is pretty rock solid."
True. Especially given they're all already doing something new in the cloud. They have custom CPU's, custom boards, more efficient protocols, alternatives to all kinds of standards... you name it. No convergence on stuff that could get OSS benefits once open licensed. They could keep a good chunk to themselves for competitiveness if they wanted. Just do more than they are on getting CPU, kernel, firmware, and OS modifications. Other contributors, including from CompSci, will do plenty more as we've seen in Linux, LLVM, Java, browsers, especially Python, and so on. It's ridiculous the companies ignoring the opportunity are those standing to benefit.
"I consider nix* more "silver ductape" than "silver bullet"---it made personally using Unix tolerable :)."
Fair enough. A lot of good stuff in IT is ductape.
"Also if your are running some "pre-cloud" "pre-container" "ancient" setup---on a heterogeneous pile of old desktops in a closet even!---I think nix* would actually allow one to change well than some more popular technologies."
I was thinking shops doing Red Hat, OpenSUSE and so on might benefit from stuff like this. Definitely potential there.
"but I think that's better than the reverse because it's easier to rewrite a misdesigned UI than misdesigned foundation."
Not that: enterprises and other businesses know someone will handle their problems now and later with Red Hat, SUSE, and Ubuntu. Is there assurance of that for Nix?
"the real risk is more shitty software than malicious software, and Nix for a long time has been fully capable of dealing with the former. "
That's the risk I was talking about.
"I don't know how one would fuck up the packaging itself: that either works and properly encapsulates things or doesn't work."
Parsing, protocol, filesystem, and network errors. Even ASN.1 and JSON had issues despite their simplicity. So, that has to be considered, too. Preferrably auto-generated from grammar, checked, and in safe code (even C subset).
"but do note NixOS doesn't need systemd (or Linux!) for any fundamental reason."
So the whole distro is separate from Linux itself in terms that it could work on a BSD or Windows just replacing some OS-specific modules? There a link describing that in more detail? Good to know it's not dependent on systemd, though, for uptake reasons. I agree with you on supporting multiple mechanisms. High-assurance also has a mantra of separating mechanisms from policy since it provides all kinds of benefits. Btw, are you a NixOS developer or did "we" mean something else?
> Not that: enterprises and other businesses know someone will handle their problems now and later with Red Hat, SUSE, and Ubuntu. Is there assurance of that for Nix?
No. For this reason alone nothing big is about to happen. Some consulting shops might prescribe this, or may just use it internally. Other places I know its in deployment they have an employee whose a power user or contributor who probably evangelized it in the first place.
> So the whole distro is separate from Linux itself in terms that it could work on a BSD or Windows just replacing some OS-specific modules?
I am much more familiar with nixpkgs (the packages themselves, suitable for single-user install on top of some distro) proper, but let me take a shot. Nix is like a way better version or puppet/ansible/etc in that virtually all the work is done not in nix but in the nix expression themselves. This is true for both nixpkgs and nixos. The most interesting thing that Nix does is the sandboxing, and must of that I think could be done as support code in the nix expression language except then it would be easier to subvert.
They way nixos is structed (topological sort on deps is)
The purpose of the module system is the key to understanding nixos vs nixpkgs. Nixpkgs is just software to build: you can build as much as you want, as many versions of a thing as you want (nix doesn't even disambiguate between 2 packages vs 2 versions of the same package). Since it's just building software, there is no services or long running software or state really, other than nix itself.
Now that's all great, but a distro inevitably involves more state / finite resources. Only one process gets to be PID 1, only so many port files, etc. Nix doesn't want to deal with all this itself, so it largely just spits out /etc files. In rarer cases there are deliberately impure "packages" that may run some commands to set up something (e.g. the "package" that builds /etc itself.)
The module system allows one to write configuration modules (duh!) that (a) declare a few options (b) do a few things based on those options. Those "things" include delegating to other modules. Now the key point is the config options are safely combined so that syntactically conflicting configuration is caught -- we have conceptually a "partial monoid" of configurations. e.g. `{ a = [ "b" ]; }` (+) `{ a = [ "c" ]; }` => `{ a = [ "b" "c" ]; }`, `{ a = "foo"; }` (+) `{ a = "bar"; }` => error. This means one can use config itself to model finite resources (modules can also assert on config so one can e.g. ensure list is a set).
Because nixpkgs is one ginormous repo, its very easy to refactor and add abstractions. So on any system that Nix will one, one can just add more layer to bluntly abstract over non-portabilities. Not exactly glamorous, but it works. And people do use nixpkgs on FreeBSD and illumos at atleast, so I am sure it runs there. [Few users + our shitty CI practices means that is prone to bitrot, cygwin once worked years ago IIUC]. I don't know if Nix knows about jails or zones yet, but there is plain chroot "sandboxing", or even none at all, for more portability.
> Good to know it's not dependent on systemd, though, for uptake reasons.
For example, there was some talk about smudging the nixpkgs--nixos divide so that single-user-install nix users on MacOS could use the module system to define services. That would naturally involve abstracting over init as no systemd on Darwin!
> "mechanisms from policy"
Ah, that was the phrase I was forgetting :)
> Btw, are you a NixOS developer or did "we" mean something else?
The "we" is really just group membership psychology at work :). I don't have repo privileges or anything but contribute odds and ends. Currently working on better cross-compiling abstractions in nixpkgs ...because is anything ever designed with cross-compiling in mind from day one?!
> His gripes on Pike's comment and industry mimicked my own.
Yeah I always found it funny that many of the ex-fishworks people don't like Pike's 2000 paper, which is essentially the same complaint as theirs but different specifics [s/(Unix|Windows)/Linux/ s/Plan 9/Illumos/]. As I think both are interesting, a set up the right direction, and not quite radical enough, I'm especially inclined to see the similarities.
> He's way overstating how much people ignore the system level...
I'm a huge fan of Galois too, I think there is a legitimate complaint that most of industry only look this far down the stack where they must, e.g.. embedded systems or real-time where desktop hardware and a mainstream linux won't do. From reading many of your past posts, I get the sense we both think different operating systems, or even hardware, should (eventually) get used all over. I get why for projects due in a year go the path of real resistance, but I think the economic argument that e.g. Google should be designed something post-unix for 15 years is pretty rock solid. And yet I don't see them or anybody else (since Midori was cancelled) doing that.
> Come on, now. Try to avoid that trap.
First of all, to be clear I responding to the OP more than what I linked. That I interpreted as infrastructure around Unix (or Windows? Haven't read up on OpenStack), not OS work or something lower level. Looking at innovation on the whole stack, I consider nix* more "silver ductape" than "silver bullet"---it made personally using Unix tolerable :).
> compatibility/legacy
So yes nix changes the way unix is administered---and if you use it without changing your ways you will miss most the benefit. At the same time nixpkgs demonstrates that it is feasible to shoehorn-in software that wasn't designed for this with few--no modifications. I think enterprise has sunk more money into their devs' Java monstrosities than ops' perl scripts, but I could be wrong here.
Also if your are running some "pre-cloud" "pre-container" "ancient" setup---on a heterogeneous pile of old desktops in a closet even!---I think nix* would actually allow one to change well than some more popular technologies.
> production worthiness, security
I don't think anybody as really audited the nix* ecosystem to the degree that some users would require, but people do use it in production.
> talent to aid deployment/support
So Nix has great fundamentals with a crappy user interface. Now maybe i am a masochistic idealist, but I think that's better than the reverse because it's easier to rewrite a misdesigned UI than misdesigned foundation.
> That's great if implemented well
It is. Sandboxing for security is a little WIP, but assuming enterprise users wouldn't install things willy-nilly, the real risk is more shitty software than malicious software, and Nix for a long time has been fully capable of dealing with the former. [And by shitty software I mean the thing being packaged. I don't know how one would fuck up the packaging itself: that either works and properly encapsulates things or doesn't work.]
> I'm barely in the debate but lean against systemd
I am completely out of the debate, but do note NixOS doesn't need systemd (or Linux!) for any fundamental reason. Indeed if we had better CI and better delegation on code review and merging PRs (my biggest gripes with nix*), I'd have expected somebody to have fixed this by now.
My personal goal (which I think is common in the community) is all the features, none of the policy. Support all distros' init etc decisions; support Linux Darwin, BSDs, Windows + MSYS2; and so on. [I actually think the Joyent people should be all over NixOS as a way to make moving between Unices painless, but they have gone with lx-branded zones for that.]