Slashdot Mirror

There are many good resources on the web. The standard resource is The Linux Documentation Project, or http://www.tldp.org/. Another site, which is much better than it used to be, is http://www.linux.com/. http://www.linuxjournal.com/ has many great articles to guide you through a wide variety of small projects. A great newer site with helpful articles is http://www.howtoforge.com/. For help on the desktop side, http://www.desktoplinux.com/ has many articles you may find of use. Documentation and information about KDE is, of course, available at http://www.kde.org/ and it's affiliated sites (linked from their homepage). IBM is always putting up new articles at http://www-128.ibm.com/developerworks/linux/ that can provide usefull information for development work under Linux. You may also find the articles on http://www.debian.org/, http://www.gentoo.org/, and http://www.ubuntulinux.org/ usefull even though the articles were written for other distros.

If you can't find what you're looking for there, you can always head over to irc.freenode.net. The #suse and #opensuse channels will be of particular interest to you. You may find #kde helpful for KDE applications. ##linux is basically a catch-all channel; we'll generally be able to field just about any question you throw at us there. If we can't, we will point you in the right direction.

Keeping up with the FOSS news can also teach you quite a bit. You already know about Slashdot. http://osnews.com/ is another very nice resource. http://www.kerneltrap.org/ is a less frequently updated site which can provide you with more advanced information. Keeping an eye on http://www.freshmeat.net/ can help you get a better feel for the various software available for Linux. And of course, with gmail you can setup alerts for Linux, KDE, etc.

If you really want to learn more about Linux, there's no better way than distro hopping. Go to http://www.vmware.com/ and download their free VMWare Server 1.0 to allow you to try out various distros without having to wipe your hard drive. This does, however, require you have a decent amount of RAM (I'd recommend at least 1 GB). Go to http://www.distrowatch.com/ for a fairly complete list of the available Linux distros, sorted by popularity.

If all these links really don't solve your problems, take yourself over to your best local bookstore and buy a book or two. The drawback of doing this, however, is that most of them will be pretty much out of date by the time they hit the shelves. On the other hand, they will give you a great foundation upon which you can build (update yourself) easily by utilizing the online resources.

Also, never forget about http://www.google.com/linux!

Um, Debian is HP's linux distribution of choice. HP maintains the Carrier Grade version of Sarge. which they supply to Motorola and others.

I just don't understand where this myth that you cannot get support for debian comes from. With 658 Debian consultants in 59 countries Debian seems to have more support options than most other distributions. I will admit that some of those consultants are single person outfits. But HP is also on the list.

You might want to reexamine your assumptions.

Debian has a list of consultants / commercial support people on its site.

There are other companies who will offer support too. I offer Debian support on a paid basis too, even though I prefer to point people at community resources where possible.

I agree with Erich Schubert's blog post (http://blog.drinsama.de/erich/en/2006073102-micro soft-vapourware, found via http://planet.debian.org/) that it's more vapour than some E3 "rendered in-game" footage. Citing the UWash Photo Tour (http://phototour.cs.washington.edu/) whose technology ultimately makes up PhotoSynth, the processing power required is of the scale of two weeks to place 597 of 2635 images using a 3.4 GHz P4. I doubt that too many home computers will have the grunt to do that on a reasonable time-scale before the end of the decade. I expect it will be a serviceon Microsoft Live, where you submit the pictures and use a viewer.

I really didn't have any problems with X or wifi when I recently installed Dapper.

But seeing a number of posts to the contrary I wonder if Debian's recent work on making x.org the default for Etch has anything to do with Debian based distros experiencing hiccups with X? All in all I've had very little trouble with Ubuntu since I first tried Hoary Hedgehog but then again I've only put it on slightly older boxes with pretty standard hardware. From the grumblings I'm hearing it would seem it does have some trouble with bleeding edge hardware. Then again what OS doesn't?

Anyway, with 5 years of support to depend on Ubuntu is starting to make a lot more sense for use on servers.

Thanks Mark!

Ubuntu is a sham. If I want to run a Debian OS I'll fucking run Debian, not some half-baked African operating system.

The service industry is information in, information out, and if some of that information happens to pass through internally modifified Free Software tools, does that mean you have to open up all those tools?

And what if your modification is to pull values out of your core business logic for display? Do you have to GPL your internal codebase, or just transmit source copies with embedded tags like "<? print xmlrpc.getMagicValue('internalserver'); ?>" and let the end user deal with the fact that they don't work outside of your business environment?

I think this is a really, really bad idea. Even Debian voted to reject the GNU Free Documentation License because of similar issues. I could easily imagine them deciding to also reject the GPLv3, which would mean that software under such a license would not be admitted into Debian, and therefore probably not Ubuntu or Debian's other derivatives. I just don't see where the FSF is going with this one.

Running units is faster than using Google, for some of us.

And perl is even faster than PHP in most situations - if only by a small margin.

I guess the main reason everybody uses PHP is because, well, everybody else uses PHP.

Perl just doesn't have the ease of "just drop your .php file into docroot" nor an established, ready to go
"build a website in 3h" framework like ruby-on-rails.
To get decent results with perl you need not only some intimate knowledge of the perl-language itself
but also a pretty good idea of how a webapp (or even "servlet engine") smells from
the inside because, basically, you'll be writing one from scratch.

Anyways, as I was taught recently, real men write their webapp in LUA. ;-)

http://wiki.debian.org/multiarch

The "will support" part is outdated. I have been running debian on amd64 for months. Even sarge has amd64 support.

http://www.debian.org/ports/amd64/

The only difference is, really, that amd64 is on the official main mirrors for etch (and by that, I mean it has been for months).

It runs great.

Unfortunately you can't mix 32-bit and 64-bit programs and libs, or so it seems. For example, I can't play windows codecs using a 64-bit MPlayer because Wine doesn't yet support running win32 code in a 64-bit executable/library. So you have to use a completely 32-bit MPlayer + libavcodec + libwine if you want to use the Win32 WMV or Quicktime codecs. Or at least that was the case a few months ago when I spent a few days wrestling with compiling Wine and the other libs trying to get it all to work. In the end I installed a 32-bit chroot environment and run 32-bit MPlayer from there.

If you mean mixing packages like SuSE and Fedora do, no.
If you mean create a 32bit chrooted environment in which you can run a full 32bit distro that integrates perfectly with the "main" 64bit system, yes.

Please see the Debian AMD64 Howto: https://alioth.debian.org/docman/view.php/30192/21 /debian-amd64-howto.html
And don't miss the Debian x86_64 Mailing List.

This is old news/dupe: Debian told that on their announcement about 4.0 ( http://www.debian.org/News/2006/20060724 ), to which slashdot has linked in a previous article (http://linux.slashdot.org/article.pl?sid=06/07/24 /1830228 )

http://www.debian.org/News/2005/20050811

Although Sarge (the current Debian stable) was not released with AMD64 support, it was added as an official, fully-supported architecture two months after the release -- way back in August of last year. TechWorld didn't read the recent news announcment correctly.

You're probably running Gentoo on an x86 and only worried about the Linux kernel, so the limitations of 3.4 don't affect you. Debian switched to 4.1 in part because it fixes problems with the hppa and m68k ports (and the nascent Debian ports to HURD and the FreeBSD kernel), and in part because it has new warnings pointing out code that isn't 64-bit clean.

You're probably running Gentoo on an x86 and only worried about the Linux kernel, so the limitations of 3.4 don't affect you. Debian switched to 4.1 in part because it fixes problems with the hppa and m68k ports (and the nascent Debian ports to HURD and the FreeBSD kernel), and in part because it has new warnings pointing out code that isn't 64-bit clean.

GTK 2 was present in Woody: http://packages.debian.org/oldstable/libs/libgtk2. 0-0

Multiarch is currently under development, see http://www.debian.org/News/weekly/2006/20/.
If I understand correctly, it will not be ready for etch (4.0), but the following stable release seems likely to have it.

module-assistant is a nice utility for installing (and updating) external modules e.g. wireless device drivers or nvidia drivers
http://packages.debian.org/testing/devel/module-as sistant

... with this announcement from Martin "Joey" Schulze. There was a similar announcement on debian-devel-announce (see http://release.debian.org/20060717), but it didn't contain a specific date.
In a german debian IRC-channel (#debian.de on ircnet) other DDs accused him of sending mails to debian-announce without prior consultation of the release team. German source: http://nopaste.info/877fdb503d.html
--
Moritz
http://moritz.faui2k3.org/

You must be thinking of some other distro.

I found that 2.6.17, with the improved IO handlers, definately added a performance boost to my machines. The main headaches I've had with testing have revolved around X.org 7.x being quite a bit different from previous versions (more componentized) and issues with getting it to work with the NVidia stub (you need to tell it where to find the new lib location), etc.

However, all-in-all I've found that running Debian/testing has gone pretty well, and Debian/stable+backports has worked pretty well too. I'll be looking forward to when the features in testing happily merge back into stable.

Oh, and hopefully the rather-cool FPS Nexuiz will merge into stable as well, as it's pretty impressive to see something like that ending up open-source and available in the standard repositories (it's available in testing+ right now). It's also the first OSS app that's really given my graphics card a run for its money.

It's the algorithm. It's straight complexity theory;

Not so.

Really? According to the shootout, regular expressions are much faster on Ruby then C++ or java.
Most of my web programming spends its time either in database lookup or regex processing, so ruby seems to not be such a bad fit...
http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=regexdna&lang=all

It's possible to say everything siad in this article -- vaugely, as it is said in this article -- and be right, and yet still dance around the reality.

Take a look yourself on http://shootout.alioth.debian.org/

C's faster than Java. It will probably always generally be so, unless you're trying to run C code on a hardware Java box.

This article says Java, for example, CAN be faster. But it doesn't say "C is almost always faster than Java or Fortran, usually faster than ADA, and C can be mangled (in the form of D Digital Mars, for instance) to be faster than C usually is. Often, Java is a pig, compared to C, BUT THERE ARE TIMES WHEN IT ISN'T. Really. There are times, few and far between, when it's actually, get this, FASTER. It's fun to look for those few times. And if you write programs which do that, that'd be cool. And as processors get wackier and wackier, there will be more and more times where this is true. Meanwhile, if your developers write good code, Java's easier to develop in and debug." Which would be more completely correct.

Excuse, me, now. I have to go back to my perl programming.

http://shootout.alioth.debian.org/

You'll notice that C does pretty well. Note also however that several other high level languages come in pretty close in terms of performance (of course they usually win on program length). In particular 3 modern functional languages (Clean, OCaml and Haskell) come in just behind gcc and well before your jited or bytecode languages.

So yes, high level languages that compile to native machine code are fully competitive with C and that's not even considering important things like programmer time, safty, maintanability etc.

I'm currently working on a new String and IO library for Haskell and we're getting idiomatic one line programs that are within a few % of equivalent C programs. This is nice because typically you have to uglify your high level code to become more competitive with C performance.

For what it's worth, at The Computer Language Shootout, OCaml does pretty well. Of course, C is still faster for most things (but note that the really high factors (29 and 281) are in OCaml's favour!), but OCaml is pretty fast compared to Java or Perl. Haskell does pretty well too. Functional programming, anyone?
Of course, these benchmarks measure only speed, are just for fun, and are "flawed", but they are still interesting to play with. If you haven't seen the site before, enjoy fiddling with things to try and get your favourite language on top :)

For what it's worth, at The Computer Language Shootout, OCaml does pretty well. Of course, C is still faster for most things (but note that the really high factors (29 and 281) are in OCaml's favour!), but OCaml is pretty fast compared to Java or Perl. Haskell does pretty well too. Functional programming, anyone?
Of course, these benchmarks measure only speed, are just for fun, and are "flawed", but they are still interesting to play with. If you haven't seen the site before, enjoy fiddling with things to try and get your favourite language on top :)

