►
Description
A show that features the people and technology that make Red Hat Enterprise Linux into the world’s leading enterprise Linux platform.
Episode 1: New vector for Red Hat Enterprise Linux
Guest: Gunnar Hellekson
Practical Demo: Managing Software with Application Streams
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
the
very
first
episode
of
red
hat
enterprise,
linux
presents
here
on
openshift
tv
today,
we're
joined
by
the
one
and
only
scott
mcbryan,
and
he
has
brought
on
a
very
special
guest
scott.
Would
you
like
to
introduce
yourself
and
then
maybe
hand
it
off
to
our
special
guest
to
introduce
themselves.
B
C
D
C
A
Awesome,
it's
great
to
have
you
both
on
I'm
super
excited
about
this
show.
As
it's.
You
know,
I've
worn
my
special
set
in
force.
One
shirt,
I'm
very,
don't
think
I
didn't
notice,
I'm
very
appreciative.
I
have
been
in
the
red
hat
ecosystem
since
the
90s
and
I've
been
at
red
hat
for
two
years
now
and
I'm
just
like
tickled
to
just
be
here
to
just
have
this
job
and
also
to
be
talking
to
the
both
of
you,
because
I've
used
linux
forever
and
it's
pretty
much
been
rel.
B
C
C
C
D
A
C
C
C
It
down
for
you
right
in
front
of
you
yeah.
Actually
it's
funny
the
lead
of
engineering
mike
mcgrath
actually
does
have
a
digital
clock
behind
him
in
every
video
call,
which
is
like
it's
just
it's.
This
constant
presence
of
like
counting
down
the
hours
and
minutes
and
seconds
yeah.
That's
amazing!
No
pressure,
yeah,
no
pressure
at
all
yeah.
C
C
We
turn
it
on,
and
so
my
colleague
susan
denham,
who
who
runs
the
partner
engineering
team
for
for
rarel.
You
can
think
about
her
like
pasting,
every
nda
roadmap
in
the
industry,
up
on
a
huge
wall
and
looking
for
like
one
piece
of
white
space,
and
she
knows
so.
She
would
look
there
and
she'd
be
like
rel7
right
about
there
right.
That's
the
sweet
spot
where
we're
gonna
like
slide
into
the
schedule
and
enable
as
many
people
as
possible
without
being
disruptive,
but
over
the
last
like
five
years.
C
The
hardware
industry
has
just
gotten.
So
I
don't
want
to
say
chaotic,
but
there's
there
are
so
many
new
players.
It
is
so
I'll
call
it
disordered
right.
It's
you
know
used
to
run
on
a
pretty
steady
metronome,
and
so
we
could
schedule
things
like
that.
The
hardware
industry
doesn't
work
like
that
anymore
between
public
clouds.
Hardware,
accelerators
all
these
new,
all
these
new
architectures.
So
we
said
well.
C
If
our
job
is
to
make
life
as
easy
as
possible
for
for
a
customer,
then
we
have
to
be
the
ones
to
take
the
hit
of
all
of
that
chaos
and
disorder.
So
we're
gonna
set
a
steady
schedule
so
that
people
can
actually
plan
around
it
right
because,
if
you're
planning
around,
if
you
know
when
rail's
gonna
land,
then
you
can
like
anticipate
budgets,
you
can
anticipate
your
project
plans
and
things
like
that
and
it's
kind
of
funny.
You
know
when
I,
when
I
started
when
I
started
with
rel.
B
C
D
A
A
Just
you're
absolutely
right,
gunner
the
the
pervasiveness
of
hardware,
the
diversity
of
where
it's
landing
and
when-
and
you
know
it's
just
like
you
know-
nvidia
just
released
like
some
new
tinker
toy
chipset
thing
yesterday
it
was
like.
Oh
my
gosh
like
this
is
a
new
thing.
Another
new
thing
is
wow.
It
is
a
very
high
intensity
and
yeah
keeping
up
with
just
the
hardware.
That's
hard
enough.
So
having
that
established
schedule,
I
feel,
like
is
a
value
add
in
my
opinion,
yeah.
C
That's
right
well,
and-
and
it's
also
not
just
the
whatever
it
is
5
000,
hardware,
certifications
or
whatever
it
is
that
we've
got
it's
the
it's
also
the
combinatorics
of
all
of
those
different
pieces
of
hardware
right,
because
none
of
the
things
people
buying
are
monolithic.
It's,
like
you
know
the
choice
of
each
individual
component,
making
sure
all
those
individual
components
work
together.
C
C
B
So
gunner
you
mentioned
choosing
which
packages
are
in
or
out
of
red
hat
enterprise
linux.
I
think
that
ties
into
one
of
our
other
conversations
that
we've
had
in
the
past,
which
is
we
also
made
a
decision
with
red
hat
enterprise,
linux
8,
to
make
some
changes
to
how
we
include
or
don't
include
packages.
D
C
Strategy
yeah,
so
so
here's
here's
the
other
thing
that
so-
and
I
know
this
back
when
I
was
an
assist
admin-
is
so
here's
a
fun
fact.
Every
major
release
has
increased
in
size
by
50
and
that's
not
because
the
job
of
the
operating
system
required
50
more
hardware.
Each
time
we
did
a
major
release
right
right.
The
reason
is
it's:
it's
interesting
people
don't
people.
C
Yes,
they
want
an
operating
system,
but
the
actual
operating
system
part
of
what
we
ship
is
actually
a
small
fraction
of
the
actual
of
all
the
packages
that
are
that
are
in
the
box
right.
What
happens?
Is
people
begin
to
trust
their
operating
system
vendor
to
ship
them,
software
that
works
and
that's
going
to
get
maintained
and
it's
going
to
get
patched,
and
so
people
use
the
operating
system,
yes
as
an
operating
system
proper,
but
they
also
use
an
operating
system
as
like
a
library
of
dependencies
that
I
can
trust
right.
C
So
I
don't
have
to
go
like
roll,
my
own
nginx
or
whatever,
and
so
what
people
do
is
you
know
they
rely
on
the
python
that
we
ship
or
they
rely
on
whatever
you
know,
ruby
or
pearl
or
like
whatever
the
runtime
is,
and
we've
been
we've
struggled
with
that,
because
on
one
hand
you
have
the
operating
system,
kind
of
life
cycle,
promises
themselves
extend
out.
You
know
10
years
13
years
into
the
future.
B
Yeah-
and
you
know,
there's
kind
of
like
two
two
competing
factions
in
system
admin,
architecture,
world
and
one
is
the
it's
never
fast
enough
right.
I
need
I
need
the
latest.
Oh
there's
a
zero
one
update
to
node.
I
need
that
and
then
the
opposite
is
like
the
well.
Ten
years
ago
we
made
a
thing
yeah
and
we.
C
Yeah
well,
here's
the
here's.
The
fun
part
is
that
those
two
people
are
the
same
person
because
it's
it's
like
everybody
wants
exactly
like
the
very
latest
thing
right
up
until
you
go
into
production
and
then
don't
even
don't
sneeze
at
it,
don't
look
at
it,
don't
touch
it
just
like
leave
it
exactly
the
way
it
is
right
and
obviously
folks
who
have
like
thoroughly
gone
through
the
you
know
the
devops
indoctrination
and
have
gone.
You
know.
B
C
B
B
So
about
two
years
ago,
I
was
asked
to
update
a
piece
of
code
at
red
hat
that
had
been
in
production
for
17
years
that
I
had
written
in
a
weekend
and
the
reason
I
was
asked
to
update
it
was
because,
like
no
one
else
knew
how
it
worked,
and
it
was
written
on
this
really
old
thing.
It's
like
if
it's
so
critical
to
your
business,
that
that
you
need
to
have
it.
B
C
A
C
Well,
we
could
but
like
what's
the
point
like
it's
like,
you
can
go,
get
it
yourself,
it's
not
it's
not
that
hard,
and
so
it's
it's
letting
people
live
in
as
much
of
the
middle
as
possible
right
to
introduce
like
just
enough
stability
where
it's
useful
without
getting
kind
of
decrepit
right.
That's
the
that's!
The
balance.
B
Where's
my
where's,
my
overhead
light
gunner.
I
will.
I
will
get
the
answers
out
of
you.
Oh
so
I
know
that
we're
not
supposed
to
choose
the
child,
we
love
the
most,
but
I
definitely
have
a
child.
I
love
the
most.
What's
the
thing
that
is
most
interesting
important
about
red
hat
enterprise
linux
to
you.
C
So
we
talked
about
the
we
talked
about
the
cadence
and
I
think
now
that's
actually
probably
my
favorite
feature,
but
that's
connected
to
my
second
favorite
thing,
which
is
again
along
those
lines
of
the
product.
The
product
is
only
incidentally,
the
bits
the
product
is
everything
around
the
bits
for
us,
and
so
that's
actually
the
ecosystem.
C
It
is,
and
it's
and
there's
a
small
army
of
people
inside
red
hat
that
make
sure
that
all
of
those
things
work
together
and
the
the
ability
for
us
to
do
all
that
grunt
work
so
that
we
can
deliver
as
much
as
much
option
value
to
customers
as
possible.
I
think
that's
the!
I
think
it's
really
cool
it's
it.
I
remember
when
I
used
to
when
I
started
with
red
hat.
C
It
was
just
like
expected
that
an
operating
system
would
have
a
lot
of
hardware
and
that
would
have
a
lot
of
applications,
but
now
now
that
I'm
kind
of
on
the
other
side
of
the
wire-
and
I
see-
and
I
can
kind
of
peek
behind
the
curtain
and
see
literally
hundreds
of
people
that
have
to
toil
every
day
to
make
sure
that
all
of
this
stuff
actually
works.
I
now
have
like
a
newfound
appreciation
for
how
how
actually
hard
that
is
not
just
on
a
single
row
release
but
on
we're.
Maintaining.
C
You
know
multiple
major
rail
releases
at
any
given
time
and
then
multiple
minor
releases
inside
that.
I
think
at
one
point
somebody
told
me
we're
running
like
43
current
kernels
concurrently
at
any
given
time
and
so
the
ability
to
keep
that
ecosystem
coherent
across
those
43
or
whatever
kernels
is
a
that's
extraordinary.
I
mean
it's,
it's
it's
something
I'm
proud
of
anyway,.
B
Yeah
and
to
add
a
little
context
to
that,
what
many
people
I
don't
think
understand
is
that
we've
got
not
just
the
major
release
but
there's
dot
releases
that
have
a
longer
term
maintenance
cycle
within
it.
So,
for
example,
rail,
8.1
and
8.2,
or
what
we
call
eus
or
extended
update
support
releases,
and
we
have
those
for
rel,
seven
as
well,
and
rail,
six
as
well,
and
rail
five
as
well
at
least
for
a
little
while
longer,
and
so
when
something
like
a
critical
vulnerability
comes
out
for,
say
the
linux
kernel.
B
B
So
yeah
totally
so
one
of
the
other
changes
that
we
did
with
route
8
was
changing
the
maintenance
and
a
little
bit
on
life
cycles.
So
we
talked
somewhat
on
lifecycle
because
we
now
this
predictable
release
cadence,
but
one
of
the
other
things
I
found
really
interesting
was
that
we've
pre-announced
all
of
the
dot
releases
for
rail,
eight
and
plotted
them
out
on
a
rough
calendar
of
when
they'll
be
released.
B
C
Well,
it
kind
of
the
first
follows
from
the
other
right
like
if
you're
gonna
have
a
predictable,
cadence
and
you're
gonna
kind
of
call
the
ball
this.
If,
if
I'm,
if
I'm
honest
that
certainty
in
the
schedule,
it
helps
customers
for
all
the
reasons
I
just
talked
about,
but
it
also
helps
us
in
our
own
resource
planning,
right,
like
figuring
out
exactly
like
how
many
engineers
need
to
be
working
on
a
particular
thing
at
a
given
time.
So
now
that
the
customer
is
certain
we
and
we're
certain
we
can.
C
Oh,
I
know
when
then,
when
my
what
my
refresh
cycle
can
be,
because
I
know
when
the
rel
releases
are
going
to
come
right,
that's
a
big
part
of
the
calculation,
and
so
likewise,
internally,
like
we
know
what
the
we
know
when
all
the
schedules
are
going
to
work
out,
and
so
we
know
what
the
staffing
has
to
look
like
across
across
each
of
these
across
these
releases.
So
yeah.
B
Yeah-
and
I
don't
know
if
you've
experienced
this
when
you
were
working
in
sales
or
not,
but
it's
always
disheartening
when
you're
talking
to
a
customer
about
oh
yeah,
we're
end
of
maintenancing,
this
and
they're
like
what,
but
I
have
an
app
and
it's
going
to
take
a
million
dollars
for
me
to
you,
know,
engage
the
developers
and,
like
do
all
the
stuff,
and
it's
like
now.
You
know
when
that's
going
to
fall
into
your
budget
right,
and
so
it's
not
a
six
month,
we're
in
mid
cycle
of
the
budget
year.
B
C
That's
a
risk
because
they're
not
able
to
take
advantage
of
what's
going
on
in
upstream,
all
the
new
features
and
all
the
fun
stuff.
So
that's
bad
for
them.
It's
also
bad
for
us,
because
we
get
people
piled
up
on
a
particular
release
and
now
we
got
to
extend
maintenance
on
it
or
or
whatever
like.
If
people
get
stuck,
that's
bad
for
both
of
us
so
and
actually
you're.
Making
me
think
about
this.
I'm
gonna
revise
my
answer
on
what
you
said.
What
my
favorite
child
is.
C
B
And
there
may
be
some
some
things
that
happen
at
the
application
layer
that
need
to
be
updated
right
because
you
get
the
like
30
000
little
red
dots
saying
that
they
need
to
be
updated.
But
you
know,
generally
it
all
just
kind
of
works,
because
the
functionality
provided
by
the
library
system
just
keeps
going
right
right.
So
I
know
that
we're
not
there
today,
but
that's
certainly
where
they
want
to
be.
C
Yeah
and
that's
it,
you
know
that
imprison
upgrade
tool.
That's
a
good
example
of
there
are
some
operating
system
features
which
are
like
you
just
write
them
and
then
they're
done,
and
then
they
just
work
and
the
in-place
upgrade
is
a
good
example
of
one
of
those.
It's
not
a
feature.
It's
like
a
lifestyle
like.
C
B
D
C
That's
right
so
so
one
so
one
thing
that
I've
noted,
so
here's
a
behavior
that
I've
noticed
is
that
and
it's
actually
we're
actually
also
guilty
of.
It
is
when
people
talk
about
how
to
use
the
operating
system
and
how
to
improve
it,
and
things
like
that.
The
use
case
or
like
the
persona
is
always
like
up
someone
with
a
keyboard
and
a
mouse
interacting
with
the
computer
right
that
is
still
like
in
product
planning.
That's
that
way,
that'll
still
sleep
in
like
when
people
think
about
like.
C
Oh
well,
like
what
do
I
need
out
of
an
operating
system,
that's
kind
of
like
what
they
have
in
mind
right.
You
know
the
number
of
people
who
like
complain
about
the
you
know
gooey
stuff,
on
rel
right,
like
there's,
still
a
lot
of
people
who
come
into
augusta
when
the
fact
is
that,
like
the
vast
majority
of
rel,
is
not
managed
from
a
keyboard
or
a
mouse
or
even
a
person
like
the
vast
majority
of
rel,
is
being
managed
by
a
robot
somewhere.
C
It's
like
a
configuration
management
system
or
some
provisioning
system,
or
something
like
that
and
there's
a
lot
of
people
who,
for
very
good
and
defensible
reasons,
are
still
managing
their
rel
each
one.
As
like
a
separate
snowflake,
you
know
highly
optimized.
You
know
this.
Like
okay,
I'm
gonna,
I'm
gonna
shape
this
operating
system
around
this
database
and
make
sure
that
I'm
getting
all
the
perfect
performance
out
of
it
and
all
the
rest
of
it.
C
C
If
you
are
still
handcrafting
your
operating
system
do
yourself
a
favor
and
and
start
automating
it
even
if
it's
just
you,
it's
gonna,
make
your
life
easier
and
and
reduce
the
number
of
errors
and
all
the
rest
of
that.
So
that's
that's!
That's
the
first
thing
and
kind
of
connected
to
those
two
things
is
there's
two
kind
of
sleeper
features
in
rel,
eight,
which
I'm
like,
which
I
really
want
more
people
to
be
taking
advantage
of.
C
The
first
is
called
system
rolls.
We
took
a
bunch
of
ansible
modules
and
shipped
them
in
rel
and
to
the
point
about
in-place
upgrades
earlier.
The
idea
here
is
that,
when
you
upgrade
from
one
major
version
of
an
os
to
another
one
of
the
biggest
most
painful
things
about,
it
is
not
not
just
the
making
sure
your
applications
run
and
pass
qe
and
all
the
other
stuff.
C
It's
that
all
the
day,
two
management
changes
as
well
because,
like
we
do
silly
stuff
like
move
etsy
files
around
and
like
change,
daemons
and-
and
it's
not
called
bind
anymore
and
stuff
like
that
right
and
so
what
these?
What
these,
what
these
system
roles
do
is
give
you
one,
consistent
interface
that
will
be
consistent
across
major
releases
for
automation.
C
So
you
have
like
one
consistent
way
of
managing
time,
one
consistent
way
of
managing
whatever
the
web
server,
whatever
it
is,
se
linux,
another
good
example
right,
and
so
you
can
be
kind
of
inoculated
from
any
kind
of
version
to
version
changes.
We
we
create
this
kind
of
stability
layer
that
we
call
system
rawls,
it's
kind
of
funny.
We
spend
a
lot
of
time
in
rail
thinking
about
the
abi
right,
the
binary
compatibility
to
make
sure
that
applications
that
run
on
rail
7
will
also
run
on
rl8.
C
C
Let
you
know
if
you
had
critical
vulnerabilities
or
whatever
the
we've
recently
added
a
whole
bunch
of
insights,
features
to
do
things
like
managing
drift,
for
example.
So
you
know
if
your
systems
have
changed
configurations,
you
know
if
your,
what
your
patch
levels
are
security
and
vulnerabilities.
C
I
didn't
do
my
homework,
so
I'm
not
going
to
like
go
through
all
the
keywords,
but
there's
now
like
an
entire
universe
of
new
tools
available
for
you.
If
you
have
registered
your
systems
with
insights,
and
the
idea
here
is-
is
to
make
it
as
easy
as
possible
to
do
that.
Automation
to
do
that,
that
that
scalable
management
for
rel
and
not
just
on-premise
but
also
in
the
cloud
and
elsewhere,
so
expect
to
see
lots
more
great
things
coming
out
of
that
insights
platform.
A
Yeah
john
spanx
once
told
me
a
story
about
a
customer
that
had
this
like
bespoke,
set
up
with
some
database
and
some
version
of
rel,
and
they
just
did
a
sample
size
of
systems
and
put
them
in
the
insights
and
it
found
like
they've,
been
working
with
the
database
vendor,
for
you
know
months
trying
to
figure
out
why
this
thing
was
happening
and,
like
insights
found.
Oh
there's
incompatibility
between
this
specific
kernel
and
this
specific
version
of
database
and
yeah
like
insights,
just
like
bing
found
it
immediately
so
yeah.
C
Operators,
the
way
I
explain
it
to
the
way
I
explain
to
customers
this
light
is
that
the
insights
is
meant
to
be
it's
an
expert
system,
that's
built
on
15
years
of
support
cases
right
that
have
come
into
us
right
and
so
like
as
long
as
we
have
seen
a
problem
in
the
past.
The
goal
is
to
make
sure
that
that
that
we
can
identify
that
problem
using
insights
so
anyway,
yeah.
I
think
it's
great
more
people.
C
B
B
As
a
prior
assistant,
administrator
and
professional
services,
person
like,
I
always
likened
being
a
really
good
system,
administrator
to
like
being
an
airline
pilot
right,
like
pilots
aren't
up
there
like
jacking
the
stick
and
like
messing
with
the
throttle,
the
entire
flight
right.
It's
like
they
have
autopilot
and
they
have
automations
and
they
just
kind
of
set
it,
and
then
they
sit
back
and
they
like
read
their
ipad
drink.
B
B
Point
of
having
two
pilots
right.
Well,
so
what
happens
when
that
autopilot
like
freaks
out
right
for
whatever
or
solar
flare,
or
what
have
you?
It's
like?
You
have
that
person
to
be
like?
Oh
yeah,
no,
we're
we're
not
over
the
airport
right
now!
There's
an
ocean
down
there.
Let
me
not
land
the
plane
at
this
moment
yeah
and
that's
what
good
system
administrators
should
strive
to
be.
It's
like
you
could
spend
hours,
administering
one
box
or
five
boxes.
Oh.
D
B
B
Now,
when
that
population
grows
to
50
boxes
or
500
boxes,
you're
not
having
to
spend
a
hundred
times
the
amount
of
time
that
you're
spending
before
right
or
ten
times
the
amount
of
time
you're
spending
before
instead,
you
can
sit
back
and
kind
of
read
your
your
kindle
and
drink
some
coffee
and
wait.
Wait
for
your
autopilot
to
land
your
plane.
B
So
gunner
you,
you
grew
up
in
hawaii.
That
is
where
I
learned
that
you
can
never
turn
your
back
on
the
ocean.
That's
true
because
it
will
destroy
you.
Yes,
well
standing
at
the
beach
and
like
somebody
from
my
family
was
standing
on
the
on
the
shoreline
and
they
called
me
and
I
turned
around
and
looked
at
them
and
then,
when
I
turned
back
around
it
was
just
a
wall
of
water
over
my
head
and
just
pick
me
up,
and
slam
me
into
the
into
the
shore.
B
C
Just
call
it
so
yeah
yeah
totally
so
so
I've
been
working,
I'm
almost
15
years
with
with
red
hat,
and
I
don't.
I
did
not
completely
understand
the
red
hat
enterprise,
linux
lifecycle
policies,
if
you
ever
go
to
the
lifecycle
page
internally,
we
joke
about,
like
the
lifecycle
page
and
then
everybody
kind
of
like
or
like
everybody
kind
of
laughs
into
their
into
their
hands,
because
the
lifecycle
page
is
this
impossibly
used
to
be
this
impossibly
byzantine,
okay.
C
Well,
if
you're
at
this
stage
and
you're
in
this
phase,
then
you're
getting
these
services,
but
then
there's
this
one
year
of
overlap
where
you're
getting
this,
but
not
this,
and
then
you
own
to
go
into
the
maintenance
phase
and
then,
after
that,
there's
the
extended
lifecycle
phase
and
it's
like
anyway.
So.
C
We
were
able
to
kind
of
simplify
the
rules
a
little
bit
and
make
them
at
least
give
a
human,
a
chance
of
understanding
what
the
what
the
rules
were,
and
so
we
did.
We
did
a
first.
We
did
a
massive
content
consolidation,
so
it
used
to
be.
I
remember
when
I
installed
my
first
rel
system.
I
was
confronted
with
this
like
confusion
of
available
channels
and
they
had
very
obvious
names
like
optional
extras.
B
C
C
Exactly
right,
and
so
so
you
had
all
these
channels
and
then
you
had
all
these
different
life
cycle
phases.
So
you
got
a
certain
set
of
services
in
the
fourth
year
through
the
first
four
years
and
then
a
set
of
services
in
the
fifth
year
and
then
in
the
years
six.
Through
I
mean
it
was
just
it
was
a
mess.
So
first
thing
we
did
was:
did
the
content
consolidation
so
now
there's
fewer
channels
and
they're
now,
all
hopefully
now
all
obviously
named.
C
So
that's
that's
so
that
was
the
first
thing
I
was
naming
is
hard
though
butting
is
hard.
Naming
is
hard
first
step
towards
naming
is
getting
rid
of
things
that
you
have
to
name
right,
so
that
was
that
was
the
philosophy
right
just
reduce
the
reduce
the
attack
surface
for
confusion.
If
you
like
and
then
and
then
the
second
thing
we
did
was
simplify
the
the
phases.
So
now
it's
first
five
years
getting
features.
Second,
five
years
only
bug
fixes
easy.
C
A
C
D
A
C
Oh
yeah,
no,
we
have
the
rights
yeah,
no,
no
red
hat.
No,
the
the
red
hat
engineer
the
red
enterprise
linux
engineering
team
has
been
extraordinarily
indulgent.
With
this
requirement
is
how
I
will
put
it
they
have
been.
I
mean
obviously
everybody's
worried
about
having
too
much
work
to
do
and
all
the
rest
of
it,
but
I
think
they're,
a
combination
of
we
had
some
some
clever
automation
internally
has
helped
with
this
a
great
deal.
We
did,
as
you
know,
scott.
B
All
right,
so
let
me
bring
up
our
live
product
experience
here,
for
anybody
who
hasn't
seen
it
before
it's
lab.redhat.com
and
myself
and
other
folks,
including
folks
in
engineering,
all
kind
of
contribute.
Some
labs
running
on
live
systems
to
showcase
some
of
the
features
and
things
that
red
hat
enterprise
linux
offers.
B
Yeah,
so
we
let
the
system
provision
here
for
a
second
and
basically,
what
it's
doing
is
taking
a
system
out
of
a
pool
of
pre-configured
systems
and
attaching
it
to
the
red
hat,
subscription
manager
and
doing
a
little
bit
of
that
kind
of
stuff.
While
it's
provisioning
here
and
when
that
message
finally
goes
away,
we'll
have
a
live
box
to
monkey
with,
and
chris
you've
seen
this
as
well,
because.
A
B
B
B
Like
three
little
rail
boxes
that
you
get
to
manage
so
there's
some
some
more
complex
stuff,
but
generally
our
our
lessons,
all
kind
of
deal
with
one
box,
because
we
see
these
as
foundational
skills
that,
as
you
get
into
larger
layouts
like
you,
just
carry
the
skill
set
with
you
and
it
all
kind
of
works.
The
same
also
for
those
of
you
who
may
not
have
seen
this
before
any
command,
that's
got
this
little
enter
key
character.
Next
to
it
is
clickable,
so
I
could
type
that
command
over
here.
Okay,.
B
B
You
know
it's
a
live
box,
so
it
pulls
it
from
whatever
is
most
most
available,
all
right
so
gunner
and
I
were
talking
and
talking
about
application
streams
and
how
we're
providing
multiple
versions
of
things
for
folks
now,
and
so
there
are
some
that
are
managed
as
modules
meaning
they're,
like
a
set
of
rpms.
That
kind
of
get
managed
together
and
there
are
some
that
are
independent
so
for
for
the
purposes
of
you,
know
kind
of
expressing
this
as
a
more
useful
thing,
we're
going
to
talk
about
the
module
ones
so.
A
B
All
right,
so
there
are
three
different
versions
of
postgres
available
for
red
hat
enterprise:
linux
8.,
when
it
originally
released
with
8
0,
9,
6
and
10
were
available,
and
when
red
hat
enterprise
linux
8.2
was
released,
postgres12
came
into
the
mix
as
well.
So
as
the
distro
grows
and
continues
on
its
life
cycle,
we
will
add
these
different
versions
of
packages
in
here
to
help
folks
out.
B
If
rail
nine
came
out
today,
right
pause,
rel,
nine
is
not
coming
out
today
right,
but
if
it
were,
it
would
have
postgres
12
in
it
right,
because
that's
the
most
recently
available,
one
that
we
support,
and
so,
if
you
had
postgres
10
and
you
moved
to
postgres
12
on
rail,
eight
and
then
round
nine
came
out,
and
it
also
has
postgres
12
right.
How
big
of
a
lift
for
your
app
would
it
be
to
move
it
over
to
this
updated
operating
system?
B
B
B
But
in
any
event,
so
we'll
continue
to
add
new
versions
of
applications
and
stuff,
as
rel8
continues
up
until
that
five
year
mark.
So
that
would
be
2024
is
when
we
switch
over
to
maintenance
for
rel
eight
all
right.
So
we
can
see
those
three
different
versions
there
and
if
you
want
to
install
a
version
of
it
notice
that
one
this
one
right
here
is
labeled
as
the
default.
B
A
B
B
Going
to
click
this
one,
because
I'm
lazy
and
notice
that
it's
running
it
here
and
it
goes
ahead
and
installs
postgres
the
module
grouping
for
postgres
is
the
client
and
the
server
so
installs,
both
those
and
then
also
the
prerequisites
for
those
all
right.
And
if
we
look
at
the
yum
module
list
again
this
time,
I'll,
just
look
at
those
postgres
ones,
all
right.
This
one's
enabled
and
installed
all
right,
because
I
said
that
I
wanted
nine
six
all
right
and
then
we
can
just
double
check
that
it's
there.
A
B
So
we
generally
do
not
automatically
enable
software
that
gets
installed
on
rail
right,
because
just
because
you
have
it
installed
doesn't
mean
that
you
want
it
running,
because
if
you
have
it
running
and
it's
a
network
service
and
other
things
that
provides
additional
aspects,
that
you
need
to
account
for
like
ports
and
firewalls
yeah
yeah
exactly
so
this
postgres
version,
that
was
the
client
side
right.
That's
the
client
command
that
you
use
for
connecting
to
the
database
that
reported
back
through
is
9610.,
so
yeah.
If
I
systemd.
A
A
D
A
B
B
B
So
the
the
rule
of
thumb
with
application
streams
is,
you
can
have
any
choice
of
one
that
you
want
just
one,
but
just
one
right.
So
if
we
need
to
have
postgres,
10
or
post
quest
12
installed,
we
need
to
get
rid
of
the
postgres96
okay.
Now
that
that
creates
some
administrative
work
too
right
yeah,
because
I
don't
just
want
to
remove
postgres96
no.
B
B
Postgresql,
actually
right
doesn't
exist
all
right,
and
if
we
look
again
at
what
our
available
postgres
are
right,
this
one
is
available
or
enabled
this
one
is
still
the
default
and
we
still
have
12
out
here
all
right,
but
the
important
thing
is
96
over
here
doesn't
say
that
it's
installed
any
longer
right.
It
has
been
deleted.
B
B
D
B
All
right
so
then
we
can
do
our
yum
module
install
again.
If
we
just
did
postgres
and
didn't
have
any
versioning
information,
it
would
probably
choose
the
right
one,
but
why
take
the
chance
right?
I
like
to
be
explicit
when
I
tell
it
to
do
things
and
now,
when
we
do
a
module
list,
it
should
show
that
module
or
the
version
10
is
installed
installed.
A
A
B
A
Yeah
you
know:
what's
funny,
I
had
one
of
the
companies
I
used
to
work
for
I
had
a.
I
had
a
team
that
had
a
hard
dependency
on
the
latest
version
of
git,
like
they
needed
get
version
like
this
was
way
back
when
it
was
like
one,
nine
something
right
like
and
the
version
that
came
with
rel.
I
think
it
was
six
at
the
time
was
like
one,
oh
something
and
it
was
like
okay,
so
we're
gonna
now
make
our
own
rpms
forget.
This
is
weird
but
okay.
Here
we
go
yeah.
A
B
D
A
B
B
A
B
A
C
B
A
B
A
B
B
A
B
B
Yeah
so
so
be
on
the
lookout
for
some
more
versions
of
things
to
come
in
to
application
streams,
because,
while
in
red
hat
enterprise
linux
world
six
months
is
probably
not
a
very
long
time
in
the
open
source
world.
Six
months
is
a
lot
of
time,
especially
for
things
like
node
or
or
nginx,
where
they're
coming
out
with.
B
B
B
A
Not
quite
the
morally
certain,
but
almost
so,
if
you
like
the
show,
let
us
know
if
you
want
to
see
somebody
on
the
show.
Let
us
know
you
can
always
find
me
at
chrisshort
on
twitter.
Seashort
redhat.com
is
my
email,
as
always
very
thankful
to
have
you
watching
today
and
please
join
us
in
two
weeks
for
the
next
red
hat
enterprise.
Linux
presents,
oh,
you
don't
want
to
do.
A
D
B
So
I'm
I'm
fairly
confident
that
I'll
have
at
least
one
of
the
editors
for
the
enables
this
admin
community
to
come
up.
You
know
we
could
talk
to
them
about
the
naval
system
and
the
practical
that's
going
to
go
along
with
that.
Is
they
often
produce
articles
that
are
like
the
10
best
insert
function
here
right,
10,
best
system,
administration
tools,
10
best
retro
games
on
linux,
so
I
think
I'm
going
to
go
through
and
just
talk
about
those
10
best
system,
admin
tools
they
most
recently
featured
yeah.