Cool. So today I'm going to talk about Linux.
I'm going to do a little bit of a different presentation than I would normally do.
Actually, I will be doing a different presentation than any sane person would do.
This is all of me. My name is Aleix. I am from Barcelona. I'm living in Berlin.
I am living in Berlin because I went to work for Ambition to put KT software
on and we learn things on Mercedes cars but I've been doing kiddie stuff for
ages and I'm also the kiddie beat president now.
Normally when I or like I
said saying people would do the presentations
they say well I'm doing this presentation from this perspective what
I'm gonna try and do today and maybe I will succeed is
to like sandwich all of these personas into one presentation
and try to give you um well somewhat
of a combined experience of how everything uh
feels uh from
the different perspectives uh from the perspective of um while doing a kd developer
and seeing your software being adopted by another company and how they adopted
from the perspective of um being an integrator of free software in these companies
and seeing what kind of practices are useful to be done,
are useful when they're done by an open source project.
And then the perspective of being in the KDV, being a person in general in the
community that tries to think how we can do our products a little bit better
and a little bit more smart.
And while seeing which things works on either side, right?
Let's see. Maybe it will be chaos, maybe it will be interesting for everyone,
or just probably a little bit of both, like everything is in life, right?
So, on the title I was talking about embedded Linux. Embedded Linux is something
that I had been, and I imagine that all of you who have not been working on
it professionally, you've seen the term being used.
And it does feel a bit diluted and you know and understand all of the technologies
that are part of it but they're clearly being used in a different way than we
normally do this is the definition that windriver.com gives windriver being
one of the companies that have been doing,
embedded links forever since forever so i thought
uh let's go with this one because they did it
right like when embedded has been
presented to me in the past people tell me about no no
no it's about uh systems that have not a lot of memory or it's about systems
that uh i don't know they're smaller right but like none of these are actual
um things that define a system that would say you need to work differently or
you would need to make an operating system in a different way and even Even when Wind River,
who are people who sell themselves as creators of embedded and embedded Linux devices,
the definition they give is also kind of sparse, right?
They talk about using the same Linux kernel, but they want higher reliability, they want.
Security, tighter resource availability, right? None of these things are super
specific about any embedded device.
And even if we think about embedded devices, like, for example,
when embedded maybe started to appear in the KDE spheres where when,
like, smartphones started to be a thing and, like, they were already not that
different from what we have on a laptop.
And, like, for example, what we do in Mercedes, like, the computer that you
have on those cars is not all that far off from this laptop or any smartphone.
So, like, we're not on the crux. But on the other hand, how these products are being created is very,
very vastly different from how we do it in communities and the traditional desktop
and probably even server Linuxes, how they're created if we exclude the whole container part.
We, as KDE, we do care about all of those things, right? Like,
we care about security, of course we do. We care about resources.
Do we not care about resources as much as an embedded device?
It will definitely depend on the hardware.
But, like, resources have been a big thing for us. And, for example,
when we, like, PinePhone came to us and they told us, let's put together a device that works.
Well, we did have, we were able to put a lot of effort in resources that actually,
like, had a very big impact on the rest of our products, right?
So we do care about that, and that's for sure.
Reliability, I think that it's obvious that we want to be reliable,
and every piece of software will want to be reliable in general.
Maybe not by the same measures that some of them will, but again,
it's not something that is like a yes or no kind of question.
And availability, well, same thing.
So that is kind of why I call it a lie. right like it
is a lie because they're not doing
something really different maybe
actually like the branding of embedded Linux is
created to be able to have your sales people go to the different work clients
and explain how they want to do things different but and that is because that
useful lie right When an embedded engineer goes into a project and looks at it,
what they want to effectively make sure that always happens is that the person
who's using this device gets to do what they want to do.
The use cases will normally be probably more narrow, but creating the thing
that I think that just works.
Maybe right now you can be thinking this is also what we do but those of you
who are developing KDN's.
You also know that this is not right like we have a lot of of um decoration and things around,
how we work that are not only about how making things just work for example
we don't release things every day right like if we want the thing to always
just work every time we do a bug fix we would get that bug fix into our users
devices right this is not how it happens there's good reasons why it happens,
there's good reasons why we don't want it to happen every day,
it wouldn't be convenient,
it also probably doesn't make all that sense, but this is kind of the difference,
and this is normally done by allowing whatever person is doing this integration
to just fork and license the software, like, no, not license,
fork and adapt the software to the use case of like that device,
like let's say this little display or,
where this phone if you are have decided that it needs to always just work,
you will do whatever to the software that you're shipping in there to make it work, just work, right?
Which is gonna be a bit of a,
Contraposition of how we normally work because we also are trying to make things
work all the time, right?
This leads me to think that maybe on the other side of things,
we've been complicating a little bit our story.
And I am very well understanding that I am not the only person kind of talking
about this topic right here.
Harald talked about this proof of concept of operating system that he's suggesting we do.
Yesterday, it's very much aligned with what I'm talking about here. year.
I think David, I didn't see his presentation, but also was talking about this topic quite a bit.
But in practice, we've definitely complicated the story, right?
Like, it hasn't been just us delivering to our users.
We've had a whole mechanism that is complex,
and it is complex also for certain reasons that is put between whoever is doing
that bug fix and whoever is leveraging that bug fix.
But has made it so that these bugfixes that whoever wrote is not yet on your computer.
How this ends up happening is by shifting somewhat the responsibility of the
stability of your system to the user.
And we end up doing that by creating a big dependency tree.
We do that by telling them, you can update whenever.
We do that by different ways. But it's about shifting this responsibility of
who is responsible for making sure that the product works.
On an embedded product, it would be always the manufacturer.
And the manufacturer will be insisting you on getting everything up to date.
And the more distance you have with your user, the more flexible you will be
with this kind of definition. definitions.
Another thing that is very important is that in practice, we don't have a lot
of information about how software ends up being used, right?
An embedded developer, again, will be thinking of a very specific use case,
and then that's why they have this, or they take this license to modify and
adapt the software they create.
They think that they fully understand their use case
and they go all the way with it which is something that on the other hand kd
we have probably not really done in in the past we've been while trying to make
everything super configurable and we've been trying to make everything,
adaptable to the different use cases and like linux distributions and all of that and,
And maybe that's probably one of the differences within us and these embedded integrators.
So what I wanted to talk about today a little bit would be, how can we better
serve this industry partner?
So if other projects want to come and work with our software,
how we can make it so that we can work together better?
What can we learn from maybe my experience and the experience from the people
who do this kind of projects?
And which strategies we can adopt as KDE that will better serve KDE, right?
Like, if we have more of these people contributing patches, for example,
we will improve because, and to be super clear, having people using our software
doesn't improve It just, well, it's a happy thing.
Maybe somebody will get a job, but that doesn't improve anything.
Things start improving when you start getting the patches, you start getting
bug fixes, or you start having some kind of conversation, right? So, yeah.
And there are some certainly some things that we can do or that i think that could be interesting,
that um yeah so as is and like the first thing that um normal uh embedded developer will do is,
when something doesn't go their way we'll start to patch your thing and uh maybe
it is obvious Yes, but what I want to convince you all today is that this is a bad thing.
The moment that they patch your code, everything will start to become more complex.
For them, for example, they will have a harder time updating to your next version.
They will have less incentive to create patches for your software,
because when you release your software with the patches that they created,
they won't be able to rebase it, because they had other patches.
And it all becomes a super complex story.
So if we make our software, maybe here I would have in mind more Queen,
which is what we've been working on mostly, but not exclusively,
like also a ton of frameworks.
If you create the software in ways that are easily extensible without modifying,
so let's say adding plugins, adding what things that happen around,
around having other processes that modify the behavior of the system in general.
Then you have the opportunity of telling them, you make your configuration,
your special thing over there outside, and then you keep a somewhat clean,
queen or whatever project we're talking about, and the maintainership of that
will be easy, the maintainership of your own modules,
you get to do that because they're your own, you don't even need to do the whole
engineering of patches, which.
Is a pain in the ass and i don't think anyone wants to do that and
well these are being done with all of your software
if you have any free software uh in in
the open right um another thing
that is very important is this encouraging of working upstream
a lot of the embedded developers might not even be like open source people like
there's a lot of open so uh people working on linux and open actual open source
software that i don't know they don't have the drive to uh go to go to academy
every year or to join regular communities, right?
But encouraging, explaining and doing all of this work, it needs to happen.
Because, well, that's how we collectively win. And like there's objective reasons.
It's not about at this point, moral or ethical reasons, like software should
should be ethical or open.
It's about we're all engineers solving complex problems.
Let's make sure that we have one source of truth that is where you actually,
they all got the software originally from, right?
And even if they do everything correctly, it will happen that they will be using,
old versions of the software. We do see that in the normal non-dat-embedded Linux normally, right?
That people in their offices, in their stuff, they have weird old versions of
random software because somebody decided that upgrading it was a bad idea.
And this is bad.
This is bad because it's less incentive for everybody to upgrade things.
But, well, I guess we need to be still mindful of it. I still gave it a thumbs down because of...
On the other hand, since we know that, we know that we need to be mindful about compatibility, right?
So if we create new interfaces or if we modify interfaces, interfaces.
If we keep, for example, source compatibility on a lot of things,
it's very useful because you don't need to, like, the maintainership remains low.
If things want to change, they get documented. Well, you have something to sit onto.
I know that a lot of the, like, rebasing work I've done in Queen,
for example, if I hadn't been so involved with the KDE part of the development,
it would have been very hard for me to follow and do.
And actually, even in this case, we are carrying huge patches that,
well, when we release, we will need to keep in the open, because Queen is open source, right?
Well, it's GPL, so it's part of the license.
You will see that they are pretty hefty patches, so making sure that we explain
what the changes are and what the compatibility looks and tries to be is important.
And if for example, like I was saying before, if things become plugins,
well, make sure that these interfaces are reasonably stable,
right? That's something you can always do.
Like this cosmetic changes in code go a little bit against the well,
the spirit of what I'm talking about.
And I was talking about before about
how they won't be that familiar with our uh mindset but
also it's like i said they won't be following
the planet every day they won't be following uh like our matrix channels every
day so it's not really about documenting things i think that very often or more
often than not if we can simply make just things simpler i think that it serves
us all collectively better uh And I do think that we've,
in KDE, not always valued simplicity as much as we could have.
So I don't know. Maybe if it's something that we can keep in mind when taking
decisions, it's something that in the future it will serve us well.
I was talking about plugins before. And in the Qt and C++ world,
this normally means ABIs and actual...
Shared objects that get loaded. These are also like a bit harder and more tightly coupled.
Like you're already talking about C++ headers.
It actually means that all of these extensions need to be implemented in C++,
for example, when like companies and increasingly actually like C and C++ interfaces
are well becoming less and less standard, right?
So because people like to use Rust and Go and I don't know, Dart.
So making things, if things can happen in different processes,
it means that, for example, you can implement it in any kind of technology and
you're less tightly bound in this kind of way.
It also means that, for example, you can consider sandbox all of these processes,
which actually is something that we could leverage ourselves.
In fact, in KDE, we do have a problem with that. that, right?
Like, right now, we need to have all of our plasmoids in Plasma Shell in the
same process, and all of the QML plugins need to be specified in a certain ABI.
And I don't know, I think that it's pretty clear, like, when you're starting
Plasma Shell, like a lot of what's happening there is a lot of like,
QML things that maybe could happen in other processes, and we could parallelize more.
A lot of the blocking that happens, for example, is in Dbus, right?
I'm getting ahead of myself. But what I just was meaning to say here is the
more we can move into separate processes, the more we can keep things separate,
the more powerful we all collectively become as well that way.
Something that is sad but also not entirely sad is that organizations will decide
to use open source technologies because they don't really care that much about it, right?
Like if a big organization decides to use a piece of open source software is
because they want to build something on top of it.
It's not because they say, now we're going to put a huge team here to work on it.
And like this is bad because it means you are not going to have a whole lot of development.
It also is good, I would say, because it means like they're not normally going
to like come and like disturb you, all of your the chickens in your community
because they're building on top of it.
So making sure that they can contribute, I think, the patches on top,
making sure that there's a good communication and relationship,
inviting them to things like the advisory board also is useful.
I think that this is something to keep in mind as well. But normally,
like if they decided that they really care about one of such technologies,
what I imagine, or what I've seen happening in general,
and I'm not even talking about Mercedes here, is like, they just created themselves, right?
Like, how hard can it be?
But it's also important, I think, that for our technology in general,
that organizations are using it, right?
Like, it's probably tempting to say, yeah, asterisk it.
No need to care about other people outside using it.
But it's important that the world outside of ours is using our products and
making sure that it's reliable and it can be ported to different ways.
Like, a lot of the work I've been able to do upstream in Queen,
for example, wouldn't have been
able to or wouldn't have happened if I hadn't done it because of them.
And not only that, right? Like, when I was in Blue Systems and we were working
with Valve and when they are working with Valve, they also get to work on things
that if they didn't have Valve behind saying, this is important,
this is important, and this is important, it wouldn't happen.
And I am sure that if you talk to anyone who has been working on one of these
projects, they will be able to tell you that they have done fixes,
they have done optimizations, features,
that they wouldn't have worked on if it wasn't for one of these clients and
it has been for the best of the community and of open source in general.
In KDE we do a lot of testing for sure. It's also done largely in the context of a community,
but also, for example, if I see the amount of money and involvement that there
is with testing, for example, in Mercedes and again, other deployments, maybe Valve,
it's on a whole different level as well.
Well, so that's also a good reason to make sure that these organizations use you, right?
They will have like big, I don't want to say farms,
but like groups of people whose job is to like touch the UI to make sure that
things pop and they will find you issues with like, I don't know,
lib input when you press every two seconds and you don't know what's happening, right?
So, yeah, like we are not here to sell this industry and that's perfectly fine
to say, but we're not that different.
Like we are all sitting on the same kind of hardware.
We are we're trying to like take what we have today and bring it to products
into the future that go in the future.
And the things we end up needing are not that different like we need to keep adding different,
features and we need to support them over time and make sure that like this
over time is an easy thing to happen right and also on the other hand it's not
like we're doing the same things but it's important that when things get done
they get done on the technologies that we're on because um.
Otherwise, like they're fixing other people's products and they get better.
So where does that leave us?
This is very long, but I don't want to get into it. Are we competent about security
model? I think that the security model in Linux is still all over the place.
It is all over the place for desktop.
It's all over the place for everything else.
Everybody's doing the same thing. Red Hat is going in one direction.
Canonical is going in their direction. and this all takes us in a very weird place.
In KDE, we've made a very, very, very big effort in ABIs and keeping ABIs stable.
I am increasingly thinking that this was maybe an error or it's slowly becoming,
well, less useful in any case.
So my takeaways on this topic are, are.
We'll win if our products are easy to use.
It is when we do it because we can do things like the PinePhone and going into
new tablets and new products and everything is amazing.
Collaborating is useful. I don't think I need to sell you that idea.
And only abstracting what is needed to abstract is also useful and important
and important for our products like we need to sit on tools that are powerful
enough and a way to make sure that things are powerful enough is to see that
other people are also doing powerful things with it,
we need to have a plan for um i don't know what i wanted to say here and.
Yeah, we need to be able to move into different form factors and platforms.
Like maybe something to think is like, do we really need to think,
uh, change anything about who we are? Probably not.
Like we've been serving maybe just different, uh, Lords, but in practice,
what we're talking about is doing, uh, an operating system of our own.
We're talking about, uh, like these hardware vendors, uh, a lot.
We're talking about when we do apps while doing entirely
the same thing but with the different new formats so probably
it's a good moment that we start thinking in this more embedded
and aggressive way of like the important thing is that what we deliver works
and just enjoy being used by people who is that matters right now i think there's
still some time for questions then.
So one thing that I have seen being in companies is they somehow believe their
magic patch is super important and they don't want to contribute it back.
Like this back fix they did, which is like two lines.
They want to keep it forever, which is nonsense.
I know it's nonsense. You know it's nonsense. And I don't know if we could have
some page or something explaining what you said, right? It's better if you contribute the badge.
We're going to be all happier. You're going to have a nicer time updating later.
I've had this feeling that some of the companies don't buy what you're selling.
I guess that one of the important parts here is to make sure that people who
are working on the companies understand themselves what the advantages of open source are.
When you are in a company, you do that. And in the end, like they all need to
release it because we are LGPL, right?
So when this goes in the open, you can always decide also to integrate a change
from a third party because we don't have CLAs and things like that.
So if it's really an improvement it's also like we can also be proactive there.
Yeah actually a comment regarding your comment
so one thing yeah contributing
a patch upstream is always a good idea i fully agree but if you do that at work
then it means convincing the maintainer that your patch is a good idea going
through reviews that can take time and sometimes times well the company is happy
if your two lines patch works it can ship the product and save,
iterations over days and days and continue with other stuff that's a practical issue,
Yeah, you're completely right. This is something we were actually talking,
discussing with Kai Uwe the other day because he was in this same situation.
It has been a whole thing in Mercedes as well, how do we make sure that things go out.
I think that first, making sure that engineers and the people who are in charge
understand because first of all, it's their job, right?
I don't think anybody has been in the right by saying this patch shouldn't go upstream.
And I think that us as engineers, we need to be confident enough to tell our bosses that.
Obviously, every situation is different and, well, social problems are social problems.
But I think that it's our responsibility, I think, as open source engineers
and people who understand what we're doing to convince them.
What we are discussing with Kai as well would be if there's possibilities abilities
for doing, for example, from KDE or even from another organization like FSFE or whatever,
like having pages or documentation explaining why this is a good idea,
there might be value in that.
But I don't know. Like if somebody has a great idea of how that would work,
that's something we can do.
The problem, I guess, it becomes when or it happens when they start saying,
no, no, no, it's legal reasons.
And then obviously we have to go, yeah, I'm not a lawyer, but this becomes a bit more complex.
But I mean, we're all a bit lawyers, so we can all leverage that, I guess.
And if not, we need to be friends with lawyers who can have this open mindset, right?
You're laughing because I said friends with lawyers? Oh my God.
Is there any other question maybe?
First swing. That's what I'm going to do.
So, what I have experienced is that contributing a patch upstream is,
while it's completely normal for us.
It's a completely foreign idea to a lot of,
normal developers. This doesn't come to their mind that they could contribute
that upstream to the project.
Which, yeah, I don't understand, but that's what I see.
I thought it was interesting what you said at the end about maybe Plasma being an embedded product.
This is something that has occurred to me as well.
To what extent do you think that the customizability and flexibility that we
offer in Plasma is ideally targeted at vendors who want to create a customized
experience for their users?
I mean we're already in this discussion right like if
we decided to take Harald's proof of concept today
and ship it to our users we will need to come up with
solutions for I don't know how do you install this weird
thing that always appears on your shell or how do you
install new queen plugins all of that like we're
on this game we need to
have with technologies which is the other side and that's why i was talking about
uh security model earlier like there's
a lot of things that we don't really have good answers for just
yet like um i remember
talking with uh valve uh years ago and they were talking about how what happens
if this application wants to put a menu over there and stuff and stuff and you
simply cannot do that right now on wayland uh we need to find ways and i actually
i think that part of the solution here is.
Also ourselves, like in the recent years, we're also trying to squeeze a lot
the things we led the third party applications to do.
I think that we need to unsqueeze a little bit, because we need to make sure
that we support the world, that the world can use our technology and do everything they want to do.
And I think that this is part of the discussion there.
But it's entirely a social thing, like saying we need to implement this protocol
and this other protocol, and then everybody can do the things they were using.
And like the switch to, for example, to Wayland, the switch to a container, the switch to a.
Uh an immutable operating system they become uh non-question
and we can actually focus on like actually starting
to deliver products that are useful for everyone
like for example to make sure that uh we can offer an operating system to uh
our hardware vendors and know that it will uh well not break like harold was
saying when they upgrade and all of that like this needs to be our stepping
stone because otherwise we cannot be always saying we're better.
People should be using us, but having this small asterisk of like,
unless you're using Leap C 2023, blah, blah, blah, because everything breaks, right?
Like we need to be able to produce things that we can put on hardware,
then get shipped on the other side of the world.
And we know that when they upgrade, when they get a new version,
whatever it won't break and if it breaks it's because the laptop exploded not
because we did a typo on our packaging or whatever right also if the laptop
explodes it's not our fault which is to be the good side of it although clearly a tragedy.
All right um so if there's no more questions and you really like this topic
you can reach out to me and choose whatever hat you want to discuss it under
and I'll be happy to thank you very much for listening.