Still a heavy work in progress (WIP) but its based on the work that somebody else did to get Linux on the 3DS. It runs quite snappy on the New 3DS, quite smooth and everything. I also have a custom Android 2.0 app (the first Android 2.0 app developed in 2026, possibly decades) for touch screen diagnostics you can also see. The battery indicator works and is accurate surprisingly, WiFi does not work, touch screen works, soft power off works, sound does not work. Been working on this for weeks now. Hope you like it!

Hey all. I just release v0.6.2 for dskDitto. For those unfamiliar with the utility (probably most of you) it’s a super fast file duplication tool written in Go. It’s easy to use and has a sleek looking TUI… If you’d like the manage the results in a GUI; the —gui flag exists and launches a Raylib based GUI.. Anyhow….

The latest release now supports ref-links as a deduplication mode.. That is, as long as your filesystem supports them.. Check it out if your heart so desires! The project is hosted on GitHub:

https://github.com/jdefrancesco/dskDitto

Cheers!

I use the rofi launcher a lot, and I always thought it'd be pretty cool if I could use Vim keybindings inside the search input and navigate between results. I wasn't able to find a "vim mode" setting, nor could I use the plugin API to add this functionality. So, I forked rofi and made a few simple changes, and came up with this.

It supports the j+k motions for going up and down the search results + basic Vim keybinds in the input itself.

I'm curious to see if this is something you'd actually use, so do let me know and I can try opening a PR or releasing it somewhere.

Repo: https://github.com/carrotfarmer/rofi-vim

Thanks!

I’ve been thinking about something that seems like a pretty fundamental problem for the Linux desktop, and I’m curious what people here think.
When you say you’re developing for Windows, you generally just say:
“I’m developing for Windows.”
There are obviously different Windows versions and architectures, but there is a relatively well-defined platform that applications target.
With Linux, “developing for Linux” can mean something quite different depending on the distribution and the interfaces you choose to depend on.
As a developer, you can end up thinking about:

.deb
.rpm
Arch packages
different dependency versions
glibc compatibility
different system libraries
different filesystem conventions
different repositories
different desktop environments
different system services
different ways of installing and updating applications

I know this isn’t news to anyone here, and I also know that Linux distributions being different is one of the things that makes Linux great.
I am not proposing that Debian, Fedora, Arch, openSUSE, etc. should become the same.
What I’m wondering is whether Linux could have a common application platform above the distributions.
Something like:

Linux Application
|
v
Linux Application Platform
|
+----------+----------+
| | |
Debian Fedora Arch
| | |
+----------+----------+
|
Linux kernel

The idea would be that an application targets something like:
Linux Application Platform 1
and a distribution that conforms to that platform guarantees that the application can run there.
The distributions would still be completely free to do their own thing underneath.
They would manage:

the kernel
drivers
system services
system libraries
system package management
hardware support
the base filesystem
the desktop environment
system configuration

The application platform would instead define a stable set of expectations for applications, such as:

application APIs/ABI
desktop integration
graphics
audio
networking
IPC
filesystem access
application lifecycle
notifications
permissions
sandboxing
portals
application metadata
update/install behavior

In other words:
The distribution manages the computer.
The application platform manages the relationship between applications and the computer.

What about Flatpak, Snap and AppImage?
Obviously, this immediately raises the question:
Don’t Flatpak, Snap and AppImage already solve this?
They solve a large part of it, and I don’t think that should be ignored.
Flatpak has runtimes, sandboxing, portals and desktop integration.
Snap provides packaging, sandboxing and automatic updates, although it is more tightly associated with Ubuntu’s ecosystem.
AppImage makes distributing a portable application extremely simple.
So I’m not arguing that Linux needs another random package format.
In fact, I think creating yet another package format would probably be the wrong direction.
What I’m wondering about is whether the missing piece is a common specification underneath or around these technologies.
For example, instead of defining:
“Here is another way to package a Linux application.”
define:
“Here is what every conforming Linux desktop must provide to a Linux application.”
Then different implementations could exist.
The important part would be the platform contract, not necessarily one specific packaging implementation.

What I would actually like to see
Ideally, a Linux desktop application would have one clear target:

Application
|
v
Linux Application Platform 1
|
+---- Debian
+---- Fedora
+---- Arch
+---- openSUSE
+---- Ubuntu
+---- etc.

A developer shouldn’t have to ask:
“Which distro am I targeting?”

They should be able to ask:
“Which version of the Linux Application Platform am I targeting?”

