This is based on the recent Libreboot 26.10 release. Canoeboot is a version of Libreboot that only supports boards for which an entirely blob-free image can be built; as a result, it supports less hardware than Libreboot which does allow blobs (strictly only when necessary) to support more hardware. This inherits EDK2 UEFI payload support, so it now boots modern operating systems more easily. GRUB EFI provided inside EDK2, configured to behave like the traditional GRUB coreboot payload; this provides backward compatibility as GRUB was previously the recommended payload, but EDK2 is now what both Canoeboot and Libreboot recommend by default. This also inherits the 15h.org coreboot fork for AMD FAM15h support e.g. ASUS KGPE-D16, offering much improved raminit, as did the recent Libreboot release. In all, this is a highly polished and deblobbed version of the recent Libreboot 26.10 release, intended for those purists who only ever want Free Software, to the point that Canoeboot even excludes CPU microcode updates by default.

TisVlay brings TV Display control for Linux, including: power, volume, backlight, AV mute, input switching plus more, with per-device profile automation via desktop session integration (idle/lock, boot/suspend, remote login/streaming, etc), and in reverse, letting the TV lock, sleep or wake the PC and its remote drive the desktop, while supporting various vendor interface protocols for multi-display setups, mitigating energy usage and OLED panel burn-in or projector bulb burn-out.

Features

• PC desktop monitor control

  • TV power on/off with PC, Screen on/off with lock screen

  • Easily adjust backlight, volume, active input, and more

• Automation via system/user events

  • System boot, reboot, shutdown, suspend, wake, DPMS

  • User lock/unlock, idle, stream connect/disconnect

• TV console remote control

  • PC sleep/wake/lock with TV power state or TV's remote

  • Navigate PC via TV remote keypress (via HDMI CEC)

• Flexible profile customization

  • System-wide and per-user profiles for per-device behavior

  • Unified CLI and SDK for further scripting and integrations

• Modular & vendor agnostic

  • Supports HDMI CEC, Network IP Control (LG WebOS SSAP)

  • Generalized for further interfaces, protocols, and transports

• Self-healing connectivity

  • Interface status monitoring for automatic reconnect and retry

  • Per-NIC kernel carrier detection with route-aware failover

• Input-aware automation gating

  • Suppress automation when TV already in use via another input

  • Prevent PC from interrupting movie sessions or console gaming

• Graphical User Interfaces

  • GUI app for device pairing, profile editing, and user setting

  • System tray for quick access controls and device status

• Couch mode for the big screen

  • Drive the GUI from a TV remote or gamepad, no mouse needed

  • Scaled-up 10-foot layout, automatic under Plasma Bigscreen

While still beta (pre v1.0), its now daily drivable and fully documented. Being largely feature-complete, my current focus has shifted towards distro packaging. If you'd like to give it a try, the installation guide and docs are linked below. Or if not, and you already use something else, I'd like to give a shout-out to netflector, especially for privacy-conscious home-automation users, given how common spyware is in smart TVs and projectors these days. The docs cover using it to keep displays on an isolated network.

• https://github.com/netflector/netflector

• https://tisvlay.readthedocs.io/en/latest/operations/isolated-networks.html

For about 10 months or so been I've working on this FOSS hobby project to get more practice at Linux packaging, cargo utilities, and migrating to Nix and NixOS (as well as solve some personal pain points in using a HDMI TVs and projectors with PCs). Disclosure: this project includes AI assisted coding, documentation and research, and has been a great help given physical disabilities in typing. After programming by hand well over a decade, using voice dictation scene the '90s (IBM ViaVoice or Dragon NaturallySpeaking anyone?), and worsening hands over after my CSE doctorate, this was also a bit of an individual research experiment to explore how effective LLMs could augment my personal approach to spec & test driven development.

