Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The flaw in this white paper is that it starts by explaining the solution instead of the problem. So everyone should start by skipping to the bottom and reading the conclusion:

>In 1985 it seemed completely natural and inevitable that, by 2015, everyone in the world would have a network computer. Our files, our programs, our communication would all go through it.

>When we got a video call, our computer would pick up. When we had to pay a bill, our computer would pay it. When we wanted to listen to a song, we'd play a music file on our computer. When we wanted to share a spreadsheet, our computer would talk to someone else's computer. What could be more obvious? How else would it work? . . .

>The Internet didn't scale into an open, high-trust network of personal servers. It scaled into a low-trust network that we use as a better modem — to talk to walled-garden servers that are better AOLs. We wish it wasn't this way. It is this way.

This is the problem Urbit aspires to solve: Why does everything suck? Why aren't we living in the future we were promised in 1985, where everything is easy because all software plays nice together? Why do we have a planetary series of Rube Goldberg machines instead of the fun version of the Borg?

The answer is that we've been building everything on top of leaky abstraction, piling band-aids on top of band-aids instead of just starting with a stable foundation. Urbit's solution is to replace every OS, file system, and communications protocol on Earth with a single application: Urbit.

The project is meant to be the biggest pain in the ass ever. It's an attempt to fix everything that is wrong with computers by rebooting the entire information age.

The beauty is that it doesn't all have to happen at once. Urbit can function like a kernel for all non-Urbit systems: They get to call Urbit to receive its super-reliable data, but it never makes system calls so they can't inject side effects into the shiny new Urbit ecosystem. Over time, if Urbit works as intended, it will assimilate everything else.

Once you understand the stakes, Nock and Hoon no longer look like cruel jokes. It would be madness to expect coders to invest all that effort to learn 'just another language.' It's only pseudo-madness to make the same demands while promising that their code will still work a million years from now, because all computers will still be running Urbit.

Instead of caviling about details like how to pronounce the code when reading it aloud, let's delve into the issues that really matter:

I. Does modern computing suffer from a leaky abstraction problem that needs to be solved?

II. If so, is the solution to build an overlay network that provides a global static functional namespace?

III. If so, is Urbit a viable implementation of that solution?

IV. If so, what is the likelihood of Urbit reaching the critical mass necessary for mass adoption?

The last question is the one that interests me the most. In order to overcome the massive inertia behind legacy computing, Urbit needs a killer app: Something that exploits the new system's intrinsic advantages to accomplish feats that were previously impossible.

So... uh... Any suggestions?



A hint: consider the difference between calling web APIs from a cloud appliance controlled by a third party, versus calling web APIs from a personal server controlled by the user.

A new network has no Metcalfe's law effect by definition. So an important early skill is parasitizing existing networks...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: