I love this response. "Microsoft can make better programs because they use the super-secret ultra-special hidden APIs." Completely false. Though sometimes I wish there were secret hidden APIs that could be used to somehow make programs work better, this seems pretty far-fetched.
Microsoft employees use MSDN for documentation just like everybody else. While it is possible that they have access to better support options than the average developer (i.e. their friends that work on the Windows team can given them advice), there is no secret sauce available. Just elbow grease.
In fact, SQL Server has it worse than non-Microsoft products. Beyond the simple absurdity of "secret APIs", there are also legal restrictions. SQL Server (just like any other non-Windows* MS product) legally must restrict itself to public Windows APIs. As a part of the antitrust restrictions on Microsoft operations, if the API is not documented on MSDN, SQL Server cannot use it. Every other company gets to use whatever Microsoft API they can find, however they can find it. SQL Server has to do everything by the book. Not only that, but the SQL Server team (and the teams behind every other non-Windows program shipped by Microsoft) has to be able to document that they aren't using any undocumented APIs.
On the other hand, SQL Server has it better than other databases. The SQL Server team gets to focus its efforts on a single OS. SQL Server is TIGHT (like this!) with Windows. It has been tuned and re-tuned to work well on Windows. It leverages the Win32 API like no other database on the market. No abstraction layers, no designing to the lowest common denominator, no limitations because "one of the OSes we support can't do that". (Well, not entirely true -- multiple versions of Windows with differing capabilities are supported, but still mostly true.) SQL Server makes use of the Windows OS like probably no other program that has ever been written.
If Microsoft programs ever outshine the competition, it is because they got more effort put into them or were designed better. And when other programs work better than Microsoft's, it is because they got more effort or were designed better. No secret sauce, no secret APIs.
* (Windows components do use internal and undocumented APIs to communicate with other Windows components. That's just abstraction layers at work - every program I can think of uses undocumented APIs to talk to other parts of itself. In any case, only Windows components are allowed to use undocumented Windows APIs.)
That would be all well and good, except that Max OS X's mechanism isn't secure. The reason Vista's mechanism is more complex is because it deals with security issues that Mac OS X ignores. There is an inherent tradeoff between security and convenience, and Microsoft has tried to emphasize security here. Maybe Mac OS X chose a better balance between security and convenience, but only time will tell.
All you need is 1 GB RAM, enough hard drive space, and Vista drivers for your hardware. Unless you insist on running Aero, Vista will run just fine on most XP-spec hardware (though you may need to add some more RAM).
I ran Vista on an old desktop with 1 GB of RAM and it worked great. It was a bit sluggish on my old laptop (512 MB), but still usable. With 2GB of RAM, my new laptop is doing quite nicely. No performance issues at all.
I will certainly admit that there are a lot of things to like about OS X, and for some people, it will be the better choice. For others, Windows is better, and Vista is a big step forward.
The article comes across as "Why OS X is better than Vista" instead of "Comparison of OS X and Vista". But that's par for the course. The author does have some valid comments about areas that could have been done better in Vista.
I do disagree on some of the evaluations of Vista's merits. The most misunderstood area is User Access Control.
Not that UAC is perfect -- I've got a nice list of things I don't like about it. For example, if the system incorrectly detects that a program probably needs to run as Admin, it is a bit of a pain to convince the system to just run it normally. And there aren't any good tools for working with UAC from the command line (i.e. I want an equivalent to Unix su). I've written some myself, but they really should have been included with the system. And some tasks that should be able to be done by accepting one UAC prompt end up requiring 5 or 6.
However, the author of the article passes UAC off as useless and annoying. Well, it is annoying, but so is finding my car keys every time I want to drive my car. But it is definitely not useless - just misunderstood.
UAC consists of three mechanisms, along with related tools for configuring them:
1. The shell of an Administrator can optionally be run with reduced permissions. This means that if UAC is enabled, the user's shell (explorer.exe) will drop privileges when it is initialized (after the user logs on). In other words, the shell tells the kernel that even though it is running under the account of an Administrator, the kernel should deny any requests to use administrator privileges, and should not grant any access to resources based on the user's membership in the Administrators group.
2. There is a mechanism to regain administrator privileges so that administrative tasks can still be performed. If you are logged on as a user in the Administrators group, this mechanism requires a confirmation dialog (ok/cancel). If you are logged on as an unprivileged user, this mechanism requires a username + password of an administrator ("over the shoulder login").
Note that this mechanism must be protected from abuse. Potential abuses include: keyloggers (capture the administrator's password), event injection (simulate a mouse-click or keyboard event to respond to the confirmation dialog automatically), and luring (put a malicious executable with the same name as a trusted executable into the user's path, then trick the user into trying to run the trusted executable). Protecting against these abuses leads to a bit more inconvenience, but a lot more safety. This is why nothing else can be done while the UAC prompt is active -- the UAC prompt turns on some security features to protect against keyloggers and event injection. This is something that is more annoying than OS X's system, but also significantly more secure.
3. There is a mechanism to detect programs that require administrator privileges. Vista-aware applications include a manifest that tells the program loader whether administrator privileges are required. Vista also tries to automatically detect non-Vista-aware applications that require administrator privileges (such as installers). For now, this is a bit of a pain when it doesn't work, but in the future, this will end up working well. For example, as the author indicated, it becomes more challenging to install a pre-Vista application to your personal folder without help from an admin (Vista detects that the installer probably needs admin privileges). In the future, the installer will have a manifest telling Vista that it doesn't need admin privileges immediately, and will ask for them only if the user decides to install the app onto the system instead of to a personal folder.
I've been using Office 2007 for several months now (yes, I work for MS). I never would have realized that there was a steep learning curve had I not read this article. Up till now, I just used it without really thinking about it much. Now I realize that I must have been doing things incorrectly, since I haven't made any drastic changes from the way I used Office 2003 and Office XP.
Seriously, I'm a very experienced computer user (I've been doing tech support for my family for something like 16 years now), so I may be overlooking things that would confuse a less experienced user. I'm a developer, so I spend more time in Vim than I do in Word, so I don't use the complex features much (most days I just use Outlook). And I'm probably a bit biased, since if people buy more Office 2007, my stock in MS goes up. But I can honestly say that at least for me, the switch was natural and I gave it little thought. Adapting to the new interface has not been a problem.
There are some nifty new features, including RSS browsing in Outlook, and some things are a bit more refined (they fixed a number of little annoyances). I definitely prefer the new version. That said, there isn't anything I couldn't do without (though I suppose that could be said about any upgrade, since I somehow did without it before...).
How is it even going to know? Nothing really changes except that the processor is now in the VM mode. Since Windows doesn't look at the VM mode bit, as far as Windows can tell, nothing has changed.
Not to say that pulling this off is easy... Just that the challenge is not in fooling Windows or preventing it from freaking out.
Think about VMWare -- Windows doesn't royally freak out when it is running as a VM under VMWare.
The hardware issue is very different for a rootkit versus VMWare. VMWare has to virtualize the hardware so that it can redirect the guest OS's calls to the host OS and make it play nice. A rootkit doesn't have to do this. It can let the "guest" OS directly access the hardware.
The rootkit doesn't have to help the guest OS share the hardware with another OS. All it has to do is hide itself and watch for interesting tidbits of information.
1. This is not news. Driver writers have known about this for years. This is how XP-64 and Server2003-64 work already. And this has been posted on Slashdot at least twice before.
2. Win64 (whether Vista, 2003, and XP) requires signed drivers unless you boot up in "debug" mode. Win32 does not, although it will warn you.
3. If you have any unsigned drivers running (Win64 OR Win32), certain "trusted path" applications (i.e. DRM-enabled video players) will not run. Basically, the content author says "I only give permission to watch this video if your system is trusted" (for some definition of trusted, as defined by the content author). Microsoft is providing a way to certify your system as trusted. Without this certification, you don't have permission of the content author to view the content. (Workarounds will be found, I am sure, but legally, that's how it works.)
4. Microsoft will issue a PIC (driver signing certificate) to pretty much anybody with a valid code publishing certificate from an accepted certification authority. Currently, "accepted certification authority" means Verisign, but MS claims to be willing to entertain other applicants. It is the certification authority that gets the $500, not Microsoft.
5. The point of the signature is identification, not security. Basically, Microsoft wants to be able to identify the author of any kernel-mode code running on Win64. Stable? Well written? That is a completely separate matter covered by a different process. The idea is that if a kernel-mode driver does something stupid/illegal like sniff for passwords, Microsoft wants to be able to track down the author and possibly blacklist/revoke the driver signing certificate if flagrant violations are found.
Yes, this presents some inconvenience for small or not-for-profit organizations that want to write drivers. In most cases (something like WinPCap), I suspect they'll be able to find a "sponsor" organization willing to sign the driver. Other drivers can really never be trusted (CoLinux, for example) because the driver loads arbitrary externally supplied code into the kernel, so sponsors might be more hesitant to sign them (their certificate would probably be blacklisted).
On the other hand, it means that any rootkit/sniffer/malicious driver will have a name and address associated with it -- very handy for picking up the trail of the author (or at least shutting him/her down via certificate revocation).
About 1 week ago, I installed RC1++ (RC1 refresh, 5728 or something like that). It installed smoothly on my computer at home (previous builds of Vista have given me tons of driver problems).
I can dual boot between XP and Vista. I was originally planning to just use Vista for testing (the program I work on is not yet 100% Vista compatible, so I need a Vista machine to use for testing my fixes). However, it has worked well enough for me that I haven't booted back to XP all week. That says a lot.
One thing I've learned about Vista is that there are a few places where a driver problem will drag your performance down. For example, the system does more disk flushes than XP. One driver was not handling the flushes well, and the result was that previous versions of Vista felt terribly slow. I was blaming it on the Video card, but it turned out to be the RAID driver. Once that driver got updated, the performance (along with my opinion of Vista) went up about 3 notches.
There are definitely pros and cons.
Pro: Vista looks nifty, runs smoothly and has a nice feel to it. It just looks and feels polished to me, if you care about that kind of thing. The machine I've been using gets a performance rating of 4 or 5 on everything except the graphics card, which rates a 2, but the Aero interface is still fast enough that I can leave it on. (Occasionally, dragging a Window is a bit sluggish, but most of the time it is fine.)
Con: Lots of things are in new places. I know my way around XP like... Well, pretty darn well. I don't know my way around Vista. On the other hand, there are search boxes in convenient places in Vista, and you can search for things like where to find setting X or how to fix problem Y.
Pro: Console window is improved. The console behaves the same, but I can put a TrueType font on my console window and it still scrolls faster than it did in XP with a bitmap font. Scrolling the console window at max speed no longer takes 100% CPU.
Con: I still don't like the UAC prompt that pops up whenever I do anything that requires administrator privileges. I've gotten used to it, though. (Basically, I think of it as automatic SU without a password requirement.) It actually makes sense to have something like that, and it allows me to run at reduced privilege and still have easy access to Admin tasks. On the other hand, it could still use some work. For example, I wish the "control panels that require administrative privileges" were all grouped together so I could just click on one UAC prompt and be done with it. As it is, I have to accept one UAC prompt here to change setting A, another UAC prompt for setting B, another over there... And if I want to copy a file to a restricted location, then rename it, then edit it, I have to approve 3 different UAC prompts. However, once I got the system set up the way I like it, the prompts come up more rarely, and the occasional UAC prompt for something significant become natural.
The only issues I have are with a few programs that don't behave well without Admin privileges. Upgrades are coming soon for them, and I have figured out workarounds for now. This is probably a good thing, as it will give software vendors a good kick in the pants to get their programs fixed to not require admin.
You need to add physical memory until your performance is adequate.
You need to add swap until you have enough. You have enough if you don't run out of (virtual) memory while doing whatever you need to do with the system.
On my main (fast) system, I have a lot of physical memory. I have about 1.5X that much swap set up, because occasionally I load a lot of programs at once.
On a test (slow) system, I have very little physical memory. I have about 10X that much swap set up, because I still need to run programs that allocate a lot of memory, but their working set tends to stay small, so they run ok even when 90% is in swap.
That's not due to pre-emptive swapping. Pre-emptive swapping makes your hard disk work more when the system is idle, but it doesn't force anything out of memory.
Your issue is due to an incorrect decision somewhere (not sure where) about how much memory to make available to WoW's direct (memory allocation) and indirect (disk cache) needs. WoW IS taking advantage (directly or indirectly) of that extra memory, but it probably only makes a 0.1% performance difference and you would rather it left your other programs in RAM. That is a hard situation to tune for.
Note that there are (at least) two different ways for memory to be used even when it shows up as "free". One is via disk cache. The other is via large temporary allocations that are made, used, and then freed before they really register on the performance monitor.
You obviously recognize the times when it would be valuable to have the guest be completely oblivious to the fact that it is being virtualized, so I won't go into that side of the argument.
If the guest knows that it is running virtualized, it can optimize itself accordingly. VMWare can emulate a PIT, sound card, IDE port, ethernet card, video card, etc. well enough that the guest can load standard drivers and run well. Or it can tell the guest "yes, you can use the driver for a real ethernet card if you want, but you can get 10X better performance if you just do this instead..."
The interface specification for an ethernet card is a very good interface for OS to hardware communication. It turns out to be extremely inefficient as an interface between OS and a host, involving many expensive context switches, state machines, hardware emulation and translation, etc. If the OS (or at least the driver) is aware that it is being virtualized and knows how to communicate with the host, performance can be seriously improved and all kinds of nifty features become possible.
Though this is one interesting thought about JITted environments such as Java and.NET -- they CAN (and do) inline between dynamic libraries at JIT time, gaining some performance advantages that non-JITted code cannot. This can even work with AOT (ahead-of-time) compiling for.NET starting with version 2.0.
Accusation: Nintendo doesn't have their Wii hardware ready and is just running the demos on GameCube hardware with a new controller plugged in.
Fact: Nintendo doesn't have their Wii hardware ready and is just running the demos on GameCube hardware that has been upgraded to Wii specs with a new controller plugged in.
Difference: Accusation is correct: Nintendo doesn't have final hardware ready yet (no biggie). Accusation is incorrect: Nintendo is just using GameCube hardware for demos and dev kits and hasn't gotten the updated hardware story figured out yet (this would be scary).
Not really. The signing process only requires a certificate, not any buyoff from Microsoft. Anybody who can afford the certificate can create a driver.
This is basically saying "Windows won't let you run kernel-mode code unless you tell it the name of the company who wrote the code". The signature allows the user to identify the source of all kernel-mode code on his/her system and to verify that none of that kernel-mode code has been tampered with.
amd64 is AMD's implementation of a 64-bit architecture. em64t is Intel's. Microsoft doesn't want to be seen as favoring one over the other (AMD and Intel are both important partners), so it has to pick something different from either of them.
There is actually some value to getting a game to run at a framerate higher than VSync. The framerate is an average rate, so the actual framerate goes up and down depending on the scene complexity. With an average framerate of 60 fps, you are going to hate life when you walk into a room with something actually going on and your frame rate drops to 15 fps. On the other hand, if your average framerate is 100 fps, things are still ok when the things get busy and the rate drops down to 60 fps.
While MPEG-4 is cool and all, don't forget that in many cases you have to pay royalties to use it. This is often above and beyond what you paid for the encoder and the player. The MPEG-4 codec is covered by patents and is NOT public domain.
WMV is not (currently) subject to any content royalties as long as you're using a licensed encoder and player. And it comes pre-installed with Media Player 9 or later, and is available for earlier players in a simple codec pack.
OGG is probably free of all royalties, but comes with its own installation and distribution complexities.
Slashdot Mirror
One process per concurrent connection. After the connection is closed, the process is reused for another connection.
I love this response. "Microsoft can make better programs because they use the super-secret ultra-special hidden APIs." Completely false. Though sometimes I wish there were secret hidden APIs that could be used to somehow make programs work better, this seems pretty far-fetched.
Microsoft employees use MSDN for documentation just like everybody else. While it is possible that they have access to better support options than the average developer (i.e. their friends that work on the Windows team can given them advice), there is no secret sauce available. Just elbow grease.
In fact, SQL Server has it worse than non-Microsoft products. Beyond the simple absurdity of "secret APIs", there are also legal restrictions. SQL Server (just like any other non-Windows* MS product) legally must restrict itself to public Windows APIs. As a part of the antitrust restrictions on Microsoft operations, if the API is not documented on MSDN, SQL Server cannot use it. Every other company gets to use whatever Microsoft API they can find, however they can find it. SQL Server has to do everything by the book. Not only that, but the SQL Server team (and the teams behind every other non-Windows program shipped by Microsoft) has to be able to document that they aren't using any undocumented APIs.
On the other hand, SQL Server has it better than other databases. The SQL Server team gets to focus its efforts on a single OS. SQL Server is TIGHT (like this!) with Windows. It has been tuned and re-tuned to work well on Windows. It leverages the Win32 API like no other database on the market. No abstraction layers, no designing to the lowest common denominator, no limitations because "one of the OSes we support can't do that". (Well, not entirely true -- multiple versions of Windows with differing capabilities are supported, but still mostly true.) SQL Server makes use of the Windows OS like probably no other program that has ever been written.
If Microsoft programs ever outshine the competition, it is because they got more effort put into them or were designed better. And when other programs work better than Microsoft's, it is because they got more effort or were designed better. No secret sauce, no secret APIs.
* (Windows components do use internal and undocumented APIs to communicate with other Windows components. That's just abstraction layers at work - every program I can think of uses undocumented APIs to talk to other parts of itself. In any case, only Windows components are allowed to use undocumented Windows APIs.)
That would be all well and good, except that Max OS X's mechanism isn't secure. The reason Vista's mechanism is more complex is because it deals with security issues that Mac OS X ignores. There is an inherent tradeoff between security and convenience, and Microsoft has tried to emphasize security here. Maybe Mac OS X chose a better balance between security and convenience, but only time will tell.
All you need is 1 GB RAM, enough hard drive space, and Vista drivers for your hardware. Unless you insist on running Aero, Vista will run just fine on most XP-spec hardware (though you may need to add some more RAM).
I ran Vista on an old desktop with 1 GB of RAM and it worked great. It was a bit sluggish on my old laptop (512 MB), but still usable. With 2GB of RAM, my new laptop is doing quite nicely. No performance issues at all.
I will certainly admit that there are a lot of things to like about OS X, and for some people, it will be the better choice. For others, Windows is better, and Vista is a big step forward.
The article comes across as "Why OS X is better than Vista" instead of "Comparison of OS X and Vista". But that's par for the course. The author does have some valid comments about areas that could have been done better in Vista.
I do disagree on some of the evaluations of Vista's merits. The most misunderstood area is User Access Control.
Not that UAC is perfect -- I've got a nice list of things I don't like about it. For example, if the system incorrectly detects that a program probably needs to run as Admin, it is a bit of a pain to convince the system to just run it normally. And there aren't any good tools for working with UAC from the command line (i.e. I want an equivalent to Unix su). I've written some myself, but they really should have been included with the system. And some tasks that should be able to be done by accepting one UAC prompt end up requiring 5 or 6.
However, the author of the article passes UAC off as useless and annoying. Well, it is annoying, but so is finding my car keys every time I want to drive my car. But it is definitely not useless - just misunderstood.
UAC consists of three mechanisms, along with related tools for configuring them:
1. The shell of an Administrator can optionally be run with reduced permissions. This means that if UAC is enabled, the user's shell (explorer.exe) will drop privileges when it is initialized (after the user logs on). In other words, the shell tells the kernel that even though it is running under the account of an Administrator, the kernel should deny any requests to use administrator privileges, and should not grant any access to resources based on the user's membership in the Administrators group.
2. There is a mechanism to regain administrator privileges so that administrative tasks can still be performed. If you are logged on as a user in the Administrators group, this mechanism requires a confirmation dialog (ok/cancel). If you are logged on as an unprivileged user, this mechanism requires a username + password of an administrator ("over the shoulder login").
Note that this mechanism must be protected from abuse. Potential abuses include: keyloggers (capture the administrator's password), event injection (simulate a mouse-click or keyboard event to respond to the confirmation dialog automatically), and luring (put a malicious executable with the same name as a trusted executable into the user's path, then trick the user into trying to run the trusted executable). Protecting against these abuses leads to a bit more inconvenience, but a lot more safety. This is why nothing else can be done while the UAC prompt is active -- the UAC prompt turns on some security features to protect against keyloggers and event injection. This is something that is more annoying than OS X's system, but also significantly more secure.
3. There is a mechanism to detect programs that require administrator privileges. Vista-aware applications include a manifest that tells the program loader whether administrator privileges are required. Vista also tries to automatically detect non-Vista-aware applications that require administrator privileges (such as installers). For now, this is a bit of a pain when it doesn't work, but in the future, this will end up working well. For example, as the author indicated, it becomes more challenging to install a pre-Vista application to your personal folder without help from an admin (Vista detects that the installer probably needs admin privileges). In the future, the installer will have a manifest telling Vista that it doesn't need admin privileges immediately, and will ask for them only if the user decides to install the app onto the system instead of to a personal folder.
I've been using Office 2007 for several months now (yes, I work for MS). I never would have realized that there was a steep learning curve had I not read this article. Up till now, I just used it without really thinking about it much. Now I realize that I must have been doing things incorrectly, since I haven't made any drastic changes from the way I used Office 2003 and Office XP.
Seriously, I'm a very experienced computer user (I've been doing tech support for my family for something like 16 years now), so I may be overlooking things that would confuse a less experienced user. I'm a developer, so I spend more time in Vim than I do in Word, so I don't use the complex features much (most days I just use Outlook). And I'm probably a bit biased, since if people buy more Office 2007, my stock in MS goes up. But I can honestly say that at least for me, the switch was natural and I gave it little thought. Adapting to the new interface has not been a problem.
There are some nifty new features, including RSS browsing in Outlook, and some things are a bit more refined (they fixed a number of little annoyances). I definitely prefer the new version. That said, there isn't anything I couldn't do without (though I suppose that could be said about any upgrade, since I somehow did without it before...).
How is it even going to know? Nothing really changes except that the processor is now in the VM mode. Since Windows doesn't look at the VM mode bit, as far as Windows can tell, nothing has changed.
Not to say that pulling this off is easy... Just that the challenge is not in fooling Windows or preventing it from freaking out.
Think about VMWare -- Windows doesn't royally freak out when it is running as a VM under VMWare.
The hardware issue is very different for a rootkit versus VMWare. VMWare has to virtualize the hardware so that it can redirect the guest OS's calls to the host OS and make it play nice. A rootkit doesn't have to do this. It can let the "guest" OS directly access the hardware.
The rootkit doesn't have to help the guest OS share the hardware with another OS. All it has to do is hide itself and watch for interesting tidbits of information.
1. This is not news. Driver writers have known about this for years. This is how XP-64 and Server2003-64 work already. And this has been posted on Slashdot at least twice before.
2. Win64 (whether Vista, 2003, and XP) requires signed drivers unless you boot up in "debug" mode. Win32 does not, although it will warn you.
3. If you have any unsigned drivers running (Win64 OR Win32), certain "trusted path" applications (i.e. DRM-enabled video players) will not run. Basically, the content author says "I only give permission to watch this video if your system is trusted" (for some definition of trusted, as defined by the content author). Microsoft is providing a way to certify your system as trusted. Without this certification, you don't have permission of the content author to view the content. (Workarounds will be found, I am sure, but legally, that's how it works.)
4. Microsoft will issue a PIC (driver signing certificate) to pretty much anybody with a valid code publishing certificate from an accepted certification authority. Currently, "accepted certification authority" means Verisign, but MS claims to be willing to entertain other applicants. It is the certification authority that gets the $500, not Microsoft.
5. The point of the signature is identification, not security. Basically, Microsoft wants to be able to identify the author of any kernel-mode code running on Win64. Stable? Well written? That is a completely separate matter covered by a different process. The idea is that if a kernel-mode driver does something stupid/illegal like sniff for passwords, Microsoft wants to be able to track down the author and possibly blacklist/revoke the driver signing certificate if flagrant violations are found.
Yes, this presents some inconvenience for small or not-for-profit organizations that want to write drivers. In most cases (something like WinPCap), I suspect they'll be able to find a "sponsor" organization willing to sign the driver. Other drivers can really never be trusted (CoLinux, for example) because the driver loads arbitrary externally supplied code into the kernel, so sponsors might be more hesitant to sign them (their certificate would probably be blacklisted).
On the other hand, it means that any rootkit/sniffer/malicious driver will have a name and address associated with it -- very handy for picking up the trail of the author (or at least shutting him/her down via certificate revocation).
About 1 week ago, I installed RC1++ (RC1 refresh, 5728 or something like that). It installed smoothly on my computer at home (previous builds of Vista have given me tons of driver problems).
I can dual boot between XP and Vista. I was originally planning to just use Vista for testing (the program I work on is not yet 100% Vista compatible, so I need a Vista machine to use for testing my fixes). However, it has worked well enough for me that I haven't booted back to XP all week. That says a lot.
One thing I've learned about Vista is that there are a few places where a driver problem will drag your performance down. For example, the system does more disk flushes than XP. One driver was not handling the flushes well, and the result was that previous versions of Vista felt terribly slow. I was blaming it on the Video card, but it turned out to be the RAID driver. Once that driver got updated, the performance (along with my opinion of Vista) went up about 3 notches.
There are definitely pros and cons.
Pro: Vista looks nifty, runs smoothly and has a nice feel to it. It just looks and feels polished to me, if you care about that kind of thing. The machine I've been using gets a performance rating of 4 or 5 on everything except the graphics card, which rates a 2, but the Aero interface is still fast enough that I can leave it on. (Occasionally, dragging a Window is a bit sluggish, but most of the time it is fine.)
Con: Lots of things are in new places. I know my way around XP like... Well, pretty darn well. I don't know my way around Vista. On the other hand, there are search boxes in convenient places in Vista, and you can search for things like where to find setting X or how to fix problem Y.
Pro: Console window is improved. The console behaves the same, but I can put a TrueType font on my console window and it still scrolls faster than it did in XP with a bitmap font. Scrolling the console window at max speed no longer takes 100% CPU.
Con: I still don't like the UAC prompt that pops up whenever I do anything that requires administrator privileges. I've gotten used to it, though. (Basically, I think of it as automatic SU without a password requirement.) It actually makes sense to have something like that, and it allows me to run at reduced privilege and still have easy access to Admin tasks. On the other hand, it could still use some work. For example, I wish the "control panels that require administrative privileges" were all grouped together so I could just click on one UAC prompt and be done with it. As it is, I have to accept one UAC prompt here to change setting A, another UAC prompt for setting B, another over there... And if I want to copy a file to a restricted location, then rename it, then edit it, I have to approve 3 different UAC prompts. However, once I got the system set up the way I like it, the prompts come up more rarely, and the occasional UAC prompt for something significant become natural.
The only issues I have are with a few programs that don't behave well without Admin privileges. Upgrades are coming soon for them, and I have figured out workarounds for now. This is probably a good thing, as it will give software vendors a good kick in the pants to get their programs fixed to not require admin.
I think so.
Hey, that would have been a good answer to the "why AM2" question...
Pacifica is out on AM2, and it is widely regarded as superior to Intel's VT. This is mainly due to Pacifica's support for "nested page tables".
You need to add physical memory until your performance is adequate.
You need to add swap until you have enough. You have enough if you don't run out of (virtual) memory while doing whatever you need to do with the system.
On my main (fast) system, I have a lot of physical memory. I have about 1.5X that much swap set up, because occasionally I load a lot of programs at once.
On a test (slow) system, I have very little physical memory. I have about 10X that much swap set up, because I still need to run programs that allocate a lot of memory, but their working set tends to stay small, so they run ok even when 90% is in swap.
That's not due to pre-emptive swapping. Pre-emptive swapping makes your hard disk work more when the system is idle, but it doesn't force anything out of memory.
Your issue is due to an incorrect decision somewhere (not sure where) about how much memory to make available to WoW's direct (memory allocation) and indirect (disk cache) needs. WoW IS taking advantage (directly or indirectly) of that extra memory, but it probably only makes a 0.1% performance difference and you would rather it left your other programs in RAM. That is a hard situation to tune for.
Note that there are (at least) two different ways for memory to be used even when it shows up as "free". One is via disk cache. The other is via large temporary allocations that are made, used, and then freed before they really register on the performance monitor.
I would vote to make it configurable.
You obviously recognize the times when it would be valuable to have the guest be completely oblivious to the fact that it is being virtualized, so I won't go into that side of the argument.
If the guest knows that it is running virtualized, it can optimize itself accordingly. VMWare can emulate a PIT, sound card, IDE port, ethernet card, video card, etc. well enough that the guest can load standard drivers and run well. Or it can tell the guest "yes, you can use the driver for a real ethernet card if you want, but you can get 10X better performance if you just do this instead..."
The interface specification for an ethernet card is a very good interface for OS to hardware communication. It turns out to be extremely inefficient as an interface between OS and a host, involving many expensive context switches, state machines, hardware emulation and translation, etc. If the OS (or at least the driver) is aware that it is being virtualized and knows how to communicate with the host, performance can be seriously improved and all kinds of nifty features become possible.
Though this is one interesting thought about JITted environments such as Java and .NET -- they CAN (and do) inline between dynamic libraries at JIT time, gaining some performance advantages that non-JITted code cannot. This can even work with AOT (ahead-of-time) compiling for .NET starting with version 2.0.
That's why you only inline stuff from static libraries, not stuff from dynamic libraries.
THIS IS THE RIGHT ANSWER.
Of course, the moderators will never see it, but hopefully the original poster will.
It looks like everybody is missing the point.
Accusation: Nintendo doesn't have their Wii hardware ready and is just running the demos on GameCube hardware with a new controller plugged in.
Fact: Nintendo doesn't have their Wii hardware ready and is just running the demos on GameCube hardware that has been upgraded to Wii specs with a new controller plugged in.
Difference: Accusation is correct: Nintendo doesn't have final hardware ready yet (no biggie). Accusation is incorrect: Nintendo is just using GameCube hardware for demos and dev kits and hasn't gotten the updated hardware story figured out yet (this would be scary).
Flamebait?
C'mon. It's funny. Laugh. And maybe visit a Gentoo forum (they're funny too!).
(Not to knock Gentoo -- it's a decent distro. But some of the posts on the forums are, shall we say, a bit over the top.)
Not really. The signing process only requires a certificate, not any buyoff from Microsoft. Anybody who can afford the certificate can create a driver.
This is basically saying "Windows won't let you run kernel-mode code unless you tell it the name of the company who wrote the code". The signature allows the user to identify the source of all kernel-mode code on his/her system and to verify that none of that kernel-mode code has been tampered with.
amd64 is AMD's implementation of a 64-bit architecture. em64t is Intel's. Microsoft doesn't want to be seen as favoring one over the other (AMD and Intel are both important partners), so it has to pick something different from either of them.
There is actually some value to getting a game to run at a framerate higher than VSync. The framerate is an average rate, so the actual framerate goes up and down depending on the scene complexity. With an average framerate of 60 fps, you are going to hate life when you walk into a room with something actually going on and your frame rate drops to 15 fps. On the other hand, if your average framerate is 100 fps, things are still ok when the things get busy and the rate drops down to 60 fps.
Sure. Its just something to keep in mind when selecting the technology - what is it going to cost me?
While MPEG-4 is cool and all, don't forget that in many cases you have to pay royalties to use it. This is often above and beyond what you paid for the encoder and the player. The MPEG-4 codec is covered by patents and is NOT public domain.
WMV is not (currently) subject to any content royalties as long as you're using a licensed encoder and player. And it comes pre-installed with Media Player 9 or later, and is available for earlier players in a simple codec pack.
OGG is probably free of all royalties, but comes with its own installation and distribution complexities.