Mozilla Thunderbird is a great lightweight email client replacement for Outlook. Your average home user who has an imap or pop account from an ISP really has no good excuse not to uninstall Outlook from their machine and switch. Corporate users on the other hand are a little more screwed, since many of them use Exchange servers that don't have OWA turned on and/or aren't Exchange 2000/2003, which precludes using Evolution's commercial plugin to get calendaring integration and whatnot. However corp users that do meet those server-side requirements can do so. Or if you don't use or need the calendaring part in your organization and the exhcnage server has IMAP, then you can also go Thunderbird there too.
Tables and CSS are orthogonal devices for laying out content anyways, a given project can use either extensively or not-at-all, and the use of one doesn't inhibit the use of the other.
The idea behind researching higher-speed protocols is that if you took plain old TCP and ran it on a line 6000x faster than DSL, you would find that the workings of the protocol itself would become the performance bottleneck in the system. These guys are thinking ahead and writing the protocols we'll need on future faster networks. The blurb _is_ kinda moronic in how it compares a protocol to DSL, but at the same time it is truthful. It would have made more sense if they had made it clearer that the protocol was designed to fully utilize an as-yet-unknown broadband service 6000x faster than DSL that might exist in the future.
I think computer games can definitely improve your mental reaction times, and even up your quick tactical thinking skills. Certainly group games can improve your team skills. However, specific physical tasks emulated in a game rarely transfer to real life. Duck Hunt will not make you a pistol marksman, not by far. (By the way, did you ever wonder wtf you were doing shooting ducks with a pistol anyways? Shotguns are for ducks).
Never fear, firearms are an enjoyable hobby that follows the old slogan from that Mastermind boardgame "A minute to learn, a lifetime to master". You'll have great fun with it anyways despite the inapplicability of your Duck Hunt skills.
Only some poor fools in the windows community, and some hopelessly insane Mono developers, along with a cadre of self-styled software journalists and gurus, believe that.Net stands a chance. The rest of computer science will continue to move on without you, and we always take C wherever we go, it is our foundation.
The format you're looking for is any format you like stored on reliable storage.
Why bother with all the intricacies of a pseudo-fault-tolerant data structure? Ultimately the best archive format for recovery will be one that just duplicates the whole archive twice over, doubling space requirements and improving immunity to lost sectors on drives. At which point one asks, "Why don't I just stick to simple files and archives, and use reliable storage that handles this crap for me, for all my data, automagically?" Storage of any sort just keeps getting cheaper and bigger. If you have any interest in the longevity of your data these days, there's almost no excuse for not using the data-mirroring built into virtually every OS these days and doubling your storage cost and read performance while preventing yourself from worrying about drive failure.
Strangely enough, I had a related experience (I think). the same day over in Houston, TX on this Friday. I parked my car downtown, went to work, and got out a little after 5. My Alarm remote did unlock my doors, but there was a "Security" light on my dash and the ignition was disabled. Took some messing around and unlocking/relocking the alarm system and doors with the fob to get it all reset and allow me to drive my car again. This is a car I've owned for 5 years, and never had any issue with the alarm system in the past.
Yeah the problem is getting metal parts out of a 3d printing solution. The current expensive systems only do plastics, like ABs and polycarbonate. While those plastics are durable enough for many uses, and even for the majority of the parts of a full-auto rifle like the AK47, there's a list of very important parts that must withstand pressures much to great for plastics of this sort. You can't print all your AK parts till you can print metal parts made of high quality alloys.
You can already buy expensive 3-d printers that do this. They form fairly durable plastics in a wide variety of colors. Most people that buy them use them for parts prototyping. You stick a CAD file in one end and a usable plastic part gets "printed" by hardening a liquid polymer with a certain laser wavelength layer by layer (or at least that's my basic layman understanding of most of them).
Check out www.stratasys.com and www.3dsystems.com for examples.
Eventually this stuff will get cheap enough to make it viable for mass home use, and eventually other materials will be easier to work with, presumably even metals and wood by using laser cutting from blocks or something.
I'm sorry, but I'm still on ESR's side on this. I've been a longtime supporter of Sun in the commercial world, and a longtime supporter of Linux in the free world. These days however, the free world ahs taken the battle to the commercial world, and the commercial world is starting to lose. I think it's only a matter of "when" and not "if", that we'll see old proprietary non-open-source systems as legacy crap that nobody wants around, and that will include Solaris and Sun's hardware if they don't change their ways fast. They should have realized this and started changing their ways in the late 90's, at this point they have a long road of catchup work to do, if they ever even bother.
If you want specifics - look at price/performance rations on Sparc64 platforms from Sun vs the x86 stuff Linux runs on from major vendors. HP and IBM both offer a pretty robust support and service platform, and highly capable hardware, at a much lower price/perf ratio. Why spend millions on supposedly unbreakable machines and high-end service agreements from sun, when you can just cluster a few Dells together under Linux with 24 hour parts turnaround and forget about it?
The Java Desktop and related initiatives have yet to really materialize for us, so they're hard to evaluate. So far we've seen a demo of a 3d desktop from them recently based on this platform. It looks like a far-enough-along demo that if they tossed it on sourceforge it would take over the world, but instead they've locked it up in their research labs - not even a binary version to download.
Sun could have perhaps revived their sparc servers by going linux on sparc, cutting OS development staff, and reducing the cost to the end user to some degree. Eventually the commodity x86 hardware would win anyways, but it would extend the life of their investment in the sparc world, and provide them with more linux internals knowledge to help them transition to an x86-centric world. Instead, they've barely helped provide enough documentation for the community-sponsored sparc ports of Linux, and they shun the idea of such a beast in their commercial product line.
I learned assembler first myself, although I'm of a somewhat newer generation (27 atm) than older programmers who were forced to. I think it's a big help for the same reasons stated, and I've noticed too that the best programmers I know are people who, like myself, know assembler. Of course you need other things too:), but it's a good start.
You can even take this a step further and say that before one learns assembler, one should learn basic electronics, both analog and digital. You don't need to go so far as designing microprocessors - but at least far enough to build little logic and timer circuits from standard TTL and CMOS ICs, perhaps advancing from that towards building circuits around a PIC microprocessor and writing asm code for the PIC to control little hardware devices.
Then do x86 assembler, preferably without a real OS in the way (e.g. MASM/TASM under plain old DOS without using MSDOS interrupt functions, or even BIOS ones if you can help it), then graduate to using assembler and C both seperately and linked together under a protected-mode OS where one must use system calls (ala Linux like the book), and then move on to regular C/C++ coding without doing anything in asm unless neccesary for speed (which is very rare), and THEN, PERHAPS, if the situation warrants, or other things (available contracts, stupid corporate policies, etc) require, you could learn ugly languages like Java and code in them.
It's not hard at all to make a motherboard (and hence a whole PC) which is completely standards-compliant and backwards-compatible in every meaningful and useful way, but which has no legacy busses or ports. The ISA bus has been internalized on most modern motherboards for some time. Getting rid of parallel, serial, and PS/2 mouse/keyboard would be an easy next step. Floppy drive busses/controllers, as well as the floppy drive itself, can also take a hike. Replace it with an optional IDE LS-120 drive for those that need it.
In the end, a modern consumer PC should really only have an AGP slot (and a graphics card in it), 1-2 PCI slots, Audio I/O ports (USB audio has drawbacks), and USB ports. Sell USB->{parallell, serial, etc} adapters for people with legacy deviecs to connect. You could do that today and get away with it, but they're just dragging their collective feet about it.
Honestly, the science that goes on today on pure science missions has been viewed by many as not much scientific bang for the buck. And really, observation and science in space would happen no matter what if we had regular commercial and military space missions. Therefore, the cheap way to get the science done without blowing too much money is to piggyback an expanded commercial or military space plan.
I haven't thought it through recently - but the last time I was contemplating such things, I seem to remember coming to these basic conclusions about time travel as we currently conceive of it (or theorize about):
Traveling to the future is very real and easy (relatively speaking) - although you're not really travelling to the future, you're just slowing down your local frame of reference while the rest of the world speeds past you.
Travelling to a past before backwards time travel technology existed can't happen, it just doesn't work.
Travelling backwards to a time when a machine designed for this purpose already existed may be possible. As a mental example you can imagine if you could create and manipulate wormholes, how you could set a pair up right now that someone in 2050 could jump back to you from.
I've heard this said before. My understanding is that something along the lines of a typical 3-5 inch think telephone directory is deal for stopping a high-powered rifle round.
While we're on the subject, the caliber of the bullet has a lot less to do with what a bullet ends up doing than the exact brand and type of ammo involved, the gun it was fired from, the shooter's technique, and the point/angle of impact. e.g. A low-powered "target practice" plain lead.44 mag round coming out a short-barrelled pistol and hitting in the wrong place or at the wrong angle would probably bounce off of damn near anything, much less hurt a human. A very well-placed hollow-point +P (high pressure) 9mm from a long barrelled handgun will wreak serious havoc.
If define "later phase of the project" as a point further down the line on a scale of code complexity, then it's obviously true. Rooting out a bug is much easier when the codebase is smaller and simpler than when it has grown into a huge complex behemoth.
Oh please. No doubt having had a different focus and so many years of time advantage, there are key areas where Solaris still trumps Linux. For instance, multiprocessor scalability (although it seems they sacrificed performance on 1-2 cpu boxes to acheive this result for their 64+ cpu boxes).
However, don't ever claim that Sun's kernel is in general superior to Linux. In a lot of ways Sun's kernel is ancient and crappy compared to Linux. Take a look at Sun's IP stack versus Linux's, for instance. Or how about lvm+softraid? When will Solaris stop relying on Veritas? (and don't answer diskuite, please). Or how about good integrated netfilter-like code?
While we're on it, let's talk hardware. The price/performance ratios on UltraSparcs make Xeons look like a super bargain, not to mention Athlons. It's way past late for them to have closed up the Sparc shop and moved everything over to this cheaper commodity platform that can pump more mips or flops per dollar than Sun can. And how freaking long did it take them to adopt PCI? At one point in the past 64-bit 25Mhz SBus was acceptable.... but how long did they have to delay deploying PCI on their high end systems before finally giving in?? It was nuts, and they've finally owned up and gone pretty much solid PCI-only now. Of course, now most of my Suns have 64/66 PCI busses, while my latest Intels are doing PCI-X...
The paper leans in the drive manufacturer's favor, which it shouldn't. It implies that the silly OS vendors have been misleading people by stating base2 storage sizes and not properly explaining this.
The reality of the situation is, in the computer realm (which is the only realm in which bytes, kbytes, Mbytes, abd Gbytes even matter), numbering has *always* been base2. Before the hard drive existed, the OS accounted storage and memory and anything else in base2 sizes. This was and always has been standard convention. Hard drive manufacturers have always bucked this trend, and enumerated their Mbytes and Gbytes as multiples of 1,000,000 bytes and 1,000,000,000 byets rather than their true value, because it trumps up the apparent size of the disk. It's a perversion of terms on the drive manufacturers' part.
These are the computer definitions of these numbers, and lying hard drive manufacturers are not allowed to change the definitions of the terms. If they want to call a 115GB drive a "123", then they need to state it as "123 Billion bytes", which is more factually correct.
While we're on the subject - the little "b" means bits, the big "B" means bytes, when you look at transfer rates this is important. Vis:
Slot machines are mathematically one of the worst thigns you can do with your money at a casino. And that's assuming they're fair chances as published and no manipulation is going on. For that matter, you gani zero advantage moving between slots or any other hokey little slots theory. Slots do not get hot and cold.
You're right in general, that of the current crop Google is good. However, it was arguable in pre-google-popularity days that altavista.digital.com had better search technology and better works in progress in their labs. But history since then has relegated the altavista name into nothingness. Still, there was innovative and useful search pre-Google. When google was first becoming popular, Digital's altavista was still a more powerful tool than Google was, although they've caught up in the intervening years of popularity.
You are out of touch with current network security practices, but that's a good thing. Most security guys these days are just not thinking straight, IMHO. The first order of business is to clearly delineate your real internal network and your semi-publicly-accessible DMZ where public services are hosted. No traffic crosses the DMZ without going through a proxy service or application level gateway of sorts. Secondly only setup simple (and password protected I might add) proxies for outbound connectivity. If a group wants a publicly-accessible service facing the net, don't poke it through onto the private network - make them put a seperate server in the DMZ, and make sure they don't establish any unneccesary trust between that machine and the inside network. And lastly, the simple model of firewalling ports is always a good thing. It's just that beyond that, for the ports which must be open to certain hosts, an application-aware transparent proxy or firewall can go a long ways into making sure the traffic doesn't show signs of attack. Hooking up snort is a good thing too. Once you get the rules tuned such that false positives are somewhat rare - set it up to trigger scripts that cause a firewall blackhole on IPs believed to be attacking you, and even make it smart enough to blackhole networks when enough IPs from that net send an attack. Beware denial of service when implementing this - you'll need to keep an eye on what gets blackholed, and should probably timeout the blackholes after a week or two anyways.
This tried to go through as an article on k5 a while back too but got voted out. AMTPs commercial/personal/spam field can easily just be a header field inside a message, as has been suggested several times - and TLS security and authentication already exist in ESMTP. So what exactly does AMTP do that can't be done with the existing widely deployed protocol?
Slashdot Mirror
Mozilla Thunderbird is a great lightweight email client replacement for Outlook. Your average home user who has an imap or pop account from an ISP really has no good excuse not to uninstall Outlook from their machine and switch. Corporate users on the other hand are a little more screwed, since many of them use Exchange servers that don't have OWA turned on and/or aren't Exchange 2000/2003, which precludes using Evolution's commercial plugin to get calendaring integration and whatnot. However corp users that do meet those server-side requirements can do so. Or if you don't use or need the calendaring part in your organization and the exhcnage server has IMAP, then you can also go Thunderbird there too.
Tables and CSS are orthogonal devices for laying out content anyways, a given project can use either extensively or not-at-all, and the use of one doesn't inhibit the use of the other.
could code their way out of a paper bag in any language.
The idea behind researching higher-speed protocols is that if you took plain old TCP and ran it on a line 6000x faster than DSL, you would find that the workings of the protocol itself would become the performance bottleneck in the system. These guys are thinking ahead and writing the protocols we'll need on future faster networks. The blurb _is_ kinda moronic in how it compares a protocol to DSL, but at the same time it is truthful. It would have made more sense if they had made it clearer that the protocol was designed to fully utilize an as-yet-unknown broadband service 6000x faster than DSL that might exist in the future.
I think computer games can definitely improve your mental reaction times, and even up your quick tactical thinking skills. Certainly group games can improve your team skills. However, specific physical tasks emulated in a game rarely transfer to real life. Duck Hunt will not make you a pistol marksman, not by far. (By the way, did you ever wonder wtf you were doing shooting ducks with a pistol anyways? Shotguns are for ducks).
Never fear, firearms are an enjoyable hobby that follows the old slogan from that Mastermind boardgame "A minute to learn, a lifetime to master". You'll have great fun with it anyways despite the inapplicability of your Duck Hunt skills.
Only some poor fools in the windows community, and some hopelessly insane Mono developers, along with a cadre of self-styled software journalists and gurus, believe that
The format you're looking for is any format you like stored on reliable storage.
Why bother with all the intricacies of a pseudo-fault-tolerant data structure? Ultimately the best archive format for recovery will be one that just duplicates the whole archive twice over, doubling space requirements and improving immunity to lost sectors on drives. At which point one asks, "Why don't I just stick to simple files and archives, and use reliable storage that handles this crap for me, for all my data, automagically?" Storage of any sort just keeps getting cheaper and bigger. If you have any interest in the longevity of your data these days, there's almost no excuse for not using the data-mirroring built into virtually every OS these days and doubling your storage cost and read performance while preventing yourself from worrying about drive failure.
Strangely enough, I had a related experience (I think). the same day over in Houston, TX on this Friday. I parked my car downtown, went to work, and got out a little after 5. My Alarm remote did unlock my doors, but there was a "Security" light on my dash and the ignition was disabled. Took some messing around and unlocking/relocking the alarm system and doors with the fob to get it all reset and allow me to drive my car again. This is a car I've owned for 5 years, and never had any issue with the alarm system in the past.
Yeah the problem is getting metal parts out of a 3d printing solution. The current expensive systems only do plastics, like ABs and polycarbonate. While those plastics are durable enough for many uses, and even for the majority of the parts of a full-auto rifle like the AK47, there's a list of very important parts that must withstand pressures much to great for plastics of this sort. You can't print all your AK parts till you can print metal parts made of high quality alloys.
You can already buy expensive 3-d printers that do this. They form fairly durable plastics in a wide variety of colors. Most people that buy them use them for parts prototyping. You stick a CAD file in one end and a usable plastic part gets "printed" by hardening a liquid polymer with a certain laser wavelength layer by layer (or at least that's my basic layman understanding of most of them).
Check out www.stratasys.com and www.3dsystems.com for examples.
Eventually this stuff will get cheap enough to make it viable for mass home use, and eventually other materials will be easier to work with, presumably even metals and wood by using laser cutting from blocks or something.
I'm sorry, but I'm still on ESR's side on this. I've been a longtime supporter of Sun in the commercial world, and a longtime supporter of Linux in the free world. These days however, the free world ahs taken the battle to the commercial world, and the commercial world is starting to lose. I think it's only a matter of "when" and not "if", that we'll see old proprietary non-open-source systems as legacy crap that nobody wants around, and that will include Solaris and Sun's hardware if they don't change their ways fast. They should have realized this and started changing their ways in the late 90's, at this point they have a long road of catchup work to do, if they ever even bother.
If you want specifics - look at price/performance rations on Sparc64 platforms from Sun vs the x86 stuff Linux runs on from major vendors. HP and IBM both offer a pretty robust support and service platform, and highly capable hardware, at a much lower price/perf ratio. Why spend millions on supposedly unbreakable machines and high-end service agreements from sun, when you can just cluster a few Dells together under Linux with 24 hour parts turnaround and forget about it?
The Java Desktop and related initiatives have yet to really materialize for us, so they're hard to evaluate. So far we've seen a demo of a 3d desktop from them recently based on this platform. It looks like a far-enough-along demo that if they tossed it on sourceforge it would take over the world, but instead they've locked it up in their research labs - not even a binary version to download.
Sun could have perhaps revived their sparc servers by going linux on sparc, cutting OS development staff, and reducing the cost to the end user to some degree. Eventually the commodity x86 hardware would win anyways, but it would extend the life of their investment in the sparc world, and provide them with more linux internals knowledge to help them transition to an x86-centric world. Instead, they've barely helped provide enough documentation for the community-sponsored sparc ports of Linux, and they shun the idea of such a beast in their commercial product line.
I learned assembler first myself, although I'm of a somewhat newer generation (27 atm) than older programmers who were forced to. I think it's a big help for the same reasons stated, and I've noticed too that the best programmers I know are people who, like myself, know assembler. Of course you need other things too :), but it's a good start.
You can even take this a step further and say that before one learns assembler, one should learn basic electronics, both analog and digital. You don't need to go so far as designing microprocessors - but at least far enough to build little logic and timer circuits from standard TTL and CMOS ICs, perhaps advancing from that towards building circuits around a PIC microprocessor and writing asm code for the PIC to control little hardware devices.
Then do x86 assembler, preferably without a real OS in the way (e.g. MASM/TASM under plain old DOS without using MSDOS interrupt functions, or even BIOS ones if you can help it), then graduate to using assembler and C both seperately and linked together under a protected-mode OS where one must use system calls (ala Linux like the book), and then move on to regular C/C++ coding without doing anything in asm unless neccesary for speed (which is very rare), and THEN, PERHAPS, if the situation warrants, or other things (available contracts, stupid corporate policies, etc) require, you could learn ugly languages like Java and code in them.
It's not hard at all to make a motherboard (and hence a whole PC) which is completely standards-compliant and backwards-compatible in every meaningful and useful way, but which has no legacy busses or ports. The ISA bus has been internalized on most modern motherboards for some time. Getting rid of parallel, serial, and PS/2 mouse/keyboard would be an easy next step. Floppy drive busses/controllers, as well as the floppy drive itself, can also take a hike. Replace it with an optional IDE LS-120 drive for those that need it.
In the end, a modern consumer PC should really only have an AGP slot (and a graphics card in it), 1-2 PCI slots, Audio I/O ports (USB audio has drawbacks), and USB ports. Sell USB->{parallell, serial, etc} adapters for people with legacy deviecs to connect. You could do that today and get away with it, but they're just dragging their collective feet about it.
1. Post certifications and work-related experiences on a front page slashdot article, along with a plea for help.
2. ???
3. Profit!
Honestly, the science that goes on today on pure science missions has been viewed by many as not much scientific bang for the buck. And really, observation and science in space would happen no matter what if we had regular commercial and military space missions. Therefore, the cheap way to get the science done without blowing too much money is to piggyback an expanded commercial or military space plan.
I haven't thought it through recently - but the last time I was contemplating such things, I seem to remember coming to these basic conclusions about time travel as we currently conceive of it (or theorize about):
Traveling to the future is very real and easy (relatively speaking) - although you're not really travelling to the future, you're just slowing down your local frame of reference while the rest of the world speeds past you.
Travelling to a past before backwards time travel technology existed can't happen, it just doesn't work.
Travelling backwards to a time when a machine designed for this purpose already existed may be possible. As a mental example you can imagine if you could create and manipulate wormholes, how you could set a pair up right now that someone in 2050 could jump back to you from.
I've heard this said before. My understanding is that something along the lines of a typical 3-5 inch think telephone directory is deal for stopping a high-powered rifle round.
While we're on the subject, the caliber of the bullet has a lot less to do with what a bullet ends up doing than the exact brand and type of ammo involved, the gun it was fired from, the shooter's technique, and the point/angle of impact. e.g. A low-powered "target practice" plain lead
If define "later phase of the project" as a point further down the line on a scale of code complexity, then it's obviously true. Rooting out a bug is much easier when the codebase is smaller and simpler than when it has grown into a huge complex behemoth.
Oh please. No doubt having had a different focus and so many years of time advantage, there are key areas where Solaris still trumps Linux. For instance, multiprocessor scalability (although it seems they sacrificed performance on 1-2 cpu boxes to acheive this result for their 64+ cpu boxes).
However, don't ever claim that Sun's kernel is in general superior to Linux. In a lot of ways Sun's kernel is ancient and crappy compared to Linux. Take a look at Sun's IP stack versus Linux's, for instance. Or how about lvm+softraid? When will Solaris stop relying on Veritas? (and don't answer diskuite, please). Or how about good integrated netfilter-like code?
While we're on it, let's talk hardware. The price
The paper leans in the drive manufacturer's favor, which it shouldn't. It implies that the silly OS vendors have been misleading people by stating base2 storage sizes and not properly explaining this.
The reality of the situation is, in the computer realm (which is the only realm in which bytes, kbytes, Mbytes, abd Gbytes even matter), numbering has *always* been base2. Before the hard drive existed, the OS accounted storage and memory and anything else in base2 sizes. This was and always has been standard convention. Hard drive manufacturers have always bucked this trend, and enumerated their Mbytes and Gbytes as multiples of 1,000,000 bytes and 1,000,000,000 byets rather than their true value, because it trumps up the apparent size of the disk. It's a perversion of terms on the drive manufacturers' part.
These are the computer definitions of these numbers, and lying hard drive manufacturers are not allowed to change the definitions of the terms. If they want to call a 115GB drive a "123", then they need to state it as "123 Billion bytes", which is more factually correct.
While we're on the subject - the little "b" means bits, the big "B" means bytes, when you look at transfer rates this is important. Vis:
bit = b = basic unit, 1 single binary digit
byte = B = 8 bits
kilobyte = kB = 1024 bytes (= 8192 bits)
megabyte = MB = 1024 kB (= 1048576 Bytes)
gigabyte = GB = 1024 MB (= 1048576 kB)
kilobit = kb = 1024 bits (= 128 Bytes)
megabit = mb = 1024 kb (= 131072 Bytes, = 128 kB)
Therefore a 1.5Mb/s DSL connection (1.5 megabits per second) transfers 192 kB/s (192 kilobytes per second).
Slot machines are mathematically one of the worst thigns you can do with your money at a casino. And that's assuming they're fair chances as published and no manipulation is going on. For that matter, you gani zero advantage moving between slots or any other hokey little slots theory. Slots do not get hot and cold.
You're right in general, that of the current crop Google is good. However, it was arguable in pre-google-popularity days that altavista.digital.com had better search technology and better works in progress in their labs. But history since then has relegated the altavista name into nothingness. Still, there was innovative and useful search pre-Google. When google was first becoming popular, Digital's altavista was still a more powerful tool than Google was, although they've caught up in the intervening years of popularity.
You are out of touch with current network security practices, but that's a good thing. Most security guys these days are just not thinking straight, IMHO. The first order of business is to clearly delineate your real internal network and your semi-publicly-accessible DMZ where public services are hosted. No traffic crosses the DMZ without going through a proxy service or application level gateway of sorts. Secondly only setup simple (and password protected I might add) proxies for outbound connectivity. If a group wants a publicly-accessible service facing the net, don't poke it through onto the private network - make them put a seperate server in the DMZ, and make sure they don't establish any unneccesary trust between that machine and the inside network. And lastly, the simple model of firewalling ports is always a good thing. It's just that beyond that, for the ports which must be open to certain hosts, an application-aware transparent proxy or firewall can go a long ways into making sure the traffic doesn't show signs of attack. Hooking up snort is a good thing too. Once you get the rules tuned such that false positives are somewhat rare - set it up to trigger scripts that cause a firewall blackhole on IPs believed to be attacking you, and even make it smart enough to blackhole networks when enough IPs from that net send an attack. Beware denial of service when implementing this - you'll need to keep an eye on what gets blackholed, and should probably timeout the blackholes after a week or two anyways.
This tried to go through as an article on k5 a while back too but got voted out. AMTPs commercial/personal/spam field can easily just be a header field inside a message, as has been suggested several times - and TLS security and authentication already exist in ESMTP. So what exactly does AMTP do that can't be done with the existing widely deployed protocol?
The LPF has several notable papers by notables regarding software patent issues here: http://lpf.ai.mit.edu/Patents/patents.html