For what it's worth, at The Computer Language Shootout, OCaml does pretty well. Of course, C is still faster for most things (but note that the really high factors (29 and 281) are in OCaml's favour!), but OCaml is pretty fast compared to Java or Perl. Haskell does pretty well too. Functional programming, anyone?
Of course, these benchmarks measure only speed, are just for fun, and are "flawed", but they are still interesting to play with. If you haven't seen the site before, enjoy fiddling with things to try and get your favourite language on top :)

For what it's worth, at The Computer Language Shootout, OCaml does pretty well. Of course, C is still faster for most things (but note that the really high factors (29 and 281) are in OCaml's favour!), but OCaml is pretty fast compared to Java or Perl. Haskell does pretty well too. Functional programming, anyone?
Of course, these benchmarks measure only speed, are just for fun, and are "flawed", but they are still interesting to play with. If you haven't seen the site before, enjoy fiddling with things to try and get your favourite language on top :)

For what it's worth, at The Computer Language Shootout, OCaml does pretty well. Of course, C is still faster for most things (but note that the really high factors (29 and 281) are in OCaml's favour!), but OCaml is pretty fast compared to Java or Perl. Haskell does pretty well too. Functional programming, anyone?
Of course, these benchmarks measure only speed, are just for fun, and are "flawed", but they are still interesting to play with. If you haven't seen the site before, enjoy fiddling with things to try and get your favourite language on top :)

