Cromix was the best CP/M derivative I ever used. It was based on CDOS, Cromemco's CP/M clone, and ran on a multi-processor Z80... each process ran in a 48K bank-switched TPA on one of the Z80 cards, and the BIOS/BDOS area was bank-switched and (IIRC) shared read-only between the cards, so you could have an awful lot of code (for a Z80) in that 16K chunk. It provided the CP/M API, a UNIX-compatible API, and a huge chunk of libc (including printf!) in the BDOS.
To provide compatibility with CP/M programs, the drive letters were treated like VMS global symbols: you could assign "M:" to/usr/include and "L:" to "/usr/lib" so when you ran Microsoft M80 or L80 you didn't have to deal with the "/ as option versus / as file separator" problem. It was a mich nicer approach to dealing with the conflict between CP/M and UNIX syntax than the mess Microsoft came up with in MS-DOS 2.11.
Its only shortcoming is that a few CP/M programs required a 56K TPA (though fewer over time as the BDOS grew and memory-mapped video started to catch on and chew up part of high memory), so wouldn't run under Cromix.
Because in reality RPMs (even with all their flaws) are light years ahead of what Windows uses with myriad installers and some shitty metadata in the registry... An RPM system with the right frontend would easily be much more intuitive than the mess on Windows.
Like War and Peace is much easier and more intuitive than Finnegan's Wake?
I have a real problem with this, because the problems are not usually inherant in the PC, but in the operating system that runs on the PC.
Before I got to OS X, I had tried Windows, FreeBSD, two variants of Linux, BeOS, Rhapsody DR1, BSD-under-Windows via Interix, Xenix, and System V, and that's just on the Wintel hardware. I've also got a NeXT, a Mac SE/30 running AUX, an original Mac, an AT&T UNIX PC, and I've had 3 Amigas, and Atari ST, an Apple II, and a couple of 8-bit Ataris. Plus the mini and mainframe stuff I've used professionally.
So I've got a pretty damn broad view of "the operating system(s) that run on the PC"... and it doesn't matter if the problems are inherent in the PC or not, because they're still there even in the best alternatives.
But the instant those same enthusiests try to do something (hardware modification wise) with a Mac and resell it, they're branded as criminals.
It's all the fault of you people who were too stupid to buy BeOS back when it was coming out in beta and clearly better than every other operating system on the planet! Now you're stuck complaining about systems that aren't even object oriented and don't have BeFS which could have done everything Spotlight or WinFS can do or would have if people had just used BeOS so it didn't die out back before Search was king!
Applications are already written for that model: they use APIs like BLAS and LINPACK that hardware vendors can reimplement to take maximum advantage of their parallel capabilities, and they use intrinsically parallelizable language primitives (like Fortran's parallel array primitives).
That doesn't make a bit of difference: unless they have actually implemented these libraries on the Cell processor, running the benchmarks YOU want will tell YOU nothing about the performance of the Cell using those libraries, because they'll be running that code on the PPC. It's not just a matter of running that benchmark under Linux as the OP implied.
If the Cell architecture can't provide high performance for those kinds of existing parallel codes, then there is something wrong with Cell and/or its compilers.
Given that the only people working on developing software for the Cell right now aren't doing it in Fortran or using the BLAS or LINPACK libraries, but more likely in C and C++ and using OpenGL and Renderman and NovodeX, then it's quite possible they don't even HAVE a Fortran compiler for it yet... so I suppose that counts as "something wrong with its compilers".:)
There isn't in UNIX shared libraries either. The person you're responding to should have said "the default version", what you get if you don't specify a version when you compile your application. A program can use any library with the same major version number and a higher minor version number than it was compiled against. Major version number changes are supposed to be reserved for API changes that can't be made backwards compatible.
The *identity* of a shared library is the library file itself, so it doesn't matter if you have multiple libraries with the same name in different files, programs will run using the version that matches first in their library path. This way you can have a program that needs a special version of a library and it can use it without creating any conflicts with the rest of the system.
This is a very simple and versatile mechanism, and doesn't require any Grand Acronym Cache to work.
I thought I was going to hear about all the good reasons WinTel really did suck from a security standpoint (even despite Microsoft's recent considerable efforts to resolve this).
1. Internet Explorer and Windows Explorer use the same HTML control, and that HTML control is given final responsibility in deciding what rights an object is given based on its "security zone".
2. Windows Networking services are minimally configurable. Most of them can not be bound to an interface, even when they're only used internally and should be bound to loopback. They also require a server port open even when they're only operating as a client. This means that a firewall is the only way to control access to these ports, rather than merely being an additional layer of security.
3. The windows shell passes an uninterpreted string to an application, rather than parsing a command down to a list of names that don't need to be parsed or broken up by the application, so when an application calls an external program that program is responsible for parsing file names and metacharacters out of the command line. Different programs do this in different ways, so a program launching a helper application has to know THAT helper application's specific syntax.
4. Windows is written in C and C++, and uses a filename separator that is also the escape character in C and C++ character strings, making errors in code to parse and verify file names easier.
5. The lack of a single formal system call interface between an application and code that can potentially be exploited makes error checking harder. There used to be a site that documented the effect of this but Microsoft managed to get it shut down without explanation.
I'm not certain but I think kids might be hazardous in a lot of computing environments.
I got my daughter a Mac because I was tired of reinstalling her Windows box. She'd start having problems within a month of install, and 2 or 3 times a year I'd have to wipe it and start over. She had a few problems with her Mac at first, but a bit of training and they vanished.
But...
Six months later I went to do a software update on it and there wasn't room, and then I couldn't find half the programs I tried to use to figure out what was wrong. I think I may have even had to copy Terminal.app over from my Mac. I found that she had accidentally moved her iTunes music to the system partition (this was an older Mac with an 8G limit on the boot partition), ran out of room, and gone in to any folder on her system disk she could find and deleted stuff to make space. It's a good thing "/usr", "/etc", and so on were hidden from Finder... but she still managed a pretty impressive job on what she could find. After seeing this I'm amazed that her Windows system hadn't been in worse condition.
I moved her music back to the big partition, brought back some of the more critical apps and utilities, and ran Software Update. It was all still working fine when I upgraded her to a newer Mac a year later.
So kids can really abuse computers, but Mac OS X seems able to take kid-abuse a lot better than Windows can.
What *needs* to happen for the continued production of laptops in Apple's camp is a low-power equivalent of the G5;
There's nothing wrong with the G4 that a faster memory bus won't fix. The G4 is clocking up to 2 GHz even with only a 7-stage pipeline, and the only thing holding it back is the 166 MHz memory bus. It really reminds me of the P-III versus P-4 mess, where the P-III was faster clock-for-clock than the P-4 but was held back by its slower FSB (133 vs 400 MHz, as I recall).
Which is why Intel's newer mobile chips are based on the P-III core. Oh, Intel describes them as a mix of the P-4 and the P-III, but if so it's a mix that's almost all P-III. "what intel's engineers did" wasn't "take what's good in the P-III and apply it to the P-4", they took the best part of the P-4, the faster external bus, and applied it to the P-III. And that's EXACTLY what Apple needs. Not a cut-down G5, but a liberated G4.
And that's what Freescale's been working on. The Freescale e600 is basically new G4 with a MUCH faster bus. I don't know if the Freescale e600 will actually end up faster clock-for-clock than the G5, but it's certainly possible... at least for code that generates a lot of pipeline flushes. But it will certainly be faster watt-for-watt.
Apple's already using the standard G4 chips from Freescale, so going to their new single- and dual- core chips seems like a MUCH more logical next step than trying to build a "Power-PC-Lite" G5.
What I care about is how fast the thing runs when I run normal code compiled with a normal compiler and (possibly hand-optimized) numerical libraries.
It'll run them exactly as fast as any other PPC 970 core. As far as I can see from the information that's been released so far, to use the coprocessors at all you'll need to redesign your application around an asymmetric coarse-grained parallel processing model, with explicit memory management to feed data to the shared RAM the SPUs have access to.
I really hope OS X gets this. The Core APIs and Quartz Engine could be modified to take advantage, with end developers not even having to know or care.
I could see these units being used through abstract APIs like OpenGL, or used by WindowServer for compositing and rendering, but much of the advantage of the Cell would be wasted if it wasn't possible for applications to set up and use Streams... but the SPUs don't operate through VM and have no MMU, so if you let applications use these processors directly, how would you prevent an application from programming them to hijack or modify data that another processor is operating on?
OS X has actually REMOVED a lot of complexity in the underlying UNIX.
I have to disagree.
Then you haven't been looking in the right place. The UNIX command line is not really that complex an environment, most of the complexity in a modern UNIX system is in the configuration and maintainence of 30 years worth of legacy software.
For example, in UNIX almost every program has its own configuration file syntax. In OS X the role of these traditional configuration files is much reduced... oh, you CAN go in and screw with/etc/rc, but it's much easier to feed a bundle to SystemStarter. Bundles are everywhere, little self-documenting and self-contained collections of code and libraries and property lists. One common mechanism for what used to be dozens of separate configuration mechanisms, and with a structure that's not only easy to handle from the GUI it's also easy to handle from the command line. AND it's easy enough to use that it's natural to follow Apple's lead, even if your own software isn't built using their libraries.
This is potentially at least as big a change in the management of a UNIX system as the introduction of environment variables in Version 7 was.
This is why I think it's a shame that the open source community isn't looking closer at what Apple's released in the open Darwin code tree, because all the hooks you need to create this kind of environment in ANY UNIX system are right there.
People shouldn't be faced with the need to become experts on fuel injection just to drive a car.
People used to complain about how hard UNIX was because it was so much more complex than DOS.
Well, you know, it's still about as much more complex than DOS as it ever was, but Windows has shot past it... and has at least as many little tricks you need to stay on top of. It just hides them better.
OS X has actually REMOVED a lot of complexity in the underlying UNIX.
all they need to do is craft the e-mail with just the slightest enticing subject and content and the avergage user will double-click the.pif,.exe,.scr,.bat, etc., file
I have yet to have a user come to me *twice* with the story that they downloaded and ran an attachment.
I have had them come to me mutiple times with the story that they'd clicked "OK" to a prompt and let a virus install itself that way.
There really is a difference between "download and run" and "click OK". It's like the difference between taking a package off a shelf at a grocery store and buying something because you rubbed your nose at the wrong time at an auction.
Education is not the solution, and just getting rid of apps with unfixable leaky sandboxes has a MUCH bigger effect.
For security, I'd say that you're right... the biggest problems by far are programs that use the MS HTML control (including, by the way, Netscape 8!), though email is still at least as big a part of it as IE.
And if you're conscientous, and really truly NEVER use Outlook or IE, you're pretty safe. But you have to be conscientious, and there's no way to turn off the use of the HTML control internally, and the HTML control *does* follow links.
And of course all the old Windows issues like DLL HELL and the mystery meat registry and the broken socket library are still there. I don't get viruses, but I still have to reinstall on a fairly regular basis when SOMETHING goes wrong. So if you're going to come clean... why not make a real clean break and remove the temptation of "oh, just going to use IE for this ONE site..."
Yes, the Mac is flawed. No, that doesn't mean it's just as susceptible to exploits. There are whole classes of exploits that only Windows is susceptioble to. Really. No other platform in the world, for example, is subject to "cross zone attacks". None. Security zones (should be insecurity zones) are purely a Windows problem AND they're the biggest problem Windows has.
You forgot step 4, use antivirus software. I guess that's so automatic you don't think about it, except I don't use AV, not even on Windows before I switched, and I don't get infected.
1: avoid fishy sites? That means avoid all web forums, message boards, and anything else that can potentially contain an injection attack. That means don't use web-based mail readers. That means avoid sites that run banner ads, because they can be used for spyware injections as well. And for god's sake don't follow links from search engines.
2: get updates every couple of months? Try... weeks... but wait a while before you install big updates and service packs because sometimes they break stuff, and it can be a while before a fix for the stuff they break.
3: use a firewall of some sort. Don't worry about the viruses that disable security software... so far they seem to be sticking to turning off virus scans, they probably won't get around to firewalls for a while.
I got a better idea. Don't ask for an infection in the first place. It IS possible.
Let's go back to 1997 or so. Somewhere in there Microsoft made a change in Windows that changed it from something that your suggestions were good enough to stay clean on, into something where you could actually get a virus just by reading email.
I mean, there was a JOKE going around about a virus where you could get infected JUST BY READING A MESSAGE. It was a joke because NOBODY believe anyone would ever write a mail program that even had a mechanism to run a virus without downloading and unpacking it.
THEN, Microsoft integrated IE and the desktop and Outlook.
THEN, we got a huge flood of viruses.
For the division I worked for, well, we didn't get infected like the rest of the company. And we didn't even use antivirus for a couple more years. All we did was completely ban IE and Outlook and any other program that used the IE core... the MS HTML control... for untrusted documents.
That's all. That's the biggest thing you can do to stay virus free. Just stop using Microsoft's mail and web software. It works.
Slashdot Mirror
The reason it isn't Windows vs. Mac vs. Unix is because everyone knows Unix is better.
The reason is it isn't Windows vs Mac vs UNIX is because the "Mac vs UNIX" part isn't a meaningful statement: Mac OS X is UNIX.
Funny, I use the command line for remote access to my Macs, and that's usable over a 300 bps modem link.
CP/M met UNIX in Cromix.
/usr/include and "L:" to "/usr/lib" so when you ran Microsoft M80 or L80 you didn't have to deal with the "/ as option versus / as file separator" problem. It was a mich nicer approach to dealing with the conflict between CP/M and UNIX syntax than the mess Microsoft came up with in MS-DOS 2.11.
Cromix was the best CP/M derivative I ever used. It was based on CDOS, Cromemco's CP/M clone, and ran on a multi-processor Z80... each process ran in a 48K bank-switched TPA on one of the Z80 cards, and the BIOS/BDOS area was bank-switched and (IIRC) shared read-only between the cards, so you could have an awful lot of code (for a Z80) in that 16K chunk. It provided the CP/M API, a UNIX-compatible API, and a huge chunk of libc (including printf!) in the BDOS.
To provide compatibility with CP/M programs, the drive letters were treated like VMS global symbols: you could assign "M:" to
Its only shortcoming is that a few CP/M programs required a 56K TPA (though fewer over time as the BDOS grew and memory-mapped video started to catch on and chew up part of high memory), so wouldn't run under Cromix.
Because in reality RPMs (even with all their flaws) are light years ahead of what Windows uses with myriad installers and some shitty metadata in the registry... An RPM system with the right frontend would easily be much more intuitive than the mess on Windows.
Like War and Peace is much easier and more intuitive than Finnegan's Wake?
CP/M was just a bad copy of ISIS with a bunch of random commands from RSX-11 and TOPS-10 plastered amateurishly over it.
I have a real problem with this, because the problems are not usually inherant in the PC, but in the operating system that runs on the PC.
Before I got to OS X, I had tried Windows, FreeBSD, two variants of Linux, BeOS, Rhapsody DR1, BSD-under-Windows via Interix, Xenix, and System V, and that's just on the Wintel hardware. I've also got a NeXT, a Mac SE/30 running AUX, an original Mac, an AT&T UNIX PC, and I've had 3 Amigas, and Atari ST, an Apple II, and a couple of 8-bit Ataris. Plus the mini and mainframe stuff I've used professionally.
So I've got a pretty damn broad view of "the operating system(s) that run on the PC"... and it doesn't matter if the problems are inherent in the PC or not, because they're still there even in the best alternatives.
But the instant those same enthusiests try to do something (hardware modification wise) with a Mac and resell it, they're branded as criminals.
I beg your pardon? When did that happen?
It's all the fault of you people who were too stupid to buy BeOS back when it was coming out in beta and clearly better than every other operating system on the planet! Now you're stuck complaining about systems that aren't even object oriented and don't have BeFS which could have done everything Spotlight or WinFS can do or would have if people had just used BeOS so it didn't die out back before Search was king!
I guess I mistook 'complexity' for 'power'
That's an impression Apple has been fighting for 20 years now.
*wry grin*
Applications are already written for that model: they use APIs like BLAS and LINPACK that hardware vendors can reimplement to take maximum advantage of their parallel capabilities, and they use intrinsically parallelizable language primitives (like Fortran's parallel array primitives).
:)
That doesn't make a bit of difference: unless they have actually implemented these libraries on the Cell processor, running the benchmarks YOU want will tell YOU nothing about the performance of the Cell using those libraries, because they'll be running that code on the PPC. It's not just a matter of running that benchmark under Linux as the OP implied.
If the Cell architecture can't provide high performance for those kinds of existing parallel codes, then there is something wrong with Cell and/or its compilers.
Given that the only people working on developing software for the Cell right now aren't doing it in Fortran or using the BLAS or LINPACK libraries, but more likely in C and C++ and using OpenGL and Renderman and NovodeX, then it's quite possible they don't even HAVE a Fortran compiler for it yet... so I suppose that counts as "something wrong with its compilers".
I really don't think Microsoft could have done much better with the design of the GAC.
They could have if they were willing to take advantage of long file names and copy the UNIX mechanism.
Yes except there is no global 'official' version.
There isn't in UNIX shared libraries either. The person you're responding to should have said "the default version", what you get if you don't specify a version when you compile your application. A program can use any library with the same major version number and a higher minor version number than it was compiled against. Major version number changes are supposed to be reserved for API changes that can't be made backwards compatible.
The *identity* of a shared library is the library file itself, so it doesn't matter if you have multiple libraries with the same name in different files, programs will run using the version that matches first in their library path. This way you can have a program that needs a special version of a library and it can use it without creating any conflicts with the rest of the system.
This is a very simple and versatile mechanism, and doesn't require any Grand Acronym Cache to work.
I thought I was going to hear about all the good reasons WinTel really did suck from a security standpoint (even despite Microsoft's recent considerable efforts to resolve this).
1. Internet Explorer and Windows Explorer use the same HTML control, and that HTML control is given final responsibility in deciding what rights an object is given based on its "security zone".
2. Windows Networking services are minimally configurable. Most of them can not be bound to an interface, even when they're only used internally and should be bound to loopback. They also require a server port open even when they're only operating as a client. This means that a firewall is the only way to control access to these ports, rather than merely being an additional layer of security.
3. The windows shell passes an uninterpreted string to an application, rather than parsing a command down to a list of names that don't need to be parsed or broken up by the application, so when an application calls an external program that program is responsible for parsing file names and metacharacters out of the command line. Different programs do this in different ways, so a program launching a helper application has to know THAT helper application's specific syntax.
4. Windows is written in C and C++, and uses a filename separator that is also the escape character in C and C++ character strings, making errors in code to parse and verify file names easier.
5. The lack of a single formal system call interface between an application and code that can potentially be exploited makes error checking harder. There used to be a site that documented the effect of this but Microsoft managed to get it shut down without explanation.
That do for a start?
I'm not certain but I think kids might be hazardous in a lot of computing environments.
I got my daughter a Mac because I was tired of reinstalling her Windows box. She'd start having problems within a month of install, and 2 or 3 times a year I'd have to wipe it and start over. She had a few problems with her Mac at first, but a bit of training and they vanished.
But...
Six months later I went to do a software update on it and there wasn't room, and then I couldn't find half the programs I tried to use to figure out what was wrong. I think I may have even had to copy Terminal.app over from my Mac. I found that she had accidentally moved her iTunes music to the system partition (this was an older Mac with an 8G limit on the boot partition), ran out of room, and gone in to any folder on her system disk she could find and deleted stuff to make space. It's a good thing "/usr", "/etc", and so on were hidden from Finder... but she still managed a pretty impressive job on what she could find. After seeing this I'm amazed that her Windows system hadn't been in worse condition.
I moved her music back to the big partition, brought back some of the more critical apps and utilities, and ran Software Update. It was all still working fine when I upgraded her to a newer Mac a year later.
So kids can really abuse computers, but Mac OS X seems able to take kid-abuse a lot better than Windows can.
What *needs* to happen for the continued production of laptops in Apple's camp is a low-power equivalent of the G5;
There's nothing wrong with the G4 that a faster memory bus won't fix. The G4 is clocking up to 2 GHz even with only a 7-stage pipeline, and the only thing holding it back is the 166 MHz memory bus. It really reminds me of the P-III versus P-4 mess, where the P-III was faster clock-for-clock than the P-4 but was held back by its slower FSB (133 vs 400 MHz, as I recall).
Which is why Intel's newer mobile chips are based on the P-III core. Oh, Intel describes them as a mix of the P-4 and the P-III, but if so it's a mix that's almost all P-III. "what intel's engineers did" wasn't "take what's good in the P-III and apply it to the P-4", they took the best part of the P-4, the faster external bus, and applied it to the P-III. And that's EXACTLY what Apple needs. Not a cut-down G5, but a liberated G4.
And that's what Freescale's been working on. The Freescale e600 is basically new G4 with a MUCH faster bus. I don't know if the Freescale e600 will actually end up faster clock-for-clock than the G5, but it's certainly possible... at least for code that generates a lot of pipeline flushes. But it will certainly be faster watt-for-watt.
Apple's already using the standard G4 chips from Freescale, so going to their new single- and dual- core chips seems like a MUCH more logical next step than trying to build a "Power-PC-Lite" G5.
Would *that* shut up the "Apple has to switch to Intel to have faster cooler laptop chips!!! or they're D000000Med!!!!! " crowd?
I'd be happy with an e600 dual-core G4 with a 766 MHZ memory bus. What's taking them so long?
What I care about is how fast the thing runs when I run normal code compiled with a normal compiler and (possibly hand-optimized) numerical libraries.
It'll run them exactly as fast as any other PPC 970 core. As far as I can see from the information that's been released so far, to use the coprocessors at all you'll need to redesign your application around an asymmetric coarse-grained parallel processing model, with explicit memory management to feed data to the shared RAM the SPUs have access to.
I really hope OS X gets this. The Core APIs and Quartz Engine could be modified to take advantage, with end developers not even having to know or care.
I could see these units being used through abstract APIs like OpenGL, or used by WindowServer for compositing and rendering, but much of the advantage of the Cell would be wasted if it wasn't possible for applications to set up and use Streams... but the SPUs don't operate through VM and have no MMU, so if you let applications use these processors directly, how would you prevent an application from programming them to hijack or modify data that another processor is operating on?
Then you haven't been looking in the right place. The UNIX command line is not really that complex an environment, most of the complexity in a modern UNIX system is in the configuration and maintainence of 30 years worth of legacy software.
For example, in UNIX almost every program has its own configuration file syntax. In OS X the role of these traditional configuration files is much reduced... oh, you CAN go in and screw with
This is potentially at least as big a change in the management of a UNIX system as the introduction of environment variables in Version 7 was.
This is why I think it's a shame that the open source community isn't looking closer at what Apple's released in the open Darwin code tree, because all the hooks you need to create this kind of environment in ANY UNIX system are right there.
People shouldn't be faced with the need to become experts on fuel injection just to drive a car.
People used to complain about how hard UNIX was because it was so much more complex than DOS.
Well, you know, it's still about as much more complex than DOS as it ever was, but Windows has shot past it... and has at least as many little tricks you need to stay on top of. It just hides them better.
OS X has actually REMOVED a lot of complexity in the underlying UNIX.
all they need to do is craft the e-mail with just the slightest enticing subject and content and the avergage user will double-click the .pif, .exe, .scr, .bat, etc., file
I have yet to have a user come to me *twice* with the story that they downloaded and ran an attachment.
I have had them come to me mutiple times with the story that they'd clicked "OK" to a prompt and let a virus install itself that way.
There really is a difference between "download and run" and "click OK". It's like the difference between taking a package off a shelf at a grocery store and buying something because you rubbed your nose at the wrong time at an auction.
Education is not the solution, and just getting rid of apps with unfixable leaky sandboxes has a MUCH bigger effect.
For security, I'd say that you're right... the biggest problems by far are programs that use the MS HTML control (including, by the way, Netscape 8!), though email is still at least as big a part of it as IE.
And if you're conscientous, and really truly NEVER use Outlook or IE, you're pretty safe. But you have to be conscientious, and there's no way to turn off the use of the HTML control internally, and the HTML control *does* follow links.
And of course all the old Windows issues like DLL HELL and the mystery meat registry and the broken socket library are still there. I don't get viruses, but I still have to reinstall on a fairly regular basis when SOMETHING goes wrong. So if you're going to come clean... why not make a real clean break and remove the temptation of "oh, just going to use IE for this ONE site..."
Yes, the Mac is flawed. No, that doesn't mean it's just as susceptible to exploits. There are whole classes of exploits that only Windows is susceptioble to. Really. No other platform in the world, for example, is subject to "cross zone attacks". None. Security zones (should be insecurity zones) are purely a Windows problem AND they're the biggest problem Windows has.
You forgot step 4, use antivirus software. I guess that's so automatic you don't think about it, except I don't use AV, not even on Windows before I switched, and I don't get infected.
1: avoid fishy sites? That means avoid all web forums, message boards, and anything else that can potentially contain an injection attack. That means don't use web-based mail readers. That means avoid sites that run banner ads, because they can be used for spyware injections as well. And for god's sake don't follow links from search engines.
2: get updates every couple of months? Try... weeks... but wait a while before you install big updates and service packs because sometimes they break stuff, and it can be a while before a fix for the stuff they break.
3: use a firewall of some sort. Don't worry about the viruses that disable security software... so far they seem to be sticking to turning off virus scans, they probably won't get around to firewalls for a while.
I got a better idea. Don't ask for an infection in the first place. It IS possible.
Let's go back to 1997 or so. Somewhere in there Microsoft made a change in Windows that changed it from something that your suggestions were good enough to stay clean on, into something where you could actually get a virus just by reading email.
I mean, there was a JOKE going around about a virus where you could get infected JUST BY READING A MESSAGE. It was a joke because NOBODY believe anyone would ever write a mail program that even had a mechanism to run a virus without downloading and unpacking it.
THEN, Microsoft integrated IE and the desktop and Outlook.
THEN, we got a huge flood of viruses.
For the division I worked for, well, we didn't get infected like the rest of the company. And we didn't even use antivirus for a couple more years. All we did was completely ban IE and Outlook and any other program that used the IE core... the MS HTML control... for untrusted documents.
That's all. That's the biggest thing you can do to stay virus free. Just stop using Microsoft's mail and web software. It works.
"For over a thousand generations, the Jedi were the Guardians of peace and justice in the old republic. Before the dark times, before the empire."
The fact that they were "Guardians of peace and justice" doesn't mean "they were always 100% effortlessly successful".
It's not hard science fiction, and really not science fiction at all.
Well, yes, that too... but it's a deeper problem than that: it's not just "not science fiction", it's "anti-science" fiction.