4 ms·

Oma: An attempt at reworking APT's interface

53 points by yankcrime 1y ago

ivolimmen 1y ago
This is a nice and fast interface. I normally use synaptic as I dislike the common 'Software' but this is a really nice command line interface.
- bayindirh 1y ago
  There's always aptitude if you want a more powerful interface, too. aptitude can also handle extended states (autoinstall, manual overrides, holds, etc.) and can be used as a apt replacement (aptitude update). Also, aptitude can provide alternative solutions to harder package migration scenarios, showing all resolutions on a nice TUI. Wish the developers compared it with aptitude too, because I see no comparison there.
  - ivolimmen 1y ago
    Yeah I know of it's existence but I always forgot how the interface in aptitude works. It is not intuitive for me. I prefer apt for command line. 99% of the time I mostly use 'apt install x' and that is it. Changing a package to a specific version and other really niche stuff I will use synapic for. With this tool I can actually search and install and that is really nice. When I do not know the name of a package I needed to switch from command line to synapic as I do not know all commands to do so from the command line and that breaks my flow. One should not need to know all different options by heart of package manager on the command line, and with this I do not need to.
    - bayindirh 1y ago
      Note: This is not to discount oma of what it does, but to shed some light to how aptitude thinks about its workflow. > I always forgot how the interface in aptitude works. It is not intuitive for me. That's a fair criticism of aptitude, but let me give you a couple of hints, not to change your mind but to give some insights, how to use aptitude, if you prefer. First, aptitude is mouse aware. You can just click around. Packages, top menu, everything. To close menus you can you can press <ESC>. Alternatively you can press <CTRL> + T to toggle the menu and navigate with arrows. Management of packages with keyboard shortcuts is like this: + : Add / Install - : Remove _ : Purge = : Hold M : Mark auto m : Mark manual Makes sense if you ask me. Upgrading is equally straightforward. "u" for upgrading package lists and "U" for marking every upgradeable package to upgrade. I think of "g", which aptitude uses as "Next >" button, as (g)o. The solution of conflicts of other things also intuitive from my PoV. e for examine, "." for next, "," for previous, "!" for apply/force (think as "do as I say switch" in vi/vim). The only shortcoming of aptitude can be told as not searching package descriptions from the search interface, which can be opened with "/", which is search in almost any other CLI tool in Linux. Also, this search interface accepts regular expressions to match parts of the package names. Lastly, both apt and aptitude has bash completion for everything from switches to package names. apt(itude) can accept pretty convoluted command line switches, but I rarely use them, if ever. So yeah, this is how I think of and operate with apt(itude), hope it sheds some more light into these tools. Again, this is not to discount oma or change your mind, but a little cheat sheet. P.S.: aptitude has minesweeper built-in, because we used to use this thing on dial-up era, and waiting for packages was boring. A couple of rounds of it always brings some joy to late night waits.
      - ivolimmen 11mo ago
        Thanks for the info, I never knew it used mouse as well.
- mingcongbai 1y ago
  As a hint - there's a TUI interface to oma, just run `oma' without any parameter!
self_awareness 1y ago
for fuzzy package search we can run `apt-cache search keyword | fzy` (fzy is a fuzzy pager). it of course works with Arch pacman -Ss, Gentoo qsearch, etc.
imiric 1y ago
This looks nice, thanks for sharing. Though IMO the main issues with APT/dpkg are not related to their UI. It is their decades-old internals, and very limited support for transactional/atomic upgrades and rollbacks. Upgrading an APT system is the same launch-and-pray operation as on most Linux systems. I see that oma has an `undo` command, which is great, but I wonder how reliable that is in practice. I think that every modern OS should support safe upgrades and rollbacks. Nix and Guix are obviously built from the ground up with this in mind, but they both leave a lot to be desired as far as UX goes. Nix more so than Guix. It is these package managers that would benefit the most from a good UI/UX polish. So for a new OS/distro, I would start with a package manager with solid fundamentals, and work on refining their UI/UX, rather than do the same for one with fundamental issues such as APT. BTW, I was interested in learning more about AOSC, but the main site is in Chinese with no English translation, so I guess it's not meant for global use.
- happymellon 1y ago
  https://wiki.aosc.io/aosc-os/is-aosc-os-right-for-me/ https://wiki.aosc.io/aosc-os/is-aosc-os-right-for-me/ I see both English and Chinese languages in their wiki.
