The solution for wireless could be a TCP congestion control change, such as Westwood+ which accounts for bandwidth by delay rather than dropped packets.

But even better is a simple proxy setup. The proxy handles the request at the AP for the client, and retransmits can occur over the much faster wireless link.

It's mostly a cost issue, since only recent APs are powerful enough to run a local caching proxy.

And pretty much everything you said is true in some sense. Given not so superb equipment for mixing, recording, and playback, simply having the slight room for aliasing filters and frequency information can improve the final product that gets output at 16/44.

But as the article says, if you do it right the first time, there's really nothing to be had going for more than 16 bits, and 44kHz, it should encapsulate the entire range of human hearing in any normal situation.

I'm really glad the article was posted. It cleared up some of my misconceptions.

And now I know the final product at 16/44 is just fine if done right.

This is true, but modern branch predictors are pretty good. Sandy Bridge reportedly is correct more than 80% of the time. So it really depends if having fast on chip DRAM (but a smaller amount) is more valuable than having L1, L2, L3, and RAM caches at differing speeds with their own predictors.

I'm guessing it depends on the application.

If Microsoft implements it right, it should be faster than NTFS.

Since it's copy on write, you can batch together random writes into a single linear write (while still maintaining consistency). They also mention having 3 allocators depending on the size of data to be written (because a one size fits all allocator is worse than 3 tuned to data size).

And considering it gets rid of some rarely used NTFS features, it also stands to be faster because it doesn't have to support as much.

Are you sure that's saving you power? Sometimes you have to initialize the device in order to activate the power saving features. It happens in Windows as well with wireless cards. The default state is "max power."

I agree generally, like AMD's bulldozer hitting 8GHz on a single core before failing to the limits of physics (even with extreme cooling). I'm assuming nobody will never be able to get more than 1 or 2 cores active (out of 8) while getting to 8GHz on that architecture.

But these days, the chips run in multiple clock domains. I believe the Intel chips are separated by a base clock, L3 Clock, Core clocks, RAM clocks, and bus clocks. The architectures are moving ever toward asynchronous operation in order to pack billion upon billion of transistors on a package without having to synchronize them all the time.

Microsoft is doing the right thing here. They are dropping the antiquated Win32 API and its bloat, in favor of a new universal WinRT API that targets both ARM and X86. Furthermore, it consolidates everything (Silverlight, Win32, WPF, .Net) into a cohesive API that you should be easily able to port to. If you cannot easily port to it, you're probably designing some custom business app that has and never will upgrade. Sorry but the new Windows isn't for you.

People have been asking Microsoft to the drop the bloat for some time. The security has been a nightmare because they've had to maintain the old unsecure model for the sake of compatibility. This clean break allows them to fix the permission model so that each App asks and gets only the permissions it needs during the install (like Android).

I like this change. Apps will now have to focus on doing one thing really well (and being able to connect and share with other apps) instead of being one-stop bloatware packages. Have you seen new contract API that facilitates this? It seems to follow the UNIX philosophy of doing a single task and being to pipe that output to anywhere.

Reading the paper, it seems the proposed protocol for key exchange forces a wait time of 17ms, and then hashes the packet to ensure it doesn't get modified (forcing the use of slots and keeping the air open during attack).

The only problem I see is that you could easily use this mechanism to effectively DoS the network by making it wait for the CTS packets constantly while the protocol rejects the bad check-summed packets.

But I guess that's a minor flaw since it's already trivial to DoS wireless networks in general.

Here's to hoping this actually gets widely implemented.

Is there an advantage to a reformat?

You say it creates a recovery partition? But when I run it from an existing Snow Leopard install, my existing Snow leopard partition size remains unchanged. I don't have an extra partition after installing Lion.

As an example, I've loaded a custom build of Tomato firmware onto my WRT54GL router. This router is considered out dated, slow, and lacking in RAM. And yet, I've got a new firmware for it that gives me a 2.6.22 kernel (originally 2.4) and IPv6 support.

Now my ISP (U-Verse) doesn't have any mention of IPv6 support, but the provided gateway does have much more powerful specs. In theory it should be a much more capable box, but their crapware firmware doesn't unlock any of its potential.

Thanks for that informative post!

So basically, we would need the FCC to open up the airway for more frequencies, thus reducing collisions and allowing switching when one channel is in use.

AFAIK, almost every wireless device in my house is around 2.4GHz.

I'm surprised Half-Life wasn't on that list. It was and still is regarded in the gaming industry as one of the best games ever made during that era. I think it, and Half-Life 2 have some of the highest combined scores by reviewers.

It also spawned a whole scene of modding that produced Counter-Strike, among other games, which today is still of the most played games in the world.

The Olympics happened?

http://googleblog.blogspot.com/2010/03/searching-for-gold-during-games.html

I call bullshit on that. I regularly use Steam from school, my apartment, and my parents house and on many different machines. My brother also logs into my account to access my game libarary and vice versa.

Really the only ban is for cheating on VAC secured servers and games. Even if you get banned for cheating, it's still possible to play on non VAC secured games and servers.