Latest / Oxide and Friends / The episode formerly known as ℔

Transcript

The episode formerly known as ℔ · Oxide and Friends

• 0:00
  Speaker 1: We are good to go. Alright. Alright. Well, welcome, everybody. Welcome especially to, I mean, Adam, you're, of course, always valued.
• 0:09
  But as the master of the recording
• 0:10
  Speaker 2: There you go.
• 0:11
  Speaker 1: Especially valued. Thank you. So I thought we might kick this off, with, Tom, I've got some great questions for you in a little bit. I we had an amazing space last week, with with Jessamyn and and g Pascal and Zachary.
• 0:28
  Speaker 2: I I mean, Adam, what
• 0:29
  Speaker 1: were some, do you have some favorite moments from that? I I've got a couple.
• 0:33
  Speaker 2: You know, just this I was I was very curious about how it's gonna come together because we're talking about, more topics perhaps than we usually do. We had, like, 6 or 7 where usually we we have 1 or 2. And just the the way that the two books intersected about, Soul A New Machine being about the product and totally ignoring the families. Like, Jessamine only being mentioned, to Thomas's daughter as, as the person he went on a bike ride with one day as opposed to showstopper really showing the the the human carnage left in the wank of this product. So I I love that part of it.
• 1:11
  Speaker 1: I thought that was amazing. I thought the interplay between, Jasmine and and Zach, Greg, was was amazing. I also I have to say the d base and the Ashton Tate, oh my god. Do we need a book on Ashton Tate? Did you go into that Wikipedia page?
• 1:27
  No. That Wikipedia page will take you out. That Ashton Tate is mesmerizing. And like, so dBase 4, you should look at the I mean, obviously, it's like it's it's Wikipedia, so it's obviously, like, I guess, not authoritative. I mean, it's not authoritative for sure.
• 1:47
  I mean, so I tell my kids. But, oh my god. In terms of the reasons for failure of dBase 4, basically, the thing was a wreck. It didn't work according to according to my sources on Wikipedia. But then they have all these, like, strange pivots into, like, personal information software, including Friday.
• 2:05
  Bang. Friday was like a like a didn't use, like, Sidekick back in the day on the on a PC. This is like Google Calendar for DOS, if that makes any sense.
• 2:22
  Speaker 2: This is that's awesome.
• 2:24
  Speaker 1: It's it's so weird. It's so weird. Blinky. So, anyway, I and, in particular, we've got so, Cole collected some and has been collecting terrific notes for the spaces. So Twitter and then so, Cole, we're really, grateful for that.
• 2:44
  You had some good questions that you're asking online, so I would thought you might be able to kick us off by asking some of those questions.
• 2:50
  Speaker 3: Yeah. Totally. And, oh, can you hear me?
• 2:53
  Speaker 1: Yep.
• 2:53
  Speaker 4: Can anyone hear me? We
• 2:54
  Speaker 1: can hear you loud. Okay.
• 2:56
  Speaker 3: Totally. I really appreciate it. The the thank you, and so you're welcome. And, I was kinda wondering about some of the phrasing they use. So they called it an operating program, not an operating system.
• 3:08
  That was very odd. And I was just wondering if that was for kind of the layperson, the reader, you know, to kind of make more sense of it or if that's actually what they used to call operating systems.
• 3:20
  Speaker 1: So my answer to that would love Tom's answer and others' answer, but my answer to that is that it it is it was an operating system. It was known as an operating system. I think the the the kind of 2 potential answers are, 1, Zach is calling it an operating program to kind of connect. He's deliberately trying to connect as Kidder did to a non technical leadership. So that maybe a bit of that.
• 3:44
  I also wonder if it's a bit of there is a trend to talk about, like, operating environments instead of operating systems. And, Adam, I I made references to this book just before you joined, But I ran across this talk that Steve Jobs gave at MIT to Sloan in in 1992. And, boy, does it make, interesting viewing in contrast or in addition to the Steve Jobs' The Next Big Thing that we talked about a couple weeks ago. He viewed so in particular in that talk, I mean, there are a lot of things that are interesting in that talk. But one of the things that's interesting in the talk is he is called your question.
• 4:23
  He is adamant that Next step is not an operating system. It is an operating environment. So Wow. So there is a little bit of a zeitgeist at that time. And I remember, like, we were calling Solaris an operating environment as well.
• 4:37
  So I think people are trying to get out from underneath the kind of the DOS and OS stigma. Does that Tom, does that does that does that make any sense?
• 4:48
  Speaker 5: Yeah. I I think for a while, people thought started to think of operating systems as totally boring and commoditized. And so it was it was it was all marketing, but also emphasizing what next step, you know, the windowing system.
• 5:04
  Speaker 4: And the yeah.
• 5:06
  Speaker 6: Well, so, like, from my perspective, you know, just, you know, I went back and watched some of those things, you know, just because for the lulls, something that I that I thought was quite interesting was when you're they talk about operating environments versus operating systems. They talk about the context of what the user can actually do within it. Which is something that, you know, when you talk about the DOS based stuff and things like that or even like really old windows. Right? They it's not really talking about what you can do in the environment.
• 5:40
  It's talking about what it lets you do outside of it, like running your programs and whatnot. And a big part of it was, at least to me, it seemed like we are talking about what this and what the operating system gives you. And if you talk about it as an environment, then it gives you that imagery that this is something that you're in and you can do stuff in and participate in, which is something that is different from, say, a cold meaning of the word system.
• 6:08
  Speaker 1: Yeah. Interesting. And and that definitely dovetails exactly with what Jobs was saying about next step, whatever it's worth them talking about. The ability to create applications faster, and how they were how Sun was coming after them, and they were annihilating Sun at this. It was, interesting talk, honestly.
• 6:27
  Always interesting to hear jobs when he's, like, healthy, and, you mean, you forget how kinda robust he was before when he was not sick? So so Cole Well,
• 6:37
  Speaker 6: he also
• 6:38
  Speaker 1: Sorry. Go ahead, Neil.
• 6:40
  Speaker 6: Yeah. So he also he you know, those things that he said during his talking about Next versus Sun, he actually replayed a lot of the same verbiage when he was talking about Mac OS 10 when he launched when it launched it with Aqua and all that stuff. There was a lot of focus on what Mac OS 10 itself did for you. And that's, like, the things with the widgets, with the UI, the, the spinder enhancement, spotlight, all those things. Like, those are features that are part of the operating environment itself, the desktop environment, or if you wanna call it by classical terms.
• 7:14
  But they considered it 1 and the same, and that kind of mindset, I think is what drove them to develop a usable, seamless interactive experience for users
• 7:27
  Speaker 1: Yeah. Interesting.
• 7:28
  Speaker 6: Which I think everyone else didn't do.
• 7:30
  Speaker 1: Yeah. Yeah. No. That's interesting. And, I mean, certainly, it was it was definitely an inflection point.
• 7:35
  And then, Cole, you had another, another good question, I thought.
• 7:40
  Speaker 3: Yeah. So, Pascal, the author of the book had talked about wanting to support n t wanting to support different kind of modes of operation, wanting to support Windows programs, but also OS 2 programs, and they call them personalities. And so they called it supporting multiple personalities. Yeah. And I just thought that was the the most odd phrasing I had ever heard of that.
• 8:04
  Speaker 2: And, Brad, I don't know about I don't know for you if that that comment really just transported me back to, like, something that I Absolutely.
• 8:12
  Speaker 6: Oh my goodness. I remembered all that.
• 8:15
  Speaker 2: No. No. Totally. We're we're I, you know, I I had this moment reading through the showstopper thinking, oh, yeah. Didn't NT run on on, like, alpha systems?
• 8:26
  Like, am I am I just imagining that was just a beautiful dream? Yeah. Obviously and they got to it in the book, but but I I I definitely forgotten about that for about 20 years.
• 8:35
  Speaker 1: Absolutely. I
• 8:36
  Speaker 6: remember running NT on a PowerPC Mac. Like, it was a thing.
• 8:40
  Speaker 4: That's awesome.
• 8:40
  Speaker 6: It was hard, but it was it was possible.
• 8:45
  Speaker 1: Yeah. So I no. I Adam, I felt the exact same way. It was I felt like I could hear, like, smashing pumpkins playing on the radio. I think, you know, it was it was, like, you know, rage against the machine.
• 8:56
  I felt like I was it was getting me right back in that nineties zeitgeist. So, Cole, as you may be inferring, personality is very much a technical term from the nineties. And there is this kind of idea that, we are gonna make a, an operating system operating environment, that looks like another one. And, Tom, you had left Sun before spring, I imagine.
