►
From YouTube: Registries After Dark, Part 2: Distributed Random Access Merkledags - Daniel Mangum & Jason Hall
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Registries After Dark, Part 2: Distributed Random Access Merkledags - Daniel Mangum, Upbound & Jason Hall, Chainguard
Our friend the registry is back and is getting into more mischief than ever. After stretching the OCI image and distribution specifications to implement a registry that acts as a chat server, Dan and Jon have continued to exploit the generality of the spec to support more use cases. In this session, they’ll move beyond what actually happens when you “push” and “pull” or use tags as identifiers. Taking a step back and looking at the landscape of hosted registries offers a unique view of the capabilities of this network of systems we all rely on - capabilities exhibited by other systems we are familiar with: computers. Attendees will join Dan and Jon on a crash course through the history of computer architecture, making stops along the way at Turing machines, load-store architectures, and compiler design, before finding themselves faced with a new definition of DRAM: Distributed Random Access Merkledag.
A
A
I
work
at
upbound
and
I'm
a
maintainer
of
the
crossplane
project
and
unfortunately,
jason
is
unable
to
be
here
this
week,
but
he
worked
with
me
on
preparing
this
and
definitely
had
a
large
part
in
it.
I
think
he
might
be
actually
watching
virtually
so
if
you're
also
watching
virtually
feel
free
to
bug
him
about
anything.
I
get
wrong
in
this
presentation.
A
A
We
specifically
focused
on
the
advantages
of
pulling
by
digest
and
kind
of
the
general
structure
of
how
a
registry
works
in
this
talk,
we're
going
to
be
focusing
a
lot
more
on
how
to
get
things
into
the
registry,
specifically
some
things
that
you
may
not
expect
to
put
into
a
registry,
and
why
or
why
not
different
things
would
be
a
good
idea
to
store
in
a
container
registry,
I'm
going
to
be
moving
pretty
fast.
There's
a
lot
of
content
in
this.
So
stick
with
me
and
I'll.
A
A
So
if
you're
sitting
in
this
room
or
you're
watching
virtually,
you
probably
have
a
laptop
in
your
bag
or
maybe
you're
watching
this
on
a
laptop
and
even
you
know
a
laptop
which
is
a
pretty
similar
machine
between
all
the
ones
we
have
is
very
different
in
the
internals
right,
there's
different
components
that
make
up
the
machine.
You
have
discrete
processors,
you
might
have
a
cpu,
a
gpu.
If
you
have
maybe
an
m1
mac,
you
have
a
number
of
processors
as
well
as
memory
all
integrated
on
the
same
chip.
A
If
you
have
a
pc
like
me,
you
have
more
discrete
components
that
are
talking
to
each
other,
so
even
in
very
similar
machines,
there
are
lots
of
different
heterogeneous
components.
However,
even
at
the
wider
scale
of
types
of
computers,
this
heterogeneity
can
still
be
described
through
a
logically
similar
model
and
typically
the
way
we
do.
That
is
through
five
general
components
here.
In
this
talk,
we're
only
going
to
be
talking
about
the
first
three
of
them.
A
Although
input
and
output
are
obviously
very
critical,
especially
today
in
a
very
networked
world,
we're
going
to
be
focusing
on
controlled
data
path
and
memory
and
we'll
start
off
with
control
and
data
path.
These
are
frequently
referred
to
as
the
components
that
make
up
the
cpu.
So
it's
the
brain
or
the
decision
making
the
thing
that
actually
does
the
work
in
your
computer
and
broadly,
these
two
components
operate
on
two
different
types
of
data
really
instructions
and
the
data
the
instructions
operate
on
data
is
simply
any
information
that
can
be
stored
and
retrieved
right.
A
You
can
put
it
in
memory
somewhere,
you
can
take
it
back
out
and
the
instructions
tell
us
when
we
want
to
take
it
in
and
out
of
memory,
bring
it
into
the
processor
as
well
as
what
we
want
to
do
with
it
right.
How
do
we
transform
it?
How
do
we
perform
operations
on
it
to
understand
how
we
kind
of
got
to
this
place,
where
we
have
logically
similar
compute
components
in
computers?
A
It's
helpful
to
go
back,
and
this
is.
We
could
go
back
way
farther,
but
we'll
stop
around
the
late
40s
early
50s
with
john
von
neumann,
who
I'm
sure
many
of
you
have
likely
heard
of
and
around
that
time
and
for
actually
a
number
of
decades.
After
that,
there
are
computers
that
had
memory
right.
They
could
store
data,
whether
that
was
magnetic
core
memory
or
earlier
than
that,
maybe
a
vacuum
tube
array,
something
like
that.
A
There
was
ability
to
store
memory
and
that
greatly
enhanced
what
we
could
use
computers
for,
however,
programming
a
computer
was
a
different
operation
that
was
done
outside
of
the
actual
execution
of
the
machine.
This
was
typically
done
via
paper
tapes
or
later
punch
cards.
Some
folks
in
this
room
might
actually
have
experience
with
using
these
kind
of
technologies.
A
Looking
at
you
jared
and
what
von
neumann
realized
in
the
late
40s
when
he
was
working
on,
the
edvac,
which
was
the
successor
to
the
eniac
in
early
computer,
was
that
we
could
actually
store
the
instructions
not
on
paper
tape,
not
on
something
that
was
outside
of
the
machine,
but
also
in
memory.
Just
like
our
data,
and
not
only
could
we
store
it
in
memory,
just
like
our
data,
we
could
store
it
in
the
same
memory
as
our
data,
so
the
same
actual
components.
A
A
That
is
the
most
popular
complex
instruction
set.
Essentially,
the
goal
of
a
complex
instruction
set
is
to
give
you
higher
level
operations
that
allow
you
to
achieve
more
functionality
with
a
single
instruction
and
when
instruction
sets
were
first
being
defined.
This
made
a
lot
of
sense
because
programmers
were
actually
writing
assembly
directly
right
so
now
that
we
have
higher
level
languages
that
give
us
these
really
expressive
capabilities.
A
Earlier
on,
we
tried
to
actually
jam
more
of
that
into
the
capabilities
of
the
hardware.
Reduced
instruction
sets
have
also
been
around
for
quite
a
while.
I
mentioned
m1
max
earlier
they're.
Actually,
an
an
arm
isa,
and
so
it
uses
a
reduced
instruction
set
and
it,
as
you
might
expect,
is
kind
of
the
converse
of
that.
So
you
have
less
instructions
that
are
simpler,
easier
to
implement
in
hardware,
but
you
have
to
execute
more
of
them
to
achieve
the
same
kind
of
outcomes
as
you
would
with
a
complex
instruction
set.
A
A
If
you
hold
the
clock
rate,
constant,
the
number
of
instructions
in
a
program
and
the
average
cycle
per
instruction
is
going
to
dictate
how
long
it
takes
us
to
execute
it.
So
sys
and
risk
both
want
to
bring
down
the
cpu
time
and
since
the
two
factors
that
we
can
impact
here
are
instructions
and
cpi.
They
take
different
approaches
to
making
your
program
faster.
A
A
Over
the
last
few
decades,
we've
started
to
see
a
decline
in
moore's
law,
which
is
essentially
the
idea
that
you
can
put
more
transistors
in
a
chip
every
couple
of
years,
thus
getting
performance
for
free.
If
you
will,
you
can
just
buy
a
new
machine
and
it
will
be
faster
since
that
started
to
decline.
We
need
to
be
more
creative
and
create
domain
specific
accelerators
for
a
variety
of
different
computing
domains.
A
A
There's
tiny
embedded
devices
that
are
in
fields
and
agriculture,
and
we
also
have
you
know,
at
the
other
end
of
the
spectrum,
high
performance,
computing
and
data
center
servers,
and
that
sort
of
thing
so
the
way
that
risk
five
wants
to
propose
a
solution
for
this
is
to
have
a
single
instruction
set
architecture,
but
employ
the
common
engineering
principle
of
making
it
modular
and
extensible.
So
it
can
apply
to
all
of
these
a
wide
variety
of
domains
that
we
have
the
way
it
does.
A
A
So
we
have
multiplication
and
division
floating
point
operations,
atomics
memory,
fences,
those
sorts
of
things
are
defined,
but
there's
also
the
ability
to
add
custom
extensions.
So
if
you're
a
vendor-
and
you
make
some
custom
hardware-
you
have
some
some
proprietary
ip-
you
can
build
your
own
compiler
or
you
can
modify
an
existing
one,
and
this
slide
is
a
little
bit
intimidating.
A
But
please
don't
get
up
and
leave
we're
not
going
to
go
through
exactly
what
this
means,
but
I
think
it
conceptually
helps
us
think
about
what
a
risk
instruction
set
and
how
it
differs
from
a
cisc
one.
So
these
are
the
six
core
instruction
formats
in
risk
five,
so
they
are
the
way
that
we
encode
our
instructions
as
data
and
memory,
and
I
want
to
point
out
two
specific
things:
one
if
you
see
an
operand
such
as
the
opcode
or
rd
or
rs1,
or
something
like
that
in
any
instruction
format.
A
It's
always
in
the
same
location
right.
It's
always
the
same
bits
in
this
in
the
instruction
format.
That
makes
it
a
lot
easier
to
decode
these
instructions
and
hardware,
because
you
can
just
generically,
pull
out
these
arguments
and
then
select
the
ones
with
a
multiplexer
that
allows
you
to.
You
know,
based
off
the
op
code,
decide
what
you
want
to
do
with
the
bits
that
are
present
in
the
instruction.
A
The
other
thing:
you'll
notice
is
they're
all
the
same
length.
Every
instruction
and
all
of
those
architectures
is
32
bits,
with
the
exception
of
compressed
extension,
which
shortens
them
to
16
bits,
but
they're
all
the
same
length,
which
is
in
contrast
to
something
like
x86.
If
you've
ever
tried
to
parse
x86
instructions,
it
is
very
upsetting.
I
would
not
recommend
doing
it.
They
have
lots
of
different
lengths
and
they
depend
on
kind
of
unorthodox
things
so
anyway,
just
want
to
take
that
away.
We
don't
have
to
understand
exactly
what's
happening
here.
A
A
So
we
have
our
base
things
like
addition
and
subtraction,
and
variance
for
adding
a
word
which
is
32
bits
versus
a
double
word,
which
is
64
bits.
We
also
have
load
and
store
operations.
Another
important
thing
to
point
out
about
risk
architectures
is:
they
are
also
known
as
load
store.
Architectures.
That
means
that
anytime,
you
access
memory,
that's
a
discrete
operation.
You
don't
actually
operate
on
the
memory
you
access.
In
order
to
be
able
to
actually
modify
data.
You
have
to
first
load
it
into
memory.
A
A
A
I
will
take
all
your
ridicule
afterwards,
but
there
are
two
big
ideas
in
memory,
which
is
a
brash
simplification,
but
the
first
idea
is
that
data
that
was
accessed
recently
is
likely
to
be
accessed
again.
A
good
example
of
this
is
storing
a
value
in
a
variable
and
then
performing
some
operation
on
that
variable,
and
the
second
one
is
that
data
that
lives
close
to
data
that
was
accessed
recently
is
likely
to
be
accessed
soon.
A
The
canonical
example
for
this
is
iterating
through
an
array
or
something
like
that,
so
values
that
live
close
together
in
memory.
We
refer
to
the
first
one
as
temporal
locality,
so
it
has
to
do
with
time
and
the
second
one
spatial
locality
has
to
do
with
how
close
together
things
are.
These
are
two
big
ideas
and
they
drive
our
memory
hierarchy,
which
in
theory,
we'll
show
here
in
a
second,
so
our
memory
hierarchy
once
again
in
a
very
simplified
view,
looks
something
like
this
registers
live
in
the
cpu.
A
A
In
most
modern
computers,
you'll
have
three
levels
of
cache
and
then
we'll
have
ram,
which
is
what
you
configure
when
you
buy
your
laptop
on
whatever
website
you're
getting
it
from
these
are
made
with
different
physical
components.
So,
like
I
said,
the
registers
live
in
the
cpu.
The
cache
is
static,
random
access
memory
and
the
ram
is
dynamic,
random
access
memory.
A
We
unfortunately
do
not
have
time
to
get
into
what
those
individually
mean,
but
the
big
idea
here
is
that,
as
you
move
down
the
memory
hierarchy,
you
can
store
more
things,
but
also,
as
you
move
down
things
get
slower.
What's
not
mentioned
here
is,
as
you
move
down
things
also
get
cheaper,
which
might
make
sense,
given
their
other
attributes.
A
A
We
are
going
to
look
at
a
very
simple
program.
We
are
declaring
three
32-bit
integers.
We
are
assigning
values
to
two
of
them.
We
are
then
calculating
a
sum,
and
we
are
returning
that
sum.
This
is
a
weird
program.
I
know
you
probably
don't
want
to
return
a
non-zero
exit
code
from
main
here,
but
this
is
just
to
illustrate
some
of
the
instructions
that
are
going
to
be
generated.
A
So
let's
go
ahead
and
compile
this
for
risk
5
here.
So
I'm
going
to
use
my
risk
5
cross
compiler
and
I'm
going
to
specify
that
we
want
to
use
a
subset
of
the
generic
standard,
extensions,
we're
just
going
to
use
integer
and
double
precision
floating
point,
so
I
can
say
that
with
rv64
id
and
we're
going
to
compile,
main.c
and
we'll
call
the
output
cubecon
all
right,
so
we
have
cubecon
there
and
let's
look
at
what
that
actually
looks
like
in
our
main
function:
you'll
notice
there
that
I
didn't
compile
with
any
optimization.
A
A
So
let's
take
a
look
at
this,
we'll
disassemble
the
instructions
and
we
want
to
remove
any
pseudo
instructions
and
actually
just
look
at
exactly
what
it
gives
us
and
I'm
going
to
search
for
our
main
symbol
here
all
right.
So
this
is
the
body
of
our
main
function,
the
first
three
instructions.
There
are
what's
known
as
a
function,
prologue.
A
What
we're
doing
there
is
setting
up
our
stack
frame
so
we're
first
moving
our
stack
pointer
down
32
bytes,
the
the
stack
goes
downwards
in
wrist
five,
we're
then
taking
s0,
which
is
the
frame
pointer
register,
and
we
are
storing
that
on
our
stack
at
the
top
of
our
stack.
That
frame
pointer
is
actually
from
the
calling
method
from
crt0.
A
So
we're
basically
just
saying
we're
going
to
save
this
and
reinstate
that
for
you
when
we
return
and
then
we're
going
to
set
our
own
frame
pointer
to
the
top
of
the
stack
right.
So
our
our
frame
pointer
is
now
up
here.
32
bytes
stack
pointer.
This
is
what
we're
going
to
use
for
our
stack
for
the
remainder
of
our
procedure.
Here
then
we're
going
to
go
through
a
variety
of
operations,
you're
going
to
see
we're
going
to
load
two
into
one
of
our
argument.
A
Registers
we're
going
to
store
that
on
the
stack
right
below
where
we
stored
that
frame
pointer,
then
we're
going
to
store
the
other
argument
and
then
we're
going
to
load
them
back
in
add
them
together
return.
The
sum
then,
there's
some
function
epilogue
there
at
the
end
as
well.
So,
like
I
said,
there's
no
need
for
us
to
be
putting
things
on
the
stack
in
this
case
right.
We
could
keep
them
all
in
registers,
which
would
be
optimal,
but
because
I
compiled
with
no
optimization,
so
we
can
see
more
instructions.
A
This
is
what
it
looks
like
for
this
presentation.
I
actually
wrote
a
risk
five
emulator
in
rust,
because
I
wanted
us
to
be
able
to
see
exactly
what
was
happening
and
lots
of
emulators.
Don't
actually
give
you
really
good
insight
into
instructions
and
just
kind
of
assume
you
know
what's
going
on,
which
I
don't
like
very
much
so
hopefully
this
one
will
do
a
bit
of
a
better
job
so
with
each
instruction
that
we
get
it's
going
to
describe
what
the
actual
name
of
the
instruction
is
as
well
as
logically
what's
happening
here.
A
A
This
is
kind
of
hard
to
see
on
the
screen,
but
you'll
see
that
we
have
a
frame
pointer
loaded
in
there
at
ox80010,
and
we
have
our
stack
pointer
set
to
eight
zero
zero,
zero
zero,
so
we're
gonna
subtract
32
from
that
e
is
execute
it's
gonna.
Let
us
know
what
happened
now,
we're
going
to
move
to
the
next
instruction
and
this
one
we're
going
to
store
that
frame
pointer
on
our
stack.
A
A
So
I
am
going
to
stop
doing
that
for
just
a
moment,
because
I
want
to
show
you
one
other
thing.
Let
me
make
this
one
a
little
bit
bigger
and
let's
see
what
we
have
here.
Well,
I
don't
know
what
that
play
me
thing
is:
did
y'all
see
that
earlier
that
looks
like
it's
new?
Let's
take
a
look
at
what
that
is,
I'm
a
little
concerned.
B
A
B
I'm
sorry,
sorry
to
interrupt
everyone
hi,
I'm
jason
from
the
talk
dan.
I'm
sorry
to
interrupt
this.
This
is
registries
after
dark
right
right,
I'm
in
am
I
in
the
right.
Am
I
in
the
right
room
thanks
for
the
thanks
for
the
super
interesting,
deep
dive
in
how
computers
work
and
everything,
but
I
can't
help
but
notice.
We
haven't
mentioned
oci
registries
yet,
and
I
kind
of
thought
that
was
the
point
of
the
talk.
So
if
it's
all
right,
I
think
I'm
gonna.
B
I
think
I'm
gonna
commandeer
take
over
for
a
little
bit
and
try
to
get
us
back
on
topic
so
how's
this
related
to
ocr
registries.
Well,
I'm
glad
you
asked
there
is
an
interesting
thing
you
mentioned,
you
said.
Storing
and
retrieving
data
is
the
foundation
of
all
computing.
I
thought
that
was
a
good,
maybe
a
good
segue,
into
oci
registries.
After
all,
oci
registries,
let
you
store
and
retrieve
data
you
can.
You
can
put
a
blob,
you
can
get
a
blob.
Everything
works
out.
B
Clients
if
you
squint
clients,
even
do
a
form
of
caching
with
a
temporal
locality.
If
you
pull
a
blob
and
then
pull
it
again,
a
lot
of
clients
will
just
say:
hey.
I
have
a
copy
already
here
on
desktop
you
don't
need
to
you,
don't
need
to
fetch
it
again,
so
that's
kind
of
like
caching,
if
you
think
about
it,
you
may
say,
but
oci
registries
are
just
for
container
images
right.
Well,
you
typically,
you
know
historically
sure,
but
it
doesn't
have
to
be
in
a
lot
of
cases.
B
Registries,
don't
care
what
your
blobs
are.
If
you,
if
you
put
anything
you
want
in
there,
they'll
allow
it
and
in
fact,
in
a
lot
of
cases,
registries,
don't
even
know
what
your
clubs
are
they're
just
going
to
accept
them
and
store
them
for
you,
so
yeah
you
can
put
anything
in
there.
Why
would
you
want
to
do
that?
Well,
you
know.
Content
addressable
storage
is
is
a
cool
concept.
B
B
B
So,
like
my
friend
drake
here
would
say
you
know
you
can
you
can
keep
your
s3
and
your
vendor
lock
in
it's
oci
for
me
every
single
day
and
we're
not
even
alone
storing
a
lot
of
other
stuff
in
oci
registries.
There's
a
lot
of
projects
these
days
that
are
storing
ammo
of
all
kinds
in
container
registries.
B
Tecton
tasks
can
be
pulled
from
registries,
cross,
plane
packages,
helm,
charts,
tons
and
tons
and
tons
of
other
things.
You
can
even
sign
sign
contents
and
attach
s-bombs
and
attestations
to
those
things
using
cosine
and
tons
of
wasm
thingies.
I
didn't
go
to
wasm
day,
but
I
hear
wasm
is
all
over
oci
registries.
These
days,
there's
a
whole
ecosystem
of
stuff
around
oci
registries.
Anything
any
thingy
in
an
oci
registry
can
be
signed.
You
can
say
I'm
jason
and
I
approve
this
thingy
and
here's
a
signature
that
proves
that.
B
B
A
Well,
I
didn't
think
that
jason
was
gonna
join
us,
but
it
turns
out
that
he
seemed
to
have
dropped
a
little
video
for
us
and
he
also
kind
of
spoiled
what
I
was
doing
so
I'm
gonna
have
to
talk
to
him
after
this,
but
jason
is
in
fact
right
when
we
were
storing
to
a
memory
there.
That
was
actually
writing
to
an
oci
registry.
A
In
this
case
it
was
docker
hub,
and
so,
let's
kind
of
step
through,
what's
really
going
on
here,
so
most
risk
architectures
follow
some
variation
or
some
evolution
of
this
pipeline
here
starts
off
with
fetching
the
instruction.
Then
you
need
to
decode
it
figure
out
what
we
need
to
do.
You
need
to
execute
it
and
then
potentially
access
memory
if
it's
a
loader,
store
operation
or
write
something
back
to
a
register.
A
A
A
So
this
is
an
oci
manifest
here
for
an
image
and
you'll
see
that
our
single
layer
is
only
eight
bytes,
because
we
are
storing
a
64-bit
double
word
or
an
eight
byte
double
word
and
we
have
the
hash
there.
You
also
see
that
we
told
a
really
big
lie
and
said
this
is
a
file
system,
image
layer
and
it's
a
tarball.
A
I
don't
know
many
eight
byte
tarballs,
but
that's
what
we
said
it
was
so,
let's
actually
see
if
that's
really
what
happened
so
just
before,
while
jason
was
talking,
I
went
ahead
and
I
posted
a
tweet
that
tells
how
you
can
follow
along
with
this
and
actually
pull
these
images.
This
is
a
public
repository,
so
you're
welcome
to
do
the
same
that
I
do
here,
but
the
link
to
the
actual
repository
is
this
one?
If
you
want
to
look
at
the
tags
and
if
you
want
to
pull
down
kceu.
A
You
can
pick
any
of
the
tags
there
and
those
will
be
memory
addresses
that
we
actually
wrote
to,
and
so
that's
what
I'm
going
to
do
now,
let's
make
a
new
directory,
we'll
call
it
image,
surgery
and
we'll
go
in
all
right.
We
don't
have
anything
here,
I'm
going
to
use
crane.
You
may
have
some
trouble
with
docker
if
you're
pulling
down
with
it,
because
docker
is
not
going
to
like
that.
We
lied
about
that
tarble,
but
crane
is
a
much
more
accommodating
force
here.
So
what
did
I
say?
A
A
All
right
and
it
looks
like
we
have
what
we
would
expect
from
an
image
we
have
our
manifest
here
we
have
a
gzip
tarball
layer
and
we
also
have
our
config.
In
this
case.
Our
config
is
not
very
useful.
I
just
stuck
rimu
in
there,
which
is
the
name
of
the
emulator,
so
that's
going
to
make
things
unhappy,
but
if
we
tried
to
look
at
our
gzip
tarball,
that
is
not
a
gzip
tarball
at
all.
It's
just
a
data
file.
A
So
let's
see
what
data
is
in
there,
so
we're
going
to
pipe
that
to
a
hex
dump
and
I'm
going
to
say
this
is
little
indian
and
we
want
to
group
by
8
bytes
here
and
what
we're
going
to
see
is
we
have
8
0
zero
one
zero
and
we
were
wanting
to
store
our
frame
pointer
at
this
address.
Let's
see
if
that
is
our
frame
pointer,
yep,
it
does
look
like
that's
our
frame
pointer
and
I
think
we
performed
some
other
operations
as
well.
A
Let's
see
if
our
tags
are
present
here,
yep,
it
looks
like
we
have
a
few
other
memory
addresses
as
well,
and
if
we
wanted
to
go
through
and
continue
executing
this
program,
we
could
continue
to
have
as
much
fun
as
we've
been
having
this
whole
time
and
continue
to
store
new
things
in
our
registry.
So
we
should
see
a
new
tag
pop
up
here.
A
A
One
of
the
things
we
want
to
illustrate
is
everything
is
just
bits
right
and
it's
just
data
on
a
wire
and
frequently
we
think
of
things
in
different
contexts
right
because
it's
useful
for
structuring
it
in
our
brain,
but
in
reality
we're
just
passing
information
around
and
jason
mentioned
a
few
different
applications
of
putting
non-image
things
in
a
registry.
I
work
on
crossplane.
We
do
that
quite
a
lot
and
are
big
fans
of
doing
it.
A
So
I
hope
you
know
this
kind
of
makes
you
think
a
little
bit
about
what
things
might
be
good
to
put
in
a
registry
that
you
wouldn't
normally
think
of,
there's
also
distribution.
It
allowed
for
this
cool
demo,
where
y'all
could
pull
it
down
and
look
at
that
and
go
see
it
on
docker
hub.
If
you
wanted
to,
it,
also
was
free.
For
me
at
least,
I
was
able
to
push
to
docker
hub,
and
hopefully
we
didn't
abuse
their
rate
limit
too
much,
but
they're
available
and
relatively
cheap.
A
So
it
didn't
take
a
lot
of
effort.
I
didn't
even
create
that
repository
before
it.
Just
push
created,
so
lots
of
cool
things
there,
but
we
obviously
don't
want
to
do
this
right.
This
doesn't
make
any
sense.
Why
doesn't
it
make
any
sense?
Well
we're
trying
to
emulate
a
program
and
the
network
is
very
slow.
A
A
The
subtitle
of
this
talk
was
distributed.
Random
access,
merkle,
dags,
a
merkle
dag,
is
essentially
a
directed
acyclic
graph,
but
one
where
the
nodes
are
a
hash
of
their
leaf
labels,
which
are
hash
of
their
content.
In
this
case,
we're
not
getting
a
lot
of
benefits
from
that,
because
we
have
very
tiny
payloads
and
we're
not
really.
You
know
reusing
them
very
much.
That
being
said
in
theory,
you
would
be
able
to
reuse
the
same
layer
if
you
push
the
same
memory
address,
but
in
general
not
a
great
use
case
of
it.
A
So
what
I
hope
you
have
kind
of
walking
away
from
this,
because
I
know
I'm
probably
cutting
into
q
a
here
is
that
there
are
some
great
applications.
Jason
listed
a
few
of
them
and
there
is
a
good
reason
to
use
the
registry
for
some
things,
but
there's
also
good
reason
not
to
so
so
be
judicious
in
your
usage
and
with
that
I'm
open
to
any
thoughts,
comments
or
questions
and
expressions
of
utter
disgust.
A
A
This
is
about
five
percent
of
the
total
content
that
was
in
it
and
we've
been
systematically
cutting
it
down,
which
I
think
it
was
still
kind
of
a
fire
hose,
but
would
love
to
talk
to
anyone
who
found
this
interesting
or
wants
to
talk
more
about
risk,
five
or
container
registries,
or
anything
like
that.
But
once
again
thank
you
for
coming
and
I
hope
you'll
have
a
great
rest
of
your
kubecon.