Nope, numpy needs libblas and scipy needs libatlas, both of which have to installed from the system package manager. I slap my forehead every time I move to a new system and find that the pip install in the virtualenv failed.
CM7 user here. Can confirm that it is vulnerable. Easily fixed by installing a second dialer so that you'll always get a prompt.
Also I can't find any info on whether cm7 supports USSD factory reset. Anybody aware?
Is this right? Java really has better latency than Go right now? And with 2 processors, Go's latency is 25ms for 50 concurrent requests. Anybody with better experience care to comment on this?
There's still this lingering belief that Java is slow, maybe related to the terrible start-up times of the JVM. But once it's going, Java is fast - really fast. And since its niche is basically enterprise webapps, a lot of attention has been paid to scalability and concurrency.
A little known secret is that most mainstream languages have nice libraries to handle multi-core programming that go beyond basic thread handling, similar to what Go offers.
You just have to know where to look for, plus you don't need to throw away mature languages and tooling.
1 - There has been a lot of man years put into the JVM (threading and garbage collection), and Java memory model. I'm somewhat surprised by the magnitude of the difference. Java and JVM are very mature technologies.
2 - Go's CPM paradigm is not necessarily more performant than the preemptive threading model of Java, and I don't believe that has ever been claimed for CPM. It is claimed that it is "easier" to write concurrent code using the (CPM/Go) message passing paradigm, but in my experience, you either get concurrency (and can do both variants ok) or you don't, in which case any real world concurrent system will hardly be "easy". That said, for the concurrency novice, Go is far less intimidating experience given the language level support for goroutines (fibers), channels, selectors, etc. (think Java NIO ...)
I have no idea if it is "right" since I'm not going to duplicate this exact benchmark, but it seems likely. Raw performance hasn't been a huge focus for Go, though this has been changing. The tip version produces much faster code than the last official release that seems to have been used here. Also you often get more efficient Go from the gccgo frontend than from the Google compiler since it can take advantage of a lot of front-end-neutral optimizations that gcc already has (though this gap is closing as the Google compiler gets improved). For the runtime, work continues on the goroutine scheduling, gc, etc.
I have been really impressed with Go's portability. I recently cross compiled a binary from a Linux machine for an ARM target and had it running from scratch in less than 15 minutes. Go could become a serious option for embedded Linux targets.
I agree. My current spare-time project involves programming in Go for ARMv5-based boards (old chumby devices).
I write the code in Windows (Sublime Text 2), compile in Windows, but target GOOS=linux, GOARCH=ARM, GOARM=5 and end up with an executable that I can easily rsync and run over on the ARM device. The cross-compiling available in Go is much easier to setup initially than the usual situation of having to build an entire toolchain for your target.
It's not. It's really not. I've heard good things about PyCharm, but the best environment for Python that I have seen so far is Emacs. And Light Table definitely looks like an improvement on that. My only concern with this is the speed. I want this to have the same response time as Emacs or Vim. Then there would be no reason not to use it.
I specifically chose the description "pretty good" (as opposed to "great" or something more flowery) for PyDev, because I think that best summarizes it. It's got a number of issues with it (and it's sometimes as slow as a dog), but for the hobby developer it's more than enough.
Once I started working in Python and spending 30-something hours/week in the environment, its flaws started to overcome its benefits (namely: it was free, and I knew how to use it), and it was time to move to PyCharm...which is also slow, unless you throw a few gigs of RAM at it and at which point it becomes amazing.
