Podcasts about Solaris

This show has been flagged as Clean by the host. This is the first column in a series dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. This month's column was inspired by an article on the Linux Journal web site 1 describing a custom-built script that would contain a binary tar archive and, when run, would extract the contents onto the user's system. Upon reading this, memories immediately came rushing back of the days of Usenet, before MIME-encoded e-mail made sending file attachments standard 2 , and where we walked ten miles each way to school (uphill both ways!) in three feet of snow. Yes, at that time, you had to put everything into the body of your message. But what if you needed to send a bunch of files to someone? There was tar , but the format differed between systems, and e-mail and Usenet could only reliably handle 7-bit plain-text ASCII anyhow. You could send separate e-mail messages (but what if one goes missing?) or put "CUT HERE" lines to designate where one file ends and another one begins (tedious for the recipient). The solution was a shell archive created by the shar program. This wraps all your files in a neat shell script that the recipient can just run and have the files magically pop out. All he needs is the Bourne shell and the sed utility, both standard on any UNIX-like system. Suppose you had a directory named "foo" containing the files bar.c, bar.h, and bar.txt, and wanted to send these. All you'd need to do is run the following command, and your archive is on its way. $ shar foo foo/* | mail -s "Foo 1.0 files" bob@example.com When the recipient runs the resulting script, it will create the foo directory and copy out the files onto his system. You can also pick and choose files; if you wanted to leave out bar.txt, you could do shar foo foo/bar.c foo/bar.h or, more simply, shar foo foo/bar.? . Different versions of shar have varying capabilities. For example, the BSD 3 and OS X 4 editions can only really manage plain-text files. If you had a binary object file bar.o, it'd likely get mangled somewhere along the way if you tried to include it in an archive. They also require, as in the examples above, that you name a directory before naming any files inside it (the typical way is to let the find command do the work for you; it produces a list in the right order). The GNU implementation is more flexible and can take just a directory name, automatically including everything underneath. It can also handle binary files by using uuencode—a method for encoding data as ASCII that predated the current base64 MIME standard. GNU shar rather nicely auto-detects whether the input file is text or binary and acts accordingly, and can even compress files if asked. However, unpacking encoded or compressed files from such an archive requires the recipient to have the corresponding decode/uncompress utility, and the documentation is littered with (now somewhat anachronistic) warnings about this 5 . Looking at other UNIX systems, the HP-UX version 6 also can uuencode binary files, and as a special bonus adds logic to the script that will compile and use a simple uudecode tool if the recipient doesn't already have one. It will even handle device files and put the corresponding mknod commands into the script, probably making it the most full-featured implementation of all. IBM's AIX doesn't appear to come with shar . Neither do SunOS and Solaris, which seems quite odd as original development of the program is credited to James Gosling 5 ! And so we bid farewell to shar . Next time you're considering rolling your own script for a particular purpose, consider whether such a tool might already exist, just waiting on your system for you to use it. References: Add a Binary Payload to your Shell Scripts https://www.linuxjournal.com/content/add-binary-payload-your-shell-scripts MIME (Multipurpose Internet Mail Extensions) Part One https://datatracker.ietf.org/doc/html/rfc1521 BSD shar manual page https://man.freebsd.org/cgi/man.cgi?query=shar&sektion=1&manpath=4.4BSD+Lite2 macOS 26.2 shar manual page https://man.freebsd.org/cgi/man.cgi?query=shar&sektion=1&manpath=macOS+26.2 GNU shar utilities manual https://www.gnu.org/software/sharutils/manual/sharutils.html HP-UX Reference (11i v3 07/02) - 1 User Commands N-Z (vol 2) https://support.hpe.com/hpesc/public/docDisplay?docId=c01922474&docLocale=en_US This article was originally written in May 2010. The podcast episode was recorded in February 2026. Provide feedback on this episode.

Expand The Room, every Friday at 22.00, Athens Free Radio 98.1 FM & www.athensfreeradio.com 1. Ivan Fernandez (AR) - Colors (Original Mix) 2. Bautista Gaya - Frozen Senses (Original Mix) 3. URIGEAR = Eden (Ewan Rill Remix) 4. Miro - Paradise (Quivver Extended Remix) 5. Nick Reverse - Maya (Ornery Extended Remix) 6. Rivvo - Celestial Drift (Matt Oliver, Teclas Remix) 7. Brann - Morning After (Gowzer Remix) 8. Solaris, BRUNN - Between Feelings (Original Mix) 9. Tam Mi - Virtual Reality (Original Mix) 2nd Hour 10. Blended Voices - Sonar (Original Mix) 11. Luciano Lozz, Mäthzz - Plasma (Original Mix) 12. Gabo Martin - Drifted Realms (Ellroy Remix) 13. Fijoni - Deep State (Original Mix) 14. Plafnik - Entering Nazareth (Original Mix) 15. Hobin Rude - Seraph (Monojoke Pres. Amaare Remix) 16. Gai Barone - Clutchy (Original Mix) 17. ICoen - The Morning Road (Original Mix) 18. Martin Lune - Patagonia (Original Mix) 19. Bjorn Fogelberg - Conscious Technology (John Keding Remix)

Bryan Cantrill is the co-founder and CTO of Oxide Computer Company. We discuss why the biggest cloud providers don't use off the shelf hardware, how scaling data centers at samsung's scale exposed problems with hard drive firmware, how the values of NodeJS are in conflict with robust systems, choosing Rust, and the benefits of Oxide Computer's rack scale approach. This is an extended version of an interview posted on Software Engineering Radio. Related links Oxide Computer Oxide and Friends Illumos Platform as a Reflection of Values RFD 26 bhyve CockroachDB Heterogeneous Computing with Raja Koduri Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today I am talking to Bryan Cantrill. He's the co-founder and CTO of Oxide computer company, and he was previously the CTO of Joyent and he also co-authored the DTrace Tracing framework while he was at Sun Microsystems. [00:00:14] Jeremy: Bryan, welcome to Software Engineering radio. [00:00:17] Bryan: Uh, awesome. Thanks for having me. It's great to be here. [00:00:20] Jeremy: You're the CTO of a company that makes computers. But I think before we get into that, a lot of people who built software, now that the actual computer is abstracted away, they're using AWS or they're using some kind of cloud service. So I thought we could start by talking about, data centers. [00:00:41] Jeremy: 'cause you were. Previously working at Joyent, and I believe you got bought by Samsung and you've previously talked about how you had to figure out, how do I run things at Samsung's scale. So how, how, how was your experience with that? What, what were the challenges there? Samsung scale and migrating off the cloud [00:01:01] Bryan: Yeah, I mean, so at Joyent, and so Joyent was a cloud computing pioneer. Uh, we competed with the likes of AWS and then later GCP and Azure. Uh, and we, I mean, we were operating at a scale, right? We had a bunch of machines, a bunch of dcs, but ultimately we know we were a VC backed company and, you know, a small company by the standards of, certainly by Samsung standards. [00:01:25] Bryan: And so when, when Samsung bought the company, I mean, the reason by the way that Samsung bought Joyent is Samsung's. Cloud Bill was, uh, let's just say it was extremely large. They were spending an enormous amount of money every year on, on the public cloud. And they realized that in order to secure their fate economically, they had to be running on their own infrastructure. [00:01:51] Bryan: It did not make sense. And there's not, was not really a product that Samsung could go buy that would give them that on-prem cloud. Uh, I mean in that, in that regard, like the state of the market was really no different. And so they went looking for a company, uh, and bought, bought Joyent. And when we were on the inside of Samsung. [00:02:11] Bryan: That we learned about Samsung scale. And Samsung loves to talk about Samsung scale. And I gotta tell you, it is more than just chest thumping. Like Samsung Scale really is, I mean, just the, the sheer, the number of devices, the number of customers, just this absolute size. they really wanted to take us out to, to levels of scale, certainly that we had not seen. [00:02:31] Bryan: The reason for buying Joyent was to be able to stand up on their own infrastructure so that we were gonna go buy, we did go buy a bunch of hardware. Problems with server hardware at scale [00:02:40] Bryan: And I remember just thinking, God, I hope Dell is somehow magically better. I hope the problems that we have seen in the small, we just. You know, I just remember hoping and hope is hope. It was of course, a terrible strategy and it was a terrible strategy here too. Uh, and the we that the problems that we saw at the large were, and when you scale out the problems that you see kind of once or twice, you now see all the time and they become absolutely debilitating. [00:03:12] Bryan: And we saw a whole series of really debilitating problems. I mean, many ways, like comically debilitating, uh, in terms of, of showing just how bad the state-of-the-art. Yes. And we had, I mean, it should be said, we had great software and great software expertise, um, and we were controlling our own system software. [00:03:35] Bryan: But even controlling your own system software, your own host OS, your own control plane, which is what we had at Joyent, ultimately, you're pretty limited. You go, I mean, you got the problems that you can obviously solve, the ones that are in your own software, but the problems that are beneath you, the, the problems that are in the hardware platform, the problems that are in the componentry beneath you become the problems that are in the firmware. IO latency due to hard drive firmware [00:04:00] Bryan: Those problems become unresolvable and they are deeply, deeply frustrating. Um, and we just saw a bunch of 'em again, they were. Comical in retrospect, and I'll give you like a, a couple of concrete examples just to give, give you an idea of what kinda what you're looking at. one of the, our data centers had really pathological IO latency. [00:04:23] Bryan: we had a very, uh, database heavy workload. And this was kind of right at the period where you were still deploying on rotating media on hard drives. So this is like, so. An all flash buy did not make economic sense when we did this in, in 2016. This probably, it'd be interesting to know like when was the, the kind of the last time that that actual hard drives made sense? [00:04:50] Bryan: 'cause I feel this was close to it. So we had a, a bunch of, of a pathological IO problems, but we had one data center in which the outliers were actually quite a bit worse and there was so much going on in that system. It took us a long time to figure out like why. And because when, when you, when you're io when you're seeing worse io I mean you're naturally, you wanna understand like what's the workload doing? [00:05:14] Bryan: You're trying to take a first principles approach. What's the workload doing? So this is a very intensive database workload to support the, the object storage system that we had built called Manta. And that the, the metadata tier was stored and uh, was we were using Postgres for that. And that was just getting absolutely slaughtered. [00:05:34] Bryan: Um, and ultimately very IO bound with these kind of pathological IO latencies. Uh, and as we, you know, trying to like peel away the layers to figure out what was going on. And I finally had this thing. So it's like, okay, we are seeing at the, at the device layer, at the at, at the disc layer, we are seeing pathological outliers in this data center that we're not seeing anywhere else. [00:06:00] Bryan: And that does not make any sense. And the thought occurred to me. I'm like, well, maybe we are. Do we have like different. Different rev of firmware on our HGST drives, HGST. Now part of WD Western Digital were the drives that we had everywhere. And, um, so maybe we had a different, maybe I had a firmware bug. [00:06:20] Bryan: I, this would not be the first time in my life at all that I would have a drive firmware issue. Uh, and I went to go pull the firmware, rev, and I'm like, Toshiba makes hard drives? So we had, I mean. I had no idea that Toshiba even made hard drives, let alone that they were our, they were in our data center. [00:06:38] Bryan: I'm like, what is this? And as it turns out, and this is, you know, part of the, the challenge when you don't have an integrated system, which not to pick on them, but Dell doesn't, and what Dell would routinely put just sub make substitutes, and they make substitutes that they, you know, it's kind of like you're going to like, I don't know, Instacart or whatever, and they're out of the thing that you want. [00:07:03] Bryan: So, you know, you're, someone makes a substitute and like sometimes that's okay, but it's really not okay in a data center. And you really want to develop and validate a, an end-to-end integrated system. And in this case, like Toshiba doesn't, I mean, Toshiba does make hard drives, but they are a, or the data they did, uh, they basically were, uh, not competitive and they were not competitive in part for the reasons that we were discovering. [00:07:29] Bryan: They had really serious firmware issues. So the, these were drives that would just simply stop a, a stop acknowledging any reads from the order of 2,700 milliseconds. Long time, 2.7 seconds. Um. And that was a, it was a drive firmware issue, but it was highlighted like a much deeper issue, which was the simple lack of control that we had over our own destiny. [00:07:53] Bryan: Um, and it's an, it's, it's an example among many where Dell is making a decision. That lowers the cost of what they are providing you marginally, but it is then giving you a system that they shouldn't have any confidence in because it's not one that they've actually designed and they leave it to the customer, the end user, to make these discoveries. [00:08:18] Bryan: And these things happen up and down the stack. And for every, for whether it's, and, and not just to pick on Dell because it's, it's true for HPE, it's true for super micro, uh, it's true for your switch vendors. It's, it's true for storage vendors where the, the, the, the one that is left actually integrating these things and trying to make the the whole thing work is the end user sitting in their data center. AWS / Google are not buying off the shelf hardware but you can't use it [00:08:42] Bryan: There's not a product that they can buy that gives them elastic infrastructure, a cloud in their own DC The, the product that you buy is the public cloud. Like when you go in the public cloud, you don't worry about the stuff because that it's, it's AWS's issue or it's GCP's issue. And they are the ones that get this to ground. [00:09:02] Bryan: And they, and this was kind of, you know, the eye-opening moment. Not a surprise. Uh, they are not Dell customers. They're not HPE customers. They're not super micro customers. They have designed their own machines. And to varying degrees, depending on which one you're looking at. But they've taken the clean sheet of paper and the frustration that we had kind of at Joyent and beginning to wonder and then Samsung and kind of wondering what was next, uh, is that, that what they built was not available for purchase in the data center. [00:09:35] Bryan: You could only rent it in the public cloud. And our big belief is that public cloud computing is a really important revolution in infrastructure. Doesn't feel like a different, a deep thought, but cloud computing is a really important revolution. It shouldn't only be available to rent. You should be able to actually buy it. [00:09:53] Bryan: And there are a bunch of reasons for doing that. Uh, one in the one we we saw at Samsung is economics, which I think is still the dominant reason where it just does not make sense to rent all of your compute in perpetuity. But there are other reasons too. There's security, there's risk management, there's latency. [00:10:07] Bryan: There are a bunch of reasons why one might wanna to own one's own infrastructure. But, uh, that was very much the, the, so the, the genesis for oxide was coming out of this very painful experience and a painful experience that, because, I mean, a long answer to your question about like what was it like to be at Samsung scale? [00:10:27] Bryan: Those are the kinds of things that we, I mean, in our other data centers, we didn't have Toshiba drives. We only had the HDSC drives, but it's only when you get to this larger scale that you begin to see some of these pathologies. But these pathologies then are really debilitating in terms of those who are trying to develop a service on top of them. [00:10:45] Bryan: So it was, it was very educational in, in that regard. And you're very grateful for the experience at Samsung in terms of opening our eyes to the challenge of running at that kind of scale. [00:10:57] Jeremy: Yeah, because I, I think as software engineers, a lot of times we, we treat the hardware as a, as a given where, [00:11:08] Bryan: Yeah. [00:11:08] Bryan: Yeah. There's software in chard drives [00:11:09] Jeremy: It sounds like in, in this case, I mean, maybe the issue is not so much that. Dell or HP as a company doesn't own every single piece that they're providing you, but rather the fact that they're swapping pieces in and out without advertising them, and then when it becomes a problem, they're not necessarily willing to, to deal with the, the consequences of that. [00:11:34] Bryan: They just don't know. I mean, I think they just genuinely don't know. I mean, I think that they, it's not like they're making a deliberate decision to kind of ship garbage. It's just that they are making, I mean, I think it's exactly what you said about like, not thinking about the hardware. It's like, what's a hard drive? [00:11:47] Bryan: Like what's it, I mean, it's a hard drive. It's got the same specs as this other hard drive and Intel. You know, it's a little bit cheaper, so why not? It's like, well, like there's some reasons why not, and one of the reasons why not is like, uh, even a hard drive, whether it's rotating media or, or flash, like that's not just hardware. [00:12:05] Bryan: There's software in there. And that the software's like not the same. I mean, there are components where it's like, there's actually, whether, you know, if, if you're looking at like a resistor or a capacitor or something like this Yeah. If you've got two, two parts that are within the same tolerance. Yeah. [00:12:19] Bryan: Like sure. Maybe, although even the EEs I think would be, would be, uh, objecting that a little bit. But the, the, the more complicated you get, and certainly once you get to the, the, the, the kind of the hardware that we think of like a, a, a microprocessor, a a network interface card, a a, a hard driver, an NVME drive. [00:12:38] Bryan: Those things are super complicated and there's a whole bunch of software inside of those things, the firmware, and that's the stuff that, that you can't, I mean, you say that software engineers don't think about that. It's like you, no one can really think about that because it's proprietary that's kinda welded shut and you've got this abstraction into it. [00:12:55] Bryan: But the, the way that thing operates is very core to how the thing in aggregate will behave. And I think that you, the, the kind of, the, the fundamental difference between Oxide's approach and the approach that you get at a Dell HP Supermicro, wherever, is really thinking holistically in terms of hardware and software together in a system that, that ultimately delivers cloud computing to a user. [00:13:22] Bryan: And there's a lot of software at many, many, many, many different layers. And it's very important to think about, about that software and that hardware holistically as a single system. [00:13:34] Jeremy: And during that time at Joyent, when you experienced some of these issues, was it more of a case of you didn't have enough servers experiencing this? So if it would happen, you might say like, well, this one's not working, so maybe we'll just replace the hardware. What, what was the thought process when you were working at that smaller scale and, and how did these issues affect you? UEFI / Baseboard Management Controller [00:13:58] Bryan: Yeah, at the smaller scale, you, uh, you see fewer of them, right? You just see it's like, okay, we, you know, what you might see is like, that's weird. We kinda saw this in one machine versus seeing it in a hundred or a thousand or 10,000. Um, so you just, you just see them, uh, less frequently as a result, they are less debilitating. [00:14:16] Bryan: Um, I, I think that it's, when you go to that larger scale, those things that become, that were unusual now become routine and they become debilitating. Um, so it, it really is in many regards a function of scale. Uh, and then I think it was also, you know, it was a little bit dispiriting that kind of the substrate we were building on really had not improved. [00:14:39] Bryan: Um, and if you look at, you know, the, if you buy a computer server, buy an x86 server. There is a very low layer of firmware, the BIOS, the basic input output system, the UEFI BIOS, and this is like an abstraction layer that has, has existed since the eighties and hasn't really meaningfully improved. Um, the, the kind of the transition to UEFI happened with, I mean, I, I ironically with Itanium, um, you know, two decades ago. [00:15:08] Bryan: but beyond that, like this low layer, this lowest layer of platform enablement software is really only impeding the operability of the system. Um, you look at the baseboard management controller, which is the kind of the computer within the computer, there is a, uh, there is an element in the machine that needs to handle environmentals, that needs to handle, uh, operate the fans and so on. [00:15:31] Bryan: Uh, and that traditionally has this, the space board management controller, and that architecturally just hasn't improved in the last two decades. And, you know, that's, it's a proprietary piece of silicon. Generally from a company that no one's ever heard of called a Speed, uh, which has to be, is written all on caps, so I guess it needs to be screamed. [00:15:50] Bryan: Um, a speed has a proprietary part that has a, there is a root password infamously there, is there, the root password is encoded effectively in silicon. So, uh, which is just, and for, um, anyone who kind of goes deep into these things, like, oh my God, are you kidding me? Um, when we first started oxide, the wifi password was a fraction of the a speed root password for the bmc. [00:16:16] Bryan: It's kinda like a little, little BMC humor. Um, but those things, it was just dispiriting that, that the, the state-of-the-art was still basically personal computers running in the data center. Um, and that's part of what, what was the motivation for doing something new? [00:16:32] Jeremy: And for the people using these systems, whether it's the baseboard management controller or it's the The BIOS or UF UEFI component, what are the actual problems that people are seeing seen? Security vulnerabilities and poor practices in the BMC [00:16:51] Bryan: Oh man, I, the, you are going to have like some fraction of your listeners, maybe a big fraction where like, yeah, like what are the problems? That's a good question. And then you're gonna have the people that actually deal with these things who are, did like their heads already hit the desk being like, what are the problems? [00:17:06] Bryan: Like what are the non problems? Like what, what works? Actually, that's like a shorter answer. Um, I mean, there are so many problems and a lot of it is just like, I mean, there are problems just architecturally these things are just so, I mean, and you could, they're the problems spread to the horizon, so you can kind of start wherever you want. [00:17:24] Bryan: But I mean, as like, as a really concrete example. Okay, so the, the BMCs that, that the computer within the computer that needs to be on its own network. So you now have like not one network, you got two networks that, and that network, by the way, it, that's the network that you're gonna log into to like reset the machine when it's otherwise unresponsive. [00:17:44] Bryan: So that going into the BMC, you can are, you're able to control the entire machine. Well it's like, alright, so now I've got a second net network that I need to manage. What is running on the BMC? Well, it's running some. Ancient, ancient version of Linux it that you got. It's like, well how do I, how do I patch that? [00:18:02] Bryan: How do I like manage the vulnerabilities with that? Because if someone is able to root your BMC, they control the system. So it's like, this is not you've, and now you've gotta go deal with all of the operational hair around that. How do you upgrade that system updating the BMC? I mean, it's like you've got this like second shadow bad infrastructure that you have to go manage. [00:18:23] Bryan: Generally not open source. There's something called open BMC, um, which, um, you people use to varying degrees, but you're generally stuck with the proprietary BMC, so you're generally stuck with, with iLO from HPE or iDRAC from Dell or, or, uh, the, uh, su super micros, BMC, that H-P-B-M-C, and you are, uh, it is just excruciating pain. [00:18:49] Bryan: Um, and that this is assuming that by the way, that everything is behaving correctly. The, the problem is that these things often don't behave correctly, and then the consequence of them not behaving correctly. It's really dire because it's at that lowest layer of the system. So, I mean, I'll give you a concrete example. [00:19:07] Bryan: a customer of theirs reported to me, so I won't disclose the vendor, but let's just say that a well-known vendor had an issue with their, their temperature sensors were broken. Um, and the thing would always read basically the wrong value. So it was the BMC that had to like, invent its own ki a different kind of thermal control loop. [00:19:28] Bryan: And it would index on the, on the, the, the, the actual inrush current. It would, they would look at that at the current that's going into the CPU to adjust the fan speed. That's a great example of something like that's a, that's an interesting idea. That doesn't work. 'cause that's actually not the temperature. [00:19:45] Bryan: So like that software would crank the fans whenever you had an inrush of current and this customer had a workload that would spike the current and by it, when it would spike the current, the, the, the fans would kick up and then they would slowly degrade over time. Well, this workload was spiking the current faster than the fans would degrade, but not fast enough to actually heat up the part. [00:20:08] Bryan: And ultimately over a very long time, in a very painful investigation, it's customer determined that like my fans are cranked in my data center for no reason. We're blowing cold air. And it's like that, this is on the order of like a hundred watts, a server of, of energy that you shouldn't be spending and like that ultimately what that go comes down to this kind of broken software hardware interface at the lowest layer that has real meaningful consequence, uh, in terms of hundreds of kilowatts, um, across a data center. So this stuff has, has very, very, very real consequence and it's such a shadowy world. Part of the reason that, that your listeners that have dealt with this, that our heads will hit the desk is because it is really aggravating to deal with problems with this layer. [00:21:01] Bryan: You, you feel powerless. You don't control or really see the software that's on them. It's generally proprietary. You are relying on your vendor. Your vendor is telling you that like, boy, I don't know. You're the only customer seeing this. I mean, the number of times I have heard that for, and I, I have pledged that we're, we're not gonna say that at oxide because it's such an unaskable thing to say like, you're the only customer saying this. [00:21:25] Bryan: It's like, it feels like, are you blaming me for my problem? Feels like you're blaming me for my problem? Um, and what you begin to realize is that to a degree, these folks are speaking their own truth because the, the folks that are running at real scale at Hyperscale, those folks aren't Dell, HP super micro customers. [00:21:46] Bryan: They're actually, they've done their own thing. So it's like, yeah, Dell's not seeing that problem, um, because they're not running at the same scale. Um, but when you do run, you only have to run at modest scale before these things just become. Overwhelming in terms of the, the headwind that they present to people that wanna deploy infrastructure. The problem is felt with just a few racks [00:22:05] Jeremy: Yeah, so maybe to help people get some perspective at, at what point do you think that people start noticing or start feeling these problems? Because I imagine that if you're just have a few racks or [00:22:22] Bryan: do you have a couple racks or the, or do you wonder or just wondering because No, no, no. I would think, I think anyone who deploys any number of servers, especially now, especially if your experience is only in the cloud, you're gonna be like, what the hell is this? I mean, just again, just to get this thing working at all. [00:22:39] Bryan: It is so it, it's so hairy and so congealed, right? It's not designed. Um, and it, it, it, it's accreted it and it's so obviously accreted that you are, I mean, nobody who is setting up a rack of servers is gonna think to themselves like, yes, this is the right way to go do it. This all makes sense because it's, it's just not, it, I, it feels like the kit, I mean, kit car's almost too generous because it implies that there's like a set of plans to work to in the end. [00:23:08] Bryan: Uh, I mean, it, it, it's a bag of bolts. It's a bunch of parts that you're putting together. And so even at the smallest scales, that stuff is painful. Just architecturally, it's painful at the small scale then, but at least you can get it working. I think the stuff that then becomes debilitating at larger scale are the things that are, are worse than just like, I can't, like this thing is a mess to get working. [00:23:31] Bryan: It's like the, the, the fan issue that, um, where you are now seeing this over, you know, hundreds of machines or thousands of machines. Um, so I, it is painful at more or less all levels of scale. There's, there is no level at which the, the, the pc, which is really what this is, this is a, the, the personal computer architecture from the 1980s and there is really no level of scale where that's the right unit. Running elastic infrastructure is the hardware but also, hypervisor, distributed database, api, etc [00:23:57] Bryan: I mean, where that's the right thing to go deploy, especially if what you are trying to run. Is elastic infrastructure, a cloud. Because the other thing is like we, we've kinda been talking a lot about that hardware layer. Like hardware is, is just the start. Like you actually gotta go put software on that and actually run that as elastic infrastructure. [00:24:16] Bryan: So you need a hypervisor. Yes. But you need a lot more than that. You, you need to actually, you, you need a distributed database, you need web endpoints. You need, you need a CLI, you need all the stuff that you need to actually go run an actual service of compute or networking or storage. I mean, and for, for compute, even for compute, there's a ton of work to be done. [00:24:39] Bryan: And compute is by far, I would say the simplest of the, of the three. When you look at like networks, network services, storage services, there's a whole bunch of stuff that you need to go build in terms of distributed systems to actually offer that as a cloud. So it, I mean, it is painful at more or less every LE level if you are trying to deploy cloud computing on. What's a control plane? [00:25:00] Jeremy: And for someone who doesn't have experience building or working with this type of infrastructure, when you talk about a control plane, what, what does that do in the context of this system? [00:25:16] Bryan: So control plane is the thing that is, that is everything between your API request and that infrastructure actually being acted upon. So you go say, Hey, I, I want a provision, a vm. Okay, great. We've got a whole bunch of things we're gonna provision with that. We're gonna provision a vm, we're gonna get some storage that's gonna go along with that, that's got a network storage service that's gonna come out of, uh, we've got a virtual network that we're gonna either create or attach to. [00:25:39] Bryan: We've got a, a whole bunch of things we need to go do for that. For all of these things, there are metadata components that need, we need to keep track of this thing that, beyond the actual infrastructure that we create. And then we need to go actually, like act on the actual compute elements, the hostos, what have you, the switches, what have you, and actually go. [00:25:56] Bryan: Create these underlying things and then connect them. And there's of course, the challenge of just getting that working is a big challenge. Um, but getting that working robustly, getting that working is, you know, when you go to provision of vm, um, the, all the, the, the steps that need to happen and what happens if one of those steps fails along the way? [00:26:17] Bryan: What happens if, you know, one thing we're very mindful of is these kind of, you get these long tails of like, why, you know, generally our VM provisioning happened within this time, but we get these long tails where it takes much longer. What's going on? What, where in this process are we, are we actually spending time? [00:26:33] Bryan: Uh, and there's a whole lot of complexity that you need to go deal with that. There's a lot of complexity that you need to go deal with this effectively, this workflow that's gonna go create these things and manage them. Um, we use a, a pattern that we call, that are called sagas, actually is a, is a database pattern from the eighties. [00:26:51] Bryan: Uh, Katie McCaffrey is a, is a database reCrcher who, who, uh, I, I think, uh, reintroduce the idea of, of sagas, um, in the last kind of decade. Um, and this is something that we picked up, um, and I've done a lot of really interesting things with, um, to allow for, to this kind of, these workflows to be, to be managed and done so robustly in a way that you can restart them and so on. [00:27:16] Bryan: Uh, and then you guys, you get this whole distributed system that can do all this. That whole distributed system, that itself needs to be reliable and available. So if you, you know, you need to be able to, what happens if you, if you pull a sled or if a sled fails, how does the system deal with that? [00:27:33] Bryan: How does the system deal with getting an another sled added to the system? Like how do you actually grow this distributed system? And then how do you update it? How do you actually go from one version to the next? And all of that has to happen across an air gap where this is gonna run as part of the computer. [00:27:49] Bryan: So there are, it, it is fractally complicated. There, there is a lot of complexity here in, in software, in the software system and all of that. We kind of, we call the control plane. Um, and it, this is the what exists at AWS at GCP, at Azure. When you are hitting an endpoint that's provisioning an EC2 instance for you. [00:28:10] Bryan: There is an AWS control plane that is, is doing all of this and has, uh, some of these similar aspects and certainly some of these similar challenges. Are vSphere / Proxmox / Hyper-V in the same category? [00:28:20] Jeremy: And for people who have run their own servers with something like say VMware or Hyper V or Proxmox, are those in the same category? [00:28:32] Bryan: Yeah, I mean a little bit. I mean, it kind of like vSphere Yes. Via VMware. No. So it's like you, uh, VMware ESX is, is kind of a key building block upon which you can build something that is a more meaningful distributed system. When it's just like a machine that you're provisioning VMs on, it's like, okay, well that's actually, you as the human might be the control plane. [00:28:52] Bryan: Like, that's, that, that's, that's a much easier problem. Um, but when you've got, you know, tens, hundreds, thousands of machines, you need to do it robustly. You need something to coordinate that activity and you know, you need to pick which sled you land on. You need to be able to move these things. You need to be able to update that whole system. [00:29:06] Bryan: That's when you're getting into a control plane. So, you know, some of these things have kind of edged into a control plane, certainly VMware. Um, now Broadcom, um, has delivered something that's kind of cloudish. Um, I think that for folks that are truly born on the cloud, it, it still feels somewhat, uh, like you're going backwards in time when you, when you look at these kind of on-prem offerings. [00:29:29] Bryan: Um, but, but it, it, it's got these aspects to it for sure. Um, and I think that we're, um, some of these other things when you're just looking at KVM or just looks looking at Proxmox you kind of need to, to connect it to other broader things to turn it into something that really looks like manageable infrastructure. [00:29:47] Bryan: And then many of those projects are really, they're either proprietary projects, uh, proprietary products like vSphere, um, or you are really dealing with open source projects that are. Not necessarily aimed at the same level of scale. Um, you know, you look at a, again, Proxmox or, uh, um, you'll get an OpenStack. [00:30:05] Bryan: Um, and you know, OpenStack is just a lot of things, right? I mean, OpenStack has got so many, the OpenStack was kind of a, a free for all, for every infrastructure vendor. Um, and I, you know, there was a time people were like, don't you, aren't you worried about all these companies together that, you know, are coming together for OpenStack? [00:30:24] Bryan: I'm like, haven't you ever worked for like a company? Like, companies don't get along. By the way, it's like having multiple companies work together on a thing that's bad news, not good news. And I think, you know, one of the things that OpenStack has definitely struggled with, kind of with what, actually the, the, there's so many different kind of vendor elements in there that it's, it's very much not a product, it's a project that you're trying to run. [00:30:47] Bryan: But that's, but that very much is in, I mean, that's, that's similar certainly in spirit. [00:30:53] Jeremy: And so I think this is kind of like you're alluding to earlier, the piece that allows you to allocate, compute, storage, manage networking, gives you that experience of I can go to a web console or I can use an API and I can spin up machines, get them all connected. At the end of the day, the control plane. Is allowing you to do that in hopefully a user-friendly way. [00:31:21] Bryan: That's right. Yep. And in the, I mean, in order to do that in a modern way, it's not just like a user-friendly way. You really need to have a CLI and a web UI and an API. Those all need to be drawn from the same kind of single ground truth. Like you don't wanna have any of those be an afterthought for the other. [00:31:39] Bryan: You wanna have the same way of generating all of those different endpoints and, and entries into the system. Building a control plane now has better tools (Rust, CockroachDB) [00:31:46] Jeremy: And if you take your time at Joyent as an example. What kind of tools existed for that versus how much did you have to build in-house for as far as the hypervisor and managing the compute and all that? [00:32:02] Bryan: Yeah, so we built more or less everything in house. I mean, what you have is, um, and I think, you know, over time we've gotten slightly better tools. Um, I think, and, and maybe it's a little bit easier to talk about the, kind of the tools we started at Oxide because we kind of started with a, with a clean sheet of paper at oxide. [00:32:16] Bryan: We wanted to, knew we wanted to go build a control plane, but we were able to kind of go revisit some of the components. So actually, and maybe I'll, I'll talk about some of those changes. So when we, at, For example, at Joyent, when we were building a cloud at Joyent, there wasn't really a good distributed database. [00:32:34] Bryan: Um, so we were using Postgres as our database for metadata and there were a lot of challenges. And Postgres is not a distributed database. It's running. With a primary secondary architecture, and there's a bunch of issues there, many of which we discovered the hard way. Um, when we were coming to oxide, you have much better options to pick from in terms of distributed databases. [00:32:57] Bryan: You know, we, there was a period that now seems maybe potentially brief in hindsight, but of a really high quality open source distributed databases. So there were really some good ones to, to pick from. Um, we, we built on CockroachDB on CRDB. Um, so that was a really important component. That we had at oxide that we didn't have at Joyent. [00:33:19] Bryan: Um, so we were, I wouldn't say we were rolling our own distributed database, we were just using Postgres and uh, and, and dealing with an enormous amount of pain there in terms of the surround. Um, on top of that, and, and, you know, a, a control plane is much more than a database, obviously. Uh, and you've gotta deal with, uh, there's a whole bunch of software that you need to go, right. [00:33:40] Bryan: Um, to be able to, to transform these kind of API requests into something that is reliable infrastructure, right? And there, there's a lot to that. Uh, especially when networking gets in the mix, when storage gets in the mix, uh, there are a whole bunch of like complicated steps that need to be done, um, at Joyent. [00:33:59] Bryan: Um, we, in part because of the history of the company and like, look. This, this just is not gonna sound good, but it just is what it is and I'm just gonna own it. We did it all in Node, um, at Joyent, which I, I, I know it sounds really right now, just sounds like, well, you, you built it with Tinker Toys. You Okay. [00:34:18] Bryan: Uh, did, did you think it was, you built the skyscraper with Tinker Toys? Uh, it's like, well, okay. We actually, we had greater aspirations for the Tinker Toys once upon a time, and it was better than, you know, than Twisted Python and Event Machine from Ruby, and we weren't gonna do it in Java. All right. [00:34:32] Bryan: So, but let's just say that that experiment, uh, that experiment did ultimately end in a predictable fashion. Um, and, uh, we, we decided that maybe Node was not gonna be the best decision long term. Um, Joyent was the company behind node js. Uh, back in the day, Ryan Dahl worked for Joyent. Uh, and then, uh, then we, we, we. [00:34:53] Bryan: Uh, landed that in a foundation in about, uh, what, 2015, something like that. Um, and began to consider our world beyond, uh, beyond Node. Rust at Oxide [00:35:04] Bryan: A big tool that we had in the arsenal when we started Oxide is Rust. Um, and so indeed the name of the company is, is a tip of the hat to the language that we were pretty sure we were gonna be building a lot of stuff in. [00:35:16] Bryan: Namely Rust. And, uh, rust is, uh, has been huge for us, a very important revolution in programming languages. you know, there, there, there have been different people kind of coming in at different times and I kinda came to Rust in what I, I think is like this big kind of second expansion of rust in 2018 when a lot of technologists were think, uh, sick of Node and also sick of Go. [00:35:43] Bryan: And, uh, also sick of C++. And wondering is there gonna be something that gives me the, the, the performance, of that I get outta C. The, the robustness that I can get out of a C program but is is often difficult to achieve. but can I get that with kind of some, some of the velocity of development, although I hate that term, some of the speed of development that you get out of a more interpreted language. [00:36:08] Bryan: Um, and then by the way, can I actually have types, I think types would be a good idea? Uh, and rust obviously hits the sweet spot of all of that. Um, it has been absolutely huge for us. I mean, we knew when we started the company again, oxide, uh, we were gonna be using rust in, in quite a, quite a. Few places, but we weren't doing it by fiat. [00:36:27] Bryan: Um, we wanted to actually make sure we're making the right decision, um, at, at every different, at every layer. Uh, I think what has been surprising is the sheer number of layers at which we use rust in terms of, we've done our own embedded firmware in rust. We've done, um, in, in the host operating system, which is still largely in C, but very big components are in rust. [00:36:47] Bryan: The hypervisor Propolis is all in rust. Uh, and then of course the control plane, that distributed system on that is all in rust. So that was a very important thing that we very much did not need to build ourselves. We were able to really leverage, uh, a terrific community. Um. We were able to use, uh, and we've done this at Joyent as well, but at Oxide, we've used Illumos as a hostos component, which, uh, our variant is called Helios. [00:37:11] Bryan: Um, we've used, uh, bhyve um, as a, as as that kind of internal hypervisor component. we've made use of a bunch of different open source components to build this thing, um, which has been really, really important for us. Uh, and open source components that didn't exist even like five years prior. [00:37:28] Bryan: That's part of why we felt that 2019 was the right time to start the company. And so we started Oxide. The problems building a control plane in Node [00:37:34] Jeremy: You had mentioned that at Joyent, you had tried to build this in, in Node. What were the, what were the, the issues or the, the challenges that you had doing that? [00:37:46] Bryan: Oh boy. Yeah. again, we, I kind of had higher hopes in 2010, I would say. When we, we set on this, um, the, the, the problem that we had just writ large, um. JavaScript is really designed to allow as many people on earth to write a program as possible, which is good. I mean, I, I, that's a, that's a laudable goal. [00:38:09] Bryan: That is the goal ultimately of such as it is of JavaScript. It's actually hard to know what the goal of JavaScript is, unfortunately, because Brendan Ike never actually wrote a book. so that there is not a canonical, you've got kind of Doug Crockford and other people who've written things on JavaScript, but it's hard to know kind of what the original intent of JavaScript is. [00:38:27] Bryan: The name doesn't even express original intent, right? It was called Live Script, and it was kind of renamed to JavaScript during the Java Frenzy of the late nineties. A name that makes no sense. There is no Java in JavaScript. that is kind of, I think, revealing to kind of the, uh, the unprincipled mess that is JavaScript. [00:38:47] Bryan: It, it, it's very pragmatic at some level, um, and allows anyone to, it makes it very easy to write software. The problem is it's much more difficult to write really rigorous software. So, uh, and this is what I should differentiate JavaScript from TypeScript. This is really what TypeScript is trying to solve. [00:39:07] Bryan: TypeScript is like. How can, I think TypeScript is a, is a great step forward because TypeScript is like, how can we bring some rigor to this? Like, yes, it's great that it's easy to write JavaScript, but that's not, we, we don't wanna do that for Absolutely. I mean that, that's not the only problem we solve. [00:39:23] Bryan: We actually wanna be able to write rigorous software and it's actually okay if it's a little harder to write rigorous software that's actually okay if it gets leads to, to more rigorous artifacts. Um, but in JavaScript, I mean, just a concrete example. You know, there's nothing to prevent you from referencing a property that doesn't actually exist in JavaScript. [00:39:43] Bryan: So if you fat finger a property name, you are relying on something to tell you. By the way, I think you've misspelled this because there is no type definition for this thing. And I don't know that you've got one that's spelled correctly, one that's spelled incorrectly, that's often undefined. And then the, when you actually go, you say you've got this typo that is lurking in your what you want to be rigorous software. [00:40:07] Bryan: And if you don't execute that code, like you won't know that's there. And then you do execute that code. And now you've got a, you've got an undefined object. And now that's either gonna be an exception or it can, again, depends on how that's handled. It can be really difficult to determine the origin of that, of, of that error, of that programming. [00:40:26] Bryan: And that is a programmer error. And one of the big challenges that we had with Node is that programmer errors and operational errors, like, you know, I'm out of disk space as an operational error. Those get conflated and it becomes really hard. And in fact, I think the, the language wanted to make it easier to just kind of, uh, drive on in the event of all errors. [00:40:53] Bryan: And it's like, actually not what you wanna do if you're trying to build a reliable, robust system. So we had. No end of issues. [00:41:01] Bryan: We've got a lot of experience developing rigorous systems, um, again coming out of operating systems development and so on. And we want, we brought some of that rigor, if strangely, to JavaScript. So one of the things that we did is we brought a lot of postmortem, diagnos ability and observability to node. [00:41:18] Bryan: And so if, if one of our node processes. Died in production, we would actually get a core dump from that process, a core dump that we could actually meaningfully process. So we did a bunch of kind of wild stuff. I mean, actually wild stuff where we could actually make sense of the JavaScript objects in a binary core dump. JavaScript values ease of getting started over robustness [00:41:41] Bryan: Um, and things that we thought were really important, and this is the, the rest of the world just looks at this being like, what the hell is this? I mean, it's so out of step with it. The problem is that we were trying to bridge two disconnected cultures of one developing really. Rigorous software and really designing it for production, diagnosability and the other, really designing it to software to run in the browser and for anyone to be able to like, you know, kind of liven up a webpage, right? [00:42:10] Bryan: Is kinda the origin of, of live script and then JavaScript. And we were kind of the only ones sitting at the intersection of that. And you begin when you are the only ones sitting at that kind of intersection. You just are, you're, you're kind of fighting a community all the time. And we just realized that we are, there were so many things that the community wanted to do that we felt are like, no, no, this is gonna make software less diagnosable. It's gonna make it less robust. The NodeJS split and why people left [00:42:36] Bryan: And then you realize like, I'm, we're the only voice in the room because we have got, we have got desires for this language that it doesn't have for itself. And this is when you realize you're in a bad relationship with software. It's time to actually move on. And in fact, actually several years after, we'd already kind of broken up with node. [00:42:55] Bryan: Um, and it was like, it was a bit of an acrimonious breakup. there was a, uh, famous slash infamous fork of node called IoJS Um, and this was viewed because people, the community, thought that Joyent was being what was not being an appropriate steward of node js and was, uh, not allowing more things to come into to, to node. [00:43:19] Bryan: And of course, the reason that we of course, felt that we were being a careful steward and we were actively resisting those things that would cut against its fitness for a production system. But it's some way the community saw it and they, and forked, um, and, and I think the, we knew before the fork that's like, this is not working and we need to get this thing out of our hands. Platform is a reflection of values node summit talk [00:43:43] Bryan: And we're are the wrong hands for this? This needs to be in a foundation. Uh, and so we kind of gone through that breakup, uh, and maybe it was two years after that. That, uh, friend of mine who was um, was running the, uh, the node summit was actually, it's unfortunately now passed away. Charles er, um, but Charles' venture capitalist great guy, and Charles was running Node Summit and came to me in 2017. [00:44:07] Bryan: He is like, I really want you to keynote Node Summit. And I'm like, Charles, I'm not gonna do that. I've got nothing nice to say. Like, this is the, the, you don't want, I'm the last person you wanna keynote. He's like, oh, if you have nothing nice to say, you should definitely keynote. You're like, oh God, okay, here we go. [00:44:22] Bryan: He's like, no, I really want you to talk about, like, you should talk about the Joyent breakup with NodeJS. I'm like, oh man. [00:44:29] Bryan: And that led to a talk that I'm really happy that I gave, 'cause it was a very important talk for me personally. Uh, called Platform is a reflection of values and really looking at the values that we had for Node and the values that Node had for itself. And they didn't line up. [00:44:49] Bryan: And the problem is that the values that Node had for itself and the values that we had for Node are all kind of positives, right? Like there's nobody in the node community who's like, I don't want rigor, I hate rigor. It's just that if they had the choose between rigor and making the language approachable. [00:45:09] Bryan: They would choose approachability every single time. They would never choose rigor. And, you know, that was a, that was a big eye-opener. I do, I would say, if you watch this talk. [00:45:20] Bryan: because I knew that there's, like, the audience was gonna be filled with, with people who, had been a part of the fork in 2014, I think was the, the, the, the fork, the IOJS fork. And I knew that there, there were, there were some, you know, some people that were, um, had been there for the fork and. [00:45:41] Bryan: I said a little bit of a trap for the audience. But the, and the trap, I said, you know what, I, I kind of talked about the values that we had and the aspirations we had for Node, the aspirations that Node had for itself and how they were different. [00:45:53] Bryan: And, you know, and I'm like, look in, in, in hindsight, like a fracture was inevitable. And in 2014 there was finally a fracture. And do people know what happened in 2014? And if you, if you, you could listen to that talk, everyone almost says in unison, like IOJS. I'm like, oh right. IOJS. Right. That's actually not what I was thinking of. [00:46:19] Bryan: And I go to the next slide and is a tweet from a guy named TJ Holloway, Chuck, who was the most prolific contributor to Node. And it was his tweet also in 2014 before the fork, before the IOJS fork explaining that he was leaving Node and that he was going to go. And you, if you turn the volume all the way up, you can hear the audience gasp. [00:46:41] Bryan: And it's just delicious because the community had never really come, had never really confronted why TJ left. Um, there. And I went through a couple folks, Felix, bunch of other folks, early Node folks. That were there in 2010, were leaving in 2014, and they were going to go primarily, and they were going to go because they were sick of the same things that we were sick of. [00:47:09] Bryan: They, they, they had hit the same things that we had hit and they were frustrated. I I really do believe this, that platforms do reflect their own values. And when you are making a software decision, you are selecting value. [00:47:26] Bryan: You should select values that align with the values that you have for that software. That is, those are, that's way more important than other things that people look at. I think people look at, for example, quote unquote community size way too frequently, community size is like. Eh, maybe it can be fine. [00:47:44] Bryan: I've been in very large communities, node. I've been in super small open source communities like AUMs and RAs, a bunch of others. there are strengths and weaknesses to both approaches just as like there's a strength to being in a big city versus a small town. Me personally, I'll take the small community more or less every time because the small community is almost always self-selecting based on values and just for the same reason that I like working at small companies or small teams. [00:48:11] Bryan: There's a lot of value to be had in a small community. It's not to say that large communities are valueless, but again, long answer to your question of kind of where did things go south with Joyent and node. They went south because the, the values that we had and the values the community had didn't line up and that was a very educational experience, as you might imagine. [00:48:33] Jeremy: Yeah. And, and given that you mentioned how, because of those values, some people moved from Node to go, and in the end for much of what oxide is building. You ended up using rust. What, what would you say are the, the values of go and and rust, and how did you end up choosing Rust given that. Go's decisions regarding generics, versioning, compilation speed priority [00:48:56] Bryan: Yeah, I mean, well, so the value for, yeah. And so go, I mean, I understand why people move from Node to Go, go to me was kind of a lateral move. Um, there were a bunch of things that I, uh, go was still garbage collected, um, which I didn't like. Um, go also is very strange in terms of there are these kind of like. [00:49:17] Bryan: These autocratic kind of decisions that are very bizarre. Um, there, I mean, generics is kind of a famous one, right? Where go kind of as a point of principle didn't have generics, even though go itself actually the innards of go did have generics. It's just that you a go user weren't allowed to have them. [00:49:35] Bryan: And you know, it's kind of, there was, there was an old cartoon years and years ago about like when a, when a technologist is telling you that something is technically impossible, that actually means I don't feel like it. Uh, and there was a certain degree of like, generics are technically impossible and go, it's like, Hey, actually there are. [00:49:51] Bryan: And so there was, and I just think that the arguments against generics were kind of disingenuous. Um, and indeed, like they ended up adopting generics and then there's like some super weird stuff around like, they're very anti-assertion, which is like, what, how are you? Why are you, how is someone against assertions, it doesn't even make any sense, but it's like, oh, nope. [00:50:10] Bryan: Okay. There's a whole scree on it. Nope, we're against assertions and the, you know, against versioning. There was another thing like, you know, the Rob Pike has kind of famously been like, you should always just run on the way to commit. And you're like, does that, is that, does that make sense? I mean this, we actually built it. [00:50:26] Bryan: And so there are a bunch of things like that. You're just like, okay, this is just exhausting and. I mean, there's some things about Go that are great and, uh, plenty of other things that I just, I'm not a fan of. Um, I think that the, in the end, like Go cares a lot about like compile time. It's super important for Go Right? [00:50:44] Bryan: Is very quick, compile time. I'm like, okay. But that's like compile time is not like, it's not unimportant, it's doesn't have zero importance. But I've got other things that are like lots more important than that. Um, what I really care about is I want a high performing artifact. I wanted garbage collection outta my life. Don't think garbage collection has good trade offs [00:51:00] Bryan: I, I gotta tell you, I, I like garbage collection to me is an embodiment of this like, larger problem of where do you put cognitive load in the software development process. And what garbage collection is saying to me it is right for plenty of other people and the software that they wanna develop. [00:51:21] Bryan: But for me and the software that I wanna develop, infrastructure software, I don't want garbage collection because I can solve the memory allocation problem. I know when I'm like, done with something or not. I mean, it's like I, whether that's in, in C with, I mean it's actually like, it's really not that hard to not leak memory in, in a C base system. [00:51:44] Bryan: And you can. give yourself a lot of tooling that allows you to diagnose where memory leaks are coming from. So it's like that is a solvable problem. There are other challenges with that, but like, when you are developing a really sophisticated system that has garbage collection is using garbage collection. [00:51:59] Bryan: You spend as much time trying to dork with the garbage collector to convince it to collect the thing that you know is garbage. You are like, I've got this thing. I know it's garbage. Now I need to use these like tips and tricks to get the garbage collector. I mean, it's like, it feels like every Java performance issue goes to like minus xx call and use the other garbage collector, whatever one you're using, use a different one and using a different, a different approach. [00:52:23] Bryan: It's like, so you're, you're in this, to me, it's like you're in the worst of all worlds where. the reason that garbage collection is helpful is because the programmer doesn't have to think at all about this problem. But now you're actually dealing with these long pauses in production. [00:52:38] Bryan: You're dealing with all these other issues where actually you need to think a lot about it. And it's kind of, it, it it's witchcraft. It, it, it's this black box that you can't see into. So it's like, what problem have we solved exactly? And I mean, so the fact that go had garbage collection, it's like, eh, no, I, I do not want, like, and then you get all the other like weird fatwahs and you know, everything else. [00:52:57] Bryan: I'm like, no, thank you. Go is a no thank you for me, I, I get it why people like it or use it, but it's, it's just, that was not gonna be it. Choosing Rust [00:53:04] Bryan: I'm like, I want C. but I, there are things I didn't like about C too. I was looking for something that was gonna give me the deterministic kind of artifact that I got outta C. But I wanted library support and C is tough because there's, it's all convention. you know, there's just a bunch of other things that are just thorny. And I remember thinking vividly in 2018, I'm like, well, it's rust or bust. Ownership model, algebraic types, error handling [00:53:28] Bryan: I'm gonna go into rust. And, uh, I hope I like it because if it's not this, it's gonna like, I'm gonna go back to C I'm like literally trying to figure out what the language is for the back half of my career. Um, and when I, you know, did what a lot of people were doing at that time and people have been doing since of, you know, really getting into rust and really learning it, appreciating the difference in the, the model for sure, the ownership model people talk about. [00:53:54] Bryan: That's also obviously very important. It was the error handling that blew me away. And the idea of like algebraic types, I never really had algebraic types. Um, and the ability to, to have. And for error handling is one of these really, uh, you, you really appreciate these things where it's like, how do you deal with a, with a function that can either succeed and return something or it can fail, and the way c deals with that is bad with these kind of sentinels for errors. [00:54:27] Bryan: And, you know, does negative one mean success? Does negative one mean failure? Does zero mean failure? Some C functions, zero means failure. Traditionally in Unix, zero means success. And like, what if you wanna return a file descriptor, you know, it's like, oh. And then it's like, okay, then it'll be like zero through positive N will be a valid result. [00:54:44] Bryan: Negative numbers will be, and like, was it negative one and I said airo, or is it a negative number that did not, I mean, it's like, and that's all convention, right? People do all, all those different things and it's all convention and it's easy to get wrong, easy to have bugs, can't be statically checked and so on. Um, and then what Go says is like, well, you're gonna have like two return values and then you're gonna have to like, just like constantly check all of these all the time. Um, which is also kind of gross. Um, JavaScript is like, Hey, let's toss an exception. If, if we don't like something, if we see an error, we'll, we'll throw an exception. [00:55:15] Bryan: There are a bunch of reasons I don't like that. Um, and you look, you'll get what Rust does, where it's like, no, no, no. We're gonna have these algebra types, which is to say this thing can be a this thing or that thing, but it, but it has to be one of these. And by the way, you don't get to process this thing until you conditionally match on one of these things. [00:55:35] Bryan: You're gonna have to have a, a pattern match on this thing to determine if it's a this or a that, and if it in, in the result type that you, the result is a generic where it's like, it's gonna be either the thing that you wanna return. It's gonna be an okay that contains the thing you wanna return, or it's gonna be an error that contains your error and it forces your code to deal with that. [00:55:57] Bryan: And what that does is it shifts the cognitive load from the person that is operating this thing in production to the, the actual developer that is in development. And I think that that, that to me is like, I, I love that shift. Um, and that shift to me is really important. Um, and that's what I was missing, that that's what Rust gives you. [00:56:23] Bryan: Rust forces you to think about your code as you write it, but as a result, you have an artifact that is much more supportable, much more sustainable, and much faster. Prefer to frontload cognitive load during development instead of at runtime [00:56:34] Jeremy: Yeah, it sounds like you would rather take the time during the development to think about these issues because whether it's garbage collection or it's error handling at runtime when you're trying to solve a problem, then it's much more difficult than having dealt with it to start with. [00:56:57] Bryan: Yeah, absolutely. I, and I just think that like, why also, like if it's software, if it's, again, if it's infrastructure software, I mean the kinda the question that you, you should have when you're writing software is how long is this software gonna live? How many people are gonna use this software? Uh, and if you are writing an operating system, the answer for this thing that you're gonna write, it's gonna live for a long time. [00:57:18] Bryan: Like, if we just look at plenty of aspects of the system that have been around for a, for decades, it's gonna live for a long time and many, many, many people are gonna use it. Why would we not expect people writing that software to have more cognitive load when they're writing it to give us something that's gonna be a better artifact? [00:57:38] Bryan: Now conversely, you're like, Hey, I kind of don't care about this. And like, I don't know, I'm just like, I wanna see if this whole thing works. I've got, I like, I'm just stringing this together. I don't like, no, the software like will be lucky if it survives until tonight, but then like, who cares? Yeah. Yeah. [00:57:52] Bryan: Gar garbage clock. You know, if you're prototyping something, whatever. And this is why you really do get like, you know, different choices, different technology choices, depending on the way that you wanna solve the problem at hand. And for the software that I wanna write, I do like that cognitive load that is upfront. With LLMs maybe you can get the benefit of the robust artifact with less cognitive load [00:58:10] Bryan: Um, and although I think, I think the thing that is really wild that is the twist that I don't think anyone really saw coming is that in a, in an LLM age. That like the cognitive load upfront almost needs an asterisk on it because so much of that can be assisted by an LLM. And now, I mean, I would like to believe, and maybe this is me being optimistic, that the the, in the LLM age, we will see, I mean, rust is a great fit for the LLMH because the LLM itself can get a lot of feedback about whether the software that's written is correct or not. [00:58:44] Bryan: Much more so than you can for other environments. [00:58:48] Jeremy: Yeah, that is a interesting point in that I think when people first started trying out the LLMs to code, it was really good at these maybe looser languages like Python or JavaScript, and initially wasn't so good at something like Rust. But it sounds like as that improves, if. It can write it then because of the rigor or the memory management or the error handling that the language is forcing you to do, it might actually end up being a better choice for people using LLMs. [00:59:27] Bryan: absolutely. I, it, it gives you more certainty in the artifact that you've delivered. I mean, you know a lot about a Rust program that compiles correctly. I mean, th there are certain classes of errors that you don't have, um, that you actually don't know on a C program or a GO program or a, a JavaScript program. [00:59:46] Bryan: I think that's gonna be really important. I think we are on the cusp. Maybe we've already seen it, this kind of great bifurcation in the software that we writ

Publicada originalmente en 1961, Solaris se aleja de las historias de exploración espacial convencionales para ofrecer una reflexión radical sobre la ciencia y la incapacidad humana para comprender lo verdaderamente ajeno. La trama sigue al psicólogo Chris Kelvin en su llegada a una estación espacial donde la tripulación sufre trastornos mentales debido a la influencia de un océano inteligente que cubre el planeta. Esta entidad, que no posee células ni órganos, actúa materializando los recuerdos y problemas del pasado de los investigadores, lo que sirve como una metáfora sobre los límites de nuestra percepción y el antropocentrismo del conocimiento. La obra ,que cuenta con una aclamada adaptación cinematográfica de Andrei Tarkovsky, plantea que el universo puede contener fenómenos que, simplemente, no son comprensibles para la mente humana.

Episode 28- The path is set forward. To avoid chaos in the city a deal must be struck. An actual play, tabletop role-playing game that uses the Pathfinder 1E rule-set. The epic story follows the brave players through a unique dark fantasy world. The Heroes trials and tribulations will have them brought face to face with demons, devils, angry spirits, the occult, and more. The story takes place in the dark fantasy world of Mel'Herron. Our heroes are brought together by mysterious circumstances leaving them with more questions than answers. An ever-present dark force seems to be lurking in the shadows seeking the party for reasons they must figure out or be swept up by the coming storm. Please like and follow !!! =) Marty is the Dungeon Master, Bobby plays Uri, Wes plays Rein, Derek plays Solaris, Morris play Lirium, Marcus plays Torad Follow us on Twitter: @dicebargaming1    Facebook: The Dice Bar Gaming Podcast Music by: https://www.fesliyanstudios.com Scott Buckley  www.scottbuckley.com.au. Kevin MacLeod Link: https://incompetech.filmmusic.io/song/5048-stay-the-course License: https://filmmusic.io/standard-license. Paid license from: www.epidemicsound.com March of Midnight by Scott Buckley | www.scottbuckley.com.au Music promoted by https://www.chosic.com Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/ Unseen Horrors Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/ Music promoted by https://www.chosic.com/ For world info- https://www.worldanvil.com/w/mel-herron-bruehawk Friends of the podcast: Bored Online? Board Offline!- https://www.youtube.com/channel/UCVmlVsZVlruYWnIYd42iBhw Game Knight Hero Podcast- https://podcasts.apple.com/us/podcast/game-knight-heroes/id1552887060 Deadlands by Kerri Smith- https://www.youtube.com/channel/UCAVrPUutK3IvxLWDKaN3UgQ **Episodes contain adult content. “a mature Podcast”**

Rudi Wrany im Gespräch mit Promoterin Anna über ihr neues Baby „Solaris“ und große Pläne. (superfly.fm)

Episode 27- An old enemy returns. Will he stay that way? An actual play, tabletop role-playing game that uses the Pathfinder 1E rule-set. The epic story follows the brave players through a unique dark fantasy world. The Heroes trials and tribulations will have them brought face to face with demons, devils, angry spirits, the occult, and more. The story takes place in the dark fantasy world of Mel'Herron. Our heroes are brought together by mysterious circumstances leaving them with more questions than answers. An ever-present dark force seems to be lurking in the shadows seeking the party for reasons they must figure out or be swept up by the coming storm. Please like and follow !!! =) Marty is the Dungeon Master, Bobby plays Uri, Wes plays Rein, Derek plays Solaris, Morris play Lirium, Marcus plays Torad Follow us on Twitter: @dicebargaming1    Facebook: The Dice Bar Gaming Podcast Music by: https://www.fesliyanstudios.com Scott Buckley  www.scottbuckley.com.au. Kevin MacLeod Link: https://incompetech.filmmusic.io/song/5048-stay-the-course License: https://filmmusic.io/standard-license. Paid license from: www.epidemicsound.com March of Midnight by Scott Buckley | www.scottbuckley.com.au Music promoted by https://www.chosic.com Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/ Unseen Horrors Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/ Music promoted by https://www.chosic.com/ For world info- https://www.worldanvil.com/w/mel-herron-bruehawk Friends of the podcast: Bored Online? Board Offline!- https://www.youtube.com/channel/UCVmlVsZVlruYWnIYd42iBhw Game Knight Hero Podcast- https://podcasts.apple.com/us/podcast/game-knight-heroes/id1552887060 Deadlands by Kerri Smith- https://www.youtube.com/channel/UCAVrPUutK3IvxLWDKaN3UgQ **Episodes contain adult content. “a mature Podcast”**  

This show has been flagged as Clean by the host. These are the commands mentioned in the You may need to use "sudo" to run these commands depending on how your system is configured. strace uptime strace ls 2>&1 | grep open strace -e openat ls / strace ls /does/not/exist strace -o ls-trace.log ls strace -ff -o pid12345-trace.log -p 12345 HISTORY The original strace was written by Paul Kranenburg for SunOS and was inspired by its trace utility. The SunOS version of strace was ported to Linux and enhanced by Branko Lankester, who also wrote the Linux kernel support. Even though Paul released strace 2.5 in 1992, Branko's work was based on Paul's strace 1.5 release from 1991. In 1993, Rick Sladkey took on the project. He merged strace 2.5 for SunOS with the second release of strace for Linux, added many features from SVR4's truss(1), and produced a ver‐ sion of strace that worked on both platforms. In 1994 Rick ported strace to SVR4 and Solaris and wrote the automatic configuration support. In 1995 he ported strace to Irix (and became tired of writing about himself in the third person). Beginning with 1996, strace was maintained by Wichert Akkerman. During his tenure, strace development migrated to CVS; ports to FreeBSD and many architectures on Linux (including ARM, IA-64, MIPS, PA-RISC, PowerPC, s390, SPARC) were introduced. In 2002, responsibility for strace maintenance was transferred to Roland McGrath. Since then, strace gained support for several new Linux architectures (AMD64, s390x, SuperH), bi- architecture support for some of them, and received numerous additions and improvements in system calls decoders on Linux; strace development migrated to Git during that period. Since 2009, strace has been actively maintained by Dmitry Levin. During this period, strace has gained support for the AArch64, ARC, AVR32, Blackfin, C-SKY, LoongArch, Meta, Nios II, OpenRISC 1000, RISC-V, Tile/TileGx, and Xtensa architectures. In 2012, unmaintained and apparently broken support for non-Linux operating systems was removed. Also, in 2012 strace gained support for path tracing and file descriptor path decoding. In 2014, support for stack trace printing was added. In 2016, system call tampering was implemented. For the additional information, please refer to the NEWS file and strace repository commit log. Links https://strace.io https://en.wikipedia.org/wiki/Strace https://www.man7.org/linux/man-pages/man1/strace.1.html Provide feedback on this episode.

An airhacks.fm conversation with Simon Ritter (@speakjava) about: first computer experiences with TRS-80 and mainframe ALGOL68 programming via punched cards in the 1970s UK, one-week turnaround times for program execution, writing battleship games on mainframes, bbc micro with color graphics and dual floppy drives, father's influence as a tech enthusiast with a PDP-8 in his chemistry lab, early fascination with robotics and controlling machines through programming, writing card games and Mandelbrot set fractal generators in Basic, transition from BASIC to C programming through sponsored university degree, working at Rocc Computers on Unix device drivers and kernel debugging, the teleputer, memory leak debugging requiring half-inch mag tape transfers and two-week investigation periods, AT&T Unix source code license access and kernel modifications, Unix System V Release 4 and Bell Labs heritage, Motorola 68000 processor's flat memory model versus Intel's near/far pointers, Novell acquisition of Unix from AT&T in 1993, Unixware development and time spent in Utah, SCO's acquisition of Unix IP and subsequent IP trolling, joining Sun Microsystems in 1996 as Solaris sales engineer, transition to Java evangelism in 1997, working under Reggie Hutcherson and Matt Thompson for nearly 10 years, building Lego Mindstorms blackjack-dealing robot with Java speech recognition and computer vision, using Sphinx for voice recognition and FreeTTS for speech synthesis, JMF webcam integration for card recognition, JavaOne 2004 robot demonstration, Glassfish application server evangelism and reference implementation benefits, Sun's technology focus versus business development challenges, CDE desktop environment nostalgia, Oracle acquisition of Sun in 2010, Jonathan Schwartz's acquisition announcement email, Oracle's successful stewardship of Java through openJDK, praise for Brian Goetz Mark Reinhold John Rose and Stuart Marks, six-month release cycle benefits, Project Amber Loom Panama and Valhalla developments, OpenSolaris discontinuation leading to docker adoption for server containerization, Oracle's 2015 pivot to cloud focus, career-defining conversation in Japan about cloud versus Java evangelism, layoff during vacation in September 2015, joining Azul Systems after three-and-a-half-hour interview with Gil Tene, ten years at Azul working on high-performance JVM Platform Prime garbage collection and CRaC technology, comparison of Azul culture to Sun Microsystems innovation environment, commercial Java distribution value propositions and runtime inventory features Simon Ritter on twitter: @speakjava

Episode 26- Solaris communicates with the ship. The heroes plan their next move. An actual play, tabletop role-playing game that uses the Pathfinder 1E rule-set. The epic story follows the brave players through a unique dark fantasy world. The Heroes trials and tribulations will have them brought face to face with demons, devils, angry spirits, the occult, and more. The story takes place in the dark fantasy world of Mel'Herron. Our heroes are brought together by mysterious circumstances leaving them with more questions than answers. An ever-present dark force seems to be lurking in the shadows seeking the party for reasons they must figure out or be swept up by the coming storm. Please like and follow !!! =) Marty is the Dungeon Master, Bobby plays Uri, Wes plays Rein, Derek plays Solaris, Morris play Lirium, Marcus plays Torad Follow us on Twitter: @dicebargaming1    Facebook: The Dice Bar Gaming Podcast Music by: https://www.fesliyanstudios.com Scott Buckley  www.scottbuckley.com.au. Kevin MacLeod Link: https://incompetech.filmmusic.io/song/5048-stay-the-course License: https://filmmusic.io/standard-license. Paid license from: www.epidemicsound.com March of Midnight by Scott Buckley | www.scottbuckley.com.au Music promoted by https://www.chosic.com Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/ Unseen Horrors Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/ Music promoted by https://www.chosic.com/ For world info- https://www.worldanvil.com/w/mel-herron-bruehawk Friends of the podcast: Bored Online? Board Offline!- https://www.youtube.com/channel/UCVmlVsZVlruYWnIYd42iBhw Game Knight Hero Podcast- https://podcasts.apple.com/us/podcast/game-knight-heroes/id1552887060 Deadlands by Kerri Smith- https://www.youtube.com/channel/UCAVrPUutK3IvxLWDKaN3UgQ **Episodes contain adult content. “a mature Podcast”**

Welcome to Out of the Shadows, a series that dives into the world of (mostly) 80s horror movies. Join Chris Chavez and Jim Clark as they explore the best and worst of what made the 80s the golden age of horror. This week, Jim's “Space Horror” interlude comes to a close as he and Chris discuss the 1972 sci-fi Soviet psychological thriller (not horror) Solaris.

Un podcast de divertissement où Fred partage ses passions : bandes dessinées, vintage, livres, brocante, histoires sorties de son imagination… et tente parfois de vous faire sourire avec un brin d'humour. Cette semaine, les épisodes 20 et 21 du Grenier Pop. Et je vous raconte la légende de Solaris… ou plutôt ce qui a failli être la légende de Solaris dans le jeu ultra-punitif Kenshi.

Episode 25- Rean is back! He has a story to share. An actual play, tabletop role-playing game that uses the Pathfinder 1E rule-set. The epic story follows the brave players through a unique dark fantasy world. The Heroes trials and tribulations will have them brought face to face with demons, devils, angry spirits, the occult, and more. The story takes place in the dark fantasy world of Mel'Herron. Our heroes are brought together by mysterious circumstances leaving them with more questions than answers. An ever-present dark force seems to be lurking in the shadows seeking the party for reasons they must figure out or be swept up by the coming storm. Please like and follow !!! =) Marty is the Dungeon Master, Bobby plays Uri, Wes plays Rein, Derek plays Solaris, Morris play Lirium, Marcus plays Torad Follow us on Twitter: @dicebargaming1    Facebook: The Dice Bar Gaming Podcast Music by: https://www.fesliyanstudios.com Scott Buckley  www.scottbuckley.com.au. Kevin MacLeod Link: https://incompetech.filmmusic.io/song/5048-stay-the-course License: https://filmmusic.io/standard-license. Paid license from: www.epidemicsound.com March of Midnight by Scott Buckley | www.scottbuckley.com.au Music promoted by https://www.chosic.com Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/ Unseen Horrors Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/ Music promoted by https://www.chosic.com/ For world info- https://www.worldanvil.com/w/mel-herron-bruehawk Friends of the podcast: Bored Online? Board Offline!- https://www.youtube.com/channel/UCVmlVsZVlruYWnIYd42iBhw Game Knight Hero Podcast- https://podcasts.apple.com/us/podcast/game-knight-heroes/id1552887060 Deadlands by Kerri Smith- https://www.youtube.com/channel/UCAVrPUutK3IvxLWDKaN3UgQ **Episodes contain adult content. “a mature Podcast”**

The Irish are famously among the biggest tea drinkers in the world. It used to be a choice of either Lyons or Barrys but increasingly we are branching out in the types of tea we drink including Matcha, Chai and Green tea. One tea importer in Galway, called Solaris is run by a German couple who have now achieved the rare accolade of a B Corp Status denoting the highest standards in how the business is run. Jorg Müller, co-owner of Solaris Tea told Joe all about the company.

Spoilers del Futuro es un podcast que explora los problemas políticos del presente por medio de las visiones, advertencias y fantasías de la ciencia ficción.Fernando Nieto, profesor de gobierno y administración pública en El Colegio de México y Humberto Beck, historiador del pensamiento político en la misma institución, combinan literatura, cine y teoría política para entender mejor qué nos está pasando y hacia dónde podríamos ir.En este episodio, dialogan sobre la conciencia y el problema del otro a partir de la novela Solaris de Stanisław Lem. Producción: Coordinación de Educación Digital / Colmex Digital

Debbie Solaris | Galactic History, Star Lineages & Akashic Recordswith Joan of Angels | Dr. Joan HangarterPresented by Portal to AscensionIn this powerful live conversation, Debbie Solaris joins host Joan of Angels (Dr. Joan Hangarter) for a deep exploration of galactic history, star lineages, and humanity's forgotten cosmic origins.This discussion weaves together Debbie's personal extraterrestrial contact experiences, her work as an Akashic Records reader, and her lifelong research into ancient civilizations and interstellar histories. Together, they explore how starseed remembrance, universal spiritual knowledge, and interdimensional awareness can be integrated into grounded, practical awakening in daily life.Debbie Solaris is widely known for her ability to bridge higher-dimensional information with embodied understanding, helping humanity remember its place within a vast, intelligent, and interconnected universe.

Episode 24- We are back! The heroes find a truly terrible place belonging to their greatest enemy. An actual play, tabletop role-playing game that uses the Pathfinder 1E rule-set. The epic story follows the brave players through a unique dark fantasy world. The Heroes trials and tribulations will have them brought face to face with demons, devils, angry spirits, the occult, and more. The story takes place in the dark fantasy world of Mel'Herron. Our heroes are brought together by mysterious circumstances leaving them with more questions than answers. An ever-present dark force seems to be lurking in the shadows seeking the party for reasons they must figure out or be swept up by the coming storm. Please like and follow !!! =) Marty is the Dungeon Master, Bobby plays Uri, Wes plays Rein, Derek plays Solaris, Morris play Lirium, Marcus plays Torad Follow us on Twitter: @dicebargaming1    Facebook: The Dice Bar Gaming Podcast Music by: https://www.fesliyanstudios.com Scott Buckley  www.scottbuckley.com.au. Kevin MacLeod Link: https://incompetech.filmmusic.io/song/5048-stay-the-course License: https://filmmusic.io/standard-license. Paid license from: www.epidemicsound.com March of Midnight by Scott Buckley | www.scottbuckley.com.au Music promoted by https://www.chosic.com Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/ Unseen Horrors Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/ Music promoted by https://www.chosic.com/ For world info- https://www.worldanvil.com/w/mel-herron-bruehawk Friends of the podcast: Bored Online? Board Offline!- https://www.youtube.com/channel/UCVmlVsZVlruYWnIYd42iBhw Game Knight Hero Podcast- https://podcasts.apple.com/us/podcast/game-knight-heroes/id1552887060 Deadlands by Kerri Smith- https://www.youtube.com/channel/UCAVrPUutK3IvxLWDKaN3UgQ **Episodes contain adult content. “a mature Podcast”**

El 1 de julio de 2025, el telescopio de sondeo del Sistema ATLAS en Chile descubrió el tercer objeto interestelar conocido: el cometa 3I/ATLAS. Con un brillo extremadamente tenue, en una magnitud aparente de 18, el objeto recién descubierto estaba entrando en el sistema solar interior a una velocidad de 61 km/s (220.000 km/h) con respecto al Sol, situado a una distancia de la Tierra de 3,52 UA (527 millones de kilómetros). Para septiembre de 2025 había aumentado hasta la magnitud 14-15. A medida que 3I/ATLAS se acercó al Sol a finales de octubre, sorprendió a los astrónomos al brillar mucho más rápido de lo esperado: de repente pasó a ser visible para observatorios espaciales con magnitud 9-10. Las observaciones iniciales no dejaron claro si se trataba de un asteroide o de un cometa. Las observaciones realizadas el 2 de julio de 2025 por el Deep Random Survey en Chile, el Lowell Discovery Telescope en Arizona y el Observatorio CFHT (Canadá, Francia, Hawai) en Mauna Kea mostraron una coma marginal y una cola corta de tres segundos de arco de longitud angular, lo que indica que el objeto es un cometa. El 2 de julio de 2025, el MPC (Centro de Planetas Menores, organismo del Observatorio Astrofísico Smithsoniano, que forma parte del Centro de astrofísica Harvard-Smithsonian junto con el Observatorio Harvard College) anunció el descubrimiento del cometa y le otorgó la designación de objeto interestelar «3I», lo que significa que era el tercer objeto interestelar confirmado. El MPC también le dio la designación de cometa no periódico C/2025 N1 (ATLAS).​ Cuando se anunció el proyecto 3I/ATLAS, el Centro de Planetas Menores había recopilado 122 observaciones del cometa desde 31 observatorios diferentes. La controversia ha estado presente en el descubrimiento de este objeto interestelar desde el inicio. El 16 de julio de 2025, el equipo del astrofísico Avi Loeb de la Universidad de Harvard publicó un artículo en arXiv especulando que 3I/ATLAS podría ser una nave espacial extraterrestre​ dadas algunas características «anómalas»,​ como su brillo inusual, no muestra aceleración no gravitacional, la falta de compuestos químicos identificables, su trayectoria precisa a través del Sistema Solar y la ausencia de desgasificación cometaria evidente en sus inicios, argumentando que no se comporta como un cometa. Loeb también ha observado que los chorros del cometa podrían estar disparándose en pulsos, creando un patrón repetitivo a modo de "latido". Cada estallido de gas y polvo hace que la coma se intensifique, se desvanezca y vuelva a intensificarse. Esto aún podría ser un proceso natural —por ejemplo, una zona muy volátil de la superficie que libera gas una vez por cada rotación—. Pero Loeb señala que, si los chorros no apuntan siempre hacia el Sol o si su sincronización resulta demasiado precisa el comportamiento empieza a parecer menos "propio de un cometa" y más... antinatural. En este caso, afirma, podríamos estar viendo indicios de un mecanismo artificial con un sistema de expulsión controlado. Otros astrónomos criticaron inmediatamente la especulación de Loeb.​ Darryl Seligman, que dirigió el primer estudio publicado sobre 3I/ATLAS, afirmó que «se han realizado numerosas observaciones telescópicas que demuestran que muestra señales clásicas de actividad cometaria». Además explicó que las sustancias químicas en el cometa podrían no ser detectables aún, dado que el objeto todavía se encontraba lejos del Sol.​ Desde entonces las observaciones han evidenciado indicios de un cometa clásico: presenta un pequeño núcleo helado, una coma rica en dióxido de carbono, ráfagas de vapor de agua e incluso una rara anticola causada por la geometría de la observación. El 29 de septiembre el cometa sobrevive ileso a una tormenta solar, a diferencia de muchos cometas del Sistema Solar. El 30 de septiembre 3I/ATLAS pasa detrás del Sol, desapareciendo de la vista hasta finales de noviembre. El 29 de octubre 3I/ATLAS sobrevive a su paso cercano al Sol, aumentando de brillo de forma repentina. El 2 de noviembre vuelve a ser visible tras perderse en el resplandor del Sol. El 4 de noviembre parece estar cambiando de color, adquiriendo un tono azulado. El 10 de noviembre el radiotelescopio MeerKAT en Sudáfrica detectó una señal de radio procedente de 3I/ATLAS —una emisión de fondo constante típica del gas y el polvo en el espacio, no una señal modulada que transporte información. Emisiones similares se registraron por primera vez en cometas en la década de 1970. El descubrimiento del cometa 3I/ATLAS es importante porque es un auténtico objeto interestelar, lo que significa que no se formó en nuestro Sistema Solar, sino que proviene de otro sistema estelar. Estos objetos son increíblemente raros, por lo que descubrir uno genera un gran revuelo. Además, las primeras estimaciones indican que su núcleo podría alcanzar los 5 kilómetros de diámetro, lo que lo convierte en uno de los cuerpos interestelares más grandes jamás detectados. Tras su máximo acercamiento al Sol a finales de octubre de 2025, 3I/ATLAS ha comenzado su viaje de regreso al espacio interestelar. Viajando alrededor de 30 kms/s en una trayectoria claramente hiperbólica, se mueve lo bastante rápido como para escapar por completo a la gravedad del Sol. El cometa ha alcanzado el perigeo (máximo acercamiento a la Tierra) el 19 de diciembre de 2025 y cruzará más allá de la órbita de Júpiter para el 16 de marzo de 2026. A comienzos de la década de 2030 habrá abandonado la región planetaria del Sistema Solar, continuando su silencioso viaje por la galaxia, tal como una vez llegó. Kaptep, Daryl Groetsch, Robert Scott Thompson, Ard Bit, 36 & zakè, Terminus Void, Max Corbacho, Infinite Third, David Helpling & Eric "the" Taylor, Pulse Mandala, Applefish, SoLaRiS, Keith Richie, Yawning Portal, Extraworld. 🎧 El playlist detallado: lostfrontier.org/space.html#1070

Rozmówcą Jakuba Duszaka jest Łukasz Kucharczyk – autor rozprawy doktorskiej Granice ciała. Somapoetyka w twórczości Stanisława Lema oraz książek z gatunku fantastyki (Granty i smoki i Wszystkie drogi prowadzą), a także doktor nauk humanistycznych i adiunkt w Katedrze Literatury XX wieku na Uniwersytecie Kardynała Stefana Wyszyńskiego.W rozmowie na antenie Radia Wnet, pisarz dogłębnie omawia życie i twórczość Stanisława Lema. Na początku zaznacza:W dalszym ciągu Stanisław Lem, w kontekście wszystkich wznowień jego ksiażek, to jest jeden z najchętniej czytanych pisarzy,  nie tylko fantastycznych, ale pisarzy w ogóle w Polsce.Lem i obcyRozważając sposób, w jaki Stanisław Lem konstruował postacie i byty pozaziemskie, Łukasz Kucharczyk zwraca uwagę, że pisarz odrzucał popularną w fantastyce wizję kosmosu jako zbioru egzotycznych, lecz w gruncie rzeczy ziemskich światów:My szukamy luster w kosmosie. I tak naprawdę we wszystkich tych opowieściach, całej twórczości jedyne co ludzkość znajduje to tylko lustra.~ mówi literaturoznawca, odwołując się do słynnej sceny z Solaris, w której bohaterowie uświadamiają sobie, że wyprawy kosmiczne nie służą poznaniu Innego, lecz potwierdzaniu własnych wyobrażeń. W tym sensie Lem polemizuje z popkulturową fantastyką spod znaku Gwiezdnych wojen i Star Treka, gdzie planety i ich mieszkańcy są jedynie fantastycznymi wariantami Ziemi.Lem a socjalizmAnalizując wątki życia czołowego przedstawiciela polskiej literatury fantastycznej, Łukasz Kucharczyk uznaje, że komunistyczne akcenty dostrzegalne we wczesnych dziełach Lema nie świadczą o prosocjalistycznym wyrazie ogółu jego twórczości:Wydaje mi się, że to była bardziej młodzieńcza, powojenna wiara w odbudowę tego świata. Ona została szybko utrącona, zresztą to bardzo szeroko też jest opisywane w lemowskiej twórczości, szczególnie tej groteskowej.~ stwierdza pisarz i w tym kontekście wspomina Ijona Tichy'ego bohatera  Dzienników gwiazdowych. W jednym z tych opowiadań, podróżnik międzygalaktyczny trafia na planetę, na której funkcjonuje Dobrowolny Upowszechniacz Porządku Absolutnego – maszyna mająca za zadanie zaprowadzić porządek absolutny.Kończy się to tym, że po prostu wszyscy mieszkańcy są przekształceni w estetyczne, bardzo ładnie do siebie pasujące desenie, które zdobią całą planetę. Więc jakby to jest już jeden z pierwszych i nie jedynych w symboli naigrywania się Lema z tych błędów i wypaczeń socjalizmu.~ interpretuje Łukasz Kucharczyk.Lem przez pryzmat pamięciJak mówi nasz gość, w dziełach Lema nie brakuje też wątków autobiograficznych. Istnieje podejrzenie, że młody Stanisław przebywał w lwowskim getcie. Według prof. Agnieszki Gajskiej Solaris można interpretować właśnie poprzez pryzmat pamięci:Solaris to są widma de facto, prawda? Widma ludzi, których odeszli, widma być może traum wojennych.~ mówi rozmówca./ab

En este episodio de Las Claves de la Noticia, Desglosamos las noticias más relevantes del 9 de enero de 2026

This week Noah and Steve work on Steve's house, a new automated lock system goes in, some new structured wiring goes in, and we talk about automating your Christmas tree. -- During The Show -- 00:48 Intro Happy Christmas Kids and presents Quests at Steve's Steve's Christmas tree Steve on a Mac 16:20 Feedback You start the conversation Send in an email success stories problems you can't solve suggest a topic 18:00 Switch Bot A room to keep dogs and kids out of Why Switch Bot? Gold tier certified by Home Assistant Value of talking with others How to evaluate "the line" The "delta" Gratitude 36:17 Structured Wiring 2 Recessed outlets with Ethernet 2 Projector rooms The Smart Home Hookup (https://www.thesmarthomehookup.com/) The Smart Home Hookup Youtube (https://www.thesmarthomehookup.com/) Playing D&D with the family Lay of the land Running Cat6 SDI Video/Audio Belden Cables (https://www.belden.com/products) Vertical Cables (https://verticalcable.com/) HDMI Decimators Keystones 55:57 News Wire Darktable 5.4 - darktable.org (https://www.darktable.org/2025/12/darktable-5.4.0-released/) Kdenlive 25.12 - kdenlive.org (https://kdenlive.org/news/releases/25.12.0/) OpenShot 3.4 - openshot.org (https://www.openshot.org/blog/2025/12/15/new_openshot_release_340/) OpenZFS 2.4 - github.com (https://github.com/openzfs/zfs/releases) GNUCash 5.14 - gnucash.org (https://www.gnucash.org/news.phtml) Nvidia Linux 590.48 - phoronix.com (https://www.phoronix.com/news/NVIDIA-590.48.01-Linux) Linux 6.17 EOL - 9to5linux.com (https://9to5linux.com/linux-kernel-6-17-reaches-end-of-life-its-time-to-upgrade-to-linux-kernel-6-18-lts) RELIANOID 7.8.0 - relianoid.com (https://www.relianoid.com/blog/release-notes-relianoid-7-8-0-community-edition/?srsltid=AfmBOoqTXRsWaTNKQFzVEqPBJTCWcDsZ6UdJ39cTIPM4-r7CGJXQ8Ldq) SparkyLinux 2025.12 - sparkylinux.org (https://sparkylinux.org/sparky-2025-12/) Easy OS Excalibur 7.1 - puppylinux.com (https://forum.puppylinux.com/viewtopic.php?t=16128) Emmabuntus Debian Edition 6 - emmabuntus.org (https://emmabuntus.org/category/english/) Solaris 11.4 - blogs.oracle.com (https://blogs.oracle.com/solaris/whats-new-in-oracle-solaris-11-4-sru-87) FreeBSD 15.0 - freebsd.org (https://www.freebsd.org/releases/15.0R/relnotes/) Rust CVE in Linux - itsfoss.com (https://itsfoss.com/news/first-linux-kernel-rust-cve/) Senate Intel Chair - cyberscoop.com (https://cyberscoop.com/tom-cotton-open-source-software-foreign-influence-national-cyber-director/) Beavertail Malware - scworld.com (https://www.scworld.com/news/north-korean-beavertail-malware-sparks-attacks-across-financial-sector) Open-Source Protein Co-Folding Model - nvidia.com (https://www.nvidia.com/en-us/customer-stories/mit-recursion-open-source-protein-co-folding-model/) Bloom - siliconangle.com (https://siliconangle.com/2025/12/22/anthropic-announces-bloom-open-source-tool-researchers-evaluating-ai-behavior/) CUGA - infoq.com (https://www.infoq.com/news/2025/12/ibm-cuga/) Nemotron AI Models - finance.yahoo.com (https://finance.yahoo.com/news/nvidia-corporation-nvda-launches-family-144517323.html) -- The Extra Credit Section -- For links to the articles and material referenced in this week's episode check out this week's page from our podcast dashboard! This Episode's Podcast Dashboard (http://podcast.asknoahshow.com/472) Phone Systems for Ask Noah provided by Voxtelesys (http://www.voxtelesys.com/asknoah) Join us in our dedicated chatroom #GeekLab:linuxdelta.com on Matrix (https://element.linuxdelta.com/#/room/#geeklab:linuxdelta.com) -- Stay In Touch -- Find all the resources for this show on the Ask Noah Dashboard Ask Noah Dashboard (http://www.asknoahshow.com) Need more help than a radio show can offer? Altispeed provides commercial IT services and they're excited to offer you a great deal for listening to the Ask Noah Show. Call today and ask about the discount for listeners of the Ask Noah Show! Altispeed Technologies (http://www.altispeed.com/) Contact Noah live [at] asknoahshow.com -- Twitter -- Noah - Kernellinux (https://twitter.com/kernellinux) Ask Noah Show (https://twitter.com/asknoahshow) Altispeed Technologies (https://twitter.com/altispeed)

Solaris Blueraven is an independent researcher and commentator focused on the disclosure of covert and advanced technologies operating beyond public awareness. Her work explores classified aerospace systems, black-budget projects, suppressed energy technologies, and the intersection of military, corporate, and intelligence interests that shape technological secrecy. Through careful analysis of historical patterns, whistleblower testimony, and emerging data, Solaris examines how hidden technologies may already be influencing global power structures, surveillance, and the future of humanity. Her perspective invites serious inquiry into what has been developed in secrecy—and what disclosure could mean for society at large.Become a supporter of this podcast: https://www.spreaker.com/podcast/the-x-zone-radio-tv-show--1078348/support.Please note that all XZBN radio and/or television shows are Copyright © REL-MAR McConnell Meda Company, Niagara, Ontario, Canada – www.rel-mar.com. For more Episodes of this show and all shows produced, broadcasted and syndicated from REL-MAR McConell Media Company and The 'X' Zone Broadcast Network and the 'X' Zone TV Channell, visit www.xzbn.net. For programming, distribution, and syndication inquiries, email programming@xzbn.net.We are proud to announce the we have launched TWATNews.com, launched in August 2025.TWATNews.com is an independent online news platform dedicated to uncovering the truth about Donald Trump and his ongoing influence in politics, business, and society. Unlike mainstream outlets that often sanitize, soften, or ignore stories that challenge Trump and his allies, TWATNews digs deeper to deliver hard-hitting articles, investigative features, and sharp commentary that mainstream media won't touch.These are stories and articles that you will not read anywhere else.Our mission is simple: to expose corruption, lies, and authoritarian tendencies while giving voice to the perspectives and evidence that are often marginalized or buried by corporate-controlled media

Many people think of the Akashic Records as a system of files existing in the astral plane, difficult to reach by anyone but trained readers.But Galactic Historian Debbie Solaris describes it as an energetic space that anyone can set an intention to connect with.This means that while Akashic Record channelers are especially skilled in retrieving and interpreting this data, we ALL have the capacity to access infinite troves of cosmic information!This brand new episode is a DEEP dive into the Akashic Records - a first for Soul Guide Radio! Tune in as I sit down with world-renowned Galactic Historian, Akashic Records Channeler, and Starseed Intuitive Debbie Solaris for a FASCINATING conversation about the impact of the Galactic Akashic Records on humanity, our cosmic origins and hidden histories, and Debbie's take on where we're headed as a collective. You'll discover:What is included in the Akashic Records and the benefits of accessing themHow you can plug into your own Akashic RecordsThe trauma that we carry from past multidimensional lifetimesAbout Debbie: Debbie Solaris is a Galactic Historian, Akashic Records Channeler, and Starseed Intuitive known for her grounded approach to cosmic wisdom. After a transformative extraterrestrial contact experience, she awakened to her star lineage and began receiving extensive galactic and spiritual downloads. Through readings, classes, and multimedia presentations, she helps others remember their divine origins and soul mission. Affectionately called the “Galactic Wikipedia,” Debbie has been featured on Gaia TV and numerous podcasts, shows, and events worldwide.Timestamps:00:00 Welcome02:09 Meet Debbie Solaris: Galactic Historian06:25 Understanding the Akashic Records10:52 Accessing the Akashic Records16:25 The Power of the Akashic Records21:45 Exploring Different Star Systems34:58 Understanding Galactic History and Its Impact38:40 Predictions for Earth's Future and Extraterrestrial Contact49:22 InvitationConnect with Debbie: Website: www.debbiesolaris.com YouTube: https://www.youtube.com/user/sydkat7 Instagram: https://www.instagram.com/debbiesolaris/STAY CONNECTED: Soul Guide Circle: JOIN the Soul Guide Circle closed Facebook Group Facebook: FOLLOW on Facebook Instagram: FOLLOW on Instagram YouTube: Follow in YouTube Ready to grow a prosperous soul-guided business? BOOK a free Intuitive Consult Leave a review for Soul Guide Radio (and we'll read it on the air!)

„Als ich den Roman gelesen habe, habe ich sofort das Surren der Raumstation gehört.“ Kein Wunder, dass Schauspieler und Regisseur Christian Friedel auch die Musik zu seiner „Solaris“-Inszenierung schreiben wollte. Zusammen mit seiner Band Woods of Birnam hat er die 15 teils düsteren, teils melancholischen Songs jetzt veröffentlicht. Und er bleibt dem Genre treu: Gerade erst hat Friedel seinen ersten Science Fiction-Film abgedreht. Nicht zum letzten Mal, wie er hofft: „Man sagt immer, ich habe ein historisches Gesicht, aber ich finde, es passt auch gut in die Zukunft.“

We Review: Jay Kelly, One Fine Day, Out of Sight, Ocean's Eleven, Michael Clayton, Batman & Robin, Solaris (2002)One of our last "classic movie stars" is out with a new film that looks back on the legacy of a fictional classic movie star. We review the new George Clooney film Jay Kelly and then discuss our George Clooney top 3s and hot takes.Subscribe on YouTube:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠www.youtube.com/@moviesshapedpod⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠follow us:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠www.instagram.com/moviesshapedpod/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Subscribe to the pod on Spotify:https://open.spotify.com/show/6ShPbVNVFjyxHVHch8JtYqSubscribe to the pod on Apple Podcasts:https://podcasts.apple.com/us/podcast/movies-that-shaped-us/id1591109094 Follow us:https://www.instagram.com/moviesshapedpodChapters:00:00:00 Intro00:01:00 George Clooney Thoughts00:13:30 Jay Kelly00:40:06 Batman & Robin00:49:03 One Fine Day01:00:07 Out of Sight01:08:10 Ocean's Eleven01:16:52 Solaris (2002)01:23:57 Michael Clayton01:33:21 What Should He Do Next?01:36:50 Next Episode Preview & Outro

Sonce na Zemljo pošlje vsakodnevno dovolj energije, da bi z njo lahko pokrili vse potrebe človeštva po njej in še mnogo več. A kljub temu je danes povsem očitno, da se tovrstna 'energetska enačba' - vsaj za zdaj - nikakor ne izide v obojestransko zadovoljstvo človeštva in planeta.Morda pa bi se lahko naslonili na že stoletje in več stare ideje Hermana Potočnika Noordunga in Nikole Tesle ter prestregli potrebno energijo, ki prihaja s Sonca, kar v Zemljini orbiti? Nad atmosfero je fotonov mnogo več kot na površju, oblakov tam ni in paneli bi načeloma lahko zbirali energijo 24 ur na dan ter jo pošiljali na izbrano lokacijo na Zemlji. O tem resno razmišljajo pri Nasi in v drugih vesoljskih agencijah, vse več je tudi ambicioznih podjetij, ki stavijo na to, da so prav orbitalne elektrarne tisti pravi odgovor na dilemo brezogljične prihodnosti skupaj z obiljem električne energije.Kje je danes na tem področju meja med fantastiko in realno možnim, v Intelekti razmišljajo dr. Uroš Kerin, direktor Elektroinštituta Milana Vidmarja, izr. prof. dr. Marko Jošt s Fakultete za elektrotehniko Univerze v Ljubljani ter prof. dr. Mihael Sekavčnik s Fakultete za strojništvo Univerze v Ljubljani.Foto: umetniška upodobitev prenosa energije z orbite na Zemljo, projekt Solaris, ESA

Gäst: Ayan Yamal Supporta Kult: Patreon.com/branne  Standup-Turné Minirundan med Ahmed Berhan & Isak Jansson 2026 https://minirundan.se  Min Special "Har jag Fel?" https://www.youtube.com/watch?v=rI07ehmgU3o&t=5s  En Torpeds Bekännelser Redux https://www.youtube.com/watch?v=JZQCSRvukQ8   Kommande filmer:  Training Day (Patreonlåst) Sagan om de två tornen Solaris

Within the studio's ‘Invent and Integrate' design approach, Mask Architects has unveiled a fully self-chargeable solar motorcycle named Solaris. At its core, Solaris looks a little bit like any other bike, but upon charging, retractable photovoltaic wings unfold, collecting rich sunlight to supply energy to the bike's lithium storage unit.The project serves as an exploration of autonomous mobility, focusing on vehicles capable of generating their own power without relying on fuel, charging networks, or electrical grids. When parked, Solaris effectively becomes its own charging station, operating independently and supporting site-free energy use. This technical foundation is paired with a distinctive biomimetic design philosophy.

Artist: Tayu (Russia) Name: Live@Solaris | 2025 Genre: Electronic Release Date: 24.11.2025 Exclusive: Deep House Moscow Tayu: @tayumusique Instagram: www.instagram.com/tayumusique Follow us: www.facebook.com/deephousemsk/ www.instagram.com/deephousemoscow/ vk.com/deephousemsk/

Travel with Jim back to the psychedelic, genre-bending 1960s—the decade that transformed speculative fiction forever. In this episode, we're counting down the best fantasy and science-fiction villains from every single year of the '60s, pairing one fantasy foe and one sci-fi threat for each year from 1960 to 1969.From the unknowable mind of Solaris… to the terror of the Huntsmen of Annuvin… to HAL 9000's chilling calm… this decade gave us some of the most iconic villains ever written. Join us for a journey through New Wave sci-fi, mythic British fantasy, cosmic dread, dystopian nightmares, and legendary paperback classics.Tell us YOUR favorite villain from the era! So many to choose from…If you enjoy these deep-dives, don't forget to like, subscribe, and ring the bell so you never miss an episode. And if you want to help support the channel and get bonus perks, behind-the-scenes access, and more, check out our Patreon!:

In the Pulse of Franconia: A View of the Nuremberg Underground Scene Far away from the commercial glitter world, where honest music beats to the rhythm of the city, we illuminate the pulsating Nuremberg underground scene. Our expedition leads us deep into the electronic hemisphere of the Franconian metropolis, in search of the "hottest shit"—the authentic and unadulterated sounds that define the true sound of Nuremberg. Amidst the urban fabric, away from mainstream hotspots like Die Rakete or Hirsch—which serve as established venues—lies an oasis of creative independence: the collective nb grooves. This artist collective has made it its mission to consolidate the underground culture and give it a common platform, always focusing on local players and the interplay of different genres and crews. nb grooves is more than just an event organizer; it is a center of gravity for those whose roots are deeply anchored in the underground. Whether it's the unconventional beats of Ivan le Mutant or Trip Inc, the profound soundscapes of Wartenberg, or the energetic sets of Stefan Riegauf and Hannoi—they all embody the essential energy and the courage for the niche that distinguishes this scene. They create a counter-world where the music itself is the headliner. Rts.fm is taking a close look at these currents. We inspect the scene in its purest, most original form, searching for the direct, unadulterated, and true musical expression of this city. It is a sonic retrospective, an archaeological search for the frequencies that shape Nuremberg and its Franconian surroundings beyond the popular buzz. Our goal is to peel back the layers and give a voice to those artists whose works most authentically reflect the raw and passionate soul of electronic music. Stefan Riegauf The Nuremberg native, born in Schwabach in 1972, turned his love for music into a profession early on. His passion for vinyl and electronic music led to his first steps as DJ Solaris at the legendary Prime Rose Club in Nuremberg. In 1996, he opened his own record store, "Recordstore," together with Stefan Volkert (Warren). With him, he also organized events like "SoundLab" at Desi for several years and formed the DJ duo Warren & Solaris. From 2003, he was the literal heart of the Nuremberg techno and house club "Die Rakete" (The Rocket), which he successfully co-managed until 2020. As a Rakete resident, his warm and organic sound, somewhere between House and Techno, evolved there. With empathy for the dancefloor, an instinct for the right track at the right time, and influences from Dub, Acid, and Electronica, he always manages to span a large arc across his sets. For his own event series "Super Klub," he invited fellow DJs such as Levon Vincent, Subb-An, Gerd Janson, Barnt, and many more. His monthly event series "Mitkete" at the "Mitte Soundbar" was also a constant fixture of Nuremberg's nightlife for years. Since 2014, he has been releasing tracks produced with Markus Homm on labels such as Bondage, Cyclic, and Brise, including remixes by Mihai Popoviciu and Schlepp Geist. With nearly 30 years of experience behind the decks, he repeatedly manages to create surprising moments and transmit a positive vibe. Links: Stefan Riegauf https://www.instagram.com/dj_stefan_riegauf/ Better Times https://www.instagram.com/bettertimesnbg/ NBGrooves https://www.instagram.com/nbgrooves/

AI Cheating?, O, Canada, npms, passkeys, Exchange, Solaris, the amazing Rob Allen of Threatlocker, and More on this edition of the Security Weekly News. Segment Resources: Ingram Micro Working Through Ransomware Attack by SafePay Group | MSSP Alert: https://www.msspalert.com/news/ingram-micro-working-through-ransomware-attack-by-safepay-group This segment is sponsored by ThreatLocker. Visit https://securityweekly.com/threatlocker to learn more about them! Visit https://www.securityweekly.com/swn for all the latest episodes! Show Notes: https://securityweekly.com/swn-525

Ian Clark, founder and CEO of Activation Products (code: BIOHACKINGBRITTANY), unpacks why iodine sits at the center of metabolic health, thyroid function, and oral ecology — and how simple mineral habits can shift energy, hormones, teeth and gums, and even pregnancy outcomes.  We dive into iodine vs iodide, receptor "blockers" like fluoride and chlorine, Solaris for the mouth, and how to build results-driven routines without overwhelm. This episode is perfect for busy moms and women who want simple, pregnancy-smart mineral habits to boost thyroid energy, clear brain fog, and strengthen teeth and gums—without complex stacks or overwhelm. WE TALK ABOUT:  07:40 - Why iodine is important for your health 11:35 - Iodine vs. iodide and the form your body actually uses 15:40 - Pregnancy and postpartum priorities for iodine sufficiency 16:45 - The surprising story behind today's low iodine RDA 27:55 - Beating plaque at home with a minimalist mineral routine 39:50 - Minerals as root-cause medicine: Iodine, magnesium, selenium 46:10 - Mom-proof health shifts: Tiny habits, big wins 50:35 - Start-here essentials: A simple, affordable mineral toolkit 59:00 - Daily practices for maintaining "perfect health" biomarkers SPONSORS: Feeling bloated, tired, or hormonally off? Try BiOptimizers — supplements that actually absorb and work for women's health. Get 15% off at bioptimizers.com/biohackingbrittany with code BIOHACKINGBRITTANY. Join me in Costa Rica for Optimize Her, a 5-night luxury women's retreat in Costa Rica with yoga, healing rituals, and biohacking workshops—only 12 spots available. RESOURCES: Trying to conceive? Join my Baby Steps Course to optimize your fertility with biohacking. Free gift: Download my hormone-balancing, fertility-boosting chocolate recipe. Explore my luxury retreats and wellness events for women. Shop my faves: Check out my Amazon storefront for wellness essentials. Activation Products' website (get 15% discount with code: BIOHACKINGBRITTANY) Ian Clark's Instagram LET'S CONNECT: Instagram, TikTok, Facebook Shop my favorite health products Listen on Spotify, Apple Podcasts, YouTube Music

AI Cheating?, O, Canada, npms, passkeys, Exchange, Solaris, the amazing Rob Allen of Threatlocker, and More on this edition of the Security Weekly News. Segment Resources: Ingram Micro Working Through Ransomware Attack by SafePay Group | MSSP Alert: https://www.msspalert.com/news/ingram-micro-working-through-ransomware-attack-by-safepay-group This segment is sponsored by ThreatLocker. Visit https://securityweekly.com/threatlocker to learn more about them! Show Notes: https://securityweekly.com/swn-525

AI Cheating?, O, Canada, npms, passkeys, Exchange, Solaris, the amazing Rob Allen of Threatlocker, and More on this edition of the Security Weekly News. Segment Resources: Ingram Micro Working Through Ransomware Attack by SafePay Group | MSSP Alert: https://www.msspalert.com/news/ingram-micro-working-through-ransomware-attack-by-safepay-group This segment is sponsored by ThreatLocker. Visit https://securityweekly.com/threatlocker to learn more about them! Visit https://www.securityweekly.com/swn for all the latest episodes! Show Notes: https://securityweekly.com/swn-525

AI Cheating?, O, Canada, npms, passkeys, Exchange, Solaris, the amazing Rob Allen of Threatlocker, and More on this edition of the Security Weekly News. Segment Resources: Ingram Micro Working Through Ransomware Attack by SafePay Group | MSSP Alert: https://www.msspalert.com/news/ingram-micro-working-through-ransomware-attack-by-safepay-group This segment is sponsored by ThreatLocker. Visit https://securityweekly.com/threatlocker to learn more about them! Show Notes: https://securityweekly.com/swn-525

Caskey Russell's novel The Door on the Sea (Solaris, 2025) follows Elan, the youngest member of once revered Flicker Clan, on a journey to find a weapon that can defend his people from the shapeshifting Koosh invaders threatening their existence. To reach his goal, Elan must captain a canoe crewed by an unlikely team and force the cooperation of a raven who is the only one who knows the weapon's location. Throughout their journey, the crew must navigate an increasingly hostile political landscape, as the Koosh invasion throws old laws and alliances into disarray. In this interview, Russell describes the process of developing the novel over several years and the ways that he built a world inspired by nineteenth century Tlingit culture. We discuss survivalist elements in fantasy, shifting relationships with violence, and the role of journeys and quest in fantasy. The Door on the Sea is an engaging, thoughtful story and it was so much fun discussing it with the author. Learn more about your ad choices. Visit megaphone.fm/adchoices Support our show by becoming a premium member! https://newbooksnetwork.supportingcast.fm/new-books-network

Caskey Russell's novel The Door on the Sea (Solaris, 2025) follows Elan, the youngest member of once revered Flicker Clan, on a journey to find a weapon that can defend his people from the shapeshifting Koosh invaders threatening their existence. To reach his goal, Elan must captain a canoe crewed by an unlikely team and force the cooperation of a raven who is the only one who knows the weapon's location. Throughout their journey, the crew must navigate an increasingly hostile political landscape, as the Koosh invasion throws old laws and alliances into disarray. In this interview, Russell describes the process of developing the novel over several years and the ways that he built a world inspired by nineteenth century Tlingit culture. We discuss survivalist elements in fantasy, shifting relationships with violence, and the role of journeys and quest in fantasy. The Door on the Sea is an engaging, thoughtful story and it was so much fun discussing it with the author. Learn more about your ad choices. Visit megaphone.fm/adchoices Support our show by becoming a premium member! https://newbooksnetwork.supportingcast.fm/literature

Caskey Russell's novel The Door on the Sea (Solaris, 2025) follows Elan, the youngest member of once revered Flicker Clan, on a journey to find a weapon that can defend his people from the shapeshifting Koosh invaders threatening their existence. To reach his goal, Elan must captain a canoe crewed by an unlikely team and force the cooperation of a raven who is the only one who knows the weapon's location. Throughout their journey, the crew must navigate an increasingly hostile political landscape, as the Koosh invasion throws old laws and alliances into disarray. In this interview, Russell describes the process of developing the novel over several years and the ways that he built a world inspired by nineteenth century Tlingit culture. We discuss survivalist elements in fantasy, shifting relationships with violence, and the role of journeys and quest in fantasy. The Door on the Sea is an engaging, thoughtful story and it was so much fun discussing it with the author. Learn more about your ad choices. Visit megaphone.fm/adchoices Support our show by becoming a premium member! https://newbooksnetwork.supportingcast.fm/fantasy

SUNSET TO SUNRISE: Autumnal Equinox Special

Elizabeth Figura is a Wine developer at Code Weavers. We discuss how Wine and Proton make it possible to run Windows applications on other operating systems. Related links WineHQ Proton Crossover Direct3D MoltenVK XAudio2 Mesa 3D Graphics Library Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today I am talking to Elizabeth Figuera. She's a wine developer at Code Weavers. And today we're gonna talk about what that is and, uh, all the work that goes into it. [00:00:09] Elizabeth: Thank you Jeremy. I'm glad to be here. What's Wine [00:00:13] Jeremy: I think the first thing we should talk about is maybe saying what Wine is because I think a lot of people aren't familiar with the project. [00:00:20] Elizabeth: So wine is a translation layer. in fact, I would say wine is a Windows emulator. That is what the name originally stood for. it re implements the entire windows. Or you say win 32 API. so that programs that make calls into the API, will then transfer that code to wine and and we allow that Windows programs to run on, things that are not windows. So Linux, Mac, os, other operating systems such as Solaris and BSD. it works not by emulating the CPU, but by re-implementing every API, basically from scratch and translating them to their equivalent or writing new code in case there is no, you know, equivalent. System Calls [00:01:06] Jeremy: I believe what you're doing is you're emulating system calls. Could you explain what those are and, and how that relates to the project? [00:01:15] Elizabeth: Yeah. so system call in general can be used, referred to a call into the operating system, to execute some functionality that's built into the operating system. often it's used in the context of talking to the kernel windows applications actually tend to talk at a much higher level, because there's so much, so much high level functionality built into Windows. When you think about, as opposed to other operating systems that we basically, we end up end implementing much higher level behavior than you would on Linux. [00:01:49] Jeremy: And can you give some examples of what some of those system calls would be and, I suppose how they may be higher level than some of the Linux ones. [00:01:57] Elizabeth: Sure. So of course you have like low level calls like interacting with a file system, you know, created file and read and write and such. you also have, uh, high level APIs who interact with a sound driver. [00:02:12] Elizabeth: There's, uh, one I was working on earlier today, called XAudio where you, actually, you know, build this bank of of sounds. It's meant to be, played in a game and then you can position them in various 3D space. And the, and the operating system in a sense will, take care of all of the math that goes into making that work. [00:02:36] Elizabeth: That's all running on your computer and. And then it'll send that audio data to the sound card once it's transformed it. So it sounds like it's coming from a certain space. a lot of other things like, you know, parsing XML is another big one. That there's a lot of things. The, there, the, the, the space is honestly huge [00:02:59] Jeremy: And yeah, I can sort of see how those might be things you might not expect to be done by the operating system. Like you gave the example of 3D audio and XML parsing and I think XML parsing in, in particular, you would've thought that that would be something that would be handled by the, the standard library of whatever language the person was writing their application as. [00:03:22] Jeremy: So that's interesting that it's built into the os. [00:03:25] Elizabeth: Yeah. Well, and languages like, see it's not, it isn't even part of the standard library. It's higher level than that. It's, you have specific libraries that are widespread but not. Codified in a standard, but in Windows you, in Windows, they are part of the operating system. And in fact, there's several different, XML parsers in the operating system. Microsoft likes to deprecate old APIs and make new ones that do the same thing very often. [00:03:53] Jeremy: And something I've heard about Windows is that they're typically very reluctant to break backwards compatibility. So you say they're deprecated, but do they typically keep all of them still in there? [00:04:04] Elizabeth: It all still It all still works. [00:04:07] Jeremy: And that's all things that wine has to implement as well to make sure that the software works as well. [00:04:14] Jeremy: Yeah. [00:04:14] Elizabeth: Yeah. And, and we also, you know, need to make it work. we also need to implement those things to make old, programs work because there is, uh, a lot of demand, at least from, at least from people using wine for making, for getting some really old programs, working from the. Early nineties even. What people run with Wine (Productivity, build systems, servers) [00:04:36] Jeremy: And that's probably a good, thing to talk about in terms of what, what are the types of software that, that people are trying to run with wine, and what operating system are they typically using? [00:04:46] Elizabeth: Oh, in terms of software, literally all kinds, any software you can imagine that runs on Windows, people will try to run it on wine. So we're talking games, office software productivity, software accounting. people will run, build systems on wine, build their, just run, uh, build their programs using, on visual studio, running on wine. people will run wine on servers, for example, like software as a service kind of things where you don't even know that it's running on wine. really super domain specific stuff. Like I've run astronomy, software, and wine. Design, computer assisted design, even hardware drivers can sometimes work unwind. There's a bit of a gray area. How games are different [00:05:29] Jeremy: Yeah, it's um, I think from. Maybe the general public, or at least from what I've seen, I think a lot of people's exposure to it is for playing games. is there something different about games versus all those other types of, productivity software and office software that, that makes supporting those different. [00:05:53] Elizabeth: Um, there's some things about it that are different. Games of course have gotten a lot of publicity lately because there's been a huge push, largely from valve, but also some other companies to get. A lot of huge, wide range of games working well under wine. And that's really panned out in the, in a way, I think, I think we've largely succeeded. [00:06:13] Elizabeth: We've made huge strides in the past several years. 5, 5, 10 years, I think. so when you talk about what makes games different, I think, one thing games tend to do is they have a very limited set of things they're working with and they often want to make things run fast, and so they're working very close to the me They're not, they're not gonna use an XML parser, for example. [00:06:44] Elizabeth: They're just gonna talk directly as, directly to the graphics driver as they can. Right. And, and probably going to do all their own sound design. You know, I did talk about that XAudio library, but a lot of games will just talk directly as, directly to the sound driver as Windows Let some, so this is a often a blessing, honestly, because it means there's less we have to implement to make them work. when you look at a lot of productivity applications, and especially, the other thing that makes some productivity applications harder is, Microsoft makes 'em, and They like to, make a library, for use in this one program like Microsoft Office and then say, well, you know, other programs might use this as well. Let's. Put it in the operating system and expose it and write an API for it and everything. And maybe some other programs use it. mostly it's just office, but it means that office relies on a lot of things from the operating system that we all have to reimplement. [00:07:44] Jeremy: Yeah, that's somewhat counterintuitive because when you think of games, you think of these really high performance things that that seem really complicated. But it sounds like from what you're saying, because they use the lower level primitives, they're actually easier in some ways to support. [00:08:01] Elizabeth: Yeah, certainly in some ways, they, yeah, they'll do things like re-implement the heap allocator because the built-in heap allocator isn't fast enough for them. That's another good example. What makes some applications hard to support (Some are hard, can't debug other people's apps) [00:08:16] Jeremy: You mentioned Microsoft's more modern, uh, office suites. I, I've noticed there's certain applications that, that aren't supported. Like, for example, I think the modern Adobe Creative Suite. What's the difference with software like that and does that also apply to the modern office suite, or is, or is that actually supported? [00:08:39] Elizabeth: Well, in one case you have, things like Microsoft using their own APIs that I mentioned with Adobe. That applies less, I suppose, but I think to some degree, I think to some degree the answer is that some applications are just hard and there's, and, and there's no way around it. And, and we can only spend so much time on a hard application. I. Debugging things. Debugging things can get very hard with wine. Let's, let me like explain that for a minute because, Because normally when you think about debugging an application, you say, oh, I'm gonna open up my debugger, pop it in, uh, break at this point, see what like all the variables are, or they're not what I expect. Or maybe wait for it to crash and then get a back trace and see where it crashed. And why you can't do that with wine, because you don't have the application, you don't have the symbols, you don't have your debugging symbols. You don't know anything about the code you're running unless you take the time to disassemble and decompile and read through it. And that's difficult every time. It's not only difficult, every time I've, I've looked at a program and been like, I really need to just. I'm gonna just try and figure out what the program is doing. [00:10:00] Elizabeth: It takes so much time and it is never worth it. And sometimes you have to, sometimes you have no other choice, but usually you end up, you ask to rely on seeing what calls it makes into the operating system and trying to guess which one of those is going wrong. Now, sometimes you'll get lucky and it'll crash in wine code, or sometimes it'll make a call into, a function that we don't implement yet, and we know, oh, we need to implement that function. But sometimes it does something, more obscure and we have to figure out, well, like all of these millions of calls it made, which one of them is, which one of them are we implementing incorrectly? So it's returning the wrong result or not doing something that it should. And, then you add onto that the. You know, all these sort of harder to debug things like memory errors that we could make. And it's, it can be very difficult and so sometimes some applications just suffer from those hard bugs. and sometimes it's also just a matter of not enough demand for something for us to spend a lot of time on it. [00:11:11] Elizabeth: Right. [00:11:14] Jeremy: Yeah, I can see how that would be really challenging because you're, like you were saying, you don't have the symbols, so you don't have the source code, so you don't know what any of this software you're supporting, how it was actually written. And you were saying that I. A lot of times, you know, there may be some behavior that's wrong or a crash, but it's not because wine crashed or there was an error in wine. [00:11:42] Jeremy: so you just know the system calls it made, but you don't know which of the system calls didn't behave the way that the application expected. [00:11:50] Elizabeth: Exactly. Test suite (Half the code is tests) [00:11:52] Jeremy: I can see how that would be really challenging. and wine runs so many different applications. I'm, I'm kind of curious how do you even track what's working and what's not as you, you change wine because if you support thousands or tens thousands of applications, you know, how do you know when you've got a, a regression or not? [00:12:15] Elizabeth: So, it's a great question. Um, probably over half of wine by like source code volume. I actually actually check what it is, but I think it's, i, I, I think it's probably over half is what we call is tests. And these tests serve two purposes. The one purpose is a regression test. And the other purpose is they're conformance tests that test, that test how, uh, an API behaves on windows and validates that we are behaving the same way. So we write all these tests, we run them on windows and you know, write the tests to check what the windows returns, and then we run 'em on wine and make sure that that matches. and we have just such a huge body of tests to make sure that, you know, we're not breaking anything. And that every, every, all the code that we, that we get into wine that looks like, wow, it's doing that really well. Nope, that's what Windows does. The test says so. So pretty much any code that we, any new code that we get, it has to have tests to validate, to, to demonstrate that it's doing the right thing. [00:13:31] Jeremy: And so rather than testing against a specific application, seeing if it works, you're making a call to a Windows system call, seeing how it responds, and then making the same call within wine and just making sure they match. [00:13:48] Elizabeth: Yes, exactly. And that is obviously, or that is a lot more, automatable, right? Because otherwise you have to manually, you know, there's all, these are all graphical applications. [00:14:02] Elizabeth: You'd have to manually do the things and make sure they work. Um, but if you write automateable tests, you can just run them all and the machine will complain at you if it fails it continuous integration. How compatibility problems appear to users [00:14:13] Jeremy: And because there's all these potential compatibility issues where maybe a certain call doesn't behave the way an application expects. What, what are the types of what that shows when someone's using software? I mean, I, I think you mentioned crashes, but I imagine there could be all sorts of other types of behavior. [00:14:37] Elizabeth: Yes, very much so. basically anything, anything you can imagine again is, is what will happen. You can have, crashes are the easy ones because you know when and where it crashed and you can work backwards from there. but you can also get, it can, it could hang, it could not render, right? Like maybe render a black screen. for, you know, for games you could very frequently have, graphical glitches where maybe some objects won't render right? Or the entire screen will be read. Who knows? in a very bad case, you could even bring down your system and we usually say that's not wine's fault. That's the graphics library's fault. 'cause they're not supposed to do that, uh, no matter what we do. But, you know, sometimes we have to work around that anyway. but yeah, there's, there's been some very strange and idiosyncratic bugs out there too. [00:15:33] Jeremy: Yeah. And like you mentioned that uh, there's so many different things that could have gone wrong that imagine's very difficult to find. Yeah. And when software runs through wine, I think, Performance is comparable to native [00:15:49] Jeremy: A lot of our listeners will probably be familiar with running things in a virtual machine, and they know that there's a big performance impact from doing that. [00:15:57] Jeremy: How does the performance of applications compare to running natively on the original Windows OS versus virtual machines? [00:16:08] Elizabeth: So. In theory. and I, I haven't actually done this recently, so I can't speak too much to that, but in theory, the idea is it's a lot faster. so there, there, is a bit of a joke acronym to wine. wine is not an emulator, even though I started out by saying wine is an emulator, and it was originally called a Windows emulator. but what this basically means is wine is not a CPU emulator. It doesn't, when you think about emulators in a general sense, they're often, they're often emulators for specific CPUs, often older ones like, you know, the Commodore emulator or an Amiga emulator. but in this case, you have software that's written for an x86 CPU. And it's running on an x86 CPU by giving it the same instructions that it's giving on windows. It's just that when it says, now call this Windows function, it calls us instead. So that all should perform exactly the same. The only performance difference at that point is that all should perform exactly the same as opposed to a, virtual machine where you have to interpret the instructions and maybe translate them to a different instruction set. The only performance difference is going to be, in the functions that we are implementing themselves and we try to, we try to implement them to perform. As well, or almost as well as windows. There's always going to be a bit of a theoretical gap because we have to translate from say, one API to another, but we try to make that as little as possible. And in some cases, the operating system we're running on is, is just better than Windows and the libraries we're using are better than Windows. [00:18:01] Elizabeth: And so our games will run faster, for example. sometimes we can, sometimes we can, do a better job than Windows at implementing something that's, that's under our purview. there there are some games that do actually run a little bit faster in wine than they do on Windows. [00:18:22] Jeremy: Yeah, that, that reminds me of how there's these uh, gaming handhelds out now, and some of the same ones, they have a, they either let you install Linux or install windows, or they just come with a pre-installed, and I believe what I've read is that oftentimes running the same game on both operating systems, running the same game on Linux, the battery life is better and sometimes even the performance is better with these handhelds. [00:18:53] Jeremy: So it's, it's really interesting that that can even be the case. [00:18:57] Elizabeth: Yeah, it's really a testament to the huge amount of work that's gone into that, both on the wine side and on the, side of the graphics team and the colonel team. And, and of course, you know, the years of, the years of, work that's gone into Linux, even before these gaming handhelds were, were even under consideration. Proton and Valve Software's role [00:19:21] Jeremy: And something. So for people who are familiar with the handhelds, like the steam deck, they may have heard of proton. Uh, I wonder if you can explain what proton is and how it relates to wine. [00:19:37] Elizabeth: Yeah. So, proton is basically, how do I describe this? So, proton is a sort of a fork, uh, although we try to avoid the term fork. It's a, we say it's a downstream distribution because we contribute back up to wine. so it is a, it is, it is a alternate distribution fork of wine. And it's also some code that basically glues wine into, an embedding application originally intended for steam, and developed for valve. it has also been used in, others, but it has also been used in other software. it, so where proton differs from wine besides the glue part is it has some, it has some extra hacks in it for bugs that are hard to fix and easy to hack around as some quick hacks for, making games work now that are like in the process of going upstream to wine and getting their code quality improved and going through review. [00:20:54] Elizabeth: But we want the game to work now, when we distribute it. So that'll, that'll go into proton immediately. And then once we have, once the patch makes it upstream, we replace it with the version of the patch from upstream. there's other things to make it interact nicely with steam and so on. And yeah, I think, yeah, I think that's, I got it. [00:21:19] Jeremy: Yeah. And I think for people who aren't familiar, steam is like this, um, I, I don't even know what you call it, like a gaming store and a [00:21:29] Elizabeth: store game distribution service. it's got a huge variety of games on it, and you just publish. And, and it's a great way for publishers to interact with their, you know, with a wider gaming community, uh, after it, just after paying a cut to valve of their profits, they can reach a lot of people that way. And because all these games are on team and, valve wants them to work well on, on their handheld, they contracted us to basically take their entire catalog, which is huge, enormous. And trying and just step by step. Fix every game and make them all work. [00:22:10] Jeremy: So, um, and I guess for people who aren't familiar Valve, uh, softwares the company that runs steam, and so it sounds like they've asked, uh, your company to, to help improve the compatibility of their catalog. [00:22:24] Elizabeth: Yes. valve contracted us and, and again, when you're talking about wine using lower level libraries, they've also contracted a lot of other people outside of wine. Basically, the entire stack has had a tremendous, tremendous investment by valve software to make gaming on Linux work. Well. The entire stack receives changes to improve Wine compatibility [00:22:48] Jeremy: And when you refer to the entire stack, like what are some, some of those pieces, at least at a high level. [00:22:54] Elizabeth: I, I would, let's see, let me think. There is the wine project, the. Mesa Graphics Libraries. that's a, that's another, you know, uh, open source, software project that existed, has existed for a long time. But Valve has put a lot of, uh, funding and effort into it, the Linux kernel in various different ways. [00:23:17] Elizabeth: the, the desktop, uh, environment and Window Manager for, um, are also things they've invested in. [00:23:26] Jeremy: yeah. Everything that the game needs, on any level and, and that the, and that the operating system of the handheld device needs. Wine's history [00:23:37] Jeremy: And wine's been going on for quite a while. I think it's over a decade, right? [00:23:44] Elizabeth: I believe. Oh, more than, oh, far more than a decade. I believe it started in 1990, I wanna say about 1995, mid nineties. I'm, I probably have that date wrong. I believe Wine started about the mid nineties. [00:24:00] Jeremy: Mm. [00:24:00] Elizabeth: it's going on for three decades at this rate. [00:24:03] Jeremy: Wow. Okay. [00:24:06] Jeremy: And so all this time, how has the, the project sort of sustained itself? Like who's been involved and how has it been able to keep going this long? [00:24:18] Elizabeth: Uh, I think as is the case with a lot of free software, it just, it just keeps trudging along. There's been. There's been times where there's a lot of interest in wine. There's been times where there's less, and we are fortunate to be in a time where there's a lot of interest in it. we've had the same maintainer for almost this entire, almost this entire existence. Uh, Alexander Julliard, there was one person starting who started, maintained it before him and, uh, left it maintainer ship to him after a year or two. Uh, Bob Amstat. And there has been a few, there's been a few developers who have been around for a very long time. a lot of developers who have been around for a decent amount of time, but not for the entire duration. And then a very, very large number of people who come and submit a one-off fix for their individual application that they want to make work. [00:25:19] Jeremy: How does crossover relate to the wine project? Like, it sounds like you had mentioned Valve software hired you for subcontract work, but crossover itself has been around for quite a while. So how, how has that been connected to the wine project? [00:25:37] Elizabeth: So I work for, so the, so the company I work for is Code Weavers and, crossover is our flagship software. so Code Weavers is a couple different things. We have a sort of a porting service where companies will come to us and say, can we port my application usually to Mac? And then we also have a retail service where Where we basically have our own, similar to Proton, but you know, older, but the same idea where we will add some hacks into it for very difficult to solve bugs and we have a, a nice graphical interface. And then, the other thing that we're selling with crossover is support. So if you, you know, try to run a certain application and you buy crossover, you can submit a ticket saying this doesn't work and we now have a financial incentive to fix it. You know, we'll try to, we'll try to fix your, we'll spend company resources to fix your bug, right? So that's been so, so code we v has been around since 1996 and crossover, I don't know the date, but it's crossover has been around for probably about two decades, if I'm not mistaken. [00:27:01] Jeremy: And when you mention helping companies port their software to, for example, MacOS. [00:27:07] Jeremy: Is the approach that you would port it natively to MacOS APIs or is it that you would help them get it running using wine on MacOS? [00:27:21] Elizabeth: Right. That's, so that's basically what makes us so unique among porting companies is that instead of rewriting their software, we just, we just basically stick it inside of crossover and, uh, and, and make it run. [00:27:36] Elizabeth: And the idea has always been, you know, the more we implement, the more we get correct, the, the more applications will, you know, work. And sometimes it works out that way. Sometimes not really so much. And there's always work we have to do to get any given application to work, but. Yeah, so it's, it's very unusual because we don't ask companies for any of their code. We don't need it. We just fix the windows API [00:28:07] Jeremy: And, and so in that case, the ports would be let's say someone sells a MacOS version of their software. They would bundle crossover, uh, with their software. [00:28:18] Elizabeth: Right? And usually when you do this, it doesn't look like there's crossover there. Like it just looks like this software is native, but there is soft, there is crossover under the hood. Loading executables and linked libraries [00:28:32] Jeremy: And so earlier we were talking about how you're basically intercepting the system calls that these binaries are making, whether that's the executable or the, the DLLs from Windows. Um, but I think probably a lot of our listeners are not really sure how that's done. Like they, they may have built software, but they don't know, how do I basically hijack, the system calls that this application is making. [00:29:01] Jeremy: So maybe you could talk a little bit about how that works. [00:29:04] Elizabeth: So there, so there's a couple steps to go into it. when you think about a program that's say, that's a big, a big file that's got all the machine code in it, and then it's got stuff at the beginning saying, here's how the program works and here's where in the file the processor should start running. that's, that's your EXE file. And then in your DLL files are libraries that contain shared code and you have like a similar sort of file. It says, here's the entry point. That runs this function, this, you know, this pars XML function or whatever have you. [00:29:42] Elizabeth: And here's this entry point that has the generate XML function and so on and so forth. And, and, then the operating system will basically take the EXE file and see all the bits in it. Say I want to call the pars XML function. It'll load that DLL and hook it up. So it, so the processor ends up just seeing jump directly to this pars XML function and then run that and then return and so on. [00:30:14] Elizabeth: And so what wine does, is it part of wine? That's part of wine is a library, is that, you know, the implementing that parse XML and read XML function, but part of it is the loader, which is the part of the operating system that hooks everything together. And when we load, we. Redirect to our libraries. We don't have Windows libraries. [00:30:38] Elizabeth: We like, we redirect to ours and then we run our code. And then when you jump back to the program and yeah. [00:30:48] Jeremy: So it's the, the loader that's a part of wine. That's actually, I'm not sure if running the executable is the right term. [00:30:58] Elizabeth: no, I think that's, I think that's a good term. It's, it's, it's, it starts in a loader and then we say, okay, now run the, run the machine code and it's executable and then it runs and it jumps between our libraries and back and so on. [00:31:14] Jeremy: And like you were saying before, often times when it's trying to make a system call, it ends up being handled by a function that you've written in wine. And then that in turn will call the, the Linux system calls or the MacOS system calls to try and accomplish the, the same result. [00:31:36] Elizabeth: Right, exactly. [00:31:40] Jeremy: And something that I think maybe not everyone is familiar with is there's this concept of user space versus kernel space. you explain what the difference is? [00:31:51] Elizabeth: So the way I would explain, the way I would describe a kernel is it's the part of the operating system that can do anything, right? So any program, any code that runs on your computer is talking to the processor, and the processor has to be able to do anything the computer can do. [00:32:10] Elizabeth: It has to be able to talk to the hardware, it has to set up the memory space. That, so actually a very complicated task has to be able to switch to another task. and, and, and, and basically talk to another program and. You have to have something there that can do everything, but you don't want any program to be able to do everything. Um, not since the, not since the nineties. It's about when we realized that we can't do that. so the kernel is a part that can do everything. And when you need to do something that requires those, those permissions that you can't give everyone, you have to talk to the colonel and ask it, Hey, can you do this for me please? And in a very restricted way where it's only the safe things you can do. And a degree, it's also like a library, right? It's the kernel. The kernels have always existed, and since they've always just been the core standard library of the computer that does the, that does the things like read and write files, which are very, very complicated tasks under the hood, but look very simple because all you say is write this file. And talk to the hardware and abstract away all the difference between different drivers. So the kernel is doing all of these things. So because the kernel is a part that can do everything and because when you think about the kernel, it is basically one program that is always running on your computer, but it's only one program. So when a user calls the kernel, you are switching from one program to another and you're doing a lot of complicated things as part of this. You're switching to the higher privilege level where you can do anything and you're switching the state from one program to another. And so it's a it. So this is what we mean when we talk about user space, where you're running like a normal program and kernel space where you've suddenly switched into the kernel. [00:34:19] Elizabeth: Now you're executing with increased privileges in a different. idea of the process space and increased responsibility and so on. [00:34:30] Jeremy: And, and so do most applications. When you were talking about the system calls for handling 3D audio or parsing XML. Are those considered, are those system calls considered part of user space and then those things call the kernel space on your behalf, or how, how would you describe that? [00:34:50] Elizabeth: So most, so when you look at Windows, most of most of the Windows library, the vast, vast majority of it is all user space. most of these libraries that we implement never leave user space. They never need to call into the kernel. there's the, there only the core low level stuff. Things like, we need to read a file, that's a kernel call. when you need to sleep and wait for some seconds, that's a kernel. Need to talk to a different process. Things that interact with different processes in general. not just allocate memory, but allocate a page of memory, like a, from the memory manager and then that gets sub allocated by the heap allocator. so things like that. [00:35:31] Jeremy: Yeah, so if I was writing an application and I needed to open a file, for example, does, does that mean that I would have to communicate with the kernel to, to read that file? [00:35:43] Elizabeth: Right, exactly. [00:35:46] Jeremy: And so most applications, it sounds like it's gonna be a mixture. You're gonna have a lot of things that call user space calls. And then a few, you mentioned more low level ones that are gonna require you to communicate with the kernel. [00:36:00] Elizabeth: Yeah, basically. And it's worth noting that in, in all operating systems, you're, you're almost always gonna be calling a user space library. That might just be a thin wrapper over the kernel call. It might, it's gonna do like just a little bit of work in end call the kernel. [00:36:19] Jeremy: [00:36:19] Elizabeth: In fact, in Windows, that's the only way to do it. Uh, in many other operating systems, you can actually say, you can actually tell the processor to make the kernel call. There is a special instruction that does this and just, and it'll go directly to the kernel, and there's a defined interface for this. But in Windows, that interface is not defined. It's not stable. Or backwards compatible like the rest of Windows is. So even if you wanted to use it, you couldn't. and you basically have to call into the high level libraries or low level libraries, as it were, that, that tell you that create a file. And those don't do a lot. [00:37:00] Elizabeth: They just kind of tweak their parameters a little and then pass them right down to the kernel. [00:37:07] Jeremy: And so wine, it sounds like it needs to implement both the user space calls of windows, but then also the, the kernel, calls as well. But, but wine itself does that, is that only in Linux user space or MacOS user space? [00:37:27] Elizabeth: Yes. This is a very tricky thing. but all of wine, basically all of what is wine runs in, in user space and we use. Kernel calls that are already there to talk to the colonel, to talk to the host Colonel. You have to, and you, you get, you get, you get the sort of second nature of thinking about the Windows, user space and kernel. [00:37:50] Elizabeth: And then there's a host user space and Kernel and wine is running all in user, in the user, in the host user space, but it's emulating the Windows kernel. In fact, one of the weirdest, trickiest parts is I mentioned that you can run some drivers in wine. And those drivers actually, they actually are, they think they're running in the Windows kernel. which in a sense works the same way. It has libraries that it can load, and those drivers are basically libraries and they're making, kernel calls and they're, they're making calls into the kernel library that does some very, very low level tasks that. You're normally only supposed to be able to do in a kernel. And, you know, because the kernel requires some privileges, we kind of pretend we have them. And in many cases, you're even the drivers are using abstractions. We can just implement those abstractions kind of over the slightly higher level abstractions that exist in user space. [00:39:00] Jeremy: Yeah, I hadn't even considered the being able to use hardware devices, but I, I suppose if in, in the end, if you're reproducing the kernel, then whether you're running software or you're talking to a hardware device, as long as you implement the calls correctly, then I, I suppose it works. [00:39:18] Elizabeth: Cause you're, you're talking about device, like maybe it's some kind of USB device that has drivers for Windows, but it doesn't for, for Linux. [00:39:28] Elizabeth: no, that's exactly, that's a, that's kind of the, the example I've used. Uh, I think there is, I think I. My, one of my best success stories was, uh, drivers for a graphing calculator. [00:39:41] Jeremy: Oh, wow. [00:39:42] Elizabeth: That connected via USB and I basically just plugged the windows drivers into wine and, and ran it. And I had to implement a lot of things, but it worked. But for example, something like a graphics driver is not something you could implement in wine because you need the graphics driver on the host. We can't talk to the graphics driver while the host is already doing so. [00:40:05] Jeremy: I see. Yeah. And in that case it probably doesn't make sense to do so [00:40:11] Elizabeth: Right? [00:40:12] Elizabeth: Right. It doesn't because, the transition from user into kernel is complicated. You need the graphics driver to be in the kernel and the real kernel. Having it in wine would be a bad idea. Yeah. [00:40:25] Jeremy: I, I think there's, there's enough APIs you have to try and reproduce that. I, I think, uh, doing, doing something where, [00:40:32] Elizabeth: very difficult [00:40:33] Jeremy: right. Poor system call documentation and private APIs [00:40:35] Jeremy: There's so many different, calls both in user space and in kernel space. I imagine the, the user space ones Microsoft must document to some extent, but, oh. Is that, is that a [00:40:51] Elizabeth: well, sometimes, [00:40:54] Jeremy: Sometimes. Okay. [00:40:55] Elizabeth: I think it's actually better now than it used to be. But some, here's where things get fun, because sometimes there will be, you know, regular documented calls. Sometimes those calls are documented, but the documentation isn't very good. Sometimes programs will just sort of look inside Microsoft's DLLs and use calls that they aren't supposed to be using. Sometimes they use calls that they are supposed to be using, but the documentation has disappeared. just because it's that old of an API and Microsoft hasn't kept it around. sometimes some, sometimes Microsoft, Microsoft own software uses, APIs that were never documented because they never wanted anyone else using them, but they still ship them with the operating system. there was actually a kind of a lawsuit about this because it is an antitrust lawsuit, because by shipping things that only they could use, they were kind of creating a trust. and that got some things documented. At least in theory, they kind of haven't stopped doing it, though. [00:42:08] Jeremy: Oh, so even today they're, they're, I guess they would call those private, private APIs, I suppose. [00:42:14] Elizabeth: I suppose. Uh, yeah, you could say private APIs. but if we want to get, you know, newer versions of Microsoft Office running, we still have to figure out what they're doing and implement them. [00:42:25] Jeremy: And given that they're either, like you were saying, the documentation is kind of all over the place. If you don't know how it's supposed to behave, how do you even approach implementing them? [00:42:38] Elizabeth: and that's what the conformance tests are for. And I, yeah, I mentioned earlier we have this huge body of conformance tests that double is regression tests. if we see an API, we don't know what to do with or an API, we do know, we, we think we know what to do with because the documentation can just be wrong and often has been. Then we write tests to figure out what it's supposed to behave. We kind of guess until we, and, and we write tests and we pass some things in and see what comes out and see what. The see what the operating system does until we figure out, oh, so this is what it's supposed to do and these are the exact parameters in, and, and then we, and, and then we implement it according to those tests. [00:43:24] Jeremy: Is there any distinction in approach for when you're trying to implement something that's at the user level versus the kernel level? [00:43:33] Elizabeth: No, not really. And like I, and like I mentioned earlier, like, well, I mean, a kernel call is just like a library call. It's just done in a slightly different way, but it's still got, you know, parameters in, it's still got a set of parameters. They're just encoded differently. And, and again, like the, the way kernel calls are done is on a level just above the kernel where you have a library, that just passes things through. Almost verbatim to the kernel and we implement that library instead. [00:44:10] Jeremy: And, and you've been working on i, I think, wine for over, over six years now. [00:44:18] Elizabeth: That sounds about right. Debugging and having broad knowledge of Wine [00:44:20] Jeremy: What does, uh, your, your day to day look like? What parts of the project do you, do you work on? [00:44:27] Elizabeth: It really varies from day to day. and I, I, a lot of people, a lot of, some people will work on the same parts of wine for years. Uh, some people will switch around and work on all sorts of different things. [00:44:42] Elizabeth: And I'm, I definitely belong to that second group. Like if you name an area of wine, I have almost certainly contributed a patch or two to it. there's some areas I work on more than others, like, 3D graphics, multimedia, a, I had, I worked on a compiler that exists, uh, socket. So networking communication is another thing I work a lot on. day to day, I kind of just get, I, I I kind of just get a bug for some program or another. and I take it and I debug it and figure out why the program's broken and then I fix it. And there's so much variety in that. because a bug can take so many different forms like I described, and, and, and the, and then the fix can be simple or complicated or, and it can be in really anywhere to a degree. [00:45:40] Elizabeth: being able to work on any part of wine is sometimes almost a necessity because if a program is just broken, you don't know why. It could be anything. It could be any sort of API. And sometimes you can hand the API to somebody who's got a lot of experience in that, but sometimes you just do whatever. You just fix whatever's broken and you get an experience that way. [00:46:06] Jeremy: Yeah, I mean, I was gonna ask about the specialized skills to, to work on wine, but it sounds like maybe in your case it's all of them. [00:46:15] Elizabeth: It's, there's a bit of that. it's a wine. We, the skills to work on wine are very, it's a very unique set of skills because, and it largely comes down to debugging because you can't use the tools you normally use debug. [00:46:30] Elizabeth: You have to, you have to be creative and think about it different ways. Sometimes you have to be very creative. and programs will try their hardest to avoid being debugged because they don't want anyone breaking their copy protection, for example, or or hacking, or, you know, hacking in sheets. They want to be, they want, they don't want anyone hacking them like that. [00:46:54] Elizabeth: And we have to do it anyway for good and legitimate purposes. We would argue to make them work better on more operating systems. And so we have to fight that every step of the way. [00:47:07] Jeremy: Yeah, it seems like it's a combination of. F being able, like you, you were saying, being able to, to debug. and you're debugging not necessarily your own code, but you're debugging this like behavior of, [00:47:25] Jeremy: And then based on that behavior, you have to figure out, okay, where in all these different systems within wine could this part be not working? [00:47:35] Jeremy: And I, I suppose you probably build up some kind of, mental map in your head of when you get a, a type of bug or a type of crash, you oh, maybe it's this, maybe it's here, or something [00:47:47] Elizabeth: Yeah. That, yeah, there is a lot of that. there's, you notice some patterns, you know, after experience helps, but because any bug could be new, sometimes experience doesn't help and you just, you just kind of have to start from scratch. Finding a bug related to XAudio [00:48:08] Jeremy: At sort of a high level, can you give an example of where you got a specific bug report and then where you had to look to eventually find which parts of the the system were the issue? [00:48:21] Elizabeth: one, one I think good example, that I've done recently. so I mentioned this, this XAudio library that does 3D audio. And if you say you come across a bug, I'm gonna be a little bit generics here and say you come across a bug where some audio isn't playing right, maybe there's, silence where there should be the audio. So you kind of, you look in and see, well, where's that getting lost? So you can basically look in the input calls and say, here's the buffer it's submitting that's got all the audio data in it. And you look at the output, you look at where you think the output should be, like, that library will internally call a different library, which programs can interact with directly. [00:49:03] Elizabeth: And this our high level library interacts with that is the, give this sound to the audio driver, right? So you've got XAudio on top of, um. mdev, API, which is the other library that gives audio to the driver. And you see, well, the ba the buffer is that XAudio is passing into MM Dev, dev API. They're empty, there's nothing in them. So you have to kind of work through the XAudio library to see where is, where's that sound getting lost? Or maybe, or maybe that's not getting lost. Maybe it's coming through all garbled. And I've had to look at the buffer and see why is it garbled. I'll open up it up in Audacity and look at the weight shape of the wave and say, huh, that shape of the wave looks like it's, it looks like we're putting silence every 10 nanoseconds or something, or, or reversing something or interpreting it wrong. things like that. Um, there's a lot of, you'll do a lot of, putting in print fs basically all throughout wine to see where does the state change. Where was, where is it? Where is it? Right? And then where do things start going wrong? [00:50:14] Jeremy: Yeah. And in the audio example, because they're making a call to your XAudio implementation, you can see that Okay, the, the buffer, the audio that's coming in. That part is good. It, it's just that later on when it sends it to what's gonna actually have it be played by the, the hardware, that's when missing. So, [00:50:37] Elizabeth: We did something wrong in a library that destroyed the buffer. And I think on a very, high level a lot of debugging, wine is about finding where things are good and finding where things are bad, and then narrowing that down until we find the one spot where things go wrong. There's a lot of processes that go like that. [00:50:57] Jeremy: like you were saying, the more you see these problems, hopefully the, the easier it gets to, to narrow down where, [00:51:04] Elizabeth: Often. Yeah. Especially if you keep debugging things in the same area. How much code is OS specific?c [00:51:09] Jeremy: And wine supports more than one operating system. I, I saw there was Linux, MacOS I think free BSD. How much of the code is operating system specific versus how much can just be shared across all of them? [00:51:27] Elizabeth: Not that much is operating system specific actually. so when you think about the volume of wine, the, the, the, vast majority of it is the high level code that doesn't need to interact with the operating system on a low level. Right? Because Windows keeps putting, because Microsoft keeps putting lots and lots of different libraries in their operating system. And a lot of these are high level libraries. and even when we do interact with the operating system, we're, we're using cross-platform libraries or we're using, we're using ics. The, uh, so all these operating systems that we are implementing are con, basically conformed to the posix standard. which is basically like Unix, they're all Unix based. Psic is a Unix based standard. Microsoft is, you know, the big exception that never did implement that. And, and so we have to translate its APIs to Unix, APIs. now that said, there is a lot of very operating system, specific code. Apple makes things difficult by try, by diverging almost wherever they can. And so we have a lot of Apple specific code in there. [00:52:46] Jeremy: another example I can think of is, I believe MacOS doesn't support, Vulkan [00:52:53] Elizabeth: yes. Yeah.Yeah, That's a, yeah, that's a great example of Mac not wanting to use, uh, generic libraries that work on every other operating system. and in some cases we, we look at it and are like, alright, we'll implement a wrapper for that too, on top of Yuri, on top of your, uh, operating system. We've done it for Windows, we can do it for Vulkan. and that's, and then you get the Molten VK project. Uh, and to be clear, we didn't invent molten vk. It was around before us. We have contributed a lot to it. Direct3d, Vulkan, and MoltenVK [00:53:28] Jeremy: Yeah, I think maybe just at a high level might be good to explain the relationship between Direct 3D or Direct X and Vulcan and um, yeah. Yeah. Maybe if you could go into that. [00:53:42] Elizabeth: so Direct 3D is Microsoft's 3D API. the 3D APIs, you know, are, are basically a way to, they're way to firstly abstract out the differences between different graphics, graphics cards, which, you know, look very different on a hardware level. [00:54:03] Elizabeth: Especially. They, they used to look very different and they still do look very different. and secondly, a way to deal with them at a high level because actually talking to the graphics card on a low level is very, very complicated. Even talking to it on a high level is complicated, but it gets, it can get a lot worse if you've ever been a, if you've ever done any graphics, driver development. so you have a, a number of different APIs that achieve these two goals of, of, abstraction and, and of, of, of building a common abstraction and of building a, a high level abstraction. so OpenGL is the broadly the free, the free operating system world, the non Microsoft's world's choice, back in the day. [00:54:53] Elizabeth: And then direct 3D was Microsoft's API and they've and Direct 3D. And both of these have evolved over time and come up with new versions and such. And when any, API exists for too long. It gains a lot of croft and needs to be replaced. And eventually, eventually the people who developed OpenGL decided we need to start over, get rid of the Croft to make it cleaner and make it lower level. [00:55:28] Elizabeth: Because to get in a maximum performance games really want low level access. And so they made Vulcan, Microsoft kind of did the same thing, but they still call it Direct 3D. they just, it's, it's their, the newest version of Direct 3D is lower level. It's called Direct 3D 12. and, and, Mac looked at this and they decided we're gonna do the same thing too, but we're not gonna use Vulcan. [00:55:52] Elizabeth: We're gonna define our own. And they call it metal. And so when we want to translate D 3D 12 into something that another operating system understands. That's probably Vulcan. And, and on Mac, we need to translate it to metal somehow. And we decided instead of having a separate layer from D three 12 to metal, we're just gonna translate it to Vulcan and then translate the Vulcan to metal. And it also lets things written for Vulcan on Windows, which is also a thing that exists that lets them work on metal. [00:56:30] Jeremy: And having to do that translation, does that have a performance impact or is that not really felt? [00:56:38] Elizabeth: yes. It's kind of like, it's kind of like anything, when you talk about performance, like I mentioned this earlier, there's always gonna be overhead from translating from one API to another. But we try to, what we, we put in heroic efforts to. And try, try to make sure that doesn't matter, to, to make sure that stuff that needs to be fast is really as fast as it can possibly be. [00:57:06] Elizabeth: And some very clever things have been done along those lines. and, sometimes the, you know, the graphics drivers underneath are so good that it actually does run better, even despite the translation overhead. And then sometimes to make it run fast, we need to say, well, we're gonna implement a new API that behaves more like windows, so we can do less work translating it. And that's, and sometimes that goes into the graphics library and sometimes that goes into other places. Targeting Wine instead of porting applications [00:57:43] Jeremy: Yeah. Something I've found a little bit interesting about the last few years is [00:57:49] Jeremy: Developers in the past, they would generally target Windows and you might be lucky to get a Mac port or a Linux port. And I wonder, like, in your opinion now, now that a lot of developers are just targeting Windows and relying on wine or, or proton to, to run their software, is there any, I suppose, downside to doing that? [00:58:17] Jeremy: Or is it all just upside, like everyone should target Windows as this common platform? [00:58:23] Elizabeth: Yeah. It's an interesting question. I, there's some people who seem to think it's a bad thing that, that we're not getting native ports in the same sense, and then there's some people who. Who See, no, that's a perfectly valid way to do ports just right for this defacto common API it was never intended as a cross platform common API, but we've made it one. [00:58:47] Elizabeth: Right? And so why is that any worse than if it runs on a different API on on Linux or Mac and I? Yeah, I, I, I guess I tend to, I, that that argument tends to make sense to me. I don't, I don't really see, I don't personally see a lot of reason for, to, to, to say that one library is more pure than another. [00:59:12] Elizabeth: Right now, I do think Windows APIs are generally pretty bad. I, I'm, this might be, you know, just some sort of, this might just be an effect of having to work with them for a very long time and see all their flaws and have to deal with the nonsense that they do. But I think that a lot of the. Native Linux APIs are better. But if you like your Windows API better. And if you want to target Windows and that's the only way to do it, then sure why not? What's wrong with that? [00:59:51] Jeremy: Yeah, and I think the, doing it this way, targeting Windows, I mean if you look in the past, even though you had some software that would be ported to other operating systems without this compatibility layer, without people just targeting Windows, all this software that people can now run on these portable gaming handhelds or on Linux, Most of that software was never gonna be ported. So yeah, absolutely. And [01:00:21] Elizabeth: that's [01:00:22] Jeremy: having that as an option. Yeah. [01:00:24] Elizabeth: That's kind of why wine existed, because people wanted to run their software. You know, that was never gonna be ported. They just wanted, and then the community just spent a lot of effort in, you know, making all these individual programs run. Yeah. [01:00:39] Jeremy: I think it's pretty, pretty amazing too that, that now that's become this official way, I suppose, of distributing your software where you say like, Hey, I made a Windows version, but you're on your Linux machine. it's officially supported because, we have this much belief in this compatibility layer. [01:01:02] Elizabeth: it's kind of incredible to see wine having got this far. I mean, I started working on a, you know, six, seven years ago, and even then, I could never have imagined it would be like this. [01:01:16] Elizabeth: So as we, we wrap up, for the developers that are listening or, or people who are just users of wine, um, is there anything you think they should know about the project that we haven't talked about? [01:01:31] Elizabeth: I don't think there's anything I can think of. [01:01:34] Jeremy: And if people wanna learn, uh, more about the wine project or, or see what you're up to, where, where should they, where should they head? Getting support and contributing [01:01:45] Elizabeth: We don't really have any things like news, unfortunately. Um, read the release notes, uh, follow some, there's some, there's some people who, from Code Weavers who do blogs. So if you, so if you go to codeweavers.com/blog, there's some, there's, there's some codeweavers stuff, uh, some marketing stuff. But there's also some developers who will talk about bugs that they are solving and. And how it's easy and, and the experience of working on wine. [01:02:18] Jeremy: And I suppose if, if someone's. Interested in like, like let's say they have a piece of software, it's not working through wine. what's the best place for them to, to either get help or maybe even get involved with, with trying to fix it? [01:02:37] Elizabeth: yeah. Uh, so you can file a bug on, winehq.org,or, or, you know, find, there's a lot of developer resources there and you can get involved with contributing to the software. And, uh, there, there's links to our mailing list and IRC channels and, uh, and, and the GitLab, where all places you can find developers. [01:03:02] Elizabeth: We love to help you. Debug things. We love to help you fix things. We try our very best to be a welcoming community and we have got a long, we've got a lot of experience working with people who want to get their application working. So, we would love to, we'd love to have another. [01:03:24] Jeremy: Very cool. Yeah, I think wine is a really interesting project because I think for, I guess it would've been for decades, it seemed like very niche, like not many people [01:03:37] Jeremy: were aware of it. And now I think maybe in particular because of the, the Linux gaming handhelds, like the steam deck,wine is now something that a bunch of people who would've never heard about it before, and now they're aware of it. [01:03:53] Elizabeth: Absolutely. I've watched that transformation happen in real time and it's been surreal. [01:04:00] Jeremy: Very cool. Well, Elizabeth, thank you so much for, for joining me today. [01:04:05] Elizabeth: Thank you, Jeremy. I've been glad to be here.

Beyond Special Love: Awakening to the Light of Divine Identity  This profound movie gathering offers a heartfelt prelude to the Mystical Christ Academy through the movie Solaris. David explores the transformative themes of forgiveness and spiritual awakening. Through insightful commentary, he examines the subtle yet powerful ways the ego uses special relationships to distract us from the truth of our divine nature. David explores the inner conflict between the desire for personal attachments and the call to surrender to the light of God's love. With emotional depth and clarity, he guides listeners through the courageous process of confronting fears, releasing the past, and embracing the peace that arises from genuine spiritual surrender. This episode serves as a heartfelt invitation to let go of illusions and remember the eternal connection we share with God. Recorded live on August 9, 2025, at Casa Quatico, Chapala, Mexico. To participate online in a Movie Gathering, join our online community: https://programs.the-christ.net/courses/membership-weekly-online-movie-gatherings Join our online community:  https://programs.the-christ.net/products/communities/tribe-of-christ Who is David Hoffmeister?: https://davidhoffmeister.com/ If you are interested to know more about David Hoffmeister and Living Miracles events, here is more information:  https://circle.livingmiraclescenter.org/events. Read A Course in Miracles online here: https://acourseinmiraclesnow.com/ Learn more about David Hoffmeister here: https://davidhoffmeister.com

"You mean more to me than any scientific truth." For Episode 373, David and Brandon kick off their Hard Sci-Fi month with Andrei Tarkovsky's SOLARIS. Listen as they discuss Tarkovsky's career before the film, why he wanted to make the movie, what famous sci-fi film the movie was a reaction to, why the original novelist disliked the movie, and more!  Also, don't forget to join our Patreon for more exclusive content: Opening - Gearing up for October and Borrowing Movies -  (00:00:10) Intro to Hard Sci-Fi Movies (00:06:06) Intro to Solaris (00:15:50) How Solaris Got to Production (00:24:38) Favorite Scenes (00:37:00) On Set Life - (01:05:32) Aftermath: Release and Legacy (01:11:41) What Worked and What Didn't (01:19:41) Film Facts (01:25:57) Awards (01:26:39) Final Questions on the Movie (01:31:25) Wrapping Up the Episode (01:37:45) Contact Us: Facebook: @cinenation Instagram: @cinenationpodcast Twitter/X: @CineNationPod TikTok: @cinenation Letterboxd: CineNation Podcast

Hello fiends and familiars! We have come to the conclusion of our Once More with Feeling marathon. This month, we've seen trash, after trash, after trash. Can Steven Soderbergh's Solaris get us out of a rut? Or are we just witnessing fleeting memories of shelvable films? We talk film tones, Soderbergh's proclivities as director, and much, much more. Join us as we take Solaris to the analysis table again!

Join me and special guest Navy Blue on Saturday, August 30 at Loudmouth in Brooklyn, for the ninth iteration of Reel Talk, a Reel Notes movie night. We'll be screening the 1999 animated sci-fi drama The Iron Giant and talking about his latest album, Memoirs in Armour, his production work on Earl Sweatshirt's latest album, Live Laugh Love, and much more. Tickets and more info here.My guest this week is New Jersey-born rapper, producer, director, and humanitarian, GDP. We spoke about Clive Barker's Nightbreed, the magic of independent movie theaters, Solaris, Highest 2 Lowest, Kids, coming up as a rapper and skater in New Jersey, navigating the blog era, looking back on his old music, reflecting on his decade-long break, co-directing a documentary about rapper Tame One, and the creative process behind he and Fatboi Sharif's EP Endocrine, out now via Fused Arrow Records. Come fuck with us.Endocrine is available wherever music is sold, streamed, or stolen. Consider copping directly from GDP's Bandcamp. Follow GDP on Instagram and Twitter: @g6d6p6. Follow Fused Arrow Records on Instagram and Twitter: @fusedarrowrecsMy first book, Reel Notes: Culture Writing on the Margins of Music and Movies, is available now, via 4 PM Publishing. Order a digital copy on Amazon.Reel Notes stands in solidarity with American immigrants against ICE and the oppressed peoples of Palestine, Congo, Sudan, Tigray, and Haiti. Please consider donating to the Coalition for Humane Immigrant Rights, the Palestine Children's Relief Fund,  The Palestinian Youth Movement, The Zakat Foundation, HealAfrica, FreeTigray, and/or Hope For Haiti.  For information about contacting your representatives to demand a ceasefire, finding protests, and other tools, check out CeasefireToday!Follow me on Instagram (@cinemasai), Twitter (@CineMasai_), Bluesky (@cinemasai.bsky.social), TikTok (@cinemasai), Letterboxd (@CineMasai), and subscribe to my weekly Nu Musique Friday newsletter to stay tapped into all things Dylan Green.    Support the show

What if your 60s could feel better than your 20s?   In this episode, I sit down with Ian Clark, founder of Activation Products, who shares his extraordinary journey from life-threatening illness in his 40s to vibrant health and sharp mental clarity well into his 60s, and how you can do the same.   We talk about the biggest health myths holding people back, why you must become the CEO of your own body, and how powerful solutions, like Solaris, can activate the body's repair and detox systems at a cellular level.   If you feel stuck in survival mode, or want to radically shift the way you age, this episode is a masterclass in reclaiming your vitality.   RESOURCES & LINKS: Follow Ian: @ianclarkactivated Follow Activation Products: @activationproducts   THIS SHOW IS BROUGHT TO YOU BY:   ZEOCHARGE Go to zeolitelabs.com and use code IDEAL10 to save 10% on this powerful, broad-spectrum zeolite binder for daily detox support.   ESSENTIAL ENERGY Visit essentialenergy.solutions and use code IDEAL10 to save 10% on their EMF tech, designed to balance and harmonize your body's natural electromagnetic circuit.   OYSTERMAX Head to marinehealthfoods.com and use code IDEAL10 to save 10% on this ultra-pure oyster extract, rich in zinc, copper, vitamin B12, and naturally occurring iodine.   Follow us on Instagram → @idealdayadam

In the science fiction film Solaris (1972), a psychologist is sent to a space station hovering a distant planet to evaluate a crew of scientists suffering from serious emotional disturbances. But when he arrives, he finds the station in disarray and the crew members seemingly disoriented, obstinate, and psychotic.   See the full watch along! https://www.youtube.com/playlist?list=PLG0szTOgxKS4vRzOoQg8PeLVOyakpSG-a   Follow us on Instagram! Dr. Drea Letamendi - @drdreapsychology Brian Ward - @b_ward028 The Arkham Sessions - @thearkhamsessions   Join our Patreon! Patreon.com/ArkhamSessions

PODCAST HIGHLIGHTS:The Akashic & Galactic Astrology secrets shaping humanity's shift into the next age.* Revealed: Star systems and cosmic alignments driving Earth's evolution now.* Planetary transits + ancient prophecies hidden in the Akashic Records.* Chart clues that prove YOU are part of the planetary awakening.Today's guest, Debbie Solaris, is an interdimensional traveler and renowned galactic historian. What if your soul's origins weren't on Earth? Debbie isn't just an ET contactee — she's a galactic historian who reads the stars and the Akashic Records to reveal your true cosmic blueprint. In this episode, you'll discover the map of your soul… and the secrets of humanity's next age. This is one you do not want to miss.

Steven Soderbergh's second release of 2002, after FULL FRONTAL, was another very odd move: a remake of Andrei Tarkovsky's SOLARIS (well, more of a new adaptation of the Stanislaw Lem novel). Underappreciated at the time, Soderbergh's SOLARIS has grown in reputation as one of the great science fiction films of the 2000s - so we brought on a bonafide science fiction expert, Aaron Thorpe, to talk about it! Join us for a thoughtful and wide-ranging conversation about the purpose of science fiction, comprehending the vastness of space, grief, blackness in sci-fi, and OSMOSIS JONES. Don't worry, it's plenty stupid, too. Further Reading: Solaris by Stanislaw Lem Sculpting in Time by Andrei Tarkovsky Tool-Being: Heidegger and the Metaphysics of Objects by Graham Harman Myths of the Near Future by J.G. Ballard Further Viewing: SOLARIS (Tarkovsky, 1972) CONTACT (Zemeckis, 1997) EVENT HORIZON (Anderson, 1997) OSMOSIS JONES (Farrelly, 2001)  STAR TREK: NEMESIS (Baird, 2002) Follow Aaron Thorpe: https://x.com/afrocosmist https://x.com/thetrillbillies https://substack.com/@spacelight Follow Pod Casty For Me: https://www.podcastyforme.com https://twitter.com/podcastyforme https://www.instagram.com/podcastyforme/ https://www.youtube.com/@podcastyforme Support us on Patreon: https://www.patreon.com/PodCastyForMe Artwork by Jeremy Allison: https://www.instagram.com/jeremyallisonart  

Our three co-hosts are stuck in the multiverse and need to get back to their home universe. Clearly, the only way to do that is to explore our cultural obsession with multiverses, alternate timelines and parallel worlds, and tie it all into a conversation about post-modern art, pop culture, and the lessons these stories teach us. Also, each episode, one of them is an asshole who will probably sabotage the whole thing. This week we discuss 1972's Solaris, directed by Andrei Tarkovsky! Features: Michael Swaim: https://bsky.app/profile/michaelswaim.bsky.social Adam Ganser: https://bsky.app/profile/ganz.bsky.social Abe Epperson: https://bsky.app/profile/abeepp.bsky.social Support Small Beans and access Additional Content: https://www.patreon.com/SmallBeans Check our store to buy Small Beans merch! https://www.teepublic.com/stores/the-small-beans-store?ref_id=22691