First off, if you replace every "e" with "3", then you've actually shrunk the search space (by folding "e" and "3" into a single token), rather than expanded it. Now, you might have looked at every "e" and tossed a coin, and it just happens to have come up heads every time (are you sure you're not named Rosencrantz?), which is fair, but I would expect a sufficiently random approach to generate something more like:
13etdo0d
which is a good start. Of course, it's still a small search space, but you have done something terribly important: you've increased the number of "vowel" characters, which is one of the great weaknesses in using english words for passwords. Now you can also go beyond 8 characters, whcih really helps. Let's try adding a randomly chosen alphanumeric to the end:
13etdo0dT
Choosing a random alphanum for the last character multiplied the entire search space by 62, which is a nice benefit for having to remember one extra character. Next, you have "13" at the beginning... since you're going to remeber that as "thirteen" anyway, why not abbreviate it as "TH"? Ok, so the resulting password is
THetdo0dT
This is a simple example of how trivial it can be to generate a stronger password with even the most lame-brained of inputs.
Yeah, the banking industry has some very bad rules on password management. I had to convince my superiors to let me apply for waivers to some of them (e.g. password MAXIMUMS, requirements for certain characters, etc).
Especially the nice fact that if the programm is ever compromised, everybody has a nice seed for his brute force cracker.
Not at all, that's the entire point. The search space for my programs output is designed to be at least as large as the passwords that any human would come up with, and hopefully MUCH larger. Specifically, I would consider this program a total failure if having access to it (which I plan to publish) gave you a leg up on cracking the generated passwords.
On the other hand, the foibles of human nature that lead to a password being "easy to remember" certain ARE a starting point, but security of passwords MUST be a trade off in the direction of memorability or in the direction of non-crackability unless you move away from re-usable passwords (the ultimate right choice, but rarely practical as yet).
Are you taking into account that "aaAA00$$$" has 24 permutations that are identical (2!^3 * 3!^1 = 24), and must therefore be counted as one?
If you could dredge up the math for calculating permuations of intersecting sets, I'd be thankful, though, I've been too lazy to go look that up and verify my own math.
Another area in which my math needs double-checking in the docs before I release... sigh.
PS: I hope you don't take this the wrong way, but your first suggestion is not a good password generator. There is a very high affinity for certain letters. Here's the distribution in my personal word-list for first-letters:
406 A
280 B
382 C
180 D
215 E
116 F
191 G
239 H
107 I
176 J
73 K
197 L
347 M
159 N
90 O
282 P
9 Q
188 R
438 S
190 T
33 U
69 V
102 W
4 X
28 Y
32 Z
4545 a
4359 b
7280 c
4633 d
3063 e
3250 f
2373 g
2595 h
3155 i
624 j
525 k
2250 l
3847 m
1579 n
1860 o
5857 p
374 q
4275 r
8552 s
3706 t
2043 u
1100 v
1888 w
21 x
209 y
124 z
Thus trying any password that contained K, Q, X, Z, x, y or z would not be worth-while, and your search space starts to get pretty small!
The second option is pretty bad as well, but has promise. You'd like my program... it has some really fun generation schemes. Some of them (e.g. english-like word generation) are just as weighted as your examples, but I throw in some interesting curve-balls to expand the search space substantially, and it works out well.
If you want a tweakable Linux distro, there are better choices than FC to start from.
I would disagree with that. There are distributions with different approaches and different trade-offs, but "better"? No.
Plus, it has been acknowledged as a testbed for RH Enterprise distro's, so you can't exactly hope for rock solid stability.
I don't see how that follows. If, by rock-solid stability, you mean "nothing ever changes", then yes, you're correct. If you mean "software works out of the box," then I can't agree. I have yet to find anything in FC3 that behaves out of specification. The problems I've had have been related to the performance of spam checking in E2 (not a stability issue); the brokeness of the NVidia binary driver (not an FC3 issue, and not even SHIPPED with FC3); and the lack of portability of some FC1-2 apps (again, not an FC3 issue).
I have yet to see a (OS-wide, or application-specific) crash since I loaded FC3 (saw some under FC3test3). Actually, that's a lie. What's more accurate is that I've yet to see a crash in a component that shipped on the FC3 media... other things I added, HAVE crashed once or twice.
Other than people who are forced to keep Red Hat legacy systems[...]
I am not forced to run FC3, and it suits my needs. Your milage may vary, and that's fine.
The symmetric key cryptosystems used by almost all modern public-key systems to encrypt the bulk of the data stream (where public-key is only used to transfer an initial session key) tend to be far more demonstratably secure than most public key cryptosystems.
The only reason we use public key at all is for the ability to exchange keys over a public channel, otherwise they would not be terribly interesting.
So, is this program available? Under the GPL or BSDL, hopefully?
Someday soon, I hope to contribute it to the community. It's hard to let it go, since I'm always adding new patterns or pattern modifiers, and all of the documentation is math that I need to put in front of others before I trust my results.
I'm not stingy though, and I do intend to contribute this.
I Am Not A Crytography expert, so I was just wondering if you could explain further why *excluding* punctuation and numbers was harder to crack?
Password space 1 (mkpasswd as shipped by expect):
1 punctuation, 2 numbers, 2 upcase, 2 downcase, 2 "any". There were other restrictions, but I'll stick to these for now.
Password space 2 (just an example, not always good password):
8 random upper/lower alpha and/or numeric characters.
While the latter category lacks punctuation, it can include results like "aaaaaaaa" and "a0a0a0a0" both of which are not allowed in the first result set. The resulting search spaces are about the same size, even though the first example is 9 characters, where the second is 8.
So you claim that you read Applied Cryptography, and yet you use a proprietary/secret method, not obviously subjected to peer review, to generate your "secure" passwords?
That's a leading way to state it. Here's another way (perhaps just as leading): I went from one proprietary, unreviewed method (whatever came to my head) to another non-entirely proprietary, unreviewed method which I felt to be a small improvement in the process.
I resolved this problem by writing a program that generates provably secure, memorable passwords for users.
Of course, the security buffs in the audience just stood their chairs back upright, brushed off the cheetos dust from their pants and are preparing to roast me over a slow fire for public stupidity. Let me explain.
I tried using a password generator called mkpasswd that comes with expect. I thought it generated great passwords because they looked impressively secure. Then I did the math... ulch.
This was my introduction to a concept that I later read about in many places, including Applied Cryptography: the human's ability to judge secure from insecure is based on pattern-recognition. If you generate passwords or other tokens that don't match a pattern that the brain is used to, it looks "obscure", and that maps in most people's minds to "secure"... wrong.
This program generated a 9-character password (sounds good) which had to contain at least one punctuation mark and 2 digits... Prolbem is there are only 10 digits, and just a handful more valid punctuation marks, so searching all 9-character passwords that contain 2 digits and a punctuation mark is orders of magnitude less work than searching all possible 9-character passwords. The result was then limited further to the requirement of 2 upper-case letters and 2 lower-case latters. Well, there goes the farm! It turns out that the result is easier to crack than a random sequence of alpha-numerics with no punctuation (and only slightly more secure than an 8-character sequence of random alpha-numerics)!
So, I began doing some research on techniques for generating things that would look insecure (i.e. are memorable), but would actually be more secure than mkpasswd's approach. I found several approaches, and eventually came up with several of my own over the course of about 8 years. I now use a set of about 20 patterns which are permuted into slightly over 100 patterns including pseudo-word generation, permutation and combination of english words and so on. Each pattern maps to at least 1x10^13 possible passwords, and usually much more.
I've also added various strictness settings where the top 1% or so of crackable passwords are eliminated from the result space (this is tricky, as removing too many possible results is just as bad as having a weak pattern).
I now generate all of my passwords this way, and in reviewing what I used to have for passwords before, I have to say that my passwords are certainly more difficult to crack now (of course, part of that is that I use longer passwords now that MD5 passwords are fairly universally supported).
Obviously, there's no universal answer (as wp mentions), but I've always interpreted them thusly:
"Sausage?!"
In American english this would be spoken "SAW-suge?" with near-hysterical emphasis on the first sylable. It is a question, but spoken so as to imply disbelief, begging a confirmation.
"Sausage!?"
Spoken as "saw-suge" with a very light emphasis on the first sylable. It is an exclamatory statement, but with just enough of a rise at the end to imply a question. I would almost always interpret this as rhetorical, implying that the speaker is more shocked by the fact than expecting a confirmation or refutation.
Your article isn't news at all because in February 2004, United Linux was declared dead by Jack Messman and Paula Hunter.
As you say, you know this because you've been following it.
It's a bit like a Mac user saying, "the current stance of Apple on [insert some interesting MacOS feature] isn't news because Steve Jobs answered that question in a press conference 6 months ago." Only problem is that most people have no idea what Steve Jobs said in a press conference 6 months ago.
The point to a "retrospective" about United Linux is not bringing YOU up to speed, because you already are.
They could also broadcast without ads for a small download fee.
Then it wouldn't be a true P2P network. I'm talking about something like Gnutella, not a proprietary download service (that's been tried... and failed).
P2P is just so much more resilient and costs so much less in terms of bandwidth that I can't see anything else flying. Plus, the goal is to drown out the illegal sharing with quality, legal content. That requires sharing over the same networks as the illegal stuff.
I think this is the future of television: direct downloads of shows for interested parties. Small fee, no ads.
I think the pay-TV model is dead, but it could come to pass that Cable companies (now that they pretty much own the residential Internet business, at least in the US) would decide to host shows the same way they carry pay cable channels like HBO or Showtime.
No. Reverse engineering is key in understanding what virus writers are doing TODAY, and how the state of the art is progressing. It is hoped that you will conclude, "these are just a bunch of script kiddies who don't write unique and interesting code," but in reality dissassembling this stuff reveals that the Virus/Worm writing market is getting quite sophisticated. Tracking the advances and giving that information to the white-hats is key.
So the obvious solution is for media companies and studios to start building P2P broadcast stations that produce such high-quality entertainment that a) it can generate huge ad revenues and b) it drowns out the illegal stuff... right?
Why they should do this:
1. They're not restricted in terms of media. They can ship any audio, video, text, software, etc. media that the "viewers" can open. 2. They have a leg-up on illegal files because they can provide several stable download points (perhaps even using something like Akamai) that make their files faster to download. 3. There is no uplink lag 4. Uplink equipment cost is trivial by comparison with a broadcast or even cable station. 5. Ad revenues can be tied to more reliable measures of the viewer base than with broadcast or television. Neilsen would love this, as would advertisers. 6. You get to leap-frog HDTV and go to better digital formats long before HDTV telvisions have saturated the market.
There are more, subtler advantages, but I think any Hollywood MBA worth is diploma should be able to see them.
Lossiness is ignorable, that just reduces the value of each sample, but you can always include more samples to compensate. However, compression noise is usually the least of your concerns. You really care about hand-held motion, skew, obstructions and screen artifacts. All of these could be removed through careful compositing (thank's for reminding me there's a term for this).
It's not that FC is a bad distribution, per se, it's just that I fail to see anything particularly special about it.
Best endorsement of Fedora I've ever heard! Hey, if you want the shiny-things OS go buy a Mac. If you're looking for the logical successor to the free Red Hat Linux distribution (which was never "particularly special"), Fedora is your choice.
You CAN tweak the hell out of FC3 and get it to look and feel very pretty, but the important things to most long-time RHL and Fedora users are careful integration of new features combined with a smooth transition from previous releases. I get all of the above from FC3.
I tried to build ReZound http//rezound.sf.net/ but it failed to compile [...] Neither does Audacity
Well, that's hardly Fedora's fault. You could always port those packages and contribute back the changes... Many packages end up relying on compiler or library features that they should not. I've had problems compiling some pacakges that don't play ball with the newer glibc because of this. These projects should be appropriately spanked and given patches.
When compiling MPlayer it fails to build with GUI and it fails to play sound if you playback a video
I'm running mpalyer and mplayer-gui as provided, what did you need to compile your own for that SRPM wasn't sufficient for?
JAVA: I don't like to have gcj installed instead of a real JVM
gcj has nothing to do with the JVM not being present. The JVM is not present because it's not free. Talk to sun about releasing it under an OSS-compatiable license.
MP3: none of the installed sound tools can play or record MP3 files
This is, of course, old news. Red Hat stopped shipping anything related to MP3 a long time ago due to patent concerns. You can always get the mp3 goodies from elsewhere, but Red Hat won't ship them and hasn't since RH9 (possibly as far back as 8, I'm not 100% certain).
Your other comments are quite interesting, and I'm not trying to say that the above aren't problems, it's just that I think you want to keep some perspective on these issues which don't all have trivial solutions.
Speaking of convergance, give a Garmin iQue a test-drive... you'll never look back. It's a PalmOS-based GPS which has all of the features of a great Garmin GPS including routing, spoken directions, a great in-car system including an amplified speaker connected to the cigarette-lighter power adapter, color display, flash reader for map storage, re-routing on the fly, ability to save locations into the address book, ability to search for nearby businesses by type (e.g. find the nearest BBQ joint).
Slashdot Mirror
Hmmm.. interesting. Well, at least it sounds like it's getting incrementally better. Progress is good.
First off, if you replace every "e" with "3", then you've actually shrunk the search space (by folding "e" and "3" into a single token), rather than expanded it. Now, you might have looked at every "e" and tossed a coin, and it just happens to have come up heads every time (are you sure you're not named Rosencrantz?), which is fair, but I would expect a sufficiently random approach to generate something more like:which is a good start. Of course, it's still a small search space, but you have done something terribly important: you've increased the number of "vowel" characters, which is one of the great weaknesses in using english words for passwords. Now you can also go beyond 8 characters, whcih really helps. Let's try adding a randomly chosen alphanumeric to the end:Choosing a random alphanum for the last character multiplied the entire search space by 62, which is a nice benefit for having to remember one extra character. Next, you have "13" at the beginning... since you're going to remeber that as "thirteen" anyway, why not abbreviate it as "TH"? Ok, so the resulting password isThis is a simple example of how trivial it can be to generate a stronger password with even the most lame-brained of inputs.
Oh please, if you want to bait me, you're going to have to do better than that.
Yeah, the banking industry has some very bad rules on password management. I had to convince my superiors to let me apply for waivers to some of them (e.g. password MAXIMUMS, requirements for certain characters, etc).
Especially the nice fact that if the programm is ever compromised, everybody has a nice seed for his brute force cracker.
Not at all, that's the entire point. The search space for my programs output is designed to be at least as large as the passwords that any human would come up with, and hopefully MUCH larger. Specifically, I would consider this program a total failure if having access to it (which I plan to publish) gave you a leg up on cracking the generated passwords.
On the other hand, the foibles of human nature that lead to a password being "easy to remember" certain ARE a starting point, but security of passwords MUST be a trade off in the direction of memorability or in the direction of non-crackability unless you move away from re-usable passwords (the ultimate right choice, but rarely practical as yet).
If you could dredge up the math for calculating permuations of intersecting sets, I'd be thankful, though, I've been too lazy to go look that up and verify my own math.
Another area in which my math needs double-checking in the docs before I release... sigh.
PS: I hope you don't take this the wrong way, but your first suggestion is not a good password generator. There is a very high affinity for certain letters. Here's the distribution in my personal word-list for first-letters:Thus trying any password that contained K, Q, X, Z, x, y or z would not be worth-while, and your search space starts to get pretty small!
The second option is pretty bad as well, but has promise. You'd like my program... it has some really fun generation schemes. Some of them (e.g. english-like word generation) are just as weighted as your examples, but I throw in some interesting curve-balls to expand the search space substantially, and it works out well.
No, if I were relying on STO, then it wouldn't be a very good password generator would it? ;-)
If you want a tweakable Linux distro, there are better choices than FC to start from.
I would disagree with that. There are distributions with different approaches and different trade-offs, but "better"? No.
Plus, it has been acknowledged as a testbed for RH Enterprise distro's, so you can't exactly hope for rock solid stability.
I don't see how that follows. If, by rock-solid stability, you mean "nothing ever changes", then yes, you're correct. If you mean "software works out of the box," then I can't agree. I have yet to find anything in FC3 that behaves out of specification. The problems I've had have been related to the performance of spam checking in E2 (not a stability issue); the brokeness of the NVidia binary driver (not an FC3 issue, and not even SHIPPED with FC3); and the lack of portability of some FC1-2 apps (again, not an FC3 issue).
I have yet to see a (OS-wide, or application-specific) crash since I loaded FC3 (saw some under FC3test3). Actually, that's a lie. What's more accurate is that I've yet to see a crash in a component that shipped on the FC3 media... other things I added, HAVE crashed once or twice.
Other than people who are forced to keep Red Hat legacy systems[...]
I am not forced to run FC3, and it suits my needs. Your milage may vary, and that's fine.
Ah... symmetric hole?! What symmetric hole?
The symmetric key cryptosystems used by almost all modern public-key systems to encrypt the bulk of the data stream (where public-key is only used to transfer an initial session key) tend to be far more demonstratably secure than most public key cryptosystems.
The only reason we use public key at all is for the ability to exchange keys over a public channel, otherwise they would not be terribly interesting.
So, is this program available? Under the GPL or BSDL, hopefully?
Someday soon, I hope to contribute it to the community. It's hard to let it go, since I'm always adding new patterns or pattern modifiers, and all of the documentation is math that I need to put in front of others before I trust my results.
I'm not stingy though, and I do intend to contribute this.
I Am Not A Crytography expert, so I was just wondering if you could explain further why *excluding* punctuation and numbers was harder to crack?
Password space 1 (mkpasswd as shipped by expect):
1 punctuation, 2 numbers, 2 upcase, 2 downcase, 2 "any". There were other restrictions, but I'll stick to these for now.
Password space 2 (just an example, not always good password):
8 random upper/lower alpha and/or numeric characters.
While the latter category lacks punctuation, it can include results like "aaaaaaaa" and "a0a0a0a0" both of which are not allowed in the first result set. The resulting search spaces are about the same size, even though the first example is 9 characters, where the second is 8.
So you claim that you read Applied Cryptography, and yet you use a proprietary/secret method, not obviously subjected to peer review, to generate your "secure" passwords?
That's a leading way to state it. Here's another way (perhaps just as leading): I went from one proprietary, unreviewed method (whatever came to my head) to another non-entirely proprietary, unreviewed method which I felt to be a small improvement in the process.
I resolved this problem by writing a program that generates provably secure, memorable passwords for users.
Of course, the security buffs in the audience just stood their chairs back upright, brushed off the cheetos dust from their pants and are preparing to roast me over a slow fire for public stupidity. Let me explain.
I tried using a password generator called mkpasswd that comes with expect. I thought it generated great passwords because they looked impressively secure. Then I did the math... ulch.
This was my introduction to a concept that I later read about in many places, including Applied Cryptography: the human's ability to judge secure from insecure is based on pattern-recognition. If you generate passwords or other tokens that don't match a pattern that the brain is used to, it looks "obscure", and that maps in most people's minds to "secure"... wrong.
This program generated a 9-character password (sounds good) which had to contain at least one punctuation mark and 2 digits... Prolbem is there are only 10 digits, and just a handful more valid punctuation marks, so searching all 9-character passwords that contain 2 digits and a punctuation mark is orders of magnitude less work than searching all possible 9-character passwords. The result was then limited further to the requirement of 2 upper-case letters and 2 lower-case latters. Well, there goes the farm! It turns out that the result is easier to crack than a random sequence of alpha-numerics with no punctuation (and only slightly more secure than an 8-character sequence of random alpha-numerics)!
So, I began doing some research on techniques for generating things that would look insecure (i.e. are memorable), but would actually be more secure than mkpasswd's approach. I found several approaches, and eventually came up with several of my own over the course of about 8 years. I now use a set of about 20 patterns which are permuted into slightly over 100 patterns including pseudo-word generation, permutation and combination of english words and so on. Each pattern maps to at least 1x10^13 possible passwords, and usually much more.
I've also added various strictness settings where the top 1% or so of crackable passwords are eliminated from the result space (this is tricky, as removing too many possible results is just as bad as having a weak pattern).
I now generate all of my passwords this way, and in reviewing what I used to have for passwords before, I have to say that my passwords are certainly more difficult to crack now (of course, part of that is that I use longer passwords now that MD5 passwords are fairly universally supported).
Obviously, there's no universal answer (as wp mentions), but I've always interpreted them thusly:
"Sausage?!"
In American english this would be spoken "SAW-suge?" with near-hysterical emphasis on the first sylable. It is a question, but spoken so as to imply disbelief, begging a confirmation.
"Sausage!?"
Spoken as "saw-suge" with a very light emphasis on the first sylable. It is an exclamatory statement, but with just enough of a rise at the end to imply a question. I would almost always interpret this as rhetorical, implying that the speaker is more shocked by the fact than expecting a confirmation or refutation.
Your article isn't news at all because in February 2004, United Linux was declared dead by Jack Messman and Paula Hunter.
As you say, you know this because you've been following it.
It's a bit like a Mac user saying, "the current stance of Apple on [insert some interesting MacOS feature] isn't news because Steve Jobs answered that question in a press conference 6 months ago." Only problem is that most people have no idea what Steve Jobs said in a press conference 6 months ago.
The point to a "retrospective" about United Linux is not bringing YOU up to speed, because you already are.
They could also broadcast without ads for a small download fee.
Then it wouldn't be a true P2P network. I'm talking about something like Gnutella, not a proprietary download service (that's been tried... and failed).
P2P is just so much more resilient and costs so much less in terms of bandwidth that I can't see anything else flying. Plus, the goal is to drown out the illegal sharing with quality, legal content. That requires sharing over the same networks as the illegal stuff.
I think this is the future of television: direct downloads of shows for interested parties. Small fee, no ads.
I think the pay-TV model is dead, but it could come to pass that Cable companies (now that they pretty much own the residential Internet business, at least in the US) would decide to host shows the same way they carry pay cable channels like HBO or Showtime.
No. Reverse engineering is key in understanding what virus writers are doing TODAY, and how the state of the art is progressing. It is hoped that you will conclude, "these are just a bunch of script kiddies who don't write unique and interesting code," but in reality dissassembling this stuff reveals that the Virus/Worm writing market is getting quite sophisticated. Tracking the advances and giving that information to the white-hats is key.
So the obvious solution is for media companies and studios to start building P2P broadcast stations that produce such high-quality entertainment that a) it can generate huge ad revenues and b) it drowns out the illegal stuff... right?
Why they should do this:
1. They're not restricted in terms of media. They can ship any audio, video, text, software, etc. media that the "viewers" can open.
2. They have a leg-up on illegal files because they can provide several stable download points (perhaps even using something like Akamai) that make their files faster to download.
3. There is no uplink lag
4. Uplink equipment cost is trivial by comparison with a broadcast or even cable station.
5. Ad revenues can be tied to more reliable measures of the viewer base than with broadcast or television. Neilsen would love this, as would advertisers.
6. You get to leap-frog HDTV and go to better digital formats long before HDTV telvisions have saturated the market.
There are more, subtler advantages, but I think any Hollywood MBA worth is diploma should be able to see them.
Lossiness is ignorable, that just reduces the value of each sample, but you can always include more samples to compensate. However, compression noise is usually the least of your concerns. You really care about hand-held motion, skew, obstructions and screen artifacts. All of these could be removed through careful compositing (thank's for reminding me there's a term for this).
It's not that FC is a bad distribution, per se, it's just that I fail to see anything particularly special about it.
Best endorsement of Fedora I've ever heard! Hey, if you want the shiny-things OS go buy a Mac. If you're looking for the logical successor to the free Red Hat Linux distribution (which was never "particularly special"), Fedora is your choice.
You CAN tweak the hell out of FC3 and get it to look and feel very pretty, but the important things to most long-time RHL and Fedora users are careful integration of new features combined with a smooth transition from previous releases. I get all of the above from FC3.
I tried to build ReZound http//rezound.sf.net/ but it failed to compile [...] Neither does Audacity
Well, that's hardly Fedora's fault. You could always port those packages and contribute back the changes... Many packages end up relying on compiler or library features that they should not. I've had problems compiling some pacakges that don't play ball with the newer glibc because of this. These projects should be appropriately spanked and given patches.
When compiling MPlayer it fails to build with GUI and it fails to play sound if you playback a video
I'm running mpalyer and mplayer-gui as provided, what did you need to compile your own for that SRPM wasn't sufficient for?
JAVA: I don't like to have gcj installed instead of a real JVM
gcj has nothing to do with the JVM not being present. The JVM is not present because it's not free. Talk to sun about releasing it under an OSS-compatiable license.
MP3: none of the installed sound tools can play or record MP3 files
This is, of course, old news. Red Hat stopped shipping anything related to MP3 a long time ago due to patent concerns. You can always get the mp3 goodies from elsewhere, but Red Hat won't ship them and hasn't since RH9 (possibly as far back as 8, I'm not 100% certain).
Your other comments are quite interesting, and I'm not trying to say that the above aren't problems, it's just that I think you want to keep some perspective on these issues which don't all have trivial solutions.
Speaking of convergance, give a Garmin iQue a test-drive... you'll never look back. It's a PalmOS-based GPS which has all of the features of a great Garmin GPS including routing, spoken directions, a great in-car system including an amplified speaker connected to the cigarette-lighter power adapter, color display, flash reader for map storage, re-routing on the fly, ability to save locations into the address book, ability to search for nearby businesses by type (e.g. find the nearest BBQ joint).
You'll fall in love.
Gossip column? Ah huh. Well, sorry you didn't get anything out of it. Enjoy the other articles today.
Oh, this is fun, let me try:
;-)
Number of 9-character passwords made up of just letters (mixed case) and numbers: 1.354e+16
Number of valid ".com" domain names: 7.009e+91
Chance that two sites will have the same root password: priceless