Slashdot Mirror

Mark Shuttleworth is subsidizing the Kubuntu team is working on a software installer named Adept. I find this to be rather wasteful, since there is already an extremely feature-rich, robust and mature installer from SUSE named YAST. YAST is Free and Open Source (GPL) and it is built on the Qt/KDE framework and integrated in the KDE Control Center, so it would fit very nicely in the Kubuntu environment.

YaST is the app that makes the proverbial "Linux on the Desktop" a reality. It is the most robust, comprehensive and user-friendly configuration tool for GNU/Linux -- software management, hardware detection, system administration and much more. In short, it is everything the average newbie from W$ needs to set up and update his computer without having to touch the command line.

Devising a new GUI app for installing packages is reinventing the wheel by duplicating the gigantic functionality of YAST. This project will only yield a half-baked solution that will get abandoned as soon as it starts tackling the more thorny issues that YAST has already solved.

The YAST code is clean, and has already been used by Linux distros like Yoper, so it is definitely feasible to get it running under Debian/Kubuntu if their devs don't start reinventing the wheel. YAST might be complex, but then any program that excels at setting up and updating a Desktop Linux system is going to become complex no matter what.

  Unlike, oh say Linux which is in a constant state of flux and change?

After all Aero Glass is mostly based on developments seen quite a while ago in OS X.

Repeating this again and again doesn't make it true. In fact, there are no significant features in Aqua that weren't known and used previously in UIs. In particular, Apple invented neither animation, nor hardware acceleration, nor transparency as part of the UI.

If anything, Apple deserves a good deal of criticism for misrepresenting the Aqua style of GUI as the result of Apple research.

if ya gotta buy a new box to run Vista, then why not just simply make the switch

Indeed, why not make the switch? After all, if it is cutting edge GUI features you desire, Gnome has both Vista and Aqua beat.

I can't find a license under that link but I do know that the licence for GLX "SGI FREE SOFTWARE LICENCE B" has ben deemed non-free by debian http://bugs.debian.org/211765

"I predict version 5 by that time, and Xgl will still be in an unstable apt repo.

And packages.debian.org will still be broken, as will search.debian.org. Seriously, they can't have been working very hard on it. It'll be two years in May.

Lazy asses.

"I predict version 5 by that time, and Xgl will still be in an unstable apt repo.

And packages.debian.org will still be broken, as will search.debian.org. Seriously, they can't have been working very hard on it. It'll be two years in May.

Lazy asses.

It is official -- Netcraft confirms: FSF is dying

One more crippling bombshell hit the already beleaguered FSF community when IDC confirmed that the FSF's mindshare has dropped yet again, now down to less than a fraction of 1 percent of all computer users. Coming on the heels of a recent announcement from Linus Torvalds, which plainly states that the Linux kernel will NOT be moving to GPLv3, this news serves to reinforce what we've known all along. The FSF is collapsing in complete disarray, as fittingly exemplified by founder Richard Stallman's hairstyle and rambling GNU/Everything Communist anti-developers'-rights "I'm-right-and-you're-stupid" commentary.

You don't need to be a Kreskin to predict the FSF's future. The hand writing is on the wall: the FSF faces a bleak future. In fact there won't be any future at all for the FSF because the FSF is dying. Things are looking very bad for the FSF. As many of us are already aware, the FSF continues to lose mindshare. In a recent poll on Slashdot, 97% of computer users preferred Microsoft to the FSF in terms of both ideals and the quality of their flagship products.

The GNU operating system is the most endangered of all the FSF's projects, having lost 93% of its core developers. Unable to convince users to use GNU's own "Hurd" kernel, the FSF has made several desperate attempts to capture mindshare by riding Linux's coattails. The aforementioned sudden (although not unexpected) denouncement of the GPLv3 by Linus Torvalds only serves to underscore the point more clearly. There can no longer be any doubt, the FSF is dying.

Let's keep to the facts and look at the numbers.

