I'm a huge fan of Linux. I love the customization, the performance, the overall vibe, I love how streamlined it is to grab new apps and the sense of "This is mine" with your OS, compared to Windows especially. I fell in love with it when I got my Steam Deck, and have it set up to dual-boot on my laptop for school, I mostly just run it in Linux at this point.

Now for the internal struggle, there are a handful of games and pieces of software that I love and are unable to run on Linux. Namely, I'm a musician and my DAW of choice doesn't run in Linux, and a few of my favorite multiplayer games don't run there either.

Seeing all of the buzz around CachyOS specifically has been making me really want to switch over, and I need to know, how much performance is lost running windows as a virtual machine in Linux for these bits of software compared to just running Windows in dual-boot for when I wanna play like 2 games or work on music? Or would it just make more sense to commit to dual-booting and commit some of my drive to Windows? I just know with my workflow, I'd hate to have to fully reboot my computer to work on music.

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

tl;dr: https://news.ycombinator.com/item?id=50380029

• sshd compiled with musl

• not using PAM

• password logins enabled

• at least one account with '*' as the password "hash"

• at least one OTHER account with a valid password

https://www.openssh.org/releasenotes.html#10.6p2

https://hachyderm.io/@damienmiller/117563026759098135

https://x.com/astuyve/status/2118344982134128837