WEBVTT

99:59:59.999 --> 99:59:59.999
Welcome back, the next talk will be
Jan Kiszka

99:59:59.999 --> 99:59:59.999
on Getting more Debian into our
civil infrastructure.

99:59:59.999 --> 99:59:59.999
Thank you Michael.

99:59:59.999 --> 99:59:59.999
So my name is Jan Kiszka,

99:59:59.999 --> 99:59:59.999
you may not know me, I'm not a Debian
Developer, not a Debian Maintainer.

99:59:59.999 --> 99:59:59.999
I'm just an upstream hacker.

99:59:59.999 --> 99:59:59.999
I'm working for Siemens

99:59:59.999 --> 99:59:59.999
and part of the Linux team there
for now 10 years actually,

99:59:59.999 --> 99:59:59.999
more than 10 years.

99:59:59.999 --> 99:59:59.999
We are supporting our business units
in getting Linux into the products successfully

99:59:59.999 --> 99:59:59.999
for that long time, even longer actually.

99:59:59.999 --> 99:59:59.999
Today, I'm representing a collaborative
project that has some relationship

99:59:59.999 --> 99:59:59.999
with Debian, and more soon.

99:59:59.999 --> 99:59:59.999
First of all, maybe a surprise to some
of you,

99:59:59.999 --> 99:59:59.999
our civilization is heavily running on Linux
and you may now think about

99:59:59.999 --> 99:59:59.999
this kind of devices where some kind of
Linux inside,

99:59:59.999 --> 99:59:59.999
or you may think of the cloud servers
running Linux inside.

99:59:59.999 --> 99:59:59.999
But actually, this is about devices closer
to us.

99:59:59.999 --> 99:59:59.999
In all our infrastructure,

99:59:59.999 --> 99:59:59.999
there are control systems, there are
management systems included

99:59:59.999 --> 99:59:59.999
and many many of them run Linux inside.

99:59:59.999 --> 99:59:59.999
Maybe if you are traveling with Deutsche
Bahn to this event these days,

99:59:59.999 --> 99:59:59.999
there was some Linux system on the train
as well,

99:59:59.999 --> 99:59:59.999
as they were on the ???,
so on the control side.

99:59:59.999 --> 99:59:59.999
Energy generation.

99:59:59.999 --> 99:59:59.999
Power plants, they are also run with Linux

99:59:59.999 --> 99:59:59.999
in very interesting ways, in positive ways

99:59:59.999 --> 99:59:59.999
Industry automation, the factories, they
have control systems inside

99:59:59.999 --> 99:59:59.999
and quite a few are running Linux inside.

99:59:59.999 --> 99:59:59.999
And also other systems like health care,
diagnostic systems.

99:59:59.999 --> 99:59:59.999
These big balls up there, they're magnetic
resonance imaging systems,

99:59:59.999 --> 99:59:59.999
they're running on Linux for over
a decade now.

99:59:59.999 --> 99:59:59.999
Building automation, not at home but in
the professional building area.

99:59:59.999 --> 99:59:59.999
Actually, as I said, the train systems are
going to be more on Debian soon.

99:59:59.999 --> 99:59:59.999
We have Debian for quite a while in
power generation.

99:59:59.999 --> 99:59:59.999
"We", in this case, Siemens.

99:59:59.999 --> 99:59:59.999
We have the box underneath,
on the third row,

99:59:59.999 --> 99:59:59.999
the industrial switch there is running
Debian.

99:59:59.999 --> 99:59:59.999
And the health care device is still
on Ubuntu, but soon will be Debian as well.

99:59:59.999 --> 99:59:59.999
Just to give some examples.

99:59:59.999 --> 99:59:59.999
These are the areas where we, as a group,
and we, as Siemens, are active.

99:59:59.999 --> 99:59:59.999
But there are some problems with this.

99:59:59.999 --> 99:59:59.999
Just take an example from a railway
system.

99:59:59.999 --> 99:59:59.999
Usually, this kind of devices installation,
they have a lifetime

99:59:59.999 --> 99:59:59.999
of 25, 30 years.

99:59:59.999 --> 99:59:59.999
It used to be quite simple with these
old devices,

99:59:59.999 --> 99:59:59.999
simple in the sense that it was mechanic,
it was pretty robust

99:59:59.999 --> 99:59:59.999
I was once told that one of these locking
systems,

99:59:59.999 --> 99:59:59.999
they were basically left in a box out there
for 50 years and no one entered the ???

99:59:59.999 --> 99:59:59.999
No one touched the whole thing for 50 years

99:59:59.999 --> 99:59:59.999
These times are a little bit over.

