Personally, I’m looking forward to native Wayland support for Wine and KDE’s port to Qt 6.
Red Hat dying
Just because they’re fucking up RHEL doesn’t mean they’re not the biggest contributer to Linux there is.
-
bcachefs; I currently use zfs and am not a huge fan of btrfs. Having another filesystem mainlined will be fun.
-
eBPF, particularly if somebody picks up after the presumably abandoned bpfilter.
-
Improved/matured support for rust written drivers. I’m not so fussed about in-tree work, but future third party drivers being written in a safer language would be a nice benefit.
-
long term: the newly introduced accelerator section of the kernel might make SoCs with NPUs and the like have better software support.
-
very hyped for plasma 6, and Cosmic both. I’ve got a lot of confidence in KDE devs, and Cosmic previews look very nice.
-
NixOS has been a really cool distro for a while, but it also looks to have a solid build system from which interesting derivatives will show up.
My issue is not with the ARC, it’s a few things:
-
kernel integration is iffy; I don’t want to attach a module to my system every time I compile the kernel and prey that the difference in pace between the release schedules of openZFS and Linux hasn’t caused issues, and because of the licencing issues my options of having a distro with zfs built in are very limited.
-
it’s performance isn’t excellent from a NVME standpoint. It’s not terrible, but it could be better.
-
it has a massive code base, making introducing things like performance improvements and new features quite a challenge (Though the openZFS team are doing a bang-up job despite this).
Ultimately if I was still holding on to 40+TB of important data, I’d be using ZFS and be happy about it. I want snapshots on my workstation, without all the strange issues I’ve had with btrfs. I’m sure bcachefs will have its own issues but it’s better to have options.
Sure, I understand the part about having to compile the ZFS module every time alongside the kernel. But that must be some heavy-lifting you’re doing if you’re regularly compiling your own kernel. I’d be interested in what you’re running that requires such efforts.
I don’t understand why you would need NVMe for ARC. Doesn’t it run in RAM only? Isn’t L2ARC what runs on storage devices?
It’s a technology that lets you run code through the kernel’s JIT compiler. It’s an extremely flexible way to run code in kernel space; the typical example is using it to build XDP programs for networking, which can deeply analyse network packets without having to incur the performance penalty for changing context to userspace.
from which interesting derivatives will show up.
I don’t think that will happen and hope it won’t because NixOS can handle the usual preferences people might have internally.
Don’t like glibc? pkgsMusl is the entire package set but with musl instead of glibc.
Want static compilation? pkgsStatic.
Afraid of systemd? Well okay, we don’t have that right now but I don’t think anyone would be opposed to optional support for worse service managers. It’d just be an opt-in toggle that we could support with enough people interested in it.
Nah, people always want to put their own spin on things and I welcome the diversity.
Arch can bring in all the necessary packages yourself, but Garuda exists and people enjoy using it. Horses for courses.
Garuda only exists because the only way to distribute a set of default configuration in regular distros is to create a whole new distro/installer. We don’t have that problem in NixOS because all configuration is declarative and composable.
In the NixOS world, Garuda would be a NixOS base config which users would import in their own config and extend with their own configuration. You’d still be using NixOS though.
Flatpaks seaminglessly supporting all apps plus cli applications and drivers would be the holy grail.
- Nix (OS, the package manager, and the language) having excellent and exhaustive documentation.
- It being so easy to use that my grandmother could use it. Heck, a GUI to handle packages would be amazing!
It has so many interesting possible applications. Declarative and reproducible wine configurations for games and software; universal (cross-distro) packaging (without emulated runtime environments like flatpak); reproducible user environments managed easily with a GUI with trivial version control (both for config and software versions); pre-configuring a system before even setting it up (such as configuring a raspberry pi before you’ve even bought one so that once you have, you just install and configure everything in one go).
I dont think thats really the goal here. NixOS is not designed to be used by your grandmother. Better Documentation would sometimes be nice though.
By the way, there already is https://github.com/vlinkz/nixos-conf-editor
It isn’t not the goal, either. Nix is very popular with devs for many obvious reasons, so most of the developments naturally has to do with making that an even better experience. That doesn’t mean accessibility is a non-goal; there just isn’t a great deal of motivation to work on making the operating system easy for non-devs to use.
Probably not the goal, but a NixOS-based begginer distro could be great, with one app to install all your package and one app to manage all your settings. (I personally really like the idea of having app settings in the “general” settings app). But probably the killer advantage of NixOS is that it’s really hard to break and really easy to fix, which is important for a distro aimed at the general public.
P.S.: Also check out nix-software-center by the same guy.
Martin Wimpress is working on it https://github.com/wimpysworld/nix-config
SteamOS is making huge strides for adoption, i look forward to more people being freed from corporate lock in.
While what you say is true it is also irrelevant to OPs question. SUSE is a corporation, so is canonical, so is mozilla’s corporate wing. can you clarify what your point was, pal?
edit: ah, i used the word corporate, fair point then. I meant in the sense of vendor lock to defacto standards rather than ‘corporate bad’.
Steam/Proton/Gamescope work outside of steamOS. Valve contributes to open source software, including linux amd drivers, that can easily be used outside of steamOS
Valve contributes to open source software
Maybe so, but Steam itself is still proprietary, closed source software.
*freed from Microsoft’s monopoly. Valve is still a corporation.
They have a lot of work to do before they can publicly release it. They really messed up basing it on Arch, IMO. Whereas Fedora has their Silverblue and SUSE has their CoreOS, Valve is really treading new ground with an immutable Arch distro. As it is now, the immutability is a major barrier to doing even very simple things. If I want to install an external driver on Silverblue, I just navigate to it’s folder and run rpm-ostree install -driver-. SteamOS has no rpm-ostree equivalent, so you have to disable read-only which is more complicated and defeats the purpose of immutability anyway.
Valve will have to develop a bunch of brand new tools or (more likely) contract the work out, which as far as I know hasn’t happened yet even 1.5 years after official release.
I guess my point is they made an easily accessible experience that is not frustrating to use for the average user which will help dispell the belief that linux is hard to use or that gaming is only for windows. They provided a console like experience and made it hard for normies to break it. You’re free to install silverblue on the thing. Personally i’ll probably re-image with arch later but for my use so far I haven’t really have to change anything. I haven’t run into an issue that couldn’t be solved with a flatpak yet.
