Urbit user guide, hosted on Urbit
urbit.org
urbit.org
So, is there support for running a separate p2p network? Or is the only option to wait for urbit to stabilize?
[ed: Never mind, it's covered under "Launch Instructions": If you don't have an invitation, pick a nickname for your comet, like mycomet. Urbit will randomly generate a 128-bit plot]
[ed2: Hm, looks like the ability to spawn an alternate universe would make playing with urbit more interesting, as I understand it - without an invite, most of the best parts are inaccessible: "The fanciest way to control your urbit is through Urbit itself: a moon, or satellite urbit. Sadly, only planets can have moons."]
Is this another way to say that you can never know what version of urbit you're running? So when someone compromises the upstream keys/ids urbit becomes one big botnet?
It's worth thinking about why we've accepted this tradeoff. The cost of evergreen software is that we put all our eggs in one basket, and watch the heck out of that basket. The benefit is that we solve a huge set of system administration problems that would otherwise be ridiculously impractical.
One metaphor I like to use is the difference between the Soviet and American design styles in aerospace. The Soviet way was to build systems with loose tolerances that worked okay even when parts were a little out of spec. The American way is to build systems with precise tolerances that work perfectly when everything is right, and fail catastrophically when it isn't.
There's much to be said for the Soviet style, and indeed it might be summed up well in Postel's law. But as the problems you're trying to solve get harder (like keeping all the world's browsers updated), it doesn't scale very well. If we compare the problems we can solve with manual upgrades and Postel's law, to the problems we can solve with automatic upgrades and rigorous protocol validation, there's no contest.
> Yes. And the same is probably true of the browser you used to post this. Also, the OS it's running on. It's the price of being "evergreen."
The OS, yes, to a certain extent. I don't think I've set up apt/cron-apt to automatically pull in stuff on (any of) my desktop(s) yet -- they tend to have a couple of bleeding edge repos enabled, and I often do not want even security updates at surprising times. Nothing like firing up your laptop on an airplane just to discover 3d acceleration no longer works because of a kernel security update (frequently for a local-only crash/exploit).
As for browsers, I'm mostly familiar with FF, and that usually prompts before update? I think you can set it to automatically update, though?
I do accept that trusting a single group of people to maintain the OS can be a good trade-off -- I trust Debian's Security team to do that. Sure, if they are compromised (or more likely, make a mistake) I'll suffer. But I'm not interested in having the small chance of key compromise be multiplied with all the (complex) software packages I use.
Also, for context, the same documentation clearly states "Urbit is not (currently) secure in any way" (or something to that effect), and in passing "if urbit runs as root". Well, apt-get does run as root, but a) it only runs automatically if I tell it to, and b) it's built on rather well-tested primitives (GnuPG etc).
So, having Urbit be notified of changes, and optionally automatically update sounds great, I'm not sure if I think "always automatically update" sounds quite as great. Especially if the stuff on which trust is built (encryption etc) is still considered unstable.
[ed: To be clear, the last bit, I like: "A normal Urbit user never has to think about software update." Key word being "normal". As Urbit is unstable, and everyone are developers and/or testers - there aren't (yet) any such "normal" users? ]
With SaaS web apps, it is of course impossible to turn off updates, which annoys the heck out of me.
It's also possible to hard-fork the network. The galaxies' public key hash is hard-coded in the source, so if you change it your ship will accept that the new key is the actual galaxy. Of course, there is no guarentee that any OTHER ship you talk to will agree with you...
http://urbit.org/docs/dev/contributing
There's much more to cover in terms of how the network works. It's coming! For the time being some things are just folk knowledge. We're always happy to answer questions though.
- Programming/computing is very new.
- Many mistakes were made.
- Due to human stuff, mistakes stick around.
- It's pretty clear that computing as it is today is very far from optimal.
- What can computing/programming look like if we start from a clean slate?
https://github.com/cgyarvin/urbit/blob/master/doc/book/1-noc...
The symbol evaluation is designed to take whoever is trying to program in Nock in circles around the specification. It makes even the most basic operations unnecessarily verbose and hard to memorize. To increment a number, you must put it adjacent to the expression [4 0 1]. So 42 [4 0 1] evaluates to 43, after several steps. There is no reason that an "assembly code" should have a decrement operator that must be evaluated more than once in order to get to the final expression.
Hoon, the "high-level" langauge is worse. A function to decrement an input by one is specified by the expression:
(a=. =+(b=0 |-(?:(=(a +(b)) b $(b +(b))))))
Like a postmodernist artists asks "what makes art?" and answers that there can be no objective answer, Urbit asks the question "What makes good software engineering?" Unfortunately there are many objectively bad design decisions you can make in software engineering. Forcing even the most basic operations to be incredibly verbose and unintelligible is one of them.
Nock is a functional assembly language, so it's not meant as a human interface. I think you mean "increment" instead of "decrement." Yes, [4 0 1] is an increment formula in Nock; 4 is the increment operator, 0 dereferences a tree address in the subject, 1 is the root of the tree; so [4 0 1] means "increment the subject," where your subject is 42.
If you know Lisp, you can think of Nock as Lisp without symbols or an environment; instead of having this hardcoded key-value store, the environment, you have a subject which is referenced with tree addresses (1 is the root, n2 is the left child, n2 + 1 is the right child).
Is this horribly arcane? It doesn't seem that way to me, but de gustibus non disputandum.
Hoon may be a little deliberately different which can be construed as obtuse but it actually takes less time than you might think to get up to speed in it.
Urbit is a little bit like that. When he says clean slate he really does mean clean slate.
Which in a way is what makes it fun. It's so far out of your normal experience that it's delightful to play with. At least if you are someone like me anyway.
You can build a practical system around the lambda calculus, which is arguably as simple as Nock. But you don't build a practical system by building layers on top of a simple lambda interpreter; you do it by extending the simple lambda interpreter, until it's no longer simple.
The critical feature of Nock is that it's very simple and you don't extend it, you layer on top of it. So, for instance, it's very easy to upgrade Hoon's syntax or semantics over the network in a live system, because the interpreter is a Nock interpreter and doesn't know anything about Hoon.
From my point of view, no other justification need be made, since no one is in any way forced to use, understand, or even acknowledge my creations.
I stared at the nock specification for about 3 minutes, just the symbolic specifications, not any explanation in english language, and I easily understood it. After just 3 minutes of staring at some symbols, I know everything there is to know about nock.
There is no other assembly language with this property. It seems to me it not deliberately obtuse, but in fact it's very clear, simple, and understandable.
I haven't looked at hoon and other things yet.
Why is that an advantage? The ability to give things names seems like a big win to me.
To be practical, though, I think the point here has to do with the idea that languages come and go, and their package namespaces along with them, but VMs stick around as long as useful libraries run on them... unless the VM is tied in some way or another to a language that has gone out of fashion.
Think of the JVM: even if you're writing Clojure, you call Java functions by their Java names. Effectively, you have to know a (tiny) bit of Java to call those functions. Why? Because Java syntax assumptions are baked into JVM's module/function naming rules. Clojure functions end up with Java-like names too, after compilation. Clojure hides it from you, but to call a Clojure function from Scala, you can't write a tiny bit of Clojure; you have to write a tiny bit of Java. Naming rules have made Java the only first-class JVM citizen.
Nock, on the other hand, defers the concept of naming up to the language/platform level. Effectively, each language running on Nock needs to make up a naming rule, and decide the canonical name (canonical to the language, not to the VM) for every available function itself. This means that there would be no de-facto "Urbit library ecosystem"; there couldn't be, as a particular arrangement of Urbit functions—a taxonomy—wouldn't be guaranteed to survive in any sensible manner between languages. Not all languages would have the concept of a "module", or a "package", etc.
This could be seen as bad: every Urbit-derived language would need to effectively create its own ecosystem of "library taxonomies", manifests mapping from its module system out to function-space, making each language maintainer roughly like a Linux distro maintainer, consuming functions from "upstream" and packing them.
But this lack of forced naming also has the potential to be very good: it creates the opportunity for taxonomies to be created separately from any particular language, and then consumed voluntarily by multiple languages. A taxonomy becomes its own first-class object, above "runtime" but below "language", where languages can pick a runtime+taxonomy to support. This, further, moves the creation of a "standard library" from the language authors to the taxonomy authors; languages "on" the same taxonomy become thinner bundles of syntax and compile-time features, while sharing all their stdlib algorithms, "primitive" data structures, and language "features" like GC (because that's mostly up to whether the data structure "primitives" provided by the particular taxonomy are implemented that way.)
Because the whole point of computing is to create value for humans, and humans think in terms of names. The fact that the lower layers of the internet don't care about names is not a feature, it's a bug. The internet runs on 32-bit IPV4 addresses because in the 1970s when the ARPAnet was invented that's all we could afford. But it's not 1970 any more, it's 2015, and computing and storage are many orders of magnitude cheaper today then they were then. We can afford to give names to things that we couldn't before.
We had the chance to "fix" this with IPv6... but we decided to give IPv6 addresses as well. I'm pretty sure having addresses that can be broken into prefixes to assign to different ASes and refer to in BGP routing tables is a feature.
(In IPv6, there are such things as Cryptographically Generated Addresses that are "identity-like"—but these still only exist within the last 64 bits of the IPv6 address, leaving the first 64 bits to function as a hierarchically-assigned routing prefix.)
Who is this "we" of which you speak? IPv6 was designed by a committee, and committees get things wrong all the time, even in 2015.
> I'm pretty sure having addresses that can be broken into prefixes to assign to different ASes and refer to in BGP routing tables is a feature.
You are conflating two different things here. Yes, it's good to be able to build routing tables that are very efficient. But having a number that describes the route to a machine is a very different matter than having a number that determines a machine's identity.
The way things work today -- even with IPv6 -- is that a machine's identity is determined by a number (its IP address) and we have a namespace layered on top of that (DNS). The assumption that the machine's identity is determined by its IP address (a number) rather than by its host name is baked deeply into the fabric of today's standards. This leads to all sorts of horrible non-orthogonalities, like the "Host" header being required in HTTP 1.1.
I'm not saying this was an unreasonable design tradeoff, just that it was a tradeoff, not something that was desirable for its own sake.
Doesn't this ignore the concept of Urbit's "jets"? You write code that does things in a stupid-but-canonical way; it's then the runtime's responsibility to take canonical patterns and provide optimized implementations.
The cool thing is that you get to write a naive interpreter for all existing code in a couple-hundred lines, while also being able to write a good interpreter that makes the same code run quickly. Like regular Lua vs. LuaJIT, but much moreso.
In fact, the best thing to compare it to, in my mind, would be RarVM bytecode: another ISA designed to be "forward-compatible" in the sense of ensuring that even the first interpreter will be able to run code from years in the future. Nobody ever sees RarVM bytecode; nobody even realized it existed for decades. It was just there, an implementation detail of the RAR encoding/decoding process, doing its job of enabling the RAR format to change its algorithm over time.
And at least loop-unrolled x64 code describes what it's doing straightforwardly, instead of throwing around redundant mathematical abstractions and hoping the interpreter will magically pattern-match them away.
As an aside, though:
> Abstract ISAs are still languages.
Not always true. A lot of current abstract ISAs are (because they were designed to be programmed in, as well as as compile targets), but many aren't. Most code read into a modern VM gets chewed on a bit more from its "canonical" form; the internal representation that results, with threaded code and JIT profiling hooks and tracing et al, basically looks like Nock: a graph of numbers. For most VMs, those numbers are just pointers to structs it has allocated, so they can't really "live" outside the VM. Nock just goes a bit further and says "but if you give those struct-pointers persistent wire-representable identifiers ala CapnProto, you can serialize the whole internal-VM-state graph in a portable way—and then that can serve as the VM's ISA."
And no matter the form you turn a language into, it's still a language. Speech and text are generally considered equivalent in that sense, for example- it's the abstract form that matters here.
A Smalltalk live-image, a core-dump of a process, an SQLite database, etc. are all "languages" by definition 1, but obviously not "languages" by definition 2. Nock's ISA is more like those: a format for machines to generate and other machines to consume, and for humans to use tools to introspect; not a format targeted at direct human production or consumption, even through a 1:1 mapping ala disassembly.
Either way it's undeniably fun to play with right now.
The point is that we ought to have a permanent, immutable home for our personal computation that's universally available on the network. Not an app, not a service, but a general-purpose tool that I trust and can program. I have one on my desk, but I want one in the cloud that doesn't feel like flying a 747 (aka being a unix sysadmin).
Our approach is simple: the reason this doesn't exist is not because it's not a good idea, but because existing old-school system software is too complicated.
I'm daunted by it, but I'm intrigued by it. I'm also pretty convinced that if I devote some time to it, it will make sense. And as a bonus I'll probably understand the rest of my computing a little better as well. Which is why I'm cloning the repo right now to have a play.
PS. Big repo. 400mb and counting.
https://git-scm.com/docs/git-filter-branch
But this will sever history with all cloned copies, much like rebasing master would.
It reintroduces the social computing environment, emphasis on the word computing. The Old Internet and timesharing systems like ITS and Unix were based around this model:
https://medium.com/message/tilde-club-i-had-a-couple-drinks-...
So you have a standard identity layer, instead of a million little fiefdoms of identity competing for sign ups. You have proper one-to-one connections between individual users on the system, with modern cryptography inbetween.
You have a functional, very very small kernel out of which the rest of the system is built. This kernel and core concept is a sort of distillation of the ACID concept from database systems, so that your computer has transactions and forgives mistakes.
It bakes the social layer and the community layer of the Internet into the protocol. Urbit tries to be community-aware and politics-aware and handle this gracefully. This sort of formal acknowledgement of necessary human factors in technology is certainly in line with Curtis Yarvin's previously expressed views on social organization. (And is mostly what people are talking about when they say he 'baked neoreaction' into Urbit. This accusation strikes me as intellectually dishonest on multiple levels, but I'd rather not digress on it.)
If nothing else it's a very interesting piece of new research in computer science, you should be excited about it.
EDIT: Curtis I know you're lurking, can I get an invite?
And how is this system "politics-aware"? I'm not even sure what that would entail from what basically seems to amount to a collection of esolangs.
Social means a bit more than just Facebook. It also means primitives for things like collaborative editors and coworking spaces, video conferencing, etc. IMO the ideal social system would look a lot like a mix between the old timesharing systems, the early Internet and Douglas Engelbarts "Mother of All Demos": https://archive.org/details/XD300-23_68HighlightsAResearchCn...
>And how is this system "politics-aware"? I'm not even sure what that would entail from what basically seems to amount to a collection of esolangs.
Well it comes with the community. The way Urbit is structured your personal cloud/ship/etc is intended to be linked up to a community of other users. Politics are part of being social and part of communities. If you don't have a structured way of handling it it'll happen regardless and can be made less ugly with official support.
"The part that is stable we are going to predict, and the part that is unstable we are going to control." - John Von Neumann, 1948
I think the crucial layer that we need to implement... a lot of things... is a global immutable (aka referentially transparent) namespace. Urbit is one project building such a thing; another one is IPFS. (Urbit names are addressed by identity; IPFS names are content-addressed; so they're complementary and not competitive.)
One of the reasons the Web seems like such a poor imitation of Xanadu is that it rests on this rickety foundation of a mutable binding from name to resource. Once global immutable namespaces -- Urbit, IPFS, anything -- are more widely deployed, I think Xanadu would be wise to use such a thing as a layer.
But to paraphrase a famous saying: grant me the serenity to accept the code I cannot rewrite, the courage to rewrite the code I can, and the wisdom to know the difference :-)
Theodore Nelson has said this himself, I can't remember the exact source but I think it was in his google talk he said that you need permanent addressing for Xanadu to work. He at least reiterates the concept (though with less principal importance) here:
http://xanadu.com/XanaduSpace/btf.htm
"STABILIZED ADDRESSES
Imagine that everything you type is given a permanent, immutable address. Then to refer to a given sentence, or paragraph, you would refer to its permanent address span (start, length). This would have many benefits.
This is not the way things are ordinarily done, but in this system we simulate such permanent addresses in order to get these benefits."
Computer Science is not renowned for it's diligent study of history. And that's just for those that actually study it in some form of institution, not all the people who "practice" it without any formal training.
That said, the fact that Ted Nelson/the publisher have stubbornly refused to just publish for example "Computer Lib/Dream Machines" free on the (inferior) web, or at least as a DRMed ebook or merely a dead-tree re-print -- makes it unnecessarily hard for people to read up on the concept(s).
You can still find copies on Abe Books but they're not cheap.
http://www.abebooks.com/servlet/SearchResults?isbn=091484549...
Glad I held on to this little bit of dead tree history even if it is the revised version.
Another lesson is to avoid too long a stealth period.
Urbit is 100% open source, and (as you mention in your other post) probably a good fit for implementing Xanadu on top. Our filesystem satisfies a lot of the requirements.
Want to build it? Great. We'll happily help.
But apparently there's some little islands or somewhere where they do. Will fix.
It is nice to see sanely written documentation though. Cheers on improving that. :)
Edit: Useful, thanks! vvvv
All those resources are actually markdown files that are being built for use in our doc browser — but you can also browse the raw .md.
Here's an example of how to retrieve raw .md:
http://urbit.org/docs/user/intro http://doznec.urbit.org/home/pub/docs/user/intro.md