With Intel Vanderbuilt and AMD Pacifica I thought this was a non-issue? Guest OSs don't know they're running under a hypervisor with Xen on those platforms. And VMWare works the same way (but does it with Ring-0 callouts, like QEMU).
What standards are they arguing about? Disk image formats? APIs for accessing dedicated hardware on the host machine? I'm guessing the latter, since that's all that Oracle would care about.
Mitsubishis are some of the shittiest import cars in terms of reliability (including behavior during accidents). Honda, Toyota, Hyundai, Subaru: all worlds better.
Hit a tree at 10mph in a Honda Odyssey and you will need to replace your bumper (if you mind that dent in it).
'tis better to leverage the protocol across a cluster of machines. Dedicate one or two disks and a GB port per blade and isolate it to a VLAN. Use AoE to expose the disks as a remote aggregation target or for a cluster aware FS. (I recommend partitioning them and using 60-70% for a cluster FS and the latter 30-40% for emulating networked tape drives for backups).
In that, the VSS service notifies applications with open files _on the volume_ to checkpoint themselves before the snapshot. But it doesn't really understand NTFS at all. It can interface with the FS API though to get usage informations and to send notification events. Anyhoo yeah it's still up to the applications to take the hint and flush their buffers and stuff. The filesystem can't do that for them. Otherwise it might as well wipe their collective asses while it's at it, if you know what I mean.
It won't corrupt your files overall. If you are running an I/O intensive process to a specific file during a snapshot that file may end up useless. But the rest of your stuff will be valid.
And didn't anyone tell you that 'Ak*' is an unlucky family name to have?
If Peter Denning, bless his heart, were to study the Linux kernel for a few more months, he'd be able to start teaching and writing about it too. (Specifically, in addition to the OS design classes he already teaches).
Substitute it for any document workflow (ClearCase, RUP, SourceSafe (bleh), Unison). I think it's still good to have an explicit workflow system in addition to having incremental backups AND the previous versions feature.
ALL THREE! Booyah. Oh, and ya gotta mail archives off to some remote site office in case of pirate ninja terra-ists.
First of all, to Microsoft's credit, the user folder contains a registry, which is where per-user settings are stored (and this can be housed on a network share) so I don't think that's an issue. This has been a standard since NT 3.5.
Program authors have a lot to answer for, however. Many of them insist on tattooing settings into HKLM which really don't need to be there. They should consider putting settings in the program folder itself which are superceded by optional settings in HKLM/Group Policy set by an administrator.
The ultimate no-no is when they put direct paths in the registry. Goodbye program relocatability. However, some of the smarter software makers have started using REG_EXPAND_SZ settings in the registry at least, so at most what you need to do is modify an environment variable to point at the software's new installation root, and all the registry settings will work correctly post folder move.
This is encouraged but rarely followed. Oracle does this, believe it or not. And some programs like Matlab and foobar2000.
However, there is no cure in site for CLSID registrations. The whole thing is a mess, IMHO. I think the "answer" to that problem would be for every program to add a facility in a menu somewhere that re-sets all it's file associations in the users' CLSID section. This would be the one case of using RunOnce that I would tolerate. Have it run once at user login, and then only again after a user asks for associations to be reset.
And you can relocate the folders to alternate volumes. It's quite possible. See some of my other posts on how you can do this. The only thing is you will probably need to keep a Program Files and Documents and Settings folder on the boot drive always. There are ways to fix that too but since the default windows installation puts and expects to find things there, you'd have a hard time with that. But you certainly wouldn't need to back it up frequently (or at all).
A better question would be why we need the following files at all anymore: autoexec.bat config.sys msdos.sys io.sys ntdetect.com
Those five files exist to make sure that this NTFS disk, if copied to a FAT partition, isn't attempted to be booted by anything other than Windows NT. But never mind that they are tiny files which are stored inline in the MFT, and marked H/S so you can't even see them normally. They implement a sort of null windows 98 boot telling you that you need to boot from a NT bootloader... which is *fanfare* NTLDR!
ntldr and boot.ini are what make a drive bootable. They need to be in the drive root.
Now Recycler and System Volume Information are ALSO both hidden and system so you don't normally see them. There are one of these per drive (they have nothing to do with a specific windows installation but store your Recycled Files and Restore Points for a drive respectively).
So everything is marked hidden. After install, all you see are: Documents and Settings Program Files Windows
I was just trying to be complete and figured the parent poster probably was annoyed after disabling "hide operating system protected files" and looking in his C:\...
And what does it matter where they are? Because if the sector location on disk mattered, it certainly wouldn't make any difference if you located it inside Windows, because you'd have no way to migrate the windows folder itself anyway.
In fact you can move around those folders (and you can use more than one) if you are smart about things.
Typically I install a small system in C: using the original paths. I install all the SPs I can find, and update all my drivers.
Then I change the UserProfiles folder to point to a RAID-0 volume so that all local/remote users profiles get created on the faster volume on first login. Thus some profiles are located on C: (DefaultUser, Adminsitrator) and everyone else's are in C:\UserData or D: or whatever.
You can also choose to install Programs in _any_ folder you want at install time. C:\Program Files is just a default, and one that Windows uses internally to house things like Internet Explorer. Programs in the registry can store whatever path they want.
So make yourself an E:\programs network folder after boot and put all install all your software there.
I see your point. However I will submit the following counterpoints:
* It works across the entire file system, which creates questions about its efficiency: A disk-wide snapshotting system will be less resource intensive that a system that has to make multiple, discrete metadata updates per write transaction. Since system restore is enabled by default on XP and I haven't heard much complaint about it performance-wise, I think this is a non-issue. (An exception might be systems that have very slow disks and limited RAM, like a palmtop).
* Its 'all or nothing' implementation does create significant liability in places like law offices, as other have already noted;
Enabling this system doesn't make you or your data more or less at risk. The reality is that old copies of files will stick around on disk for about as long as the Restore feature will keep old versioned copies. The difference between enabling and disabling the feature is whether you want to be able to _definitively_ access an old file or attempt a recovery with a tool booted from CD-ROM, which has to operate with less definitive metadata, and may only be able to give you a corrupted or incomplete copy. Keep in mind that if you are concerned about hackers accessing your deleted files and you don't feel the need to use this service for recovery, the hacker will probably be able to resurrect enough of the files anyway for it to be moot. That is, if you get penetrated by a hacker, the issue is moot. You are already in trouble. The real issue is whether you would like a safety net for legitimate recovery. Since the additional resources consumed are neglible, I would posit it would be foolish not to take advantage of it.
Furthermore, when deleting files, if you don't want anyone to get at them ever, then whether you use this system or not is irrelevant. Once you delete a file, you need to use a secure undelete facility to make sure all non-allocated space on your system is overwritten. Even with this undelete feature operational, such a tool will invalidate and overwrite ALL the restore points as well as free space. (That is because the facility gives up restore points when disk space gets tight, and the tool operates by attempting to fill up the entire disk with random data, thus it will demand-release all undeleted files, which will then be overwritten). I would recommend you DISABLE the versioning feature before wiping a machine, to ensure all undeleted files are irrecoverable.
* It encourages laxness in data management; yet
* It doesn't seem to be rich enough to support proper change management processes.
That's not what this tool is for. You still need to have change management processes in place. The tool is for recovering files you didn't know were important! (Otherwise, why would a user delete it? If it were important he or she would have checked it into the Subversion repository, right?:-D ) It's to cover corner cases and disastrous events outside the data management model. It's less invasive than a recovery from backup too.
But it would be foolish to rely on this facility alone. Just as it is foolish to rely on RAID alone for data security on the server side.
I'm sorry. You're allowed 5 punctuation errors and capitalization mistakes per post submitted to this website. You are quite over that limited, and your spelling is atrocious. Please, leave and don't come back. Thanks.
It's not like this feature tries to hide what it's doing. You can go in yourself and free up old snapshots and stuff, or turn it off completely (not that it really gives you any more privacy). You do know that deleted files are really deleted anyway on any modern system, right? I think you've lost your Slashdot user's license, please turn it in at the front desk and don't let the door hit you on the way out.
Windows is a mess. Look at all the files sittings at the top level (c:) after a fresh install.
I've got 13, and that's only because it's a boot drive:
Documents and Settings Program Files Recycler System Volume Information WINDOWS autoexec.bat boot.ini config.sys io.sys msdos.sys ntdetect.com ntldr
Each of them has a good reason to be there. So what's your problem?
Now, while the Program Files and Windows directories are kind of tied together per installation (only limited by the installed program's abilities to re-instate themselves into the registry, which is a sadly lacking feature), the Documents and Settings folder (or rather, it's subfolders) are migratable.
This versioning in NT is based on a generic disk-snapshot system (similar to Linux's LVM, FreeBSD's gvinum stuff, Solaris DiskSuite, NetApp, etc. etc.) The VMS versioning was done in the file system itself. This system (and many related systems) are done at a layer underneath the filesystem, and are often filesystem agnostic.
People like to say that Windows NT borrows a lot from VMS. That's like saying Linux borrows a lot from Multics. There isn't really _anything_ in common, but they are in the same spirit.
... but it's been in Windows in various incantations since fucking WINDOWS ME.
I mean, alert the presses!
I'm surprised at the low level of technological familiarity from Slashdot recently (gauging by the reaction to this article). Low working knowledge about basic things like filesystems and disk management.
How dare you question my decisions, explorer.exe! DOWN BOY, DOWN.
Besides, doesn't everyone rsync their old garbage to a file server or burn a DVD before deleting old files to make space? Oh, you dont? (not necessarily directed to parent) Your loss.
XPs: System Restore Windows 2003: Volume Shadow Copy / Previous Versions
It's a system service that puts a shim between userspace and your physical disks (like LVM on linux). It can take file-system wide snapshots at configurable intervals. Those different names are just different levels of user-space interaction with the same underlying stuff.
VSS can notify programs that a snapshot is about to be taken. If they are VSS aware they will flush their open files to make sure the snapshot is "consistent". Otherwise the snapshot could be made of files that are corrupt (in the middle of being changed by an application). Most applications by 3rd parties are unfortunately not VSS-aware. Office 2003+ and MS SQL Server 2005 are, however, which is nice.
The snapshot is made at the block level, having no real knowledge of "files" per-se. It records changed blocks between snapshots so you can construct a historical version of a whole disk. It's not like rsync or anything.
Windows Volume Shadow Copy operates using a periodic interval (say, 1 day between snapshots). It makes a whole-filesystem snapshot. It doesn't care if files are open, if that was the case across a snapshot then those files are invalid for that snapshot. Typically you schedule a snapshot for after-hours so you have a reasonable guarantee that user files are closed and consistant.
The nice thing about a time-based snapshot system is that it doesn't need to store much between the snapshots if nothing changed (this is similar to other systems like LVM or Veritas).
Vista comes with the Previous Version Explorer extension installed by default, and System Restore now watches the whole disk.
Ok. So what? This feature has been around for awhile, and if you have privacy issues, well just disable system restore (or whatever the equivalent option will be in Vista).
Never mind that as you make new versions of a file, the old ones are still hanging around in your drives' free space for a long time (about the same amount of time the previous-versions feature would keep them). So basically you're making the distinction between being able to access the deleted files explictly, vs. having to use a drive recovery tool.
If you're security concious, you disable the old restore points, fill the drive with a big file full of random data, then delete it. This isn't going to change...
Nearly impossible to set up unless you've deployed your own CA before, but uh, it's infeasbile to crack without obtaining an authenticated device (you do encrypt your private keys, right?)
1) The EM64T extensions take exactly zero extra chip real estate on the first compatible Intel CPUs. They implemented it on Northwood (?) with just a microcode flash (the ALUs and many data paths were already 64-bit).
2) The chip real estate difference between K8 and K7 is negligible. The ALUs get widened, the register file is a bit wider, the TLBs are extended. This is nothing. The big chip estate changes were the on-die memory controller and additional execution and FPU cores.
At most you are wasting cache space on larger pointers. That being said, you can run a cache-concious thread in 32-bit mode if it matters to you.
But uh, actually using the extra registers to avoid trampling your cache in loops, totally not useful at all for encryption or media encoding/decoding. And that pesky wide-open address space in kernel mode makes DMA thunking a thing of the past, and allows for more zero-copy-from-userspace situations, but that's not useful at all either. Being able to statically map any and every file into memory, why would anyone want to do that? Statically arranged dynamic library loading? Totally not useful for reducing application startup time. You just keep your 2GB/2GB memory split. But don't come crying to me because you can't seek effectively through a 2GB+ file.
The only problem with the cores from Intel's perspective is they try to do 4+ cores on a single bus which is utterly retarded (and that's SHARED with I/O... idiocy). I have 8 core systems from AMD. They scale like nobody's business. I have 12-way SPARCs too but they're only useful for running Oracle expensively.
I don't recommend them for desktop usage unless you have mad money.
(unless you're virtualizing an entire private office network at once, then it makes sense for a terminal server)
Yeah, Intel better ditch that bus design before they go with 8 cores. If they don't you have every right to be mad. AT THEM. AMD does it right, at least.
On Unix your extensions are stored in.firefox in your home directory. Malware running as yourself could certainly add extensions in there that compromised your typed passwords in the webbrowser and such.
1) Mod_perl 2) FastCGI 3) FastCGI or a daemon process using Apache2::* to integrate with Apache as a in-any-capacity servlet engine.
You use these to create idioms for how your cgis handle requests.
Then you move on to your Object persistance, Session handling... (may I suggest memcached?) And you have choices there.
I guess that's what makes Perl nice in this sense... you can pick and choose from all different parts and put it together how you feel comfortable. You can use HTML::Inline or Mason or SimpleTemplates or XSLTs or straight friggin prints for the View portion and they are all on equal footing.
OTH if you are going to be cutting and pasting code from the web, then by all means, use Zend or Rails or some vertically integrated system. (Well I shouldn't lump rails in there so much but the ActiveRecord thing rubs me the wrong way)
Slashdot Mirror
__
With Intel Vanderbuilt and AMD Pacifica I thought this was a non-issue? Guest OSs don't know they're running under a hypervisor with Xen on those platforms.
And VMWare works the same way (but does it with Ring-0 callouts, like QEMU).
What standards are they arguing about? Disk image formats? APIs for accessing dedicated hardware on the host machine? I'm guessing the latter, since that's all that Oracle would care about.
Mitsubishis are some of the shittiest import cars in terms of reliability (including behavior during accidents). Honda, Toyota, Hyundai, Subaru: all worlds better.
Hit a tree at 10mph in a Honda Odyssey and you will need to replace your bumper (if you mind that dent in it).
'tis better to leverage the protocol across a cluster of machines.
Dedicate one or two disks and a GB port per blade and isolate it to a VLAN.
Use AoE to expose the disks as a remote aggregation target or for a cluster aware FS.
(I recommend partitioning them and using 60-70% for a cluster FS and the latter 30-40% for emulating networked tape drives for backups).
In that, the VSS service notifies applications with open files _on the volume_ to checkpoint themselves before the snapshot. But it doesn't really understand NTFS at all. It can interface with the FS API though to get usage informations and to send notification events.
Anyhoo yeah it's still up to the applications to take the hint and flush their buffers and stuff. The filesystem can't do that for them. Otherwise it might as well wipe their collective asses while it's at it, if you know what I mean.
It won't corrupt your files overall. If you are running an I/O intensive process to a specific file during a snapshot that file may end up useless. But the rest of your stuff will be valid.
And didn't anyone tell you that 'Ak*' is an unlucky family name to have?
If Peter Denning, bless his heart, were to study the Linux kernel for a few more months, he'd be able to start teaching and writing about it too. (Specifically, in addition to the OS design classes he already teaches).
Substitute it for any document workflow (ClearCase, RUP, SourceSafe (bleh), Unison).
I think it's still good to have an explicit workflow system in addition to having incremental backups AND the previous versions feature.
ALL THREE! Booyah. Oh, and ya gotta mail archives off to some remote site office in case of pirate ninja terra-ists.
You found the hidden spelling mistake!
You can stay.
First of all, to Microsoft's credit, the user folder contains a registry, which is where per-user settings are stored (and this can be housed on a network share) so I don't think that's an issue. This has been a standard since NT 3.5.
/Group Policy set by an administrator.
Program authors have a lot to answer for, however. Many of them insist on tattooing settings into HKLM which really don't need to be there. They should consider putting settings in the program folder itself which are superceded by optional settings in HKLM
The ultimate no-no is when they put direct paths in the registry. Goodbye program relocatability.
However, some of the smarter software makers have started using REG_EXPAND_SZ settings in the registry at least, so at most what you need to do is modify an environment variable to point at the software's new installation root, and all the registry settings will work correctly post folder move.
This is encouraged but rarely followed. Oracle does this, believe it or not. And some programs like Matlab and foobar2000.
However, there is no cure in site for CLSID registrations. The whole thing is a mess, IMHO. I think the "answer" to that problem would be for every program to add a facility in a menu somewhere that re-sets all it's file associations in the users' CLSID section. This would be the one case of using RunOnce that I would tolerate. Have it run once at user login, and then only again after a user asks for associations to be reset.
And you can relocate the folders to alternate volumes. It's quite possible. See some of my other posts on how you can do this.
The only thing is you will probably need to keep a Program Files and Documents and Settings folder on the boot drive always. There are ways to fix that too but since the default windows installation puts and expects to find things there, you'd have a hard time with that.
But you certainly wouldn't need to back it up frequently (or at all).
A better question would be why we need the following files at all anymore:
autoexec.bat
config.sys
msdos.sys
io.sys
ntdetect.com
Those five files exist to make sure that this NTFS disk, if copied to a FAT partition, isn't attempted to be booted by anything other than Windows NT. But never mind that they are tiny files which are stored inline in the MFT, and marked H/S so you can't even see them normally.
They implement a sort of null windows 98 boot telling you that you need to boot from a NT bootloader... which is *fanfare* NTLDR!
ntldr and boot.ini are what make a drive bootable. They need to be in the drive root.
Now Recycler and System Volume Information are ALSO both hidden and system so you don't normally see them. There are one of these per drive (they have nothing to do with a specific windows installation but store your Recycled Files and Restore Points for a drive respectively).
So everything is marked hidden. After install, all you see are:
Documents and Settings
Program Files
Windows
I was just trying to be complete and figured the parent poster probably was annoyed after disabling "hide operating system protected files" and looking in his C:\...
And what does it matter where they are? Because if the sector location on disk mattered, it certainly wouldn't make any difference if you located it inside Windows, because you'd have no way to migrate the windows folder itself anyway.
In fact you can move around those folders (and you can use more than one) if you are smart about things.
Typically I install a small system in C: using the original paths. I install all the SPs I can find, and update all my drivers.
Then I change the UserProfiles folder to point to a RAID-0 volume so that all local/remote users profiles get created on the faster volume on first login. Thus some profiles are located on C: (DefaultUser, Adminsitrator) and everyone else's are in C:\UserData or D: or whatever.
You can also choose to install Programs in _any_ folder you want at install time. C:\Program Files is just a default, and one that Windows uses internally to house things like Internet Explorer. Programs in the registry can store whatever path they want.
So make yourself an E:\programs network folder after boot and put all install all your software there.
I see your point.
:-D ) It's to cover corner cases and disastrous events outside the data management model. It's less invasive than a recovery from backup too.
However I will submit the following counterpoints:
* It works across the entire file system, which creates questions about its efficiency:
A disk-wide snapshotting system will be less resource intensive that a system that has to make multiple, discrete metadata updates per write transaction. Since system restore is enabled by default on XP and I haven't heard much complaint about it performance-wise, I think this is a non-issue. (An exception might be systems that have very slow disks and limited RAM, like a palmtop).
* Its 'all or nothing' implementation does create significant liability in places like law offices, as other have already noted;
Enabling this system doesn't make you or your data more or less at risk. The reality is that old copies of files will stick around on disk for about as long as the Restore feature will keep old versioned copies. The difference between enabling and disabling the feature is whether you want to be able to _definitively_ access an old file or attempt a recovery with a tool booted from CD-ROM, which has to operate with less definitive metadata, and may only be able to give you a corrupted or incomplete copy.
Keep in mind that if you are concerned about hackers accessing your deleted files and you don't feel the need to use this service for recovery, the hacker will probably be able to resurrect enough of the files anyway for it to be moot.
That is, if you get penetrated by a hacker, the issue is moot. You are already in trouble. The real issue is whether you would like a safety net for legitimate recovery. Since the additional resources consumed are neglible, I would posit it would be foolish not to take advantage of it.
Furthermore, when deleting files, if you don't want anyone to get at them ever, then whether you use this system or not is irrelevant. Once you delete a file, you need to use a secure undelete facility to make sure all non-allocated space on your system is overwritten. Even with this undelete feature operational, such a tool will invalidate and overwrite ALL the restore points as well as free space. (That is because the facility gives up restore points when disk space gets tight, and the tool operates by attempting to fill up the entire disk with random data, thus it will demand-release all undeleted files, which will then be overwritten).
I would recommend you DISABLE the versioning feature before wiping a machine, to ensure all undeleted files are irrecoverable.
* It encourages laxness in data management; yet
* It doesn't seem to be rich enough to support proper change management processes.
That's not what this tool is for. You still need to have change management processes in place. The tool is for recovering files you didn't know were important! (Otherwise, why would a user delete it? If it were important he or she would have checked it into the Subversion repository, right?
But it would be foolish to rely on this facility alone. Just as it is foolish to rely on RAID alone for data security on the server side.
I'm sorry. You're allowed 5 punctuation errors and capitalization mistakes per post submitted to this website.
You are quite over that limited, and your spelling is atrocious. Please, leave and don't come back. Thanks.
It's not like this feature tries to hide what it's doing. You can go in yourself and free up old snapshots and stuff, or turn it off completely (not that it really gives you any more privacy).
You do know that deleted files are really deleted anyway on any modern system, right?
I think you've lost your Slashdot user's license, please turn it in at the front desk and don't let the door hit you on the way out.
Windows is a mess. Look at all the files sittings at the top level (c:) after a fresh install.
I've got 13, and that's only because it's a boot drive:
Documents and Settings
Program Files
Recycler
System Volume Information
WINDOWS
autoexec.bat
boot.ini
config.sys
io.sys
msdos.sys
ntdetect.com
ntldr
Each of them has a good reason to be there. So what's your problem?
Now, while the Program Files and Windows directories are kind of tied together per installation (only limited by the installed program's abilities to re-instate themselves into the registry, which is a sadly lacking feature), the Documents and Settings folder (or rather, it's subfolders) are migratable.
So what now?
This versioning in NT is based on a generic disk-snapshot system (similar to Linux's LVM, FreeBSD's gvinum stuff, Solaris DiskSuite, NetApp, etc. etc.)
The VMS versioning was done in the file system itself. This system (and many related systems) are done at a layer underneath the filesystem, and are often filesystem agnostic.
People like to say that Windows NT borrows a lot from VMS. That's like saying Linux borrows a lot from Multics. There isn't really _anything_ in common, but they are in the same spirit.
... but it's been in Windows in various incantations since fucking WINDOWS ME.
I mean, alert the presses!
I'm surprised at the low level of technological familiarity from Slashdot recently (gauging by the reaction to this article).
Low working knowledge about basic things like filesystems and disk management.
Christ...
I instinctively hold SHIFT when I delete files.
How dare you question my decisions, explorer.exe! DOWN BOY, DOWN.
Besides, doesn't everyone rsync their old garbage to a file server or burn a DVD before deleting old files to make space?
Oh, you dont? (not necessarily directed to parent) Your loss.
XPs: System Restore
Windows 2003: Volume Shadow Copy / Previous Versions
It's a system service that puts a shim between userspace and your physical disks (like LVM on linux). It can take file-system wide snapshots at configurable intervals. Those different names are just different levels of user-space interaction with the same underlying stuff.
VSS can notify programs that a snapshot is about to be taken. If they are VSS aware they will flush their open files to make sure the snapshot is "consistent". Otherwise the snapshot could be made of files that are corrupt (in the middle of being changed by an application). Most applications by 3rd parties are unfortunately not VSS-aware. Office 2003+ and MS SQL Server 2005 are, however, which is nice.
The snapshot is made at the block level, having no real knowledge of "files" per-se. It records changed blocks between snapshots so you can construct a historical version of a whole disk. It's not like rsync or anything.
Windows Volume Shadow Copy operates using a periodic interval (say, 1 day between snapshots).
It makes a whole-filesystem snapshot. It doesn't care if files are open, if that was the case across a snapshot then those files are invalid for that snapshot.
Typically you schedule a snapshot for after-hours so you have a reasonable guarantee that user files are closed and consistant.
The nice thing about a time-based snapshot system is that it doesn't need to store much between the snapshots if nothing changed (this is similar to other systems like LVM or Veritas).
Vista comes with the Previous Version Explorer extension installed by default, and System Restore now watches the whole disk.
Ok. So what? This feature has been around for awhile, and if you have privacy issues, well just disable system restore (or whatever the equivalent option will be in Vista).
Never mind that as you make new versions of a file, the old ones are still hanging around in your drives' free space for a long time (about the same amount of time the previous-versions feature would keep them). So basically you're making the distinction between being able to access the deleted files explictly, vs. having to use a drive recovery tool.
If you're security concious, you disable the old restore points, fill the drive with a big file full of random data, then delete it. This isn't going to change...
Nearly impossible to set up unless you've deployed your own CA before, but uh, it's infeasbile to crack without obtaining an authenticated device (you do encrypt your private keys, right?)
And what apps are typical?
Just curious.
(facing a similar-yet-different project soon)
Utter bullshit.
1) The EM64T extensions take exactly zero extra chip real estate on the first compatible Intel CPUs. They implemented it on Northwood (?) with just a microcode flash (the ALUs and many data paths were already 64-bit).
2) The chip real estate difference between K8 and K7 is negligible. The ALUs get widened, the register file is a bit wider, the TLBs are extended. This is nothing. The big chip estate changes were the on-die memory controller and additional execution and FPU cores.
At most you are wasting cache space on larger pointers. That being said, you can run a cache-concious thread in 32-bit mode if it matters to you.
But uh, actually using the extra registers to avoid trampling your cache in loops, totally not useful at all for encryption or media encoding/decoding.
And that pesky wide-open address space in kernel mode makes DMA thunking a thing of the past, and allows for more zero-copy-from-userspace situations, but that's not useful at all either.
Being able to statically map any and every file into memory, why would anyone want to do that?
Statically arranged dynamic library loading? Totally not useful for reducing application startup time.
You just keep your 2GB/2GB memory split. But don't come crying to me because you can't seek effectively through a 2GB+ file.
The only problem with the cores from Intel's perspective is they try to do 4+ cores on a single bus which is utterly retarded (and that's SHARED with I/O... idiocy).
I have 8 core systems from AMD. They scale like nobody's business. I have 12-way SPARCs too but they're only useful for running Oracle expensively.
I don't recommend them for desktop usage unless you have mad money.
(unless you're virtualizing an entire private office network at once, then it makes sense for a terminal server)
Yeah, Intel better ditch that bus design before they go with 8 cores. If they don't you have every right to be mad. AT THEM.
AMD does it right, at least.
On Unix your extensions are stored in .firefox in your home directory.
Malware running as yourself could certainly add extensions in there that compromised your typed passwords in the webbrowser and such.
1) Mod_perl
2) FastCGI
3) FastCGI or a daemon process using Apache2::* to integrate with Apache as a in-any-capacity servlet engine.
You use these to create idioms for how your cgis handle requests.
Then you move on to your Object persistance, Session handling... (may I suggest memcached?)
And you have choices there.
I guess that's what makes Perl nice in this sense... you can pick and choose from all different parts and put it together how you feel comfortable.
You can use HTML::Inline or Mason or SimpleTemplates or XSLTs or straight friggin prints for the View portion and they are all on equal footing.
OTH if you are going to be cutting and pasting code from the web, then by all means, use Zend or Rails or some vertically integrated system. (Well I shouldn't lump rails in there so much but the ActiveRecord thing rubs me the wrong way)