- contrarian1234 1y ago
  That's like someone gives you a nicer car and you say "yeah but it doesn't fly". Having a better UI for APT is a separate goal from.. making the next package manager? or improving Nix? The reality is that Ubuntu LTS (and APT by extension) is pretty much the standard OS of Linux. Even if there are better solutions, that's sort of irrelevant. And APT users could use a better UI
  - imiric 1y ago
    > That's like someone gives you a nicer car and you say "yeah but it doesn't fly". No, not really. It's like someone giving you a car that looks like a Ferrari, but has the internals of a Fiat. To be fair, I'm not discrediting this project. I think it's great that someone is thinking about these things. I'm just saying that I would've started with a project with solid internals, rather than put lipstick on a pig.
contrarian1234 1y ago
Can someone involved with packaging help me understand why dependency management and system configuration are integrated and not separate things entirely? For instance, if I "install" LXQT on Ubuntu LTS, it's going to not only install all the dependency libraries (and the dependencies' dependencies) as well as all the relevant executables.. but it's also going to go around and change a bunch of configurations so that when I boot LXQT boots instead of whatever I used before. Why would it not make sense to have installing libraries/executables and their dependencies be decoupled from all the twiddling config files and setting up the spiderweb of userland processes?
- b112 1y ago
  This isn't true. debconf plus update-alternatives plus display manager login menus means configs are sticky. There are rare exceptions, but unless Ubuntu is very strange, deviating fron Debian significantly (and stupidly), what you're saying doesn't happen. And it is separate. The package manager is calling update alternatives. It's not some ad hock wild west. You're either asked, or alternatively no change is made.
- bayindirh 1y ago
  > it's also going to go around and change a bunch of configurations so that when I boot LXQT boots instead of whatever I used before. This because you left the alternative in "auto" mode, or the installed package called update-alternatives and changed the config forcibly. Debian doesn't change alternatives during package installations without consulting to you if there's a TTY attached. Installing vim doesn't change "editor" to vim, or installing most doesn't change "pager" to most (unless the configs are in auto mode and the package you installed has a higher priority on that alternative list). Also, when working with apt(itude), the changes are visibly done, saying that "update-alternatives: x has changed to new_program (auto)" or something similar. So nothing is hidden from you, and why apt has a rolling log so you can review things even after it's completed.
- everforward 1y ago
  It's mostly about user intent. If you install the LXQT binaries on Ubuntu, you probably intend to use LXQT as your DE. It makes sense to set that up for you. There's also an accessibility aspect. Novice users are likely to struggle with setting up the configs, so auto-configuring the packages makes them more accessible to novices. Wanting to install a package without configuring it is a poweruser kind of request; it makes sense to require poweruser knowledge to get a poweruser install, rather than making poweruser-style installs the default. Fwiw, I believe most package managers can be told to not run their configuration steps if you really want that.
majorbugger 1y ago
I'm really disappointed that it's yet another tool that requires "curl into bash" to install, even when you're building from source.
- mingcongbai 1y ago
  I mean, it's not required per se, it's right there in a repository... the script configures the repository and installs oma afterwards (there are system dependencies). https://repo.aosc.io/oma/ https://repo.aosc.io/oma/ Out of curiosity, how - by your preference - should this be done so that it's easier for the user?
  - TheDauthi 1y ago
    Not the original person, but I'd like to see the ACTUAL install instructions, a la the vscode via the microsoft repository. It's a little more work for the user, but, honestly, the user is using a CLI for managing packages - I think three lines that show clearly what's going on is reasonable. something like: curl -fsSL https://repo.aosc.io/pubkeys/repo/oma.gpg | sudo gpg --dearmor -o /usr/share/keyrings/oma.gpg echo "deb [signed-by=/usr/share/keyrings/oma.gpg] https://repo.aosc.io/oma $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/oma.list > /dev/null sudo apt update && sudo apt install -y oma Just showing me what it's gonna do and giving me the clear option to do that instead of curl | bash would make me feel better. Microsoft also has a "download deb and install", which I still consider slightly better than curl | bash; it's basically the windows install flow. People who are using a GUI can just double click it, people who want to see what it's going to do can examine it, and your (unsafe) one-liner is `curl XXX.deb && dpkg -i XXX.deb`. Plus it can be shipped to a multiple machines at once easily. And hey, you already know they have dpkg. (edited: mangled my command spacing a bit)

