Slashdot Mirror

Indeed...

Gartner, 2001: "Gartner predicts that, by 2006, IPF-based servers will have a 20 percent share of the overall server market by revenue"

Gartner, 2001: '...for Windows Data Center Server and Enterprise Server, the question is not "Will it be [Itanium]?", but "When?"'

Microsoft, 2010: "Windows Server 2008 R2 to Phase Out Itanium"

It doesn't need to be found out. Read the fucking news. This is as goddamn annoying as retards claiming Linux "dusnt support mah hardwair." It sounds stupid to anyone who has used it.

Amusingly, the Technet blog entry has text marked as "Calibri" font, with no alternatives. Calibri is a Microsoft-only font that comes with Vista. So non-Vista systems render the text in Times Roman. Calibri is a sans-serif font, and all the other fonts in that Wordpress theme are sans-serif, so the page looks awful.

Now that font downloading works in essentially all the current browsers, that's not necessary, at least if you stick to public-domain fonts. However, there aren't many public-domain fonts that don't suck at small type sizes. (Here's a page of mine with some downloaded fonts.) If you have anti-aliasing on, it looks OK; if not, the text font looks ugly. Interestingly, Linux and Macs do anti-aliasing routinely, but older Windows systems do not.

Google Docs has the same problem. Currently, it works like classic HTML; if you have the font locally, you can use it, but if not, you get some default. The stock fonts in Google Docs are the lowest common denominator: "Normal", "Normal/Serif", "Courier New", "Trebuchet", and "Verdana". If Google is going to make a big push on competing with Word, they need to do better than that. Google could make progress on this by buying twenty or so really good body fonts outright from a major font foundry, and setting them up for download on demand for Google Docs.

No.

Apple has also been auditing all the factories that source their products after they discovered this type of thing going on a few years ago.

So does Microsoft:

"We should note that as part of Microsoft’s ongoing supplier SEA program, an independent auditor has been inspecting the KYE factory annually. In addition, Microsoft personnel conduct quarterly on-site assessments, and receive weekly reports from KYE on key labor and safety criteria that we monitor as part of our supplier SEA program. Over the past two years, we have required documentation and verification of worker age, and no incidence of child labor has been detected. Worker overtime has been significantly reduced, and worker compensation is in line with the Electronic Industry Citizenship Coalition standards for the Dongguan area."

Problem with those audits is that it is easy to see the picture that isn't real. To give an overreaching example, back in 30s, some people have done "audits" of Soviet gulags, and reported on healthy and happy inmates - every single one, if asked, admitting to most heinous crimes - engaging in hard but fair labor, and showing all signs of rehabilitation.

No it doesn't have the same bite. By calling out a specific company, more bad press is drawn to that company and it is more likely they will act to manage the PR disaster.

Well, that already happened - in the same link I've posted earlier, there is a mention of a new audit by MS specifically to investigate the allegations. The problem is that it will solve the problems - if any - at this particular factory, and maybe at some more factories which deal with MS. How many more are out there that deal with other companies on the list (but not MS)?

Exactly. Nothing new here from previous post, except you get a bit of 'Daily Mail' sensationalism.
Appropriate, since people are now (unfavourably) comparing /. to the Daily Mail...
http://crashedpips.com/2010/03/slashdot-the-daily-mail-of-the-tech-world/

Better to read the NLC's original report, (which is actually even more damming, since it contains more detail):
http://www.nlcnet.org/reports?id=0034 - April 13

In the interests of balance:
http://blogs.technet.com/microsoft_blog/archive/2010/04/15/working-to-ensure-the-fair-treatment-of-workers-in-our-manufacturing-and-supply-chain.aspx

http://blogs.technet.com/msrc/archive/2010/04/19/guidance-on-internet-explorer-xss-filter.aspx

.

Sorry, but Open != Detailed Documentation any more than Closed does. See Mark Russinovich's blog for way too much detail about the Windows kernel and ecosystem.
I'd also argue the MSDN site is far more comprehensive and easy to use (if they'd stop pratting about with the colours and layout every other week) than any single source of linux docs (if there even is one)
MS do seem to realise that you can't write docs assuming the reader knows what the doc is about, unlike most OSS documentation that assumes way to much knowledge.

These IBM pages are very useful and a commendable activity and a good read for any one interested in *nix, or operating systems. But these are the exception rather than the general rule.

Looks like Microsoft is serious about pushing this FUD. If you search for Chrome on TechNet it'll list a bunch of results tagged with "Google Chrome steals your privacy", but when you click through on the links there is no mention of Chrome. See for yourself at http://edge.technet.com/Search/Default.aspx?Term=chrome

