It was fixed just today by the dev/maintainer! Linux is awesome.

The repo is Pocknix! Os for ARM devices

https://github.com/shuuri-labs/pocknix-os/issues/134

I also just made the environment shell desktop thingy for my RP5 already via hyprland. Very prototypy

Hey guys, this may be the last proper release of sxwm. I think all the needed features are there and it works great.

I spent a long time cleaning up the codebase and stuff so this is more of a fixes release.

https://github.com/uint23/sxwm

terminal: https://github.com/uint23/cterm

bar: https://github.com/uint23/sxbar

wallpapers: https://github.com/uint23/uint23 (latest commit)

font: Tamzen 8x16b

A curated collection of technical resources for GNU/Linux users and system administrators: Manuals, books, video courses, and tutorials covering command-line fundamentals, server infrastructure, Bash shell scripting, GNU tools...

Originally I wrote this for myself to multibox World of Warcraft, that I have since generalized for other purposes. I wanted to run a second client in its own X server and drive it with my real keyboard and mouse, and I couldn't find anything that did that cleanly.

It grabs your keyboard and mouse, and a hotkey (Ctrl+Shift+Space) switches them between your desktop and a target. The target can be another X server, like a second game client or a nested Xephyr window. Or it can be a set of virtual input devices that you assign to another seat, pass into a container, or hand to anything else that reads evdev.

It's a single small binary with no daemon and no config file. It finds your keyboard and mouse automatically, and you can point it at specific devices instead. Anything you're holding when you toggle gets released on both sides, so you don't end up with stuck keys. It doesn't need root, just the input group, and it builds with a plain ./configure && make. X support is optional.

If you need network forwarding or scriptable hotkeys, netevent and evsieve are more full-featured and worth a look. This one aims to be the option you can just run with no setup.

The repo and README cover setup, permissions, and how to try it in a Xephyr window: https://github.com/blakewon/evdev-forward

Feedback is welcome, drop a star if you find it useful.

I posted spotatui here about 10 months ago, when it was a revived spotify-tui. A lot has changed since then, so here's an update.

What's new

- Desktop app (preview).
Same player, own window, a Spotify-like layout: home, album and artist pages, your library, lyrics, a queue panel and a device picker. Packages for Linux are .deb, .rpm and AppImage (x86_64 and arm64). It needs WebKitGTK 4.1 and glibc 2.39, so Ubuntu 24.04+, Debian 13, Fedora 40+ or Arch.

- No Spotify developer app or client ID anymore.
Spotify cut the Web API down hard for developer apps this year, so spotatui now talks to the same internal endpoints the official client uses, over librespot. You log in by confirming a code in your browser. Spotify still needs Premium. This means that that there are no more rate limits or deprecated endpoints. (rate limits could technically be possible but that would also affect the official spotify client so i doubt they will ever do that)

- Native playback.
spotatui is its own Spotify Connect device, so no official client or spotifyd is needed.

The terminal app also plays local files, Navidrome/Subsonic, internet radio, YouTube and Qobuz from one queue. The desktop preview is Spotify only for now with other sources coming later.

Both share one Rust core, settings and listening history.

- GitHub: https://github.com/LargeModGames/spotatui

- Downloads: https://github.com/LargeModGames/spotatui/releases/latest

- AUR: spotatui-bin. Also Nix, or the install script on spotatui.com.

The installers aren't signed yet. Feedback and bug reports are very welcome.

"Sony really made an official Linux kit for the PlayStation 2, and somehow we got our hands on one 24 years later. The only problem is we’re missing some pretty important hardware, the discs are in Japanese, and getting this thing running is anything but straightforward. So naturally, we’re going to try anyway and see what Linux on a PS2 was actually like in 2002."

Interesting stuff. I work with a large Usenet archive (1980–2013). The comp.os.minix thread “What would you like to see most in minix?” has 86 posts in it. 8 are from August 1991. The other 78 run from 26 Aug 2011, the day after the post’s 20th anniversary, to May 2013. Nothing is dated in between.

1991: The first question back was whether it needed an MMU. Linus: “Yes, it needs a MMU (sorry everybody)… Simply, I’d say that porting is impossible.” On the 64 MB task segments: “Anybody who needs more than 64Mb/task – tough cookies.” Two days later, on the task limit: “Fragmentation is evil,” and “I don’t want to be on the machine when someone is spawning >64 processes, though :-)”

