This assumes that your users are savvy enough to understand that SSL does not prove the identity of the third party. For example, it would be possible to make an SSL gateway which proxies the traffic between both endpoints. This would have the effect of producing an SSL certificate error on the client(because they're not signed by a trusted CA), but with the average Joe just getting an error(to which they would presumably click accept/allow) and seeing that:
They would probably enter their info in it anyway. This approach can also work anywhere public computers are used, with the added bonus that the computer could have the fake root CA approved, thus presenting no SSL certificate error at all.
There are ongoing research projects for mutual authentication(ie. you know that you're sending your data to a non-fake website and the bank knows that they're getting data from you and not a third party pretending to be you), such as ones involving Elliptic Curve Cryptography(ECC) over HTTP.
It's a bit annoying because activation can sometime misfire or require more than a couple clicks of the mouse.
For example, my installation of Vista got hosed during the holidays and, after reinstalling it, it required activation. However, the activation wizard mentioned that "This key is already in use", so I had to call their activation center to validate with a human being that "my copy of Vista died and I'm reinstalling it". It's a waste of five minutes I could have avoided.
I wonder how much it costs Microsoft to process those phone activation requests.
Project Celeste is basically what the OP is talking about. It's a distributed filesystem with automatic replication, handles rogue nodes via voting and also exports the "filesystem" as CIFS. It's essentially a distributed object store, which can be used to implement a filesystem on top of it. I saw a demo of it last year and I was pretty surprised, it seems to work quite well for a research project.
The objection that I have to this program was that it was an experiment, a costly one, with no guarantees of future success.
The fact that there were no guarantees of success is what makes research interesting and worth it. If you're only researching things that you're certain will lead somewhere, only incremental improvements are possible. On the other hand, fundamental research has no guarantee of finding something useful, but can lead to major breakthroughs(or not).
This might be a cultural thing. In regions where mass transit is more frequently employed, such as Japan, people almost exclusively use text messages. Since the US is more car-centric, it makes more sense to talk while driving instead of trying to type a text message.
Except that screens are a crappy reading medium. Face it, real physical books are, at least for now, way better for more in-depth research than just Ctrl-F'ing through a webpage, as said earlier.
You can annotate books and put stickies in them to find the exact paragraph you wanted. With the web, all you get is a crappy bookmark that stores one URL and can't store, say, the highlighted paragraph you're currently reading. Can't have a good display that just feels right for reading. No need to worry about battery life.
I do agree that keyword search is a bit limited with books, though. Full text indexing would be neat.
Have you tried the speech recognition in Windows Vista? I haven't tried it with the screenreader at the same time, but it seemed to work semi-decently and I'm curious as to how people with actual disabilities think of it. I was quite surprised by how well it seemed to be integrated with the OS-bundled applications.
Give it a try folks, and forget about carpal tunnel forever...
Beware of straining your voice though. Also, while speech recognition is actually pretty good for natural text, it is pretty awful for programming due to the tediousness of entering punctuation and variable names, which aren't dictionary words most of the time.
Putting a bunch of Nigerian-language characters onto a keyboard doesn't qualify as an "invention"; it's exactly what's been done for hundreds of other languages around the world since before Nigerian-language characters were in the Unicode standard even (which, I might point out, that same generous West put in after working hard to create those standards in the first place and then giving them to poor countries like Nigeria for free).
Their keyboards don't really seem that inventive once you give them a look. They seem to use a shift^2/Ng key which probably does the exact same thing as AltGr, which is present on a lot of multilingual keyboards, although not at the same location.
No. It requires signed kernel drivers. Drivers for all bus-attached devices should run in userspace on Vista(so your USB printer can't crash the whole system but your video driver might).
The gOS distribution [...] is based on the just-released Ubuntu 7.10 ("Gutsy Gibbon") distro, but with the lightweight Enlightenment window manager instead of heavy Gnome/KDE desktops.
Enlightenment is lightweight nowadays? Is it because Enlightenment improved or because Gnome/KDE got bigger? I remember it being quite unstable/slow a decade ago, but how have things changed in E?
There is a difference. Usually, streaming is done over RTP or other similar protocols which do not offer guaranteed delivery but rather a best effort timely delivery.
If you're saving a RTP stream and your connection drops some packets, you'll have holes in your stream. Not so with a download over TCP.
Our team(SONIA) is working on autonomous underwater vehicles and we are using Linux with Java for the AI part. For communication with actuators, we use the CAN bus, which is fairly common in the industrial automation and automotive fields.
There are CAN bus adapters that plug into serial or USB ports and there is Linux support for these. We're using one from Vector.
As for hardware, we use the Kontron JREX SBC with JFlex I/O boards to add the I/O ports we need(firewire and serial, mostly). Of course, if you're not cramped for space, you might go with something a bit larger.
I hope this helps, feel free to ask more questions.
Slashdot Mirror
This assumes that your users are savvy enough to understand that SSL does not prove the identity of the third party. For example, it would be possible to make an SSL gateway which proxies the traffic between both endpoints. This would have the effect of producing an SSL certificate error on the client(because they're not signed by a trusted CA), but with the average Joe just getting an error(to which they would presumably click accept/allow) and seeing that:
They would probably enter their info in it anyway. This approach can also work anywhere public computers are used, with the added bonus that the computer could have the fake root CA approved, thus presenting no SSL certificate error at all.
There are ongoing research projects for mutual authentication(ie. you know that you're sending your data to a non-fake website and the bank knows that they're getting data from you and not a third party pretending to be you), such as ones involving Elliptic Curve Cryptography(ECC) over HTTP.
It's a bit annoying because activation can sometime misfire or require more than a couple clicks of the mouse. For example, my installation of Vista got hosed during the holidays and, after reinstalling it, it required activation. However, the activation wizard mentioned that "This key is already in use", so I had to call their activation center to validate with a human being that "my copy of Vista died and I'm reinstalling it". It's a waste of five minutes I could have avoided. I wonder how much it costs Microsoft to process those phone activation requests.
Sorry, here's a better link about Project Celeste.
Project Celeste is basically what the OP is talking about. It's a distributed filesystem with automatic replication, handles rogue nodes via voting and also exports the "filesystem" as CIFS. It's essentially a distributed object store, which can be used to implement a filesystem on top of it. I saw a demo of it last year and I was pretty surprised, it seems to work quite well for a research project.
CO2 is about 1.5 times heavier than air, so it will stay underground.
Clearly the best videogame console is the Infinium Labs Phantom. It even plays Duke Nukem Forever!
This might be a cultural thing. In regions where mass transit is more frequently employed, such as Japan, people almost exclusively use text messages. Since the US is more car-centric, it makes more sense to talk while driving instead of trying to type a text message.
Because it's what the market is ready to pay for. If nobody wanted to pay that much for SMS service, you can be sure they would lower its price.
Except that screens are a crappy reading medium. Face it, real physical books are, at least for now, way better for more in-depth research than just Ctrl-F'ing through a webpage, as said earlier.
You can annotate books and put stickies in them to find the exact paragraph you wanted. With the web, all you get is a crappy bookmark that stores one URL and can't store, say, the highlighted paragraph you're currently reading. Can't have a good display that just feels right for reading. No need to worry about battery life.
I do agree that keyword search is a bit limited with books, though. Full text indexing would be neat.
Have you tried the speech recognition in Windows Vista? I haven't tried it with the screenreader at the same time, but it seemed to work semi-decently and I'm curious as to how people with actual disabilities think of it. I was quite surprised by how well it seemed to be integrated with the OS-bundled applications.
Wow, now I know that the sky refreshes like a CRT now! :)
There is a difference. Usually, streaming is done over RTP or other similar protocols which do not offer guaranteed delivery but rather a best effort timely delivery.
If you're saving a RTP stream and your connection drops some packets, you'll have holes in your stream. Not so with a download over TCP.
Our team(SONIA) is working on autonomous underwater vehicles and we are using Linux with Java for the AI part. For communication with actuators, we use the CAN bus, which is fairly common in the industrial automation and automotive fields.
There are CAN bus adapters that plug into serial or USB ports and there is Linux support for these. We're using one from Vector.
As for hardware, we use the Kontron JREX SBC with JFlex I/O boards to add the I/O ports we need(firewire and serial, mostly). Of course, if you're not cramped for space, you might go with something a bit larger.
I hope this helps, feel free to ask more questions.