Re: [PLUG] Linux and package managers/repos

[JP Vossen <jp@jpsdomain.org>]

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


> Date: Tue, 22 Mar 2011 16:28:18 -0400
> From: bergman@merctech.com
> Subject: Re: [PLUG] Linux and package managers/repos
>
> 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.

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.


> 	[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 like Matt's citation later in the thread, and I had forgotten that 
WindowsUpdate was backported into Win95 using IE4 (late 1997 per 
http://en.wikipedia.org/wiki/Internet_Explorer_4).

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.

http://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified
http://en.wikipedia.org/wiki/RPM_Package_Manager
http://en.wikipedia.org/wiki/Advanced_Packaging_Tool
http://en.wikipedia.org/wiki/Deb_%28file_format%29


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

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:
http://en.wikipedia.org/wiki/Red_Hat_Network


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

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.


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

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: http://www.google.com/search?q=%22too+many+choices%22


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

http://www.debian.org/doc/devel-manuals

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

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...
>
> Hmmm...so the programs change with the distro & version...but that's not
> counted as a negative....compared to, for example
> "windowsupdate.microsoft.com"?

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.

Later,
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"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         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug