 We had the Lenaro Connect here in San Francisco, and who are you? I was hoping you could tell me. You're Paul McKinney. Oh, okay. McKinney from IBM. You're right. I am. Okay. I'm glad. Thank you for clearing that up for me. And we did a video at the Lenaro Connect a few years ago. Yeah, like five? Five years ago. Okay. That was the last time you had the Lenaro Connect? Hong Kong. And so what have you done since then? Mostly usual stuff. I made up an RCU, did a little bit of chasing down quantum computing, going back and forth on trying to make... I mean, the biggest challenge for me, actually, the thing I realized a few years ago, is that Linux runs on billions of machines. That's not a big... I mean, it's 1.4 billion androids as of what, three years ago? But I was talking to Dave Rusling, and he was saying he thought the number was about 20 billion. 20 billion Linux in ARM machines? 20 billion Linux machines, maybe most of them are ARM, I don't know, but he just said... Yeah. I'm going to guess ARM was played heavily in that estimate. So how many is... How much of those 20 billion devices have you or so? All of them? All of them? Core, RCU? It's in every one of them. Okay. So let's talk about this here a little bit. Let's suppose that RCU has a bug in it that happens on a given machine, on average, once every million years, okay? That's happening like 30, 40 times a day across the installed base. Now I've been doing validation of concurrent software for more than 25 years. I'd like to think I'm pretty good at it, but I'm here to tell you, I mean, I've done a lot of stuff, I know a lot of different ways to cheat, dirty tricks, but 20 billion is a really big number. Thing is, you've heard of Murphy's Law, right? Of course you have. Yeah. Yeah. Whatever can happen will, right? Now if you have an installed base of 6,000 machines, like I did when I worked for Sequel in the 1990s, Murphy's actually a pretty nice guy. Everything that can happen will, eventually, maybe in geologic time. But when you have 20 billion machines, Murphy's a real jerk. Everything that can happen will and it happens really fast. That weapons right now. Yeah, pretty much. All the time. Yeah. What's happening? Well, we don't really know, right? I mean, there's some projects to try to gather oopsies and things like that, but if you're light bulb panics, how would you know? The rumor I hear, this may be thud from a certain competitor of harm, okay? I don't know, right? But the rumor I heard was they just don't validate the SOCs, some of the SOCs, because it takes too long and it costs money. And the software just resets the thing and something bad happens. Okay, so how would you know? How would you know? Now I could take that, I mean, you've got a smartphone, right? An Android probably? Yeah, of course. Yeah, okay. An Android is probably working a million years from now. Of course, it has to work, right? All right, this guy's an optimist. This guy's an optimist. I love that. But the thing is, even if you weren't that much of an optimist, the fact is that there's certain places in the world, a few in Europe and maybe here in the United States the same, I haven't checked out, where if you have a device, okay, some device is supposed to get some purpose, some job done. It's something with mechanics in it and maybe electrical and it's probably got a computer in it. I mean, what device doesn't have a computer these days? And my car is a rolling, the final car I've got, I mean, it's got two touch screens and I'm having a hard time because it's like, okay, how do I tell this, what the air conditioner is doing? Oh, okay, it's just a round knob, you know, you're going, and you look up, oh, it's up on the screen, right? So the thing is though that some of these devices, they have regulatory controls on them. So they have testing you have to do. So if you run it for some number of years, and depending on what it is, it might be as few as three years, it might be as many as 20, but if it does what it's supposed to for some period of time, safety critical. So there are, I haven't, I have no public indication of this, however I've talked to people who claim to have installed Linux kernel for applications that put the public at risk. So this bit about hiding behind software unreliability just isn't, I mean, I don't know about you, but I'd feel really bad if my software killed somebody, right? Can you make software that has some kind of AI that validates itself constantly or something? You could. On the other hand, one of my professors back in the day taught me functional programming it was. He's now at DARPA. He's a second line manager, and part of his remit is verification, you know, software verification, formal verification, and he got off a bunch of people a year and a half ago and said, okay, one of our priorities is doing formal verification of deep learning, machine learning software. And most of the academics of the crowd would, like that, but again, what you've done is you said, okay, we're using machine learning stuff, but that's just a magic, right? Because now how do I know that the machine learning stuff is operating correctly? If there's some condition where it should reboot the machine and it fails to, that's a failure that might put the public at risk. So, you know, in any case, there actually are some things that might be helping here. There's what happened is that some years ago I was in a memory ordering conference. It was a workshop, and there were a bunch of formal verification people there. And so I was getting up and talking to them, and they were giving a hard time about formal verification. I said, yeah, you know, I've used formal verification since early 1990s. There's something called promulant spin. You basically write a program, and it's this little language, kind of like Pascal and C, kind of sort of. But instead of executing it step by step, it does a full state-based search. And so it just goes, and anything that a program could possibly do, it finds it. And you can put assertions in there, or you can make little time-based logic expressions, essentially saying, if this happens, this has to happen sooner or later, or if this has happened, this thing can't happen, or things like that. And it'll go, and it'll verify it as long as your program is small enough. And that's been really helpful, but it's only good for design. If the thing is, the Linux kernel comes out every two or three months. So if I'm going to use promulant, I have to hand convert from Linux kernel C to this promulant language like five or six times a year. I'm a human being, I'm going to make mistakes, right? So I make a change. How do I change my promulant model to match? Did I do it right? Did I really catch something? I said, oh, this change shouldn't affect the problem. Well, should it have? Was there a bug in there already that I failed to notice? So what you really need is you need something that will actually read the C code, or better yet, the binary produced, because then if you read the binary produce, you can ignore compiler bugs. Because you just look what the compiler produced, who cares what the compiler bugger not, if what it produces is correct, then no big deal, right? Anyway, what you're describing here is the glitch. The famous glitch that people talk about in the news sometimes. There's been a computer glitch. Yeah, somebody made a mistake. And people, so error is human. It's been around for a long time. You were mentioning just before that you worked on a quantum computing. What are you doing with that? Are you trying to make it work? Well, it's one of these things that sometimes your manager gives you an assignment and you don't want to ask too many questions. And the assignment was, hey, Paul, go find out about this quantum computing stuff. Go find out about it. Yeah, go tell me what you know. Doesn't IBM make them? It does. It's making quantum computers. Yeah, but I'm in the Linux Technology Center, and as IBM Research making them, and my manager's in the Linux Technology Center as well. So you go and find the chips and connect them. You don't have to. You don't have to. I mean, if you Google for IBM Quantum Experience, you'll be at a tutorial. If you run the tutorial, you'll get points. And with three points, you get five points, I think back in a while ago when I did it, you can spend the points to actually run programs on the real quantum hardware. Anybody can do this. You could make an account, you could go through this stuff, and you can run. And you can simulate for free. OK, so they have quantum simulators. They've got a couple pieces of hardware you can use, but they have simulators that are just not a cloud. Anybody can use them. And so I went and figured out what it was doing, and read up on it, and so on. And it's one of these things where you don't want to ask too many questions when you get an assignment like that is, yeah. Why? Is it because it's the military? Well, no. The reason I don't want to ask too many questions is because what he told me is go off and have fun finding about quantum computing, right? If I ask too many questions, it might be that I know the answer already, and then I'm going to have fun with quantum computing, right? So it was fun? Do you want to do that? It was. Is it something special? Potentially. The jury's kind of out. And actually, it turned out it was good, I didn't ask questions, because the question really was what had happened is apparently somebody had asked him, well, what are you guys doing to Linux? So we'll handle quantum computing. And he's going, I don't know. So he came to me and said, Paul, find out quantum computing. But of course, it's straightforward at this point. This may change sometime in the future. So Linux just runs on quantum computers? Oh, yeah. What we do, in fact, is better than that. What we do, quantum qubits have superposition, right? I mean, you can actually have sort of kind of multiple values at once in a funny way. And so what we do is we run a superposition of Linux, Windows, and iOS on the same hardware. A super what? Super? We run a superposition. Superposition. Yeah. Of Linux, Windows, and iOS on the same hardware. What's a superposition? That means you take two different things and kind of lump them together. I'm pulling your leg. I'm sorry. Now, what's going to happen is it's going to be kind of like an FPGA or GPGPU. So you have this big quantum computing thing. It's going to have a lot of performance. Potentially. This is really early times. As far as quantum computing is concerned, this is kind of like the 1940s for real computing, or classical computing, I'm calling it. And I don't know if you have thought, have no much about what was going on with fully electronic sort of program computers in the 40s. They were cracking the Hitler codes. Well, that was not stored program. There was a fully electronic, the Colossus. I've seen that. It's a really cool machine. If you ever get to Bletchley Park in the UK, go check it out. I mean, they run it. They still runs. They run the thing. The code-crackering machine. And then before that, they have electromechanical ones. Those are the bomb. That's the ones that Alan Turing was most involved in. And they're really cool, but they're not stored program. And the bomb, the one that did the enigma, that's not even fully electronic. The oldest still intact fully electronic stored program computer is in Melbourne, Australia. Really? Yeah. It's in a museum there. It's called the CyRAC. What were they doing? It was just a research project. They used it for some kind of computations for a few, for some years after it was created. Did you see it? I did. You went all the way there just to check it out? No, I was at Linus Conf at U. And that was one of the activities you could do. No, I'm not quite that crazy. But maybe give me a few years. I might be. Anyway, the thing about it is that you've got to think about what that machine was. It had 2,000 vacuum tubes. Now, a vacuum tube is kind of like a light bulb, really. Except a low wattage one. So it's like a 15-watt latch bulb. And 15 times 2,000 is, in fact, 30,000. And the thing did, in fact, consume 30 kilowatts of power. And a vacuum tube isn't as potent as a transistor. So as a rough rule of thumb, if it takes five transistors in a circuit, it's going to take you seven vacuum tubes. And the reason is that each in the transistor has about the same voltage range. And tubes are wildly different. You have a few volts, high amperage at one end, and you have 600 volts, really low amperage at the other. And you have to have impedance match. Anyway, this thing had 768 words of memory. But this wasn't semiconductor memory. I mean, the transistor, this thing went into service in 1949. The transistor wasn't invented yet, OK? It also wasn't core memory. I was giving somebody a hard time about don't trust bits you can't see. Core memory was the stuff that was about this big. And you actually see each bit with your naked eye. But it was before core memory, too. It was before video memory. What they used to do is they took a bunch of photos receptors and stamped them in front of a CRT. And they had long persistence phosphor. And so the electron beam would paint the image. And the photoreceptors would run. It wasn't that either. It was before that. This thing used acoustic memory. You'd run sound waves through an object. And it would take a while for the sound waves to get through. And that time was the storage for the sound waves, OK? Now, back of that time, you could do it today, no problem. You make single crystal stuff. It'd be great. But 1949, you didn't want anything solid because it'd have cracks and imperfections that would reflect the sound back and mess things up. So it had to be liquid. You want something that had a really, really high speed OK. There's a substance that checks all those boxes. Would you care to guess what it is? Water? I don't know. Air? No, or air's not liquid. Water has a much higher speed of sound than air. I'll give you that. But it's still not all that fast. So you want me to guess some more? If you want. I'll give you. Come along. Liquid hydrogen or something. No, that would be interesting, although it wouldn't be. Mercury. Liquid mercury. The thing is, you've got to keep in mind, before the early 60s, metallic mercury was considered harmless. I mean, when I was a kid, my cousins had this little toy that was a maze of the blob of mercury. And so that's the reason it's the oldest intact computer and not the oldest operating one. Because there's no way you could make it work today and pass safety regulations. And not break some of those things would be sad. You don't want to break a historic thing like that. Yeah. And vacuum tubes are really hard to come by and they're really expensive. But the thing is, that's kind of where we're at with quantum computing right now. But nonetheless, they've got some preliminary results analyzing molecular hydrogen, H2, and lithium hydride, and also beryllium dihydride, BEH2. And they use the quantum computer. The thing about the molecules is that there's quantum effects in them. And it takes a very large computer, a huge amount. We're talking a big cluster, inverting these huge giga entry matrices in order to solve it and figure out what the configuration of the molecule is, the lowest configuration of the molecule is. And the hope is, and this is something that is still, I mean, there's some encouraging initial results, the hope is that you can actually use the quantum nature of the quantum computer to directly model the quantum interactions that happen in a molecule and thus potentially solve it much more quickly. It's kind of, as I said, this is really early times. It could be a threat for ARM? I don't know. The thing is right now, the biggest quantum computer in terms of qubits is from D-Wave. It's a company in British Columbia. And it's got 2,048 qubits, 2048 of them. And you're not going to run Linux on that, right? Even if each qubit was worth 100 bits, you're still not going to fit Linux on that. Even if you're doing what Nicholas Pitch is working with, it's still not going to fit. So right now what it is, you might have an ARM there, no problem, because you're going to have a computer into which this attaches. So you have this room full of cryogenic stuff and this little chip that has little qubits and the quantum and the wave guys and all that good stuff and the control. And it's going to plug in to a normal computer, perhaps like one of these guys here. That one's running ARM. This is going to say six. I don't know why you guys don't have a mainframe here. I guess we don't do embedded very well. But that means that ARM could be the computer. X-axis could be the computer. Power or mainframe could be the computer. But you'll have a normal computer there for some time. There may come a time 20, 30 years from now when we just have a quantum computer that runs by itself. But quite frankly in the study I've done, I'm not optimistic about that, but a lot can happen in 30 years. I can tell you that. Because at IBM they're doing lots of crazy advanced chips, chip technology. And you are in another department that makes us have to run on all these crazy advanced chips. So what is it that you do? Usually what happens is that most of the time the chips are just ways of making things run faster for normal computers. Quantum computing, meaning exception that proves the rule. What I do is I'm down in the very low guts of the Linux kernel, there's a small piece of it that's my baby, RCU, which is a synchronization primitive that allows mostly data structures to be processed really, really quickly with high scalability. So that's been a lot of fun as well. And these linearo guys, it's fun to see them once every five years? Well, you see them online all the time. You guys are in San Francisco, so I figured I should drop by, you know, why not? Cool. All right, and you probably have all kinds of other things happening, right? And you have hobbies? Or they're basically... I have very weird hobbies. What is that? Well, mostly related to what I'm doing. All right, so basically your job is your hobby, right? Not pretty much. Yeah, I get out in the gym, I do some hiking. Living in the Pacific Northwest, you're really cheating yourself, you don't get out and check out the waterfalls and the mountains and the trails and the trees. So I do that. And, you know, it keeps things going. Cool, I hope we can do another video sooner than in five years. Well, it was good talking to you, Sharbo. And how do you splash your name? Charbax. Charbax, okay, like it's spelled. From armdevices.net. All right. All right, thanks a lot. And you have a good one. Have a great evening.