It doesn't look like they took into account tipping for cab fares. A 15% addition to the Taxi fares would make Uber the clear winner in all cases, I think.
Is this a case where D-Wave was fraudulently trying to pass something off as quantum when they knew it wasn't, or did they really and truly not know. How could they not know?
Good job capturing the "steamroller effect"
on
Why Lavabit Shut Down
·
· Score: 5, Insightful
I think this is an important article because he does a good job of showing how the govt bullies people around -- and illuminating precisely why governmental power NEEDS checks and balances, like a functioning (not rubber-stamp) court and warrant system.
Moto's 3G and radio patents had real teeth. Heck, some of them might be actual, real, inventions....as opposed to the drivel that Apple's been flogging.
The moment my Nest changes my settings without me asking for it is the moment I ditch the device and go to a different brand. Yes, there's the auto-learn feature, but I have it disabled and have manually set my programs: and that better be the way it stays.
Peering fights are as old as the Internet itself. Just economics. Nothing to see here, move along. Vote with your wallets and pick ISPs that do a better job with their peering arrangements.
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.
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.
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.
"Although a five-axle tractor-trailer loaded to the current 80,000 pound Federal weight limit weighs about the same as 20 automobiles, the impact of the tractor trailer is dramatically higer. Based on Association data, and confirmed by its officials, such a tractor-trailer has the same impact on an interstate highway as at least 9,600 automobiles"
So every time you go through a tollbooth, ask yourself "why isn't this truck paying 9600 times more toll than me?" The answer: you are subsidizing that truck.
Actually, you're incorrect in your thinking. They were required to put GPS in it for E911 to work and the device will not function until the GPS location is verified.
As the owner of a microcell I can tell you that GPS reception is the biggest #$@!@# pain in the ass for the thing in general. I have a metal roof at home and the microcell will only activate for me if I hang the device in the skylight.
Seriously. It is difficult to express in words just how inefficient XMPP is as a protocol -- and this will be even worse! Sure, it's not a big deal on the client side, but real-world XMPP servers spend a substantial amount of time just parsing XML stanzas...and this would be a worst-case for them. Wow.
Yes, for long-running servers, GC performance can still be a very big issue with Java (and all GC languages). For short- or medium-lived apps (the kind that you're more thinking about -- since you talk about VM and library load time) GC performance is less of an issue.
"To imitate the sudden freezing, thawing and overheating of a notebook, I put each system into the freezer at 25 degrees Fahrenheit and let it sit there for 15 minutes. After they were allowed to warm up, I put them into an oven set to 175 degrees Fahrenheit for 15 minutes."
15 minutes at 25 degrees? Come on -- find me a laptop, rugged or not, that *couldn't* do this. What a useless test.
Slashdot Mirror
Want to pursue a STEM or other high-paying degree? No problem, but you have to pay a lot more for your degree.
It doesn't look like they took into account tipping for cab fares. A 15% addition to the Taxi fares would make Uber the clear winner in all cases, I think.
This is almost certainly a firmware bug with their read disturb compensation. At least they're owning up to it - but wow.
Is this a case where D-Wave was fraudulently trying to pass something off as quantum when they knew it wasn't, or did they really and truly not know. How could they not know?
I think this is an important article because he does a good job of showing how the govt bullies people around -- and illuminating precisely why governmental power NEEDS checks and balances, like a functioning (not rubber-stamp) court and warrant system.
Moto's 3G and radio patents had real teeth. Heck, some of them might be actual, real, inventions....as opposed to the drivel that Apple's been flogging.
The moment my Nest changes my settings without me asking for it is the moment I ditch the device and go to a different brand. Yes, there's the auto-learn feature, but I have it disabled and have manually set my programs: and that better be the way it stays.
Looks like a SCM merge error to me. That kind of stuff happens, unfortunately...
Peering fights are as old as the Internet itself. Just economics. Nothing to see here, move along. Vote with your wallets and pick ISPs that do a better job with their peering arrangements.
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.
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.
The Internet has needed a standardized reliable UDP protocol for many years. There have been many attempts, but hopefully this one will stick.
There's still a glidepath indicated by visually by the PAPI at a 2.85 degree slope for 28L at SFO.
My Bad: 3.8NM is just about 2 minutes at Vref, not 3 -- using 130kts as a placeholder (ie 2NM/min). Point still holds.
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.
This is written like a troll, but is actually the most sensible thing that's ever been written about IPV6
Go to page 23:
"Although a five-axle tractor-trailer loaded to the current 80,000 pound Federal weight limit weighs about the same as 20 automobiles, the impact of the tractor trailer is dramatically higer. Based on Association data, and confirmed by its officials, such a tractor-trailer has the same impact on an interstate highway as at least 9,600 automobiles"
So every time you go through a tollbooth, ask yourself "why isn't this truck paying 9600 times more toll than me?" The answer: you are subsidizing that truck.
Actually, you're incorrect in your thinking. They were required to put GPS in it for E911 to work and the device will not function until the GPS location is verified. As the owner of a microcell I can tell you that GPS reception is the biggest #$@!@# pain in the ass for the thing in general. I have a metal roof at home and the microcell will only activate for me if I hang the device in the skylight.
You're right, because no passengers should be allowed to talk on the phone either....
seriously: my wife teaches high schoolers, she made a comment about The Matrix and got a whole room of stares in response. 1999 was 12 years ago...
Seriously. It is difficult to express in words just how inefficient XMPP is as a protocol -- and this will be even worse! Sure, it's not a big deal on the client side, but real-world XMPP servers spend a substantial amount of time just parsing XML stanzas...and this would be a worst-case for them. Wow.
it's been a long and storied run
Yes, for long-running servers, GC performance can still be a very big issue with Java (and all GC languages). For short- or medium-lived apps (the kind that you're more thinking about -- since you talk about VM and library load time) GC performance is less of an issue.
"To imitate the sudden freezing, thawing and overheating of a notebook, I put each system into the freezer at 25 degrees Fahrenheit and let it sit there for 15 minutes. After they were allowed to warm up, I put them into an oven set to 175 degrees Fahrenheit for 15 minutes."
15 minutes at 25 degrees? Come on -- find me a laptop, rugged or not, that *couldn't* do this. What a useless test.
It might be more useful if you actually explained WHY they were different.