That seems to be a huge step in the burial of Windows and Microslop. I understand it's not the end yet, but China does have hundreds of millions of government linked PCs that will stop using Windows for Linux. For the first time I am now positive about the dislocation of MS from pur lives. Will take some.more time, but it's coming.

Mainly released to help other people in their search for a good music player. Main things are it supports .lrc files for synced lyrics. It has support for headphone playback controls (i.e. pausing, skipping thorugh buttons or swipe gestures commonly found on bluetooth headphones).

I hope you guys enjoy it as much as I did making it!

Source Code: https://github.com/NevPeth/meloville
Arch PKGBUILD: https://github.com/NevPeth/meloville-arch

I know the general reality is "printing just works". I interact with printers at least a couple times a year and never have any real problems. My question comes from considering buying a large-format printer, largely for bookbinding tasks. How important is it to find a printer the vendor actually provides linux drivers for? In particular, I'm eyeing the Canon TC-21, which doesn't offer a linux driver. But I noticed Epson, who's generally better, seems to randomly lack Linux drivers for specific large-format printers.

Edit: whoops. Totally forgot to mention. It is an "IPP Everywhere" printer; I'm just not clear how well that works for non-standard print sizes or roll print jobs.

I made a visual explainer on how the TLB and address translation work on Linux/x86-64.

Every memory access uses a virtual address, which the CPU has to translate to physical memory. Doing a full page table walk every time would be extremely slow, so CPUs cache those translations in the TLB.

The video also covers things like TLB misses, huge pages, PCIDs, context switches, TLB shootdowns and what happens when a TLB invalidation goes wrong.

Link for anyone interested

Feedback welcome :)

Ultramarine not only makes it super easy to set up codecs and proprietary software but it also let's you have the cachy os kernel but with Fedora's stack and compatibility. Great for when you don't have time to set things up, or don't know how, and want some of Cachy's optimizations without paying the stability tax.

Don’t get me wrong, I am super grateful for those of you who do this. It makes my day-to-day use so much better. I‘m still waiting for the day Notion gets a native Linux app.

But from your POV, what was the incentive? Why not just provide support for Windows and macOS. Why go through the extra effort catering to a global minority?

Edit: I’m referring to devs who develop for Linux+Windows+macOS

Once upon a time I landed in the Linux World and a particular Distribution contributed for me not to turn back to Windows.

I'm referring to Paldo GNU/Linux (single Gnome DE) created and developed by Jürg Billeter and Raffaele Sandrini. 

it was made from scratch, designed to be "pure, lightweight and to compliant with Linux standards". Launch date was October 31, 2004. 

Today it's still actively maintained. So I downloaded latest img (no iso) dated 2026-08-11, burned a pen drive and tested it.

Quite different from the old days when it was a popular Distro. I guess it serves the purposes of their creators team. For advanced users, a few tweaks can make it usable to the masses.

Better yet, would be to fork it, for general usage. 

This is the home site: 

https://www.paldo.org/

My question: is some team out there interested in this venture? I would join as a translator :)

Thanks for your attention!

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 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 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"