Nitrux uses the Liquorix kernel, described as “an enthusiast Linux kernel designed for uncompromised responsiveness in interactive systems, enabling low latency in A/V production, and reduced frame time deviations in games.”
It also uses OpenRC instead of systemd. New in this release is kboot, a utility to switch kernels on-the-fly without needing a reboot, and VMetal, which allows users to run Windows in parallel to Nitrux to provide users of access to Windows software.
You must log in or register to comment.
Has anyone done an unbiased comparison of systems/openrc/whatever that compares each doing what it does best? So far the only difference is just me not having a clue how to do what I want when distro hopping.
They both achieve the same thing in different ways, but it comes down to philosophy if that even matters to the user. You can build gentoo for example with openrc or systemd, and depending on what you do you’ll need to integrate things differently (using elogind with openrc since logind is systemd specific). In gentoo it affects how you’ll compile. Its really a non issue, but it all depends on what level folks wanna spend on something that could potentially be different. I use openrc daily on multiple setups and it took maybe a week of using it to get the hang of it. Its just operationally different.
Does it really matter for most folks? No. But if its something you find interesting, it can be a nice change based on personal views and principles. I run openrc because I personally as a programmer don’t believe in how “proprietary” systemd is designed, nor agree with the decisions the maintainers have made. That’s just my opinion. At the end of the day it doesn’t technically matter.
This is a more hardcore viewpoint but it covers a lot of the issues folks have with it. https://suckless.org/sucks/systemd/
Cool I’ll check that out. I don’t think I’m at a level where the differences significantly affect me but I don’t really know what they are to begin with.
I use Gentoo which originated openrc but also enables systemd.
They’re both fine. Both will do the job. Systemd just can do more without additional packages or can be configured / built to be pretty minimal.
At the end of the day, they all achieve exactly the same experience. The only real difference is that systemd does a lot of the work for you. Personally I wasn’t a huge fan of micromanaging my services manually on openrc or s6
i used them all, i didn’t notice much difference. but openrc has the coolest bootup screen by far
Great with more systemd free distros!
I use Devuan, if you need Debian without systemd.
I’m quite possibly an idiot, but immutable to me would mean it’s not update capable. Is it only partially immutable? Is it deleting and replacing?
Immutable in this context usually means the root filesystem is readonly at runtime, and all changes are performed by updating a set of declarative config files that describe the desired state of the system. Changes would be prepared and applied after a reboot. Something like that.
That makes sense. Thanks!
Looks interesting but I think claims of VMetal in regards of gaming are kind of bullshit. I have been looking into running windows/Linux in VM and have it full access to GPU (GPU pass through) and there are 2 major problems.
-
Nvidia and amd being scummy and having firmware limiters in consumer GPUs to segment their products. This should be “fixable” by modifying firmware but … Yeah… Not very comfortable thing to do
-
Motherboards not having support or worse have broken implementation of iommu.
Maybe my “research” was bad. Let’s hope someone will correct me.
Not sure what firmware limiters you’re talking about? I’m using a cheap ASUS board (B450i-gaming), a Zen 2 CPU and a 6600 XT, and single GPU passthru works just fine for me on Arch using this guide. (I haven’t tried VMetal or this new release of Nitrux yet). Yes, some manufactures are iffy about IOMMU support, mostly Intel-CPU and Intel-based boards in my experience, but if you’re using AMD you should be fine.
There is something called an ACS override patch, but that’s a kernel patch not a GPU firmware patch, and from my understanding, that’s for dual-GPU users. Regardless, it doesn’t modify your firmware in any way.
Not sure what firmware limiters you’re talking about?
The same limitation mentioned it the guide you shared:
This solution basically hands over the GPU to guest OS upon booting the VM and hands it back to the host OS upon powering off the VM. The obvious downside of this is that you can’t use the host OS (at least graphically) while the guest is running. It is therefore highly recommended that you set up SSH access to your host OS just in case of issues.
Also thanks for sharing it. I will try it some other time. 🙂
Patch NVIDIA BIOS (only for Pascal GPUs)
Only 10xx is affected or older cards are too ?? 😑
-
