NixOS for Workstations vs NixOS for Servers

Rephrased (with not absolutely equivalent semantics):

  • “NixOS for Home”
  • “NixOS for Business”

Or still:

  • “Nix for Home”
  • “Nix for Business”

I got the impression in many recent and previous interactions, that many discussions tacitly lack sometimes clarity about the fundamental target use case: “Nix(OS) for Home” or “Nix(OS) for Business”.

Sometimes, it’s obvious, sometimes it’s less obvious. But the main question is: how often it’s actually conscientously and deliberately one thing or the other?

I think, the Nix Ecosystem would benefit from more prominent clarity in semantics.

Not only would discussion benefit, but also the comonalities and distinctive qualities of these use cases may help build better mental models and fuel the evolution of the Ecosystem.

Personally for example, my perspective is 90% of the time “for Business”. And it would probably help to not apply that mindset in a discussion or project that is clearly labeled “for Home”.

Equally, it might help consumers of the ecosystem to quickly find if any given tool or invention is suitable for their useage scenario.

If this idea enjoys momentum, one could even think of such pervasive application as to create official(ized) “Nix for Work” / “Nix for Home” repo badges and the like.

My 2 cents on the current nomenclature undertaking; I hope somebody from the doc team will advice me how to route this properly. :grinning_face_with_smiling_eyes:

4 Likes

I don’t think we should distinguish them. I’m sure many companies run on crappy code I would certainly not even use at home :sweat_smile: while some other companies may requirements so complex that a full time person isn’t enough (and can’t be done at home).

Nixpkgs is free software under MIT license, Nix is AGPL (IIRC). No guarantee comes with them, this could be a blocker for some companies I suppose.

Then, for the ecosystem, I think we hit a few issues:

  • we have different opinion the meaning of “business grade”
  • software author may think their tool is “business grade” enough
  • tagging a project “for home” may hurt a good project that could be useful for companies
8 Likes

I’m not sure if this is a good argument.

Because I can tell from my very own experience, that the line isn’t as blurry, as a matter of fact.

“For Business” comes with a certain opulence in (yes) tacitly assumed guarantees (which ones? → tbd).

“For R&D”, which is sort of what I read into your argument, is still some mileage away from “for Business”. And R&D has a tendency to ignore this and look for the good stuff under the hood, anyways. So the distinction wouldn’t necessarily break your point in the way you suggest.

But as a matter of generalized mental model, the current blurryness is a hindrance to X (adoption, ecosystem dynamic, job opportunities, …). This is just because we have to take on the perspective of “a Business” and it’s needs: Cost Effectiveness,
Time-to-Market, proven solutions, etc. All these things (and more) all of a sudden become (a blocking) priority.

I think there are precisely two things that drive “Nix for Business” with its current feature set and that is: DevOps & DevX (though we still fail Mac users & windows users do exist, too).

So if somebody wants to monetize in later stages on the huge initial personal investment (of learning the Nix Ecosystem), then I think these are the two corners to look for (first).

I think it is entirely possible to map “for Business” to some sort of conceptual continuum that includes “for DevOps”, “for DevX”, but in general also caters the oversimplification requirements of effective marketing.

EDIT:

As an additional data point.

