Slashdot Mirror

Kerberos will authenticate without storing or sending passwords. It works for email, remote login (ssh, telnet, rlogin), file service (AFS, ftp) and web as well. Pidgin supports Kerberos, though you wouldn't know it to look at the documentation; it took me a while to realize I needed to load the Debian package libsasl2-modules-gssapi-mit.

I'm not surprised the ubuntu fabois would be out in force in this thread spreading FUD.

You are seriously trying to argue that the ubuntu lts 18 month support is somehow longer than the debian stable support which is 1 year after the release of the next version and new stable release do not happen within the same year so it's always more than 24 months?

Furthermore, you don't need support(in the security/major bugfix sense) for a single debian stable release for very long time periods because you can upgrade to the current stable release very smoothly - and guess what - it's still stable.

Nor do I understand your insistence that not having a predictable release cycle is such a terrible flaw. Does it really matter if you update your server in March one year, and September the next? I don't get it.

Oh look, 700-ish companies providing commercial debian support: http://www.debian.org/consultants/

Everyone point you raise is completely inaccurate and misleading. I can understand being a fan of a certain system you use, but let's try to be more factual next time.

what vendor *wouldn't* love to lock their users into *their* online services and *their* software to manage content on their portable devices and the like - all the while being able to advertise their other services, products, etc.

Um...Debian?

