Re: [PLUG] Linux and package managers/repos

[bergman@merctech.com]

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


	[SNIP!]

=> 
=> 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.

	[SNIP!]

=> 
=> 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'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].


	[SNIP!]

=> 
=> 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".

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

=> 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.

=> 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
components).

=>   (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. 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.

	[SNIP!]

=> 
=> 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.].


=> 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.

=> 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.

=> 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?

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?

=> 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.

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,
	etc.)

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. 

=> 
=> 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...

Hmmm...so the programs change with the distro & version...but that's not
counted as a negative....compared to, for example
"windowsupdate.microsoft.com"?


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.

Mark

	[1] http://magazine.redhat.com/2007/02/08/the-story-of-rpm/

=> 
=> Later,
=> JP
=> ----------------------------|:::======|-------------------------------
=> JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
=> My Account, My Opinions     |=========|      http://www.jpsdomain.org/
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug