Slashdot Mirror

There is already a competitive market for creative works - if you don't want to play Spore you're welcome to play another game instead

As I understand it, you mean something like playing Lockjaw instead of Tetris, or some off-brand ludo board game if I don't want Hasbro's Trouble, Sorry!, Aggravation, or Parcheesi. I'll take you up on that offer if you can answer one question: Which Free game with similar rules to Spore would you recommend?

I don't even see why there is a discussion going on here. Seriously, nothing could possibly be easier than getting an old box, installing a netinstall cd of debian http://www.debian.org/CD/netinst/ setting up a raid1 or 5 during the installation. Once it is installed and reboots (10 minutes), then use aptitude to install your NAS stuff, either samba or nfs. Very easy. It gets tricker to have different levels of users with different permissions but it can be done, the tutorials are out there. I run a min install of debian on everything I have. No I have never done a NAS solution but I saw a guy do it once on a movie

Beats the heck out of a cheesy slow $300+ embeded solution.

alien

You can pay me in jellybeans.

I suggest Flight Gear flight simulator. Any modern computer should be able to run it, it is not as graphics intensive as you might think, just need OpenGL. Great game, fun to play and also teaches the physics of flight and world geography. My kids and I love it! You can find pre-built Debian packages at http://packages.debian.org/sid/flightgear they should install just fine on Ubuntu.

My machines (all laptops/netbooks, I do not like desktops because they eat lots of power and are thus anti-ecological) are now equipped with SSDs for the OS (Debian GNU/Linux) and for non-OS stuff, which is actually very little, I just plug some fast SD or CF memory cards or roomy USB flash drives. I do not use any hard disks anymore, except for a few old machines that I hardly use now or for my servers. Everything works great. I feel as if I am running supercomputers - it's so fast. Just to make sure my SSDs will live for a long time, I use ext2 instead of ext3/ext4, and I configured my /tmp to live in a tmpfs filesystem. Filesystem fixing takes just a few seconds with SSDs, so the speed advantage of journaling ext3/ext4 does not hold anymore, and after all I never liked journaling filesystems at all. I see no reason why anyone would want an SSD bigger than 32GB/64GB for an OS, except for booting multiple OSes. For those running games or other programs that need fast disk access, it is always possible to plug an external SSD over eSATA (or Firewire) or put multiple SSDs into your machines if the motherboard supports that.

I abandonded slack for debian over a decade ago... Back in the day there wasn't much friendliness about slack at all, so I can't comment on slack's source friendliness. I can give you my debian source experiences to compare though.

Debian offers source for all its packages, so just using "apt-get source <package>" would get the source package and debian diffs. I never use that. If software is available in a binary package I will just apt-get it, if I want to compile from source it's probably because I want some (version of) software not offered by the Debian packages.

I've compiled all kinds of apps from source be it in c, c++, ocaml or python... the only thing I've ran into are missing libraries. So I apt-get the lib<..>-dev and try again until it works ;-) Sometimes I don't know what dev lib package it needs and I need to search the packages for the file configure complains about. Apt-cache search to the rescue, or often just this debian page

It might be worth noting that I always chose to do a minimum install and add things when I need them. I'm pretty sure the installation offers a development task you can add so you won't need to apt-get many dev libraries, if any at all.

All these comments about slack srsly make me want to see what's become of it... Good thing I'm getting a new machine with 4GB of ram this week *cheer*... good ole slack's gonna be the first install in my new virtualization playground.... :)

Faster by far, just don't expect to run gnome or kde desktops, which are the default window manager/desktops in most distros. The more RAM you have the better off you will be. 500MB will do nicely.

Install debian by downloading the CD and burning it: http://cdimage.debian.org/cdimage/lenny_di_rc1/i386/iso-cd/debian-testing-i386-netinst.iso

Follow these instructions to get an XFCE desktop: http://wiki.debian.org/DebianXFCE

Faster by far, just don't expect to run gnome or kde desktops, which are the default window manager/desktops in most distros. The more RAM you have the better off you will be. 500MB will do nicely.

Install debian by downloading the CD and burning it: http://cdimage.debian.org/cdimage/lenny_di_rc1/i386/iso-cd/debian-testing-i386-netinst.iso

Follow these instructions to get an XFCE desktop: http://wiki.debian.org/DebianXFCE

There are several entities involved with the proliferation and development of Linux and its components. One of the more notable examples is Red Hat.

Here are some contributors to debian

One could think of it being like: many people put together computers. Some people build them at home, while large companies such as Dell sell by volume. They have a large array of companies supplying parts and components, and you can't really say that one is more valuable than the other.

Debian Edu / Skolelinux

Debian Edu
* is a Debian project to make the best distribution for educational purposes.

Skolelinux
is the name of a Debian Pure Blend which is produced by the Debian Edu project.
"Skole" ([skuËl]) is the Norwegian form of "school". Both "skole" and "school" comes from the Latin word "schola".

Goals

* Provide a complete software solution using free software and ...
* tailored for the needs and use-cases in educational scenarios.
* preconfigured for easy installation (standalone, as well as network-wide rollout).
* easy to use, maintain, and administer.
* supporting your language natively.
* Classify and package all free software related to education.
* Write documentation to describe how to use the various softwares (in an educational context).
* International availability, currently being translated into XX languages

I know there are Ruby on Rails camps and Python advocates, however does not PHP still run faster than either? (Take the same programmer, writing code with expert knowledge with all three programming languages, would not his final product , from a strictly performance issue in PHP be faster than Ruby or Pythong?) Considering that PHP was written with the web in mind and delivering web pages...do you really want anything else from strictly performance issues?

You're mixing languages and platforms up a bit, and it is the implementation that usually has a bigger bearing on speed than the language itself. But don't assume PHP is automatically the fastest.

eg with PHP, a given chunk of PHP code on mod_php is way faster than running the same code as a traditional CGI script which reloads the whole interpreter for every request. And now there are FastCGI implementations etc that can outperform Apache/mod_php a lot of the time. Then you can get into op caches etc. There will be a huge range of performance for that same code depending on how it runs. For the most part though, PHP code gets loaded for each request rather than being processed by a long running process that already has the code in memory ready to run.

Yeah Rails has a reputation as a slow platform, and the current Ruby implementations are also a bit slower than other languages implementations too. But comparing PHP to Rails is an apples to oranges comparison anyway - you'd need to compare a full stack framework written in PHP (eg Cake or Symphony etc) to Rails for a more meaningful comparison.

And Python is also all over the place in terms of implementation performance depending on what it runs on/as. You can run a Python script as a CGI, or using mod_python in Apache. You can run it on a Rails like framework (eg Django etc etc) with long running processes etc etc etc.

Also Ruby and Python have multiple implementations of the language itself - eg IronPython and IronRuby on .NET, Jython and JRuby on Java. These .NET and Java implementations show some promise, and don't have the threading limitations that the native Ruby and Python implementations have. There also seem to be a bunch of other experimental implementations as well.

And then most web app performance usually ends up being limited by the database anyway.

And to finish off here's some probably meaningless benchmarks: PHP vs Python Python vs Ruby Ruby vs PHP

I know there are Ruby on Rails camps and Python advocates, however does not PHP still run faster than either? (Take the same programmer, writing code with expert knowledge with all three programming languages, would not his final product , from a strictly performance issue in PHP be faster than Ruby or Pythong?) Considering that PHP was written with the web in mind and delivering web pages...do you really want anything else from strictly performance issues?

You're mixing languages and platforms up a bit, and it is the implementation that usually has a bigger bearing on speed than the language itself. But don't assume PHP is automatically the fastest.

eg with PHP, a given chunk of PHP code on mod_php is way faster than running the same code as a traditional CGI script which reloads the whole interpreter for every request. And now there are FastCGI implementations etc that can outperform Apache/mod_php a lot of the time. Then you can get into op caches etc. There will be a huge range of performance for that same code depending on how it runs. For the most part though, PHP code gets loaded for each request rather than being processed by a long running process that already has the code in memory ready to run.

Yeah Rails has a reputation as a slow platform, and the current Ruby implementations are also a bit slower than other languages implementations too. But comparing PHP to Rails is an apples to oranges comparison anyway - you'd need to compare a full stack framework written in PHP (eg Cake or Symphony etc) to Rails for a more meaningful comparison.

And Python is also all over the place in terms of implementation performance depending on what it runs on/as. You can run a Python script as a CGI, or using mod_python in Apache. You can run it on a Rails like framework (eg Django etc etc) with long running processes etc etc etc.

Also Ruby and Python have multiple implementations of the language itself - eg IronPython and IronRuby on .NET, Jython and JRuby on Java. These .NET and Java implementations show some promise, and don't have the threading limitations that the native Ruby and Python implementations have. There also seem to be a bunch of other experimental implementations as well.