• 9:23
  Speaker 5: Yeah. I mean, I I heard a lot about it.
• 9:25
  Speaker 1: But Oh, man. So spring was kinda like the neutral of this, of we are gonna support arbitrary personalities. We're gonna have a micro kernel based system. Mock, I think I mean, I don't know. I think the personality term must have originated with mock, I would imagine.
• 9:40
  Speaker 6: It did. It it came from CMU mock, which both, Gnu Hurd and Mac OS 10, x n u, inherited.
• 9:48
  Speaker 1: Yeah. So the and for me, it's very, like, evocative of the nineties because we actually, as an undergraduate, developed a, in our operating systems course, had a professor, god bless him, loved to stay current. And he loved to kinda redo the project to stay current. And, unfortunately, current in 1993 meant developing a microkernel based operating system with a personality. So it we developed a spring like operating system, which was just absolutely brutal.
• 10:23
  Speaker 7: But, that those times are back. Right? So now we have, you know, we have the m one and we have ARM and, and, you know, we have Windows subsystem for Linux and, you know, it's kinda like personalities and different architectures. And, you know, the days of running Windows NT on your alpha, it's kinda coming back. Right?
• 10:42
  Speaker 1: It it is kinda coming back.
• 10:43
  Speaker 6: Yeah. But it's differently. It's it's different though. This time, I would also impl like, another aspect of this is that back then in the nineties, it was all about pulling other types of things into 1. In this case, it's putting one thing into other stuff.
• 10:58
  And so, like, the terminology of using subsystem and things like that kind of implies that it's not about bringing them together in a way where it's like a unified thing. Even though in some cases, like LXSS or WSL as it's branded, actually does some of this. It's not about the same kind of unification that you saw with Windows NT4 with the POSIX OS 2 and Win 32, personalities. It's a little different in that way.
• 11:27
  Speaker 5: Yeah. These these days, you have virtualization everywhere, which, you know, lets you lets you do all these personalities. But in the original personality concept, you know, it went along with microkernels. They were assumed that separate personalities made something simpler. There is
• 11:44
  Speaker 2: today, that's not true. Yeah. Well,
• 11:47
  Speaker 6: that was not true. I don't know if that was true even then, although a lot of people believed it.
• 11:51
  Speaker 5: Yeah. Yeah.
• 11:52
  Speaker 2: Yeah. I mean, I I there there is sort of an ideal, quaint idealism to it and sort of obliqueness to this dockerized world where people often take the view that you could never configure your system properly. So I'm just gonna ship everything and just take static link linking to the absolute extreme in order for you to run this thing.
• 12:12
  Speaker 6: Please stop making me sad.
• 12:15
  Speaker 1: Yeah. It so, Cole, that's a long answer to your to your question, about the, the but the so personality is very, very much term. And, Simeon, I think it gets kinda it is an interesting point that, you know, a lot of this stuff has actually come back and has been, has become newly relevant or or more practical.
• 12:39
  Speaker 7: There's a there's another thing which I'm kinda curious about, and that's like the the microkernel So microkernels, I guess you got Mach, and you got various, like, embedded stuff. You know, that microkernel seem to be very popular in, you know, embedded operating systems, especially safety critical stuff. But you know, there's of course the famous Torvalds, disagreeing with Dunnebaum about MINIX debate. And and now I hear, you know, you folks are working on a microeconomics for, what is it, hubris? It is.
• 13:14
  So tell us about that.
• 13:15
  Speaker 2: Yeah.
• 13:15
  Speaker 1: I was gonna actually I I I was trying to get Laura in here as well as a as a a speaker. But, yeah. We well, and so, in terms of my my own history with microkernels, because I was coming up in this time of personalities, Cole, and when this we're very much in vogue. And we had developed this this micro kernel based, system as an undergraduate project. So I actually went to work for a micro kernel OS company, called QNX, qNX.
• 13:44
  And it was great. I mean, a micro kernel system, it it's basically it's a message passing system, l 3, l 4 like system Unix was. And my view on Unix was, like, why would we not run this absolutely everywhere? And we should open source it, and it should be everywhere. And I still feel like it could be in an alternate reality.
• 14:04
  QNXT
• 14:05
  Speaker 7: You got a you got a disk. I remember you got a disk that you could actually boot QNX on a on an x86 machine? The
• 14:12
  Speaker 1: you you've got a good memory. So that was a 1.44 megabyte floppy disk. That was from Dan Hildebrand who sadly died, I of died of brain cancer maybe 6 or 7 years after that. I loved Dan. Dan had such an impact on my own career.
• 14:27
  He actually is the reason I was at QNX. And Dan was so enthusiastic and was always looking for, like, new ways to kind of talk about what we could go do with Qunix. So he had this idea of, like, we should put it on a 1.44 megabyte floppy. And yeah. That's it.
• 14:42
  Did you run it, Simeon? Did you did you play
• 14:44
  Speaker 7: with that? Yeah. I mean, I guess it is like, I don't know if you guys ever saw Oberon. That was also like a weird operating system that you could boot on a single floppy. Single floppy.
• 14:55
  Yeah. You know, I booted it up. It was kinda cute. It had a sort of a nice little GUI that's sort of reminiscent of, you know, other of the small GUI operating systems. And it it was Unix like, if I remember correctly, but
• 15:09
  Speaker 1: I never did much of it. You do. And you you yeah. You've got a very good memory. That GUI was called, Photon.
• 15:17
  And the, and Photon was super interesting, I thought. The it was kind of this and very much leveraged the message passing architecture of the system. So this is a long way of, of kind of this is kind of some of the backdrop for me personally. Laura, do you wanna kinda take it here and talk about what we're doing with with Hubris?
• 15:42
  Speaker 8: Sure. I can talk a little bit about we were doing from Cuberis. I think probably I should probably back when I first joined Oxide I started out by writing in RFPs because at Oxide we do a lot of writing. And I sort of want talking about trying to do a survey about, okay, what exactly is was over there, what we were going to do for a microcontroller system. And I think I had done a pretty wide survey, and and somewhere there I had a thing about, you know, router or numbers.
• 16:06
  I think I put put in there, no, this is a bad idea. We probably wouldn't do this, yadayada. There there is plenty of other things out there. And behold we ended up running our own. And I and I think I I say this just because I think what we found is that we really wanted this thing to be fairly precise to be able to have the isolation, I think, more than anything from what we wanted and be able to have something that's correct.
• 16:32
  And of course also in Rust. So what we're trying to go back for. So I I think we really hopefully be able to try and learn from the core of the of the, various micro kernels to be able to deliver something that is hopefully small and also very useful and also
• 16:47
  Speaker 6: very particular and I
• 16:47
  Speaker 8: think opinionated about what exactly it does. I think especially learning from I think other things out there, probably we trigger people's past just being able to deliver the core kernel and act together so there's a single image and things like that I think more than anything. And, I mean it's also I I think everybody also dreams about getting to write their own operating system from scratch. So the chance to be able to do that I think
• 17:11
  Speaker 2: has been fantastic. And it's it's been a
• 17:13
  Speaker 8: great learning experience I think just to be able to see things out. Cliff, who is one of our colleagues, who is, smarter than all of us and not on Twitter, all the design work to be able to get this off the ground and it's been a very precise and, you know, good about trying to make sure that this thing is very correctness focus among everything else and also to make, make sure that it is hard to misuse a lot of these interfaces as well, especially from we're trying to do things. But, in terms of just being able to say, write a driver and then be able to have an interface that's hard to screw
• 17:47
  Speaker 1: things up. So And so and Laura, had you worked on a micro kernel based system before? I assume I mean, I haven't worked on one for 25 years. So I assume you you had not?
• 17:55
  Speaker 3: Or
• 17:56
  Speaker 8: No. I I when I in college, I read papers about it and other things like that, but I think this is also one of these things that I don't think I fully internalized, what exactly meant to work on micro or anything, like that.
• 18:11
  Speaker 1: And and how have you found it in terms of, like, developing? Because you and I have obviously both developed drivers for Hubris and tasks and so on. How have you found it?
• 18:18
  Speaker 8: I've enjoyed it so far. I I think it's certainly I think also because it is ultimately an embedded system and a fairly flat one. I think it's it's not certain things are missing but, I think it also forces you to think about exactly how are you sharing the memory and various
• 18:43
  Speaker 1: clips great insights And it kind of just came about as we were thinking about our own root of trust and how you deal with with what a program looks like in an embedded system and how you kind of sign that and how you attest to that. And one of the mistakes, honestly, that general purpose embedded systems make is the ability to load an arbitrary program. But in an embedded system, you don't need to load an arbitrary program. You know when you build that particular image, you know all the programs that are gonna be in there. And I think one of Cliff's great observations was, hey.
• 19:15
  If we know all that, we can actually know statically what our tasks are, and then you're not doing any dynamic allocation. So when a task dies, you know that the memory that that task was using is available for that task to be restarted because that task is now dead. So now it's alive again. And there's, like, a bunch of so there's very little dynamic allocation we have. Laura, so far, I think we've got damn near zero dynamic memory allocation.
• 19:42
  Speaker 8: Yeah. I I I think more than anything, I think especially for what we've been doing right now, it's a lot of been
• 19:47
  Speaker 6: figuring out. I think the
• 19:48
  Speaker 8: basis about what actually works for a driver. And I think also in particular, one thing we've also made the distinct choices to not is, black preemption which has also solved a lot of I'm not gonna say solved a lot of problems but it is presented to us with a focus set of problems to be able to solve. But yeah, the lack of dynamic allocation or at least the so far we haven't found the need to have it, I I think it's made made things easier. I think that's that's been also with part of our design is that before we answer them, we've been a long time to say, okay, okay but do we really need this because I think in particular because it's a you know micro kernel IPC based system we've been it's been synchronous. I mean, they've been spent a long time trying to say, okay, but do we really need asynchronous?
• 20:29
  And, you know, spending a long time before we really need to add anything like that. I've included so far that no. We haven't actually found the need to add anything like that yet, which I think has been forcing ourselves to make sure we're using the right tool for the job, not just adding things because we get really excited about them or, anything like that.
• 20:46
  Speaker 1: Yeah. And I love, you know, Laura made the illusion to this RFP that she wrote about, like and it I Laura, I think it was, like, almost verbatim with the RFP. It's like, well, it'd be great. Everyone would dream about writing offerings from scratch, but, of course, that doesn't make sense us. And then as we investigate it more, it's like, actually, this doesn't make sense for us.
• 21:02
  So this is, well
• 21:05
  Speaker 7: because, yeah, maybe you guys, had a look at Talk. I mean, I've seen some of your stuff, online about Talk and and found some issues with it that it wouldn't work.
• 21:14
  Speaker 1: Yeah. So I would say that Talk is, I mean, so talk is real first of all, love talk. Love I mean, love Philip, love what they've done there. I think that it's got great admiration for Talk. I think part of the challenge for Talk is it was really designed to be a a teaching operating system, which is great and admirable.
• 21:35
  But so dynamic program loading is something that's very important to talk. The ability to load a a new binary. And in in some ways, I don't know about you for you, Laura, but for me, like, that was part of the the, of the kind of, that was a very catalytic in terms of thinking, wait a minute. How would the TalkLoader look in an environment where everything needs to be signed? I'm like, oh my god.
• 21:57
  This is just gonna get super, super gnarly. And I don't know. It's been my memory. It was kind of about that time that Cliff was beginning to think, like, maybe we need to do go a totally different route.
• 22:09
  Speaker 6: So, you know, something about all this that, you know, as you've you and Laura have been talking about this, you know, I I've been thinking about there's lots and lots and lots of operating systems for embedded and and various RTOS and smallware stuff. And what Laura said about, do we really need dynamic allocation? Do we need arbitrary code, code program loading? And the answer to those were no. And I think this is where it becomes easier to make an operating system if you want to because you're not implementing a full operating system.
• 22:43
  You're implementing a a special purpose once effectively. And that lets you make all call, all kinds of trade offs that make it tons easier to implement a system of Well, that's right. And I
• 22:53
  Speaker 1: think that, you know, another very important thing that we did is that we have got an all Rust user land, which Talk actually Talks has struggled a bit with Rust user. I mean, Laura, I saw you unmuting there to talk about some of the kind of our thinking there about why not Talk.
• 23:08
  Speaker 8: Yeah. I mean, I I also agree with Brian's that the talk people were great to work with and I I definitely appreciate all the support they gave us and I I ultimately kind of came down to we had different ideas about, what we wanna do and I I really hope to see you talking to you to grow and succeed just because I think, you know, having more operating systems out there is a great choice. And I think also to Brian's point about like user program that I think that that was back on the pain points and I think also the all our choice to do everything in Rust I think is also certainly made things easier just because I think that was trying to do, potentially support C programs or having to think about that for talk made just another set of things to for us to have people try and worry about we don't have to do so
• 23:52
  Speaker 1: with with the wrong way. Right. And actually, Lauren, Adam, I just had a bad Robey Rippey flashback as well. I
• 23:58
  Speaker 2: Yeah. And this is I mean, Laura, this discussion was taking me back to it was just about just about a year ago, maybe a little over a year ago that, you mostly, but me, some were struggling with just, how we were gonna handle the the slots and talk. And it was just it's not that it was misdesigned. It was just a different design center.
• 24:18
  Speaker 8: Yeah. And and your example about Ropey Ropey, I think this is also, discussing some of the growing case I think of risk 5 as well because that was the other thing is is that, so the Ruby Ruby referred to particular compiler features especially on no new systems, to be able to, do some of the program molding you wanted. I I think if we have notes later, I'll have to go back and to get some, notes on this. But that's an example of something that was major compiler support that was missing and then try to figure out how to work around that was a big pain point in terms of trying adding that. And then I mean, you know, Oxide jokes about having startups with startups then I mean, become a compiler engineer or certainly something, you know, again, in terms of why we're working with the compiler engineers.
• 25:00
  Sounds like a lot of fun, but it's not actually, you know, our our core product.
• 25:04
  Speaker 2: Right. And when you're kind
• 25:05
  Speaker 1: of, like, 5 startups deep, that's when it's time to be like, wait a minute. Where are we exactly? What exactly are we doing? And, and, I mean, I can't believe that with honestly, there's a lot that I love about risk 5. So that was the other kind of things, I mean, that we were because we were looking at OpenTalk on OpenTitan, to a certain degree, it ended up also being risk 5 versus Cortex.
• 25:24
  But then even that is I I think the the the much larger issue for us was just our use case was just a little bit different. And I Laura was extremely good very early on as we are because it's really hard to start out on a hard daunting problem when you got so much to do in front of you. And, Laura, I just thought thought you did a great job in those early days of being like, okay. But how do we sign what we need? You know, you're really kind of, like, already beginning to think about, like, this needs to be a root of trust, and we're gonna need mechanics to kinda manage and sign this and you begin to think, like, yeah.
• 25:57
  Right. This is gonna be complicated.
• 26:00
  Speaker 8: Yeah. And then I I want to give credit Cliff for, being able to point all of the perils about trying to do things because he had done some some similar work in the past. So I think I think one of the only things we set out to our is that we spend a lot of time trying to read and learn from what's out there so that, hopefully, is just that we are making entirely new set of mistakes.
• 26:18
  Speaker 1: That's right.
• 26:20
  Speaker 8: One for the people part.
• 26:21
  Speaker 6: That is the second time today I've heard that.
• 26:23
  Speaker 8: Well, as
• 26:23
  Speaker 1: you know, this is a that you've been in the second good conversation today. I think trying to make different sets of mistakes is shows a level of self awareness, but we are definitely trying to make different mistakes. You know, Laura, I can't remember if I talked to you about one of the very surprising differences between qNex and a monolithic system, but this one was very, one of the the perils of micro kernel robustness, stack were pretty buggy. We're, like, very buggy. And part of the reason that there was, like, not a huge I mean, it's like people wanted to fix bugs, but when you can just, like, restart the network stack when it dies or restart the file system.
• 27:08
  Like, the machine doesn't bounce. There's a little bit less of a social pressure to kinda fix some of these issues. And I remember it's, like, having this thought at Sun being like, wow. If the file system has an error, the entire operating system crashes. And, boy, we are really focused on making a robust file system, making a robust networking stack.
• 27:27
  So I think we wanna not repeat. We wanna I think we wanna never use Hubris' robustness as an excuse for making slipshod tasks. I would say not that we would. Good.
• 27:41
  Speaker 6: That's gonna be really hard.
• 27:42
  Speaker 2: We also we do I mean
• 27:44
  Speaker 6: Because well well, because, like, if you it thinks of like, when you're doing that, you have to think about, like, how important is a failure domain. And and when you're talking about micro kernels that are robust and that will just basically whack things until they work, and you don't notice. Right? The most important part is you don't notice because otherwise they're not robust. Then then how important is it?
• 28:05
  Speaker 2: And, like
• 28:06
  Speaker 1: and you definitely get that they're, you know, how much do you want a single task to kind of, continue to soldier on when it's in when it is, kinda arbitrary corrupted. I think one of the things that Laura, I don't know about you, but I have definitely appreciated. I mean, I feel that, like, I have always been pro memory protection. I don't feel I've ever been, I mean
• 28:28
  Speaker 6: Why would you be anti memory protection?
• 28:30
  Speaker 2: This last week. I mean, when you learned it when you learned of it finally, having your, your childhood stolen by Bill Gates. But, yeah, yeah, see last week for for more on that.
• 28:38
  Speaker 1: Right. Viz last week. Oh, no. And well, and, I mean, it just Microsoft being very explicitly anti memory protection, and memory protection and Cutler and Gates having this huge argument inside that that that is outlined in showstopper is really compelling. But one of the things that I feel that I that I mean, I have always been very pro memory protection, but this whole experience has made me way more pro memory protection.
• 28:59
  I mean, Laura, I don't know what your take is on it, but, boy, the MPU has been essential for us.
• 29:04
  Speaker 8: Yeah. And and I think it's also important to to point out that this is an and then you will assume that it does have the MPU protection just to be able to protect from physical memory access which I agree has been absolutely essential. But in in some respects, maybe one of the things you could potentially make a trip says, okay. The system is potentially so simple. Do we really need the perhaps expense about trying to set these things up or other things like that, which I I could see in the abstract by someone might make that trade up, but I I would not want to be doing this, without any kind of memory protection just from, you know, screwing things up.
• 29:37
  Speaker 1: Yeah. And I think that one of the things that I've appreciated again, Laurent, I don't know about you, but I have kind of appreciated that, the unsafe operations in Rust, in otherwise safe Rust, are all the stack operations. And, you know, there was a in earlier days of Hubris, we you know, you've got a task. It's got a single region, and, and stacks are would effectively grow. If stacks overflowed, they would not hit the protection boundary.
• 30:02
  They would hit the data segment of the process. And that created some Rust bugs in, like, see in, like, otherwise correct safe Rust, but a stack overflow now becomes this really pernicious memory corruption. So, Laura, I mean, I know I I dealt with a couple of I think you dealt with a couple of those too, right, where you would have something that, like, is trying to panic because it's trying to go deeper into the stack and instead it's inducing data corruption.
• 30:26
  Speaker 8: Yeah. I so so I I'd say that stack corruption has always been one of these things that's very difficult to try and debug in the first place just because you can end up with stuff that just looks like complete nonsense because you can't actually use it to back trace. But yes, I I think that adding additional protection to be able to find that has been really key. I think even just with trying to do basic debugging, I think in particular the way we have things structured, you're only getting access to a particular region of, I think, given your sets of registers, which is also another way I think to really be able to fully audit. Okay.
• 30:54
  And ask, does this driver really need access to this particular memory block? Or can it provide you more isolation? I think it's which is, another way I think of just making sure things are even more effective. I think it really makes you think about things a little bit more as well.
• 31:07
  Speaker 1: Yeah. Well, it's really a good point. So another thing that we've done in in Hubris is there's this kind of before any given image, there's this kind of, TOML file that describes here the tasks I'm gonna have. Here is kind of this the the the the how they're gonna be sized. And then here are the specific device drivers that it device memory regions that it needs access to, which allows us to really kind of constrict things.
• 31:29
  Speaker 2: And to close to get the punchline, how did you guys close-up that, that ability to corrupt the the data segment from a stack overflow?
• 31:38
  Speaker 1: We we flipped them. So we had the stack. So the, it used to be that the stack is at the top of the member protection region and the data is at the bottom. And then the if your stack overflowed, it would overflow into your data. And it's also stack overflow is the worst because it's corrupt and run where, you know, I go deep on one stack trace, and I maybe hit just like, one byte, in your data segment, and then I run away.
• 32:02
  I run my stack on wines, and, like, I haven't died, but you are now corrupt. Run. And so the, we flipped those and had the stack then, grows towards the production boundaries. So the data's at the top. The stack's at the bottom, and you could still, you know, construct.
• 32:21
  Certainly, unsafe for us that would corrupt itself. But, now when you stack up when your stack flows, you hit the production boundary and you die cleanly.
• 32:30
  Speaker 2: Nice.
• 32:31
  Speaker 1: And sorry, Laura. Are we trying to get
• 32:33
  Speaker 2: in there?
• 32:33
  Speaker 1: I didn't mean to cut off there.
• 32:35
  Speaker 8: Oh, no. That I I think you covered everything. Yeah.
• 32:37
  Speaker 1: But, yeah, it's it's it's been, it's been, I mean, it's been fun. Bluntly. It's been it's been great. I feel like we the it the, and I mean, all credit due Cliff, who is the and it definitely you get Cliff's sense of humor in in hubris, which I gotta say, I Laura, I don't know about you. I still laugh every time at the so, the hubris, of course, we make reference to the Ozymandias, the from the the the famous poems that was a Shelley poem.
• 33:06
  Right? The, I so we are bought that if you have any Rust format that's incorrect. Adam, do you know this? Have have you seen this?
• 33:16
  Speaker 2: No. I haven't seen this.
• 33:17
  Speaker 1: Oh my god. This is so good. I almost wanna make you discover this naturally, but I I I I can't at this point. So if you have, any Rust David, if you've got a Rust format issue, the bot will correct your formatting. It the bot's name is Ozymandias, in Greek.
• 33:34
  And the the comment, which I can't even relate to you without laughing, it's not my joke, so I feel like I can laugh at it, is all in caps. Look upon my reformatting e mighty and despair bang, which I just think is great. Nice.
• 33:51
  Speaker 2: I don't
• 33:51
  Speaker 1: know, Laura. Maybe I've got a I I'm
• 33:52
  Speaker 2: not sure if they that's, like, it's a chuckle out of
• 33:54
  Speaker 1: you, but, like, it's a chuck. I not to the point where I deliberately introduced for running problems, though, I'd like to say.
• 34:01
  Speaker 6: I don't know. I don't believe you, Brian.
• 34:02
  Speaker 1: I actually no. No. I've got a complicated enough relationship with Rust format as it is. I I I I need to Are are
• 34:08
  Speaker 8: we gonna have to put a dollar in the Brian complaints about Rust format or
• 34:11
  Speaker 1: I I've already put one in. Does that mean that I get to complain about Rust format if I put one in in advance? Yes. Yes. You know what?
• 34:18
  I we've got there's an open issue on our our what is she? No. It's fine. Actually, I I I'm I'm I'm becoming fine with the Rust format. I'm gonna still put my dollar in the jar anyway, but I have I'm at peace with the Rust format in part because I tell it to skip things that I feel it's not formatting well.
• 34:35
  But, you know, I'm trying to be the
• 34:37
  Speaker 6: So you've bludgeoned it into Well,
• 34:38
  Speaker 1: it's actually so the the in particular, the what the way Rust format works is it rewrites code, which I will I really admire, actually, that it is that it is not like a style checker. It is a code rewriter. And the fact that it gets it, like, so correct so frequently is actually very impressive.
• 34:58
  Speaker 2: You know, Brian, that that is a a big shift because I think a year ago, you would not have admired it. You described it, I think, as a war crime. So it's a quite quite an evolution. Remember you
• 35:09
  Speaker 6: I remember Brian describing it as a war crime.
• 35:11
  Speaker 1: Trying to be on on my my best behavior. First of all, I reserve that language apparently for Stalebot, which Laura also
• 35:19
  Speaker 2: just maybe we can Laura's got
• 35:21
  Speaker 1: a great blog entry to write on the on the the I was I was deriding the Stalebot because I was in a project in which it is not used very well. And Laura was rightfully pointing out, like, hey. Stalebot can be really important in a project where you got a lot of, consumer facing open source, Laura. Is that a fair description?
• 35:41
  Speaker 8: I think that's reasonable.
• 35:42
  Speaker 2: But And to be fair, I
• 35:43
  Speaker 8: I think you're right with that stale bot in this particular instance was valid.
• 35:47
  Speaker 1: Yeah. I mean, I think actually that Laura and I both actually have the same issue when the the same root issue, which is, you know, in in issues database, you've got 2 people meeting. You've got the submitter at least 2 people meeting many people meeting. You've got the submitter, and you've got the issue they have and maybe the people that they represent. And then you have the people that are maintaining the project.
