►
From YouTube: Unsung Hero Of the Cloud Native Revolution: Container Linux Then And Now - Vincent Batts
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Unsung Hero Of the Cloud Native Revolution: Container Linux Then And Now - Vincent Batts, Microsoft Azure
Speakers: Vincent Batts
Back in 2013, Alex Polvi and Brandon Philips had a vision for a minimal Linux distribution: a kernel, systemd and just enough additional packages to run containers. This “CoreOS” was as much a part of the early cloud native revolution as Docker and Kubernetes, and has spawned or inspired many subsequent container-optimized Linux distributions each with its own unique place in the ecosystem. In this talk, I review what defines a container-optimized Linux and how it changes the experience of running software like Kubernetes compared with a traditional enterprise Linux. I also share a “family tree” landscape of container Linuxes widely used in the community today, compare/contrast their philosophies, and consider some of the current active areas of development and innovation in the space.
A
And
y'all
are
spread
out
all
over
the
room.
That's
fine,
I!
Honestly.
This
is
way
more
people
than
I
was
expecting
at
four
o'clock
on
a
Friday
afternoon
after
a
long
week.
So,
thank
you
all
for
being
here
in
this
talk
the
unsung
hero
of
cloud
native
I'm,
going
to
talk
to
a
little
bit
of
history
in
a
little
bit
of
where
we
are
in
container
linux's
or
linux's
in
general,
Linux,
High,
first
I
know
a
few
of
you
I'm
already
seeing
faces
in
here.
A
So,
first
off
container
Linux,
all
these
nice
little
buzz
words
here
with
a
little
Bumble
piece
everywhere.
What
would
you
say
would
be
a
container
Linux
like?
Actually
what
would
y'all
say?
Container
Linux
means
to
you
thin
minimal.
Whatever
anybody
else
come
on
what
purpose
built
use
case,
specific
builds.
A
A
I
put
Ikea
versus
artisanal
just
because
cattles
versus
pet
kind
of
whatever,
but
you
go
to
you,
go
to
Ikea
and
it's
a
warehouse
of
mass
built
things
and
good
luck,
but
it's
like
mass
produced
and
then
anything
RTS
know
when
you
see
that
this
one
thing
doesn't
quite
look
like
the
other.
You've
now
got
something
tailored,
not
necessarily
different
than
purpose
built,
but
we'll
kind
of
get
into
that
a
little
bit
and
the
atomic
Updates.
This
is.
A
A
Obviously
there's
a
good
place
for
a
well
actually
here
the
what
makes
it
what
you
and
your
tools
are
expecting.
That's
really
what
people
are
coming
down
to
and
that's
really
been
the
most
interesting
part
about
Cloud
native
and
you
know
any
any
distribution
or
otherwise
that
you
have
been
familiar
with
whether
it
was
Solaris
zones,
whether
it's
Windows
otherwise,
like
what
tools.
A
It's
been
a
good
Target
for
that,
but
because
Linux
has
been
so
malleable,
it
has
made
it
wildly
confusing
for
a
lot
of
us
who
are
either
new
to
the
area
or
having
to
support
more
than
one
use
case.
Would
y'all
say
that's
true
or
not
a
couple
of
heads
nodding:
okay,
because
at
some
point
you're
going
to
be
trying
to
figure
out
what?
What
about
the
thing
that
you're
trying
to
deploy
is
having
a
grind
like?
A
Is
it
the
the
kernel?
Wasn't
compiled
quite
the
same?
Is
it
not
have
the
drivers
that
you're
looking
for?
Maybe
it's
that
you're
on
a
rail
kernel,
that's
2632,
but
it
somehow
has
the
kernel
features
that
you
know
weren't
introduced
until
for
something,
and
so
it's
like
well,
it's
still
kind
of
the
Linux
that
I'm
looking
for.
A
But
you
know
it
gets
into
the
use
case
specific
pieces
here
lately
some
of
the
particular
grinds
we
figured
out
how
to
work
around
most
of
these,
like
syscalls
eye
octals,
whether
it's
set
comp,
whether
you
know
why
something
is
not
available
to
you
or
not.
You
kind
of
like
work
around
it
sniffing
around
trying
to
see.
If
it
is
the
kernel
config
how
to
work
around
it.
A
A
Rpm
variant
of
some
kind
or
whatever
and
their
Etsy
stuff
is
in
a
slightly
different
place
and,
like
you
can't
reap
it,
takes
a
lot
of
effort
and
lift
that
you
find
yourself
doing
and
you
feel
like
you're
dying
in
isolation,
because
something
is
different
than
how
the
community
tested
and
it
could
just
be
something
in
Etsy
or
how
the
tools
play
with
it.
It's
inconsistent
early
boot
provisioning.
A
Where
are
you
actually
storing
your
secrets
when
you
do
that
early
provisioning,
like?
Are
you
storing
your
secrets
for
bootstrapping
in
your
Cloud
init,
or
are
they
coming
through
ignition,
like
people
start
figuring
out
like
how?
How
and
where
they're
doing
all
these
things
and
you'll
you'll
find
conversations
you'll
find
conversations
where
people
will
think
this
is
just
a
Linux
problem,
or
this
is
how
you're
interacting
with
it
like
make
it
consistent,
and
we
all
know
it's
intentionally,
inconsistent
like
it.
A
Whatever
your
flavor
is
on
system
d,
whether
you
love
it
or
hate
it?
It
is
an
API
of
like
interacting
with
these
ini-esque
files
like
unit
files,
Landing
them
somewhere
on
the
host
dealing
with
them.
Reconciling
them
system
do,
you
might
know,
might
know
what
to
do
with
them.
But
do
you
have
tools
that
can
parse
those
config
files
to
know
what
the
behavior
of
your
host
is
doing?
Are
you
willing
to
subject
yourself
to
dbus
anybody
in
here
really
willing
to
who
who's
who's
interacted
directly
with
dbos
or
written
code?
To
do
it?
A
Three
people,
there's
probably
what
60
people
in
here
that's
a
that's
higher
than
I
was
expecting,
but
this
is
the
nature
of
there's
a
bias,
because
you're
here
dbus
is
painful
and
it's
like
yeah.
It's
an
API,
but
even
though
even
the
authors
of
it
realize
that
it's
painful,
but
it's
that
standard
and
this
last
one
is
kind
of
ambiguous
the
NVR,
the
name
version
and
release
many
packages.
This
gets
into
like
a
packaging
conversation,
but
like
is
the
Linux
the
packages
that
you're
using?
How
do
you
know
that,
like
bash
forward?
A
Whatever
is
the
one
that
you're
expecting
and
you
can
get
into
all
kinds
of
like
s-bombs?
Where
did
it
come
from?
Who
signed
that
package?
Is
it
the
same?
Build
did
I
just
did
I
just
pretend
to
have
the
same
version
in
VR
so
that
your
scanner
will
pass
I
could
do
that
all
day
but
like
how
did
you
actually
attest
that
whole
chain?
A
How
do
these
things
land?
Did
you
compose
it
statically
test
it
and
then
deploy
it,
or
did
it
just
happen
to
update
on
my
system
in
a
non-deterministic
fashion?
Is
that
your
Linux
experience
it
might
be?
That
might
be
what
you're
expecting,
but
don't
just
expect
that
that's
the
same
for
everybody
else.
A
So
as
a
as
a
real
rudimentary
history
on
this
I
would
venture
to
say
the
first
kind
of
widely
used
read
read-only
Linux
that
people
are
aware
of
would
be
nopics,
canopic,
synopics
it.
It
was
intended
to
be
on
a
CD,
so
they
often
ran
around
700
Megs.
That's
not
necessarily
a
point
as
the
size
on
that
one
was
the
fact
that
it
was
a
read-only
kind
of
like
in
memory
state
or
at
least
able
to
read
and
pick
up
from
the
disk.
A
A
A
Did
anybody
ever
put
their
hands
on
damn
small
Linux
hell,
yeah
love,
damn
small
Linux?
If
you
ever
had
those
like
business
cards,
CDs
I
wish
I
had
a
CD-ROM
job
just
to
still
have
a
business
card.
Cd
DSL
would
fit
on
a
business
card
CD,
so
you
could
like
fit
it
in
your
wallet
and
walk
into
some
place,
but
that
was
2005
even
so
in
and
around
that
same
time
the
Linux
kernel
was
introducing
namespaces.
A
The
first
one
happened
was
just
new
namespace
around
2002
and
then
more
started
happening
around
2006..
So
a
lot
of
these
things
started
coming
together
around
the
same
time,
yeah
it's
on
the
next
slide,
but
through
all
this
time
I
mean
like.
If
you
go
look
at
the
Wikipedia
page
for
Linux
distributions,
it's
fascinating.
A
Unfortunately,
it
hasn't
been
updated
in
probably
a
year
and
a
half,
but
still
you
can
see
how
the
sprawl
of
Linux
distributions
is
has
exploded
over
the
Inception
since
SLS
or
whatever
you
want
to
say,
is
the
beginning,
Debian
or
slackware
or
whatever
it
doesn't
matter,
but
just
constant
amounts
of
sprawl
and
every
single
one
of
those.
This
is
not
to
say
this
is
like
the
Ellipsis.
Like
things
happened
like
everybody's,
been
experimenting
with
lots,
lots
of
different
approaches.
Do
you
thin?
Do
you
make
it
thin?
Do
you
just
Harden
it?
A
Do
you
just
some
produce
something
that
can
build
operating
systems
or
render
a
file
system
really
quickly,
but
there
is
something
about
like
the
kernel
and
like
the
user
space
tooling,
and
how
do
you
play
with
those
things
and
make
consistencies?
That's
probably
single-handedly
the
most
valuable
part
about
in
the
open
source
area
in
general,
but
in
Linux,
distros,
specifically
being
able
to
fork
and
play
with
a
flavor
of
something
until
you
see
that
like
this
is
its
own
use
case
or
it
needs
to
kind
of
roll
back
in.
A
We
learned
a
lesson
and
you
can
let
that
thing
die
and
you
roll
in
some
learnings
over
and
over
and
over.
So
if
you
look
at
any
one
of
those
different
Linux
distributions,
Debian
to
Ubuntu
and
otherwise
the
different
Fedora
one
red
hat
other
ones,
but
that
they
like
learn
along
the
way
and
some
of
them
die
and
some
of
them
merge
into
others.
But
it
needs
to
happen.
It
needs
to
continue
iterating
foreign.
A
A
dot.
Cloud
did
the
demo
with
the
Python
scripts
of
Docker
in
the
summer
and
then
by
the
Fall
Winter.
We
had
the
the
emergence
of
the
Go
version
of
docker
and
that
there
was
kind
of
like
some
cross-pollinations
in
both
directions.
There
lots
of
History
I'm
not
going
to
worry
about
core
OS
container
Linux
was
based
on
chromium,
which
was
adjustment
for
the
Chromebooks,
but
to
this
day
still
the
predecessor,
the
successors
of
that
distro
still
do
the
same
kind
of
a
b
partitions
with
a
variable.
You
know
readable
partition.
A
You
have
hot
side,
cold
side.
You
can
build
in
the
the
true
the
trust
at
boot
time.
If
one
fails
it'll
roll
back
to
the
other
tag,
the
cold
side
is
available
for
update
and
weight.
While
it's
running
the
workloads,
that's
like
how
Chromebooks
to
some
extent
work.
That's
how
koros
container
Linux
works.
That's
how
flat
car
continues
to
work,
whether
you
like
or
hate
Gen
2
is
an
upstream
all
of
them
use
gen2
as
an
upstream
chromium,
container,
Linux
and
flat
car.
A
What's
interesting
about
that.
If
just
in
like
quick
technical
details
is
that
you
can
have
your
Upstream
of
how,
like
the
the
Portage
scripts,
that
you
pull
from,
or
whether
you're
building
up
a
snapshot
so
that
you
can
test
incrementally
and
then
you
have
your
overlays
and
the
Gen
2
overlays
at
least
allow
you
to
have
you.
Can
override
so
you
say:
here's
our
build
of
the
kernel
like
I
know
you
don't
have
to
go
to
Great
Lengths
to
rip
out
the
kernel
that
was
in
the
Upstream.
A
Since
then,
particularly
again,
thinking
about
the
container
Linux
space
there's
been
a
lot
of
iterations.
There
was
the
atomic
project
that
came
out
of
Fedora
and
red
hat
and
since
then
it's
now
Fedora
curl
rest
and
they
have
a
Rel
core
OS
and
a
Cintas
core
S
interesting,
interesting
and
good
developments.
There,
especially
even
though
it
has
the
names
namesake,
the
core
OS
container
Linux
to
the
Fedora
core
OS
was
a
was
not
a
jump
like
there
was.
A
There
was
a
breaking
change
in
there,
so
you
actually
had
to
redo
your
workloads
to
do
that.
It
was
not
despite
the
namesake
a
clean
jump,
but
then
you
have
like
Talos
is
doing
interesting
stuff
and
is
completely
rethinking.
The
entire
problem
does
not
even
have
like
a
bin
sh
in
the
root
file
system.
You
interact
over
like
different
interfaces
with
it.
It's
so
it's
not
like.
Oh
you
do
this
thing,
and
then
you
SSH
into
the
host.
A
If
you're
SSH,
again,
it's
probably
through
a
container
and
it's
not
the
actual
host
like
it's
drastically
rethinking
what
a
Linux
is
but
fascinating
developments
in
that
space,
a
bottle
rocket
coming
out
of
AWS,
fascinating
work,
rethinking
the
whole
K.
You
know
situation
as
well,
K3,
OS,
I,
know.
I
was
told
this
at
some
point,
but
k3s
might
likely
have
been
using
the
Linux
kit
from
behind
the
scenes.
If
how
many
of
you
put
your
hands
on
Linux
kit,
it
originally
came
out
of
Docker
cool
but
like
how
do
you?
How?
A
How
could
you
find
the
tooling
that
just
needs
to
build
the
image
that
you
can
iterate
on?
So
like
you?
Can
build
your
trust
up
to
a
certain
point
and
then,
rather
than
just
consuming,
you
could
actually
build
that
thing
for
yourself
and
say
this
one
package
is
in
the
base
or
whatever
fascinating,
but
then
you
still
find
yourself
having
to
own
some
amount
of
the
same
like
full
testing,
end-to-end
framework
testing
and
ownership
of
it.
A
Rather
than
saying
we
know
it
was
good
on
a
certain
base
and
we
just
needed
to
add
on
top
of
that
open
source
of
micro,
Garden
Linux,
which
a
couple
of
these
I
would
say.
Talos
Talos
is
building
a
lot
from
from
the
from
like.
As
far
as
leveraging
an
upstream,
the
atomics
and
core
OS
of
recent
choruses
are
leveraging
whatever
their
relative
Fedora,
Rel
or
Centos
as
an
upstream
bottle
rocket
Jesse.
A
A
Okay,
so
kind
of
a
two-step
piece
from
those
they
couldn't
hear
was
that
bottle
rocket
being
minimal
in
its
way
is
actually
a
cargo
rust
build
system,
but
some
of
the
packages
it
sources,
those
from
Amazon
Linux,
which
has
Fedora
as
an
upstream
still
so
open
Sousa
Garden
Linux,
is
based
on
Debian
is
an
upstream
anyhow
and
I'm
sure
that
there's
like
again.
This
is
one
of
these
things
that
should
and
is
organically
always
like
people
have
derivations.
A
A
How
easy?
Or
would
you
say
this
as
a
point
of
frustration
of
when
do
you
win
something
in
your
deployment,
particularly
in
the
Linux
space
becomes
artisanal,
like
you
did
your
best
to
put
everything
into
terraform
ansible,
whatever
it
was,
and
then
somebody
sshed
in
and
put
in
an
iptables
rule.
Do
you
know
when
that
happens?.
A
Probably
not
or
they
ran
a
job
or
they
dropped
in
a
unit
file
or
something
like
this
log
directory
keeps
filling
up.
Let's
drop
in
a
systemd
unit
to
like
wipe
it
or
log,
rotate
it
or
something
who
knows
what
and
then
suddenly
it
became
artisanal
like
this
is
almost
an
unanswerable
question.
Most
of
the
time
due
to
the
nature
things,
it's
not
necessarily
a
problem,
it
is
a
problem,
but
it's
the
nature
of
things
and
it's
kind
of
like
embracing
that
piece
of
it.
A
I've
alluded
to
this
piece
already
package
management
where
they
came
from.
Do
you
trust
them?
Are
you
managing
these
packages,
or
are
you
like
leveraging
an
upstream
and
their
trust
chains,
but
even
not
in
that
part
of
packaging?
Is
the
determinism
and
This
Bites
everybody
over
and
over
and
over
as
long
as
your
packages,
whether
they're
Debian
RPM
long
tail
of
other
things?
If
there
is
a
scriptlet
that
runs
in
them
like
a
pre-install
post,
install
pre-install,
post,
uninstall
scriptlet,
you
have
a
non-deterministic
state
period,
you're
you're
going
to
be
fighting
dragons
constantly.
A
This
this
causes
outages
all
the
time,
so
even
just
like
being
able
to
push
out
some
kind
of
immutable,
blob
or
otherwise
and
roll
it
out
is
great,
but
even
with
that,
the
reason
that
so
many
people
use
scriplets
is
because
there
are
like
file
system
apis.
How
do
you
add
a
user
to
the
file
system?
How
do
you
do
a
lot
of
these
different
things
like
you
can't
just
drop
something
into
a
users.d.
A
I
know
systemds
talked
about
this,
but
there's
like
lots
of
these
systems
that
you're
like
no,
no,
then
you
have
to
go
edit
this
file
somewhere.
Do
you
have
to
twiddle
a
file
somewhere?
How
do
you
do
that?
That
is
the
API
of
interacting
with
a
Linux
for
like
it
or
hate
it.
It
is
like
something
we
should
expect
when
you
roll
out
a
security
update
or
not,
who
actually
gets
to
say
that
this
thing
needs
a
reboot.
Is
it
the
maintainer
of
the
kernel?
Is
it
the
maintainer
of
lib
C?
A
Is
it
your
admin?
Is
it
your
CSO
or
whoever
security
person
that
says?
No,
you
took
an
update
of
any
kind.
It's
not
considered
complete
until
you
reboot,
or
that
a
rubid
is
even
needed
or
does
what
ran
the
update?
Does
it
just
get
to
reboot
the
node,
or
do
you
actually
have
to
talk
to
the
cluster
on
top
and
say
a
reboot
is
needed.
Who
gets
to
say
that
that
experience
a
is
not
consistent
and
B.
A
There's
no
API
for
that.
There's!
No
interaction
for
that,
like
that's,
that
is
Mystical,
and
so
most
because
of
that
process,
you
just
say
Ruby
reboots
are
pretty
much
always
needed
and
then
immediately
everybody
knows
you're
going
to
have
customers
or
yourself
say:
Do,
not
reboot.
Until
some
you
know
like
you,
you
reach
some
kind
of
like
higher
thought
or
scheduled
time
or
otherwise,
but,
like
we
all
know
that,
like
people
are
that's
why
people
are
interested
in
k-patch
or
splice
or
whatever
it
is
like.
A
A
A
The
last
couple
of
pieces
here-
I
think
I've
already
alluded
to
this,
but
one
lesson
learned
and
all
the
projects
that
I've
been
involved
in
is,
if
you're
not
allowing
a
a
path
for
your
users
to
stumble
into
the
right
way
of
doing
things
or
to
stumble
into
a
migration
path.
You
have
screwed
up
like
you,
have
legit
messed
up
like
how
do
you
migrate?
A
So
if
you
it's
great
that
you
innovate
it's
great
to
find
drastic
new
ways
of
thinking
about
it,
but
if
your
users
didn't
like
in
an
airplane,
if
they
can't
find
that
bright,
shiny
path
of
stumbling
into
migrations
or
upgrades,
you've
messed
up
like
just,
please
stop
and
rethink
it.
Even
if
you
have
a
great
Visionary
thing
in
the
future,
you
have
to
think
about
how
do
users
get
there
easily,
because
a
lot
of
us
are
dying
in
silence
for
that
Innovation
and
cumulatively
dying
in
silence?
A
And
what's
the
last
one?
Oh
yeah,
everybody
thinking
that
their
approach
is
right,
so
yeah
so
again,
I've
already
kind
of
talked
about
the
deterministic
piece
of
things,
and
this.
This
even
adds
into
this.
You
you
you're
at
kubecon,
you're
hearing
all
about
the
kubernetes
when
you
go
to
deploy
or
as
a
Linux
distro
person,
who's
involved
in
those
things
or
you're
using
them.
When
you
go
to
deploy
a
kubernetes,
it
is
not
just
a
single
thing.
A
It
is
like,
like
config
files
on
yaml
yamls
will
have
implications
on
what's
underneath
in
the
host,
whether
it's
like
runtimes
networking,
Stacks
kernel
modules,
all
kinds
of
things,
and
it's
not
just
like
a
thing.
You
don't
just
deploy
a
kubernetes.
That's
why
there's
vendors
in
there
selling
you
Solutions
on
how
to
make
that
easier
for
you,
but
it
is
not
just
like
a
thing
that
you
deploy
a
kubernetes
so
as
a
Linux
distro.
How
do
you
make
that
feel
as
easy
as
that's
possible?
A
A
So
all
that
to
say
even,
however,
you
render
this
file
system
or
you're
excited
about
the
distro
that
you're
building,
even
if
you
have
ventured
away
from
an
upstream
in
any
aspect
of
a
conversation
where
you
would
say
we're
moving
on
to
functions
or
some
other
higher
level,
part
of
the
stack
and
like
I,
don't
have
to
think
about
those
other
stuff.
The
packages
and
the
upstreams
that
these
distros
are
built
on
are
absolutely
critical.
A
If
at
any
point,
you
think,
like
we've
moved
on
beyond
that,
like
who
actually
still
published
packages
RPMs
and
spec
files,
my
gosh,
they
are
absolutely
critical
and
if
you
don't
think
so,
then
you
are
like
taking
for
granted
thousands
and
hundreds
and
millions
of
person,
hours
that
are
still
working
basically
to
make
your
life
easier
and
all
these
other
tools
you
need,
you
need
them
period,
so
it
is
highly
relevant.
You
need
those
things
the
kernel
and
the
OS
interfaces
that
you
use
absolutely
matter
like.
A
A
I
don't
care
I
just
want
to
not
be
frustrated
like
all
of
us
that
are
having
to
be
like,
oh
well.
This
next
version
of
the
same
thing
is
different
and
I'm
having
to
spend
a
lot
of
hours
on
it.
I
don't
care
like
please
make
me
not
have
to
do
this,
and
so
like.
This
is
the
kind
of
things
of
like
how
could
we
actually
start
talking
together
to
not
have
to
do
that
over
and
over
and
over?
A
So
all
that
to
say-
and
this
is
enough
of
a
rant,
but
the
the
big
takeaway
is
all
of
us
are
feeling
this
collectively
if
you're
new
to
this
space-
and
you
are
thinking
that
you're
going
crazy
because
you're
frustrated
with
it
you're
in
good
company
if
you've
been
in
this
space
for
a
long
time-
and
you
think
why
hasn't
haven't?
Why
haven't
we
solved
this
yet
you're
in
good
company?
A
A
A
Again,
everybody
wants
their
baby
to
win,
but
there
are
obviously
Lessons
Learned
and
there's
things
that
we
could
at
least
take
away
or
make
it
easier
for
the
tools
to
be
more
consistent
to
Bubble
these
things
up,
maybe
it's
to
work
around
the
cubelet
and
that
API
or
to
like
begin
to
iterate.
On
that
we
love.
We
love
the
control
plane
API
of
kubernetes,
but
like
the
cubelet,
everybody
has
something
they
wishes
would
be
improved
there.
How
do
we
talk
to
the
OS?
Is
it
through
existing
csic
and
I
CRI?
Whatever?
A
Is
there
something
new?
How
much
overlap
is
there
between
coupe
the
cubelet
and
system
D
at
the
end
of
the
day?
Again,
most
of
us
don't
care,
we
just
want
it
to
run.
We
want
to
be
able
to
figure
out
what's
going
on
so
this
is
that
conversation
and
honestly,
it's
not
about
saying
we're
going
to
choose
a
winner.
That
is
not.
A
That
is
honestly,
not
the
end
goal
here.
There
are
use
case,
specific
things.
There
are
we
we,
the
people
that
are
involved
in
the
space,
make
decisions
that
have
implications
on
everybody
and
if
those
people
that
are
having
to
suffer
because
of
those
choices,
don't
have
a
voice
to
be
able
to
speak
back
and
say
the
tools
do
or
don't
support
it.
Then
it's
kind
of
a
broken
feedback
loop,
so
this
is
kind
of
a
gap.
A
That's
been
in
the
space
because
the
OS
has
not
mattered
and
a
lot
of
the
container
like
people
have
moved
on
from
that.
But
time
is
at
least
proving
it.
Absolutely
matters,
there's
absolutely
a
place
to
have
a
conversation
around
this
and
a
place
to
have
good
to
maybe
iterate
on
some
some
interfaces
and
make
a
step
forward
like
a
migration
path
so
that
we
can
continue
not
caring
and
just
do
cool
stuff
together.
A
All
right
right,
almost
on
time,
find
me
online
I'm
at
vbats
at
most
places.
Obviously
online
is
great
and
that's
how
most
of
us
live.
I,
love
the
human
connection
so
again
feel
free
to
reach
out
to
me.
Don't
feel
like
you
can't
reach
out
to
me
and
I
look
forward
to
working
together
on
these
projects,
so
cheers.