Oma: An attempt at reworking APT's interface
1–10 of 26 posts
Re: Oma: An attempt at reworking APT's interface
#2This 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.
Re: Oma: An attempt at reworking APT's interface
#3This 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.
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.
Re: Oma: An attempt at reworking APT's interface
#4This 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.
As a hint - there's a TUI interface to oma, just run `oma' without any parameter!
Re: Oma: An attempt at reworking APT's interface
#5for 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.
Re: Oma: An attempt at reworking APT's interface
#6This 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.
Re: Oma: An attempt at reworking APT's interface
#7This 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 ev…
https://wiki.aosc.io/aosc-os/is-aosc-os-right-for-me/
I see both English and Chinese languages in their wiki.
Re: Oma: An attempt at reworking APT's interface
#8This 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 ev…
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
Re: Oma: An attempt at reworking APT's interface
#9Can 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?
Re: Oma: An attempt at reworking APT's interface
#10Can 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…
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.