 This is the seventh weekly update of the t2 tile project. Let's get into it. The goal from last week We had two possibilities one was to actually build a new board that has a light sensor on it and so forth that was contingent on the board actually getting in from the Fab house it did not so that didn't happen Although we did finally just as of yesterday Managed to get a tracking number and it's supposed to arrive by tomorrow Now I am not going to put myself on the hook for assembling one of these boards for next week because I'm going to be traveling some for the holidays But I have other stuff to focus on that'll be easier to do when I'm away from all the hardware stuff So that will have to wait a couple of weeks. The other thing I was supposed to do was to get the Ubuntu packaging back in my brain. I haven't released Ubuntu packages since 2000 summer 2017 I did a little bit of that But I didn't actually get to go but our one and only goal my one and only goal or one only goal for next week is To actually get oolong for with MFM That is the brick wall geometry for the t2 plus the first version of splat out in Ubuntu packages Which means it will hit master in the repose and so forth for other possible purposes. So That's what we're shooting for Today We've got a little bit of news I wanted to have a few comments following up on a really good discussion about fork bombs and a come and see that was on the YouTube channel and If I didn't get to your comment, I apologize for it I I pick a few sometimes I answer in the comments sometimes I answer here sometimes both and then actually I want to spend most of the time it'll probably be eight or ten minutes talking about the actual architecture of the t2 specifically and Usually I'm afraid to talk about this stuff because I fear people are gonna get bored But on the other hand, you know when I as a programmer want to hear someone you're talking about a computational model I actually want the details. I want to know what really is gonna happen and how it all actually works So I can start thinking about who that sounds like that would be fun to play with that sounds like that's a trap and so forth so I'm gonna go through it at a pretty detailed level try to get all the sort of the actual the way it works And from the hardware point of view a little bit about the way it works from the software point of view that's today Now one of the things that happened that I wanted just to show you because I thought it was kind of cool Is I was working through the Ubuntu Packaging stuff and there's a bunch of changes that need to happen on the MFM command line and the alarm command line Because changes internally between a division of labor for various purposes talk about it another time But one of the things I did was I got the CPP the C++ demos working again That had been kind of broken for a while and so this What this works on this actually hasn't been pushed yet, but this will work as of next week put it that way So you run with the command line argument CPP demos and you get this you know completely packed full Palette of elements combined in all kinds of various stuff I just want to show you the one that you may folks may have seen because there actually is a separate video for it This is Trent Smalls procedural city generation Implemented the move the feast in C++ So you start with a sidewalk and the sidewalks make streets and they pop intersections and the intersections intersect with each other And where they mismatch that makes little parks and so on Eventually this thing starts putting out little buildings and the buildings send out cars They wrap themselves around and it ends up looking to me like you know the Looking down from a helicopter or a drone shot of one of those cartoons when I was a kid What was it Dick Tracy Batman something like that? Anyway Getting all of the information that these Adams used to communicate with each other packed into individual Adams is actually quite a trick Trent was one of the original authors of the move a feast machine simulator So if anyone's going to be able to know how to do it he is there we go and then Eventually the buildings start to pop up and so on not going to let this run because it's going to take a lot of time But it's pretty fun to play with there's a bunch of other stuff that maybe we'll come back around because a lot of this In the CPP demos these various things are more of the kind of basic bottom-up dynamics This sort of design patterns for robust first computing that we should be familiar with on the one hand and have names for On the other hand so that we can talk about them back and forth to each other. Anyway, okay So that I just wanted to show you a little bit All right We've got let's push on so we've gotten as part of my excuse for why I don't have the packages out and it really is an excuse Is that we got a pull request from Spencer Harmon with a bunch of fixes and improvements for splat and that's like Thank you You know to improve the the pearl packaging layout to make it more official and and to make it work on his system and so on and so forth It's a great thoughtful commit. It just came in yesterday or the day before. I don't know So I haven't really gotten to evaluate it, but I want to figure out how to get it into before the Oolong for goes out next week You know be warned Spencer in particular That I've been kind of bad about actually trying to place the files out into the file system like they're supposed to go and Pretty much everything goes into user Libs Oolong and then directories underneath that so my inclination will be to put the demo Source codes there as well But we'll see I haven't really had a chance to look at it But again, we're seven weeks in to you know, I finally tentatively asked the universe You know, can you help me do this and and help us coming back and it just really makes me feel great So thank you so much in the same vein Andrew Walpole who's doing all the screen stuff now has Mfm rocks store at MFM rocks that's store and the comm I'll put the link in the Description below and you can buy Carpe event window t-shirts. I've ordered two. I haven't gotten them yet But again Totally great So I feel very very jolly and you know the only thing that make it even better is if I had a little bit more progress So let's push on All right, yes there are There was a tremendous amount of Good thinking and discussion and back and forth on the YouTube comments about fork bombs and incumbency and so forth and You know, I if I don't didn't get your comment up. I apologize, but you know, I just sort of pick a few I responded to some down there You know Andrew Walpole Mr. Everywhere says, you know, how about crypto? It's sort of a standard approach Oh, hi says, you know, how are we gonna avoid bootlegging if this thing is really gonna be indefinitely scalable? I know everybody says infinitely, but I think infinite. I Don't believe in infinity infinity is brain damage So I say indefinitely to try to drive home that you know, is it this big? Well, we could add more You can't say it's definitely only this big because we could always add more so it's indefinitely scalable Just to avoid the word infinity because that's one of my trigger words if it's supposed to be indefinitely scalable It's hard to imagine how some might not make their own boo like yeah, absolutely. How are we gonna deal with that? I guess it's thunder chief also talking about the distinction between creation and destruction Very interesting and incumbency is this idea of a resource yet and that's actually really true All of this one of the things that we take for granted when we're looking at computational systems is You know when you're an actual living system you have to put food on the table You actually have to go out and find the energy to keep yourself running Whereas in computational systems in conventional manufactured computational systems You just plug the sucker into the wall and the program doesn't have to deal with it at all The entire system has paid the energy cost now That's becoming less and less true as things are more and more battery-powered and we're dealing with CPUs that will slow themselves down to save energy and turns the various regions off and spin down the disk and so forth and Gradually it becomes more like well depending on exactly what you're doing What am I willing to run that program because that would cause me to speed up the CPU? And I don't know who my battery could take it in the end. There is a link between the real resource is Once you have a computational system the real resource is energy of some kind to keep it running and When we say we're gonna do something like incumbency is it how long you've been in a site Is it how long the atom has been alive? What exactly does incumbency mean? That's what Thunderchief was getting at and yeah, these are all good questions and Somehow in the end I would like to try to fold it all back toward the literally physical actual energy When you when you think something was good you you plug it in Oh, and and the energy will spread and that will ultimately be the resource that we're gonna use Somehow as best we can if we can figure out how to starve things like fork bombs because they're not making the owner of the Hardware happy so the owner is not going to give more power Now the problem of course is how we can avoid having the awful fork bombs take the good guys down with it That's the whole game of civilization and it's exactly what's gonna be going on inside it indefinitely scale a computer Just like it happens in the real world I'm gonna circle back around to crypto and stuff in a second But I just wanted to get on to the sort of physicality of energy and incumbency and to thank everybody for having these great comments About the fork bombs on the discussion. All right, so let's talk about the T2 architecture for real I spent way too much time making this diagram, so we're gonna take a good look at it All right, so Let's just go through it all the way around starting with so here's one thing Bespoke physics, this is the idea that just like you talk about virtual machines Is a virtual machine a real machine or not a real machine? I mean to a computer scientist you say well, who cares because it acts like a real machine in the sense that it's got an Interface if you do this that happens if you do this that happens and so forth So who cares whether it's physical machine or some other machine that was implemented in Software which was implemented in software, which is implemented in physical machine. Who cares? Bespoke physics is the same idea when we're doing indefinitely scalable Computation we're making it out of tiles because we have to be able to make it as big as we possibly want We have to be able to add to it while it's running and in the end Physical space the fact that this tile is east of this tile and this tile is northwest of that tile is going to be reflected In the computational structures inside it and that's very different than the way we think about traditional computation But we can only think about traditional computation that way because we have random access memory Which puts everything right next to everything which of course is the security disaster that we're living with and of course is only Finitely scalable so what we are doing I suggest When we're writing our oolong programs when we're writing our splat programs we are creating a new set of laws of physics and The then the computations the atoms running around on the sites and the fork bombs and whatever else if we made fork bombs We get fork bombs. It's up to us all of that stuff is the you know that the chemistry and the biology and you know one day the psychology and Sociology and ecology of living computation built on these kinds of large-scale indefinitely scalable fabric Calling it the spoke physics is meant to do several things number one It's meant to suggest that the rules are fairly simple and finite and hopefully easy to explain The many of the rules of physics are extremely simple Whereas many of the rules defining how instruction set architecture works This is a comment that I made in a paper called bespoke physics for living computation That points out, you know the Intel Instruction set architecture Specification is like 5,000 pages 7,000 pages. It's crazy The laws of physics, you know f equals ma and all that kind of stuff by contrast much smaller, so When we write our oolong probe program when we write our splat program It's supposed to be like physics in the sense that ideally it Presents a very generalizable useful interface that most of the value that get out of it It's not really the specific value of oxygen versus nitrogen versus carbon But the fact that you can put them together in large numbers in so many different ways to do different things The chemistry is emergent and that's what we want as well The other thing that we want to use get out of the physics definition is the idea that it's rigid The laws of physics don't change and ideally in a tight in a tiled system the code The transition functions would be burned into ROM. They would be burned into custom logic and unchangeable Once we knew that if you had this table of elements, you could do all kinds of wonderful things The smart thing to do would be to get the programmability at the level of laws of physics out So the laws of physics can no longer change We're not anywhere near that So we put the laws of physics into flash memory that can be written and then we have to worry about well What if someone comes along and changes the laws of physics? The bespoke laws of physics out from underneath us and that's the security risk and the crypto risk and so forth So here's a picture of our tile a logical scheme the tile as a Linux host That runs the hardware to perform the communication to the neighbors the packets a packet protocol It also provides Crypto checking when you build a when you compile an MFZ file You need to have a handle the handle corresponds to a private key the private key signs the MFZ file We're going to do the same thing there so that T2 tiles out of the box They're only going to run MFZ files that have been signed by Somebody that is on the list of public keys that we install by hand when we configure the tile Is that absolutely safe? Of course not it has all of the typical problems of crypto and expired keys and Stolen private keys and so forth all of the same problems But we're only using it because we are not smart enough yet to make the laws of physics read only So we use traditional defense with all of its problems to make the updating the changing the laws of physics the Performing of magic when the laws of physics are violated existing laws change for crypto the the T2 tile is going to handle that it's also going to You know migrate MFC files from tile to tile automatically so that the we can inject a properly signed new MFZ file into one tile and it will gradually infect the entire Connected grid That will be a major milestone when we can actually see that happening on T2 hardware. That'll be great All right, but at one tile it doesn't really mean very much What we actually need is a whole grid of these things we want to go on and on and on This is the actual what I'm planning on doing this this may change But the idea is to do a hundred and thirty-three tiles plus a bunch more for spares and replacements That's why I say a hundred and fifty as a sort of target. Would it be cooler to do two hundred and sixty-six? Yeah, sure you bet It's not cheap. We have to figure out how to do it a hundred and thirty-three tiles why a hundred and thirty-three tiles because that's seven times nineteen why Seven times nineteen Because of this idea of a power zone you take one tile in the middle You put six tiles around it and you put another layer of tiles around that and that gives you 19 tiles which is kind of shaped like a brick. It's got a little pointy ends But in fact you can now take one of those 19 tile zones and you can tile it with more copies of itself Which is what's happening up here. So this is seven 19 tile zones these zones are not just administrative They actually matter because you see these green connectors between tiles are sharing data and also sharing power These beige interconnects which we use at the edge of a zone shared data, but do not share power So we can only support so much power getting shared through the Physical pieces of copper that we're connecting these guys together with and we have to engineer the system to handle it and 19 tiles ought to be pretty comfortable for the way. I've specified it here In fact are the actual pin values every one of these little Here's one every one of these This is an inter tile connector. That's two 14 pins 14 pins to 14 pins and a little handle to stick it on the top And this is the actual pin assignment. There's Each tile can ask the other one Can I have a lock meaning is it okay if I do an event near the edge and then I will tell you what the result was So don't you do an event near the edge? This one the corresponding grant is down here going in the other direction And they both have it so in fact they can race with each other both saying I want the lock and They can get into a case where they both think they got it And and they have to negotiate that there's code already written in the Linux kernel module to handle That we're racing as best as we can. We'll talk about that another day In addition to so there's two lines for lock request unlock grant going out two lines for lock request and grant coming back The other way plus two more lines in each direction for saying I have the next data bit of the next packet going from me to you Take it when you're ready. I am ready. Here's the value other guy says I am ready Here's the value and so on and the bidirectional things are interlocked So when I go up that means my value is ready But he can release his and then when he goes up his value is ready And I can update mine and they go back and forth So we're constantly sending bits in both directions On each of these six-way intertile connectors and there's some some pretty nifty stuff about that as well So that's four lines four lines is eight lines plus power and ground each of them gets three lines Although that's not quite true in the interzone connectors These three lines that connect power are broken so that power doesn't go through but otherwise ground us Okay, so we're gonna be able to use kind of a typical wall wart power supply That's sold by the gazillions these days to power LED strips Which is also kind of the reason that we're settling on 12 volt power We're gonna be able to plug one of these things into the middle of each power zone and then figure out whether We're gonna get enough power out of the mains I do imagine that if we actually really scaled this thing out We might actually end up having to you know run power zones off of car batteries or something on tables And only run it and sort of brief spurts until we can trickle charge everything back up But that's for a way another day So that's the idea so we have a grid the grid can in principle can consist of however many Power power zones that we can afford in this case. We're going for seven And each of them connects together and then the down to the tiles In addition to doing all of the actual hardware management We're gonna run a version of MFMS simulator on each tile except it's gonna be called MFM T2 And it's gonna know how to interface with the hot to hardware drivers the packet formats and so forth So that instead of simulating another tile there actually will be another tile and we'll talk to it But otherwise the code will run mostly the same. That's what we're hoping So well all of this the storage for all the individual sites This is the other point I wanted to make before we get start finishing up here is So each tile has an array a two-dimensional array of sites That's the important thing to keep in mind We think in terms of atoms which are instances of elements, but what's physical is a site and So here's a representation of a site. It's got room to store one atom It's got called the the active atom. This is the one that actually gets events, but there is more information there There's also a u32 a regular 32 bit integer that holds a color which determines what is painted on the screen And there's also another atom called the passive atom that can be read and written Just as additional storage by the active atom, but it never gets events You can make a copy of yourself. You could market for your favorite thing You could draw pheromone trails on the passive atoms The only restriction is you can only read and write the atom. That's directly underneath you You cannot look at the rest of the event windows Passive atoms you have to be there and then there are our sensors so that we can have actually touch sensors And the fact that there was a drag going by and so forth and perhaps in the future light sensors from the thing being with it wet-ranged by and so forth all of that is expressed in terms of these Transition rules that say if you see this event window replace it with this event window that determines the chemistry the biology And everything else of larger-scale systems We've got Ulam code which we can use to write these transitions We could write splat code which compiles to Ulam code to write other transitions Important point is all of that is laws of physics That cannot change again modulo traditional security failures Which can certainly happen in our research tiles that have rewritable laws of physics But all of that is at a very different level of stiffness and rigidity than the atoms the instances of Dreg and seed and so forth that are running around just as concept as contents of The active site the active atom in sites. Okay, so there's the explicit distinction that traditional computing tries to avoid By making everything universal numbers is just programs program is just numbers In the traditional von Neumann machine approach. We're pulling it apart in two very separate stages You write laws of physics. We protect that as best we can with what we'd like to protect it with you know Inability to do anything else. We actually got to protect it with crypto and so forth and Then the program that is running on the combination the grid full of sites now. Here's more details Each of the atoms this is called the p3 atom. We did have P1 atoms and P2 atoms P2 didn't really got out too much, but this is the p3 atom each atom is 96 bits long And once you start programming with it then you start thinking wow how the heck to Trent small do that stuff in his Procedural generation of the city with only 96 bits to work with but wait It's worse than that because of those 96 bits 16 bits represent the type of the atom when we say element seed here in some splat code or element drag down here in some oolong code that ends up Corresponding to a type number of which there are 65,000 16 bits worth And that's how we get from reading the atom to the associated transition rule We have a table that maps from atomic type to a pointer to the corresponding function to do the job That's how it works Now what would happen if one of these atomic type bits got corrupted, you know x-ray cosmic ray something like that comes in The problem with the atomic type is it's a very high leverage set of bits Because there's nothing that the oolong programmer or the splat programmer could do to defend against a flaw a failure of the Atomic type so we have nine bits that are dedicated for error correcting code This is not error correcting code for the entire 96 bits This is nine bits just for the atomic type that leaves 71 bits left over that we can actually program with It takes some getting used to it absolutely does but from there we go up we put 41 We put sites together each tile has a rectangular array They tile together and we have events that happen on them and so on I'm imagining I'm saying second first quarter 2019 we're actually going to have these tiles in hand I really want that to be true exactly how many sites we put on each tile remains to be seen 64 by 32 2,000 sites per tile who knows it might work that might be too slow this whole thing is going to be super Super super slow if you think your simulator is running too slow because it's doing only 20 air or something like that 20 average event rate sites per set average events per site per second I am going to be happy if a t2 grid does one air one event per site per second on average Across an arbitrarily large grid As far as I'm concerned one air is the line in the sand. That's what we will established and then we'll say hey You know how to design hardware better than this You know how to do optimize stuff better than this beat it if we can get to air if we can get five air That's great One air will do what we needed to do which is say this is now possible You can create an indefinitely scalable computer from here the horizon That does one event per site per second for as many sites as you want. All right So that's it The next episode will be out one week from today Happy Friendsgiving day if you're in the United States and hope you have a good weekend against no matter where you are Thanks so much for watching