99:59:59.999 --> 99:59:59.999
Nowadays, we have more electronic systems
in these systems

99:59:59.999 --> 99:59:59.999
and they contain of course software.

99:59:59.999 --> 99:59:59.999
What does it mean?

99:59:59.999 --> 99:59:59.999
Just to give you an idea, how this kind
of development looks like in this domain.

99:59:59.999 --> 99:59:59.999
So ???

99:59:59.999 --> 99:59:59.999
development takes quite a long time
until the product is ready,

99:59:59.999 --> 99:59:59.999
3 to 5 years.

99:59:59.999 --> 99:59:59.999
Then, in the railway domain, it's mostly
about customizing the systems

99:59:59.999 --> 99:59:59.999
for specific installations of the railway
systems,

99:59:59.999 --> 99:59:59.999
not only in Europe, they are kind of messy
regarding the differences.


99:59:59.999 --> 99:59:59.999
So you have specific requirements of the
customer, the railway operators

99:59:59.999 --> 99:59:59.999
to adjust these systems for their needs.

99:59:59.999 --> 99:59:59.999
And you see by then,

99:59:59.999 --> 99:59:59.999
after 5 years already, a Debian version
would be out of maintenance and

99:59:59.999 --> 99:59:59.999
if you add an other year, you can start
over again.

99:59:59.999 --> 99:59:59.999
So, in the development time, you may
change still the system

99:59:59.999 --> 99:59:59.999
but later on, it's getting hard to change
the system ???

99:59:59.999 --> 99:59:59.999
because then the interesting parts start
in this domain, not only in this domain,

99:59:59.999 --> 99:59:59.999
that's safety and security assessment and
approval for these systems.

99:59:59.999 --> 99:59:59.999
And that also takes time.

99:59:59.999 --> 99:59:59.999
For example, in Germany, you go for the
Eisenbahn ???

99:59:59.999 --> 99:59:59.999
and you ask to get a permission to run
that train on the track

99:59:59.999 --> 99:59:59.999
and if they say "Mmh, not happy with it",
you do it over again

99:59:59.999 --> 99:59:59.999
and it takes time

99:59:59.999 --> 99:59:59.999
and if you change something in the
system, it becomes interesting

99:59:59.999 --> 99:59:59.999
because some of these certification
aspects become invalid,

99:59:59.999 --> 99:59:59.999
you have to redo it.

99:59:59.999 --> 99:59:59.999
And then of course, these trains on
the installation,

99:59:59.999 --> 99:59:59.999
the have a long life as I mentioned
before.

99:59:59.999 --> 99:59:59.999
So how do you deal with this in
an electronic device and

99:59:59.999 --> 99:59:59.999
in software-driven devices over
this long phase?

99:59:59.999 --> 99:59:59.999
That's our challenge

99:59:59.999 --> 99:59:59.999
and just one example and there are
more in this area.

99:59:59.999 --> 99:59:59.999
At the same time, what we see now is
these fancy buzzwords

99:59:59.999 --> 99:59:59.999
from cloud business entering
our conservative, slowly moving domain.

99:59:59.999 --> 99:59:59.999
We talk about IoT, industrial IoT, so
connected devices.

99:59:59.999 --> 99:59:59.999
We talk about edge computing, it means
getting the power of the cloud

99:59:59.999 --> 99:59:59.999
to the device in the field, closer to
where the real things happen.

99:59:59.999 --> 99:59:59.999
So, networking becomes a topic.

99:59:59.999 --> 99:59:59.999
In the past, you basically built a system,
you locked it up physically

99:59:59.999 --> 99:59:59.999
you never touched it again, except
the customer complains that

99:59:59.999 --> 99:59:59.999
there were some bug inside.

99:59:59.999 --> 99:59:59.999
These days, the customer asks us to
do a frequent update.

99:59:59.999 --> 99:59:59.999
And actually the customers ???
ask for this.

99:59:59.999 --> 99:59:59.999
So you have to have some security
maintenance concept in this

99:59:59.999 --> 99:59:59.999
which means regular updates, regular fixes

99:59:59.999 --> 99:59:59.999
and that is of course ???
for this kind of doing the way you have

99:59:59.999 --> 99:59:59.999
slow running and long running
support cycles.

99:59:59.999 --> 99:59:59.999
To summarize, there's a very long time
we have to maintain our devices in the field

99:59:59.999 --> 99:59:59.999
and so far, this was mostly done
individually.

99:59:59.999 --> 99:59:59.999
So each company, and sometimes quite
frequently also inside the company,

99:59:59.999 --> 99:59:59.999
each product group, development ???
did it individually.

99:59:59.999 --> 99:59:59.999
So everyone was having their own kernel,
everyone was having their own base system,

99:59:59.999 --> 99:59:59.999
it was easy to build up so it should be
easy to maintain.

99:59:59.999 --> 99:59:59.999
Of course it's not.

99:59:59.999 --> 99:59:59.999
This was one thing, one important thing.

99:59:59.999 --> 99:59:59.999
And then, of course, we not always are
completely happy

99:59:59.999 --> 99:59:59.999
with what the free software gives us.

99:59:59.999 --> 99:59:59.999
There are some needs to make things
more robust,

99:59:59.999 --> 99:59:59.999
to make things more secure, reliable.

99:59:59.999 --> 99:59:59.999
So we have to work with these components
and improve them, mostly upstream,

99:59:59.999 --> 99:59:59.999
and that, of course, is not a challenge
we have to address in this area.

99:59:59.999 --> 99:59:59.999
And catch up with a trend coming in from
the service space on the cloud space.

99:59:59.999 --> 99:59:59.999
So with this challenge…

99:59:59.999 --> 99:59:59.999
it was the point where we, in this case,
a number of big users of

99:59:59.999 --> 99:59:59.999
industrial open source systems,

99:59:59.999 --> 99:59:59.999
came together and created a new
collaborative project.

99:59:59.999 --> 99:59:59.999
That's what you do in the open source
area.

99:59:59.999 --> 99:59:59.999
This project is called Civil Infrastructure
Platform.

99:59:59.999 --> 99:59:59.999
It's under the umbrella of the Linux
Foundation,

99:59:59.999 --> 99:59:59.999
there are many projects of the Linux
Foundation you may have seen,

99:59:59.999 --> 99:59:59.999
but most of them are more in the area
of cloud computing

99:59:59.999 --> 99:59:59.999
or in the area of media.

99:59:59.999 --> 99:59:59.999
Automotive computing, this one is actually
even more conservative than the other ones

99:59:59.999 --> 99:59:59.999
and it's also comparably small.

99:59:59.999 --> 99:59:59.999
Our goal is to build this open source
base layer for these application scenarios

99:59:59.999 --> 99:59:59.999
based on free software, based on Linux.

99:59:59.999 --> 99:59:59.999
We started two years ago.

99:59:59.999 --> 99:59:59.999
That's basically our structure, to give
you an idea.

99:59:59.999 --> 99:59:59.999
Member companies, the 3 on the top are
founding platinum companies,

99:59:59.999 --> 99:59:59.999
Hitachi, Toshiba and Siemens.

99:59:59.999 --> 99:59:59.999
We have Codethink and Plat'Home
on board,

99:59:59.999 --> 99:59:59.999
we had them on board for the first time
as well.

99:59:59.999 --> 99:59:59.999
Renesas joined us and just recently also
Moxa.

99:59:59.999 --> 99:59:59.999
So if you compare this with other
collaborative projects,

99:59:59.999 --> 99:59:59.999
it's a pretty small one, comparatively
small one,

99:59:59.999 --> 99:59:59.999
so our budget is also limited.

99:59:59.999 --> 99:59:59.999
It's still decent enough, but, well,
we are growing.

99:59:59.999 --> 99:59:59.999
And based on this budget, we have
some developers being paid,

99:59:59.999 --> 99:59:59.999
Ben is paid this way, you will see
later on why.

99:59:59.999 --> 99:59:59.999
And we have people working from
the companies in the communities

99:59:59.999 --> 99:59:59.999
and we are ramping up on working with
communities

99:59:59.999 --> 99:59:59.999
to improve the base layers for our needs.

99:59:59.999 --> 99:59:59.999
Everything is open source, we have
a GitLab repo as well and

99:59:59.999 --> 99:59:59.999
you can look up there what's going on there.

99:59:59.999 --> 99:59:59.999
So, the main areas of activities where
we are working on right now.

99:59:59.999 --> 99:59:59.999
4 areas.

99:59:59.999 --> 99:59:59.999
Kernel maintenance,

99:59:59.999 --> 99:59:59.999
we started with declaring one kernel as
the CIP kernel to have

99:59:59.999 --> 99:59:59.999
an extended support phase for this kernel
of 10 years.

99:59:59.999 --> 99:59:59.999
This is what we're aiming for, which is
feasible already

99:59:59.999 --> 99:59:59.999
for some enterprise distros
in a specific area

99:59:59.999 --> 99:59:59.999
but here we are talking about an industrial
area, an embedded area

99:59:59.999 --> 99:59:59.999
so there is some challenge.

99:59:59.999 --> 99:59:59.999
I'm saying 10 years, there's sometimes
written 15 years,

99:59:59.999 --> 99:59:59.999
we will see after 10 years if we follow
on to this.

99:59:59.999 --> 99:59:59.999
Along with this, of course, comes the need
for real time support.

99:59:59.999 --> 99:59:59.999
Currently, it's a separated branch, but
it's going to be integrated eventually

99:59:59.999 --> 99:59:59.999
to have the PREEMPT_RT branch 
??? doing this.

99:59:59.999 --> 99:59:59.999
As I mentioned before, Ben is currently
our 4.4 CIP kernel maintainer.

99:59:59.999 --> 99:59:59.999
This is the core, basically where we
started activities.

99:59:59.999 --> 99:59:59.999
We continued in extending this on
test infrastructure,

99:59:59.999 --> 99:59:59.999
so we invested a bit in improving on
??? infrastructure,

99:59:59.999 --> 99:59:59.999
we are now ramping up an internal
??? just to enable

99:59:59.999 --> 99:59:59.999
the kernel testing of course.

99:59:59.999 --> 99:59:59.999
And then, that's actually what I'd like
to talk about today a bit more,

99:59:59.999 --> 99:59:59.999
there's a CIP core.

99:59:59.999 --> 99:59:59.999
The kernel alone doesn't make a system,
you need a user space,

99:59:59.999 --> 99:59:59.999
you need a user land and that's basically
where we are now focusing on,

99:59:59.999 --> 99:59:59.999
ramping up.

99:59:59.999 --> 99:59:59.999
Our activity is to define this CIP core,
means a base system,

99:59:59.999 --> 99:59:59.999
user space base system which you want
to maintain as long as the kernel,

99:59:59.999 --> 99:59:59.999
so an other 10 years thing.

99:59:59.999 --> 99:59:59.999
Our group had a couple of members which
were already familiar with Debian before.

99:59:59.999 --> 99:59:59.999
So it was pretty easy for that group
to decide on

99:59:59.999 --> 99:59:59.999
choosing Debian as the base source
for our core, CIP core package.

99:59:59.999 --> 99:59:59.999
So, why was Debian chosen?

99:59:59.999 --> 99:59:59.999
Well, it has an outstanding maturity and
a focus on stability,

99:59:59.999 --> 99:59:59.999
so we are pretty much aligned regarding
how conservative we see certain things

99:59:59.999 --> 99:59:59.999
which is a positive thing for us.

99:59:59.999 --> 99:59:59.999
It has very professional security properties
but we also rely on heavily.

99:59:59.999 --> 99:59:59.999
And also another interesting aspect for us
is the license hygiene that you are after

99:59:59.999 --> 99:59:59.999
to ensure that there is only free software
in these packages

99:59:59.999 --> 99:59:59.999
and that is properly documented.

99:59:59.999 --> 99:59:59.999
We, when we are using and redistributing
software,

99:59:59.999 --> 99:59:59.999
in contrast to, for example, the service space

99:59:59.999 --> 99:59:59.999
when you don't usually redistribute things,

99:59:59.999 --> 99:59:59.999
we are redistributing devices, so we are
redistributing software,

99:59:59.999 --> 99:59:59.999
we have to take care of the licenses
that we are redistributing

99:59:59.999 --> 99:59:59.999
and that we are compliant with all these
licenses included.

99:59:59.999 --> 99:59:59.999
So it's very important for us that this is
a consistent picture we get from the package.

99:59:59.999 --> 99:59:59.999
Someone looked at this already, we are still
looking ourselves on this

99:59:59.999 --> 99:59:59.999
but that's a very important thing.

99:59:59.999 --> 99:59:59.999
With these characters, we chose Debian
as the base system.

99:59:59.999 --> 99:59:59.999
So, what does it mean right now?

99:59:59.999 --> 99:59:59.999
We are currently in the process to select
the core packages from the Debian packages

99:59:59.999 --> 99:59:59.999
There is still a little bit of ???
obviously.

99:59:59.999 --> 99:59:59.999
So we are already working with Debian on
certain long term support aspects

99:59:59.999 --> 99:59:59.999
Just to mention 2 activities,

99:59:59.999 --> 99:59:59.999
we were sponsoring already the staging
repo for security master.

99:59:59.999 --> 99:59:59.999
Actually I'm ??? aware of the current
state of the project

99:59:59.999 --> 99:59:59.999
but we got the feedback that it's
apparently a valuable thing for LTS activity

99:59:59.999 --> 99:59:59.999
We just joined LTS platinum sponsoring
and we are now involved in discussion

99:59:59.999 --> 99:59:59.999
for this extended LTS activity,

99:59:59.999 --> 99:59:59.999
so anything beyond 5 years

99:59:59.999 --> 99:59:59.999
and in the end, that's what we committed
to our users.

99:59:59.999 --> 99:59:59.999
We want to ensure that for the base system
the 10 years is reached.

99:59:59.999 --> 99:59:59.999
Of course, ideally, in the community,
not only based on our personal activities

99:59:59.999 --> 99:59:59.999
but in the end, we have to fill the gap

99:59:59.999 --> 99:59:59.999
and that's basically our commitment
on this.

99:59:59.999 --> 99:59:59.999
Don't take literally what is written here.

99:59:59.999 --> 99:59:59.999
This is basically to reflect the package set
we are discussing

99:59:59.999 --> 99:59:59.999
and there are some 30 to 300 packages
on the discussion, so to say right now

99:59:59.999 --> 99:59:59.999
We're condensing basically all the input
from our users, from our members,

99:59:59.999 --> 99:59:59.999
what they are using already

99:59:59.999 --> 99:59:59.999
and there is a difference we will later
on where this comes from

99:59:59.999 --> 99:59:59.999
in the amount of packages, if the way
they're using.

99:59:59.999 --> 99:59:59.999
So, the kernel currently is not part of
the Debian thing we import,

99:59:59.999 --> 99:59:59.999
although some of our users would directly
use a Debian kernel

99:59:59.999 --> 99:59:59.999
but as I said, when there's a need for
additional activities and

99:59:59.999 --> 99:59:59.999
that's why CIP Core comes in

99:59:59.999 --> 99:59:59.999
but then we have a set of base packages

99:59:59.999 --> 99:59:59.999
and then of course, we also have to have
a certain set of packages that we need to keep

99:59:59.999 --> 99:59:59.999
in a usable way to ensure reproducibility
of this base set.

99:59:59.999 --> 99:59:59.999
Because if we want to fix something
after 9 years in the field

99:59:59.999 --> 99:59:59.999
on a base system produced in the past,

99:59:59.999 --> 99:59:59.999
we have to ensure if we can come up
with the same result

99:59:59.999 --> 99:59:59.999
plus the delta.

99:59:59.999 --> 99:59:59.999
So there are different ways how to build
a system

99:59:59.999 --> 99:59:59.999
and compared to the classic installation

99:59:59.999 --> 99:59:59.999
you may know from a desktop or a server
you're not installing,

99:59:59.999 --> 99:59:59.999
we are prebuilding images and then deploy
these images on the devices

99:59:59.999 --> 99:59:59.999
either in the factory or out there
in the field.

99:59:59.999 --> 99:59:59.999
So the challenge for us is, if we have
this package list,

99:59:59.999 --> 99:59:59.999
how to get to the device image.

99:59:59.999 --> 99:59:59.999
So just to give you a brief idea, of course
there is some input

99:59:59.999 --> 99:59:59.999
from the CIP kernel in source form

99:59:59.999 --> 99:59:59.999
then we are using ???
prebuilt binary packages from Debian

99:59:59.999 --> 99:59:59.999
and/or source package, the source feed
from Debian,

99:59:59.999 --> 99:59:59.999
the upstream source but the Debian patches
as input feeds

99:59:59.999 --> 99:59:59.999
and that comes bound to a minimum
base system to be generated

99:59:59.999 --> 99:59:59.999
and we are currently working on this.

99:59:59.999 --> 99:59:59.999
There is no defined way of producing
this image within CIP at this point,

99:59:59.999 --> 99:59:59.999
we are basically following two paths.

99:59:59.999 --> 99:59:59.999
One of them is the path which is dominated
by the idea

99:59:59.999 --> 99:59:59.999
"Ok, we have to ensure we, in this case
the ??? environments

99:59:59.999 --> 99:59:59.999
have to ensure to reproduce the image
ourself, the binaries ourself"

99:59:59.999 --> 99:59:59.999
so we take the maintain sources from
the Debian community

99:59:59.999 --> 99:59:59.999
but we rebuilt and then generate a new
binary ??? out of this.

99:59:59.999 --> 99:59:59.999
That's one way and that's an activity
which you have heard about,

99:59:59.999 --> 99:59:59.999
meta-debian project prominently driven
by Toshiba,

99:59:59.999 --> 99:59:59.999
which uses the ???
way of producing a base system

99:59:59.999 --> 99:59:59.999
but out of Debian sources so that you have
a maintained source input feed

99:59:59.999 --> 99:59:59.999
for this production.

99:59:59.999 --> 99:59:59.999
That's one path.

99:59:59.999 --> 99:59:59.999
The other path is using predominantly
binary packages

99:59:59.999 --> 99:59:59.999
and personally and specific also at Siemens
we are more following this path here.

99:59:59.999 --> 99:59:59.999
So there is for example the ISAR project,

99:59:59.999 --> 99:59:59.999
??? is one of their developers here
as well

99:59:59.999 --> 99:59:59.999
We are working on this path, it means that
95 or 99% of your image consists originally

99:59:59.999 --> 99:59:59.999
of binaries, Debian binaries as they are
shipped, as they are released

99:59:59.999 --> 99:59:59.999
and then there is often the need to modify
a little bit,

99:59:59.999 --> 99:59:59.999
it might be the kernel, it might be
the bootloader,

99:59:59.999 --> 99:59:59.999
it might be a special patched package
for whatever reason,

99:59:59.999 --> 99:59:59.999
hopefully good ones.

99:59:59.999 --> 99:59:59.999
You have an infrastructure to assemble
the binary images and

99:59:59.999 --> 99:59:59.999
to produce the source packages
on demand

99:59:59.999 --> 99:59:59.999
and install that into an image that you
then can flash on the device.

99:59:59.999 --> 99:59:59.999
That's the second path we are following,
as I said,

99:59:59.999 --> 99:59:59.999
that's just to describe the workflows,
the technology behind it is

99:59:59.999 --> 99:59:59.999
not yet standardized in the CIP.

99:59:59.999 --> 99:59:59.999
For us at Siemens, currently,
???

99:59:59.999 --> 99:59:59.999
it's also ??? based

99:59:59.999 --> 99:59:59.999
yocto-like production,

99:59:59.999 --> 99:59:59.999
but based on the Debian binaries
producing a ready-to-install device image.

99:59:59.999 --> 99:59:59.999
We look at the situation.

99:59:59.999 --> 99:59:59.999
So what is Debian providing?

99:59:59.999 --> 99:59:59.999
Well, a large set of packages, a nice
level of support, 3 + 2 years LTS mostly.

99:59:59.999 --> 99:59:59.999
That's already great, I mean there's
everything available,

99:59:59.999 --> 99:59:59.999
almost everything in the world of
Free Software, we can get via Debian.

99:59:59.999 --> 99:59:59.999
The build, it supports native build.

99:59:59.999 --> 99:59:59.999
That's also an advantage, because finding
after 10 years, 15 years with cross build…

99:59:59.999 --> 99:59:59.999
There's always a problem with
cross building, even a little bit.

99:59:59.999 --> 99:59:59.999
So this is a good strategy to go, although
you're also working on cross build

99:59:59.999 --> 99:59:59.999
that may be interesting for certain
scenarios as well for us

99:59:59.999 --> 99:59:59.999
and we're all discussing this these days,

99:59:59.999 --> 99:59:59.999
reproducible builds is also very important
for us

99:59:59.999 --> 99:59:59.999
because we also have to prove that
the delta is really only on the delta

99:59:59.999 --> 99:59:59.999
that has to be changed and not anything
else and

99:59:59.999 --> 99:59:59.999
we have to rebuild something for
whatever reason,

99:59:59.999 --> 99:59:59.999
we don't want to produce a completely
different image in the end.

99:59:59.999 --> 99:59:59.999
So it's a very important topic.

99:59:59.999 --> 99:59:59.999
I mentioned already before the license
compliance topics.

99:59:59.999 --> 99:59:59.999
I'm not really deep expert on all the
licensing thing,

99:59:59.999 --> 99:59:59.999
except when I have to be because some
customer asks us internally

99:59:59.999 --> 99:59:59.999
how to be compliant and how to solve
certain compliance findings.

99:59:59.999 --> 99:59:59.999
A colleague of mine, ??? example
who's maintaining the fossology project

99:59:59.999 --> 99:59:59.999
is way more in this because we have also
our infrastructure

99:59:59.999 --> 99:59:59.999
to ensure license compliance and identify
packages, ???

99:59:59.999 --> 99:59:59.999
and the idea, as far as I heard, is to
combine these kinds of activity

99:59:59.999 --> 99:59:59.999
so that Debian can also use the information
that this kind of scanners produce

99:59:59.999 --> 99:59:59.999
like spdx formats and build it into
the Debian 5 next generations.

99:59:59.999 --> 99:59:59.999
In turn, we can extract this information
and ensure that they are still valid

99:59:59.999 --> 99:59:59.999
when we take a package.