(Just sayin'...) :)

You dont install it on every piece of hardware I can imagine. That would be here: Many Archs

If you moved half the Windows installation base to Linux overnight you'd probably see Linux facing the same complaints Windows does. You'd see a lot more viruses and malware happening, as well as the same crappy hardware causing crashes.

My mother was able to browse the web and do email with Linux in 1999 (I left her one of my Linux boxes when I went to Japan that year). The autoexecute stuff coming across the wire is of uniquely Microsoft origins. The computing community had already decided that was a Very Bad Idea.

Or do you believe Linux is immune to bad memory?

I know it isn't. I recall vividly the "signal 11" FAQ. http://lists.debian.org/debian-user/1996/04/msg00210.html Earlier in the same year, Linus personally helped me debug a system with a Cyrix CPU that ultimately proved to have a bad L1 cache chip.

The BSDs of the time (mid 1990s) were even more sensitive to bad RAM. On the basis of the machine that had a bad L1 cache chip (it always crashed quickly in BSD, but did not crash in Linux 1.2), the company I was working for decided to use Linux instead of BSD (my original recommendation) in its migration away from SCO Unix.

Linux right now is used almost exclusively used by nerds. If XP had the same user base, instead of every high school student, grandma, and hockey mom it would likely not have a reputation for crashing.

It does have a reputation of crashing with the people I work with, all of whom could be described by the pejorative "nerd". I dispute that assertion. And just to be clear, I am referring to Microsoft Windows XP/SP2, enterprise license.

For me personally it's a pain in the butt to get Debian up to date with the things I need on there, which is trivial in CentOS. We're talking about latest versions of things like Python (Etch still ships with 2.4.x) and so on. Not impossible, just time consuming.

I hate to have to be the one to tell you this, but Python 2.5 is present in Debian Etch--it's just not the default version.

I hope you didn't waste a lot of time on this one, because apt-get install python2.5 was all that was needed.

Good luck!

changelog
Downloads and displays the Debian changelog for each of the given source or binary packages.

*sigh* And guess where it downloads them from?

http://packages.debian.org/changelogs/pool/main/

Challenge: Find the changelogs for samba 2:3.2.3-3 and iceweasel 3.0.3-2.

Schwab

You can say "It's disappointing that Debian missed their internal goal of releasing Lenny in early September 2008". But you can't really say "It's disappointing that Debian failed to release Lenny in September as they promised", because the official release schedule clearly says that Lenny will be released "in the second half of 2008".

http://lists.debian.org/debian-devel-announce/2007/06/msg00005.html

So that's what they've actually promised, and there's still plenty of time to keep that promise. Just a week ago the number of RC bugs in Debian was over 270. Now it's a bit more than 200. It'll be interesting to see what the RC bugs count shows one week from now.

It looks like there aren't any floppy installation images for Lenny i386 . This is a real sore point for me since the Etch floppies wouldn't properly boot from a USB drive on my laptop and I had to fall back to Sarge to bootstrap a fresh installation. I was hoping they'd have this fixed but apparently they just decided to lazily drop support altogether.

It's really frustrating that Debian is letting floppy installation support slip. This is a big deal for those of us with old or unusual hardware that can't boot from a CD or memory stick or through netbios/PXE.

If this is happening, first check the changelog for the affected package in /usr/share/doc. If it is out of date or missing, you need to file a severity minor (with the following rationale) against the packages missing the updated changelog. This is not a violation of Debian policy (which would warrant a severity of serious), but it's suggested by policy and trivial to add.

If this is happening, first check the changelog for the affected package in /usr/share/doc. If it is out of date or missing, you need to file a severity minor (with the following rationale) against the packages missing the updated changelog. This is not a violation of Debian policy (which would warrant a severity of serious), but it's suggested by policy and trivial to add.

Which changelogs are you referring to? These? Or the changelogs within the package?

Perhaps this is a candidate for a new benchmark for The Computer Language Benchmarks Game.

1. Write the reference program, which implements the algorithm all other programs use (so that we are comparing language implementations, not the quality of a bunch of different algorithms).
2. Everyone pitch in and port that program to other languages!
3. Submit to Alioth for inclusion in the benchmarks
4. Profit! (intellectually, of course)

Debian GNU/Linux is the distro for real men. That's what I use for desktops and laptops (lenny/testing with a bit of sid/unstable and custom things) and servers (etch/stable with some custom things) and it works extremely well. Debian-based distros are not the real thing. Debian is the real thing and that's what real admins use. It's a shame that Wikipedia overlooked Debian. Some people may think that other distros have "predistable releases" but that's a myth, because you can always get some new stuff from the testing and unstable branches, which contrary to their name are working very well. When all other distros and all other OSes die, Debian will be alive and totally ready to run all PCs and servers with extreme stability and security. I think that they chose another distro just because they didn't researched Debian's advantages well enough. See also this interesting bit here. We, Debian people, should help them understand why Debian is the best distro out there and why it should run their servers.

There is an EEE subproject in Debian that did a decent job with my EEE:

http://wiki.debian.org/DebianEeePC

They have a nice set of packages that will light up your Ethernet and Wireless out of the box. LXDE and wicd to manage the wireless with a nice sane Debian Testing repository was hella nicer than trying to get newish stuff on that mutated Xandros they come with. The last time I checked they didn't supply a driver for the camera although the standard Debian repository has an automated build source package for it that wasn't too awful bad to get working. Other than that, everything works. The hotkeys for brightness and volume even worked although you don't get the popup on screen for them.

It's a shame this won't be in the upcoming Lenny release of Debian. The in-kernel support for heaps of webcams via gspca is a very nice user-visible element of this release.

http://release.debian.org/emails/release-update-200808

Although, I guess they made the decision for 2.6.26 before they realised that a September release would be an impossible target.

The "Open Source Definition"?
What does that have to do with open source? You mean "Open Source (TM)"? Sorry, that doesn't exist.
If you meant "Open Source Initiative Approved License (TM)" then you might be onto something, but that's not what's being claimed.

Open source has a Linux centric background, but nobody can dictate what exactly it means. It is commonly accepted today to mean you can see the source.
GNU's take on "open source"
The original open source announcement
http://www.debian.org/social_contract.html#guidelines>What it was based on

It's funny it started because "free software" was too ambiguous. ROFL!

GNU's right..

Ambiguity
The term "free software" has an ambiguity problem: an unintended meaning, "Software you can get for zero price," fits the term just as well as the intended meaning, "software which gives the user certain freedoms." We address this problem by publishing a more precise definition of free software, but this is not a perfect solution; it cannot completely eliminate the problem. An unambiguously correct term would be better, if it didn't have other problems.
Unfortunately, all the alternatives in English have problems of their own. We've looked at many alternatives that people have suggested, but none is so clearly "right" that switching to it would be a good idea. Every proposed replacement for "free software" has a similar kind of semantic problem, or worse--and this includes "open source software."
The official definition of "open source software," as published by the Open Source Initiative, is very close to our definition of free software; however, it is a little looser in some respects, and they have accepted a few licenses that we consider unacceptably restrictive of the users. However, the obvious meaning for the expression "open source software" is "You can look at the source code." This is a much weaker criterion than free software; it includes free software, but also includes semi-free programs such as Xv, and even some proprietary programs, including Qt under its original license (before the QPL).
That obvious meaning for "open source" is not the meaning that its advocates intend. The result is that most people misunderstand what those advocates are advocating. Here is how writer Neal Stephenson defined "open source":
Linux is "open source" software meaning, simply, that anyone can get copies of its source code files.

Whatever meaning the OSI meant open source to have (the Linux centric ideals) is lost.

On Linux usb ports can be powered down to save power. However it turns out that many USB devices are broken and can't cope with being powered down. Now the question comes up what version of Linux are you using? If it's something older than 6 months then there's a good chance this has been fixed (the list of things allowed to be powered down has gone from a blacklist to a whitelist of large categories). See this commit talking about the kernel no longer powering anything down bar USB hubs for some more details.

A very short term band aid might be to disable usb autosuspend on that device via /sys/.

It's for rpm based commercial distros. Debian doesn't fit, and the "alien" program doesn't work on everything. Since I use Debian on servers and Debian-derived on desktop, I don't care about the LSB, I care more about the standards of the Debian project.

http://wiki.debian.org/DebianLsb

http://packages.ubuntu.com/hardy/lsb-base

It isn't really about the packages at all. It is more about Linux becoming "desktop agnostic". It is about how to have a library (call it the "lsb" library if you will) such that a program written to call that library can access standard elements of the desktop, such as the taskbar, the clipboard and the file open/save dialogs.

It is all about making it easier for developers to write an application for the Linux desktop that will work regardles of what desktop and what distribution the user has installed.

If you actually install any application written to this standard on your Debian system, then apt will automatically install the Debian lsb package for you as a dependency. So you don't have to "worry" about it at all, it will "just work".

How one packages such a cross-distribution program for desktop Linux is another isue. There are solutions for cross-distribution packages, but really it is simpler for the application provider to simply write the application to lsb standards, and then make an .rpm package **AND** a .deb package (from the same source) for binary distribution purposes.

I believe that Debian was prevented from accepting a similar agreement because it in some way conflicted with their ideology.

Not "in some way". It conflicts with an explicitly stated guideline, in particular,

8. License Must Not Be Specific to Debian.

If Debian can work out an agreement, that agreement needs to be with the entire free software community; the agreement must not be limited to something named Debian (after all, if the agreement becomes invalid when someone takes that component out of Debian, then by the general consensus, that component is not free).

This is a FAQ about free software licences, see http://people.debian.org/~bap/dfsg-faq.html question 12.g.

12. g.

Q: I'm a working scientist, and would like to release code implementing my work. However I want to make sure that people using the software mention its use, and cite my papers, in papers they write. Should I include this in the license?

A: You have a valid concern. Computer scientists often receive inadequate credit for their scientific contributions. But putting such a clause in the license would render your software non-free. Instead we suggest a note, not part of the license itself, reminding users of the rules of scientific propriety. Eg:

SCIENTISTS: please be aware that the fact that this program is released as Free Software does not excuse you from scientific propriety, which obligates you to give appropriate credit! If you write a scientific paper describing research that made substantive use of this program, it is your obligation as a scientist to (a) mention the fashion in which this software was used, including the version number, with a citation to the literature, in the Methods section, to allow replication; (b) mention this software in the Acknowledgements section. The appropriate citation is: Robert B. Laub (2003) "BLOBBER: A program that blobs", Blobbing Bulletins 12(34):567-89. Moreover, as a personal note, I would appreciate it if you would email bobblaub@ubl.edu with citations of papers referencing this work so I can mention them to my funding agent and tenure committee.

Only one way to settle this, a shootout. Spidermokey is already on there. Get the rest of them up. (I'd get V8 up except it's missing command line arguments.)

Not true. A quick look at the Debian lanugage shootout will reveal that Haskell's performance is only barely slower than C's, and that's even with a ban on setting up the garbage collector to work well with the program that's being run, and an out of data compiler that isn't as efficient as the most recent.

Umm... GNU IceCat or Debian IceWeasel? Maybe Swiftfox or just compile a rebrand.

Not that I don't think this is stupid. But there are ways around this.

That's not the way it happened.

Actually... yes, that is the way it happened. Debian thought they had an agreement (which they cite in that thread) from Mozilla which would let them continue to use the "Firefox" name while avoiding certain aspects of the branding requirements which proved too onerous for the DFSG. And all was well until one day a guy from Mozilla Corporation (which, ironically, is not the entity which owns the trademark) came along and started the threat process.

Once again: Mozilla's done this before. They're doing it again. Isn't it about time we had a Free browser?

Yeah, just like we have a free SSL package.

That's not the way it happened.

Actually... yes, that is the way it happened. Debian thought they had an agreement (which they cite in that thread) from Mozilla which would let them continue to use the "Firefox" name while avoiding certain aspects of the branding requirements which proved too onerous for the DFSG. And all was well until one day a guy from Mozilla Corporation (which, ironically, is not the entity which owns the trademark) came along and started the threat process.

Once again: Mozilla's done this before. They're doing it again. Isn't it about time we had a Free browser?

I submitted it as http://packages.debian.org/iceweasel without a / at the end, which does work, I don't know why it got changed.

The iceweasel link should be http://packages.debian.org/sid/iceweasel

You should take a look at Debian's user security manual. This will give you some idea of how seriously they take it. Also, there's a lot of material under www.debian.org/security/ that is worth looking at.

You should take a look at Debian's user security manual. This will give you some idea of how seriously they take it. Also, there's a lot of material under www.debian.org/security/ that is worth looking at.

OK, some servers got hacked, the attackers didn't inject rogue packages into the repository servers so no customers/users were affected. Red Hat/Fedora responded by auditing everything and releasing a statement, along with tools to detect packages with the attackers' signature. Big deal.

Seriously, what else is there to be known about it?

Yeah, say whatever you want, but it's not as if Debian never had its servers compromised in a similar fashion, and never had to perform some PR damage control.

Unlike Debian, Red Hat is a publicly traded company with a whole bunch of customers with signed SLAs. Handling such matters without press trolls all rolling over it spreading FUD and causing unnecessary panic is _not_ an easy task, as can be beautifully shown by TFA.

I respectfully disagree with Bruce Perens. The Debian OpenSSL fiasco was so much more serious, damaging and dangerous to users all over the world, it's not even fair to compare. We're talking about millions of known networks and sessions compromised in Debian over a year and a half period, versus none in Red Hat over a week.

I appreciate how Debian acted _after_ the fact, but was there any other way to handle such a terrible mishap?

This is not about flawed Open Source policies, this is about seriously flawed journalism, where conspiracy theories are used to make a story where there is none.

OK, some servers got hacked, the attackers didn't inject rogue packages into the repository servers so no customers/users were affected. Red Hat/Fedora responded by auditing everything and releasing a statement, along with tools to detect packages with the attackers' signature. Big deal.

Seriously, what else is there to be known about it?

Yeah, say whatever you want, but it's not as if Debian never had its servers compromised in a similar fashion, and never had to perform some PR damage control.

Unlike Debian, Red Hat is a publicly traded company with a whole bunch of customers with signed SLAs. Handling such matters without press trolls all rolling over it spreading FUD and causing unnecessary panic is _not_ an easy task, as can be beautifully shown by TFA.

I respectfully disagree with Bruce Perens. The Debian OpenSSL fiasco was so much more serious, damaging and dangerous to users all over the world, it's not even fair to compare. We're talking about millions of known networks and sessions compromised in Debian over a year and a half period, versus none in Red Hat over a week.

I appreciate how Debian acted _after_ the fact, but was there any other way to handle such a terrible mishap?

This is not about flawed Open Source policies, this is about seriously flawed journalism, where conspiracy theories are used to make a story where there is none.

Debian has a mips port, where you can likely download precompiled packages just fine. http://www.debian.org/ports/mips/

Evince is a strong offering and it is available on MIPS. It's probably my favorite PDF and postscript program for viewing.

Link to evince on Debian package search for MIPS

No precompiled apps to download,

Yeah, there's only a little over 20,000 precompiled MIPS packages here. (Well, technically, somewhere in here, with an index located here.) I tend to think that 20,000+ is a little bit more than zero, but maybe that's just me. :)

No precompiled apps to download,

Yeah, there's only a little over 20,000 precompiled MIPS packages here. (Well, technically, somewhere in here, with an index located here.) I tend to think that 20,000+ is a little bit more than zero, but maybe that's just me. :)

No precompiled apps to download,

Yeah, there's only a little over 20,000 precompiled MIPS packages here. (Well, technically, somewhere in here, with an index located here.) I tend to think that 20,000+ is a little bit more than zero, but maybe that's just me. :)

Well anything would be faster than where they where as the fourth slowest language on the shootout. (Ok, not anything: Ruby, PHP, and Tcl.)

I'm personally waiting to see the Epiphany team's Webkit based browser.

Why wait? :)

B (v1) Depends: C (v2)
B (v2) Depends: C (v1)

You have a later version of B depending on an earlier version of C! How often does that happen?

Not often. I was coming up with a simple and contrived example off the top of my head late at night, and it doesn't look much like what happens in real archives. But, of course, the choices of Cv1 and Cv2 are arbitrary; you could swap them and have the same situation:

A (v1) Depends: B (v1), C (v1)
A (v2) Depends: B (v2), C (v1)
B (v1) Depends: C (v1)
B (v2) Depends: C (v2)

The point is that you have to backtrack to solve this (unless you happen to pick a satisfying solution with your first choice of version for each package), which your pseudocode doesn't do. Even that isn't enough, though:

