[RFC] First-class compressed application images for Linux

[RFC] First-class compressed application images for Linux

[Artem S. Tashkinov]

Hi,

I’d like to float an idea for discussion: first-class support for 
compressed, read-only application images that can be executed directly, 
without explicit mountpoints, systemd units, FUSE runtimes, or 
application-specific unpacking.

The motivating case is simple.

Large desktop applications such as Firefox, Thunderbird, Telegram, IDEs, 
etc. are mostly immutable application trees. Installing or updating them 
traditionally means writing hundreds of megabytes of individual files, 
metadata, inodes and directory entries to disk, even though the 
application itself is effectively read-only.

Today there are several partial solutions, but none feels like the right 
abstraction:

- **UPX and similar executable packers** reduce disk usage, but they 
work against the VM subsystem. They interfere with normal demand paging 
and file-backed executable mappings, often increasing memory usage and 
startup cost.
- **AppImage** gets much closer architecturally, but brings a userspace 
runtime, FUSE/mount machinery, `AppRun`, integration conventions, and 
its own packaging ecosystem. It solves distribution, not merely 
compressed execution.
- **SquashFS/EROFS mounted manually** work extremely well, but require 
explicit mount management, namespace-visible mountpoints, boot 
integration and external lifecycle logic.
- **Transparent filesystem compression** would solve the storage 
problem, but ext4 still does not provide it, and application deployment 
should arguably not depend on which writable filesystem happens to back 
`/opt`.

What I have in mind is something closer to a new executable-container 
abstraction.

For example:

     Telegram.app

could contain a small metadata header plus a SquashFS/EROFS-like 
filesystem image and an entrypoint such as `/Telegram`.

Then:

     ./Telegram.app

would cause the kernel/binfmt/VFS machinery to instantiate an internal 
read-only filesystem view and execute the entrypoint normally.

The important property is that files inside remain real file-backed 
objects from the VM subsystem’s perspective. Executable and library 
pages can still be mmap()ed, shared, reclaimed and faulted back in 
normally. Compression exists only below the VFS layer.

Conceptually:

     execve("Telegram.app")
         -> recognize packaged application
         -> instantiate internal read-only filesystem
         -> resolve declared entrypoint
         -> ordinary ELF execution / mmap / page cache

No visible `/mnt/foo`, no loop-device choreography, no FUSE daemon, no 
mandatory systemd unit.

I recently experimented with exactly this model manually by placing 
Telegram, Firefox and Thunderbird into SquashFS images and mounting them 
under `/opt`. The result is strikingly effective: dramatically less 
persistent storage, lower write amplification during upgrades, and much 
better runtime behavior than executable packing. In one case, Telegram’s 
RSS dropped from over 1 GiB with UPX compression to roughly 400 MiB when 
stored in SquashFS, while also starting faster.

That experiment mostly convinced me that the missing piece is not 
compression technology; Linux already has excellent compressed read-only 
filesystems. The missing piece is a first-class executable-container 
interface tying binfmt, VFS and an internal mount together.

I’m not proposing that application distribution policy, update systems, 
desktop integration or signing formats be baked into the kernel. Those 
belong in userspace.

The kernel-side primitive could stay deliberately small:

- recognize a packaged executable format;
- instantiate its embedded read-only filesystem;
- expose a declared entrypoint;
- preserve normal file-backed VM semantics;
- allow the container file itself to remain the only externally visible 
object.

Is this something that has been discussed before in a comparable form?

If not, would there be any interest in exploring what the minimal kernel 
mechanism could look like?

Regards,
Artem

[RFC] First-class compressed application images for Linux

[Artem S. Tashkinov]

Hi,

I’d like to float an idea for discussion: first-class support for 
compressed, read-only application images that can be executed directly, 
without explicit mountpoints, systemd units, FUSE runtimes, or 
application-specific unpacking.

The motivating case is simple.

Large desktop applications such as Firefox, Thunderbird, Telegram, IDEs, 
etc. are mostly immutable application trees. Installing or updating them 
traditionally means writing hundreds of megabytes of individual files, 
metadata, inodes and directory entries to disk, even though the 
application itself is effectively read-only.

Today there are several partial solutions, but none feels like the right 
abstraction:

- **UPX and similar executable packers** reduce disk usage, but they 
work against the VM subsystem. They interfere with normal demand paging 
and file-backed executable mappings, often increasing memory usage and 
startup cost.
- **AppImage** gets much closer architecturally, but brings a userspace 
runtime, FUSE/mount machinery, `AppRun`, integration conventions, and 
its own packaging ecosystem. It solves distribution, not merely 
compressed execution.
- **SquashFS/EROFS mounted manually** work extremely well, but require 
explicit mount management, namespace-visible mountpoints, boot 
integration and external lifecycle logic.
- **Transparent filesystem compression** would solve the storage 
problem, but ext4 still does not provide it, and application deployment 
should arguably not depend on which writable filesystem happens to back 
`/opt`.

What I have in mind is something closer to a new executable-container 
abstraction.

For example:

     Telegram.app

could contain a small metadata header plus a SquashFS/EROFS-like 
filesystem image and an entrypoint such as `/Telegram`.

Then:

     ./Telegram.app

would cause the kernel/binfmt/VFS machinery to instantiate an internal 
read-only filesystem view and execute the entrypoint normally.

The important property is that files inside remain real file-backed 
objects from the VM subsystem’s perspective. Executable and library 
pages can still be mmap()ed, shared, reclaimed and faulted back in 
normally. Compression exists only below the VFS layer.

Conceptually:

     execve("Telegram.app")
         -> recognize packaged application
         -> instantiate internal read-only filesystem
         -> resolve declared entrypoint
         -> ordinary ELF execution / mmap / page cache

No visible `/mnt/foo`, no loop-device choreography, no FUSE daemon, no 
mandatory systemd unit.

I recently experimented with exactly this model manually by placing 
Telegram, Firefox and Thunderbird into SquashFS images and mounting them 
under `/opt`. The result is strikingly effective: dramatically less 
persistent storage, lower write amplification during upgrades, and much 
better runtime behavior than executable packing. In one case, Telegram’s 
RSS dropped from over 1 GiB with UPX compression to roughly 400 MiB when 
stored in SquashFS, while also starting faster.

That experiment mostly convinced me that the missing piece is not 
compression technology; Linux already has excellent compressed read-only 
filesystems. The missing piece is a first-class executable-container 
interface tying binfmt, VFS and an internal mount together.

I’m not proposing that application distribution policy, update systems, 
desktop integration or signing formats be baked into the kernel. Those 
belong in userspace.

The kernel-side primitive could stay deliberately small:

- recognize a packaged executable format;
- instantiate its embedded read-only filesystem;
- expose a declared entrypoint;
- preserve normal file-backed VM semantics;
- allow the container file itself to remain the only externally visible 
object.

The container ecosystem has independently moved toward directly 
mountable, compressed filesystem images—eStargz, Nydus and EROFS 
snapshotters exist largely to avoid eagerly unpacking application data. 
This suggests that the underlying abstraction is useful beyond 
containers. A normal Linux application could potentially benefit from 
the same idea without requiring OCI, containerd, FUSE, overlayfs or a 
container runtime at all.

Is this something that has been discussed before in a comparable form?

If not, would there be any interest in exploring what the minimal kernel 
mechanism could look like?

Regards,
Artem