Great news Monday,% username%. Recently, the stable branch of the Flatpak 1.10 toolkit was published . It is designed to build self-contained packages that are not tied to specific Linux distributions and run in a special container that isolates the application from the system.
Flatpacks are guaranteed to work for Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux, and Ubuntu. They are also part of the Fedora repository and are supported by the stock GNOME application management software. Under the cut - more about the new product and its capabilities.
What is Flatpak?
This toolkit allows developers to simplify the distribution of their own programs that are not included in the standard distribution repositories. How is this implemented? One universal container is being prepared without forming separate assemblies for each distribution kit.
The toolkit also provides a high level of information security, allowing a questionable application to run in an isolated container. In this case, access is only granted to the network functions and user files that are associated with the application. Plus, with Flatpak, you can install the latest releases of applications without the need for system changes. Thus, Flatpak packages are being prepared for LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio and dozens of other applications.
To reduce the size of the package, the developers have included only application-specific dependencies. But all the main libraries are designed as plug-in runtime applications. Flatpack has a key difference from Snap - the latter uses system environment components and isolation based on syscall filtering. But Flatpack creates a container separate from the system, operating with large runtime sets, so that not packages are provided as dependencies, but typical system environments. These can be any libraries that GNOME / KDE programs need to run.
As for the typical system environment, in addition to runtime, additional dependencies are installed that are needed for the application to work correctly. The main system environment and these dependencies form the core of the container. Accordingly, the runtime is installed separately and binds to several containers at once. This makes it possible to do without duplication of common system files for containers.
Several different runtime or several versions of the same runtime can be installed on the same system. The container with the application as a dependency uses the binding to a specific runtime without taking into account the individual packages that make up the runtime. Missing items are packaged with the app. When the container is formed, the runtime content is mounted as the / usr section, and the bundle is mounted in the / app directory.
The stuffing of runtime and application containers is formed using OSTree technology. In this case, the image is updated from a Git-like repository. This is done so that version control methods can be applied to distribution components. For example, a user can roll back the system to a previous state. It is worth highlighting that RPM packages are translated to the OSTree repository using a special layer rpm-ostree.
Separate installation and update of packages within the working environment is not supported, so the system is updated as a whole, and not at the level of individual components. There are also tools for incremental application of updates, which eliminates the need to completely replace the image with each update.
The sandboxed environment is independent of the distribution you are using. So, with the appropriate package settings, the environment does not have access to the files and processes of the user or the host system. Also, the environment cannot directly access the equipment and network subsystem. The Wayland protocol and X11 socket forwarding are used for graphics output and input. Interaction with the external environment is built on the basis of the DBus messaging system and the special Portals API.
For isolation, the Bubblewrap layer and standard container virtualization technologies are used. They are based on cgroups, namespaces, Seccomp and SELinux. The sound is output using PulseAudio. The insulation can be turned off if necessary.
What's new?
- , , . OSTree. , . , . , , , 100 . , Flatpack . , 6.6 (1.8 ), x86-64 — 2.7 (554 ). 20 .
- «flatpak pin» runtime. runtime, , .
- runtime ( ).
- , , "/org/gnome/sound-juicer", «org.gnome.SoundJuicer».
- os-release .
- tcsh.
- , .
- .
- API, flatpak_installation_list_pinned_refs, flatpak_transaction_set_disable_auto_pin, flatpak_transaction_set_include_unused_uninstall_ops, flatpak_transaction_operation_get_subpaths, flatpak_transaction_operation_get_requires_authentication.
- GCC 11.
- PulseAudio .
- , . , - , .
- root .
