►
From YouTube: 2022 03 11 Platform SIG
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
A
A
And
any
other
addition,
any
other
topic
so
mike.
I
think
your
topic
would
fit
under
the
the
docker
agent
support
editions
question
you
would,
I
think,
wanted
to
talk
about
windows,
server,
support
versions,
et
cetera,.
B
I
did
all
right
so
interested
in
the
system
d
instead
of
system
five
and
net
okay.
I
think
the
ubuntu
images
are
not
using
that.
So
I
understood
something
correctly
yesterday
for
the.
A
A
Great
so,
let's
well,
let's,
let's
certainly
go
through
and
we
can
certainly
discuss
it.
Absolutely,
I'm
not
aware
of
any
open
action.
Oh
I
take
it
back.
We've
got
one
open
action
item
that
still
needs
to
carry
forward.
It's
a
documentation
task
for
the
sig
that
I
haven't
completed.
Yet
the
plug-in
installation
manager
docs
still
need
to
be
updated,
with
more
use
cases
etc.
A
A
B
We
finally
have
images
for
the
64-bit
platforms.
A
A
Sluggish
okay
tags
and
if
we
look
at
the
most,
let's
look
at
the
most
recent
lts,
and
here
we
see
and
let's
make
it
big
enough,
so
human
beings
can
read
it
amd
64..
Oh
that's
what
I
get
from
so
amd,
64
arm,
64
and
system.
390
are
all
provided
in
those
in
those
images.
A
Did
did
that
answer
your
question
mike?
It
totally
did
okay
yeah,
so
this
is.
This
is
special
thanks
to
tim,
jacom
and
damian
deportal
tim
found
how
to
use
docker
buildex
bake
to
let
us
build
multi-platform
binaries
on
amd64,
and
then
we
have
automated
tests
that
were
provided
by
a
person
at
ibm
that
test
these
things
regularly
and
make
sure
that
they're
still
well
behaved
on
the
actual
platforms.
A
A
A
A
A
B
B
It
can
be
if,
if
it's
not
too
much
trouble,
could
you
just
give
me
an
overview
of
lte?
What
is
ltsc?
What
is
the
difference
between
that
and
this
1809.
A
A
A
A
A
A
Yeah
good
question,
so
the
the
the
the
the
message
there
is
that
we
intentionally
want
ltsc
and
we
don't
attempt
to
track
the
semi-annual
channel.
Okay,
so
so
ltsc
is
the
preferred
channel
is
the
channel
we
we
track.
A
A
With
an
lts
server
right
here
we
go:
let's
get
this
one.
I
think
this
is
the
place
where
we
can
okay
windows
server.
Yes,
here
we
go
so
ltsc.
2019
was
the
preview.
Is
the
the
previous
and
apparently
they've
just
not
long
ago
done
ltsc
2022
and
we
haven't
yet
had
a
pull
request
to
update
to
ltsc
2022.
A
B
A
Apparently,
exactly
see
that
where
1809
is
a
semi-annual
channel
name
right,
that's
2018
the
ninth
month,
whereas
2019
is
ltsc
naming
but
yeah
the
the
similarity
similarities
they're,
both
four-digit.
They
didn't
have
the
decency
to
put
a
dash
or
a
dot
between
things
so
yeah.
It's
it's
plenty
confusing.
A
B
B
A
B
Yeah,
I
believe,
but
that's
that's
my
understanding
too,
is
that
they
they
need
to
be
matched
for
the
functionality
to
work
like
you
wanted
to.
A
We'll
tend
to
stay
with
ltsc
2019,
keep
us
informed
and
or
submit
a
pull
request.
If
you
get
to
that
point,
where
you
say
hey,
we
really
want
ltsc
2022.,
it's
a
it's
a
reasonable
thing
to
say:
let's
get
to
the
newest,
it
just
will
require
us
to
do
some
infrastructure
updates
to
jenkins
infra
in
order
to
use
ltsc
2022
images
to
build
it.
Okay,.
B
If
I
will
definitely
keep
you
apprised
of
any
movement
or
updates
on
that
topic,.
A
A
A
Red
hat
and
centos
so
so
we're
pretty
confident
that
it's
working
as
expected,
there
are
some
there
are.
There
have
been
one
or
two
bug
reports.
There
have
been
a
few
bug
reports.
Let's
just
say
it
that
way
on
specific
details
and
we
need
some
need
documentation,
improvements.
A
For
some
of
those
details,
so
one
of
them
is,
for
instance,
that
now
we
can
use
reserved
ports
like
port
80
or
port
443
directly
thanks
to
system
b.
But
there
isn't
any
instructions
specifically
in
the
documentation
about
how
you
make
that
change.
It's
a
pretty
simple
change,
but
you
have
to
read
configuration
files
to
make
it
so
how
to
use
port
80
or
or
443.
B
So
I'd
heard
that
we
didn't
have
systemd
support
yet
in
the
debian
packages.
A
A
I
forget
the
specific
details,
but
but
we're
expecting
more
things
like
that,
where
some
surprise
happens
and
and
users
have
to
make
a
change
that
it's
really
elegant,
that
now
we
can
make
configuration
edits
on
any
platform,
use
the
same
commands
or
any
linux
linux
install
use
the
same
commands
system
d
really
does
does
make
it
easier
to
administer
the
trade-off
there
is.
It
also
moves
the
log
location
to
a
system
d,
standard
location
and
it
places
the
war
file
in
a
system
in
a
standard
location.
A
A
On
systemd,
because
we're
expecting
lots
of
lots
of
interest
on
how
do
you
use
this
thing?
Well,
how
do
you
help
it?
Let
it
help
you.
A
A
A
A
A
A
B
A
Great
excellent,
okay,
so,
and
and
now
as
part
of
this
effort,
what
what
basel
has
also
done
has
created
some
downstream
epics
for
the
eventual
transition
to
java
17..
That
may
be
several
years
away
yet,
but
we've
got
a
placeholder
to
capture
that
so
that
we
know
oh
hey,
when,
when
the
java
17
transition
happens,
we'll
we'll
use
the
same
technique.
A
B
A
B
I
think
so
that's
kind
of
covered
the
questions.
I
was
curious
about
so.
A
Yeah,
basel
has
really
done
an
excellent
job
there.
So
the
next
topic,
then,
was
the
linux
operating
system
support
policy.
Back
in
february,
I
had
proposed
a
pull
request
using
the
windows
operating
system,
support
policy
that
we
have
on
jenkins.io
to
propose
a
whoops
to
propose
a
a
linux
support
policy,
and
if
we
look
here,
we
should
be
able
to
go
find
well,
let's
look
at
the
page,
so
it
describes
three
levels:
level,
one
supported
level,
two
patches
considered
and
level.
Three
unsupported
and
level.
Two
is
hey,
we'll
take
it
most
anything.
A
The
only
reason
something
is
on
level.
Three
is
if
the
the
vendor
of
the
linux
operating
system
no
longer
supports
that
version,
so
we
will
not
accept
patches
to
support
ubuntu
14..
Sorry,
it's
just
off
the
list
level.
2
are
platforms
that
we
don't
have
the
capacity
to
test
risk
5,
for
instance,
the
32-bit
architectures.
We
we
just
aren't
going
to
spend
the
effort
to
construct
testing
environments
for
those
and
pretty
much
everything
else
is
here.
B
I
I
it
makes
sense,
and
I
think
you
know
having
them,
follow
the
same
sort
of
model
and
terminology
and
everything
just
going
to
make
life
easier
for
everybody.
A
Right
exactly
yeah
good
point,
so
it's
and
there
was
a
developer
mailing
list.
There
is
a
developer
mailing.
This
discussion
on
it
and
people
can
read
it.
It's
it's,
it's
been
quiet,
and
so
I'm
trying
to
bring
it
back
to
life.
A
A
However,
I
noticed,
as
I
was
testing
it,
that
it
had
a
surprise
in
that
when
I
do
a
docker
run,
it
will
stay
in
the
foreground
by
default.
Until
I
restart
jenkins
and
then
the
docker
run
process
appears
to
exit,
but
the
docker
process
that
is
jenkins
continues.
So
it's
a
minor,
a
minor
compatibility
change
that
I
found
interesting
and
we
may
need
to
document
that
kind
of.
I
don't
know
anybody
that
actually
runs
docker
in
the
foreground
and
expects
it
to
stay
there
long
term
right.
That's
that's
really
odd.
A
B
Explored
further,
I
I
I'm
only
superficially
familiar
with
it,
but
anything
that
reduces
complexity
and
standardizes
things
across
platforms.
I
am
100
and
supportive.
So
if
my
understanding
of
the
benefit
of
that
is
correct,
like
I
think
it's,
it's
definitely
worth
pursuing.
B
A
Is
teeny
tiny,
tiny,
so
so
this
is.
This
is
a
one
that
I
haven't
even
proposed
yet,
but
in
a
in
the
docker
world,
docker
has
the
ability
to
so
there
is.
There
needs
to
be
a
process
reaper
for
for
processes
started
by
docker.
That
then
start
sub
processes
and-
and
in
our
case
we
use
tiny,
which
is
a
small
version
of
init,
and
this
tiny
that
we
use
is
actually
now
been
sub,
been
sort
of
replaced.
A
A
Yes
run
multiple
services
in
a
container
talks
about
in
it
and
if
you
run
it
with
the
init
option
to
run
the
container,
it
creates
a
tiny
init
process
and
reaps
the
processes
for
you.
When
the
container
exits.