I'm not sure how practical your idea would be since the player would either have to be turned on when you plugged in the headphones or it would have to constantly use battery power to monitor the headphone jack. If you're turning on the player manually it's not much harder to just hit the play button.
I'm sorry, but this is just plain wrong. Headphone jacks that sense the presense of a plug generally do so by a mechanical switch. Just like a power button, this switch does not have to be "monitored".
Even if such a switch did not already exist in every iPod in production, how hard could it possibly be for your average EE to figure out how it could be done, given that the user is already plugging a piece of metal into their iPod every time they plug in the earphones?
Sorry, RailCorp, facts aren't copyrightable. As long as the developer of Transit Sydney uses a presentation or layout that differs from that used by Rail Corporation, their claim is not valid.
IANAL.
Leaving aside the question of whether facts are copyrightable (another post suggests that when Crown copyright gets involved they are in at least some cases), the basic contention made by RailCorp in the portion of the article quoted in the summary is that the railroad timetables are *not* facts.
Quantum mechanics applies to a *lot* more than just spin of photons. To name just one example, the classic double-slit experiment demonstrates quantum (or at least non-classical) behavior of the amplitude of light.
IMO, even if it's true that every "quantum system" developed up till now has been based on photon spin (which I don't believe), any system which depends on a quantum effect would qualify as a "quantum system." Note also that entanglement is not the only quantum effect which might be relevant here.
To be fair, Windows is probably proportionally about as much larger than (the default install of) OpenBSD as OpenBSD is than DJBDNS.
So you ought to allow Windows about 9 vulnerabilities in that time;-)
Seriously though, I wonder what sort of rate expected number of vulnerabilities should increase with respect to size of a codebase, given somehow equivalent levels of "correctness". Intuitively, i suspect it'd be at least O(size^2), if not much, much faster.
I agree on both points (especially OmniGraffle!), but just thought I'd point out that one often does not have the privelege of using one's apps in a vacuum.
For example, I run Eclipse inside a Windows VM because the Java code I'm developing interfaces to commercial Windows-native code. I could develop "remotely" from the host OS, but it would be a fair bit of hassle just to replace a solution that works.
Slashdot Mirror
Yes, but you need to remember the ranking.
Less evil than Google
More evil than Microsoft
I lived through the OS/2 wars. "More evil than Microsoft" is not a phrase I can allow to *exist* unchallenged.
I'm not sure how practical your idea would be since the player would either have to be turned on when you plugged in the headphones or it would have to constantly use battery power to monitor the headphone jack. If you're turning on the player manually it's not much harder to just hit the play button.
I'm sorry, but this is just plain wrong. Headphone jacks that sense the presense of a plug generally do so by a mechanical switch. Just like a power button, this switch does not have to be "monitored".
Even if such a switch did not already exist in every iPod in production, how hard could it possibly be for your average EE to figure out how it could be done, given that the user is already plugging a piece of metal into their iPod every time they plug in the earphones?
Sorry, RailCorp, facts aren't copyrightable. As long as the developer of Transit Sydney uses a presentation or layout that differs from that used by Rail Corporation, their claim is not valid.
IANAL.
Leaving aside the question of whether facts are copyrightable (another post suggests that when Crown copyright gets involved they are in at least some cases), the basic contention made by RailCorp in the portion of the article quoted in the summary is that the railroad timetables are *not* facts.
Quantum mechanics applies to a *lot* more than just spin of photons. To name just one example, the classic double-slit experiment demonstrates quantum (or at least non-classical) behavior of the amplitude of light.
IMO, even if it's true that every "quantum system" developed up till now has been based on photon spin (which I don't believe), any system which depends on a quantum effect would qualify as a "quantum system." Note also that entanglement is not the only quantum effect which might be relevant here.
To be fair, Windows is probably proportionally about as much larger than (the default install of) OpenBSD as OpenBSD is than DJBDNS.
So you ought to allow Windows about 9 vulnerabilities in that time ;-)
Seriously though, I wonder what sort of rate expected number of vulnerabilities should increase with respect to size of a codebase, given somehow equivalent levels of "correctness". Intuitively, i suspect it'd be at least O(size^2), if not much, much faster.
I agree on both points (especially OmniGraffle!), but just thought I'd point out that one often does not have the privelege of using one's apps in a vacuum.
For example, I run Eclipse inside a Windows VM because the Java code I'm developing interfaces to commercial Windows-native code. I could develop "remotely" from the host OS, but it would be a fair bit of hassle just to replace a solution that works.