Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Thought: different engine (Score 3, Informative) 734

Turbines really don't do well with stops and starts, particularly when hot. If you could setup a system where the turbine ran continuously for a longish period and then shut down for a full cool down cycle: then yes, I think it might be a good match...but in general that load pattern doesn't match very well with automobile transportation. Perhaps batteries really are large enough now to make that work.

My experience with turbines has been that startup is always a risky operation and that every start has a small but real chance of causing catastrophic failure. Its hard for me to imagine they'll ever be robust enough for mass market use in something like an automobile....but who knows, technology is always getting better.

Comment Re:Thank you (Score 2) 141

No, you really don't understand what this is useful for. They aren't "reinventing TCP" because they think they can do it better: they have a different problem domain and can do better than TCP for their specific problem.

TCP insists on strong ordering of data: it provides reliability AND ordering. Sometimes you don't want both of these, and giving up one or the other can get you big benefits.

For example, there are many classes of problems where you want reliability but are willing to lessen the ordering requirements (networked gaming is a common example) because you want the lowest possibility of latency. By not requiring a strict ordering you can avoid stalls and get data sooner: when a packet is lost in TCP the driver has to buffer the data until it gets retransmitted. For a concrete example, if packet #99 in a TCP stream is dropped, even though your machine has received packets 100-2000 it can't give them to your application until 99 has been retransmitted....since the TCP contract is for strict ordering. This leads to significant latency effects under packet loss, and is one of the reasons why people use UDP.

Comment This /. headline is sensationalist drivel (Score 5, Insightful) 248

Yes, they were below the glidepath, and yes they blew the approach and had to go around: but this is hardly seconds from disaster or even a close thing. 600' at a normal approach speed is not "close" to the ground and 3.8 NM is more than 3 minutes at Vref which is certainly adequate time to respond.

These kinds of things happen and the only reason we're even hearing about this one is that it happened at SFO 28L.

I expected a little less sensationalism and a lot more intelligence from slashdot.

Slashdot Top Deals

Duct tape is like the force. It has a light side, and a dark side, and it holds the universe together ... -- Carl Zwanzig