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?

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

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.

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.

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

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.