The pawn shops around here also sell PS2 and origional XBOX games for $2-4 each. When I first discovered that they were so cheap, I would go there every week and just buy $20 worth of games (whatever looked interesting). I ended up with a large collection of PS2 games very quickly (more than I think I'll ever play within my lifetime). I was buying over 20 games a month, while I only had an hour or two at most every day to play them. I haven't even had a chance to try a lot of them!
I think the main reason people are buying more games is because there are so many available now for cheap prices.
When I was a kid, Nintendo games were were considered expensive (I think they were like $70 or $80 each). Most of the people I knew with Nintendos only had a few games, and you would play them all completely through (even if they were boring) because you wouldn't be getting another game for a while. Nowadays there are brand new PSP titles sold at Wal-Mart for $10 or $20.
Back in the day me and my friends would all get together, get stoned, and play Quake or Mario Kart or whatever we had available. Now that we're older we all have separate tastes...one person is big into FPS, another is into RPG's, another is into RTS. We also have wives and families and don't have the space for 4+ networked systems in the living room anymore.
I'm not big into online gaming myself, but I can totally understand how games like WoW can bring people together who are in the same kind of situation.
Yes, there is a point after each IE release where Microsoft pushes the newest version through Automatic Updates (I think it's even pushed as a critical update, but I can't remember for sure). There is a toolkit and various registry settings to stop the automatic delivery of IE through Automatic Updates, which is supposed to be applied by IT before that time.
Yeah and mobile phones and car stereo's won't need an HD codec. and yes, in a decade the same ISPs will be offering the same piss poor bandwith we get today, but probably with more customers sharing it.
I'm sure Google doesn't want to use the more resource intensive AES-256 encryption for search page instead of the much faster RC4 algorithm.
s sufficient enough. It's considered insecure because there are a few implementation exploits for it (like WEP) but the algorithm itself is sound. I'm sure it would take long enough to crack the 3.4 * 10E38 possible key combinations.
There's a good chance my ISP is sniffing my packets and my government is digging through them to find whatever the political hangup of the day is, and there's a good chance that what ever they are doing, they are doing incompetently.
Yeah, because we all know that a government intelligence agency would have the shittiest resources available when it comes to packet sniffing. It's all been luck that the FBI's been finding these terrorist plots that were coordinated over e-mail and IM.
whether those searches (innocuous and legal as they are) trigger some stupid keyword alert in some badly written network surveillance system.
Do you really think intelligence agencies use the shittiest tools and waste their time and resources whenever "bomb" passes over the wire? Or perhaps they have a very efficient system which can process all of this information easily and hone in on real targets.
I know the government always puts on the keystone cops appearance (especially with CSIS here in Canada), but lets not underestimate them and congradulate ourselves thinking that an SSL wrapped Google search will be their undoing. It's not like they can't see a log of every other site you open from Google's results, which I'm sure they could use to piece together your search (if they cared at all).
M$ is doing that to try to force the few people who had useful 16 bit software to throw it away so they'd finally spend money on newer stuff.
No, they are doing it because the 16-bit subsystem (NTVDM) uses the processor's virtual 8086 mode which is not available under x64. They would have to emulate the whole thing under x54, which is what Virtual PC does already.
I don't know about such things, but is it theoretically possible for torrents to work without trackers?
Trackers are needed so that the peers can locate each other efficiently. If you're downloading a file, the tracker will tell you who is hosting the various pieces so you can connect to them. Without the tracker your client would have no way to know the IP's which are hosting the file.
It's the same problem that's been present since the early days of P2P. You need to have some hosts which keep an index of the files and the IP addresses of clients which are hosting them. The RIAA can always target these sites.
Torrent trackers are static hosts with large centralized indexes, which means they are fast for clients to query but also can be easily targeted by the RIAA.
FastTrack and Gnutella get around this by offloading the tracker functionality to individual clients with high bandwith (which makes them harder to target). Each query must be forwarded from clients to their trackers, and from their trackers to other tracker nodes, and then the results must be returned the same way. This means it can take a long time for a query to complete as you wait for responses from each node.
There have been some P2P designs which eliminate tracking nodes altogether by having the clients maintain a list of close peers. The clients contact their peers which forward search requests to their list of peers and so on. Every search must be cascaded across many clients and returned from each one, so they are slow. You also must always maintain a good list of peers, or you will end up stranded from the network.
Write did morph into WordPad, and PaintBrush into MSPaint. In fact, if you type "Write" or "Pbrush" into the run box there is an App Paths mapping that redirects them to their newer equivellents.
File Manager was atill used for a long time under Windows NT. At one time it was the only tool that could work with some of the Services for Macintosh. It may even be included with Server 2003, but I haven't had to use it in so long I don't even know. There is also a version of winfile for Vista.
Program Manager was garbage and the only contribution to the "Windows experience" is the program to convert progman groups into start menu folders (grpconv.exe) which still ships with current Windows versions...probably for compatability with apps like you described.
System 7 wasn't bad at all. It had a minimum requirement of 1MB of RAM or something (I remember people were in a uproar over how much more it needed that system 6). I ran it on my MacSE with 2.5MB of RAM just fine.
I think the difference is the way the systems managed memory. On the Mac applications would have the initial and maximum size under the "Get Info" window. IIRC PageMaker's requirements were fairly high (and you would want to give it more memory if possible for better performance). I'm positive that Windows 3.1 had virtual memory, so it could probably swap a lot of PageMaker's memory to disk, which the Mac couldn't do back then.
Under pre-emptive multi tasking the scheduler interrupts the application's execution and suspends it's state registers to memory. It doesn't matter if the application yields or not becuase it's execution will be interupted by the timer and the scheduler will run.
Cooperative tasking requires the application return control to the OS by some means (like the DoIdle function on the MacOS). There are also schemes that allow indirect control to return to the OS, like when the program calls a system function the OS performs any background processing before servicing the request and returning control to the application.
Preemptive multitasking would be the only efficient way to multitask DOS since DOS programs would never be written to with a function to return control to the OS. But it may be that just the DOS executive used preemptive scheduling but still needed to receive initial control from the cooperative Windows applications.
I agree with you on that point, most of OS X was completed while OS 8 was still current. People often forget about OS X Server 1.0 which was released 3 years before the client OS X version everyone knows today. Before that there was also Rhapsody Blue Box which was a complete transitional build of the OS and technology for developers. Carbon provided a fairly compatible API to the classic MacOS toolbox so they could transition code pretty easily. A lot of stuff had to be re-implemented in Cocoa after the release of 10.0, probably because it was using Carbon.
I'm sure Apple would've open sourced the classic MacOS a long time ago if it didn't contain a lot of their proprietary technologies and code which is still in use.
If you force users to click a button, the same button, in the same place, over and over and over again when there is no real need to do so, all you do is condition them to click a button and ignore the useless UI.
Every day I launch Visual Basic 6.0 from my start menu, and every time it gives me the same UAC warning that it will be run with Admin privileges. If I had to stop and determine the correct button every time it would be a total pita. If UAC presents me with a different dialog or presents it under a different set of circumstances it still gets my full attention, but if I open VB6.EXE...I've already read the dialog once and know what is happening. I've also discovered that using Norton UAC's option to disable the dialog after you've seen it once is also not the best solution because you have no cue if some apps are started admin or not.
Users don't want to authorize a program to either have complete control of their computer or not run. Those are shitastic options
When UAC presents you with a box suggesting that a program needs admin privileges, most of the time it's because the program is trying to do something that explicitly needs those privileges. There's no other option at that point: if you run it under limited privileges the program will fail (or not be very useful).
On Linux and OSX apps that want to edit non user files either need to be started as root or they won't run.. period. When MS Windows reaches the same point Microsoft will have finally caught up.
The same is true on any NT based Windows operating system. Set up a limited user account in Windows XP and try to run software that makes changes to the system...it won't work! Unless you use runas to run the software as an administrative user, it cannot change the system files. The only exception is if they are on a FAT partion (which doesn't support ACL's).
Right now I have mission critical accounting software that won't run as anything but administrator and I don't feel like were winning the security war at all.
You seriously can't blame Microsoft because the developers of your accounting software chose to do things that require Administrator priviliges. Developers were told to stop doing that when Windows 2000 was released. Microsoft's only fault there is that they didn't put any hard enforcement of the rule until Vista.
As for the accounting software, there may be ways you can adjust the ACL's on the files and registry entries the software uses so that it can run under a regular user context. A lot of software got caught because they were doing stupid things like writing to the local machine registry hive or to data files inside their Program Files subdirectory. Of course, allowing all members of "Users" to change those objects might be another security issue in itself...
There is a hard division between all 32-bit and 64-bit programs and DLL's. For example, you have 64-bit and 32-bit versions of Internet Explorer. 32-bit Internet Explorer will be emulated so you want to use 64-bit Internet Explorer which should perform better. But 64-bit IE can only run 64-bit plugins. So if you have one plug-in (*cough* Flash) that doesn't have a 64-bit version, then you have to use the 32-bit version of IE. The 32-bit version of IE only runs 32-bit plugins, so you also have to install the 32-bit versions of your 64-bit plug-ins for 32-bit IE. In the end you have to install both versions of every plugin (so you'll have both the 32-bit and 64-bit versions of the Java runtime installed for example). You even have a 32-bit and 64-bit version of Explorer, depending on if you have 64 or 32-bit shell extensions. You end up using the 32-bit version anyway because of one plugin (like Flash) and hoping you can use the 64-bit version and fully enjoy the performance benefits.
Windows XP x64 was a complete test by Microsoft to try and figure out a way of doing a 64-bit client. I don't think they really intended for anyone besides developers to actually use it. They took all of their lessons from XP x64 and used it to make Vista 64-bit work well. The whole OS experience feels like an incomplete and abandoned project. Microsoft also didn't provide support for it for very long, and just wanted people to move onto Vista. You can't get a lot of software for it, and because of it's version (5.2) a lot of software assumes you're not running a client OS. Even 32-bit Windows Live Messenger requires clever trickery to get it installed and running.
Vista / 7 dropped support for Virtual DOS Machine. Relevant if you want to play Tomb Raider, Carmageddon, Blood and other late DOS games (Dosbox is too slow for them at high resolutions).
32-bit editions of Vista and Windows 7 still come with NTVDM and run DOS applications just fine. They didn't include it in 64-bit Windows because it uses the processor's virtual 8086 mode which isn't available on 64-bit processors. They would have had to rewrite the entire subsystem to emulate the x86 real mode hardware under x64, which is what Virtual PC already does.
Most people don't run DOS or 16-bit Windows applications very much anymore. If they needed to most of their apps don't have heavy requirements and would run fine with Virtual PC's emulated hardware.
I never had an experience with that particular config but if you blue screened I'd blame HP's drivers...for their portables they are pretty crummy. I think HP seriously spends 10% of their time getting the low level (critical) features working and the other 90% implementing things like detecting when you're low on ink or disconnected from the internet.
For example the HP media keys driver can bork any other keyboards connected to the system. If it fails for whatever reason, you have to boot into safe mode to type in your password. I've never seen any other media key driver () that can bork the system keyboard driver completely. Most other media key drivers use a service or user mode application...I suspect that HP is using a filter driver which doesn't cascade the information down to the lower drivers properly.
I've also seen them release ATI display drivers which are completely custom built and don't match (or work with) the components of the regular ATI release drivers...and it's not for optimization. The ATI release drivers work better in every way, and the HP ones will often have random hardware acclerated features disabled in their drivers for no apparent reason (maybe the video peformance is too good?).
Their uninstallers often lock up or crash the system entirely outside of safe mode too, which shows how stable their driver packages are, and how well they're tested. The list of bad drivers and software included with the Pavillion is huge. Any service pack upgrade with their stuff installed is a serious game of chance. A clean install of SP3 would probably work. Just make sure you preserve your OEM activation if your model uses it. Also make sure your SATA controller's text mode drivers are included in your Windows XP install disk because you can only install them from a floppy in text mode setup. You can slipstream them with nLite if they aren't included.
For example, there is no technical reason that we could not encrypt almost everything in an e-mail, with nothing but the actual addresses required for delivery and error handling sent in the clear. There is no reason we could not digitally sign e-mails as standard so anyone can verify that a message claiming to come from a certain source really did. The world would be a better place if we put the nice, trusting protocols of yesterdecade to rest and created a secure communications medium for this century.
The reason that we avoid encrypting all e-mail messages is because it adds additional complexity and security which isn't necessary.
If every message was encrypted you wouldn't be able to do any additional message processing on the server (like antivirus scans of attachments). The user would need a copy of their certificate installed on every computer that they use to access their e-mail. They would also need to have access to the public keys for every single person they would want to send e-mail to.
What would be the advantage of the extra layer of security for most people? In the enterprise sure it would be very useful. As far as personal e-mail, most do not contain anything at all that would need to be encrypted, and you rarely need to question a message's source. There is no reason that everything has to be encrypted just because we can do it.
The main idea behind using a floppy for all those years is that it is a very simple interface for the BIOS to initialize and use. Even a BIOS with a bad flash can access the floppy easily enough to load a recovery image. Access to the CD-ROM or USB drives is done through more interfaces and requires more work for the BIOS to use them. You also might need to flash the code that deals with any one of those interfaces.
It's just like the BIOS using a PCI video adapter for emergency recovery. Even though AGP or PCI express are more common, it's easier for the BIOS to get the PCI adapter going in an emergency situation.
I don't buy the "journaling kills flash drive" either since there are tens of millions of flash drives formatted with HFS+ Journaled happily working for years.
The real flash drive killer in NTFS is the last accessed date stamp. The NTFS Change Journal is only updated when you make changes to the files on the disk. The last accessed date stamp is updated every time a file or folder is accessed for any purpose. This means that data is constantly being written to the MFT and the folder entry for a file every time it's handles are closed. The last accessed stamp can also only be It can only turned off globally via the system registry.
Most of the time when you are using your MP3 player or phone it's not changing any of the files, so the change journal is not being written very much either. Bits of data that does change (like song play count or ratings) can be flushed at one time to keep flash writes low. That's why journalled HFS+ is not a big problem. NTFS would write data to the file system every time those files are opened, which is a lot of additional wear.
Slashdot Mirror
The pawn shops around here also sell PS2 and origional XBOX games for $2-4 each. When I first discovered that they were so cheap, I would go there every week and just buy $20 worth of games (whatever looked interesting). I ended up with a large collection of PS2 games very quickly (more than I think I'll ever play within my lifetime). I was buying over 20 games a month, while I only had an hour or two at most every day to play them. I haven't even had a chance to try a lot of them!
I think the main reason people are buying more games is because there are so many available now for cheap prices.
When I was a kid, Nintendo games were were considered expensive (I think they were like $70 or $80 each). Most of the people I knew with Nintendos only had a few games, and you would play them all completely through (even if they were boring) because you wouldn't be getting another game for a while. Nowadays there are brand new PSP titles sold at Wal-Mart for $10 or $20.
Back in the day me and my friends would all get together, get stoned, and play Quake or Mario Kart or whatever we had available. Now that we're older we all have separate tastes...one person is big into FPS, another is into RPG's, another is into RTS. We also have wives and families and don't have the space for 4+ networked systems in the living room anymore.
I'm not big into online gaming myself, but I can totally understand how games like WoW can bring people together who are in the same kind of situation.
Yes, there is a point after each IE release where Microsoft pushes the newest version through Automatic Updates (I think it's even pushed as a critical update, but I can't remember for sure). There is a toolkit and various registry settings to stop the automatic delivery of IE through Automatic Updates, which is supposed to be applied by IT before that time.
Yeah and mobile phones and car stereo's won't need an HD codec. and yes, in a decade the same ISPs will be offering the same piss poor bandwith we get today, but probably with more customers sharing it.
I'm sure Google doesn't want to use the more resource intensive AES-256 encryption for search page instead of the much faster RC4 algorithm. s sufficient enough. It's considered insecure because there are a few implementation exploits for it (like WEP) but the algorithm itself is sound. I'm sure it would take long enough to crack the 3.4 * 10E38 possible key combinations.
Yeah, because we all know that a government intelligence agency would have the shittiest resources available when it comes to packet sniffing. It's all been luck that the FBI's been finding these terrorist plots that were coordinated over e-mail and IM.
Do you really think intelligence agencies use the shittiest tools and waste their time and resources whenever "bomb" passes over the wire? Or perhaps they have a very efficient system which can process all of this information easily and hone in on real targets.
I know the government always puts on the keystone cops appearance (especially with CSIS here in Canada), but lets not underestimate them and congradulate ourselves thinking that an SSL wrapped Google search will be their undoing. It's not like they can't see a log of every other site you open from Google's results, which I'm sure they could use to piece together your search (if they cared at all).
Sweet! I'm tried of all those hackers sniffing my slashdot posts. They can go to my profile page just like everyone else!
No, they are doing it because the 16-bit subsystem (NTVDM) uses the processor's virtual 8086 mode which is not available under x64. They would have to emulate the whole thing under x54, which is what Virtual PC does already.
Trackers are needed so that the peers can locate each other efficiently. If you're downloading a file, the tracker will tell you who is hosting the various pieces so you can connect to them. Without the tracker your client would have no way to know the IP's which are hosting the file.
It's the same problem that's been present since the early days of P2P. You need to have some hosts which keep an index of the files and the IP addresses of clients which are hosting them. The RIAA can always target these sites.
Torrent trackers are static hosts with large centralized indexes, which means they are fast for clients to query but also can be easily targeted by the RIAA.
FastTrack and Gnutella get around this by offloading the tracker functionality to individual clients with high bandwith (which makes them harder to target). Each query must be forwarded from clients to their trackers, and from their trackers to other tracker nodes, and then the results must be returned the same way. This means it can take a long time for a query to complete as you wait for responses from each node.
There have been some P2P designs which eliminate tracking nodes altogether by having the clients maintain a list of close peers. The clients contact their peers which forward search requests to their list of peers and so on. Every search must be cascaded across many clients and returned from each one, so they are slow. You also must always maintain a good list of peers, or you will end up stranded from the network.
Write did morph into WordPad, and PaintBrush into MSPaint. In fact, if you type "Write" or "Pbrush" into the run box there is an App Paths mapping that redirects them to their newer equivellents.
File Manager was atill used for a long time under Windows NT. At one time it was the only tool that could work with some of the Services for Macintosh. It may even be included with Server 2003, but I haven't had to use it in so long I don't even know. There is also a version of winfile for Vista.
Program Manager was garbage and the only contribution to the "Windows experience" is the program to convert progman groups into start menu folders (grpconv.exe) which still ships with current Windows versions...probably for compatability with apps like you described.
System 7 wasn't bad at all. It had a minimum requirement of 1MB of RAM or something (I remember people were in a uproar over how much more it needed that system 6). I ran it on my MacSE with 2.5MB of RAM just fine.
I think the difference is the way the systems managed memory. On the Mac applications would have the initial and maximum size under the "Get Info" window. IIRC PageMaker's requirements were fairly high (and you would want to give it more memory if possible for better performance). I'm positive that Windows 3.1 had virtual memory, so it could probably swap a lot of PageMaker's memory to disk, which the Mac couldn't do back then.
Under pre-emptive multi tasking the scheduler interrupts the application's execution and suspends it's state registers to memory. It doesn't matter if the application yields or not becuase it's execution will be interupted by the timer and the scheduler will run.
Cooperative tasking requires the application return control to the OS by some means (like the DoIdle function on the MacOS). There are also schemes that allow indirect control to return to the OS, like when the program calls a system function the OS performs any background processing before servicing the request and returning control to the application.
Preemptive multitasking would be the only efficient way to multitask DOS since DOS programs would never be written to with a function to return control to the OS. But it may be that just the DOS executive used preemptive scheduling but still needed to receive initial control from the cooperative Windows applications.
I agree with you on that point, most of OS X was completed while OS 8 was still current. People often forget about OS X Server 1.0 which was released 3 years before the client OS X version everyone knows today. Before that there was also Rhapsody Blue Box which was a complete transitional build of the OS and technology for developers. Carbon provided a fairly compatible API to the classic MacOS toolbox so they could transition code pretty easily. A lot of stuff had to be re-implemented in Cocoa after the release of 10.0, probably because it was using Carbon.
I'm sure Apple would've open sourced the classic MacOS a long time ago if it didn't contain a lot of their proprietary technologies and code which is still in use.
Every day I launch Visual Basic 6.0 from my start menu, and every time it gives me the same UAC warning that it will be run with Admin privileges. If I had to stop and determine the correct button every time it would be a total pita. If UAC presents me with a different dialog or presents it under a different set of circumstances it still gets my full attention, but if I open VB6.EXE...I've already read the dialog once and know what is happening. I've also discovered that using Norton UAC's option to disable the dialog after you've seen it once is also not the best solution because you have no cue if some apps are started admin or not.
When UAC presents you with a box suggesting that a program needs admin privileges, most of the time it's because the program is trying to do something that explicitly needs those privileges. There's no other option at that point: if you run it under limited privileges the program will fail (or not be very useful).
Just my 2cents...
The same is true on any NT based Windows operating system. Set up a limited user account in Windows XP and try to run software that makes changes to the system...it won't work! Unless you use runas to run the software as an administrative user, it cannot change the system files. The only exception is if they are on a FAT partion (which doesn't support ACL's).
You seriously can't blame Microsoft because the developers of your accounting software chose to do things that require Administrator priviliges. Developers were told to stop doing that when Windows 2000 was released. Microsoft's only fault there is that they didn't put any hard enforcement of the rule until Vista.
As for the accounting software, there may be ways you can adjust the ACL's on the files and registry entries the software uses so that it can run under a regular user context. A lot of software got caught because they were doing stupid things like writing to the local machine registry hive or to data files inside their Program Files subdirectory. Of course, allowing all members of "Users" to change those objects might be another security issue in itself...
Dude, if they're not going to apply a stupid patch to Quickbooks so it runs on SP3, they sure as hell aren't going to migrate to Linux.
There is a hard division between all 32-bit and 64-bit programs and DLL's. For example, you have 64-bit and 32-bit versions of Internet Explorer. 32-bit Internet Explorer will be emulated so you want to use 64-bit Internet Explorer which should perform better. But 64-bit IE can only run 64-bit plugins. So if you have one plug-in (*cough* Flash) that doesn't have a 64-bit version, then you have to use the 32-bit version of IE. The 32-bit version of IE only runs 32-bit plugins, so you also have to install the 32-bit versions of your 64-bit plug-ins for 32-bit IE. In the end you have to install both versions of every plugin (so you'll have both the 32-bit and 64-bit versions of the Java runtime installed for example). You even have a 32-bit and 64-bit version of Explorer, depending on if you have 64 or 32-bit shell extensions. You end up using the 32-bit version anyway because of one plugin (like Flash) and hoping you can use the 64-bit version and fully enjoy the performance benefits.
Windows XP x64 was a complete test by Microsoft to try and figure out a way of doing a 64-bit client. I don't think they really intended for anyone besides developers to actually use it. They took all of their lessons from XP x64 and used it to make Vista 64-bit work well. The whole OS experience feels like an incomplete and abandoned project. Microsoft also didn't provide support for it for very long, and just wanted people to move onto Vista. You can't get a lot of software for it, and because of it's version (5.2) a lot of software assumes you're not running a client OS. Even 32-bit Windows Live Messenger requires clever trickery to get it installed and running.
32-bit editions of Vista and Windows 7 still come with NTVDM and run DOS applications just fine. They didn't include it in 64-bit Windows because it uses the processor's virtual 8086 mode which isn't available on 64-bit processors. They would have had to rewrite the entire subsystem to emulate the x86 real mode hardware under x64, which is what Virtual PC already does.
Most people don't run DOS or 16-bit Windows applications very much anymore. If they needed to most of their apps don't have heavy requirements and would run fine with Virtual PC's emulated hardware.
lol USB? NT4 didn't even support plug and play by default.
I never had an experience with that particular config but if you blue screened I'd blame HP's drivers...for their portables they are pretty crummy. I think HP seriously spends 10% of their time getting the low level (critical) features working and the other 90% implementing things like detecting when you're low on ink or disconnected from the internet.
For example the HP media keys driver can bork any other keyboards connected to the system. If it fails for whatever reason, you have to boot into safe mode to type in your password. I've never seen any other media key driver () that can bork the system keyboard driver completely. Most other media key drivers use a service or user mode application...I suspect that HP is using a filter driver which doesn't cascade the information down to the lower drivers properly.
I've also seen them release ATI display drivers which are completely custom built and don't match (or work with) the components of the regular ATI release drivers...and it's not for optimization. The ATI release drivers work better in every way, and the HP ones will often have random hardware acclerated features disabled in their drivers for no apparent reason (maybe the video peformance is too good?).
Their uninstallers often lock up or crash the system entirely outside of safe mode too, which shows how stable their driver packages are, and how well they're tested. The list of bad drivers and software included with the Pavillion is huge. Any service pack upgrade with their stuff installed is a serious game of chance. A clean install of SP3 would probably work. Just make sure you preserve your OEM activation if your model uses it. Also make sure your SATA controller's text mode drivers are included in your Windows XP install disk because you can only install them from a floppy in text mode setup. You can slipstream them with nLite if they aren't included.
Let's not forgot about good old Liquid Motion, yet another "flash killer" from that era.
The reason that we avoid encrypting all e-mail messages is because it adds additional complexity and security which isn't necessary.
If every message was encrypted you wouldn't be able to do any additional message processing on the server (like antivirus scans of attachments). The user would need a copy of their certificate installed on every computer that they use to access their e-mail. They would also need to have access to the public keys for every single person they would want to send e-mail to.
What would be the advantage of the extra layer of security for most people? In the enterprise sure it would be very useful. As far as personal e-mail, most do not contain anything at all that would need to be encrypted, and you rarely need to question a message's source. There is no reason that everything has to be encrypted just because we can do it.
I understand some Japanese and I don't get how it has anything to do with them flipping the romanji word upside down.
The main idea behind using a floppy for all those years is that it is a very simple interface for the BIOS to initialize and use. Even a BIOS with a bad flash can access the floppy easily enough to load a recovery image. Access to the CD-ROM or USB drives is done through more interfaces and requires more work for the BIOS to use them. You also might need to flash the code that deals with any one of those interfaces.
It's just like the BIOS using a PCI video adapter for emergency recovery. Even though AGP or PCI express are more common, it's easier for the BIOS to get the PCI adapter going in an emergency situation.
The real flash drive killer in NTFS is the last accessed date stamp. The NTFS Change Journal is only updated when you make changes to the files on the disk. The last accessed date stamp is updated every time a file or folder is accessed for any purpose. This means that data is constantly being written to the MFT and the folder entry for a file every time it's handles are closed. The last accessed stamp can also only be It can only turned off globally via the system registry.
Most of the time when you are using your MP3 player or phone it's not changing any of the files, so the change journal is not being written very much either. Bits of data that does change (like song play count or ratings) can be flushed at one time to keep flash writes low. That's why journalled HFS+ is not a big problem. NTFS would write data to the file system every time those files are opened, which is a lot of additional wear.