WEBVTT 00:00.000 --> 00:12.760 All right, let's get started. 00:12.760 --> 00:16.320 So this is going to be the lightning talk on Redox. 00:16.320 --> 00:17.320 Good. 00:17.320 --> 00:18.320 Yeah. 00:18.320 --> 00:19.320 So hello, everyone. 00:19.320 --> 00:20.320 Thank you for coming to my talk. 00:20.320 --> 00:21.320 I'm Jacob. 00:21.320 --> 00:25.560 I'll be giving you a very short introduction to the microchernal-based 00:25.560 --> 00:29.240 unit-like OS Redox. 00:29.240 --> 00:37.160 So essentially, Redox, yeah, Redox tries to be a unit-like operating system built on 00:37.160 --> 00:42.320 top of a microchernal from which much of the post-exenabling functionality is incrementally 00:42.320 --> 00:46.480 and continuously being moved into user-based. 00:46.480 --> 00:51.880 Isn't inspired by many existing OSS, both monolithic and microchernal, like SCL4, the 00:51.880 --> 00:57.040 BSTs, an importantly planned mine, from which much of the file system architecture is 00:57.040 --> 00:59.040 arrived. 00:59.040 --> 01:03.880 Redox has been in community development since 2015, and it's almost exclusively written 01:03.880 --> 01:05.120 in rust. 01:05.120 --> 01:08.520 somewhat ironically, even our C library, a real MC. 01:08.520 --> 01:13.600 There are, of course, some third-party exceptions, like the Z-compiler and WebRoss 01:13.600 --> 01:17.200 and NetSurf, etc. 01:17.200 --> 01:23.600 The portability focus is not primarily on Cisco translation or virtualization, but you 01:23.600 --> 01:32.880 implement post-ex from scratch, and this is on primarily in larger user-based components. 01:32.880 --> 01:38.400 This, along with our maturing really C, has recently allowed porting loss to new applications. 01:38.400 --> 01:44.640 For example, the cost-mix apps have been reused from the cost-mix desktop, and also we've 01:44.640 --> 01:48.920 been able to port lots of regular C and rust software. 01:48.920 --> 01:53.800 A bit about me, I'm an engineering physics student from Sweden, I'm going to read 01:53.800 --> 01:58.720 Ox contributor for a bit now, and I'm currently maintainer as well. 01:58.720 --> 02:05.120 I've been a summer's co-student and worked on I-O, user-space-ified, some previously 02:05.120 --> 02:11.920 kernel things, done to band-paging, and this year also, I've been working on the analytics 02:11.920 --> 02:16.120 project, UNIX-style signals. 02:16.120 --> 02:23.120 You can check on my talk from yesterday to get a more detailed overview of the signal project, 02:23.120 --> 02:27.200 but yeah, that one has been mostly finished. 02:27.200 --> 02:33.600 I said to give a brief explanation of the architecture, again it's a micro-chernel, so the 02:33.600 --> 02:39.040 things that normally would have been in kernel space on a monitor-thic kernel, instead 02:39.040 --> 02:41.680 of a live-smoking user-space components. 02:41.680 --> 02:48.560 This is on through an IPC protocol that is mostly file-like, so essentially you write these 02:48.560 --> 02:55.240 schemes that sort of behave like fizes and user-space fusa. 02:55.240 --> 02:57.240 Yep. 02:57.240 --> 03:06.600 Yeah, these are called schemes, mostly for historical reasons, they were originally 03:06.640 --> 03:15.520 Euro's schemes, but now they've been sort of downgraded to regular, mom points. 03:15.520 --> 03:20.880 The Cisco API is intentionally unstable, and we hope we didn't break it as much as 03:20.880 --> 03:24.200 possible in the near future. 03:24.200 --> 03:30.840 Normally, a stable API would have made a lot more sense on a monitor-thic kernel, and 03:30.840 --> 03:33.960 this is why Linux-USD presumably. 03:34.000 --> 03:38.360 The burden of supporting old interfaces is not nearly that high when your kernel is 03:38.360 --> 03:45.600 already that huge, but when your kernel is really tiny, old interfaces affected the 03:45.600 --> 03:47.640 entire architecture. 03:47.640 --> 03:53.120 So the way we handle a BI stability, is instead through our C library, so the stable 03:53.120 --> 03:58.640 API is essentially in real-obsit. 03:58.640 --> 04:05.760 Real-obsit is our C library, and it's almost again entirely written in Rust. 04:05.760 --> 04:11.200 Only a few macros, et cetera, are not written in Rust. 04:11.200 --> 04:17.960 Most of the other headers are actually C-bine-gen orders generated, and yeah, the 04:17.960 --> 04:23.000 Rustification has allowed making the code safer, so we can, for example, encode C-strings 04:23.000 --> 04:25.360 using the strong types of stuff. 04:25.360 --> 04:32.040 There is both a Linux backend, which is quite similar to a minimalist C library, like 04:32.040 --> 04:42.960 muscle, which is a thin wrapper of RolsterSchools on Redox, and instead uses the Redox 04:43.040 --> 04:45.680 or key component. 04:45.680 --> 04:54.920 So yeah, as with the status, the POSIX coverage has increased noticeably, recently. 04:54.920 --> 04:59.800 For example, last summer we were able to record the Cophnic apps, so they're now the 04:59.800 --> 05:02.400 defaults. 05:02.400 --> 05:08.680 Also with dynamic linking being closer, we'll be able to improve development speed quite 05:08.760 --> 05:13.360 a lot, and it's also improved the POSIX for self-hosting in the near-future, which still 05:13.360 --> 05:17.440 isn't quite supported. 05:17.440 --> 05:26.240 The signal project will allow for future user-based vacation, having sold one of the 05:26.240 --> 05:35.120 major obstacles to that, and although there are some blocking buggy-scernly nuts stack, 05:35.160 --> 05:40.760 I try this while we go cargo new, followed by cargo ROM, actually works in the 05:40.760 --> 05:44.280 hell of a world example. 05:44.280 --> 05:51.400 The things that currently fail is when you try to fetch creates from the internet and 05:51.400 --> 05:53.960 unpacking large-torables, et cetera. 05:53.960 --> 05:59.000 So yeah, I'll be doing the D-Mail now, let's hope this works. 06:05.120 --> 06:20.320 There's the serial output there, as we have a bunch of user-based applications currently inherited 06:20.320 --> 06:42.880 from Cophnic, we can open, yeah, we can just let we do it itself, and I, yes. 06:50.320 --> 07:17.960 All right, so there is one there. 07:20.320 --> 07:27.320 Can you explain a bit more what has changed with the schemes, because from everything is 07:27.320 --> 07:34.960 the file, we're using everything is URL, so I assume that that was those schemes, and 07:34.960 --> 07:35.960 what has changed there? 07:35.960 --> 07:40.280 Okay, so your question is why we change from everything as a URL to everything as a file, 07:40.280 --> 07:47.400 no, you mentioned that there are some changes in schemes, yeah, from one point I believe, 07:47.400 --> 07:49.120 what has changed there exactly, I do not know. 07:49.120 --> 07:57.440 Yeah, so previously schemes were sort of a top-level mount point, so like a bit similar 07:57.440 --> 08:04.280 to Windows drivers, but with arbitrary names, and they were intended to act as a scheme 08:04.280 --> 08:10.880 part of a URL, so you could for example do second, disk, column, slash, slash, and then 08:10.880 --> 08:18.640 some path, but this colon slash, slash part makes politics compatibility really hard, because 08:18.720 --> 08:24.040 politics allows any character except for the null character and the slash character itself 08:24.040 --> 08:32.560 to be present in a file name, or in a path, and this means we more or less had to abandon 08:32.560 --> 08:36.360 the scheme path format for it to be compatible.