When people see me using my computer, web browser, office suite, photo editing, it's all fine. But if they catch a glimpse of my white-on-black terminal, they completely zone out. The shell is not something I know about and they don't but very well could, it's a hard no. It's a dark zone they feel they can't enter. Using a terminal is not within the realm of interacting with a machine but black magic. It's not that they simply "prefer" to use the mouse for everything. They feel an almost religious revulsion it seems.

Especially in times of AI chatbots where everybody and their dog start using the keyboard again to do a text-based back-and-forth with a machine, shouldn't the shell come more natural to people Or is it time for "sish"? Super intelligence shell that internally translates human language into shell commands? Interaction would go like this:

What do you want to do? Please list all files in the current directory.
Sure thing, here goes:
..
.
file1
file2
etc

Anything else? Would you also like to see creation time and file sizes?

I recently built a new rig around an AMD Ryzen 5 9600X paired with 32GB of DDR5 RAM. My primary goal was to find the optimal Linux distribution for this setup—specifically one that could leverage the CPU’s hardware instructions (AVX-512 / AVX-VNNI) to run local LLMs via Ollama at maximum speed, without needing a dedicated GPU.

Going into this, my/AI thought process was leaning heavily toward openSUSE Tumbleweed. The reasoning seemed rock-solid on paper:

• Bleeding-edge Stack: A brand-new CPU architecture (Zen 5) needs the latest Kernel (7.2+) and modern Mesa drivers to run at full potential.
• x86-64-v3 / v4 Optimizations: Tumbleweed’s fresh toolchains and rolling packages should theoretically compile and run AVX-heavy workloads like llama.cpp significantly faster.
• Leap Scepticism: The traditional perception was that openSUSE Leap’s frozen base and older Kernel would bottleneck CPU-bound AI tasks or fail to initialize modern ISA extensions efficiently.

Note: The heavy write churn on SSDs from daily zypper dup and Snapper snapshots on Tumbleweed was a side concern, but my main focus was pure performance.

To test this, I ran Ollama on both Tumbleweed (with a manually compiled Ollama build) and Leap 16.1 (using the stock install script) running the gemma4:e4b-it-qat model.

Here are the real-world execution numbers:

Tumbleweed (Custom Build):

Prompt Eval Rate: ~102.12 tokens/s

Eval Rate (Generation): 17.85 tokens/s

Leap 16.1 (Stock Script):

Prompt Eval Rate: ~154.45 tokens/s

Eval Rate (Generation): 18.21 tokens/s

Why Were the Assumptions Wrong?

Even with a Kernel 6.2+ baseline on Leap, the OS properly exposes avx512f, avx512_vnni, and avx_vnni flags to user space (lscpu verified this). That’s all llama.cpp needs to execute matrix multiplications at full speed.

CPU-based LLM inference is overwhelmingly memory-bound by DDR5 transfer rates, not by driver overhead or kernel tweaks. Once AVX-512 is enabled, the CPU hits a hardware ceiling.

Since Ollama was running strictly on CPU threads, Mesa driver versions had zero impact on the final generation rate.

Conclusion: The assumption that a rolling release is inherently faster for CPU AI workloads didn't hold up. Leap 16.1 delivered identical (and slightly tighter prompt evaluation) performance out of the box at ~18 t/s, while offering a rock-solid, low-maintenance environment with vastly reduced disk write cycles.

Hey y'all so before we start i should warn AI was used in the creation of this but don't worry it not vibe coded slop and I've made it open source under MIT so you all can inspect it all you want. But i came to y'all today to tell you I've been working on interpreter for basic it called basically it is still very early in development as in i just finished the FOR/NEXT support. I went into this to learn to basic cause I mean what's the best way to learn basic its write an interpreter but looking around i saw there aren't a lot of interpreters on linux so I open sourced it. I hope to end this project with the goal of it being able to interpret itself excuse my lack of knowledge here but i believe this is called bootstrapping correct me if I'm wrong. Thanks for looking at my post and hopefully not clicking off at the mention of AI and here is a link to the github.