• 36:08
  Right? I guess this is like we we should do it, like, a law and order intro for there are two sides to GitHub to GitHub issues. The the people who submit issues and the people who close them out is not very small.
• 36:24
  Speaker 6: Oh, lord.
• 36:25
  Speaker 1: But I think that that Laura's issue, which is a is a totally legit issue, is when people file issues without real empathy for the maintainers. And especially when you've got a big project that is consumer facing or has a very broad market facing, people really do not treat I mean, in these poor you know, it's like the atcxkcd. Right? With everything depending on an open source project that's been neglected for years, I feel that, like, people don't treat those manateas very well, and they they treat them in a very entitled way. And I think Laura's objection Laura, I I've obviously, correct me if I'm wrong, but I think Laura's objection is when people are kind of filing issues without empathy for the person that's gonna read that issue.
• 37:09
  Is that fair?
• 37:11
  Speaker 8: I I think that's fair. And and I think it's also better of the I I think your point about, you know, obviously, for the submitter is also a good one. Because the point is that okay, it is I think open source is ultimately supposed to be a collaborative process so the point is that how are we exactly working together to try and solve this? And I think the point is that when a submitter is making a bug, you especially his maintainer has spent a long time trying to figure out, okay, how exactly is that gonna work with this? And I mean, sometimes, unfortunately, the submitters just don't give you a lot to work with.
• 37:39
  It ends up being stuck between a rock and hard place and it says, okay, I can try and close this bug now and tell them, sorry, I don't think I'm ever actually gonna get to to this or I can let it go for a while and maybe it'll get fixed by something else for something else. Just through happenstance. And you're sort of left between there. On the other hand this is also a case of where I think of your example where, if you you're a submitter and you spend a lot of time trying to really find a bug, but perhaps you've given like the back price. You've done a lot of debunking already.
• 38:08
  You've seen that cater to do a lot more of their specialized expertise and do that. And to see that gets close, that really hurts as well for both those cases. So it really is, you know both have the same same calling for empathy about it, figuring out exactly how to do this. I do think I still think that there are some cases where automatically closing bugs can be useful. But again as you know I think I pointed out is that bots should be supplementing maintainers, not fully replacing them.
• 38:30
  And I think this does mean that the maintainer needs to be able to try to use their best judgment of really trying to work with submitters to actually solve the problem.
• 38:37
  Speaker 2: That that that's right. Steelbot as a defense for hardworking, earnest, maintainers who are trying to do the right thing, that's one thing. But as a, like a defense from from, users who are trying to misuse their time. But I think in this case, at least, this was a a proxy. Like, instead of being, diligent maintainer, this was kinda closing things out.
• 39:00
  And, Brian, you said, you know, the maintainers and the folks submitting the issues are supposed to meet in the issues. But when you see, you know, reports of data corruption that have gone uncommented on despite thorough review, that's really disheartening.
• 39:13
  Speaker 1: It is. And I often felt I feel like that, you know, may all of the open source projects you use be blessed with an issue that you encounter early. Because I do feel like the that when you discover an issue with a project and you as a submitter, okay. We're using this project. I wanna make sure that I am treating others the way I wanna be treated.
• 39:32
  And I do a lot of homework and then and submit that. How is that issue received? And when that issue is received well, it feels great on all sides, actually. It's like I I mean, I've had a couple projects where and then there were some projects where you're like, you know, this project, there are things I don't like about this project, but they're really receptive to my feedback, and I actually really appreciate that. And
• 39:54
  Speaker 9: Brian, can I talk about a fun bug? So I worked on QNX for about 5 years. About 10 years ago, I started working on, QNX on, embedded Internet of Things, operating system. And and so on 32 bit, it's unsigned. So we've got this 2038 problem coming up, and it's kinda like y two k.
• 40:12
  And I knew about it and but it I set it for 2106 since it's, unsigned. And, it crashed the system. So that that, you know, represented something they needed to fix. You know, normally if it rolls over, it's no big deal. But, you know, so I had to argue for that bug, to get fixed.
• 40:27
  Speaker 1: Oh, that's interesting. Okay. So what years And
• 40:29
  Speaker 9: and then, black black BlackBerry owns QNX now. That I'll I'll take, take it offline here.
• 40:35
  Speaker 1: Yeah. So it and it's I mean, QNX had kind of a funky history that they were independent for a long time, and the owners and the the the kind of co inventors of Kinix, Dan Dodge and Garbelle, were are terrific folks. But they then it went to Blackberry. It went to Harmon. I think it went to Harmon, I think, after Blackberry, before Blackberry.
• 40:59
  It was I think it was before Blackberry. Right? So
• 41:02
  Speaker 6: It's before Blackberry because it's at Blackberry now.
• 41:05
  Speaker 1: And, so the the, and I'd be curious to know kinda when your un unsigned issue was. I think the other thing that that that happened to QNX is kinda interesting is that that hearkens back to discussion last time. They wrote all the POSIX utilities. They decided that they didn't like the price. There were folks that were selling POSIX utilities.
• 41:25
  And this is, like, before like, right before the GNU utilities are really viable. So this is, like, 1990 1990, maybe. 19 89, 19 90, 1991. And, Tom, I mean, I know this is, like, bullseye for you, so maybe you can you can expand on this. But they ended up with not wanting to go from, like, what Mentat or I there were some folks that had POSIX Utilities that they could buy.
• 41:51
  But, Dan, if I recall correctly, Dan puked the price and decided, screw it. We're gonna rewrite it. And they wrote everything. So they wrote their own awk at q nix, which I think is right?
• 42:05
  Speaker 5: Yeah. I I I
• 42:08
  Speaker 2: That whole lies, mate.
• 42:09
  Speaker 5: I never knew much about qnx, but I've never heard any anyone say anything bad about it.
• 42:14
  Speaker 1: So kiwetel was very endearing in a lot of ways. And they so they have their own de novo implementation of Oc and said and what were some of these so as a result, like, some of the engineers there, like Steven McPolin, I know, would and, Peter Van Der Vein, they would have I mean, in terms of, like, trivia masters on the on the the Unix utilities because they didn't plan them all from scratch.
• 42:39
  Speaker 5: How about nrof, t rof?
• 42:41
  Speaker 1: No. Absolutely. I think that they did the whole they did everything required for POSIX. So they wanted what was then POSIX dot 4 real time compliance. And so that's what they had to go implement.
• 42:56
  And,
• 42:59
  Speaker 2: POCA That
• 43:00
  Speaker 6: means they wrote their own vibe.
• 43:02
  Speaker 1: I funny you should say that. I was just gonna say that the vibe VI divide was first of all, I was, like, I was an undergraduate. I was interning there. I kinda used e max, I guess. And I got there, and I'm like, like, where's e max?
• 43:17
  And I was like, just use vi. I'm like, I don't even know what that is, but I'm gonna okay. So I realized, like, days later as I was trying to compile eMacs, I'm like, I think they meant vi when they said vi. I is that a Canadian thing? I I don't know if that's a I did come away with so many Canadianisms.
• 43:35
  I you know, I would say process and resources, and I was a big fan of the CFL. I I actually loved Canada. But the I'm not sure if Vy is a can Vy versus Vy is a Canadian, but you're not. But, anyway
• 43:48
  Speaker 6: I mean, I've always said Vy even, you know, in, as a kid, and I'm an American. I I've never I've never, like, spent any significant time in Canada other than to go to Niagara Falls. I've never heard anything other than Via.
• 44:00
  Speaker 10: Guys are all wrong. It's v I.
• 44:02
  Speaker 2: Right. It's only there. It's just spelled vi.
• 44:04
  Speaker 5: Yeah. It's definitely vi. Yeah. From Berkeley.
• 44:08
  Speaker 6: Oh, I know it is VI, but I've never heard anyone actually say it.
• 44:11
  Speaker 1: It show I right now?
• 44:12
  Speaker 10: Use an actual UNIX trivia question.
• 44:14
  Speaker 6: As in right now. As in right now. This is the first time I've ever heard anyone call it the eyes.
• 44:19
  Speaker 5: Maybe maybe it's a generational thing.
• 44:22
  Speaker 10: Wow. Alright. Here here here's the true UNIX trivia question. How do you pronounce the name of the standard text editor?
• 44:30
  Speaker 6: E d?
• 44:31
  Speaker 5: E d. Yeah.
• 44:31
  Speaker 2: That is correct. It is e d.
• 44:33
  Speaker 1: It is Tom, what do you say? Yeah.
• 44:35
  Speaker 6: You say that one. What you're I mean,
• 44:37
  Speaker 1: I think I say Ed. I say ed and v I. I say
• 44:41
  Speaker 6: ed I say ed and v I as well. So
• 44:43
  Speaker 2: you Budway.
• 44:44
  Speaker 6: But I know that the actual standard way to say it is both e b and vi. I've always known that. But I've never said it that way because I've never heard anyone say it.
• 44:51
  Speaker 1: Having your vi moment, I'm having that with Ed, which I think I've always called Ed. Adam, what did you call Ed?
• 44:56
  Speaker 2: You know, I'm I call it Ed, but I think I might have learned that from you.
• 44:59
  Speaker 1: No. I think you definitely learned it from me. I I'm so sorry. I've obviously, like, I I
• 45:03
  Speaker 2: I I Well, unfortunately, it doesn't come up that much.
• 45:05
  Speaker 5: Off what their ends.
• 45:07
  Speaker 6: Thank god.
• 45:08
  Speaker 5: But I
• 45:08
  Speaker 2: I just like how Brian tried to totally downplay being an Emax user and was like Oh, no.
• 45:14
  Speaker 6: Emax represent. I was gonna say that. Emax for the win.
• 45:18
  Speaker 1: I I I view Emax as a as a youthful indiscretion, Dan. I I I I you know, I actually, honestly, it was very helpful to learn even hand on heart. The reason I became a VI user, effectively, after that summer is because I could know that any system I would be on would have it, and I wouldn't have to compile it. And that's also the reason that I ended up learning what I used to call ed up until several minutes ago, but I now know that it'd be called ed. Do we do we call it s e d for the stream editor, out of curiosity, Dan?
• 45:49
  Speaker 2: No. Not no. That's that's all.
• 45:50
  Speaker 1: Yes. Oh my god. All of that.
• 45:52
  Speaker 2: So sad. Oh my god.
• 45:54
  Speaker 6: Is it no. No. No.
• 45:57
  Speaker 8: I'm sorry.
• 45:57
  Speaker 1: Neil, you do not call it s e d. You call it s e d and a w k?
• 46:03
  Speaker 6: I call it zed and r.
• 46:04
  Speaker 2: That's right. You are correct.
• 46:06
  Speaker 6: You are correct.
• 46:08
  Speaker 2: I did. But however
• 46:10
  Speaker 1: Oh, great. Unix decider. Who is correct among us?
• 46:14
  Speaker 2: The the the ED editor is, the, follow on from QED.
• 46:20
  Speaker 1: It is. Yes. So this that helps. Okay.
• 46:26
  Speaker 2: If that helps anyone remember how to how to pronounce.
• 46:29
  Speaker 1: Okay. What?
• 46:31
  Speaker 2: Okay. I get it. I get it. I've heard you. Okay?
• 46:33
  Speaker 1: Is this an intervention? Adam, did you stage this? Are you are you
• 46:37
  Speaker 2: in in better I've got a banner behind me. Yes. Yes.
• 46:39
  Speaker 1: That's right. Adam learned weeks ago that I had abused him as a
• 46:43
  Speaker 2: young engineer and had Oh, teach me to call it
• 46:48
  Speaker 1: ads. Ed. I will show
• 46:50
  Speaker 2: this guy.
• 46:50
  Speaker 10: 25 year joke in the making.
• 46:53
  Speaker 1: That's right. That's right. He said, you yeah. Do you
• 46:55
  Speaker 2: know why you're at Toast Hopper?
• 46:56
  Speaker 6: Really long. Because Dan told
• 46:58
  Speaker 10: you to
• 46:58
  Speaker 1: be Toast Hopper. Do you know why Dan told you? Because I told him. It's like you were the puppet master.
• 47:03
  Speaker 2: That's right.
• 47:03
  Speaker 1: All for this moment. Kobayashi.
• 47:05
  Speaker 2: Right. There we go.
• 47:07
  Speaker 6: Please tell me you guys at least call PS PS because otherwise, I don't know what to do
• 47:11
  Speaker 1: under y'all. We do call I I do call PS. I I guess I don't have, like, a real rubric for what I say as words and what I don't. I mean, clearly, I mean, in the, like, our communities always find a way to divide themselves department. I guess this is like a kubectl versus kubectl issue for Kubernetes.
• 47:27
  I've always been
• 47:28
  Speaker 6: So I originally called it kubectl until I heard Kelsey call it kubectl. And so I was like, alright. If that guy calls it kubectl, I'll call it that too. Now everybody at work is mad at me for calling
• 47:38
  Speaker 1: it kubectl. And then what is the, Dan, what is the directory that contains the password file in UNIX? Oh, great. Decider of UNIX. How do you pronounce that?
• 47:51
  The directory that contains the password file.
• 47:54
  Speaker 2: Oops. Sorry. I was at Etsy.
• 47:57
  Speaker 1: Etsy. Okay. That is Etsy, though.
• 47:59
  Speaker 2: But but yeah.
• 48:00
  Speaker 6: I've called it Etsy.
• 48:01
  Speaker 5: Is that in the same time? It was etcetera.
• 48:05
  Speaker 1: It was ex
• 48:06
  Speaker 6: Well, it was always etcetera.
• 48:07
  Speaker 5: That's how they pronounce etcetera.
• 48:09
  Speaker 1: It was pronounced etcetera password.
• 48:14
  Speaker 6: Yep. Yeah. Why wouldn't it be? Because it was the etcetera files. It was the stuff
• 48:17
  Speaker 1: that didn't fit anywhere else. But I just amazed that that was actually, like, the way you would that one way one would say it. I mean, I've always
• 48:26
  Speaker 6: Well, it's why we still we still call USR user, like, for the same reason.
• 48:31
  Speaker 10: Same reason. That's where user home directories were initially.
• 48:36
  Speaker 6: Well, I know that, but I'm saying that the fact that it's written as USR, we still call it user because we know that what it was supposed to be for.
• 48:44
  Speaker 10: I I see. That c. Gotcha.
• 48:48
  Speaker 6: Yeah. Look. Obviously, yeah. It's where the home directory is.
• 48:51
  Speaker 1: I mean, clearly, there's gonna be no consistent rubric that's gonna be understood as actually, I and even qNex versus qNX, I I feel that I've heard I mean, I said QNX, but I felt like I heard I only called it QNX after having worked there. I called it q and x before going there. And I yeah. I'm sorry. Pappaka Tepepato.
• 49:11
  How how do I pronounce your name?
• 49:13
  Speaker 9: Just call me Pappaka.
• 49:14
  Speaker 1: Okay. There you go. Pokka. Pokka is easier. So Pokka, how did you pronounce it, when you were using the operating system?
• 49:21
  QNIX. Okay. You call it QNIX. Yeah. Yeah.
• 49:22
  Yeah. So and QNIX, the origin of that is is quick Unix, by the way. So QNIX always felt like it made it made sense.
• 49:29
  Speaker 2: Hey, Brian Brian, pronunciation quiz for you.
• 49:31
  Speaker 6: I heard it called Queenix.
• 49:32
  Speaker 2: Brian, pronunciation quiz for you. The the Octothorpe character. What did you pronounce that as and what do you pronounce that as? Okay.
• 49:40
  Speaker 1: That was a Are are my children putting you up to this? Is this is this the the number one fan that's putting up to this? Because I you tell him I will find him, and I will bust him. Okay. So the the what Adam is to get me to say and I will just like so
• 49:57
  Speaker 2: I have No. No. I my I've changed over time. I've I've succumb to the to the children.
• 50:01
  Speaker 1: The children. Well, so the I call the octothorpe a pound, a pound sign. And the the children obviously don't recognize. And I when I say children, I don't mean that pejoratively in this case. I actually mean it literally.
• 50:15
  Oh, literally. Oh, and pejoratively with my own children. But the the the the the Gen Zers call that hashtag. So, like, you know, the password to get into the garage is, you know, hashtag 28 or whatever. The and I'm like, hashtag?
• 50:30
  Don't or hash. And then I realized that, like, I have started to say hashtag. So
• 50:36
  Speaker 6: So have always called it pound sign until, I got my first job working at an embedded systems company, Camtien, where I was introduced to calling it hash by a UNIX an old UNIX dude who also told me what UNIX people like to call some of the other symbols. Like, for example, the symbol that you can do when you press shift 1. What do you call that, Brian?
• 51:01
  Speaker 5: Bang. Bang. Bang.
• 51:05
  Speaker 6: Bang. Exactly. And what about shift 8?
• 51:06
  Speaker 1: Hold on. I gotta go to my keyboard. What is shift 8? I didn't even know what I typed anymore.