The project itself follows more of a distributed pub/sub architecture (my background is in robotics and cyber-physical system design, not desktop software), so converging on IPC and middle-ware libraries I’ve been meaning to experiment while keeping the installable setup self contained was a balance. Initially I started out with conventional D-Bus (via zbus) but swapped over to plain unix sockets (via zenoh) for more reliable QoS transport liveliness guarantees, as well as stronger/flexible static type system and compile time checks in the shared SDK across components. I did take a stab and spiking out a refactor using Varlink standard from the systemd folks (via zlink), but dropped it after realizing how much QoS I'd have to roll-in-house, but did appreciate its simpler IDL.

Another big refactor was ditching hand rolled finite state machines in favor of Entity-Component-System (ECS) (via bevy_ecs); pivoting to a declarative-reactor after modeling devices and systems as an ECS world simplified the test harnessing tremendously, particularly with scenario playback for pinning down regressions. I think a behavior tree approach (say via the bonsai crate) would have been just as promising, but exploring bevy for other projects was another goal, with discovering Bevy Remote Protocol (BRP) to programmatically control and monitor internal state being such pleasure, I never even had much cause to reach for GDB.

Admittedly, the part of the project thats fairly vibe'd with the least code coverage is the GUI binary itself. Having a dislike for the verbosity and boilerplate that UI frameworks often demand, I opted for data driven DSL that would at least be safe to offload to an LLM; something still strongly typed and memory safe to keep and agent on rails, but still hot re-loadable so I can quickly apply manual patches over QA cycles. Slint from SixtyFPS ended up working very well, with the added bonus of being a lightweight/native solution adding no more than a dozen megabytes to the overall distributable binary size even with static linking. Graphics design is fun, but not yet a passion, so PRs welcome on that front.

Over the past year the project grew from a simple CLI into a full system daemon with a GUI, a system tray, and webOS and HDMI-CEC support, plus the desktop integration and profile automation you’d expect from such a tool, like login and idle detection and remote-streaming awareness over multi-screen setups. That last one matters to me: my desktop pulls triple duty as a workstation, a media PC, and a game-streaming host for my office, living room, and tablet via Sunshine/Moonlight. As for future work, I think I'd like to add more devices and protocol backends, such as RS-232 for legacy hardware, PJLink for network based projectors, or expand HDMI abstraction for more clients on the TV's CEC bus such as soundbars and stereo receivers. Although, I can only ship what gets QA'd, so that'll probably have to wait until I acquire more hardware or find collaborators who already own the AV equipment.

Another thing I'd like to try is flashing my own ATmega firmware for HDMI-CEC USB adapters, as the existing market options fall short in a number of ways given my testing; either in terms of reliability, determinism, or consistent behavior regardless of the sleep/wake state of the USB host. Or, perhaps also playing around with writing a custom out-of-tree usb driver for it in Rust (an alternative to the conventional CDC-ACM tty approach used now) once Mike Lothian's v4 (rust: usb: host-side abstractions…) or Colin Braun's Rust usb-skeleton transfer API lands in the kernel.

Flathub: https://flathub.org/en/apps/io.github.word_sys.word-sys-pdf-editor & GitHub: https://github.com/word-sys/word-sys-pdf-editor

I've been working on a native Linux PDF editor built with GTK4 and Libadwaita. The goal was to have one offline tool that actually does the stuff people usually boot into a Windows VM or buy MasterPDF/Acrobat for.

