407 karma · joined June 12, 2011
It would be ridiculously easy right now for a person to attach a firearm to a quadrotor with a CV system, program it to identify human shaped objects, and fire at them. It's not a miracle that such a thing hasn't happened, there are very few people in this world with both the desire and skills to do these things.
I'm reminded of a short story I read a few years back [1]. It got me thinking about the possibility of a single depressed individual hitting the big red button and destroying all humanity. I think it's a real possibility, and when you think it through with the assumption that these super-weapons will be readily available much in the same way that AK-47s are ubiquitous now, you can start to wrap your head around ways to perhaps prevent this.
First, mental health is a huge issue. We're seeing the results of neglecting mental health in America now with these spree/ego shootings, where disturbed individuals either radicalize or "snap" and go kill people in malls, churches, theaters, schools, and other public places. Semi-automatic firearms and explosives are enabling these things to happen, but weapons are a Pandora's box which can never be closed once opened. The way that nuclear weapons restrictions are handled now is probably best. Restrict the ingredients to make the weapons, and you can prevent them from falling into the wrong hands.
Another thing that we as a global society can do to prevent these weapons from becoming widespread is to sabotage them. Include vulnerabilities and kill switches that would allow us to neutralize their effectiveness. China did this with the ASICs used in some military machines built by the US [2]. This is a valid option, but requires a motivation on the part of those creating the devices. One could argue that a nation-state could create devices like this lacking intentional back-doors.
Engineers can also work on counter-measures and disseminate them widely, and that seems like it will be the most likely outcome. Humans are clever, AI is very specialized, and that will make the big difference. Once a general AI better than humans is created, our desire to not be murdered by it won't really matter anyway.
I think our best hope is to build these AI weapons, but do it so shittily that they fail more than they work. I also like the American technique of building it better than everyone else and sabotaging the work of any potential rival so that they can develop them but not realize they don't work correctly until it's too late.
1: http://www.fullmoon.nu/articles/art.php?id=tal 2: http://www.scribd.com/doc/95282643/Backdoors-Embedded-in-DoD...
I don't think we should change the funding system from grants to prizes. The existence of my job relies almost entirely on NIH funded grants, and I am not worried about this in the least. When they start talking about replacing the other $23.9+ billion in NIH grants with prizes, then we should worry.
I found a writeup [1] on how to write your own virtualenv. It doesn't look like there's much overhead there.
I suppose one could justify not using virtualenv if they're on a system with limited resources or network access. I've known people who spent hours building a compiling python 2.7 from source on embedded systems because they rolled their own distro, and in that situation it would make sense to not want to mess with virtualenv if you just spent hours getting pip working.
1: https://www.recurse.com/blog/14-there-is-no-magic-virtualenv...
virtualenv -p python2.7 env_name or virtualenv --python=/some/path/to/python env_name
You've made the best argument for using pip like this, however. Instead of having to install a virtualenvironment and install dependencies and all of that, you could just ship your program with the pip -t libraries, though you'd have to include the path somehow on the install so python knew where to find those files.
The relative path is an interesting trick, I'll have to keep that in mind in the future.
Many sites will send session tokens over http because they don't set the "secure" cookie flag. It's a simple thing to do, and prevents a malicious ARP poison or DNS attack from potentially hijacking an account.
You'd be surprised how many sites are vulnerable to such attacks. Reddit, parts of Ebay, several university websites, and many other sites still are vulnerable to session hijacking.
I think people writing web libraries need to start building "sane defaults" concerning security. All cookies should be secure by default, and only those who know what they are doing should turn them off. It's not that much extra overhead, and the potential benefits outweigh the increased processing and bandwidth.
1: https://www.owasp.org/index.php/Transport_Layer_Protection_C...
I can see both sides of the argument, but often the password complexity rules result in users writing down their passwords on sticky notes. You could make the argument that if an attacker is at the desk, you're already compromised, but still it's probably better to just enforce a policy of reasonable password complexity no matter what it is. They have javascript password complexity indicators on many sites now, I think that should become standard.
Where I work, we chose Xamarin over PhoneGap/Cordova.
[1]: http://en.wikipedia.org/wiki/Topological_quantum_computer
Is the operation of the D-Wave an unknown? I don't know much about it.
Also I believe there may be a typo in your last paragraph
>while staying clear of the brittle mess than is inheritance
It should be "that" instead of "than", I think.
Also, a lot of what is being done is automated monitoring. An algorithm can be developed to measure, for example, blood pressure, and if the patient deviates from acceptable ranges, the algorithm can trigger a contact to the patient, their healthcare provider, and family to begin an intervention to correct the bad blood pressure.
Adherance (doing it when you're supposed to) and validity (the measurements reported for Bob Smith are actually from Bob Smith) are big concerns, and there are also a lot of things done to ensure that the patient is doing their part correctly.
[1]: http://www.acep.org/Legislation-and-Advocacy/Practice-Manage...