Slashdot Mirror

Just reading the Debian homepage, I see much less to irritate him than I do on, say, http://www.ubuntu.com/

If gNewSense was a fork of Debian (whose full name is "Debian GNU/Linux" btw), we'd have heard about it by now, especially given that Debian is more "Free as in Speech" than "Open Source" (hence closer to rms philosophically than most distros). Who knows, maybe he (rms) is just trying to attach the popularity of Ubuntu to his philosophy... but do you really need a fork for that?

While Debian (main) is 100% free, there are considered-useful packages that are very commonly distributed with Debian that are non-free.

http://nonfree.alioth.debian.org/
http://www.debian.org/social_contract

"We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.... We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian."

The reason the FSF (and RMS) won't promote Debian is because of the non-free components that are in the most common standard installations of Debian.

While Debian (main) is 100% free, there are considered-useful packages that are very commonly distributed with Debian that are non-free.

http://nonfree.alioth.debian.org/
http://www.debian.org/social_contract

"We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.... We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian."

The reason the FSF (and RMS) won't promote Debian is because of the non-free components that are in the most common standard installations of Debian.

Here's my attempt at a solver / generator (Java backend, with a console frontend, a graphical frontend, and a j2me frontend):

http://cons.org.nz/~gringer/

I don't actually find sudoku puzzle *solvers* all that interesting, because they are able to do the solution by brute-force. Sudoku puzzle *generators*, on the other hand, tend to be more difficult, because one requirement for the traditional puzzles is that the puzzle must only have one solution. For puzzle generators that rely on brute-force for their solvers, this "only one solution" requirement is difficult to enforce.

Just to demonstrate this, see the following bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351043

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time.

I can't replicate that result on my box (see measurements below). But even if it's true, doubling is insignificant if you're starting at between 1-10ms to startup.

Here are the results I get on my box (OS X Leopard):

$ time java Hello
hello, world!

real 0m0.145s
user 0m0.080s
sys 0m0.045s

$ time lua hello.lua
Hello, world!

real 0m0.005s
user 0m0.001s
sys 0m0.003s

$ time ./luajit hello.lua
Hello, world!

real 0m0.005s
user 0m0.001s
sys 0m0.003s

Lua and LuaJIT are indistinguishable, and both are either 29x or 80x faster than Java, depending on whether you're measuring by real time or user time.

The JVMs JIT however, doesn't affect startup time at all.

Umm, this supports my point, which is that the JVM sucks for its own reasons, and that having a JIT doesn't imply being as resource-hungry as the JVM.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT [debian.org] or not [debian.org].

