That would inherently require to increase the (average) number of releases supported at once, i.e. additional people maintaining releases (and other) resources.
true, I hope one day this could be a goal or we could investigate other models. Currently we couldn’t do this at all.
I suspect, without proofs, that NixOS users are a little bit more
server than desktop, however I’m pretty convinced, again without
proof, that most NixOS users are “expert enough” to choose their
own environment(s) so the official ISO is probably mostly used by
new users to made their first NixOS personal deploy.
Create custom ISO, at any point in time, for instance from stable
channel, embedding personal configs, is super-easy to a point that
passing through official ISO after the first time is not much
If the above statements are true having official images/releases
with modern DE is a big work for developer and nothing much
interesting for end users. Users willing to use Kde or Gnome will
install it from their final config, regardless of the live default
environment, as any other desktop users for their favourite DE/WM.
A GNU/Linux “power user” could be interested in NixOS because of Nix
not because of Kde or Gnome default desktop experience. A newcomer
to GNU/Linux probably fail to use NixOS anyway since maintain a
config is not for that kind of users.
In release instead of ISO image terms, supporting Kde and Gnome is
something probably most users expect, even if they use some other
DE/WM, but the level of “polishing” might not be that critical.
Also personally I think that in a not so far future Gnome will be
GnomeOS, Kde will be something similar, so painful to be used
outside that most distros will drop them. Only an official distro
for one and the other will remain… They have go far past the
level of usability in *nix terms already…
Long story short IMVHO a default with something really neutral in
modern terms, like XFCE, it might be far simpler and made most
users happy enough. People like me using EXWM do not be much
annoyed by such “lightweight” desktop, People who like modern DE
would not be lost in XFCE, a default nice theme (like Xubuntu)
might be enough for all.
Local docs with an well visible “launcher” like NixOS manual and
NixOS Wiki embedded, a not so basic CLI apps selection, perhaps
zsh with a modern prompt, completers&c active, optional fish,
elvish, bash, few GUIs like GParted for people willing to work via
GUI, a modern lightweight text editor, nvim and Emacs, a GUI file
manager (Xfe like, Thunar, does not matter much), a Browser.
That’s IMO the best experience a new user might like, just taking
a look a /r/unixporn (Reddit) can be a good index of users mean
Also IMO instead of build two giant ISO (Gnome and Kde) a minimal
CLI iso, a light GUI iso and an optional zfs iso to avoid questions
about zfs license, can be better for most users. Taking a look at
System Rescue (formerly SystemRescueCD) software selection can be
another good example to take.
Offer pre-made code to generate a custom ISO, encouraging that
practice, offer pre-made configs for LUKS+LVM+zfs, zfs directly,
with or without crypto, [LUKS+]LVM+zfs, [LUKS+]LVM+btrfs would
be a very nice addition.
I doubt that in the near future NixOS, while growing, will be a
“mainstream top distro” like Ubuntu, Fedora or Arch, so try to
“compete” in their terms is not much a battle worth doing. NixOS
goals are reproducibility, robustness, “buil-in IaC”, NixOps,
Disnix, … the rest is only obligatory boilerplate aside.
Sorry for the length and bad English…
I think the people that are aware of NixOS will want to try it out regardless if it was released a month before or after Ubuntu.
Since we seem to need a month to stabilize around our “weird mix” of package versions, we never release on time anyway. So, being “ahead” of Ubuntu never actually occurs.
I think usually we released a little ahead of Ubuntu, even if it was a week or two behind the targeted month.
EDIT: of course, if we want to keep the timing, it seems easy to do the fork-off earlier… regardless of which month is targeted.
Another option would be to de-prioritize the desktop managers, and get the release out the door in a timely manner. However, I don’t like this as it makes the “stable” branch not really stable.
If I just take my personal original experience, I was happy to be able to test in a virtualbox machine with a desktop that I could use the system in a correct way before really jumping my local computer to NixOS, so sadly, having a DE (KDE or Gnome) was good to feel a bit more comfortable as the logic of the distribution is really different from other distributions.
I wouldn’t be able to use another distribution again… now, but the first impression, I think must be as smooth as possible, IMHO.
That said, now I have a flake with my tricks for my configurations / home-manager configurations / packages overlay, and I don’t use the iso the same way. So I don’t use the DE iso image anymore…
So, I think it is a bit crual, we should have a good DE ISO experience for beginners even though they use it only once.
I tried to help for this ZHF, but was not necessarly able to find the correct/canonical way to fix the different problems I saw, also the hydra UX is quite hard to follow, there is so much lag between a fix and a release, so I think I wasn’t as helpful as I wish . Maybe the stabilisation process should be started sooner .
Anyway. from what I read in this discussion, I think we should find a way to split the problem into multiple teams that work all the time, not only before a release: team KDE, team GNOME, team “Apps” (for vscode/slack/…) that handle the different schedules, so that each type of situation can handle the different timelines. I don’t know how to properly handle this (maybe more staging/dev branches for specific ecosystems)
Also as a newbie maintainer, I was expecting to receive some notifications from hydra when my packages were failing, I don’t think to go checking that everything is ok there. Maybe more tooling (or just doc) I would be happy to have my own r-ryantm bot just to follow my different packages.
My experience for the server part is on the contrary very good, but I feel that this situation is way simpler as there are a lot less dependencies than on the desktop world.
here are two cents of mine:
summary: +1 to optimize on people’s time and release May/November
I use NixOS in ‘production’ (my own mail server) and as daily driver (laptop)
for production: I want it to be reliable (only security updates or backports of broken packages)
as daily driver: I use EXWM so I personally do not really care about the big DEs, but my environment should just work.
If shifting the release months helps the NixOS developers, then that’s perfect.
I use NixOS as my main Linux OS. I’m not that experienced, but declarative configuration makes my life way easier than imperative.
I don’t mind tinkering and often do, but having a ‘stable default’ (plasma desktop) that you can just go back to, where just everything works, is a big point for me.
Perhaps also aiming GNOME was a wrong decision? It think it’s a lot of work to target two huge DEs. (but perhaps people willing to work on GNOME are wholly different people willing to work on KDE.)
R.e. server vs desktop, I would say that desktop users / daily driver users should be on the unstable channel. There is simply too much desktop software for backporting to be realistic with the current workflow. And considering that Arch Linux and its derivatives are often recommended for desktop users, the rolling release model can work well for the desktop. There is enough quickly-expiring software (browsers, chat clients, etc.) that the stable version is more often broken than unstable, in terms of usability.
I think the real issue though is the release being delayed due to strange software problems. This is similar to unstable being delayed (New Merge Policy for an always-green hydra). In both cases, the only real solution seems to be to ensure someone is actively working on fixing these failures; maybe the NixOS foundation could hire a release manager, or put up bounties on release-critical bugs.
Although I agree in general. I don’t think unstable is at the point that it’s realistic to expect people to put with the occasional breakages.
Yes, but in what I proposed above, it’s easier to just package the latest than having to troubleshoot our “unusual mix” of software versions.
All I really do is just polish docs and help with the process. I think having a reproducible process is more important than hiring a personality. As I mentioned Marketing Team: Can we present Nix/NixOS better? , we create a pretty difficult situation to release on time, and our release date always slips because of it.
Given how NixOS is structured and developed, I am not sure running on
unstable is for everyone, maybe
stable boot system / DE configuration with high-churn applications (which will not be that stable or that reliable in real world whatever version you use…) installed from
unstable, and maybe some high-impact high-quality well-stabilised software installed from
I usually rebuild my system from
master, though. Maybe rolling back if it gets too broken… But I also split the package set into many shards, which can be rolled back or delayed independently.
A post was split to a new topic: Package set shards
You release managers convinced me! Until the upstream projects test more comprehensively, we’re best off aligning ourselves to their ways. There’s ways to use any freed-up contributor time than fighting to make an odd combination of these components work.
Perhaps there will be a time “post wayland” when things settle down, but I get the sense right now the guts of mainstream Desktop Linux are rather unstable (in the original sense of “shifting around”, not necessary “broken” :)). This state of affairs increases the costs of non-alignment.
I absolutely agree with what @Mathnerd314 is saying about us needing to improve CI and what-not so we aren’t constantly shooting ourselves in the foot, but I think this is a little different, because I doubt it will be possible to incrementally update these desktop components while not breaking things — there is no magic “grey code” upgrade path.
First of all, even the most ambitious testing plans don’t call for the necessary suite of consumer hardware and CIing physical interactions (does hibernate work? Is there tearing? etc.)
Even if we did all that, we might be stuck contributing to the underlying packages much more than we can afford to actually fix discovered issues.
Overall GNOME is and has been easier to upkeep than plasma and has a lot more purity atm
I’ve already mentioned above that having an eternally rolling channel for desktop distribution isn’t going to work really well in nixos because we for 1. can’t move fast enough and 2. for GNOME using desktops the stack changing will make maintaining unstable pretty hard or broken for periods What should stable NixOS prioritize? 3. Having a stable release with a frozen base of packages allows us with our resources to provide a better experience
I’m not sure if the NixOS foundation, being a non profit, can hire people so they can make profit to work on something? idk, I would have to check but if I was being payed to do releases it probably would have been a slightly different story.
I’m not sure if the NixOS foundation, being a non profit, can hire people so they can make profit to work on something?
I’m pretty sure non-profits can have employees (and contractors)…
NixOS isn’t really a product you can sell.
You could have have consulting around it, and that’s essentially what tweag is.
However, I’m all for hiring a NixOS/Nixpkgs full-timer. It would solve a lot of issues with community engagement to have someone review PRs, respond to issues, be aware of most things at a high-level.
I spend 20-40 hrs a week on nixpkgs, and most of that is “maintenance”, I’m no longer making many PRs or commits. I would love to go back to be just a “contributor”
Hehe, I felt similar, you cannot make commits like that when you’re a RM. Lol, if the foundation is interested and having two people at least part timing they’re before you
I would like to share my view to this topic.
First I would like to state that I really value the work that everybody is putting into make NixOS a great Desktop distribution. I use it for years now (9years) and I can not imagine using something else.
Also I think we all agree that managing a Desktop distribution is a lot of work. I have witnessed numerous super human efforts into what NixOS is today. This kind of efforts also burned out many contributors in the past (including myself). I don’t think this is a sustainable model going forward or at it is at least very unhealthy.
I do think postponing the release for 2 (or even more) months - as proposed by @jonringer - will offload some of the desktop integration work to other distributions. I think this is the easiest change we can do immediately (eg. next release) and observe if we are next release are going to be easier to do.
I do hover see that in order to improve NixOS we need to increase our contributors. And since the contributors are first users and then contributors we need to first increase our users. I don’t think focusing on Desktop will improve substantially, only because the market for linux Desktop is not as big as - for example - Server market is (this also includes all the cloud stuff). Also the problem space with Server version of NixOS would be much smaller and more achievable for smaller teams like NixOS.
I’m not entirely sure how to get to this Sever version of NixOS but here is what I would propose:
NixOS release process stays the same, it is not nice to break expectations
create NixOS Server (or NixOS Minimal or NixOS Cloud) version of NixOS which is released 2 months before NixOS, only to be used as a base on which Desktop stabilization is going to happen.
we would also need to create a new channel which is between “unstable” and “stable”. We might even call it “server” (or whatever this version of NixOS is going to be called). For certain period “server” and “stable” will actually be the same and we can mirror them, so there is no need to back port to both branches all the time, just in those 2 months when “server” and “stable” channel are different.
I think above solution would solve the problems mentioned in this thread so far (at least to my understanding). Also it wont break the current way of doing things if we give it a try.
I find it a bit funny that the only way to help Desktop version of NixOS is to de-prioritize it and focus on Server version of NixOS first until our user base grows and is able to support the effort. But I do understand that not everybody sees it this way and want to work on Desktop version of NixOS today and we shouldn’t prevent that (or make it harder) in any way.
EDIT: probably off topic but I think there should be a release team behind release manager which would help resolving release related issues. I think that would make the job of release manager much less stressful and manageable.