The ultimate issue is that renames (or moves) are implemented as delete+addition operations. Maybe back in the day, that appeared to be ok, but now its obvious it's a large failing.

That's not the problem. Mercurial also does this, and nobody (at least on slashdot :-) is complaining about Mercurial's rename implementation. If you look closely, Mercurial has problems with its rename implementation, as does *gasp* git. See my BSc thesis for details: https://www.inf.fu-berlin.de/w/SE/ThesisTreeConflicts

The problem with Subversion's implementation is that people are much more likely to run into some of its very annoying shortcomings in practice. But there are only a handful of cases which Subversion needs to handle better to catch up (though making these cases happen is a lot of work, see my other comment here: http://news.slashdot.org/comments.pl?sid=1934004&cid=34755596).

Take a look at the tables on pages 29 and 30 in the thesis pdf. Note that these were based on Subversion 1.5 behaviour. Subversion 1.6 already detects more of these cases than git and hg combined, but it doesn't even try to automatically resolve any of them, even trivial cases. This is why hg's and git's merging are working nicer in practice right now. In theory there is no tool that hasn't got severe problems if you put the bar up high enough. Would you possibly want sane conflict resolution when merging directories across branches (table on page 30)? Sorry, there is no open source tool that can do that, yet...

It is entirely possible that this will never happen in any reasonable time frame without re-engineering the whole system. If it can happen with relatively minor changes, it should have happened by now.

Speaking as a Subversion committer: Yes, you're right, it will still take a long time. It's very hard to make it work with a few small changes because the system contains quite a lot of layers of abstractions. We need to peel at each layer to make this work.

Each layer has a public API with some amount of compatibility guarantees. Which is both a blessing and a burden. It's a blessing for people who want to write tooling around Subversion, because they know that the tools they've written against Subversion at, say, version 1.0, will still work, without recompilation, with any subsequent 1.x release. This allowed a lot of third party tools of decent quality to be developed. No need for parsing command line output to interface with the version control tool (as was the case with CVS and AFAIK is still, today, with git). But it's a burden because it means we have to be careful not to break existing interfaces when making changes.

I wasn't around when the API compatibility guidelines were set up, and my life would be easier if they weren't there now. But the project is committed to keep them. Trying to fix things anyway is quite a challenge. It's very, very hard, and has to happen in lots of small steps, spread out over several release cycles. But it's a lot of fun, too.

We're currently rewriting the lowest layer on the client side, the working copy library. This will eventually allow us to do things like tracking local renames, so that tree conflicts involving a local rename will be solved more or less automatically. There will eventually also be improvements in other layers, e.g. client/server interface, and eventually the repository itself. Then we can start propagating rename information from the server to the client to close the loop and also handle non-local renames properly. When? Dunno. When it's done. It will take longer than many would like in any case.

If it is going to require major changes, somebody is essentially going to have to fork it and redo the core SCM storage from the ground up.

I don't see how forking would magically help with bringing about the desired changes any faster. You might just as well try to write a new and perfect centralized version control system from scratch. Or join the few people who are still actively committed to bringing Subversion forward and help us out. Subversion has already solved an awful lot of problems any centralized version control tool has to deal with. The glass is half-full when you look at it that way.

The problem is that the RT2500 chipset is proprietary, closed-source that's "maintained" by a Taiwanese manufacturer who doesn't care about his users at all and only wants to sell cheap hardware and as much of it as possible.

Well, actually, Ralink has for a long time been providing documentation to open source developers writing drivers for their devices, without requiring an NDA.

• http://www.thejemreport.com/content/view/293/
• http://kerneltrap.org/node/6550

You could certainly put drivers in a higher ring than the kernel and allow them to only have limited access to memory, just as you do with a user-space application.

X.org has lots of userspace drivers that many of us use every day.

When I first heard about Linux, I had incorrectly assumed it was an evolution of Linux.

No no no, your assumption was correct!

it totally breaks all that added security you were supposed to get through virtualization

Virtualization does not add any security to the overall system. Adding more code to a system cannot make it more secure by definition. You need less code running in the system to have less bugs in the system that malware authors can exploit. Adding virtualization adds yet another attack vector for malware: attacking the hypervisor. See http://en.wikipedia.org/wiki/Blue_Pill_(malware), for example. There are good reasons for using virtualization, but improving overall system security isn't one of them.

I'd take that comment with a grain of salt.
I will be mentoring a student, too.
And yes, I expect to be bouncing patches back to students (we have two), and suggest improvements, and maybe even provide a code example here and there to help them. It's part of the learning process they will go through. Just like any contributor.
But coding is only one side of open source development. There are many more. Another goal is to try to integrate the student with the project, and let it be a fun and rewarding experience. If students stay with the project even after the summer of code is over, you've done the best possible job as a mentor. That is the hard part. It's much harder than getting the code right.

Was Google created to promote and facilitate illegal file-sharing? No? Then Google is safe.

And what about Slashdot? Was it created to promote and facilitate illegal file-sharing? No? Well maybe not unless you follow this link and copy the content you are seeing to your friend's computer.
Come on. This ruling breaks the internet.

I studied CS at FU-Berlin, the program can be quite demanding, but it's very good. Some courses are taught in English, and in those courses you can write the exams in either German or English. If you're just going to spend a semester abroad, you may be able to get away with taking all your courses in English. You'll inevitably need to learn some German though, if only for social life (even though many people are fluent in English), but the effort may well be worth it. There is also a welcoming Linux geek society at the faculty. Oh, and Berlin is a very nice city. There's the typical tourist attractions, but also a large and very active hacking community which naturally provides lots of entertainment for CS students (projects such as the CCC, freifunk, C-base, bootlab). Beware -- many students have been known to end up stranded in these communities. Check here for information about application procedures for students from abroad.