WEBVTT 00:00.000 --> 00:14.960 Hello, hello, okay, we are on. Yes, hello, everyone. So this is one of the Illumus talks. 00:14.960 --> 00:22.000 Talking about one of the more fun features about it, the package manager for Open Solaris. 00:22.000 --> 00:29.840 Things that got forgotten by history, but are very active. I'm known as Tosterson in the 00:29.840 --> 00:35.920 Open Indiana Project. I'm a maintainer of Open Indiana. So I work with IPS for quite a bit. 00:37.920 --> 00:43.680 And when you go to Open Solaris, let you see projects or continuation projects, 00:44.720 --> 00:51.040 you get a whole lot of tools like if a T-Trace, you get your own set-of-ass like this whole package 00:51.840 --> 00:59.520 of very fun things that people like. And there's one thing that people often do not talk about. 00:59.920 --> 01:06.160 And that's IPS, so I'm making a finally after 10 years to talk about it. So somebody keeps 01:06.160 --> 01:12.320 remembering that it exists and actually we can get some more people in, because it's a little bit 01:12.320 --> 01:18.960 different than what you would expect the package manager to be. That's kind of like the good thing, 01:18.960 --> 01:26.080 but it's also like, everybody comes in and it's like, how can I make my post install script and 01:26.080 --> 01:33.760 we're like, we don't have that. Sorry, no post install in this area, this is a completely different approach 01:33.760 --> 01:45.920 to it. So a lot of it goes to the point of like, you have an image and you want to boot that image. 01:45.920 --> 01:53.520 That's what you want to do in an enterprise. Imagine it's 2005, 10-ish. What's the big deal? What's 01:53.520 --> 01:59.920 the big deal on block? If you're thinking VMWare, that's kind of like the deal. It's like VM's coming up. 02:00.960 --> 02:07.920 Windows can finally be run on one more than one Windows per server, physical server. 02:09.120 --> 02:15.600 And of course, VMWare starts like a little images, you throw around that disk file and you boot it and it works. 02:16.560 --> 02:22.560 It doesn't system prep and all that other stuff. Oh boy, we have SVR4. 02:23.760 --> 02:38.640 And yeah, SVR4 was for its time, I think, 80's even it started. The name SVR3 comes from system version 4, 02:39.360 --> 02:46.800 SVR4. It's that packaging. It's developed and it grew an internet part. You could download packages, 02:47.760 --> 02:55.040 also from distributors like IBM. And you could get problems from packages with distributors like IBM. 02:56.800 --> 03:04.880 If anybody has a memory of very tough backup, yeah, see some hands go up, I see something. 03:04.880 --> 03:12.560 Oh, the package was as bad as you could think and it in certain scenarios broke a lot of things. 03:14.080 --> 03:17.680 Which was one of the reasons why IBM got invented the way it did. 03:19.760 --> 03:27.600 Little side note, IPS is a spiritual successor to APT or Debian package manager, 03:28.560 --> 03:37.600 mostly because the chief guy at the time at open scenarios was the guy of Debian. 03:38.240 --> 03:46.160 Also same guy. So he put in a lot of information like repository, centric, like put this all like of the internet. 03:46.160 --> 03:52.880 You need to be able to download the packages and so on. But a lot of more things happen at that time. 03:53.840 --> 04:04.000 So if SVR4 where you have your binary, blob of tar balls or whatever you used to be at the time, 04:04.000 --> 04:11.440 whatever package. And if IPS, you fetch every file individually. So you don't have them collected. 04:11.440 --> 04:15.920 You already have a pair file, they've deduplications, so you don't have multiple, 04:16.480 --> 04:21.360 you don't have to manage the packages, so you get deduplication in the packages. And it's all this like 04:21.520 --> 04:33.120 kind of detail stuff. But the biggest change is it's all image, why are you there? 04:33.120 --> 04:39.680 There you are. Ah, I'm too much here. Okay, better presentations of it. We can do that. 04:40.880 --> 04:48.880 So in open scenarios, with set of SVs, you have what you in 3BSD guys know as put environments. 04:49.440 --> 04:59.440 So IPS hooks into that. It creates put environments for you. So it basically defines the state 04:59.440 --> 05:04.880 of all the files of a put environment, what files need to be on a put environment for a image 05:04.880 --> 05:14.160 to be putable. So you have text-based manifest that like set is all up. You update image, 05:14.720 --> 05:22.320 you run over it, you can even go and fix it. If things got broken, if you have a 1 disc set of 05:22.320 --> 05:28.480 SVs pool and you have it half corrupted, then you could restore 10 files from it. You go set of a 05:28.480 --> 05:37.200 package fix your image. And you would do it because it can. It has a record of what should be on that image. 05:37.840 --> 05:43.920 And that's a very, very different approach to SV4 where, well, what's on the image is what 05:43.920 --> 05:53.200 ever happens at the end of the post install. So that's the main shift. And another thing that we 05:53.200 --> 06:01.680 got introduced is an FMRI. And that's something people outside of the salaries well do not know. 06:01.920 --> 06:11.920 It stands for Fault Management Resource Identifier. Fault Manager is another component in 06:11.920 --> 06:24.560 the system that enables self-healing. And it identifies items uniquely. This storage chassis 06:24.720 --> 06:36.160 is CD-ROM's Bauthafium. And so we have this URL structure to a package. So whenever you say 06:37.200 --> 06:45.440 install GCC-10, it will not install GCC-10 just as the name. It will expand it to the full URL 06:45.440 --> 06:54.000 that it gets like developers, GCC-10. I don't know all URLs on top of my hair because I just say 06:54.000 --> 07:03.520 install GCC-10 and it does it. It's very simple and usage. And we also got introduced multiple 07:04.320 --> 07:11.280 version identifiers. You have the main version of the software. You have the build of the OS for 07:11.280 --> 07:21.920 which that software was built. You have the branch of the specific subOS type where you want to go 07:21.920 --> 07:28.400 if you have like an enterprise sub branch with licensing or something. And what's more happening 07:28.400 --> 07:35.280 in back in enterprise days not really happening today. And you then have a time step at the 07:35.280 --> 07:41.040 end so you know which one is current. But you could have all these packages in the same repository, 07:41.040 --> 07:49.200 in the same publisher, and have them all de-duplicated files, all the different versions. So you remember 07:49.200 --> 07:56.640 when you have the, with Microsoft, the different versions of home, pro, all the after that stuff. 07:57.520 --> 08:03.120 Yeah, you can have all that files in the same repository, de-duplicate and several 08:03.120 --> 08:11.680 the different options. It was designed for that. It's kind of like our UUID. And yeah, if you want 08:11.680 --> 08:17.520 to make a rollback or something like that, you can address a package partially by just the name, 08:17.520 --> 08:25.120 by the full version. You can say I want to be with this very specific build. You can address it 08:25.120 --> 08:31.760 by just the software version or just the main branch of the version of that. So you can be very flexible 08:31.760 --> 08:39.840 in dependency management. If you use it, most these days we don't use that very directly. We use 08:39.840 --> 08:48.640 basically name addressing and exact timestamp addressing, not much else. And another thing 08:48.640 --> 08:56.400 as you may think about, so what did people use post-installed scripts for actually? Well, 08:57.600 --> 09:03.040 at the end of the day, an operating system has users. That's the user database. In our case 09:03.040 --> 09:08.560 we also have rule-based access controls. So you have a rule-based access control database, which is 09:08.560 --> 09:17.680 a file. You need to edit that. You can't just deliver a file. Well, in dopant service days, 09:17.680 --> 09:25.760 we came up with a principle of self-assembly. Possibly principle says, every database of users, 09:26.080 --> 09:36.640 rules, config files, needs to have, needs to have a users pass with e.d, 09:38.240 --> 09:44.320 where you put snippets into it of just your user that you deliver. And on boot, 09:45.840 --> 09:53.600 you, the system itself needs to take those files and build its user database. That allows 09:54.080 --> 10:00.400 for config management to plug in. No more. I need to edit a i and i line with 10:00.400 --> 10:07.360 puppet that need to use the i and i plug in of puppet and all of that fun breakages, those entails. 10:08.160 --> 10:16.320 If anybody has ever done that, I did. Not good. Thankfully, Linux not done, 10:16.400 --> 10:26.400 dilemmas. But the point is it always assembles when you start a software. 10:27.520 --> 10:35.600 So we never need to break the user database with your package. Which kind of few people did with 10:35.600 --> 10:51.120 SVR for packages? Very tough. And of course, the good thing is it's reversible. If you have 10:52.400 --> 10:57.200 a system that you can install properly and it boots up, you can see, okay, exactly this failed 10:57.200 --> 11:05.120 during this boot, I can get in, I can fix it up. And, all right, it's coming back. I think, 11:07.520 --> 11:17.040 no. Hi. And you're back online. The other things, of course, with boot environments, 11:17.040 --> 11:23.520 you can always switch between them. And since we are natively editing images, we can also do 11:24.080 --> 11:30.080 the very cool thing of never edit the live image during an update. You simply have a, 11:31.040 --> 11:35.920 if you do a package update, it actually doesn't just do a package update, it also creates a new 11:35.920 --> 11:42.560 boot environment for you. And you don't have to remember to do that manually. Like, that's the 11:42.560 --> 11:49.520 product design of the system. You're like, I just want to do an update. It needs to do the security 11:50.480 --> 12:01.600 itself. Yeah, that's pretty much the basics. We have a couple of controls for the image, 12:02.320 --> 12:09.840 this like general concepts that work as a framework to be able to make good packages. 12:11.360 --> 12:19.440 So we have facets, that's optionality. Basically, when you say like, oh, I have 10 different language 12:19.680 --> 12:25.840 images in a software. You can classify each language file of a software when you build it, 12:27.120 --> 12:33.760 deliver all of it with it, and on the system you install it, you can define a facet to be 12:33.760 --> 12:41.040 true or false. And everything where the facet is defined, false, just gets deleted off the system. 12:41.920 --> 12:47.920 So if you want to shrink down the system, you just check which facets are defined. So like, oh, 12:47.920 --> 12:51.040 I don't need manpages on this system. Nobody reads it. This is an appliance, 12:52.000 --> 12:58.640 remove the manpages with facet, manpages off. It's gone. No need to split it off into separate 12:58.640 --> 13:04.320 manpages packages or separate developer files packages. You can put all in the same package, 13:04.320 --> 13:12.240 just classify the files correctly. And the user can control how he wants to have things installed on 13:12.320 --> 13:20.320 his system. So you don't have to do it as a package. The Riance is basically the implementation 13:20.320 --> 13:30.560 of choice. So can you say like, okay, we have usual Riance that they used are global and non-global 13:30.560 --> 13:38.400 zones. So virtualization, not virtualization, which kernel do you need to install or which architecture, 13:38.400 --> 13:44.800 if you have binary files, you can basically have one package that works for Spark, 13:44.800 --> 13:54.160 AirM, and X86. And you simply set the Rorei into that version. Say, Archifree86, that's X86 13:54.160 --> 14:03.680 in Illumus, which is 64 and 32 bit, no matter which one of the two. And it will only install 14:04.000 --> 14:11.920 Defiles that are needed for X86 files, a system, even if the package itself also delivers the 14:11.920 --> 14:19.360 Spark files. So you can make kind of like fat packages for multiple ARCs. Or if you want to go 14:19.360 --> 14:25.280 very crazy, you can make a variety of the operating system and deliver for Windows, Mac, and Linux 14:25.280 --> 14:31.680 in the same package. You could. If you should, that's not a question, but you could. 14:33.680 --> 14:44.480 And the other thing that we have is called mediators, which is SimLink put in place in Linux, 14:44.480 --> 14:50.160 it's called update alternatives, the system. This is built into the package manager, where in 14:50.160 --> 14:58.560 the package you define exactly which files are a like alternative and which alternative they are 14:58.560 --> 15:06.000 say Java 8, the Java 10, Java 12, and Java 16, 7 in any area. And you can basically say 15:06.000 --> 15:12.640 everything in the Java folder, put gets into the system, Java folder, as the mediator, Java 10. 15:13.200 --> 15:19.280 But you have it as a copy under the slash user, Java 8, for example. 15:21.920 --> 15:27.120 That's very useful if you want to give all the different versions in there. And if something 15:27.200 --> 15:34.000 links to a specific version, you simply tell it, hey, your specific Java prefix for that very 15:34.000 --> 15:40.400 specific Java version, which is not the default, is on the slash user, Java 8. And don't go look 15:40.400 --> 15:48.000 anywhere in the default paths. And if you want to have it on the default, you just leave it there 15:48.000 --> 15:53.360 and usually auto tools or anything picks up the defaults. And with the mediator, is which the 15:53.360 --> 15:59.680 defaults around? Or if you have a custom software and you want to have user pin, Java, be, 15:59.680 --> 16:07.760 Java 11 or whatever. You can set it up per image and you can also have multiple images on the 16:07.760 --> 16:13.760 same system because you have zones. Every zone is its own image and you can control them from 16:13.760 --> 16:21.360 the global zone or from the zone itself. And the last thing which we have is consolidations, 16:22.320 --> 16:28.320 which is a system integrity feature. So if you have ever installed a Docker image, 16:28.960 --> 16:32.240 you know that it's basically a tarball, you get the files you get there. 16:33.360 --> 16:41.200 Well, IPS has that also built-in. That's the consolidation. You say, I have a consolidation, 16:41.200 --> 16:47.680 and I want to make sure that everything that I care about in this system is on a very specific 16:48.560 --> 16:56.560 version. Say you want to have SAP installed on a system. SAP certifies only very specific 16:56.560 --> 17:02.400 versions of libraries. So you need SAP colonization to make sure your system package 17:02.400 --> 17:09.680 manager never updates you away from certified the certifiedness of SAP. That's a problem 17:09.680 --> 17:15.680 that had to be solved at some point. Thankfully, we are a bit better now. We've opened source 17:15.840 --> 17:21.360 and not in the enterprise space, but still a good feature. It works like a Docker file or a 17:21.360 --> 17:28.160 Docker image. Just put it on it and you're sure you are on that version you download it on the 17:28.160 --> 17:38.800 whole system, not just a package. Yeah. And again, that's the main point. An image is the whole 17:38.880 --> 17:44.240 system. Inside the image, you have packages. And you can install packages. You can 17:44.880 --> 17:51.600 remove then you can update some, but you want at some point to look onto a system as a system 17:51.600 --> 17:59.360 of this like unit. The unit that has been designed by developer tested by somebody and given to 17:59.360 --> 18:05.600 you. So you as the enterprise administrator don't have to retest everything. It's not a unique 18:05.680 --> 18:11.120 thing you want to copy it around. An IPS is the package manager that enables that. 18:15.520 --> 18:24.400 So, and with that, well, IPS, as I've made, I've started tells from the early mid 2000s. 18:25.840 --> 18:31.120 It started off with 2005. I think I have the earliest commits. 18:32.080 --> 18:38.080 Came in with open salarys to 2008 and got fully integrated into salarys around 2011. 18:39.360 --> 18:48.560 Or salarys 11. And it's copuses that old and not very maintained even by the salarys people. 18:49.200 --> 18:55.200 They maintain it for what they need. And there's quite a few improvements that over the last decade 18:55.200 --> 19:03.360 we can input into it. Well, with the programming language that I use, Rust, there is a native 19:03.360 --> 19:10.080 multi-freading improvements that we can use now. We've already seen it on Spark where it finally 19:10.080 --> 19:16.720 uses all 500 cores of the machine and not that one, the incidentally core that does everything. 19:16.720 --> 19:25.760 And all that stuff. So, we're kind of like really trying to get it more modern, update the 19:27.120 --> 19:34.000 catalogs to like what happens when you have 10,000 packages all over something because you're not 19:34.000 --> 19:40.640 just an enterprise distribution. You're running release, rolling release, open source distribution. 19:40.640 --> 19:46.480 And you have 10 or thousands of versions of stuff. And you need to maintain all this stuff. 19:47.680 --> 19:53.360 And that's kind of like what we're working on right now, getting that upgraded, but with the same 19:53.360 --> 19:59.520 solid basis. Thank you very much. Questions?