►
From YouTube: CentOS Automotive SIG office hours - 2021-12-01 US am
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
A
A
It
is
five
after
and
start
to
see
some
stuff
in
the
chat,
so
let's
maybe
dive
in
a
little
bit
welcome
everyone
to
office
hours.
This
is
the
informal
non-planned
sort
of
event
that
we
do
about
once
a
month,
two
weeks
opposite
the
formal
meeting
where
we
go
over
formal
status
for
the
group,
everything,
and
so
I
thought
that
we
would
first
start
out
with
just
a
technical
update.
A
I
think
pierre
posted
the
technical
update
to
the
mailing
list
just
just
a
couple
of
days
ago,
and
I
have
it
up
on
my
screen
somewhere
and
as
soon
as
I
locate
it,
I
will
go
over
it,
but
ian
if
you
get
to
it
before.
I
do
please
feel
free
this.
A
Actually
said
on
the
mail
right
yeah,
he
has
to
believe
he's
got
a
conflict
today,
but
he
did
send
it
just
a.
I
guess
it
was
five
days
ago
now
a
extensive
update
on
the
technical
aspects,
there's
a
new
make
file
in
the
git
repo.
That
does
all
the
steps
involved
when
building
images,
and
we
can
even
show
that
if
I
can
get
my
screen
back.
A
And
go
over
to
github
and,
of
course
I
will
post
the
github
link
in
the
chat
so
that
we
can
all
see
it
so
here
says:
there's
a
new
mix
make
file
that
makes
it
easier
and
makes,
and
the
docs
are
simpler,
for
example,
to
build
an
os3
based
neptune
image
start
targeting
the
raspberry
pi
4.
All
you
have
to
do
is
run
a
make.
A
A
make
command,
that's
listed
on
his
email
and
or
if
you
want
to
build
an
rpm
based
key
image.
Instead
run
a
different
make
a
different
make
command,
so
that
does
make
it
quite
a
bit
easier,
there's
documentation,
which
I
will
also
post
the
link
and
pierre
and
the
other
folks
working
on
that
team
have
been
good
at
keeping
it
up
to
date.
Keep
in
mind
also
that
you
know.
A
A
So,
as
far
as
reference
platforms,
we
would
like
to
you
know
the
the
main
goal
of
this
is
to
use
a
arc64,
a
64-bit
arm
in
general.
A
A
A
A
C
B
A
So
the
there
has
been
some
discussion
of
creating
a
build
farm
and
to
have
remotely
accessible
physical
boards.
I
think
that's
a
it's
an
interesting
idea.
I
have
it.
D
Yeah
may
I
step
into
and
give
some
background
of
the
question.
So
I
understand,
of
course,
that
raspberry
pi
is
a
great
platform,
because
it's
easy
achievable
and
it's
easy
to
develop
on
it,
and
many
people
are
used
to
it
anyway
and
maybe
have
it
at
home.
Even
therefore,
it's
a
good
starting
point.
I
I
think
that's
that's
the
case,
and
many
of
things
developed
in
automotive
context
can
also
be
developed
on
raspberry
pi.
D
I
don't
see
any
reason
why
not,
but
some
things
like,
if
we
think
about,
can
bus
or
this
connectivity
things
or
if
you
think
about
safety
and
security
when
it
may
get
really
hard,
they
are
platform
dependent
and
that's
a
question,
maybe
for
a
later
step.
If
it
fails
on
a
roadmap,
something
like
we
are
choosing
some
additional
hardware
platforms
at
a
later
step,
something
like
that.
C
I
think
one
thing
that's
just
striking
is:
is
both
the
next
steps
up
are
always
both
much
less
easy
to
obtain
and
significantly
more
expensive.
So
I
and
it
would
probably
that's
not.
You
know-
that's
always
going
to
be
the
case,
so
we
shouldn't
hold
that
as
a
blocking
issue
necessarily,
but
then
you
know,
maybe
we
could
take
a
poll
or
something
and
just
say:
does
anyone
have
an
idea
would
if
we
were
to
choose
a
next
platform
to
have
a
reference
build
for
what
would
it
be
and
what
would
be
useful.
C
C
E
E
If,
if
I
know
that
the
system
is
working
on
renesas,
gen
3,
because
someone
tested
it-
and
you
know
all
the
cross
are
checked
out,
I
think
this
is
more
important
than
you
know,
having
access
by
ssh
to
some
board,
because
that's
it's
not
going
to
solve
the
problem
for
people
who
need
to
have
recess
anyway
and
clearly
at
iot
business,
for
example,
for
the
renaissance
board,
we
can
clearly
make
sure
and
do
the
test
to
make
sure
that
the
platform
is
working
and
when
it's
asked
to
get
that
you
know
tested.
E
So
people
won't
try
stuff
that
don't
work.
I
think
where
the
issue
is
going
to
be
more
tricky
is
on
how
to
use
the
different
devices
on
the
board.
E
D
So
I
think
you
got
one
aspect
of
my
question
like
this:
security
related
specific
things
or
safety
related
specific
things
to
different
cpu
types,
and
regarding
testing,
I
understood
that
the
idea
would
be
to
have
a
kind
of
community
based
approach,
because
everybody
will
have
some
or
some
members
will
have
some
some
boards
available.
For
example,
in
in
my
company
we
have
run
as
this
good
available.
D
C
C
We
don't
have
this
type
of
community
for
a
wide
swath
of
servers
anymore,
because
there's
not
a
big
question
about
whether
a
piece
of
server
hardware
will
fundamentally
run
or
bring
up
an
operating
system
constructed
like
the
way
that
fedora
or
rel
or
centos,
or
you
know,
debian
or
suse
do
so.
I
think
it
is
interesting
like
that.
C
The
real
challenge
in
this
beyond
the
hardware
being
non-standard
is
the
extent
to
which
people
are
willing
to
or
open
to
starting
to
treat
these
platforms
in
a
way
that
starts
to
look
a
little
bit
more
like
a
server
where
you
know.
If
we,
if
we're
wildly
successful
this
notion
that
we
would
have,
we
would
explicitly
add
board
support,
goes
away
because
there's
a
crisp
interface
there.
So,
but
in
the
interim
I
don't
know
it's
interesting
to
see
how
that
might
work
out.
C
I've
I've
become
aware,
since
becoming
involved
in
this,
that
there
may
be
reference
platforms
that
we
would
get
in
big
trouble
for
making
available
on
a
public
build
farm.
Where
there's
you
know,
a
condition
of
gaining
access
to
it
is
is
to
agree
not
to
not
to
widely
publish
enabling
source,
or
things
like
that.
So
it
is
it's
a
different
environment
than
maybe
some
of
us
are
familiar
with.
D
Yes,
I've
also
seen
that,
of
course,
one
problem
when
we
talk
about
the
safety
area
is
that
typically,
the
hardware
vendors
like
soc
vendors,
all
that
safety
manuals
are
kind
of
confidential
and
you
cannot
really
publish
them
or
if
you
collaborate
on
them
and
it's
kind
of
somehow
contradicting
with
open
source.
D
And,
of
course,
from
my
point
of
view,
it
would
be
kind
of
optimal
if
it
would
be
possible
to
find
at
least
one
soc
vendor
who
would
be
willing
to
somehow
contribute
to
this
open
source
idea
and
to
make
also
this
documentation
more
public,
as
it
is
currently
right.
It's
not
only
about
safety.
It's
about
all
this
hardware
manuals
and
everything
of
stuff
which
is
existing
for
the
socs
and
yeah.
I'm
not
sure
if
that
could
be
possible
to
at
least
find
one
who
would
be
willing
to
do
that.
E
Yeah,
unfortunately,
it's
probably
not
going
to
happen.
Tomorrow
is
a
good
example.
They
they
have
ips
that
say
they
buy
from
other
party,
and
so
you
have
a
renesas
board.
For
example,
the
graphics
stack
is
not
public,
so
you
have
to
sign
an
agreement
to
use
it,
and
otherwise
the
imagination
kit
is
not
shipped
with
a
bsp,
and
it
has
been
an
issue
for
us.
For
example,
we
cannot
provide
a
binary
operating
system
running
on
renaissance
boards.
That
include
graphic
acceleration
because
of
that
restriction
on
the
imagination,
toolkit
yeah.
E
D
Yes,
yes,
I
agree
to
that,
but
still
it
could
be
a
good
goal.
If
that
would
be
achieved,
it
would
be
a
big
step
forward
from
from
my
point
of
view,
and
if
really
a
soc
vendor
would
yeah
align
on
open
source
strategy
that
could
be
kind
of
a
preferred
reference
platform,
of
course
right,
but
yeah.
Let's,
let's
keep
it
in
mind.
I
would
say.
A
Yeah,
it's
definitely
in
mind
it's
hardware
and
build
farm.
Things
come
up
on
every
call,
pretty
much.
A
So
to
answer
your
second
question:
real,
quick
about
which
open
source
software
related
to
automotive
is
in
mind,
currently
we're
getting
the
we're
kind
of
starting
from
the
more
general
and
then
moving
towards
the
more
specific.
A
So
right
now
there
is
a
there
is
a
base
operating
system
that
builds
from
the
instructions
in
the
in
the
link
that
I
just
posted,
it
uses
the
a
real-time
kernel
and
I
don't
think,
there's
a
whole
lot
of
automotive
specific
stuff.
Yet
I
think
one
of
the
things
we'd
like
to
target
in
in
q1
of
next
year
within
this
project
is
to
sort
of
evaluate
the
manifest
manifest
that
goes
into
the
build
and
see.
What
is
what
is
a
requirement.
D
Is
that
yes,
and
no
so,
do
I
understand
the
idea
correctly,
that
the
background
of
the
goal
of
the
automotive
stick
is
not
only
about
this
operating
system
layer,
it's
also
to
go
up.
Let's
call
it
middleware
to
also
have
some
middleware
open
source
components
around
automotive.
Is
that
correct.
A
C
Ian
is
that
yeah
it
is,
and
I
would
I
mean
this-
is
a
sig
in
the
context
of
the
centos
project,
so
we're
the
foundationally
we're
using
the
most
recent
centos
stream,
which
is
central
stream.
Nine.
That
also
does
happen
to
align
clearly
with
what
you
know
where,
where
red
hat's
interests
are
in
terms
of
developing
a
product
on
this,
but
that's
not,
that
is
very
intentionally
not
the
only
option
for
influencing
what
the
sig
looks
at,
but
certainly
to
the
extent
that
we've
seeded
some
of
these
early
manifests
and
ideas.
C
They
have
focused
on
using
centos
stream,
nine
as
the
basis
we
also
have
built.
Some
you
know
is
sort
of
notional
software
that
would
live
on
top
of
that,
then
the
neptune
sample
application
from
cute
is
something
that
we've
built
as
an
example
of
something
that
might
not
be
part
of
the
core
operating
system,
but
is
a
middleware
ish
type
thing
that
someone
would
build
on
top
of
it?
But
we
are,
I
don't
want
to
say,
constrain,
but
our
foundation
is
the
sort
of
rpm
ecosystem.
C
That's
around
santos
and
centro
stream,
nine
in
particular.
C
So
things
like
people
write
this
fairly
large
package
set.
That
is
drawn
largely
from
things
that
are
also
available
in
fedora,
and
then
there
will
over
time,
some
of
the
other
things
that
you
associate
it
with
the
centos
ecosystem,
but
that's
by
no
means
the
limits,
but
that
is
a
fairly
significant
set.
I
mean,
I
think
my
my
sense
is,
if
you
were
to
compare
it
to
with
what
I
had
seen
that
is
broadly
available
and
reasonably
well
maintained
for
yocto
or
agl,
for
example,
there's
a
lot
of
the
same
things.
C
Are
there
just
presented
in
a
slightly
different
way.
D
Yeah
so
from
from
my
point
of
view,
there's
two
different
directions
into
which
to
go.
If,
when
it
comes
to
middleware
and
one
would
be
kind
of
the
autonomous
drive
space
and
the
other
one
would
be
the
kind
of
hmi
space,
and
I
would
expect
this
is
different
kind
of
middleware
sets,
and
the
question
was
also
directed.
Is
there
some
preferred
air
domain
with
which
to
start,
or
you
want
to
depend
on
community
and
members
contributing,
and
that
was
kind
of
a
background
of
a
question.
C
I
I'll
make
a
a
broad
observation
which
maybe
me
people
may
or
may
not
agree
with
here,
but
I
think
so.
First
of
all,
the
examples
we've
given
so
far
have
have
been
ivi,
as
I
said,
which
is
not
meant
to
indicate
that
that's
the
only
thing
it
could
be
another
way.
I
would
contrast
the
output
that
you
would
get
if
you
were
using
a
yakuto
or
agl
as
the
foundation,
but
we're
targeting
adas.
I
know,
although
that's
there's,
there's
other
issues
with
that.
C
I
would
not.
I
would
expect
large
portions
of
it
to
not
only
look
identical
but
to
be
identical
from
the
ivi
case.
The
kernel
glib
c,
the
system
systemd
like
there
won't
there
will
be
a
lot
of
shared
base
components
and
those
will
be
exactly
the
same
just
because
of
the
way
that
centos
works
and
the
way
that
that
ecosystem
differs
from
the
build
from
source
ecosystems.
D
Yes,
there's
one
aspect
which
makes
me
doubt
that
ada's
could
be
the
right
their
goal,
and,
and
that
is
because
we
had
a
discussion.
Yesterday,
jeffrey
you
had
been
involved
with
redhead
right
and
from
my
understanding.
The
target
is
acer
level
b,
and
I
would
assume,
though
this
is
about
function,
safety,
and
I
would
assume
that
in
autonomous
drive,
mostly,
you
will
have
acell
level
d
targets
like
ace
level
d
and
therefore
I'm
not
sure,
maybe
some
functionality.
A
There
are
a
number
of
eight
s:
components
that
are
asl
b.
Is
my
understanding
things
like
lane,
keeping
the
some
some
cars
have
a
camera
that
keeps
an
eye
on
the
driver
to
make
sure
that
they're
not
drunk
or
asleep.
Those
things
are,
I
think,
are
all
acyl
b
but
it'll
be
really
interesting.
To
see,
I
mean
we're
stuff,
we're
just
initially
initially
evaluating
all
those
things
within
red
hat
for
those
those
use
cases
I
mean
it's
kind
of
secondary.
A
So
it's
a
process,
that's
still
ongoing.
Iso
26262
is
a
beast,
and
it's
really
hard
to
for
linux
to
fit
into
that
certification.
For
that
there's,
an
ongoing
effort
within
the
iso
community
to
update
iso
26262
to
accommodate
linux
and
we're
helping
to
drive
that
I
mean
it's
a
it's.
A
multi-multi-company
and
multi-country
effort
it'll
be
very
interesting
to
see
over
the
next
year
and
to
put
in
a
plug
we're.
Actually
there
there
is
a
functional
safety
buff
that
will
happen
at
the
automotive
linux
conference
in
december.
A
I
guess
in
two
weeks
now
it'll
be
december
15th.
A
So
if
you're,
I
know
it's
a
it's
a
terrible
time
for
the
east
coast
of
the
us,
but
it's
not
it'll
be
early
morning
for
for
europe.
D
D
C
I
mean
I
know
it's
come
up
in
broad
terms
and,
like
you,
I
tend.
I
tend
to
hold
the
way
that
we
handle
security,
escalations
embargoes
and
then
eventual
release
and
in
relatively
high
regard.
I
might,
I
may
well
be
proven
wrong
and
find
that
there's
like
fundamental
inconsistencies
between
that
and
what
the
the
automotive
security
standard
has.
But
I
just
I
know
it's
an
active
barrier
of
investigation
right
now.
D
E
D
D
C
I
mean
the
biggest
conflict
point.
I'm
aware
of
this
is
one
of
the
ways
that
I
I
associate.
One
of
the
reasons
why
I
feel
security
is
well
handled
in
linux,
broadly,
is
that
we
have
use
cases
now
and
sort
of
deployment
deployment
methodologies
where
you
can
get
a
fix
to
a
vulnerability
and
deploy
that
very
rapidly,
and
I
map
that
to
automotive.
C
It
also
happens
to
be
that
there's
a
great
deal
of
interest
in
being
able
to
update
over
the
air
much
more
rapidly
and
that
you
know
contrasting
with
a
model
from
even
not
the
not
too
distant
past,
where
the
software
is
never
updated
or
is
only
updated
by.
You
know,
with
physical
access
and
it
goes
hand
in
hand
being
able
to
update
over
the
air
gives
an
attack
surface
that
generates
an
additional
incentive
to
be
able
to
update
over
the
air
in
case
that
attack
surface
is
exploitable
because
of
some
sort
of
yeah.
E
Yeah
go
ahead.
Sorry,
if,
if
you
read
the
the
new
standard
for
automotive
on
cyber
security
effectively,
most
of
the
requirements
are
pretty
generic
and
does
not
really
change
much
compared
to
other
iot
security
model
or
industrial
security
model.
There
are
a
few
things
that
are
specific,
so
software
update
on
the
air
is
mandatory.
E
They
do
not
impose
on
how
much
time
you
should
react,
which
is
something
they
do
for
telecom,
for
example,
but
on
the
other
hand,
say,
for
example,
also
impose
that
you
can
do
the
update
offline.
So
it
imposes
you
to
support
those
models,
and
so
you
have
few
specifics
to
the
automotive
sector
in
u.s.
They
also
impose
that
you
can
do
the
update
by
the
obd
plug,
which
is
potentially
a
nightmare.
E
It
does
not
look
that
this
is
mandatory
in
europe,
so
you
have
few
specific
things,
but
I
think
most
of
the
work
is
really
paperwork
on
on
making
sure
that
you've
done
a
good
evaluation
of
all
your
assets
and
what
is
going
to
happen
if
one
asset
is
attack
and
how
you
can
you
know,
put
some
resilience
on
your
system,
so
you
have
some.
You
know
fail-back
mechanism
in
case
of
a
problem,
so
nothing
rocket
science,
but
clearly
a
lot
of
paperwork
you
have
to
handle
all
the
dependency
you
have
to
provide.
E
All
the
you
know
the
the
the
place
where
the
data
is
going
through,
and
so
I'm
not
sure
how
much
of
that
can
be
automated,
but
clearly
some
parts
should
be
automated
yeah.
C
Well-
and
I
was
good-
the
thing
I
was
building
too
is
that
the
what
this
does
come
into
conflict
with
is
that
we've
had
heard
the
question.
If
we
provide
a
a
update
to
the
colonel
to
address
an
embargoed
cve
and
we
release
it
and
that's
needs
to
be
applied
rapidly.
E
So
that's
an
assessment
you
have
to
do
so
effectively.
You
have
to
guarantee
that
you
have
an
assessment
to
to
make
sure
that
your
modification
does
not
break
your
test
feature
and
so
on,
but
I'm
not
sure
how
much
of
that
depend
on
the
distribution
and
how
much
of
that
is
specific
to
the
implementation.
So
I
clearly
you
know.
E
E
My
my
question
to
the
group,
as
we,
this
is
an
informal
you
know
meeting-
is
what
do
we
expect
to
be
different
in
between
the
automotive
version
of
santos
and
an
iot
santos,
or
you
know
raspbian
or
any
other
distribution.
We
have.
I
think,
that's
that's
a
clear
question
for
many
people.
Okay,
what
is
going
to
be
different?
What
what
is
what's
the
plus
of
this
new
distribution
compared
to
the
others.
C
Beyond
that,
it's
unclear
we're.
We
are
allowing
ourselves
to
do
other
replacement.
Having
once
you've
replaced
the
kernel.
You
know
you've
kind
of
crossed
a
big
threshold
already,
so
if
there
are
functional
reasons
why
we
might
want
to
substitute
other
components
that
are
would
otherwise
be
inherited
from
centos
directly.
We'll
do
that.
I
think
the
thing
that
you
know
we
have.
C
We
have
the
beginning
the
vague
outline
of
some
ways
in
which
system
initialization,
particularly
early
system
initialization,
might
want
to
function
a
little
differently,
particularly
around
things
like
the
the
timing
requirements
on
things
like
the
reversing
camera
and
there
there
are
timing
requirements
and
other
things.
Someone
might
imagine
that
we
would
have
a
different
or
optimized
system
d
or
early
boot
configuration
that
isn't
isn't
exactly
the
same
as
centos,
but.
C
It's
kind
of
use
case
driven,
I
have
there's
not
been
other
than
the
fast
startup
and
the
fact
that
there's
we
want
a
fairly
lean
arc,
64
kernel
and
we
know
we're
dealing
with
a
slightly
different
hardware
set.
Those
are
the
things
that
have
really
driven.
E
C
Thinking
on
how
it
would
need
to
deviate
beyond
that,
centus
is
a
fairly
rich
set
of
software
available
that
we
can
drop
from
already
so.
C
E
Yeah
yeah,
making
it
smaller
yeah.
One
thing
we
we
relatively
often
have
to
do
for
safety
issue
is
when
we
boot.
The
linux
system
is
to
organize
a
hardware
distribution
in
such
a
way
that
we
we
ignore
some
of
the
memory
eventually
a
core,
and
we
run
the
different
operating
system
in
that
specific
zone.
And
that's
that's
not
that
easy
to
be
done.
E
That
would
be
a
big
plus,
but
but
it's
it's
often
dependent
on
the
hardware
yeah.
Even
if
you
know
few
mechanisms
like
jailhouse,
for
example,
allows
to
make
it
somehow
generate,
but
it's
not.
C
We've
heard
whispers
of
that
kind
of
thing,
but,
as
you
say,
once
it
becomes
hardware
specific,
then
it
often
disappears
behind
this
wall
of
it's
a
you
know,
it's
a
bsp
specific.
It's
it's
considered
a
specific
value,
which
is
a
big
hardware
platform
like,
but
it
is
very
intriguing.
Can
you
could
you
envision
making
useful
progress
on
that,
while
still
using
a
hardware
platform
like
the
pi,
that's
widely
available.
E
And
jailhouse
is
only
one
model-
it's
it's
done
by
siemens,
so
it's
open
source
and
pretty
cool,
but
it
it
allows
you
to
have
a
hardware
separation
in
such
a
way
that
linux
ignore
some
of
your
core
memory,
maybe
a
device.
And
then
you
can
run
some
bare
metal
code
or
some
very
low
level
operating
system
in
that
space
to
handle
some
safety,
critical
functionality
and
it's
pretty
tough
to
to
make
it
work
to
to
have
a
smooth
integration
with
the
kernel
and
some
user
space.
F
F
Yeah
yeah,
maybe
too
many
numbers,
but
anyway
it
will
be.
I
would
I
wouldn't
say
it's
mandatory,
but
because
at
the
end
the
oems
have
to
provide
a
way
to
to
check
the
integrity
of
the
system,
but
it's
not
said
that
they
will
have
to
use
gm
ret
or
whatever
technical
implementation
for
that,
but
at
least
proposing
a
reference
one
would
be
would
be
valuable.
I
think-
and
this
one
doesn't
I'm
not
sure
it's
to
rely
so
much
on
the
hardware.
C
Yeah,
that
would
be
an
interesting
one
as
well.
I
think,
like
I,
I
found
myself
wondering
because
I
did
the
breastplate
pi4
doesn't
have
a
tpm
hardware
on
it
as
far
as
I
know,
but
it
also
doesn't
have
uafi
firmware
on
it,
and
yet
we
use
it
as
if
it
did
by
putting
it
on
and
pretending
that
that's
the
ufc
firmware.
So
I
wonder
if
anyone's
done
it.
E
C
C
Extending
from
that
idea
of
people
thought,
for
example,
we'll
put
something
that
masquerades
as
a
tpm
in
the
firm
in
firmware
that's
on
the
sd
card,
so
that
you
could
demonstrate
sort
of
integrity.
You
know
an
imagined
integrity,
end-to-end
integrity
check,
even
though
it's
not
fully
supported
on
the
hardware.
E
A
We
actually
only
got
this
to
basically.
The
first
did
the
first
note
on
the
first
bullet
point
on
pierre's
technical
update,
so
we
could
we
could
move
on
from
there
unless
anybody
has
anything
they'd
like
to
discuss.
I
mean
this
is
a
as
we
said,
an
informal
meeting
so
something's
on
anybody's
mind,
please,
you
know
just
follow
around.
G
Awesome,
hey
jeffrey!
This
is
nicholas,
hey
everyone.
I
I
work
on
the
uxd
team
in
the
in
the
automotive
automotive
side
of
things
at
red
house
hat,
but
I'm
a
user
researcher
who's
really
interested
in
understanding.
Just
as
we
make
the
tool
chain
available
to
everyone
how
they're
using
it,
you
know
how
easy
is
it
to
get
started
and
just
understanding
the
experience
of
of
using
the
the
tool
chain
that
we're
putting
together
in
the
the
sig
context.
G
So
you
know
that
would
one
of
the
things
we'd
love
to
do
is
talk
to
members
of
the
sig
and
understand
what's
working
for
them?
What's
not
that
sort
of
thing?
What
are
their
expectations?
How
we
can
make
that
experience
a
little
bit
easier.
A
A
Okay,
I
can
tell
from
the
cacophonous
response
that
that,
maybe
I
I
don't
think
people
are
having
too
many
problems
with
them,
understood.
G
Yeah,
do
we
have
a
mechanism
at
the
moment
to
kind
of
capture
feedback
on
on
those
or
are
on
on
kind
of
the
the
experiences
that
we're
that
people
are
having
using
these
these
pieces?
So
if.
A
A
I
don't
know
if
there
is
for
the
documentation,
which
is
a
good
question,
I
don't
see
a
way
to
file
a
bug
against
docs,
but
it's
all
still
fairly
new.
I
mean
this:
is
the
documentation
is
being
updated
daily?
The
the
tools
are
going
through
a
heavy
churn.
G
If
there
are
big
questions
out
there
about
end
users,
how
we
can
support
some
of
the
getting
some
of
those
questions
answered
from
a
user-centered
point
of
view
and
bring
that
back
to
this
group
share
our
findings.
That
sort
of
thing
as
well
definitely
want
to
bring
some
of
that
capability
to
the
to
the
group.
G
That's
great
it's
great
to
have
that
as
a
as
an
option
yeah.
So
I
don't
know
if
we
how
we
work
out
a
process
for
that,
but
ask
you
know
if
we're
documenting
kind
of
open
questions
in
the
the
centos
document
or
in
the
get
lab,
it
would
be
interesting
to
figure
out
sort
of
what
are
the
big
burning
questions
for
this
group
if
we
can
go
out
and
get
some
answers
for
them,
it's
related
to
the
users,
our
users
specifically.
A
Yeah,
I
think
that,
as
we're
spinning
up
basically
from
you
know
a
base
technical
point
of
view,
I
think
that
once
the
once,
this
sig
does
create
a
actual
distribution
that
can
be
that
has
a
regular
release
schedule
and
that
has
things
being
added
to
it
and
removed
from
it
that
it'll
be
more
more
relevant
to
to
do
some
deep
dives
on
usability.
G
Yeah
and
making
an
assumption
right
correct
this
assumption
if
it's
inaccurate,
but
as
we
make
things
available
for
distro,
my
assumption
is
that
people
are
going
to
be
picking
up
that
distro,
whether
they're
internal
to
red,
hat
or
other
places.
Would
it
be
helpful
to
to
understand
how
people
downstream
are
kind
of
receiving
it
and
bring
that
information
back
to
this
group?
Is
that
a
value.
A
I'd
say
that
probably
everybody
on
this
group
is
going
to
be
having
the
same
thing,
whether
they're
within
red
hat
or
not.
You
know
we
are
very
interested
in
this
from
a
red
hat
perspective.
Obviously,
but
I
know
that
a
lot
of
other
organizations
are
evaluating
and
and
will
have
different
kinds
of
feedback.
D
I
see,
of
course,
source
code
in
gitlab
and
I
see
documentation,
but
what
could
be
also
valuable,
maybe
not
in
a
very
detailed
level,
but
at
least
in
some
basic
level
to
have
also
some,
let's
call
it
stakeholder
requirements.
So
what
is
the
special
requirements
which
automotive
environment
puts
to
linux?
Like
all
that
use
cases
like
it
needs
to
be
booted
up
in
two
seconds
for
some
use
cases,
or
it
needs
to
be
more
real-time,
like
normal
linux
or
so
this
kind
of
yeah.
A
You
know
right
so
far.
We've
been
really
focused
on
just
bring
up
and
getting
the
infrastructure
in
place.
Maybe
this
is
the
the
right
time
to
start
addressing
the
requirements
of
how
we
can
evaluate
whether
a
specific
package
is
relevant
to
automotive,
for
example,
but
I
think
I
think
the
the
centos
wiki
is
probably
the
best
place
to
do
that
and
I
have
so
I'd
be
happy
to
start
collecting
and
nick.
G
Understood
yeah,
we
can
definitely.
A
And
it'll
identify
the
you
know
the
points
in
which
people
diverge
in
opinions
as
well.
Thank
you
are
with
a
great.
A
One
of
the
other
things
that
pierre
had
said
is
that
there
are
more
streamlined
templates,
but
a
number
of
changes
landed
to
the
os,
build
mpp
pre-processing
tool
that
the
workflow
relies
on.
So
that's
new.
There
is
a
new
kernel
that
has
landed
that
brings
support
improved
support
for
the
rp4,
as
well
as
the
nvidia
jetson
boards.
That's
great.
I
didn't
realize
that
that
was
already
starting
to
roll
out.
A
The
jetson
is
one
of
the
ones
that
has
has
emerged
in
all
of
these
discussions
as
being
a
popular
alternative,
and
if
you
can
get
your
hands
on
one,
I
believe
it's
not
a
5
000
board
with
more
closer
to
a
five
or
six
hundred
dollars,
which
is
very
helpful.
The
kernel
is
building
on
cs9
on
our
centos
stream,
nine,
which
is
great,
and
there
are
more
real-time
packages
as
well,
and
the
kernel-auto
repo.
A
A
We're
down
to
about
10
minutes
left.
Are
there
any
other
topics
that
anybody
would
like
to
bring
up?
This
is
a
great
time
to
do
so.
E
Yeah,
maybe
maybe
one
point
is
I'm
not
sure
how
much
of
the
kernel
and-
and
you
know
the
core
configuration
is
going
to
be
different
in
between
this
automotive
sig
and
the
requirement,
for
example,
for
robotics,
and
you
know,
I'm
I'm
not
convinced
that
it
is
in
the
interest
of
a
group
to
define
a
very
low
level
stuff
that
is
so
specific
to
that
world.
E
On
the
other
hand,
the
middleware
are
clearly
more
specific
to
to
the
automotive,
even
if
gts,
for
example,
is
used
both
in
the
autonomous
driving
and
in
the
robotic
world.
So
there
are
also
some
commonality,
but
at
least
for
the
low
level
part.
I
think
all
the
industrial
iot
have
roughly
the
same.
Real-Time
requirements,
safety
requirements,
cyber
security
and
so
on,
and
I
don't
know
how
much
group
are
working
on
on
the
subject
in
red
hat,
but
maybe
there
are
some
capability
to
agglomerate
more
people.
E
So
that's
for
the
point
one
for
for
the
point
two
talking
about
reference
board.
I
have
to
check
how
we
can
do
that,
but
I
think
we
at
iot
business
we
we
can
probably
maintain
some
ready
to
go
and
out
of
the
box
version
for
some
boards,
like
the
renaissance
or
nxp,
or
you
know
some
of
the
qualcomm
board,
because
we
have
many
ports
available.
E
C
That
sounds
great,
and
I
would
I
that,
having
a
few
more
reference
platforms,
even
if
even
if
it
doesn't
extend
to
having
them
available
in
some
sort
of
you,
know
remote
access
way,
just
having
a
known
working
configuration
and
even
manual
confirmation
that
changes
in
these
manifesto
work,
or
maybe
some
remote
testing,
where
it's
it.
It's
we
get
tests
and
test
reports.
That
would
be
a
if
that's,
if
you're
interested
in
integrating
to
that
extent.
E
Yeah,
we
clearly
are
not
going
to
provide
remote
access
to
our
board.
Yes,
excellent
people,
that's
obvious,
but
yes,
I
think
it's
possible
to
provide.
You
know
ready-to-go
binaries
and
for
all
susports.
So
people
can
you
know
very
easily
jump
start
and-
and
this
also
come
back
to
the
question
on
how
complex
it
is
to
bootstrap
the
process
so.
A
A
You
know
beyond
automotive
there's
a
there
is
obviously
an
automotive
context
there
with
ottaware,
and
I
would
really
love
to
see
the
ottawa
folks,
you
know,
show
up
in
the
sig
and
maybe
do
some
to
either
contribute
some
some
work
or,
if
somebody,
what
else
it
doesn't
have
to
be
auto
where
folks,
somebody
else
is
doing,
work
with
auto
wear
to
contribute
it
into
the
sig
would
be
fantastic.
E
Yeah
clearly
we,
you
know,
we
use
the
same
system
for
automotive
in
you
know,
on
on
ship,
when
we
do,
you
know
autonomous
ship
or
you
know,
connected
chip,
and
we
also
use
that
to
collect
data
from
helicopters.
So
I
don't
think
we
should
limit
ourselves
to
specifically
the
automotive,
because
the
problematics
that
we
tried
to
solve,
which
is
booting
fast,
having
a
small
system
running
for
10
years
having
a
cybersecure,
you
know
continuously
updated
their
software,
that's
not
specific
to
the
automotive
sector.
Yeah.
Certainly.
A
Not
yeah,
it's
also
very
relevant
to
base
systems
yeah,
there's
a
number
of
regulatory
challenges
with
aviation,
but
I
think
that
there's
also
a
good
opportunity
there
in
the
future.
Perhaps
you
know
we
could
certainly
brainstorm
on
some
of
the
various
use
cases,
but
that
you're
right
that
they
all
do
seem
to
have
very
similar
requirements.
E
Especially
if
the
group
is
willing
to
focus
on
what
is
common,
because
it's
very
different,
if
you
focus
on
creating
a
specific
middleware,
that
is
targeting
a
specific
industry,
but
if
you
want
to
focus
on
the
common
point,
especially
the
kernel,
this
is
not
specific
to
the
automotive
sector.
Yeah.
That's
very
true.
A
A
So
in
our
last
four
minutes
to
if
we
do,
we
have
anything
else
we
want
to
cover.
One
thing
I
would
want
to
mention
is
that
we
are
still
trying
to
figure
out
the
best
cadence
for
these
meetings.
I
feel,
like
the
the
last
one
kind
of
threw
a
wrench
into
things.
The
last
change
that
I
made
there
are
two
meetings
per
day
when
we
do
have
meetings
now,
there's
one
right
now,
which
is
a
relative.
E
By
the
way,
I
posted
a
note
that
the
wiki
time
is
wrong.
Is
it
incorrect?
Okay,
yeah?
I
see
you
have
two
different
time
depending
on
which
wiki
you
look
at
and
the
system
is
talking
about
summer
time
and
we're
in
winter
time.
E
A
Okay,
I
didn't
know
about
the
sig
one.
I
will
take
a
look
yeah.
I
think
that's
the
the
the
issue
is
the
the
sig
one
is.
A
E
C
A
Yeah
and
we
can
take
that
offline-
I
know
we're
here
at
the
top
of
the
hour,
but
I
will
definitely
track
down
this
other
this
other
resource
and
make
sure
that
they're
in
sync.
A
All
right:
well,
I
think
that
may
wrap
us
up
if
we
don't
have
any
other
topics,
any
burning
topics
here
in
the
last
30
seconds
and
maybe
I'll
give
everybody
a
minute
and
a
half
back
before
they
get
stuck
in
the
next
meeting.