I'm sorry, I'll hide behind here and then I can.
Allow me to introduce Mr. David Edmondson, who will be talking to us about Adapt or Die.
Yes, I want to talk about what packaging format changes mean for the wider KDE.
And by packaging formats, I mean Flatpak, Snaps, Ling Long.
And I don't know enough about them to say which one's better or have that discussion.
I might have a favourite, I'll point to it. But the point is they are all better
than the current state and for the purpose of this sort of talk they're all
the same and they're all similar.
Where you have a runtime provided by KDE which has a bunch of libraries,
and then the application takes a version of our runtime and it's all put in
a nice little sandbox sandbox, where there's a few ways to talk to your host environment,
but not a lot of ways to destroy your system.
And it's amazing. They're all amazing.
And I've not been doing a lot of this work on the Flatpaks and the Snaps.
But I wanted to share my moment of enlightenment of when I realized it's not
just another way to get apps,
but how we should be approaching things as the default state that we should
be aiming for, the future.
And talk about how this affects some things we do in frameworks,
how it affects some things we do in Plasma, and really focus on where we go from there.
So, my moment as a Wayland developer, I have to pick up random projects and
see why I don't work under Quinn, which is normally the application's fault.
So I had to build some random GTK application, and I tried building it,
and it requires a newer version of this thing, an older version of that other
thing, and trying to find this Goldilocks situation which compiles was a nightmare.
And I wasted a day on whatever project it was.
And then, I double clicked on the Flatpak file and knownbuilder opened up and
it had all of the source code for your project,
it had all of the source code for your dependency that I was actually wanting
to change in library tree, and all of the other dependencies got magically brought
in and it was an amazing developer experience.
And my takeaway from this was, that was nice, but I don't need it in KDE because
I already have a dev setup.
And I think everyone in this room probably goes, we don't need any of that nice
stuff for getting all your dependencies, because I already have all your dependencies.
And when you say it out loud, you realize that's not a good way to think.
So using this as a way to get people on and have other people quickly build
your app is really important.
If you go to most GNOME apps now, like a new GNOME terminal that's just landed,
the readme me doesn't say clonus repo and get these dependencies and store these headers it says,
clonus repo open a flatpak file and
i think we want that experience in kde but if you look at any of our readmes
our readme for ocula just says clonus repo and hope your distribution's got
the right version of these things and do your weird things you need to do under
debian to get your headers, which are missing,
and go through a painful process.
So that really changed my mind and thinking, this is what we need to be doing.
The other thing that happened around the same time as the call for papers was
we had an issue in Plasma where somebody randomly grabbed something off our
store and it sort of wiped all of their files.
Yeah, a little bit wiped all their files. And we've got a simultaneous extreme
situation where we have our applications where we have to fight all your sandboxing
and we're telling users is, you've installed this app,
it might be unsafe because it's doing this tiny little thing.
And at the same time, Plasma is just letting you download scripts and run them
without that same level of warnings.
And as a user, the expectations of what an app system needs to provide are increasing
because this tech exists.
I mean, I have sandboxing tech on my phone and I'm comfortable possible downloading
and running a Ryanair app next to my banking apps, but I don't feel the same
about downloading some random thing off GitHub.
Even if I can see a source, I'd rather trust a sandbox than trust me reading
a source because I can't be bothered to read a source.
So sandboxing is important.
And that got me thinking about what else can we gain from this sort of technology.
Moving forward, we don't have to care about ABI too much.
Every time we make a new runtime, a new SDK of saying this is what you run your
application against, it doesn't have to be ABI compatible with the last one.
And that will give us a lot more flexibility when we approach moving through
KS6 to get to KS7. We can start deprecating things early and stopping after
using them and making sure they change.
Or we can just be more eager to include new libraries into our SDK,
knowing it's safe to just make a change later if we want to.
And also, bugs should be reproducible.
My work is filled with Nate telling me he's got a weird bug that only he has.
And in theory, in a world where we run the same software, we're in the same
sub stack with the same dependencies, should behave the same and I'll have fewer of them.
They won't all go away. I'm sure you'll still find a way to out QA me.
Worth debatable. Another thing that's going to be super cool,
and I've not seen this really exposed or talked about yet, is I compile something
on my laptop, it takes forever.
I compile something on my desktop, it takes forever, even though I've just compiled the same thing.
And it takes forever because my caches on my laptop are not usable,
it's a different compiler I'm using, things have a slightly different path or
a slightly different timestamp.
If you're building everything in containers, that problem goes away.
So I'm hoping we're going to see sccache used or just copying your ccache folder
and moving between machines or even having somebody write a new merge request
and then me not having to recompile any of those files on the other side of
the world is actually doable. And that could be game changing.
And the other important part is even if you don't like the flat plaques and
snaps, you don't have a choice because they're coming and there are distributions
where it's the only way to get applications.
So always immutable atomic distributions are coming up everywhere and by immutable
distributions I mean ones where you download a distribution and you can't add
or change any of these files and every week there's a new one of these.
There's another one. And Fedora Silverblue spin-offs, Micro S from Sousa,
Ubuntu's got a slightly different vibe and if you want to learn more about Ubuntu
Core, Kevin has a whole talk about tomorrow going into,
nitty-gritty detail of that and I've got a certain experience with one of these
other products on screen.
So what's this?
So in these systems, the only way to get applications is through your stores
with a Flutterpack and Snaps.
And if they're not available in the Flutterpacks or Snaps, they may as well not exist.
So there's pressure coming in that we can't avoid.
And fact, most users will be using one of these distributions in the next few
years. You might think it's a prediction, but it says facts on the screen.
And I'm on stage, so I'm right.
So what do we need to deliver for those distributions? We need our apps to be available, obviously.
But I'm not going to blab one of our apps because that's hopefully been talked
about over the last few years again and again.
But we also need our base system outside that to be really small.
Because it's often stored in duplicates.
It's something that other companies promising as here is the product.
So they want to have some control over what they're offering.
And as I talked about before, it needs to be robust.
There's no point saying your apps are sandboxed if everything outside it is not.
So we really need to focus on hardening that.
And on the framework side, we need to come up with an SDK that works,
something that's predictable.
You look at a library documentation and see, here's a library documentation.
I expect it to work the way Linux apps are being deployed now,
which is in these Flatpaks and Snaps.
And we need to have that integration work and be clear when it won't.
So what's the state in KDE right now? Things are good enough.
I mean, if you see my rest of the devices out there, Silverblue's out there,
and people can get a lot of our apps, and they're available.
But the experience could definitely be better. Like our frameworks,
what we're thinking about where we're going to be in five years is not designed
with this flat pack first approach.
We've designed from that 15 years of, 20 years of history, 25 years of history
of traditional packaging, and that sort of flows through now.
And that makes sense, because that's how things used to work.
Had distribution packaging, where we ship, give stuff to distributions,
they give a random version to consumers, we don't know what it is,
and clients have to work around guessing,
working against maybe building against this version of Qt with this version
of frameworks, and that mismatch.
So we need to move towards this container-first approach, where we think about
sandboxing existing already and working.
So before I talk about what we need to do next in frameworks,
I need to give a quick summary of how all of the security stuff works in these containers.
So by default, you can't access any of the files in home, well,
with some exceptions, or your root file system.
You can't just grab a random library that's installed and use a lib somewhere.
No access to devices, which is generally a good thing.
And when you want to talk to one of these other apps on the host,
other posters on the host, it goes through a filter.
And the host goes through a filter and these messages get filtered.
Some messages can go into our application in the container, but the messages
out from our application to a host get filtered, and very few are allowed.
Also, the host system, Plasma, only gets to see a handful of files from the application.
It gets to see a desktop file which says how to launch it, and the command that
says how to launch it gets modified by its install process.
So where you say exec equals dolphin, the host sees exec equals Flatpak run dolphin.
Same for DbusServiceFiles. So things can be DbusActivated.
And again, that's a modification of the entry point gets modified as far as
the host DbusDemon sees it.
And obviously we get a nice little icon.
So there's your static permissions, and you can do other tasks without needing those.
So if you want to open a URL, you send a message to your portal,
rather than actively you saying, launch Firefox, you ask the portal,
please open this URL, and then magic things happen.
If you want to open a specific file, you talk to your portal and say,
can I show you a file dialogue, please?
And then the host shows a file dialogue with all of your files and hands back
a magic way that you can open just that one file,
And we've got things like notifications go through this portal things that maybe
don't need a security any Additional security things but also something that
we want to be restricted Go see this portal and then we can show you use a prompt saying,
Do you really want to let K write start recording your screen?
Sounds suspicious and the user can say yes or no.
And the static permissions are somewhat of a fallback.
If you go to Flathub right now and you request to access all of the files in
the home directory, you get a scary warning.
Full system read-write access. This is bad.
And it starts to look like the back of a cigarette packets where you've got
a picture of a lung disintegrating.
And that's what's going to happen if you open .config.
And another fact, over time, FlatHub's going to start making that warning more and more severe.
And users are going to see a scary looking warning and go, well,
I can choose between this application without a warning or this application
from KDE with this giant scary notice.
It's a no brainer what you're going to choose. issues.
So we need to design our framework around this flat pack first approach where
things by default go through not having big scary warnings.
So I'll go through a few case studies not going through everything we need to
change in frameworks because that's your job over the next five days and next
five years of working out where we want to take frameworks.
So, system tray icons. This is the icon in the little bottom right corner of
the screen where you can see you're running KALARM and you've left KALARM open
and you might want to do some quick access with it.
So if you use KSTATUS NOTIFIER item or QSYSTEMTRAY right now and try and use it, it just won't work.
And that's a bad thing. But it can be avoided with one of these static permissions.
If you add to your JSON file dash
dash talk name org dot kd dot status notifier item, it can go through.
But you have to know as a packager, which you should be doing yourself as an
application developer, that you need to add this.
And no documentation in case status notifier item or QSYSTEM tray icon mentioned
this, you find out, pardon?
Well, yes. Or outsourcing.
No, no, on a serious note, we can change this one thing, but we need to approach
this of everything, right?
And I'm happy to make a merge request for this one thing, but what I'm hoping
for is people go, oh, but this also applies to here.
This also applies to K auto start. that, this also applies to whatever,
and open up that discussion.
And it's worth noting there are other ways to fix this at a Plasma and Frameworks level.
If we rename that Dbus interface to org3desktop.portal.whatever,
it gets allowed through without any prompts.
It's a good thing, but it might annoy some people.
So your alternative is we start talking to some people at the portals and say,
well, we have these requirements, we have this API, let's make it work.
And that means talking to people making an XDD desktop portal and say, let's do this.
Wait, and Neil will take care of this, okay? It's been a re-signing task during this talk apparently.
Kconfig is like a core of all of our apps to load configuration files, and it works okay-ish,
But on a base system, you install a version of Dolphin, and then you upgrade
to your next version of Dolphin, and it's newer.
And every distro has some way to do some meddling about, but it's complicated
and nobody does it and it's unsupported.
With a lot of these other operating systems, upgrading, downgrading,
it's really surfaced as this user-facing API that you can do with a button,
where you don't need to log into to root,
you can go on a Steam Deck, I want the beta channel, I want the main channel,
I want the beta channel, I want the main channel. And people do this.
And our code does not handle it as well.
So this is an open discussion of we need to fix this and come up with some mechanism
to handle upgrades and downgrades.
And the way we currently solve it is finding when people report a bug and then
monkey patching it away and hoping that's the last one.
Which isn't a very long-term solution.
The other problem we have with kconfig is that it has this very neat mechanism
that you can have your global files in kdglobals and your application specific
files in your applicationrc and it will transparently merge them into one single unified looking file.
So you just query something once and it comes from this file and it doesn't
matter if it's a global file or application file.
If we're in a container, we can't see that global file, so we cascade with nothing.
On top of that, if we do want to get global configuration values,
which we can do through your portal, we can say, I want to grab this global
config option from the host, we need to handle it explicitly.
So we have a mechanism that makes it really difficult to see whether we want
to do something from the global file or not.
So over time, I think our concept up to KD Globals, it's just getting in the
way and we should port away from that into development files.
Yes, things are complicated and software is hard.
Let's go shopping. Okay, wallet. Yes. I'll explain how the wallet systems are
meant to work in containers, and nobody really does this yet.
The way it's meant to work, if you talk to your portal and you get one password
back, you don't know what your password's for, it's just one password back,
and then you use this password you've got back from the host keychain to unlock your keychain.
So it's this two-part system and that way it doesn't matter what's being used
inside a Flatpak, it could be any library to store all of the keys.
That's not how KWallet works. KWallet talks to your host and expects you to
query key value pairs of your keys.
And we're moving to another library which also doesn't handle this very well.
So we need to think this is where things are heading, let's try and target that
now rather than trying to do something now and importing again in a year.
It's a very negative talk so far, there's a positive aspect.
KIO, super core part of KDE, it's one of the big shining things of this is something
we have in KDE is a KIO, which allows you as an application to grab something over FTP or Samba or NFS,
without going through a horrible kernel stuff that doesn't work.
So, does it work in a Flatpak? Sort of, ish.
If you open KWrites, we also bundle our plugin to be able to talk over Samba,
and it can load that plugin internally and load a file.
But your password sharing isn't shared and doesn't work very well and we also
don't have file change notifications because that's on the host with the KDEAD
modules and if you allow the application to access KDEAD lots of bad things
happen because it can do a lot of things like unload KDEAD.
So copying what GNOME does is always a good idea.
There their file system abstraction runs as daemons and applications can talk
to these daemons in a somewhat safe way and say I've got this url can you open it for me.
And even if you don't support that their equivalent fallback where we have KeoFuse,
they have DVFS hues, where you can use your normal POSIX API to open a file, they have that working.
Our situation, a little bit ropey. Nico, did you want to say something?
Okay, just chill down for a second.
The other thing we need to think about with frameworks, moving forward,
not necessarily over the next 20 minutes, but over the next five years,
is how we structure things.
In In KF5, we layered things based on their dependencies for external usage.
And that's all we thought about, really. We need to approach this from the point
of view of how is it going to be used and will it work in an SDK?
If it doesn't work in an SDK, maybe it should be a framework,
but maybe it shouldn't be in the SDK that we present to people when they first go to api.kde.org.
And we need to split these concepts.
So I'll go through an example. KDVS add-ons, very nice framework.
Does it belong in Flatpak? Yes or no, hands up for yes.
Yes, sort of. Answer is complicated, because some things yes, some things no.
So people who are ambivalent, which is all of you, were right.
So KDBusService is a really important class for having a unified Dbus interface
that all three desktop applications are meant to implement.
That's part of this framework. Yes, we want everyone to have that.
KDEVModule is a thing for running things in the host in the same binary.
That doesn't make sense.
K update launch and job, a very specific class for updating environment variables
used by a demon demon, Dbus demon, next time it launches something.
No, it clearly was all nah, but well done for that.
So we've got a mix. And as we approach KS7, we need to look at saying,
well, let's try and split this based on that. Will it actually work?
And more generally, does kof belong in the SDK?
No? Open questions. And does Baloo work in SDK?
It requires the database to be of the same version that your application is
running. We can't really guarantee that.
So maybe there's other ways to expose the contents of the database to applications,
either through a virtual file system API, which we have all the code to do.
There's a lot of options, but we should start exploring them.
K-purpose, also plug-ins, doesn't really work. So we need to start approaching this.
Can somebody bring me more water please? Oh, it's done now. Nate,
can you grab me a water? Thank you.
Flat pack integration within Plasma. It's the other topic of this.
We've got, we've got Plasma. It doesn't work very well. It works,
sorry, Plasma works very well.
But the integration with applications and Plasma is very challenging because
the whole point of a sandbox is to separate these two things and historically
we've had this tie-in where we're saying we've got this application in Qt,
we're going to inject these plugins and try and manipulate it to work well in our desktop.
And that part doesn't work so well.
So styles, your Qstyle, we allow people to choose it and that's a plugin.
Does this work in Flatpak? Kinda. Oh a trick you all.
Yeah it kind of does work, but also no.
So As a user, you have to go and manually install, if we don't ship it,
your Qstyle on your host, so this KCM sees it.
And then there is a mechanism to add plugins into your SDK that we provide.
But it's not hooked in from this KCM, and that sort of falls apart.
And even if it did work, it sort of undermines the sandboxing if you're grabbing
these external plugins and trying to mess them around.
So we need to move away from this concept of us injecting things into other
processes dynamically.
So there's a talk tomorrow from Ian about a new way to approach styles,
where we say, let's try and just use one style and then have other ways to theme
this, which is based on configuration values,
rather than injecting binary things.
The other plugin we inject into the application is a QPlatform theme.
For most other applications, it's hosted in Qt, Plasma, we host it in Plasma
and release it in LockSync with Plasma releases.
But that doesn't get loaded, so on the Flatpak side, they grab this repository
and also bundle it in whichever Flatpak SDK release we have.
So that also somewhat falls apart because you might be running an old version
of plasma integration on a new plasma.
Which requires us to keep all of these things in sync so it actually keeps working.
So can we use container tech to improve Plasma?
Yes, this is a positive bit of a talk. So I'm going to go for a case study of,
how other people can extend parts of Plasma, which is the opposite way around
rather than apps, Plasma extending applications.
So K-Runner, it used to be a plugin systems where we had K-Runner,
it was a framework and people could write binary plugins that Plasma then loaded.
And that gets you so far, but only stuff that distribution is then packaged.
It's very difficult for third parties to do anything that any user can actually use.
So we try to move away from that And we move to a process where KRunner talks
Dbus, FPC, to another binary in any language that gets launched with Dbus activation.
We say, the user searched the word foo. Do you have any results that match the
search? And then we display them and maybe invoke the action.
And we landed that in 5.27.
And users started shipping this stuff. And on get hot new store stuff,
a KDE website, we have 50 plugins of people, not plugins, sorry,
50 ways of people, 50 runners. Thank you.
And then those scripts were just bits of Python, things that you can just randomly
run because they're scripting language. You can just download and run them.
Except that's not even how scripting languages work. They still have dependencies.
So those scripts started calling apt-get and RPM and Pacman and doing horrible
things that scripts should not be doing. And we started supporting that.
And the result's a mess. So we want to use that same amazing infrastructure
that Flatpaks and Snap should provide.
And there's nothing fundamentally stopping us from making that work,
except for some tiny details.
We've acquired a desktop file, this config file that says, I'm a runner,
please run me, to be installed into user share K-Runner Dbus plugins, which Plasma can't see.
Because the Flatpak environment doesn't copy a file to any way the host can see.
So fixing is easy. Just move where that file is to a file that we can see.
And I've ported one of these runners to be in a Flatpak. It was a two-line change
and now we can start getting runners in Flatpaks.
But it's also interesting that GNOME had the same problem with their identical
framework GNOME search,
and they patch Flatpak to just also copy a file, which is the approach we should
be looking at in terms of how can we fix these, just modify a software that
gets used, is a valid approach.
And we have the same problem in a few other places in Plasma.
Solid device actions when you plug in a USB pen.
Or your SD card, you might want to automatically open it in Gwenview,
and you can write these rules that say, if it's an SD card and there's a folder
called DSIM, open Gwenview.
And that absolutely can work in a Flatpak world, but the host needs to better see these files.
And we have this really nice feature that we all love, where we can configure
application notifications in Plasma and I like it,
but it's not going to work for any Flatpak app because it requires reading a
notify RC file that Plasma can't see.
And that needs a solution or it's going to just end up in the bin.
Another case study. File thumbnails.
File thumbnails are really important because tricking a user into plugging in
a USB drive or downloading a file is relatively simple.
You don't require social engineering to make somebody download a file.
Making them open it, sure, but then hopefully it's in that sandbox environment.
But to show a little preview of it, someone needs to open a file and look at
the content and make that little preview. you.
So it's currently shipped as plugins that have to match the same version of
Plasma that we are running right now, or the same version of Dolphin.
If you've got an app like Blender that wants to install its own from-lailing
tool, it can't because it can't export a file to do so.
And they're currently running on our host completely un-isolated.
And I'm pleased to say it's in work merging to Kira right now that should allow
Flutterpack apps to make your own thumbnails and start sandboxing the stuff
we have, which is going to be awesome.
And long term, we need to be thinking about using this container tech for all
of our applets, all of our extra KCM modules, so you don't have to be inside our base.
And that requires some new infrastructure that doesn't exist yet.
But hopefully, that's something we can work on over the next few years.
And I intend to work on over the next few years.
Questions? Or lunch? Snack?
Nate, do you want to just shout? Oh, the microphone here. Okay.
Does it work? Maybe? Yes, it works. Okay, so I'll be brief with my question.
What do you think is the ideal balance of changing our apps to work with Flatpak
versus changing Flatpak to work with our apps? About a five.
I think it's a compromise. It depends on the situation. We should try.
And we can say we've got... is if it's no work for us to change,
then we should just change.
If there's a benefit to changing Flatpak, we should change Flatpak.
And we can at least try our approach and see what works.
So there's no right or wrong answer to any of this. It's a see which is the
path of least resistance.
The question in front.
So I have seen complaints about the free desktop secret service,
as in it gives you a false sense of security because actually everyone can see everything.
So how is your work going to make this better or address this issue?
I think there's a difference between where we want to go and where we are now.
And we're approaching this in a very transitional way of let's actually get
apps using this framework and then tighten and tighten and tighten and tighten.
Rather than what we've seen in some other transitions of saying,
this is a perfect world we want to jump to.
And then everyone's struggling to actually make anything work. And that's a balance.
And I think it was just something that we're just going to transition to over time.
And you're right. Right now, maybe there's a false sense of security.
But the alternative is also not safe at all.
So, as long as we're transparent to the user, that should be okay.
And I think transparency is really important.
And that's something we can definitely make sure is right. And that's something on us to fix.
But the technical side is just about time and putting in the effort.
Portal actually owns the portal. Yes, sorry. I missed your question. Secret Service.
Yes. Yeah, yeah, sorry. Yes. Secret Service basically has the security model
of KWallet, which is anything can access anything.
But the portal is the thing where you only get that one key.
So that should be secure against that. It should.
But we need to actually make use of that. I should mention on the KWallet side,
Carl has a talk, a buff on Tuesday about wallets so if you're interested in
wallets and Secret Service and the other Secrets Portal,
go to that and we can make sure we come up with something that works and is amazing,
That would be good because secrets are a mess right now everywhere,
But I've been following what Gnome have been doing on the project that got the
Sovereign Fund money and they were open to collaboration operation on the daemon side.
What about running more Plasma core resources as flatpaks?
Like for example, running kScreenLocker in a container or Quinn, or maybe even KRunner?
I think definitely over time, it's one of those, let's keep adding and adding and adding and adding.
Um, I mean, the things with Plasma are always a little bit difficult because
we need to launch applications and do all of the things that we need to do.
So I would like to see more because I want to see that core reduce.
So I think the important part is to get things like print manager out so that
can have a different release cycle and those sorts of things out first and then
a core stuff comes later.
So really focusing on a cost to benefit ratio.
If there's a huge benefit with little cost that's what we do first and then work our way way down.
So I know it's going to be bad, right? Is it working? Okay.
All right. There we go. So you talked all about how this, you know,
sandboxing and permissioning and all this fun stuff that you want to have in
applications, SDK, Plasma.
Yeah, some sort of KD goal, if you will.
I'm not going there. uh but uh i i kind of think that the actual thing you want
is to see the plasma stack as a whole,
operate with the assumption that there's a sandbox and that we have a sandbox
delivered with a manifest that executes on that yeah i don't think that necessarily
means we're coupling it with Flatpak.
There's a tool out there that I saw some months ago called BubbleJail,
and it basically takes the same security confinement manifest that you use in Flatpak,
and it takes it out and you can use it for arbitrary application processes and
services regardless of delivery system.
This is something that could make a ton of sense for us to use now to start
moving towards a sandboxed model for sensitive processes?
100%. I mean, it's about using the right tool for your job. And if stuff is
coming from a third party, you need to think about a distribution as well.
If something like the thumbnails we talked about, if they're coming from KDE,
yes, I still want to sandbox them, but I don't need to worry about your distribution.
At which point, you're right, we need to find a tool that only covers that one part of your job.
I think we've got time for one more question.
Is there, so from what I understand, your focus is top level,
so to speak, applications and not the base system.
Do you know if there is any work on KDE working to make it more easy to work
with immutable usable OSs like Micro OS that uses read-only stuff like read-only user.
I think maybe hang around today, go to Howard's talk.
Is that? Yep. Hang around today, go to Howard's talk and have a look what he's doing.
What's the name of the cool talk? An operating system of our own.
An operating system of our own, and that might have some similar concepts.
I've been told to stop, so I will leave. Thank you.