The time for a new NixOS release is approaching us once again. The release of NixOS 19.03 “Koi” will be managed by @samueldr and myself. This year, we’re aiming for a feature freeze and branch-off on the 25th of February in order to get a release* within March.
Some of the changes to look forward to from 18.09:
Your change here! If you have anything big that you want to get into the release, please let us know (@lheckemann and @samueldr on GitHub), especially if you’re not sure if it’ll be in master by then.
Between the 25th of February and the release, we will be working towards Zero Hydra Failures and starting the regular release maintenance work, backporting minor bugfixes and security patches.
Looking forward to working with you for a wonderful release!
Linus
*Releasing actual koi into the wild may damage ecosystems and be illegal in your jurisdiction. Please don’t do this.
One feature I’ve been working on is less reliance on nscd for caching because it broke systemd dynamic users. Caching now is only used for positive lookups of DNS names, all other forms I’ve already disabled. This fixed some issues with NixOS laptops sometimes not being able to browse the web when roaming.
I want to get rid of the nscd caching totally, by replacing the name lookup cache with systemd-resolved. Nscd is then purely a proxy for resolving NSS modules in the nix store. It should eliminate a lot of caching related bugs that we’ve faced before.
Also I would like to see a new version of systemd for 19.03, as there were issues with Cgroups V2 not working well with nixos-containers that have been fixed. This could allow people to opt in to Cgroups v2 without issues.
It would be great if we also can manage to switch from C to C.utf-8 locales in stdenv and our glibc package as many applications now expect unicode locales (i.e. python). Debian and Fedora are already on board with this. Also since systemd has now support for that too
I’d like to create logrotate rules by default for enabled services like apache, etc… like other distros do, or at bare minimum document the need to rotate logs.
Users coming from Debian can be surprised to find out their logs continue to grow indefinitely instead of being rotated automatically like they are on Debian.
I’m willing to do the work on this, but would like to hear any opinions that people have before I start.
Yeah for desktop use case there isn’t anything to turn on for logrotate usually, as it is covered by journald as you mentioned.
I’m thinking for people who enable services which are not covered by journald.
The 2 use cases I have in mind are apache and rsyslog. I think there is value in automatically rotating those logs for users, like Debian does, or at least making mention in the documentation that the user needs to set up log rotation as most users would expect this to already be in place.
We have a milestone for 19.03 to track issues features and fixes we want included in 19.03. You can see a list of them on GitHub under the 19.03 milestone:
These are sometimes more manageable to try to help out on compared to random ones from the global issue tracker.
