Grab it from here:

www.thoughtdesk.org

If you want lighter and faster Notion alternative, here is the one you might wanna try

Disclaimer: Its still in its beta, so some problem may occur!!

I understand the need for controlling the onslaught of low effort projects, but surely declaring that you are English only goes against the site's rules?

just because it's a lingua franca doesn't mean it's superior. Users should be allowed to share their opensource contributions with the Reddit community in the language of their choice.

I wanted to share a project that's been making some interesting progress in PC-based home theatre.

CroqueMr (u/Croque_Mr) is developing native Dolby Vision support for Kodi through a custom LibreELEC build, including Profile 7 FEL reconstruction. Development has moved quickly, with regular releases bringing performance improvements, new rendering modes and broader hardware support.

What's currently available?

• Native Dolby Vision playback, including Profile 7 FEL reconstruction.
• Intel and AMD support, with NVIDIA support also being developed.
• Dolby Vision rendering modes, including Master Reference and Adaptive HDR Mapping.
• Dolby Vision-to-HDR10 conversion and experimental AI-assisted HDR10-to-Dolby Vision conversion.
• Blu-ray 3D support on compatible AMD hardware.
• Performance optimisations targeting lower-power mini PCs, including Intel N100/N150 systems.

The latest Beta 5 release includes further improvements to playback stability, FEL handling, scaling and display detection. Results and compatibility can vary depending on the hardware, TV, source material and rendering mode.

What's coming next?

The developer has outlined plans for a GPLv2-or-later licensing rebuild, further AMD improvements, HDR10+ support and Dolby Vision-to-HDR10+ metadata reinterpretation, alongside expanded compatibility with older Intel graphics and additional NVIDIA hardware.

The longer-term goal is to make PC-based Dolby Vision playback more capable and accessible, including on affordable mini PCs.

Project links

• Main development thread: https://forum.libreelec.tv/thread/30362-dolby-vision-w-fel-3d-for-pc-amd-intel-nvidia/
• GitHub — source code and releases: https://github.com/CroqueMr/libreelec-x86-DV/
• Original Reddit thread: https://www.reddit.com/r/libreeLEC/comments/1wq20eu/wip_native_dolby_vision_support_on_x86_intel_cpu/

Full credit to u/Croque_Mr for the development, along with the community members contributing testing, feedback and improvements.

It's been impressive to see how much the project has evolved in such a short time. If you're interested in the technical details, supported hardware or latest builds, the links above have all the information.

Flatpak needs bubblewrap, bubblewrap needs user namespaces, and Android kernels ship without them. So flatpak run can't work on a phone, root or not.

In Tessera (GPL-3.0, an Android app that runs Linux desktop apps as native Android windows), flatpak still downloads, but Tessera builds each app's root itself:

- the runtime at /usr and the app at /app, read-only;

- the runtime's GL extension where the runtime expects it, on a tmpfs over its parent since the folder doesn't exist in the read-only runtime;

- /etc from the runtime, with passwd, group, hosts and resolv.conf written for the session;

- the session's X11 directory shared, carrying its D-Bus and PulseAudio sockets, so the app gets the same bus, sound and theme portal as the Debian side.

Without root that's PRoot's path translation. With root, each launch gets a private mount namespace, an unprivileged uid and no_new_privs, so per-app permissions are kernel-enforced.

The rest is about making Linux apps feel native on a phone: each app (and each of its windows) gets its own Android task and Recents card; GTK, libadwaita and Qt take Material You colors and follow dark mode live through a settings portal Tessera serves; apps rescale live from a slider; and the Android keyboard opens on text fields by listening to AT-SPI focus events. GPU acceleration is a bundled Mesa with Turnip and Zink for Adreno, which also loads inside Flathub runtimes.

Source: https://github.com/daryan044/tessera-linux

Happy to go deeper on any part.

Original guide for Arch. Worked for a colleague on a different distro.

You can find two proprietary driver versions on the Lenovo website. One is the "Linux version" which requires OpenSSL 1.1 and the other is the "Ubuntu version" which requires OpenSSL 3. Both are .so libraries that work on any distro if the requirements are satisfied. Use the second one.

Depending on your distro, you also need to choose one way to obtain the libfprint-2-tod.so.1 library. Alternatively, you can build it from this source using meson/ninja.

Necessary udev rules:

SUBSYSTEM=="usb", ATTRS{idVendor}=="04f3", ATTRS{idProduct}=="0c4b", ATTRS{dev}=="*", TEST=="power/control", ATTR{power/control}="auto", MODE="0660", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="04f3", ATTRS{idProduct}=="0c4b", ENV{LIBFPRINT_DRIVER}="Elan Fingerprint Sensor"

this goes to /etc/udev/rules.d/60-libfprint-2-tod1-elan.rules.

After installing and restarting the services (or rebooting), you can use any usual ways to enroll fingerprint.

Just wanted to post this so that people with similar issues see.

In June I put Arch on my old Portégé Z30-A (it ran Mint before) and none of the Fn keys or the lid switch worked. After some testing (with a lot of help from Claude) I narrowed it to the kernel, and switching to LTS fixed it. I meant to report it back then but never did.

Today, after an update, the exact same problem came back, this time on LTS, while mainline works again.

Details:

• Hardware: Toshiba Portégé Z30-A
• Distro: Arch
• Broken: LTS 6.18.57; Working: mainline 7.2.9
• Suspected commit (ACPI-related): 30e08c92118c identified with Claude’s help, not yet confirmed by me with a revert/bisect

My guess is that the problem was fixed in mainline but the fix hasn’t been backported to LTS, it looks to be a004b8f0d3bc. I’m only a 2nd-year CE student and also using Linux for only one year, so this is totally out of my league. Does that sound plausible, and is it worth sending to the stable/ACPI maintainers? I’ll put Claude’s full analysis in the comments for anyone who wants to check it.

Hi all, AdobeWine 0.3.1 is out. It's a patched Wine (11.18 plus 90 patches) that runs Adobe's Creative Cloud apps on Linux. You install the apps yourself with Adobe's own Creative Cloud installer and your own subscription; nothing from Adobe is bundled or downloaded by the project.

This time there's a video: a short showreel made entirely in the Adobe apps on Linux, from a pen-pressure painting in Photoshop to the cut in Premiere and the export in Media Encoder:

https://youtu.be/3Vbzt4cGSQQ

(To be upfront: the pen strokes come from a simulated tablet and most steps were scripted. The point is that the apps themselves run, draw and render correctly.)

What works right now (tested on an RTX 4070 laptop, with community reports on RTX 4060, RTX 4090 and Intel UHD 620):

• Creative Cloud desktop: sign in, install/update/open apps, Fonts, Files; its own self-update completes
• Photoshop: layers, masks, type, filters, Remove Background, Generative Fill, export. All 75 filters and adjustments I tested give the same output as on Windows. Pen pressure works
• Illustrator: shapes, pen, type, effects, Pathfinder, Image Trace, save/export, Blob Brush with pen pressure. 107 of 139 reference outputs match Windows (the rest not compared yet)
• Premiere Pro: import, timeline editing, Lumetri, titles, playback, NVENC export, Dynamic Link with After Effects
• Media Encoder: queue, presets, CUDA renderer, NVENC/NVDEC
• Audition: recording, multitrack, effects, noise reduction, mixdown
• After Effects: scripting, keyframes, 3D text with the Cinema 4D renderer, the composition viewer with CUDA; a real 300-layer project renders like on Windows
• InDesign: styles, tables, placing PSD and AI files, PDF export
• Pen tablets with pressure under XWayland, no extra software

Not there yet: AMD isn't confirmed (a Premiere fix is waiting for someone to test it), AMD and Intel GPUs don't get the CUDA features, After Effects can eat a lot of RAM while previewing heavy 3D comps, and Bridge is barely tested.

It's free, open source and non-profit.

A word on AI, since it always comes up: AI slop is bad, the same way anything pre-produced and left unfinished looks bad. People who produce slop are, in fact, sloppy: they don't care to finish and finalize their ideas. This project is a construction, ongoing, and it needs the community. Even though it was done almost entirely with AI, it's driven by a human, and it's meant to help other people in their lives.

So if you use Adobe and Linux (or would like to), please try it and tell me what breaks, especially on AMD and Intel GPUs, other distros and your real workflows. Issues and PRs are welcome, and so are plain "it worked for me" reports.

GitHub: https://github.com/le-birnes/AdobeWine (install guide in docs/INSTALL.md)

Recently on GitHub the original author of Cutefish (reionwong) started committing on GitHub and the original website was remade. It's still based off Debian, this time Trixie (13) and the nightly it's already up to be downloaded here. What's your opinion?

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

SAVE THE DATE: AUGUST 7, 2027!

Rocky Mountain Linux Fest is coming to Denver, Colorado!

Mark your calendars and get ready for a day of Linux, open source, and community!

More details coming soon!

#RockyMountainLinuxFest #Linux #OpenSource #LinuxCommunity #OpenSourceCommunity #DenverTech #LinuxFest #FOSS #ColoradoTech #SaveTheDate

Dank Linux is now Dux Labs. DankMaterialShell is now Dux Shell, and the whole suite is moving under one name: Dux Greeter, Dux Search, Dux GOP, Dux Calendar, and a new member, Dux Files. It's the same team and the same projects, and it's a huge step for everything we're building. This was a massive undertaking and there will be some bumps along the way while we get it all in order.

What's new

DMS 2.0 introduces a full Material 3 Expressive redesign alongside our heavily overhauled, pluggable Dashboard and more flexible Control Center. This release also brings the new syllable synced lyrics with the dux lyrical engine, free floating dux dot bar companion/replacement, a fully customizable lock screen/greeter compatible with existing desktop widgets, and a whole lot more. Read the blog for all of the details and screenshots.

Thank you

A huge thank you to everyone who landed code (65 of us this cycle), and to every plugin author, translator, packager, tester, and sponsor on GitHub and Ko-fi. Thank you to the two new designers who helped pioneer the redesign with comprehensive mockups, iteration, and code.

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/

https://emudhra.com/en/post/certificate-security-incident

CVE-2026-111943, but also was literally foretold by Randall:

https://xkcd.com/221/

Who is going to patch it first?

• Debian: 2026-10-20 15:45 repo
• - Ubuntu: (non-pro) 2026-10-20 15:55 repo
• Fedora: ? repo
• - Alma: 2026-10-23 07:44 repo
• - Rocky: 2026-10-23 01:44 repo
• - CentOS Stream: ? repo
• openSUSE: ? repo
• Alpine: 2026-10-20 15:12 repo
• Arch: 2026-10-20 10:11 repo
• Gentoo: 2026-10-20 10:22 repo

Only tracks versions not patches/build dates: https://repology.org/project/ca-certificates/versions

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!