WEBVTT

00:00.000 --> 00:15.000
Thanks a lot for coming. Welcome to my talk about a potential path for the future.

00:15.000 --> 00:21.760
So I have too many slides, so let's get quickly over with. I'm Dan, I work for Sousa,

00:21.760 --> 00:25.600
I've done package maintenance, I've been doing it for a while. If you want to send me

00:25.600 --> 00:30.600
hate mail later on, you'll find it in the slides how to contact me, but please don't.

00:30.600 --> 00:38.600
At least not with hate mail. So what are we going to talk about? Mostly start out where we are.

00:38.600 --> 00:44.600
What kind of is the problem that I see in our in the way how we build distributions?

00:44.600 --> 00:51.600
And then we're going to take a quick look at a few notable examples that popped up in the last

00:51.600 --> 01:01.600
years and that successfully employed, let's say cloudy container technologies and attracted quite the user base.

01:01.600 --> 01:09.600
And then I am going to present a proposal what we could do and essentially you can just see that as an inspiration

01:09.600 --> 01:16.600
for what we could do or maybe won't. We'll see. So where are we?

01:16.600 --> 01:23.600
And essentially I'm please don't take this as an offense, but if I look around the room,

01:23.600 --> 01:30.600
unfortunately, it kind of confirms this a little bit. The open source.

01:30.600 --> 01:37.600
I'm getting older as well. We're all getting older and there's not that many young people trickling in.

01:37.600 --> 01:43.600
So tide lift made the survey that the open source community is getting grey and grey on.

01:43.600 --> 01:53.600
If you want to find this blog post, you'll have to go to archive.org because they got bought by so-and-a-type at some point and now it's down.

01:53.600 --> 02:00.600
But this thing looks kind of okay. People are getting older, but if you look at the data, it's like from 2021 to 2024,

02:00.600 --> 02:05.600
I wouldn't count that as so such tremendous evidence.

02:05.600 --> 02:14.600
So we went digging a little bit and if you're looking for developer surveys, that's the elephant in the room and that's the stack overflow developer survey.

02:14.600 --> 02:19.600
And so what you see here is I hope you can read it.

02:19.600 --> 02:29.600
It's essentially a graph from 2016 to 2025, how the developer age distribution evolved.

02:29.600 --> 02:38.600
And then you can also see an interesting pattern evolving by itself, which I must admit I do find it surprising,

02:38.600 --> 02:45.600
because you see that the majority used to be between 25 and 34.

02:45.600 --> 02:54.600
And that one shrunk in 10 years by about the same amount that's the 35 to 44 core group.

02:54.600 --> 03:06.600
So that part probably just aged. Fortunately, the part the developers between 18 and 24, they didn't shrink by as much.

03:06.600 --> 03:10.600
So there's younger people coming in.

03:10.600 --> 03:12.600
But what does this tell us about us?

03:12.600 --> 03:21.600
Literally nothing because what's the overlap between the distro builders and general developers?

03:21.600 --> 03:31.600
So let's look at a few other surveys. For instance, Linux Foundation ran a diversity and inclusion survey in 2021.

03:31.600 --> 03:37.600
I overlay the stack overflow survey data from 2021.

03:37.600 --> 03:45.600
And you can see well already the Linux Foundation, which is not just distribution adjacent people already there.

03:45.600 --> 03:51.600
We see a big overlap of older folks.

03:51.600 --> 04:00.600
Debian ran something like that. In 2016, sadly not since then, at least nothing with actual demographic data.

04:00.600 --> 04:14.600
That one is with data from 2016. Again, you see quite a shift towards older people, older developers.

04:14.600 --> 04:27.600
Now, from my side of the world, open-susa that definitely matches my perception of the open-susa community, which tends to be relatively old.

04:27.600 --> 04:31.600
This is a maintainer survey from 2021.

04:31.600 --> 04:38.600
I think it had only something like 220 respondents, so you've got to take it with a grain of salt.

04:38.600 --> 04:42.600
But you see a certain trend here.

04:42.600 --> 04:51.600
Sadly, I couldn't find really any distribution that did a demographic survey at one point at an later point, where you would see some kind of shift.

04:51.600 --> 04:54.600
But I hope you get my point.

04:54.600 --> 04:58.600
And then let's take a look at the heap new stuff, the CNCF.

04:59.600 --> 05:04.600
They ran a survey called the state-of-cloud native development in 2025.

05:04.600 --> 05:11.600
If you overlay the stack overflow survey from 10 to 25, you see it matches pretty much exactly except that best.

05:11.600 --> 05:15.600
More young people, a little bit fewer old people.

05:15.600 --> 05:22.600
But this shows you something, and that's essentially what do developers want.

05:22.600 --> 05:26.600
So let's look at the stack overflow developer survey.

05:26.600 --> 05:30.600
This is the most admired, most desired.

05:30.600 --> 05:33.600
That's the admired versus desired column.

05:33.600 --> 05:36.600
You see, admired desired darker.

05:36.600 --> 05:38.600
It's number one.

05:38.600 --> 05:43.600
Then at some point you get AWS Kubernetes, NPM.

05:43.600 --> 05:47.600
Well, the web is eating the world.

05:48.600 --> 05:54.600
And another thing that's also pretty, pretty jarring is code and documentation.

05:54.600 --> 05:59.600
Collaboration tools get up is by far number one.

05:59.600 --> 06:04.600
I have questions about point number four.

06:04.600 --> 06:06.600
I don't know why there's Gira.

06:06.600 --> 06:07.600
I don't know.

06:07.600 --> 06:14.600
Every time I have to use Gira, I think about debugging Pearl code because it's more fun and more enjoyable.

06:15.600 --> 06:17.600
So, but yeah, but you see Gira.

06:25.600 --> 06:27.600
I doubt that's going to change anything.

06:31.600 --> 06:39.600
Yeah, so anyway, now we have to ask ourselves why aren't we up there?

06:39.600 --> 06:41.600
Why aren't we desired?

06:42.600 --> 06:48.600
And I don't know how to formulate this nicely, but our tooling and our platforms.

06:48.600 --> 06:50.600
They aren't just cool anymore.

06:50.600 --> 06:52.600
We aren't cool hot shit.

06:52.600 --> 06:56.600
And I mean, well, I think most of us are developers.

06:56.600 --> 06:59.600
We like the cool new stuff.

06:59.600 --> 07:03.600
And sadly, we've been around for 20, 30 years.

07:03.600 --> 07:05.600
Stuff is established.

07:05.600 --> 07:09.600
And it's just not super exciting anymore.

07:09.600 --> 07:15.600
Also, to a certain extent, our values aren't that super exciting and that much respected anymore.

07:15.600 --> 07:19.600
If you're very much into software, into software freedom,

07:19.600 --> 07:23.600
people at least many developers tend to be more pragmatic.

07:23.600 --> 07:26.600
And just slap my T on it.

07:26.600 --> 07:31.600
Don't caff it's GPL or MIT or don't care.

07:31.600 --> 07:37.600
Something that might become a problem and that one I can at least tell you from the open suicide.

07:37.600 --> 07:40.600
The other lamps are not trained on our tools.

07:40.600 --> 07:43.600
They don't understand packaging formats very well.

07:43.600 --> 07:46.600
They guess wrong stuff.

07:46.600 --> 07:49.600
And that's going to also be a problem.

07:49.600 --> 07:56.600
So if I ask a cloud for a spec file, it will give me one for centers, not for open suicide leap.

07:56.600 --> 07:58.600
And then I have to do the work.

07:58.600 --> 08:01.600
And also building a distribution is very hard.

08:01.600 --> 08:05.600
If you just take a look at what all goals in there,

08:05.600 --> 08:07.600
you have to have to curate sources.

08:07.600 --> 08:09.600
You have to build packages, build repose.

08:09.600 --> 08:13.600
You have to do a lot of QA. You have to publish it somewhere.

08:13.600 --> 08:15.600
You have to hold a whole lot of infrastructure.

08:15.600 --> 08:18.600
And a bad part of that is also it's kind of soft.

08:18.600 --> 08:21.600
Because I think we all do a pretty good job of it.

08:21.600 --> 08:26.600
So why should you get in there as a new developer?

08:26.600 --> 08:30.600
Because it kind of works and I don't care.

08:31.600 --> 08:36.600
And for the average death, the whole pipeline in there looks pretty much like this.

08:36.600 --> 08:38.600
At some point there is upstream.

08:38.600 --> 08:42.600
And then I don't have a wizard head with me, but I take it.

08:42.600 --> 08:47.600
And then the deliverables fall out of it.

08:47.600 --> 08:51.600
So I don't want to spend more time complaining.

08:51.600 --> 08:57.600
Let's take a look at a few notable examples that became very popular in the recent years.

08:57.600 --> 09:00.600
I'm sorry I have to talk about Omar Chi.

09:00.600 --> 09:03.600
That's so if you haven't heard about it,

09:03.600 --> 09:08.600
that's a very opinionated arch Linux been with Hyperland.

09:08.600 --> 09:11.600
It's made by DHH.

09:11.600 --> 09:13.600
It got quite a lot of traction,

09:13.600 --> 09:21.600
surprising a lot from the typical Mac user that develops their Kubernetes app and runs it in AWS.

09:21.600 --> 09:26.600
But one thing that's interesting, it all runs on GitHub.

09:26.600 --> 09:30.600
They meet on Discord, they collaborate all over there.

09:30.600 --> 09:32.600
And if you look on their GitHub page,

09:32.600 --> 09:35.600
and you look at the language distributions what they use,

09:35.600 --> 09:37.600
it's mostly shell.

09:37.600 --> 09:39.600
So it's mostly shell scripts.

09:39.600 --> 09:42.600
I'm not saying we should replace everything with shell scripts.

09:42.600 --> 09:47.600
And Omar Chi is just, it's just lay at on top of Arch Linux.

09:47.600 --> 09:51.600
So it's not replacing for this distribution.

09:51.600 --> 09:55.600
There's also another great example that's the universal blue product.

09:55.600 --> 09:57.600
The universal blue project.

09:57.600 --> 10:02.600
So they have a very nice quote that they put on the web page.

10:02.600 --> 10:04.600
That describes the whole project.

10:04.600 --> 10:10.600
The universal blue is a tool that allows Cloud infrastructure people to use their skills to help the Linux desktop.

10:10.600 --> 10:13.600
Which, in my opinion, is a genius idea,

10:13.600 --> 10:19.600
because you saw all the new developers trickling into the Clouds into the Cloud ecosystem.

10:19.600 --> 10:21.600
And there's a lot of interest going there.

10:21.600 --> 10:27.600
And they have very few touching points to get into a distributing

10:27.600 --> 10:30.600
and universal blue tries to make that happen.

10:30.600 --> 10:32.600
And how did they do that?

10:32.600 --> 10:34.600
Essentially using boot C.

10:34.600 --> 10:37.600
So boot C for those who haven't heard,

10:37.600 --> 10:44.600
that's a project kind of adjacent to Podman and comes from the Red Hat side.

10:44.600 --> 10:50.600
And it's essentially a way how you can deploy a container image that's been built

10:50.600 --> 10:53.600
on your bare metal OS.

10:53.600 --> 10:58.600
I mean, yes, it is kind of the wrong format for the job.

10:58.600 --> 11:04.600
I do agree with that, but the damn thing is extremely successful.

11:04.600 --> 11:09.600
And for completeness, they, everything is on GitHub.

11:09.600 --> 11:12.600
The CIS on GitHub actions.

11:12.600 --> 11:16.600
They talk on Discord, Discord, but as I said,

11:16.600 --> 11:22.600
they've been very successful of recruiting new contributors,

11:22.600 --> 11:26.600
because every new developer knows how to write a Docker file.

11:26.600 --> 11:28.600
Every single one of them knows that.

11:28.600 --> 11:31.600
And that's just a huge enabler.

11:31.600 --> 11:36.600
Yes, what falls out of it is terrible to deploy on their metal.

11:36.600 --> 11:40.600
I think no one from the boot C team would disagree,

11:40.600 --> 11:45.600
but you just get, you just enable so many poor people to contribute.

11:45.600 --> 11:49.600
So take away what do developers like?

11:49.600 --> 11:50.600
They like GitHub.

11:50.600 --> 11:53.600
I don't think we should switch to GitHub.

11:53.600 --> 11:55.600
I think that's a terrible idea.

11:55.600 --> 11:56.600
They like this score.

11:56.600 --> 12:00.600
Most distros are already there because matrix bridges are cool.

12:00.600 --> 12:04.600
They like opinionated distributions.

12:04.600 --> 12:10.600
Yeah, I think many, there's many opinionated spins of open source of Fedora.

12:10.600 --> 12:14.600
I think there's also variations of BB and Ubuntu,

12:14.600 --> 12:17.600
but I'm not that familiar with that side of the world,

12:17.600 --> 12:20.600
but I think we have some in that regard.

12:20.600 --> 12:24.600
But they like to use their tooling,

12:24.600 --> 12:27.600
and that's where we are lacking.

12:27.600 --> 12:30.600
And so I would like to raise something with you,

12:30.600 --> 12:36.600
and that's can we embrace container-based tooling more?

12:36.600 --> 12:40.600
Maybe not because it's the best tool for the job,

12:40.600 --> 12:45.600
but it's because it's the tool that will help us attract the next generation.

12:45.600 --> 12:48.600
Because otherwise it's going to be the same guys in 20 years,

12:48.600 --> 12:50.600
and eventually we're going to start retiring,

12:50.600 --> 12:53.600
and I don't want that to happen.

12:53.600 --> 12:57.600
So let's take a look at the base of the distribution.

12:57.600 --> 13:01.600
So far we only look at spins that are built on top of all our packages,

13:01.600 --> 13:05.600
but what's really the building block, that's the package itself.

13:05.600 --> 13:08.600
So I come from the RPM side of the world,

13:08.600 --> 13:12.600
and we built RPM packages from spec files.

13:12.600 --> 13:18.600
I threw in one of the packages that I happened to co-maintain,

13:18.600 --> 13:21.600
and essentially it's countdown, so it's not so long,

13:21.600 --> 13:27.600
but essentially a package you have some metadata that tells you bits about your package.

13:27.600 --> 13:30.600
You can add licenses, sources,

13:30.600 --> 13:34.600
define built dependencies, more metadata,

13:34.600 --> 13:36.600
and then you go into the actual building.

13:36.600 --> 13:40.600
So this is RPM everything that starts with a percentage sign as a macro,

13:40.600 --> 13:45.600
that does things kind of either variable or a conditional,

13:45.600 --> 13:50.600
or it could be a shell script or it could be a section.

13:50.600 --> 13:54.600
So let's ignore the exact details for now,

13:54.600 --> 13:57.600
but this one would essentially first you unpack the package,

13:57.600 --> 14:00.600
and you actually build it,

14:00.600 --> 14:05.600
and you should test it if you can, you should, but sometimes you don't.

14:05.600 --> 14:10.600
And you install the whole thing into some destination,

14:10.600 --> 14:12.600
and at some point you have the final package,

14:12.600 --> 14:15.600
you define what goes into the package,

14:15.600 --> 14:18.600
and then my most unfavorite part is the change log,

14:18.600 --> 14:23.600
which fedora fortunately now automated to just take from git.

14:23.600 --> 14:27.600
And honestly, this looks all pretty arcane,

14:27.600 --> 14:32.600
but let's take a leap of faith.

14:32.600 --> 14:35.600
Is it really much different to this?

14:35.600 --> 14:39.600
Where you define your build route,

14:39.600 --> 14:41.600
you copy over your sources,

14:41.600 --> 14:44.600
you install your build dependencies,

14:44.600 --> 14:46.600
you build the damn thing,

14:46.600 --> 14:48.600
you install it somewhere,

14:48.600 --> 14:50.600
and you create another stage,

14:50.600 --> 14:53.600
where you from which you assemble the RPM,

14:53.600 --> 14:55.600
you add some metadata into that,

14:55.600 --> 14:59.600
and then you copy over your binaries.

14:59.600 --> 15:02.600
I think it's kind of similar,

15:02.600 --> 15:04.600
and essentially at the end of this,

15:04.600 --> 15:09.600
you would have a container image with a base layer,

15:09.600 --> 15:11.600
that is your distro,

15:11.600 --> 15:14.600
and the layer above is your package,

15:14.600 --> 15:16.600
and then you just have to take this layer,

15:16.600 --> 15:18.600
and convert it into an RPM.

15:18.600 --> 15:20.600
And because I know how you really love

15:20.600 --> 15:22.600
just theoretical stuff,

15:22.600 --> 15:24.600
I tried it,

15:24.600 --> 15:25.600
I made a tool,

15:25.600 --> 15:27.600
I gave it a terrible name called Rosie,

15:27.600 --> 15:29.600
it's very hacky,

15:29.600 --> 15:31.600
but it kind of works,

15:31.600 --> 15:33.600
and it essentially does exactly that.

15:33.600 --> 15:36.600
So it builds RPMs from these stalker files.

15:36.600 --> 15:39.600
And you just have to shift concepts a little bit.

15:39.600 --> 15:42.600
You convert sections become stages in a stalker file.

15:42.600 --> 15:45.600
Your file section essentially becomes copying files

15:46.600 --> 15:50.600
from your boot stage into the final stage.

15:50.600 --> 15:52.600
Macros.

15:52.600 --> 15:54.600
I'll come to them later.

15:54.600 --> 15:56.600
You have work around,

15:56.600 --> 16:00.600
but I think we could also rethink things here.

16:00.600 --> 16:03.600
The preamble where you redefine all the metadata

16:03.600 --> 16:07.600
that becomes unfortunately also a config file,

16:07.600 --> 16:10.600
because some things you just can't put into labels.

16:11.600 --> 16:13.600
Fuse RPMs scriptlets for those of you

16:13.600 --> 16:14.600
don't know them,

16:14.600 --> 16:15.600
consider yourself fortunate.

16:15.600 --> 16:17.600
We have to put them in another file.

16:17.600 --> 16:20.600
But I think what's also a very nice thing is

16:20.600 --> 16:23.600
currently every distro has some kind of isolation

16:23.600 --> 16:26.600
to build their RPMs,

16:26.600 --> 16:29.600
and for that we can just use container tooling,

16:29.600 --> 16:32.600
because it can already do isolation.

16:32.600 --> 16:34.600
Okay,

16:34.600 --> 16:36.600
bigger issues.

16:36.600 --> 16:39.600
RPMs has automatic dependency,

16:40.600 --> 16:41.600
dependency generation,

16:41.600 --> 16:43.600
so if you build something,

16:43.600 --> 16:46.600
and it needs a shared library or something else,

16:46.600 --> 16:48.600
RPMs will figure out for yourself,

16:48.600 --> 16:50.600
and you don't want to lose that,

16:50.600 --> 16:54.600
because that would be a horrible, horrible regression losing it.

16:54.600 --> 16:56.600
But it's possible,

16:56.600 --> 16:58.600
because RPMs have some tools for that.

16:58.600 --> 17:00.600
Reproducible builds.

17:00.600 --> 17:02.600
About that one,

17:02.600 --> 17:05.600
I hope setting source state epoch will be enough,

17:05.600 --> 17:07.600
but I haven't tested it yet.

17:08.600 --> 17:11.600
Debug info is kind of,

17:11.600 --> 17:13.600
I think that should be possible,

17:13.600 --> 17:16.600
but that one I didn't get to,

17:16.600 --> 17:18.600
so unfortunately,

17:18.600 --> 17:20.600
unfortunately wasn't sick enough long,

17:20.600 --> 17:22.600
over Christmas,

17:22.600 --> 17:25.600
so I didn't get to work on this long enough.

17:25.600 --> 17:27.600
I haven't looked into change logs,

17:27.600 --> 17:29.600
because I hope we can just get rid of them,

17:29.600 --> 17:30.600
because I hate them,

17:30.600 --> 17:33.600
and I don't think they provide a lot of value.

17:33.600 --> 17:36.600
Macros and filest,

17:36.600 --> 17:39.600
well, let's see if we get to them actually.

17:39.600 --> 17:41.600
So how does this really work?

17:41.600 --> 17:45.600
I try to make a pretty graph that kind of explains this.

17:45.600 --> 17:49.600
So at initially you throw in your Docker file,

17:49.600 --> 17:52.600
you launch the first build stage,

17:52.600 --> 17:54.600
which I just called Build requires,

17:54.600 --> 17:56.600
where you copy in the sources,

17:56.600 --> 17:57.600
you install dependencies,

17:57.600 --> 18:00.600
and that one runs with network access,

18:00.600 --> 18:04.600
and then you would go into the actual build stage,

18:04.600 --> 18:08.600
which is really just another stage in a Docker file,

18:08.600 --> 18:10.600
and that one runs without network isolation,

18:10.600 --> 18:12.600
there you build your package,

18:12.600 --> 18:14.600
you create a new container image,

18:14.600 --> 18:19.600
and then you run the install stage,

18:19.600 --> 18:24.600
where you just copy files from the build into the final image,

18:24.600 --> 18:28.600
and that one you base again on your distro build route.

18:28.600 --> 18:30.600
Then as a last step,

18:30.600 --> 18:32.600
Rosy really does the heavy lifting,

18:32.600 --> 18:36.600
and that's assembling from this stage,

18:36.600 --> 18:38.600
it assembles the RPM.

18:38.600 --> 18:40.600
It runs, so fortunately,

18:40.600 --> 18:43.600
RPM has a binary called RPM Deps,

18:43.600 --> 18:46.600
which runs all these dependency generators.

18:46.600 --> 18:48.600
It's no longer being used for that,

18:48.600 --> 18:49.600
but it still works,

18:49.600 --> 18:51.600
and you can parse its output,

18:51.600 --> 18:53.600
generate the dependencies from that,

18:53.600 --> 18:56.600
and then there's also a YAMO config file,

18:56.600 --> 19:00.600
I know some people hate YAMO, but cloud people like YAMO,

19:00.600 --> 19:08.600
so that is used to really assemble the full RPM.

19:08.600 --> 19:12.600
Yeah, and that's, it kind of works,

19:12.600 --> 19:15.600
not yet completely, but it kind of works.

19:15.600 --> 19:18.600
A few things about macros,

19:18.600 --> 19:21.600
since I know that I'm running relatively short on time,

19:21.600 --> 19:24.600
let's just breeze through this a little bit,

19:24.600 --> 19:27.600
so the RPM macro language is,

19:27.600 --> 19:30.600
it's M4 and CPP inspired,

19:30.600 --> 19:32.600
and to make matters worse,

19:32.600 --> 19:35.600
it also has a lower interpreter,

19:35.600 --> 19:38.600
and it supports shell expansion and security-wise,

19:38.600 --> 19:41.600
on a developer machine, it's actually very, very horrible.

19:41.600 --> 19:43.600
But it's,

19:43.600 --> 19:45.600
there's main usage,

19:45.600 --> 19:48.600
like you can use it just for variables,

19:48.600 --> 19:51.600
you can use shell variables for that.

19:51.600 --> 19:54.600
The shell has conditionals too.

19:54.600 --> 19:57.600
It supports something like functions.

19:57.600 --> 20:00.600
That could be replaced by shell scripts,

20:00.600 --> 20:03.600
the sections, as I said, these become stages.

20:03.600 --> 20:07.600
The real big problem is new fancy RPM features,

20:07.600 --> 20:11.600
like declarative builds and spec parts.

20:11.600 --> 20:14.600
That one,

20:14.600 --> 20:18.600
so honestly, I don't think we will get rid of RPM or that we should,

20:18.600 --> 20:21.600
but maybe we can,

20:21.600 --> 20:25.600
maybe we can just use parts of this to make,

20:25.600 --> 20:28.600
to make the developer workflow nicer.

20:28.600 --> 20:32.600
And the second part is file lists,

20:32.600 --> 20:34.600
and that's,

20:34.600 --> 20:35.600
so I must confess,

20:35.600 --> 20:36.600
I don't know how, for instance,

20:36.600 --> 20:38.600
RH or DB and do this,

20:38.600 --> 20:40.600
but in RPM it's conventional,

20:40.600 --> 20:41.600
at the end of the package,

20:41.600 --> 20:43.600
you declare what you put in there,

20:43.600 --> 20:44.600
and if you copy something,

20:44.600 --> 20:46.600
and if you put something into the build route,

20:46.600 --> 20:47.600
that's not in this list,

20:47.600 --> 20:49.600
it barfs at you.

20:49.600 --> 20:51.600
If you do it from a Docker file,

20:51.600 --> 20:52.600
you do explicit copies,

20:52.600 --> 20:53.600
so it's kind of,

20:53.600 --> 20:56.600
so you have to be explicit about it as well.

20:56.600 --> 20:59.600
The problem is really these additional,

20:59.600 --> 21:02.600
these additional macros in front of that,

21:02.600 --> 21:03.600
like config and config,

21:03.600 --> 21:05.600
no replace for that.

21:05.600 --> 21:07.600
I think to a certain extent,

21:07.600 --> 21:09.600
we could go by convention,

21:09.600 --> 21:11.600
so that if you put something at sea,

21:11.600 --> 21:13.600
it's most likely a config file.

21:14.600 --> 21:16.600
And if that doesn't work,

21:16.600 --> 21:18.600
then probably,

21:18.600 --> 21:20.600
then maybe use labels or something,

21:20.600 --> 21:21.600
but this part,

21:21.600 --> 21:23.600
I haven't yet solved.

21:23.600 --> 21:25.600
So, and since this,

21:25.600 --> 21:27.600
since I'm running short on time,

21:27.600 --> 21:29.600
and this is actually more of a

21:29.600 --> 21:31.600
45 minute talk,

21:31.600 --> 21:35.600
I'm going to do one to skip a few,

21:35.600 --> 21:38.600
and go to the call to action,

21:38.600 --> 21:41.600
and I don't want you to take the pitchforks

21:41.600 --> 21:42.600
and tell me that I'm full of shit,

21:42.600 --> 21:44.600
and that this is a terrible idea.

21:44.600 --> 21:46.600
I want you to take this as an inspiration

21:46.600 --> 21:48.600
and as an example,

21:48.600 --> 21:50.600
how we can rethink our tooling.

21:50.600 --> 21:51.600
What we can change,

21:51.600 --> 21:53.600
to get in new people,

21:53.600 --> 21:56.600
and to ensure that we don't die out,

21:56.600 --> 21:59.600
because I would really not like that to happen.

21:59.600 --> 22:01.600
And if you want to take a look,

22:01.600 --> 22:02.600
there's a link to RoC,

22:02.600 --> 22:04.600
there's a link to the slides,

22:04.600 --> 22:07.600
and I think we might have time for a question or two,

22:07.600 --> 22:09.600
so thanks a lot for your attention.

22:09.600 --> 22:22.600
Yeah.

22:22.600 --> 22:25.600
Fantastic talking very much.

22:25.600 --> 22:29.600
And how do you think we can make this decision

22:29.600 --> 22:30.600
effectively?

22:30.600 --> 22:32.600
Because we,

22:32.600 --> 22:34.600
we think so much for a tool, right?

22:34.600 --> 22:36.600
You took us a lot of them for a lot of years

22:36.600 --> 22:37.600
to build the current,

22:37.600 --> 22:38.600
and it's only a slide.

22:38.600 --> 22:41.600
It's very complex, very sophisticated,

22:41.600 --> 22:44.600
and we're able to take this for something that is simpler,

22:44.600 --> 22:46.600
and I'm always the right tool for you,

22:46.600 --> 22:49.600
but it's widely available in slide,

22:49.600 --> 22:51.600
and one of the businessmen.

22:51.600 --> 22:53.600
So how do we make this decision?

22:53.600 --> 22:54.600
So for the stream,

22:54.600 --> 22:57.600
the question is essentially how do we transition

22:57.600 --> 23:00.600
from the current tooling to new tooling.

23:00.600 --> 23:02.600
I think with this,

23:02.600 --> 23:05.600
it's actually it could kind of coexist.

23:05.600 --> 23:08.600
So that's of course a maintenance burden,

23:08.600 --> 23:14.600
but so RoC doesn't work without RPM.

23:14.600 --> 23:17.600
So it's not really a full replacement,

23:17.600 --> 23:19.600
and I don't think that we can make a full replacement

23:19.600 --> 23:22.600
in one go, that's not realistic.

23:22.600 --> 23:25.600
So this would be just a step.

23:25.600 --> 23:28.600
So I think we have to do things step by step,

23:28.600 --> 23:31.600
because if you take a giant leap,

23:31.600 --> 23:34.600
and re, and throw everything under the bus,

23:34.600 --> 23:38.600
then I think 90% of the people in this room I just can say,

23:38.600 --> 23:39.600
I'm out.

23:39.600 --> 23:40.600
See ya.

23:40.600 --> 23:41.600
This is crap.