> Finally, if at all possible, make sure your DHCP server sends ACK using unicast where possible. AFAIK, every major OS should be able to handle this

Windows Vista by default (stupidly/evilly pick one) sets the broadcast flag for DHCP, so it requires broadcast responses. While it can handle unicast replies if configured accordingly, by default it doesn't ask for unicast replies and thus should not be getting unicast replies.

See: http://support.microsoft.com/kb/928233

Windows 7 probably handles it better: http://blogs.technet.com/teamdhcp/archive/2009/02/12/dhcp-broadcast-flag-handling-in-windows-7.aspx

That said, "default Vista" is OK with "broadcast replies" which are are unicast layer 2 (dest= mac address of vista machine) but broadcast layer 3 (dest=255.255.255.255). This may or may not be RFC compliant (in my reading the RFC is not very specific on this), but it works.

How I know this? Because in my previous workplace (which supplied "expensive hotel/airport internet") I wrote a dhcp server which was somewhat RFC compliant (and did work with Vista unlike some other dhcp servers ;) ), but I had to deal with a scenario where some network devices between the client and server were not forwarding layer 2 broadcast frames (they were supposed to) - so the dhcp replies never reached the vista clients. Fixing the devices in time was not possible, so I worked around it by doing the above.

If 802.11 broadcasts are that expensive (I can see why it would be different from unicast but are there any decent articles on that? ), then it looks like that feature would be useful in this scenario too - since you then send a 802.11 unicast but have the dest IP = 255.255.255.255. :)

Not sure if some patent troll has patented that already - to me it's just an obvious solution.

I don't see a good technical reason why Vista (or other DHCP client) should use broadcasts by default though.

And I wonder though how many laptop users are actually using Vista and sticking with it, instead of moving to Windows 7?

My bad... it's called SuperFetch, and here's what MicroSoft has to say about it:
http://blogs.technet.com/askperf/archive/2007/03/29/windows-vista-superfetch-readyboost.aspx
and here is tomshardware's analysis of it:
http://www.tomshardware.com/reviews/windows-vista-superfetch-and-readyboostanalyzed,1532.html

There was some discussion about disk cache inflating memory utilization stats, but to me, swapping is the real test. When paging/swapping takes place, the speed of the computer is pretty much limited to the throughput of the disk, which is an order of magnitude slower than even the slowest memory access. As an added bonus, most Windows machine have only one physical hard drive, so the swapping is competing with system and user I/O that is probably the root cause of swapping in the first place.

A little bit of swapping is good for you. A typical machine runs quite a few services in background but are used less than 1% of the time. I don't print very much. If the print spooler is swapped out, no biggie. Even if it has to get swapped back in, the performance penalty is nothing compared to the warmup time for the printer.

I am not a Windows 7 expert by any means, but I know about VMS, which is where Microsoft got many if its ideas for Windows - especially memory management. VMS was ultra-stable -- perhaps MS should have borrowed a little MORE from that technology. DEC had numerous patents (having co-mingled software and hardware) and held on to some of their top OS people until the bitter end. Thus, Microsoft was unable to make Windows a complete ripoff of VMS. It wasn't for lack of trying.

As we search for viable explanations for apparent memory saturation (beyond disk caching), consider this great article on paged and non-paged pool

True, the technical details for interested geeks are here http://blogs.technet.com/askperf/archive/2007/03/29/windows-vista-superfetch-readyboost.aspx

Not only did Microsoft announce this on their Outlook 2010 blog back on Jan 22, but they announced the patch for it on Feb 11.

And it's beta software. We kinda expect it to make mistakes. Unlike some companies that keep their products in beta for a decade.

I've been using Office 2010 for a few months now and absolutely love it. It's not very different from 2007. Just refined, like Windows 7 is to Vista. It has a few new features in each application that users will enjoy, especially in Sharepoint environments.

One very cool feature in Outlook is the "People Pane" which appears optionally next to the message you're reading. Expand it and it will show you all of your prior appointments, emails, IMs, attachments, and more that are connected to that person. So when Fred sends you an email and says "what did you think about that other email I sent you?" it's a piece of cake to find it.

But oh noes! A beta has a bug! There must be nothing else to bash Microsoft for today.

http://edge.technet.com/Media/Interview-with-Mark-Russinovich-the-future-of-Sysinternals-Security-Windows
http://mschnlnine.vo.llnwd.net/d1/edge/2/9/5/1/MarkRussinovichEdge_edge.wmv
Most of the video is basic market hype. But at 27:10
Why not scrap the entire Windows code base and start over?
Russinovich openly freely admit that it's simply too much work!
CONCLUSIONS
1. Vista/7/8 = Forever Unsafe.
2. Microsoft dont even want to try making a safe Windows.

http://mschnlnine.vo.llnwd.net/d1/ch9/9/1/1/5/3/4/RussinovichInsideWindows7_ch9.wmv
Most of the video is basic market hype. But at 41.50
Russinovich explain one of the reasons why Vista/7 will always be bloated.
CONCLUSION
Every Windows will be slower and slower and slower and slower.

In product after product, Microsoft continues to ship fewer vulnerabilities than our competitors. Look at the results from Jeff Jones blog: http://blogs.technet.com/security/. Jeff is a Microsoft guy, of course, and thus not an entirely impartial source. But conduct your own research, use your own methodology and I think youll see: in product after product, the Microsoft offering is usually more secure than the competitors. We achieved those results through long-term sustained application of the SDL.

Bwahaha. Nothing to see here.

I don't know, what can you do with Win7 and Office 2010 that you couldn't do with WinXP and Office 2000? What new improvements in productivity do you gain from them? How did they lower your other costs (e.g. hardware)?

There has been a dramatic shift to the 64 bit OS in Win 7:

Windows 7 eclipses Vista on Steam, 64-bit dominating 32-bit

If you shop Walmart.com - every desktop $300 and over is 64 bit Windows Home Premium, every laptop over $350. That's about 150 systems, only ten of which are priced over $1000.

The geek's ten year old office suite probably isn't going to integrate well with SharePoint.

It won't be off-loading tasks to the GPU.

Incremental improvements in productivity do matter when you have 1500 full and part time clerical workers on staff.

That is why it is worthwhile for Microsoft to invest time and money in improving something as basic as cut & paste: How does usage data improve the Office User Experience?

I've been reading Slashdot for over 10 years i think. :) The guys at Port 25 probably read slashdot a lot!

Port 25 is the Open-Source Lab at Microsoft
http://port25.technet.com/

NewSID does work with Vista, but it was retired last year. Russinovich looked into the common belief of why everyone thought we needed to change the SID and determined that it wasn't necessary. His full post is here

I've known about this bug for many years - it's one of a few that date back to my college days when I had a scholarly interest in such things. Back then I used to haunt the dark corners of the Internet where these things were good for a laugh. Now they're good for a quarter million dollars because GO's haunt the dark corners now and they pay good money, and only now are ones like this coming out in common knowledge. You may be sure that if you're a high value target you've been exploited this whole time and that's why your competitors mysteriously beat you to market, or how knockoffs appeared more suddenly after your innovation than reverse engineering would allow.

What's absurd is that there are hundreds more just in the core OS. Go to apps and WMP doesn't have a streaming format that doesn't have pwnership, and let's not even talk about IE. Then there's all the forgotten formats and services, each with its vestigal exploits that still work. And then there's Office. Good Lord, as if providing multiple Turing machine capable development environments were not enough, every app includes embeds for hundreds of formats that can hose any machine that opens a document, and for each of those there's a Microsoft-only undocumented interface that's truly trusted to be exploited, because that's how they roll. And one of those apps is an email client - think about that for a bit.

Each fix only adds to the problem. Even if the patch doesn't add new exploits (most do) most people don't patch, and half of the few who do patch slowly to avoid incompatibilities. In the meantime the patch gives clues to the amateurs on which features to exploit. For 90% of systems you only need to pwn it once and leave some obvious malware and the idiot running it will clean it and think it's all good. So the smart black hat builds a database of servers running Windows he can get at from his previously Pwned boxes (yes, some of them are probably inside your firewall and most but not all of them are clients) and crafts a package to pwn the rest of your network and if necessary leave some cleanable traces. The truly nefarious black hats exploit the patching system itself - of course it has exploits and hidden hooks too.

Each rewrite leads to new problems. In 2008 how the hell do you write a server OS that hangs on a bad packet on the file sharing service? That's not what Bill promised us in 2002. In six years they couldn't even get that right? That's your clue that they're not even trying or at least they're not able. At the very least they're struggling just to copy a file as if that were a new requirement.

You would think with the billions they have to throw away on XBox and Pink, from Bing to Zune, Microsoft could afford to hire a few Pakistani code geeks to haunt the dark corners and report what they find written on the wall there. They're getting rid of their profits but they're not doing it well. You would think code security audits would extend to the historical catalog of code, but no... that group has enough to do just vetting this month's patches, let alone the output of the dev teams. I imagine the rest of them are building Bing interfaces into Yahoo's services as if they had a hope in hell of getting us to use Bing. For sure they're not throwing a ton of quality code geeks into saving their butt on WiMo 7. Fixing bugs widely known in the Underground that consumers like you don't know about? That's a 0 priority task.