For what it's worth, at The Computer Language Shootout, OCaml does pretty well. Of course, C is still faster for most things (but note that the really high factors (29 and 281) are in OCaml's favour!), but OCaml is pretty fast compared to Java or Perl. Haskell does pretty well too. Functional programming, anyone?
Of course, these benchmarks measure only speed, are just for fun, and are "flawed", but they are still interesting to play with. If you haven't seen the site before, enjoy fiddling with things to try and get your favourite language on top :)

It's actually pretty easy[0]. Examples of the method can be seen in scientific papers[1] and text-only publishing formats such as electronic mailing lists[2].

[0] http://www.answers.com/easy
[1] http://pdos.csail.mit.edu/scigen/rooter.pdf
[2] http://lists.debian.org/debian-news/debian-news-20 06/msg00029.html

...either URPMI or APT for updates, both of which are trivial and powerful to use compared with Microsoft's chaotic collactions, and have been for many years.

Such use would also make the dynamic customisation of updates much simpler and faster (and more possible at all). People who are much less control-dominated thab MS faced and solved these kinds of issues well and long ago.

If it was a joke, then fine. However realise that the web is a very lossy medium when considering how accurately intended sarcasm/humour can be interpreted by those reading a post. :)

Your beef with the Debian development is not incorrect, and you are not the only one who feels this way. However a more appropriate venue to discuss this problem in general would be debian-devel@lists.debian.org.

Also, I'm not sure what relevance of the age of the kernel bug is, since the kernel upstream rejected the LSM patches; you really want to track http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3 13588.

While having Debian's PAM package lagging so far behind upstream is annoying, PAM is also a package that is of critical importance to the operation and security of a machine running Debian. It is the kind of package that is probably better off being maintained by a fairly conservative maintianer.

I can't really comment on the multiple-arch problem. As far as I'm concerned it does not exist; my packages get autobuilt automatically and so supporting the twelve architecture imposes no burden on me. Maintaners of buggier packages may have to debug and fix problems that manifest themselves on other archs, but this process results in software that runs on more systems and is less buggy, so it seems to me that the only ones who complain about it are lazy maintaners who don't really care about doing a good enough job. If they choose to part ways with the project, I will not complain.

It really doesn't become clear. I have to say though, if you want a bug to be fixed, trolling Slashdot is not the way to get it done.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3 13588;msg=67

[15:49] <vorlon> marga: as I've commented elsewhere, my mental schedule of
not working on pam this week now has a mental note added to it indicating
that I'm doing so with spite

http://www.us.debian.org/News/2006/20060713

The servers compromised, in both cases, were not running kernels supported by the debian security team. The Debian sysadmin people typically roll their own kernels for use on Debian.org machines. In fact, had the default stable kernel been used, the machine would not have been vulnerable to this exploit. See http://lists.debian.org/debian-news/debian-news-20 06/msg00030.html for more info. (In short, 2.6.8 is not vulnerable.) The compomised server was running a custom 2.6.16.18 kernel, and was thus vulnerable. It has since been upgraded to a custom 2.6.17.4 kernel. If you're going to knock anybody in this case, knock the Debian sysadmins for not keeping up with security on their own machines, or for having policies in place that allow weak passwords to lead to any kind of access. But don't knock the Debian security team.

The Debian security team has fixed 98 kernel security bugs since sarge was first released. Refer to changelogs for the kernel-source-2.6.8 versions 4sarge1, 4sarge2, and 4sarge3 for details if you need them. What more do you want?

noah

He does one choose users, aka developpers on debian?

But seriously, no FUD: How do they work to trust their developpers. I can't imagine I'm writting a little tiny app, knock on the debian door and they would open it. This is user trust policy.

You raise two different questions: how can Debian Developers be trusted, and how can the code that ends up in Debian be trusted.

