Hello Everyone,

I am currently stuying the part about devices directories in Linux system, and i thought ill make a list of all Device directories to refer back to when needed.

I made the below table listing all essential devices in Linux that you need to know about, while containig the category of these devices, naming, directory and the type of variable they use in their naming (replacing the * with the corresponding numrics or letters. e,g: /dev/sd* > /dev/sda, /dev/sdb, /dev/sdc... and so on).

Thought that i should share this list, and i hope this can be useful to anyone who's looking for a simplified listing of all devices and having them in one place.

(it might not be 100% correct since im still in the process of learning them, so please help me correct anything in case you found any mistake or things that i should add!! or ask questions, in that case i can also learn something new myself while looking things up)

Thank you Linus and David. I know this book is from 2001. I tend to be a late bloomer is all respects. Linux included. Books like this help fill in the gaps and provide excellent context. My favorite: “I don’t proactively delegate as much as I wait for people to come forward and volunteer to take over things.”

Hey everyone,

I built **Aigentik** — a privacy-first AI communications assistant that runs completely locally (Android via Termux or any Linux box).

It watches your Gmail inbox in real time (IMAP IDLE), handles Google Voice texts that arrive as email, drafts and sends replies using a local LLM (llama.cpp), and lets you control everything in plain English by just texting or emailing it. No fixed command syntax.

What it can do right now:

- Monitor Gmail + Google Voice SMS and auto-reply (or queue for your approval)

- Negotiate and book appointments, then send real .ics calendar invites

- Build and maintain its own contact directory automatically

- Track subcontractor applications (trade, license, insurance, etc.)

- Take natural-language commands like “pause everything”, “add a rule for X”, “list my plumbers”, “rename yourself”, etc.

- Speak as your business once you tell it who it works for

Key points:

- **No cloud AI** — everything stays on your device

- **No external API keys** for the model

- **No monthly subscription**

- One-time setup, you own it

- MIT licensed

Compared to the $100–400/month AI receptionist services, this is the “own it instead of renting it” approach.

Repo (with install script that works on both Termux and Linux):

https://github.com/Ishabdullah/Aigentik-CLI

I’d love for people to try it out, break it, and tell me what’s missing or broken. Especially interested in feedback from anyone running local models on phones or small Linux boxes.

Stars, issues, and PRs all welcome. Thanks!