In a recent discussion I raised the importance of documentation (in the https://diataxis.fr sense) in a probably not as clearly labeled “for R&D” discussion, because of my underlaying “for Business” assumption.

I got barked at because in a “for R&D” and “for Home” type of discussion, documentation can be forgiven upon (best example: Nix itself, but this is fortunately changing).

This even culminated in a quick Moderating action.

We see: the fundamental perspective and clarity thereof is important for fruitful (and helpful) discussions. I obviously can apply this “illumination” all by myself, but that doesn’t necessarily benefit the ecosystem at large.

2 Likes

The nix community is already fragmented enough. Encouraging further separation seems to be going at the problem from the wrong direction.

9 Likes

I think the mantle of “NixOS for Business” will probably be taken by one or more companies that will provide LTS releases, à la Red Hat. The community should not concern itself with this, IMO - we’re not all businesses nor trying to run one, Nix is a labor of love :heart:

3 Likes

Wouldn’t you agree that the fragmentation is precisely a symptom of a missing unifying semantic that calls alike “alike” and distinct “distinct”?

A solid mental model (not only in the distinction between “for Business” vs. “for Home”) tends to align people and exert an invisible coordinating force through inherent clarity, which might be precisely the answer to the shortcoming that you raise.

I think it is rather futile to approach this the other way round, as you may have implicitly suggested, by (even if only carelessly) calling distinct “alike”.

I think there is nothing better that could happen to this community than orderly differentiation based on a comprehensive common, unifying semantic.

In this context, this post, indeed, focuses on the question of the hobby-business continuum.

I feel I have been misunderstood, here. My initial post cites three "anti-"pairs to describe a semantic continuum that acknowledges two fundamentally different use cases.

Of course, brand names will emerge around use cases, but, I agree with you, that these (commercial brand) dynamics are not of concern for our own ecosystem semantics. Which we are free to choose, if they help us.

And the argument being: it would help us.

I disagree completely, actually. As I see it, the fragmentation is due to a lack of similarity in the issues, terminology, interfaces, etc, which each usecase brings up. A simple example is “installing a package”. This basic interface looks rather different across different usecases (NixOS, nix-env, nix-shell, flakes or not, etc), and that discourages unity in discussion and problem solving, as well as discouraging people familiar with one usecase from trying out another, contributing to the segregation of the community.

3 Likes

But I do not think that this (type of things) is driving business value. In my opinion, as I explained above, what drives business value coming out of the Nix Ecosystem is DevOps and DevX, at this point.

So by capping the wealth of expressiveness and differentiation of the mental model to a constricted set of catch-alls: It is as if it was an antithesis to the argument of bridging segregation. A path-dependent semantic emanating of a clearly observable predominant set of (“for Home”) use cases, that sometimes is simply nothing more than a mismatch.

While I do absolutely agree on the interfaces (and if by chance you’ve had an interest in Standard, you wouldn’t doubt a second), I do not think that the semantics of divergent, but fit-to-purpose mental models are constricting precursors to common interfaces.

Interfaces are contracts and the beauty of contracts is that they can be negociated between perspectives that come from vastly distinct backgrounds and interests, as long as there exists an intersection of interest.

I haven’t seen a worthy contract, where a predominant perspective is simply “taking over”. Studying the counterpart within her own mental model is inevitable. And negotiating is, as well.

1 Like

I’m afraid I don’t understand what you mean. Could you write this in a more simple style?

1 Like

mental model != interfaces - I think @tejing (no offense) confounded them in his reply.

  • mental model helps with reason

  • interfaces help with communication

Interfaces, thereby naturally span diverging domains of reason. And that is good and useful, not bad and segregating.


Then, again, maybe I misunderstood @tejing , ofc. :grinning_face_with_smiling_eyes:

It’s all rather more tied together than you’re making it. The interfaces we use to solve problems also become the language with which problem solvers communicate with one another, and strongly affect the mental models we build.

We’re getting somewhat far off the original post, and it’s becoming increasingly clear that I may well have no idea whatsoever what you actually meant by it. The main thing I gleaned from it is that you want discussion, solutions and such so be labelled by what usecase they related to. Abstract language aside, this seems like it’s explicitly requesting greater segregation of the community.

3 Likes

Absolutely!

No, this wasn’t meant primarily with a labeling spin. The spin of my post was clarity of use cases (and what they entail). To have a common understanding of that, you need a glossary.

Glossaries are one of the most effective tools against “segregation” (you’d need to start to define it, though), that I know of. Labeling is insofar just a natural consequence thereof.

To that extend, I really can’t follow your argument and still think it contradicts itself.


If you want, I can offer to read over it again tomorrow with a fresh mind :grinning_face_with_smiling_eyes:

Clear definitions are needed regarding technology itself. However, I don’t see why the nix community should strive to make clear distinctions between categories of human endeavor which happen to use nix. Is there an actually technical distinction you’re seeking to make here?

Too many definitions are just as detrimental as too few.

2 Likes

I can agree that as long as we are in the endeavor “for R&D” (which may be a department of a [big] business), it is not absolutely fundamental to ask for the endeavour.

In such scenarios, productivity constraints are such that an offer-driven interaction (i.e. “i don’t care about your endeavour”) is not a deal-breaker.

So we can start arguing: “Nix is offer-driven (and we don’t care if that’s not for you). You need to have (and spent) the money for R&D or you’re precluded from the benefits of Nix.” *

I, personally, wouldn’t appropriate such a stance, if the community decides to. I do beleive that offer and demand are just two sides of the same medal. And if we make ourselves true, then we realize: of course there is a demand for Nix, something drives people to spent time with it.

The argument that is resounding in my postings, here, is that this demand is predominantly driven “for Home” / “for Study” / “for R&D”.

So are we really offer-driven (and we don’t care if it’s not for you)? No.

But we would benefit from practical clarification of the needs of “for Business” / “for Work”, and even if for nothing else, still because we’re an open, curious and (business-)friendly (?) community.

So what can that use case mean?

I said above that it comes with certain opulence, without specifying that further.

I do not think a “support contract” (LTS) is what I would expect of something that lays claim on being “business ready” or “designed with work in mind”, although support may be a business model in itself for Nix entrepreneurs.

Since I think the reasons to spend money on nix (in exchange for some productivity surplus — because ultima ratio doesn’t spend money on anything else) lies within DevOps and DevX, we may have a closer look what entails an overperforming DevOps and DevX function in a business / productivity context — empowered by Nix.

These are very varied demands, and I can really just cite a random few at this point, such as: ease of onboarding, soundness of design, robustness, ease of maintainability, UX and fieldability.

This last concept actually reminds me of NASA’s Technology Readiness Levels, which may be actually a good start to look for further ideas / discoveries.

Ultimately, it mostly boils down to some variation of “Time-To-Market” or derivations thereof. That’s where businesses be born and die.

* As a side-note: what do we end up with if everybody starts spending money on R&D, for real? → fragmentation, precisely.