 The T2 tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday Updates. Our top stories this week, best effort, the science fiction novel is supposed to be working on, it's supposed to be doing 2,000 words a week since November ended, I didn't come close to that. I haven't given up, I did some cleanup in it, it's not clear exactly how I get my head back and forth between the nerd stuff and the science fiction stuff this past week. There's more than nerd stuff, don't let me off the hook about this. A couple of weeks ago I talked about an essay by Avery Pennerham about absolute scale crups absolutely and I mentioned at the end that he was involved in a new company called Tailscale and I was guessing that they were doing some kind of crypto overlay network while they've come out of stealth or maybe they've run out of stealth for a while, I'm not sure. But I got in touch, signed up to try out their stuff and I ended up having a long back and forth with Avery Pennerham and so download a little dev package and it's actually surprisingly small which is kind of refreshing and you try to log in, I tried to log in, I got stuck in some kind of loop, I reported it and this was just back and forth. I didn't even expect to be talking to a human when I typed in my email address into their web form and then bam, not only talking to a human, I'm talking to a dog human. Gave me a quick workaround to try, that appeared to work and then I was authorized and so I'm going to talk about it another time because I haven't got enough time this week. But it is, it's a crypto overlay network that you can basically enroll whatever devices you want, you get your own little private, virtual private network, kind of, but it's a mesh network and it's got a bunch of nice features and, you know, sorry and so forth and it was nice, I had a little interaction with them. One of the things I really like about it is this fundamental idea that when you have a log of a connection being made from one machine to another, there's inherently two ends to that connection. They say, you know, well, we make logs on both sides, the thing that's doing the connecting, the thing that's being connected to and so forth and that means you can correlate against them and this is just a simple, natural, lovely example of the thickness of the relationship stuff that I talk about as a way to do robustness and build a relationship is by having both sides know that each connection happened and you can correlate them later. Or to be thought about it about that again, not going to do it today. All right, so last week we had picked up this new, from August 3rd, 2019, Debbie in 9.9, that we were trying to upgrade our Linux, we're still trying to upgrade our Linux too. It's fun to burn the thing in and push the button and see it actually work and, you know, it did work in the sense of boot, but it didn't work in the sense of actually do anything we want, but it's actually being, you know, 4.14 dot whatever instead of 4.4, which is what it used to be, installing a whole bunch of packages and eventually getting as far as trying to build my Linux kernel modules. This is where we were last week, getting a whole bunch of errors. And so this week I'm just knocking through it, trying to figure out what each sort of group of errors is about. Clean them up as best I can. This, you know, there's RP message header is this basic thing, our RP message is remote proc message that the main Linux computer on the T2 tile uses to talk to the proves that are doing the communications, the six-way communications. And you know, we can't find RP message header. That's really weird. Class adders got upgraded to class groups. I mentioned this last week, this was an easier one. I found the diff where you say, instead of doing it this way, you do it that way and you change the name so that you, you know, it's just a little bit more structured than it used to be. And once I found that out, that wasn't so bad. I made those changes. Task list. Another thing that suddenly has vanished and I needed task list because I wanted to check to see if there was anything on the task list. Check if it was empty. Well, okay, you find out there's different method call wait queue active that you call instead and that does the list empty call for you. And instead of using task list, it task list, it uses head. All right, I figured that one out. But this incomplete type struct RP message header, that was a real problem. And, you know, that caused, well, in addition, other things had changed about RP message as well, so that my functions that were supposed to be plugged into the RP message framework were no longer matching up. The key didn't fit the lock. And so I started searching, you know, where did RP message header go? I mean, it's a definition of this little struct that, you know, it's kind of pretty fundamental to dealing with all of this stuff. I looked here, I grep through the thing, you know, Linux RP message dot H, so it's got to be there. No, not. There's a bunch of other stuff there. Not that. Eventually I find it. Here it is, a struct RP message header, blah, blah, blah, all the stuff in it that you want and so forth, but it's in a C file. And that means for programmers that you're not supposed to include that in another file. If a file is meant to be used by other files, you make it a dot H for a header file. Dot C is supposed to be terminal. Supposed to be the leaf that no one else uses it. So how am I supposed to get at this thing if it's down in a dot C file? I really don't get it. It seems to me like I'm not supposed to be using it, but I think I really do clearly need it. So in the end, I actually copied and pasted the struct into my own file, RP message T2 local dot H. That can't be the right thing to do, but I don't know what else to do. So I did it. The code out there, the ZQuge is one of these guys that did this BeagleScope is a big application for the BeagleBone. Does a logic analyzer, essentially like an oscilloscope, a great thing, lots of technique in it, and lots of good stuff to steal from. It still uses size of struct RP message header, which is the same thing I wanted to do. So all right, so that got a bunch of those fixed up a bunch of them, but just in a terrible way of copying and pasting. In addition, the RPM tricend, so in the code I wrote, the first argument to RP message tricend was an RP message channel, which makes perfect sense. And I was using version 4.4.54 of Linux, but in fact, when we move on to 4.14.108, now it no longer takes a RP message channel. It takes an RP message endpoint. Okay, you know, whatever it is. These source code here is coming from a website called Bootlin, which has, as far as I can tell, every version of Linux all cross index. So you can just click around back and forth around. But it's a huge, great, wonderful resource. Eventually, I found the commit message that was saying why they changed it. And you know, it was inconvenient, you know, unusual case that was not my use case. If you had secondary endpoints, which I don't, then it was hard to do blah, so it was better to do it this way, which is fine. But now I needed to know how am I supposed to change this to take this new thing. I don't know where to go to get an endpoint. I never had to worry about endpoints before. And so I searched high and low, right, so here's the patch. Get rid of RP message channel, put in RP message endpoint, and so forth, make little changes within it. But what I needed was not the code to do the tricend, but the code to call tricend to see how I'm supposed to set it all up. And I searched all over the place, you know, different places using it. They were still talking, you know, RP message channel, even in 2018. Even you won't be able to see this, but Colonel Doc documentation, that looks pretty official. Nope, it's still talking RP message channel. So, you know, it's fairly new. It's fairly slow propagating through, and you just have to be following it step by step. You got to stay an expert. You got to be surfing the wave of the change in the software if you're going to be able to stay with it with any kind of efficiency. And I'm not surfing the wave, so I'm paddling and paddling and paddling, trying to catch on how am I supposed to ride this thing. Eventually I find out it's not in the documentation that appears to be rotted, but in samples, there's RP message, RP message client sample. And indeed, that told me what I needed to do. Had a pattern match to get rid of the RP message channel and get the RP message endpoint, and I was able to then get it going. All right, the final thing was, oh yeah, my callback had previously returned void, had no value at all, and it wasn't compiling. It took me the longest time to see it. It was supposed to return an int, a number, saying how things went. I got that, and then I could actually start building, well, the Linux kernel module built, so I actually decided to try to see if I could build MFM, which takes forever. I don't know if anybody actually plays ex-meal on the planet, except for me. But this has never happened in all the years I've been playing the thing. I got absolutely every point it's possible to get in one hand. All the coupereyes, all the values, everything, bonuses, and so forth. So I had to record that. That was while I was waiting for one of these things to finish during the day. And MFM built successfully, so that's progress. But there's many other issues. So one of the issues is there's running out of disk space. There's only four gigabytes on the thing. And as you upgrade the packages and then I install MFM and so forth, the disk space just starts, yeah, 52 megabytes left, 99% used. That's pretty much like right out of the box. And it's like, how did that happen? I started investigating around and, you know, the slash user directory where a ton of stuff is had 2.2 gigabytes of stuff in it, which is quite a bit. And user share had almost a gigabyte, 955 megabytes all by itself. And user share TI, Texas Instruments had 345 megabytes, which didn't seem to me like it should really need it. It had the bunch of stuff that wasn't there before CGT-CX, OpenCL, TIDL. This is all the Beelabone AI stuff for deep learning, Texas Instruments deep learning and so forth. So I actually extended my scripts that do the conditioning and stuff to nuke a bunch of stuff out of the middle of that. And sure enough, when I went to look in the Beelabone mailing list group, just today, or well, yesterday, Monday, December 9th, people were saying, hey, I was using the August 3rd IoT image and I was ending up with no space. That was exactly my issue. And the response from Robert C. Nelson, the guy that does all this stuff is, well, you know, I fixed that a week later, but I can't update the thing. So go get this other place. And you know, this is the long and short. This is the joys of software. The web page says, you know, recommended images, latest recommended images, and you use it and it's a trap. OK, all right. You know, you get what you pay for. It's open source and so forth. But oh, the days, the hours, the time lost. So now, in fact, it's not 9.9 anymore. It's 9-11 and so I got it. I did the whole thing over again with that. And now also with my own deleting some of that extra stuff, there really wasn't that much space left over with the supposedly fixed one. So I don't know what the story was, but I had already engineered my own thing to go back and tear out the deep learning stuff and all that things that I certainly don't need for the T2 tile. And we're back at the point of going forward. So the fact that these ITCs, that's the intertile connectors, trying to allocate the pins to do it and it's not working yet, that's because we have not yet addressed the device tree changes where we describe to Linux how everything is all laid out. So it doesn't know. So that stuff is failing. So that's not surprising, but it's the next stop. And the thing that would describe it, the bone green T212DTB device tree. I don't know what the B stands for, is not compiling because that needs to be worked on. So that's the frontier where we are. All of this process made me think about something that I worked on a long time ago, that this kind of happening again. And I wanted to spend the last minute or two talking about that. This is a picture, well, this is a signed picture from a bunch of people that worked on of the CCR-TK universe. That this picture is from mid-90s. This is like 23 years old. This software and all of these little these little blobs that are sticking out the side of this rectangle are networked doorways to other people's worlds. Then they're all sticking in on this room and they're chatting and we were just taking a group picture and they were all, you know, mangling slogans of mine, you know, use a blemish, be a blemish and so forth. This was a mighty complicated piece of software in some ways, much in the spirit of the T2 tile, except the T2 tile takes the whole thing down to hardware instead of being on TCP on the internet and uses it as an architecture for programming rather than directly as a user interface for a distributed multiplayer environment, second life-ish kind of thing. So yeah, so this snapshot was from 1996. So 23 plus years ago, it has Chad. It has a graphical view. It's got some programming systems and all kinds of stuff that it had. And this thing had an extremely complex initialization sequence, the stuff that you had to go through. I had zillions of bugs figuring out how to get everything all started up because things would come together and you couldn't use services until they were all done. So I ended up creating this whole notion of epochs that divided up. The first epoch was the species stuff. Are you the CCRTK client that has graphics? Are you the CCRT that's just command line and so forth? You went from there to the species stuff to the individual stuff. Start, load database, load keys, verify, gain entropy. That's for the random number generator. There's a million of these individual different stages and the same thing all the way through a life and finally death and unexpected death and so forth. This path of having these epochs that the whole thing moves through, the reason they all have names here is so that the other code can hook onto these things kind of like this system D thing that's happening with Linux is trying to do as well. In my case, for what I did for this past week for the T2 tile is I created the image construction stages. You know, if you're going to build a brand new image, you get you download the thing, that's the pristine source selection. You make an SD card on the host. You do and so forth and you work it through. And it was finally when I actually settled down and wrote all this stuff that I actually was starting to make sense out of the process and be able to say, no, you can't do the T2 install until later because we have to reboot to get the updated kernel version, blah, blah, blah. This is what a whole stack looks like. This is what booting, setting up, constructing a whole computational stack is about. And there's this interesting thing, right, that. There's two routes to doing this. What I'm doing now is the de novo construction, like from a seed. You take the original ingredients and let it go. But once you have it, it's going to be on a card. It's going to get much of it is to get distributed by the common data manager. So there's the living route where it reproduces that I can't use right now because I'm trying to do a fresh start. There is no running T2 tile version on this current version of Linux. So the the de novo versus the checkpoint or the reproduction version. Those are both two routes. There's something kind of deep to that. And I think it happens in any software or hardware software system. It's just it's not necessarily quite so obvious that there's this route and that route anyway. OK, I've gone over my time and long and short of it is you take the pristine image, you put it into the T2, you get in route and you type I see as boot one Linux packages seed, and it does all of this stuff. And I've run long, so I will stop now. Let's really hope that next week we'll get the device tree sorted out. And who knows, maybe we'll get the display to light up again in the new version of Linux. I hope that wasn't too nerdy. Thanks for being here. I hope to see you next week.