This article points to a bunch of other efforts from the past. This list is most notably missing BEEP which also included the ability to multiplex multiple streams on top of TCP at the application layer.

I hope they're able to synthesize all of the thinking from these protocols into their work, and they bring this into the IETF and W3C for discussion when it's appropriate...

It makes me wonder if there's dark black fiber. Or is it black dark fiber... Either way, it's fiber that you don't know is there, and doesn't transmit any data.

So if you cut it, does it make a noise?

You are aware that "closest" in this context means "faster", aren't you?

Is your point that a host that's connected via T-1 that's a mile away is faster than a host that's connected on an OC-3 3,000 miles away? That is, based on knowing the geographic location of a host, you're saying it's somehow an indication of how fast my download will complete? That's the only thing that matters to me -- when will I have my completed bits. My only point here is that the information given in mirror selection is not enough to pick the "fastest" way to get what I want. It lists the geographical location and that's it.

Probably is too much a power user the one able to install the package "apt-spy" which will build a sources.list for you based on bandwith probes, isn't it?

Yes. Yes it is. If such a list can be generated, then why not just generate it in normal operation or list the mirrors based on the output of that tool? Though I do appreciate the tip, and I will try it. Obviously bandwidth and availability varies on a day by day basis. So taking a snapshot at one point in time seems like it will get stale.

Oh, and please, don't let parent post at +Insigthful when it's plain -Nonsense.

It's a legitimate end-user concern. "Which mirror should I select" should not be a user problem. The user wants his bits as soon as possible, which is a technical problem that has allegedly been solved with apt-spy. If that's the case, we should probably integrate that with the mirror selection process, and then you don't have to put up with all the "Nonsense".

Is it just me or is the fun game of "pick your closest mirror" not very fun at all? Just download the damn thing at best possible speed. I don't care where you get it from.

As if I'm in a position to pick the best site where to download something from. Give me a break. Apologies to the power users who can lick their Ethernet cable and tell which site will have the best download performance and availability.

I've been programming for 30 years or so, and I've been feeling ashamed. I've been feeling like I've done something wrong and that I haven't structured my programs right. That if only I was smart enough I would be able to take advantage of these multicore systems.

But I think I'm feeling better about myself. If I write rational multithreaded programs and use scalable patterns like producer / consumer, then I'll be pretty much ready to go.

And it seems like a lot of this isn't really relevant for desktop applications. I mean, there's some amount of keeping the main event thread moving so that your application is responsive, and you do time consuming operations on separate threads. But the only time I've really used a whole lot of threading is in server apps where you have a whole bunch of incoming connections that you're processing concurrently.

I understand that there is a branch of computer science that surrounds parallel computing, and there are some applications that might benefit from this (image processing being the canonical example). But I think it's another tool in the toolbox. Another way to approach a problem like map / reduce or whatever is in vogue. Some problems will benefit from being solved this way. Some won't. Use the right tool.

And I don't understand why we need to beat the drum for more efficient use of multicore. It's cool, we'll figure out what to do with all these cores. And then we'll put that in our toolbox and use it when appropriate.

I bought an Eye-Fi with a CF adapter that works fine in my digital Rebel.

Honestly, I don't see how these things would take off if they required rewiring your house just to be able to recharge them.

This is a perfectly valid sentiment, but given the realities of physics right now, I think it's inevitable.

Let's do some quick math. Essentially what we're talking about is the maximum amount of juice you can pump through a "normal plug". So this is 120 volts at a maximum of, let's say, 30 amps. If you plugged your car in, and it was perfectly efficient recharging the batteries, each hour you'd replenish 120 * 30 = 3600 watt hours of energy, or 3.6 kilowatt hours. Consulting the chart of gasoline gallon equivalents, you see that you need about 33.56 killowatt hours to equal one gallon of gasoline. So it's ten hours to get the equivalent of one gallon of gas in your car using a normal plug.

Now, if you up the voltage to 240 volts and the amperage to 70 amps, you get 16.8 kilowatt-hours from a one hour charge, which is better -- now we're up to two hours for a gallon of gas.

Now we get into "mileage". I've seen electric cars that can go 100 miles on 33.56 kilowatt hours. So for a range of 100 miles, you need to charge for two hours at 240 volts / 70 amps vs. ten hours at 120 volts and 30 amps. For some people, this is probably acceptable. For some people, they probably want the beefy charging infrastructure.