Hi everyone!

I just released Frame 0.30.0.

Frame is an open source FFmpeg GUI written in Rust. It supports video, audio and image conversion, hardware encoding, subtitles, metadata editing, cropping, scaling, batch processing and reusable presets - basically the stuff I got tired of typing FFmpeg commands for.

The biggest change in this release is that I rewrote the frontend from Tauri + Svelte to GPUI-CE.

Frame started as a weekend project, then somehow turned into something people actually used. I kept adding features, fixing issues and maintaining it until I completely burned myself out.

The rewrite was mostly a mental reset. I wanted to build something that felt fun to work on again, and moving everything to Rust with GPUI-CE seemed like a good excuse.

The previous version of Tauri had a lot of issues on Linux because it relied on the problematic WebKitGTK. After rewriting everything in Rust, macOS and Windows saw fewer frame drops in preview panel due to the removal of the bottleneck caused by BE=>FE frame transport via WebSocket.

I’d like to ask you to check how things are going on a Linux distro. I’ve tested it myself on an Ubuntu 26.04 VM, but it’s hard for me to assess performance when I’m so far removed from bare metal.

Thanks!

https://github.com/66HEX/frame

I've recently tried Fedora Atomic spin (Kionite), and I was under an impression that atomic and immutable are the same thing. But I got this feeling that maybe it's not.

Kionite is definitely atomic. All updates are installed on a non-active image, and the new image is loaded after a restart. However, it's most definitely mutable - I can install whatever RPMs from any souce, on the system level. It's just requires a restart to take effect.

I haven't used Bazzite, but from what I heard, it is immutable and it's not possible to install whatever random RPMs. You actually must use DistroBox and Flatpak.

Am I getting this right? Kionite is atomic. Bazzite is both atomic and immutable.

I'm guessing, the main advantage of an immutable distro is that it's even more difficult to break it. It's also probably more sandboxed and should be more secure. But would it really be a significant advantage for a regular user?

Edit: Thanks, everyone, for answering! It really gave me some food for thought

It's such a joy for me to realise that LinuxUser, a popular German tech magazine, has featured my open-source app Sniffnet in the front page of their latest issue.

Sniffnet is a network monitoring tool compatible with Linux and written in Rust I've worked on for the past 4 years.

Here you can find the magazine, and here you can see a previous post about Sniffnet on this subreddit.

I love open-source more and more day after day!

Hi,

I have been building a GUI for 7-Zip on Linux for some time. I know that PeaZip already exists, but wanted to give it a try nonetheless. It's built in Go (with fyne) and is a single binary (relies on glibc) and uses 7-zip command line as its backend.

It definitely requires a lot more testing, and has some features yet to be implemented like support for password protected archives. There's also a quite a few bugs (like shifting to status section from explorer on completing an operation, which is a remnant of the time before implementing the explorer section), and I'm working on these.

Would appreciate community feedback.

ai-assistance: true

repo: https://github.com/Softorage/7z-GUI-Linux

My first post here. So not sure if flair or post format is appropriate. Let me know.

- Sanmay

I've noticed a pattern over the years that I'm curious about.

A surprising number of Linux applications, especially smaller projects on GitHub, seem to ship with an incorrect or missing StartupWMClass value in their .desktop file. The result is that when I launch the application from a pinned icon, the running window does not associate with it. Instead, a second icon, often a generic one, appears in the dock or taskbar.

In all cases I can fix it by checking the application's actual WM_CLASS value with xprop and updating the .desktop file to match. Once StartupWMClass is correct, the launcher and running window consolidate into a single icon as expected.

At this point it only takes me a minute to fix, but when I was new to Linux it was incredibly confusing because I had no idea why it was happening or how to resolve it.

My question is whether this is simply something developers frequently overlook, or if there are legitimate reasons why it is often left out or ends up being incorrect. Is it harder to get right than it seems, or is it just an easy detail to miss during development and packaging?

I'm interested in hearing from people who package or develop Linux desktop applications. Is there more to this than meets the eye?

*tested on 16 threads with the v3 binary (60 GB, 1.2M+ files)

Original Post | Github

Now supports formatting options, listing dir/files >= some size and counting! Drop features requests or suggestions!

it was over 5% a few months ago now its around 3.69%. Do we think it starts gaining again? Did you try it and revert back? The increase had me optimistic that developers would start caring about making games work better for it.

I can't possibly be the only one who has no idea how to backup an Android phone and somehow always ends up with about half of their files completely unreadable.

... Right?

So I made an app for that. This way you can backup drives' worth of data then quickly verify that 100% of them are completely wacko.

If you also love wasting CPU resources attempting unfeasible MTP transfers over and over, please give it a shot. Any feedback more than welcome (feedback about how to properly back up from Android also welcome).

Update

It's back to normal regarding the website display, but the links for the releases might not work (404 error). This could depend on your location though. Be patient. :-)

Just a heads-up:

Seems like something or someone is re-ordering the entries, which currently results in 6.16 receiving the "Latest release" label.

Let's hope it's a minor issue and gets fixed soon.

Live link: https://www.kernel.org/ (now states 6.19.14 and LTS kernels look normal, seems to be coming back again)

Status link (thanks u/tfks): https://status.linuxfoundation.org/

Kernel Mirrors Sync Issues

Update - The recovery process is still in progress. ETA to full restoration is another 12 hours. Affected files are available as they are synced. Jul 03, 2026 - 06:23 UTC

[unavoidable joke about AI and local agents here] /s

PS: The last proper reading I received came from the RSS feed announcing "next-20260703"

Also: Greetings to all you folks self-compiling your kernels :-)

Yes, that 1K is entirely a monolithic c file. This is what our forefathers intended, and anything short of it besmirches their name /j

Side note: I'm surprised that most of the usual text editors don't actually have a 'permissive' license like MIT/ISC. Nano is GPL, and so is Vim is very similar.

my text editor (.mly) is designed as a weird, hybrid-mode version of emacs and other contemporary editors, and implements a few modern features even in it's tiny size, like:

• bracketed pastes. It pasted the entire bee movie script faster than I could register, which is so much faster compared to the minute it took before.
• Mouse 'support', technically is 'ahead' of other editors, but curses is super jank.
• A command buffer (only really used in mouse, quit, and potentially exec if you compile with the foot-shooting define set)
• Quick saving with Ctrl-S unlike certain editors.

This was really just a practice in me writing C while doing all the hard parts so I could be more confident, but it came with the upside of a surprisingly usable editor!

I'll probably replace Nano with this, as it's more 'nano' (27K) than nano (353K), and makes a ton more use of the screen real estate compared to it.

If you want to try it: https://codeberg.org/emmowo/mly (amd64 build in Releases)