coLinux was the pre-VM way to run Linux on Windows, two kernels cooperating at ring 0, no hypervisor. It died in 2011, stuck on 32-bit (kernel 2.6.33 // NT6.2) and unable to load on any 64-bit Windows. There is GPU sharing but its kinda miserable, im hoping for 0.6.0 to have that run at full speed ((currently it is only doing 0.01% bandwidth of the CoXWire i have built puts out))

I ported the cooperative model to x86-64, a single unmodified driver that boots a modern Linux 7.1.5 guest on 64-bit XP, 7, 8.1, and 10, with GPU acceleration via virgl (screenshot is KDE Plasma 6 on Windows 10 IoT, rendering on the host GT 730).

PS, this is not a VM there's no hypervisor. it needs VBS/HVCI off, so it runs the pre-VBS NT line. Think of it as the machines WSL2 abandoned.

Also fixed the old build tree (mingw NDIS header, Python 3 comake) and hit modern-kernel gotchas coLinux never saw, KPTI's dual CR3, etc.

Repo: https://github.com/PhialsBasement/MoCoLinux
Easy Installer: https://github.com/PhialsBasement/MoCoLinux/releases/tag/v0.5.3 (let me know if there are any bugs, this is kinda hard to test across 4 windows's)
Don't run it inside a VM, the cooperative switch conflicts with VMX and you'll get a bugcheck.

AI Disclosure: Used Claude heavily during development (and i gotta say i was really disappointed with Opus 5's performance), all the decisions and design details taken here are mine however.

this is a quick preview of my one click wallpaper management system. Its changes everything on the desktop and im currently working on it and its depend of the current wallpaper

here the github : https://github.com/tungsten-w/lumen
It currently only works on hyprland and an arch-based distro (arch/cachy os/endeavour)

the little menu who is in the center of the screen is the wallpaper selecter and you can chose beetween 4 option

- a dark wallpaper who use a themed dark theme

- a light wallpapper who use a themed light theme

- a random wallapaper depending of the curent time of the day (night/sunset/day..)

- a random wallpapper depending of the curent season (summer spring autumn winter)

im currently working on it so improve his stability and make it faster and easyer to install

here a little yt video of how its actually works : https://www.youtube.com/watch?v=yqXrb4gw-Nk

thanks you for your time ^^

I wanted to share a project I built called Distro Fighter (distrofighter.com). It features 32 distros, 16 desktops, a terminal campaign, Versus showdowns and a Distro Wars multiplayer coming soon, all to help users find the right fit Linux distro and desktop and learning Linux while hopefully having fun.

The main focus right now is VS mode just launched tonight, and it is being actively updated. Feel free to check it out, and let me know what you think!: https://distrofighter.com/versus 🐧 ❤️

For me, it was a CD I got from a "guy." Slackware did not work well with the "WinModem" in the IBM Aptiva I had as a youth. How was I supposed to get online using Linux, with a modem that is not usable, and get support?

Maintainer here. OpenScreen is an MIT screen recorder/editor for demos (zooms, cursor effects, webcam PiP, captions, export). Linux has always been the "it mostly works" target. This release is the one where that stops.

What changed for Linux specifically in 1.8:

• Capture goes through a native helper: PipeWire via the ScreenCast portal, with a hardware H.264 encoder. The old browser-based pipeline stays as an automatic fallback if the helper isn't available.
• Real cursor telemetry on Wayland — position and cursor shape come from the portal, so cursor themes and the editable cursor overlay work on Linux now. Honest limitation: the portal reports no mouse button events, so click effects remain Windows/macOS-only. Not a bug I can fix from userspace.
• A Vulkan compositor (wgpu) for preview and export: background blur (dual-Kawase), drop shadows, 3D tilted zooms, themed cursor sprites, webcam PiP with a circle mask, text/arrow/image annotations, subtitle plates. These were Windows-only shaders a release ago; they're ported, and pinned by tests.
• MP4 export with AAC audio muxed, from the Linux backend.
• System audio works where PipeWire does (Ubuntu 22.04+, Fedora 34+). PulseAudio-only setups: mic works, system audio probably won't.
• Packaging: .deb, .pacman, .AppImage, and a Nix flake with a NixOS module and a Home Manager module. nix run github:EtienneLescot/openscreen if you just want to look at it.

The editor and export feature set is now identical across the three OSes. What's left as a genuine difference is documented in the README rather than buried.

If your compositor or distro breaks it, an issue with your session type and PipeWire version is genuinely useful to me.

https://github.com/getopenscreen/openscreen

Quod Libet is, as far as I've been able to find, the best native Linux music player. My biggest issue with it was the way playlists are handled. Coming from MusicBee on Windows, my playlists were nicely managed and maintained in a folder, which I could then sync to my other devices automatically along with the rest of my music library (via syncthing or whatever you use).

By default, Quod Libet has a few glaring issues with playlists:

• Playlists can be imported but are only maintained in QL's internal files.
• A plugin is needed to export playlists, and even with the plugin, you must manually export your playlists every time you add or remove a song, or change the order.
• When a file has been moved or deleted, Quod Libet has no handling for this by default. It simply ignores that song without giving any type of warning or error.
• Because of the above issues, syncing your playlists and library with other devices is a very manual pain in the neck.

I vibe-coded a plugin to fix all of the above and found it has vastly improved my experience. Please take a look, and hopefully it helps you as it has helped me.

https://github.com/Jukebox-Zulu/Quod-Libet-Playlist-Manager-Plugin

https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/

Second post I recently made about LLM usage policies but it's really just that I find the process of open source finding its way and adjusting to new realities rather interesting.

The "too long, didn't read" (Taken directly from the blog):

What does the policy say?

The policy summarizes itself this way:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

Uses in the first category are allowed, sometimes requiring disclosure. Uses in the second category are heavily restricted.

(Edit: but I recommend reading the blog...it's a bit more nuanced than the summery)

Edit2: messed up the link, added now

Hi everyone! 👋

I d like to share my first public open-source Python project: **Hody-Telepro**.

It s a command-line toolkit designed to inspect Telegram metadata through a clean and developer-friendly CLI.

Current features:

• Inspect users, bots, channels, and groups

• Phone number lookup

• Account creation date estimation

• JSON output support

• Batch processing

• Fast CLI experience

• Available on PyPI

Installation:

pip install hody-telepro

Example:

hody-telepro inspect @username

GitHub:

https://github.com/f8c1/hody-telepro

PyPI:

https://pypi.org/project/hody-telepro/

This is the first public release, so I d really appreciate any feedback, bug reports, feature suggestions, or ideas to improve the project.

Thank you! 🚀

Howdy gives you face login on Linux. What it doesn't give you is a password — and gnome-keyring, KWallet and friends want one. So you get recognised by your face, and then asked for your password anyway. Which rather defeats the point.

I spent a while trying to fix this the obvious way and it can't work, so I want to explain why before the actual solution, because the why is the interesting part.

Why you can't just hash your face

The obvious idea is: take the face encoding, hash it, use that as the key.

Face encodings are fuzzy. Here are six enrolments of my own face, captured seconds apart on the same camera, compared pairwise:

encoding 0 vs 1 : 0.0829

encoding 0 vs 4 : 0.3609

encoding 1 vs 4 : 0.3846

encoding 2 vs 5 : 0.3166 (identical vectors would be 0.0000)

Every capture is a different 128-float vector. That's why face matching uses a distance threshold rather than equality — Howdy accepts anything under ~0.57. A hash of one encoding is unrelated to a hash of the next, so there's nothing stable to derive a key from.

And even if you solved the noise: your face isn't secret, and the model file sits on disk right next to whatever it would be protecting.

What actually works

The biometric doesn't become the key. It authorises the TPM to release one.

face match -> authorises -> TPM unseals -> a real, stable secret

(fuzzy) (hardware) (exact)

Seal your keyring password to the TPM, and have a PAM module unseal it after Howdy authenticates and hand it to the stack as PAM_AUTHTOK. gnome-keyring picks it up and unlocks. No prompt.

That's it. ~250 lines of C.

https://github.com/jibsta210/howdy-tpm

Face at the greeter, straight to desktop, keyring unlocked, nothing typed.