99:59:59.999 --> 99:59:59.999
So there's a lot of activity already
in this area

99:59:59.999 --> 99:59:59.999
and of course testing, not to mention.

99:59:59.999 --> 99:59:59.999
So, what we need to require here,
as I said.

99:59:59.999 --> 99:59:59.999
One thing is we will need a longer support
phase.

99:59:59.999 --> 99:59:59.999
The number of packages fortunately is
much lower.

99:59:59.999 --> 99:59:59.999
As I said, something like 200 at most is
what we're currently heading for

99:59:59.999 --> 99:59:59.999
for most of our devices.

99:59:59.999 --> 99:59:59.999
We have the need to both build natively and
cross build predominantly

99:59:59.999 --> 99:59:59.999
in the development phase,

99:59:59.999 --> 99:59:59.999
but there might also cases where it might
be useful for a product image

99:59:59.999 --> 99:59:59.999
but predominantly it's for development
phase, you want to

99:59:59.999 --> 99:59:59.999
??? when you are building on on x64 ARM
for example.

99:59:59.999 --> 99:59:59.999
The binary source packages should be
managed and reproducible.

99:59:59.999 --> 99:59:59.999
The license compliance already
mentioned.

99:59:59.999 --> 99:59:59.999
And the testing activity is also something
that we want to improve on further.

99:59:59.999 --> 99:59:59.999
So, where we see the collaboration.

99:59:59.999 --> 99:59:59.999
Already mentioned long term maintenance
for packages,

99:59:59.999 --> 99:59:59.999
that's definitely an area where we are
reaching out and we are in discussion.

99:59:59.999 --> 99:59:59.999
Contributing to Debian cross, there's
activities going on this area.

99:59:59.999 --> 99:59:59.999
Reproducible builds, we had some
discussion, Holger and Chris, these days

99:59:59.999 --> 99:59:59.999
where we could possibly support you
on this.

99:59:59.999 --> 99:59:59.999
It's not our topmost priority at
this point but it's obvious that

99:59:59.999 --> 99:59:59.999
it will become in the future.

99:59:59.999 --> 99:59:59.999
Also, a way possibly interesting for you,

99:59:59.999 --> 99:59:59.999
I think there is a good chance that
these activities also open up

99:59:59.999 --> 99:59:59.999
more adoption in the ???
of Debian.

99:59:59.999 --> 99:59:59.999
Because we are also discussing this kind
of things with our suppliers,

99:59:59.999 --> 99:59:59.999
means the silicon vendors, pushing them
to be more upstream

99:59:59.999 --> 99:59:59.999
in order to have it easier for us to
integrate their work in our systems

99:59:59.999 --> 99:59:59.999
and eventually, also enabling them to
use the same mechanism that we are using

99:59:59.999 --> 99:59:59.999
for building our images to build there
our customer SDKs

99:59:59.999 --> 99:59:59.999
or however they call them

99:59:59.999 --> 99:59:59.999
and that can create a large ecosystem.

99:59:59.999 --> 99:59:59.999
We have been discussing already with
some of these vendors

99:59:59.999 --> 99:59:59.999
and some are actually interested
in Debian as well as a default image

99:59:59.999 --> 99:59:59.999
to replace those not so successful
source build approaches

99:59:59.999 --> 99:59:59.999
that are out there in the field
eventually with something more easy to use

99:59:59.999 --> 99:59:59.999
An other area I really like to see that
we have collaboration on

99:59:59.999 --> 99:59:59.999
is regarding the license result.

99:59:59.999 --> 99:59:59.999
We, at Siemens, currently are running
through with this subset package

99:59:59.999 --> 99:59:59.999
that fossology run

99:59:59.999 --> 99:59:59.999
and I would like to see the result of
this run, comparing it to what

99:59:59.999 --> 99:59:59.999
Debian is currently reporting in the
metadata

99:59:59.999 --> 99:59:59.999
if there are any gaps, anything that our
experts say

99:59:59.999 --> 99:59:59.999
"Ok, you should document it more that way"
or "There is something missing"

99:59:59.999 --> 99:59:59.999
and of course report these issues upstream

99:59:59.999 --> 99:59:59.999
because eventually, I don't want to rescan
every single security update package

99:59:59.999 --> 99:59:59.999
internally again if you did already.

99:59:59.999 --> 99:59:59.999
That should just run through and
we should have the trust that

99:59:59.999 --> 99:59:59.999
this information is accurate and we can
rely on that.

99:59:59.999 --> 99:59:59.999
That's the vision behind it.

99:59:59.999 --> 99:59:59.999
Test cases would be also an area where
we see a chance to contribute something.

