Do you believe that one of the core principles of NixOS is its declarative approach?

[nyabinary]

Question

If so, should NixOS strive to further minimize state and enhance its declarativity in the future?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[mschwaig]

Yes.

If so, should NixOS strive to further minimize state and enhance its declarativity in the future?

I think this is one of the technical issues, where the steering board should act like gardeners and not like an architects, and only if it's necessary.

I think specific proposals about this kind of thing should arise in and gain support from the community first, and not come from or be blessed by the SC.

[tomberek]

Do you believe that one of the core principles of NixOS is its declarative approach?
- If so, should NixOS strive to further minimize state and enhance its declarativity in the future?

Personally, yes and yes. Though I would expect most decisions about this to be delegated to the appropriate teams rather than a top-down approach. The SC would be more involved with ensuring that those teams exist, are functioning, and that their decisions are communicated.

... ensuring that decisions are made explicit, along with their origins. - Ensure project decisions get made in a timely manner as far as possible...
- https://github.com/NixOS/nix-constitutional-assembly/blob/main/constitution.md#steering-committee

In most situations, we should let people explore solutions in a non-interfering and non-dictated manner.

TIP: When there is an interesting problem, try to get multiple teams competing to solve it. Competition is great fun and can produce better answers than monopolized problems. You can even explicitly create competitions with prizes for the best solutions.
- https://hintjens.gitbooks.io/social-architecture/content/chapter1.html

Contention

If a truly contentious topic came up related to the direction of development for NixOS that could not be explored simultaneously in a non-conflicting manner, then we may need to decide. My thought process is to find out who should decide. We have:

• the RFC process; good to get input, but doesn't scale well nor establish effective ownership.
• NixOS Release Team; relevant expertise, but is not a permanent team and is established with only a specific task each time.
• No specific team listed in https://github.com/NixOS/nixpkgs/blob/master/maintainers/team-list.nix or https://github.com/NixOS/org/tree/main/doc
• anyone else?

It seems then that the SC should consider identifying and establish a team specifically for long-term NixOS maintenance and decision making, or expand the NixOS Release Team with the role to decide.

Deadlock

If those mechanisms all stall and fail, it then falls to the SC to break the deadlock.

[getchoo]

Do you believe that one of the core principles of NixOS is its declarative approach?

100%. I've always found this to be the most appealing part of NixOS, and it supports the functional deployment approach Nix has taken from the beginning

If so, should NixOS strive to further minimize state and enhance its declarativity in the future?

Again, yes. Improving what is one of the project's most unique and powerful aspects will do nothing but good IMO.

This is not to say NixOS should only focus on this, though. I wouldn't want it to put some of NixOS' imperative possibilities (that have been quite important for users just starting out) on the backburner

[Scrumplex]

Do you believe that one of the core principles of NixOS is its declarative approach?

Yes

If so, should NixOS strive to further minimize state and enhance its declarativity in the future?

Obviously there is only so much you can do to achieve this in the real world. Sometimes state is useful (i.e. allowing NixOS to know which UIDs/GIDs have been used before) and other times it is mandatory (like with a database).

I think the challenge is to find a balance between stateful and stateless configuration. For example I think it would be great if I could configure Postgres users and databases using a stateless and declarative configuration instead of a convergent one (see NixOS/nixpkgs#206467). But I would argue that this is a non-trivial problem and wouldn't really be something that the SC should specifically work on.

[nyabinary]

Yes. (It's, in fact, one of the main reasons I switched to NixOS in the first place)

I believe the declarative nature of NixOS is a fundamental strength that sets it apart. It empowers users to manage systems with precision, fostering both predictability and reproducibility. As we progress, I am committed to advocating for enhancing this declarative approach by minimizing system state as much as realistically possible. My goal is to extend these benefits to all system aspects, including secret and home management, ensuring consistency while maintaining flexibility and ease of use.

[winterqt]

Yes to both (where it make sense), plain and simple; it's what we're all here for, after all.

[proofconstruction]

Strong affirmative to both questions. The declarative approach is crucial both for effective static analysis and for useful version control. In the context of NixOS deployments, being able to reference the current configuration files and have a high degree of confidence in the runtime state is absolutely invaluable. Future expansions on this theme will be very welcome; I'd especially like to see a Nix-based answer to database state, particularly with declarative migrations.

[Infinidoge]

Absolutely. In my configuration, all of my machines (except for ones i haven't actively used in a long time) are impermanent with a tmpfs root, and everything I configure is actively done through Nix and nothing else. The more I can declare as part of my configuration, the better. I agree with proofconstruction that something I want to see is better handling of database state. Working with Postgres is easily one of my biggest points of anxiety about my current server setup.

Additionally, one of my biggest recent sticking points has been the move to relying on systemd state directories for generating the long-term storage of where state should be. I want to be able to declare that location myself, and having to vendor several modules to accomplish that is frustrating. But that is a matter better suited for elsewhere.