I don't see how it's fair to demand registration of copyleft and not other copyrighted works. Enforcement of copyright is (and should remain) a private not criminal matter, the government doesn't have to hunt anyone down. I imagine the authors of the work will show up in court if they file infrigement charges.

I'm stunned. This has to be the most brutal attack on the idea of free culture to date. We're all accustomed to copyright being made more strict, but actively making it harder to release your works under permissive licensing is a new low.
It's like the copyright lobbyists didn't care about keeping a low profile anymore and shouted "we own your government" from the rooftops.

I wish the x264 guys, <brownnose>who implemented the world's best h264 encoder and thus are obviously extremely talented and experienced in developing encoders,</brownnose> would fork a vp8 encoder from x264. While vp8 might be inferior as a codec, I'm sure their psychovisual modelling could still do wonders to vp8's visual performance.
It's a bit hard to get people hooked on vp8 when the only freely-available encoder is painfully slow and doesn't shine in the quality department either.

They love the open source software that is created around their products of course, just look at codeplex. It's full of Office, Sharepoint, WPF and XNA stuff.
And well, maybe it's fine, you can't prevent people from writing open source apps for their platforms. But it feels weird, this whole open source ecosystem springing up, that is completely incompatible with the Linux/BSD centered one. They're probably aiming for their community to displace ours as the number one thing people think when they hear "open source".

I wasn't complaining about AMD's strategy, I support them releasing specs. I was pointing out that despite documentation being made available, work on the open source drivers has been progressing rather slowly.

I really anxiously await the day that I can buy a recent AMD graphics card to replace my aging GF7600 and expect the same level of stability and a higher level of performance, on the desktop and in the games I play.

My bad, I meant R800, the family mentioned in the article.

However I'm intrigued, does your R700 run a compositing window manager, Tremulous and Enemy Territory: Quake Wars? What kind of uptime do you get on those drivers?

I have to admit phoronix' reports that the R600g driver is rather early in its development cycle were what mostly remained in my memory, while I overlooked that R600 classic has "decent 3D support". (Partly due to phoronix providing mostly coverage of R300 and R500 drivers.)

You have the source. You can compile it yourself. If it doesn't work the way you'd like, you can change it.

Sure, but the glacial pace at which Gallium3D and its drivers advance is a testimony to how hard it must be to write a graphics driver. If it was a job for your average programmer, the guys working on this stuff would have given us functional drivers two years ago. At this pace you'll be able to enjoy stable and fast R700 hardware support another 3 years from now.

In the future, when those drivers are done, they will surely be benefits to them being open source. But the only actual benefit now would be if some ingenious hacker got involved, committed and wrote the drivers in a couple months. Currently the development model isn't working very efficiently, because R600 docs were released over 2 years ago and we're only beginning to see functional drivers.

Open source works better when the barrier to involvement is lower, OpenGL infrastructure is more complex than most kernel drivers. It requires:
* knowing the OpenGL API intimately
* a firm grasp of 3D math and rasterization process
* an idea how to manage non-uniform memory and do low level hardware access in a thread-safe way
* a fair bit of compiler design for compiling shaders to GPU instructions
* all of the above done in C, because we still haven't developed a better language for low level work (see this paper for things a driver design language could have)

I'm not intimately familiar with the GC infrastructure they have, but I bet they just provide tools for generating barriers and maybe querying the types of stack slots.
Similarly exception handling support exists, but exception throwing code doesn't (Some LLVM clients use gcc's exception throwing code).
Without a common object model it's hard to do either memory management or exception handling in a language-agnostic way. I don't think there's any interoperability between current LLVM-based compilers.
Like I said, it's a tool for building code generators, not a platform in itself.

And as far as JIT compilation goes, it's possible but it's slow.

Players are more likely to pay if they get more advantages out of it, but players who can't pay or can't pay enough to stay competitive won't really have an incentive to play.
The game has to remain playable regardless of the level of monetary contributions or else it ceases to be about gameplay and turns into a bidding war. While that might give you a couple high income players, I doubt it's feasible in the long run.

I used to play a MUD by a certain well-known developer in the MUD community. It was advertised as free-to-play, pay-for-perks, but its scheme had two major flaws:

The power plateau was ridiculously high, it took thousands of dollars AND months of playing to reach it, per character.

The baseline character power level, at which the game was by design balanced required an investment of around $200-300. There was no segregation between paying and non-paying players, both competed in the same game world. This put non-paying players at a big disadvantage unless they just wanted to use the game as a glorified chat-room. The developers used to counter this argument on message boards saying that players can get the perks through contests and in-game currency. However contests were not frequent enough and too competitive to make much of a difference (usually the same clique of players won). And buying them for in-game currency required weeks of grinding quests (mere knowledge of which required a lot of gameplay beforehand) competitively against other players with similar goals (because the game offered no instancing).

Was the game successful? Moderately, they're making some money, they've made quite a lot of a couple selected players with deep pockets. But ultimately there never was enough players to keep the game from feeling empty, usually just a couple players per character class at any given time. I heard their other games using the same model were more successful though, on the order of 500 players logged in on the most popular one. But I can't help but wonder what kind of numbers they could have raised if the price for playing the game competitively was an order of magnitude lower. Their MUDs are actually worth paying for, compared to all the uninspired DIKU clones, just not that much.

I regret sinking $200 into it before I realized I just can't compete without buying the equivalent of a used car in skills and virtual items.

Not missing it. Code level generally catches 99.99999% of any generic-type problems that I've ever run into

CLR's generics not only retain type information for better type safety, but also for better performance. In Java generics involve boxing of primitive types, CLR VMs specialize generic instantiations for value types. Ask the Scala developers how much of a performance problem that can be and why they included a primitive form of specialization in their compiler.

Don't see the benefit of being more procedural in an object oriented language, but good for you I suppose

Once again performance. Hotspot is a very advanced virtual machine and can optimize away some needless allocations with escape analysis. However that just exacerbates the problem of its startup performance and, more importantly, is only available on one VM implementation. Java's obliviousness to the cost of allocating new objects is also one of the reasons Java programs consume so much RAM, because the JVM needs to keep a large pool of memory for fast allocation of tons of useless objects. (Although to be fair, CLI isn't that much better in this regard, but the aforementioned features do make a difference.)

CLR delegates are actually more like magically created (by the runtime) instances of anonymous inner classes implementing callback interfaces. Their advantage is that they're implemented very efficiently by the runtime (effectively just a function pointer + a captured "this" pointer).

That's not entirely true, CLR delegates are relatively heavyweight. I haven't actually looked at the internals, but from what I gather each delegate instance is an object that needs to be allocated. It contains a function pointer, a context pointer and a next pointer for multicast delegates. Even a simple binding of an object's method to a delegate variable involves a delegate object allocation. Creating a closure probably involves two allocations (delegate object and context object), although that could be optimized, if other constraints don't prevent it.
Contrast with for example D where a delegate is a struct (func ptr, ctx ptr) and only escaping delegates pointing to closures need to have their context allocated on the heap.