►
From YouTube: CentOS Automotive SIG - May 4, 2022
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).
A
Anything,
oh
now,
I'm
being
recorded
okay.
So
let
me
pop
up
some
slides
here
and
I
will
say
good
morning
there
we
go.
I
will
say
good
morning:
everybody
welcome
to
the
official
centos
automotive
sig
meeting
for
may
2022.
A
I
am
your
host
jeff
rowe
and
we
have
a
quick
agenda.
Mostly.
What
we're
going
to
be
doing
today
is
just
the
technical
status
update,
which
pierre
very
thankfully
sent
around
earlier
this
week
yesterday,
I
think
or
monday,
and
then
we'll
just
open
it
up
for
discussion.
A
A
Well,
actually,
two
questions,
but
we'll
get
there
when
we
get
there
in
the
meantime,
does
anybody
have
any
agenda
items
they
would
like
to
throw
in
anything
else,
you'd
like
to
discuss
while
we're
here.
A
A
D
I
also
went
through
the
the
last
few
automotive
six
weekly
updates
that
we're
sending
to
the
automotive
sig
winning
list.
B
D
Yeah,
so
I
think
we
mostly
overwrite,
so
there
is
I'll
start
with
your
slide.
Then,
when
you
flash
when
you,
when
you
build
an
image
and
you
flash
it
onto
the
sd
card,
it's
not
going
to
use
the
full
size
of
the
sd
card.
The
image
is
about
seven
to
eight
gigs
in
general.
So
if
you
have
an
sd
card
that
is
about
32,
gigs
or
128,
you
still
are
only
going
to
use
seven
or
eight
gigs.
So
that's
potentially
problematic.
D
If
you
just
want
to
put
the
systems
and
look
around,
that's
that's
fine.
There's
no
issue
there,
but
if
you
want
to
you
know,
use
that
to
raspberry
pi
to
build
other
images
quickly.
You'll
have
you
run
into
disk
issues,
so
we've
started
with
documenting
how
to
manually
resize
the
the
slash
partition
on
the
rewrite
api.
D
So
that's
the
documentation
that
jeffrey
is
showing
here,
which
is
available
on
six
dot,
centers
of
org,
slash,
automotive,
and
that's
so
that's
step
one,
but
the
one
thing
that
we
have
worked,
that
we
are
working
on
this
week,
and
that
will
be
this.
I'm
basically
giving
a
preview
to
the
email
on
friday
is
that
we
have
a
way
to
make
this
automatic.
D
So
we
are,
we
are
going
to
change
all
the
images
that
are
built
targeting
raspberry
pi
so
that
they
automatically
resize
the
good
partition
upon
first
put,
so
that
would
basically
make
this
documentation
out.
You
know
not
needed
anymore,
not
outdated,
but
not
delayed
anymore
and,
and
that
should
be
happening
automatically
now
or
at
least
once
we
are
once
by
the
end
of
the
week.
I
have
good
hope
that
will
be
would
be
good.
D
The
the
other
question
is
another
thing
that
we
have
worked
on
over
the
last
few
weeks
is:
how
do
I
create
a?
How
do
I
create
a
manifest?
How
do
I
create
an
image
definition
file
that
that
I
can
customize?
So
there
are
two
ways
to
do
that.
One
way
is
to
look
at
the
distro
file
and
that's
the
that's
the
way
we
have
currently
documented
in
the
documentation.
D
So
if
you
go
to
customizing
images
in
the
documentation,
you'll
see
you
see
something
that
goes
about
these
profiles
and
that
allows
you
to
basically
override
any
of
the
variables.
D
But
if
you
want
to
go
more
than
just
overriding
of
some
of
the
variables
you
will
need
to
create
an
image
file
and
it's
you
know
you
can
you
can
keep
that
in
the
github
in
your
git
clone,
but
you
may
also
want
to
track
this
in
a
separate
git
clone.
So
we
have
added
a
way
to
interact
with
the
mac
file
in
such
a
way
that
you
can
point
to
the
image
directory
of
another
in
another
location
in
another
repo.
D
D
D
I
need
to
go
one
level
done
so
this
is
the
correct
link
in
the
chat.
Here.
You
have
an
images
directory
which
has
a
number
of
images.
D
You
can
add
files
in
there
and
they
will
be
automatically
picked
up
by
the
mag
file,
but
you
can
also
keep
these
files
in
a
different
in
a
different
repo
in
a
different
place,
not
in
your
git
clone
here
and
then
you
can
still
use
the
make
file
to
build
the
images,
all
the
benefits
of
all
the
all
the
infrastructure
that
we
have
set
up
from
these
recipes,
but
still
giving
you
the
ability
to
customize
it.
That
is
something
that
we
still
need
to
document
a
little
bit
more
as
well.
D
There
is
one
thing
as
well:
it's
about
the
efi
runtime
services,
so
the
the
way
it
was
coded
in
the
in
the
linux
kernel
was
that
when
you
enabled
the
real-time
patch
at
the
right
time
patch
on
the
kernel,
it
would
automatically
disable
the
efi
runtime
services
and
there
was
no
way
to
turn
them
back
on.
So
a
change
that
had
been
pushed
in
our
kernel
was
there
is
an
extra
configuration
key
that
you
can,
that
you
can
use
that
will
enable
the
efi
runtime
services.
D
If
you
turn
on
the
rt
patches,
it
will
be
disabled
by
default,
but
you
can
go
ahead
and
turn
it
on.
If
you
really,
if
you
know
what
you're
doing
or
if
you
really
need
them,
so
we
actually
went
ahead
because
we
believe
that
this
is
something
of
interest
and
we
have
enabled
the
efi
runtime
services
in
our
artic
piano.
D
So
that's
something
you
can
already
use
today
and
benefit
from
a
little
bit
in
the
in
the
same
question.
The
next
one
is
about
naming
the
the
name
of
the
images.
So
if
you
can
build
images
in
the
documentation
that
the
g4
linked
to
you
know,
customizing
images,
the
the
link
that
you
looked
at
earlier,
you
can
specify
you
know
you
can
override
some
of
the
variable
via
the
command
line.
D
This
is
great,
except
that
the
image
name
that
you
get
as
the
output
is
going
to
be
the
name
of
the
file,
which
means
you
know
you
you're,
building
this
developer
os3
image
and
you
get
a
developer
image.
Okay,
great,
how
do
I
know
which?
How
do
I
keep
track,
that
this
is
the
os3
image
that
has
gdp
installed?
D
Well,
you
can't
because,
or
you
couldn't,
because
there
was
no
way
to
customize
them,
so
we've
added
the
ability
to
use
the
add
sign
in
the
define
name
and
then
the
add
sign
is
preserved
in
the
output
name,
and
that
gives
you
basically
a
way
to
tag
or
to
to
give
extra
information
about
the
image
name.
And
then
you
have
you
will
you
can
have
two
different
names
for
the
image?
That
is
the
stock?
You
know
developer
registry
image
or
the
os3
the
developer
s3
image
with
some
of
the
customization
that
you
have
made.
D
Back
on
the
slide,
I
forgot:
what's
the
next
step
on
the?
What's
the
next
point
there.
The
look
is
like
the
leukocyte
cache
structure
on
center.
So
this
is
something
that
that
is
less
about
building
images,
but
more
about
how
we
integrate
with
the
center's
field
system
and
the
the
way
the
loom.
D
The
way
centers
linux
was
built
is
that
we
have
one
place
that
is
used
for
red
hat
to
to
push
the
rpms
the
sources
of
the
rpms
that
are
used
to
build
rail
as
well
as
a
place
where
sigs
can
build
on
the
top
of
of
centers
pedestals
linux
back
in
the
days
or
center
stream.
For
the
marker
for
the
more
recent
six.
This
has
led
to
a
number
of
restrictions
in
the
way
that,
for
example,
the
git
it's
it's
the
same,
git
repository
for
the
siege
and
for
red
hat.
D
So
there
needs
to
be
strong
enforcement
about
the
git
branching
structure
so
that
the
six
can
only
push
to
the
branch
that
they
have
access
to
and
they
cannot
push
two
things
to
the
to
the
c8
branch
or
the
c9
branch,
which
is
the
progressive
of
red
hat
only,
but
that
can
is
a
lot
to
push
to
this
branch
that
branching
structure
was
also
formed
in
the
lucas.
I
cache
there
was
mapping.
D
D
But
if
we
still
enforce
that
branching
structure
on
gitlab,
because
the
leukocyte
cache
it
was
using
that
structure,
it
makes
little
sense.
So
what
we
did
is
that
we
work
with
the
centos
infrastructure
team
and
we
came
up
with
with
a
new
endpoint.
So
if
you're
an
existing
sig-
and
you
don't
want
to
change
anything-
you
can
just
keep
the
way
it
is.
There
is
it's
fully
backward
compatible.
The
old
scripts
work,
the
old
endpoints
work.
D
E
D
In
center
stream
and
that
structure
gives
it
no
longer
relies
on
the
git
branch
name,
which
means
on
gitlab
you're.
You
have
the
flexibility
of
using
any
branching
structure
that
you'd
like
in
your
git
repository,
so
that
just
gives
us
a
lot
more
flexibility
in
that
it
also
makes
its
trivial
two
back
ports
built
from
from
federal
to
to
to
center
stream.
D
It's
basically
a
matter
of
creating
the
repositories
on
gitlab,
pulling
things
from
fedora,
pushing
them
on
gitlab,
pulling
the
sources
from
the
federal
local
site
cache
and
pushing
them
to
the
center,
such
as
I
cache,
and
it
will
work
out
of
the
box.
So
that's
a
that's
a
nice
experience,
user
experience
that
we've
built
there.
D
What's
in
the
the
next
point,
is
we
have
sample
images
in
autosd.center.talk?
I
don't
know
if
we
are
ready
with
this.
Yet
there
was
work
in
progress.
They
were
close
to
being
there.
I
do
not
know
if
they
are
entirely
there,
yet
I
believe
so.
Yes,
we
do
have
now
so
I'll
put
the
link
in
the
chat
here.
You
want
to
go
the
bottom
to
the
latest.
Folder
and
you'll
have
sample
images,
so
those
are
qmu
minimal
image
using
os3
qmu
qa
image
using
ostru
and
rpi4
minimal
image.
D
That
is
not
using
os3.
It's
a
it's
a
regular
image.
D
So,
if
you're
interested
to
get
a
minimal
raspberry,
pi
4
system,
you
can
directly
download
this
this
image
and
flash
it
onto
the
sd
card
and
remove
it
and
that's
the
place
where
we
we
will
want,
in
the
future,
to
to
publish
probably
a
little
more
a
little
bit
more
images.
D
It's
there's
some
it's.
Basically,
you
download,
decompress
and
flash
them
onto.
A
D
Sd
card,
it's
okay,
so
it's
very
simple
yeah!
There
is
one
thing
that
you
do
not
have
and
that
we've
added
in
the
same
time,
it's
a
we've
added
documentation
on
how
to
contribute
packages.
So
you
have
you
know
you
have
a
few
places
where
you
can
contribute
packages.
It
can
be
in
fedora,
it
can
be
in
the
automotive
c
repo
or
it
can
be
in
auto
sd
directly.
D
So
if
we
came
up
for
it's
in
the
the
link
is
in
the
chat,
if
you
want
but
or
yeah
it's
right
there.
So
fedora
has
the
added
value
of
giving
you
a
long
time
vision
to
the
future.
This
is
what
rail
will
be.
So
this
is
what
the
in-vehicle
os
will
be
based
on,
but
any
chance
made
in
federal
will
take
a
while
before
it
trickles
down
to
to
rail
into
the
in
vehicle
os.
D
D
D
And
then
you
have
the
auto
sd
part,
which
is
the
so
auto
isd
being
the
public
in
development
version
of
the
product.
So
everything
that
lands
in
auto
sd
is
meant
to
arrive
to
into
the
to
the
in
vehicle
operating
system
and
and
that
so
this
one
it
will
be
a
little
bit
a
lot
more
scrutinized
when
a
change
is
made
because
the
idea
there
is
that
everything
that
lends
in
osd
will
be
supported
by
reddit.
D
So
there
is
a
there
are
consequences
here
about
every
change
made,
but
the
automotive
sig
there
is
a
lot
more
freeform
into
what
we
want
to
do
or
what
we
built,
for
example,
the
pi
resize
rpm
package
that
I
mentioned
earlier.
That's
installs
a
script
and
a
systemd
service
that
will
automatically
expand
this.
The
slash
partition
upon
first
boot.
That
is
something
that
is
part
of
the
automotive
sig
rpm
repository.
D
It's
not
something
that
I
doubt
that
redact
will
want
to
support
this
in
this
product.
I
don't
think
that
we
will
that
we
really
want
to
support
the
raspberry
pi
in
the
product,
but
that's
definitely
a
place
where
the
sig
has
a
has
added
value,
and
I
think
that's
all
I
had
on
on
your
list
and
on
my
list
so.
A
Okay,
yeah,
the
only
other
thing
on
the
list,
I
think,
was
the
the
name,
space
change.
D
Oh
yeah,
if
we
haven't
mentioned
it,
yeah
there's.
Definitely
if
you,
if
you
have
not
seen
it,
we
moved
from
git.com
automotive
to
gitlab.com
center,
slash
automotive
and
the
added
value
here
is
that
we're
using
the
centos
account
system
instead
of
using
the
redat
account
system,
which
means
that
we
can
onboard
community
members
to
contribute
to
the
project.
A
That
was
quite
a
lot
of
information
there.
I
want
to
make
sure
that
everybody,
if
anybody's,
getting
any
questions
or
comments.
C
So,
for
example,
if
we
want
to
explore
the
idea
of
the
rough
equivalent
of
a
bsp
kernel
in
in
our
universe
would
be
a
different
kernel.
Rpm
that
isn't
the
official
kernel
rpm.
We
could
do
that
there
we
could
have
a
kernel,
rpm
or
multiple
kernel,
rpms
and
even
supporting
packages
for
boards.
That
aren't
yet
supported
by
the
main
line
or
the
product
kernel,
so
the
the
groundwork
has
been
laid
for
doing
that
now,
which
is
great.
D
There
is
one
thing
that
we
need
to
figure
out
and
I
I
don't.
I
don't
currently
have
the
the
magic.
This
is
how
we're
going
to
do
that
is
I'm
looking
for
you
know,
I'm
running
auto
sd
and
I
want
to
contribute.
Where
do
I
find
the
sources
to
that?
D
I
that
I
need
to
to
look
at
because
for
most
of
photo
led,
the
sources
are
going
to
be
coming
from
center
stream
and
for
a
small
fraction
they
will
be
diverging
from
center
stream
and
they
will
be
present
in
the
automotive
name
space
under
centers
in
gitlab
here,
but
the
sources
that
are
under
git
lab
centers
automotive
could
also
be
sources
that
are
used
in
the
sig,
but
not
in
at
osd.
D
So
and
that's
that's,
the
one
aspect
is
like.
If
there
is
a
you
know,
if
I'm
running
autosd-
and
I
see
what's
that,
what's
a
good
example,
I
have
a
kernel
issue
and
I
look
at
I
look
at
the
kernel
and
I
see
one
canal
in
center
stream
and
I
see
one
kernel
in
the
center's
automotive.
D
So
is
the
canal
in
center,
automotive,
the
one
that
is,
that
I'm
running
in
a
touristy
or
is
that
one
that
is
only
in
the
sig
or
is
it
both?
So
we
need
to.
We
need
to
find
to
figure
out,
and
I
yeah
we
need
to
figure
out
how
to
point
people
to
the
right
location
when
they
want
to
contribute
to
something.
I
don't
have
a
good
answer
for
that.
D
D
So
yeah
the
lynx
firmware
is
a
it's
an
interesting
one.
We
we
created
a
linux
firmware
automative
package
that
is
only
present
in
the
sig.
We
could
have
this
with.
You
know
extras
we
could
have
one
in
atosd
that
has
only
the
the
firmware
of
the
board
that
are
supported
and
we
could
have
one
in
the
sig
that
has
more
firmware
than
in
the
product.
D
If
I
run
one
of
them,
which
one
should
I
go,
which
one
should
I
go
for
right,
so
these
are
the
those
are
the
the
things
that
we'll
need.
We
will
need
to
collectively
figure
out
as
we
go.
We
currently
do
not
have
that
problem.
We
may
in
the
future,
that's
something
to
keep
in
mind
and
we
need
to
figure
out
a
way
to
to
help.
E
D
E
C
C
Knowing,
where
will
only
be
the
first
barrier
to
them
getting
the
change
in
is
the
other
thing
you
can
talk
about
that
yeah,
but
it's
all
about
lowering
those
documentation
should
be.
Are
you
sure
you
want
to
do
this?
Yes
or
no?
No,
I
could
we.
We
should
be
looking
at
reducing
those
barriers
as
well.
So.
A
C
A
A
A
One
alternative
that
I
was
going
to
ask
about
ian
is
showing
us
his
what's
it
worth
to
you
jeffrey.
I
don't
have.
C
A
Don't
have
budget
for
that.
One
alternative
question
that
I
had
was
about
the
pi
400,
which
is
essentially
a
raspberry
pi
that
comes
in
a
keyboard
form
factor,
and
I
was
just
wondering,
is:
is
that
actually
compatible
enough
to
run
auto
up
there
bruce
has
one?
Is
it
compatible?
Is
it
something
that
we
could
recommend
that
people
use?
Is
it
just
a
pi
4
with
a
different
package,
or
is
it
actually
a
different
different
beast
altogether.
E
It's
by
four
packaged
with
a
keyboard
integrated
and,
interestingly,
the
it
comes
with
the
micro
s,
the
micro
hdmi,
which
is
an
oddball
sort
of
thing.
There
are
20
of
these
at
my
local
micro
center
they're
about
a
hundred
bucks.
The
interesting
thing
to
me
was
this:
has
an
integrated
heat
spreader
inside
so
for
my
my
regular,
for
I
need
to
make
sure
I
go.
Buy
a
heatsink
or
I've
got
a
case.
That's
got
the
the
fan
in
it,
I'm
not
a
I'm.
E
I
don't
like
fans
on
my
on
my
raspberries,
so
this
this
could
be
the
way,
there's
a
site
that
popped
up
on
white
combinator.
Recently,
that's
was
like
where
to
find
raspberry
pi's
to
buy
so
there's
that
as
well,
and
I
also
got
the
last
tinker
edge
that
they
had
in
stock.
That's
how
bad
supply
chains
are
and
they
had
zero
of
the
actual
raspberry
pi
they
haven't
had
them
for
months.
They
said
they
get
them
on
wednesdays
and
they're
gone
before
they
can
even
put
them
in
this
stock.
A
Thank
you
adam.
That's
great.
I
know
that
adafruit
had
a
small
quantity
not
too
long
ago.
I
think
last
week,
which
I
I
normally
do
not
keep
quite
the
close
eye
on
supply
chains,
but
lately
it
has
been
almost
almost
comical,
except
for
people
who
actually
need
them,
in
which
case
it's
not
comical
at
all.
Anyway.
I
just
wanted
to
make
sure
that
we
covered
all
the
options
as
far
as
showing
which
actual
packages
you
could
go
to
the
store
and
purchase
that
were
compatible
with
this,
and,
of
course,
keemu,
is
also
always
an
option.
A
The
other
thing
that
came
up
hardware
availability-wise
the
other
question
that
I
had-
and
this
is
an
idle
question
I
mean
we
should
turn
off
the
recording,
I'm
not
sure,
but
the
the
question
was
about
x86
compatibility
for
auto
sd
somebody
had
asked:
are
we
ever
going
to
be
building
or
supplying
packages
for
these
for
auto
sd
with
x86?
C
I
mean
it's
our
intention
to
provide
an
x86
equivalent
speaking
speaking
from
the
program
and
the
product
side.
It's
it's
clear
from
a
lot
of
interactions
that
this
x
actually
building
and
running
on,
x86
is
done
quite
broadly
and,
as
is
running
on
a
raspberry
pi,
by
the
way,
at
least
when
they
used
to
be
available.
So
I
don't
know
that
we've
highlighted
it
in
in
the
sig,
because
it's
been
it's
much
more
interesting
to
contemplate
doing
it
on
arm,
but
we
could.
Maybe
we
should
look
into
that
as
well.
A
A
A
But
anyway
it
just
it
was
something
that
that
came
up,
so
I
thought
I
would
bring
it
up
to
the
group.
We
always
used
usually
have
a
good
time
tossing
hardware
ideas
around.
E
C
E
C
Yeah
I'll
say
that
we,
I
there's
not
a
lot
of
concern
about
being
able
to
produce
a
close
x86
equivalent,
and
I've
always
highlighted
that.
That's
that's
one
of
the
things
that
may
be
unfamiliar
to
people
who
are
who
have
used
different,
embedded
target
os's
in
the
past.
Is
that
there's
not
a
lot
of
distinction
between
the
develo
and
build
environment
and
the
runtime
environment,
unlike
something
like
some
of
the
rtos
is
where
the
develop
build
environment
is
an
app
that
runs
on
x86
and
the
target
environment
is
some
other
thing.
C
We
don't
really
have
that
distinction,
and
it's
not
it's
essentially
trivial
for
us
to
produce
an
x86
equivalent,
but
if
you're
building
for
an
armed
target,
you
need
an
arm,
build
environment,
and
that's
why
that
message
coming
through
that
we're
talking
to
people
who
are
mostly
used
to
the
sdk
model
and
therefore
x86
can
be
their
devel
environment
and
build
environment,
even
if
the
target
is
arm,
whereas
the
tools
that
we
inherit
from
fedora
and
rel
are
based
around
a
different
model.
So
that's
why
our
focus
has
been
on.
C
How
do
we
make
arm
easy
to
use?
What
arm
platforms
are
available?
How
can
we
bridge
the
two
together
pierre
has
done
some
cool
work
for
some
interesting
ways
to
literally
bridge
physically
bridge
the
two
together
in
a
way
that
might
be
useful,
so
yeah,
but
the
x86
is
not
excluded
from
this
by
any
means.
It's
just
not
it's
not
the
hard
problem.
I
guess
to
put
it
that
way.
Certainly.
A
Certainly,
a
related
question
came
up
from
the
fedora
side
actually
or
from
the
fedora
community
about
risk
five,
because
fedora
as
now
con,
I
believe
it's
now
completely
up
to
date
with
risk
five
hardware,
with
at
least
a
couple
of
different
actual
pieces
of
risk.
Five
hardware
that
we
have
in
the
in
the
lab
is
there
any
in
intention
for
us
to
eventually
support
risk,
five,
possibly
not
coming
from
red.
B
Hat
store
doesn't
support
it.
Sorry
fedora
doesn't
support
it
yet
either
it's
not
in
the
regular
build
system.
Okay,
it's
being
built
in
a
like
a
shadow,
koji
and
uploaded.
B
The
none
of
the
systems
have
that
have
been
evaluated
or
looked
at
meet
what
we
need
to
be
in
the
main
data
center,
okay
and
so
they'd
have
to
be
in
like
the
boston
lab
and
that
one's
full.
So.
B
So
the
actual
most
of
the
build
hardware
for
fedora
lives
in
a
data
lights
out.
Data
center
in
outside
of
washington
dc
lights
out
means
that
there
aren't
anybody.
C
B
Systems
should
be
autonomous
and
able
to
handle
themselves.
I
do
remember
this
discussion
yes
and
the
risk
five
hardware
is
not
at
pro
it's
beyond
prototype,
but
is
not
in
that
level.
C
Yeah
yeah
and
this
clearly
a
desire
as
risk
five
matures
to
bring
it
into
the
fedora
ecosystem.
I
don't
know
what
the
road
map
thoughts
are
on
it
for
server.
For
example,
I
think
it's
an
interesting
one
in
that
it
seems
likely
to
be
something
that
will
never
it's
not
really
being
targeted
at
that
which
gets
right
back
actually
to
the
build
and
sdk
environment.
If
there's
not
really
going
to
be
server
class
hardware
running
risk
five,
then
that
is
a
challenge
for
the
way
that
we've
typically
chosen
to
build
things.
But
there
is.
A
C
But
like
if
we
restrict
our
discussion
to
we're
focusing
on
auto
sd,
this
sig
is
is
not
actually
I
mean
we're
up.
I
I
believe
most
many
of
the
people
joining
are
fedora
users,
often
fedora
silver,
blue
users.
It's
not
like
we're
not
aware
of
her,
don't
want
it,
but
it's
been
a
conscious
decision
to
focus
the
sigs
on
at
least
red
hat's
contribution
to
this
on
things
that
are
more
targeted
at
a
derivative
of
rel.
So
and
there's
no,
I
don't
know
when
risk
five
is
on
the
roadmap
for
rel.
C
C
C
A
One
well,
one
of
the
reasons
why
I'm
bringing
it
up
is
because
there's
an
ongoing
discussion
within
the
risk
five
community
for
those
who
don't
know,
I
was
deeply
involved
with
risk
five
for
a
couple
of
years
over
the
last
few
years,
and
there
has
been
a
discussion
going
on
in
the
community
about
automotive
hardware
and
what
are
the
requirements
now
granted
the
risk
five
community
is
all
about
the
risk.
Five
instruction
set
architecture.
It's
not
about
actual
hardware.
A
So
there
will
likely
be
a
an
automotive
discussion
group
starting
up
within
the
risk
five
community
this
year,
and
I
thought
it
would
be
fun
to
bring
auto
sd
to
it
and
say
here's
something
that
we
could
potentially
run.
You
know
if
somebody
has
a
a
kimi
setup
or
a
some
other
kind
of
maybe
on
an
fpga,
a
core
that
we
could
load
up
and
let's,
let's
go
ahead
and
run
it
and
see,
see
what
we
can
see
if
there's
a
way
to
dynamically
co-develop.
These
two
things.
A
This
is
obviously
outside
of
the
realm
of
what's
interesting
to
red
hat,
using
auto
sd
as
an
upstream
for
a
product
called
the
red
hat
in
vehicle
operating
system.
Yes,
yeah.
C
No,
I
mean,
I
guess
I'll,
ask
a
pointed
question
about
this
like,
and
this
is,
I
don't
have
skin
in
this
game.
But
what
is
the?
What
is
the
presumed
benefit
of
risk?
Five
over
smaller
footprint
arm
based
socks?
Is
it?
Is
it
purely
the
open
nature
of
the
instructor?
I
I
don't
even
want
to
poison
the
discussion
like
what
is
what
is
the
expected
role
that
it
would
play
relative
to
a
similar
arm
risk
based
system
that
is
smaller
than
some
of
the
ones
we've
been
looking
at
right
now,.
A
The
main
benefit
of
risk
five
is
because
it
is
open,
it
is
completely
customizable
by
the
user,
so
you
can
literally
go
out
and
just
design
your
own
course
and
deploy
them.
It
is
not
something
where
you
need
to
have
a
license
or
or
follow
any
kind
of
a
guideline,
so
it's
basically
wild
west,
and
while
that
is
you
know,
can
be
beneficial
in
some
ways
it
can
also,
you
know.
Sometimes
those
limits
are
there
for
a
reason.
B
Engineer
but
there's
a
lot
of
liability
and
such
that
goes
yeah
to
somebody
else's
pocket
and
all
of
a
sudden.
It's
on
mine,
yes,
yeah.
E
Whereas
power
pc
could
not
make
that
conversion
with
power
quick,
because
although
they
had
a
lot
of
flexible
and
very
interesting
little
blocks,
they
couldn't
bring
the
whole
picture.
So
it's
interesting
to
see
risk
five,
basically
take
the
op
and
open
source
stab
at
the
same
kind
of
situation.
A
Yeah,
I
was,
I
wondered
why
open
power
didn't
proliferate
in
that
same
way,
given
that
it's
also
an
open
isa,
but
anyway
it's
yeah.
It's
interesting
to
watch
it's.
Obviously
it's
it's
not
directly
on
our
our
radar.
As
of
the
automotive
sig.
D
A
Not
yet,
but
I
think
it
it
probably
could
be
a
it
probably
will
come
up.
You
know
over
the
next
year.
A
And
it
is
very,
it
is
very
fun
to
watch
the
disruption
within
within
the
market,
I'm
actually
much
more
optimistic
about
in
the
arm
world
about
sophie
and
the
the
reference
architecture
that's
being
developed
specifically
for
you
know,
embedded
and
automotive
applications.
A
So
it
is
18
minutes
until
the
top
of
the
hour.
Does
anybody
have
anything
else
they
want
to
discuss,
because
we
could,
probably
just
you
know,
yammer
about
hardware
for
the
rest
of
the
day.
D
The
the
one
thing
about
the
risk
work
would
be
if
we,
if
we
were,
if
we
wanted
to
look
at
this,
you
know
in
six
months
from
now
we
would
we
would
have
to
do
a
bunch
of
the
work
of
porting.
D
Basically,
we
would
not
be
able
to
leverage
center
stream,
so
if
santa
stream
was
spotted
to
to
risk
five,
then
we
would
be.
We
would
automatically
inherit
from
that,
and
we
would
only
have
to
care
about
the
part
where
we
diverge
from
the
stream.
But
if
this,
as
long
as
as
long
as
sensor
stream
isn't
doesn't
support
risk
fight-
and
it's
a
that
makes
it
all-
you
know
another
level
of
of
work-
sure
to
be
able
to
experiment
with
that.
A
C
I
thought
so
maybe
I'm
misremembering
but
or
maybe
it
was
rel7
even
centos
7,
I
should
say
yeah
yeah
it's
on
I.
I
have
no
insider
information
on
this,
but
I
consider
it
unlikely
that
risk
5
would
be
added
as
a
supported
architecture
in
the
lifetime
of
real
nine.
But
it's
not
unprecedented
for
the
centos
community
to
experiment
with
that.
B
B
About
they
ran
it
as
a
separate
group,
and
then
they
once
sent
us
eight
was
gone.
There
wasn't
a
their
interest
in
doing
so
continuing.
It
was
gone
too.
B
A
Sounds
good
all
right!
Well,
thank
you.
Everybody
for
joining
really
appreciate
the
update
pierre
and
congratulations
on
the
very
large
amount
of
work
done
over
this
last
month
and
we'll
talk
to
you
all
soon.