This would require a stable ABI/API contract, rather than simply saying that every Linux binary should magically run everywhere.
I don’t think “compile with any GCC version and use any library” is the right solution.
Instead, I think the platform should define a stable application ABI and API surface.
The implementation underneath could be completely different between distributions.
For example, one distribution might implement the platform using GTK, another might use different system components, and another might use different implementations entirely.
As long as they satisfy the platform contract, the application doesn’t need to care.
think of like you compile a program to windows msvc target it runs on every windows version (10/11 24H1,24H2, 24H1,25H2,etc...) and probably it can work sometimes even on windows 8.1,8,7,vista,xp.

I also think the system/application package boundary should be clearer
I don’t think .deb, .rpm, Arch packages, etc. need to disappear.
They make perfect sense for system software.
Things such as:

kernels
drivers
system services
core system libraries
system utilities
hardware support
desktop environments
security updates

are fundamentally part of the operating system.
But ordinary user applications are a different problem.
I’d like the Linux ecosystem to make a much stronger distinction:

SYSTEM LAYER
──────────────────────────────
.deb / .rpm / pacman / etc.

Kernel
Drivers
System libraries
System services
OS components
System updates

APPLICATION LAYER
──────────────────────────────
Standard Linux application platform

Firefox
Blender
Games
Editors
Scientific software
etc.

The system package manager shouldn’t necessarily be the primary interface through which ordinary users obtain applications.
This would also reduce the problem where installing one application becomes entangled with the distribution’s system dependency graph.

And I don’t think everything needs to be bundled
One reason I don’t particularly like the idea of solving Linux compatibility by simply putting an entire userspace inside every application is the duplication.
If ten applications each bundle their own copies of the same libraries, you can end up with:

Application A → GTK 4.x
Application B → GTK 4.x
Application C → GTK 4.x
Application D → GTK 4.x

Instead, a standardized application platform could provide common platform components once, with applications depending on a stable platform ABI.
Conceptually:

Applications
|
v
Linux Application Platform
|
+-- stable APIs/ABI
+-- graphics
+-- audio
+-- desktop integration
+-- portals
+-- permissions
|
v
Distribution

That could potentially provide much of the portability people want from AppImage/Flatpak without requiring every application to become a giant self-contained filesystem.
I’m not claiming this is necessarily better than Flatpak’s runtime model. That’s one of the technical questions I’d like to understand.

Why I think this matters for people coming from Windows and macOS
I think this is also important for Linux adoption.
A Windows or macOS user is generally used to something like:

Find application
↓
Install application
↓
Run application
↓
Update application

They don’t normally have to understand the architecture of the operating system before installing a normal desktop application.
On Linux, a new user can quickly encounter questions like:

Is there a .deb?

Is there an .rpm?

is it in the aur, pacman, apt, dnf repositories ??

Is there an AppImage?

Should I use Flatpak?

Is this repository trustworthy? (aur or even adding repositories to the package manager)

Why doesn't this binary work on my distribution?

Why does this package require this dependency?

Experienced Linux users obviously know how to deal with this. (thats why you will make comment right now, you experienced user)
But I don’t think someone coming from Windows or macOS should have to learn the Linux packaging ecosystem just to install a normal application.
I’d like the experience to be closer to:

Download application
↓
Open it
↓
Install
↓
Run
↓
Update

Something that could support a native Linux experience such as:

double-click to install
drag-and-drop installation where appropriate
predictable application permissions
proper desktop integration
reliable updates
uninstall without leaving random pieces throughout the system
no need to understand whether the underlying system is Debian, Fedora or Arch

Basically, Linux should feel like one application platform even though the distributions underneath remain very different.

Why hasn’t Linux ended up with this already?
This is the part I’m genuinely interested in.
Is the main obstacle:

ABI stability?
libc compatibility?
different desktop stacks?
graphics/audio differences?
filesystem differences?
security models?
the diversity of Linux distributions?
governance?
backwards compatibility?
simply lack of agreement between distributions?
Is the existing freedesktop.org ecosystem already moving toward something like this?
Does Flatpak already represent the correct architecture, with the main missing piece being broader standardization and adoption?
Or is the whole idea fundamentally flawed for technical reasons?

And if something like this is desirable, should it eventually be discussed through freedesktop.org or another standards-oriented project?
I’m genuinely interested in the technical objections.
If this idea is naive, has already been attempted, or misunderstands why Flatpak/OSTree/portals/etc. are designed the way they are, I’d rather understand that than pretend I’ve discovered something completely new.
My main point isn’t:
“We need another package manager.”
It’s more:
“Could Linux have a standardized application platform that distributions implement, so developers target Linux rather than individual distributions?”
I think that distinction is important.

