I've had problems every time I upgrade my laptop with the WEP key stored in the key chain getting messed up somehow. Took a huge amount of poking around to figure out what was going on, because the error handling was atrocious (Unix programmers take note). It didn't report anywhere that it couldn't retrieve the WEP key, it just failed to make a connection with no clue as to why. Of course, because there was no problem indication from the software and no official information from Apple on the problem (probably because they had no clue along with everybody else), there were literally hundreds of incorrect theories out there on the Internet as to what might fix it. And, of course, these dominate the Google search making it take days to find somebody who actually know what they were talking about.

In this case, the fix is trivial: Delete the WEP key with the keychain tools and let it ask again.

Depending on who you talk to, nuclear waste must be sequestered from 200,000 to more than a million years before it becomes safe.

It is completely absurd to claim that we have any sort of technology to do that. Remember that Engineering (as opposed to a lab experiment) is based on merging mathematics and physics with practical experience in getting real world results. The basic cycle is build, analyze, then factor the results back into the design process. A real world example is integrated circuits. We started out in the 60s with a couple dozens transistors on a chip and iteratively improved the design until now there are any millions of transistors on a chip. In terms of building long lived structures, some of the oldest lived man made structures on the planet are the pyramids: In round numbers, they are 5000 years old and failed at their intended purpose in prehistoric times (not to mention that the design data for them is long gone). Designing a waste storage facility to last a million years is like starting from scratch in 1960 with a chunk of silicon and immediately trying to design a 12 core, server class, CPU in the first design iteration. We are so inexperienced in the long term nuclear storage space we don't even know what the problems are!

The only way to get rid of the Nuclear waste is to recycle it (not reprocess, really recycle into something safe). AFIK, nobody has a clue how to do it or is even looking into the problem.

We so short sighted thinking it's all about us or the things we make:

How about the call of a Passeger Pigeon (for example):

There is still a lot of commercial software written in COBOL -- and as you say, almost everyone who knows it is retiring any time now.

Even back before the Y2K crisis at the turn of the century there was a shortage of COBOL programmers. Consultants were getting 2-3x the normal rates for fixing COBOL programs.

The same is also true of Fortran; although, it's close enough to other languages that most good programmers can things done if they have to.

They might actually be right... It is basically a radio transmission.

If you care, encrypt...

On another note. Smart phones are computers that are connected to the Internet; so, wouldn't the Computer Fraud and Abuse Act apply to them (and the use of a stringray to access them)?

I have several comments:

1. If you have side to side problems, there is something wrong with the lens. There isn't supposed to be any difference side to side. If your vendor can't fix it, go someplace else.

2. I find that my progressives are OK to use with LCDs for a while, but not with analog monitors. If you are still using analog monitors, get rid of them.

3. For long term use, I have some fixed glasses that are just for the computer distance (which is not the same as the reading distance). I keep a pair at work and a pair at home. At least for me, the computer prescription doesn't change much; so, the frames actually wear out before the lenses need changing.

4. If you need progressives, it is probably unreasonable to expect a bargain basement chain supplier to supply decent lenses. There is definitely a quality difference in lenses.

The first time, I asked which IP address the DOS was coming from. They gave me a 192.168.x.x address (which is, of course impossible), but I pretended to be looking it up in the router for 5 minutes to keep them on the line. Of course, I told him there was no computer with that address here. After wasting 5 minutes of his time, I told him there weren't any PCs here. That actually didn't stop him, he switched to a Mac script. Then I asked if the DOS was IP or TCP and he said neither. So I said that proved he didn't know what he was talking about; so, he put on his supervisor. After yanking the supervisor around with technical questions he couldn't answer (but tried to), I revealed that I knew it was a scam and was intentionally trying to waste his time. I also mentioned that he was an idiot who didn't know what he was talking about (with the other scammer listening in, no doubt). Who knew that Indians know so many English swear words (which actually might mean they aren't really in India).

That does get one put on their do not call list :-)

a) Longer cables do increase the noise on the line -- especially if they are cheap ones. That would explain tearing effects due to drop-opts.

c) Nothing wireless will be with 3 orders of magnitude fast enough to do this...

The actual announcement has this phrase in it: "... the following individuals are not currently on the No Fly List as of the date of this letter". They explicitly go on to state that "we make no other representations with respect to past or future travel". In other words, as soon as the court case is over, they go right back on the list...

Devices designed for standard outlets in the US aren't allowed to draw more than 12 amps continuous. At 120V (the standard voltage), that works out to 1440 Watts. One will find that many things are rated at that wattage, because one has to use a different plug to go beyond that. The outlet circuits are generally fused at 20 amps to allow more than one device to be plugged in (and there can be more than one outlet on the 20A circuit).

Packet loss and latency are both significant. The recovery time from a single packet loss is proportional to the latency.

Large windows should still help; although, there might be some rare situations where they make performance worse (if the network they are on is saturated and the extra traffic pushes it past a tipping point so packet loss increases).

When one is dealing with large windows, even 0.01% packet loss hurts. This is because it takes longer to get back up to full speed after a packet loss. It will still be faster than a smaller window size, but the packet loss will eat away more overall throughput than it would with a smaller window size.

Yes, if they are following the RFCs, they can use up to 4 packets (assuming the MTU is small) for the initial congestion window. That cuts two RTTs off the ramp up time (very roughly 10%). The last time I checked, web sites were usually transferring less than 100K bytes -- The use of 4 packets for the initial congestion window should actually help them a lot more than having a large window size (that they will never actually ramp up to). Where the large window sizes really help are large uni-directional transfers (ftp, sftp, etc).

Large window sizes only help when there is absolutely no packet loss (which is not the Internet) and even then it takes a long time to scale up. Even when there is a large window size, the slow start mechanism is really really slow when the RTT is in the 100 msec range (the Internet). If you have regular low level packet loss, the actual throughput plot looks like a sawtooth wave and the upward ramp is very slow. The congestion window rarely even gets close the max allowed by the window size in the TCP header. It can take several minutes for the congestion window to ramp up with 100msec latency.

SACK might help a little bit if implemented properly, but even SACK is still required to do the slow start congestion avoidance.

There are RFCs (I haven't had time to read, yet) where routers get involved with congestion control. But the RFCs haven't become standard, yet, and the chances that every router in an Internet path supports them is probably negligible.

The kind of cryptography you would need to make this safe (as posted earlier) is Public Key. The big problem with that is teaching ALL the voters how to use it. And we aren't even talking about distributing the software or handing out keys: That's easy compared to the training...

TCP performance on the Internet is almost totally limited by latency (AKA RTT or round trip time for the ACKs), not the bandwidth.

Streaming data isn't limited by the latency -- totally different beast.

Verizon's analysis would indicate that's not the case, unless the Netflix traffic is multicast, but the traffic is on demand; so, I kind of doubt much of it is multicast.

Even if it is, Verizon's customers are paying for for bandwidth at the edge of the network; so, they should be getting internal network support for that.