A (v1) Depends: B (v1), C (v1)
A (v2) Depends: B (v1), C (v1)
B (v1) Depends: C (v1)
B (v2) Depends: C (v2)

If the user asks to install B v2, you have to consider removing A to install it (because Bv2 requires Cv2, and all versions of A need Cv1). Note that the simple approach of walking through the dependencies of B and trying each one won't help here, because it's not a dependency of B that's broken. You need to look at the reverse dependencies of C too, and in a larger archive A might have reverse dependencies that also need to be taken care of once it's removed.

I've written a little bit about some of these issues at http://people.debian.org/~dburrows/model.pdf. You can find a lot of this in a basic AI textbook or in the theory behind constraint solving algorithms too, though; that link just applies some standard techniques to the problem of dependency resolution.

Daniel

Wow, that article on the French is an evidence-free zone. The only actual French OSS project they mention is some middleware doodah that I've never even heard of. Trying to think of some myself... um:

1. Mandrake
2. ...er ...
3. ... that's it.

I'm sure there are others but none springs to mind.

Actually it's Mandriva. Using Mandrake is no more allowed, because of Mandrake the magician ( http://en.wikipedia.org/wiki/Mandriva_Linux#Name_changes )

Well Mandriva is just an example of software tagged "French" (not by Mandriva itself, but it's often referred as "French distro" or something).
As you guessed, we can find some other examples of software started by french people (videolan, Xfce, azureus, libcaca, sympa, frozen-bubble[2] etc.).

But is it important ? Is Mandriva really a French distro ? Mandriva now owns Conectiva (from Brazil) and Lycoris (from USA). So it's more 50% French, 25% US and 25% Brazilian. But wait it's using a kernel started by a Finnish guy, and a Desktop Environment born in (and still hugdely attached to) Germany...
You know were i'm heading. I don't think counting the number or "French OSS projects" is a good measure of how much France is involved or not in FLOSS. Perhaps we can find more valuables way to measure it. For instance by finding some projects where French people are really involved :

• Gnome :
  • http://www.gnome.org/~jdub/random/GnomeWorldWideHuge.jpg (I agree, we don't see much here. Just a bunch of points somewhere in West Europa)
• KDE :
  • http://worldwide.kde.org/pics/fullmap.jpeg
  • http://commit-digest.org/mappy/?view=2008-08-17&scheme=map_default&region=world&mode=embedded&standalone=no
• Debian
  • http://www.debian.org/devel/developers.loc (Same remark as Gnome)

We can also looks at studies and statistics :

• http://www.infonomics.nl/FLOSS/report/Final-2b.htm#_Toc14094379
• http://news.cnet.com/8301-13505_3-9992379-16.html

This part was only about FLOSS development, we could also study FLOSS use or lots of different things. Well, i think my post is long enough already (sorry when i start, i just can't stop) so i won't cover all this. One last thing : I have no clue about other countries, but there is a lot of movement around FLOSS : Events :

• RMLL/LSM (Libre Software Meeting) : http://2008.rmll.info/?lang=en
• Paris Capitale du Libre (Paris http://en.paris-libre.org/index.php?option=com_frontpage&task=&id=0&Itemid=1
• Solutions Linux : http://www.solutionslinux.fr/
• FOSSDEM http://fosdem.org/ (That's true i lied again, it's not in France, but in Belgium. In Brussels, the French speaking part of Belgium)

There are also powerful Associations and usersgroups like April ( http://april.org/index.html.en )
Well April is Involved in so many things (promotion of FLOSS, lobyying, meetings with politics, action groups against tying, against treacherous computing, against software patents, against OOXML normalizat

You can create your own table with whatever weightings you want at the language shootout page: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Note that I linked the Gentoo/P4 platform since it has the most ranked entries.

http://www.debian.org/
http://www.fedoraproject.org/
http://www.ubuntu.com/
http://www.opensuse.org/
http://www.slackware.org/
http://www.gentoo.org/
http://www.freebsd.org/
http://www.openbsd.org/

Truetype support sucked on linux back then, so it was a very short lived exercise.

TrueType support still sucks on Linux by default: most distros use the dreadful Freetype auto-hinter, which inflicts unspeakably mangled contortions on font outlines in its misguided desperation to ensure that everything lines up exactly with pixels.

However, it is possible to configure it to use real TrueType hinting (if you like the Windows look and don't care about software patents), and it's also possible to turn hinting off completely and get fonts that look just like the ones on a Mac (very true to the printed appearance, but some people find them too blurry). Do whichever of those two things you prefer, and you can end up with something that you can read without wanting to claw out your own eyeballs in horror.

Does anyone here regularly install those fonts on any linux computer they use? I know I haven't.

Yes; in fact it's not uncommon. For example, Debian's statistics suggest that msttcorefonts is by far the most popular package in their contrib/X11 section, though it's only 1/6 as popular as e.g. the DejaVu fonts.

Why wait until someone to put up a new live-cd, the perfect one, the way you would like, e.g. with just totally free software or perhaps full of practical propriatary for you mundane needs? Just use Debian-Live and easily choose your favorite packages to make your own Linux Live-CD! Now everyone can be happy! RMS can make his own live CD with just gcc, emacs, a lisp interpreter, e-mail reader and a text browser! (I mean... Just gcc and emacs.)

http://debian-live.alioth.debian.org/

Make your own Live-CD and be happy and free!... or not free, or not happy. Whatever, now it's your call, dude!!...

Debian put together a patch:

http://people.debian.org/~cjwatson/openssh-blacklist.diff

There is a tool in there called ssh-vulnkey and you can get the blacklists from debian here:

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz

You need to run the install script as some bytes get stripped from the provided blacklist files.

Debian put together a patch:

http://people.debian.org/~cjwatson/openssh-blacklist.diff

There is a tool in there called ssh-vulnkey and you can get the blacklists from debian here:

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz

You need to run the install script as some bytes get stripped from the provided blacklist files.

Not really it looks like the DragonflyBSD folks added the Debian patches and these are not to be found in the OpenSSH sources. But that is sort of a joke actually. The tool is called ssh-vulnkey, and you can find a patch for it here:

http://people.debian.org/~cjwatson/openssh-blacklist.diff

There is a man page for it, here is an online version:

http://www.tin.org/bin/man.cgi?section=1&topic=ssh-vulnkey

What it does is a binary search of key files against /etc/ssh/blacklist.TYPE-LENGTH files. It can be used to hunt for bad known weak keys. You can download the blacklist files here from debian:

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz

The README describes it better (I had to trim the junk characters):

This package contains a set of default SSH keys that were known to have
been generated during the time when the Debian OpenSSL package had a
broken Random Number Generator.

The source package contains the full fingerprint of the vulnerable keys
in blacklist.RSA-2048 and blacklist.DSA-1024. The installed package uses a
partial fingerprint for identifying the keys by stripping off the first 12
bytes of the fingerprint.

Also there is a new feature of the patched sshd that searches the blacklist files for matches. It can be disabled by the 'PermitBlacklistedKeys' option to sshd.

So the reason that this is funny is that how this works is that there is a list of known weak keys. If some user generated a ssh key pair on an affected Debian box, you're affected and the blacklist won't do you any good.

Not really it looks like the DragonflyBSD folks added the Debian patches and these are not to be found in the OpenSSH sources. But that is sort of a joke actually. The tool is called ssh-vulnkey, and you can find a patch for it here:

http://people.debian.org/~cjwatson/openssh-blacklist.diff

There is a man page for it, here is an online version:

http://www.tin.org/bin/man.cgi?section=1&topic=ssh-vulnkey

What it does is a binary search of key files against /etc/ssh/blacklist.TYPE-LENGTH files. It can be used to hunt for bad known weak keys. You can download the blacklist files here from debian:

http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.1.1.tar.gz

The README describes it better (I had to trim the junk characters):

This package contains a set of default SSH keys that were known to have
been generated during the time when the Debian OpenSSL package had a
broken Random Number Generator.

The source package contains the full fingerprint of the vulnerable keys
in blacklist.RSA-2048 and blacklist.DSA-1024. The installed package uses a
partial fingerprint for identifying the keys by stripping off the first 12
bytes of the fingerprint.

Also there is a new feature of the patched sshd that searches the blacklist files for matches. It can be disabled by the 'PermitBlacklistedKeys' option to sshd.

So the reason that this is funny is that how this works is that there is a list of known weak keys. If some user generated a ssh key pair on an affected Debian box, you're affected and the blacklist won't do you any good.

Now the problem with the driver isn't that it doesn't exist, or doesn't work. It's that some vocal minority simply refuses to use it. That's a personal problem of their own manufacturing.

I have an nVidia GeForce 2 MX video card. I use Debian and recently wanted to upgrade the kernel to 2.6.26. Guess what? The package nvidia-kernel-legacy-71xx-source doesn't compile with that kernel. nVidia doesn't support it any more.

Now, the problem with the driver is precisely that it doesn't work and cannot be made to work by anyone other than nVidia. How do you figure this technical problem is a personal problem of my own manufacturing?