WEBVTT 00:00.000 --> 00:12.560 So, today we will talk about how we develop our money for the last four years, and first 00:12.560 --> 00:16.360 of all the things about myself. 00:16.360 --> 00:33.240 So, my name is Andrew, I help with many years of experience doing different stuff. 00:33.240 --> 00:43.280 I do redhead based something for 13 years already, and I am a money architect from the day one. 00:43.280 --> 00:49.040 So, why the person who asked questions about why I am going to sit this way or another, 00:49.040 --> 00:54.000 because I basically was involved in every decision made. 00:54.000 --> 01:02.480 So, as it said previously, yesterday we surveyed four years, first our first public release, 01:02.480 --> 01:12.560 it was, yeah, so it was 8.3, better, a purple manu, and it was released like exactly 01:12.560 --> 01:22.640 55 days after it had an announcement about like Santos Linux 8 and the 5, and in the beginning 01:22.640 --> 01:29.040 it was like, it's very early stage, so we had just one architecture, it was Intel obviously, 01:29.040 --> 01:34.560 we were exactly at head loan, we didn't have any secure boot support, we didn't have any 01:34.640 --> 01:41.040 euros yet, we did the cafe new rattle opens cup, but Santos never have themselves kind of fine. 01:42.000 --> 01:48.880 Anyway, we during four years we changed everything about this, except obviously 55 days we can't 01:48.880 --> 01:57.840 change the past. So, today we're talking about, I'm a municipal system, and it's our way to build packages 01:57.840 --> 02:03.680 for seven architecture already, how we maintain images, we maintain a lot of them, and we try to 02:03.680 --> 02:09.600 maintain the easiest way, the most transparent way, to make it easier to contribute to them, 02:10.400 --> 02:18.960 how we unwoked upgrades inside the enterprise new secure systems, because in the personal 02:18.960 --> 02:22.960 Linux, it's not possible to just do the NF update and go from seven to age, for example. 02:24.720 --> 02:33.280 How we decided on why the decided to stop being rattle on, how we bring back devices support, 02:34.320 --> 02:44.960 how we decided to run on older CPUs and what had runs, and our future plans, so let's start. 02:46.480 --> 02:53.440 Every since starts here, so we build a package in our build system that we develop to make for 02:55.120 --> 03:01.040 all this for years, obviously, we develop it. It's a context of several companies, 03:01.040 --> 03:05.360 core components are there, so it's a server from 10 build node sign node, some file, 03:05.360 --> 03:10.880 the difference between sign node and sign file is that sign node is dedicated for RPM sign in, 03:10.880 --> 03:17.760 sign file is just a little service to sign and you rent them file, like RAPOMD or checksum file, 03:17.760 --> 03:23.920 with PGP, we have used a lot of open source projects, obviously, and there's a hood that 03:23.920 --> 03:30.720 one of the projects I want to talk about is pop, so pop is basically a certified storage, 03:31.040 --> 03:35.680 so it allows us to store RAPOMD packages, Python models and so on, 03:36.880 --> 03:44.400 organize them into RAPOMD and it's used by RAPOMD for many years, it's now used by Fedora Cooper, 03:44.400 --> 03:49.680 and also it's used by Almanus build system, so basically we decided to build our 03:49.760 --> 03:58.960 system around RAPOMD storage. Why we need it? What's wrong with God? Nothing wrong with 03:58.960 --> 04:04.800 them, but we just have our own vision, we have a lot of the experience doing packages and builds 04:04.800 --> 04:10.640 and so on, so that's why we decided to have our own build system and well, it's a way we want, 04:11.280 --> 04:16.720 and what we can do, so we can build, obviously, for some architecture, now we can build for 04:16.720 --> 04:24.480 RAPOMD as well, we can build models, kind of think from RAPOMD 8 and 9 generations, 04:26.080 --> 04:33.120 we can sign a binary responsible for Intel and ARM architecture, so we can release build images, 04:33.120 --> 04:39.600 Intel, build packages into RAPOMD storage and export to file systems and to primary mirrors and 04:39.600 --> 04:45.440 to mirrors around the world, we can collect security advisers from RAPOMD Head, 04:45.440 --> 04:52.080 public sources, modify them, and provide in different ways, and also now we can do our own 04:52.080 --> 04:59.840 advisers because sometimes, as not being RAPOMD anymore, we can do CV fixes much earlier. 05:01.520 --> 05:08.720 So, cool thing about power here, so how we resolve this, we don't need to rebuild the whole 05:08.720 --> 05:16.400 RAPOMD, it's a whole recompose, so it has to add us, so it has to include updates, we just can 05:16.400 --> 05:22.640 with public and just add RAPOMD packages to RAPOMD and then see it, so how it works here, so 05:23.280 --> 05:31.360 in container CDs, when you release packages, so it allows you to basically see where packages 05:31.360 --> 05:40.720 goes, so as you can see, you have storage source package, both to source RAPOMD, like no architecture 05:40.720 --> 05:46.080 RAPOMD goes to make any architecture, this particular package is a small CD package, so it goes to 05:46.080 --> 05:57.040 32 bits and 64 bits, and other packages goes to corresponding architecture, and we decide where to 05:57.040 --> 06:01.200 place package, like base of a sub-sumer or whatever, because we monitor ourselves and we monitor 06:01.920 --> 06:08.560 and send to a stream, so we see where packages will place it and place the same way. 06:10.400 --> 06:15.680 So, as for security patching, so the threat provides public data for it, so it's not a problem for 06:15.680 --> 06:23.120 us to get security information, it's available in API, it's available in all feed, which is 06:23.200 --> 06:30.000 deprecated right now, but still available, it's about a new way called VAX documents, RSS fees, 06:30.000 --> 06:35.360 and this information is totally not for us to work with our libraries, because it has IDs, 06:35.360 --> 06:41.680 descriptions, CVs, whatever, so what we can do later, so we collect this information from it 06:41.680 --> 06:49.120 have put into this UI, and here, when container can control what we release, packages might 06:49.360 --> 06:54.960 do changes to title, description, whatever, if it's necessary to to brand something, so 06:57.760 --> 07:04.320 so yes, and that how it release to public, and also recently, because we started to 07:04.320 --> 07:09.840 release in a base before it had we need our own way to release security advisor, so basically 07:09.840 --> 07:17.280 we can create just new security advisor with an informational one there, and then when it's created 07:17.280 --> 07:23.680 we can public in different ways, so we public them to our other side, to mailing these to our 07:23.680 --> 07:29.680 says feed, we public to our specific format, just on, and also it used by several security 07:29.680 --> 07:34.560 planners, we still publish them to overall feed, and we're not going to deprecate this, 07:35.680 --> 07:42.000 I hope that info.xml, which we included in any dnf repo, and to work with dnf 07:42.640 --> 07:49.840 to on user site, and always visit a base is kind of a new model, a Google thing, for example, 07:51.040 --> 07:59.600 release of dnfs in this format. Next topic for today is images, so we release a lot of images 07:59.600 --> 08:06.480 of different kinds, and we try to build them easier for our community and contributors, so first 08:06.560 --> 08:12.960 of all, obviously, we need to build types of images, but because we don't use corgi anywhere, 08:12.960 --> 08:19.520 we have to punch it all, which is used by the patterns and so on, so we patch it to not use 08:19.520 --> 08:27.600 and not provide to corgi, so our fork is available, anyone can use it, also we obviously 08:27.600 --> 08:31.920 will provide our configuration files, and to make things easier, we also provide guide 08:32.000 --> 08:38.560 how to build and might be obsessed to images yourself. For container images for Docker podman, 08:38.560 --> 08:45.360 so we build them in GitHub actions, to make it super easy for everyone, to contribute there, 08:45.360 --> 08:51.760 so it's possible to build for any architecture, we push them to Docker hub to acquire a lot of 08:51.760 --> 08:56.880 GitHub packages, and we create poor quest to Docker official library because obviously we are 08:56.880 --> 09:09.360 official image server, wife media images also created in GitHub actions, so no problem, so we build 09:09.360 --> 09:14.400 for into an entire RAM, we upload types of images and logs to Amazon history market, and we also 09:14.400 --> 09:20.640 announce these builds in our like chat channel of live media sick, so everyone can try it 09:20.640 --> 09:28.400 then before they will appear publicly for everyone who knows, perhaps, Raspberry Pi, and we also 09:28.400 --> 09:35.040 support Raspberry Pi files, a five-facing Google has the first RPM based distribution who started to 09:35.040 --> 09:43.200 support it, so I also build completely in GitHub actions, we are easy to contribute, I also publish 09:43.200 --> 09:51.840 to history, and chat channel. According to the program images, a lot of them will build, so 09:51.840 --> 10:01.360 open-step, open-name of Azure Amazon, Oracle, GCP, we don't build them because Google do that on their 10:01.360 --> 10:08.880 sites, so send to them, and the program images of any kind, including images for a RAM, for Apple, 10:08.880 --> 10:16.560 Silicon Maps, Macs, for VMware Fusion, and Parallels, this part is not really good, I might 10:16.560 --> 10:21.120 do it right now, obviously we have a lot of configurations and scripts, but we need to automate 10:21.120 --> 10:26.000 it in GitHub actions, so if you have good GitHub actions, you can help us with this. 10:29.840 --> 10:37.360 Some two with the first I think, we released almalinux is almalinux depot 2 because we created this 10:37.360 --> 10:48.320 project with sentoS7, 8 and 5 in mind, so we know that there are a lot of systems with sentoS6, sentoS8, 10:48.320 --> 10:53.760 available, so we need to integrate them without any reviews, without any problems, so we provide 10:53.760 --> 11:02.640 two for that, and we provide migration guide, how to do that, and with this two you can go from any 11:02.640 --> 11:08.960 8 across the system to almalinux, and from any 9 across the system to almalinux 9, but what you need 11:08.960 --> 11:16.480 to do if you want to jump from one version to another, so we decided to start to elevate 11:16.480 --> 11:23.200 project for this, so because we knew that sentoS7 and the 5 is also expected pretty soon, so 11:23.520 --> 11:32.720 it based on route ahead leap for in work, so it has to migrate as route 7 to 8 for example, 11:33.360 --> 11:42.320 but this still doesn't allow to use anything but route ahead, and it doesn't support 11:42.320 --> 11:47.920 search patching levels, and it's very hard to find the system production without Apple Rep, for example, 11:48.800 --> 11:57.360 so we think that so we maintain our version of this tool that supports non-retreat distribution, 11:57.360 --> 12:05.680 so it's actually not only up not all the almalinux, so we support all of them, and we support several 12:05.680 --> 12:12.080 reports, like Apple, Docker, MariaDB and whatever, and it's really easy to contribute there if you want 12:12.800 --> 12:22.000 to extend this list, so currently support pass as a following, so almalinux, so S10 isn't better yet, 12:22.000 --> 12:31.600 so it's not kind of recommended, but sentoS3n is available a target, so you can go all the 12:31.600 --> 12:38.640 way from sentoS6 to sentoS3n can, I can say it would be easy, but this will save some mental health 12:38.640 --> 12:48.160 for you definitely, so yes, so we maintain the repository report for that, you can contribute there, 12:48.160 --> 12:52.800 and configuration data, like Rep or files, like in 1000 configurations has stored in the 12:52.800 --> 12:59.840 leak data, so yes, and there is a contribution guide which shows exactly how to sort of 12:59.840 --> 13:05.520 put your report to evaluate the make it work, so during first them we were requested for 13:06.720 --> 13:11.440 RP Infusion, for example, so we are ready for such contributions as well, 13:13.760 --> 13:20.960 everything was fine before this, so in 2000, 23, it had decided not to upload 13:20.960 --> 13:30.640 like package sources anymore to sendoSGit and they only available behind subscription, it's not a 13:30.640 --> 13:36.240 problem, I mean to get subscription developer subscription allows it, it's not a problem even to 13:36.240 --> 13:41.440 buy subscription, the problem is that this subscription agreement doesn't allow it to use this 13:41.440 --> 13:50.320 sources for your distribution, so we took our time to think about agmalinux viewers and decided 13:50.320 --> 14:02.480 that is right, because we are fine, sources is not a big problem by the way, because we still have 14:02.480 --> 14:09.600 40% about 40% of them from RATKTBI, it's exactly RATKT sources, they are public, they are legal, 14:09.600 --> 14:18.720 everything is fine, and we took other of 60% from packages from sentoS3M, the way that RATKT 14:18.720 --> 14:25.280 does that, I mean we don't sendoS3M rebuild, so almalinux is a little bit behind sentoS3M, 14:25.280 --> 14:33.200 exactly the same way as RATKT behind sentoS3M, so sources is not a problem, we have them, 14:35.040 --> 14:43.520 but what is cool now, I do not be in RATKT clone, so we can do bug fixes earlier, 14:44.000 --> 14:50.800 because sometimes community members come to us and say, please fix this, and before that we said, 14:50.800 --> 14:56.960 oh we can't, because we are at RATKT clone, we need to fix this in RATKT first, but now we can fix this ourselves, 14:58.160 --> 15:05.520 the same situation was vulnerability, and also as a distribution developer, we have 15:06.080 --> 15:12.480 ability to get information without vulnerability's earlier, then they will come public, so we 15:12.480 --> 15:21.040 prepare it for this, and also we have some derivatives, all right, so we have done strings, 15:21.040 --> 15:29.120 and we need, we can now propose them to include their specific changes to almalinux, of course, 15:29.120 --> 15:36.640 if they don't affect almalinux users in any way, to move this part to us and let them focus on their 15:36.640 --> 15:44.000 work, and also we can include more device drivers to support other hardware, so I will show you 15:44.560 --> 15:51.200 how we do that, so let's go one by one bug fixes, one case in November we were contacted about 15:51.200 --> 15:59.920 the zip to update, so this update basically, security updates that RATKT made, break, broken, 15:59.920 --> 16:06.240 like that interface test, so we were contacted by the zip developer about this, he said, 16:07.520 --> 16:13.680 you should apply another patch from upstream to make it work and explain this situation, 16:14.560 --> 16:22.480 so we took three days for us to release update, a great issue in RATKT GERR, and send 16:22.480 --> 16:34.800 who requests for CentOS Stream 8 and 9 to fix this, and then actually RATKT 9 never got this update 16:34.800 --> 16:43.280 anyway, but RATKT 8 got this update several days ago, so little bit longer, so for some time we were 16:43.280 --> 16:51.360 only one with working zip to, as for security, this happened sometimes, I think our first case was 16:51.360 --> 16:58.880 a ZenBlit vulnerability in AMD processors, so we started extensive testing of Linux firmware 16:58.880 --> 17:06.800 of the package update with our community, and did update on July this year, like that year, 17:07.520 --> 17:17.040 and update appear in RATKT, like two months later, and recent example is open SSH, 17:17.040 --> 17:24.400 vulnerability, so thanks to developers, like my little list, we have this information before, 17:24.400 --> 17:32.960 so we were able to release update, like two days before RATKT, is it one kind of an also 17:32.960 --> 17:40.160 appropriate, but it's enough to talk to the system of us, so and for the RATKT if CS, we can help 17:40.160 --> 17:45.600 them do their work, I think the most popular RATKT right now is 12 Linux, so decided to use 17:45.600 --> 17:52.240 my Linux repos and my Linux build packages in their products since version 8.5, and just focus on 17:52.240 --> 18:01.680 their work, so yes, and one of the examples is called in it package, for example, so we may 18:01.680 --> 18:06.960 end up maintaining parts in our money, so we maintain parts to both our money and so they don't 18:06.960 --> 18:14.160 need to rebuild it, so this happens sometimes with the RATKT, and for additional hardware, yes, 18:14.160 --> 18:20.800 a lot of users started noticing that when they tried to migrate from 10 to 7 to 8, for example, 18:20.800 --> 18:26.560 a lot of old storage devices stopped working for them, and the same for network devices, so we 18:26.560 --> 18:34.240 calibrated with a RATKT project which provides models for such drivers, for such devices, and just 18:34.240 --> 18:42.320 merged this to Almalinux stock kernel for this particular drivers, and this cover, I mean, almost 18:42.320 --> 18:51.600 all cases like this, so yes, how to do that, we maintain several patches in Almalinux stock kernel, 18:51.600 --> 18:59.600 so first patch is global patch to allow you to just move all the disabled PCI-IDs to unmentantly, 18:59.600 --> 19:06.640 so now it works and says that drivers not maintained, which is true, but it still works, which is great, 19:07.440 --> 19:15.680 and also we maintain several specific patches for several specific drivers to enable additional 19:15.680 --> 19:23.440 PCI-IDs there. So yeah, I was special enough, I think, but then we decided, okay, how to do 19:23.440 --> 19:29.680 more special things, how to bring major changes, how to test them, how to be better prepared for 19:29.680 --> 19:35.040 next major release, and we did an Almalinux kit and announced it in October of last year, 19:36.160 --> 19:41.680 so what is it? It doesn't have any minor versions, it's based on sentoestring, 19:41.840 --> 19:48.720 then sources supported at least five years, just like them, it's our recommendation for better, 19:48.720 --> 19:57.360 and 92% of packages went directly to a wrong kit and to better, and it allows to get 19:57.360 --> 20:02.560 stable updates earlier, just like sentoestring 10 allows to do that for a third, 20:03.600 --> 20:10.640 but from the first day we had a lot of changes, comparison to sendoestring, so it is built 20:10.800 --> 20:16.640 for this framework, it's enabled, so how easily profile and debug your applications, 20:17.360 --> 20:24.560 secure boot is supported for Intel and TMZ, we bring back spice protocol, last for that, 20:24.560 --> 20:30.320 and let's head drop it since, let's head 9, same happened to KVM, 20:30.320 --> 20:37.040 virtualization on an IBM hour, it was dropped, but we brought it back, we support even more, 20:37.600 --> 20:41.520 disabled devices, and we decided to support our traditional architecture, 20:43.200 --> 20:58.880 so basically Red Hatten will start working on CPUs after 2013 and we did it for CPUs after 20:58.880 --> 21:06.880 2008, so basically the same CPUs were Red Hatten 9, or Malin's 9 works, so how to do that, 21:07.600 --> 21:16.160 this level of architectures are supported, so the higher levels, the better CPU you need to work, 21:16.160 --> 21:21.520 so they are supported in RPM, but unfortunately nowhere else, so we had to patch 21:21.520 --> 21:27.200 like 20 packages to make it work in Kitten, so he listed here, so we are going to 21:27.920 --> 21:32.640 contribute this work, for this one, to work for Dora, in the Intel center stream, 21:34.240 --> 21:39.840 there is some other issue with this level of architectures, because this code will 21:39.840 --> 21:44.080 left, it doesn't work for it, for example, because it's not exact, this architecture, 21:44.080 --> 21:50.160 so we have to patch this on our side, but proper decision is to make code looks like a 21:50.240 --> 21:57.440 right block, so we already had conversations about this with Dora guys, and hope they will start 21:58.320 --> 22:04.720 help helping us, so what's our plans for this year, so it's like Al Malinux 10, 22:04.720 --> 22:12.400 stable recently, we started working recently on Al Malinux 10, for this five, and tells 22:12.400 --> 22:21.120 to expect this year, and for several words, we started discussions on technical student committee 22:21.120 --> 22:29.280 level about Apple 10 for V2, because it's nice to have a minus for V2, but without Apple, 22:29.280 --> 22:34.880 like it's kind of not complete, so we also need to build this, so join discussions if you 22:34.880 --> 22:41.360 have something to say, we need to extend our automation to focus on cool stuff, not on our daily 22:41.360 --> 22:46.880 things, and we also are going to improve contributor experience, so more contribution guides, 22:47.680 --> 22:56.240 more deplace and de facto, and whatever, so yes, that's our plans, and this is what we do every 22:56.240 --> 23:04.880 day, this is how we do that, so if you think that it's great, and your hard feels it's great, 23:04.960 --> 23:12.720 so we have a lot of six where you can join, so I build six course six, so just check them out 23:12.720 --> 23:19.840 in our V2, and join what we do, it will be happy to see you there, thank you 23:20.800 --> 23:33.520 you. Do we have any questions? That's an interesting spot, can you please pass it over? 23:38.880 --> 23:44.480 Hi, on the slide for Armandinov's kit, and you had a point saying firefox and thunderbird, 23:44.480 --> 23:51.120 or included, but you didn't strike out, and you didn't say, oh yes, I forgot to mention this obviously, 23:51.120 --> 23:56.080 so yes, from the start we have firefox and thunderbird, but recently we could have decided to 23:56.080 --> 24:05.440 add them as well, so it's not a difference anymore, but obviously we have them. Any more questions? 24:05.680 --> 24:15.120 I was looking for Armandinov's 10 for cloud images, but it was not in the battle, 24:15.120 --> 24:22.800 so I was wondering, is it going to be first released in the release, or would it be like a 24:22.800 --> 24:30.720 pretty release of the cloud images, specifically the generic sounds? So we released cloud images 24:30.800 --> 24:39.280 for Keaton already, so we have them, but not the 10 better, but don't better, okay we can do that. 24:40.640 --> 24:49.840 In Keaton works fine, I was just wondering. Do we have times for the more questions? 24:50.480 --> 24:55.200 One more? Yeah. Any more questions? 24:55.280 --> 25:09.280 Might as well. So, for this claim, I mean, before I ask this question, I work for that head, 25:09.280 --> 25:18.960 but the famous article that I think was Matt Hicks wrote on this continuing in this 25:18.960 --> 25:25.280 center's sources, essentially said, this enables other distributions to make a difference, 25:25.280 --> 25:30.880 and, you know, thank you for that. And so, wouldn't you more or less agree that 25:32.240 --> 25:37.760 because of this decision, Armandinov's is now better than it was before, because it can offer a 25:37.760 --> 25:42.960 difference, and is now added value compared to the largest copy in real? 25:43.040 --> 25:47.680 Yes, personally, I think so. It's better now. Okay, thank you. 25:52.800 --> 25:56.320 That is it, thank you so much.