Unlike governments, corporations have no power to imprison or execute you. And no one's forcing you to use any of the services you list, whereas you can't opt-out of goverment surveillence.
That's true, but it is possible for 32-bit applications to use up to 4GB when run on 64-bit Windows if the application is compiled with the right options.
It has 2 supporters, one of which commented "I signing this because I'm stupid."
I just explained a lot of the reports were either not hobbyists, or not near airports. My earlier comment should have said "many" rather than "most."
There are already laws against flying drones near airports. No need for another, just enforce the existing ones.
You only read the parts of the article you wanted to, didn't you.
It said more than a dozen of the reports involved military drones. It said a half dozen were far too high to be hobbyist drones. Some were commercial drones. Some weren't drones at all--there was a "mini blimp", a vulture, and model rocket specifically mentioned, but it didn't say how many weren't actually drones.
BTW, I don't own a drone at all. I just think the "drone panic" is ridiculous. And legislating based on that panic is even more ridiculous.
What part of "most of the reports didn't involve hobbyists flying near airports" did you not understand?
Why? According to TFA, over 500,000 hobbyist drones have been sold in the past few years. 27 actually incidents (and not all of them were caused by hobbyists) is a very low number. Why should the 99.999% of drone owners who are responsible be punished? There are already laws to punish the irresponsible, and as TFA points out, some have been. Also, why should corporations, government agencies, and military by allowed to fly them (they caused some of the incidents too), but not civilians?
Did you read TFA? The point is many of the reports of drone "close calls" were either cases where the drone operator *was* flying within the rules, or the drone was government or commercial or military, not a hobbyist, or it wasn't even a drone to begin with. The FAA is lumping all these reports together, added fuel to the panic.
You obviously didn't read TFA... the pilots reporting the incidents are making the distinction between "close call" and "near miss", not the hobbyists behind the report.
That falsely assumes that the FBI always collects XXX and only XXX and hasn't and will never collect YYY or ZZZ.
That doesn't really apply here. Merrill runs an ISP and the NSL was (presumably) for information on one or more of his customers. Disclosing what types of information the FBI wanted still wouldn't tell you which customer(s) they were investigating. And its a moot point anyways, as the FBI admits the case(s) was/were closed years ago. There's no possible justification left here for a gag order.
NSLs were intended for time-sensitive extreme cases where the suspect(s) can't be tipped off, but the FBI issues thousands per year, so clearly they're not just using them for the extreme cases. And trying to keep a gag order in place 11 years after it was issued (and supposedly time-sensitive) goes far beyond "stretching the law".
The electrons go backwards in time.
As I read it, the shooter can see right into the operator's backyard from his deck. If he had looked around for 2 seconds he would have seen the operator. But no, his first thought was to get the shotgun and start shooting.
you are just trying to justify that the drone operator was correct on assumptions when this happened, you know now by the video of what the drone saw, but the thing is that you need to know this things when this was happening, not after
Are you saying shoot first, ask questions later?
If the guy didn't like the drone flying over his property he could have just talked to the operator. If he had real reason to think it was filming his daughters (presuming they are underaged), he should have contacted the police. Getting out your gun at the first sign something might be amiss isn't the way to handle things in a society of justice and laws.
Some programming languages manage to absorb change, but withstand progress. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982