JP Vossen on 24 Mar 2011 01:47:42 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Linux and package managers/repos

Sorry about the latency on my reply, I'm kinda swamped...

Date: Tue, 22 Mar 2011 16:28:18 -0400
Subject: Re: [PLUG] Linux and package managers/repos

The pithy ruminations from JP Vossen <> on "[PLUG] Linux and pa
ckage managers/repos" were:

=> Well, it actually does get a lot of press, but under a different name
=> and in a different context.  The one that gets press is called an "app
=> store," but Linux has had that since Debian (at least, possibly longer?)
=> except it's called a "repository" and it's full of free (as in no cost
=> and freedom) software.

Repositories aren't necessarily full of "free" software...there's
nothing intrinsic about the technical concept of the repository (or an
"app store") that has any implication about the cost or freedom of
the products. There are repositories for closed-source (proprietary)
software that are free in cost, and every flavor in-between.

You're right, and other folks pointed that out later too. I don't even only use the "free" repos myself, so I can't even claim to be ideologically pure. :-) I should have said something more like that the default repos are mostly "free" but that other options exist.


=> To update Windows you use WindowsUpdate, which was tacked on at the 11th
=> hour because no one updated anything and thus left gaping holes

Citation, please.

I like Matt's citation later in the thread, and I had forgotten that WindowsUpdate was backported into Win95 using IE4 (late 1997 per

But overall you got me, I'd have sworn Debian had APT and repos longer than they did. I plead being a Red Hat user until 2002 or so... (Well, Slackware via Walnut Creek CDs for a while, then RH4.0 - RH9.)

I'm most familiar with RPM-based distributions, but the "repository"
concept (particularly "yum" as opposed to the proprietary RHN) came
pretty late in the hi story of using RPMs to package the files used in a
distribution. A quick search seems to show that "yum" appeared in about
2005, as a successor to "yup" (c. 2001), well after the RPM format was
determined (c. 1998)[1].

Yum is a wrapper around the lower-level RPM tools and did come to the partly later (from Yellow Dog Linux, as a solution to "RPM dependency hell"). APT (circa 1998/1999) is a wrapper around dpkg, but is older than yum.,_Modified


=> On the other hand, since not too long after the dawn of Linux, this has

Um, how do you define "dawn of Linux" or "distribution"? I began with
slackware, with a version number in the 0.9x range. The "distribution"
was little more than a bunch of tar files and "Make".

Ouch, ask a hard one why don't you?!? Well, the dawn of Linux is 1992/1993 or so when Linus released it. A distribution is a Linux kernel, some drivers for some hardware, and some userland packages all rolled up in some way that in theory makes it easier to install and use. But you already know that... :-)

RedHat was a big improvement because of RHN, but that certainly didn't mean
> it was a very robust or open package manager.

Ugh, I hated RHN.  I like yum a lot better.  And RHN is circa 2001:

=> been baked in to the very core of what a "distribution" is.  And as long

What is the "core" of a distribution? You seem to be conflating the concepts of
 3rd party products, the package management interface, and a lot of anti-Window
s bias.

I mean the core purpose of a distro, not the guts or stuff that's included. To me, the core purpose of a distro is to facilitate ease of use for some purpose. Making software easier to install & use certainly falls into that. I already noted above that I was thinking "repos" were older than they are though...

=> as you stay inside the package manager, 'sudo aptitude update && sudo
=> aptitude full-upgrade' updates *everything* on the system...bang...done.

Usually. Unless (as happened to me last night), "apt-get upgrade" breaks
because the Nvidia driver (a piece of "not free as in freedom" software,
from it's own repository, but available through the same interface as
the other free & non-free software on the machine) didn't get upgraded
to match the new kernel.

Or, on some of my servers, when the same kind of issue happens with
the Qlogic drivers (proprietary, free-of-charge, available from 3rd
party repositories via the same "yum" interface used to manage other

Matt already hit that one too. If you stick with the official repos, it should all work. Go third-party and at least some bets are off. And I understand that sometimes you have no choice if you want the hardware to work...

=>   (Or 'yum upgrade' for Red Hat-ish or 'emerge world' (Rich, right?) for
=> Gentoo.)
=> So what does "stay inside the package manager" mean?  It means that you
=> don't install stuff from source (except Gentoo, but that *is* the
=> package manager :), you install from the repo.  OK, but what if you need

What "repo"...there are many repositories...some free-as-in-beer,
some free-as-in-speech, some neither.

OK, true, I meant the default repos.

The fact that a single interface
(apt-get, or yum, or emerge) can reference multiple repositories is
a tremendous convenience vrs. the WindowsUpdate interface, but it's
not fundamentally different than using a single Windows product (SCCM,
for example) to manage updates that are distributed from multiple sources.

There, I disagree. Microsoft doesn't get access to the source code to tweak the upstream (third-party) software it is re-distributing. That may be seen as a pro or a con, but it's a fundamental difference.

But I wasn't even thinking of that, I was thinking more about how pretty much anything a "typical" user could ask for is either already installed right out of the box, or is just waiting in the repos to be clicked on. And most of what is chosen to be in there is chosen for reasons other than "the vendor paid a bucket of money" to be a) included and/.or b) ranked near the top as a "featured" whatever.


=> So, todays example.  I got an email at work discussion a non-intuitive
=> customer name issue, and I thought I'd be funny and try to do an anagram
=> of it.  But the name was 19 characters, which is too long for the

Here's a good challenge...perfect for someone who enjoys shell scripting:

	Assuminng the presence of /usr/dict/words, do the anagram search
	using only "standard" shell tools (bash, sed, grep, awk, sort, wc,
	etc.) [note the absence of perl, python, ruby, etc.].

That would be a good one!  I don't have the time for it, but I like it.

=> web-based anagram engines.  So in literally 10 minutes (read the
=> timestamps) I:

I love the example!

=> 	1) Searched for apps to solve my problem
=> 	2) installed one, took a few minutes to realize didn't like it
=> 	3) installed the other, took a few minutes to use it
=> 	4) purged the one I didn't like, and am sure it's really gone
=> How long would a search for a similar tool take for Windows?  You have
=> to Google it, read various descriptions scattered all over the web,

Huh? If I was doing this on any platform, I'd still do some research
(google, reading package descriptions available through the package
manager, etc.) before blindly installing software. You're citing a false
distinction between the Windows and Linux.

Not for me. Maybe different work-flows as Matt noted. But I did read the descriptions, I even included them in the session log. I love how new apps to do almost anything are just there, at your fingertips.

=> choose from possibly hundreds of analysis-paralysis-inducing choices,

You seem to be arguing that having just 2 choices for a solution is better than
hundreds... Maybe, but someone could make just the opposite case.

I like choice as much as the next person, that's a big part of why I use and prefer open source software. But in a case like my example, I don't want to spend a lot of effort, I want to get the job done. Having someone else narrow down the choices to stuff that will at lest *probably* work is a big value to me.

See also:

=> download it, hope it's not malware, figure out how to install it, try

Um, how do you know that the thing you just installed on your Linux system
> isn't malware?

Because I trust the structured or organized entity that is Debian or Canonical/Ubuntu Devs a **HELL** of a lot more than I trust the chaos of the Internet. And I trust that if something bad snuck in, someone will find it pretty quick and fix it. And that there is a process to fix it that does not involve trying to get some law enforcement agency in another country to shut down a random web site offering Trojans.

How does the issue of "figuring out how to use an application" enter into
the discussion about repositories & package managers, other than as a red
herring which indicates your bias for or against a particular environment?

I said figure out how to install it, not use it. It might be an EXE, or an MSI, or a ZIP, or a RAR (gulp), or maybe even something else. Not a huge deal, and double-click-n-pray usually works. But still it's an extra step.

=> it, then figure out if it will cleanly uninstall (probably not).  Not
=> for me...

Again, this is a false distinction...the package management interface provides
little assurance that something will cleanly uninstall.

Nope, Debian has really good policies and tools there and Ubuntu has inherited them. Those policies are arguably why APT-based systems generally support major-version upgrades while RPM-based systems generally recommend clean re-installs. It's not the technology, that's not that different anymore. It's the developer philosophies and policies and mentoring.

Having said that, some of it *is* the technology, since the package system knows what files and dirs it installed and it can remove them. That does not cover cases where the program creates new files or dirs unilaterally, but it's still better than the old Windows, sure stick DLLs anywhere method. And yes, they've gotten a lot better about that, since XP or so...

Ironically, I'd actually argue that Windows is better at managing packages that
> do not come from Windows. If you want to install a Linux package that isn't
> packaged for your distro, you've got a few choices:

[A]	install the native version (ie., from source or the binary that came with the package). If you're
	very luck, and you keep the Makefile for ever, there might be an uninstaller.

[B]	repackage the native version in your own distro's packaging format (this is a path to madness for
	most people...and still says little about a clean uninstall)

[C]	use a tool like checkinstall[2] to do the above task [B]. Much easier, but it still doesn't do much
	for the uninstall beyond removing files (ie., no reversal of any system files that were changed,

OK, interesting point. That's part of why I argue to stay inside the package system. And almost anything you want is already in there. But... When it isn't, it does get ugly. Very often someone else has already done that work in a PPAs or sometimes just a plain old *.deb, but yeah, worst case it gets ugly fast.

But I really like Matt and Brent's answers there too.

In Windows, most installed packages--wether from the Windows distribution or not--show up in the"Add & Remove" control panel (ick...) and there's at least a place to
try to begin the removal.

"Try" being the keyword. Everyone knows how Windows slows down over time, until you eventually have to do a clean reinstall. (I know, you're going to ding me for a citation again. It's getting too late and I need to wrap this up. :)

=> Notes:
=> * I prefer the command line.  There are various GUI tools that do all of
=> this too.  The names change based on distro and version of distro.  Poke
=> around... the programs change with the distro & version...but that's not
counted as a negative....compared to, for example

Yeah, got me there, that does bug me.

By the way, I firmly agree with your preference for Linux (and it's package
managers) over Windows. My issue here is with the specious reasoning & examples.

I don't think I was as bad as all that, but you certainly did have some points.

Anyway, thanks for stimulating my brain, and thanks to Matt, Brent and Rich (sorry if I'm missing someone) for their follow-up as well.

JP Vossen, CISSP            |:::======|
My Account, My Opinions     |=========|
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --