Nope, not at all. Dockerfiles are not deterministic. Most of the ways I see Dockerfiles written are highly non-deterministic. Docker also requires root access and to some degree exposes that root access to any user with Docker access on a host.
The "stacked filesystem" model also allows far less flexibility than Nix does when it comes to composing a system out of different components. The fundamental problem is the inability to combine features of Docker images with different bases. Compare this with OO languages lacking multiple inheritance.
However, in my eyes, the biggest sin of Docker is the conflation of the problem of software dependency management with isolation & security policy. The two are fundamentally different things, causing developers pain when doing local development and leading to security-slackening changes that make their way into production. NixOS does not make this mistake.
Last time I was running a project with NixOS I was able to git bisect my entire application & software stack to locate the source of a regression (a package maintainer had changed the location of a file) - what can you do?
If you know your instance takes long to build, you should set the health check grace period. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
Or if the checked service comes up before the system is ready, set a cooldown on the scaling up https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
Or in extreme cases, prepare a complete AMI to boot from. This is not a NixOS issue. This it completely on how you operate your AWS.
Point by point:
> Small community
This reason applies to any new tool that doesn't immediately have significant corporate backing. Nothing would ever grow organically if everyone thought this was a deal-breaker. The real point here is that if you use NixOS then you must be committed to be an early adopter and bear all the costs that entails. If you don't get high value out of Nix, then you shouldn't adopt it. Simple enough, yea?
> SOFTWARE MANAGEMENT
This section seems a bit completely ridiculous? Yes, you can't configure your NixOS system unless you write nix expressions. That's literally the point of using NixOS. You don't boot up emacs and complain that it doesn't care about your .vimrc.
> Want to customize something in the OS, be ready, you’ll need to write your custom systemd service to do that. Aaand, yes, service configuration file also need to be declared using Nix expression language.
Yes. That's the point. As much of your system configuration is configured in a principled way.
> All standard system configuration files like /etc/fstab, for example are generated by a weird code and read only.
Yes. That's the point. You can only modify your system configuration in a principled way.
> Forget about Chef, Puppet or Ansible! Only Nix expressions! Only hardcore!
Yes. That's the point. That's what you sign up for when you install NixOS.
> It is not possible just to upgrade the kernel from “ver1” to “ver2”. New kernel will bring whole set of system packages and their dependencies with it. Do not know if it is safe. Will test it soon.
Wait, does this person think you can ad-hoc change your kernel version without considering whether your low level and/or kernel specific packages are compatible with it? That's _the point_ of system packages being parameterized on kernel version in NixOS.
> CLOUD SUPPORT
Yeah, actually you have to be knowledgeable in both Nix and whatever cloud service you're using to get by without issue. It's an early adopter cost, as mentioned before.
> Do not even try to use it in Auto Scaling group and passing configuration.nix content through user-data. ...
I'm pretty sure the author was not deploying NixOS to the cloud correctly, based on this comment. But! It's not obvious how to do it correctly, so understandable.
> Cache
I don't even understand the issue here? You don't have to rely on the community cache. Our shop builds the entirety of nixpkgs and caches it for ourselves as a matter of routine.
> And yes, your own cache size will also grow very fast!
Well yes. You have a cache that contains every artifact relevant to your business going back as far as you want. That sounds rad, actually? Again. That's the point.
> SECURITY
Yea, that sucks. I also dislike when the community introduces breaking changes. This is yet another early adopter cost and if you're not involved in the community the cost can be shocking and difficult to deal with. I sympathize with the author.
> WINDOWS SUPPORT
This Linux distribution doesn't support... Windows? Ok, I've never worked at a Windows shop. What sort of support for Windows do other Linux distributions have that the author is lacking in? It is very true that if you need to support Windows you shouldn't use NixOS.
> SYSTEM REQUIREMENTS
That's what the cache is for my guy :^)
> Conclusion
I'm really sorry for the author, because it looks like somebody made a rash decision to use NixOS that did not get everyone on board and did not fully commit to leveraging NixOS's advantages to outweigh its high early adopter costs.
But I think this rant is more than a little misinformed.
> Wait, does this person think you can ad-hoc change your kernel version without considering whether your low level and/or kernel specific packages are compatible with it? That's _the point_ of system packages being parameterized on kernel version in NixOS.
Linux has done an amazing job of clearly defining the kernel and userland boundaries while fanatically maintaining (recent) backwards compatibility from a new kernel to an older userland. The kernel and the modules/headers associated with the kernel should be treated the same as any other package, and arguably almost no other package on the system should have a hard dependency against a kernel package. It's entirely reasonable to wish to build a rootfs/userland and ship it to be run under an arbitrary linux kernel you dont control. (i.e. paravirt vms, container images, and devices only supported by a vendor kernel).
