Why would it matter if not all sectors were overwritten the same number of times. If all sectors are overwritten seven or more times you should be pretty safe, even on exotic hardware.
This tread is going round in circles. It isn't fair to require that Linux load GDM (rather than just display a login window onto the frame buffer with out loading X, kind of like a bootsplash), while allowing MacOS X to display anything that look like a login window. Now maybe Mac OS X is at an equivalent stage in the boot process when it reaches the login window as Linux is when it reaches GDM, but it is very hard to define an equivalent stage of the boot process between two entirely different OS's. FYI, I suggested replacing the bootsplash with a tiny program like a login screen: http://brainstorm.ubuntu.com/idea/10735/
All good examples. FYI you may be interested in trying PSPP, a SPSS like statistics package, although the current version (0.6.1) seems very limited. I use the R/CRAN statisical package myself, although retraining is unlikely to be worth it. Running through wine is problematic. VirtualBox or buying the Linux version should work I also find the lack of a decent PDF editor annoying... again there are many PDF ediors for Linux, though none that I really recommend, see e.g. http://www.linux.com/feature/113907. At least the foxit pdf editor apparently runs under wine.
But in principle this need not be the case. Imagine for example that your drive head didn't seek to *exactly* the same position it did last time it read the track. Then there could be for example a narrow strip where the original data remains. (There is also a possibility that data remains in relocated bad sectors, but that is a separate issue).
I had 100% recovery (AFAICT) using Disk Internals, even thought it didn't think there was even a partition there (I think track 0 was zeroed somehow). Was it just easier to restore from backup, or was there something making things harder? (For those that are interested, things like scandisk/fsck are not good for recovering data from badly corrupted disks, since those will only work if your filesystem can be returned to a perfect state. Typically most/all of your important data can be recovered from a corrupted partition even if your filesystem can't)
Harddisks aren't so so small that a bit is single atom. So you at the physical level you aren't going to have exactly 0 or 1. Potentially after zeroing
10101...
would become
(0.1)0(0.1)0(0.1)...
which could in principle be read by a sufficiently accurate instrument.
To me a more valid concern is the following linear time algorithm to break encryption:
1) Invest $1000.
2) Making use of Moore's law, wait until $1000 is enough to buy a machine that can break that now old outdated encryption.
3) Profit!
It seems to me that zeroing or/dev/randing a hdd is so easy that if you are paranoid to encrypt your whole hdd, including swap and filenames, then you might as well erase you hdd just to be on the safe side.
So I take it you never say anything like "Photoshop is great" without telling people where to get it (Three blocks north, then turn left...) and how much you can expect to pay? Linux users tend to be more paranoid and geeky that the average population, but in this case even the Linux user wasn't so anally retentive as to quote URLs in casual conversation, nor so paranoid as to believe it was necessary. Presumably the Windows user had done many "download, click setup, press next (repeat)" cycles successfully, and there was no forewarning that this particular time it would get them scammed.
One minor issue is that this will leave existing data in the previous format, so you might get better performance if you reformat, or at least copy your old data around.
If we define boot time by when the login window sleeps, we could technically boot really quickly if the bootsplash was a login window... (although this isn't necessarily a bad idea, so you can login at your leisure without slowing the boot.)
You may be able to mount ext3 as ext4, but you won't get the cool new features like extents. From Converting an ext3 filesystem to ext4, it is easy to enable these features without a reformat. You may want a plain ext3/boot partition for compatibility with older versions of GRUB, but it looks like the GRUB for Jaunty will support ext4, so a separate/boot partition may not be necessary.
Did you know that some REALLY old school DOS apps bypassed the OS and wrote files straight to the hard drive?
DOSBox supports harddrive images. Presumably these applications would work if we used a hdd image. I do recall that there was software that didn't run on DOSBox though. I think the CA-Clipper compiled software didn't work properly in DOSBox, but did work properly in a Windows DOS window for some reason.
Perhaps, but AFAICT DOSBox is a virtual machine, one that is optimized for compatibility with old DOS games. For example you need full support for really old CGA/EGA graphics features to run Linux/Windows/FreeBSD etc. However these features are needed to run many old dos apps, particularly games, and DOSBox has these.
I don;t mind, but really - if you want to drive volume...
And even then I was only able to get one for a limited special offer period.
This is what I found annoying. Everyone else here is complaining that we have to donate one, but they basically wouldn't let me help "drive volume" even with the "donate one" offer. The OLPC came out long before the EeePC, but I missed the first offer, and I didn't have the opportunity to buy one until I already had an EeePC.
Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved
I understand that btrfs will support a copy-on-write version of cp, which should allow this.
Yes, because we all not only have a beta copy of windows 7/want a copy/but also can produce accurate results from an accurate and identical testbed. Oh, did I mention that we clearly have the same files to work with, same iso's, same everything. Yeah, suuuure.
And having "numbers" would make all of the above so much easier. We could ask why they don't give a video of them performing the benchmarks. At the end of the day, it is you who has provided no evidence for your accusations ZDnet has ever faked a benchmark. And it was you who was caught "lying" about the MS EULA. What evidence do we have that you are not an astroturfer for one of ZDnet's competitors?
This isn't about fun or not. It's about not filling an area devoid of information with things that aren't there via magic speculation.
Oh, but filling a void of information with magic speculation about other people lying *is* fun! Why else would we be wasting time on this completely fact-free thread?
If the "numbers" aren't out there you can still say "hey, that [those rankings] isn't what I got using the exact same setup as you tested with". Of course we won't know whether you really did the benchmarks, so we'll just accuse you of lying because it is so much easier (and more fun) than doing the benchmarks ourselves to test whether you are right.
Interesting. It is always nice to learn something new. Incidentally, VMware also has the ability to share memory between VMs (and of course it doesn't pose a security risk). I imagine that DLLs that use that feature might have a reason for it (maybe the clipboard uses shared memory? I imagine it could be more efficient than message passing.)
And IPC. FYI, There is nothing inherently dangerous about sharing DLLs, that memory is either read-only or Copy-on-write. There is much less likely to be a bug in something as simple as shared memory handling code than a VM.
access to users documents, Direct X, OpenGL, screenshots (GIMP)
access to users documents: VMs don't give access to user documents or systemwide screenshots by default. This would lose much of the security of running a VM.
Direct X, OpenGL: VMware includes experimental support for Direct3D video acceleration. This feature is not fully functional.
Virtual box only supports OpenGL. As far as I know VirtualPC doesn't support either.
And it would STILL be more compatible than what we currently get passed off as "backward compatibility"
Really? Because even Wine offers much better support for gaming than any VM I have come across (which is all I use Vista for). I haven't had any trouble with backwards compatibility with Vista, except with device drivers, and the VMs aren't going to have much use for those. And I have continually hit bugs and limitations with every VM I have come across.
Either you didn't read the entire post, you chose to ignore the part that explains why we would be better off memory wise,...
Maybe because the closest thing is an argument was
Literally at worst your XP application would require 3 gigs of ram. Now consider that you now have an OS that cleanly could access up to 16 exabytes of RAM, the memory limitation would be far worse on the 32 bit native than it would be on the clean 64-bit system running virtual machines as they could load more programs, and each program could have more memory than if it ran native on a 32-bit machine.
None of which explains how running 5 3gig VMs could be more memory efficient than running 32bit code directly on a 64bit kernel allocating only and exactly the memory it needs. And 5*3gig of memory is not all that cheap.
Have you considered that it may be you who fails to understand? In any case, this thread has become more confrontational than interesting, and have little interest in spending more time on it.
Microsoft also used a similar technique for DOS apps. Pre-OS X applications didn't have any memory protection capabilities, and virtualisation may have been pretty much the only way Apple could get OS9 applications to play nicely with OS X. I don't think Apple (or MS) claimed that these VMs gave much in the way of security benefits.
On windows a clipboard isn't just text, so it isn't entirely trivial. But the clipboard is just one thing. Then there is drag-and-drop, and other cross-procedure calls, shared memory, library installation and replacement, access to users documents, Direct X, OpenGL, screenshots (GIMP), keylogging (hot key manager). Failing to support any of these things *could* prevent a legitimate application from interacting with the system the way a user expects. If you implement all of these you really aren't gaining that much security. Particularly if you run all your 64bit code outside the VM. Also, most VMs also have security flaws. Finally there is no reason to believe that the 64bit code is any less likely to have a virus than the 32bit code. If the user wants to run a VM, there are plenty of off the shelf VMs. If a Vista license allowed the user to run any previous windows in a VM of their choice that would be kind of cool, but I doubt the MS would have been able to create the perfect VM when VMware etc. have been been working for ages and still only support a fraction of the features I discussed above.
It would be expected that MOST applications would not be legacy.
But most Windows Applications aren't open source. Even MS doesn't have access to the code. They can't just decide to recompile all the applications as 64bit, they have to wait for every vendor to do it. Remember how long it took to get 64bit flash?
"I load every application I have into memory... 5 times."
As it stands each application can access almost 4G. With VMs, either you have a VM for each app, which is going to be very wasteful, or all of your 32bit apps together can only access 4G.
Virtual Machines aren't a panacea. For starters cutting and pasting between Virtual Machines isn't going to work without some special fiddling. You could add a holes to the VM so that this all works, but you are going to lose more and more of the security benefits from going with a VM. Also, the "Vista is too bloated" crown isn't going to be too impressed by starting up a whole VM whenever we start a legacy application.
Slashdot Mirror
Why would it matter if not all sectors were overwritten the same number of times. If all sectors are overwritten seven or more times you should be pretty safe, even on exotic hardware.
This tread is going round in circles. It isn't fair to require that Linux load GDM (rather than just display a login window onto the frame buffer with out loading X, kind of like a bootsplash), while allowing MacOS X to display anything that look like a login window. Now maybe Mac OS X is at an equivalent stage in the boot process when it reaches the login window as Linux is when it reaches GDM, but it is very hard to define an equivalent stage of the boot process between two entirely different OS's. FYI, I suggested replacing the bootsplash with a tiny program like a login screen: http://brainstorm.ubuntu.com/idea/10735/
All good examples. FYI you may be interested in trying PSPP, a SPSS like statistics package, although the current version (0.6.1) seems very limited. I use the R/CRAN statisical package myself, although retraining is unlikely to be worth it. Running through wine is problematic. VirtualBox or buying the Linux version should work I also find the lack of a decent PDF editor annoying... again there are many PDF ediors for Linux, though none that I really recommend, see e.g. http://www.linux.com/feature/113907. At least the foxit pdf editor apparently runs under wine.
But in principle this need not be the case. Imagine for example that your drive head didn't seek to *exactly* the same position it did last time it read the track. Then there could be for example a narrow strip where the original data remains. (There is also a possibility that data remains in relocated bad sectors, but that is a separate issue).
... making it easier for the government to control your mind ... just so you know.
I had 100% recovery (AFAICT) using Disk Internals, even thought it didn't think there was even a partition there (I think track 0 was zeroed somehow). Was it just easier to restore from backup, or was there something making things harder? (For those that are interested, things like scandisk/fsck are not good for recovering data from badly corrupted disks, since those will only work if your filesystem can be returned to a perfect state. Typically most/all of your important data can be recovered from a corrupted partition even if your filesystem can't)
Harddisks aren't so so small that a bit is single atom. So you at the physical level you aren't going to have exactly 0 or 1. Potentially after zeroing 10101...
would become
(0.1)0(0.1)0(0.1)...
which could in principle be read by a sufficiently accurate instrument.
To me a more valid concern is the following linear time algorithm to break encryption: /dev/randing a hdd is so easy that if you are paranoid to encrypt your whole hdd, including swap and filenames, then you might as well erase you hdd just to be on the safe side.
1) Invest $1000.
2) Making use of Moore's law, wait until $1000 is enough to buy a machine that can break that now old outdated encryption.
3) Profit!
It seems to me that zeroing or
So I take it you never say anything like "Photoshop is great" without telling people where to get it (Three blocks north, then turn left ...) and how much you can expect to pay? Linux users tend to be more paranoid and geeky that the average population, but in this case even the Linux user wasn't so anally retentive as to quote URLs in casual conversation, nor so paranoid as to believe it was necessary. Presumably the Windows user had done many "download, click setup, press next (repeat)" cycles successfully, and there was no forewarning that this particular time it would get them scammed.
But MacOS X doesn't have GDM (or ironically, X) so this thread still hasn't defined a "fair" comparison between Ubuntu and MacOS X boot times.
One minor issue is that this will leave existing data in the previous format, so you might get better performance if you reformat, or at least copy your old data around.
If we define boot time by when the login window sleeps, we could technically boot really quickly if the bootsplash was a login window... (although this isn't necessarily a bad idea, so you can login at your leisure without slowing the boot.)
You may be able to mount ext3 as ext4, but you won't get the cool new features like extents. From Converting an ext3 filesystem to ext4, it is easy to enable these features without a reformat. You may want a plain ext3 /boot partition for compatibility with older versions of GRUB, but it looks like the GRUB for Jaunty will support ext4, so a separate /boot partition may not be necessary.
Did you know that some REALLY old school DOS apps bypassed the OS and wrote files straight to the hard drive?
DOSBox supports harddrive images. Presumably these applications would work if we used a hdd image. I do recall that there was software that didn't run on DOSBox though. I think the CA-Clipper compiled software didn't work properly in DOSBox, but did work properly in a Windows DOS window for some reason.
Perhaps, but AFAICT DOSBox is a virtual machine, one that is optimized for compatibility with old DOS games. For example you need full support for really old CGA/EGA graphics features to run Linux/Windows/FreeBSD etc. However these features are needed to run many old dos apps, particularly games, and DOSBox has these.
I don;t mind, but really - if you want to drive volume... And even then I was only able to get one for a limited special offer period.
This is what I found annoying. Everyone else here is complaining that we have to donate one, but they basically wouldn't let me help "drive volume" even with the "donate one" offer. The OLPC came out long before the EeePC, but I missed the first offer, and I didn't have the opportunity to buy one until I already had an EeePC.
Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved I understand that btrfs will support a copy-on-write version of cp, which should allow this.
Yes, because we all not only have a beta copy of windows 7/want a copy/but also can produce accurate results from an accurate and identical testbed. Oh, did I mention that we clearly have the same files to work with, same iso's, same everything. Yeah, suuuure.
And having "numbers" would make all of the above so much easier. We could ask why they don't give a video of them performing the benchmarks. At the end of the day, it is you who has provided no evidence for your accusations ZDnet has ever faked a benchmark. And it was you who was caught "lying" about the MS EULA. What evidence do we have that you are not an astroturfer for one of ZDnet's competitors?
This isn't about fun or not. It's about not filling an area devoid of information with things that aren't there via magic speculation.
Oh, but filling a void of information with magic speculation about other people lying *is* fun! Why else would we be wasting time on this completely fact-free thread?
So, you are going to take the word of Zdnet over some random 6 digit UID slashdotter? They could just made that up you know! :P
If the "numbers" aren't out there you can still say "hey, that [those rankings] isn't what I got using the exact same setup as you tested with". Of course we won't know whether you really did the benchmarks, so we'll just accuse you of lying because it is so much easier (and more fun) than doing the benchmarks ourselves to test whether you are right.
Interesting. It is always nice to learn something new. Incidentally, VMware also has the ability to share memory between VMs (and of course it doesn't pose a security risk). I imagine that DLLs that use that feature might have a reason for it (maybe the clipboard uses shared memory? I imagine it could be more efficient than message passing.)
I assume you mean things like shared dlls.
And IPC. FYI, There is nothing inherently dangerous about sharing DLLs, that memory is either read-only or Copy-on-write. There is much less likely to be a bug in something as simple as shared memory handling code than a VM.
access to users documents, Direct X, OpenGL, screenshots (GIMP)
access to users documents: VMs don't give access to user documents or systemwide screenshots by default. This would lose much of the security of running a VM. Direct X, OpenGL: VMware includes experimental support for Direct3D video acceleration. This feature is not fully functional. Virtual box only supports OpenGL. As far as I know VirtualPC doesn't support either.
And it would STILL be more compatible than what we currently get passed off as "backward compatibility"
Really? Because even Wine offers much better support for gaming than any VM I have come across (which is all I use Vista for). I haven't had any trouble with backwards compatibility with Vista, except with device drivers, and the VMs aren't going to have much use for those. And I have continually hit bugs and limitations with every VM I have come across.
Which sounds more security to you?
Well, myself I'd pick an effective way of sandboxing applications without the overhead of a VM, and then sandbox everything whether it is 64bit or not.
Either you didn't read the entire post, you chose to ignore the part that explains why we would be better off memory wise,...
Maybe because the closest thing is an argument was
Literally at worst your XP application would require 3 gigs of ram. Now consider that you now have an OS that cleanly could access up to 16 exabytes of RAM, the memory limitation would be far worse on the 32 bit native than it would be on the clean 64-bit system running virtual machines as they could load more programs, and each program could have more memory than if it ran native on a 32-bit machine.
None of which explains how running 5 3gig VMs could be more memory efficient than running 32bit code directly on a 64bit kernel allocating only and exactly the memory it needs. And 5*3gig of memory is not all that cheap. Have you considered that it may be you who fails to understand? In any case, this thread has become more confrontational than interesting, and have little interest in spending more time on it.
Microsoft also used a similar technique for DOS apps. Pre-OS X applications didn't have any memory protection capabilities, and virtualisation may have been pretty much the only way Apple could get OS9 applications to play nicely with OS X. I don't think Apple (or MS) claimed that these VMs gave much in the way of security benefits.
A shared clipboard is trivial.
On windows a clipboard isn't just text, so it isn't entirely trivial. But the clipboard is just one thing. Then there is drag-and-drop, and other cross-procedure calls, shared memory, library installation and replacement, access to users documents, Direct X, OpenGL, screenshots (GIMP), keylogging (hot key manager). Failing to support any of these things *could* prevent a legitimate application from interacting with the system the way a user expects. If you implement all of these you really aren't gaining that much security. Particularly if you run all your 64bit code outside the VM. Also, most VMs also have security flaws. Finally there is no reason to believe that the 64bit code is any less likely to have a virus than the 32bit code. If the user wants to run a VM, there are plenty of off the shelf VMs. If a Vista license allowed the user to run any previous windows in a VM of their choice that would be kind of cool, but I doubt the MS would have been able to create the perfect VM when VMware etc. have been been working for ages and still only support a fraction of the features I discussed above.
It would be expected that MOST applications would not be legacy.
But most Windows Applications aren't open source. Even MS doesn't have access to the code. They can't just decide to recompile all the applications as 64bit, they have to wait for every vendor to do it. Remember how long it took to get 64bit flash?
"I load every application I have into memory... 5 times."
As it stands each application can access almost 4G. With VMs, either you have a VM for each app, which is going to be very wasteful, or all of your 32bit apps together can only access 4G.
Virtual Machines aren't a panacea. For starters cutting and pasting between Virtual Machines isn't going to work without some special fiddling. You could add a holes to the VM so that this all works, but you are going to lose more and more of the security benefits from going with a VM. Also, the "Vista is too bloated" crown isn't going to be too impressed by starting up a whole VM whenever we start a legacy application.