This is entirely unrelated to my original point (which was that JITs don't inherently have to be resource pigs). But since I do pretty much hate the JVM I'll take the bait. I've already pointed out the reasons why Java is much more straightforward to optimize than Lua. If you want to compare apples to apples, compare a dynamic languages on the JVM with LuaJIT, like JavaScript Rhino vs. LuaJIT or Groovy vs. LuaJIT. On second thought you might not want to look, the results are kind of embarrassing.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

How very mature of you. I love how you've taken my original argument which was nothing more than "JITs don't have be slow-starting memory hogs" as an argument that Lua is always better than the Java on the JVM. That would be a stupid argument, because there are clearly times when you want a static language with its associated performance characteristics. I happen to think the JVM sucks, but that doesn't mean that I think Lua is always the most appropriate alternative.

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time.

I can't replicate that result on my box (see measurements below). But even if it's true, doubling is insignificant if you're starting at between 1-10ms to startup.

Here are the results I get on my box (OS X Leopard):

$ time java Hello
hello, world!

real 0m0.145s
user 0m0.080s
sys 0m0.045s

$ time lua hello.lua
Hello, world!

real 0m0.005s
user 0m0.001s
sys 0m0.003s

$ time ./luajit hello.lua
Hello, world!

real 0m0.005s
user 0m0.001s
sys 0m0.003s

Lua and LuaJIT are indistinguishable, and both are either 29x or 80x faster than Java, depending on whether you're measuring by real time or user time.

The JVMs JIT however, doesn't affect startup time at all.

Umm, this supports my point, which is that the JVM sucks for its own reasons, and that having a JIT doesn't imply being as resource-hungry as the JVM.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT [debian.org] or not [debian.org].

This is entirely unrelated to my original point (which was that JITs don't inherently have to be resource pigs). But since I do pretty much hate the JVM I'll take the bait. I've already pointed out the reasons why Java is much more straightforward to optimize than Lua. If you want to compare apples to apples, compare a dynamic languages on the JVM with LuaJIT, like JavaScript Rhino vs. LuaJIT or Groovy vs. LuaJIT. On second thought you might not want to look, the results are kind of embarrassing.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

How very mature of you. I love how you've taken my original argument which was nothing more than "JITs don't have be slow-starting memory hogs" as an argument that Lua is always better than the Java on the JVM. That would be a stupid argument, because there are clearly times when you want a static language with its associated performance characteristics. I happen to think the JVM sucks, but that doesn't mean that I think Lua is always the most appropriate alternative.

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time. The JVMs JIT however, doesn't affect startup time at all.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT or not.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time. The JVMs JIT however, doesn't affect startup time at all.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT or not.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time. The JVMs JIT however, doesn't affect startup time at all.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT or not.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time. The JVMs JIT however, doesn't affect startup time at all.

When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT or not.

I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.

JIT is a compiler interleaved with runtime. However JIT is not the only way to do things. JIT has a cost both in language implementation programming effort and runtime performance. If your compiler runs fast in addition to producing fast code, JIT is just a waste of time.

Consider Ikarus Scheme which is only 6 times slower than C. It doesn't use a JIT and it compiles the entire file before using it (i.e. the benchmarks thus include compilation time for Ikarus but not GCC since Ikarus doesn't have a command-line way to compile files before running them). The implementer of Ikarus purposely choose to go that route so he could concentrate on things that have larger impact on performance and as a result puts most other implementations to shame.

Ikarus is living proof that what the GP suggests isn't all that crazy.

Javascript has no hope of being comparable to C speedwise in ordinary use

Funny, since another dynamically dynamic language SBCL Lisp, gets within a factor of 2.0 of C.

Being the same speed? Never.

Being close enough that programmer performance matters more than program performance? Easy.

Here's a link to back you up indicating that C++ is 1.2 times faster than C.

(Disclaimer: Yes, it's a benchmark. Yes, benchmarks are useless. Yes, this isn't even a very good benchmark. See link. But if used properly it can give ballpark performance ranges.)

Here's a link to back you up indicating that C++ is 1.2 times faster than C.

(Disclaimer: Yes, it's a benchmark. Yes, benchmarks are useless. Yes, this isn't even a very good benchmark. See link. But if used properly it can give ballpark performance ranges.)

The overhead of dynamic types is quite immense

That is a common myth but unless you call a factor of 2.0 immense, it it wrong. The truth is that the cost is immense only in the most naive implementations (*cough* ruby *cough). For example, while the compiler has to insert type checks whenever you do something like "+", with a well designed implementation that uses pointer tagging that should cost at most one bitwise-and and one branch-if-zero (with modern CPU pipelines that should cost a fraction of a cycle since the branch should predict fail and in the fail case there is no data dependency). In addition a well designed system will be analyzing the code and eliminate/commonize those checks whenever possible. Finally for really high performance some implementations allow you to run in unsafe mode where those checks are turned off (not applicable to untrusted JavaScript code in a browser but in other applications may be useful).

We could spend all day debating the details of this but in reality it all comes down to the numbers so lets talk numbers. Looking at the programming language shootout, I see Python Psyco, Scheme Ikarus, and Lisp SBCL as implementations of dynamically typed languages. Their performance relative to Intel C are 6.2, 5.9 and 2.0.

Bottom line, will dynamically typed languages always be slower than statically typed languages? Yes, but in good implementations it should only be a small (2-6) factor.

(Note, that Ikarus doesn't even do any heavy code analysis or optimization. It's just a good straight implementation of the language. I note this in case some cry foul that SBCL uses programmer supplied type hints and Psyco uses JIT specialization.)

In terms of performance, C is a lousy language; Fortran is a "faster language" than C.

The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.

Huh? You say that C is a lousy language for performance and then commence to list the reasons why it is a good language for performance?

Anyway... it seems C can be optimized better than Fortran. You are probably basing your statements on theory (and I agree that languages running under JIT could potentially be faster under certain, limited conditions), but real-world examples and benchmarks do not agree with you.

Umm, Lua is a language where global variable references and method calls require hash table lookups, where you can hook your own code into primitive operations like table reads and writes, and where primitive operations like binary operators have to check the types of their arguments at runtime (possibly performing implicit conversion). Java on the other hand knows the types of all data at compile time and can perform all method dispatch with a single pointer dereference.

This point is not whether Java is faster than Lua, the point is that a JIT doesn't have to allocate enough memory to fill a 1987-sized hard drive just to run "Hello, World."

Because really, Java's design makes it very close in features to something like D. But should JIT compiling really make the runtime take 3-18x as much RAM??

Except that Lua actually runs at half the speed of Java, although it does use significantly less ram, as you say.

Except that Lua actually runs at half the speed of Java, although it does use significantly less ram, as you say.

Except that C# code isn't as fast as C code. It's 2.7 times slower.

The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.

For example, take LuaJIT, a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead. It also takes 2-8x less memory and starts up 10x faster than the JVM, despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.

I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.

The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.

For example, take LuaJIT, a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead. It also takes 2-8x less memory and starts up 10x faster than the JVM, despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.

I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.

Every time one of these awful exploits are found, it seems majority of them are Redhat vulnerabilities (with the exception of the recent Debian hole). What's up with that?

I guess you missed the 187 Debian security advisories that have been published so far this year?

Just because many public POC exploits are tailored for RHEL doesn't mean other distros are immune.

Is this bug in OpenSSH related to the one that was found in Debian-related distros back about April?

Debian had a security vulnerability in their openssl package (and it was found in May).

http://www.debian.org/security/2008/dsa-1571

It's not a Google search, it's dict.

Description: Dictionary Client
dict is the client that queries the dictd server. Since it is TCP based, it can access servers on the local host, on a local network, or on the Internet.

Also, the syntax for a Google dictionary search is define:atheism

1) Why are languages like Java used for web applications when they are used for not many local applications?

a) mindshare.
b) libraries. Java GUI libraries are bad. not just not nice; bad, really bad (compare with nice ones like Qt, PowerPlant, wx, etc). the first implementations were also buggy and dog-slow, that's solved now (i think); but the bad taste remains, and today it's not first choice for almost anybody that need a GUI.

2) Why is every web app, after loading fully, very sluggish in my experience? Is the Java(script) inherently slow or do people just implement it poorly?

first, let me repeat that Java and JavaScript doesn't have anything in common, except the first four letters of their name.

now, JavaScript is usually slow because it's poorly implemented (only recently we're getting the first bytecode VMs and JITs); but also because some language definitions are not easily optimizable.

i'm not talking about type strictness, or dynamic (very) late binding. (take a look at Lua to see a beautiful language with similar ideas but far faster than most scripting languages. (Lua vs. Python, LuaJIT vs. Python+Psyco)). There are some nasty details about hash table references, and lack of proper lexical scoping that make an optimizer's work a lot harder.

also, using HTML+DOM for a GUI is a huge performance drag.

1) Why are languages like Java used for web applications when they are used for not many local applications?

a) mindshare.
b) libraries. Java GUI libraries are bad. not just not nice; bad, really bad (compare with nice ones like Qt, PowerPlant, wx, etc). the first implementations were also buggy and dog-slow, that's solved now (i think); but the bad taste remains, and today it's not first choice for almost anybody that need a GUI.

2) Why is every web app, after loading fully, very sluggish in my experience? Is the Java(script) inherently slow or do people just implement it poorly?

first, let me repeat that Java and JavaScript doesn't have anything in common, except the first four letters of their name.

now, JavaScript is usually slow because it's poorly implemented (only recently we're getting the first bytecode VMs and JITs); but also because some language definitions are not easily optimizable.

i'm not talking about type strictness, or dynamic (very) late binding. (take a look at Lua to see a beautiful language with similar ideas but far faster than most scripting languages. (Lua vs. Python, LuaJIT vs. Python+Psyco)). There are some nasty details about hash table references, and lack of proper lexical scoping that make an optimizer's work a lot harder.

also, using HTML+DOM for a GUI is a huge performance drag.

it's faster than java

really?

1. Debian new releases ALWAYS come with release notes that contain upgrade instructions. Follow them. It is usually NOT as simple as a dist-upgrade if you have certain packages installed.
2. Debian stable is generally pretty stable upon release, but feel free to wait a bit if it will make you more comfortable. Just make sure that your sources.list says "etch" and not "stable". When lenny is realeased, etch will become 'oldstable'.

So basically, you've got the right idea. To read the release notes, go to the Debian website and look for the text "If you're upgrading to the latest stable release from a previous version, please read the release notes before proceeding."

That's the best thing about Debian. As long as you at least put forth some degree of effort to RTFM, Debian won't give you many surprises. They make it easy to find and use the documentation.

1. Debian new releases ALWAYS come with release notes that contain upgrade instructions. Follow them. It is usually NOT as simple as a dist-upgrade if you have certain packages installed.
2. Debian stable is generally pretty stable upon release, but feel free to wait a bit if it will make you more comfortable. Just make sure that your sources.list says "etch" and not "stable". When lenny is realeased, etch will become 'oldstable'.

So basically, you've got the right idea. To read the release notes, go to the Debian website and look for the text "If you're upgrading to the latest stable release from a previous version, please read the release notes before proceeding."

That's the best thing about Debian. As long as you at least put forth some degree of effort to RTFM, Debian won't give you many surprises. They make it easy to find and use the documentation.

If you're upgrading to the latest stable release from a previous version, please read the release notes before proceeding.

I'm trying really hard to not make some disparaging comments. Let's just say that ubuntu is for those who can't figure out how to install debian. ;)

To be more helpful, it is indeed possible to simply do an "aptitude update && aptitude dist-upgrade" but it's safer to follow the detailed instructions in the release notes that advise such things as upgrading the kernel first and making a few other precautions that can help resolve some rare problems that can occur. (e.g. if your system happens to get powered off in the middle of the upgrade)

If you're upgrading to the latest stable release from a previous version, please read the release notes before proceeding.

I'm trying really hard to not make some disparaging comments. Let's just say that ubuntu is for those who can't figure out how to install debian. ;)

To be more helpful, it is indeed possible to simply do an "aptitude update && aptitude dist-upgrade" but it's safer to follow the detailed instructions in the release notes that advise such things as upgrading the kernel first and making a few other precautions that can help resolve some rare problems that can occur. (e.g. if your system happens to get powered off in the middle of the upgrade)

Just to note: you should use aptitude rather and apt-get.

I think this has been officially the case for some time now, and the former's handling of various situations is considered superior.

BTW. I've rarely had problems in such upgrades, but I agree, without physical access you should read the release notes (as noted already these will be here with great care. You will see they do advocate aptitude.

Leave it alone and only apply the security updates. I have a server happily running sarge that I have no plans to change.

Ummm.. you know that sarge no longer gets security updates, right? :S (announcement)

I read The Fine Article; a few comments on the author's article:

Iceweasel
=-=-=-=-=
One of the complaints is that he wants "real" Firefox rather than the renamed Iceweasel. Well, until the Mozilla Foundation says differently, that isn't possible. Mozilla withdrew their prior permission to ship Firefox with a replaced logo that fit the Debian Free Software Guidelines, and the only way to comply with both Mozilla and the DFSG was to rename the application. So if you want to complain about this, write to Mozilla. I think Debian totally made the right choice to rename.

Shorter explanation:
      http://en.wikipedia.org/wiki/GNU_IceCat
Longer explanation:
      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622

Playing a DVD
=-=-=-=-=-=-=
The author wasn't able to test playing a DVD; normal movie DVDs that use encryption won't play out of the box. This is because Debian cannot ship libdvdcss2 as part of the main distribution for legal reasons, same as other distributions. There are other external repositories (outside of the US) that contain libdvdcss2 -- but it may not be legal to import the package into the US. You might find some choices if you put "Debian" and "multimedia" into Google and see what comes up.

Modem
=-=-=-=
Wow, the author set up the POTS modem. When is the last time you had to use one of those? Gotta give him credit for going through that effort.

- Chris

Because you said a netinstall is out of the question, might I suggest to first install a core CLI-only system? For example, these Debian ISOs are only 180MB in size and contain enough to get yourself up and running. From there you have a full Debian system at your disposal - you can configure your 802.11 and WPA2 settings and pull down KDE via apt-get as needed.

I see 3 install ISOs. Debian has 21 images, but you only really need the first one to install with a GUI. IIRC, openSUSE 10.1 required a minimum of 3 discs out of 5. So tell me: Which ISOs do I need to have KDE installed at boot? My ISP doesn't like it when I download CD images, so I want to avoid downloading all three if at all possible. Unfortunately, I am not connected to the Internet by a wire, so unless one can use a WPA2 wifi connection during the installation, a netinstall is out of the question. Thanks.

1. Release notes will be here (right now they contain the etch release notes).
2. You probably will have to type apt-get dist-upgrade a couple of times (I usually average two). Reason is first couple of times, some packages will be stuck because of conflicting versioning, but it usually fixes itself once you get a couple of packages upgraded (usually once you get past libc and the kernel)

Generally speaking, Debian upgrade is much more painless than Ubuntu upgrades, IMO, possibly because of the longer release cycle. My Debian systems usually have some mixture of stable and backports, and I don't remember having any problems upgrading. Even desktops where I am third-party repos outside backports, I don't have any problems.

One thing you might want to do, especially if you don't have physical access to the server, is to wait a week to upgrade to see if there is a huge problem with other people's upgrade.

Generally -- except in one notable case, and expected in Debian lenny. As you can imagine, this caused a lot of complaints. From what I skimmed there and other places, the attitude is that /bin/sh under Debian should be a fully POSIX-compliant shell, and if you want to use bashisms, start your program with #!/bin/bash.

I don't really want to switch over to Ruby / Python, largely for performance reasons

Why, do you need your language to be slower than Python but not slower than PHP?

I don't really want to switch over to Ruby / Python, largely for performance reasons

Why, do you need your language to be slower than Python but not slower than PHP?

One thing I can say in favor of Red Hat. I used to use Debian at home (now I use Gnewsense, a knockoff of Ubuntu, which is a knockoff of Debian). For many months, the "search the contents of a package" feature was disabled on Debian's website. So if I wanted the program "sftp" but didn't know it was in package openssh-client, I could search there and discover that. But Debian just decided to take it down for a few months. Red Hat would not do that for so long, if at all, and if they did I could call and complain.

As a side note: you probably should have mailed the debian-user list and complained about that :) Someone would probably have told you that every Debian mirror has a set of index files called e.g. "Contents-i386.gz", which contain that information (and are regularly updated if the packages change). They're sitting over there in dists/stable/ on any mirror (and if you use "testing" or "unstable", it's analogous). You can download the file and search inside it. For example:

% wget http://ftp.us.debian.org/debian/dists/stable/Contents-i386.gz
[...]
% zgrep bin/sftp Contents-i386.gz
usr/bin/sftp net/openssh-client
usr/sbin/sftp-server.lsh net/lsh-server

Mac OS X 10.5 Leopard:
$129 for a single license ($199 for a family pack)

Microsoft Windows Vista Home Premium Edition:
239.99 for a single license.

Microsoft Windows XP Pro:
$199 for a single licence.

and, of course,
Debian GNU/Linux
$0, unlimited installs.