53 points by yankcrime 1y ago

This is a nice and fast interface. I normally use synaptic as I dislike the common 'Software' but this is a really nice command line interface.

bayindirh 1y ago
There's always aptitude if you want a more powerful interface, too. aptitude can also handle extended states (autoinstall, manual overrides, holds, etc.) and can be used as a apt replacement (aptitude update). Also, aptitude can provide alternative solutions to harder package migration scenarios, showing all resolutions on a nice TUI. Wish the developers compared it with aptitude too, because I see no comparison there.
- ivolimmen 1y ago
  Yeah I know of it's existence but I always forgot how the interface in aptitude works. It is not intuitive for me. I prefer apt for command line. 99% of the time I mostly use 'apt install x' and that is it. Changing a package to a specific version and other really niche stuff I will use synapic for. With this tool I can actually search and install and that is really nice. When I do not know the name of a package I needed to switch from command line to synapic as I do not know all commands to do so from the command line and that breaks my flow. One should not need to know all different options by heart of package manager on the command line, and with this I do not need to.
  - bayindirh 1y ago
    Note: This is not to discount oma of what it does, but to shed some light to how aptitude thinks about its workflow. > I always forgot how the interface in aptitude works. It is not intuitive for me. That's a fair criticism of aptitude, but let me give you a couple of hints, not to change your mind but to give some insights, how to use aptitude, if you prefer. First, aptitude is mouse aware. You can just click around. Packages, top menu, everything. To close menus you can you can press <ESC>. Alternatively you can press <CTRL> + T to toggle the menu and navigate with arrows. Management of packages with keyboard shortcuts is like this: + : Add / Install - : Remove _ : Purge = : Hold M : Mark auto m : Mark manual Makes sense if you ask me. Upgrading is equally straightforward. "u" for upgrading package lists and "U" for marking every upgradeable package to upgrade. I think of "g", which aptitude uses as "Next >" button, as (g)o. The solution of conflicts of other things also intuitive from my PoV. e for examine, "." for next, "," for previous, "!" for apply/force (think as "do as I say switch" in vi/vim). The only shortcoming of aptitude can be told as not searching package descriptions from the search interface, which can be opened with "/", which is search in almost any other CLI tool in Linux. Also, this search interface accepts regular expressions to match parts of the package names. Lastly, both apt and aptitude has bash completion for everything from switches to package names. apt(itude) can accept pretty convoluted command line switches, but I rarely use them, if ever. So yeah, this is how I think of and operate with apt(itude), hope it sheds some more light into these tools. Again, this is not to discount oma or change your mind, but a little cheat sheet. P.S.: aptitude has minesweeper built-in, because we used to use this thing on dial-up era, and waiting for packages was boring. A couple of rounds of it always brings some joy to late night waits.
    - ivolimmen 11mo ago
      Thanks for the info, I never knew it used mouse as well.
mingcongbai 1y ago
As a hint - there's a TUI interface to oma, just run `oma' without any parameter!

self_awareness 1y ago

for fuzzy package search we can run `apt-cache search keyword | fzy` (fzy is a fuzzy pager). it of course works with Arch pacman -Ss, Gentoo qsearch, etc.

imiric 1y ago

This looks nice, thanks for sharing. Though IMO the main issues with APT/dpkg are not related to their UI. It is their decades-old internals, and very limited support for transactional/atomic upgrades and rollbacks. Upgrading an APT system is the same launch-and-pray operation as on most Linux systems. I see that oma has an `undo` command, which is great, but I wonder how reliable that is in practice. I think that every modern OS should support safe upgrades and rollbacks. Nix and Guix are obviously built from the ground up with this in mind, but they both leave a lot to be desired as far as UX goes. Nix more so than Guix. It is these package managers that would benefit the most from a good UI/UX polish. So for a new OS/distro, I would start with a package manager with solid fundamentals, and work on refining their UI/UX, rather than do the same for one with fundamental issues such as APT. BTW, I was interested in learning more about AOSC, but the main site is in Chinese with no English translation, so I guess it's not meant for global use.

happymellon 1y ago
https://wiki.aosc.io/aosc-os/is-aosc-os-right-for-me/ https://wiki.aosc.io/aosc-os/is-aosc-os-right-for-me/ I see both English and Chinese languages in their wiki.
contrarian1234 1y ago
That's like someone gives you a nicer car and you say "yeah but it doesn't fly". Having a better UI for APT is a separate goal from.. making the next package manager? or improving Nix? The reality is that Ubuntu LTS (and APT by extension) is pretty much the standard OS of Linux. Even if there are better solutions, that's sort of irrelevant. And APT users could use a better UI
- imiric 1y ago
  > That's like someone gives you a nicer car and you say "yeah but it doesn't fly". No, not really. It's like someone giving you a car that looks like a Ferrari, but has the internals of a Fiat. To be fair, I'm not discrediting this project. I think it's great that someone is thinking about these things. I'm just saying that I would've started with a project with solid internals, rather than put lipstick on a pig.

contrarian1234 1y ago

Can someone involved with packaging help me understand why dependency management and system configuration are integrated and not separate things entirely? For instance, if I "install" LXQT on Ubuntu LTS, it's going to not only install all the dependency libraries (and the dependencies' dependencies) as well as all the relevant executables.. but it's also going to go around and change a bunch of configurations so that when I boot LXQT boots instead of whatever I used before. Why would it not make sense to have installing libraries/executables and their dependencies be decoupled from all the twiddling config files and setting up the spiderweb of userland processes?

b112 1y ago
This isn't true. debconf plus update-alternatives plus display manager login menus means configs are sticky. There are rare exceptions, but unless Ubuntu is very strange, deviating fron Debian significantly (and stupidly), what you're saying doesn't happen. And it is separate. The package manager is calling update alternatives. It's not some ad hock wild west. You're either asked, or alternatively no change is made.
bayindirh 1y ago
> it's also going to go around and change a bunch of configurations so that when I boot LXQT boots instead of whatever I used before. This because you left the alternative in "auto" mode, or the installed package called update-alternatives and changed the config forcibly. Debian doesn't change alternatives during package installations without consulting to you if there's a TTY attached. Installing vim doesn't change "editor" to vim, or installing most doesn't change "pager" to most (unless the configs are in auto mode and the package you installed has a higher priority on that alternative list). Also, when working with apt(itude), the changes are visibly done, saying that "update-alternatives: x has changed to new_program (auto)" or something similar. So nothing is hidden from you, and why apt has a rolling log so you can review things even after it's completed.
everforward 1y ago
It's mostly about user intent. If you install the LXQT binaries on Ubuntu, you probably intend to use LXQT as your DE. It makes sense to set that up for you. There's also an accessibility aspect. Novice users are likely to struggle with setting up the configs, so auto-configuring the packages makes them more accessible to novices. Wanting to install a package without configuring it is a poweruser kind of request; it makes sense to require poweruser knowledge to get a poweruser install, rather than making poweruser-style installs the default. Fwiw, I believe most package managers can be told to not run their configuration steps if you really want that.

majorbugger 1y ago

I'm really disappointed that it's yet another tool that requires "curl into bash" to install, even when you're building from source.

mingcongbai 1y ago
I mean, it's not required per se, it's right there in a repository... the script configures the repository and installs oma afterwards (there are system dependencies). https://repo.aosc.io/oma/ https://repo.aosc.io/oma/ Out of curiosity, how - by your preference - should this be done so that it's easier for the user?
- TheDauthi 1y ago
  Not the original person, but I'd like to see the ACTUAL install instructions, a la the vscode via the microsoft repository. It's a little more work for the user, but, honestly, the user is using a CLI for managing packages - I think three lines that show clearly what's going on is reasonable. something like: curl -fsSL https://repo.aosc.io/pubkeys/repo/oma.gpg | sudo gpg --dearmor -o /usr/share/keyrings/oma.gpg echo "deb [signed-by=/usr/share/keyrings/oma.gpg] https://repo.aosc.io/oma $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/oma.list > /dev/null sudo apt update && sudo apt install -y oma Just showing me what it's gonna do and giving me the clear option to do that instead of curl | bash would make me feel better. Microsoft also has a "download deb and install", which I still consider slightly better than curl | bash; it's basically the windows install flow. People who are using a GUI can just double click it, people who want to see what it's going to do can examine it, and your (unsafe) one-liner is `curl XXX.deb && dpkg -i XXX.deb`. Plus it can be shipped to a multiple machines at once easily. And hey, you already know they have dpkg. (edited: mangled my command spacing a bit)