FSF founder RMS states that there are almost 7000 remaining GNU users. How many of those use Emacs? Let's see. Consider the bell-shaped curve of an IQ distribution graph. At best, Emacs users universally score two standard deviations below the mean, which means that they make up approximately 2% of any given sample. Therefore, there are 140 Emacs users left in the world. A recent article showed that GCC usage is declining among truly free operating systems in favor of ICC or even SDCC. There's GNU and Emacs, what else does the FSF produce aside from hot air?

Due to the troubles of the GNU operating system, abysmal adoption rates and so on, the GNU folks gave up on improving their code and instead began to concentrate on marketing their beta-quality OS. Theirs is just another unfinished open source project with a poorly designed interface and a lot of ideological baggage. It's no wonder that more and more businesses are turning to Microsoft.

All major surveys show that the FSF has steadily declined in mindshare. The FSF is very sick and its long term survival prospects are very dim. If the FSF is to survive at all it will be among juvenile political dilettante dabblers. The FSF continues to decay. Nothing short of a miracle could save it at this point in time. People just don't want to hear their message anymore. For all practical purposes, the FSF is dead.

Fact: The FSF is dying

GNU Free Documentation License 1.2 (GFDL) is non-free [1]. Should we discredit all GNU licenses as a whole?

The CC licenses are not upfront about what terms they contain and their names are deceptive. For example the sampling+ license might as well be a completely commercial 'no rights' license, since all it permits would be allowed by fair use anyways.

