I'm not sure I understand. Based on the summary, this video was supposed to have been created by Microsoft? It was posted by The Linux Foundation and doesn't seem like a video that would be produced by Microsoft (not so much the style or content, but the perspective; it doesn't seem like it's Microsoft telling the story at all).

Instead, it plays like some sort of lead-up to an announcement OSDL/TLF are planning to make...?

You just reinforced my core point.

Blaming add-ons for FF's memory leaks and failure to reclaim is like the "repair your disk permissions" or "update your drivers" of the browser world.

It's sometimes add-ons. Very rarely.

My thoughts exactly.

This is, really, the only reason I don't use Firefox. And I keep trying to go back, probably every month for the last year and a half.

I do use a lot of tabs, but over time the memory usage grows to well over 1GB (sometimes 2 or even 3GB), and the memory is never released, even after closing all tabs. This has been a problem for me since at least FF 3.0, on several systems, each with its own unrelated profile. On both Mac and Windows. I don't think I navigate to particularly unusual sites.

I use no add-ons, at least on most systems.

The response to this problem is usually exactly the comments we see in this story, which are generally:

1) Memory leaks are due to bugs in add-ons. Disable all your add-ons one at a time until the problem goes away.
2) I don't have this problem; something must be wrong with you.
3) Just buy more RAM. It's cheap.

I don't understand why people are so aggressively against investigating these problems. Even with a task force announced to address the problems, a huge # of people in this comment stream are still calling foul.

I'm not sure if Chrome uses less memory, but at least when I close a tab, the memory is released. All of it. Immediately. I don't have to restart the browser to get it back.

"Tonight, on a special episode of HowMom..."

Vidgame? Is that a thing? Or just that "kids today can't be bothered to call something by a name longer than two syllables" way that marketeers rename TV shows and movies...?

I try to seriously use Linux as a personal (home or work) system about every 6 months (maybe once a year nowadays). Invariably within the first few weeks I have to spend 2+ hours going through something like this; hacking Makefiles, finding some obscure patch, editing some file I really shouldn't have to. (Actually, my tolerance has dropped to about 20 minutes). At that point I stop using it. Repeat.

2011 will be the year of Desktop Linux.

Pet peeve - is it really necessary to misspell "you're" as "your", throw in unnecessary profanity, and generally use bad grammar/capitalization/etc?

If you're going to be a pedant on style, at least use good style.

And you know, in my experience that's where one of the real problems - and one of the most commonly undiagnosed problems - exists. In nearly 99% of networks I've looked at where buffer overflows were occurring and drops were happening, network admins were not only unaware of the severity of packet drops and didn't understand the impact this was having on their *critical* workloads, they had no idea how to even look for it.

It's a myth that routers have the ability to tell a client to slow down, at least in the majority of environments (particularly ones with Ethernet segments, but other network types too).

Ethernet Flow Control has very limited utility here. You'll see it kick in in a rare few congestion cases - like if a switch backplane becomes overloaded - but it is used in a very limited number of situations and definitely will not be used end-to-end on a network for a router or host to tell another host (client) to do slow down.

Instead, when buffers fill, packets will be dropped. Yes, congestion control and FLOW CONTROL are handled using *packet drops* as the signalling method. It's assumed that TCP will use one of number of drop detection methods and congestion control algorithms to recover, and that does work better than one might think, but it's still ridiculously inefficient (especially with some types of drop patterns). I'll say it again, because I've been working on this pretty much daily for 10+ years and it still amazes me - you have to DROP PACKETS for any kind of end-to-end flow control to kick in.

In Ethernet land, there are some technologies created by folks like Cisco that are collectively being called "lossless Ethernet" that will definitely help here, and provide end-to-end flow control. But I'll pretty much guarantee you don't have hardware that supports it at the moment.

So?

As EMC is by far the largest producer of IT storage equipment and software...And is the parent company of VMware, Iomega, Mozy, etc... I think it's your own fault if you pick "ElectroMagnetic Conformance" as likely instead of knowing something about IT.

That's true. Although on the OTHER hand, facts and evidence show that they're not.