Posts

Showing posts from May, 2018

Some blockchain applications and Reviewcoin

Conjecture 34: Forall x, we have "x on blockchain". I don't have a proof but I have seen dental on blockchain, kiwis on blockchain, shoes on blockchain, etc. Apart from the many silly x-on-blockchain attempts, I have heard some serious and promising applications. The Brave browser basic attention token seems to be a serious effort and can help redefine the ad-economy on the browsers. I also recently heard about Abra digital currency bankteller , which is another solid company and application. To continue,  Jackson Palmer said these are his favorite decentralized technology projects:   WebTorrent ,  Dat  / Beaker ,  Mastodon , and  Scuttlebutt . Finally, there are well circulated requests for apps , which I think can make some uptick in the blockchain applications game. My blockchain app suggestions I didn't want to be left out of the action. Ideas are free. Here are some things that occurred to me. Medical school students can do an ICO and fund their sch

TUX2: Distributed Graph Computation for Machine Learning

Image
The TUX2 paper appeared in NSDI 17 and was authored by Wencong Xiao, Beihang University and Microsoft Research; Jilong Xue, Peking University and Microsoft Research; Youshan Miao, Microsoft Research; Zhen Li, Beihang University and Microsoft Research; Cheng Chen and Ming Wu, Microsoft Research; Wei Li, Beihang University; Lidong Zhou, Microsoft Research. TUX2 introduces some new concepts to graph process engines to adapt them better for machine learning (ML) training jobs. Before I can talk about the contributions of TUX2, you need to bear with me as I explain how current graph processing frameworks fall short for ML training. Background and motivation Graph processing engines often takes a "think like a vertex" approach. A dominant computing model in "think like a vertex" approach is the Gather-Apply-Scatter (GAS) model. You can brush up on graph processing engines by reading my reviews of Pregel and Facebook graph processing. Modeling ML problems as bip

SoK Cryptocurrencies and the Bitcoin Lightning Network

We wrapped up the distributed systems seminar with two more papers discussed last month. The "SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies" paper appeared in 2015. Although the cryptocurrency scene has seen a lot of action recently, this survey paper did not age and it is still a very good introduction to learning about the technical aspects and challenges  of cryptocurrencies. The paper starts with a technical overview of the cryptocurrency concept. Then it delves more into incentives and stability issues. It observes that it is unclear "how stability will be affected either in the end state of no mining rewards or in intermediate states as transaction fees become a non-negligible source of revenue". It talks about possible attacks, including Goldfinger attack and feather-forking, and also about stability of mining pools and the peer-to-peer layer. Finally it also covers some security and privacy issues. "The Bitcoin Lightnin

Book Review -- Accidental Genius: Using Writing to Generate Your Best Ideas, Insight, and Content

I had read this short book a long time ago. It is a very helpful book to learn about how to use writing for thinking --freewriting. Motivation for freewriting The mind is lazy. Thinking is hard, and our brains don't like hard. It recycles tired thoughts, and avoids unfamiliar and uncomfortable territory. Freewriting prevents that from happening. Freewriting is a form of forced creativity. Writing is nature's way of letting you know how sloppy your thinking is.  --Guindon  If you think without writing, you only think you're thinking. --Lamport  Freewriting helps to unclog the mind, reduce resistance to thinking and writing, bring clarity, provide perspective, improve creativity by causing a chain reaction of ideas, and articulate better about ideas. The premise of freewriting is simple: getting a 100 ideas is easier than getting 1 . "When you need an idea, don’t try for just one. When searching for one great idea, we demand perfection from it, depress ours

Paper summary. Decoupling the Control Plane from Program Control Flow for Flexibility and Performance in Cloud Computing

Image
This paper appeared in Eurosys 2018 and is authored by Hang Qu, Omid Mashayekhi, Chinmayee Shah, and Philip Levis from Stanford University. I liked the paper a lot, it is well written and presented. And I am getting lazy, so I use a lot of text from the paper in my summary below. Problem motivation  In data processing frameworks, improved parallelism is the holy grail because it can get more data processed in less time. However, parallelism has a nemesis called the control plane . While, control plane can have a wide array of meaning, in this paper control plane is defined as the systems and protocols for scheduling computations, load balancing, and recovering from failures. A centralized control frame becomes a bottleneck after a point. The paper cites other papers and states that a typical cloud framework control plane that uses a fully centralized design can dispatch fewer than 10,000 tasks per second. Actually, that is not bad! However, with machine learning (ML) applica