This has clearly caused confusion, for example the freesounds project claims to be making freely available sound samples... A good goal indeed, but they have chosen the sampling+ license, thus making their samples not free at all. (This is not only been noticed by RMS, I found this discussion: http://lists.debian.org/debian-legal/2005/11/msg00 287.html)

Sampling+ isn't the first example of this... For example CC created a CC-wiki license which allows website operators to take attribution from creators. It's not bad if you're upfront about it, but they werent... WORSE, they went and snuck these terms into CC-BY-SA-2.1 without comment or even updating the 'human readable' version of the license.

You can have a desktop linux NOW. Fetch a modern commercial distro (http://www.ubuntu.com/>Ubuntu, Mandrake, etc) or any of the free ones and you'll have an excellent desktop with little issues, if any.

    The people that bitch about the "linux desktop" haven't normally ever tried Linux and want something that feels like their WinXP desktop. If you're looking for that, yes, there's nothing like it now and probably won't be for a while. If you want an useable Unix desktop, there's a lot of excellent ones arround.
    You have a wide choice of desktops and window and managers, and there's a lot of excellent software for them. A linux desktop is useable today, and by anyone - i had Ubuntu on a desktop for a while and my mother, who's 'computer-imparied' had zero issues using it. Besides being unable to find the blue E icon ;)

I think the author of the editorial makes a rather trivial point. (They could have made the point a lot stronger, pointing out that malware, spyware, adware, trojans, etc., are all able to be run from within unprivileged user-space.)

I don't think it's a trivial point as there are many people who don't get it that reducing privileges isn't a solution.

(a) Smaller target.

That point is becoming more and more moot due to things like Metasploit.

(b) Remote exploits. This, I think, is a lesser issue, but not a trivial one--there are a considerable number of remote exploits in Microsoft software, and there have been a non-trivial number of viruses and malware that spread through this vector.

I think the key question is to determine the ways the PC of an average user gets compromised and decide which OS does a better job in preventing these attack vectors.

In my experience, there are two major ways a Windows box gets owned, either by a remote exploit or by tricking the user into running malicious code. As you say, *NIX wins the first category, although Microsoft is slowly catching up.

The second category is much more interesting, however. Under *NIX, it usually requires pretty much knowledge if you want to execute third-party code (unless some brain-dead distribution registers wine as the default handle for EXE files).

Look at this benchmarks ...

http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=all

Ruby has made some important OO design contributions

It has ?! Like what ?! What's in Ruby that wasn't in other languages ?!!

For patience's sake, this is the problem...All I see are ideas that were in other languages, thrown together in a learn-as-you-go experiment. People think continuations are cool? Then look at Scheme and look at Smalltalk. You can't compare years of development to that experiment. Ruby is rubbish. Compare it to any Smalltalk implementation. Download a Common Lisp IDE (LispWorks, Franz) and tell me how cool Ruby is...When people diss Java, remember to also diss HotSpot. Can your little language optimize code statistically like that? I thought not...

You want new stuff? Look at Factor, Joy, the Mozart/Oz system, or Slate.
Wanna compile at gcc performance? Try Scheme with the Bigloo implementation, or Objective Caml. Bechmarks for Ocaml here (and for SML with MLTon compiler here.- The bechmarks for Bigloo were reomved some time ago).

I'll just post the buzzwords for Factor:

Continuations, exception handling.
Powerful and logical meta-programming facilities. Introspection, code generation and extension of both syntax and semantics is very easy.
Higher-order programming allows code blocks to be treated as data and used as parameters.
Highly minimalist, very consistent design. No layers upon layers of indirection, no confusing corner-cases, no poorly-thought-out features.
Postfix syntax with an extensible parser; values are passed on the stack.
Higher-order programming allows code blocks to be treated as data and used as parameters.
A powerful and very generic collections library allows many algorithms to be expressed in terms of bulk operations without micro-management of elements, recursion, or loops.
A very consistent object model based on generic predicate dispatch.
Arithmetic operations that closely model mathematical concepts, rather than just being a thin abstraction over underlying machine arithmetic. All integer operations are done in arbitrary precision, and exact fractions are supported. Complex numbers and complex-valued elementary functions are integrated.
Damn, that Slava Pestov is one smart dude.

When you see those languages, you kinda get sad that Ruby is such an attention-grabber, but I can see clearly that this is just because of disinformation. With the exception of Joy and Slate (for now, I hope), all the others I cited have pretty workable environments.

And by the way, you don't write LISP anymore, it's Lisp.

Ruby has made some important OO design contributions

It has ?! Like what ?! What's in Ruby that wasn't in other languages ?!!

For patience's sake, this is the problem...All I see are ideas that were in other languages, thrown together in a learn-as-you-go experiment. People think continuations are cool? Then look at Scheme and look at Smalltalk. You can't compare years of development to that experiment. Ruby is rubbish. Compare it to any Smalltalk implementation. Download a Common Lisp IDE (LispWorks, Franz) and tell me how cool Ruby is...When people diss Java, remember to also diss HotSpot. Can your little language optimize code statistically like that? I thought not...

You want new stuff? Look at Factor, Joy, the Mozart/Oz system, or Slate.
Wanna compile at gcc performance? Try Scheme with the Bigloo implementation, or Objective Caml. Bechmarks for Ocaml here (and for SML with MLTon compiler here.- The bechmarks for Bigloo were reomved some time ago).

I'll just post the buzzwords for Factor:

Continuations, exception handling.
Powerful and logical meta-programming facilities. Introspection, code generation and extension of both syntax and semantics is very easy.
Higher-order programming allows code blocks to be treated as data and used as parameters.
Highly minimalist, very consistent design. No layers upon layers of indirection, no confusing corner-cases, no poorly-thought-out features.
Postfix syntax with an extensible parser; values are passed on the stack.
Higher-order programming allows code blocks to be treated as data and used as parameters.
A powerful and very generic collections library allows many algorithms to be expressed in terms of bulk operations without micro-management of elements, recursion, or loops.
A very consistent object model based on generic predicate dispatch.
Arithmetic operations that closely model mathematical concepts, rather than just being a thin abstraction over underlying machine arithmetic. All integer operations are done in arbitrary precision, and exact fractions are supported. Complex numbers and complex-valued elementary functions are integrated.
Damn, that Slava Pestov is one smart dude.

When you see those languages, you kinda get sad that Ruby is such an attention-grabber, but I can see clearly that this is just because of disinformation. With the exception of Joy and Slate (for now, I hope), all the others I cited have pretty workable environments.

And by the way, you don't write LISP anymore, it's Lisp.

Take a look at this Computer Language Shootout

There's Debian Linux

Actually, the project and distribution you're referring to calls itself Debian GNU/Linux.

but strictly speaking, because there's no complete operating system that uses only GNU utils and the Linux kernel, there's no such thing as GNU/Linux.

You misunderstand the argument for calling the system GNU/Linux. Allow me to summarize it.

Premises

• The operating system in question consists of a many components from many projects.
• It would be unreasonable to name the system after all these components.
• A compromise must be made where the system is named after the most important components.
• The most significant contribution to this operating system is GNU.
• The second most significant contribution is a kernel named Linux.
• Failing to include GNU in the name of the system leaves most users unaware that GNU is the most significant component.
• The GNU project's idealism resulted in a significant practical outcome.
• Unawareness of the significance of GNU's contribution can lead to two problems, a person thinking their philosophy is impractical, or not knowing about it at all.
• The philosophy of the GNU project and the free software movement is a philosophy worth spreading.
• Including GNU in the name of the system does not spread the philosophy, but it does highlight the contribution's significance, increasing the chance that a user will learn about and agree with the philosophy.

Conclusion: The best name for the operating system in question is GNU/Linux.

I understand why someone who rejects any of these premises would disagree with the conclusion. If GNU were not the most significant component, it would be unfair to insist on including it in the system's name, even if one wanted to promote the philosphy. (We don't call Solaris or FreeBSD, GNU systems) If one does not feel it is important to spread the project's philosophy, there is little gained by including it in the name, even when one recognizes that GNU is the most significant component. Thus, it must be understood that the combination of these reasons and circumstances leads to the conclusion.

There's Debian Linux, RedHat Linux, SuSE Linux, Gentoo Linux, and dozens of others.... Debian is probably closest to GNU/Linux

These are all GNU/Linux systems, Debian doesn't have more GNU software than the others. All of them use Linux as a kernel and the following vital GNU components:

• The GNU C Library (glibc)
• BASH, the GNU shell
• GNU Coreutils
• GNU Findutils
• GNU grep
• GNU sed
• GNU Tar
• GNU zip, gzip
• GNU Diffutils
• Ncurses, the GNU curses library.

In the case of Gentoo, GNU make, gcc, GNU binutils. and GNU patch should be viewed as vital too. :)

If you think carefully about what makes a system 'Unix like', you will appreciate why GNU is the most significant contribution. Another pos

Personally, this is the only archive I trust to draw untested (by me) programs to be on my computer (companies I consult for of course frequently use "other" systems - and lose a lot of sleep and hair keeping it semi-clean). And the reason for that trust is driven by their simple, and effective, requirement to adhere Item 2 of this .

Personally, this is the only archive I trust to draw untested (by me) programs to be on my computer (companies I consult for of course frequently use "other" systems - and lose a lot of sleep and hair keeping it semi-clean). And the reason for that trust is driven by their simple, and effective, requirement to adhere Item 2 of this .

_and_ has a functional and up-to-date distribution behind it

They are - well, they're talking about it at least...

I wish the Debian team would discuss getting http://packages.debian.org/ working!

From the Debian project's "about" page:

Most software costs over 100 US dollars. How can you give it away?

A better question is how do software companies get away with charging so much? Software is not like making a car. Once you've made one copy of your software, the production costs to make a million more are tiny (there's a good reason Microsoft has so many billions in the bank).

Second, relying on non-Free software to store your documents is not a very good idea. It's a bit like instead of buying a book, you buy a machine that reads specially-formatted books. But when buying the machine, you have to sign a contract that says you will never look inside these special books or the machine to learn how they work, and the company that you buy it from has the right to stop supporting the machine or your special books at any time. And when they stop supporting your machine (don't worry, they will) and the machine breaks down, you'll have no way to fix it.

These are not the only reasons Free Software is a good idea.

In short, invarient clauses, DRM restrictions and a few other things. See http://people.debian.org/~srivasta/Position_Statem ent.html

Or, closer to the original: "Breathing. If you don't know how to, you shouldn't be messing with environmental oxygenation anyway."

Here's a link to a howto for configuring your Debian installation to use the experimental packages. (It's in section 4.6.4.3, or just search on the page for "experimental".)

Let me guess: You're a CS major, or you are repeating what you heard from a CS major?

