I'm not sure that's a sufficient reason. All Valves are "N-type", and a typical bipolar logic gate (or bistable) using only NPN transistors does indeed ground the emitters. The reason for indirect heating of the cathode isn't really about biasing (especially if a negative supply rail exists), but about allowing cheap, unrectified AC supplies to be used for the heater without introducing hum into the signal. For a battery-driven radio, this problem vanishes.
Incidentally, I recently built a battery-powered valve/op-amp hybrid amplifier. The valves are 1980s era, really quite tiny, and draw 10mA at 1.5V for the heaters, which glow almost imperceptibly. The B battery is a single 9V battery. (This one is rather a demonstration device; it doesn't have much voltage gain, and the valves have to be buffered by the op-amp to drive headphones - but it can be done).
Well, that's true excepting that the patent system is used to prevent independent invention. The idea (originating from techniques for making stained glass iirc), is that in return for a long monopoly, the inventor of a technique gives away the secret so that his competitors can also use it 25 years later. But the problem is really that we aren't preventing reverse engineering; we're banning independent thoughts. I'd accept raising the bar, but we'd have to really really strengthen the "obvious to one skilled in the art" test. For A to obtain a patent, it should be the case that, when faced with the same situation, same technical requirements, and same background knowledge, an expert practitioner B would almost never be able to reach the same invention.
Incidentally, I think you have your causation backwards: as technologies became important, there was a desire to monopolise inventions (so as to keep newcomers out of the field), and so "lobbying" pressure arose to create patent laws. Note that, for example, most chemical companies are in Switzerland: they were founded there because, at the time, Switzerland had no patent protection for chemicals, and so companies could grow there after escaping litigation elsewhere.
Pharma is the one industry where patents might be tolerated, as a pragmatic exception, not a correct one.
Seriously...there is no positive side to patents excepting the sense of mutually assured destruction. Patents are good for lawyers, but hurt innovators, consumers, and the development of technology. (It's true that the current system is badly broken, but I'm not advocating scrapping it because it's too hard to fix; I'm advocating scrapping it because it's wrong in principle and in practice).
Yes, it's true that investors like to see patents - but if nobody had them, that wouldn't matter.
Also, remember that most investors invest in companies that build things, not that innovate. As Edison said, the 1% inspiration may be necessary, but it's nowhere near sufficient for success. What a new company needs isn't a phantom of the potential to sue; what it needs is certainty that it will be protected from predatory IP enforcement.
Incidentally, the patent system doesn't just hurt the economy and slow progress; it kills people. Take a look at this technical history of the aircraft, or the failure to cross-license for some of the combined anti-retroviral pills.
You have it backwards. The fallacy with patents is to always see oneself as the person with the patent using it so no one "steals" your idea. Actually, the risk is that if you have a company with a product, you will be destroyed by a "troll" who sues you. [Also, the concept of owning ideas is itself wrong: think "standing on the shoulders of giants"]
I accept that if we scrap the patent system, we would have no way to protect small companies against cloners (though they'd still have first-to-market advantage). But we already can't protect small companies: a predator can already crush them by finding something they infringe.
Yes...but surely there's a market for a good, less expensive hearing aid that is either wired (like an iPod), or slightly bulky (like a bluetooth headset)?
Actually, why hasn't anyone tried to modify a bluetooth headset: pair with an android phone, do some DSP, and use the device in loopback mode?
What we need is a way for individuals and companies to opt out of the intellectual monopolies system altogether. Something like "I promise never to asset an intellectual monopoly against anyone (except defensively); in return, I obtain the right to never be sued". It really needs a whole country to be brave enough to unilaterally scrap the patent system: and whichever one does this first will make a fortune from investment. Think "tax-haven" but where's it's really a "freedom to innovate haven".
I always thought these were "toys" - but having received one as a gift, which can do x400, I'm pretty impressed with it. (Also, just works under Linux, as a v4l device).
You might also consider an SLR camera with a macro lens: you can pick up an Olympus OM1 for about $20 on eBay, and add a 300mm macro lens for perhaps $30.
* It's reasonably clear (from most guidelines) that session cookies are fine, (because they are essential to functionality). Furthermore, implict consent is given by the act of logging in,
* Long term preference cookies "remember my name and my customisations" are also OK, though it's usually good practice to notfiy the user (the T&C is sufficient for this).
* Analytics cookies (eg Google Analytics) really should be covered by the directive, but basically aren't.
* Evil (cross site advertiser tracking cookies) ought to be exterminated...but these ones can simply be consented into, without really understanding.
I think you're looking too late in the cycle. Enterprise devs in Fortune 500 made their choices 5 years ago; I'm talking about the people who are making their choices now. Consider at the moment that Android is rapidly overtaking iOS. Here's why:
- Much greater ease of entry (Eclipse is a free download; for iOS, first I need a Mac computer, then I need to buy Xcode)
- More powerful platform (some apps simply can't be written for iOS, because it is too locked down)
- No Apple AppStore policy (OK, the app store is great for quality control, but why shouldn't I write an app that competes with an Apple native features, or that runs an interpreter, or that tethers without carrier-support, or that has my own payment method, or that supports unapproved content?)
Also, the Macbook hardware is pretty good (especially compared to some Windows offerings). But as Woz points out, just because Apple are doing well doesn't mean that they can't do better!
Here are some things Apple could/should do to become (again) good citizens of the engineering community. They'd see a huge surge in developers and technical users if they do this. As it is, most techies cannot use or recommend Apple in good conscience.
1. Political. Join OIN, and pledge never to sue first for patent infringement. Also, stop trying to buy bad laws. Pledge not to sue any open source project for patent infringement (eg font hinting). Make its media codec patents available to HTML5 without royalty.
2. It's *my* hardware if I buy it. Guarantee the ability to Jailbreak all devices. This is a win for users, a win for tinkerers, a win for some customers who need to run their own arbitrary code, and a win for security (exploits get fixed, rather than hoarded for jailbreaking purposes). I'd be perfectly happy to accept a compromise where a jailbroken device loses some DRM features. Root shouldn't be available by default (most users rightly want it simple, and to trust Apple to look after them), but should be available on request to anyone who is competent enough to run a CLI program.
3. Support all open standards where possible. For example, the iPod still can't play Ogg files. There's NO good reason why not: the cost is zero, and the hardware is capable. Likewise, the newest iPods won't work on Linux: Apple could very easily give a couple of free devices and some documentation to the libgpod project each time they release a new model. (this would be far cheaper than supporting native iTunes). Likewise, support for NFS as a media repository.
4. End the misfeatures for the purposes of lock-in, I've so often experienced this: it's like buying a shiny new car, and finding someone has deliberately welded an upturned thumbtack to the driver's seat. Every product has a sting in the tail - not because it can't do something, but because it won't. I can't be the only one who finds this frustrating.
5. I'd love to see a bit of extra focus on hobbyist and educational development. Perhaps Apple could stock the Raspberry Pi / Arduino, and Apple stores might sell items for geeks (eg bare iPod connectors for DIY docks, USB-to-Relay adaptors, and the tools usually made by iFixit).
The trick is to write the CSS as a PHP file, but make sure it is only parsed rarely, and cached. On the server, create "style.php" (linked from thje main HTML just as if it were a normal style.css file). Then fix the caching and mime-type. Result: easy to write, still efficient.
//Respond with 304 (not-modified) unless the file is changed. This means the PHP file is only evaluated once per client per session. $last_modified_time = filemtime(__FILE__); $etag = md5_file(__FILE__);
header("Last-Modified: ".gmdate("D, d M Y H:i:s", $last_modified_time)." GMT"); header("Etag: $etag");
if (@strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) == $last_modified_time || trim($_SERVER['HTTP_IF_NONE_MATCH']) == $etag) { header("HTTP/1.1 304 Not Modified"); exit; }
$max_age=600; //10 minutes. header("Cache-Control: max-age=$max_age"); // HTTP/1.1 (Client won't even try to reload more than every 10 mins). header("Content-type: text/css"); //Set the mime-type to CSS (so the browser will cope with it.)
//Now write out the CSS, using PHP to help make it more terse.
What we need is a viral anti-patent system, designed to be stronger than the GPL with the intention of destroying the patent system together. Like OIN (the open invention network), but with real teeth. Here's how it would work:
0. Philosophy: intellectual monopolies are completely wrong, opposed to the scientific method, economically evil, and morally unjustified. Nobody can own an idea, and everyone stands on the shoulders of giants.
1. Create a "public patent foundation" (PPF) similar to the FSF.
2. Anyone with an invention can grant their idea (or patent) to the PPF. Anyone may license a PPF patent, royalty free, provided they are not involved in offensive patent litigation.
3. The PPF makes its patents available to anyone for the purposes of counter-suit. No matter who you are, if you are the victim of a patent lawsuit, then (unless you fired first), the PPF will lend any of its patents to you for you to counter-sue the aggressor..
4. If the PPF wins a lawsuit, the settlement terms would include all patents of the loser being shared with the PPF.
5. The result is that the PPF would eventually hold a large majority of the patents worldwide. It would allow anyone to use these, royalty free, but would demand that users of PPF patents covenant never to sue in a patent lawsuit.
6. As a pragmatic (but non principled exception), we might exclude pharma-patents from this.
I have a (UK) project involving a certain chip manufactured by Rockwell. There is an exceptionally terse datasheet available online. I asked for a a little more, and Rockwell, while courteous, basically declined to help me, citing ITAR. The chip is a CCD (sensitive to the infra-red), but otherwise nearly obsolete, and the datasheet I wanted was something similar to the common documentation for the 555 timer chip. The idea that I might build a guided missile out of this thing is laughable.
Actually, it can be quite useful having 2 different clipboards, if used thoughtfully. Otherwise, klipper or parcellite can unify them for you if you want.
The optimal solution (right now) is to build some more Gen IV reactors (such as the "Integral Fast Reactor"): this uses far less uranium, and burns up the lanthanides in situ, yielding very small amounts of waste that are safe [same level as the uranium ore] within 200 years.
Having done basically this, I suggest you use Cat6-S (the shielded version). More expensive, unnecessary for networking, but it does reduce the general amount of RFI present. Likewise, if you have fancy computerised dimmers. We have both, and our electrically operated curtains(*) now occasionally act like we have a poultergeist!
(*) We're not that lazy, but these ones are inaccessible.
Shouldn't this be handled at the datalink level by the wireless hardware? If there's transmission errors due to noise, more bits should be dedicated to ECC codes. The reliability is maintained at the expense of (usable) bandwidth and the higher layers of the stack just see a regular link with reduced capacity.
Yes, it certainly should be. But it often isn't.
Incidentally, regular ECC won't help here: adding 1kB of ECC to 1KB of packet doesn't help against a 1ms long burst of interference, which obliterates the whole packet.
Yes...which is why DHCP shows the problem even more severely. DHCP needs 4 consecutive packets to get through OK, and when the environment is noisy, this doesn't happen. But the same happens for TCP, mitigated (slightly) by TCP having a faster retransmit timeout.
My point still stands:
Symptom: packet loss.
Common cause: link saturation.
Remedy: back off slightly, and hope everyone else also notices.
Symptom: packet loss (indistinguishable from the above)
Less common cause: RF interference because the AP is near the edge of range.
Remedy: try really hard, and flood the link with repeats to get at least some packets through.
In the wireless example, we still have a dedicated 10 Mbit link, it's just really unreliable. Being profligate with packets might get me 25% of 8 Mbit/s; being conservative with packets, would back off to perhaps 90% of 0.01 Mbit/s.
There is one other problem: TCP assumes that dropped packets mean the link is saturated, and backs off the transmit rate. But Wireless isn't like that: frequently packets are lost because of noise (especially near the edge of the range). TCP responds by backing off (it thinks the link is congested) when actually it should be trying harder to overcome the noise. So we get really really poor performance(*).
In this case, I think the kernel should somehow realise that there is "10 MB of bandwidth, with a 25% probability of packets returning". It should do forward-error correction, pre-emptively retransmitting every packet 4x as soon as it is sent. Of course there is a huge difference between the case of lots of users on the same wireless AP, all trying to share bandwidth (everyone needs to slow down), and 1 user competing with lots of background noise (the computer should be more aggressive). TCP flow-control seems unable to distinguish them.
(*)I've recently experienced this with wifi, where the connection was almost completely idle (I was the only one trying to use it), but where I was near the edge of range from the AP. The process of getting onto the network with (DHCP) was so slow that most times it failed: by the time DHCP got the final ACK, NetworkManager had seen a 30 second wait, and brought the interface down! But if I could get DHCP to succeed, the network was usable (albeit very slow).
Unfortunately, I think you haven't quite got this right.
The problem isn't buffering at the *ends* of the link (the two applications talking to one another), rather, it's buffering in the middle of the link.
TCP flow control works by getting (timely notification of) dropped packets when the network begins to saturate. Once the network reaches about 95% of full capacity, it's important to drop some packets so that *all* users of the link back off and slow down a bit.
The easiest way to imagine this is by considering a group of people all setting off in cars along a particular journey. Not all roads have the same capacity, and perhaps there is a narrow bridge part way along. So the road designer thinks: that bridge is a choke point, but the flow isn't perfectly smooth. So I'll build a car-park just before the bridge: then we can receive inbound traffic as fast as it can arrive, and always run the bridge at maximum flow. (The same thing happens elsewhere: we get lots of carparks acting as stop-start FIFO buffers).
What now happens is that everybody ends up sitting in a car-park every single time they hit a buffer. It makes the end-to-end latency much much larger.
What should happen (and TCP flow-control will autodetect if it gets dropped packet notifications promptly) is that people know that the bridge is saturated, and fewer people set off on their journey every hour. The link never saturates, buffers don't fill, and nobody has to wait.
Bufferbloat is exactly like this: we try to be greedy and squeeze every last baud out of a connection: what happens is that latency goes way too high, and ultimately we waste packets on retransmits (because some packets arrive so late that they are given up for lost). So we end up much much worse off. A side consequence of this is that the traffic jams can sometimes oscillate wildly in unpredictable manners.
If you've ever seen your mobile phone take 15 seconds to make a simple request for a search result, despite having a good signal, you've observed buffer bloat.
Actually, even then, you might be OK if you use rsync. Rsync will allow you to do daily incremental backups with very little overhead. Of course, you still have to handle getting the first (full) backup made, and the cost of a full download if you need to recover. But that's not nearly as bad (and I believe there are some services will let you physically deliver a disk for initialisation).
The real problem is that these factories, operating under very poor conditions, drive down prices by competition. Therefore they outcompete western factories. But, they have a huge economic advantage: the near slave-labour conditions are enforced by the lack of democracy, and crackdowns on protestors/unions. imho, China's lack of democracy is anti-competitive, and we should be imposing a "non-democracy surcharge" on imports from any country where the workers can''t protect themselves. (This isn't specifically to protect workers in China, it's to protect workers in the US/EU from downward pressure on working conditions).
Slashdot Mirror
I'm not sure that's a sufficient reason. All Valves are "N-type", and a typical bipolar logic gate (or bistable) using only NPN transistors does indeed ground the emitters. The reason for indirect heating of the cathode isn't really about biasing (especially if a negative supply rail exists), but about allowing cheap, unrectified AC supplies to be used for the heater without introducing hum into the signal. For a battery-driven radio, this problem vanishes.
Incidentally, I recently built a battery-powered valve/op-amp hybrid amplifier. The valves are 1980s era, really quite tiny, and draw 10mA at 1.5V for the heaters, which glow almost imperceptibly. The B battery is a single 9V battery. (This one is rather a demonstration device; it doesn't have much voltage gain, and the valves have to be buffered by the op-amp to drive headphones - but it can be done).
This is still dodgy. If you are worried about this, you should be forthright and block https.
Well, that's true excepting that the patent system is used to prevent independent invention. The idea (originating from techniques for making stained glass iirc), is that in return for a long monopoly, the inventor of a technique gives away the secret so that his competitors can also use it 25 years later. But the problem is really that we aren't preventing reverse engineering; we're banning independent thoughts. I'd accept raising the bar, but we'd have to really really strengthen the "obvious to one skilled in the art" test. For A to obtain a patent, it should be the case that, when faced with the same situation, same technical requirements, and same background knowledge, an expert practitioner B would almost never be able to reach the same invention.
Incidentally, I think you have your causation backwards: as technologies became important, there was a desire to monopolise inventions (so as to keep newcomers out of the field), and so "lobbying" pressure arose to create patent laws. Note that, for example, most chemical companies are in Switzerland: they were founded there because, at the time, Switzerland had no patent protection for chemicals, and so companies could grow there after escaping litigation elsewhere.
Pharma is the one industry where patents might be tolerated, as a pragmatic exception, not a correct one.
Seriously...there is no positive side to patents excepting the sense of mutually assured destruction. Patents are good for lawyers, but hurt innovators, consumers, and the development of technology. (It's true that the current system is badly broken, but I'm not advocating scrapping it because it's too hard to fix; I'm advocating scrapping it because it's wrong in principle and in practice).
Yes, it's true that investors like to see patents - but if nobody had them, that wouldn't matter.
Also, remember that most investors invest in companies that build things, not that innovate. As Edison said, the 1% inspiration may be necessary, but it's nowhere near sufficient for success. What a new company needs isn't a phantom of the potential to sue; what it needs is certainty that it will be protected from predatory IP enforcement.
Incidentally, the patent system doesn't just hurt the economy and slow progress; it kills people. Take a look at this technical history of the aircraft, or the failure to cross-license for some of the combined anti-retroviral pills.
You have it backwards. The fallacy with patents is to always see oneself as the person with the patent using it so no one "steals" your idea.
Actually, the risk is that if you have a company with a product, you will be destroyed by a "troll" who sues you.
[Also, the concept of owning ideas is itself wrong: think "standing on the shoulders of giants"]
I accept that if we scrap the patent system, we would have no way to protect small companies against cloners (though they'd still have first-to-market advantage). But we already can't protect small companies: a predator can already crush them by finding something they infringe.
Yes...but surely there's a market for a good, less expensive hearing aid that is either wired (like an iPod), or slightly bulky (like a bluetooth headset)?
Actually, why hasn't anyone tried to modify a bluetooth headset: pair with an android phone, do some DSP, and use the device in loopback mode?
What we need is a way for individuals and companies to opt out of the intellectual monopolies system altogether. Something like "I promise never to asset an intellectual monopoly against anyone (except defensively); in return, I obtain the right to never be sued". It really needs a whole country to be brave enough to unilaterally scrap the patent system: and whichever one does this first will make a fortune from investment. Think "tax-haven" but where's it's really a "freedom to innovate haven".
I always thought these were "toys" - but having received one as a gift, which can do x400, I'm pretty impressed with it. (Also, just works under Linux, as a v4l device).
You might also consider an SLR camera with a macro lens: you can pick up an Olympus OM1 for about $20 on eBay, and add a 300mm macro lens for perhaps $30.
* It's reasonably clear (from most guidelines) that session cookies are fine, (because they are essential to functionality). Furthermore, implict consent is given by the act of logging in,
* Long term preference cookies "remember my name and my customisations" are also OK, though it's usually good practice to notfiy the user (the T&C is sufficient for this).
* Analytics cookies (eg Google Analytics) really should be covered by the directive, but basically aren't.
* Evil (cross site advertiser tracking cookies) ought to be exterminated...but these ones can simply be consented into, without really understanding.
I think you're looking too late in the cycle. Enterprise devs in Fortune 500 made their choices 5 years ago; I'm talking about the people who are making their choices now. Consider at the moment that Android is rapidly overtaking iOS. Here's why:
- Much greater ease of entry (Eclipse is a free download; for iOS, first I need a Mac computer, then I need to buy Xcode)
- More powerful platform (some apps simply can't be written for iOS, because it is too locked down)
- No Apple AppStore policy (OK, the app store is great for quality control, but why shouldn't I write an app that competes with an Apple native features, or that runs an interpreter, or that tethers without carrier-support, or that has my own payment method, or that supports unapproved content?)
Also, the Macbook hardware is pretty good (especially compared to some Windows offerings). But as Woz points out, just because Apple are doing well doesn't mean that they can't do better!
Here are some things Apple could/should do to become (again) good citizens of the engineering community. They'd see a huge surge in developers and technical users if they do this. As it is, most techies cannot use or recommend Apple in good conscience.
1. Political. Join OIN, and pledge never to sue first for patent infringement. Also, stop trying to buy bad laws. Pledge not to sue any open source project for patent infringement (eg font hinting). Make its media codec patents available to HTML5 without royalty.
2. It's *my* hardware if I buy it. Guarantee the ability to Jailbreak all devices. This is a win for users, a win for tinkerers, a win for some customers who need to run their own arbitrary code, and a win for security (exploits get fixed, rather than hoarded for jailbreaking purposes). I'd be perfectly happy to accept a compromise where a jailbroken device loses some DRM features. Root shouldn't be available by default (most users rightly want it simple, and to trust Apple to look after them), but should be available on request to anyone who is competent enough to run a CLI program.
3. Support all open standards where possible. For example, the iPod still can't play Ogg files. There's NO good reason why not: the cost is zero, and the hardware is capable. Likewise, the newest iPods won't work on Linux: Apple could very easily give a couple of free devices and some documentation to the libgpod project each time they release a new model. (this would be far cheaper than supporting native iTunes). Likewise, support for NFS as a media repository.
4. End the misfeatures for the purposes of lock-in, I've so often experienced this: it's like buying a shiny new car, and finding someone has deliberately welded an upturned thumbtack to the driver's seat. Every product has a sting in the tail - not because it can't do something, but because it won't. I can't be the only one who finds this frustrating.
5. I'd love to see a bit of extra focus on hobbyist and educational development. Perhaps Apple could stock the Raspberry Pi / Arduino, and Apple stores might sell items for geeks (eg bare iPod connectors for DIY docks, USB-to-Relay adaptors, and the tools usually made by iFixit).
The trick is to write the CSS as a PHP file, but make sure it is only parsed rarely, and cached. On the server, create "style.php" (linked from thje main HTML just as if it were a normal style.css file). Then fix the caching and mime-type. Result: easy to write, still efficient.
//Respond with 304 (not-modified) unless the file is changed. This means the PHP file is only evaluated once per client per session.
$last_modified_time = filemtime(__FILE__);
$etag = md5_file(__FILE__);
header("Last-Modified: ".gmdate("D, d M Y H:i:s", $last_modified_time)." GMT");
header("Etag: $etag");
if (@strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) == $last_modified_time ||
trim($_SERVER['HTTP_IF_NONE_MATCH']) == $etag) {
header("HTTP/1.1 304 Not Modified");
exit;
}
$max_age=600; //10 minutes.
header("Cache-Control: max-age=$max_age"); // HTTP/1.1 (Client won't even try to reload more than every 10 mins).
header("Content-type: text/css"); //Set the mime-type to CSS (so the browser will cope with it.)
//Now write out the CSS, using PHP to help make it more terse.
What we need is a viral anti-patent system, designed to be stronger than the GPL with the intention of destroying the patent system together. Like OIN (the open invention network), but with real teeth. Here's how it would work:
0. Philosophy: intellectual monopolies are completely wrong, opposed to the scientific method, economically evil, and morally unjustified. Nobody can own an idea, and everyone stands on the shoulders of giants.
1. Create a "public patent foundation" (PPF) similar to the FSF.
2. Anyone with an invention can grant their idea (or patent) to the PPF. Anyone may license a PPF patent, royalty free, provided they are not involved in offensive patent litigation.
3. The PPF makes its patents available to anyone for the purposes of counter-suit.
No matter who you are, if you are the victim of a patent lawsuit, then (unless you fired first), the PPF will lend any of its patents to you for you to counter-sue the aggressor..
4. If the PPF wins a lawsuit, the settlement terms would include all patents of the loser being shared with the PPF.
5. The result is that the PPF would eventually hold a large majority of the patents worldwide. It would allow anyone to use these, royalty free, but would demand that users of PPF patents covenant never to sue in a patent lawsuit.
6. As a pragmatic (but non principled exception), we might exclude pharma-patents from this.
I have a (UK) project involving a certain chip manufactured by Rockwell. There is an exceptionally terse datasheet available online. I asked for a a little more, and Rockwell, while courteous, basically declined to help me, citing ITAR. The chip is a CCD (sensitive to the infra-red), but otherwise nearly obsolete, and the datasheet I wanted was something similar to the common documentation for the 555 timer chip. The idea that I might build a guided missile out of this thing is laughable.
For anyone who hasn't encountered Mr Lehrer, I recommend a Youtube search for "Lobachevsky"
Actually, it can be quite useful having 2 different clipboards, if used thoughtfully. Otherwise, klipper or parcellite can unify them for you if you want.
Here is some research into the actual safety figures in deaths per TWh generated:
http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy-source.html
As you surmise, Coal is the worst. Nuclear is the safest, bar none, beating Solar/Wind/Hydro.
The optimal solution (right now) is to build some more Gen IV reactors (such as the "Integral Fast Reactor"): this
uses far less uranium, and burns up the lanthanides in situ, yielding very small amounts of waste that are safe
[same level as the uranium ore] within 200 years.
Having done basically this, I suggest you use Cat6-S (the shielded version). More expensive, unnecessary for networking, but it does reduce the general amount of RFI present. Likewise, if you have fancy computerised dimmers. We have both, and our electrically operated curtains(*) now occasionally act like we have a poultergeist!
(*) We're not that lazy, but these ones are inaccessible.
Seems to me that the UK should forbid our carriers from complying with this.
Shouldn't this be handled at the datalink level by the wireless hardware? If there's transmission errors due to noise, more bits should be dedicated to ECC codes. The reliability is maintained at the expense of (usable) bandwidth and the higher layers of the stack just see a regular link with reduced capacity.
Yes, it certainly should be. But it often isn't.
Incidentally, regular ECC won't help here: adding 1kB of ECC to 1KB of packet doesn't help against a 1ms long burst of interference, which obliterates the whole packet.
Yes...which is why DHCP shows the problem even more severely. DHCP needs 4 consecutive packets to get through OK, and when the environment is noisy, this doesn't happen. But the same happens for TCP, mitigated (slightly) by TCP having a faster retransmit timeout.
My point still stands:
Symptom: packet loss.
Common cause: link saturation.
Remedy: back off slightly, and hope everyone else also notices.
Symptom: packet loss (indistinguishable from the above)
Less common cause: RF interference because the AP is near the edge of range.
Remedy: try really hard, and flood the link with repeats to get at least some packets through.
In the wireless example, we still have a dedicated 10 Mbit link, it's just really unreliable. Being profligate with packets might get me 25% of 8 Mbit/s; being conservative with packets, would back off to perhaps 90% of 0.01 Mbit/s.
There is one other problem: TCP assumes that dropped packets mean the link is saturated, and backs off the transmit rate. But Wireless isn't like that: frequently packets are lost because of noise (especially near the edge of the range). TCP responds by backing off (it thinks the link is congested) when actually it should be trying harder to overcome the noise. So we get really really poor performance(*).
In this case, I think the kernel should somehow realise that there is "10 MB of bandwidth, with a 25% probability of packets returning". It should do forward-error correction, pre-emptively retransmitting every packet 4x as soon as it is sent. Of course there is a huge difference between the case of lots of users on the same wireless AP, all trying to share bandwidth (everyone needs to slow down), and 1 user competing with lots of background noise (the computer should be more aggressive). TCP flow-control seems unable to distinguish them.
(*)I've recently experienced this with wifi, where the connection was almost completely idle (I was the only one trying to use it), but where I was near the edge of range from the AP. The process of getting onto the network with (DHCP) was so slow that most times it failed: by the time DHCP got the final ACK, NetworkManager had seen a 30 second wait, and brought the interface down! But if I could get DHCP to succeed, the network was usable (albeit very slow).
Unfortunately, I think you haven't quite got this right.
The problem isn't buffering at the *ends* of the link (the two applications talking to one another), rather, it's buffering in the middle of the link.
TCP flow control works by getting (timely notification of) dropped packets when the network begins to saturate. Once the network reaches about 95% of full capacity, it's important to drop some packets so that *all* users of the link back off and slow down a bit.
The easiest way to imagine this is by considering a group of people all setting off in cars along a particular journey. Not all roads have the same capacity, and perhaps there is a narrow bridge part way along.
So the road designer thinks: that bridge is a choke point, but the flow isn't perfectly smooth. So I'll build a car-park just before the bridge: then we can receive inbound traffic as fast as it can arrive, and always run the bridge at maximum flow. (The same thing happens elsewhere: we get lots of carparks acting as stop-start FIFO buffers).
What now happens is that everybody ends up sitting in a car-park every single time they hit a buffer. It makes the end-to-end latency much much larger.
What should happen (and TCP flow-control will autodetect if it gets dropped packet notifications promptly) is that people know that the bridge is saturated, and fewer people set off on their journey every hour. The link never saturates, buffers don't fill, and nobody has to wait.
Bufferbloat is exactly like this: we try to be greedy and squeeze every last baud out of a connection: what happens is that latency goes way too high, and ultimately we waste packets on retransmits (because some packets arrive so late that they are given up for lost). So we end up much much worse off.
A side consequence of this is that the traffic jams can sometimes oscillate wildly in unpredictable manners.
If you've ever seen your mobile phone take 15 seconds to make a simple request for a search result, despite having a good signal, you've observed buffer bloat.
Actually, even then, you might be OK if you use rsync. Rsync will allow you to do daily incremental backups with very little overhead. Of course, you still have to handle getting the first (full) backup made, and the cost of a full download if you need to recover. But that's not nearly as bad (and I believe there are some services will let you physically deliver a disk for initialisation).
The real problem is that these factories, operating under very poor conditions, drive down prices by competition. Therefore they outcompete western factories. But, they have a huge economic advantage: the near slave-labour conditions are enforced by the lack of democracy, and crackdowns on protestors/unions.
imho, China's lack of democracy is anti-competitive, and we should be imposing a "non-democracy surcharge" on imports from any country where the workers can''t protect themselves. (This isn't specifically to protect workers in China, it's to protect workers in the US/EU from downward pressure on working conditions).