That just illustrates my point. If congestion in 2.4GHz made the band useless, consumers would demand 5GHz support. Yet here we are in 2012, and only just now are consumers beginning to switch. The problem cannot be as bad as girlintraining posits.
10kbps wifi is practically useless when you only have 11 channels. There will almost always be more than 11 users within a few miles, and at 10kbps they will all be using the channels at close to 100%. Congestion will kill your throughput. In addition, the temptation for someone to come up with a 110kbps 11-channel device will be impossible to resist, and running one of those will kill it for everybody else. The same goes for 1Mbps for an office complex, that is completely inadequate with the number of channels we have today.
No, we need to move up in frequency to get more channels and use power and antenna design to fix the range problems. Already, 5GHz has quite good range in practice, as one bar of signal strength often gives you 20Mbps or more of bandwidth. Of course your device is likely to see the lovely 3 bars of 2.5GHz coverage and jump there instead, only to be stuck with a lousy congested 1Mbps channel.
Allowing everyone to run their own multi-mile cells with indoor coverage is not currently doable in any frequency band. It is also fairly stupid, the likelihood is that most of the traffic is to/from the Internet, so why send the signal for miles instead of just hitting a nearby AP?
I completely disagree. 802.11a was ratified in 1999, and still there is no significant problem with congestion in the 5GHz band. Sure, eventually the 2.5GHz crunch will move to 5GHz too, but I bet we have at least 10 years of joy before that happens. In 10 years 60GHz will be affordable. When 60GHz gets congested, terahertz or light should be affordable. In the infrared, we can currently do 100Gbps in 50GHz (commercially available, but only through fiber). 80 channels of 100Gbps is probably enough for me.
Certification and black vans and watchgroup groups make development slower and more expensive. That will delay the switch to better frequency bands and therefore CAUSE the problem rather than fixing it. If you must regulate, at least only touch 2.5GHz. Ban Bluetooth, baby monitors (unless they transmit 802.11g-or-better compatible) and analog CCTV systems from 2.5GHz perhaps, that would help.
If you're in an office building, range is not a problem (except too much of it). You want to turn down the radios so they don't interfere, and just lock everything connecting at less than perhaps 10Mbps out of the network.
The problem is that way too many devices are 2.5GHz only. Even some phones. And the other problem is that many devices love raw signal strength and will often pick the strong, crowded, useless 2.5GHz AP over the weak but low-noise-floor and no-congestion 5GHz AP.
There aren't that many workers lining up in China any more. Well there is in the interior, but that is not where the factories are (yet). Mass migration from the interior to the coast is no longer very practical.
When you have moved a thousand km away from home and get to see your family a few times a year, you really don't want to lose a day of holiday. You're already likely to spend a day travelling at each end of the holiday.
Anyway, the days of doing low-wage manufacturing in China are almost over. Luckily.
As a nice turn of events, the platform maintainer is actually working for NVIDIA, not for Broadcom. Shows you who is open source friendly and who isn't these days.
That actually seems to be a bit of a trend -- nVidia engineers doing spare time open source work on non-nVidia platforms. It ensures that they cannot be accused of leaking nVidia secrets in the code.
Whether it shows anything about who is open source friendly, and what exactly it shows, is less clear to me...
Of course it helped that most of the developers in the ARM community seemed to agree with the point Linus made. Other concerns had just taken priority.
DECT wireless headsets. They are damn expensive but WONDERFUL. Of course if your computer is also the phone, you still need a wire from the computer to the headset base station, but hopefully that is permanently fixed to the docking station. That gets rid of most of all your concerns except donning the headset, but at least the wire won't snag on anything. You can walk pretty much anywhere you want with the headset, the range is great.
I would never personally do without a hardphone, despite having one of those head sets. Then again I work for a company selling hosted PBX's, so maybe I just like when we sell more phones.
If there is less than about 8 people talking at the same time in the same general area, you can use cheaper Bluetooth headsets. They work fine as long as the 2.5GHz band doesn't get too crowded, and as long as you stay quite close to the base station.
I mistyped, there is missing "each" at the end of "Not even if your GPU with 10000 cores can do a hash in one clock cycle." That would be a total performance of 10Ghashes/second, which is more than 1000 times the performance of your hardware. Even with that generous performance, the universe will end before you get a collision in SHA2-224.
If you keep a common extra salt somewhere in your server configuration, you can get lucky that the adversary only gets a copy of the password database and the per-password salts. That way the adversary has a hard time breaking even the easy passwords, and the post I replied to is right: "If the passwords are decently salted and the salt is unknown good luck with that."
However, that protection relies on luck. The salt is rarely unknown.
Why wouldn't you want faster cryptographic hashes? It is trivial to slow a hash down as much as you want, but when you need it to go fast, it is very difficult to speed it up.
Go right ahead then, pick any of the contestants and bruteforce a collision. You'll be famous.
We cannot even design a computer to COUNT to 2^128, so for any even minimally secure hash function of 256 bits or more, brute force won't happen. Not even if your GPU with 10000 cores can do a hash in one clock cycle.
The salt is difficult to keep unknown. Every part of the web application which needs access to the salted hashed password also needs access to the salt, so if your security fails and allows access to the salted password, it probably allows access to the salt as well.
Sometimes you get lucky and the attackers get only the salted hashed password, but you cannot design your security around getting lucky.
You are assuming failures are independent. Hopefully, when something fails at a nuclear power plant, they look at every similar unit with some suspicion. Having 5 pumps only helps if no common cause could ever cause problems for more than one at a time.
In some cases, this was enough to get the defendant to plead to a lower crime, with life in prison without possibility of parole as the agreed punishment.
Right, let us threaten people into admitting guilt, so we don't have to deal with the nastiness of an actual trial. It works great with witches, I hear.
The DSP thing is such a joke. They are just equalizers, and the difference between models is how many bands the equalizer has. There are a bunch of useful dynamic things a hearing aid could do, and they are doing none of them.
True, I didn't make it clear that I meant 10% of the instructions actually executed. Sorry about that. As you point out, supported but never executed instructions are free. Some CPU's have even given up on certain instructions and leave it to the OS to very slowly emulate them. That is fine if you can avoid those instructions for new programs.
The Intel designers apparently believed that it would be possible to program around the slow instructions and the pipeline stalls. Alas, compilers failed to become sufficiently clever (they still aren't). The fact that 90% or more of actual executed instructions went blazingly fast on Pentium 4 just wasn't enough, the last less than 10% actual executed instructions slowed everything down too much.
This does assume that all instructions are used the same amount, which isn't necessarily the case.
No extra assumptions are necessary.
If 10% of the instructions executed take 10 clock cycles each, there is no budget left if your target is 1 instruction per clock cycle (and that target is not exactly aggressive). If any of the other instructions executed take more than zero clock cycles, you will miss the target.
zSeries has off-die L4 these days. And let us just close our eyes and pretend Itanium ever happened. At the same time we can pretend that Compaq never bought DEC and HP, so the Alpha is alive and well.
Remember, this is the company that got rid of the barrel shifter for the P4.
They didn't really have a choice. Intel had decided that clock speed was what counted, damn everything else. To that end, they did a double-pumped ALU (running at 6GHz when the rest of the processor is at 3GHz). Barrel shifters were too slow, they would hold everything else back. Intel hoped that by making most stuff go really fast, it would make up for doing a few things very slowly. Alas, if you make 10% of the instructions take 10 clock cycles, you have to do the other 90% at 0 clock cycles just to reach 1 instruction per clock. It's sort of a serial version of Amdahl's Law.
By your definition all power generation can respond quickly to load changes. That removes all meaning from the phrase. Throwing away energy by venting the steam or turning the wings out of the wind or dumping the electricity in resistor arrays does NOT count, all technologies can do that.
I can't imagine what it would be like having a giant reflector on the Earth bouncing light back into space and heating the atmosphere on the way back out.
I can't believe I'm reading this on Slashdot. Please hand in your geek card.
As for environment loss, the US could go 100% solar for electricity just by replacing the corn fields used for biofuel with solar panels.
Slashdot Mirror
That just illustrates my point. If congestion in 2.4GHz made the band useless, consumers would demand 5GHz support. Yet here we are in 2012, and only just now are consumers beginning to switch. The problem cannot be as bad as girlintraining posits.
So add an access point in each room where you actually stay for extended periods. Use 5GHz for the rest.
10kbps wifi is practically useless when you only have 11 channels. There will almost always be more than 11 users within a few miles, and at 10kbps they will all be using the channels at close to 100%. Congestion will kill your throughput. In addition, the temptation for someone to come up with a 110kbps 11-channel device will be impossible to resist, and running one of those will kill it for everybody else. The same goes for 1Mbps for an office complex, that is completely inadequate with the number of channels we have today.
No, we need to move up in frequency to get more channels and use power and antenna design to fix the range problems. Already, 5GHz has quite good range in practice, as one bar of signal strength often gives you 20Mbps or more of bandwidth. Of course your device is likely to see the lovely 3 bars of 2.5GHz coverage and jump there instead, only to be stuck with a lousy congested 1Mbps channel.
Allowing everyone to run their own multi-mile cells with indoor coverage is not currently doable in any frequency band. It is also fairly stupid, the likelihood is that most of the traffic is to/from the Internet, so why send the signal for miles instead of just hitting a nearby AP?
I completely disagree. 802.11a was ratified in 1999, and still there is no significant problem with congestion in the 5GHz band. Sure, eventually the 2.5GHz crunch will move to 5GHz too, but I bet we have at least 10 years of joy before that happens. In 10 years 60GHz will be affordable. When 60GHz gets congested, terahertz or light should be affordable. In the infrared, we can currently do 100Gbps in 50GHz (commercially available, but only through fiber). 80 channels of 100Gbps is probably enough for me.
Certification and black vans and watchgroup groups make development slower and more expensive. That will delay the switch to better frequency bands and therefore CAUSE the problem rather than fixing it. If you must regulate, at least only touch 2.5GHz. Ban Bluetooth, baby monitors (unless they transmit 802.11g-or-better compatible) and analog CCTV systems from 2.5GHz perhaps, that would help.
If you're in an office building, range is not a problem (except too much of it). You want to turn down the radios so they don't interfere, and just lock everything connecting at less than perhaps 10Mbps out of the network.
The problem is that way too many devices are 2.5GHz only. Even some phones. And the other problem is that many devices love raw signal strength and will often pick the strong, crowded, useless 2.5GHz AP over the weak but low-noise-floor and no-congestion 5GHz AP.
There aren't that many workers lining up in China any more. Well there is in the interior, but that is not where the factories are (yet). Mass migration from the interior to the coast is no longer very practical.
When you have moved a thousand km away from home and get to see your family a few times a year, you really don't want to lose a day of holiday. You're already likely to spend a day travelling at each end of the holiday.
Anyway, the days of doing low-wage manufacturing in China are almost over. Luckily.
As a nice turn of events, the platform maintainer is actually working for NVIDIA, not for Broadcom. Shows you who is open source friendly and who isn't these days.
That actually seems to be a bit of a trend -- nVidia engineers doing spare time open source work on non-nVidia platforms. It ensures that they cannot be accused of leaking nVidia secrets in the code.
Whether it shows anything about who is open source friendly, and what exactly it shows, is less clear to me...
It happened again, Linus flaming people gets stuff done.
It all started a year and a half ago with this innocent-sounding topic: [GIT PULL] omap changes for v2.6.39 merge window.
Of course it helped that most of the developers in the ARM community seemed to agree with the point Linus made. Other concerns had just taken priority.
DECT wireless headsets. They are damn expensive but WONDERFUL. Of course if your computer is also the phone, you still need a wire from the computer to the headset base station, but hopefully that is permanently fixed to the docking station. That gets rid of most of all your concerns except donning the headset, but at least the wire won't snag on anything. You can walk pretty much anywhere you want with the headset, the range is great.
I would never personally do without a hardphone, despite having one of those head sets. Then again I work for a company selling hosted PBX's, so maybe I just like when we sell more phones.
If there is less than about 8 people talking at the same time in the same general area, you can use cheaper Bluetooth headsets. They work fine as long as the 2.5GHz band doesn't get too crowded, and as long as you stay quite close to the base station.
I mistyped, there is missing "each" at the end of "Not even if your GPU with 10000 cores can do a hash in one clock cycle." That would be a total performance of 10Ghashes/second, which is more than 1000 times the performance of your hardware. Even with that generous performance, the universe will end before you get a collision in SHA2-224.
I know how salts work. I was educating AIXtreme, who apparently believes that they can be kept hidden in general.
If you keep a common extra salt somewhere in your server configuration, you can get lucky that the adversary only gets a copy of the password database and the per-password salts. That way the adversary has a hard time breaking even the easy passwords, and the post I replied to is right: "If the passwords are decently salted and the salt is unknown good luck with that."
However, that protection relies on luck. The salt is rarely unknown.
Why wouldn't you want faster cryptographic hashes? It is trivial to slow a hash down as much as you want, but when you need it to go fast, it is very difficult to speed it up.
Go right ahead then, pick any of the contestants and bruteforce a collision. You'll be famous.
We cannot even design a computer to COUNT to 2^128, so for any even minimally secure hash function of 256 bits or more, brute force won't happen. Not even if your GPU with 10000 cores can do a hash in one clock cycle.
The salt is difficult to keep unknown. Every part of the web application which needs access to the salted hashed password also needs access to the salt, so if your security fails and allows access to the salted password, it probably allows access to the salt as well.
Sometimes you get lucky and the attackers get only the salted hashed password, but you cannot design your security around getting lucky.
You are assuming failures are independent. Hopefully, when something fails at a nuclear power plant, they look at every similar unit with some suspicion. Having 5 pumps only helps if no common cause could ever cause problems for more than one at a time.
In some cases, this was enough to get the defendant to plead to a lower crime, with life in prison without possibility of parole as the agreed punishment.
Right, let us threaten people into admitting guilt, so we don't have to deal with the nastiness of an actual trial. It works great with witches, I hear.
The DSP thing is such a joke. They are just equalizers, and the difference between models is how many bands the equalizer has. There are a bunch of useful dynamic things a hearing aid could do, and they are doing none of them.
How will I prevent this thing from going off on the plane? Will it look suspicious when going through security?
(Not that there is actually anything wrong with cell phones on air planes, but that is a rant for a different time).
True, I didn't make it clear that I meant 10% of the instructions actually executed. Sorry about that. As you point out, supported but never executed instructions are free. Some CPU's have even given up on certain instructions and leave it to the OS to very slowly emulate them. That is fine if you can avoid those instructions for new programs.
The Intel designers apparently believed that it would be possible to program around the slow instructions and the pipeline stalls. Alas, compilers failed to become sufficiently clever (they still aren't). The fact that 90% or more of actual executed instructions went blazingly fast on Pentium 4 just wasn't enough, the last less than 10% actual executed instructions slowed everything down too much.
This does assume that all instructions are used the same amount, which isn't necessarily the case.
No extra assumptions are necessary.
If 10% of the instructions executed take 10 clock cycles each, there is no budget left if your target is 1 instruction per clock cycle (and that target is not exactly aggressive). If any of the other instructions executed take more than zero clock cycles, you will miss the target.
zSeries has off-die L4 these days. And let us just close our eyes and pretend Itanium ever happened. At the same time we can pretend that Compaq never bought DEC and HP, so the Alpha is alive and well.
Remember, this is the company that got rid of the barrel shifter for the P4.
They didn't really have a choice. Intel had decided that clock speed was what counted, damn everything else. To that end, they did a double-pumped ALU (running at 6GHz when the rest of the processor is at 3GHz). Barrel shifters were too slow, they would hold everything else back. Intel hoped that by making most stuff go really fast, it would make up for doing a few things very slowly. Alas, if you make 10% of the instructions take 10 clock cycles, you have to do the other 90% at 0 clock cycles just to reach 1 instruction per clock. It's sort of a serial version of Amdahl's Law.
By your definition all power generation can respond quickly to load changes. That removes all meaning from the phrase. Throwing away energy by venting the steam or turning the wings out of the wind or dumping the electricity in resistor arrays does NOT count, all technologies can do that.
I can't imagine what it would be like having a giant reflector on the Earth bouncing light back into space and heating the atmosphere on the way back out.
I can't believe I'm reading this on Slashdot. Please hand in your geek card.
As for environment loss, the US could go 100% solar for electricity just by replacing the corn fields used for biofuel with solar panels.