(I know you probably already know this, but others may not.)
Certificates are required because you need to know that the other end of the connection is who they say they are. Without that assurance, you open yourself up to a man-in-the-middle attack:
Alice is using SSL to talk to secure.bob.com. Eve wants to see what Alice and secure.bob.com are talking about.
Eve positions herself between Alice and secure.bob.com. She creates two public/private key pairs. She sends one of those public keys to Alice, posing as secure.bob.com. and the other to secure.bob.com, posing as Alice.
As Alice sends data to secure.bob.com, Eve decrypts it with her key and re-encrypts it with secure.bob.com's real public key. The same happens in the other direction.
This can't happen with certificates because secure.bob.com's public key is authenticated with the certificate. (Admittedly, Alice doesn't have a cert in most SSL transactions, but most people settle for the end that they feel needs to be most trustworthy -- the server -- to have the cert.)
Now keep in mind that most browsers are designed to keep the large portion of the Internet-using public (who are stupid) from hurting themselves. Hence the need for certificates, because there is no way you are going to get Grandma to understand man-in-the-middle attacks -- and if you tell her about them, she most certainly will not trust SSL in general.
That said, the SSL patches to lynx don't require certs.:-)
AlterNIC tried this with DNS, and all it required was the cooperation of folks who ran DNS servers all over the world (a relatively small group, actually.) Didn't work.
I definitely won't take the odds on anyone being able to convince the Internet-using public (most of which is stupid, frankly) to install new certs in their browsers. Also, forget about getting them preinstalled in the browsers -- M$ is buddy-buddy with Verisign, and without IE support, no one will use our CA.
If sites are all directing folks to download new certs (I know this will happen anyway with the root rollovers, but bear with me), we will be training folks to accept any cert that they stumble across. Since anyone can create a cert, this could open up unsuspecting users to thinking a connection is ``secure'' when there is no guarantee (even the slight guarantee given by the current CAs) that the other end is who they say they are.
I would say, at best, that if this goes through, SSL should be considered proprietary and dead, and should be shunned by those of us who think computing should be open. It's quite a shame.
Re:BSD has lost, Linux won the unix war. READ ON
on
FreeBSD 3.4 released
·
· Score: 2
OpenBSD has telnetd enabled by default, as well as most other standard services (see inetd.conf).
From inetd.conf on my OpenBSD 2.6 laptop (recently installed, not yet tweaked):
#telnet stream tcp nowait root...
Your other points, however, are well taken. Most open source OSen can be made as secure or as insecure as the admin is capable of. In the case of OpenBSD, it simply takes less effort since the emphasis is on security, whereas other OSen seem to be focused on ``gee whiz, look what I can do'' out of the box.
This is a classic example of ``security by obscurity'', and it's what Microsoft relies on. I would say that the problem would have been found eventually. If you follow BUGTRAQ at all you'll notice that there are people finding buffer overflows in code they don't have the source to simply by throwing shellcode into fields that look like they have a fixed length. If it makes it crash, they've found a potential exploit. (Note to security gurus: yes, I know this is terribly simplistic; but it makes my point.)
If you get hacked because of this bug, please write a nice "thank you" letter to the U.S. Patent Office.
And to RSA as well. It's amazing to me that in the CERT advisory, they grant permission to have this fix be made, but don't grant permission for any further fixes to be made, should they become necessary. I can see if, in their original onerous license, they might not have added that clause just because they weren't thinking about it. But come on, RSA! Wake up!
I think RSA believes their patent enforced monopoly entitles them to write sloppy, slow, poor quality code.
My personal feeling is that they put out the code ``for the benefit of academia'', to train a horde of students to bow down at the RSA throne -- and then when those students get out in the Real World(TM), they love RSA the algorithm, but need to shell out big bucks to use a better RSA implementation because -REF just plain sucks. It would not surprise me if this were intentional.
Someone on BUGTRAQ floated that the RSAREF buffer overflow might be used in an AIM-style ``detection'' fashion. (Remember the AIM buffer overflow that was used to see if the client on the other end was a ``genuine'' AIM client or not?)
As most know, if you're in the US, RSAREF is the be-all and end-all of what you can use -- and only then, noncommercially. If you want to use RSA without RSAREF, you have to buy software from someone who pays RSA licensing fees. (On a side note, it's probably worthless to see if you can get a personal license from RSA to use OpenSSL or some other toolkit, even if you have money. I floated this question on the OpenBSD list, since OpenBSD includes OpenSSL, and it seems it's been tried -- and RSA ignored the request.)
In any event, RSA could theoretically use the RSAREF vulnerability to scan US hosts for compliance with the RSAREF mandate. If the buffer overflow was there, and they were a commercial entity, the red alert klaxon would sound and the lawyers would be summoned. Not a pretty picture.
The way to combat a potential scenario like this would be to get the news out as fast as possible that you can patch RSAREF (RSA graciously allowed us in the CERT advisory to patch it, gee how nice of them) and should ASAP.
I think the real problem with searching really isn't that the Internet is growing too large. The central problem with it being too hard to find information is due to the unfortunately ever-changing nature of HTML. (Yes, I know there are much better solutions out there -- I work with some of them on a daily basis. However, we seem to presently be stuck with HTML and its variants.)
It's a self-feeding monster, whose typical cycle goes as follows: SearchEngineInc (a division of ConHugeCo) creates a new technology that really impresses people with its ability to find what they want more quickly. (Right now SearchEngineInc is probably Google, at least in my view.)
Once the new technology takes root, content authors (well, maybe not the authors so much as their PHBs) note that SearchEngineInc doesn't bring their business (which sells soybean derivatives) to the top of the search list (when people type ``food'' into the search engine). Said PHBs make the techies work around this ``problem'', and all of a sudden SearchEngineInc's technology isn't so great anymore because the HTML landscape it maps has changed.
A similar situation occurs when PHBs think their site doesn't ``look'' quite as good as others. (Insert my usual rant about content vs. presentation here.) Whether via a hideous HTML-abusing web authoring program, or via all sorts of hacks that God never intended to appear in anything resembling SGML, the HTML landscape is changed there as well, and SearchEngineInc's product becomes less effective.
What's the solution to this? I'm not quite sure. Obviously there are better technologies out there that are at least immune to PHBs' sense of ``aesthetics'' but I would wager few of them are immune from hackery. I'd say that search engine authors are doomed for all time to stay just one step ahead of the web wranglers. At least it assures them that their market segment won't go away any time soon.:-)
This may be way off-topic but I had to at least respond to the last part.
However, given something interesting you can concentrate better than 'normal' people.
``Suffer'' was perhaps the wrong choice of word. I do have to agree with you here. However, in this case it could be construed as suffering because the mundanity of walking from place to place is theoretically causing me to get taken in by mall security.
In addition, I'd like sometimes just to be able to do something simple without being distracted; after all, I do have to do silly things like move from place to place or my taxes sometimes.
A system like this is probably worth far less than the time invested in creating it. Yeah, sure, right now they can't fool it. But give them credit -- while your common criminal's pretty stupid, thieves are thieves because they are good at what they do. They'll relearn how to sneak and new ones will learn as they enter the ``trade''.
In the meantime, I imagine I'll be setting off lots of alarms. (Poor George, his donuts will go stale.) I suffer from ADD and it's not uncommon that I'll be striding purposefully somewhere one moment and forget what I was doing the next. That's got to look an awful lot like suspicious behavior to a computer.
With the next round of additions from Sun, Ecma's "standard Java" (which they'd have to choose some other name for) would look like "poor man's choice".
Very true. Let's not also forget to look at just what ECMA has done for JavaScript compatibility. Very little. I see at least three different implementations out there, probably a heck of a lot more. All need to be ``written to''. Sigh.
Ever stop and consider that the VM's you were using were at fault, and weren't verifying their bytecode correctly?
Never crossed my mind, honestly. But I can say with certaincy that said compiled code would crash on Sun JVMs as well as others, rather defeating the purpose in the first place. Regardless who was at fault, I could accomplish the following:
Compile with M$ compiler, crash on Sun and other JVMs but not M$
Compile with Sun compiler or guavac (the only other options available at the time), run on M$ JVM, Sun JVM, just about any other JVM you can name...
Finger-pointing aside, which would you choose if you had a job to get done?
I used VJ++ a couple years ago (versions 1.1 and 6, I think, were the versions I tried; the former downloaded from MS's site) because I had become familiar with using the MS dev tools. However, I had to turn around and recompile all my code with Sun's compiler because the code generated by the MS compiler would crash non-MS JVM's. This was simple code, too -- all JDK1.0-compliant and pure. Didn't even try to detect platforms or anything.
In any event, I'm glad to see J++ starting to fade into obscurity. It really wasn't a very useful product.
I own a Casio E11, E10, and a E105, One of the Two is an HPC, i've never right tapped on,
On the H/PC, go to your desktop sometime, hold down Alt, and tap one of the icons. That's your ``right tap''. Anyway, the thrust of that point was originally that the reason I dislike CE is because they are trying to fit a desktop metaphor into a handheld or palm unit, and I don't think it makes sense. Tom Christiansen's recent article on interface zen explains it better than I can.
And I beg to differ that free != good. In the world of development tools, the freer they are, the better -- because you can count on more varied applications being available as well as lots of apps that will mimic the freeness of the development tools and will be able to be improved on by many people. CE seems to, probably because the devel tools are so expensive, encourage locking up of apps and code.
Anyway, I can see we're not going to reach an agreement on this one.:-)
Microsoft Outlook and Exchange and Office 2000 are used Exclussively at work
Then I guess you don't have a problem with ``Pocket Outlook''. I do, because I am moving away from Microsoft Outlook. I think it is an inferior solution, and it ties me unnecessarily to the Windows platform. If, someday, your company decided that Outlook/Exchange was no longer right for its needs, what would your CE device do then?
your point there proves you have never used a CE device. The GUI is the same in its looks, you never have to right tap, and there is no such thing.
How childish of you. You speak of something you know nothing about as if it does not exist and assumes it proves me wrong. Pick up an H/PC sometime and check it out.
You make a lot of points about web synchronization here. I don't have a problem with those; they work equally well regardless of platform, primarily because Microsoft doesn't have their hands in them.
Finally, correct me if I'm wrong (I regret I have not investigated this as thoroughly as I should), but isn't Palm's official development platform already free? Seems like it's better if the platform owner supports your efforts from the beginning. Helps insure you don't get left out in the cold when xxx new feature comes along.
About 90% of the names pointed to an "under construction" site...
Question for you. Ignore totally how anyone feels about just plain cybersquatting and reselling of domain names. That's not the issue here.
You are starting an Internet business. Does it not stand to reason that when you start said business, you will register the domain before you ``go into business'' proper, and will have an ``under construction'' page?
Just something to think about... there may very well be legitimacy behind those pages. I might also add that it is still possible (last time I checked) to run a domain without even having a site attached to it.
Hmm. I have a domain that actually some folks might be interested in. I grabbed it from a lame delegator some time ago because I was at the time setting up an IRC net. We were popular for about, oh, 3 months... then we got to the point where we had more servers than people.:-)
Wonder how much I could get for nameless.net? I'll trade someone it for a new Visor Deluxe:-)
Congratulations, you have found the device that you want for your needs.
I had a handheld CE device for some time. Its touchscreen recently broke so it's only usable with the keyboard. But even before then, I had the following beefs with it:
Its scheduling app was not something that made sense on a handheld or palm-based device. It felt just like a copy of Outlook (which ties in with point #3, btw.)
The traditional Windows GUI metaphors just don't work on handheld devices. I mean, come on, we're going to simulate right-clicking by holding down Alt and tapping?
It only syncs with Microsoft products. I can't emphasize enough how terrible that really is. I've been slowly migrating to FreeBSD and Linux more and more for all my ``desktop'' work. They do a good job of being compatible with each other. However, my H/PC, as well as Outlook itself (which can import iCal/vCard but can't export them), hold the data I've trusted them with very close and don't let it go.
CE just bothers me. Its interface is unintuitive for doing what I expect a handheld or palm unit to do first and foremost -- calendaring and contacts. I'm getting a Visor as soon as I can. (Ironically enough, where I used to work, an engineer recently sold his Nino after having offered it for several months. But another tech who has a Palm III just mentions in passing he might be upgrading to a newer Palm and there are already three people lined up to buy it.)
Re:GUIs are killing good CLI and keyboard shortcut
on
Interface Zen
·
· Score: 2
Everytime the machine reboots, I have to go up to the keyboard and type "Alt-F, down, down, return, return" to get it to start taking pictures.
I know Windows at least used to come with a ``macro recorder'' of some kind that, it would seem, could automate this for you. But as I have been avoiding Windows innards religiously for some time I can't say for sure what the current state is...
As far as ergonomic nightmares go, I have to wonder what people think of the split keyboards. I put my hands on one in an office store once and immediately felt nauseous, but I wonder... if they didn't have the Windoze keys (among others), would they help or hinder in achieving keyboard zen?
Re:About mouse usage with keyboard
on
Interface Zen
·
· Score: 2
Now this interests me. I might just be crazy enough to try it. I suppose you've got to have a certain kind of mouse, though -- looking around my desk, I see a Dove-bar shaped Dell mouse... the ever-present warped M$ mouse... and what looks like a melted Dove-bar Compaq mouse.:-)
What kind of mouse did said person use? What size were his feet? (I wonder if my size 13's could move a mouse effectively at all...) I wonder if OSHA has any problem with it...
I was recently lucky. I got a hold of two boxes full of those wonderful fully mechanical (clickety-clickety-clack-clack, annoys my wife to no end) IBM keyboards with PS/2 plugs on them (I think they were used with terminals of some kind...?)
It's almost worth buying a bunch of AT-to-PS/2 adapters to use them on all my systems.:-) In any event, I find myself using my slow, old laptop quite a bit now -- even at home! -- because I can plug one of those keyboards into it, whereas I can't plug one into my HP 720.
Why not clone it? Admittedly, my first experience with UNIX workstations were with HP-UX (first running VUE, then CDE), but I found CDE to be nice, clean, and very usable.
I think it's a great idea to continue to create new working environments. As soon as the/. effect dies down I'm grabbing a copy.
One good reason data should be encrypted first, then compressed later (no-one seems to be mentioning it) is that compressed data generally has some sort of header that could be used to speed up the cracking process.
Slashdot Mirror
(I know you probably already know this, but others may not.)
Certificates are required because you need to know that the other end of the connection is who they say they are. Without that assurance, you open yourself up to a man-in-the-middle attack:
Alice is using SSL to talk to secure.bob.com. Eve wants to see what Alice and secure.bob.com are talking about.
Eve positions herself between Alice and secure.bob.com. She creates two public/private key pairs. She sends one of those public keys to Alice, posing as secure.bob.com. and the other to secure.bob.com, posing as Alice.
As Alice sends data to secure.bob.com, Eve decrypts it with her key and re-encrypts it with secure.bob.com's real public key. The same happens in the other direction.
This can't happen with certificates because secure.bob.com's public key is authenticated with the certificate. (Admittedly, Alice doesn't have a cert in most SSL transactions, but most people settle for the end that they feel needs to be most trustworthy -- the server -- to have the cert.)
Now keep in mind that most browsers are designed to keep the large portion of the Internet-using public (who are stupid) from hurting themselves. Hence the need for certificates, because there is no way you are going to get Grandma to understand man-in-the-middle attacks -- and if you tell her about them, she most certainly will not trust SSL in general.
That said, the SSL patches to lynx don't require certs. :-)
Nice thought, but there are two central problems:
AlterNIC tried this with DNS, and all it required was the cooperation of folks who ran DNS servers all over the world (a relatively small group, actually.) Didn't work.
I definitely won't take the odds on anyone being able to convince the Internet-using public (most of which is stupid, frankly) to install new certs in their browsers. Also, forget about getting them preinstalled in the browsers -- M$ is buddy-buddy with Verisign, and without IE support, no one will use our CA.
If sites are all directing folks to download new certs (I know this will happen anyway with the root rollovers, but bear with me), we will be training folks to accept any cert that they stumble across. Since anyone can create a cert, this could open up unsuspecting users to thinking a connection is ``secure'' when there is no guarantee (even the slight guarantee given by the current CAs) that the other end is who they say they are.
I would say, at best, that if this goes through, SSL should be considered proprietary and dead, and should be shunned by those of us who think computing should be open. It's quite a shame.
From inetd.conf on my OpenBSD 2.6 laptop (recently installed, not yet tweaked):
#telnet stream tcp nowait root ...
Your other points, however, are well taken. Most open source OSen can be made as secure or as insecure as the admin is capable of. In the case of OpenBSD, it simply takes less effort since the emphasis is on security, whereas other OSen seem to be focused on ``gee whiz, look what I can do'' out of the box.
This is a classic example of ``security by obscurity'', and it's what Microsoft relies on. I would say that the problem would have been found eventually. If you follow BUGTRAQ at all you'll notice that there are people finding buffer overflows in code they don't have the source to simply by throwing shellcode into fields that look like they have a fixed length. If it makes it crash, they've found a potential exploit. (Note to security gurus: yes, I know this is terribly simplistic; but it makes my point.)
And to RSA as well. It's amazing to me that in the CERT advisory, they grant permission to have this fix be made, but don't grant permission for any further fixes to be made, should they become necessary. I can see if, in their original onerous license, they might not have added that clause just because they weren't thinking about it. But come on, RSA! Wake up!
My personal feeling is that they put out the code ``for the benefit of academia'', to train a horde of students to bow down at the RSA throne -- and then when those students get out in the Real World(TM), they love RSA the algorithm, but need to shell out big bucks to use a better RSA implementation because -REF just plain sucks. It would not surprise me if this were intentional.
Someone on BUGTRAQ floated that the RSAREF buffer overflow might be used in an AIM-style ``detection'' fashion. (Remember the AIM buffer overflow that was used to see if the client on the other end was a ``genuine'' AIM client or not?)
As most know, if you're in the US, RSAREF is the be-all and end-all of what you can use -- and only then, noncommercially. If you want to use RSA without RSAREF, you have to buy software from someone who pays RSA licensing fees. (On a side note, it's probably worthless to see if you can get a personal license from RSA to use OpenSSL or some other toolkit, even if you have money. I floated this question on the OpenBSD list, since OpenBSD includes OpenSSL, and it seems it's been tried -- and RSA ignored the request.)
In any event, RSA could theoretically use the RSAREF vulnerability to scan US hosts for compliance with the RSAREF mandate. If the buffer overflow was there, and they were a commercial entity, the red alert klaxon would sound and the lawyers would be summoned. Not a pretty picture.
The way to combat a potential scenario like this would be to get the news out as fast as possible that you can patch RSAREF (RSA graciously allowed us in the CERT advisory to patch it, gee how nice of them) and should ASAP.
I think the real problem with searching really isn't that the Internet is growing too large. The central problem with it being too hard to find information is due to the unfortunately ever-changing nature of HTML. (Yes, I know there are much better solutions out there -- I work with some of them on a daily basis. However, we seem to presently be stuck with HTML and its variants.)
It's a self-feeding monster, whose typical cycle goes as follows: SearchEngineInc (a division of ConHugeCo) creates a new technology that really impresses people with its ability to find what they want more quickly. (Right now SearchEngineInc is probably Google, at least in my view.)
Once the new technology takes root, content authors (well, maybe not the authors so much as their PHBs) note that SearchEngineInc doesn't bring their business (which sells soybean derivatives) to the top of the search list (when people type ``food'' into the search engine). Said PHBs make the techies work around this ``problem'', and all of a sudden SearchEngineInc's technology isn't so great anymore because the HTML landscape it maps has changed.
A similar situation occurs when PHBs think their site doesn't ``look'' quite as good as others. (Insert my usual rant about content vs. presentation here.) Whether via a hideous HTML-abusing web authoring program, or via all sorts of hacks that God never intended to appear in anything resembling SGML, the HTML landscape is changed there as well, and SearchEngineInc's product becomes less effective.
What's the solution to this? I'm not quite sure. Obviously there are better technologies out there that are at least immune to PHBs' sense of ``aesthetics'' but I would wager few of them are immune from hackery. I'd say that search engine authors are doomed for all time to stay just one step ahead of the web wranglers. At least it assures them that their market segment won't go away any time soon. :-)
This may be way off-topic but I had to at least respond to the last part.
``Suffer'' was perhaps the wrong choice of word. I do have to agree with you here. However, in this case it could be construed as suffering because the mundanity of walking from place to place is theoretically causing me to get taken in by mall security.
In addition, I'd like sometimes just to be able to do something simple without being distracted; after all, I do have to do silly things like move from place to place or my taxes sometimes.
A system like this is probably worth far less than the time invested in creating it. Yeah, sure, right now they can't fool it. But give them credit -- while your common criminal's pretty stupid, thieves are thieves because they are good at what they do. They'll relearn how to sneak and new ones will learn as they enter the ``trade''.
In the meantime, I imagine I'll be setting off lots of alarms. (Poor George, his donuts will go stale.) I suffer from ADD and it's not uncommon that I'll be striding purposefully somewhere one moment and forget what I was doing the next. That's got to look an awful lot like suspicious behavior to a computer.
Very true. Let's not also forget to look at just what ECMA has done for JavaScript compatibility. Very little. I see at least three different implementations out there, probably a heck of a lot more. All need to be ``written to''. Sigh.
Never crossed my mind, honestly. But I can say with certaincy that said compiled code would crash on Sun JVMs as well as others, rather defeating the purpose in the first place. Regardless who was at fault, I could accomplish the following:
Compile with M$ compiler, crash on Sun and other JVMs but not M$
Compile with Sun compiler or guavac (the only other options available at the time), run on M$ JVM, Sun JVM, just about any other JVM you can name...
Finger-pointing aside, which would you choose if you had a job to get done?
I used VJ++ a couple years ago (versions 1.1 and 6, I think, were the versions I tried; the former downloaded from MS's site) because I had become familiar with using the MS dev tools. However, I had to turn around and recompile all my code with Sun's compiler because the code generated by the MS compiler would crash non-MS JVM's. This was simple code, too -- all JDK1.0-compliant and pure. Didn't even try to detect platforms or anything.
In any event, I'm glad to see J++ starting to fade into obscurity. It really wasn't a very useful product.
On the H/PC, go to your desktop sometime, hold down Alt, and tap one of the icons. That's your ``right tap''. Anyway, the thrust of that point was originally that the reason I dislike CE is because they are trying to fit a desktop metaphor into a handheld or palm unit, and I don't think it makes sense. Tom Christiansen's recent article on interface zen explains it better than I can.
And I beg to differ that free != good. In the world of development tools, the freer they are, the better -- because you can count on more varied applications being available as well as lots of apps that will mimic the freeness of the development tools and will be able to be improved on by many people. CE seems to, probably because the devel tools are so expensive, encourage locking up of apps and code.
Anyway, I can see we're not going to reach an agreement on this one. :-)
Then I guess you don't have a problem with ``Pocket Outlook''. I do, because I am moving away from Microsoft Outlook. I think it is an inferior solution, and it ties me unnecessarily to the Windows platform. If, someday, your company decided that Outlook/Exchange was no longer right for its needs, what would your CE device do then?
How childish of you. You speak of something you know nothing about as if it does not exist and assumes it proves me wrong. Pick up an H/PC sometime and check it out.
You make a lot of points about web synchronization here. I don't have a problem with those; they work equally well regardless of platform, primarily because Microsoft doesn't have their hands in them.
Finally, correct me if I'm wrong (I regret I have not investigated this as thoroughly as I should), but isn't Palm's official development platform already free? Seems like it's better if the platform owner supports your efforts from the beginning. Helps insure you don't get left out in the cold when xxx new feature comes along.
Question for you. Ignore totally how anyone feels about just plain cybersquatting and reselling of domain names. That's not the issue here.
You are starting an Internet business. Does it not stand to reason that when you start said business, you will register the domain before you ``go into business'' proper, and will have an ``under construction'' page?
Just something to think about... there may very well be legitimacy behind those pages. I might also add that it is still possible (last time I checked) to run a domain without even having a site attached to it.
Hmm. I have a domain that actually some folks might be interested in. I grabbed it from a lame delegator some time ago because I was at the time setting up an IRC net. We were popular for about, oh, 3 months... then we got to the point where we had more servers than people. :-)
Wonder how much I could get for nameless.net? I'll trade someone it for a new Visor Deluxe :-)
Congratulations, you have found the device that you want for your needs.
I had a handheld CE device for some time. Its touchscreen recently broke so it's only usable with the keyboard. But even before then, I had the following beefs with it:
Its scheduling app was not something that made sense on a handheld or palm-based device. It felt just like a copy of Outlook (which ties in with point #3, btw.)
The traditional Windows GUI metaphors just don't work on handheld devices. I mean, come on, we're going to simulate right-clicking by holding down Alt and tapping?
It only syncs with Microsoft products. I can't emphasize enough how terrible that really is. I've been slowly migrating to FreeBSD and Linux more and more for all my ``desktop'' work. They do a good job of being compatible with each other. However, my H/PC, as well as Outlook itself (which can import iCal/vCard but can't export them), hold the data I've trusted them with very close and don't let it go.
CE just bothers me. Its interface is unintuitive for doing what I expect a handheld or palm unit to do first and foremost -- calendaring and contacts. I'm getting a Visor as soon as I can. (Ironically enough, where I used to work, an engineer recently sold his Nino after having offered it for several months. But another tech who has a Palm III just mentions in passing he might be upgrading to a newer Palm and there are already three people lined up to buy it.)
``Moon Penguin Power, Make-Up!''
(sorry, couldn't resist...)
I know Windows at least used to come with a ``macro recorder'' of some kind that, it would seem, could automate this for you. But as I have been avoiding Windows innards religiously for some time I can't say for sure what the current state is...
As far as ergonomic nightmares go, I have to wonder what people think of the split keyboards. I put my hands on one in an office store once and immediately felt nauseous, but I wonder... if they didn't have the Windoze keys (among others), would they help or hinder in achieving keyboard zen?
Now this interests me. I might just be crazy enough to try it. I suppose you've got to have a certain kind of mouse, though -- looking around my desk, I see a Dove-bar shaped Dell mouse... the ever-present warped M$ mouse... and what looks like a melted Dove-bar Compaq mouse. :-)
What kind of mouse did said person use? What size were his feet? (I wonder if my size 13's could move a mouse effectively at all...) I wonder if OSHA has any problem with it...
I was recently lucky. I got a hold of two boxes full of those wonderful fully mechanical (clickety-clickety-clack-clack, annoys my wife to no end) IBM keyboards with PS/2 plugs on them (I think they were used with terminals of some kind...?)
It's almost worth buying a bunch of AT-to-PS/2 adapters to use them on all my systems. :-) In any event, I find myself using my slow, old laptop quite a bit now -- even at home! -- because I can plug one of those keyboards into it, whereas I can't plug one into my HP 720.
Goodbye mushy keyboards!
Why not clone it? Admittedly, my first experience with UNIX workstations were with HP-UX (first running VUE, then CDE), but I found CDE to be nice, clean, and very usable.
I think it's a great idea to continue to create new working environments. As soon as the /. effect dies down I'm grabbing a copy.
One good reason data should be encrypted first, then compressed later (no-one seems to be mentioning it) is that compressed data generally has some sort of header that could be used to speed up the cracking process.
Hmm, wonder if some team outside the US could implement a SSL/TLS via DH and merge it into Mozilla...
Bite this, Microsoft -- "Sorry, you can't visit this secure site unless you use the lizard." Hehehehe...
Sorry if this isn't up to my usual standards, but I'm very pissed off at IE right now. :-)