For the first case, there is an extensive New Maintainer application process. This includes tests to see whether the applicant knows what s/he is doing, questions to see whether s/he understands and agrees with the philosophies of the Free Software movement, and a GPG key check to make sure that at least one current developer has met and verified the identity of the applicant. Additionally the applicant is supposed to have a history of doing good Debian work. At least two individuals, an Application Manager and one of the Debian Accounts Managers, independently research the applicant. (Only the DAM knows how extensive this research is but I have reason to believe it is quite thorough.)

For a package maintainer who isn't a Debian Developer yet, all his/her work goes through a developer sponsor who reviews it carefully. Only the maintainer's source package is used (not binary .debs), and it is rebuilt into .debs by the sponsor before upload. The sponsor takes particular care to ensure that the upstream source code ("orig.tar.gz" file) used by the maintainer is identical to that available from upstream's web site. Since the sponsor takes the final responsibility of uploading this person's work, s/he has an incentive to make sure everything is OK with it.

This ties into the second question. Even for a package uploaded by a Debian Developer, there is first supposed to be an Intent To Package announcement posted on the debian-devel mailing list (here's an example; notice that this isn't just a rubber-stamp procedure; the example I gave led to a lot of discussion). The developer is expected to review the source code, as much as is reasonable, to make sure there are no trojans built in. With each new revision by upstream, the developer reviews the full diff between versions.

Of course neither procedure is foolproof. Someone with enough dedication, intelligence, and malevolence could manage to get through the New Maintainer procedure and do what you suggest. Or an upstream that was clever enough to write well-disguised trojan code could trick a developer into uploading it into the Debian archive. (There was actually an example of this happening, though the trojanned code wasn't harmful; see this thread. Needless to say this didn't help the upstream author's New Maintainer application.) But these are risks in any software project, not only Debian and not limited to Free/open source software.

He does one choose users, aka developpers on debian?

But seriously, no FUD: How do they work to trust their developpers. I can't imagine I'm writting a little tiny app, knock on the debian door and they would open it. This is user trust policy.

You raise two different questions: how can Debian Developers be trusted, and how can the code that ends up in Debian be trusted.

For the first case, there is an extensive New Maintainer application process. This includes tests to see whether the applicant knows what s/he is doing, questions to see whether s/he understands and agrees with the philosophies of the Free Software movement, and a GPG key check to make sure that at least one current developer has met and verified the identity of the applicant. Additionally the applicant is supposed to have a history of doing good Debian work. At least two individuals, an Application Manager and one of the Debian Accounts Managers, independently research the applicant. (Only the DAM knows how extensive this research is but I have reason to believe it is quite thorough.)

For a package maintainer who isn't a Debian Developer yet, all his/her work goes through a developer sponsor who reviews it carefully. Only the maintainer's source package is used (not binary .debs), and it is rebuilt into .debs by the sponsor before upload. The sponsor takes particular care to ensure that the upstream source code ("orig.tar.gz" file) used by the maintainer is identical to that available from upstream's web site. Since the sponsor takes the final responsibility of uploading this person's work, s/he has an incentive to make sure everything is OK with it.

This ties into the second question. Even for a package uploaded by a Debian Developer, there is first supposed to be an Intent To Package announcement posted on the debian-devel mailing list (here's an example; notice that this isn't just a rubber-stamp procedure; the example I gave led to a lot of discussion). The developer is expected to review the source code, as much as is reasonable, to make sure there are no trojans built in. With each new revision by upstream, the developer reviews the full diff between versions.

Of course neither procedure is foolproof. Someone with enough dedication, intelligence, and malevolence could manage to get through the New Maintainer procedure and do what you suggest. Or an upstream that was clever enough to write well-disguised trojan code could trick a developer into uploading it into the Debian archive. (There was actually an example of this happening, though the trojanned code wasn't harmful; see this thread. Needless to say this didn't help the upstream author's New Maintainer application.) But these are risks in any software project, not only Debian and not limited to Free/open source software.

He does one choose users, aka developpers on debian?

But seriously, no FUD: How do they work to trust their developpers. I can't imagine I'm writting a little tiny app, knock on the debian door and they would open it. This is user trust policy.

You raise two different questions: how can Debian Developers be trusted, and how can the code that ends up in Debian be trusted.

For the first case, there is an extensive New Maintainer application process. This includes tests to see whether the applicant knows what s/he is doing, questions to see whether s/he understands and agrees with the philosophies of the Free Software movement, and a GPG key check to make sure that at least one current developer has met and verified the identity of the applicant. Additionally the applicant is supposed to have a history of doing good Debian work. At least two individuals, an Application Manager and one of the Debian Accounts Managers, independently research the applicant. (Only the DAM knows how extensive this research is but I have reason to believe it is quite thorough.)

For a package maintainer who isn't a Debian Developer yet, all his/her work goes through a developer sponsor who reviews it carefully. Only the maintainer's source package is used (not binary .debs), and it is rebuilt into .debs by the sponsor before upload. The sponsor takes particular care to ensure that the upstream source code ("orig.tar.gz" file) used by the maintainer is identical to that available from upstream's web site. Since the sponsor takes the final responsibility of uploading this person's work, s/he has an incentive to make sure everything is OK with it.

This ties into the second question. Even for a package uploaded by a Debian Developer, there is first supposed to be an Intent To Package announcement posted on the debian-devel mailing list (here's an example; notice that this isn't just a rubber-stamp procedure; the example I gave led to a lot of discussion). The developer is expected to review the source code, as much as is reasonable, to make sure there are no trojans built in. With each new revision by upstream, the developer reviews the full diff between versions.

Of course neither procedure is foolproof. Someone with enough dedication, intelligence, and malevolence could manage to get through the New Maintainer procedure and do what you suggest. Or an upstream that was clever enough to write well-disguised trojan code could trick a developer into uploading it into the Debian archive. (There was actually an example of this happening, though the trojanned code wasn't harmful; see this thread. Needless to say this didn't help the upstream author's New Maintainer application.) But these are risks in any software project, not only Debian and not limited to Free/open source software.

See also this posting on debian-project for more technical details.

For anyone still following this story all these hours later, there's a new post on debian-news with a bit more detail about what happened here.

The short version is, it was a privilege-escalation exploit triggered from a compromised user account, the server in question is now restored, but several others are locked down pending inspection. Also, it says the regular and security archives were not in danger. The exploit was a known issue in the 2.6.16.18 kernel running on gluck at the time of the exploit.

Interestingly, the window between the compromise and the lockdown was less than two hours.

That's the way it's *supposed* to work, and I'm willing to grant that it may well work that way on stable. I'm running testing.

(OTOH, I was shocked whin an install of debian-keyring didn't tell me "you already have the newest version installed". Something strange here... but AFTER installing it, and running update again:
Reading package lists... Done
W: GPG error: http://security.debian.org/ etch/updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
W: GPG error: ftp://mirrors.kernel.org etch Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
W: You may want to run apt-get update to correct these problems

Just like before [though *I think* there were two unknown keys before I did the install].)

FWIW, I do have some non-debian repositories in my sources...but previously it has complained about packages not-being signed with a known key that I have KNOWN were from the Debian repository. Now it isn't saying what package it's referring to, so I can't tell if this is still true. (I'm also quite certain that I've installed debian-keyring before, though I'm only "rather certain" that it's been since I last did a clean install.) I'd been presuming that this was a common problem with Etch...

Just to follow on from what others have said, the Debian signing key changes yearly, which is probably why you had a number of unknown signature warnings.

http://bugs.debian.org/apt

haven't you ?

apt-get archives are now signed too. In Etch (testing) and Sid (unstable) apt will check the integrity of the packages for you, but the entire archive is signed. Just look at woody or sarge,

http://http.us.debian.org/debian/dists/woody/
http://http.us.debian.org/debian/dists/sarge/

Then locate the file Release.gpg. That is the signature for the release file.

apt-get archives are now signed too. In Etch (testing) and Sid (unstable) apt will check the integrity of the packages for you, but the entire archive is signed. Just look at woody or sarge,

http://http.us.debian.org/debian/dists/woody/
http://http.us.debian.org/debian/dists/sarge/

Then locate the file Release.gpg. That is the signature for the release file.

first [in 2003] we had the hack into the repository severs, and we didn't know whether or not we are running exploited code when we use apt-get to update our programs

http://www.debian.org/News/2003/20031121

The archive is not affected by this compromise!

The vulnerability they were hit by was a previously unknown vulnerability in the kernel.