Why don't you guys like synaptic?

[Lamar Owen]

Seth Vidal Wrote:
> On Thu, 2004-11-11 at 09:49 -0700, Kim Lux wrote:
>> That was my point: synaptic and apt use rpms.  So if I've got a
>> dependency issue with apt and synaptic, I'll be having a dependency
>> issue with rpms as well.  I'd much, much rather use synaptic to take
>> care of those issues than doing it manually with rpms.

> I understand it is not graphical (yet) but you do know that yum exists,
> right?

> yum install nameofpackage

> it will download and install all the dependencies you need, too.

I have used both apt-get for RPM and yum, and I have used both yumi (aka
CoBind Manager) and synaptic.  From a professional's point of view,
synaptic/apt is superior in a number of ways:

1.) Header downloads are faster.  I have timed the difference, using the
same machine/OS, between a fresh 'yum update' run and an 'apt-get update
&& apt-get dist-upgrade' run.  The apt run consistently finishes in a
subtantially shorter amount of time, set up to use the same mirrors as the
yum run.  The yum run got bogged down in the header downloads. The
difference in time was not small; I included DAG's RHEL3 repo in this
instance, and, from a scratch WBEL3 respin1 install in both cases, the apt
run took nearly two HOURS less time than the yum run.  Downloading the
headers from DAG took an hour and a half for yum, and less than five
minutes for apt.  This is on a T1 with a normally low-latency connection
to MAE-East;  congestion on the local pipe, according to mrtg, was similar
during both runs.  The machine on which this was running is a Dell
PowerEdge 1750 (2.8GHz Xeon, 1GB RAM, 3x36GB 10kRPM U320 drives on a PERC4
RAID controller; machine performance is not an issue).  I have duplicated
the results for the yum run from home, where I have a DSL connection.  I
have duplicated the time lag about four times at this point, and a
WBEL3r1->fully updated, KDE-Redhatted and DAGified WBEL3 takes
approximately three hours to complete.  I did virtually the same thing
with Scientific Linux and went for SL303->KDE-Redhatted and DAGified SL in
about an hour (downloading all the packages is close to an hour on my
DSL).  So it wasn't just a glitch in DAG's bandwidth.

2.) apt-get install and apt-get upgrade both run from the cache; thus,
multiple install runs don't need to refresh the cache each and every run.
Yum, OTOH, requires the specific use of -C to do this.  Otherwise, each
and every yum operation has to go out to the mirrors, refresh the header
info, and might have to pull down new headers.  Apt seems much faster in
this regard.  However, you do need to remember to apt-get update when
needed, which might be considered a bad thing.

3.)Synaptic is not just head and shoulders better (from a user's point of
view) than yumi currently, it is head, shoulders, torso, and legs better. 
Synaptic allows real package management, including seeing where your space
hogs are in a very easy manner (sorting by size).  I found yumi to be
usable, but just barely so.  The system-config-packages isn't even in the
same league, since there is little to no documentation or configurability
in use of third-party repos and individual package management (at least
the last time I used it this was the case, but that has admittedly been a
while).  If some of synaptic's features can be added to yumi, yumi might
be competitive.  But the startup lag is so long and slow in non-local repo
cases, that synaptic is just simply more of a joy to use because it feels
more responsive.  Now, synaptic has its own startup lag, but it is
typically not as long as yumi's. Synaptic's ability to see into the
package dependencies and dependents allows the user to remove packages if
necessary in an intelligent manner.

Both systems have dependency issues, and a yum repository is easier to set
up and maintain.  However, apt's configurability allows arcane command
line parameters to at least troubleshoot the why of the problems.  Yum's
configurability is less stellar.  I understand yum is intended to be
simple, and for keeping a system up-to-date is is an excellent tool,
paritcularly with a local repository where the latency issues of setting
up a http GET for each and every header doesn't come into as much play as
when you are accessing repositories halfway around the world (where it
doesn't matter how fast the pipe is: TCP's windowing protocol limits your
throughput regardless, and setting up the three-way handshake consumes
significant time).

In high-latency situations (which, if you are using, say, Scientific Linux
and pulling packages from the KDE-redhat project, DAG's RHEL3 repository
(in .be-land), and SL's own repository, is significant) yum loses to apt
by simple network protocol metrics; apt downloads its large files (which
benefit from TCP's window size increase algorithm) more quickly than yum
can download its smaller files.  Even if there have been few changes in
the repository, I have found that an 'apt-get update && apt-get upgrade'
sequence will have asked the user's confirmation and started downloading
packages before a 'yum update' gets to the point of asking the user's
confirmation.  That is my experience here over a significant period of
time.

I tend to use both tools; yum for automatic updates, and synaptic for
installing packages, or just seeing what new packages are out there
(yumi's interface for installing new packages is not as easy to use as
synaptic's: with synaptic, I can right click the package, select
properties, and see at a glance what sort of dependencies a package has,
see a description, etc).

YMMV.  And Seth, YUM does work, and it works well for its designed purpose
(an updater).  I use yum here with a local repository for Aurora Tangerine
(SPARCLinux for those not familiar with it) since I have a 20 node Ultra30
cluster (well, not exactly a cluster, but close) running Tangerine.  It
behooves me to have a local repo in this case, and yum loses less in that
instance.  Note that these U30's only have 248MHz CPU's, 128MB RAM, and
4GB drives.  Yum is faster on these boxes with a local (on the LAN) repo
than it is on the Dell 1750 with non-local repos, showing that it seems to
be network-bound performance-wise.  Or, if you have space for it, a local
rsync'd repo is a BIG WIN for yum performance.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu