So, we are now going to start the second talk of this session.
The title is Our Own Operating System, and this will be presented by Harald Zitter.
And Harald, the stage is yours. Thank you.
I'm quite surprised that so many people are here. I saw that I'm competing with
Qt 6.8, so apparently you all already know what's going on in 6.8.
Ah, that's the way, YOLO it. Okay, let's talk about the operating system.
So we've actually heard about the operating system a bunch of times today in
the form of immutable distros.
And what I'm going to talk about is a bit related to that.
But first, let's talk history. History is so important, isn't it?
So in the 90s, KDE came about, Linux came about, distributions came about.
And so we needed a distribution story, right?
How do we get KDE onto the user's computer?
And the story was simple. It was we provide the sources, distribution makes
installables out of the sources,
then the user gets them from the distribution, and then when things break,
because they always break, the user goes and complains to KDE. Fair enough?
That is a good story. But since then, things have changed.
So today KDE is no longer a
product it is a community of creators we are
all creators right and we create
many different products we have our frameworks which are of course the building
block we use to enrich and enhance Qt we do have KDE Plasma and its various
offsprings for the desktop for mobile, for the TV.
And that's one of our core products.
Then, of course, we have the KDE Gear, which is a bit of a mixed bag of applications,
and libraries and plugins and artwork and sounds, I guess.
So we have that. Then we have independent applications of that in the form of
Krita and KDE in Life, I think, is part of the gear, but extra applications.
Then we have KDE Neon, which is of course a thing that distributes things,
a thing of beauty, a thing of, yes, it is a thing of beauty.
Then we have, of course, the infrastructure, and we also have various hardware
initiatives, so like corporations with Slimbook, we're doing stuff with Tuxedo,
I hear we're going to do stuff with the Framework people.
So there have been quite a bit of changes in the past, and so our story needed
to evolve as well, right?
So this is our 2020s apps distribution story for Windows and Android.
It's kind of the same, right? We still are very much in the business of providing sources.
Then we take our own sources, turn them into installables, push them onto a proprietary store.
The user gets them from the store and complains to us. Who thinks that's a good story?
Good story? Not a good story? Undecided?
Okay. It is a good story. I didn't try to trip you here.
Because on Linux we have the same story today, right? In the form of Flatpak
and Snaps and what have you.
We very much still take our sources, turn them into installables,
put them onto a centralized store, even though Flatpak claims to not be the
centralized store, but it very much is.
Let's not fool ourselves.
And the user gets the installables from the store. User complains to KDE. Still a good story?
Cool? Bit undecided?
This is our distribution story in 2020. Who notices something about this?
It hasn't changed. That's strange. We are not in the 90s anymore.
Why is the story the same?
This is Plasma's distribution story. One of our core components still hasn't
changed. Still in the 90s.
Now, I'm not saying that's a bad thing, right? But it is definitely something
interesting to observe.
The distribution makes the installable, but the user complains to us.
Who thinks that's a good way to do things.
Okay, not that many people.
Okay, let's do a thought experiment.
So you said if that's all the distribution does, what if it patches stuff, right?
Is it fine then, I don't know, is it fine if we tell the distribution to patch stuff?
Probably, I mean, we told them to, so it should be fine. But then,
of course, something either David or Nicholas mentioned, how do we figure out
what the user is even using, right?
What version of Qt are they having on their distribution?
What version of Plasma? Do the two interact?
What version of Breeze? Do they have weird plugins installed? All that lovely stuff.
So in, when was it, Jonathan? 2015?
2015, Jonathan and I started KDE Neon, a sort of our answer to this problem here, right?
So we started KDE Neon, and we set out to change the distribution story.
The goal was fairly simple. We would have a rock-solid base in the form of the Ubuntu LTS core system.
Then we would put bleeding edge KDE on top, and it is something we can give
to our hardware partners.
Really good story, I think. We also had like a slogan of sorts.
KDE Neon provides an easy and elegant way for people to test the latest from
KDE or use the latest releases of KDE software.
Now something that occurred to me while preparing the slides is the comma.
It's the thought that using somehow became an afterthought.
It wasn't intentional, but the sentence makes it look that way, doesn't it?
And so that sort of lifts up with the first part of the sentence.
We want people to be able to test KDE software, which Neon does very well,
I would say. The using part, maybe not.
But let's look at the story.
KDE provides the sources. KDE takes the sources and turns them into installables.
The user gets it from KDE and then complains to KDE.
So that is technically the same story as we have for the apps, right?
Who thinks it's a good story for distributions?
Okay. about half, maybe a bit less.
So in a stroke of genius, Jonathan and I did a bit of project management and
actually wrote down why we're doing NEON and how we're doing NEON and all the
technical details of how it's going to be achieved and all that.
You can look it up on the community wiki. It's an interesting read and I think
those of you who've used NEON will actually find aspects of that represented in the actual product.
And as part of this founding plan, we've outlined challenges we expected to be appearing.
And one of them is increasingly the Ubuntu archives do not have the necessary
version of a piece of software needed by KDE software, in which case we will
add it to the Neon archives.
When preparing the slides, I was going through the documentation of NEON,
and this stuck out to me, because one of the guiding principles was,
well, it's going to be a rock-solid base.
But by our own admission, the rock-solid base isn't going to work out.
We already knew this in 2015. we said that the rock-solid base is eventually
going to be too old, so we need to add software to our own repositories in order
to bridge the gap, as it were.
Another interesting aspect is NEON won't get special treatment from the rest
of KDE by virtue of being a KDE project, and it certainly won't be the KDE distribution.
Now, two things were going on there. One was a bit political,
and I think you can guess which part of the sentence is the political maneuvering.
The other one is also very much a problem that we're seeing in KDE,
is that just by, we're seeing in Neon, that just by being part of KDE,
you're not necessarily getting the full support, the full might of KDE, if you will.
And so, what are the ailments of neon, right?
I mean, it has a good story. I think it's a good story, right?
You can disagree with me and can tell me later, and then I will tell you why you are wrong.
But for now, that's got to be a good story.
Now, what are the ailments of neon? So, as identified, the rock-solid base is
actually not an advantage. It's a problem.
Curious. Jonathan, do you agree?
Yeah, he's nodding. So why are we using Ubuntu LTS?
There are arguments for it, right? Don't get me wrong. We were not idiots in 2015.
There was a good amount of thought brought into it and there are advantages to it.
But at the same time, this is now holding us back. This is now a problem.
Because right now, today, the Ubuntu LTS space that we are on is two years old.
It doesn't have pipe wire which is just mind-blowing
it it has
ancient ancient libraries it has ancient everything right
and so today is a day where
neon has a problem because it has a
large amount of backports these backports are no
longer constituting Ubuntu LTS right we've deviated
from the product this is no longer LTS Ubuntu this is a new product this is
KDE neon and so this entire advantage that Ubuntu LTS gives us in the form of
hardware support and it's stable and has security updates and all that out the
window. It doesn't exist anymore.
Then there is this mantra of latest is usable.
So when we go back to this motivational line or the description of Neon,
the punchline, the sentence that you put out to grab people, it says,
use the latest releases of KDE software.
And here's a question. What if latest isn't greatest?
What do you do then? Do you hold on to your mission and go, yeah,
yeah, latest is in fact usable?
You complain to KDE, but you are KDE, so who do you complain to?
We don't even have superiors to complain to. We just can sit in our rooms and
be grumpy with our own decisions.
We do that anyway. That is true. I also take naps occasionally.
If you hadn't shown up, I would totally have taken a nap.
So one of the biggest issues, perhaps, is packaging.
Huya has done packaging. Who here has liked doing packaging? Oy. Oh.
OK, that's a sad story. So nobody wants to do packaging, which is unfortunate.
It can be exciting. It's a bit like programming, except packaging.
Packaging is complicated. It is from distribution to distribution different.
There are many different rules. There's a lot of cargo cult going on.
There are so many problems with packaging that aren't just the fact that it's
like separate from programming.
It's the very fact that it wants to be separate from programming, right?
It's not part of the programming story. And that is a problem.
And it is a problem because it means we collectively do not want to do it and
that is difficult if KDE wants to have an operating system like Neon perhaps is perhaps not.
And so packaging is a problem a big one but an even bigger problem is the things
that come out of it. Packages.
Oof. No, seriously. Packages. They are just the worst.
Like, if you install one package, it goes, oh, I need another package.
And then that package goes, I want another package.
And so that becomes problematic. If you have an Ubuntu LTS base and you randomly
introduce new packages because the LTS packages are too old,
so you've created a new product, you've created KD Neon, but now the packages do no longer align.
We've had this somewhat recently with Wine 32-bit.
It just broke because packages, because the dependencies didn't align anymore.
What are you going to do as a user? What are you going to do as a developer? Ah.
Ah.
See all the fancy new technology? energy, power saving also applies to the projector.
Brightness control also applies to the projector. Crazy stuff. Where was I?
Packages. Oh, yes. Thanks for reminding me.
So, packages are just terrible. They are horrible.
And they also factor into the next point, which is quality assurance in Neon is a huge, huge task.
Because with every package that the user installs, they've created a new permutation
that you need to QA. In theory, in practice, we don't.
But in theory, it's another version in of itself that you need to test.
And so, you end up with these really complicated created tests in areas that
you need to carry out in order to do proper QA.
And then as mentioned, if the KDE community,
doesn't do packaging, doesn't do the QA, doesn't care for Neon,
then that is the biggest problem of them all, is it not?
Ah! Ah, so you are involved with Neon then. That's good.
Actually, who has touched Neon in any capacity, like touched the packaging or touched Jenkins?
Okay, a third maybe?
That's good. So you are involved. You're not the problem. Everyone else, you are the problem.
In the meantime, distributions also involve.
So this is not 2015 either. so what have distributions done well they've created
new products these are some of them I guess you've heard at least of one of
them right who hasn't heard of any,
okay so quick story let's pick one Ubuntu core because it's there's a related
talk tomorrow so you can go to the related talk tomorrow and find out more.
Ubuntu Core is essentially an operating system built just out of snaps.
So everything is contained in its own little bubble and you don't get to touch
anything as a user. It's kind of the basic story.
And all of them function kind of or like more or less the same.
You have an immutable base system, you cannot change anything and then you install
applications in the form of let's call them bundles so flat pack or snap or
app image that sort of thing.
So Neon had one of these goals, right, of being something we can give to our
hardware partners because hardware is hard.
And our hardware projects are also a bit weird in that they happen by chance.
So Aleš was a bit surprised that I had this sentence on my slides because my
experience is at some point Aleš shows up and says, there's this new hardware
project that we're doing.
Are you prepared to join? And I'm like, oh, sure.
So they happen by chance and not by design, which is weird because this is a
space where we can thrive, right?
We've seen that. If we bring out a new device,
or like if Slimbook brings out a new device and we're like marketing it as the
KDE Slimbook, then that generates interest, that generates activity in the internets.
So, for hardware initiatives, we first of all need to not have them happen by chance, but by design.
And then we need a compelling operating system so we are being taken serious, right?
Like if we went up to Slimbook and said, how about you put OpenSUSE on your
thing and call it the KDE thing?
They were saying, well, we're already shipping OpenSUSE, why would we call it the KDE thing?
Which is a good thing. So, and it's hard for the community to get into, right?
Who here has been part of a hardware project in KDE?
Three, four, five, six, six people in this entire room. So that could be better, right?
Step one, and that's the important step, The next step is we need to have an operating system.
That's my proposition right now. Who disagrees?
Don't be shy.
So, there seems to be firm support for this notion. So, I'm introducing code name Banana.
Now, code name Banana is obviously a silly name. I don't know who came up with it.
Person in the audience who is also president?
Let's apply some magic to that name. Woo!
Let's call it KDE Linux.
In fact, you will find this on the last slide.
Maybe it shouldn't be called KDE Linux, but, and this is one important thing,
it's up to you what it's going to be called.
Could be anything. Here are the goals I'm proposing.
So it's going to be the KDE operating system. if someone asks you how do I use
this plasma thing then you go use this,
it might not be the fastest moving it might not be the most heckle it might
not be well actually it might be all of these things it's just gonna be amazing
so this is gonna be the KD operating system.
And it needs to have a quality experience.
So if you give it to a user, then they should go, wow, that's an exciting product.
They should be wowed by Plasma. They should be wowed by the operating system,
by what a free software community can do.
And that includes Linux as much as it includes Plasma.
It should be keeping security in mind. That is kind of a given these days. Oh, so annoying.
It shouldn't require packaging knowledge.
Ha, you might think. Harold, you madman. How are you going to create an operating
system without packaging?
And you would be right to ask that. I will show you later.
Stolen is, yes. Yes. It should focus on modern technologies.
We're not in the 90s, so why hold on to technologies from the 90s?
It should be useful to a whole bunch of people. It should be useful to the users.
It should be useful to our hardware partners.
And this is important. It should be useful to us.
If we don't use it, then the project is failed.
There's just no point to it. because we are the ones dogfooding.
We are the ones that are setting the benchmark for what the product should be and can be.
And so it must be useful to developers to us and if it's not then it's failed,
it should have a number of quality additions it
should recognize that latest isn't always the greatest 6.0 was rough it wasn't
terrible but it had problems and so maybe 6.0 wasn't the greatest 6.0.3 probably
was the greatest it could have been.
It needs to have additions for different form factors. We're not just targeting
the desktop. We're also doing mobile.
We're doing TVs, if that's still ongoing.
It should have a way for people to test. That's something we're definitely picking
up from Neon. I think Neon is doing a good job in that department.
You can download an image and go like, yes, that's the latest.
It shouldn't break and obviously it's
going to break so if it breaks then it should be easy to repair
otherwise what's the
point it needs to have community involvement right it needs to have backing
by us if it's not backed by us then again it's a failed project the community
is the recipe for success and that's why I stress the point so much that it
needs to be useful to for developers.
So let's look at a prototype. Who could possibly build a prototype for this?
Oh, me.
Fair enough. Here's the prototype.
So what do you want to know about the prototype? Any particular questions?
I can do you one better.
Yes.
So let's look at the tech a bit, because I think you're all very techy people. Am I right?
Yes? No? Lydia is hiding. Very good.
So it is an image-based operating system, which means there are no packages.
There's a caveat to that, but irrelevant for us, really.
When you download this as user, it's going to be no packages.
It's going to use SputterFS.
It has x86-64 only. It has UEFI only because we are not in the 90s,
don't need BIOS support.
It's using MKOSI, or MacOSI, as I like to call it, which is an excellent tool
by SystemD to build operating system images. That's the OSI part.
It uses an AB update system.
So if one image breaks, you can automatically roll back to an older version.
To assist that we're using systemd boot as a boot manager.
And on my particular system, it's also using systemd homed, although I'm not
quite convinced by it yet.
It has flatpack and confined snaps out of the box.
And the Plasma stack is built entirely using KDE Builder. Again,
going back to this mantra, there shouldn't be any packages.
So we're just rebuilding everything all the time through KDE Builder.
Stay tuned for blog posts on this. Then I have a couple of ideas.
Automatic QA. There's lots of QA in there because QA is important.
Send it off to Sentry and so on and so forth.
Secure boot is something to look into. ARM and RISC-V support,
definitely something to look into.
And yeah, I'll move on because I want some questions from you. Thank you.
Thank you.
Thanks for the presentation and it was quite interesting content and yeah,
we have quite enough time for questions and yeah, we are, I guess that there
should be a lot of questions.
Yep. So on which side of the dividing line between the image and the Flatpak
or Snapstaff does Plasma sit in this as a part of the image?
It's part of the images. Okay.
So perhaps to outline how it works is we take a base operating system,
install the packages from there. So there are packages somewhere.
They are just not on the user system. That's the important bit.
And then we run KDE Builder on that tree, and that results in the actual image then.
So one of the KDE goals is to make the developer experience easier.
And I could imagine that for me as somebody who was very active in KDE but hasn't
been really active for years it always faces the hurdle of oh yeah,
I would love to write a patch for this but I don't have a system set up right now.
Could I just click a button and roll into a system which has all the sources
checked out and I just write a patch and just click and it runs?
Yes. I mean, I'm not sure about checking out the sources, but the prototype
as it stands right now includes all the development headers and stuff because
comparatively these are tiny artifacts, right?
Compared to translations or dictionaries, our development headers are negligible.
So it just comes with everything pre-installed. So the development image should
be the user image in my mind because, again, we are dogfooding our own stuff.
And at that point, you can just take the image and run a build on it.
Hi. In the slide with the distributions, you said there was the KDE breaks.
Distributions, packets the installables, they break, users complain to the KDE.
But now users will complain to KDE if something other breaks that's not part
of the KDE, if ImageMagick breaks or there is a,
RC10, a CV10 that needs to be patched yesterday now that KDE has to do that.
What's your question?
Isn't that a big burden and also something that KDE got from Ubuntu for example?
More or absolutely like there are challenges with creating an operating system,
yes you're absolutely right there is stuff to watch out for I think we're prepared to handle that.
Hmm yeah.
So you're writing let's build it together what kind of help can you need how can we help out,
so that's a difficult question uh i would direct you at the matrix channel or
just send me an email and we'll get it figured out so again this is a collaborative
process right i'm not telling you this is how it needs to be.
This is a proposal from me.
If you want to change anything about it, I'm open to it. If you change nothing,
then I'm just confirmed in my superiority.
So I think maybe somewhat buried in the presentation is what's the base OS for the prototype?
I assume you're not building that with KDE Builder. You're getting it from somewhere.
What is it and why is it better than Ubuntu LTS?
It's Arch Linux. So the basic idea is you want something that is rolling.
Because we need the updated libraries anyway, right?
And since it's image-based, we can just delay releases for a bit,
or release sooner, or have entire control over the image, right?
Since we are basically repacking everything, we're in control.
Yes.
Precisely. The QA is on us. The work, as you've said, is on us.
And it was that way with NEON, and we've kind of ignored that.
And that is a problem, and I'm trying to address this problem by having us actually
be in control and be responsible by extension.
So there was also a question from the chat, is there an automatic boot assessment?
Can I keep additional versions like with RPM OS 3 on an AB system?
System, can I switch between nightly and stable plasma?
So it's basically SteamOS? It's basically SteamOS, yes.
So you can have as many versions as you want, in theory.
I haven't tried it, but I have like four versions on this laptop.
Since it's image-based, you can switch between the images as much as you want,
so you can have unstable and stable.
This, of course, factors into or plays into what David has been talking about
earlier, that we need a kconfig story for rolling back and forth.
I think I've covered all the questions. Maybe not.
Anything else?
Maybe I don't understand completely, but being image-based and not package-based,
does that mean updates require downloading an entire image, so three or four
gigabytes for each update?
Yes, currently. I mean, there are technical solutions to that problem,
but currently they don't exist with the system that we're using.
So my prototype uses systemd sys update, which is fairly new and doesn't have
any sort of optimizations for efficiency yet.
I hope they will come up with something.
Yeah, there are definitely solutions out there. The technology I used for my
prototype doesn't have it though.
I have a question about the same pescaging. So if we have no pescages,
how do we install some third-party software and only flatpak and snaps or compiling?
So software you only get a snapboard flatpak or you compile it yourself.
There's again a systemd solution for that. It's called systemd sysextension,
which basically allows you to overlay something onto your user that is otherwise read-only.
I think you may have actually just partially answered my question already.
So again, you haven't spelled it out explicitly, but the implication is you
want the base image to to be more or less immutable in the hands of the users.
So I assume that if you're a developer, you can sort of circumvent that and
get access to the Arch package manager.
But the next update will then overwrite that, right? Unless you use that systemd
mechanism to somehow...
I mean, as a developer, you can craft anything you want. It's an open system, right?
Because as a developer, occasionally I have to introduce a new dependency,
right? So the way I've been doing it is through systemd sys extension rather
than through the package manager. Yeah.
Okay. And in this Brave New World that David has described earlier,
ideally you shouldn't need a new dependency because you would get it through
Flatpak or through Snap.
Through the actual recipes. Okay.
So maybe a question from the enterprise, what if we have to include sources which are not in ARCH?
So usually often you find packages as in PPA or you dive into packaging.
How would this be solved with the immutable image?
Why would you add a dependency?
Just file systems that are, for example, not included or other applications
that are not snapped or flagged. So would we then need to use Flatpak?
There exists no such application.
Either it should be Snap or it should be Flatpak. I mean, when I say Snap and
Flatpak, I mean any of these bundle formats that are sort of isolated.
But by and large, there should not be a need for you to install anything into your actual system.
Again, with the exception that there's system desys extension which allows you to extend it.
So you can add things on top, but you are then in charge, right?
Like if there's binary problems, binary compatibility problems,
that's on you, not on anyone else.
Apart from the base, as far as I understand,
the approach with the system integration and stuff look very similar to the
way GnomeOS does the thing with the image-based stuff, except the use case of a non-developer.
I wonder, instead of Arch,
would it be better to distribute to Burden by collaborating on the Free Desktop SDK base?
That would also somehow make it better like in the previous presentations about
the Flatpak and Synapse integrations,
particularly around the Flatpak with the free desktop SDK?
Would you consider more collaboration? Yeah, like I said, that's just like the prototype I've built.
If we end up with something completely different, then so be it.
I didn't pick Arch,
specifically I just wanted something rolling that was very pristine so if we
can agree with the GNOME OS people on finding a base system that does that then hooray,
actually two of the online questions.
I have another question about images and upgrading, so you said that we should
download the full image to upgrade,
why you can't produce the diffs of the systems and updates?
Yeah, that's the technology that I was speaking about, is we can have binary
diffs and solve it through that.
And using BTRFS can produce downgrading and getting back to the previous version, right?
So it's snapshots, or why you choose exactly this process?
Independent images, right? They are like independent releases of the thing.
And so you can switch between them as much as you want. Oh, okay, great. Thanks.
I'm.