 Computers keep changing the world, but their power and safety is limited by their rigid design. The T2tile project works for bigger and safer computing using living systems principles. Follow our progress here on T Tuesday Updates. I'm Dave Ackley. This is the third T Tuesday Update. Let's get into it. So you just saw the video, the title video, version one for T Tuesday Updates. What did you think? I spent, you know, kind of a lot of time on it. I always feel guilty about that because it feels to me if I'm not doing like software for robust first indefinite scalability, or if I'm not like soldering hardware for robust first indefinite scalability, then I'm sort of being wasting time not being on mission. But really, I mean, the whole point of these updates, the whole point of writing papers and all this stuff is that getting the ideas out there, figuring out good ways to express the ideas and making it harder for people to not get it is part of the mission because ultimately we need to get more people involved in this. We need people to bring their intuitions and knowledge that they brought from traditional computing to figure out how to make that stuff work and reinvent in indefinite scalable, robust first systems. So we'll see. The video is rough and unpolished. It's 13 seconds. I was hoping for originally 10 or less. But OK, we'll take it for now. The main truly nerdy event of the time is SPLAT is now up on GitHub and is usable for a suitable definition of that. And we'll do a demo here. That'll be the main thing besides questions. The goal for next week is KaKaiCAD Refresh, which is to get the software for the hardware working again. Long time viewers will notice that this was also a goal for this past week in which I failed. But I'll talk about that a little bit and then I want to save as much time. Given we're admitting sort of a 15 to 20 minute window overall for these updates to do as many questions as I can because I really love to get questions. But of course, I talk too much about each one. All right. So the goals for SPLAT for this week was to work with Oolong4 and it would work with Brickwall Geometry and actually get the GitHub repo populated. Now, the way it currently stands as of right now is I changed the GitHub default branch to be developed. So if you get cloned now, you will end up sitting in develop. If you got it from before, it doesn't matter. You can get checkout to develop obviously and then get pull, get whatever it is and so on. But the underlying principle is now, you know, on the one hand, I really, I think Git is a remarkable piece of software and it has a lot of distributed spirit that very good living systems. You know, every cell has a copy of the complete DNA. Wow, that seems really redundant. Well, hey, what does a Git repo do? But when it comes to actually the craft of using GitHub, I am a newbie. I don't know a Git rebase from a squash from a zucchini. So I try to as simple as I can and I apologize to anybody who actually does know how to use Git better. I could use some instructions in that. But the basic principle for Oolong Splat and MFM is that the only thing that ever goes to master is stuff that's going to be the sources of the Ubuntu packages that get produced and everything else pretty much happens on develop or even some wackier branch. So if one wants to play living in dangerously, you're pretty much going to have to be on the develop branch. So that's what Splat has now joined the party as far as that goes. All right, here's the Splat GitHub page and it's got a brand new little quick start that I have actually done the first several steps. I cloned the repos. I did the make clean. This is important to notice. On the Oolong side, there's a bunch of intricacies that actually enter the build process on Oolong actually interlocks with the build process on MFM because there's libraries that MFM has to load that get generated by Oolong. So the safest thing to do is after you build MFM is to go to Oolong and do make-f rebuild.make which means you know use a special build file rebuild.make which basically burns everything down to the ground starts over rebuilds all the demos. Everything. This is the you know take off, nuke them for more, but it's the only way to be sure option. And it's what I always have to do and it does take quite a while. But so that's now in our little cooking show today. This has all been done already. So we look in. We have we have demos. Demo's are now included. Let's try Facebook. I mean fork bomb every time. Now, OK, in this case, it instantly worked. Let's get out of it and do a clean so that we can actually see how long it takes. That worked great. OK, well, I can I can to complain at this game. Actually, why don't we make this thing? It's probably sitting on my over a little bit. Well, why don't we take a little look at FB just to see what it is. All right, so FB stands for fork bomb. Its color is red or GB symmetries. It means that all the rules that are described below can be applied in any north southeast any 90 degree rotation or the two mirror flips and they all apply. We have two rules. How do you tell it's a rule? It's a rule because it begins with spaces and it's a rule because it's delimited by sections or blank lines. So this is one rule. This is another rule. Whoops. This here is another rule. What is this rule says at sign on the left means me the center of the event. That's the FB Adam. This is just next to it next to it on its right. Well, in the default symmetry next to it onto its right, but it onto its east. But it might be north, south, east or west depending on what symmetry is picked. Underscore on the left hand side of the rule says it has to be empty. And so if we have a fork bomb with an empty north, south, east or west, we can replace it with us and another copy of ourselves. That's on the right hand side of the rule means a copy of whoever is doing the event. If on the other hand, the transformation that we pick now it's important to notice when splat is having an event. It doesn't search to try all possible combinations and say, is there an empty square that would allow me to proceed? That's again, that's in the more the traditional computing frame of mind. What splat actually does is it picks a random transformation, a random symmetry rotation and flip and just checks to see. Is there an empty guy next to it? Yes or no. So this rule could totally fail even if there is some empty spots next to the guy just because the random pick didn't find it. If a rule fails and there are more rules, we just move on to the next one. This rule is called the hold rule. It means if you have a me, you can replace it with a me. If you do not have a hold rule at the end of your splat program and no other rule matches, your guy dies. If there's no assertive thing to say that he should say, a message will show up in the log file and that guy is gone. So you often have your splat programs ending with the hold rule as the last ditch. Or in a way this is kind of ugly and really you would hope that your previous set of rules would cover everything that needs to be covered. And if none of the rules match, the guy should go away. There's some kind of inconsistency, something you're not prepared for, safest thing to do like that. Now if we had changed this to this kind of rule, dot means anything. So this rule, this is a really mean fork bomb that will actually overwrite other stuff including other fork bombs. This guy on the other hand is a kind one that just fills empty space. Now I've made edits to the file. Let's see. Okay, there we go. So now we're actually, we run, what do we do with splat programs? We run splatter, that's the splat translator on them, which rewrites them into ULAM. And then in this case the make file runs them by default. So here we are. We have our brick wall tiles, two by three. These are H tiles. The default tiles in the MFMS are D tiles, which are sort of medium sized, small square tiles. There's a few, I don't know, IJK, H something, a few up at the high end of the alphabet that are actually rectangular tiles. The T2 tile itself is going to be rectangular, so it'll look a little bit more like this. And we can plop down a fork bomb and it'll take over the world. Now we might be able to defend ourselves there. Okay, because it's a nice, a kind fork bomb it doesn't blow out the walls that were established in this particular case. So you get it. If on the other hand we had changed this guy to being a match anything, then it'll have to rebuild. But now if we try to make a wall of SPs, and what SPs are... Okay, here we go. Here's our defensive line that'll keep us safe. And here's some... And now the fork bomb... No, we are not safe. This is the fork bomb apocalypse. And you know, now it looks like nothing's happening, but of course in fact these fork bomb rules are overriding each other furiously because that's what they do. All right, so that's it. There are... Swap line is a fun demo. There's C211, that's the membrane that was presented in the thing. You can go in there, you can type make, you can try it out. And we'll talk about that again in a later thing. Okay, great. And now we're out of time. No, that's all right. We still have five to ten minutes to go. So, there's our demo. Yeah, all right, so one of the goals last week was to get Kaikai going, which is the schematic capture and layout system that I used to design the thing, which in fact in the video, the T2 tile that comes up at the end, that's a photograph I just took this weekend to make the video thing. That's kind of what they actually look like. Don't get very good look at them, but we'll see them again later. Didn't get to it, screwed around too much with the title videos and so forth. So next week, this week, we're serious about it. Of course, you know, as being a teacher for all these years, you know, one of the big points is, you know, you got to be the sort of hard ass to be an external stimulus to keep people focused. I mean, you know, a lot of times people will, if they're actually self motivated, they'll go out and do great stuff. But, you know, a ton more people, they are reasonably motivated, but they have 16 other credits that they're also taking classes for. And so one needs to keep even in the arms race to get anything done. So merely posting the same thing again is not good enough. So this week's goal is refresh my Kaikai brain, meaning specifically go all the way through the workflow to produce new Gerber files, what they're called, that you can submit to a PCB fabrication apps. I don't actually have to submit it yet, but I have to come up with new Gerbers and I have to show my work so that we can actually, you know, this is one of the weird things. These maker videos, like Wintergatan Wednesdays and so forth, and all of them, Colin and Peter Schupel, you know, these guys are constantly drilling and tapping and thing and glue and barrier shooting stuff up. And I'm just sitting here blabbing, talking away and say, well, how is this an actual maker thing? But how do you do a maker thing when it's all just software? Let's see what we can come up with. I mean, there's plenty of, you know, screen grabs and whatnot. We'll see what we can come up with for next week. Okay, that's it. Let's take questions. We still have maybe six or eight minutes. Let's do it. First thing I wanted to start with was Sam Gentel asked, have you considered asking other people to explain the project back to you? And that is such a great question. And I answered it in the YouTube comments because, yeah. And I, again, this is sort of the reason I solicit questions in general is to, I would love to hear what people think, what it means to them. And as much as possible, if people are reading the YouTube comments or also on Twitter, and we'll try to get as many social media outlets going with this stuff as we can over time, that hopefully more and more people besides me will be able to answer the easy questions. So, and that would help a lot to help spread the word. So, yes, I love to hear how people think that they're thinking, thinking I'm saying, and then we can all jump in and as kindly as possible say, well, yes, perhaps, but that's not quite the way with the idea is supposed to go. All right. So that's number one. Void QK. This is from before last update. How are you going to do human input output for the entire computer? I get that each child has a mini screen, but what about the entire system of Java, Deer area? Okay. I like this question. I mean, it's a natural enough question is, you know, where, where's the input and output for this thing? And, you know, you're in good company. Bob was Nooski, I think, who is or at least was at the time, sort of the head of supercomputing development architecture at Intel, asked a similar question, you know, because when they're doing supercomputing jobs, they've got, you know, tremendous amounts of data and moving the data in and out of the system is a major problem. It's not just something that you can deal with later, you have to engineer forward up front. So he asked essentially the same question. If you have one of these, you know, from here to the horizon computers, how are you going to do IO? And the deep answer, the fundamental answer is if you have a 1000 megapixel image or whatever it is, it's already going to be in there. It's going to be part of this whole big system. And it's really just going to be a matter of saying, well, you know, it's here, how can we arrange to get the data that we need and the computation that we need that are all within this huge distributed, robust scale will computing system together. And it'll have all the same issues of anything else. But it's not so much that we want to think in terms of, you know, here's a computer that's sort of finite and boxing, we want to go in and let it come out. This thing is going to be so big. Much of what's going on, the data and the program are just going to be a different places inside the overall system. Okay, thanks for the question. All right, so here's a couple of related ones. I mode, why does your system have to be anything other than one D rather than over complicate things by building your giant string and so forth. And on the other hand, we have not exactly Jake Casabon, not sure how to pronounce it, goes the other direction. Instead of tiling the plane with hexagons, why not tile in 3D using tetrahedrons, why be married to 2D planes. So why isn't the 3D is the sort of number one question up on the family feud indefinite scalability board. Why does it have to be anything other than one D is a sort of a little bit more of a sophisticated, you know, computer science internal thing. And there are actually people have posted answers on the YouTube comments that really get at it. But I mean, let's think about it. Suppose we took, we let it be one D. I mean, putting aside the valence applied to over complicating. It's like, you know, my ideas is simple. Everybody else's ideas over complicated. Suppose we treat it as one dimensional. Okay, how many how long a string can we put in one tile? Who knows 1000 long a million long, whatever it is. Okay, now we have to put down another tile because each tile is fine. That's a rule. And so eventually we're going to have them stretching out in space. And what are we going to do? We're just going to have them stretching out in one D, a line going from here to the horizon. We can do that if we want. But don't you think we're going to be tempted to say, well, why don't we bend the line back around? Why don't we snake it back and forth? We can get much more line in the same area. Well, but now you just tied your hands because now in fact you have tiles that are close to each other. But in terms of one D, you have to go all the way down there and come back and come all the way down to get back here. So the point is the dimensionality of physical space is what governs the dimensionality of the machine. Could you make a one D machine? Yes. Is it really simpler? No, you just push the problems off onto scaling up. You still eat the cost of having to do traverse space. But yeah, you traverse it in a really stupid way because you don't acknowledge the fact that the world is 2D if not 3D. Jay Casabon on the other hand. Why not go three dimensional? Three dimensional is really cool. The only thing I don't want to do right now. I mean, I have several answers to this. One answer is, you know, we need to crawl before we fly. And there's so much that you can do with 2D that we need to understand how to robustly compute in 2D. And the other thing, as was discussed in some of the comments as well, is I want to keep the third dimension for IO, for manufacture, and for repair. So now that said, that doesn't necessarily mean it has to be just a one infinitely thin plane of atoms. In fact, a sort of hybrid architecture, which I call 2.1D, I think in the paper that was written in the year 2039, if anybody has found that yet, we scale in X and Y. And we can go as far as we can afford there. But in Z, in the third dimension, you can have a finite extent. So that's fine. And we could in fact use the T2 tiles and they have plenty of memory and it's just going to be a matter of how slow we're willing to make them go. We could have sort of, you know, like eight layers in Z and then scalable in X and Y or 16, whatever you wish. The point is, as long as one dimension is finite and two dimensions are scalable, then that's okay. We can still have manufacturing. We can still have a place to inject energy, a place to drain heat. All right, maybe we can do one more bunch. Why create ULAM instead of a set of message protocols? Ask Tim Swast. Oh, whoops, no, we already saw him. Starchy pancakes. Ask, is there eventually going to be a plan to allow for arbitrary topologies in version TN? Not the T2 tile, but the T3, the T4 tile. And the answer to both of these, and then we'll just call it a day, is, you know, it's the difference between creating an architecture for indefinite scalability and writing sort of a single program. And, you know, message protocols is all about communication and it's leaving the computation to be defined later. You can go the other way. You can define the computation and leave the communication to be defined later. But an architecture has to do both. And the Von Neum machine, it takes a position on communication and computation by the Von Neum and bottleneck. All the memory has to come and go through it. So creating a set of message protocols would not be enough. And in fact, creating ULAM is not enough either. There's the implicit engine underneath, given by the mobile feast machine that determines the actual semantics of ULAM programs. So we just need more because that's the nature of doing architecture stuff. Can a single tile host multiple programs? We'll have to circle it back to that another time. But the same thing. So you say, you know, 2D grid technology is so limited, why can't we have hypercube technology? Why can't we have factory technology? That kind of thing. And the answer to that is that they're not indefinitely scalable. If you assume that a communication link is supposed to take a bounded amount of time, then light can only travel. If you want a communication link of one second, well then that link can be no longer than one light second maximum, or else you can't do it. And how many guys can you reach in one light second? Well, you can reach a lot, but you can't reach an indefinitely scalable number of them and so on. So again, a lot of what we learn in regular computer science, including stuff in parallel systems and computation and so forth, is still going to be relevant in the mobile feast in indefinitely scalable architectures, but it's not going to be part of the architecture itself. The architecture itself has to be indefinitely scalable in physical three space. That's its number one thing. Hypercube's complete graphs not indefinitely scalable. Could you say I'm going to implement a finite hypercube inside as a programming matter rather than as an architectural matter? Sure, you can do that. It could still be fine. But now you accept that you're in the land of writing a finite computation rather than defining the architecture that is going to constrain all computations that ever run on the machine. Okay, this is 22 minutes. We need to stop. Thanks for the questions. I'm sorry I didn't get to all of them. Poor Andrew Brown's question has been waiting for days for weeks. Next episode will be out a week from now. We'll have actual hardware stuff and somehow I'll show my work. Thanks so much for watching.