131–140 of 177 posts
I think it's important to note that Urbit - a very interesting piece of work that deserves more attention - would've been presented at Strange Loop if not the PC crowd made Strange Loop disinvite Curtis Yarvin (the creator of Urbit) for reasons unrelated to Urbit. Using throwaway for obviously reasons.
Earlier quoted context omitted.
It definitely doesn't mean you have to wait for the audio to finish playing. It does mean that your brain thinks the audio. Which has a lot of consequences, including the energy it takes to think... Most people do read poetry silently, in the same way they read prose (I don't literally subvocalize), and the sound still is everything. Try reading these two poems silently: http://www.mcgonagall-online.org.uk/gems/the-t…
> It does mean that your brain thinks the audio. I'm sorry, that's simply not true. At least for me. It may be true for you. From the things you've said, I suspect you're a word-at-a-time reader, treating words as a sequential symbol stream, processing them as if they were speech. This is just one of the several different styles of reading. Others exist. I am, as I mentioned above, a phrase-at-a-time reader. I take i…
Earlier quoted context omitted.
I read more like a page at a time. Some might accuse me of being a page-at-a-time writer. Compare the way you perceive "~~" to the way you perceive "++". I hear these as "sig sig" and "lus lus". (Or rather, as "slus," because that's a further Hoon abbreviation, but never mind.) You don't hear the former at all; but you hear the latter as "plus plus," don't you? This is because "tilde tilde" is so heavy your brain doe…
> You don't hear the former at all; but you hear the latter as "plus plus," don't you? I really do not. A short silence, both of them. I suppose it depends on how you normally code. I have never had a need for speaking out code and am not well versed in it.
This is especially true of code and symbols. For example, consider this poem
> is it already too dark > to play tennis with a racket > i asked? > while I code with [
and contrast with this one
> The house filled with laughter > from mother and daughter > Both were fiends > but neither friends
or even better, combine the two
> I never used a ~ > as well as Oscar Wilde
Earlier quoted context omitted.
No, you're right, it's a highbrow dismissal. Let me be a little more detailed. Once you've built a system that's both a protocol and an OS, you realize that putting an abstraction barrier between them is like building a cow by building two halves of the cow, then sewing them together. It's incredibly hard and the resulting cow doesn't work very well. Take a problem like identity. Is this an OS problem, or a protocol…
The notion that the OS and the network are essentially the same thing, a series of procedure calls somehow knitted together either with a stack in memory or as a series of serialized frames on a network, strikes me as a very 1980s way of framing computer science. I feel like the last 20 years of network software development have been a repudiation of that idea. So yeah, I find it frustrating that Urbit insists that a…
But 1980s? Not to make it personal, but I finished Brown in 1992 and dropped out of Berkeley in 1994 (where I arguably invented ASLR [0], though the basic idea was Larry Peterson's) My field was OS in general and networking in specific, I took Mark Weiser's ubiquitous computing seminar from Mark Weiser, and if there are pieces of paper entitling me to talk about anything, it's '80s networking. "And you, sir, are no '80s networking."
'80s networking as I remember it: at Brown, it was all about TCP/IP versus OSI and crap like that. At Berkeley, the emphasis was more on ATM. And crap like that. Congestion control algorithms, like garbage collection, can be invented indefinitely. Frankly, the only thing more boring and irrelevant than '80s networking: '90s networking. At least in the '80s people still wrote new transport layers and stuff, in the vain delusion that they might get adopted.
And at least in the '90s they still invented their own IETF application-layer protocols that got deployed, or that you could imagine getting deployed. Like that great winner, XMPP. (I spent a particularly depressing afternoon as a fly on the wall in a pre-XMPP working group at some IETF in '97 or '98.) And ACAP? Wherefore art thou, ACAP? And all the calendaring stuff? Various bits of things that were designed to be open networks got fitted into various proprietary protocols of the 2000s.
(Nothing is ever new in CS, and if you're a grad student looking for new ideas about networking, this pattern suggests that the best place to look is '60s and '70s papers. Have fun digging! Or does no one do that these days, either?)
So anyway, we were talking about cows. I get it. You're not interested in cows, only in cow heads. Obviously I share your feelings about cow heads. Love 'em.
So, your problem is: the Internet is full of firewalls and crap. It's a restricted-routing network. This sucks. I remember the Internet when it had no firewalls. You do too. We remember when the Internet was a social network. What is the Internet now? Like we say on the intro page, it's a fing modem, which you use to log in to fing AOL.
So let's create an overlay network with unrestricted routing. Some kind of P2P scheme. (I hope you know Adam Ierymenko's ZeroTier -- he's api on HN. I believe he's basically solved this problem as you define it.)
Great! You have a near-perfect VPN. What else is an overlay network? Have you recreated the Internet as a social network? You know, the Internet that had a distributed Reddit called Usenet -- which, as a digital society, was as far above Reddit as Reddit is above YouTube comments?
Dude, you haven't even come close. All you have is another VPN. Why were those restricted networks put in place? Nobody had a "firewall" when I was at Brown.
To put it another way: what is your overlay network doing? Since you're delegating layer 7 to the OS, you're providing the same basic service as '80s networking, '90s networking, and of course now networking. You're sending datagrams or streams or something between Unix processes on different Unix machines.
For starters, how do you identify these endpoints? A ZeroTier address is an identity in a sense, but it provides no useful information. There's no way to tie it to any identity you're actually interested in.
Who needs a new network for Unix processes to receive data from an effectively infinite set of anonymous untrusted identities?
We already have one of these networks. We call it the Internet. It was a great social network when everyone with an IP address was an institutionally trusted entity. Once that became untrue, we put firewalls on it and it turned into a modem. Anyone can see that this will happen to your overlay network. ZeroTier can be used as a public network or a VPN -- it's a great VPN. With due respect to api, I would focus on that side of the business :-)
But of course there's a bazillion VPNs. You want something different -- you want a cow head. You don't care about the cow body. That's fine. We don't all have to be generalists.
Your theory is: why hasn't someone built a cow head and stitched it onto the alligator body yet? My theory is: (1) if you stitch any head to an alligator and it sticks, it's probably an alligator head; (2) our alligator already has a head, and nothing will be gained by cutting it off and stitching it back on again.
Now, you can see how this process of inferring the rest of the cow goes. You need an identity system, or something, for your network. A PKI. The cow neck. Who holds these identities? Processes on Unix servers? O rly? You're going to infer that person X signed document Y, because person X is connected -- in some way -- to a Unix process with access key to K? Sure, I guess we do that for HTTPS servers, but... for individual human beings?
Ok, you're going to build access to K as a separate component of each application? One keystore per process? Or since it's 2015, per container or whatever? Or the whole computer has access to K? O rly? This is good, this is really good.
So you decide to do what the browser did: create a new opaque layer, above Unix proper and isolated from it, to manage your applications. Imagine if JS "apps" could make system calls through the browser. There'd be no such thing as a Web app. HN would be like a Java applet or something.
An opaque layer (imagine a node that couldn't make system calls, for instance) gives you two wins: it lets you standardize the semantics of a network node precisely, and it lets you run untrusted code with perfect encapsulation. And it offers the even more intriguing possibility of running other peoples' code automagically, which is incredibly useful in a distributed system -- for example, to disseminate protocol validator updates. Thus, "the browser for the server side."
And you go on cow-engineering thus. Until you have the full cow. Then you can drink milk every day and laugh at your strange detour into cow-alligator Frankenstacks.
Earlier quoted context omitted.
No, you're right, it's a highbrow dismissal. Let me be a little more detailed. Once you've built a system that's both a protocol and an OS, you realize that putting an abstraction barrier between them is like building a cow by building two halves of the cow, then sewing them together. It's incredibly hard and the resulting cow doesn't work very well. Take a problem like identity. Is this an OS problem, or a protocol…
The notion that the OS and the network are essentially the same thing, a series of procedure calls somehow knitted together either with a stack in memory or as a series of serialized frames on a network, strikes me as a very 1980s way of framing computer science. I feel like the last 20 years of network software development have been a repudiation of that idea. So yeah, I find it frustrating that Urbit insists that a…
Granted, the high-level interface you want to present to the programmer is something like RPC. The two application-level communication paradigms in Urbit are a transactional "poke" and publish-subscribe.
A key difference is that a successful poke (a) contains no return data and (b) is piggybacked on the packet ack. Actually the whole transaction is piggybacked on the packet ack ("single acknowledgment" or "E2E acknowledgment.") Oh yeah, that's another feature that crosses OS/protocol lines.
This lets us produce a particularly non-leaky network abstraction against not procedure/function calls, but Arvo's stacked event calls (if normal events are a lot like GOTOs, Arvo events are more like GOSUBs). So it's not quite RPC. But it's fair to be reminded of RPC.
But at the actual packet layer, a network is a bus for sharing large (but not too large) unsigned integers, which may or may not arrive anywhere. (Network programming is quite a bit easier, by the way, given a bus-width-independent language that can just model packets and blobs as big atoms, then operate on them functionally.)
Effectively, a packet you hear is something that someone said, not something that someone told you to do. Hearing it is learning something. Idempotence at the packet level is crucial, because if someone tells you something twice, it's the same as telling you once. The protocol exists to answer the question: what happens to me if I learn this number?
It's only a short step from here to defining the entire state of an endpoint as a permanently fixed function of the list of numbers you've learned. The computer's state is a function of its packet log. What could be more natural? Why would anyone define a computer in any other way?
But of course, defining a computer as a pure function of its packet history requires you to define its VM and OS as part of defining the protocol.
And a general rule of protocol design is that your chance of achieving a compatible protocol is inversely proportional to the square of the length of the specification. It's also inversely proportional to the extensibility of the protocol.
So you're going to squeeze all of Unix into your RFC? Or even all of JS, bless its soul? And again, you wind up looking for something like Urbit. You may just be interested in the cow head, but you can't get to it without building the whole cow.
Earlier quoted context omitted.
This definitely counts as a highbrow dismissal! As I age, I find it harder and harder to remember how easy and natural it is for young people to learn new things: ideas, theories, languages, and yes -- names. Alas, we can't rejuvenate our brains. I know of only one (partial) cure: have your own kids. You'll feel jealous all the time, but it's worth it. It's painful to admit that I'm probably too old to learn other pe…
FWIW: I wrote the first half of that comment, then 5 minutes later, feeling it was too snarky without explaining itself, added the sentence: "There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters." I'm a parent of two teenagers, neither of whom seems particularly interested in new names for punctuation.
An XS Nock shirt is a dress for my daughter, but she loves the "code." I guess all kids are different. But you never know what they're ready to learn until you try to teach them.
>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?
Earlier quoted context omitted.
You mean that out of all the things in this combinator [0] flavored abstract rewrite system [1], programmed via a symmetrical [2], forward-inferenced [3] typed language, exposing modula-2 style per-code-block compilation control [4], all designed to support a content centric [5], natively networked [6] global computing environment with sovereignty-hard siloing capabilities [7], the most difficult part to understand i…
Yes.
Hopefully the tractability of the number base will help bootstrap your familiarity with the ASCII alt-names. When you've poked around Urbit enough to see the ideas described in the link storm above, I would be very interested in discussing them with you (or even to discuss them in a general, non-Urbit context, both are standing offers).