Another down-side is that the maintenance would more expensive. When you backport a fix, there’s a difference if the codebase is three months or six months old (on average), even if I disregard the possibility that you may not need to backport some stuff thanks to shorter support time.
EDIT: I should add that at least in terms of open CVEs we already seem rather undermanned in this respect, though I expect most of these are not that “severe” and many others have been fixed but not marked so.
I think the reasons there are mainly historical. IIRC, once upon a time Eelco based the first graphical ISO on KDE (was it 4 already?) because… it was the DE he was using? Anyway, as usual, much power lies in hands of those who are willing to do the work and maintain the DE/ISO. Having an official image for a DE will add some motivation but probably not enough by itself to keep it in good shape, so I believe it primarily needs dedicated maintainers. (I’m convinced such things are not for the release managers to do, because they have too much to do already and typically can’t even do all that on full time.)
In case of graphical ISOs there are additionally significant costs to infrastructure, as frequent rebuilds of the images are relatively expensive (e.g. lots of S3 storage, as there’s no sharing among the large images). At least that’s how it used to be discussed, maybe some garbage-collection changes can improve that relatively easily.
Release dates (minor consideration): I think it was advantageous for publicity to release before the Ubuntu family, and releasing soon after them may be the worst in this respect. I don’t think I’m good at PR, so I may be wrong or the real effect may be totally negligible. I’m not aware of other SW than GNOME ecosystem being significantly aligned to Ubuntu schedule, but it is possible there are more (now or in close future).
If I am representative of a typical desktop user (which I don’t know), there might be slightly different accent here. I use stable mostly because it is default, I haven’t really considered whether I should use unstable.
That said, I definitely feel friction because some important for me packages lag behind (notably, editors like VS Code and JetBrains IDE). I think the de-facto practice is that updates for those are backported to stable, but with a noticeable delay.
So, maybe more of the daily-driver folks should be using unstable, and it’s a question of renaming it to “rolling” or some such?
Fedora is literally the GNOME schedule so there’s that too.
Currently the two yearly releases aren’t the best for desktop users because they EOL a month after the new release. It’s useful for desktop users to actually be able to skip a release and still be in good shape. But that would be a much bigger change, and having feasible milestones helps us to work towards a polished goal. A good example is for Pantheon. If we were to go rolling for these types of users Pantheon could never be polished because it breaks as soon as the GNOME base does. So having that frozen stack of software also helps for desktop maintainers as well. The issue with your packages lagging behind is actually related to the release maintenance, all of those updates are usually okay to backport and should be (for a while actually I was backporting all the VS Code updates and telling the maintainers to do this… but when I wasn’t there to do that maintainers didn’t care to bother). So that issue is maintainers aren’t keeping the release fresh and they really should. I try to do stable updates to NetworkManager on releases and for actually all the things I maintain where it’s feasible. In other distro’s having ports to their stable releases is actually a bigger deal, I’ve noticed, so maybe we could add this to our documentation as a “maintainers responsibility”. GitHub actually has actions to create backports, so maybe if someone makes an RFC for that backporting your changes will just be a comment to create a PR and automated checks.
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.
Hi 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
interesting.
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
taste.
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…
– Ingmar
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
background
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? - #106 by jonringer , 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 unstable.
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.
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.