tag:blogger.com,1999:blog-433674844243762704.post6157078718756354381..comments2022-03-31T02:48:23.792-07:00Comments on Moron Lab: Urbit: functional programming from scratchC. Guy Yarvinhttp://www.blogger.com/profile/18420221587655741375noreply@blogger.comBlogger43125tag:blogger.com,1999:blog-433674844243762704.post-65951993788547126582010-01-20T00:15:10.009-08:002010-01-20T00:15:10.009-08:00@Yarvin,
A functional namespace is not needed to ...@Yarvin,<br /><br />A functional namespace is not needed to move a facebook account to MySpace. A file namespace seems sufficient.<br /><br />Are you thinking of something along the likes of Google's Django hosting solution?newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-65630859024482835722010-01-19T19:27:21.278-08:002010-01-19T19:27:21.278-08:00I agree that something like AMI can be standardize...I agree that something like AMI can be standardized. However, this is simply not a *consumer* interface to the cloud. It is an industrial-computing interface.<br /><br />AMI obviously does not standardize any higher protocol or application layers. The problem of how you port your AWS account to Rackspace is a solvable problem with present approaches. The problem of how you port your MySpace account to Facebook, or your Yahoo account to Google, or whatever, is not.<br /><br />This is what I mean by "a tank, not a car." I hope it clarifies the matter...C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-56551815213321717912010-01-19T17:32:58.393-08:002010-01-19T17:32:58.393-08:00@Yarvin,
Have you ever called AWS and asked them ...@Yarvin,<br /><br /><i>Have you ever called AWS and asked them if they could port your image over to Rackspace? If the answer is "no," ask to speak to the manager. :-)</i><br /><br />Good point. However, that seems like a problem that will be fixed in time.<br /><br /><i>Moreover, an x86-64 virtual server in the sky, even if AMI or some other virtual image format could be standardized, is about the most cumbersome and unmanageable thing in the world.</i><br /><br />First off, AMIs are already standardized. You can even download them off of S3 if you are interested. Its a self-contained (efficient?) compressed set of files which tell Amazon systems everything needed to run an instance. AFAIK Amazon uses Xen which is sufficiently standardized to be available to anybody who runs linux.<br /><br />The probable (to me) reason we don't have a standard format for machine images is that the market simply isn't large enough for this.<br /><br />Also, do you have any guarantee or argument whatsoever for asserting that Nock decks will not be similarly cumbersome? Nock code is certainly <i>more</i> cumbersome than ASM and machine code which doesn't bode well.newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-26374677142903635992010-01-19T15:02:36.160-08:002010-01-19T15:02:36.160-08:00Sorry - the word I was looking for was "porta...Sorry - the word I was looking for was "portable."<br /><br />Have you ever called AWS and asked them if they could port your image over to Rackspace? If the answer is "no," ask to speak to the manager. :-)<br /><br />Moreover, an x86-64 virtual server in the sky, even if AMI or some other virtual image format could be standardized, is about the most cumbersome and unmanageable thing in the world. The difference between it and Urbit is like the difference between a tank and a car. "Let them drive tanks" is not a valid objection to my plan to build cars!C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-32173959005386155032010-01-19T14:47:55.935-08:002010-01-19T14:47:55.935-08:00@Yarvin
Then what exactly is AWS, Rackspace, etc....@Yarvin<br /><br />Then what exactly is AWS, Rackspace, etc...?<br /><br />We do have a standardized functional language -- x86 and x86_64.newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-83382770320055545912010-01-19T14:43:48.990-08:002010-01-19T14:43:48.990-08:00It's quite essential what the function is - if...It's quite essential what the function is - if you want to move your deck from one hosting service to another! After all, it's not really a proper migration if it doesn't mean the same thing in the new place as the old.<br /><br />You'll observe that standardized, general-purpose hosting is one thing a lot of people want, but none of them seem to have...C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-7051531206020633322010-01-18T12:13:19.975-08:002010-01-18T12:13:19.975-08:00@Yarvin
Yes, it is! However, if you're trying...@Yarvin<br /><br /><i>Yes, it is! However, if you're trying to standardize a *functional* rather than a simply passive namespace, you need to standardize functions. This is the purpose of Nock, in two words: standardizing functions.</i><br /><br />Except, there is nothing about Urbit that is defined in terms of what it does internally. All we need to know it that Urbit, somehow implemented, when given a card and a deck returns some information and that upon addition to the deck, still returns the same information. How the urbit function goes about doing this seems rather irrelevant. You yourself said that how a computer acts is up to itself. As for the "deck", it seems better seen as a massive bitstream that we lesser mortals like to call "software" and "the internet." We need know no more.newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-342891756492665252010-01-17T10:03:34.472-08:002010-01-17T10:03:34.472-08:00Two Verisigns are not viable: the second will be b...<i>Two Verisigns are not viable: the second will be bought up by the first in short order, because one is more profitable than two. Hence Thawte's acquisition.</i><br /><br />I missed this comment and need to respond to it.<br /><br />What's unacceptable (to me) is monopoly or near-monopoly ownership of a namespace. I'm not opposed to paying for identifiers, because any sort of short identifier experiences contention in a successful system; that contention needs to be resolved; it can only be resolved economically.<br /><br />Moreover, not only is there no real contention for wild identities, there is even no real contention for 48-bit identities. Contention only begins at 32 - and it only begins once the system is <i>quite</i> successful. For the foreseeable future, even short identities are free (as in beer).<br /><br />So: let me answer your question. If you have two, the pressure to amalgamate is great, because one has monopoly power. If you have, say, 255, however - <br /><br />Small amalgamations do not confer any monopoly power. To become Verisign, you need *all* 255. This is quite difficult to acquire, especially if the 255 are distributed widely and among holders with benign (ie, non-mercenary) ulterior motives.<br /><br />Such as EFF. If EFF had had Thawte's rootkey, would it have sold out? Highly doubtful. The trouble with browser rootkeys is that the system evolved in a ridiculously ad-hoc manner - nobody was actually trying to design a stable oligarchical regime that would not collapse into a monarchy.<br /><br />Not that monarchy is the end of the world. But oligarchy is far more desirable from the user's point of view. And since there is contention, anarchy is not an option - <i>someone</i> has to rule.C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-61403015052513568822010-01-17T09:52:25.642-08:002010-01-17T09:52:25.642-08:00For example, suppose that weather forecasts are si...<i>For example, suppose that weather forecasts are signed with some key. I am perfectly content with referring to that key by its 32-bit ID, because there is very little risk involved on my part.</i><br /><br />Exactly. The trouble is that this works when you're trying to validate a weather forecast that you've referenced by other means. When you're trying to find the data from the name, however - dereferencing /ID/weather - teh ugly emerges.<br /><br /><i>VJ's idea of broadcast documents is very much possible without Nock.</i><br /><br />Yes, it is! However, if you're trying to standardize a *functional* rather than a simply passive namespace, you need to standardize functions. This is the purpose of Nock, in two words: standardizing functions.<br /><br />As for Nock as an IR, this will be a lot clearer once you can see and play with Watt. IR is a very general term. Nock should not be confused with RTL, but it is definitely intermediate and it's definitely a representation.C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-12909248498189249502010-01-17T06:12:16.443-08:002010-01-17T06:12:16.443-08:00@newt: That's absolutely unacceptable. Actuall...@newt: That's absolutely unacceptable. Actually any amount of money is unacceptable for identifiers.Anonymoushttps://www.blogger.com/profile/00975555602783595811noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-80211172169766348922010-01-17T00:47:25.652-08:002010-01-17T00:47:25.652-08:00@Daniel
If that is all you need, use X.509 certs....@Daniel<br /><br />If that is all you need, use X.509 certs. They are relatively easy to get -- only a few dollars per year (which for an organization is a pittance) and the risk from a central authority is far far lower than the risk of forgery from a 32 or 64-bit ID.<br /><br />PGP is quite capable of using X.509 certs seamlessly.<br /><br />If you have a friend, then exchanging verified certs should be easy and you can sign the certs yourself.newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-18414599200928326392010-01-17T00:29:05.682-08:002010-01-17T00:29:05.682-08:00@newt: But we are talking about references here. A...@newt: But we are talking about references here. Also, you can safely rely on 64-bit IDs for validating keys as long as the value that you are protecting is less than the cost of the attack, which is actually quite often the case. As long as it is the user's choice, it's not a problem.<br /><br />For example, suppose that weather forecasts are signed with some key. I am perfectly content with referring to that key by its 32-bit ID, because there is very little risk involved <b>on my part</b>. Other people, who rely on those weather forecasts for some economic activity, might be more cautious as to what they accept, so they might go up with the bit count.Anonymoushttps://www.blogger.com/profile/00975555602783595811noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-16346058534528263592010-01-16T20:00:17.240-08:002010-01-16T20:00:17.240-08:00@Daniel
The User IDs are not designed to be a sec...@Daniel<br /><br />The User IDs are <i>not</i> designed to be a security measure (at least not anymore). The cryptographic (and nearly impossible to fake) hash signatures are. If you rely on the 32 or 64 bit IDs for validating keys, you have a problem.<br /><br />@Yarvin<br /><br />Why mix identification and validation?<br /><br />Any organization has a unique ID and a certificate with lots of identifying information and a cryptographically secure signed hash liking the organization to the ID. There is no need for there to be a link between the keys an organization uses and the ID it has. IMO, such a link is a terrible idea. What happens when an organization wants to revoke a key but not its ID or vice versa?<br /><br />What is the point in creating this useless link?<br /><br />Also, I think my last comment was approaching the heart of my problem with Nock: what is the purpose? Yeah you find it aesthetically pleasing but so what? Nock isn't useful to program in because it is too low level. It is not useful as an IR because it is too far from machine language. It exists in limbo as a marginally interesting CS project. VJ's idea of broadcast documents is very much possible without Nock. Heck, it is quite doable in our current ecosystem of URIs and protocols (modulo network externalities).newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-43821046791829485432010-01-16T17:03:23.269-08:002010-01-16T17:03:23.269-08:00I like the knob idea, but the problem with Nock is...<i>I like the knob idea, but the problem with Nock is that you cannot fully turn the knob to raw Nock, because it won't execute once in the programmer's lifetime.</i><br /><br />Sure you can - this is a stateless system, after all. It doesn't have to boot. You can't process packets and resolve names, but you can turn the knob to raw Nock and test add, multiply, etc.<br /><br />There's also a lot of opportunities for metacircularity in this system. Nothing stops you from writing a raw Nock interpreter within a jet-propelled Nock environment.<br /><br />(Normally even metacircularity will be accelerated, though. For example, one thing I think we'll see at the Urbit level is Nock with an extra operator 7 - dereference Urbit path.)C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-50176932164852574722010-01-16T16:57:51.573-08:002010-01-16T16:57:51.573-08:00I'm not a PGP geek, and I've never seen ei...I'm not a PGP geek, and I've never seen either a 32-bit, or I think a 64-bit suffix, in the wild. I didn't even know they existed. Thank you for explaining them - I now know how they work, too.<br /><br />In the PGP context, these short IDs are pretty cool. In the Urbit world, they don't really work, and here's why.<br /><br />The trouble with this approach is that the suffix is (in many cases) enough for verification of an identity that is already communicated through another channel. But it is not enough to serve as the root of a namespace. <br /><br />If you can say "/id/file," id needs to be unambiguous - not only can collisions be attacked, but even resolution becomes very problematic.C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-59354133227356020982010-01-16T13:16:50.052-08:002010-01-16T13:16:50.052-08:00I like the knob idea, but the problem with Nock is...I like the knob idea, but the problem with Nock is that you cannot fully turn the knob to raw Nock, because it won't execute <i>once</i> in the programmer's lifetime. Hence my suggestion with binary atoms.Anonymoushttps://www.blogger.com/profile/00975555602783595811noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-9874923103615453952010-01-16T13:12:47.783-08:002010-01-16T13:12:47.783-08:00Two Verisigns are not viable: the second will be b...Two Verisigns are not viable: the second will be bought up by the first in short order, because one is more profitable than two. Hence Thawte's acquisition.<br /><br />But why not use suffixes (or prefixes) of wild names and let people decide how long a suffix they want to use? PGP got it right with the fingerprint (160 bits), the long ID (64 bits) and the short ID (32 bits). Yes, I can generate a key that matches anybody's short ID, but they can always fall back to using longer IDs, so I won't bother attacking even 32-bit names, but they can (and do) collide by accident as well. Now, 64-bit ID's are substantially more difficult to attack (requires huge botnets or specialized hardware), and they do not collide by accident. And still, you can always fall back to the fingerprint.<br /><br />Now, this same idea can be generalized by letting people use arbitrarily long suffixes (or prefixes) of their wild names. Spanish aristocrats have done so quite successfully. Also, for most students of cryptography Al-Kindi means <a href="http://en.wikipedia.org/wiki/Al-Kindi" rel="nofollow">Abū Yūsuf Yaʻqūb ibn Isḥāq al-Kindī</a> even though there have been quite a few Al-Kindi's out there.Anonymoushttps://www.blogger.com/profile/00975555602783595811noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-37381283800127726412010-01-16T11:43:18.430-08:002010-01-16T11:43:18.430-08:00@Yarvin
There are two ways to test: with two prog...@Yarvin<br /><br /><i>There are two ways to test: with two programs, and with one program and a bunch of hand-checked test cases. I prefer the former.</i><br /><br />Then why bother with Nock? It is quite possible (and easy) to make a human understandable language with easy semantics -- scheme being one possible example. Then the scheme version can be tested. Of course, there is an even better solution -- the scheme version can be compiled and testing is not necessary. Mathematical equivalence in that is case is indeed guaranteed by the compiler.<br /><br />As to your "memorable" 32-bit numbers. They don't seem to help. Also, the routing framework which helps to find the number is much more an overlord than the name-resolution system. If somebidy is really so worried about the naming system, they can come up with their own registry as a person can now (try to) do with IP addresses and bookmarks.newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-90427689219794659572010-01-16T11:17:31.784-08:002010-01-16T11:17:31.784-08:00Stanislav,
I'll second that - FPGA nock would...Stanislav,<br /><br />I'll second that - FPGA nock would be mondo cool. Of course eventually it will need FPGA jets, as well. Unfortunately, my hardware chops are almost nil, so I really have no other advice! Still, the beauty of a small spec is that it needs no guru...C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-77397670657039985012010-01-16T11:14:11.804-08:002010-01-16T11:14:11.804-08:00Example: If you want to jet a parser, the testing ...<i>Example: If you want to jet a parser, the testing better have damn good coverage. Far better to have an automated system of parser generation and then be able to define a parser in a few lines.</i><br /><br />By "parser" I actually mean "metaparser," ie, a function whose arguments are a text file and a constructive grammar. So, yes. It's this that gets the jet. It's not your grammar that gets the jet, because the typical formula in the grammar is just doing some consing.<br /><br /><i>Everybody knows what they want their program to do. The problem is making sure that the program actually does it.</i><br /><br />Well, what you're testing is that two programs are equivalent. You could have written the same bug twice - but that's a lot more unlikely.<br /><br />There are two ways to test: with two programs, and with one program and a bunch of hand-checked test cases. I prefer the former.<br /><br /><i>Actually, from the user perspective, anything in terms of bits is too much. Notice now that nobody remembers a slew of phone numbers. They remember a bunch of names (sometimes) and use a mapping to go back and forth. The same applies to the internet.</i><br /><br />Consider the way Facebook does it. There are three Facebook identities: the ID, a number that appears to be about 32 bits; the real name, which is not unique; and the username or handle, which is unique and first-come first-served.<br /><br />The Facebook ID is not memorable, as such. However, it's straightforward to write a function which invertibly maps a 32-bit number to a string which *is* memorable. I've done this. The function could probably be improved, but here are some random examples:<br /><br />176.215.16.104 == "divzip-dibbel"<br />30.122.0.74 == "pobmol-dabmek"<br />149.229.247.52 == "nitvas-siztif"<br /><br />Not exactly high technology. But you'll see that the latter is a lot more memorable than the former - not as memorable as a human name, of course, but not too far from a classic handle such as "monkey79." And unlike either, it does not require a central directory.<br /><br />Now, on top of this namespace, you'd certainly want to maintain a *real* namespace that would bind human names to these entities. There's no substitute for human names. However, if you have a numeric identity which is significantly more memorable than, say, phone numbers, you have a simple, solid layer on which to build a human name directory at a higher level.<br /><br />Human names are the <i>most</i> memorable. But managing human names, both individual and corporate, is a huge business problem. If you have a lower-level identity system which is usable, clean and simple, you have a good substrate on which to build the higher-level names.<br /><br />This is why Facebook started with IDs and built human names above it, then added usernames. My guess is that if Facebook could make IDs more memorable in this trivial way, usernames would not be needed. <br /><br />But, of course, Facebook IDs make you basically a serf of Facebook. No one should have to be a digital serf...C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-46055348892702524052010-01-16T10:46:16.279-08:002010-01-16T10:46:16.279-08:00@Stanislav
Good luck.@Stanislav<br /><br />Good luck.newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-77510457064172858812010-01-16T10:10:25.940-08:002010-01-16T10:10:25.940-08:00newt0311 said:
How do you plan on handling memory...newt0311 said:<br /><br /><i>How do you plan on handling memory management?</i><br /><br />For now, something like the usual cons cells (like the SCHEME79 chip.)Stanislav Datskovskiyhttps://www.blogger.com/profile/13742896763675184843noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-45500013013910879722010-01-16T09:59:49.174-08:002010-01-16T09:59:49.174-08:00@Yarvin
The jet isn't really "impure&quo...@Yarvin<br /><br /><i>The jet isn't really "impure" in the functional sense, because it doesn't have side effects. In fact, it needs no OS privileges - just a block of memory.</i><br /><br />Without a new OS (and even with perhaps), the above simply cannot be verified. Unless you are the only one writing jets, your solution is unsatisfactory.<br /><br /><i>Even Java would probably be improved if all native methods (that were native only for speed, not for system calls) had to come with a parallel specification in pure Java.</i><br /><br />Believe me when I say that Java does not have many of these. Most Java methods which do not need system calls are in Java. However, the reason they can do this is because JVM bytecode can be run efficiently on x86 computers.<br /><br /><i>Nock is actually not that hard to compile to machine code, I think. At least, relative to other languages in its class.</i><br /><br />The entire class is nearly impossible to work with. Even GHC takes a few short-cuts from pure lambda calculus and whether you like it or not, GHC is the closest that you are looking at here.<br /><br /><i>Slow interpreters with optimized library routines are well-known to be viable... </i><br /><br />Interpreters can not run themselves like compilers can compile themselves.<br /><br /><i>However, if you can be content with mere testing, this process will test your code quite unobtrusively and effectively. </i><br /><br />If testing is all that Nock gives, it <i>is</i> a worthless idea. Testing can be done quite well without Nock. Everybody knows what they want their program to do. The problem is making sure that the program actually does it. Testing is what everybody does today and clearly (according to you), it is not sufficient.<br /><br />Example: If you want to jet a parser, the testing better have damn good coverage. Far better to have an automated system of parser generation and then be able to define a parser in a few lines.<br /><br />In an earlier post:<i>I would say that cryptographically, 128-bit suffixes will almost always do.</i><br /><br />Famous last words.<br /><br />Actually, from the user perspective, anything in terms of bits is too much. Notice now that nobody remembers a slew of phone numbers. They remember a bunch of names (sometimes) and use a mapping to go back and forth. The same applies to the internet.<br /><br />The same solution is needed for Urbit (that is why I wanted to use Urbit as the base layer and build a dynamic file system on top). Assign identifiers with whatever number of bits you want (enough so that we don't run out) and then make a mapper back and forth. Digital feudalism will work quite well here as it has worked for DNS and IP addresses (which are pretty much exactly the same problems -- uniquely naming entities). If people want a strong identity match, they will have to contact the entity and get some keys themselves. This can be done through the web of security that VJ talked about. In practice, I think that this will be almost equivalent to the digital feudalism idea (unless I am misunderstanding your digital feudalism idea which is quite possible) but slightly better because there is some verification.newt0311https://www.blogger.com/profile/00275501056310821335noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-79108532513886041722010-01-16T09:38:19.515-08:002010-01-16T09:38:19.515-08:00Without a guaranteed means of verifying the equiva...<i>Without a guaranteed means of verifying the equivalence of the two blobs of code, Nock is just a very expensive waste of time.</i><br /><br />Well, a guaranteed means is a lot to ask for! Mathematically, I mean. However, if you dial optimization down and run the Nock formula, the jet still runs. And its result is compared to the formula's result.<br /><br />So if ya want <i>verification</i> - that's a research project. However, if you can be content with mere <i>testing</i>, this process will test your code quite unobtrusively and effectively.C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.comtag:blogger.com,1999:blog-433674844243762704.post-76907145359295889762010-01-16T09:32:49.606-08:002010-01-16T09:32:49.606-08:00newt,
The jet isn't really "impure"...newt,<br /><br />The jet isn't really "impure" in the functional sense, because it doesn't have side effects. In fact, it needs no OS privileges - just a block of memory.<br /><br />Yes, you are writing your function twice! I have done quite a bit of this, so I can speak to the experience. The result is (a) not twice as much work, and (b) much more than twice as reliable.<br /><br />Moreover, you don't have to do this in ordinary programming. You have to do this where, in a non-Maxwellian environment, you'd just write a native method. Even Java would probably be improved if all native methods (that were native only for speed, not for system calls) had to come with a parallel specification in pure Java.<br /><br />Nock is actually not that hard to compile to machine code, I think. At least, relative to other languages in its class. However, this is a significant engineering project which I'd rather not have in the critical path. Slow interpreters with optimized library routines are well-known to be viable...C. Guy Yarvinhttps://www.blogger.com/profile/18420221587655741375noreply@blogger.com