I must not be getting the article, because it seems that they're claiming impracticality, not impossibility. One learns in quantum computation 101 that with each qubit added to the system, computing the state of the system takes an exponentially larger amount of time because the state of the systrm is the cross product of the states of the components.
So you don't have to go into anything as esoterical as the quantum Hall effect to find that a linear increase in the complexity of a quantum system requires an exponential increase in computing power to simulate.
Worried about the eagles? Mining companies generally do surveys not to enhance a species' habitat but to destroy it. Oh, we're not allowed to harm eagles? NP, we'll just mine the shit out of their territory, and they can sustain themselves by preying on the leftover boulders. Yummy!
I completely agree. I think people's attention tends to focus on the one thing that's new in this equation. "Hyperloop completely depends on vacuum", therefore out of reflex people examine the scenarios where that one crucial dependency is suddenly unavailable.
Yet you correctly point out a much more serious implication of Hyperloop technology - it's proximity to the ground. Even if the tube could somehow be made break-away - that is, to offer the strength needed when the vehicle inside is performing nominally, yet to be completely flimsy if the angles of forces do not line up to within a strict tolerance, then, even though the tube would break apart like tissue paper if the vehicle started pushing unduly against the tube, or if an explosion were to destroy the tube, still, the vehicle would emerge from the tube travelling at a speed where any imperfection in the ground around it would probably cause it to become snagged, tip over its front, and otherwise become completely mangled.
Hmmm... emergency retro rockets?
...and I was just playing with the source control option...
If you're "playing" with a never-before-tried feature of a never-before-tried program while handing over control of your precious source code to it, you should at least back it up first.
Even if the court rules fair use, it's still a bad precedent, because fair use would subsequently have to be established for any and all future reimplementations of APIs - established in court. The risk of having to spend so much money just to prove fair use would likely put reimplementatipn out of reach for all but the most deeply pocketed companies, because, as a large company, you could suppress a potentially superior reimplementation simply by taking the upstart to court. This is uilty-until-proven-innocent. The onus must then be on the plaintiff to prove that it's not fair use, rather than on the defendant to prove that it is. And again, if it comes to that, the defendant will likely go belly-up long before any case sees the light of day. Law of the jungle:(
Actually a lot of creativity goes into the design of an API. You have to imagine what developers' code will look like as they use your API in various use cases. Will that code be legible? What abstractions do you implement? These are all design decisions - i.e. a creative process. Just look at the UNIX vs. Windows implementation of the API for launching a process: Windows is an ugly mess of filling out enormous structures, calling CreateProcess() and hoping you've crossed all your t-s and dotted all your i-s. In UNIX? fork() followed by exec(). BOOM! And I know both APIs do the same thing, because one has been implemented with the other (cygwin and wine).
So yeah... I can see Oracle's point.
IINM, the main egines were started at T-6.5s, so it should've been 7, main engine start, 6, 5, 4... I'll miss it, that's for sure. Hopefully, we'll have something better someday.
In Finland you get a piece of paper with everything filled out. You only need to mail it back if you make a modification, i.e., the tax office's information is out-of-date. So, yeah, the US is behind the times in this regard. Although, I guess, making a system work for over half a billion people is probably more complicated than making one work for five million people (int the case of Finland), not to mention the infamous complexity of the US tax system.
So, Trolltech was acquired by Nokia, but, IIRC, Trolltech has a kind of licence for QT that contains something dramatically labelled a "poison clause", or something like that. It's designed to prevent ever changing the license to a proprietary one, thereby closing the code. I'm not sure how it's done, but this blog post may be related.
Wars with the users about which features of Pidgin to implement, and why certain features have been dropped or changed have been waged repeatedly. If I may be so bold, I think I can summarize the Pidgin devs' attitude: "We're writing Pidgin for our own enjoyment and not for the purpose of attempting to gain as much IM client market share as possible. Nobody's forcing you to use it." They also use the "patches welcome" approach: "If you want a feature, write it, and we'll consider it."
I have probably mis-stated/-paraphrased/-summarized at least some of their opinion, so have a look at the Pidgin mailing lists and trac tickets for some animated discussions.
Perhaps it's by coincidence, but I recently read Robert A. Heinlein's short story named "Let There Be Light" from the collection of short stories entitled "The Man Who Sold The Moon". It speaks of ways of maximizing energy capture by using appropriately shaped quartz crystals. Took only, like, what, 65 years (since that story was first published)?
Wonderful, they come up with great cards, but their support for Linux still sucks badly. Their current Linux Radeon drivers do not even support XFree86 4.3.0 . Contrary to all this, nVidia has wonderful Linux support, so I'm stuck with a Radeon 9500 in my hand, and a nVidia GeForce2MX in my AGP slot:o(
I wonder why that is ? Let me guess: there have been so many convenience store robberies (most of them involving guns - for threats, not for use) that robbers decided it would be more economical to use toy guns - they don't have to fire them, just point them, right ?
The point is, it's a bad thing originated by the over-prevalence of guns.
I don't know about that. In Canada you don't even have Miranda rights, but we don't have absurd, DMCA-like laws and export regulations either.
Police do not necessarily fear for their lives when serving a warrant, yet nobody feels oppressed. The Government has never subjugated its subjects. Quite to the contrary, Canada has been called "the land of free cryptography" before. Furthermore, and despite all the previous examples, we are still the only country eligible for U.S. Defense contracts (AFAIK). An interesting asymmetry.
Slashdot Mirror
https://www.youtube.com/watch?...
"World Domination. Fast" -- Linus Torvalds
So you don't have to go into anything as esoterical as the quantum Hall effect to find that a linear increase in the complexity of a quantum system requires an exponential increase in computing power to simulate.
Worried about the eagles? Mining companies generally do surveys not to enhance a species' habitat but to destroy it. Oh, we're not allowed to harm eagles? NP, we'll just mine the shit out of their territory, and they can sustain themselves by preying on the leftover boulders. Yummy!
I completely agree. I think people's attention tends to focus on the one thing that's new in this equation. "Hyperloop completely depends on vacuum", therefore out of reflex people examine the scenarios where that one crucial dependency is suddenly unavailable. Yet you correctly point out a much more serious implication of Hyperloop technology - it's proximity to the ground. Even if the tube could somehow be made break-away - that is, to offer the strength needed when the vehicle inside is performing nominally, yet to be completely flimsy if the angles of forces do not line up to within a strict tolerance, then, even though the tube would break apart like tissue paper if the vehicle started pushing unduly against the tube, or if an explosion were to destroy the tube, still, the vehicle would emerge from the tube travelling at a speed where any imperfection in the ground around it would probably cause it to become snagged, tip over its front, and otherwise become completely mangled. Hmmm ... emergency retro rockets?
...and I was just playing with the source control option...
If you're "playing" with a never-before-tried feature of a never-before-tried program while handing over control of your precious source code to it, you should at least back it up first.
Kneejerk reaction: No, because this case was about implementation of the interface, not about linking to the library.
Even if the court rules fair use, it's still a bad precedent, because fair use would subsequently have to be established for any and all future reimplementations of APIs - established in court. The risk of having to spend so much money just to prove fair use would likely put reimplementatipn out of reach for all but the most deeply pocketed companies, because, as a large company, you could suppress a potentially superior reimplementation simply by taking the upstart to court. This is uilty-until-proven-innocent. The onus must then be on the plaintiff to prove that it's not fair use, rather than on the defendant to prove that it is. And again, if it comes to that, the defendant will likely go belly-up long before any case sees the light of day. Law of the jungle :(
Actually a lot of creativity goes into the design of an API. You have to imagine what developers' code will look like as they use your API in various use cases. Will that code be legible? What abstractions do you implement? These are all design decisions - i.e. a creative process. Just look at the UNIX vs. Windows implementation of the API for launching a process: Windows is an ugly mess of filling out enormous structures, calling CreateProcess() and hoping you've crossed all your t-s and dotted all your i-s. In UNIX? fork() followed by exec(). BOOM! And I know both APIs do the same thing, because one has been implemented with the other (cygwin and wine). So yeah ... I can see Oracle's point.
This case is not about use, but about reimplementation.
IINM, the main egines were started at T-6.5s, so it should've been 7, main engine start, 6, 5, 4 ... I'll miss it, that's for sure. Hopefully, we'll have something better someday.
Why not go whole-hog? http://www.catb.org/jargon/htm... I know I've spent hours rolling on the floor laughing and developing goosebumps reading that. And speaking of whole-hog: http://steve-parker.org/articl...
It depends on the book. I for one started reading Arthur C Clarke's Rama series, and I couldn't put it down.
There is such a thing. Freedom of speech only goes so far.
In Finland you get a piece of paper with everything filled out. You only need to mail it back if you make a modification, i.e., the tax office's information is out-of-date. So, yeah, the US is behind the times in this regard. Although, I guess, making a system work for over half a billion people is probably more complicated than making one work for five million people (int the case of Finland), not to mention the infamous complexity of the US tax system.
So, Trolltech was acquired by Nokia, but, IIRC, Trolltech has a kind of licence for QT that contains something dramatically labelled a "poison clause", or something like that. It's designed to prevent ever changing the license to a proprietary one, thereby closing the code. I'm not sure how it's done, but this blog post may be related.
Wars with the users about which features of Pidgin to implement, and why certain features have been dropped or changed have been waged repeatedly. If I may be so bold, I think I can summarize the Pidgin devs' attitude: "We're writing Pidgin for our own enjoyment and not for the purpose of attempting to gain as much IM client market share as possible. Nobody's forcing you to use it." They also use the "patches welcome" approach: "If you want a feature, write it, and we'll consider it." I have probably mis-stated/-paraphrased/-summarized at least some of their opinion, so have a look at the Pidgin mailing lists and trac tickets for some animated discussions.
Perhaps it's by coincidence, but I recently read Robert A. Heinlein's short story named "Let There Be Light" from the collection of short stories entitled "The Man Who Sold The Moon". It speaks of ways of maximizing energy capture by using appropriately shaped quartz crystals. Took only, like, what, 65 years (since that story was first published)?
Every mention of fingerprint-based "security" always brings to my mind a line from ST:TNG. I paraphrase (because I don't remember the exact words):
"I assume your hand will open this door whether you are conscious or not."
-- Data to the time traveller from the past
No, Windsor, ON is the strip club capital of Canada.
More strip clubs per capita than any other city.
Using ftp.ssh.com version of ssh:
This way, you get the security of ssh with the convenient P-t-P interface of vtund.
Problem solved.
Wonderful, they come up with great cards, but their support for Linux still sucks badly. Their current Linux Radeon drivers do not even support XFree86 4.3.0 . Contrary to all this, nVidia has wonderful Linux support, so I'm stuck with a Radeon 9500 in my hand, and a nVidia GeForce2MX in my AGP slot :o(
... Johnny Mnemonic, anybody ?
I wonder why that is ? Let me guess: there have been so many convenience store robberies (most of them involving guns - for threats, not for use) that robbers decided it would be more economical to use toy guns - they don't have to fire them, just point them, right ? The point is, it's a bad thing originated by the over-prevalence of guns.
I don't know about that. In Canada you don't even have Miranda rights, but we don't have absurd, DMCA-like laws and export regulations either. Police do not necessarily fear for their lives when serving a warrant, yet nobody feels oppressed. The Government has never subjugated its subjects. Quite to the contrary, Canada has been called "the land of free cryptography" before. Furthermore, and despite all the previous examples, we are still the only country eligible for U.S. Defense contracts (AFAIK). An interesting asymmetry.