Windows shops: not only are we laughing at you - we always have and we always will. You poor bastards.

http://blogs.technet.com/microsoft_blog/archive/2010/02/04/measuring-our-work-by-its-broad-impact.aspx

Protected Mode is the "sandbox" feature present in IE7 and IE8. It uses UAC that's in both Vista and 7 to run in an even more limited fashion, but not in XP. If you've got UAC disabled, you're not running Protected Mode and you're vulnerable. There are other ways which Protected Mode can be disabled.

It's best to check out the blog entry on the MSRC and the Knowledge Base article.

We now return to your regularly scheduled Microsoft bashing and Linux referrals already in progress.

Or hell if you are just wanting the speed boost put a little 32Gb SSD as the OS drive and put your data on the fat HDD. or for those of us on Windows Vista/7 that just want the advantage that SSDs have for random writes just pick up a cheap USB flash and use Readyboost.

I picked up an 8Gb thumb drive for a whole $20 over Xmas, added the whole drive to Readyboost, and now thanks to Readyboost and hybrid sleep my PC starts up faster than I can reach for the mouse, even after I have had to unplug the power, and thanks to caching on the flash my apps start up crazy fast.

So I have to agree, this seems to be a solution in search of a problem. You can go RAID 0, you can do as I said and use an SSD for OS and a HDD for storage, you can use Readyboost, there are plenty of options that will give you nice speed and probably cost much less than this thing.

The exposure for IE (it wasn't targeted at IE8 but IE8 could be vulnerable) will own any XP PC on IE6. If they have XP SP3 and IE7 they are not currently vulnerable to the initial threat, but that will change quickly. If they have XP SP3 and have upgraded to IE8, they are currently safe, unless they then turned of DEP.

http://blogs.technet.com/srd/archive/2010/01/15/assessing-risk-of-ie-0day-vulnerability.aspx

Do you have any proof showing that UAC and Protected Mode does not guard against this exploit or others? So far from the security researchers, I've only read very specific conditions under the latest systems that it's a problem.

Oh, so you have already read about conditions where this happens? Guess I dont have to answer this one then, do I?

Besides, I already gave you an example earlier. But just for shits and giggles, here's one that references the chances at 1% on IE8/Vista or IE8/Win7:

DEP Bypassed

Now, while 1% seems a trivial number, it is actually quite large when installed base is taken into account... or only a few million machines.

Then add to that, such an exploit can be attempted multiple times on a machine, which raises the likeliness of the exploit working.

And here's one more recent that states it is even more likely and has been proven to be possible:

Aurora Exploit

Hmmm... does that one sound familiar? Maybe the one this patch is supposed to address?

Or this one: Crappy Ass Microsoft Javascript implementation vector for bypassing DEP

And one that was made available to govts and large security software vendors: DEP being bypassed

And one (just to add it to the list) to bypass XP and hardware DEP: ANI Cursor Exploit

Should I go on? There are TONS of pages I can go through... and I havent even started on the hotfixes and other patches Microsoft has released to fix earlier issues with DEP and UAC.

Knowing what I've read about the various security contests, the only thing that needs to be done is execute code as the user.

But what limited scope is this? Does the vulnerability get contained within the Low profile of IE? If it drops files in there, who gives a damn? Even if it can execute code at the medium privilege level, it still doesn't have access to core system files and settings.

Hmmm... I dunno... what did the .NET stuff do for both Firefox and IE? Is .NET really truly fixed this time? This is the 6th major attempt to do so, and probably the few dozenth attempt overall.

The severity of the vulnerability to me under Windows is what I care more about, simply saying the application is "vulnerable" isn't enough.

True... but then again, I make most of my "repair" money at the company I work for from fixing virus ridden machines running on default settings (DEP and UAC enabled) from customers who have (or claim to have) done nothing and clicked on nothing - other than visiting malicious sites before the most recent .NET patch.

Not that I'm downplaying the exploit nor any fixes for it, I'm just trying to shed light on the various methods used to prevent such things from gaining much traction on a user's computer.

If the exploit can get by IE Protected Mode and execute under medium integrity I'd be a bit worried, but the attack surface is very limited until it generates a UAC prompt.

When exactly does it do that? And you realize there are mechanisms built into Windows Vista and Windows Seven to bypass UAC, correct? I'm cleaning a machine right now with Vista on it (and UAC & DEP enabled), where winlogon was infected (along with just under 100 other files).

If the user clicks OK to the UAC prompt and lets the thing get elevated privileges, well, at that point I no longer blame the application--I blame the user.

I agree... but that is not needed in vari

Microsoft's advisory admits that both IE7 and IE8 are vulnerable to the same flaw, even on Windows 7.

That is a misrepresentation, at best.

The knowledge-base article: http://blogs.technet.com/srd/archive/2010/01/15/assessing-risk-of-ie-0day-vulnerability.aspx

It states pretty clearly that IE7 *may* be vulnerable to this attack. But it also states that IE8 - on all recent platforms (XPSP3, Vista, 7) - contains the bug but due to DEP (and protected mode on Vista/7) it is not exploitable. That seems to be a pretty good reason to upgrade.

I think the patent encumbrances of ECC are the reason it's mysteriously absent from a lot of commercial software that deals with security and even a lot of Linux distros and software. I'd have to double-check, but for example, I don't think Windows Certificate Services supports ECC.

http://blogs.technet.com/pki/archive/2008/01/23/how-to-set-up-a-ca-with-a-cng-ecc-certificate.aspx

Since Vista and Windows 2008 it does, but through CNG not through the more familiar CryptoAPI / CSP.

Even then it is limited to certain NIST curves - forget about doing any enhanced EC cryptography through that API.

http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx

http://blogs.technet.com/markrussinovich/archive/2009/10/22/3288577.aspx

-Foredecker

There's a variety of reasons why i dislike EBS.

First of all, it changes several ways you "normally" administrate Windows systems - you need to use the EBS tools for most of the tasks, for fear of breaking some assistants.

That's the same as with SBS, except SBS setups are usually much less complex, which means using the normal admin tools isn't necessary as much.

To see why this is a giant problem, look at the EBS blog:
http://blogs.technet.com/essentialbusinessserver/default.aspx

Most of the postings there about fixing issues with EBS's automatic integration, which often doesn't work.

Also, look how many steps are necessary to get an SBS 2008 patched up and how much stuff can break during such a procedure. And then you'll need to fix all the stuff that comes pre-broken (BackConnectionHostnames, Sharepoint Search, IIS DCOM permissions, etc.)

Then there is EBS's security server, which comes with a product noone else uses - "Forefront TMG Medium Business Edition", which is basically a 64bit recompile of ISA 2006 that's compatible with Server 2008. This will force you to redesign your entire network around EBS - a mistake that was made with SBS 2003 (though it was optional there, and the option was removed in SBS08).

SBS has several limitations - some of them come from the "everything on one box" design, which is actually what customers want and thus an acceptable drawback.

EBS has the same level of limitations - which is why i don't like it. In my opinion, EBS should be reduced to a "license kit", that contains all of the EBS components at the same price, but leave all the integration and configuration stuff to a VAR, as a one-size-fits-all solution does not work in such environments as it does with SBS.

Windows Storage Server 2003 (yes, yes I know its from Microsoft) shipped with this feature (that is called Single Instance Storage)
http://blogs.technet.com/josebda/archive/2008/01/02/the-basics-of-single-instance-storage-sis-in-wss-2003-r2-and-wudss-2003.a

It's not even close to the same thing.

We investigated this a while back, and it is basically a dirty, filthy hack on top of vanilla NTFS.

First of all, it doesn't compare blocks or byte-ranges, but entire files only. If two files are 99% identical, then they are different, and SIS won't merge them.

Second, it uses a reparse point to merge the files, which has significant overhead, at least 4KB for each file, if I remember correctly. That is, SIS won't save you any disk space for small files, which is actually quite common on file servers. The overhead erases much of the benefit even for larger files, to the level that SIS will skip files smaller than 32KB by default.

Third, it operates in the background, after files have been written. This means that files have to be written out in their entirety, read back in, compared byte-for-byte to another file, and then erased later. This is incredibly inefficient. On large file servers, the disk was thrashed like crazy.

Lastly, we found that the Copy-on-Write mechanism immediately copied out the entire file if it was changed even slightly. For small files, this is not noticable, but for large files this can be a massive performance hog. A 4kb write can be potentially translated into a multi-GB copy!

Proper single-instancing systems use in-memory hash tables that are often partitioned using "file similarity" heuristics to prevent cache thrashing. Even more advanced systems can maintain single-instancing during replication and backups, reducing bandwidth requirements enormously. Take a look at the features of the Data Domain filers for an idea of what the current state of the art is.

Windows Storage Server 2003 (yes, yes I know its from Microsoft) shipped with this feature (that is called Single Instance Storage)
http://blogs.technet.com/josebda/archive/2008/01/02/the-basics-of-single-instance-storage-sis-in-wss-2003-r2-and-wudss-2003.a

Not quite. From the above link it works at the file level:

The files don’t need to be on the same folder, have the same name or have the same date, but they do need to be in the same volume, have exactly the same size and the contents of both need to be exactly the same.

ZFS' dedupe (and similar technologies like NetApp's A-SIS) work a the block level. From one of the leads of ZFS:

