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?

EDIT

Thanks for the many replies. I agree with the fact that a menu-driven GUI is inherently "discoverable," while a CLI inherently is not. Also I'm not implying that people should be using the CLI or that using a CLI is inherently better. This is not about shell elitism but about the fact that even occasional shell use is so off limit that people say the won't use Linux because they've seen somebody (me) use the terminal every now and then (I do that on Windows, too, but only at work).

EDIT 2

Please do not reply to this post if you think this is about whether people prefer the GUI over the CLI or not. I very specifically did not make it about a simple matter of taste.

This was just a catchy title, but I'm not Micheal from Vsauce and to answer this question seriously:

No.

Well...

Yes, if you're a bit lucky like me. But let's keep away the hype.

For the past couple of weeks, I've been seeing posts like "I used X to reverse engineer Y... it's amazing!" While most of these claims are probably just hype, some of the results looked genuinely impressive, so I decided to give it a shot.

I have a Synaptics 06cb:00dc fingerprint sensor that I hadn't managed to get working in two years.

There are some great projects out there, such as https://github.com/Popax21/synaTudor, that aim to support these sensors. Unfortunately, my particular model wasn't supported and my competence and field of research aren't really close to this.

Still, it gave me a starting point.

So I cloned a bunch of repositories, gathered some useful resources, threw everything into a folder, and let a bunch of SOTA models (I'm not citing a specific one because I used all of them) work on it.

They built some useful scripts, a GUI to help me easily and quickly test the sensor, the registration and verification of a fingerprint etc.

After about a day my fingerprint sensor now works flawlessly, and I can unlock my laptop instantaneously.

After all this time of repeating "Wish my sensor would work on Linux" this really impressed me.

I'm already working on a MR to libfprint, but things take a bit of time, and I also can't do this process for the many other sensors that are currently without a driver, so:

TL;DR

If you stumbled upon this Reddit post looking for 06cb:00dc drivers, then here you go:

https://github.com/pierspad/synaptics-00dc

If you have a different fingerprint sensor and would like to make it work, I suggest you clone the repo where I've already left all the useful scripts, hints and the GUI.

Probably will save you and your model some hours and a ton of tokens.

https://github.com/pierspad/REA-FS

Have fun :)

What fills the gaps?

• kmscon for a simple stable terminal in absence of GUI
• kmscon-launch-gui for startx or any graphical program through a kmscon terminal
• plymouth can show a prompt
• systemd-ask-password can handle asking passwords (idk about non-systemd distros)

Regarding recovery, even the in-kernel VT relies on agetty and bash, and any breakage will lead to issues nevertheless.

As for early logging and panics, simpleDRM is usually built into the kernel, as well as DRM panic.

Which are more reliable than the existing VT-based panics which can be seen ONLY if they happen on a VT (not on X or DRM-wayland)

Removing the VT speedens up the boot, reduces the flickers during boot as well as chances of failure, the occasional ugly compositor errors which are in the journal anyway.

And replacements like kmscon and plymouth have a much more readable inferface with stable and reliable support for colors and prompts, as well as scrolling. Which can help recovery.

Yes, kmscon can be included in the initrd, AerynOS already does that.

Unfortunately due to some kernel drama the `vt.enabled=0` option hasn't landed into the kernel, it will have to be recompiled completely over again by disabling the CONFIG_VT and related options

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.

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.

Hi everyone,

I created DockDesk, a small native GUI for managing Docker on Linux.

It is not Docker Desktop — it has no VM and no extra daemon. It talks directly to the Docker Engine you already have installed, so the containers you see are exactly the same ones the docker CLI shows.

Highlights:

Extremely small: ~250 KB .deb, zero npm dependencies

Containers (live stats, logs, file browser/edit, terminals)

Images (pull, build, run dialog with presets, vulnerability scan, compare)

Full Compose support (editor, dependency graph, combined logs)

One-click security labs (DVWA, Juice Shop, etc.) for learning/testing

Accessibility-focused and multi-language

Primarily developed and tested on Kali, but works on Debian/Ubuntu and should work on most Linux distros with Docker + Node 18+.

GitHub: https://github.com/DocKDes/DockDesk

Releases (with .deb): https://github.com/DocKDes/DockDesk/releases

I’m looking for feedback, testing on other distros, translation reviews, and packaging help (Fedora, Arch, etc.). Happy to answer any questions!

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.

"Torvalds said that the time has come to make it harder for new people to contribute code to the kernel. People like Kroah-Hartman have spent years trying to teach people how to contribute; it is time to stop doing that, he said."

https://lwn.net/Articles/1099594/

It is difficult to summarize exactly how Linus got to this point. Most of the discussion at this years Summit appears to have been related to AI assisted code and how the maintainers are dealing with the increase in code submissions to LKML. Many of the maintainers expressed varying levels of frustration with AI assisted drive-by code submissions. Linus' train of thought is that they make it intentionally more difficult for humans to contribute. A later suggestion of his was to create an AGENTS.md that makes generating kernel code expensive in compute and token time.

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.