We're not anywhere close to approaching the theoretical limits of information security. All you need to do is to subscribe to any number of security announcement mailing lists (e.g. BugTraq or debian-security-announce) and you will see that the number of buffer overflows, arbitrary SQL injection vulnerabilities, and /tmp races -- problems for which solutions have been well-known for years if not decades -- is simply appalling. Heck, just look at the anti-virus industry (and more recently, the anti-spyware industry), something that would not exist if it weren't for the abysmally poor design of today's computing environments.

At least until we get these problems under control, I'm not interested in hearing sermons about Turing completeness, covert channels, and the theoretical futility of ideal information security.

I don't know about you, but this Debian security advisory (+ updated packages) was dated January 20. I ran apt-get update and it showed up on the package list before the advisory was even on the security RSS feed.

I don't know about you, but this Debian security advisory (+ updated packages) was dated January 20. I ran apt-get update and it showed up on the package list before the advisory was even on the security RSS feed.

Yes.

If you don't, is that because you are afraid that They have put spyware in it?

That's part one of the many disadvantages of software having owners.

Is your tin-foil hat comfortable?

Yes, much more so than most commercial software. You should try it out sometimes. Here's a distribution that autoconfigures, runs from CD, has a GUI install and comes with some commercial software, like flash and acroread, as a security blanket.

Debian is planning to fire back about this. The GNU FDL already has this problem, and their developers will be voting soon on a project-wide statement to include a statement that this makes a licence non-free.

I certainly hope that GPLv3 doesn't disagree with the Debian Free Software Guidelines.

> What's apt-get?

http://debian.org/doc/

> What's cupsys?

apt-cache show cupsys

> What's cupsys-driver-gimpprint?

apt-cache show cupsys-driver-gimpprint

> What's cupsys-client?

apt-cache show cupsys-client

> What's cupsys-pt?

apt-cache show cupsys-pt

> And most importantly.... ...why do I need to know all of this
> stuff just to get the printer working in Debian?

Ah, you're a desktop user. Pick 'desktop' when prompted while installing and I believe all this stuff will be installed automatically. You can then go to Desktop -> Administration -> Printing to add your printer.

Good in theory, but when I did just that with the problem I had installing sarge on a Sun UltraSPARC 1E but no-one ever replied! See my report here: http://lists.debian.org/debian-boot/2005/04/msg008 27.html If anyone can give me a pointer I'd be really grateful, I still have the machine gathering dust at home.

I don't think Sarge (Debian 3.1) has a graphical installer. Sarge's Installer page lists downloads which use the NCurses-based text installer. I think you can get the graphical installer with the present 'testing' distribution, Etch, which is expected to become the 'stable' Debian release in December, at this page.

I don't think Sarge (Debian 3.1) has a graphical installer. Sarge's Installer page lists downloads which use the NCurses-based text installer. I think you can get the graphical installer with the present 'testing' distribution, Etch, which is expected to become the 'stable' Debian release in December, at this page.

The Debian SPARC port surely has some issues. It is also not yet officially qualified for Etch.At the moment it doesn't look good. But chances are that it'll make it into the next release. If everyone only complains instead of helping to set the SPARC port back on his feed, its going to take a lot longer.. ;)

The Debian SPARC port surely has some issues. It is also not yet officially qualified for Etch.At the moment it doesn't look good. But chances are that it'll make it into the next release. If everyone only complains instead of helping to set the SPARC port back on his feed, its going to take a lot longer.. ;)

The Debian SPARC port surely has some issues. It is also not yet officially qualified for Etch.At the moment it doesn't look good. But chances are that it'll make it into the next release. If everyone only complains instead of helping to set the SPARC port back on his feed, its going to take a lot longer.. ;)

i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:

• Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in /usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
• package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
• need to understand exactly how service foo starts and stops? you can read /etc/init.d/foo
• where are the config files? you can find them in /etc/foo/
• and so on...

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.

But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.

i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:

• Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in /usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
• package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
• need to understand exactly how service foo starts and stops? you can read /etc/init.d/foo
• where are the config files? you can find them in /etc/foo/
• and so on...

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.

But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.

Bill Gates Loves You.

On this planet, where you know, people need to get things done there is software that works.

Now remove it and install the various Debian packages which make up Qt. Notice how everything is different---binaries are in /usr/bin, libraries are in /usr/share/qt3/lib, headers are in /usr/include/qt3. Try accessing /usr/local/qt/include/qt.h: you can't.

I've administered systems of different ages and for different purposes, and yes, it is frustrating. But that's because package authors tend to choose poor interfaces, and system integrators then modify these interfaces, making things worse. The FHS is not a solution because it mandates different interfaces for the same package, depending on whether it is ``local'' or part of ``the system.'' I'd love it if all packages used a consistent interface which provided global names that don't change, but that's a decision for package authors, not system integrators.

Perhaps you are right that some distributions change things more than Debian. But my main point is that Debian mandates these types of changes in their policy.

Cross-platform compatibility is essential. If the upstream Apache maintainers say Apache can be stopped with apachectl stop, Debian should damn well support this interface. I don't care if they provide /etc/init.d/httpd stop in addition, but they should support the standard interface. This makes life infinitely simpler for people who deal with many different systems---they don't have to keep relearning things. It also makes things simpler for people offering support to Apache users.

The tremendous benefits of cross-platform compatibility come from a package's interface being exactly the same on every system. It is a relatively minor benefit for different packages to have similar interfaces. Breaking cross-platform compatibility, as Debian does, for the sake of cross-package similarity is a horrible idea.

I should point out that I'm picking on Debian here because they are especially bad about this, but almost every major Linux distribution is guilty of unncessarily violating cross-platform compatibility in some way.

"well, if you think Debian is getting too mainstream, there's always the wild wooly frontiers of something like Plan 9..."

Or Debian Hurd.

I'm not saying that your problems aren't real, but Debian certainly supports Sparc and in my experience, it does so very well. I've had nothing but great success with Debian and Sparc, including the installer. Perhaps you should consider filing a bug report with the Debian Installer team. The architectures which have fewer users, receive fewer bug reports. How can you expect them to fix a bug they may not know exists?

As an aside, there is a good chance Sparc will be cut from Etch, so you may not have to worry about Debian "pretending to support SPARC hardware" in the future.

I'm not saying that your problems aren't real, but Debian certainly supports Sparc and in my experience, it does so very well. I've had nothing but great success with Debian and Sparc, including the installer. Perhaps you should consider filing a bug report with the Debian Installer team. The architectures which have fewer users, receive fewer bug reports. How can you expect them to fix a bug they may not know exists?

As an aside, there is a good chance Sparc will be cut from Etch, so you may not have to worry about Debian "pretending to support SPARC hardware" in the future.

Browse through this, it's well worth the read.

Hear hear! Mod parent up.

Haskell is an ideal language for just this sort of thing, and as to performance: have a look at the recent shootout results:

http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=all

GHC Haskell is currently second, right after gcc.

Unstable has 1.5.dfsg-4 for amd64. See here. Give it a little while and it ought to filter down into testing. If you're using stable, then who knows. But testing is as stable as any other distro's release.

Since all deb packages are signed and public key is stored on a different debian server it would take quite a bit of social engineering for the mirror admin to feed you modified packages. Debian people have anticipated this kind of problems, even if signed packages came out only after sarge release.

I can find out if I'm interested. Heck, I could probably get individual names and developer contact info pretty easily...

Can you really rely on the QA process when so many different developers, with different policies and prioirities are involved?

Sure, if they post them online. Here is The Debian Policy Manual Do you have Microsoft's internal coder policies handy?

Can you easily assign patches to different groups of machines from a centralized console, so you can test them internally on a subset of machines?

Yes, it's trivial to set up your own apt repository for testing and deployment

Can you easily remove patches from hundreds of machines if one of the patches turns out to have a nasty bug? Maybe with a lot of scripting...

To be honest, in four years of using Debian I've never had to roll back a patch issued against stable...

FYI, Mono is in Debian unstable already, and it's not even in the non-free repository. Details.