This kind of thinking constantly holds back people from effecting change in their orgs. The myth that every exec is unwilling and incapable of understanding a solid path to improving their business when communicated clearly is so pervasive and I think mostly wrong. I’m part of technical leadership team of a small company (size: 10s of millions of revenue pa, 50 employees). We use NixOS on all production machines deployed to public cloud and all production bare metal at our warehouses. This decision was approved by the c-suite, specifically the CTO, who incidentally is the last word in any competent corporate governance structure on what happens with respect to implementation choices.
I understand that as report chain length increases the chances of your message making it clearly right the way to the top diminishes exponentially, but most of the time this stuff falls flat because it is presented at best present as a loose collection of woolly ideas, with the presenters unwilling to commit to any kind of concrete improvement to anything (i.e. if we do this we estimate a cycle time decrease of X, an uptime improvement of Y), while proposing a course of action which has very concrete costs “It will take at least X weeks which we won’t dedicate other things which will improve the business”.
Salaries ultimately have to get paid by making money, and if it’s not obvious how switching to nixos will drive either the top or bottom line don’t be surprised when non-technical leadership is uninterested. It would be weird if it were any other way.
How did we make the argument to switch to NixOS? I started using nix on my workstation, read the nix pills over the course of a week, packaged a couple of noddy things as a warmup, packaged our main service and its attendant configurations as a 2 day exercise, learnt how to pin packages and then demonstrated that nix solved a problem we’d been having with cicd vs local development of some rust components where tooling bumps would cause changes in depended on glibc, and made the argument that this was wasting time and would continue to waste more time as we expanded what we were doing. The concrete argument was that we would need to double up on infra head count if we didn’t make the leap because we’d be spending more time trying to trying to dealing with dependency problems than platform build out. We made the switch, we didn’t need to hire that extra headcount, and no one has ever come back to question it.
Not every org has the right people in play to make a switch work (are the technical staff capable of dealing with all the idiosyncrasies of nix / NixOS?) , but the idea that non-technical leadership will just ignore improvements to their business because they don’t understand every detail on principle is wrong. If the technical leadership team cannot articulate why NixOS is good for the business in some measurable way then not only is the no-change outcome normal, it would be weird and irrational if it weren’t normal.
You don’t get what you deserve, you get what you negotiate.
TL;DR I believe you’re making hidden assumptions about my work situation.
Noone claimed “every exec”. I claimed “these execs”. I gave an example, you’re extrapolating to a general claim and then attacking it. Should I one day have to work in a different company I might, depending on whether it is a good technological fit, pitch NixOS again. And my belief is that it will depend highly on the knowledge and goals of the C level, and the communication culture/structure of that company whether the pitch succeeds or not.
The difference is simply that you’re in a technical leadership team, and you’re in a small company. Also, I suspect that we’re working in very different companies. Processes about tech choices differ, for example, from companies who sell software or some kind of IT service as their product, to companies who sell something else and also happen to have an IT stack to support their product in some way. In the latter case, C*Os will typically have less background in IT, and more in the particular domain of their product.
Specifically, non-technical people would be the only ones to have that kind of power, and these naturally don’t have the knowledge to make the decision.
or in other words
my belief is that it will depend highly on the knowledge and goals of the C level … whether the pitch succeeds or not.
This is what I am contesting, because for this to be a problem is to suggest that these people are just repeatedly shooting themselves in the foot when there is money to be made because they don’t understand tech. I think it’s the opposite: I think in most organisations if there was a pareto-efficient choice to be made by adopting NixOS that was clearly communicated these people would not be a gate at all.
The difference is simply that you’re in a technical leadership team
is not the point. I still have to report to the CTO, who in turn reports to the CEO. Same as anywhere else.
It sounds to me like you’re mistaking people for perfect profit optimizers, the non-adoption of NixOS at my company for a problem, and a choice that increases profit for a pareto-efficient choice. I give up arguing.
It sounds to me like you’re mistaking people for perfect profit optimizers,
I haven’t said that. I’ve said that when presented courses of action that lead to profits most business leaders will take them, without a requirement that they understand all the technical details
the non-adoption of NixOS at my company for a problem
I have never once claimed your employer not adopting nix is a problem.
and a choice that increases profit for a pareto-efficient choice.
Fine: I should have said “a choice that leads to a pareto improvement”, which is broader than just making more money. A profit increase without downside would be a pareto improvement for a for-profit organisation.
There are lots of open questions and issues, or? Is there any better reason not to use nixos (for anything but a minimal server …)?
If someone tells you the nixos-rollback is a none experimental feature or even “bullet proof”, but it’s not. Don’t even think of changing the DM or Channel (e.g. to unstable and back) or live with the consequences e.g. of a broken system without any clue about the reason…
nixos can rollback the system configuration, not the state. For this you use backups. Neatly however a backup of /home and /var/lib is all you need on nixos
Please don’t spam this thread with a single personal issue that is apparently caused by switching to unstable and then being surprised that things are not stable anymore.
I certainly don’t agree. I would however suggest given that you think Nix / NixOS doesn’t live up to it’s promises that it would be no great loss to you if you uninstalled it.
We’ve been following this discussion on why companies might hesitate to adopt NixOS, and it sparked an idea. Our firm considers offering paid long-term support for NixOS, starting with the 24.05 release, to address the challenges mentioned here (like frequent upgrades and security concerns).
Internal SSL certificates in all tools that initiate https connections (nix-daemon, java, git, etc.). This is currently hit or miss with no comprehensive documentation in one place. Basically MITM proxies should just work. The most recent thing I stumbled upon is `fetchCargoTarball` fails with MITM proxy · Issue #304483 · NixOS/nixpkgs · GitHub.
Internal mirrors for everything, not just the substituters for the nix binary cache or the tarballs cache. Basically things like fetchPypi or fetchFromGithub should be configurable to go to my internal mirror of Pypi or proxy for Github, etc. with examples for the most popular proxies such as Artifactory. This is currently not supported/documented at all. I need to write my own version of fetchFromGithub.
Comprehensive support/documentation in one place on how to supply credentials (logins, API keys, etc.) for those different connections.
All of that supported in both NixOS and Nix installed in some other distribution. The latter is more important because that’s how Nix is almost always introduced.
Please let me know if I missed anything that addresses any of those issues.
UPDATE: As I was recalling other things we had to do, an additional use case was support for multiple versions of “big” tools to comply with the existing software policies in the surrounding environment. There are pockets of support for this in nixpkgs now (e.g. python versions) but we for instance needed the same for R and Apache Spark (like match the version of Spark we are given in EMR, etc.), so some kind of a general framework for doing this in nixpkgs for arbitrary packages would be very useful.