At present it's a bunch of programs that run on UNIX systems. I guess the Hoon interpreter is a C program that uses readline, talks to the network over sockets and the like. But everything on top is quite self-contained and in principle one might remove the layers underneath.
But I'm not sure that's necessarily the aim. As I understand the project's aims (and I'm not involved, I just read all the docs a few months back), it's more important that the Internet of the future is not a tangled mess of technologies that are insecure on different layers. Then it doesn't matter so what OS people's local machines are running.
I hope the essay at the URL below is still relevant, it seems to describe the aims rather well. "The result: Martian code, as we know it today. Not enormous and horrible - tiny and diamond-perfect."
They had me going in the Nock spec until "We should note that in Nock and Hoon, 0 (pronounced "yes") is true, and 1 ("no") is false. Why? It's fresh, it's different, it's new. And it's annoying. And it keeps you on your toes. And it's also just intuitively right."
But on POSIX systems, there's a reason for that. There's only one success (Since "success" should do the same thing every time), but many types of errors which can be indicated by the return value. You could argue that 1 should be success, and >1 should be failure, but that's a minor quibble.
Conversely, here it's just because "it's different". I feel that this is a bit if a shame - some of the other parts of the project appear quite interesting, but making fundamental decisions in downright wrong ways just to mess with expectations comes across as silly to say the least. Why deliberately increase the learning barrier and drive people away?
There is one ground truth, origin, fixed point like the North Star: zero. There are an infinite number of possible falsehoods: all nonzero numbers. But Urbit chooses 1 as the canonical false.
I absolutely understand your reaction, but, believe me or not, I remember myself wondering as a child why it is opposite. That time it seemed to me completely intuitive and natural that 1 should be "false" and 0 — "true".
However, years later I was introduced to boolean algebra, where 1 should be true and 0 — false, if we want multiplication to be "and" and addition "or". And it feels right, because intersection of two sets is (intuitively) multiplication, and joining — addition.
So, yeah, it doesn't seem like a good idea to me as well after all these years.
Compare to probability. Probability of element being in one set AND another distinct set is multiplication of two probabilities (which are, in reality, actually defined by sets).
"Pairs" (and, respectively, cartesian product) is a bit more complex, and not so much related to boolean algebra deduction concept.
x ∈ (A ∩ B) = (x ∈ A) * (x ∈ B) if "x ∈ A" equals 1 when x is in the
set A, 0 when x is not in the set A. Using "indicator functions" like
this also gives you a nice formulation for probability and
integration, etc. that falls apart if you use 1 to represent x ∉ A.
edit: I should add that I'm not claiming "you can't build measure theoretic probability from this formulation of booleans" is a strike against the project. Just addressing the math question.
I don't see how you lose boolean algebra, you just need to flip * and + in your equations.
x ∈ (A ∩ B) = (x ∈ A) + (x ∈ B) (and)
x ∈ (A ∪ B) = (x ∈ A) * (x ∈ B) (or)
which is useful when you define integrals and expectations:
E g(Y) = ∫ g(y) f(y) dy = ∑ᵢ g(cᵢ) P(y ∈ Aᵢ)
where Y is a random variable with density function f. Any integrable
function can be approximated as the limit of step functions, so this
is a well-behaved way to get a general theory of integration.
Of course, one could replace (y ∈ Aᵢ) with 1 - (y ∈ Aᵢ) if one wanted
to use "0" to represent the event (y ∈ Aᵢ) and "1" to represent its
complement and not affect the truth of the math, but then there will
be lots of termf floating around just to convert the notation into the
terms that you need for the math.
It just sounded as if being public domain somehow makes project more ambitious (that is, means to be more difficult to complete than if it wasn't public domain), so I probably just misunderstood.
Except that some jurisdictions in the world don't have the concept of public domain, so, in those places, this code is legally in a very weird place. It's much better (IMO) to assert copyright, and then release under the most permissive license possible.
All of that stuff works now. If you're asking how long until it's supported, I'm not an employee of Tlon, so don't ask me. I can tell you that most of this stuff is still very slow, even if it works.
Check out the demo app, you can click a button and increment a number on the page, and it generates an event that gets reflected out (through some like AJAX) through the server, back out to as many subscribers as are currently viewing the page in their javascript-supporting browsers, happens almost instantly.
I have to apologize I have no short instructions to get you to this demo, it exists but I'm sure it may still rust more before it becomes a priority to build things based on it. I'm not sure if you're meant to be impressed by this demo, but there's also twitter API client you can use to tweet which is more obviously useful if not quite as whiz-bang.
You'll find the code in your pier/ship/main/app/demo/core.hook
To reset the counter (wipe the app state), at your command-line, do:
:wipe %demo
I just tested it, I can see that it still works, but like I said none of this is guaranteed to go on working. It's all very alpha.
This is called a %gall app. It's always running because the %gall vane runs the main/app/ apps in the background without intervention, like radio/core.hook that runs the server for the :chat app. See you in :chat maybe, if you have questions about how this works you will certainly be welcome.
I know enough to be interested. Not enough to know if its nonsense.
Although, I read this:
"A pier is an Urbit virtual machine that hosts one or more Urbit identities, or ships. When you run bin/vere -c, it automatically creates a 128-bit ship, or submarine. Your name (a hash of a randomly-generated public key) will look something like:
Urbit is a weird thing that feels like it comes from a parallel universe of computing. It's a bit hard to wrap your head around it at first, but it has some neat ideas.
I like this article which introduces it:
Urbit is perhaps how you'd do computing in a post-singularity world, where computational speed and bandwidth are infinite, and what's valuable is security, trust, creativity, and collaboration. It's essentially a combination of a programming language, OS, virtual machine, social network, and digital identity platform.
"Despite messages between ships being encrypted, the founders state that they've purposely designed the network to make it as easy as possible for governments to regulate and control. It's not entirely clear why this is supposed to be a good thing."
My take on that is that this design choice arrises from the anti-democratic authoritarian sentiments which (at least one of) the developers apparently hold. At least they have repeatedly expressed these sorts of sentiments in their rather long winded blog(s).
Have you considered that democracy is not actually immune to authority, and it's really a reflection of this, rather than a window into the designs of one crazy person? (hi Curtis)
Maybe every system that comes along and says "impossible to be subverted by centralized governments" in reality is just saying "come and try to stop me, Federales". Do you think that is that what we all should be doing instead?
Actually, I have. I understand that there is complex tension between fundamental human rights (like freedom of expression, freedom of association, & privacy) and realities of the intrusion & abridgment of these rights carried out by various state security agencies and corporations.
I agree that any project which claims "impossible to be subverted by centralized governments" is just saying "come and try to stop me, Federales". Moreover, I feel that such claims are extremely difficult to substantiate (and so not particularly credible) and for the most part made by groups I'm not really motivated to associate myself with.
Speaking in a very general sense (having kept up with the news & goings on related to technology, privacy, corporate activities, and state security activities for the past few decades); it's my opinion that this tension is not only not in an ethically defensible or sustainable state, it's not in the state that most of the people in the western capitalist nations believe & expect it is.
So I find assertions like: "Despite messages between ships being encrypted, the founders state that they've purposely designed the network to make it as easy as possible for governments to regulate and control. It's not entirely clear why this is supposed to be a good thing." to be similarly worthy of skepticism and disconcerting as the "impossible to be subverted by centralized governments" claims. My feeling is that this statement translates fairly directly into "all user data is available to any corporate entity or state security agency for any purpose" and that this includes purposes like backchannel monetization through data aggregation and industrial scale warrantless surveillance & data collection.
It's pretty obvious to me that you are pretty invested in this project and I've only spent a few hours perusing the various docs, repositories, and blogs. So I'm fairly hesitant to make any sweeping statements or claims of certainty. So, with those qualifications in mind, my conclusion after my perusal is that this architectural design choice is unlikely to be a reflection of some sort of pragmatic policy coming from a non-ideological position of social responsibility that's striving to minimize any intrusion & abridgment of rights while still allowing for the realistic needs of businesses and state security agencies.
Frankly spoken, I personally find a number of the abstract concepts and architectural design choices in Urbit project to be fascinating and compelling. I've spent far too much time dredging around the information that is currently publicly available... Time I honestly can't afford. So it's really disappointing to me to find that there is a pervasive toxicity which is deeply intertwined with the project. My conclusion is that this toxicity makes the project broadly unusable (seriously) & and possibly even unfixable.
Elsewhere in this thread I saw someone claim that there were big things coming in a few months. If this is accurate I look forward to it. Perhaps there will be changes and new developments which will demonstrate my current assessment inaccurate. Honestly, that would make me pretty happy... but from what I've seen so far, I suspect that's really, really unlikely.
I know you said you are out of time, but that mention from above about "the founders state" was actually responded to by the founder, and he said he didn't agree (it actually sounded more like "I never said that" to my reading.)
I don't claim to know everything about how Urbit works. I do think that superficially, Urbit is more able to respond positively to a demand from a state that sounds like "we think your network is being used to recruit radicals and a subversive element that threatens the nation is using it to communicate operational details and plan their attacks. can you shut it down" than say, BitTorrent...
I mean, it's a centralized network where the leader is able to push out updates to the software, and in a future version you may not even need to ask for them to be downloaded or approve them before they replace your running kernel. This will be considered a feature by anyone who comes from at least a managed Windows domain.
So, it has the potential to carry out a "poisoned updates" type attack, like Apple could do to an iPhone. And the more that I think about it the more ways I can imagine that ~zod can fuck you up. It's true I am interested in this project, more than passively, I am a kind of stakeholder who owns a large part of the namespace. The only thing that keeps my ownership safe is a line of text in the git repository under ames.hoon where my public key is stored, generated by an app called :pope and interpreted by a crypto suite that I cannot audit, simply for lack of time and understanding.
So, if I've led you down the wrong path or led you to believe something about the code that simply isn't true, I apologize! I feel I have to admit this is possible, I may have grave misunderstandings or mischaracterizations about the current state of the software, and to add to it, things are also always still changing now. It's in active development, pre-alpha, not yet sure who the customers are. YMMV, take with a grain of salt.
> My feeling is that this statement translates fairly directly into "all user data is available to any corporate entity or state security agency for any purpose"
Speaking as a semi-informed bystander who's been following Urbit for a while now, it certainly seems like one of the problems it's trying to solve is the typical notion of "user data" as something controlled by third parties. Eg [1]:
> Where is Joe's financial data in mint.com? In, well, mint.com. Suppose Joe wants to move his financial data to taxbrain.com? Suppose Joe decides he doesn't like taxbrain.com, and wants to go back to mint.com? With all his data perfectly intact? [...] Imagine the restfulness of 2020 Joe when he finds that he can have just one computer in the sky, and he is the one who controls all its data and all of its code.
That said, the current implementation has been explicitly called out (in past incarnations of the docs, at least) as not-remotely-trustworthy with sensitive private data.
I definitely wouldn't endorse this description - it's a bit secondhand.
What I'd say is that Urbit is not designed to be a darknet. It is not Tor and it's not Bitcoin. Also, it is not designed for external governments, or even its mysterious and sketchy founders, to govern - it is designed to govern itself. (Through user-level reputation mechanisms which have yet to be built, but are relatively easy to build - because the limited supply of identities controls Sybil attacks.)
In particular, Urbit should be quite good at enabling anonymous free speech beyond the reach of governments. A self-hosted node in your closet is quite practical and effective. There is no anonymization / onion routing (and you can't trivially route Urbit over Tor, because Urbit uses UDP), but someone could build that.
Although I don't want them to. I want to enable anonymous, or better yet pseudonymous, free speech. I don't want to help people buy drug$ or childpron through the mail. Fortunately or unfortunately, there are already much better tools for that.
And what is the reason why an existing language and compiler doesn't suffice for 1 and 2?
For example, Haskell and GHC took decades to become what they are now (a powerful language and compiler). It seems quite wasteful to rebuild that work. If absolutely desired, Haskell can also be converted into combinator form, and vice versa, so why not use it? Seriously.
Because it's incredibly fun to work on? It's a brilliant VM once you wrap your brain around it, and the hackers behind it got to really try something new?
Judging by the documentation, Urbit looks to be less about leveraging pre-existing work and more about reinventing computer science and software engineering from the ground up.
Here's an idea: maybe anyone accusing someone else of being "too ambitious" should share one of their own projects that demonstrates exactly the right level of ambition.
Nevermind the fact that the parent post believes its possible to quantify "exactly the right level of ambition," the poster believes that the only people that should be "allowed" to comment on whether or not something is too ambitious should be people that are currently undertaking ambitious projects themselves.
This smacks of privilege. Not everyone is or can be in a position to pursue ambitious projects. To say that these people should be barred from commentary is ridiculous.
I've not suggested anyone be 'barred' from commentary.
Rather, if you want to dump generic negativity on a real, delivering project, you should justify why your negativity is relevant, for example by documenting your own related efforts.
If you want your cynicism to be respected, then yes, that's a privilege that needs to be earned. You can always say it, but it should be called-out as empty bullshit until backed with detailed reasoning or experience.
No, some projects can be too ambitious, including even recklessly or dangerously ambitious. But I'd rather hear that judgement from someone with a reputation for appropriate, successful ambitiousness, and with some supporting reasoning.
The grandparent comment comes from a pseudonym linked to no evaluable projects. It offers a costless, totally-generic pooh-poohing of a real project as "too ambitious". But that project is actually shipping code that works, with 126 contributors, many with a known history of contributions in related spheres.
Against that, the comment even uses an appeal to "HN standards"! As if, we should all be discounting this sort of stuff, on its face.
I'd prefer "HN standards" encourage such ambition, backed with code – not casually mock it with a ascii-smiley.
> But that project is actually shipping code that works
I get that this is more than just vaporware, but getting past the vaporware stage doesn't necessarily prove that something isn't too ambitious. When something is attempting to enact a paradigm shift, the final goal is adoption/usage, not just a working/functional product.
You seem to be using "too ambitious" as a synonym for "unlikely to succeed". But that's something different.
"Too ambitious" implies someone shouldn't even be trying for this goal. That's a corrosive attitude, and I'd like it kept-in-check by a requirement that sources of such negativity show their reasoning/experience/work.
Again, the contributor list in github is WAY misleading, because it accidentally somehow pulled in all the contributors of the libraries we bundled (eg, libuv). We need to fix this, I think.
Or as I sometimes say: "on the bottom it's a new kind of math, on the top it's a new kind of social network." This is kind of shameless hype but not as much as you might think.
Sounds like a 10-year research project, right? Actually I started working on Urbit in 2002, as a sort of "unsupervised PhD thesis." I figured it'd be done by 2008 or so.
We seeded a startup last fall and are busy turning a prototype into a product. You can now write a pretty decent web app in Urbit, but it's still too raw to stand the light of day. For instance, the network works, but we often run global flag days when we shut the whole planet down and change the protocol.
One of the main problems with Urbit is that extraordinary claims demand extraordinary evidence. If you're going to ship something this crazy, it has to work extremely well right out of the box. We had a sort of abortive non-launch last year when the project kind of got accidentally leaked, and decided we had to "unlaunch" and go back into quiet mode. I hate selling things I can't quite deliver.
But can you please explain why you couldn't use existing math (language and compiler) on the bottom layers (1 and 2) before replacing them by your own? That would help me understand the level of your ambition :)
One, as we know from Church-Turing equivalence, lambda and infinitely many other models of computing have the same expressive power. That doesn't mean they have the same practical utility, though.
Lambda in its Lisp incarnation is actually a rather poor substrate for something like a Lisp machine, I think, because it doesn't layer very well. You can define quite a simple Lisp model, but when you want to turn it into a practical Lisp, you don't add another layer - you grow hair on top of the existing layer. You grow a little hair, you get Scheme; you grow a lot of hair, you get Common Lisp.
I've never seen a lambda model (Qi/Shen perhaps a partial exception, but even there the underlying model is not very simple) that layers a complex language on a simple kernel. I think this is because lambda defines abstractions like symbol tables and function calls, which are user-level language features, in the computational model. The bells and whistles get mixed up with the nice clean math.
Another example is the fact that a modern OS should present itself to the programmer as a single-level store, meaning effectively an ACID programming language in which every event is a transaction. So, you're not constantly moving data across an impedance mismatch from transient to persistent storage, each having its own very different type system and data model.
But, if you're building persistently stored data structures designed to snapshot efficiently and remain maintainable, you really want your data model to be acyclic and not require GC. This goes in a very different direction from almost all the dynamic language work of the last 50 years.
Or, for instance, if your system is designed to work and play well in a network world, it really ought to be able to be good at sending typed data over the network. And validating it when it gets to the other side. Your type system ought to be able to do the same job as an XML DTD or JSON schema or whatever. Well... this wasn't exactly a design requirement when people designed, say, Haskell.
I could go on - there's a lot of stuff like this that is built the way it is because it made very good sense in the 60s, 70s, 80s or 90s. But the requirements really have changed, I think.
Can you, for example, spell out what you mean by "you really want your data model to be acyclic and not require GC"? What is cyclic about the "data model" in e.g. Go or Lua?
I can field that one. If a has A reference to B and B has a reference to C and C has a reference to A, then we have q cycle. Cycles play merry hell with garbage collectors and reference count destructors. Languages that force references to be a strict tree or DAG get cheap destruction in return - see C++ without pointers for example - I pop a local object off the stack and it's gone, along with all its children - no non-deterministic GC pause or delay, no Pythonic cycle check. Rust is built somewhat on this principle.
So "you really want your data model to be acyclic" means, "you want your programming language to forbid construction of cyclic data structures"? So, for example, connected graphs are not objects you can represent?
They do - but arguably being forced to define the distinction between direct hierarchical references, and symbolic links, helps constrain your data model and make it more rigorous.
Note that relational databases don't have back pointers either. All references between tables are symbolic. Last century, people tried to make databases that were general pointer graphs (google "network database" or "object database") - broadly speaking, it was a disaster.
They do - but arguably being forced to define the distinction between direct hierarchical references, and symbolic links, helps constrain your data model and make it more rigorous.
Note that relational databases don't have back pointers either. All references between tables are symbolic. Last century, people tried to make databases that were general pointer graphs (google "network database" or "object database") - broadly speaking, it was a disaster.
Right. The way I'd put it is: in system software, the iron law is that you don't make the programmer pay for anything she doesn't need to buy.
What you pay (GC) for the privilege of having pointer cycles in your data is grossly disproportionate to the benefit. Yes, there are a lot of things that are O(k) with pointer cycles and O(log n) without them. If what you buy from this optimization is worth the cost of GC, you are doing a lot of these things... a lot.
They already basically have all of the above, as a working tech demo. They actually had it like a year ago or more, but bits are missing or in progress still.
This seems super interesting. One of the people behind it is David Irvine [1], who apparently "was
Designer / Project Manager of one of the World’s largest private networks (Saudi Aramco, over $300M)." [2]
MaidSafe looks more similar to the original idea of Wuala. But they noticed they basically needed storage servers anyways, because the p2p nodes on people's computers and laptops had too much churn to keep enough copies online.
"Comedy writer" isn't quite how I'd describe it, but I'm surprised no one has mentioned that Urbit is run by the guy who writes/wrote under Mencius Moldbug, who is perhaps one of the more controversial people to achieve internet fandom. If you read through all the archives on his site and have no opinion (probably somewhere in the "I hate him" or "I find this reasonably convincing" statistical clusters), then your sense of outrage has been diminished, I would say.
Note: I myself am unconvinced by his writings, and find him to be just another ironic instance of the ironic nature of American culture, eager to avoid the appearance of naivete by abandoning all hopes that are fragile. Do with that what you will.
This sentence made me laugh more than it should have. Or maybe exactly as much as it should have, given that I spent a year drawing a Tarot deck that riffs on the Crowley/Harris Thoth...
I've been watching this since it's started. It has some magical atmosphere around it and you never now whether it's serious or not; whether it's a real technical project or some kind of artistic performance.
Earlier versions of the site featured a larger quantity of Moldbug's baroque, trollish prose style. Plus there was an extended argument about language design, due to the author being present in the thread.
Frankly, I'm disappointed. It used to be clearly the personal work of a lunatic. Now it feels more like a quirky open source project.
I can't decide if it's a science fiction novel written in code form, a programming environment, a game, a radical creative take on computing and networking ... Whatever it is, it's genius.
Uber-hackers of the future will write code for nanobots that cause them to self-assemble in to an android, the android will then write a program that generates a system like this that describes a new programming paradigm.
Or, something.
This reminds me of the Newton-Liebniz debate on creation.
"More specifically, Urbit is a personal cloud computer. Right now, the cloud computers we use run OSes designed for minicomputers in the '70s. An ordinary user can no more drive a Linux box in the cloud than fly an A320. So she has to sit in coach class as a row in someone else's database. It's definitely air travel. It's not exactly flying."
I doubt very much that the average person wants to either fly their own airplane or manage their own cloud computers, no matter how simple you try to make either of them.
What's so easy about driving a car? Over 30,000 people die per year in the United States due to automobile accidents. And that's after requiring every driver get a license, and teaching basic driving skills as part of our high school system. Driving a car isn't all that easy, and we're terrible at it. There's a reason that Google is inventing self-driving cars, not personal airplanes.
And the amount of possible simplicity is constrained by the problem you're trying to solve -- you can't manage to make a plane as simple as driving a car, because the car only has to navigate in two dimensions while the plane has to navigate in three. If a car stops, the car's just sitting there, whereas if a plane stops gravity is going to pull you down in a likely to be fatal incident. You can't make a plane as simple to use as a car without changing it into something other than a plane.
I suggest the car / airplane analogy was already strained before we got here.
Driving a car is easy, as evinced by the large numbers of people that are capable of it. Whether driving a car successfully (ie. without dying) is easy is obviously a matter for debate. With 0.000015% failing in this severe way, it might be argued that driving a car and dying is not particularly common, and could (no disrespect to the people involved) be thought of as a rounding error.
We have no evidence that Google isn't trying to invent self-driving or personal airplanes.
Try suddenly stopping your car on the autobahn, and see how tranquil the 'just sitting there' experience is.
Anyway, perhaps we are all missing the underlying point - an overly complicated solution (to an otherwise straightforward problem) has been the received wisdom for decades, and a re-think from fundamentals is almost definitely worth the effort.
"Anyway, perhaps we are all missing the underlying point - an overly complicated solution (to an otherwise straightforward problem) has been the received wisdom for decades, and a re-think from fundamentals is almost definitely worth the effort."
I don't know that the solution is overly complicated or that the problem is straightforward. Think of every human being as their own little Y Combinator startup -- everybody is their own little Me, Inc. Or Me, LLC. Whatever. Most people follow SOME version of "outsource everything that isn't a core competency." Like, it varies a lot from person to person -- some people go to McDonalds, some people are making their own meals from ingredients picked up at the local farmer's market, but very few people (not even most farmers) are fully self-sufficient farm-to-table for most of their meals.
So as a result of this, most people don't think of their computer in terms of it being a computer. And that's the most obviously computer computer they interact with! There's all sorts of even more abstracted away computers they deal with -- smartphones, cloud computers, etc. Most people don't care about computers, and don't in and of themselves want computers. They want to do things like "write a document," "share some family pictures with friends and relatives," "play a video game," so on and so forth. For those people, not only don't they CARE about HOW the computer is accomplishing those things, they get very upset whenever they see the wizard behind the curtain. They want all of those things abstracted away from them. From the point of the view of the most typical use case, trying to make computers easier to use by making sure the specification fits on a t-shirt seems to be rather besides the point.
Sure, I entirely agree that there's a large spectrum of user types (or people) out there.
You used the phrase 'most people' three times there to describe a quite likely common user type for off-the-shelf consumables. I am quietly confident the guys working on this are not targeting 'most people'. Or if they are, they are quite candid about it not being ready for them yet.
> You don't think the average person would want to fly their own airplane if it were as easy as driving a car?
Most people don't enjoy driving. Presumably (for most people) flying would be just like driving - exciting, interesting, and liberating at first, but would eventually become a dull and boring chore.
280 comments
[ 1.7 ms ] story [ 351 ms ] threadBut I'm not sure that's necessarily the aim. As I understand the project's aims (and I'm not involved, I just read all the docs a few months back), it's more important that the Internet of the future is not a tangled mess of technologies that are insecure on different layers. Then it doesn't matter so what OS people's local machines are running.
I hope the essay at the URL below is still relevant, it seems to describe the aims rather well. "The result: Martian code, as we know it today. Not enormous and horrible - tiny and diamond-perfect."
http://moronlab.blogspot.co.uk/2010/01/urbit-functional-prog...
My brain did not enjoy any wall of text that much since I read the bitcoin whitepaper. Now I want to learn more and be up to date.
"or even readline - this is not readline, it's internal to Arvo"
"As you may remember, to decrement 'a' we need to count up to it."
Conversely, here it's just because "it's different". I feel that this is a bit if a shame - some of the other parts of the project appear quite interesting, but making fundamental decisions in downright wrong ways just to mess with expectations comes across as silly to say the least. Why deliberately increase the learning barrier and drive people away?
There is one ground truth, origin, fixed point like the North Star: zero. There are an infinite number of possible falsehoods: all nonzero numbers. But Urbit chooses 1 as the canonical false.
So it's not very original at all.
However, years later I was introduced to boolean algebra, where 1 should be true and 0 — false, if we want multiplication to be "and" and addition "or". And it feels right, because intersection of two sets is (intuitively) multiplication, and joining — addition.
So, yeah, it doesn't seem like a good idea to me as well after all these years.
My expectation is that a set multiplication would give me a new set consisting of all pairs consisting of a single element from each set.
"Pairs" (and, respectively, cartesian product) is a bit more complex, and not so much related to boolean algebra deduction concept.
edit: I should add that I'm not claiming "you can't build measure theoretic probability from this formulation of booleans" is a strike against the project. Just addressing the math question.
g(y) = ∑ᵢ cᵢ × (y ∈ Aᵢ)
which is useful when you define integrals and expectations:
E g(Y) = ∫ g(y) f(y) dy = ∑ᵢ g(cᵢ) P(y ∈ Aᵢ)
where Y is a random variable with density function f. Any integrable function can be approximated as the limit of step functions, so this is a well-behaved way to get a general theory of integration.
Of course, one could replace (y ∈ Aᵢ) with 1 - (y ∈ Aᵢ) if one wanted to use "0" to represent the event (y ∈ Aᵢ) and "1" to represent its complement and not affect the truth of the math, but then there will be lots of termf floating around just to convert the notation into the terms that you need for the math.
This seems crazy ambitious on its own, and add to it that it's public domain. Very curious where this will be headed.
Do you mean the webshell, or the templating markup language? There is something you might want to look at called "Sail"
Having trouble finding you a link, but there are some mentions about it here:
https://github.com/urbit/urbit/search?utf8=✓&q=sail
Ah..
https://github.com/urbit/urbit/blob/master/urb/zod/main/pub/...
Check out the demo app, you can click a button and increment a number on the page, and it generates an event that gets reflected out (through some like AJAX) through the server, back out to as many subscribers as are currently viewing the page in their javascript-supporting browsers, happens almost instantly.
I have to apologize I have no short instructions to get you to this demo, it exists but I'm sure it may still rust more before it becomes a priority to build things based on it. I'm not sure if you're meant to be impressed by this demo, but there's also twitter API client you can use to tweet which is more obviously useful if not quite as whiz-bang.
http://localhost:8080/geg/demo
You'll find the code in your pier/ship/main/app/demo/core.hook
To reset the counter (wipe the app state), at your command-line, do:
I just tested it, I can see that it still works, but like I said none of this is guaranteed to go on working. It's all very alpha.This is called a %gall app. It's always running because the %gall vane runs the main/app/ apps in the background without intervention, like radio/core.hook that runs the server for the :chat app. See you in :chat maybe, if you have questions about how this works you will certainly be welcome.
Although, I read this:
"A pier is an Urbit virtual machine that hosts one or more Urbit identities, or ships. When you run bin/vere -c, it automatically creates a 128-bit ship, or submarine. Your name (a hash of a randomly-generated public key) will look something like:
~machec-binnev-dordeb-sogduc--dosmul-sarrum-faplec-nidted,...
and I laughed. A lot.
I like this article which introduces it:
Urbit is perhaps how you'd do computing in a post-singularity world, where computational speed and bandwidth are infinite, and what's valuable is security, trust, creativity, and collaboration. It's essentially a combination of a programming language, OS, virtual machine, social network, and digital identity platform.
http://alexkrupp.typepad.com/sensemaking/2013/12/a-brief-int...
Maybe every system that comes along and says "impossible to be subverted by centralized governments" in reality is just saying "come and try to stop me, Federales". Do you think that is that what we all should be doing instead?
I agree that any project which claims "impossible to be subverted by centralized governments" is just saying "come and try to stop me, Federales". Moreover, I feel that such claims are extremely difficult to substantiate (and so not particularly credible) and for the most part made by groups I'm not really motivated to associate myself with.
Speaking in a very general sense (having kept up with the news & goings on related to technology, privacy, corporate activities, and state security activities for the past few decades); it's my opinion that this tension is not only not in an ethically defensible or sustainable state, it's not in the state that most of the people in the western capitalist nations believe & expect it is.
So I find assertions like: "Despite messages between ships being encrypted, the founders state that they've purposely designed the network to make it as easy as possible for governments to regulate and control. It's not entirely clear why this is supposed to be a good thing." to be similarly worthy of skepticism and disconcerting as the "impossible to be subverted by centralized governments" claims. My feeling is that this statement translates fairly directly into "all user data is available to any corporate entity or state security agency for any purpose" and that this includes purposes like backchannel monetization through data aggregation and industrial scale warrantless surveillance & data collection.
It's pretty obvious to me that you are pretty invested in this project and I've only spent a few hours perusing the various docs, repositories, and blogs. So I'm fairly hesitant to make any sweeping statements or claims of certainty. So, with those qualifications in mind, my conclusion after my perusal is that this architectural design choice is unlikely to be a reflection of some sort of pragmatic policy coming from a non-ideological position of social responsibility that's striving to minimize any intrusion & abridgment of rights while still allowing for the realistic needs of businesses and state security agencies.
Frankly spoken, I personally find a number of the abstract concepts and architectural design choices in Urbit project to be fascinating and compelling. I've spent far too much time dredging around the information that is currently publicly available... Time I honestly can't afford. So it's really disappointing to me to find that there is a pervasive toxicity which is deeply intertwined with the project. My conclusion is that this toxicity makes the project broadly unusable (seriously) & and possibly even unfixable.
Elsewhere in this thread I saw someone claim that there were big things coming in a few months. If this is accurate I look forward to it. Perhaps there will be changes and new developments which will demonstrate my current assessment inaccurate. Honestly, that would make me pretty happy... but from what I've seen so far, I suspect that's really, really unlikely.
I don't claim to know everything about how Urbit works. I do think that superficially, Urbit is more able to respond positively to a demand from a state that sounds like "we think your network is being used to recruit radicals and a subversive element that threatens the nation is using it to communicate operational details and plan their attacks. can you shut it down" than say, BitTorrent...
I mean, it's a centralized network where the leader is able to push out updates to the software, and in a future version you may not even need to ask for them to be downloaded or approve them before they replace your running kernel. This will be considered a feature by anyone who comes from at least a managed Windows domain.
So, it has the potential to carry out a "poisoned updates" type attack, like Apple could do to an iPhone. And the more that I think about it the more ways I can imagine that ~zod can fuck you up. It's true I am interested in this project, more than passively, I am a kind of stakeholder who owns a large part of the namespace. The only thing that keeps my ownership safe is a line of text in the git repository under ames.hoon where my public key is stored, generated by an app called :pope and interpreted by a crypto suite that I cannot audit, simply for lack of time and understanding.
So, if I've led you down the wrong path or led you to believe something about the code that simply isn't true, I apologize! I feel I have to admit this is possible, I may have grave misunderstandings or mischaracterizations about the current state of the software, and to add to it, things are also always still changing now. It's in active development, pre-alpha, not yet sure who the customers are. YMMV, take with a grain of salt.
Speaking as a semi-informed bystander who's been following Urbit for a while now, it certainly seems like one of the problems it's trying to solve is the typical notion of "user data" as something controlled by third parties. Eg [1]:
> Where is Joe's financial data in mint.com? In, well, mint.com. Suppose Joe wants to move his financial data to taxbrain.com? Suppose Joe decides he doesn't like taxbrain.com, and wants to go back to mint.com? With all his data perfectly intact? [...] Imagine the restfulness of 2020 Joe when he finds that he can have just one computer in the sky, and he is the one who controls all its data and all of its code.
[1]: http://unqualified-reservations.blogspot.com/2011/10/persona...
That said, the current implementation has been explicitly called out (in past incarnations of the docs, at least) as not-remotely-trustworthy with sensitive private data.
What I'd say is that Urbit is not designed to be a darknet. It is not Tor and it's not Bitcoin. Also, it is not designed for external governments, or even its mysterious and sketchy founders, to govern - it is designed to govern itself. (Through user-level reputation mechanisms which have yet to be built, but are relatively easy to build - because the limited supply of identities controls Sybil attacks.)
In particular, Urbit should be quite good at enabling anonymous free speech beyond the reach of governments. A self-hosted node in your closet is quite practical and effective. There is no anonymization / onion routing (and you can't trivially route Urbit over Tor, because Urbit uses UDP), but someone could build that.
Although I don't want them to. I want to enable anonymous, or better yet pseudonymous, free speech. I don't want to help people buy drug$ or childpron through the mail. Fortunately or unfortunately, there are already much better tools for that.
if no, you're gonna experience even weirder things
1. A new computing model, similar to how combinators work.
2. A programming language which produces expressions involving these combinators.
3. An operating system built on the above.
4. A cloud computing environment built on the above.
Sorry, but while interesting, this sounds a little too ambitious, even by HN standards :)
There's code that you can run and can play with. It may sound super far fetched (and it is), but the guy behind it is putting sweat into it.
For example, Haskell and GHC took decades to become what they are now (a powerful language and compiler). It seems quite wasteful to rebuild that work. If absolutely desired, Haskell can also be converted into combinator form, and vice versa, so why not use it? Seriously.
http://doc.urbit.org/doc/hoon/tut/1/
Reading this feels a lot like dropping acid.
That being said, I'm curious what will come out of this.
X < Y => "oh, so X is always zero, huh?"
This smacks of privilege. Not everyone is or can be in a position to pursue ambitious projects. To say that these people should be barred from commentary is ridiculous.
Rather, if you want to dump generic negativity on a real, delivering project, you should justify why your negativity is relevant, for example by documenting your own related efforts.
If you want your cynicism to be respected, then yes, that's a privilege that needs to be earned. You can always say it, but it should be called-out as empty bullshit until backed with detailed reasoning or experience.
The grandparent comment comes from a pseudonym linked to no evaluable projects. It offers a costless, totally-generic pooh-poohing of a real project as "too ambitious". But that project is actually shipping code that works, with 126 contributors, many with a known history of contributions in related spheres.
Against that, the comment even uses an appeal to "HN standards"! As if, we should all be discounting this sort of stuff, on its face.
I'd prefer "HN standards" encourage such ambition, backed with code – not casually mock it with a ascii-smiley.
I get that this is more than just vaporware, but getting past the vaporware stage doesn't necessarily prove that something isn't too ambitious. When something is attempting to enact a paradigm shift, the final goal is adoption/usage, not just a working/functional product.
"Too ambitious" implies someone shouldn't even be trying for this goal. That's a corrosive attitude, and I'd like it kept-in-check by a requirement that sources of such negativity show their reasoning/experience/work.
Sounds like a 10-year research project, right? Actually I started working on Urbit in 2002, as a sort of "unsupervised PhD thesis." I figured it'd be done by 2008 or so.
We seeded a startup last fall and are busy turning a prototype into a product. You can now write a pretty decent web app in Urbit, but it's still too raw to stand the light of day. For instance, the network works, but we often run global flag days when we shut the whole planet down and change the protocol.
One of the main problems with Urbit is that extraordinary claims demand extraordinary evidence. If you're going to ship something this crazy, it has to work extremely well right out of the box. We had a sort of abortive non-launch last year when the project kind of got accidentally leaked, and decided we had to "unlaunch" and go back into quiet mode. I hate selling things I can't quite deliver.
One, as we know from Church-Turing equivalence, lambda and infinitely many other models of computing have the same expressive power. That doesn't mean they have the same practical utility, though.
Lambda in its Lisp incarnation is actually a rather poor substrate for something like a Lisp machine, I think, because it doesn't layer very well. You can define quite a simple Lisp model, but when you want to turn it into a practical Lisp, you don't add another layer - you grow hair on top of the existing layer. You grow a little hair, you get Scheme; you grow a lot of hair, you get Common Lisp.
I've never seen a lambda model (Qi/Shen perhaps a partial exception, but even there the underlying model is not very simple) that layers a complex language on a simple kernel. I think this is because lambda defines abstractions like symbol tables and function calls, which are user-level language features, in the computational model. The bells and whistles get mixed up with the nice clean math.
Another example is the fact that a modern OS should present itself to the programmer as a single-level store, meaning effectively an ACID programming language in which every event is a transaction. So, you're not constantly moving data across an impedance mismatch from transient to persistent storage, each having its own very different type system and data model.
But, if you're building persistently stored data structures designed to snapshot efficiently and remain maintainable, you really want your data model to be acyclic and not require GC. This goes in a very different direction from almost all the dynamic language work of the last 50 years.
Or, for instance, if your system is designed to work and play well in a network world, it really ought to be able to be good at sending typed data over the network. And validating it when it gets to the other side. Your type system ought to be able to do the same job as an XML DTD or JSON schema or whatever. Well... this wasn't exactly a design requirement when people designed, say, Haskell.
I could go on - there's a lot of stuff like this that is built the way it is because it made very good sense in the 60s, 70s, 80s or 90s. But the requirements really have changed, I think.
Note that relational databases don't have back pointers either. All references between tables are symbolic. Last century, people tried to make databases that were general pointer graphs (google "network database" or "object database") - broadly speaking, it was a disaster.
Note that relational databases don't have back pointers either. All references between tables are symbolic. Last century, people tried to make databases that were general pointer graphs (google "network database" or "object database") - broadly speaking, it was a disaster.
If I tell you a linked list of atoms (@) is made from this tile (type):
[p=@ q=*]
it becomes obvious, right?
[p=1 q=[p=2 ..]]
[p=1 q=[p=2 q=[p=3 q=[p=4 q=~]]]]
This should look like building a list from 1-4. There are no cycles, ~ is a terminator.
Q is the reference to the next item in the list.
This would constitute a cycle:
z=[p=1 q=[p=2 q=z]]
What you pay (GC) for the privilege of having pointer cycles in your data is grossly disproportionate to the benefit. Yes, there are a lot of things that are O(k) with pointer cycles and O(log n) without them. If what you buy from this optimization is worth the cost of GC, you are doing a lot of these things... a lot.
[0] http://moronlab.blogspot.co.uk/2010/01/moron-lab-goals-princ...
[1] http://www.forbes.com/sites/kashmirhill/2014/04/08/beyond-bi...
[2] https://github.com/maidsafe/MaidSafe/wiki/unpublished_papers...
Really well done, though!
http://unqualified-reservations.blogspot.com/
Note: I myself am unconvinced by his writings, and find him to be just another ironic instance of the ironic nature of American culture, eager to avoid the appearance of naivete by abandoning all hopes that are fragile. Do with that what you will.
http://mnemnion.github.io/blog/2013/12/19/commentary-on-ax/
I've been watching this since it's started. It has some magical atmosphere around it and you never now whether it's serious or not; whether it's a real technical project or some kind of artistic performance.
I think I have a destroyer somewhere.
Frankly, I'm disappointed. It used to be clearly the personal work of a lunatic. Now it feels more like a quirky open source project.
Or, something.
This reminds me of the Newton-Liebniz debate on creation.
I doubt very much that the average person wants to either fly their own airplane or manage their own cloud computers, no matter how simple you try to make either of them.
You don't think the average person would want to fly their own airplane if it were as easy as driving a car?
And the amount of possible simplicity is constrained by the problem you're trying to solve -- you can't manage to make a plane as simple as driving a car, because the car only has to navigate in two dimensions while the plane has to navigate in three. If a car stops, the car's just sitting there, whereas if a plane stops gravity is going to pull you down in a likely to be fatal incident. You can't make a plane as simple to use as a car without changing it into something other than a plane.
Driving a car is easy, as evinced by the large numbers of people that are capable of it. Whether driving a car successfully (ie. without dying) is easy is obviously a matter for debate. With 0.000015% failing in this severe way, it might be argued that driving a car and dying is not particularly common, and could (no disrespect to the people involved) be thought of as a rounding error.
We have no evidence that Google isn't trying to invent self-driving or personal airplanes.
Try suddenly stopping your car on the autobahn, and see how tranquil the 'just sitting there' experience is.
Anyway, perhaps we are all missing the underlying point - an overly complicated solution (to an otherwise straightforward problem) has been the received wisdom for decades, and a re-think from fundamentals is almost definitely worth the effort.
I don't know that the solution is overly complicated or that the problem is straightforward. Think of every human being as their own little Y Combinator startup -- everybody is their own little Me, Inc. Or Me, LLC. Whatever. Most people follow SOME version of "outsource everything that isn't a core competency." Like, it varies a lot from person to person -- some people go to McDonalds, some people are making their own meals from ingredients picked up at the local farmer's market, but very few people (not even most farmers) are fully self-sufficient farm-to-table for most of their meals.
So as a result of this, most people don't think of their computer in terms of it being a computer. And that's the most obviously computer computer they interact with! There's all sorts of even more abstracted away computers they deal with -- smartphones, cloud computers, etc. Most people don't care about computers, and don't in and of themselves want computers. They want to do things like "write a document," "share some family pictures with friends and relatives," "play a video game," so on and so forth. For those people, not only don't they CARE about HOW the computer is accomplishing those things, they get very upset whenever they see the wizard behind the curtain. They want all of those things abstracted away from them. From the point of the view of the most typical use case, trying to make computers easier to use by making sure the specification fits on a t-shirt seems to be rather besides the point.
You used the phrase 'most people' three times there to describe a quite likely common user type for off-the-shelf consumables. I am quietly confident the guys working on this are not targeting 'most people'. Or if they are, they are quite candid about it not being ready for them yet.
"An ordinary user can no more drive a Linux box in the cloud than fly an A320."
Maybe they aren't targeting most people, but if not, why are they talking about the ordinary user?
Most people don't enjoy driving. Presumably (for most people) flying would be just like driving - exciting, interesting, and liberating at first, but would eventually become a dull and boring chore.