Data can be deduplicated at the level of files, blocks, or bytes.

File-level assigns a hash signature to an entire file. File-level dedup has the lowest overhead when the natural granularity of data duplication is whole files, but it also has significant limitations: any change to any block in the file requires recomputing the checksum of the whole file, which means that if even one block changes, any space savings is lost because the two versions of the file are no longer identical. This is fine when the expected workload is something like JPEG or MPEG files, but is completely ineffective when managing things like virtual machine images, which are mostly identical but differ in a few blocks.

Block-level dedup has somewhat higher overhead than file-level dedup when whole files are duplicated, but unlike file-level dedup, it handles block-level data such as virtual machine images extremely well. Most of a VM image is duplicated data -- namely, a copy of the guest operating system -- but some blocks are unique to each VM. With block-level dedup, only the blocks that are unique to each VM consume additional storage space. All other blocks are shared. [...]

ZFS provides block-level deduplication because this is the finest granularity that makes sense for a general-purpose storage system.

http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup

http://blogs.technet.com/josebda/archive/2008/01/02/the-basics-of-single-instance-storage-sis-in-wss-2003-r2-and-wudss-2003.aspx
No need to mod me up.

Windows Storage Server 2003 (yes, yes I know its from Microsoft) shipped with this feature (that is called Single Instance Storage)
http://blogs.technet.com/josebda/archive/2008/01/02/the-basics-of-single-instance-storage-sis-in-wss-2003-r2-and-wudss-2003.a

Vista _has_ a similar architecture:
http://blogs.technet.com/photos/blog_photo_gallery/images/450100/original.aspx