maidware project is meant for people who are moving from windows to linux, it's a suite of tools meant for people who are newer and want an easier way to move over.

i'm currently the only developer in my project, and i need help with translators, coding etc. i have gotten to my limit but i would need a bit of help.

thank you, and here is my project website -

https://maidware-project.github.io/maidware.github.io

SonicDE is a fork of KDE that aims to preserve and improve the X11 and init system agnostic aspects of KDE since they announced they are going Wayland-only in KDE Plasma 6.8 and have been actively moving towards a systemd only future. SonicDE currently consists of over 120 repositories including the customized sonic-win (KWin/X11) window manager and compositor, Plasma Workspace components, the Silver theme, the Sonic Login Manager, and other components and support libraries.

Official Links:
https://sonicde.org/

https://github.com/Sonic-DE/sonic-win

https://www.reddit.com/r/sonicde/

https://sonicde.org/installing

Amazon shipped this with a 32-bit 4.4 kernel on a 64-bit MT8183. It now boots mainline 6.18 arm64. Screen, touch, Wi-Fi, USB and audio all work, with a real display driver still to go.

Most of MT8183 is already in mainline thanks to the Chromebooks that use it, which helped a lot. What wasn't there was the board itself: device tree, an audio machine driver, and a fix to the AFE driver that I'll try to send upstream once it's cleaned up.

Getting there took opening one up and finding the serial pads, since the stock kernel turns serial off. Notes and code will be in TECHO5 (https://github.com/HuskerMinion/techo5) when it's released.

Libreboot is free/opensource boot firmware replacing proprietary BIOS/UEFI. Better security/customisation than most proprietary firmware.

Highlights in this release include:

* MrChromebox EDK2 payload by default on most boards, with SeaBIOS CSM (CSMWrap) and GRUB EFI provided in-flash for backward compatibility.
* 233 new Chromebooks added; every board supported by MrChromebox coreboot. With our GRUB EFI/SeaBIOS CSM build added
* 15h.org coreboot fork used on KCMA-D8, KGPE-D16 boards for improved raminit.
* GRUB EFI build uses terminal_input console and no nativedisk; it piggybacks off of EDK2 drivers, like distros. It even works on Chromebooks (eMMC boot).
* Intel HAP bit set by default on Chromebooks, and IFD regions unlocked where appropriate
* Dell OptiPlex 5050 SFF, Supermicro X11SSH-F, ThinkPad X280, X270.

Modern Linux distros boot, with e.g. UKI/systemd-boot. Windows also compatible now.

Due to some updates to EAC, I saw that Fortnite is coming to Linux, which is awesome! I actually was just reading a research article about this. I don’t know exactly how it works, but it appears you can kind of “sign” a kernel through your TPM chip so that games can approve a list of Linux vendors (Ubuntu, Fedora, etc.) and you can use anti cheat on major distros.

https://arxiv.org/abs/2609.20909

Any worries about the fact that some distros might work with EAC but some won’t? Personally I don’t mind, I think it’s time to lock down to a set of basic ecosystems, but this might be the death of making thousands of versions of various distros if we have to verify only a select few for stuff like this.

The recordings of the October 10 2026 online meeting are published on YouTube. Since it isn’t allowed to post YouTube links directly into r/linux you have to look at https://mediawiki.gnustep.org/index.php/Monthly_Meetings#Past_Meetings for the link. It is definitely worth it, lots of interesting and new stuff inside.

I use Bazzite, and was looking through the flairs on this subreddit, and couldn't find one for bazzite. Now, i dont mean the post flairs, i mean the user flairs. The closest one i could find is fedora.

Finally they support Linux in Appimage format with specs: Ubuntu 22.04 LTS or newer, Fedora 43 or newer, or Debian 12 or newer and An internet connection is required for setup and online features. Offline mode supports eligible installed games.