It also usually seems to be slower to start (at least in my experience) -- I tend to not like to use it except for resolving broken packages (since it's the nicest way to do that).
The latest version in Debian unstable (0.7.7) seems to have brought some improvements in startup time. Generally the recent progress has been very nice.
I've never understood why debian insists on having these be different commands. It would make sense if install, search, upgrade and uninstall were all discrete, but the way it is today feels half implemented.
Same. Having to search for what you wanted to install via apt-cache, but then actually install it via apt-get, was a triumph of some unexplainable factor over usability.
I want to say it has to do with keeping each "idea" as a separate program, but the fact that apt-get can install, uninstall, list packages, etc. seems to go against that idea
Only one of them requires readwrite system administrator privileges (eg sudo). apt-cache can be run by any user as it doesn't expose any secret data and can't be used to make changes. apt-get can install and uninstall software as well as download packages and thus needs root privileges in the classic UNIX model.
apt-get doesn't fail when run as non-root, it only fails when you run it as non-root when you try to some of the commands that require root privileges (such as installing system level packages). It has lots of commands that don't need root privileges. I don't see much reason why "list all the packages available for installation", as well as the other commands in apt-cache, aren't included in that list.
"The primary command line tool is aptitude. apt-get fulfills a similar purpose and although it is no longer the recommended primary tool some still use it."
If you prefer the apt-* commands: "You can also use Wajig, for an unified and more logical command-line interface to all package management functions." (Apparently, apt is the new Wajig, except that apt doesn't automagically sudo, which Wajig did.)
"The upgrade process for some previous releases recommended the use of aptitude for the upgrade. This tool is not recommended for upgrades from wheezy to jessie."
Debian's zigzagging between package management frontends (dselect, apt-*, aptitude, dpkg, now apt?, … all in use in parallel) is incredibly frustrating. Pacman e.g. is so much easier to use because everything's in one well-structured command.
It probably reflects the classic problem of developer turnover in OSS projects and the resulting approach to technical debt. Old developers fade away, young guns come through (often still in academia), "this code is all crap, let's chuck it out and build something better, how hard can it be?"...
1. "Just use $newtool" has been Debian's spiel for every past release, and every time it's a different one.
2. Why full-upgrade and not dist-upgrade like in all the other debian package managers? Would that little bit of internal consistency really have hurt?
I don't know what you mean. dselect is like 2000 era, and was replaced by "aptitude" at least 15 years ago. "apt" has been around since the beginning and still works just fine. The fact that "aptitude" has some overlap with "apt" is a detail--its real strength is that its curses ui (which was a massive improvement over dselect).
Is this installed by default on Debian? If not, then this is a deal-breaker for me. I might as well install aptitude which also provides a similar command line interface.
There's another thing about apt that's bothered me: apt-cache search isn't a very good search engine. Its most common use case is finding the exact name of some library/framework package, ie, "apt-cache search someframework". For common frameworks, this produces hundred of search results for packages that use the framework and mention this in their description, while the framework itself is in the list but very difficult to find. The --names-only flag fixes this, but it's not the default so it's one more thing to worry about.
Search uses regular expressions so generally no need for grep unless you need more complex filters; --names-only has the -n short-form:
apt-cache search -n <regexp>
More generally apt-get and apt-cache are designed to be backward-compatible for use in scripts whereas apt is not[0]:
SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS
The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed either if a change seems beneficial for interactive use.
I can't answer specifically for `apt`, but many commands take significantly longer if you let them display to stdout versus piping their output to a file or `/dev/null`. cf.:
$ time ls -R /usr
real 0m7.570s
user 0m0.104s
sys 0m2.286s
$ time ls -R /usr > /dev/null
real 0m0.193s
user 0m0.036s
sys 0m0.154s
(edit: when will I grok HN markup?? cough support markdown cough)
Did you run those two commands in sequence? Did you account for disk-cache effects? Try running it 4 times, alternating the versions and see what your last 2 times are ...
You can actually show different speeds in different terminals - the speed of terminal rendering affects the duration of the test. In the tests below, I have no custom terminal prompts or similar (no git status lines etc) - they're all distribution defaults running bash.
# all the below run in the same MATE desktop
# lxterm (from lxde - is easiest on my eye)
$ time ls -R /usr
real 0m19.974s
user 0m0.860s
sys 0m0.832s
# gnome terminal
$ time ls -R /usr
real 0m19.902s
user 0m0.800s
sys 0m0.776s
# xterm (yes, it really is 10x the speed)
$ time ls -R /usr
real 0m1.872s
user 0m0.856s
sys 0m0.800s
# rerun in the first terminal, and the time hasn't changed - still 19s
# now in lxterm redirecting to null
# (and xterm gives similar results here)
$ time ls -R /usr > /dev/null
real 0m0.418s
user 0m0.256s
sys 0m0.156s
All that prettification and rendering takes time; if you want raw speed, use xterm... or pipe output to /dev/null.
Interestingly, 'time' on gterm and lxterm had tabs between the above field:value pairs (I had to reformat to show them nicely), but xterm used spaces. I don't know enough about the terminal underpinnings to guess as to why.
Yes, that's a reasonable assumption. I am by no means a terminal guru, but my understanding is that, for something like a progress bar or spinner (anything that is updated in-place in the terminal), the entire "screen" is being redrawn on update.
I also suspect (though have not verified) that any output to terminal is quite a bit slower than the raw operation -- that sort of difference that we should all know, as programmers.
also don't forget apt-file (very useful to find out which package contains the library/binary you want to install) and dpkg -L to figure out what a particular package installed on your system.
I switched to debian some time ago and it's interesting so many different commands are used for package management, this said I personally have an alias ap=sudo aptitude -t jessie-backports alias and use that as a command line interface for search/install, and run the full aptitude gui only when doing updates
I love this, but its terminal magic isn't working properly for me. "apt install stuff" places a progress bar at the moment, then prints some misaligned stuff and then finally manages to clear the screen (!).
Any terminal settings I need to adjust? I'm using OS X's Terminal.app, terminal declared as xterm-256color, via SSH, under zsh.
All the update does is download the latest available updates so it should not be prompting. My experience is that only upgrade/dist-upgrade will prompt.
I've got a VM running ubuntu 16.04-beta and it seems to be fine.
Yeah, Sid is the rolling unstable. It's still slower and relatively more stable than most rolling distributions, but it's constantly changing here and there and everywhere. Using it as your main desktop machine is a recipe for trouble, especially when major changes start rolling in. The only certainty with Sid is that your disk will work a lot because of the firehose of updated packages streaming in at every hour...
76 comments
[ 3.1 ms ] story [ 110 ms ] threadI think it's similar with the pkg command on FreeBSD.
In contrast, pacman or guix are quite intuitive and feel better designed.
"The primary command line tool is aptitude. apt-get fulfills a similar purpose and although it is no longer the recommended primary tool some still use it."
If you prefer the apt-* commands: "You can also use Wajig, for an unified and more logical command-line interface to all package management functions." (Apparently, apt is the new Wajig, except that apt doesn't automagically sudo, which Wajig did.)
See https://wiki.debian.org/DebianPackageManagement
"The upgrade process for some previous releases recommended the use of aptitude for the upgrade. This tool is not recommended for upgrades from wheezy to jessie."
See https://www.debian.org/releases/stable/amd64/release-notes/c...
apt install - Install packages
apt remove - Remove packages
apt upgrade - Upgrade packages without removing
apt full-upgrade - Upgrade packages, allowing removals
apt update - Refresh sources
apt show - Show a package
apt list - List packages, you can filter by stuff like --installed or --upgradable
2. Why full-upgrade and not dist-upgrade like in all the other debian package managers? Would that little bit of internal consistency really have hurt?
3. Still does not seem to cover all use cases.
Fixed that for you.
Interestingly, 'time' on gterm and lxterm had tabs between the above field:value pairs (I had to reformat to show them nicely), but xterm used spaces. I don't know enough about the terminal underpinnings to guess as to why.
Whereas a status indicator isn't exactly pushing much data to the terminal. So, It shouldn't impact run time.
http://norvig.com/21-days.html#answers
I switched to debian some time ago and it's interesting so many different commands are used for package management, this said I personally have an alias ap=sudo aptitude -t jessie-backports alias and use that as a command line interface for search/install, and run the full aptitude gui only when doing updates
https://pypi.python.org/pypi/apt-wrapper/
No prog bar but it handles all common tasks, ppa's, and elevates with sudo automatically. For example:
Any terminal settings I need to adjust? I'm using OS X's Terminal.app, terminal declared as xterm-256color, via SSH, under zsh.
You can also set the update to happen automatically so that all you have to do is run upgrade.
> You can also set the update to happen automatically so that all you have to do is run upgrade.
I'm in "testing". Sometimes, even with "-y", I'm asked to validate some messages (often inside a vi prompt).
http://askubuntu.com/questions/3167/what-is-difference-betwe...
It cleans out unnecessary packages.
All the update does is download the latest available updates so it should not be prompting. My experience is that only upgrade/dist-upgrade will prompt.
I've got a VM running ubuntu 16.04-beta and it seems to be fine.
> My experience is that only upgrade/dist-upgrade will prompt.
Source: my previous life.
I tried it a bit but it's very (very) unstable :-)
I come from Fedora and have few months only on debian. Still a rookie.
My experience is a "non-beta" Fedora is less stable than a "testing" debian.
> ...Using it as your main desktop machine is a recipe for trouble ...
Yes! It's a nightmare especially with Gnome Shell.
I see memory corruptions for months in Gnome windows. I wonder if it's related to Wayland stuff. It often occurs in Firefox.
Interesting. My use of aptitude is limited to "search" so far.
Did you see that?
https://news.ycombinator.com/item?id=11230828