Hello, hello, okay, we are on. Yes, hello, everyone. So this is one of the Illumus talks.
Talking about one of the more fun features about it, the package manager for Open Solaris.
Things that got forgotten by history, but are very active. I'm known as Tosterson in the
Open Indiana Project. I'm a maintainer of Open Indiana. So I work with IPS for quite a bit.
And when you go to Open Solaris, let you see projects or continuation projects,
you get a whole lot of tools like if a T-Trace, you get your own set-of-ass like this whole package
of very fun things that people like. And there's one thing that people often do not talk about.
And that's IPS, so I'm making a finally after 10 years to talk about it. So somebody keeps
remembering that it exists and actually we can get some more people in, because it's a little bit
different than what you would expect the package manager to be. That's kind of like the good thing,
but it's also like, everybody comes in and it's like, how can I make my post install script and
we're like, we don't have that. Sorry, no post install in this area, this is a completely different approach
to it. So a lot of it goes to the point of like, you have an image and you want to boot that image.
That's what you want to do in an enterprise. Imagine it's 2005, 10-ish. What's the big deal? What's
the big deal on block? If you're thinking VMWare, that's kind of like the deal. It's like VM's coming up.
Windows can finally be run on one more than one Windows per server, physical server.
And of course, VMWare starts like a little images, you throw around that disk file and you boot it and it works.
It doesn't system prep and all that other stuff. Oh boy, we have SVR4.
And yeah, SVR4 was for its time, I think, 80's even it started. The name SVR3 comes from system version 4,
SVR4. It's that packaging. It's developed and it grew an internet part. You could download packages,
also from distributors like IBM. And you could get problems from packages with distributors like IBM.
If anybody has a memory of very tough backup, yeah, see some hands go up, I see something.
Oh, the package was as bad as you could think and it in certain scenarios broke a lot of things.
Which was one of the reasons why IBM got invented the way it did.
Little side note, IPS is a spiritual successor to APT or Debian package manager,
mostly because the chief guy at the time at open scenarios was the guy of Debian.
Also same guy. So he put in a lot of information like repository, centric, like put this all like of the internet.
You need to be able to download the packages and so on. But a lot of more things happen at that time.
So if SVR4 where you have your binary, blob of tar balls or whatever you used to be at the time,
whatever package. And if IPS, you fetch every file individually. So you don't have them collected.
You already have a pair file, they've deduplications, so you don't have multiple,
you don't have to manage the packages, so you get deduplication in the packages. And it's all this like
kind of detail stuff. But the biggest change is it's all image, why are you there?
There you are. Ah, I'm too much here. Okay, better presentations of it. We can do that.
So in open scenarios, with set of SVs, you have what you in 3BSD guys know as put environments.
So IPS hooks into that. It creates put environments for you. So it basically defines the state
of all the files of a put environment, what files need to be on a put environment for a image
to be putable. So you have text-based manifest that like set is all up. You update image,
you run over it, you can even go and fix it. If things got broken, if you have a 1 disc set of
SVs pool and you have it half corrupted, then you could restore 10 files from it. You go set of a
package fix your image. And you would do it because it can. It has a record of what should be on that image.
And that's a very, very different approach to SV4 where, well, what's on the image is what
ever happens at the end of the post install. So that's the main shift. And another thing that we
got introduced is an FMRI. And that's something people outside of the salaries well do not know.
It stands for Fault Management Resource Identifier. Fault Manager is another component in
the system that enables self-healing. And it identifies items uniquely. This storage chassis
is CD-ROM's Bauthafium. And so we have this URL structure to a package. So whenever you say
install GCC-10, it will not install GCC-10 just as the name. It will expand it to the full URL
that it gets like developers, GCC-10. I don't know all URLs on top of my hair because I just say
install GCC-10 and it does it. It's very simple and usage. And we also got introduced multiple
version identifiers. You have the main version of the software. You have the build of the OS for
which that software was built. You have the branch of the specific subOS type where you want to go
if you have like an enterprise sub branch with licensing or something. And what's more happening
in back in enterprise days not really happening today. And you then have a time step at the
end so you know which one is current. But you could have all these packages in the same repository,
in the same publisher, and have them all de-duplicated files, all the different versions. So you remember
when you have the, with Microsoft, the different versions of home, pro, all the after that stuff.
Yeah, you can have all that files in the same repository, de-duplicate and several
the different options. It was designed for that. It's kind of like our UUID. And yeah, if you want
to make a rollback or something like that, you can address a package partially by just the name,
by the full version. You can say I want to be with this very specific build. You can address it
by just the software version or just the main branch of the version of that. So you can be very flexible
in dependency management. If you use it, most these days we don't use that very directly. We use
basically name addressing and exact timestamp addressing, not much else. And another thing
as you may think about, so what did people use post-installed scripts for actually? Well,
at the end of the day, an operating system has users. That's the user database. In our case
we also have rule-based access controls. So you have a rule-based access control database, which is
a file. You need to edit that. You can't just deliver a file. Well, in dopant service days,
we came up with a principle of self-assembly. Possibly principle says, every database of users,
rules, config files, needs to have, needs to have a users pass with e.d,
where you put snippets into it of just your user that you deliver. And on boot,
you, the system itself needs to take those files and build its user database. That allows
for config management to plug in. No more. I need to edit a i and i line with
puppet that need to use the i and i plug in of puppet and all of that fun breakages, those entails.
If anybody has ever done that, I did. Not good. Thankfully, Linux not done,
dilemmas. But the point is it always assembles when you start a software.
So we never need to break the user database with your package. Which kind of few people did with
SVR for packages? Very tough. And of course, the good thing is it's reversible. If you have
a system that you can install properly and it boots up, you can see, okay, exactly this failed
during this boot, I can get in, I can fix it up. And, all right, it's coming back. I think,
no. Hi. And you're back online. The other things, of course, with boot environments,
you can always switch between them. And since we are natively editing images, we can also do
the very cool thing of never edit the live image during an update. You simply have a,
if you do a package update, it actually doesn't just do a package update, it also creates a new
boot environment for you. And you don't have to remember to do that manually. Like, that's the
product design of the system. You're like, I just want to do an update. It needs to do the security
itself. Yeah, that's pretty much the basics. We have a couple of controls for the image,
this like general concepts that work as a framework to be able to make good packages.
So we have facets, that's optionality. Basically, when you say like, oh, I have 10 different language
images in a software. You can classify each language file of a software when you build it,
deliver all of it with it, and on the system you install it, you can define a facet to be
true or false. And everything where the facet is defined, false, just gets deleted off the system.
So if you want to shrink down the system, you just check which facets are defined. So like, oh,
I don't need manpages on this system. Nobody reads it. This is an appliance,
remove the manpages with facet, manpages off. It's gone. No need to split it off into separate
manpages packages or separate developer files packages. You can put all in the same package,
just classify the files correctly. And the user can control how he wants to have things installed on
his system. So you don't have to do it as a package. The Riance is basically the implementation
of choice. So can you say like, okay, we have usual Riance that they used are global and non-global
zones. So virtualization, not virtualization, which kernel do you need to install or which architecture,
if you have binary files, you can basically have one package that works for Spark,
AirM, and X86. And you simply set the Rorei into that version. Say, Archifree86, that's X86
in Illumus, which is 64 and 32 bit, no matter which one of the two. And it will only install
Defiles that are needed for X86 files, a system, even if the package itself also delivers the
Spark files. So you can make kind of like fat packages for multiple ARCs. Or if you want to go
very crazy, you can make a variety of the operating system and deliver for Windows, Mac, and Linux
in the same package. You could. If you should, that's not a question, but you could.
And the other thing that we have is called mediators, which is SimLink put in place in Linux,
it's called update alternatives, the system. This is built into the package manager, where in
the package you define exactly which files are a like alternative and which alternative they are
say Java 8, the Java 10, Java 12, and Java 16, 7 in any area. And you can basically say
everything in the Java folder, put gets into the system, Java folder, as the mediator, Java 10.
But you have it as a copy under the slash user, Java 8, for example.
That's very useful if you want to give all the different versions in there. And if something
links to a specific version, you simply tell it, hey, your specific Java prefix for that very
specific Java version, which is not the default, is on the slash user, Java 8. And don't go look
anywhere in the default paths. And if you want to have it on the default, you just leave it there
and usually auto tools or anything picks up the defaults. And with the mediator, is which the
defaults around? Or if you have a custom software and you want to have user pin, Java, be,
Java 11 or whatever. You can set it up per image and you can also have multiple images on the
same system because you have zones. Every zone is its own image and you can control them from
the global zone or from the zone itself. And the last thing which we have is consolidations,
which is a system integrity feature. So if you have ever installed a Docker image,
you know that it's basically a tarball, you get the files you get there.
Well, IPS has that also built-in. That's the consolidation. You say, I have a consolidation,
and I want to make sure that everything that I care about in this system is on a very specific
version. Say you want to have SAP installed on a system. SAP certifies only very specific
versions of libraries. So you need SAP colonization to make sure your system package
manager never updates you away from certified the certifiedness of SAP. That's a problem
that had to be solved at some point. Thankfully, we are a bit better now. We've opened source
and not in the enterprise space, but still a good feature. It works like a Docker file or a
Docker image. Just put it on it and you're sure you are on that version you download it on the
whole system, not just a package. Yeah. And again, that's the main point. An image is the whole
system. Inside the image, you have packages. And you can install packages. You can
remove then you can update some, but you want at some point to look onto a system as a system
of this like unit. The unit that has been designed by developer tested by somebody and given to
you. So you as the enterprise administrator don't have to retest everything. It's not a unique
thing you want to copy it around. An IPS is the package manager that enables that.
So, and with that, well, IPS, as I've made, I've started tells from the early mid 2000s.
It started off with 2005. I think I have the earliest commits.
Came in with open salarys to 2008 and got fully integrated into salarys around 2011.
Or salarys 11. And it's copuses that old and not very maintained even by the salarys people.
They maintain it for what they need. And there's quite a few improvements that over the last decade
we can input into it. Well, with the programming language that I use, Rust, there is a native
multi-freading improvements that we can use now. We've already seen it on Spark where it finally
uses all 500 cores of the machine and not that one, the incidentally core that does everything.
And all that stuff. So, we're kind of like really trying to get it more modern, update the
catalogs to like what happens when you have 10,000 packages all over something because you're not
just an enterprise distribution. You're running release, rolling release, open source distribution.
And you have 10 or thousands of versions of stuff. And you need to maintain all this stuff.
And that's kind of like what we're working on right now, getting that upgraded, but with the same
solid basis. Thank you very much. Questions?