Stick OS X on a Psystar or Hackintosh, and it is cheaper. Or, if you go with a Mac Pro, the price is competitive with as-powerful hardware.

If a standard base could be setup that still allows for distros to be unique, but also allows for them to work together a lot better, then we will see an increase in applications made for linux, both open and closed source.

Here you go.

with say Spain the most conservative and the Scandinavians the most progressive.

Spain does some pretty cool things, e.g. read the very good interview with a dev of the Extremadura Linux dist. and a Debian announce about Linux in Extremadura. Not sure about Scandinavia, Norway does good things but Denmark and Sweden seems very backward in my personal opinion.

Although that's generally true, it's not always — and these cases are the more noticeable for the harm they cause. Pidgin is an excellent case in point. The developers have actively removed features and refused to even consider adding them, even though the new methods are completely unusable for many people.

This, plus a few other programs I've updated in the last few months — Mozilla's gecko to the Firefox 3-based version, Gnome's power manager are two of the most prominant — have also changed in ways that have made my computer go from being invisible and useful to getting in my way. Aside from switching from Thunderbird to Balsa and adding a few new programs like Skype and unclutter, I haven't changed my environment in years. It's a shame that it looks like I might have to rework my computer if it's going to be useful, and not the detestable chore most Windows users computers seem to be.

Yes, but the software itself is not illegal. Does Blizzard have a right to ban you from WoW if you cheat? Yes. Can Blizzard ban you in real life... no.

Hmmm... Lets see about BNETd... http://packages.debian.org/search?keywords=bnetd oh wait... I can install it in Debian

Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: bnetd 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 363kB of archives. After unpacking 1102kB of additional disk space will be used. Get:1 http://us.archive.ubuntu.com/ gutsy/universe bnetd 0.4.25-6 [363kB] Fetched 363kB in 2s (151kB/s) Selecting previously deselected package bnetd. (Reading database ... 100562 files and directories currently installed.) Unpacking bnetd (from .../bnetd_0.4.25-6_i386.deb) ... Setting up bnetd (0.4.25-6) ... [: 17: ==: unexpected operator Starting Battle.net(R) gaming server: bnetd.

OMG! I just installed it from Ubuntu!!!

Sure, development may have stopped, but you can still get it.

GPL version is in the main repositories here

VirtualBox's greatest failing is that in using QEMU's I/O and networking code, they've made it a royal pain to set up bridged-mode networking on Linux hosts. You get to write two scripts, to add and remove a TAP device from a host-side bridge, and get to set up said bridge on the host yourself. Not only this, since the 2.6.18 kernel you need to run VirtualBox VMs as root (or set up sudo with /etc/sudoers not to prompt for a password and use it within your scripts), because only the superuser can manipulate the TAP/TUN devices; chmodding them writable by a particular privileged group is insufficient.

Compare to VMware, which handles all the bridging etc. by itself—much more convenient to use.

Then there are VirtualBox's "Guru meditations", obscure ERROR_MESSAGES_THAT_LOOK_LIKE_THIS and provide minimal information, often requiring perusal of the source code to figure out what's wrong. This is entirely unsuitable for end users as well as people whose time is valuable.

Finally, I tend to run a 64-bit kernel with 32-bit userspace. VirtualBox does not support this combination—it's either 32-bit kernel with 32-bit userspace or 64-bit kernel with 64-bit userspace. (VMware on the other hand does support 64-bit kernel with 32-bit userspace; its failing is that [as far as I know] there is no non-beta 64-bit userspace for VMware yet, though this will change with the release of VMware Server 2.0 and VMware Workstation 6.5.) This is only really a problem on Debian and Debian-derived distributions like Ubuntu, whose package manager (dpkg) is too incompetent to handle multiarch properly, despite work ongoing for about four years now, so the user has to set up a 64-bit chroot environment. (Fedora, RHEL and CentOS get this right; rpm can handle multiarch properly, so it's only a matter of installing the appropriate libraries there.)

VMware also supports 64-bit guests on certain processors. VirtualBox doesn't support 64-bit guests at all.

So in my view, between the two, VMware still wins, open source or no open source.