• 51:09
  Speaker 2: Splatter ampersandwitz. Blast art.
• 51:13
  Speaker 1: Some people call that splat. That is but I some people. That's not me. I don't know. Like, I've heard of that.
• 51:20
  I didn't do that. I wasn't there when that happened.
• 51:23
  Speaker 6: I don't know. I it sounds like you're trying to disavow yourself. Like, you're own
• 51:27
  Speaker 1: I don't know. Something I read online. I've met like, no. I have never I've always called that STAR. Tom, what did you call that?
• 51:35
  Speaker 5: Usually STAR, but splat if I'm feeling like a computer scientist.
• 51:40
  Speaker 2: I also disambiguate
• 51:42
  Speaker 6: the most like,
• 51:43
  Speaker 2: maybe whistling the tone that it would be a TMS test? Would you mind? Exactly. Thank you, Jerry. Exactly.
• 51:49
  Thank you for, that
• 51:50
  Speaker 1: that this is how I I plan to spend my final days on Earth is at the whistling various tones. I feel like I'll
• 51:59
  Speaker 6: Yeah. You need to do that.
• 52:00
  Speaker 1: A lot of these other, like okay. At sign, clearly. I feel like, the what do we say for shift 6? I don't know if I've ever used that in conversation. Carrot or hat?
• 52:16
  Speaker 6: Oh, shift 6. Carrot.
• 52:17
  Speaker 1: Or hat. I heard so Carrot is shift 6. And did you say hat? What do I I don't even know what I'm saying. I am like, I'm so disoriented right now.
• 52:24
  Speaker 2: Did you know that that used to
• 52:25
  Speaker 10: be a valid character for specifying a pipe in the shell?
• 52:30
  Speaker 2: I you know, I think I have
• 52:32
  Speaker 5: I think it still is.
• 52:34
  Speaker 2: And Born Shell is still
• 52:35
  Speaker 6: It still is. It's just not a lot of things handle it well, but it's still there.
• 52:39
  Speaker 1: Are you serious? No. Sure.
• 52:42
  Speaker 2: Well, it depends on the shell, but it's currently still on the born cell.
• 52:46
  Speaker 6: Right. Yeah. If you go all the way back and you're in, like, POSIX born shell mode, it works. But everything else doesn't handle it.
• 52:55
  Speaker 1: Yeah. My shell is not handling it now. I I mean, I it was just a prank to see if I would type that, by the way. Is that am I being rude by now?
• 53:01
  Speaker 2: If if you're using something modern, it probably won't work.
• 53:04
  Speaker 6: So No. It's legit.
• 53:05
  Speaker 10: T show corrected that for doing substitution for the last command. You could do carrot, foo, carrot, bar to replace foo with bar. So it won't work on, like, c shell derived shells and and bash and support adopt that syntax by default. But if you find yourself an old UNIX system or, you know, run a modern shell and some sort of Uber compat mode, it'll probably treat that like a pipe character.
• 53:29
  Speaker 6: Yeah. Or if you go and install, like, the old what? Is it, KSH or whatever? Like, the or the old one from AT and T, which I think is now available and built in a lot of distributions. If you install that, in POS XLE mode, it will actually do that as well.
• 53:45
  Speaker 5: So if you if you really want fun with character names, you should take a read of the old Intercal manual.
• 53:51
  Speaker 1: The and Intercal is that is Intercal deliberately designed to be unusable?
• 53:58
  Speaker 5: Oh, Oh, it's designed to be hilarious. The the the the manual the math the manual was written well before the language.
• 54:06
  Speaker 6: Oh, interesting. Well, that scares me.
• 54:09
  Speaker 10: The first joke language. Right? Or at least Right. Among the first joke languages. It was designed, literally as a joke.
• 54:14
  I mean, not like, oh my god. That's a joke. Like, COBOL is a joke. I mean, it was it was meant to be funny.
• 54:20
  Speaker 5: Right. And it it one of my brothers is a coauthor.
• 54:27
  Speaker 1: And I what do you post? I think that I think, Tom, that applies to many things. I feel that they
• 54:32
  Speaker 2: That's true.
• 54:33
  Speaker 1: That's true. I am, Matt, I I am trying to approve you. I whenever I when I go over, go to a quick
• 54:39
  Speaker 2: I'm gonna, yeah, we have to kick someone off. So, apologies for the person I'm about to kick off.
• 54:44
  Speaker 1: There you go. Yeah. That's why right. It's not giving me an error message before. Yeah.
• 54:49
  Speaker 4: You can kick off Lambe Lancie. So
• 54:53
  Speaker 5: the the other fun I've had with characters recently is is using, the Anvil units that someone someone found a copy, and so you can bring it up in a 32/70 terminal emulator.
• 55:04
  Speaker 3: Can you guys hear me?
• 55:06
  Speaker 1: Yes. Hey, Matt. Sorry. What did you, Thomas?
• 55:09
  Speaker 5: And, the thing is these 3270 terminals were, and they were missing all kinds of characters that UNIX people are used to. So instead of a backslash, it's a sent sign and stuff like
• 55:23
  Speaker 4: that. Okay. This is, this is Matt Campbell. I can you guys hear me?
• 55:28
  Speaker 1: Yep. We can, Matt. Yeah.
• 55:30
  Speaker 4: Yeah. So, you know, you guys were, you guys were talking about, pronunciation of various punctuation marks earlier, and I was reminded about how so I I'm I'm, legally blind, visually impaired, and some I often use a screen reader, and I was, I was, just thinking about how the different screen readers pronounce punctuation marks. And you can tell that so one of one of the most popular screen readers, is for Windows, called their NVDA. It stands for non visual desktop access, and it's an open source screen reader written by blind tech programmers. And, of course, they wrote it largely for themselves.
• 56:20
  And as far as I know, it is the only screen reader that pronounces the shift 1 as bang
• 56:28
  Speaker 1: Oh, it's rather than an exclamation.
• 56:30
  Speaker 4: Sweet. So so, yeah, though those guys obviously wrote you know, at least when it came to that, they did what they wanted for themselves.
• 56:42
  Speaker 1: I feel that they should be considered canonical for any of these disputes. I feel we should go to that screen reader and determine what for for any dispute we have.
• 56:50
  Speaker 2: So then what do they do what
• 56:52
  Speaker 6: do they do for shift 8? Because, like, that one has, like, 3 or 4 different words for it. I'd be curious about ship 7 because I don't know what you would say it as.
• 57:05
  Speaker 4: Hang on. Let me, let me find out. Let me let me get back in front of my PC. That's
• 57:17
  Speaker 2: is
• 57:23
  Speaker 4: shift 8 is star.
• 57:25
  Speaker 2: Okay.
• 57:26
  Speaker 4: Shift 7 is and, which, of course, is ambiguous with the word and. Oh. But Oh,
• 57:32
  Speaker 1: that
• 57:35
  Speaker 4: but maybe, maybe they, maybe they figure that you would just know from context, which one it is. Like if you're reading C code, if you're reading C code, then you know that you will find ampersands more often than the word and, and the reverse, of course, if you're reading Python.
• 57:53
  Speaker 1: And, Matt, are you a programmer as well?
• 57:55
  Speaker 4: Yes. I am.
• 57:56
  Speaker 1: So you I mean, this comes up presumably
• 57:58
  Speaker 4: quite a bit for you. Programming. I I do I I have enough sight that I can read the screen up close, so I tend to do my programming that way. Got it. Okay.
• 58:10
  But, I
• 58:12
  Speaker 6: But, you know,
• 58:13
  Speaker 4: the Anyway
• 58:14
  Speaker 9: So so am I saying it right? Is it And
• 58:16
  Speaker 4: ship 6 is carrot, by the
• 58:18
  Speaker 2: way. Yeah. Sweet.
• 58:20
  Speaker 6: So the interesting thing about this is that I would have expected the ampersand symbol to be read as et or etcetera because that is that is the unambiguous way to describe it.
• 58:37
  Speaker 4: You know, maybe I should open a GitHub issue about that. It it actually does surprise you that it's not before.
• 58:44
  Speaker 1: It it surprises me that it's not ampersand.
• 58:46
  Speaker 6: Because it's a Latin.
• 58:47
  Speaker 8: It's a well,
• 58:48
  Speaker 6: because it's a because the ampersand symbol, which is also known as the and sign in English, is a ligature to refer to etcetera. So it's it's the combination of ETC Now as one other thing.
• 59:02
  Speaker 1: I'm I'm I'm I'm I'm not surprised.
• 59:04
  Speaker 5: It's Latin and e t.
• 59:07
  Speaker 1: That's because in older script
• 59:09
  Speaker 5: in older script, you see the ampersand followed by c for etcetera.
• 59:15
  Speaker 4: I now I guess it it I guess it's not too surprising that that that oh, well, I mean, the the the the the at least one of the main programmers of NVDA was blind from birth, so I guess having never actually seen an ampersand, I guess it wouldn't be surprising that he wouldn't have made that connection.
• 59:40
  Speaker 2: Hey, Matt.
• 59:40
  Speaker 1: But Oh, sorry.
• 59:41
  Speaker 2: I didn't mean to interrupt.
• 59:42
  Speaker 10: But I I'm curious if you've ever
• 59:44
  Speaker 8: Go ahead.
• 59:44
  Speaker 10: I'm I'm curious if
• 59:45
  Speaker 2: you've ever had an opportunity to use EmaxSpeak.
• 59:50
  Speaker 4: I I actually contributed to the EmaxSpeak project back in, like, 1998, 99. Oh, cool. I made, I made an RPM package for Enax speak back in the day.
• 1:00:03
  Speaker 2: Very cool. Wow.
• 1:00:05
  Speaker 1: Ask an answer.
• 1:00:08
  Speaker 4: It's been a long time since I've used it, though.
• 1:00:11
  Speaker 2: I I mean, one of the things that T. V. Raman did when he wrote that that I thought was really cool I
• 1:00:16
  Speaker 10: mean, I think he did this.
• 1:00:17
  Speaker 2: This. I might be misremembering. But he would indicate stuff like scope by a change in pitch of the voice because it was red.
• 1:00:27
  Speaker 4: And Uh-huh.
• 1:00:28
  Speaker 2: The I thought that was
• 1:00:29
  Speaker 4: Unfortunately, I never had the fancy schmancy, speech synthesis device that he had. He he he had, he he wrote EmaxSpeak primarily for a speech synthesizer called DECtalk. Yeah. Which the one guess as to which company that
• 1:00:46
  Speaker 2: came from.
• 1:00:47
  Speaker 1: Oh, man. You are, like, Dan right now is, I mean, you you made Dan very happy. I feel that. I mean, Dan, I think I I mean, I I I shouldn't think of you as a deck apologist or sympathizer, but I think both
• 1:00:57
  Speaker 2: of you
• 1:00:57
  Speaker 4: And Raman Raman actually worked for deck when he started on emacs speak, I think, in, like, 95.
• 1:01:04
  Speaker 2: Yeah. He wrote it in Brad's school, I thought. And, I mean, he probably used the DEC workstation, and I think he did, like, an internship there or something like that.
• 1:01:14
  Speaker 4: Yeah. The now he he later added support for a soft and and and DeckTalk was a a hardware device that it was either it was either a card that you could install inside your PC or a box that you could hook up to the serial port. Now, he later added he later added support for a software speech synthesizer called IBM via voice. But, the speech synthesizer that I had back at that time was called Doubletalk, and it it was much more, limited in terms of the vocal parameters that you could change. Yeah.
• 1:01:51
  Speaker 1: Matt, is there a good I mean, this is I I feel like this is such an interesting and important and and Jessamyn hit on this last time in terms of, like, this is such a life changing aspect of technology that I don't know the history of well at all. I mean, the things you're talking about are things I'm not familiar
• 1:02:06
  Speaker 2: with at all.
• 1:02:06
  Speaker 4: I was actually thinking over, get going through, like, it and and that that semi impromptu oral history of screen readers if if you
• 1:02:16
  Speaker 1: That would be That would be really neat.
• 1:02:18
  Speaker 6: That would be very neat.
• 1:02:19
  Speaker 4: At the I mean, well and and and surely incomplete because I I don't know everything about that field either.
• 1:02:27
  Speaker 1: You know what?
• 1:02:27
  Speaker 2: I kind of But you
• 1:02:28
  Speaker 1: know what?
• 1:02:29
  Speaker 4: I I kind of
• 1:02:30
  Speaker 1: so, Matt, I don't wanna put you on the spot, but I think we're because we're hour kind of here, and we do we do wanna keep these kinda bounded. What would you think about picking that up next week as kind of our topic for our space next week? Would you be would you be down for doing your doing
• 1:02:45
  Speaker 10: Sure.
• 1:02:45
  Speaker 1: I I mean, just and just in general, like, accessibility technology in the history of
• 1:02:49
  Speaker 4: that. I was I was kinda looking for my opening the whole time, and I I didn't wanna force it. But, yeah, that would be,
• 1:02:58
  Speaker 1: now we have one. Let's let's do that next week. I think that that would be super educational. I know I would learn a lot. And, again, this is a domain of of technology that is I mean, I'm sure for you, it's been life changing and I for many other people as well has been has been and I think, you know, you kinda hear about some of these technologies that are incredibly life changing, and then they don't have a big enough market, so they begin to, like, go away, which is I'm I'm sure is also
• 1:03:22
  Speaker 4: Well, and and, open I mean, accessibility for for for open source operating systems like desktop, Linux has has has been kind of just just barely hanging on. And and on the proprietary side, what we see is that Apple and Google and Microsoft now have screen readers built into their operating systems that are in, at least in some ways, just good enough. And and and, the the future of third party Windows is the one platform that the one mainstream proprietary platform that really supports third party screen readers, and the future of that is kind of well, people wonder how much longer.
• 1:04:12
  Speaker 6: I mean, yeah, bluntly, it's probably dead With with what's going on with with the future of Windows, it's
• 1:04:19
  Speaker 4: Oh, by the way, I worked on the Windows accessibility team at Microsoft
• 1:04:23
  Speaker 5: for
• 1:04:23
  Speaker 4: 3 years.
• 1:04:24
  Speaker 2: Oh, nice. Course too bad.
• 1:04:26
  Speaker 1: Oh, man. That's great. I just okay. I do this is this is like the Internet at its best. Yeah.
• 1:04:30
  Speaker 4: I'd like to Next week.
• 1:04:31
  Speaker 1: Right now, so let's talk next week. I am convinced that if if Dan hears Emax and Deck in the same sentence, he has to sit down. I mean, Dan, correct me if I'm wrong. I just feel that, like, that's that's where where Dan becomes overcome with emotion when he hears both of those 2 great loves in the same sentence.
• 1:04:47
  Speaker 2: I'm glad you think that I have this love of Emacs. I mean, I it's like I find it useful once. Yeah. Emax is awesome.
• 1:04:54
  Speaker 1: I feel you, like, beaten me with an interest of my life with it several times. Who do you have?
• 1:04:58
  Speaker 4: Okay. I I I I I have no idea who Dan is. I I I I I don't know most of you guys, but, Emax and Deck did both come from Massachusetts. Right?
• 1:05:11
  Speaker 1: And Yes.
• 1:05:12
  Speaker 2: And they're both
• 1:05:13
  Speaker 1: on Dan Dan is a Red Sox fan along with Oh, oh,
• 1:05:16
  Speaker 2: that's that's it. Yeah. Off. That's I I I quit driving. I'm gonna get a new job.
• 1:05:21
  That's That's exactly.
• 1:05:24
  Speaker 1: All right. On on that note.
• 1:05:26
  Speaker 3: And and one.
• 1:05:27
  Speaker 1: Yeah.
• 1:05:27
  Speaker 3: One last thing. I don't necessarily know many of you either, but from Bell Labs in New Jersey, most of us support you on it, Brian.
• 1:05:35
  Speaker 2: Okay. Very good. Hey. Look at that.
• 1:05:38
  Speaker 1: Alright. We'll pick that up next time, too. I wanna I'm I'm gonna I may call in my Ed my Ed posse is gonna that we'll we'll do, but, Matt, if you wouldn't mind kicking this off with an oral history of accessibility technology, and clearly, you've been at the epicenter of it, at least at at my Well,
• 1:05:54
  Speaker 4: I I I was kind of a latecomer to the industry. I started writing my own Windows screen reader in 2004. But, yeah, I'll be happy to share what I know.
• 1:06:06
  Speaker 1: Awesome. That'll be great. Thank you very much, everyone, and thank you, Cole, especially for everything you've done for the notes. We really, really appreciate it.
• 1:06:15
  Speaker 2: It. Yeah. Thanks, Cole. Thanks, everyone. Alright.
• 1:06:17
  And thanks, Laura too, for everything
• 1:06:19
  Speaker 1: on Hubris. Thanks, everyone. See you next time.