Omar Rizwan

commonplace



latency


"Let me tell you a little story. There was once a young man who dreamed of reducing the world to pure logic. Because he was a very clever young man, he actually managed to do it. And when he'd finished his work, he stood back and admired it. It was beautiful. A world purged of imperfection and indeterminacy. Countless acres of gleaming ice stretching to the horizon. So the clever young man looked around the world he had created, and decided to explore it. He took one step forward and fell flat on his back. You see, he had forgotten about friction. The ice was smooth and level and stainless, but you couldn't walk there. So the clever young man sat down and wept bitter tears. But as he grew into a wise old man, he came to understand that roughness and ambiguity aren't imperfections. They're what make the world turn. He wanted to run and dance. And the words and things scattered upon this ground were all battered and tarnished and ambiguous, and the wise old man saw that that was the way things were. But something in him was still homesick for the ice, where everything was radiant and absolute and relentless. Though he had come to like the idea of the rough ground, he couldn't bring himself to live there. So now he was marooned between earth and ice, at home in neither. And this was the cause of all his grief." (Wittgenstein)


"Instead of outlets there are little patches of dirt in the walls. You a plant a seed and grow whatever type of computer you want"


"The problem with an auto-vectorizer is that as long as vectorization can fail (and it will), then if you’re a programmer who actually cares about what code the compiler generates for your program, you must come to deeply understand the auto-vectorizer. Then, when it fails to vectorize code you want to be vectorized, you can either poke it in the right ways or change your program in the right ways so that it works for you again. This is a horrible way to program; it’s all alchemy and guesswork and you need to become deeply specialized about the nuances of a single compiler’s implementation—something you wouldn’t otherwise need to care about one bit." (The story of ispc: origins)


"I've been jamming on this concept for making data-driven designs. Given some JSON, this app will provide you with an interface to describe how you want each entry styled, allowing you to gradually create a more complicated design."


"Critical theory and ideology critique spends a lot of time 'debunking', while a more traditional version of Enlightenment critique spends a lot of time demonstrating that certain truth-claims are in fact false or mythological. Neither of these models of critique should disappear and they certainly have their value; however, it may be that if belief is often external in this way, then debunking and demonstrating falsehood with have diminishing returns because conscious belief is not the primary mechanism that binds people to certain social systems. Rather, it seems that identification with many institutions or social formations is every bit as much a mechanism that binds people to oppressive systems as conscious belief. If that’s the case then a major strategy for undermining certain social formations would consist in the question of how to produce dis-identification." (This Extended Mind Again: We Don’t Know What a Human Being Is)


"The thrust of his argument is that tussle is inevitable. Designers tilt the playing field in some ways, but tussles are always going to pop up somewhere. Design decisions shape the structure and situs of tussle but do not deterministically control their outcome. Lots of functions migrate to the “larger ecosystem.” The impact of design decisions cannot always be foreseen. The impact of architectural and mechanism design on “values” and societal benefits is highly contingent and can only really be known ex post, not ex ante (as we have argued at length here) [...] An interesting but possibly unintended finding in this book is that it’s not even so straightforward for the designers to “know” what they are doing. As I read his older papers, it hit me that explicit formulations of the architectural principles underlying the Internet came well after the protocols had been designed and operationalized – sometimes as long as ten or fifteen years after. It is probably true that these principles, or something like them, were implicit or tacit in the work that the original designers were doing, but the time gap serves as a reminder that doing things and coming up with explicit conceptualizations of what one is doing are distinct, separate processes." (Clark’s “Designing an Internet” – A Review)


"The point of open source is not to ritualistically compile our stuff from source. It’s the awareness that technology is not magic: that there is a trail of breadcrumbs any of us could follow [...] to create and run our own essential tools and services." (On Liberating My Smartwatch From Cloud Services)