Issues when suggesting NixOS within corporate environments

Suggesting steam-run to NixOS users to run their downloaded binaries always trigger some interesting questions :smiley:

8 Likes

License reasons aside, its closire size of ~4GB is not what I’d call an easy solution and absolutely nothing that scales well.

3 Likes

I don’t disagree.
I am pointing out some difficulties on keeping, say, Nixpkgs 18.05. What we should do?

Five years, two per year, it implies ten Git tags receiving cherry-picks. Being the largest repo in existence (100k packages according to Repology), it implies potentially 5k packages, or a swarm of 50k cherry-picks.

It looks a huge work.

2 Likes

I think IT industry is still looking for a sustainable workflow that allows maintainable systems to use not so old software :sweat_smile:

I’ve been thinking about the security side of things and I can imagine that if someone is to use NixOS in the company, maintaining own packages is basically a must anyway.
So maybe instead of solving the security problem upstream (with longer release cycle, etc.) it might make sense to push/polish tools like vulnerability scans more with the intend of enabling everyone to “track and patch packages themselves”. It’s quite easy to manage out-of-nixpkgs packages with patches and if build time becomes an issue I can imagine that a company cache is an early requirement anyway.

But then again, this would probably require quite a bit of a company investment and quite some trial/error. Plus some good security engineers. looking pleadful at those awesome companies already investing many resources into Nix :pleading_face:

4 Likes

I agree, a differently named package with a similar function would be a good idea.

2 Likes

Something like bin-run

2 Likes

Unsolicited grumbling that’s vaguely in agreement:

I ported my entire development environment to various nix* solutions (albeit running on Pop!OS as a base), and I gave up + switched to linuxbrew because:

I don’t want to have to think about c++ dependencies / LD_* when pip installing numpy.

Most of the responses I’ve seen to these issues have been along the lines of “why would you want {use pip / have a global python installation with ipython and numpy}? Just use small nix environemnts for everything”. That’s just not gonna cut it for a lot of people (myself included).

2 Likes

I would argue that unless you are a tech company or otherwise have a significant existing in-house engineering base, it’s just too risky to choose NixOS - it’s too different and it’s too hard finding people who know it.

It’s all about risk management.

EDIT: that being said, there isn’t anything better (for me) at this point in time!

14 Likes

Corporate environments often have operational expectations/requirements that are at odds with best practices from a community perspective; for example, when people talk about “security” in a corporate setting, it’s usually actually about compliance , which frequently requires compromising on actual security to accomplish.

I was intrigued by this comment and was wondering if you care to explain further and/or come with examples where compliance compromises on actual security?

1 Like

‘Compliance’ is a broad term, so your mileage might vary. It probably refers to a set of rules how to use software in a company conforming to internal and external rules (legislation).

In my experience ‘compliance’ is the umbrella term for removing nearly all parts from a car, officially stamping the sad rest and declaring it safe; albeit it doesn’t drive anymore. It’s infuriating. Rules made by people who have lost connection to actual software development and rather switch on some “security feature” needlessly to not take on any responsibility.

edit I should add, it is very hard to introduce something new into such a setting. For example nix. You inevitably get the reflex: I don’t know that - end of request.

3 Likes

so far, sounds reasonable and well thought

what about changing the perspective?


“pushing” ?
What are you doing if someone is trying to push you? Do you push back?

Sounds like US-sales strategy [quite aggressive and not customer focused]


What about the “current standard”

  • make a (well planed) social media campaign [e.g. by the foundation] e.g. in LI, with basics, a bit of fun and for sure focus areas (like web dev, ai, …) - there is something like a nixos marketing team, no?
    ( – lie about anything python related … :frowning: )
  • where the community is aware of / is buying in / supporting all of it heavily

So that this awareness could make them interested to pull information/nixOS in.

1 Like

Maybe I should have use the word “advocating”, I’m not an English native person, so sometimes my words are not exactly meaning what I had in mind.

2 Likes

An infamous example of this would be FIPS compliance, which sets very specific (sometimes too specific and outdated) requirements on cryptography, and which introduces perverse incentives.

3 Likes

E.g., forbidding the use of git for version control because it uses (or did, until recently) sha1.

6 Likes

One issue is that you have to convince a whole dev team, not just a person here and there. In a team of ~30, we have two people running NixOS on their dev machines, and a handful of others use Nix so we can keep coherent versions of all dev tools. If these tools fail, the blame is often on us two NixOS users.

We don’t have NixOS servers running. Changing that would be a huge investment. We would have to rebuild everything we’ve already built with ansible. We would have to re-train the whole team. It would take a lot of time. And noone who is in a position to enforce this change understands the advantages of NixOS, let alone is able to weigh them against the advantages of our current setup.

To push NixOS to the whole company is neigh impossible because there are many different dev teams who all develop their own services. We don’t share all of our infrastructure. And on this level in particular the few people on C level who could enforce such a change have no idea about the benefits of NixOS.

8 Likes

May not apply to yourself and may not apply to your decision-makers but from a passerby POV this sentiment/phrasing can be easily mistaken for zealotry, especially if it gets recognized by those people during the attempt at convincing them. “Someone smarter would clearly want to buy what I’m selling” would be a maximally-uncharitable paraphrase and as you can imagine, it may quickly alienate someone all by itself.

Anecdotally, I feel I do understand the value proposition of Nix as well as NixOS, and have reaped a useful amount of practical experience after earnestly using it for ~7 years. In nearly all business conversations about adopting Nix officially (let alone NixOS) I would/have argued against doing so for ~95% of organizations. I say that with NixOS on two machines in daily use. I have some form of Nix on just about every computer device I’m responsible for that doesn’t run iOS and flakes in just about every personal repo.

TLDR don’t assume that all opposition must inherently come from lack of grokking the tech - it may come from different risk appetite, different emphases and priorities, concerns about documentation and education, or sincerely-held reservations about the suitability of the ecosystem or parts thereof.

8 Likes

I live in a very containerized world, so forgive the question but I’m curious, which workloads are you running that require configuring an entire OS / VM? Are you on-prem?

My current focus is getting nix out to developers a step at a time. Their workstations are migrating to the cloud and (unfortunately) run in a docker container with a persistent /home, which is a very good usecase for home-manager. If we had VMs, I’d be pushing for NixOS, but setting up a rebuildable system that shuts down dev machines after a certain period of inactivity is not yet in the time budget.
But even that has not caught on. nix is still a little too unknown.

2 Likes

No assumption was made about all opposition. Just about some particular opposition. 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. Completely independently of whether NixOS would be the right or the wrong fit. NixOS is niche, and I think people who don’t have experience with it (which is the vast majority amongst non-techies, and still the majority amongst techies) will adopt it just because some random hacker in their company promotes it.

1 Like

In fairness, this heavily depends on the company. I’ve seen plenty where the decision makers on the topic of what development infrastructure tooling is used would probably have been the people most likely to actually have heard of NixOS.

And yes, typically among such people the primary concern with something like NixOS ends up being along the lines of switching cost (both in terms of migration from old systems and training new/old employees) and concerns with the current state of the ecosystem (let’s be frank, the NixOS community - despite punching far above its weight - is a far cry from being able to provide the kinds of support ubuntu manages; also, nobody gets fired for buying IBM and whatnot).

6 Likes