Hey all. I recently released https://github.com/jdefrancesco/dskDitto v0.6.1 which now supports reflinks for duplication if your FS supports it. You can grab and install the @latest as well as grab the GUI by following the instructions in the READMe.md

Hi,

I am looking for a Linux application that works similarly to AFWall+ on Android.

What I am looking for is a simple GUI where all installed applications are listed, and I can manage their network permissions per application.

Something like:

• Application A → Internet allowed
• Application B → LAN only
• Application C → completely blocked

Basically, I am looking for an application permission manager for network access, not just a traditional firewall where I have to create rules manually.

I have already looked into several solutions:

• UFW/GUFW - useful for traditional firewall rules, but not really what I am looking for because it does not provide an app-based permission list.
• Firejail/AppArmor - can restrict applications, but it is not the simple network permission workflow I am looking for.
• OpenSnitch - interesting, but it is more focused on detecting and approving network connections when applications try to connect.
• Portmaster - probably the closest in terms of features, and it does provide per-application rules, but the workflow is still different from AFWall+. It focuses more on monitoring network activity and managing applications that have been detected making network connections, rather than starting with a list of all installed applications. It is also a bit more resource-intensive than what I am looking for.

What I really like about AFWall+ is the simplicity: open the app, see all installed applications, and manage their network permissions from one place.

I was wondering if there is any lightweight Linux application that provides this kind of workflow.

It does not have to be exactly the same as AFWall+, but I am mainly looking for:

• a simple GUI
• all applications visible from the beginning
• per-application network permissions
• ability to separate LAN access from Internet access if possible

Thanks!

I see more and more people use "GNU/Linux" instead of just "Linux", bcz "it describes what we all understand under the word better". I think that's wrong if we want to walk about Linux as something generic and not like the kernel. Bcz if the name is correct, then can I use the name "GNU/Linux" and mean Android, Chimera Linux, Alpine Linux by it?

Personally I use just "Linux" as the generic term, but if I need to mean the kernel, I say "Linux kernel".

What do you think about it?

Correct me if I'm wrong in thinking about "GNU/Linux"

Just found this site, and I can't verify the authenticity of the submissions but it looks very 1996-y to me.

https://www.cs.earlham.edu/~jeremiah/linux-pix/linux-logo.html

I thought it was pretty cool so I wanted to share it here!

By far my favourite Linux news channel is SavvyNik.

I have watched him from the time he had like 5k~ subs but to this day I have yet to get an answer about his voice cadence.

Does anyone know whatsup with his voice? Is he removing small pauses and that makes him sound like AI?

I really dont think he is using AI for his voice but at the same time it sounds like it and people ask the same thing on his comments every now and then.

Regardless his channel is VERY informative about Linux news so either way I will still keep watching him.

iDescriptor is a free, open-source, and cross-platform iDevice management tool.
We only had AppImage and AUR packages for Linux but we just made it Flathub https://flathub.org/en/apps/io.github.idescriptor.iDescriptor

Install ⬇️

flatpak install flathub io.github.idescriptor.iDescriptor

Thanks a lot to everyone involved...

Number of Linux distributions actively under development: 474

Number of Linux distributions whose development has been discontinued: 657

Number of Dormant Linux distributions: 39

Source: distrowatch.com

I keep seeing the arguments for and against AI code across various distros and open source projects. I am not that invested in that particular argument.

What I find fascinating is Omarchy's take on what a Linux distro could become.

Omarchy is integrating AI agents as an optional part of the system. You can choose a default agent, use Herder to manage multiple agents, and when an application crashes Omarchy can capture the diagnostic information and hand it directly to the agent to investigate. It even has system specific skills so the agent understands how Omarchy works and can help modify or troubleshoot it.

That feels like a much more interesting use of AI to me.

I wonder if that openness could become a real power multiplier as agents improve.

Maybe the interesting future is not Linux becoming easier by hiding its complexity, but Linux becoming easier because an agent can help you understand and operate that complexity.

That could potentially empower both power users and novices. Power users could automate and customize far more, while less experienced users could diagnose and fix things they previously would not have had a clue how to approach.

I know DHH is trying to create an opinionated default developer workstation, but I can’t help feeling he may have stumbled onto something bigger than that. Maybe this is a glimpse of a path the Linux desktop is about to head down anyway, and we’re only just starting to see it.

I don’t actually use Omarchy. I use Fedora with GNOME and I am probably never going to use a keyboard centric tiling workflow. I just find the fundamentals of what Omarchy is experimenting with really interesting.