I started one of my hobby projects (http://gibsonindex.org/) because media and government organizations were handling cyberattack reporting/prosecution so poorly, but it quickly grew tiresome. So many hacks in 2014, the mind boggles.
This post definitely offers some solid insight into the perils of reporting these types of incidents, and it's written a whole lot better than my stuff could hope to be.
I might just have to turn my site into a site that lists guitars. :-)
There are other ways to be different. Be friendlier (or edgier). Be more mobile. Be faster (see: Pinboard versus other bookmarking services). Be exclusive. Be more expensive.
...
The last one is a hard sell, obviously, but said sale is much more valuable.
I've worked on something for four years, then went to market it and saw that it had already existed for a decade.
But, of course, I already knew that I was not unique.
The reason I spent so much time on it is because I have a small but active community of users who like it very much. I am not confident I can monetize it (it's a chatboard service), so I may ditch my "chatboard as a service" plans, but I will continue to work on it.
Maybe I should forge ahead with the CaaS plan anyway, just to see if I can get any takers? A handful of paying customers would be better than none, after all.
(But in all seriousness, the reason you see low-hanging-fruit being picked is because everyone is still trying to figure out how best to employ the internet - you're seeing microeconomies rising and falling at a rapid pace, innovation both thriving and being stifled - there's a lot of flux at the moment. When everything clicks into place, it's possible that everyone will need to be an entrepreneur in their own way.)
Yay for Victoria/Vancouver Island shout-out - but I'm not sure that this is true in all corners of the world ... And definitely invest in better pockets, sheesh! :)
Well, think of the games - typically they need raw and low-level access to hardware in order to optimize the framerate and gameplay experience.
But there are several technologies on the market right now that can actually deliver such experiences with the rendering done off-device (albeit with some extra latency).
This is an example of new technologies mitigating the drawbacks to building non-native/remote-processing apps.
There seems to be an ebb and flow between "thin client" and "thick client" computing. Right now we're leaning heavily toward the "thin client" realm, with the emphasis on "Cloud this" and "Web that"; however, it's entirely possible that something will happen to bring that remote compute capacity back to the local device for the sake of efficiency.
And even now, there are reasons to compute locally in a native language instead of remotely via an abstraction. Some of those reasons (speed, primarily) are beginning to be mitigated by new technologies, but the reasons will likely always exist for why a native app can be a better solution than a thin client style implementation.
Probably what we'll see is an emphasis on APIs and intercommunication - this gives companies the power to do a lot of logic server-side, and just roll native apps for things that are difficult to do on the server. Implementations like Dropbox, Evernote, Wunderlist, and Netflix are good examples of this bridge between philosophies.
apc.enable=1 turns on Opcode caching (when php-apc is installed), and apc.stat=0 turns off "stat" checks - this means that once a file is opcode cached, PHP won't even have to touch the file on disk to execute it. The I/O gains from this, as well as the execution gains from not having to parse the file, should help quite a bit.
Yep, this is exactly what I was wondering. Opcode caching is a key part of production PHP environments - in this case, since the code isn't changing, they should even disable the "change check" (apc.stat=0) as one would do in a production environment.
And if this is the case with their configuration of PHP, it makes me wonder what other platforms are not configured for production in this benchmark :)
Hey, instant proxy and remote desktop tunnel. I wonder what movies they have on Netflix China? I wonder what the weather's like in south korea?
(ahem Obviously I'm simplifying and failing badly at being funny ... although if you don't recognize those SSH flags, you should look them up. VERY useful.)
1) The Use command can also perform aliasing, e.g. "use ExampleNamespace\subnamespace\foo as TruckNuts" allows you to alias the class to something else. This can help improve code readability. And you can to $foo = new TruckNuts();. (I'd recommend not using that exact word as the example :)
2) Many people have complained about the "ugliness" of PHP's namespaces. Maybe you could adjust the post to have a section comparing PHP Namespaces to those of other languages, and explaining why such notations would not have worked with PHP?
It's a bit absurd. A chilling effect, even; now, instead of responsible disclosure (which weev seemed to think meant scraping 100K examples of the data and giving it to a Gawker reporter), we'll be left with irresponsible disclosure (anonymously reporting it or selling it on the black market).
That said, I don't think AT&T would necessarily have reacted well to an attempt at real responsible disclosure.
For an example of the ideal scenario for how this should be handled, there's the Steam data leak that Ars Technica found: http://www.gibsonindex.org/blog/2013/02/06/steam-leak/ - I rated it as a Level Zero event on my cyber attack ranking blog, because of the proper resolution.
I agree that the blame in this case lies mostly with AT&T. It's their responsibility to protect the data. They build the program so that if anyone asked it for anyone else's info, it went "OK, sounds good, here you go."
Weev was the one who asked. AT&T should be on the hook for answering.
The charges in the indictment seem ludicrously disproportionate to the observed impact. I mean, giving away your workplace credentials is beyond stupid (and highly unprofessional), but I think it doesn't quite rise to "30 years in jail" as a valid punishment.