backtop


Print 134 comment(s) - last by kayronjm.. on Apr 17 at 5:26 PM

The truth comes out about User Account Control

Microsoft's Windows Vista operating system has been lambasted ever since it was launched for consumers in January 2007. Diehard Windows users balked at the steep system requirements, sometimes sluggish performance, inadequate driver support, and varying products SKUs at multiple price points.

One feature that has caused quite a bit of controversy with consumers has been the User Account Control (UAC) that is included in Windows Vista. UAC prompts nag users for simple operations such as going to device manager, emptying the recycle bin, or installing/uninstalling an application.

David Cross, a product manager responsible for designing UAC, gave the real reason for UAC at the RSA 2008 conference in San Francisco yesterday. "The reason we put UAC into the platform was to annoy users. I'm serious," remarked Cross.

Cross added that Microsoft's unorthodox method to stop users from wreaking havoc with their systems and to stop software makers from making applications that delved too far into the Windows subsystem was a necessary move.

"We needed to change the ecosystem, and we needed a heavy hammer to do it," Cross added. Cross went on to say that although UAC may be seen as an annoyance to some, but its lasting implications are far more beneficial to Vista users. "Most users, on a daily basis, actually have zero UAC prompts."

Many would say that many users have zero UAC prompts on a daily basis because they have already disabled UAC -- not so says Microsoft. According to Cross, 88% of Vista users have UAC enabled and 66% of Windows sessions do not encounter UAC prompts.



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

All About The Business...
By Krioni on 4/12/2008 8:07:11 PM , Rating: 2
Well, I couldn't take the time to read ALL of the posts because there are a LOT on this thread. So I apologize in advance if my point has already been made.

Please humor me for just a second for some background info...
I work in the financial services industry. The primary system on which I work does some pretty hefty recursive insurance and tax compliance calculations. Me and a few others (one of which is a highly educated and very intelligent actuary) originally wrote our engine in C++ and have since converted it to C#. We spent a substantial amount of time optimizing that code because our system must return results of millions of calculations in less than 1/10th of a second. Rather than accepting conventional wisdom on what constructs and data types were most efficient, we wrote hundreds of tests to see which worked best for *our* problems. It ends up that was justified and many best practices just didn't work out in practice for us.

There is a lot of talk of optimization, and I agree that developers should be mindful of that. BUT....

It's all about the BUSINESS... you know, those people that pay our salary. In many situations, it is far more valuable for a system to be DELIVERED quickly than to RUN quickly. My business customers really don't give a rip if I'm using a double or a float or an int.. they just care that our products get out the door on time to meet the market demands. The flip side I guess is that they WOULD care if we were taking 2 or 3 seconds to do our calculations.

I guess the point is that there's always a balancing act between performance optimizations and delivering the end product.

For something like a 3D game engine, you can bet the farm that optimizations matter entirely because a poor performing engine means fewer people can run it, which means fewer sales, etc.

So, in a purely acedemic setting, sure, we should all get our code optimized perfectly. In the real world, you simply don't have the time or resources to do that because someone is paying for you to deliver systems/components/code.




"Folks that want porn can buy an Android phone." -- Steve Jobs














botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki