KDE Plasma, x86-64-v3 (AVX2), Nvidia

[azizaktas]

Hello,

I’ve tried many different distributions, so I only used AnduinOS for a short time. I remember it being very smooth and fast, but there are a few things I can’t remember.

Do you have plans to add KDE Plasma support within the next 1–2 years?

Ubuntu recently introduced official x86-64-v3 (AVX2) package optimizations through its architecture variants feature. Since AnduinOS is Ubuntu-based, does it currently include these v3/AVX2 optimizations, or are there plans to support them?

Are NVIDIA drivers installed from the Ubuntu repositories, or do you use a dedicated repository? If so, how frequently will the drivers be updated?

Those are all my questions.

I think AnduinOS is a truly unique distribution. I used GNOME for a while and never got bored of it; it was genuinely enjoyable to use, especially with the extensions.

AnduinOS is also the first Linux distribution I’ve encountered that boots in just 3 seconds.

What I appreciate most is that it provides separate support for both Ubuntu LTS and non-LTS bases. Since I want newer software, desktop environments, kernels, and other packages, I’ll be using the Ubuntu non-LTS variant.

Also, thank you for freeing us from the problems caused by Snap. Thank you for all your hard work and effort.

[siyamsec-lab]

A few points may be worth clarifying here.

For KDE Plasma, I don't think it would be safe to assume that official Plasma support is planned unless the AnduinOS roadmap or maintainers have explicitly mentioned it. Since the current desktop experience is closely integrated with GNOME, adding Plasma would involve more than simply installing the KDE packages—it would also require maintaining the desktop integration, defaults, theming, system components, and testing.

Regarding x86-64-v3/AVX2, the fact that the base system is Ubuntu-based doesn't automatically mean that AnduinOS receives Ubuntu's x86-64-v3 optimized package variants. That depends on how AnduinOS builds and selects its packages and architecture configuration. I'd verify the actual package architecture/repository configuration before assuming v3 optimization is enabled.

For NVIDIA, I'd also check the actual package sources and installed driver packages rather than assuming a dedicated repository is being used. On Ubuntu-based systems this can normally be determined with:

apt policy nvidia-driver-*

and:

apt-cache policy | grep -i nvidia

You can also check the installed driver with:

nvidia-smi

For the AVX2 question, the CPU feature set can be confirmed with:

lscpu | grep -i avx

and:

dpkg --print-architecture

The 3-second boot time is interesting too, although actual boot time can vary significantly depending on firmware, storage, graphics initialization, and system configuration.

Overall, I agree that these are good questions for the maintainers because KDE support, architecture-specific optimizations, and NVIDIA driver maintenance are all things that depend heavily on AnduinOS's own packaging and development decisions.

[Anduin2017]

Regarding x86-64-v3 / AVX2: AnduinOS currently does not enable the amd64v3 architecture variant by default, and I don't have plans to change the default architecture at this time.

AnduinOS 2.0 is based on Ubuntu 26.04 and uses Ubuntu's official package archive together with our own AnduinOS package repository. We intentionally continue to target the standard amd64 baseline in order to preserve broad hardware compatibility. Users with supported CPUs who understand the compatibility implications can still opt into Ubuntu's amd64v3 packages themselves through APT.

Our general approach is to prefer optimizations that improve the experience on typical consumer PCs without unnecessarily raising the minimum CPU requirements of the operating system.

For example, AnduinOS applies a number of desktop-oriented system tunings:

• We boot the kernel with preempt=full, enabling full kernel preemption on kernels that support dynamic preemption. This favors lower scheduling latency and better interactive desktop responsiveness over maximum throughput.
• vm.swappiness is set to 100, and Zram enabled by default.
• Dirty-page thresholds are reduced so that large background writes are flushed more gradually, reducing the chance of noticeable UI stalls during heavy disk activity.
• The default network stack uses fq together with BBR congestion control, and TCP Fast Open is enabled.

These are the kinds of optimizations I generally prefer for AnduinOS: improvements targeted at responsiveness, latency, and real-world desktop usage, while keeping the system compatible with the normal amd64 baseline.

So in short: AnduinOS can make use of Ubuntu's architecture-variant infrastructure, and advanced users are free to enable amd64v3, but we currently do not plan to make AVX2/x86-64-v3 a requirement for the default installation.

[Anduin2017]

Regarding KDE Plasma: we currently do not plan to maintain an official KDE edition of AnduinOS.

This is primarily a maintenance decision rather than a criticism of KDE. Supporting another desktop environment properly means much more than installing a different set of packages. We would need to maintain and test another complete set of defaults, themes, settings, shell integration, desktop applications, installer behavior, upgrade paths, extensions or widgets, QA infrastructure, documentation, and many other desktop-specific components. For a project of our size, effectively maintaining two complete desktop platforms would create far too much long-term maintenance pressure.

At the same time, we are very satisfied with the direction GNOME has taken. GNOME 50 provides an excellent modern desktop foundation, and the APIs we depend on have become mature and stable enough for long-term development. GNOME also provides a highly polished visual experience out of the box, which gives us a strong foundation without requiring us to redesign every component of the desktop ourselves.

More importantly, a large part of AnduinOS's infrastructure is now being built around the modern GNOME application stack. We have been continuously migrating our own applications toward GTK4 + Libadwaita + Rust.

After extensive testing, we are very happy with this stack. In particular, it has performed extremely well for:

• fractional scaling and HiDPI displays;
• native Wayland support;
• responsive/adaptive layouts;
• consistent desktop design language;
• dark-mode integration;
• localization and internationalization;
• modern input and display environments;
• relatively low runtime overhead and good desktop responsiveness.

Libadwaita also gives our applications a consistent foundation for behavior and appearance across different screen sizes and system configurations, instead of requiring every application to reinvent these mechanisms independently.

AnduinOS itself also contains a considerable amount of GNOME-specific customization. We maintain and modify multiple GNOME Shell extensions and integrate them deeply into the default desktop experience. Over time, this has become part of the platform rather than simply a collection of optional themes.

Moving to KDE therefore would not be a matter of changing the desktop package. It would mean rebuilding a substantial part of our desktop infrastructure from the ground up: application integration, design language, settings, shell customization, testing, and many other components. At this point, doing that while continuing to maintain the GNOME edition would simply not be realistic.

Given GNOME's current feature set, its increasingly modern APIs, our GTK4/Libadwaita/Rust application work, the large amount of GNOME integration already present in AnduinOS, and its good balance between visual quality, responsiveness, and resource usage, I believe GNOME can serve as the desktop foundation of AnduinOS for a very long time.

Of course, this does not mean KDE Plasma is a bad desktop environment. It is an excellent project with a different philosophy and a very powerful feature set. Users are still free to install and customize KDE themselves. We simply do not intend to provide or maintain a separate official KDE edition of AnduinOS.

[Anduin2017]

Regarding NVIDIA drivers: AnduinOS uses the NVIDIA driver packages provided by the official Ubuntu repositories. We do not maintain a separate NVIDIA driver repository.

Our recommended installation method is simply:

sudo ubuntu-drivers install

This lets Ubuntu's ubuntu-drivers tooling detect the GPU and install the driver version that Ubuntu currently recommends for that hardware.

After installation, NVIDIA driver updates are delivered through the normal APT update mechanism, just like other Ubuntu packages. Therefore, the driver update cadence follows Ubuntu's own packaging, testing, and release process rather than a separate AnduinOS schedule.

We intentionally prefer this approach because GPU drivers are tightly coupled with the kernel, DKMS, Secure Boot, and the rest of the graphics stack. Using Ubuntu's officially maintained packages gives us a much more predictable and well-tested upgrade path than maintaining our own NVIDIA repository.

So in short:

• NVIDIA drivers come from the official Ubuntu repositories.
• We recommend installing them with sudo ubuntu-drivers install.
• Updates arrive through normal system updates whenever Ubuntu publishes a newer supported driver for the corresponding Ubuntu release.
• AnduinOS does not maintain a separate NVIDIA driver repository.