No sane airline would *allow* the President to fly commercially. It would be like painting a red target across its metaphorical face and daring terrorists to attack them, in return for less money and staggeringly-higher security expenses than it would otherwise have if normal people bought the tickets. And when the inevitable attack *did* happen, they'd get hit by lawsuits from everyone who ended up being "collateral damage". The amount of money they'd have to charge to guarantee that the service would be revenue-neutral for them (taking into account things like attacks) would probably be four times the amount we currently pay for the Secret Service and military to handle the logistics.
One bit of info that *might* be of interest... cell phone towers beacon to announce their presence to phones, but individual phones actually *poll* towers every few seconds. The reply from the tower lets them know when there's an incoming call, deliver SMS & voicemail notifications, etc. In theory, at least, if the mobile phone of any passenger came within range of a cell tower it was allowed to poll, there's probably a log of it somewhere.
That said, if the jet was at cruising altitude, the likelihood of a phone on board *doing* that is almost nil, because tower antennas are generally aimed downwards... partly, to minimize interference from airborne mobile phones that could otherwise splatter noise over a 40-100 mile radius (the line of sight when your transmitter is 5+ miles up in the air).
And how many atoms thick does the insulating layer between adjacent photosensitive or photoemitting structures need to be to prevent light emitted by one pair's LED from unduly influencing the state of an adjacent photodiode/phototransistor?
What, exactly, is the benefit of building a chip whose internal connections are basically all optoisolators?
Do the new AMD64-architecture assembly-language opcodes to do AES encryption and decryption count?
Of course, there's also ARM. It's not new, of course, but programming ARM in assembly language is kind of a recent developmen (though I'd conservatively estimate that at least 20% of assembly-language ARM code is probably malware).
In theory, you can even do JVM assembly. It's kind of pointless and masochistic, but people have done it just to say they have.
For anybody who knows... could a radar system partly or completely side-step the Doppler Dilemma ( http://en.wikipedia.org/wiki/W... ) by doing DSS or FHSS and cycling through a sequence of different carrier frequencies from pulse to pulse?
The problem is, there's no way to safely STORE large numbers of Bitcoins. Banks can store a trillion dollars with zero risk by depositing it at the Fed. The Fed notes the deposit, backs up the record in multiple places with enormous amounts of redundancy, then shreds any actual currency that was part of the deposit because it doesn't NEED it. It can always print new bills to replace the deposited ones should the need arise.
With Bitcoin, a bank can't do that. If a bank stores a thousand Bitcoins somewhere in exactly one super-secure location, and the medium on which they're stored gets physically destroyed, those Bitcoins are as gone as the money from depositors at a Wild West bank that just got robbed & had its vault emptied. Or boxes of British Pounds on a sunken ship resting in the middle of the Atlantic Ocean circa 1880.
With virtual Dollars that exist only as bookkeeping entries at the Fed, geographically-dispersed redundancy increases robustness and security. With Bitcoins, it increases their likelihood of loss by malware or theft. The only way to protect Bitcoins is to store them in a non-networked environment... but if you're burning a thousand bitcoins to BD-R discs and transporting them to vaults around the country, you'd better have armed security guards watching the discs, because a single stolen disc could be worth literally millions. If you're encrypting them and transporting them over a network, you're gambling on the encryption key not being compromised. If you're printing the base64 hashes to exactly one -piece of paper per Bitcoin and storing them in a vault, you're gambling on the vault not getting stolen or destroyed. And ultimately, you have to transfer that Bitcoin back to a networked computer in order to spend it... and all it takes is one bit of malware at that instant to completely negate everything you did up to that point to store it safely.
There's a reason why businesses don't like to handle large amounts of cash -- it's dangerous. And the danger increases exponentially with the amount. With Bitcoins, everything is effectively a cash transaction, with all the real-world risks that entails.
Or if you want to be cute, and you can hack your router's firmware a bit to auto-map internal ipv4 to external ipv6, you can ignore the fact that the underlying representations are fundamentally different and do something like:
internal device #1 = 192.168.100.101
external ipv6 prefix = 2001:44b8:6116:5aff::
internal device #1's public ipv6 address: 2001:44b8:6116:5aff:192:168:100:101
There's no law that says the lower bytes of your ipv6 address HAVE to be some god-awful value. As the parent noted, you could quite legitimately assign ip addresses to devices on your local network as 2001:44b8:6116:51ff::1, 2001:44b8:6116:51ff::2, 2001:44b8:6116:51ff::3, etc.
You can even make up addresses that spell cute things, like:
2001:44b8:6116:51ff:B16:B00:B5:1 ("Big Boobs 1"), 2001:44b8:6116:51ff:f00d:f00d:dead:beef, etc.
If you can deal with remembering a public ipv4 address and a dozen 10.x.x.x or 192.168.x.x addresses with inbound port-mapping rules, you can translate the whole thing to a scheme for assigning internal addresses that you can still remember.
AFAIK, no mobile network in existence will even route inbound TCP/IP. At one time in the distant past, Sprint would relay up to a few bytes per second sent as UDP to the public IPv4 address of a phone connected via 1xRTT, but they pulled the plug on THAT sometime around 2006.
I know that today, T-Mobile (and probably others) have begun to use the US DoD class A (or at least a hefty chunk of it) as a de-facto private address space for non-routable ipv4 addresses assigned to phones.
Actually, to legally copy a drug in India, you'd have to come up with a new process for manufacturing it. Indian IP law recognizes only manufacturing processes, not the final chemicals themselves or the purpose for which they're used.
Case in point: in America, you can take a drug like Proscar, approved in 5mg strength for treating prostate problems, and get a brand new patent for a 1mg strength used for hair growth. In India, you'd be politely told, "No" when you applied for the second patent, because as far as Indian IP law is concerned, unless you come up with a new way to manufacture the drug, you've done nothing worthy of patent protection.
The same goes for extended-release forms. If you're taking an old drug and coating bits with dissolving coating, India will yawn and say, "sorry, no new patent for you. " You'd have to come up with something groundbreaking, like OROS ( http://en.wikipedia.org/wiki/O... ), which makes drugs that would otherwise have intolerably-short half-lives viable.
Although Indian IP law doesn't regard ER forms as necessarily being special, India's unwillingness to allow patents on anything besides the manufacturing process actually opens the door to Indian pharmaceutical companies releasing ER forms LONG before the original patent expires, and before the American developer of the original drug comes out with its own version. If an Americana pharma company gets a patent on a drug & plans to wait until the first patent is about to expire before patenting an ER form, an Indian company who comes up with an alternate manufacturing process can blow their plan out of the water and release an improved ER form YEARS sooner.
So... you're thinking the introduction of government into this system will make the system cheaper and higher quality?
Cheaper? Probably not, if the government in question plays the role of neutral utility who lays the pipes, then provides service for end users to consume as they see fit, and doesn't screw things up with subsidies.
Higher quality? As long as the government literally does nothing besides lay and maintain the fiber, and keep the NOC running with five-nines uptime and off-grid backup power (providing switch fabric between fibers so OTHER companies can provide the actual service), almost certainly it'll be better than what we'd get NOW from Comcast and AT&T. We might end up paying "pure platinum" prices for service that's merely gold-plated, but overpriced gold-plating looks pretty damn appealing when the alternative is artificial scarcity and decaying infrastructure.
Nature is wildly overrated. A captive-bred tiger, lion, leopard, jaguar, or cougar in Florida or Texas has double the average lifespan of his or her cousins in the wild.
I think it's safe to say that if society is in a state of collapse and normal medical care doesn't exist anymore, the risk that a particular antibiotic will be sub-optimal due to age or storage conditions lies rather low on the hierarchy of concerns. Especially if it IS stored under optimal conditions from the moment of purchase.
One semi-drug that IS insanely unstable is methylcobalamin (which is actually vitamin B-12, in a form that can cross the blood-brain barrier and is a wonder drug for cats with diabetic neuropathy). The problem is, there's no shelf-stable form of it, so it has to be FedEx'ed in an ice chest every 2-3 months, stored in an opaque container in the refrigerator, and loaded into the syringe in the dimmest light possible to keep it from losing potency. You almost have to treat it like film in a darkroom. But god, that stuff was magic for my kitty and worth every penny. In two weeks, he went from being barely able to walk without twitching and resting with his nose on the floor to climbing stairs, climbing onto and off of the bed, and holding his head up.
There ARE oral sublingal forms of methylcobalamin, but every USP human formulation contains xylitol, which is toxic to cats. The only brand (as of last year) that's xylitol-free and explicitly made for cats is Zobaline (the feline-safe version of Xobaline). It's debatable how much benefit the cat will actually get from sublingal methylcobalamin compared to the injected form, but if you DO decide to try it, make SURE it's xylitol-free.
Exactly. Moto didn't lock bootloaders because they were forced to by evil carriers like Verizon... they did it out of religious zeal, and a belief that it was a moral imperative.
To remake Motorola in Google's image, they would have had to literally fire most of Motorola's managers, and would have probably had to fire at least 10-30% of their engineering staff as well. They were able to do enough housecleaning to make the Moto-X and Moto-G happen, but Google knew that the rest of the company was too toxic to ever fully decontaminate.
Question: did you literally upgrade to every version of OSX since 10.4? I could *swear* I remember seeing a lot of posts at GearSlutz about one Apple's past few releases (Lion or Mountain Lion, I think).
In my friend's case, he threw in the towel and bought a Muse Receptor2. It was the best $2k or so he ever spent. Instantly, all of his problems and misery went away. For those who are wondering, the Receptor2 is basically a PC in a rack case that's hand-tweaked to be a flawless dedicated VST host. Once you absolve your DAW of its softsynth VST-host duties, the misery and uncompromising hardware requirements imposed by them all basically go away. He uses it for live performances without worries, and now runs Cubase on a 3 year old HP EliteBook 2540p (with firewire audio) without problems. None. Prior to buying the R2, I spent entire days at his house trying to troubleshoot his VST glitch problems, and *nothing* could solve them, even with large sample buffers.
I managed to eliminate the glitches caused by everything besides the antivirus, Steam, and Windows deciding to maintain itself at inopportune moments, but that's when it became obvious that one way or another, he was going to need two computers... either a DAW that did absolutely nothing else besides be a DAW (and could never be safely allowed to touch the internet) and a second laptop for his normal computer use, or a standalone VST host that would allow him to use a fairly normal-spec laptop for everything BUT VST-hosting AND still run Windows normally.
I maintain that with most real-world hardware, trying to make a computer -- no matter how high-end -- be a glitch-free VST host, a DAW, AND a regular malware-protected Windows PC -- is a fundamentally lost cause, because the requirements of those three roles are fundamentally at odds with each other. Offload the VST to dedicated hardware, and everything Just Works.
Linux, Windows, and OSX all have problems with low-latency audio. The sad irony is that 15 years ago, you actually COULD connect a MIDI keyboard to a SB Pro AWE/32's MIDI port, run your sequencer app, and have it do a halfway decent job of both capture and playback. Then, host-based audio happened, and everything went to shit... accelerated by architectural changes to all three platforms that made matters even worse.
Forget about trying to do realtime CPU-based audio on any computer that needs to still be usable as a normal computer. It's impossible. You CAN hand-tweak Linux, Windows, and OS X in various ways to get the latency down (as others have noted, Linux has had realtime kernel audio available as an option for a while), but the tweaks you have to make will render it dysfunctional as a general-purpose computer.
It doesn't matter how fast your i7 or Xeon is, it doesn't matter how much RAM you have, and it doesn't matter if you have a terabyte RAID 0 SSD array... nothing you do will ever make it fast enough to do low-latency host-based audio without ever glitching. You might reduce the glitches to something that happens every 5-10 minutes, instead of every 5-10 seconds, but you'll never eliminate them completely. It's just the nature of how Windows, Linux, and OS X now handle multitasking.
The solution? Re-discover dedicated synth modules. Or set up a second PC whose only reason for existence is to be a VST/soft synth host -- aggressively tweaked for low-latency audio in ways the main DAW PC can't be.
The problem isn't MIDI (that was solved YEARS ago by just using USB to give every physical MIDI port its own dedicated full-bandwidth MIDI cable), and the problem isn't raw data being shoveled around. The problem is that even with a multi-core CPU and abundant RAM, Windows/Linux/OS X will all starve the soft synth for CPU cycles for 3-7ms at a time (usually, more like 12-20ms) while the audio buffer drains. If it empties before the CPU calculates the next 5-10ms chunk of waveform data, you get a loud audio glitch. Audio-generation is a "realtime" activity, and Windows/Linux/OS X in their roles as desktop operating systems all fall flat on their faces when realtime becomes a necessity.
So... the moral of the story: forget about trying to use a single computer as both DAW and VST/softsynth host. If you can avoid live performances involving a softsynth (or pre-record the softsynth and fake the keyboard playing during the performance, you'll save a LOT of money. Audio glitches while jamming or capturing keyboard input suck, but at least they won't affect your real recordings. Use your DAW as a DAW, and give the soft synth host its own hardware that can be properly tweaked for realtime audio.