(from http://windowsteamblog.com/blogs/windowsvista/articles/450038.aspx )

I.e. mixing and processing is done in userspace.

Such architecture is great, because you can do a lot more tasks sanely in userspace than in kernel.

http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx says pretty clearly that it's an IE vulnerability: "While the vulnerability is in an IE component", which fits with the information I have. I think perhaps the WPF plugin uses that IE component?

All the addon did was to add a piece of text in useragent that told the website .NET version. How do you manage to fuck up that?

For anyone curious as to the real state of affairs behind this MS plugin issue, you might be interested in a few things. For everyone else just enjoying a good anti-Microsoft circle-jerk, ignore this post.

The plugins being discussed do more than just change the User Agent of the browser. They allow for XAML applications to run in Firefox and ClickOnce program distribution. For everyone that normally cries about Microsoft pushing IE and trying to lock users into their browser, this is an attempt to allow people to use an alternative browser while still having access to their other Microsoft-centric technologies (.NET in this case). Isn't this a good thing?

This is the bug in question. There is a lot of interesting comment there, including the fact that while everyone is crying about Microsoft "secretly" adding the plugin and preventing users from disabling it, Mozilla doesn't even give users an option to enable it! Their blocklist is all or nothing. Why doesn't that bother anyone here? One poster is very insightful:

Many corporations have begun implementing Firefox and telling their users that it is an equally if not more capable but more secure browser. For a subset of those corporations, the action of removing necessary tech without consent or a secure method for re-enabling it will result in the removal of the browser from the system completely. It will be called a failed experiment. The following day, sys-admins around the world will be left explaining to the non-enthusiast employees that the reversal came because certain business apps would not function in FF. Those users will only hear that FF is not as capable.

But perhaps the best thing about this entire issue, is that Mozilla didn't block the plugins until AFTER they were patched and the mechanism of the block is retarded. Mozilla is claiming that Microsoft agreed to issuing the block of the affected plugins, and that might be true, but only to an extent. Mozilla is currently blocking the plugins based on the name of the plugin, not the version, which means users who have installed the patched version of the plugs (at this point almost everyone using Windows Update) are still unable to use the plugins and have no way to re-enable them.

So essentially, by issuing this patch, Mozilla is doing nothing but hurting its business customers. Slashdotters can scratch their heads trying to figure out who uses these technologies, but the answer is a lot of businesses do. This absolute, non-scriptable and non-changeable block of these plugins will just remind corporations that open source isn't ready for the big leagues and they should just stick with Microsoft and IE. The sad thing is that if this kind of knee-jerk, carte-blanche blocking behavior becomes the norm for Mozilla, they will probably be right! Taking this kind of control away from the users is simply unacceptable, doubly so for businesses.

If you're wondering what MS says about this, you might take a look at this:

First we'd like to make it clear that any customers that have applied the update associated with MS09-054 are protected, regardless of the attack vector. And most customers need not take any action as they'll receive this update automatically through Automatic Updates.

So there it is -- pretty much everyone

Actually, it was patched on Tuesday.

The Adblock guy is talking about the Assistant. Unless I'm misunderstanding the issue, the problem is with the WPF plugin. Windows Presentation Foundation - that's the vector.

I was about to bitch about the submitter/moderator not RTFA, but it turns out, the article doesn't mention it either, so I'll clarify instead: thirteen updates are being released which together address thirty-four security vulnerabilities of varying severity across varying products (ten of which are targetted at Windows). So, that's NOT thirteen flaws (plenty more actually), just thirteen updates, some of which (all?) address multiple flaws in the particular system they are targetted at. Of course, this is just the advance notification, so full details about how many vulnerabilities each update addresses and the general information on them won't be released until the patches are next Tuesday. I think it's also worth nothing (although the summary of course neglects to mention it) that the good aspect of these updates are both major zero-day exploits (targetting IIS & SMB 2.0) are patched with these updates.

And while I'm posting, why does Slashdot insist on linking to shitty tech magazine articles (poorly) summarising the raw and accurate data straight from Microsoft? Seriously, I'm not sure if it's some sort of aversion to linking to MS, but they're the ones doing the patching, so it follows that they have the best, newest, most accurate data on them, and they'll likely be the first to provide updates on their content. These articles are just summarising what Microsoft has published on their various web-sites, and being a summary, they provide a lot more information and raw data:

Microsoft Security Bulletin Advance Notification for October 2009
October 2009 Bulletin Release Advance Notification

http://blogs.technet.com/msrc/archive/2009/10/08/october-2009-bulletin-release.aspx

For October we are releasing 13 bulletins (eight critical and five important), addressing 34 vulnerabilities, affecting Windows, Internet Explorer, Office, Silverlight, Forefront, Developer Tools, and SQL Server. Most of these updates require a restart so please factor that into your deployment planning.

Windows has a handicap here in that sometimes it doesn't matter how experienced you are, the only way of fixing some stuff is with magic voodoo steps or a complete reinstall (under Linux, you usually can dig around enough to find the root cause and fix it).

I think the problem is that there is a big difference between "experienced" Linux users, and "experienced" Windows users. If people who think they were an "experienced" Windows user really were, they would know how to use various tools available to diagnose problems on Windows.

Mark Russinovich's blog contains many examples of how one can find the root cause of those odd problems using free tools.

That issue was patched a long, long time ago. Unless your LAN is 1mbit half-duplex, there's something seriously wrong with it. The patch was rolled into SP1 to boot, so... there's really no excuse for you to not have it fixed.

http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

It's nothing like Superfetch. Superfetch preloads applications into system memory [microsoft.com] and this shared cache doesn't do that instead from what I understand it preforms some of the work the linker would do on load in advance.

The whole dyld sounds a lot like some of the basic features of the .NET runtime...

Or maybe some of the features in this advanced futuristic os:

http://blogs.technet.com/askperf/archive/2008/02/06/ws2008-dynamic-link-library-loader-and-address-space-load-randomization.aspx

The reason PAE bones drivers is this-PAE uses 36bit wide addresses, and if the card can only send/receive 32bit addresses....well you get the idea. Despite what others have said here I have seen with my own peepers how the 36bit addresses can cause glitching with my capture card.

And since Mark Russinovich, who is pretty much THE go to guy when it comes to low level Windows coding says, and I quote

"Windows XP SP2 also enabled Physical Address Extensions (PAE) support by default on hardware that implements no-execute memory because its required for Data Execution Prevention (DEP), but that also enables support for more than 4GB of memory. What they found was that many of the systems would crash, hang, or become unbootable because some device drivers, commonly those for video and audio devices that are found typically on clients but not servers, were not programmed to expect physical addresses larger than 4GB. As a result, the drivers truncated such addresses, resulting in memory corruptions and corruption side effects. "

I am guessing the video and audio devices of which he is speaking is video capture cards, which of course is something you're not gonna find in your average server, but at least around here is quite popular. And of course there is a bazillion different cheap Chinese analog cap cards floating around out there right now, most with 32bit only drivers. I myself have an Easy TV FM card that I can't find a 64bit driver for to save my life, which is why I have to dual boot XP 32/64. And I can tell you from experience that it is a LOT more flaky and crash prone now that I have PAE enabled. So it isn't so much the memory as the width of the addresses that causes the flakiness. And THAT, not some licensing conspiracy, is why MSFT doesn't allow PAE over 4Gb, because things like capture cards get seriously flaky with PAE.

The best source for info for this is likely Mark Russinovich. His blog is the origin of the "difficult to measure risk" quote.

Because device vendors now have to submit both 32-bit and 64-bit drivers to Microsoft's Windows Hardware Quality Laboratories (WHQL) to obtain a driver signing certificate, the majority of device drivers today can probably handle physical addresses above the 4GB line. However, 32-bit Windows will continue to ignore memory above it because there is still some difficult to measure risk, and OEMs are (or at least should be) moving to 64-bit Windows where it's not an issue.

He also acknowledges the commercial aspect of product differentiation on MS 64-bit OS versions, but suggests that the 32-bit issue derives from actual experience;

64-bit Windows client SKUs support different amounts of memory as a SKU-differentiating feature, with the low end being 512MB for Windows XP Starter to 128GB for Vista Ultimate and 192GB for Windows 7 Ultimate...

the Windows team started broadly testing Windows XP on systems with more than 4GB of memory. Windows XP SP2 also enabled Physical Address Extensions (PAE) support by default on hardware that implements no-execute memory because its required for Data Execution Prevention (DEP), but that also enables support for more than 4GB of memory.
What they found was that many of the systems would crash, hang, or become unbootable because some device drivers, commonly those for video and audio devices that are found typically on clients but not servers, were not programmed to expect physical addresses larger than 4GB. As a result, the drivers truncated such addresses, resulting in memory corruptions and corruption side effects.

http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx

I'd suggest though, the decision to completely disable PAE instead of only enabling it when paired with drivers certified by WHQL as being PAE-safe was a commercial one, based on SKU differentiation rather than risk.

And here is the reference for PAE causing problems for many common drivers, straight from Microsoft itself.

This isn't to say that Windows doesn't have some limits that are purely marketing-driven - the memory limits for Windows Server line are that, for example (there's no technical reason as to why Enterprise edition can address more memory than Standard) - and the blog post I've linked to faithfully describes them as such. But the 4Gb limit in client OSes isn't one of them.

While the article makes various allegations that Microsoft is doing this to be bad, the author found out that many device drivers intended for 32 bit windows will break if PAE is enabled.

No surprise here - a year-old blog post by Mark Russinovich lists and explains Windows memory limits in great detail, including the part about drivers. Quote:

"Windows Client Memory Limits

64-bit Windows client SKUs support different amounts of memory as a SKU-differentiating feature, with the low end being 512MB for Windows XP Starter to 128GB for Vista Ultimate and 192GB for Windows 7 Ultimate. All 32-bit Windows client SKUs, however, including Windows Vista, Windows XP and Windows 2000 Professional, support a maximum of 4GB of physical memory. 4GB is the highest physical address accessible with the standard x86 memory management mode. Originally, there was no need to even consider support for more than 4GB on clients because that amount of memory was rare, even on servers.

However, by the time Windows XP SP2 was under development, client systems with more than 4GB were foreseeable, so the Windows team started broadly testing Windows XP on systems with more than 4GB of memory. Windows XP SP2 also enabled Physical Address Extensions (PAE) support by default on hardware that implements no-execute memory because its required for Data Execution Prevention (DEP), but that also enables support for more than 4GB of memory.

What they found was that many of the systems would crash, hang, or become unbootable because some device drivers, commonly those for video and audio devices that are found typically on clients but not servers, were not programmed to expect physical addresses larger than 4GB. As a result, the drivers truncated such addresses, resulting in memory corruptions and corruption side effects. Server systems commonly have more generic devices and with simpler and more stable drivers, and therefore hadn't generally surfaced these problems. The problematic client driver ecosystem led to the decision for client SKUs to ignore physical memory that resides above 4GB, even though they can theoretically address it."

That is only partially true. Sometimes you are limited by that 1 gig of memory you have in your video card and where it is mapped into memory by the PCI bus.

Dense reading but worth it if you want to understand how windows memory works.

http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx
http://blogs.technet.com/markrussinovich/archive/2009/07/08/3261309.aspx
http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx
http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx

That is only partially true. Sometimes you are limited by that 1 gig of memory you have in your video card and where it is mapped into memory by the PCI bus.

Dense reading but worth it if you want to understand how windows memory works.

http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx
http://blogs.technet.com/markrussinovich/archive/2009/07/08/3261309.aspx
http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx
http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx

That is only partially true. Sometimes you are limited by that 1 gig of memory you have in your video card and where it is mapped into memory by the PCI bus.

Dense reading but worth it if you want to understand how windows memory works.

http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx
http://blogs.technet.com/markrussinovich/archive/2009/07/08/3261309.aspx
http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx
http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx