You found good ad hoc methods for mutual authentication. That's good. I'd like to see more formal methods around this concept. We need tools that mortals can understand, and that work in a variety of contexts.
This wasn't a problem in the old days, because we just walked into the shop. When you remove the physical element, scamming gets easier on both sides. The problem is impersonation, and we've been avoiding solving it on the Internet.
"Don't you know my name yet? That's the only answer. Tell me, who are you, alone, yourself and nameless?" — Tom Bombadil in Tolkien's Lord of the Rings
"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton
This is one of the true hard problems in modern end-user computing, and it comes up all the time. What do you do when you get a phone call like, "hi, this is Don with $MORTGAGE_COMPANY. For security validation, please tell me your address."
How do you provide a way for two people (entities) to get introduced to each other in a reliable way, without a trusted third party to make the introduction? And, beyond that, if you have to create an "account" with me to maintain that relationship, how do we make that happen safely (another questions is why those accounts are so uni-directional; why doesn't the bank need to create an account with you as well?)
Most of the solutions to this problem favor us giving our personal information away for free to big companies, in exchange for some benefit which may never come. There's been talk for ages of having some sort of identity layer for the Internet, but that raises its own privacy and anonymity concerns.
When we were kids, many of us received immunizations against a host of nasty diseases. The purpose of these vaccines was to expose our immune systems to "fake badness," so that when we were exposed "real badness," the immune system would be pre-primed to deal with it.
Phishing is a problem precisely because most of the email that your average (l)user gets and most of the sites they visit are legitimate, with no badness (of this type) involved. When you've never been exposed to phishing behavior, it's much easier to fall for a scam.
You can run all the "awareness" campaigns you want, but users tend to ignore that sort of stuff, thinking, "right, I get it, but I'm smarter than that."
We need to inoculate users to teach them to be wary. There should be more sites like this out there. Some geared toward credit card data, some geared toward username & password, and others yet for other forms of PII.
Once a user is brought up short a few times by information pages like you see after you hit submit, they will be more cautious on all sites.
It must be a slow news day for something so technical to show up as a news article.
But then again, the article has all of the necessary alarmist features, so I guess they had to let it through.
Well, there are a few nostalgic reasons for wanting to build a mini... For instance it would give me something to do with the few reels of 9-track I still have lying around.
In another sense though, this is a mini. The "original" mini's were mini's because they were smaller than the prevelant computers of the day, right? So, the little cube is smaller than our prolific PC-size. Someday we may call the fingernail computer a "mini" because it's smaller than the more common wristwatch computer. Then we'll all have some fun when someone points out that he still manages a VAX cluster.
So it really is a "something you know" (the pin) and "something the fob knows" (the secret).
Yup. This is how all hard tokens really work. The strength of a token is related to how hard it is to get that secret back out again. This is true whether you're talking about shared-secret tokens, or PKI tokens where the secret is a secret key.
The idea of "something you have" used to be more directly connected to the real world, such as a driver's license, a passport, etc. In the digital world, folks are trying to do the same thing remotely, and that begs the question of how you can verify the physical presence of a second factor if you can't see it? To date, it's all come down to math, and the keeping of secrets.
To review, there are three factors that can be used to authenticate (positivly identify) someone:
something you know (a password)
something you have (a token)
something you are (thumb print, retina scan)
Now, just because you're using a token does not mean that you are using a second factor to authenticate. For example, I could put my password on a floppy disk, lable the disk 'TOKEN' and then explain that I have to have that floppy to log in.
OK, so that's exaggerating, but sometimes things very close to that happen. A question to ask yourself is, "what specifically do I need to authenticate myself?" Let's answer that for a couple:
S/Key: you need the skey challenge information sent by the host, and your "passphrase," all of which get fed into the skey algorithm to produce the hash response.
You still need to remember that passphrase, and there's no simple way to detect that someone else has it too. So, you're effectively back to password authentication.
Now, S/Key is better than plain password because you should never use the same twice, so It's not possible to sniff the wire and find something that can be used again to authenticate.
BOTTOM LINE If you want 2-factor auth, skey is not for you. Otherwise, it's better than passwords. Just watch out for man-in-the-middle and other known weaknesses.
SecureID: You've got to have that fob. What the fob needs is the time, which it keeps itself, the seed, and the algorithm. If you had all of those, you could roll your own. Oh, and you need that PIN too. So, this really is two factor authentication: Something you know and something you have.
The problem with token-based authentication has always been that you have to put something on the token, and then prove that it's there without giving it up again. If I just store my password on the token, and then send it across the wire when asked, I've done nothing except hide from the user the fact that we're still using a password.
There are a couple of other ways to do this, thankfully. First is challenge-response. I say: "I'm john doe." You say: "Well, if you're really john, you'll know the proper response to this challenge: "Foo!" I now do some math on 'Foo!' and respond with: "Bar!" At which point you say: "Hi, John. Nice to see you again!" This works great so long as no one sees us, because a bad guy could now associate 'John Doe' 'Foo!' and 'Bar!' If he could now trick you into issuing the 'Foo!' challenge to his impersonated John Doe, he would have the correct response.
Second is what SecureID does: make up a (strong) secret algorithm that "no one else knows." The great thing about time-based algorithms is that they're time-based: the time becomes the challenge, and since the time is always different, it's impossible to issue the same challenge twice. The bad thing about time-based algorithms is that they're time based: if the clocks fall out of sync, the show's over.
So what's the answer? "That depends....";)
How about a combination of the two, a time-based challenge issued from the server that is "windowed" at the client. Not as strong, but the time sync isn't as critical either. This makes it possible to design the token without a super-accurate internal clock. (I have no idea how much accurate clocks cost.) Challenge-response is strong, so long as it's done right, so this may be suficient.
Hardware cost is the big factor here. This is what makes the ibutton and other customizable hardware a good choice. Of course ibuttons need the little blue dot readers, unless you spring for the USB fob to hold them, in which case your workstation needs USB support. There are other USB tokens, too, so this may be a possibility. The trick is finding one that works well with an open source USB stack.
It seems like you have LESS of a right to complain if you voted, because you implicitly acknowledged the fairness of the result.
I'd say that we acknolowledge our hope in the fairness of the result.
I don't think that voting means you have to accept a deceitful outcome. Of course, proving that is another matter. But a deceitful result is very different from what happened in the last presidential election.
If we participate in an election in good faith, we "have a right" to expect fair followthrough. What we've bought into is the election process, not the outcome.
Drone about STO all you want, but obscurity as a layer on top of real security simply does slow crackers down. [Emphasis mine.]
Absolutely. But this isn't Security Through Obscurity.
The complaints about STO from the security community came from the days when fewer people understood security. Some people who thought they did (but didn't) reasoned that hiding information was the same as removing it.
This led to all sorts of strange things, including "proprietary" protocols and algorithms. Many of these secret encryption algorithms were easily broken because the algorithm was flawed. One of the first things you learn about crypto is that keeping an algorithm secret does not increase its strength. Similar things have happened to many proprietary protocols.
The concern about obscurity in any form has been that it's often used as a crutch, and that's led to a community backlash.
Yeah, but by that argument, we should never do anything because it will be cheaper/easier/etc. to do it later.
Hmm. I wonder if chronic procrastinators like myself could use this to our advantage.
Seriously, isn't this is a similar argument to one used against deep-space missions? (Since faster transportation will be only 50 years away, anyone who leaves for distant stars today will be overtaken in about 50+x years.)
I think I was lucky in my formative years: I was blessed with many "good" teachers. In fact, I think I can say I only had one or two bad ones. I can even go so far as to label a rare few "exceptional." Yes, I'm going to use names here.
Let's get started early: fourth grade. California's "Gifted & Talented" education program was just getting started. I was lucky enough to get a teacher who not only cared, but actually understood. Mrs. Yin (Cutler-Orosi USD) did a great job of letting us explore all sorts of different areas: extra music instruction, art, science, and literature (no computers yet). Oh, and we learned stuff too!:) Thanks to her for a super boost (as if I wasn't already off and running).
The big influence in Jr. High comes from Pamela Frost Martinez. English? Bah! (actually I did learn some English, too) The real work came from my involvement with the yearbook staff. Photography is Chemistry, and don't let anyone tell you otherwise! Making pottery after school was great fun, and I got to operate the kiln!
High School. Thanks first to JoAnn Powell for physically pulling me out of class into the counselor's office and making me apply to Arkansas Governor's School. Thanks also to Barbara Wade, Chemistry. She somehow figured out that when I started doodling, it meant that I understood--not that I was bored.
In college, one big thank-you goes to Dr. Susan Mengel. I'd had a lot of instruction in computer science up until that point, but she was one of the most effective teachers I've ever met.
Many new copiers sport a rather clean looking touch screen interface. There are several things I like about the design of their interfaces:
The orientation of the panel is comfortable: horizontal, about waist height
The screen is high contrast, easy to read in most light. Some units include a separate contrast control (so you can still see it if you can't read the screen!)
There is a limited amount of information on the screen at any one time, and all of the pieces of information generally relates to each other
Navigation controls are obvious and easy to use.
Since copiers are "transactional" devices (you set it up, and submit your job), the interface makes it really easy to cancel and completely start over. Different critera will apply for different types of tasks, but the the example make sense here.
Similarly, when I look at my Visor PDA, the apps I'm most likely to use when I'm on the run are those with easy to use controls--the kind I can mash with my thumb while I running through an airport!:) The other kind, like the default address book, are handy in their own way, but again, it depends on what the task is.
As a side note, I always thought it would be neat to have a touch-screen "keyboard" that you could reconfigure to support different key sequences (qwerty vs dvorak, or foreign keyboards). It could also be reprogrammed to support games, and even have manipulative controls on the keyboard.
Problem with this thing is the same problem as with most touch screens: humans rely heavily on tactile input to guide the performance of manipulative tasks. It's how we know how hard to grip a full cup of coffee, or how gently to grasp an egg, how we judge how hard to strike the egg to crack it, and how we know when our cracking efforts have been successful.
Suggestion to anyone out there who plays with mechanical engineering type things: make a touch screen-like interface with tactile feedback. You'll make a mint (and get a patent, too;)
some allow you to receive mail from multiple accounts, but none support sending through these accounts.
It sounds like your goal is really to be able to send mail "from" any of your various accounts. That is, your recipients should see the mail as "coming from" user1@domain1.com or user2@domain2.com. Am I right?
Really, which SMTP server you use doesn't matter much here, unless you're dealing with savvy people who dig into the SMTP headers. There are several e-mail clients (I use pine) that support multiple profiles. I've got a profile (pine calls it a "role" setup for each of my e-mail addresses. When I compose a new message, I get to choose what role I will use. Pine is fairly intelligent: It recognizes when someone sends mail to a particular address and replys by default come from that address/role (I can always change it, of course)
So what SMTP server do I use? After all, most smtp servers are picky about who they will allow to use their services. Easy: I have to run an MTA for fetchmail to hand my POP'ed email to, so I use the same MTA (sendmail in my case) for sending. Yes, sendmail for one person could be considered overkill and there are simpler, lighter-weight MTA's out there. Find one you like.
In short, worry less about which SMTP server you're using and look for something that lets you define multiple sending addresses.Good luck!
Could someone explain to me how having a longer pipeline speeds things up?
Ask and you shall receive.(Not that I claim to be a genius about these things;)
CPU pipelining in general is a divide-and-conquer scheme. Say you have some set of tasks, each of which you know you can do in ten minutes (take out trash, vaccuum living room, rebuild the linux kernel, etc.) What if you could break each of these down into smaller steps (like finding the trash, collecting it, taking the bag to the curb). Say each of these smaller steps takes no more than three minutes.
Now, you've got a lot of the large-scale tasks to do, so you invite a bunch of your friends over. Each person takes a specific task and does it in assembly line fashion.
Here's the scenario:
We start by finding the trash (3 minutes)
someone collects it (6 minutes total)
someone else bags it (9 minutes total)
finally someone runs to the curb (12 minutes total).
Oops! we're at 12 minutes, that's 2 minutes more than it takes me to do it by myself. But wait, how long does it take to get the next bag to the curb? If the searcher started looking for more trash as soon as he gives the first trash to the collector, he now has more trash ready to be colleted. Follow this through, and you get something that looks like this (apologies for the strangely aligned ascii-art):
-----------------------------------------
|_search__|_collect_|___bag___|___dump__|
-----------------------------------------
|_block1__|__NOP____|___NOP___|___NOP___|
|_block2__|__block1_|___NOP___|___NOP___|
|_block3__|__block2_|__block1_|___NOP___|
|_block4__|__block3_|__block2_|__block1_|
|_block5__|__block4_|__block3_|__block2_|
(and so on)
As you can see, by the time the dumper gets around to dumping block1, we have block2 (the next bag of trash) ready for him to dump. If everything proceeds in "lock-step" (that is, no one gets ahead of the others), then after that first bag of trash, we can dump a bag every 3 minutes. This is much faster than on bag every 10 minutes, and this is the most common type of speedup associated with piplining.
The first part (where various people are standing idle is called "filling the pipe." Certain pieces stand empty because we're working on the first instruction, and we just haven't gotten to them yet. In a CPU for example, the ALU will usually stand idle until the instruction decode logic has examined the bit arrangement of the instruction word and determined whether we should be ADDing, MOVing, BRAnching, or whatever.
Oh, and that brings up branches. Say you've got to stop bagging trash and start washing dishes or something. Everyone has to stop what they're doing (once they're finished with the tasks still waiting on them), and start work on something else. Sometimes we know this is coming and have prepared for it (known as "branch prediction"), but sometimes we guess wrong (say we thought we'd be doing laundry next). Now we not only are switching jobs, but we're switching to something unexpected. This can essentially cause us to skip a beat. This means that for a moment or two, someone (or two, or everyone) will have nothing to do. Then the pipe fills again and we're back up to speed.
CPU designers spend lots of time trying to find new ways to keep the pipe full, because, as you can see, the more a pipe stays full, the faster a system is overall. This is why branch prediction is so important. In addition to branch prediction, there's a whole slew of techniques, like "out of order execution," that allow us to make up time in other ways.
This is a four-stage pipeline. Imagine what's going on with Intel's 20-stage monster! If we can continually decrease the amount of time taken by the longest stage in the pipline, then we can generate more instructions per second: we still have 1 instruction per clock (IPC), but if we can speed up the clock, we get more throughput (IPS). How can we speed up the clock? We do less in each clock cycle and spread the instruction out over more pipeline stages.
This is a really simple overview. There's lots more where this came from, and it's all really neat stuff for those interested in hardware. For those interested, I'd recommend a book or course in hardware organization. You'll need a working knowledge of logic gates, some combinatorics, and some circuit design skills, but it's worth it!
Slashdot Mirror
You found good ad hoc methods for mutual authentication. That's good. I'd like to see more formal methods around this concept. We need tools that mortals can understand, and that work in a variety of contexts. This wasn't a problem in the old days, because we just walked into the shop. When you remove the physical element, scamming gets easier on both sides. The problem is impersonation, and we've been avoiding solving it on the Internet.
"Don't you know my name yet? That's the only answer. Tell me, who are you, alone, yourself and nameless?" — Tom Bombadil in Tolkien's Lord of the Rings
"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton
This is one of the true hard problems in modern end-user computing, and it comes up all the time. What do you do when you get a phone call like, "hi, this is Don with $MORTGAGE_COMPANY. For security validation, please tell me your address."
How do you provide a way for two people (entities) to get introduced to each other in a reliable way, without a trusted third party to make the introduction? And, beyond that, if you have to create an "account" with me to maintain that relationship, how do we make that happen safely (another questions is why those accounts are so uni-directional; why doesn't the bank need to create an account with you as well?)
Most of the solutions to this problem favor us giving our personal information away for free to big companies, in exchange for some benefit which may never come. There's been talk for ages of having some sort of identity layer for the Internet, but that raises its own privacy and anonymity concerns.
her position is deliberately nebulous and lacking in real authority
So, just like every other CTO, right?
But that would turn them into terrorists hackers, and we can't have that.
Keep that up and I'll have to go find my Shadowrun gear.
They want the ultimate in internet troll technology.
Apparently trolls make awesome cyber-warriors.
When we were kids, many of us received immunizations against a host of nasty diseases. The purpose of these vaccines was to expose our immune systems to "fake badness," so that when we were exposed "real badness," the immune system would be pre-primed to deal with it.
Phishing is a problem precisely because most of the email that your average (l)user gets and most of the sites they visit are legitimate, with no badness (of this type) involved. When you've never been exposed to phishing behavior, it's much easier to fall for a scam.
You can run all the "awareness" campaigns you want, but users tend to ignore that sort of stuff, thinking, "right, I get it, but I'm smarter than that."
We need to inoculate users to teach them to be wary. There should be more sites like this out there. Some geared toward credit card data, some geared toward username & password, and others yet for other forms of PII.
Once a user is brought up short a few times by information pages like you see after you hit submit, they will be more cautious on all sites.
It must be a slow news day for something so technical to show up as a news article. But then again, the article has all of the necessary alarmist features, so I guess they had to let it through.
Yes, yes, I know, but I couldn't resist.
And yes, I am from Arkansas. No, I wasn't offended by the post.
(From the article:)
I don't know about you, but I regularly turn my thrombo up to eleven, and sometimes beyond. I think it's good for it.
I was certain that Dr. Pepper had PEG as an ingredient. However, I've just read the contents on a can from my fridge, and it's not there.
Am I imagining things? Did they change the formula? Am I thinking of a different soft drink?
Well, any three planets (points) form a triangle, so what's new?
If you're cooking books, shouldn't we be discussing home-ec, not math class?
(Note: I readily admit that home-ec needs a fair bit of math. No flames, please, or at least reduce to a simmer!)
Not true. The consumer is not the telemarketers' customer. Those companies that hire the telemarketers definately want the service.
Well, there are a few nostalgic reasons for wanting to build a mini... For instance it would give me something to do with the few reels of 9-track I still have lying around.
In another sense though, this is a mini. The "original" mini's were mini's because they were smaller than the prevelant computers of the day, right? So, the little cube is smaller than our prolific PC-size. Someday we may call the fingernail computer a "mini" because it's smaller than the more common wristwatch computer. Then we'll all have some fun when someone points out that he still manages a VAX cluster.
Yup. This is how all hard tokens really work. The strength of a token is related to how hard it is to get that secret back out again. This is true whether you're talking about shared-secret tokens, or PKI tokens where the secret is a secret key.
The idea of "something you have" used to be more directly connected to the real world, such as a driver's license, a passport, etc. In the digital world, folks are trying to do the same thing remotely, and that begs the question of how you can verify the physical presence of a second factor if you can't see it? To date, it's all come down to math, and the keeping of secrets.
To review, there are three factors that can be used to authenticate (positivly identify) someone:
Now, just because you're using a token does not mean that you are using a second factor to authenticate. For example, I could put my password on a floppy disk, lable the disk 'TOKEN' and then explain that I have to have that floppy to log in.
OK, so that's exaggerating, but sometimes things very close to that happen. A question to ask yourself is, "what specifically do I need to authenticate myself?" Let's answer that for a couple:
S/Key: you need the skey challenge information sent by the host, and your "passphrase," all of which get fed into the skey algorithm to produce the hash response.
You still need to remember that passphrase, and there's no simple way to detect that someone else has it too. So, you're effectively back to password authentication.
Now, S/Key is better than plain password because you should never use the same twice, so It's not possible to sniff the wire and find something that can be used again to authenticate.
BOTTOM LINE If you want 2-factor auth, skey is not for you. Otherwise, it's better than passwords. Just watch out for man-in-the-middle and other known weaknesses.
SecureID: You've got to have that fob. What the fob needs is the time, which it keeps itself, the seed, and the algorithm. If you had all of those, you could roll your own. Oh, and you need that PIN too. So, this really is two factor authentication: Something you know and something you have.
The problem with token-based authentication has always been that you have to put something on the token, and then prove that it's there without giving it up again. If I just store my password on the token, and then send it across the wire when asked, I've done nothing except hide from the user the fact that we're still using a password.
There are a couple of other ways to do this, thankfully. First is challenge-response. I say: "I'm john doe." You say: "Well, if you're really john, you'll know the proper response to this challenge: "Foo!" I now do some math on 'Foo!' and respond with: "Bar!" At which point you say: "Hi, John. Nice to see you again!" This works great so long as no one sees us, because a bad guy could now associate 'John Doe' 'Foo!' and 'Bar!' If he could now trick you into issuing the 'Foo!' challenge to his impersonated John Doe, he would have the correct response.
Second is what SecureID does: make up a (strong) secret algorithm that "no one else knows." The great thing about time-based algorithms is that they're time-based: the time becomes the challenge, and since the time is always different, it's impossible to issue the same challenge twice. The bad thing about time-based algorithms is that they're time based: if the clocks fall out of sync, the show's over.
So what's the answer? "That depends...." ;)
How about a combination of the two, a time-based challenge issued from the server that is "windowed" at the client. Not as strong, but the time sync isn't as critical either. This makes it possible to design the token without a super-accurate internal clock. (I have no idea how much accurate clocks cost.) Challenge-response is strong, so long as it's done right, so this may be suficient.
Hardware cost is the big factor here. This is what makes the ibutton and other customizable hardware a good choice. Of course ibuttons need the little blue dot readers, unless you spring for the USB fob to hold them, in which case your workstation needs USB support. There are other USB tokens, too, so this may be a possibility. The trick is finding one that works well with an open source USB stack.
It seems like you have LESS of a right to complain if you voted, because you implicitly acknowledged the fairness of the result.
I'd say that we acknolowledge our hope in the fairness of the result.
I don't think that voting means you have to accept a deceitful outcome. Of course, proving that is another matter. But a deceitful result is very different from what happened in the last presidential election.
If we participate in an election in good faith, we "have a right" to expect fair followthrough. What we've bought into is the election process, not the outcome.
Absolutely. But this isn't Security Through Obscurity.
The complaints about STO from the security community came from the days when fewer people understood security. Some people who thought they did (but didn't) reasoned that hiding information was the same as removing it.
This led to all sorts of strange things, including "proprietary" protocols and algorithms. Many of these secret encryption algorithms were easily broken because the algorithm was flawed. One of the first things you learn about crypto is that keeping an algorithm secret does not increase its strength. Similar things have happened to many proprietary protocols.
The concern about obscurity in any form has been that it's often used as a crutch, and that's led to a community backlash.
Hmm. I wonder if chronic procrastinators like myself could use this to our advantage.
Seriously, isn't this is a similar argument to one used against deep-space missions? (Since faster transportation will be only 50 years away, anyone who leaves for distant stars today will be overtaken in about 50+x years.)
Maybe not, but death is death, whether you take your own life, or the life of another.
--
I think I was lucky in my formative years: I was blessed with many "good" teachers. In fact, I think I can say I only had one or two bad ones. I can even go so far as to label a rare few "exceptional." Yes, I'm going to use names here.
Let's get started early: fourth grade. California's "Gifted & Talented" education program was just getting started. I was lucky enough to get a teacher who not only cared, but actually understood. Mrs. Yin (Cutler-Orosi USD) did a great job of letting us explore all sorts of different areas: extra music instruction, art, science, and literature (no computers yet). Oh, and we learned stuff too! :) Thanks to her for a super boost (as if I wasn't already off and running).
The big influence in Jr. High comes from Pamela Frost Martinez. English? Bah! (actually I did learn some English, too) The real work came from my involvement with the yearbook staff. Photography is Chemistry, and don't let anyone tell you otherwise! Making pottery after school was great fun, and I got to operate the kiln!
High School. Thanks first to JoAnn Powell for physically pulling me out of class into the counselor's office and making me apply to Arkansas Governor's School. Thanks also to Barbara Wade, Chemistry. She somehow figured out that when I started doodling, it meant that I understood--not that I was bored.
In college, one big thank-you goes to Dr. Susan Mengel. I'd had a lot of instruction in computer science up until that point, but she was one of the most effective teachers I've ever met.
--
Many new copiers sport a rather clean looking touch screen interface. There are several things I like about the design of their interfaces:
Similarly, when I look at my Visor PDA, the apps I'm most likely to use when I'm on the run are those with easy to use controls--the kind I can mash with my thumb while I running through an airport! :) The other kind, like the default address book, are handy in their own way, but again, it depends on what the task is.
As a side note, I always thought it would be neat to have a touch-screen "keyboard" that you could reconfigure to support different key sequences (qwerty vs dvorak, or foreign keyboards). It could also be reprogrammed to support games, and even have manipulative controls on the keyboard.
Problem with this thing is the same problem as with most touch screens: humans rely heavily on tactile input to guide the performance of manipulative tasks. It's how we know how hard to grip a full cup of coffee, or how gently to grasp an egg, how we judge how hard to strike the egg to crack it, and how we know when our cracking efforts have been successful.
Suggestion to anyone out there who plays with mechanical engineering type things: make a touch screen-like interface with tactile feedback. You'll make a mint (and get a patent, too ;)
--
It sounds like your goal is really to be able to send mail "from" any of your various accounts. That is, your recipients should see the mail as "coming from" user1@domain1.com or user2@domain2.com. Am I right?
Really, which SMTP server you use doesn't matter much here, unless you're dealing with savvy people who dig into the SMTP headers. There are several e-mail clients (I use pine) that support multiple profiles. I've got a profile (pine calls it a "role" setup for each of my e-mail addresses. When I compose a new message, I get to choose what role I will use. Pine is fairly intelligent: It recognizes when someone sends mail to a particular address and replys by default come from that address/role (I can always change it, of course)
So what SMTP server do I use? After all, most smtp servers are picky about who they will allow to use their services. Easy: I have to run an MTA for fetchmail to hand my POP'ed email to, so I use the same MTA (sendmail in my case) for sending. Yes, sendmail for one person could be considered overkill and there are simpler, lighter-weight MTA's out there. Find one you like.
In short, worry less about which SMTP server you're using and look for something that lets you define multiple sending addresses.Good luck!
--
Ask and you shall receive.(Not that I claim to be a genius about these things ;)
CPU pipelining in general is a divide-and-conquer scheme. Say you have some set of tasks, each of which you know you can do in ten minutes (take out trash, vaccuum living room, rebuild the linux kernel, etc.) What if you could break each of these down into smaller steps (like finding the trash, collecting it, taking the bag to the curb). Say each of these smaller steps takes no more than three minutes.
Now, you've got a lot of the large-scale tasks to do, so you invite a bunch of your friends over. Each person takes a specific task and does it in assembly line fashion.
Here's the scenario:
Oops! we're at 12 minutes, that's 2 minutes more than it takes me to do it by myself. But wait, how long does it take to get the next bag to the curb? If the searcher started looking for more trash as soon as he gives the first trash to the collector, he now has more trash ready to be colleted. Follow this through, and you get something that looks like this (apologies for the strangely aligned ascii-art):
-----------------------------------------
|_search__|_collect_|___bag___|___dump__|
-----------------------------------------
|_block1__|__NOP____|___NOP___|___NOP___|
|_block2__|__block1_|___NOP___|___NOP___|
|_block3__|__block2_|__block1_|___NOP___|
|_block4__|__block3_|__block2_|__block1_|
|_block5__|__block4_|__block3_|__block2_|
(and so on)
As you can see, by the time the dumper gets around to dumping block1, we have block2 (the next bag of trash) ready for him to dump. If everything proceeds in "lock-step" (that is, no one gets ahead of the others), then after that first bag of trash, we can dump a bag every 3 minutes. This is much faster than on bag every 10 minutes, and this is the most common type of speedup associated with piplining.
The first part (where various people are standing idle is called "filling the pipe." Certain pieces stand empty because we're working on the first instruction, and we just haven't gotten to them yet. In a CPU for example, the ALU will usually stand idle until the instruction decode logic has examined the bit arrangement of the instruction word and determined whether we should be ADDing, MOVing, BRAnching, or whatever.
Oh, and that brings up branches. Say you've got to stop bagging trash and start washing dishes or something. Everyone has to stop what they're doing (once they're finished with the tasks still waiting on them), and start work on something else. Sometimes we know this is coming and have prepared for it (known as "branch prediction"), but sometimes we guess wrong (say we thought we'd be doing laundry next). Now we not only are switching jobs, but we're switching to something unexpected. This can essentially cause us to skip a beat. This means that for a moment or two, someone (or two, or everyone) will have nothing to do. Then the pipe fills again and we're back up to speed.
CPU designers spend lots of time trying to find new ways to keep the pipe full, because, as you can see, the more a pipe stays full, the faster a system is overall. This is why branch prediction is so important. In addition to branch prediction, there's a whole slew of techniques, like "out of order execution," that allow us to make up time in other ways.
This is a four-stage pipeline. Imagine what's going on with Intel's 20-stage monster! If we can continually decrease the amount of time taken by the longest stage in the pipline, then we can generate more instructions per second: we still have 1 instruction per clock (IPC), but if we can speed up the clock, we get more throughput (IPS). How can we speed up the clock? We do less in each clock cycle and spread the instruction out over more pipeline stages.
This is a really simple overview. There's lots more where this came from, and it's all really neat stuff for those interested in hardware. For those interested, I'd recommend a book or course in hardware organization. You'll need a working knowledge of logic gates, some combinatorics, and some circuit design skills, but it's worth it!
--