Misc rambling

Here, have some random stuff. Confident idiots  A couple weeks ago, I was in the YMCA sauna. There were 6 people, including 3 high school kids. One of the high school kids---who looked like a young Jonah Hill--- is excited he will be getting a car from his father and telling his friends about it. He asks his friends how often he needs to get the oil changed on the car. One of his friends authoritatively says: " Oh, they will tell you when you get the car. It is every 50 miles. " The boy says this so confidently that I am trying hard not to chuckle. So, Jonah  is OK with that. They keep talking about the car. But then this occurs to Jonah. He says " Once my mom drove us to Wisconsin and back and it is definitely more than 50 miles. It was like 500 miles. So oil change distance has got to be much longer than that. " The boy who authoritatively suggested 50 miles for oil change says with the same confidence: " Yeah, that is it, you change the oil every 5

Transmitting your message over a lossy channel

I need this plugin on my browser. HT @AlekseyCharapko And by the way, you should be writing. pic.twitter.com/ywVqHxaUsa — Murat Demirbas (@muratdemirbas) April 28, 2018 Late at night, I was tweeting random stuff and then the below tweet came. I don't understand the context of your tweet, and how it relates to this, but since I dabbled in wireless sensor networks, I can't refrain from commenting on how to deal with a lossy channel :-) — Murat Demirbas (@muratdemirbas) April 28, 2018 Since I worked on wireless sensor networks in a previous life, I had things to say here. Here are the ways to deal with a lossy channel, and what those mean for your writing. A straightforward and easy way to deal with a lossy channel is to add redundancy. Repeat the message a number of times, and one transmission will make it. In writing, this corresponds to: "Tell them what you are going to tell them, tell them, then tell them what you told them." Another way to deal

Truth is Multidimensional

Nasreddin Hoca is a 13th century Turkish wise-man / populist-philosopher, known for his funny stories and anecdotes. In one story, he was judging between two men over a conflict. He listened to the first man, and told him, he was right about the issue. Then he listened to the second man, and also found him reasonable, and told him he was right about the issue. Hoca's wife was listening and she intervened: How is that possible, how can both sides be right about the issue? Hoca thought some more about this, and said: "Dear, you are right, too." Murat Hoca I often find myself in the same position. For example most recently, I read Sinofski's tweets pro blockchain, and Jackson Palmer's tweets rebuking those, and I find both sides right. A lot of times after seeing a demo/new company using blockchain, technical people say “oh you don’t need blockchain to do that”. They are almost always right. Except that is also what everyone said of HTML/HTTP. Histor

Research and climbing

Image
I had seen this analogy in a recent tweet . How do you solve a truly hard problem? My undergrad math advisor said it's bit like trying to climb a mountain. You circle and look for a path to the peak that no one else has noticed. Often the searcher with most time and patience wins. Genius isn't what it appears from afar — Bharath Ramsundar (@rbhar90) May 1, 2018 I first liked this. But then I grew uneasy and even disturbed by it... I have been in this business (the research business ---not the climbing) for 20 years, and I find that unfortunately reality is not that simple, idealistic, and egalitarian. Climbing a mountain is hard and resource intensive To climb a mountain, you need more than a vision of a feasible path. Last year, I had read this book titled "After the summit" by Lei Wang . It gives life lessons learned from Lei's arduous journey to climb the highest peak on all seven continents, including Mount Everest, and skiing to the North and

Popular posts from this blog

The end of a myth: Distributed transactions can scale

Hints for Distributed Systems Design

Foundational distributed systems papers

Learning about distributed systems: where to start?

Metastable failures in the wild

Scalable OLTP in the Cloud: What’s the BIG DEAL?

SIGMOD panel: Future of Database System Architectures

The demise of coding is greatly exaggerated

Dude, where's my Emacs?

There is plenty of room at the bottom