[sf-lug] external usb hard drive

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

[Debian testing/unstable:]
 
> How do these "goodies" compare with what's in Ubuntu: pretty much
> the same?

Um, that's a matter of perspective.  For me to answer that question
usefully, I'd need to know what aspects of comparison you care about
and are asking about.

Debian-unstable is by far the largest, broadest, coherent collection of
cutting-edge software for *ix anywhere.  It differs from, say, Mandrake
Cooker in having in general extremely reliable software contents.  Both
Mandrake Cooker and Debian-unstable are moving-target, daily-changing
collections of software as defined on Internet package mirrors.  They
are not releases.

Debian-testing is the set of software in Debian-unstable, net of an
automated quarantining script applied against arriving source packages
uploaded by maintainers, making sure they meet certain automated quality
criteria including successfully completing the process of building
binaries on multiple CPU platforms.  

In both cases, there is a non-zero chance for any given package in the
collection, at any given time, that the package has problems that eluded
the maintainer prior to upload.

Again, please see
http://linuxmafia.com/pipermail/conspire/2008-February/003877.html for 
more on the nature of Debian's various development tracks, including the
fact that Debian-stable is a _release_-based track, and the others are
not (by contrast being daily-evolving tracks).

I would speculate that the current state of Ubuntu's Hardy Heron
prerelease branch is roughly in some senses similar to today's contents
of Debian-unstable -- except that Ubuntu concentrates specifically on
GNOME-based desktop software, Kubuntu on KDE-based desktop software,
Xubuntu on XFCE4-based desktop software, and so on, while
Debian-unstable has all available software of all types.  

If you're asking what in Ubuntu/Kubuntu/Xubuntu etc. is similar in
_quality control_ to Debian, probably the current state of the Hardy
Heron prerelease is, but I cannot say that for certain, because (1) 
I have no experience with the latter, and (2) I simply don't personally
care about GNOME, KDE, or XFCE4 as coherent _desktop environments_,
regarding them simply as suite of stuff to cherry-pick for the parts I
like, while eschewing the parts I don't.

Ubuntu/Kubuntu/Xubuntu, etc. were founded by people who care deeply
about those "desktop environments" as coherent wholes, while my
perception is that the Debian Project mostly lacks that specific focus, 
as such.  Also, Ubuntu/Kubuntu/Xubuntu, etc. differs from Debian in
promoting some different underlying policies, such as pervasive use of
sudo.  I'm sure there are other miscellaneous points of difference that
I could think of and describe if I worked at it.

But, again, I'm unclear on what you're really asking, so I probably
can't give you a useful answer.


> Here's what I'm thinking:
> It isn't _that_ important for me to be able to share the drive with 
> a MSWindows based system. (It would be nice but we can easily just get
> another drive; in the end this may be what we would have done anyway.)
> The consensus seems to be that using a different file system
> (ext2 or ext3) would be the better solution.

Well, it really depends on the problem you're trying to solve, of
course.  (It's really important, when asking for help, to be clear on
what problem you're trying to address.  Otherwise, it ends up being a
waste of everyone's time.)

Certainly, ext3 is an extremely well tested, and pretty fast filesystem
for general use.


> Rick: you say "pretty sure it _did_ do exactly what you requested"
> re: aptitude update
> Based on what you've said about mixing stable with unstable/testing
> presumably I should undo what was done-
> Would a simple repeat of the same command _after_ removing or
> commenting
> out the #
> deb http://www.backports.org/debian etch-backports main contrib
> non-free
> line in /etc/apt/sources.list do the trick?

Well....

Please refresh my memory:  Did you merely fetch new catalogues after
adding unstable and/or testing lines to /etc/apt/sources.list (e.g.,
using "apt-get update"), or did you follow up that change by actually 
_fetching_ a bunch of Debian-testing or Debian-unstable packages (e.g.,
using "apt-get dist-upgrade" or "apt-get upgrade")?

If you _did_ fetch a bunch of testing/unstable-branch packages, and
install them into your system, you've probably now got, for example, a
really cutting-edge libc6 package, and so on.  The process of doing that
would have been memorable, as it probably would have fetched a couple of
hundred packages all at once -- probably creating a rather unreliable 
system that has a lot of problems.

If you _didn't_ do that, then just comment out or remove the undesired
lines from /etc/apt/sources.list, then run "apt-get update" to fetch a
new set of software catalogues, and you're back to pure Debian-stable in
all of its boringly stable and slightly quaint glory.


> Oh, and thank you for helping with the gpg advice. So much to learn...

By the way, any time someone says "Oh, you just need a crypto key to
solve that problem; get it here", you should be thinking "_Should_ I
trust that particular crypto key?"

That is, signing of packages is supposed to be a security feature, where
you have some assurance that the packages were really created by the
authorised parties who you think did them, and haven't been tampered
with.  However, this mechanism is, at best, only as good as the means of
getting the correct key into your possession.

In this case, you fetched that key because I said, "Alex, just do:
# wget http://www.backports.org/debian/archive.key"
However, are you _sure_ that's a key you should trust?  Security tends
to involve judgement, and there aren't easy answers to some questions,
but you might analyse the situation like this:

1.  The "backports.org" collection are a bunch of unofficial packages,
some by official Debian maintainers, maybe some by others.  They _seem_
to be reliable and not a fly-by-night outfit.

2.  I know that I reached the real www.backports.org host and retrieved
the real signing key _if_ and only if I can trust my local DNS and the
routers between me and there -- and if the www.backports.org host itself
hasn't been security-compromised.  (Only you can tell whether you should
trust your local DNS and routers, and to what degree.)

As always, adjust your paranoia to suit!