And then most web app performance usually ends up being limited by the database anyway.

And to finish off here's some probably meaningless benchmarks: PHP vs Python Python vs Ruby Ruby vs PHP

I know there are Ruby on Rails camps and Python advocates, however does not PHP still run faster than either? (Take the same programmer, writing code with expert knowledge with all three programming languages, would not his final product , from a strictly performance issue in PHP be faster than Ruby or Pythong?) Considering that PHP was written with the web in mind and delivering web pages...do you really want anything else from strictly performance issues?

You're mixing languages and platforms up a bit, and it is the implementation that usually has a bigger bearing on speed than the language itself. But don't assume PHP is automatically the fastest.

eg with PHP, a given chunk of PHP code on mod_php is way faster than running the same code as a traditional CGI script which reloads the whole interpreter for every request. And now there are FastCGI implementations etc that can outperform Apache/mod_php a lot of the time. Then you can get into op caches etc. There will be a huge range of performance for that same code depending on how it runs. For the most part though, PHP code gets loaded for each request rather than being processed by a long running process that already has the code in memory ready to run.

Yeah Rails has a reputation as a slow platform, and the current Ruby implementations are also a bit slower than other languages implementations too. But comparing PHP to Rails is an apples to oranges comparison anyway - you'd need to compare a full stack framework written in PHP (eg Cake or Symphony etc) to Rails for a more meaningful comparison.

And Python is also all over the place in terms of implementation performance depending on what it runs on/as. You can run a Python script as a CGI, or using mod_python in Apache. You can run it on a Rails like framework (eg Django etc etc) with long running processes etc etc etc.

Also Ruby and Python have multiple implementations of the language itself - eg IronPython and IronRuby on .NET, Jython and JRuby on Java. These .NET and Java implementations show some promise, and don't have the threading limitations that the native Ruby and Python implementations have. There also seem to be a bunch of other experimental implementations as well.

And then most web app performance usually ends up being limited by the database anyway.

And to finish off here's some probably meaningless benchmarks: PHP vs Python Python vs Ruby Ruby vs PHP

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=perl&lang2=ruby

Have a look here for some benchmarks: http://shootout.alioth.debian.org/

Speaking about language speed, how does it come that Lisp always comes out rather high in those rankings, while newer languages like Ruby and Python and up deep down at the bottom? In terms of expressiveness they all are very similar, yet nobody seems to have bothered to write a proper native code compiler for the newer languages, even so the popular interest in them is much larger then that for Lisp. Is there any fundamental reason for this?

One thing needs to be understood however: the speed of a library like Gtk has nothing whatsoever to do with the speed of an application coded in a particular language (like C or C++). Don't confuse the efficiency of a language (implementation) with that of a popular graphics library coded in that language.

Have a look here for some benchmarks: http://shootout.alioth.debian.org/

On these benchmarks (and on Sometimes C and C++ end up as the fastest of the pack, sometimes they don't (contrary to the usual opinion of Slashdot commenters). Fortran wins several times. However, C and C++ always tend to be in the top-10%.

A rule of thumb I use:

(1) If it's floating-point centred, and especially linear-algebra centred (Linpack, LAPACK, Eispack), Fortran is likely to be fastest, certainly not C or C++. However ... Matlab, Octave, Scilab etc. tend to be quite competitive when the work can be formulated in terms of high-level matrix operations (so that the overhead caused by the interpreter can be made up for by the excellence of hand-optimized assembler libraries). Besides they get the job done in one tenth of the time it takes to code from scratch in Fortran, and you get a far better chance of getting things right the first time.

(2) If it's centred on manipulating data-structures (trees, heaps, allocation. eallocation, moving, traversing, counting, coding) which relies mostly on pointer juggling, then C and C++ tend to be fastest.

(3) For everything else ... try to find real-world examples.

This may be of interest.

debian has a keysigning process that creates a web of trust.

http://www.chaosreigns.com/code/sig2dot/debian.html
http://www.debian.org/events/keysigning

Epiphany works perfectly for me: small, clean, with support for custom stylesheets (which I use a lot, primarily to place serif fonts in place of these fscking sans-serif fonts some webmasters seem to be brainwashed in thinking that they are easier to read on screen), and upgradeable through extensions (either the included ones, third-party ones, or your own as it is very easy to build one). It even has support for both gecko and webkit (gecko seems to be working better on Debian GNU/Linux lenny/5.0 so I still use it even though webkit is now considered the preferred engine). A real full-screen view a-la Firefox 3.0 would be great to have by default, but never mind.

With all due respect to Ryan, I agree with Monty here. Not just 5.1, but the whole MySQL 5.x tree has been shipping with release critical bugs. What's more, some of those bugs (like the one that has been open since 2003) have lowered priority now because "people know about them."

It sounds like MySQL could benefit from a more debian-like release criteria.

I'm inclined to agree, but, apparently, there are hardware manufacturers who sue anyone who distributes their binary blobs without permission, but are quite happy to give Ubuntu and Debian and Redhat permission.. Freedom is not having to ask permission.

The Debian Free Software Guidelines (paragraph 8) clearly says that "License Must Not Be Specific to Debian".

http://www.debian.org/social_contract

Like the article tells, Debian developers are currently negotiating if the firmware blobs should be removed before or after the Lenny release. In any case, Debian developers are removing all the kernel binary blobs from their main repository and they won't distribute any software where the distribution license is not the same for everyone.

AFAIK, the Debian installer for Lenny already checks your hardware and it prompts for additional non-free packages of drivers or firmware (which the user needs to download separately from the installer) if your hardware needs them to work properly. Then it's up to the user to decide if non-free drivers or firmware will be installed.

A free Java is now in Debian.

Debian's been working on kernel independence for years now, both GNU and non-GNU.

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

http://www.debian.org/ports/netbsd/
http://www.debian.org/ports/kfreebsd-gnu/

Of course, to get attention from fanboi sites, they chose to use Ubuntu.

Debian's been working on kernel independence for years now, both GNU and non-GNU.

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

http://www.debian.org/ports/netbsd/
http://www.debian.org/ports/kfreebsd-gnu/

Of course, to get attention from fanboi sites, they chose to use Ubuntu.

Debian's been working on kernel independence for years now, both GNU and non-GNU.

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

http://www.debian.org/ports/netbsd/
http://www.debian.org/ports/kfreebsd-gnu/

Of course, to get attention from fanboi sites, they chose to use Ubuntu.

Replacing Linux with FreeBSD's kernel gives GNU/kfreebsd. Could Nexenta's OS be called GNU/Solaris or maybe GNU/kopensolaris?

The first one is legit, the other two are weird.

Indeed. Comment 39 is especially insightful:

The distinction here is that the firefox name is just a name, covered only by trademark law (not by copyright law), but a logo is a work of art, covered both by copyright law and trademark law. Applying trademark-*like* restrictions on a work of art in its copyright license prevents our users from doing things with that work that they are allowed to do with other free artwork, *and* which are permitted under trademark law. For instance, a trademark is limited to a field of endeavour, so using the logo in an unrelated field is permitted by trademark law but not permitted by the copyright license; or, a logo may be used as a starting point for another work of art which is a derivative *work* under copyright law, but is not a derivative *mark* under trademark law.

These are corner cases, but they are nevertheless important to Debian, as we're committed to providing our users an operating system consisting entirely of material that they have the right to modify, reuse, and redistribute (trademarks not withstanding). Of course, we've had problems living up to this even where our own trademarks are concerned, so Debian as a whole is likely to be forgiving of logo licensing problems in the near term, but the package maintainers don't *have* to avail themselves of such leniency, and it's my understanding that Eric has already decided it's in Debian's best interest to not ship the logos under a non-free copyright license.

Is the sticking point in all of this truly that the Mozilla Foundation finds it unacceptable to ship a browser named firefox which uses the non-trademarked logos, or is it that we've broken the configure option that others are expected to use when getting the un-branded version? I.e., would it be suitable if Debian updated its patch to add a separate "name but no logos" configure option, leaving the original "no name, no logos" option intact?

Let me also add the the MPL, GPL3, and LGPL3 already explicitly include the disclaimer that they do not override trademark law. It is, thus, completely irrational to fear that Freeing a logo would dilute its trademark. As if trademark law weren't already enforced beyond Reason in this modern world! Other projects don't seem to have a problem doing the Right Thing with their artwork (such as KDE). It hurts me greatly to see projects that I love so much, such as Mozilla and Fedora, turn to the evils of copyright (as opposed to copyleft) for no good reason whatsoever.

Well, you better erase that Linux distro off your hard drive if you'll only use software that doesn't use trademarked names. No, no, you can't use Debian either, because the name Linux is trademarked, too.

WRONG. It was never entirely about trademark. It was initially about the copyright status of the artwork for Firefox (the restrictive, all rights reserved "license"). Debian removed those artworks as they violate DFSG, and Mozilla Foundation said that Debian can't use the Firefox name at all if they do not use the official branding.

As for Debian's own logos and branding, they are in fact distributed with an open license (with a varying degree of openness depending on how official it is), so you are free to take them, modify them, and even distribute them (like fan art). The only thing you can't do is fraudulently claim some modified version of GNU/Linux distribution you have is the official Debian distro (i.e. the only thing that the trademark law really governs).

Don't misquote him and then argue against the misquotation. He said the license criteria are derived from the FSF's. You changed it to the licenses. He's talking about how the Open Source Definition was based on the Debian Free Software Guidelines, and he's absolutely right.

It is not. The Firefox logo is not free. Thus, any software that includes that logo is non-free also, and Debian developers know it very well

What about software whose documentation is not "Free"? Like the GNU project documentation?

What do you say about that? Where is my "unconstrained right to learn, and to change the docs as I see fit"?

I mention that since Debian folks at least have the consistency of also considering that also as "non-Free'.

An operating system is a system composed of a task scheduler, memory manager, hardware interface, etc.

Increasingly, the hardware interface is moving out of the kernel. In a Linux-based operating environment (is that a better word?), the X11 server runs in user space, so do some file systems such as the NTFS driver for FUSE, and so do drivers for devices such as printers and scanners.

Let's face it, the utilities, although indispensable, are much less visible than the applications.

So would you say FreeBSD is as close to Debian GNU/kFreeBSD as Ubuntu is to Fedora?

It is not. The Firefox logo is not free. Thus, any software that includes that logo is non-free also, and Debian developers know it very well

Say what you want about Apple/Microsoft/Sun/whatever, but nothing beats Beamer (plus KeyJnote if you are talking to idiots impressed by bling).

What about release critical bugs? Currently there are 173 of them:
http://bugs.debian.org/release-critical/

I thought that they won't be releasing next version before they are fixed. And even with optimal speed it looks like it would take at least 1,5 months to get them all fixed.

And some estimate that it would be 2009-06 before the release happens:
http://blog.venthur.de/2008/10/07/lennys-release-date/

if the sweet spot in capable of providing solutions at the time of the build, then it is still capable 5 years down the road.

Why limit oneself to five years? If I run free software and high-quality components, I can avoid the haßle of a new setup for longer.

They already provide freely downloadable tools

Not free software tools.

for processing the encoded RAW footage into more common formats (http://www.red.com/support REDCine works on Intel Mac or Windows)

Not on any other platform.

and can export to TIFF, JPEG, and OpenEXR (and possibly more, those were just the ones I saw mentioned in the latest release notes).

What about the format which counts in digital still photography, namely Adobe DNG?

They're also putting out a SDK for the format so it can be integrated into more software. It's not exactly locked down.

If one can't see the source code of the SDK or at least the specifications of the file format, it is locked down. And I bet one cannot use the SDK in free software, nor in anyðing but MS Windows and Mac OS X AMD64.

And what's so bad about replacing often?

Convenience. I tend to use e highest quality equipment I can afford, and to run free software, so I don't need to reinstall or worry much about machines and OS. Having to reinstall because e machine is obsolete is someðing I want to postpone as much as poßible.

Replace it with DFSG+DFHS... You could toss the Java and Menu policies in there too for good measure...

LSB lets third parties put their crap almost anywhere they want on your system and they're still compliant (Did that package you just installed land in /usr, /usr/share, /opt? Is it's data under it's own directory, or is it in /srv, /var, or /home/something? Are its configuration files in /etc, or somewhere else?). We essentially *have* chaos. Third party (commercial) software almost entirely abandons the standard due to its deficiencies, and does whatever it pleases using a myriad of third-party installers. Even Microsoft got with the picture and made MSI, turning RPM into a further embarrassment.

Alternatively, LSB could be scrubbed of the stupid political concessions and re-written by an independent body with no ties to any of the big corporate distributions. It should include strict filesystem guidelines (one place for configuration files. one place for libraries, etc), and a packaging format that allows for interactive installations as well as scriptable installations.

http://support.apple.com/kb/HT1222
https://help.ubuntu.com/community/AutomaticSecurityUpdates
http://www.debian.org/security/
http://www.freebsd.org/security/advisories.html
http://www.netbsd.org/support/security/

Don't be a pretentious prick. Every OS out there has to have security updates.

If anyone running a Linux system simply adopts a self-imposed policy of "I will only install software from the repositories using the package management system" ... then their system is guaranteed to never get malware.
Is that so?

There's more out there in high-level land than the current crop of scripting languages.

It's funny you mention that Python isn't QUITE fast enough to write an operating system in. I'd say it's dead-slow to write an operating in. Some guys at OLPC thought it was a good idea to write a window-manager in Python. And that is already dead-slow. Python as of now is still an interpreted scripting language. And I wouldn't exactly set the bar as low as to take PHP as a classic example of a fast, well designed language. I'm sure even the most rabid PHP fanboi (if they even exist), will agree with me.

There are a good number of high-level languages which are a good bit more flexible at a much higher performance rate than Python. Take some of the functional languages like Haskell or ML, Lisps like CL or Scheme, or Forth or Smalltalk. Not that shootouts say everything, but just compare a few benchmarks at http://shootout.alioth.debian.org/

And why are they faster? Because they can be (byte-)compiled quite efficiently. Python however was never designed with compiling in mind. And as such, there still isn't a worthy full-fledged Python compiler for real-live use. And as I understand it, Python is very dynamic in a way that's gonna be quite hard to compile.

Now Python is an elegant scripting language that is easy to pick up, has a nice and big standard library and has it's niche, but people that dare to write ' is vastly superior, both in overall design and performance, to other languages that provide a similar level of abstraction', either blatantly choose to ignore decennia of computer science, or still have a lot of cool stuff to learn.

Well, apparently they haven't advanced beyond the 1990s fad of chatterbots then.

Audacious peaked around version 1.4.5. Try to get the packages for that version (player + plugins) installed (for Debian look on snapshot.debian.net) then pin the version and stick with it.

1.5.x seems more and more buggy and unstable everyday. It crashes frequently and it has rendered my equalized useless, perfectly good settings that have worked for me for years suddenly produce distorted loud sound.

And 2.0 intends to make the classic mistake all Winamp clones have made to their own demise: to stop being like Winamp 2.0.

They could just fix the "Add or Remove Software" applet so it points towards a collection of optional software hosted on a secure server.

Sort of like a useful "Application" that's used to "Get" other applications. They could call it "Application Getter" or just appl-get for short. No, it wouldn't be confusing.

One thing that I wish Canonical would do is to set up a donation fund where I could donate say $50 per install and know that all the apps that come with Ubuntu would get a reasonably fair share of that money. Is anyone at Canonical listening?

I think Canonical tells people to donate to Debian if you want to support the development of the software.

http://www.debian.org/donations

I love doing:

wget -qO- http://cdimage.debian.org/debian-cd/4.0_r5/i386/iso-cd/debian-40r5-i386-netinst.iso | cdrecord

Straight from the net to my cd-burner. Try to do that with Windows...

Any files in /usr/local were provided by you, not Ubuntu. I have apache2 installed here on my Ubuntu box, and my /usr/local/lib directory is empty. Debian policy (which Ubuntu is based on) reserves /usr/local 100% for the local admin, and forbids packages from putting anything in that hierarchy except empty directories. (See section 9.1.2.)

Or to put it another way, no, /usr/local/libz.so.1.2.3.3 is not the "right" one. It's another wrong one that happens to be working for you. For now. The right one is /usr/lib/libz.so.1.2.3.3. Next time you upgrade, that /usr/local version is going to bite you in the ass again.

Ubuntu can do a fine job of updating itself, but it's hardly going to be able to upgrade 3rd-party software you installed manually, now, is it?

(Windows is a different case, of course, since Windows doesn't come with any useful software in the first place.) :)

I guess we have a different opinion on the meaning of "out of the box".

If you pick the "Desktop environment" "task" during a Debian net install, you get GNOME by default. That's what I meant by "out of the box". I'd say going with the base install and using apt-get to install what you need to be "extra work" and require "extra" knowledge. That's not a bad thing, but somebody expecting a lightweight install might be surprised.

On the other hand, the default installs for distros like Damn Small Linux or Puppy Linux include lightweight window managers (JWM, Fluxbox, XFCE) automatically.

My Debian GNU/Linux also outperforms it. Every GNU/Linux and BSD system does. Nothing special about Ubuntu.