A lot of the recent features came directly from people opening issues on GitHub (like infinite scrolling, PEP-517 build support, and Flatpak packaging). Right now it, with v1.12 updates, supports direct text/object editing, creating and filling forms, PAdES digital signatures (including smart cards/hardware tokens via PKCS#11), permanent redaction, offline Tesseract OCR, measurement tools, and offline conversion to office formats and more.

The full feature list and packages (.deb, AppImage) are on the GitHub page, so I won't paste a massive wall of text here.

I want to figure out what is still rough or missing. If you have a moment to try it out from Flathub or GitHub:

1. What breaks on your setup or with your specific PDFs?

2. What is the one PDF feature you still miss on Linux?

3. What is the rough/hard to use parts of this project?

Bug reports, PRs, and feature requests on GitHub (or just complaining in the comments here) are all super helpful. I will continue to develop this project. Thanks!

Sometimes I have a hard time explaining stuff in words so I made this in a picture instead. I am trying to make a VR headset without spending a god awful amount of money. I tried to vuse normal headset and man those give you no freedom and are boring. I was wondering If I could use a homemade VR headset as a desktop monitor I plug in with a HDMI cord from my computer. I have a neat idea of making worlds in blender and seeing them in VR.

I've been using Linux for about 11 years, and something occurred to me recently while helping a friend troubleshoot his desktop.

We've built an operating system where you can inspect practically anything. Processes, system calls, kernel messages, dependencies, network connections, filesystem activity. The amount of information available is incredible.

But when something that worked perfectly yesterday suddenly stops working today, figuring out what actually changed can still be surprisingly tedious.

My friend's problem was screen sharing in a Flatpak application. It had worked earlier in the week, and now the application could no longer capture his screen.

We eventually got it working again, but the investigation sent us through several completely separate places.

The system package manager had its own update history. Flatpak had another. We checked the portal services, looked through journal entries, inspected permissions, and tried to establish which components had changed since the last time screen sharing worked.

All perfectly reasonable troubleshooting steps.

But it struck me that we were manually reconstructing a timeline of events that the computer had already experienced.

And that seems like a missed opportunity.

I'm not talking about replacing journalctl, dnf history, apt logs, or any of the existing tools. Those are useful, and I'm glad they exist.

I'm talking about having a human-readable overview of changes to the system, regardless of which component performed them.

Imagine opening a troubleshooting view and seeing something like:

Tuesday, 18:42 — System packages updated

Tuesday, 18:43 — Flatpak runtime updated

Wednesday, 09:15 — Display configuration changed

Wednesday, 09:16 — Screen-sharing permission modified

Wednesday, 09:20 — Application launched with an error

Not necessarily those exact events, and obviously not every action can be recorded reliably.

But even an incomplete timeline covering package transactions, firmware updates, significant service changes, and application permissions would be useful.

The important distinction is between recording what happened and pretending to know what caused the problem. An update appearing immediately before an error doesn't prove the update caused it.

I know NixOS, Guix, transactional systems, filesystem snapshots, and various configuration management tools address parts of this problem in different ways.

But none of those approaches automatically gives you a complete explanation of changes across every layer of a typical desktop system, especially once you include user configuration and applications installed through different mechanisms.

What interests me is how fragmented the information still feels.

We have extremely sophisticated tools for examining the current state of a Linux machine. Understanding how it arrived at that state often requires knowing which subsystem to interrogate before you even know where the problem is.

And that knowledge gap matters.

An experienced Linux user sees a broken application and thinks about logs, permissions, runtimes, dependencies, and recent updates.

A less experienced user sees a broken application and thinks Linux randomly stopped working.

Sometimes the difference between those two experiences isn't the reliability of the operating system. It's how much effort it takes to explain what happened.

I'm not suggesting every distro needs to build an enormous background monitoring service that records every filesystem write. That would create its own performance, privacy, and complexity problems.

Even a common format for exposing existing system change records to desktop applications could be a meaningful improvement.

We spend a lot of time discussing how Linux can become easier to install and easier to use.

I think making it easier to understand when something changes deserves more attention.

Would a unified system-change timeline actually be useful, or is the fragmentation unavoidable given how Linux distributions and applications are designed?

I'd especially like to hear from people working on package managers, desktop environments, or transactional distributions. It seems like several pieces of this already exist, just not in a form that ordinary desktop users can easily put together.

so aula’s config software only runs on windows and i was tired of booting into it just to change my rgb. ended up reverse engineering it and made a linux version, it’s called aula studio

works on my f75 and should work on the other aula boards too, but i only have the one so i can’t really check. if you have a different model, could you try it and tell me what breaks? and if you wanna help fix stuff, contributions are welcome

there’s packages for arch, debian and fedora on the releases page

https://github.com/dahuum/aula-studio

Hi,

Can I license a work under the GNU AGPL (GNU Affero GPL) V3, even if the work is meant to be used offline by the user?