One of the reasons MSOffice loads so quickly is that it adds a "quick launch" app to Windows Startup. Part of the code loads every time you boot (adding to boot time and sucking up system resources) so that Office can load quicker.
Despite that fact that I use the MS Office applications a lot, I delete the shortcut to the quick load app because all it seems to do is slow down boot time without speeding up the loading of any Office apps.
Of course, since most of the apps load in less than 2 seconds on my moderately modern hardware (2.8GHz dual core, 3GB RAM), I'm not sure how you could speed it up.
If you ask me, Windows 7 will suffer many of the same problems
The #1 problem of Vista was the poor performance on the average hardware available for sale at the time of the release.
All software has bugs, but Vista just needed more machine than was possible to sell at a low enough price to get a large uptake.
Microsoft will "solve" this problem with Windows 7 by doing nothing but let Moore's Law lead to the inevitable faster hardware for the same price. At this point, Windows 7 looks to be nothing more than Vista with just enough changes for people to say "ooh, shiny new", but none of those changes are significant enough to require more machine to run them.
Add in the fact that it will use the same drivers as Vista, and Windows 7 will have much better hardware support at launch, which will also help the PR.
Basically, Microsoft couldn't sell a crappy OS last year, but next year they hope to convince people to buy a service pack for that same OS just because they give it a name different from "Service Pack 3".
Ballmer's net worth is 15 billion dollars on paper for the moment.
Remind me how it's divested entirely from the Microsoft shares he holds?
Even if Microsoft stock collapsed to a relatively unthinkable low, Ballmer probably would end up with stock worth north of $100M.
Remember that Microsoft has billions of cash in the bank, a large amount of real property, and no debt. So, unlike many other companies, their stock has a absolute bottom value (it could go lower, but then it would be pushed right back up as people bought it).
So, really, it's just a bunch of marketing hacks who go off on their own and come up with a bunch of names and then get together in a room and toss them around until one sticks.
If the monthly fee were truly small (say $10), and the content worthwhile, I'd be happy to pay.
But, I suspect that my definition of "worthwhile" wouldn't make the game companies very happy. I'd want the ability to play to every game they had ever made (within reason...say less than 10 years old) for that $10/month.
Basically, since the average game company puts out at most 2 good games a year, then it's still $60/game I would have purchased anyway, but I'd also have the ability to at least play around with the other games, and maybe some of them would be worth a few bucks, even if I wouldn't ever have thought about buying the game as a standalone.
For anyone interested, when I registered to allow me to do the download, it took the Sun server 30 seconds from the time I hit the "Register" button until it returned the result page.
I guess they aren't using the bad-ass storage they are trying to sell.
Last I checked Netapp was still charging $10,000 per TB! Do you really think there is no reason for this?
Of course there's a reason for this...the CEO needs a new private jet.
Really, the profit in the storage arena is insane. Part of that because the marketing convinces management they need 50,000 IOPS to run what is essentially a flat-file database. Add in the "reliability" and "support" (which generally means that if you don't mind being told that a replacement part won't be in for a week and as long as you follow standard backup strategies, you probably won't actually lose any data), and it's pretty much a license to print money.
You really can do a lot of this stuff much cheaper, and even Sun know this. As other people have pointed out, Sun already sells much cheaper solutions to the exact same problem.
Passing the CPUID information will give you the identity of the original processor, but not the actual capabilities. You could also pass the whole set of extended CPUID information to know which flavors of SSE are (or aren't) supported, etc., but that still isn't the true capabilities and details of the CPU.
The reason you can't emulate efficiently is because the matrix of "VM CPU" to "physical CPU" would be large...very large. And, it would include things that would require the hypervisor to trap an instruction because even though the "physical CPU" and the "VM CPU" both support the instruction, they do so in a slightly different way, with different side effects.
The masking technique that VMware uses doesn't require the VM kernel to know anything about exactly what instructions are or are not supported. The CPUID the VM sees doesn't show capabilities that the actual processor might have, so the OS doesn't try to use those instructions (and, if it does, they don't work and weird things happen, just like on a physical machine).
Heck, there are some programs right now that run fine in a VM, but if you live migrate them to another system that has only a slightly different CPU (speed, cache size, etc.), the program either performs very poorly or does strange things. Usually, these are programs that aren't very portable anyway (using delays based on calculated CPU speed, picking algorithms based on cache size, etc.), but that's an example of how things can go to hell even with a small change in the live migration.
however, sometimes the cost of the overhead of emulation might be less than the cost of rebooting the VM, or keeping an obsolete type of machine working, and in that case it would be nice to be able to migrate the VM to another type of processor.
Really, this just isn't a scenario that would happen. VMs are commodities that can run generally anywhere. Keeping a truly obsolete host running is always going to be far more expensive than just getting some more modern hardware to replace it. Also, any service that needs to be running 24/7/365 isn't going to be a single machine, it's going to be on something truly high availability (a clustered solution, etc.).
You'd stop the VMs on the obsolete server and then restart them on a server that is compatible with modern hardware virtualization. It would quite literally take a few minutes if the VM disk is on a shared resource (which is required for live migrations, anyway). Then, you would have the VM running in a modern cluster of all the same brand of CPU.
As a side note, one of the huge advantages of a VM is the ability to reboot it very, very quickly. Physical servers often have to do all sorts of hardware checks that are not done by the VM. Plus, virtual hardware on the VM doesn't need any artificial delays that physical hardware might need. So, basically, it's only the OS shutdown and startup you have to deal with, and that's generally not too bad.
Google for "Enhanced VMotion Compatibility" and you'll see that you don't have to do any manual work to allow every processor that supports hardware virtualization to participate in your cluster.
The only caveats are that you can't have any VMs running when you enable this feature. This is not a big deal if you enable it when you first create the cluster, and only a problem if you bring a new host with running VMs into the cluster. But, a small amount of planning deals with that, too.
Not usefully, and even so, you're still likely to take needless performance hits.
If the VM started running on a Xeon Harpertown and moved to an AMD Santa Rosa, then to a Core 2 Quad Yorkfield, which features should be enabled/disabled in each move?
First, DLLs and other shared code are missed by your idea. These are one of the worst infection vectors in Windows.
Second, the average user doesn't know what has to run to keep the system doing the right things, and getting dozens of popups would result in the same thing that is happening with UAC...people would be conditioned to just click "Yes" to get rid of the box. You want these boxes to be rare enough that they mean something to the user.
Plus, if you have verified from essentially outside the system that there are no viruses in any directory under "C;\Program Files", then why bother asking the user?
My preference would be to do things completely manually, requiring the user to approve everything.
With a PE component to the AV software, only the most critical files (kernel, some device drivers, etc.) would have to be "auto-approved". Also, I suppose that anything that runs before the AV runs would be an issue, but that's the case now, too.
And, when you think about it, any instruction that you would have to trap if the VM used to be running on a different processor must be trapped at all times.
This is because you have no way of knowing which processor type the VM was first started on. When this happened, it's likely the OS did some hardware checking and figured out which instructions it could (and could not) use. Moving the VM isn't going to change what the OS believes is the processor, and that's the problem.
Overall, VMware's Enhanced VMotion Compatibility method of lying to the OS about the capablilities of the processor seems to be the easist way of doing this. But, they only do it within one CPU manufacturer, because otherwise you'd end up with a very low-featured virtual processor.
VMware doesn't require "identical" hardware to do live migration, either.
It does have to be similar enough, which at this point pretty much means just the same processor manufacturer. As long as the processor supports the hardware virtualization, then VMware will allow you to set up a cluster that will allow live migration with no issues.
The thing about anti-virus software is that is stupidly tries not to be intrusive. AV software could be pretty much 100% effective with a few tiny changes, but those changes will make it more visible and annoying.
At install, the AV software adds a "run at reboot" entry that runs in the PE boot time, before most (but not all) other processes get a chance to run and does a full system scan at that point. You don't get to continue the install until you agree to this reboot.
After the scan, the AV software (still in the PE environment) picks a few select directories (like "C:\Windows" and "C:\Program Files") and creates checksums of all files in those directories (or subdirectories).
When the re-boot finishes and the install completes, the user is given the option to add other directories to the "safe" list, and file checksums in those directories are computed.
After this, the AV software will not allow a file on disk to be run as an executable unless it is in one of the "safe" directories and the checksum exists and has not changed.
Any other attempt to execute a file results in a full scan of the file using the virus signatures, and the user is then given a warning about running non-trusted executable and analysis of the scan.
The AV software will provide a way to manually update the "safe" directories, so that after you install software you can run it, but there should be no way to automate it.
As an option, the AV software blocks write access to every executable file in the "safe" directories.
This won't protect against scripting language malware and exploits of ActiveX (or other in-process DLL code), but it will tend to stop what they can do in the long run. Exploit code can create an executable in some directory, but it won't be able to be run without a warning, even if that code contains no known virus.
As an example, the US uses 6MHz channel steps, the UK uses 8MHz, and Australia uses 7MHz steps on UHF and varying steps on VHF.
In addition, the modulation methods are different among the different countries. Building a device that would successfully identify a digital carrier for all TV systems worldwide so that it could avoid that frequency block would be a non-trivial and expensive task.
There's several hundred megahertz of open spectrum in between the TV channels.
There is no "open" spectrum in the US TV channels:
VHF Lo: 54-72MHz, 76-88MHz
VHF Hi: 174-216MHz
UHF: 470-806MHz
All gaps in that table are filled with some other official allocation.
Now, there are places where there is no local TV channel assigned to a particular chunk of that spectrum, but this is not "open"...in many places it is not assigned because it would conflict with another TV transmitter that is close enough to be received.
The problem with this "white space" vote is that devices won't have to avoid interfering with anything but the very strong signals, so that means people like me who get TV from DC, Baltimore, Philadelphia, Harrisburg, and sometimes Richmond will fall back to getting only the "local" channels.
But, I use "Launch folder windows in a separate process" since that leads to more stability, and that might be the difference.
Still, icons in the system tray don't put themselves back when you restart Explorer...they need to be restarted themselves to make it work.
I do know that at least some of the things that run at "logon" will run if you restart Explorer, but I need to spend some time checking which ones they are.
As for the 3 minute startup...unless you have 10-year-old machine, you need to ditch some of the startup tasks. You really don't need most of those things running automatically at login. Either that, or investigate some utilities that allow you to delay the startup of less important things.
For hardware, I use a folder structure of Type/Manufacturer/Model/OS/Version in my setup.
So, I have:
Video Cards/ATI/Radeon/WinXP/Catalyst 7.10
Video Cards/ATI/Radeon/WinXP/Catalyst 8.01
Video Cards/ATI/Radeon/WinXP/Catalyst 8.08
I also don't keep the original ZIP or self-extracting EXEs, but instead something that is ready-to-use. This is good if there isn't an install file, but instead you just use Device Manager to "Update Driver". Also, for slower machines or systems with low disk space, it sometimes allows an install to complete when it wouldn't otherwise.
I don't keep everything, but I use something like the kernel install system for most package managers...keep a few versions, so that you can regress to something that isn't broken if necessary.
OK, so you don't install the device at all, in which case drivers don't matter.
Seriously, if I download newer drivers, then the same thing happens to them...they get stashed away. And, when it turns out that version 2.4 of the driver screws up the hardware, I can always revert to version 2.3 (or 2.0, or 1.8, etc.). It doesn't matter to me where the hardware came from...the driver gets saved away.
And, if I bought hardware that didn't work regardles of the driver, it gets returned. So, I wouldn't have had a "rubbish little device" sitting around to work a few years later once Linux got around to supporting it.
Its an application like any other that can be killed, move, restarted, or even removed.
Except, of course, for the fact that killing the "root" explorer.exe ends up causing you pretty ugly problems.
For example, when you kill off the explorer.exe process controlling your taskbar and system tray, starting Explorer again usually leaves you with a mess, since the running tasks don't go back into the tray. Then, too, everything that was in the various "autorun" places gets run again because Explorer is too dumb to figure out this isn't the first time it is being run.
Basically, because Explorer is the display shell and hooks into so damn much, but it isn't really the root process for your login, the whole setup is so fragile that the only way to make sure everything ends up right is to log out and log back in.
What is with all these Slashdot users who "lost the driver disc"?
The first thing I do with any driver disc (or any other software, for that matter) is copy it to my install respository that sits on a RAID array and is backed up regularly. I pretty much never clean that up, so I have drivers for hardware I don't own anymore.
A quick check shows I have Soundblaster drivers from 14 years ago.
Despite being such a pack rat, and literally keeping everything there (like install source for the last 3 versions of MS Office, every game I've ever purchased, etc.), it only takes up 330GB, which is less than $50 worth of disk space.
Slashdot Mirror
One of the reasons MSOffice loads so quickly is that it adds a "quick launch" app to Windows Startup. Part of the code loads every time you boot (adding to boot time and sucking up system resources) so that Office can load quicker.
Despite that fact that I use the MS Office applications a lot, I delete the shortcut to the quick load app because all it seems to do is slow down boot time without speeding up the loading of any Office apps.
Of course, since most of the apps load in less than 2 seconds on my moderately modern hardware (2.8GHz dual core, 3GB RAM), I'm not sure how you could speed it up.
Why yes...yes, it has.
I wish I could get some money to cover my relatively intelligent 401(k) investments like the banks are getting to cover their stupid investments.
If you ask me, Windows 7 will suffer many of the same problems
The #1 problem of Vista was the poor performance on the average hardware available for sale at the time of the release.
All software has bugs, but Vista just needed more machine than was possible to sell at a low enough price to get a large uptake.
Microsoft will "solve" this problem with Windows 7 by doing nothing but let Moore's Law lead to the inevitable faster hardware for the same price. At this point, Windows 7 looks to be nothing more than Vista with just enough changes for people to say "ooh, shiny new", but none of those changes are significant enough to require more machine to run them.
Add in the fact that it will use the same drivers as Vista, and Windows 7 will have much better hardware support at launch, which will also help the PR.
Basically, Microsoft couldn't sell a crappy OS last year, but next year they hope to convince people to buy a service pack for that same OS just because they give it a name different from "Service Pack 3".
Remind me how it's divested entirely from the Microsoft shares he holds?
Even if Microsoft stock collapsed to a relatively unthinkable low, Ballmer probably would end up with stock worth north of $100M.
Remember that Microsoft has billions of cash in the bank, a large amount of real property, and no debt. So, unlike many other companies, their stock has a absolute bottom value (it could go lower, but then it would be pushed right back up as people bought it).
So, really, it's just a bunch of marketing hacks who go off on their own and come up with a bunch of names and then get together in a room and toss them around until one sticks.
If nothing sticks, rinse and repeat.
If the monthly fee were truly small (say $10), and the content worthwhile, I'd be happy to pay.
But, I suspect that my definition of "worthwhile" wouldn't make the game companies very happy. I'd want the ability to play to every game they had ever made (within reason...say less than 10 years old) for that $10/month.
Basically, since the average game company puts out at most 2 good games a year, then it's still $60/game I would have purchased anyway, but I'd also have the ability to at least play around with the other games, and maybe some of them would be worth a few bucks, even if I wouldn't ever have thought about buying the game as a standalone.
For anyone interested, when I registered to allow me to do the download, it took the Sun server 30 seconds from the time I hit the "Register" button until it returned the result page.
I guess they aren't using the bad-ass storage they are trying to sell.
Last I checked Netapp was still charging $10,000 per TB! Do you really think there is no reason for this?
Of course there's a reason for this...the CEO needs a new private jet.
Really, the profit in the storage arena is insane. Part of that because the marketing convinces management they need 50,000 IOPS to run what is essentially a flat-file database. Add in the "reliability" and "support" (which generally means that if you don't mind being told that a replacement part won't be in for a week and as long as you follow standard backup strategies, you probably won't actually lose any data), and it's pretty much a license to print money.
You really can do a lot of this stuff much cheaper, and even Sun know this. As other people have pointed out, Sun already sells much cheaper solutions to the exact same problem.
Passing the CPUID information will give you the identity of the original processor, but not the actual capabilities. You could also pass the whole set of extended CPUID information to know which flavors of SSE are (or aren't) supported, etc., but that still isn't the true capabilities and details of the CPU.
The reason you can't emulate efficiently is because the matrix of "VM CPU" to "physical CPU" would be large...very large. And, it would include things that would require the hypervisor to trap an instruction because even though the "physical CPU" and the "VM CPU" both support the instruction, they do so in a slightly different way, with different side effects.
The masking technique that VMware uses doesn't require the VM kernel to know anything about exactly what instructions are or are not supported. The CPUID the VM sees doesn't show capabilities that the actual processor might have, so the OS doesn't try to use those instructions (and, if it does, they don't work and weird things happen, just like on a physical machine).
Heck, there are some programs right now that run fine in a VM, but if you live migrate them to another system that has only a slightly different CPU (speed, cache size, etc.), the program either performs very poorly or does strange things. Usually, these are programs that aren't very portable anyway (using delays based on calculated CPU speed, picking algorithms based on cache size, etc.), but that's an example of how things can go to hell even with a small change in the live migration.
however, sometimes the cost of the overhead of emulation might be less than the cost of rebooting the VM, or keeping an obsolete type of machine working, and in that case it would be nice to be able to migrate the VM to another type of processor.
Really, this just isn't a scenario that would happen. VMs are commodities that can run generally anywhere. Keeping a truly obsolete host running is always going to be far more expensive than just getting some more modern hardware to replace it. Also, any service that needs to be running 24/7/365 isn't going to be a single machine, it's going to be on something truly high availability (a clustered solution, etc.).
You'd stop the VMs on the obsolete server and then restart them on a server that is compatible with modern hardware virtualization. It would quite literally take a few minutes if the VM disk is on a shared resource (which is required for live migrations, anyway). Then, you would have the VM running in a modern cluster of all the same brand of CPU.
As a side note, one of the huge advantages of a VM is the ability to reboot it very, very quickly. Physical servers often have to do all sorts of hardware checks that are not done by the VM. Plus, virtual hardware on the VM doesn't need any artificial delays that physical hardware might need. So, basically, it's only the OS shutdown and startup you have to deal with, and that's generally not too bad.
Google for "Enhanced VMotion Compatibility" and you'll see that you don't have to do any manual work to allow every processor that supports hardware virtualization to participate in your cluster.
The only caveats are that you can't have any VMs running when you enable this feature. This is not a big deal if you enable it when you first create the cluster, and only a problem if you bring a new host with running VMs into the cluster. But, a small amount of planning deals with that, too.
Not usefully, and even so, you're still likely to take needless performance hits.
If the VM started running on a Xeon Harpertown and moved to an AMD Santa Rosa, then to a Core 2 Quad Yorkfield, which features should be enabled/disabled in each move?
This has two problems.
First, DLLs and other shared code are missed by your idea. These are one of the worst infection vectors in Windows.
Second, the average user doesn't know what has to run to keep the system doing the right things, and getting dozens of popups would result in the same thing that is happening with UAC...people would be conditioned to just click "Yes" to get rid of the box. You want these boxes to be rare enough that they mean something to the user.
Plus, if you have verified from essentially outside the system that there are no viruses in any directory under "C;\Program Files", then why bother asking the user?
My preference would be to do things completely manually, requiring the user to approve everything.
With a PE component to the AV software, only the most critical files (kernel, some device drivers, etc.) would have to be "auto-approved". Also, I suppose that anything that runs before the AV runs would be an issue, but that's the case now, too.
And, when you think about it, any instruction that you would have to trap if the VM used to be running on a different processor must be trapped at all times.
This is because you have no way of knowing which processor type the VM was first started on. When this happened, it's likely the OS did some hardware checking and figured out which instructions it could (and could not) use. Moving the VM isn't going to change what the OS believes is the processor, and that's the problem.
Overall, VMware's Enhanced VMotion Compatibility method of lying to the OS about the capablilities of the processor seems to be the easist way of doing this. But, they only do it within one CPU manufacturer, because otherwise you'd end up with a very low-featured virtual processor.
VMware doesn't require "identical" hardware to do live migration, either.
It does have to be similar enough, which at this point pretty much means just the same processor manufacturer. As long as the processor supports the hardware virtualization, then VMware will allow you to set up a cluster that will allow live migration with no issues.
The thing about anti-virus software is that is stupidly tries not to be intrusive. AV software could be pretty much 100% effective with a few tiny changes, but those changes will make it more visible and annoying.
This won't protect against scripting language malware and exploits of ActiveX (or other in-process DLL code), but it will tend to stop what they can do in the long run. Exploit code can create an executable in some directory, but it won't be able to be run without a warning, even if that code contains no known virus.
Thank you.
I'm a vi guy, and I just haven't spent much time learning the new features offered by vim. I always wondered what "visual mode" was.
Although vim has good online help, I'm generally too busy actually using it to learn about it.
No, it doesn't.
As an example, the US uses 6MHz channel steps, the UK uses 8MHz, and Australia uses 7MHz steps on UHF and varying steps on VHF.
In addition, the modulation methods are different among the different countries. Building a device that would successfully identify a digital carrier for all TV systems worldwide so that it could avoid that frequency block would be a non-trivial and expensive task.
There's several hundred megahertz of open spectrum in between the TV channels.
There is no "open" spectrum in the US TV channels:
All gaps in that table are filled with some other official allocation.
Now, there are places where there is no local TV channel assigned to a particular chunk of that spectrum, but this is not "open"...in many places it is not assigned because it would conflict with another TV transmitter that is close enough to be received.
The problem with this "white space" vote is that devices won't have to avoid interfering with anything but the very strong signals, so that means people like me who get TV from DC, Baltimore, Philadelphia, Harrisburg, and sometimes Richmond will fall back to getting only the "local" channels.
You could always generate parity data and store that (either on the same or another disk).
parchive is a good method, with both commandline and GUI for a wide variety of systems.
Yes, exactly the same way.
But, I use "Launch folder windows in a separate process" since that leads to more stability, and that might be the difference.
Still, icons in the system tray don't put themselves back when you restart Explorer...they need to be restarted themselves to make it work.
I do know that at least some of the things that run at "logon" will run if you restart Explorer, but I need to spend some time checking which ones they are.
As for the 3 minute startup...unless you have 10-year-old machine, you need to ditch some of the startup tasks. You really don't need most of those things running automatically at login. Either that, or investigate some utilities that allow you to delay the startup of less important things.
For hardware, I use a folder structure of Type/Manufacturer/Model/OS/Version in my setup.
So, I have:
Video Cards/ATI/Radeon/WinXP/Catalyst 7.10
Video Cards/ATI/Radeon/WinXP/Catalyst 8.01
Video Cards/ATI/Radeon/WinXP/Catalyst 8.08
I also don't keep the original ZIP or self-extracting EXEs, but instead something that is ready-to-use. This is good if there isn't an install file, but instead you just use Device Manager to "Update Driver". Also, for slower machines or systems with low disk space, it sometimes allows an install to complete when it wouldn't otherwise.
I don't keep everything, but I use something like the kernel install system for most package managers...keep a few versions, so that you can regress to something that isn't broken if necessary.
OK, so you don't install the device at all, in which case drivers don't matter.
Seriously, if I download newer drivers, then the same thing happens to them...they get stashed away. And, when it turns out that version 2.4 of the driver screws up the hardware, I can always revert to version 2.3 (or 2.0, or 1.8, etc.). It doesn't matter to me where the hardware came from...the driver gets saved away.
And, if I bought hardware that didn't work regardles of the driver, it gets returned. So, I wouldn't have had a "rubbish little device" sitting around to work a few years later once Linux got around to supporting it.
Its an application like any other that can be killed, move, restarted, or even removed.
Except, of course, for the fact that killing the "root" explorer.exe ends up causing you pretty ugly problems.
For example, when you kill off the explorer.exe process controlling your taskbar and system tray, starting Explorer again usually leaves you with a mess, since the running tasks don't go back into the tray. Then, too, everything that was in the various "autorun" places gets run again because Explorer is too dumb to figure out this isn't the first time it is being run.
Basically, because Explorer is the display shell and hooks into so damn much, but it isn't really the root process for your login, the whole setup is so fragile that the only way to make sure everything ends up right is to log out and log back in.
What is with all these Slashdot users who "lost the driver disc"?
The first thing I do with any driver disc (or any other software, for that matter) is copy it to my install respository that sits on a RAID array and is backed up regularly. I pretty much never clean that up, so I have drivers for hardware I don't own anymore.
A quick check shows I have Soundblaster drivers from 14 years ago.
Despite being such a pack rat, and literally keeping everything there (like install source for the last 3 versions of MS Office, every game I've ever purchased, etc.), it only takes up 330GB, which is less than $50 worth of disk space.