this post was submitted on 18 Jun 2024
38 points (93.2% liked)
Linux
48176 readers
897 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
By default, Fedora Atomic envisions the following in regards to installing packages/software:
rpm-ostree
.This works pretty fine, but isn't perfect:
rpm-ostree
will negatively impact how fast you can update your system, it also requires you to (soft-)reboot before you can access the newly installed package (unless you enjoy living on the edge with--apply-live
). This can be pretty cumbersome, especially if you're in flow.Thus, the situation around CLI on Fedora Atomic became a sore to the eyes. Within the community, there were multiple attempts to tackle this problem:
apt
/dnf
/pacman
withflatpak
(for GUI) andbrew
(for CLI). Furthermore, it comes with a big and healthy repository. Finally, it utilizes technologies related to the ones found on Fedora Atomic.systemd-sysext
; This has only very recently been added to systemd. I wouldn't be surprised if this will play a prominent role going forward. Though, I'm unsure if CLI will benefit most of it.Very interesting. I wish flatpak would offer a better CLI experience. I don't want another package managing tool, but here we are.
Can't agree more.
I believe Flatpak initially couldn't and/or didn't want to do CLI. At some point, it offered some basic functionality; I first noticed it on Bottles. But, it's pretty dire if no variation of
top
can be found as a Flatpak.I wouldn't be surprised if most people are simply unaware that Flatpak can even do CLI. This inevitably also negatively affects its CLI ecosystem.
The flatpak packaging tutorial has you build a cli app, so anyone building one is likely aware.
The real issue is invoking the commands. If you install a snap of top, you run top and it opens. If you installed a flatpak it wouldn’t be added to your PATH and even if you added the exports directory to your PATH you would need to remember to run org.gnu.top. Nobody wants to run some random flatpak run command all the time or create aliases for everything, so “flatpak isn’t for cli” becomes the mantra.
In an ideal world a flatpak could register the cli commands it wants to present to the user, and some alternatives system could manage which flatpak gets which command if there were collisions.
This has been my dream ever since I discovered Flatpak. I wish it becomes the case one day.
It's good that there has been partial progress in that direction. Let me give an example with the Floorp browser. I can do a
flatpak install floorp
and I can do akillall floorp
and they will work. If we can somehow get a way of accessing flatpaks as if they're regular packages via the terminal (is it possible to build a program to do this and have it packaged as a flatpak?; Maybe a program that creates a oneliner script to act as an "alias" in a directory (within $HOME so it works on immutable systems) that gets added to $PATH), that would be amazing!