In USB 1.x a low speed device (1.5mbps) occupies the entire bus and takes time from standard speed (12mbps) devices.
In USB 2.0, though. the hubs have buffers and do active rate matching. A standard speed device will NOT bring down the speed of the bus and will not get in the way of high speed (480mbps) transfers. The silicon space to do this is quite negligible these days.
Intel has supported 1394 for years - it was going to be the successor to IDE. In USB conferences prior to 1998 they kept talking about how USB and 1394 are complementary - 1394 will never be cheap enough for a mouse. If something made them change their mind I believe they have a real reason.
Most of Dave's comments are relevant to RF communication, not to optical.
Capacity is proportional to the logarithm of (1+signal to noise ratio). A small but significant difference. The result is that for a given power budget it is always better to use as much bandwidth as possible unless you are limited by arbitrary constraints such as the FCC's dumb frequency management practices.
There's no need to go to higher optical frequencies to increase capacity. The carrier frequency of a 1.3 micron infrared laser is 230 terahertz. It's easy to see that a few hundreds of megabits per seconds barely scratch the theoretical capacity.
You've got so much bandwidth in optical that more than one bit per symbol makes absolutely no sense. In fact, you want LESS than one information bit per symbol by using forward error correction codes.
The right frequency to choose is in the atmospheric window wavelengths - those least absorbed by water vapor.
In fog conditions the cumulative attenuation per meter is so high that even a hundredfold increase in laser power will not make a significant increase in the effective range. You are stuck with a few hundreds of meters. Deal with it. AirFiber's architecture looks like the right way to do it. Even if you ignore the bird problem, with a relay every few hundreds of meters the end-to-end reliability drops exponentially with the number of hops the signal has to go through. A mesh architecture can cover long distances while still maintaining adequate availability.
Transmeta isn't really a "linux company". They are not like Red Hat or other companies that are centered around linux and need to score points with the community.
Linux is just one of the operatings systems they plan to run on their devices.
A browser SHOULD be a little more picky about poorly written HTML, otherwise it encourages it and forces every other browser to parse broken HTML in EXACTLY the same way. A standards compliant browser will be blamed for not displaying pages "correctly" when it's actually the broken HTML that is to blame.
I see that a lot of slashdotters here have already made up their mind that this project is evil/sucks/is never going to work/dumb. There are tons of reasons why any particular project may succeed or fail but the model behind this one actually looks like it might work.
The way I understand this there are two unrelated "payment" systems involved: the first is a reputation-based system with "Mojo" as its currency. It is designed to increase reliability and reduce the amount of junk on the system. People that have unreliable systems or post junk will have bad reputation and won't get much "Mojo". The other payment system is voluntary, it involves real money and it lets people compensate the producers of the original material, while the Mojo system will only let you pay other users of the system for the storage, CPU and bandwidth involved in distributing the data.
As far as I can see, its generally a good thing(tm), though they'd better get the authentication right, else it will become useless.
Some kind of authentication can be achieved using packets that are transmitted with a TTL of 255. If you get a packet with a TTL of 254 there is no way it could have been sent from a host further than one hop. Lots of routers need to be upgraded for itrace, but ALL routers decrease the Time-To-Live field. I wonder how this could be effectively extended to longer distances.
It takes a very superficial view to compare BlueTooth and 802.11. True, they both transmit bits wirelessly, but so do many other systems. It's like comparing Ethernet and USB - one is a network and the other is a bus.
If you look at the specs behind these standards you'll see that the part that deals with actually delivering the bits over the wireless link is quite small. The protocols, application and presentation layer are much bigger. They present a different set of services to the user. They also have a very different mindset and corporate culture begind them, like USB and 1394 - one is PC centric and the other is heavily influenced by the consumer electronics world.
I was just as skeptic as most of the posters here about how a tiny oval patch could possibly act as a shield against radiation. So I looked a little more deeply into it I am not so sure it's a total scam, there might actually be something there.
First of all, they don't claim to block radiation. It would be impossible for a one inch patch to block a signal with a wavelength of about 1ft. What this device claims to do is generate low frequency magnetic fields that somehow reduce the damage to biological systems. They have some research done on chicken embryos to back this up.
a portable handsfree kit that's actually COMFORTABLE. Most of the ones I've tried so far are horrible. A cordless BlueTooth handsfree kit will be even better. No, I am not worried about the BlueTooth RF - it's several orders of magnitude weaker than the signal the cellular phone is transmitting.
AFAIK, all fingerprint verifiers use a reduced set of extracted features for comparison. This is the first one I see that tries to claim it's a privacy feature - it's simply how it works. Give a marketroid a bunch of technical details and he's always find a way to present them as features.
Biometric systems should always assume that the fingerprint, iris scan, etc is not a secret and is known to the attacker. Your password can only be considered secret because you can change it.
To have any meaningful security a biometric system must have a trusted reader and a secure path from the reader to the verifier.
Two examples:
1. The verifier is inside the reader. Your private key is embedded into a tamper-resistant device and a fingerprint is required to perform a private key operation (signing, decryption).
2. The verifier is in a secure remote server, but communication between the reader and the verifier is cryptographically protected. The reader should sign the scan and also use a timestamp or challenge/response system to prevent replay attacks. Each reader would have a separate signing key so they can be revoked, if necessary. Even the best tamper resistance cannot be trusted with a global reader signing key that results in catastrophic failure if it is compromised.
Suggested protocol:
Before being used for the first time the readers are connected to the verification server for initialization. The server generates random keys and sends them to the readers. These keys cannot be read back from the reader, only overwritten.
For authentication, the client first asks the verification server for a challenge. It sends the challenge into the reader which calculates a hash of the biometric scan, reader signing key and the challenge. This hash is sent to the server along with the biometric scan for verification.
The reader key should be kept in battery backed static RAM rather than EEPROM. This makes it easier to self-destruct in case a tampering attempt is detected. To prevent the value from permanently affecting the memory cells via ion migration or similar phenomena it could be cycled continously.
The key database on the server is a single point of failure - but the server is probably the same resource you are trying to protect anyway. It would still be nice to make the key database less vulnerable by using asymmetric cryptography - a key pair is generated during initialization and only the public key is stored on the server.
The Sony fingerprint scanner (also featured on slashdot recently) appears to implement #1. Does anyone know of a system similar to #2?
At the same time, I do think that for a short time at least, this will lead to lax security in companies which do purchase these policies. Some of them will doubtless reason that simply because they have purchased this policy they have all the protection they need.
Just like your insurance company may require you to install an alarm system before they cover you for burglary this type of insurance will require you to be audited and then continously monitored by a company like Counterpane systems.
In Victor Koman's Kings Of The High Frontier an aging rocket tinkerer called "Ace" Roberts is building a rocket in his backyard. In this book, several different non-government attempts to reach space actually succeed, but Roberts isn't one of them.
It is available for download for $3.5 on pulpless.com. Recommended!.
Many people don't know the difference between.gov and.com. The domain name first.com is taken, but firstgov.com was free as a backup address for the clueless.
You may remember that whitehouse.com was taken by a porn site.
Ok, you find a dinosaur killer on a collision trajectory with the Earth. It will hit us in 18 months. What do you do now?
It looks like the only technology that could possibly pack enough energy to deflect an object with such momentum is a nuclear bomb. Isn't it ironic that the same technology that brought us the possibility of destroying life on planet Earth could also save it?
A few years ago I did a few back-of-the-envelope calculations to see what would be required to deflect an object a few kilometers in size. Naturally, the delta-V you need to deliver depends on how early you can catch it. If it's still very far you need just a little nudge to ensure it won't collide. It also depends on what margin for error you want to tolerate i.e. how far from Earth do you want it to pass.
It looks like some of the bigger H-bombs have the energy to do it. The problem is how to convert it efficiently to kinetic energy. If you blow up a nuclear bomb in space all you get is a fantastic flash. The relatively small mass of the device itself evaporates and disperses into the vacuum in a matter of milliseconds. You need mass to convert this energy into motion. Using the mass of the asteroid itself is dangerous - if you blow up your bomb too close to the object it could break into many fragments with different orbits. Many of them could still hit the Earth. Splitting it neatly in half Armageddon-style is not very likely:-).
So you need to bring your own reaction mass. The bomb will be accompanied by some big tanks of water. I don't remember the calculations, but you need quite a lot of reaction mass. It appeared to be more than what current launch vehicles can handle.
I'm curious though, why should we believe that scientists/astronomers can track _every_ asteroid in a near-earth orbit, when they can't even track _every_ piece of space debris in orbit around earth now?
Objects in Earth orbit that could cause damage to a satellite or space station can be as small as a speck of dust. Asteroids that could cause serious damage in case they hit the earth are dozens of meters or more in size. It's not easy to track them becasuse there is a lot of sky to cover, but it is feasible.
The first weakness is that it is easy to poison the repositories with pads with false names. The pad names should be made self-verifying by using a hash of the entire pad as a name (e.g. md5).
The second problem is that the keyspace is too small. The obvious solution would be to encrypt the data. This way the "URL" for the information would be the names of pads to XOR plus the encryption passphrase. The encryption format should have no headers and be indistinguishable from random data without the passphrase. A good candidate would be CipherSaber.
The system's biggest advantage is that it ridiculously simple and uses existing tools. This makes it very transparent.
This algorithm is used for efficient decoding of convolutional error correction codes and for untangling signals corrupted by multipath dispersion. It has been developed by Andrew J. Viterbi (founder of Qualcomm) while at NASA for receiving the ultra-faint signals transmitted by deep space probes.
Technically speaking, it is an efficient implementation of the Maximum Likelyhood Sequence (MLS) detector, just like the FFT is an efficient implementation of the discrete fourier transform.
RCPT TO: is the most reliable way to verify the existence of an account. It doesn't always work, but there is a method to verify if it does.
(connect to port 25) 220 mail.example.com ready. HELO mydomain.com 250 pleased to meet you MAIL FROM: me@mydomain.com 250 me@mydomain.com... Sender ok RCPT TO: user@example.com 250 user@example.com... Recipient ok RCPT TO: PddVQ9XB87bq8VH6YfFQ@example.com 550 PddVQ9XB87bq8VH6YfFQ@example.com... User unknown QUIT 221 mail.example.com closing connection
Notes: 1. Always be polite and say HELO. Some servers are rude if you don't. 2. Use a valid domain for the MAIL FROM: line - some servers will look it up. 3. The second RCPT TO: is very important - it lets you find out whether the server blindly accepts all mail to its domain or actually verifies the user.
is that the numbers are really random - they are simply channelsquatting. The HF spectrum is an expensive resource because it's quite narrow and it propagates to such long distances. If you want to ensure you have your channel when you really need it just keep it busy. It's not that different than cybersquatting except that it's harder to argue with a foreign government and a few kilowatts of RF power.
POP3 over SSH with port forwarding has some timing problems - you must to wait until the SSH connection is up before running fetchmail. Consider this alternative:
Create the script sshtunnel:
#!/bin/sh ssh $1 "nc 127.0.0.1 $2"
And in your.fetchmailrc use this script with the plugin option: poll host plugin sshtunnel user name password pass
Instead of opening a TCP connection fetchmail will run the script passing it the hostname and port number as arguments and use its standard input and output to talk to the POP server. No timing issues - fetchmail will wait patiently while you type your password or passphrase to ssh.
It requires netcat to be installed on the target machine.
Why encrypt only incoming mail? My outgoing mail is also delivered over ssh (courtesy of PostFix)
Slashdot Mirror
In USB 1.x a low speed device (1.5mbps) occupies the entire bus and takes time from standard speed (12mbps) devices.
In USB 2.0, though. the hubs have buffers and do active rate matching. A standard speed device will NOT bring down the speed of the bus and will not get in the way of high speed (480mbps) transfers. The silicon space to do this is quite negligible these days.
Intel has supported 1394 for years - it was going to be the successor to IDE. In USB conferences prior to 1998 they kept talking about how USB and 1394 are complementary - 1394 will never be cheap enough for a mouse. If something made them change their mind I believe they have a real reason.
----
This wavelength is around the peak of the first Atmospheric window. It's also cheap because it's the wavelength used by CD readers.
----
Most of Dave's comments are relevant to RF communication, not to optical.
Capacity is proportional to the logarithm of (1+signal to noise ratio). A small but significant difference. The result is that for a given power budget it is always better to use as much bandwidth as possible unless you are limited by arbitrary constraints such as the FCC's dumb frequency management practices.
There's no need to go to higher optical frequencies to increase capacity. The carrier frequency of a 1.3 micron infrared laser is 230 terahertz. It's easy to see that a few hundreds of megabits per seconds barely scratch the theoretical capacity.
You've got so much bandwidth in optical that more than one bit per symbol makes absolutely no sense. In fact, you want LESS than one information bit per symbol by using forward error correction codes.
The right frequency to choose is in the atmospheric window wavelengths - those least absorbed by water vapor.
In fog conditions the cumulative attenuation per meter is so high that even a hundredfold increase in laser power will not make a significant increase in the effective range. You are stuck with a few hundreds of meters. Deal with it. AirFiber's architecture looks like the right way to do it. Even if you ignore the bird problem, with a relay every few hundreds of meters the end-to-end reliability drops exponentially with the number of hops the signal has to go through. A mesh architecture can cover long distances while still maintaining adequate availability.
----
''In this one instance you surpassed more than eight layers of management . . .''
Don't you find it frightening to think of an organization that has so many layers of management?
----
Transmeta isn't really a "linux company". They are not like Red Hat or other companies that are centered around linux and need to score points with the community.
:-)
Linux is just one of the operatings systems they plan to run on their devices.
There's also that Linus guy, of course...
----
A browser SHOULD be a little more picky about poorly written HTML, otherwise it encourages it and forces every other browser to parse broken HTML in EXACTLY the same way. A standards compliant browser will be blamed for not displaying pages "correctly" when it's actually the broken HTML that is to blame.
----
I see that a lot of slashdotters here have already made up their mind that this project is evil/sucks/is never going to work/dumb. There are tons of reasons why any particular project may succeed or fail but the model behind this one actually looks like it might work.
The way I understand this there are two unrelated "payment" systems involved: the first is a reputation-based system with "Mojo" as its currency. It is designed to increase reliability and reduce the amount of junk on the system. People that have unreliable systems or post junk will have bad reputation and won't get much "Mojo". The other payment system is voluntary, it involves real money and it lets people compensate the producers of the original material, while the Mojo system will only let you pay other users of the system for the storage, CPU and bandwidth involved in distributing the data.
----
As far as I can see, its generally a good thing(tm), though they'd better get the authentication right, else it will become useless.
Some kind of authentication can be achieved using packets that are transmitted with a TTL of 255. If you get a packet with a TTL of 254 there is no way it could have been sent from a host further than one hop. Lots of routers need to be upgraded for itrace, but ALL routers decrease the Time-To-Live field. I wonder how this could be effectively extended to longer distances.
----
It takes a very superficial view to compare BlueTooth and 802.11. True, they both transmit bits wirelessly, but so do many other systems. It's like comparing Ethernet and USB - one is a network and the other is a bus.
If you look at the specs behind these standards you'll see that the part that deals with actually delivering the bits over the wireless link is quite small. The protocols, application and presentation layer are much bigger. They present a different set of services to the user. They also have a very different mindset and corporate culture begind them, like USB and 1394 - one is PC centric and the other is heavily influenced by the consumer electronics world.
----
I was just as skeptic as most of the posters here about how a tiny oval patch could possibly act as a shield against radiation. So I looked a little more deeply into it I am not so sure it's a total scam, there might actually be something there.
First of all, they don't claim to block radiation. It would be impossible for a one inch patch to block a signal with a wavelength of about 1ft. What this device claims to do is generate low frequency magnetic fields that somehow reduce the damage to biological systems. They have some research done on chicken embryos to back this up.
Proceedings of first World Congress on the Bioeffects of Electricity and Magnetism. (note that it's sponsored by Tecno-AO)
Tecno-AO "science"
See also here and here.
----
a portable handsfree kit that's actually COMFORTABLE. Most of the ones I've tried so far are horrible. A cordless BlueTooth handsfree kit will be even better. No, I am not worried about the BlueTooth RF - it's several orders of magnitude weaker than the signal the cellular phone is transmitting.
----
AFAIK, all fingerprint verifiers use a reduced set of extracted features for comparison. This is the first one I see that tries to claim it's a privacy feature - it's simply how it works. Give a marketroid a bunch of technical details and he's always find a way to present them as features.
Biometric systems should always assume that the fingerprint, iris scan, etc is not a secret and is known to the attacker. Your password can only be considered secret because you can change it.
To have any meaningful security a biometric system must have a trusted reader and a secure path from the reader to the verifier.
Two examples:
1. The verifier is inside the reader. Your private key is embedded into a tamper-resistant device and a fingerprint is required to perform a private key operation (signing, decryption).
2. The verifier is in a secure remote server, but communication between the reader and the verifier is cryptographically protected. The reader should sign the scan and also use a timestamp or challenge/response system to prevent replay attacks. Each reader would have a separate signing key so they can be revoked, if necessary. Even the best tamper resistance cannot be trusted with a global reader signing key that results in catastrophic failure if it is compromised.
Suggested protocol:
Before being used for the first time the readers are connected to the verification server for initialization. The server generates random keys and sends them to the readers. These keys cannot be read back from the reader, only overwritten.
For authentication, the client first asks the verification server for a challenge. It sends the challenge into the reader which calculates a hash of the biometric scan, reader signing key and the challenge. This hash is sent to the server along with the biometric scan for verification.
The reader key should be kept in battery backed static RAM rather than EEPROM. This makes it easier to self-destruct in case a tampering attempt is detected. To prevent the value from permanently affecting the memory cells via ion migration or similar phenomena it could be cycled continously.
The key database on the server is a single point of failure - but the server is probably the same resource you are trying to protect anyway. It would still be nice to make the key database less vulnerable by using asymmetric cryptography - a key pair is generated during initialization and only the public key is stored on the server.
The Sony fingerprint scanner (also featured on slashdot recently) appears to implement #1. Does anyone know of a system similar to #2?
----
At the same time, I do think that for a short time at least, this will lead to lax security in companies which do purchase these policies. Some of them will doubtless reason that simply because they have purchased this policy they have all the protection they need.
Just like your insurance company may require you to install an alarm system before they cover you for burglary this type of insurance will require you to be audited and then continously monitored by a company like Counterpane systems.
----
In Victor Koman's Kings Of The High Frontier an aging rocket tinkerer called "Ace" Roberts is building a rocket in his backyard. In this book, several different non-government attempts to reach space actually succeed, but Roberts isn't one of them.
It is available for download for $3.5 on pulpless.com. Recommended!.
----
Many people don't know the difference between .gov and .com. The domain name first.com is taken, but firstgov.com was free as a backup address for the clueless.
You may remember that whitehouse.com was taken by a porn site.
----
Ok, you find a dinosaur killer on a collision trajectory with the Earth. It will hit us in 18 months. What do you do now?
:-).
It looks like the only technology that could possibly pack enough energy to deflect an object with such momentum is a nuclear bomb. Isn't it ironic that the same technology that brought us the possibility of destroying life on planet Earth could also save it?
A few years ago I did a few back-of-the-envelope calculations to see what would be required to deflect an object a few kilometers in size. Naturally, the delta-V you need to deliver depends on how early you can catch it. If it's still very far you need just a little nudge to ensure it won't collide. It also depends on what margin for error you want to tolerate i.e. how far from Earth do you want it to pass.
It looks like some of the bigger H-bombs have the energy to do it. The problem is how to convert it efficiently to kinetic energy. If you blow up a nuclear bomb in space all you get is a fantastic flash. The relatively small mass of the device itself evaporates and disperses into the vacuum in a matter of milliseconds. You need mass to convert this energy into motion. Using the mass of the asteroid itself is dangerous - if you blow up your bomb too close to the object it could break into many fragments with different orbits. Many of them could still hit the Earth. Splitting it neatly in half Armageddon-style is not very likely
So you need to bring your own reaction mass. The bomb will be accompanied by some big tanks of water. I don't remember the calculations, but you need quite a lot of reaction mass. It appeared to be more than what current launch vehicles can handle.
Have a nice day.
----
I'm curious though, why should we believe that scientists/astronomers can track _every_ asteroid in a near-earth orbit, when they can't even track _every_ piece of space debris in orbit around earth now?
Objects in Earth orbit that could cause damage to a satellite or space station can be as small as a speck of dust. Asteroids that could cause serious damage in case they hit the earth are dozens of meters or more in size. It's not easy to track them becasuse there is a lot of sky to cover, but it is feasible.
----
The first weakness is that it is easy to poison the repositories with pads with false names. The pad names should be made self-verifying by using a hash of the entire pad as a name (e.g. md5).
The second problem is that the keyspace is too small. The obvious solution would be to encrypt the data. This way the "URL" for the information would be the names of pads to XOR plus the encryption passphrase. The encryption format should have no headers and be indistinguishable from random data without the passphrase. A good candidate would be CipherSaber.
The system's biggest advantage is that it ridiculously simple and uses existing tools. This makes it very transparent.
----
This algorithm is used for efficient decoding of convolutional error correction codes and for untangling signals corrupted by multipath dispersion. It has been developed by Andrew J. Viterbi (founder of Qualcomm) while at NASA for receiving the ultra-faint signals transmitted by deep space probes.
An introduction to the Viterbi Algorithm
Technically speaking, it is an efficient implementation of the Maximum Likelyhood Sequence (MLS) detector, just like the FFT is an efficient implementation of the discrete fourier transform.
----
The OS company shall simply be called Windows and the applications division shall retain the name Microsoft.
----
Why are there no pictures of Sealand on either the HavenCo or Sealand sites?
Are you worried that people might be disappointed if they actually see what it's all about?
----
RCPT TO: is the most reliable way to verify the existence of an account. It
doesn't always work, but there is a method to verify if it does.
(connect to port 25)
220 mail.example.com ready.
HELO mydomain.com
250 pleased to meet you
MAIL FROM: me@mydomain.com
250 me@mydomain.com... Sender ok
RCPT TO: user@example.com
250 user@example.com... Recipient ok
RCPT TO: PddVQ9XB87bq8VH6YfFQ@example.com
550 PddVQ9XB87bq8VH6YfFQ@example.com... User unknown
QUIT
221 mail.example.com closing connection
Notes:
1. Always be polite and say HELO. Some servers are rude if you don't.
2. Use a valid domain for the MAIL FROM: line - some servers will look it up.
3. The second RCPT TO: is very important - it lets you find out whether the
server blindly accepts all mail to its domain or actually verifies the user.
----
is that the numbers are really random - they are simply channelsquatting. The HF spectrum is an expensive resource because it's quite narrow and it propagates to such long distances. If you want to ensure you have your channel when you really need it just keep it busy. It's not that different than cybersquatting except that it's harder to argue with a foreign government and a few kilowatts of RF power.
----
From ssh-keygen man page: (my emphasis)
:-)
-x This option will read a private OpenSSH DSA format file and print a SSH2-compatible public key to stdout.
-X This option will read a SSH2-compatible public key file and print an OpenSSH DSA compatible public key to stdout.
Am I the only one who finds this a little strange?
Maybe that's why they call them asymmetric ciphers
----
POP3 over SSH with port forwarding has some timing problems - you must to wait until the SSH connection is up before running fetchmail. Consider this alternative:
.fetchmailrc use this script with the plugin option:
Create the script sshtunnel:
#!/bin/sh
ssh $1 "nc 127.0.0.1 $2"
And in your
poll host plugin sshtunnel user name password pass
Instead of opening a TCP connection fetchmail will run the script passing it the hostname and port number as arguments and use its standard input and output to talk to the POP server. No timing issues - fetchmail will wait patiently while you type your password or passphrase to ssh.
It requires netcat to be installed on the target machine.
Why encrypt only incoming mail? My outgoing mail is also delivered over ssh (courtesy of PostFix)
----