‘This video demonstrates my design for a mechanism in #BabaIsYou which implements Cellular Automaton Rule 110, which suffices to prove the game is Turing-Complete!’ The write-up is here: http://www.twitlonger.com/show/n_1sqrh1m
Yukio-Pegio Gunji and Yuta Nishiyama from Kobe University, along with Andrew Adamatzky from the aptly named Unconventional Computing Centre at the University of the West of England decided they needed a new way to build logic gates using crabs [….] The colonies of soldier crabs that inhabit the lagoons of Pacific atolls display a unique swarming behavior in their native habitat. When in a swarm of hundreds of individuals, the front of the swarm is driven by random turbulence in the group, while the back end of the swarm simply follows the leaders. Somehow, this is a successful evolutionary strategy, but it can also be exploited to build logic gates using only crabs. The team constructed a Y-shaped maze for a pair of crabs to act as an OR gate. When two soldier crabs are placed at the top of the ‘Y’, they move forward until they meet and exit the maze through the output. This idea can be expanded to a slightly more complex AND gate, functionally identical to the electron-powered AND gate in a 7408 logic chip.
Another likely suspect is the memory allocator. After all, Nate Berkopec and Heroku remarked that fiddling with the memory allocator (either replacing it altogether with jemalloc, or setting the magical environment variable MALLOC_ARENA_MAX=2) drastically lowers [Ruby] memory usage.
It seems that recent versions of glibc (up to glibc 2.25 at least) have some dysfunctional behaviour around malloc’s arenas on multi-CPU systems, massively inflating the number of arenas allocated, which inflate reported VM sizes and (for multi-threaded Ruby services in particular) fragmenting memory badly. See also https://devcenter.heroku.com/articles/testing-cedar-14-memory-use Presto issue reported with glibc malloc arena-per-thread behaviour resulting in Presto OOMs: https://github.com/prestodb/presto/issues/8993 Hadoop affected by the inflated VM sizes reported as a side effect: https://issues.apache.org/jira/browse/HADOOP-7154 Good detailed writeup from IBM’s WebSphere blog: https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage
Talking to Podnews, a BBC spokesperson said that Google is required to sign a licence to link to their podcasts; and that the Distribution Policy also requires Google to supply user data to the BBC. There has been a “consultation with Google”, and the BBC “has no choice but to stop Google from making podcasts available via Google products.”
This is incredibly cool.
“For example,” Engheta says, “if you were trying to plan the acoustics of a concert hall, you could write an integral equation where the inputs represent the sources of the sound, such as the position of speakers or instruments, as well as how loudly they play. Other parts of the equation would represent the geometry of the room and the material its walls are made of. Solving that equation would give you the volume at different points in the concert hall.” In the integral equation that describes the relationship between sound sources, room shape and the volume at specific locations, the features of the room — the shape and material properties of its walls — can be represented by the equation’s kernel. This is the part the Penn Engineering researchers are able to represent in a physical way, through the precise arrangement of air holes in their metamaterial Swiss cheese. “Our system allows you to change the inputs that represent the locations of the sound sources by changing the properties of the wave you send into the system,” Engheta says, “but if you want to change the shape of the room, for example, you will have to make a new kernel.”
I had no idea about this — every google user has instant in-browser shell access to a Linux VM with 1.7GB of RAM