I always have trouble how to moderate a comment line this. Troll? Maybe. Flamebait? It invites flames, but... Completely clueless? That fits perfectly, but isn't a moderation option!
This was bound to happen one day. In the 'old days', the only way to spread your work to all your peers was through the estabjournals. The publishers of those journals could ask a premium price for this service. With the advent of the Internet, this barrier has fallen. Publishers should find new ways of keeping their subscribers.
No children in your neighborhood who insist on playing The Sims 2? a GAME that insists on running as administrator! And the group that plays it is IMHO also the group most likely to get bitten by the latest virus/trojan/spyware.
Usually, primes are of interest in the field of cryptography. Specifically, it is desirable to have numbers that are the product of two gigantic primes. This is because it is extremely difficult to find out what those primes are. Unless one of the primes happens to be a Mersenne prime. Simply divide your product by all 42 known Mersenne primes, and if the result is integer, you have found your factorization.
However, if you pick one Mersenne prime and one non-Mersenne prime, it is impossible for anyone to prove which Mersenne prime you've picked, unless they find the non-Mersenne prime. Which will be quite easy. Divide the product you have been given by all Mersenne primes. As there are only 41/42 known, this will be very fast. As soon as the result is integer, you have found the other number.
It reduces the problem space some, because the attacker only has to sweep through the Mersenne prime table for each of the other primes they are trying out You will work from the other side. So the problem space is reduced to 42.
There simply aren't many ten million bit CPUs out there, and that's the sort of size you need to directly process the Mersenne primes they're finding now. In elementary school, we learned how to divide arbitrarily large numbers one digit at a time. We called it 'staartdeling', but I don't know the English word. The same algorithm can be used by any computer.
but I personally wouldn't want to be doing lots of floating-point divisions with million-digit numbers. No need for floating point at all.
If you give me the product of a Mersenne prime and a non-Mersenne prime, I can write a computer algorithm to factor it in the order of a second or so.
Simple energy calculation: 1/2*m*v^2=P*t. P=60MW, t=3600s, v=60km/s. At an efficiency of 100%(!), the maximum mass you can give this speed is 120kg. The sail will be 100m across, this is 10,000 m2. The maximum mass per square meter, including structural integrity (there will be quite a bit of force on the sail to make it accelerate to 60 km/s in just one hour, about 2000N!) is 12g/m2. Then, I think, you will want to have some payload to reach Mars to do the actual experiments with... This needs to be subtracted from the mass of the sail.
OK, some of the mass of the sail will evaporate to enhance propulsion, so acceleration at the end (when the construction is lighter) will be higher than in the beginning, but a lage part of the energy will be taken away by the evaporating gas as well, so efficiency will be quite abit lower than 100%.
All in all, how do they think to make this construction?
This is really, really old news!! There have been adaptive traffic lights for years (decades?) Did you read the article? This is not about adaptive traffic lights in general. Existing systems either have complicated global control between all traffic lights in a region, or perform poorly in case of increasing traffic. He uses a simple local control scheme, that still responds well to increasing traffic.
[How to solve Rubik's cube]: Look up the solution... there's no way that someone works out how to do it without learning the solution... the solution required study from specialized people.
If you don't really like puzzles, you're right. When I bought my Rubik's Cube (was that in '82?), it was because it was a complete enigma to me. I simply had to have it because I did not understand it one bit. Then I just started to turn, and turn, and turn, and gradually I started recognizing patterns in what specific combinations of turns would do. In about two weeks, I could solve it reliably. After some more practice, I could do it in one and a half minute. Later, I learned from a book how I could do the last face more efficiently. It brought my time down to about 45 seconds. But now, 22 years later, I can still do it the way I originally found out. In about two minutes. Because I understood what I was doing. The way I learned from the book is completely gone.
And about that 'study from specialized people' bit: I was just a highschool kid then...
It's very nice that SiC can withstand high temperatures and is very hard, but are these the most important features of a semiconductor material? I would be more interested in band gap voltage, electron/hole mobility etc. Who needs a chip that can run hot when it cannot run fast? Maybe for specialized hardened aplications like space, but I don't see these being used for mainstream applications.
Soda is mostly water, and water is 8.333 lbs per gallon. Most electronics (stripped down boards, not full enclosures, obviously) are probably lighter by volume than that.
Lighter? What makes you think so? Take any electronics, trow it into water, and it will probably sink, not float. So it will most definitely be heavier than water by volume.
whenever my powered PC speakers are on, I can faintly hear the radio through them. You will see this with most cheap speakers. RF signals are rectified by the non-linearity in the input stage of the amplifier. What will help is putting a large ring core (made for high-frequency EMC compatibility) in the input lead to your speakers. Make approx. 10 turns through the core. You will need a large core because otherwise you won't be able to pull the cable with plug 10 times through it. This helped me when I had the same problem.
The Tente sets were actually quite good, they held together better then Lego
Hm, I don't know if I would like the bricks to hold together better than Lego. You should see my original Lego bricks: full of teethmarks, because that was the only way I could get them apart back in 1970...;-)
Everyone knows that complex systems are unstable with all of the Poles in the left half plane. - For every complex problem there is an answer that is clear, simple, and wrong. Ehm... did you just give an example of your own.sig? As far as I can recall, systems are unstable with poles in the RIGHT half plane...
All ground vehicles have a limit on acceleration and deceleration, exactly 1g, unless they grab the asphalt with something else than their tires.
Not exactly true. The limit on acceleration and decelerations is 1g, multiplied by the coefficient of friction, which can both be higher and lower than one. This even without taking into account the extra 'downforce' you can generate by aerodynamically shaping your car. So, acceleration of more than one g is very well possible.
But, as has been said before, the biggest problem with a vehicle like this is that, in order to brake, the center of gravity of the device+rider must be brought behind the contact area between wheel and road. With a unicycle, this can only be accomplished by accelerating first! (During stationary ride, the center of gravity will be exactly over the contact area) This makes a high deceleration in case of a panic stop very difficult.
With a normal two-wheeled motorcycle, the center of gravity is between front and rear wheel, which is behind the front wheel. See what happens when you make a panic stop with a very short motorcycle: you fly over the handlebars!
Actually, my solution would be to throw out fetchmail, throw out pop3 and the rest of its ilk, and do something completely different. There's no call for fetchmail in a sound design. OK, but as long as the rest of the world isn't using your new system, you'll still have to use the existing protocols.
And whatever protocol you're using, if you want a daemon to be able to get your mail, then that daemon needs access to the authentication information. How do you propose to do that in a way that is truely more secure than the way fetchmail handles it? And what exactly do you think would be the security problem with storing passwords in plain text as long as the file isn't world readable?
Fetchmail may have its faults, but I don't think the way authentication information is stored is one of them.
I especially like how the passwords are stored in cleartext in the various rc files, if you want fetchmail to run as a daemon. Yeah, real secure design there. And what alternative would you propose that would be more secure? Fetchmail needs the plain text version of those passwords to retrieve the mail anyway. If you would put the passwords in a encrypted file, the fetchmail daemon would have to know how to decrypt it. If the daemon can decrypt it, so can anyone else who has access to the contents of the file.
So, the solution is, make the file readable only for the user running the daemon (root or the user whose mail is being read). If anyone else cannot read your.fetchmailrc, he cannot read your password, right?
Encypting these passwords only leads to a false sense of security, as anyone with a little bit of knowledge would be able to retrieve the plain text version anyway.
BTW: My understanding is that DC current is far more deadly than AC current -- especially if applied across your heart. AC current across the heart can (under the right conditions) act as a defibrillator.
Totally wrong. 50 or 60 Hz is about the most deadly frequency you can get. It does not act as a defibrillator, on the contrary: it sets your heart into fibrillation, very fast contractions that don't pump blood but sustain themselves. What a defibrillator does is send one very large pulse of direct current through the heart. This stops the fibrillations (and the heart). A heart that is is shocked in this way will start beating again of its own accord.
The reason you can't let go when you grip live wires is that all your muscles contract to their maximum, and your grip tightens so you can't let go. If the currect is large enough, you will get burns, but most probably you will die of the fibrillating heart, not because of the burns.
Well, any digital communication device has to have a certain level of redundancy and error correction.... Anything RF on the same swath of the spectrum will screw things up.
You are absolutely right there, but when you read the article, that is not the cause that things are as bad as they are. If the reasons you mention would be the primary ones, there would be some degradation, but not a full 50% jump for a class b device just registering without transmitting further data.
As soon as a.b device registers with a.g device, the.g device has to adapt its protocol. This has nothing to do with extra interference or error correction. That is the main point of the article, and the reason this is a new issue.
You ask if this is a new issue, and then give general reasons why the theoretical bandwidth will never be attained. What you are overlooking is exactly that what the article shows, namely that there is a mechanism at work here that causes throughput to drop much more than the 'normal causes' would explain.
I have never seen a floppy disk formatted with FAT16, although it probably is possible. They are always formatted with FAT12
You are absolutely right. A floppy disk does not contain more than 4000 clusters, so it will not need FAT16. My bad.
And yes, a good deal of capacity goes into FAT12
The FAT12 filesystem takes 1.5 bytes of FAT space per FAT for every cluster on disk. Assuming 2 FATs and 512 byte cluster size, this is somewhat less than 0.6%. Add a few sectors to this for the root directory. Hardly a large overhead.
That you could cram more than the standard 1.38 MB on your floppies wasn't because you didn't use FAT12 (you still were), but because your formatting used smaller inter-sector gaps, so more sectors fitted on one track, and possibly more than the official 80 tracks. This had the downside that such floppies could not always be used reliably to interchange data between different computers. The TSR you used was needed because standard DOS only used the Media Descriptor byte to determine floppy format, and did not pay attention to the 'Number of tracks' and 'Sectors per track' fields in the bootsector.
I still stick with my original point: the overhead between 1.44 and 2 MB doesn't go into the filesystem, but into sector headers and inter-sector gaps. Using the floppy as a raw tar-archive (as the original poster proposed) will buy you some extra space, but will only give you 1.44 MB instead of 1.38, if you don't low-level reformat it.
The overhead between 1.44 MB and 2 MB does not go into the inefficiency of FAT16, but into sector headers and gaps that make it possible to use the disk in 512 byte chunks. Even if you use rawrite or tar, the disk still needs to be formatted (but then only low-level, not high-level). You still end up with only 1.44 MB. Only if it were possible to format the floppy with only one sector per track, you would cut out most of the overhead, and end up with almost 2 MB.
Although you are heavily moderated up as insightful, it appears to me you have not read the article. Even with infinitely fast hardware for the error correction and no interference at all, thoughput of 802.11g will drop to 13.4 or even 8.9 Mbps once an 802.11b station associates to an 802.11g network. The 802.11b station does not even need to transmit actual data for this!
So, yes, this is really a new issue stemming from the compatibility between 802.11g and 802.11b. Note that 802.11a does not have the same issues, as it does not try to be interoperable with 802.11b.
Slashdot Mirror
No, 800mm is 0.8cm
I always have trouble how to moderate a comment line this.
Troll? Maybe.
Flamebait? It invites flames, but...
Completely clueless? That fits perfectly, but isn't a moderation option!
This was bound to happen one day.
In the 'old days', the only way to spread your work to all your peers was through the estabjournals.
The publishers of those journals could ask a premium price for this service.
With the advent of the Internet, this barrier has fallen.
Publishers should find new ways of keeping their subscribers.
No children in your neighborhood who insist on playing The Sims 2? a GAME that insists on running as administrator! And the group that plays it is IMHO also the group most likely to get bitten by the latest virus/trojan/spyware.
When you are looking for a phrase, instead of loose words, enclose them in quotes on Google.
Googling for "The Who" gave me mostly relevant results.
Compared to the total distance, 200 miles is less than 1 percent. Harly 'quite a ways'...
I just downloaded and burned 3.7, I feel pretty shafted, the downloading isn't an issue, but I don't have many CDRW's of 700Mb to hand :/
;-)
Hm, if you burned 3.7 on CDRW, you could try erasing it and burning 3.8 on top...
Usually, primes are of interest in the field of cryptography. Specifically, it is desirable to have numbers that are the product of two gigantic primes. This is because it is extremely difficult to find out what those primes are.
Unless one of the primes happens to be a Mersenne prime. Simply divide your product by all 42 known Mersenne primes, and if the result is integer, you have found your factorization.
However, if you pick one Mersenne prime and one non-Mersenne prime, it is impossible for anyone to prove which Mersenne prime you've picked, unless they find the non-Mersenne prime.
Which will be quite easy. Divide the product you have been given by all Mersenne primes. As there are only 41/42 known, this will be very fast. As soon as the result is integer, you have found the other number.
It reduces the problem space some, because the attacker only has to sweep through the Mersenne prime table for each of the other primes they are trying out
You will work from the other side. So the problem space is reduced to 42.
There simply aren't many ten million bit CPUs out there, and that's the sort of size you need to directly process the Mersenne primes they're finding now.
In elementary school, we learned how to divide arbitrarily large numbers one digit at a time. We called it 'staartdeling', but I don't know the English word. The same algorithm can be used by any computer.
but I personally wouldn't want to be doing lots of floating-point divisions with million-digit numbers.
No need for floating point at all.
If you give me the product of a Mersenne prime and a non-Mersenne prime, I can write a computer algorithm to factor it in the order of a second or so.
Simple energy calculation:
1/2*m*v^2=P*t.
P=60MW, t=3600s, v=60km/s.
At an efficiency of 100%(!), the maximum mass you can give this speed is 120kg.
The sail will be 100m across, this is 10,000 m2.
The maximum mass per square meter, including structural integrity (there will be quite a bit of force on the sail to make it accelerate to 60 km/s in just one hour, about 2000N!) is 12g/m2.
Then, I think, you will want to have some payload to reach Mars to do the actual experiments with... This needs to be subtracted from the mass of the sail.
OK, some of the mass of the sail will evaporate to enhance propulsion, so acceleration at the end (when the construction is lighter) will be higher than in the beginning, but a lage part of the energy will be taken away by the evaporating gas as well, so efficiency will be quite abit lower than 100%.
All in all, how do they think to make this construction?
This is really, really old news!!
There have been adaptive traffic lights for years (decades?)
Did you read the article?
This is not about adaptive traffic lights in general. Existing systems either have complicated global control between all traffic lights in a region, or perform poorly in case of increasing traffic.
He uses a simple local control scheme, that still responds well to increasing traffic.
[How to solve Rubik's cube]: Look up the solution... there's no way that someone works out how to do it without learning the solution... the solution required study from specialized people.
If you don't really like puzzles, you're right.
When I bought my Rubik's Cube (was that in '82?), it was because it was a complete enigma to me.
I simply had to have it because I did not understand it one bit.
Then I just started to turn, and turn, and turn, and gradually I started recognizing patterns in what specific combinations of turns would do.
In about two weeks, I could solve it reliably.
After some more practice, I could do it in one and a half minute.
Later, I learned from a book how I could do the last face more efficiently. It brought my time down to about 45 seconds.
But now, 22 years later, I can still do it the way I originally found out. In about two minutes. Because I understood what I was doing. The way I learned from the book is completely gone.
And about that 'study from specialized people' bit: I was just a highschool kid then...
It's very nice that SiC can withstand high temperatures and is very hard, but are these the most important features of a semiconductor material?
I would be more interested in band gap voltage, electron/hole mobility etc.
Who needs a chip that can run hot when it cannot run fast?
Maybe for specialized hardened aplications like space, but I don't see these being used for mainstream applications.
I get the sink/float relationship, but I still think that most surface mount boards will float.
Just try it. Any of the components, as well as the board itself, will sink. What makes you think the composite would float?
Soda is mostly water, and water is 8.333 lbs per gallon. Most electronics (stripped down boards, not full enclosures, obviously) are probably lighter by volume than that.
Lighter? What makes you think so? Take any electronics, trow it into water, and it will probably sink, not float. So it will most definitely be heavier than water by volume.
whenever my powered PC speakers are on, I can faintly hear the radio through them.
You will see this with most cheap speakers. RF signals are rectified by the non-linearity in the input stage of the amplifier.
What will help is putting a large ring core (made for high-frequency EMC compatibility) in the input lead to your speakers. Make approx. 10 turns through the core. You will need a large core because otherwise you won't be able to pull the cable with plug 10 times through it. This helped me when I had the same problem.
The Tente sets were actually quite good, they held together better then Lego
;-)
Hm, I don't know if I would like the bricks to hold together better than Lego.
You should see my original Lego bricks: full of teethmarks, because that was the only way I could get them apart back in 1970...
Everyone knows that complex systems are unstable with all of the Poles in the left half plane. - For every complex problem there is an answer that is clear, simple, and wrong. .sig? As far as I can recall, systems are unstable with poles in the RIGHT half plane...
Ehm... did you just give an example of your own
All ground vehicles have a limit on acceleration and deceleration, exactly 1g, unless they grab the asphalt with something else than their tires.
Not exactly true. The limit on acceleration and decelerations is 1g, multiplied by the coefficient of friction, which can both be higher and lower than one. This even without taking into account the extra 'downforce' you can generate by aerodynamically shaping your car. So, acceleration of more than one g is very well possible.
But, as has been said before, the biggest problem with a vehicle like this is that, in order to brake, the center of gravity of the device+rider must be brought behind the contact area between wheel and road. With a unicycle, this can only be accomplished by accelerating first! (During stationary ride, the center of gravity will be exactly over the contact area) This makes a high deceleration in case of a panic stop very difficult.
With a normal two-wheeled motorcycle, the center of gravity is between front and rear wheel, which is behind the front wheel. See what happens when you make a panic stop with a very short motorcycle: you fly over the handlebars!
Actually, my solution would be to throw out fetchmail, throw out pop3 and the rest of its ilk, and do something completely different. There's no call for fetchmail in a sound design.
OK, but as long as the rest of the world isn't using your new system, you'll still have to use the existing protocols.
And whatever protocol you're using, if you want a daemon to be able to get your mail, then that daemon needs access to the authentication information.
How do you propose to do that in a way that is truely more secure than the way fetchmail handles it?
And what exactly do you think would be the security problem with storing passwords in plain text as long as the file isn't world readable?
Fetchmail may have its faults, but I don't think the way authentication information is stored is one of them.
I especially like how the passwords are stored in cleartext in the various rc files, if you want fetchmail to run as a daemon. Yeah, real secure design there.
.fetchmailrc, he cannot read your password, right?
And what alternative would you propose that would be more secure? Fetchmail needs the plain text version of those passwords to retrieve the mail anyway. If you would put the passwords in a encrypted file, the fetchmail daemon would have to know how to decrypt it. If the daemon can decrypt it, so can anyone else who has access to the contents of the file.
So, the solution is, make the file readable only for the user running the daemon (root or the user whose mail is being read). If anyone else cannot read your
Encypting these passwords only leads to a false sense of security, as anyone with a little bit of knowledge would be able to retrieve the plain text version anyway.
BTW: My understanding is that DC current is far more deadly than AC current -- especially if applied across your heart.
AC current across the heart can (under the right conditions) act as a defibrillator.
Totally wrong.
50 or 60 Hz is about the most deadly frequency you can get. It does not act as a defibrillator, on the contrary: it sets your heart into fibrillation, very fast contractions that don't pump blood but sustain themselves. What a defibrillator does is send one very large pulse of direct current through the heart. This stops the fibrillations (and the heart). A heart that is is shocked in this way will start beating again of its own accord.
The reason you can't let go when you grip live wires is that all your muscles contract to their maximum, and your grip tightens so you can't let go. If the currect is large enough, you will get burns, but most probably you will die of the fibrillating heart, not because of the burns.
Well, any digital communication device has to have a certain level of redundancy and error correction. ... Anything RF on the same swath of the spectrum will screw things up.
.b device registers with a .g device, the .g device has to adapt its protocol. This has nothing to do with extra interference or error correction. That is the main point of the article, and the reason this is a new issue.
You are absolutely right there, but when you read the article, that is not the cause that things are as bad as they are.
If the reasons you mention would be the primary ones, there would be some degradation, but not a full 50% jump for a class b device just registering without transmitting further data.
As soon as a
You ask if this is a new issue, and then give general reasons why the theoretical bandwidth will never be attained. What you are overlooking is exactly that what the article shows, namely that there is a mechanism at work here that causes throughput to drop much more than the 'normal causes' would explain.
I have never seen a floppy disk formatted with FAT16, although it probably is possible. They are always formatted with FAT12
You are absolutely right. A floppy disk does not contain more than 4000 clusters, so it will not need FAT16. My bad.
And yes, a good deal of capacity goes into FAT12
The FAT12 filesystem takes 1.5 bytes of FAT space per FAT for every cluster on disk.
Assuming 2 FATs and 512 byte cluster size, this is somewhat less than 0.6%.
Add a few sectors to this for the root directory.
Hardly a large overhead.
That you could cram more than the standard 1.38 MB on your floppies wasn't because you didn't use FAT12 (you still were), but because your formatting used smaller inter-sector gaps, so more sectors fitted on one track, and possibly more than the official 80 tracks.
This had the downside that such floppies could not always be used reliably to interchange data between different computers.
The TSR you used was needed because standard DOS only used the Media Descriptor byte to determine floppy format, and did not pay attention to the 'Number of tracks' and 'Sectors per track' fields in the bootsector.
I still stick with my original point: the overhead between 1.44 and 2 MB doesn't go into the filesystem, but into sector headers and inter-sector gaps.
Using the floppy as a raw tar-archive (as the original poster proposed) will buy you some extra space, but will only give you 1.44 MB instead of 1.38, if you don't low-level reformat it.
The overhead between 1.44 MB and 2 MB does not go into the inefficiency of FAT16, but into sector headers and gaps that make it possible to use the disk in 512 byte chunks. Even if you use rawrite or tar, the disk still needs to be formatted (but then only low-level, not high-level). You still end up with only 1.44 MB.
Only if it were possible to format the floppy with only one sector per track, you would cut out most of the overhead, and end up with almost 2 MB.
Although you are heavily moderated up as insightful, it appears to me you have not read the article.
Even with infinitely fast hardware for the error correction and no interference at all, thoughput of 802.11g will drop to 13.4 or even 8.9 Mbps once an 802.11b station associates to an 802.11g network. The 802.11b station does not even need to transmit actual data for this!
So, yes, this is really a new issue stemming from the compatibility between 802.11g and 802.11b.
Note that 802.11a does not have the same issues, as it does not try to be interoperable with 802.11b.