99:59:59.999 --> 99:59:59.999
Further things we are discussing might be
not that interesting for Debian,

99:59:59.999 --> 99:59:59.999
but it's interesting in general.

99:59:59.999 --> 99:59:59.999
Functional safety activities, you'd be
surprised how many people are asking for

99:59:59.999 --> 99:59:59.999
functional safe Linux these days,

99:59:59.999 --> 99:59:59.999
may it be for automotive, but also for
industrial purposes.

99:59:59.999 --> 99:59:59.999
Worth mentioning, actually, is the
security standard this way.

99:59:59.999 --> 99:59:59.999
So even if you're not involved in all
this IEC whatever stuff,

99:59:59.999 --> 99:59:59.999
it's interesting because this is pushing
us, in industry,

99:59:59.999 --> 99:59:59.999
to do things like update strategies
even more consistently

99:59:59.999 --> 99:59:59.999
and ensure that the image that we ship
is integer,

99:59:59.999 --> 99:59:59.999
so that it's really the original image.

99:59:59.999 --> 99:59:59.999
Up to the questions of how to secure
the boot

99:59:59.999 --> 99:59:59.999
and how to secure the system is running.

99:59:59.999 --> 99:59:59.999
That helps us to argue internally and
externally for consolidation

99:59:59.999 --> 99:59:59.999
and that helps us currently to push
a lot of these users

99:59:59.999 --> 99:59:59.999
towards Debian solutions.

99:59:59.999 --> 99:59:59.999
One of our units did once a survey,
recently actually,

99:59:59.999 --> 99:59:59.999
about how many Linux systems they have
there, and they counted 99 balloons

99:59:59.999 --> 99:59:59.999
erm, Linux systems, actually

99:59:59.999 --> 99:59:59.999
and of course you can imagine
it's pretty hard to maintain 99 variants

99:59:59.999 --> 99:59:59.999
in the field out there.

99:59:59.999 --> 99:59:59.999
So they are one of the most prominent
drivers inside our company

99:59:59.999 --> 99:59:59.999
to consolidate the systems and we are
currently consolidating over Debian.

99:59:59.999 --> 99:59:59.999
Not everything, but most of it.

99:59:59.999 --> 99:59:59.999
And then there is this doomsday date
as well,

99:59:59.999 --> 99:59:59.999
which is an increasing concern because
you can imagine that

99:59:59.999 --> 99:59:59.999
if you are building a device today, maybe
it's out of business in 10 years,

99:59:59.999 --> 99:59:59.999
Ok you're lucky, maybe it's still running
in 20 years and it's not yet ready for 2038

99:59:59.999 --> 99:59:59.999
and then we have a problem.

99:59:59.999 --> 99:59:59.999
That's things ??? going on currently
already,

99:59:59.999 --> 99:59:59.999
so one ??? for example is sponsoring
activities in glibc to prove the topic

99:59:59.999 --> 99:59:59.999
and as a consortium, the CIP group be also
looking into this,

99:59:59.999 --> 99:59:59.999
we would not jump in on things but
which have already been happening

99:59:59.999 --> 99:59:59.999
but if there are gaps up there, then we will
possibly jump in here as well.

99:59:59.999 --> 99:59:59.999
So, to summarize.

99:59:59.999 --> 99:59:59.999
We believe, I personally as well,
very strongly

99:59:59.999 --> 99:59:59.999
that our infrastructure is
way too critical


99:59:59.999 --> 99:59:59.999
to run ???

99:59:59.999 --> 99:59:59.999
which is happening, not everywhere,
fortunately

99:59:59.999 --> 99:59:59.999
and we can improve on this, together

99:59:59.999 --> 99:59:59.999
because there is a strong interest
in our group

99:59:59.999 --> 99:59:59.999
to enable and preserve an open source
base layer for this environment.

99:59:59.999 --> 99:59:59.999
We chose Debian as a solid foundation
because we believe that

99:59:59.999 --> 99:59:59.999
this is technically a good solution

99:59:59.999 --> 99:59:59.999
and it's also a good solution because
it's a community approach

99:59:59.999 --> 99:59:59.999
that we are also following.

99:59:59.999 --> 99:59:59.999
We see that we don't differentiate
over this base layer,

99:59:59.999 --> 99:59:59.999
we differentiate between our competitors
on the higher functionality,

99:59:59.999 --> 99:59:59.999
on the integration, but not what is
in details running underneath.

99:59:59.999 --> 99:59:59.999
This is a great great point to collaborate
and to work together.

99:59:59.999 --> 99:59:59.999
CIP is really looking forward to ???
support