2011–2013: Mostly thank-you notes, and the quote headers show at least seven languages. A few favorites, anonymous:

• “Good work from the future XD”
• “I’ll be back in 10 years to read this and see how far I’ve come.”
• “What is this Linux thing? Is it still updated? Does it support the Minix file system?”
• “What?? No floppy support? I’m out!”
• “Sounds like it might have a future. Keep at it!”
• “And without minix Mr. Torvalds would probably have done some nice windows programs. Thank /you/ Mr. Tannenbaum!”

Someone also pasted the whole “I’d just like to interject for a moment… GNU/Linux” speech, which is why the thread has a few confused replies.

Caveats: dates come from message headers, and threads are rebuilt from Message-ID/References, so the nesting in this one is unreliable. I’ve listed posts by date.

Disclosure: I license this archive commercially (about 405M posts, 18k newsgroups, with a free sample on Hugging Face). I’m posting this because the thread is fun, not as a pitch. If you’d like another group or era dug up like this, tell me.

https://github.com/bherbruck/solidcraft

This has very modern interface and looks similar to Fusion. So far it is working beautifully except for few things which are work in progress.

Nvidia’s RTX Spark (N1X) is essentially the GB10 from the DGX Spark: 20 Arm cores, a Blackwell GPU, up to 128 GB of unified memory. The closest thing to Apple Silicon outside a Mac.

Every launch device ships with Windows 11 on Arm. Microsoft has been trying to make Windows on Arm happen since Windows RT in 2012, then Windows 10 on Arm, then Copilot+ with Snapdragon X. It has never really caught on, and it still depends on x86 emulation and on third parties porting their software.

Meanwhile, the same silicon already runs Linux in the DGX Spark, where Arm is a first-class citizen and most of the AI stack is native anyway.

What we know so far:

• No official Linux support has been announced for RTX Spark laptops
• The public Linux driver supports GB10 but doesn’t list N1X device IDs yet
• There are already “[N1x Linux]” issues on Nvidia’s own GitHub, so someone is clearly running it internally

Questions:

• Will Nvidia ship official Linux support, or leave it to WSL?
• Will OEMs offer Linux SKUs (Dell, Lenovo, System76?), or will we be fighting the bootloader and device tree?
• If Windows on Arm stalls again, could Linux end up being the better OS for this hardware?

Anyone already running Linux on a DGX Spark? How’s the experience?

>We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.

I made a Windows-style Super+V clipboard history for Linux.

Written in Go with Fyne. Free and open source (MIT).

https://github.com/naftulisinger/super_v_clipboard

The DesktopEditors github repo seems to have actual releases now, with multiple download options for various linux distros, plus Windows and MacOS. From brief usage with my existing documents, it's still got a bit of work that needs to get done, but honestly I'm happy to have it finally be released in some usable capacity that doesn't require manually building!

It has begun! Some tinkerer already got it running on a laptop's bare metal just days after the official release. Supports x86_64 hardware.

Hello,

I’m one of the developers of Keysharp, an open-source implementation of AutoHotkey v2 for Linux, Windows and macOS. It’s written in C# and runs on .NET 10.

It supports hotkeys, text expansion, keyboard and mouse automation, window management, clipboard operations, GUIs, screenshots and image matching.

For example, this expands brb into “be right back” and makes Ctrl+Alt+D type today’s date:

#Requires capability InputMonitoring, InputControl

::brb::be right back
^!d::SendText(FormatTime(, "yyyy-MM-dd"))

Most AutoHotkey v2 scripts which don't use Windows API directly (for example AutoCorrect.ahk) should work without modifications in Linux too.

Linux support covers X11 and several Wayland environments. This has not been easy at all, as Keysharp basically needs to break all the security Wayland brings. Also, Wayland is rather fragmented and the interfaces needed for desktop automation differ between compositors, so window control and capture require separate integrations. Some operations remain unavailable depending on the exact compositor. The supported operations are documented here.

Global input uses keysharp-input, a privileged evdev/uinput service which requires root to install, but user priviledges to use. Window automation and capture use keysharp-desktop. The Linux installer sets up both in addition to Keysharp itself.

Keysharp is still alpha software, and I can't yet recommend it for production use, but I'm hoping to get more eyes on it and discover bugs/issues.

Documentation · Linux installation · Example scripts

Bug reports, compatibility reports and contributions are welcome.

Disclosure: AI has been heavily used for this project, especially keysharp-input and keysharp-desktop.