►
Description
In this lecture Luc will talk to us about bringing Nix’s value to the messy world of deployment
Special thanks to the NLnet Foundation, the European Commission, the NixOS Foundation, and Tweag for making this event a reality!
The continued discussion for the lecture series is happening over here:
https://matrix.to/#/#son2022-lectures:matrix.org
More information about the Summer of Nix can be found on the website:
https://summer.nixos.org
A
Hello,
everyone
I
hope
I
am
my.
My
apologies
in
my
friends.
My
microphone
isn't
as
great
as
a
part
of
me
yesterday.
So
I
won't
take
up
much
more
of
your
time
than
needed
and
put
this
upon
your
ears.
So
you
know
why
I'm
here
I'm
here
to
thank
the
people
that
made
this
happen.
The
participants,
the
summer
of
Nyx,
is
slowly
literally
coming
to
a
complete
end.
So
thank
you
again
for
participating.
Thank
you
as
well.
B
B
So
it's
a
little
bit
about
me.
I've
been
a
huge
fan
of
Nyx
for
about
five
years
now.
I
would
say
mostly
mostly
as
an
admirer
of
Nyx
from
afar,
but
it's
really
been
in
the
last
two
years
that
that
my
interest
has
grown
into
into
some
more
some
more
substantial
and
direct
engagement,
particularly
in
some
areas
that
that
interest
me
like,
like
developer
experience.
B
B
The
the
goals
of
this
talk
are
are
I
would
say,
are
very
modest,
so
I
I
really
just
want
to
get
you
thinking
about
how
you
can
potentially
bring
NYX
and
all
of
its
its
features
that
you
know
and
love
into
the
real
world.
So
that
is
into
real
teams
and
organizations
and
deployment
pipelines,
shipping
software
to
real
end
users.
B
Now,
before
I
start,
I
want
to
say
a
little
bit
about
the
devops
side
of
things.
So
I
would
say
that
that
Ops,
broadly
speaking
or
short,
for
operations,
is
concerned
with
what
I
call
the
problem
of
realization.
So
you
have
some
kind
of
software
artifact
like
a
web
service
or
something
like
that,
and
you
need
to
make
that
that
artifact
produce
real
value
for
end
users.
B
World
development
and
Ops
were
generally
treated
like
separate
concerns,
so
you
have
developers
creating
artifacts,
and
you
have
Ops
folks
trying
to
realize
value
and-
and
you
know
typically,
the
way
that
this
worked
is
that
you
would
is
that
is
that
operations
was
heavily
procedural.
So
you
would
write
these
deployment
and
management
scripts
to
perform
actions.
B
You
you've
provided
kind
of
kind
of
a
lot
like
like
Nix
and
build
logic,
I
would
say,
and
I
I
think
the
reason
that
that
I
I,
that
this
talk
is
about
devops
and
not
Ops,
is
that
I
I
do
think
that
it's
that
nowadays,
it's
safe
to
say
that
the
industry
is
moving
pretty
firmly
in
the
direction
of
devops
and
and
as
we'll
see
because
devops
has
this.
This
kind
of
declarative
Focus,
like
NYX.
It
can
pair
really
really
nicely
with
Nix
and
produce
some
really
powerful
results.
B
Two
two
great
examples
of
of
declarative
devops
platforms,
both
of
which
I'll
use
in
my
demo
today
are
terraform
and
kubernetes,
so
so
terraform
I
I
suspect
these
are
probably
familiar
to
you
all.
But
I
do
want
to
give
a
brief
overview.
So
terraform
is
a
so-called
infrastructure
as
code
tool
that
enables
you
to
write
to
write,
manifests
in
a
language
called
called
HCL.
B
It
manifests
that
that
describe
the
infrastructure
that
you
want
to
build
now,
so
so
so,
just
like
in
Nix.
You
declare
the
state
of
things
that
you
want
and
then
terraform
itself
performs
the
the
kind
of
messy
Dirty
Work
of
managing
that
infrastructure,
so
creating
it
updating
it
deleting
it
and
so
on.
B
Another
system
that
falls
into
this
category
is
is
kubernetes,
which
is
also
quite
well
known,
quite
ubiquitous
these
days,
but
in
case
you're
not
familiar.
Kubernetes
is
a
container
orchestration
platform
that
uses
a
kind
of
similar
declarative
logic
as
terraform.
So
it
enables
you
to
describe
what
you
want
the
state
of
your
cluster
to
look
like
so
the
services
you
want
to
run
the
the
disk
volumes
you
want
to
make
available
and
so
on,
and
then
leaves
the
platform
itself
to
reconcile
the
current
state
of
things
with
your
desired
state.
B
Now,
after
a
summer's
worth
of
Nick's
talks,
Nick's,
maybe
doesn't
need
too
much
more
introduction,
but
I
do
want
to
talk
about
where
it
fits
in
here.
So
so
the
wonderful
thing
about
NYX
is
that
it
provides
us
with
this
little
zone
of
of
Purity
inside
inside
an
industry
that
I
mean,
let's
face
it
often
doesn't
value
Purity.
The
way
that
we
would
like
so
so
with
NYX,
we
get
things
like
like
fully.
Reproducible
builds
that
we
can
trust.
B
B
Now
now,
both
of
these
tools,
mix,
Ops
and
deploy
RS
are
are
super
interesting
and
I.
Do
encourage
you
to
check
them
out
on
your
own,
but
I'm
not
going
to
be
featuring
them
in
my
in
my
example
demo
today,
simply
because
I
I
wanted
to
focus
on
tools
that
that
aren't
NYX
based
but
do
have
much
broader
industry
adoption
and
that
I
think
you're
much
more
likely
to
to
encounter
out
there
in
the
real
world
so
without
further
Ado.
B
It's
it's
demo
time,
I've
put
something
together,
so
I've
I've
shared
the
the
link
there
to
the
to
the
repo
that
has
all
of
the
all
of
the
the
assets
necessary
for
the
demo.
So
you
know,
do
feel
free
to
navigate
and
have
a
look
and
I've
put
something
together
here.
That
I
think
is
it's
pretty
simple,
but
I
I
do
hope
that
it
proves
to
be
in
to
be
instructive
for
for
the
summer
of
Nick's
folks.
So
one
thing
I
do
need
to
say
in
advance.
B
B
So
first
of
all,
we've
already
had
some
really
really
great
NYX
OS
talks
this
this
summer
and
I
I
highly
encourage
you
to
check
those
out
in
case
you
haven't
like
really
really
some
phenomenal
stuff
and
second
because
I
I,
think
part
of
the
goal
of
this
talk
is
to
show
you
that
NYX
can
make
a
big
impact,
even
inside
of
organizations
that
haven't
fully
bought
into
using
Nick's
end
to
end
I.
Think
I
think
it's
still
in
in
the
current
state
of
things
in
Nicks.
B
Like
I
said
on
the
infrastructure
side,
I
have
stood
up
a
kubernetes
cluster
on
on
digitalocean,
using
a
super
simple,
a
declarative,
terraform
configuration
it
just
it
all
fits
in
one
file.
Super
easy
I'm
not
actually
go
I'm,
not
actually
going
to
deploy
the
kubernetes
cluster
in
this
talk
today.
So
so
I
I
can
leave
that
as
an
exercise
for
the
reader
on
the
the
software
artifact
site.
So
remember
that
Ops
is
the
art
of
of
taking
an
artifact
and
and
realizing
value
in
the
world.
B
Our
software
artifact
is
going
to
be
a
simple
web
service
written
in
go.
Let
me
get
back
to
my
screen.
Really
quick.
Oh
there
we
go,
there's
a
a
simple
web
service
written
and
go,
and
it's
really
just
like
a
really
silly
to
do
app
with
like
one
endpoint.
That
just
does
one
thing
and
like
delivers
some
some
some
some
pre-coded
hard-coded
Json.
It's
really
nothing
interesting.
But
but
of
course
that's
okay,
because
we're
not
here
to
feature
go
we're
here
to
feature
Nicks
and
and
terraform
and
a
lot
of
other
cool
stuff.
B
So
what
we're
going
to
do
in
in
this
demo
is
we're
going
to
use
NYX
to
build
that
go
code
into
a
nice
lean,
Docker
container
that
will
then
Deploy
on
kubernetes,
but
but
because
it's
a
Docker,
because
it's
a
it's
an
oci
compliant
Docker
container.
We
could
theoretically
deploy
It
On
Any
number
of
of
other
container
orchestration
platforms.
B
Be
it
be
it
no
matter
something
else,
I'm
just
using
I'm
just
using
kubernetes
here,
because
because
it's
it's
so
widely
known
and
finally,
oh
and
finally,
the
actual
deployment
pipeline
itself
is
going
to
be
fully
automated.
So
it's,
basically
all
that
we're
going
to
need
to
do
is
run
git
push
and
CI
is
going
to
handle
the
rest.
B
So
so
we're
going
to
have
NYX
build
an
artifact
we're
going
to
have
a
nice
automated
pipeline
that
that
updates
it
in
kubernetes
and
it's
going
to
be
super
simple
and
you
know
quick
prayer
to
the
demo
Gods.
Let's
hope
that
it
goes
well
so
oops,
let's
not
jump
to
the
wrap
up
just
yet.
Let
me
come
back
and
I'm
going
to
switch
screens
really
quick
foreign.
B
Let's
go
to
okay.
There
we
go
so
hopefully
let
me
double
check
here.
Hopefully
you
all
can
see
that
okay,
I'm
gonna
make
sure
that
the
the
text
is
large
enough
I'm,
hoping
that
that's
okay
for
everybody,
okay,
so
let's
I'm
gonna
start
at
the
top
here,
so
I'm
going
to
start
with,
with
the
logic
that
I
used
to
actually
stand
up.
B
This
kubernetes
cluster
in
in
digitalocean,
which
is
a
very
nice
which
is
a
very
nice
set
of
cloud
services,
so
so
here
at
the
top
and
I'm
just
gonna
kind
of
Breeze
through
some
of
these
files.
I
do
certainly
encourage
you
to
to
to
dig
into
the
code
yourself
a
little
bit,
but
obviously
because
of
time
constraints.
I
I
can't
I.
B
I
also
want
to
stand
up
a
kubernetes
cluster
there,
based
on
you
know,
with
certain
with
certain
security
creds
like
a
like
an
access
token
and
a
cluster
CA
certificate.
Here
we
declare
some
some
variables
for
things
that
that
we
want
to
to
maybe
modify
or
change
inside
of
our
inside
of
our
infrastructure.
B
Here,
I
declare
a
the
specific
kubernetes
version
that
I
want
I,
just
kind
of
arbitrarily
chose
1.2.3
here
are
a
couple
of
outputs
that
we
can
get
from
from
terraform
if
we
need
to,
if
we
forget
like
what
our
cluster
is
called
and
a
couple
other
things
and
finally,
most
importantly,
we
have
this
this
resource,
and
this
is
kind
of
the
core
construct
in
terraform.
We
have
this
digitalocean
kubernetes
cluster,
so
so
we
give
it
a
name.
We
deploy
it
to
a
specific
region.
B
We
use
a
specific
kubernetes
version
and
then
we
have
this
node
pool,
which
is
kind
of
a
it's
like
a
sub
resource
that
defines
the
actual
machines
that
our
that
our
kubernetes
cluster
is
going
to
run
on.
So
we
have
a
certain
number
of
so
we
have
a
specific
type
of
worker
size,
and
then
we
also
have
a
specific
number
of
nodes
that
we
want
to
run
on
now.
If
we
wanted
to
to
deploy
this
on
our
own
today,
we
could
run
this.
B
Terraform
apply,
command
and
and
terraform
would
do
the
work
of
actually
of
actually
talking
with
digitalocean
setting
up
a
kubernetes
cluster
and
then
making
sure
that
that
cluster
is
configured
correctly
but,
as
I
said,
we're
not
going
to
cover
that
today,
it's
a
little
bit
outside
of
scope,
then
over
here
we
have
this.
This
really
nice
construct
in
in
terraform,
where
you
can
use
a
variable
file.
So
so
here
we'll
support
the
supply,
our
our
configuration
with
some
variables,
so
we're
going
to
call
our
cluster
just
real
world
devops
with
next.
B
B
So
so
here
we
have
this
this
to
do
type
where
each
to
do
has
an
ID
and
a
task
and
whether
or
not
the
idea
is
done
and
to
start
with
so
we're
going
to
say
that
actually
yeah
so
so
to
start
with.
No
sorry
forget
this
part:
I
messed
this
up
a
little
bit,
but
we
can
just
actually
I'm
going
to
do
some
copying
and
pasting
really
quick
and
call
a
brief
audible,
because
I
want
this
to
be
the
initial
state
of
our
of
our
web
service.
B
So
basically,
what
we
want
to
do
is
we
want
to
run
this
service
and
we
want
to
be
able
to
to
curl
this.
This
slash
to
Do's
endpoint,
and
it's
going
to
give
us
this
list
of
to-do's
which,
which
you
know
to
start
with,
is
just
going
to
have
this
one
thing
which
is
to
maybe
we
can
change
this.
You
know
Venture
forth
and
continue
exploring
nics
and
and
devops,
and
so
this
is
the
so.
B
This
is
the
the
service
that
we
want
to
deploy
super
simple
stuff
and
go
and
finally
oops.
Let's
click
save
and
now
because
this
is
a
summer
of
Nick's
talk.
Let's
have
a
look
at
some
actual
Nix
code,
so
I've
defined
everything
in
a
pretty
straightforward
flake.
So
I
I
have
a
couple
of
a
couple
inputs
next
packages,
of
course
flight
utils,
because
I
want
to
do
some
system.
B
Configuration
on
the
Nix
side
is
pretty
straightforward,
so
I
I
am
going
to
apply
just
just
one
next
package
as
overlay
that
specifies
that
that
I
want
to
use
Go
version.
19.
I
could
have
used
17
or
18.
That
would
have
been
fine,
but
of
course
I
like
to
be.
You
know,
declarative
about
these
things
and
you
might
as
well
declare
the
Go
version.
B
So
here
we
have.
We
finally
have
our
our
our
our
outputs
for
our
flake.
So
so
we
have
basically
two
packages
here,
so
so
this
for
the
the
first
package
right
here,
which
I'm
just
calling
to
Do's
I'm
using
the
super
standard
bill,
go
build,
go
module
function
from
NYX
packages,
you
know
super
straightforward,
stuff
and
Nick,
so
we're
just
going
to
call
it
to
Do's
we're
going
to
specify
the
current
directory
as
the
source
and
we're
going
to
build.
B
This
sub
package
called
command,
slash
to
Do's,
which,
which
you
see
over
here,
that's
where,
where
my
my
main
dot
go,
is
is
held
and
then,
as
per
usual
Nicks
when
you're
dealing
with
with
with
systems
of
vendor
dependencies
I'm
supplying
a
vendor
Shaw
as
well.
So
this
is
going
to
enable
us
to
to
use
NYX
to
to
build
a
nice,
go
executable
from
our
go
sources
now
this
is
where
it
gets.
B
It
gets
a
little
bit
more
interesting
from
a
devops
perspective,
we're
also
going
to
use
NYX
to
build
a
docker
container
here
now
now
this
is
kind
of
a
it's
definitely
not
a
hidden
feature
of
Nyx,
but
I
feel
like
it's.
It's
a
bit,
undersung
I,
think
I.
Think
a
lot
of
people,
even
people
who
are
interested
in
Nicks,
aren't,
aren't
fully
aware
that
you
can
use
next
to
build
Docker
containers,
but
I
mean
personally
I.
B
B
So
it
and
I
think
that,
when
your
caching
story
is
better,
that
means
that,
when
you're
sending
images
over
the
wire
that
you're
sending
them
in
much
smaller
bits,
so
you're
sending
them
as
much
as
you
know.
You're
sending
smaller
tar
balls
across
the
wire
and
then
assembling
them,
which
tends
to
be
to
be
a
much
better
option
than
than
than
shipping.
You
know
big
bulky,
monolithic
images,
so
the
actual
logic
inside
the
function
is
is
again
it's
pretty
straightforward
next
stuff.
B
So
we
give
so
we
give
our
our
our
image
and
name
so
I'm,
just
calling
it
Loop
Perkins
to
Do's,
that's
my
Docker
Hub
account
and
here
in
the
config.
Now
this
is
where,
where
we
see
some
of
the
some
of
the
Nick's
magic,
it
works
so
for
our
our
the
command
that
you
run
when
you
Docker
run
the
container.
B
B
Okay,
so
that's
so
that's
the
next
logic
at
work
and
and
basically
this
is
going
to
enable
us
to
build
this
image
by
just
running
NYX,
build
dot
for
the
current
directory
hash
Docker
for
this
specific
package,
so
super
easy
time
is
beginning
to
to
run
a
bit
short,
so
I'm,
gonna,
I'm,
gonna
jump
really
quickly
to
to
the
kubernetes
definition
here.
So
basically,
what
we
want
to
do
with
our
web
service
in
kubernetes
is
we
want
to
run
it
as
what's
called
a
deployment.
B
We
specify
three
different
replicas,
because
we
want
to
run
three
separate
nodes
and
to
start
with,
when
we
first
run
this
deployment,
it's
going
to
run
this
this
this
kind
of
like
hello,
world
image
that
that's
just
kind
of
a
seed
image,
but
we're
going
to
update
that
in
our
pipeline.
So
let's
check
really
quick.
B
So
I'm
going
to
run,
make
port
forward
and
we
can
go
over
here
and
we
kind
of
I'm
using
HD
Pi.
But
but
we
we
curl
the
service,
and
we
see
just
this
hello
world
thing.
We
don't
see
the
to-do
service
yet,
but
we
are
about
to
change
that
and
we're
going
to
look
at
the
CI
pipeline.
That
is
going
to
do
that
work.
B
So
here
I'm
going
to
pull
up
so
I'm,
just
using
GitHub
actions
for
CI,
because
I
I
know
it
well
we're
going
to
run
our
deploy
job
on
on
Ubuntu
latest.
So
that's
going
to
get
us
our
x86
64
Linux
machine
and
then,
as
per
usual
in
CI,
we're
going
to
run
git
checkout
to
get
our
code
we're
going
to
install
NYX
on
the
machine
and
with
with
flakes
automatically
enabled.
B
So
it's
going
to
be
able
to
use
our
flake.nix
logic
no
problem
and
then
what
we're
going
to
do
is
we're
going
to
actually
use
NYX
to
build
our
Docker
image.
So
we
run
this
command
Nix
build.
You
know
dot
for
the
for
the
current,
the
current
directory
hash
and
then
Docker
for
the
specific
Docker
package,
which
you
saw
I'll,
pull
that
up
once
again.
So
we're
just
building
this
package
right
here,
which
is
going
to
run
this.
This
lovely
little
function
and
get
us
a
nice.
B
So
once
we
we
built
our
image,
we're
going
to
log
into
Docker,
using
some
Secrets
I
provided
in
CI,
and
then
we're
going
to
load
and
push
the
image
to
to
to
Docker
Hub.
So
so
what
we're
going
to
do
is
so
you
see
this
Docker
load
slash
result,
so
so
this
is
the
way
that
that
Docker
is
going
to
take
the
the
tarball
that
Nix
has
built
and
it's
going
to
load
it
into
itself
into
its
into
its
own
runtime,
and
then
we're
going
to
this.
B
This
image
tag
variable
is
important,
because
one
thing
I
didn't
specify
in
in
the
the
image
build
here
is
I.
Didn't
give
it
a
specific
tag
now
I
could
have
done
something
like
this.
You
know
V1
1.0.0,
something
like
this,
but
I
didn't
do
that.
Instead,
if
you
don't
do
that,
then
what
what
NYX
does
is
it
is
it
is.
B
It
gives
your
image
its
own
tag
based
on
the
content,
so
just
so
so
the
same
way
that
NYX
uses
content
hashes
for
for
package
addresses
it's
going
to
do
that
with
a
Docker
image
as
well.
So
it's
going
to
be
called
loot
Perkins
to
do
colon
some
long.
You
know
you
know
gobbledygook
sort
of
hash
and
so
then
we're
going
to
use
Docker
because
we're
logged
into
Docker
Hub
to
push
that
image
here
and
then
we're
going
to
we.
B
So
we
want
to
keep
this
image
tag
name
around,
so
so
we're
going
to
load
it
into
the
GitHub
environment.
So
this
is
kind
of
the
kind
of
the
way
that
in
GitHub
actions
that
you
persist
variables
across
jobs.
Okay,
so
at
this
point
the
image
should
be
in
Docker
Hub,
and
now
we
can
so
now
that
the
image
is
in
Docker
Hub
we
can
we
can.
We
can
update
our
our
kubernetes
deployment.
So
here
we
use
this.
B
So
this
is
going
to
be
luke
Perkins
to
Do's
colon,
some
long
hash
and
then,
finally,
once
that's
done,
we
need
to
run
one
more
command
and
it's
going
to
run
rollout
restart
and
it's
going
to
Target
our
deployment
and
then
once
this
is
done
and
finished,
then
it's
going
to
then
our
then
the
changes
should
be
accessible
from
from
any
HTTP
client.
Okay.
B
So
let's
do
that
really
quick
I
am
going
to
let's
see
I'm
just
going
to
push
this
to
GitHub
and
I'm,
going
to
say,
changes
to
deploy
and
I'm
going
to
push
and
I'm
going
to
come
over
here
and
switch
to
the
other
to
another
screen
really
fast.
So,
let's
go
to
not
here,
let's
see
percentage
review.
No!
B
B
B
B
Oh
yeah,
okay,
here
we
go.
This
should
do
it
okay!
So
now,
let's
let
me
navigate
over
really
fast
and
we're
we're
going
to
look
at
the
actual
job
in
action.
So
we'll
pull
up
actions
here
and-
and
you
see
that
I've
pushed
I'm
going
to
expand
this
a
little
bit
and
you
see
that
I've
I've
pushed
this
changes
to
deploy,
commit
we're
going
to
have
a
look
at
the
pipeline
in
action.
B
B
I
know
I'm
kind
of
kind
of
butting
up
against
that
30
minute
constraint,
but
but
this
really
should
just
take
another
one
or
two
minutes
and
we
should
be
good
to
go
okay,
so
Docker
has
successfully
logged
in
to
to
Docker
Hub,
and
now
it's
going
to
push
this
image.
So
you
see
that
so
you
can
see
that
there
are
a
bunch
of
different
layers
to
this
image,
so
our
build
layered
image
function
has
done
its
thing,
and
now
we
see
that
the
cube
CTL
has
done
its
thing.
B
This
Json
object
that
we
that
we
expected
so
so
initially
the
container
was,
you
know
just
just
said
hello
world
when
you
ping
it,
and
now
we
were
able
to
just
with
a
simple
git
push
with
some
changes.
We
were
able
to
to
update
the
image
in
our
kubernetes
cluster
to
reflect
the
new
desired
reality
that
we
built
using
Nyx.
B
Okay,
so
let
me
make
sure
that's
right:
okay,
there
we
go
so
to
wrap
up
in
general.
I
I
think
that
this
demo,
although
it's
pretty
simple,
it,
does
provide
I,
think
a
decent
glimpse
into
one
way
of
potentially
using
Nyx
in
a
real
deployment,
Pipeline
and
and
thereby
bring
in
the
domains
of
nics
and
devops
into
into
a
really
fruitful
alignment.
So,
on
the
one
hand
we
use
NYX
to
build
to
build
these
nice
lean,
Docker
containers,
and
then
we
use
kubernetes
to
to
dramatically
simplify
our
deployment
pipeline.
B
So
so,
basically,
instead
of
having
to
spin
up
machines
and
write
scripts
to
get
our
service
running
and
updated
and
deleted,
and
so
on,
we
just
use
two
super
simple
Cube
CTL
commands
to
update
a
deployment
running
on
three
nodes.
So,
basically
what
we
get
is
we
get
the
power
of
Nyx
to
build
pure
and
dare
I,
say
perfect
software
artifacts,
and
then
we
also
get
the
power
of
declarative
infrastructure
to
put
those
artifacts
to
work,
and
that's
it.
Everyone
please
do
feel
free
to
get
in
touch
on
Twitter.
B
B
If
you
want
to
explore
all
kinds
of
fun,
Nixie
stuff,
thanks
a
Millions
everybody
to
the
organizers,
to
Summer
of
Nyx
to
to
Elko
dulstra
the
creator
of
Nyx
to
to
Graham,
and
my
colleagues
and
lots
and
lots
of
other
people,
I
hope
you've
all
had
a
wonderful
summer
of
Nyx
I
certainly
have
as
well
I
benefited
greatly
from
it
and
I
hope
you
have
as
well.
Thank
you
so
much.
Everybody.
A
A
B
B
You
know,
I
think
is
perfectly,
is
perfectly
fine
in
a
lot
of
cases
and
I
mean
if
I
go
actually
may
not
be.
The
best
may
not
be
the
best
example
of
of
of
of
reducing
Docker
boilerplate,
but
personally
I
I
mean
I,
just
really
like
that
Nick's
logic
and
and
I
love
the
way
that
NYX
is
able
to
infer
just
from
that
command
string.
A
A
B
A
A
B
Yeah
yeah
I
think
so
I,
so
I
personally
haven't
used
those
tools,
a
lot
myself,
but
but
yes,
that
would
certainly
be
you
know.
I
I
think
that
if
I
had
a
longer
talk,
if
I
had
more
than
30
minutes,
I
would
and
and
if
I
were
targeting,
if
I
thought
that
that
my
audience
was
more
people
who
were
going
to
be
well
positioned
to
push
Knicks
through,
you
know
top
to
bottom
within
their
organization,
I,
probably,
would
have
probably
would
have
used
that
approach.
I.
B
I
I
think
that
I
think
that
that
particular
technique
that
choice
wasn't
the
technical
choice.
I
think
it
was
more
of
an
audience
choice
and
and
yeah.
Perhaps
next
year
we
can
have
a
summer
of
Nick's
talks.
That's
you
know
end
to
end.
Nick's,
devops
I
think
that
that
would
be
really
interesting
and
cool
and
and
and
yeah
I
hope,
I
hope.
Somebody
puts
that
on
the
agenda.
A
B
Yeah
I
think
that
an
important
thing
to
note
is
that
is
that,
because
you
can
build
oci,
compliant
images
with
with
NYX
you're,
not
necessarily
forced
to
use
Docker.
So
there
are
some
other
tools
like
like
podman
and
some
other
other
container.
You
know
platforms
and
runtimes
that
you
can
use
with
Nick.
So
you
know
you
know,
use
NYX
to
build
that
that
nice
clean
little
tarball
and
then
use
some
other
non-doctor
system
to
pick
it
up.
I
think
that
it's
it's
I
would
say.
B
It's
probably
unlikely,
though,
that
you're
ever
going
to
see
the
kinds
of
utilities
that
you
get
in
Docker
and
podman
and
other
in
others,
inside
of
Nix,
because
I
think
that
those
tools
maybe
do
more
work
than
than
we
realized.
So
something
like
Docker.
You
know
it
it
loads,
you
know
so,
for
example,
in
the
CI
pipeline.
B
Just
because
you
know
NYX
likes
to
keep
its
its
surface
area
and
its
Mission
very,
very
clean
and
clear
it.
It
has
its
world
view
and
its
own
way
of
doing
things
when
it
comes
to
how
things
are
moved
around
between
next
doors,
but
it's
I
I
mean
actually
now
that
I
think
about
it.
I
mean
it
is
an
interesting
question.
B
B
B
Oh
gosh
I
mean
this
is
the
Eternal
question.
I
mean
it's.
It's
it's
almost
hard
to
address
because
because
you
really
had
to
go,
go
back
to
the
basics,
I
mean
I,
I,
I,
I,
I
hate
to
deflect,
but
on
on
the
nicks.dev
site,
there's
a
great
it
gives
this
list
of
like
Nick's
features
and
Nick's.
You
know
promises
that
I
have
personally
found
really
useful
when
it
comes
when
it
comes
time
to
try
to
to
try
to
talk
somebody
into
Nick.
B
So
you
know
I
usually
start
with
the
the
works
on
my
machine
problem
to
say:
hey,
you
know
we
want
to
create
environments
that
are
going
to
work
on
on
all
these
different
systems.
They're
going
to
work
in
CI
they're,
going
to
work
on
on
your
Mac
M1
they're,
going
to
work
on
a
corrupt,
the
old
Linux
box
somewhere
like
let's,
have
like
one
file.
B
That's
like
50
lines,
long
that
enables
that
to
happen,
I
think
that
tends
to
be
a
good
place
to
start
I
think
something
like
I
think
something
like
like
selling
the
the
Simplicity
of
yeah
I'm,
not
even
quite
sure
where
to
go
with
this
I
mean
I,
would
say
yeah
for
for
me
personally,
when
I'm
trying
to
sell
the
story
when
I
try
to
sell
this.
The
next
tour
I
usually
start
with
with
standardized
development
environments.
B
B
That
tends
to
be
where
I
start,
but
I
would
say,
yeah
check
out,
nicks.dev
check
out
that
list
of
features
and
and
and
for
the
specifics
situation
you're
in
maybe
maybe
pick
two
or
three
of
those
and
spin
those
into
into
a
nice
into
a
nice
and
neat
little
narrative,
and
you
know,
maybe
give
a
little
talk.
You
can
a
little
internal
talk
with
your
team.
B
A
B
Man
yeah
not
a
lot
of
softball
questions
today.
That's
that's
real
I
mean
yeah.
That's
really
a
great
question.
I
mean
I
think
that
when
I
look
forward
five
years,
I
think
that
I
think
the
devops
landscape
is
is
going
to
be
maybe
quantitatively
different
in
the
sense
that
the
kinds
of
like
declarative
logic
and
approaches
that
I've
talked
about
today.
I
think
that
those
are
going
to
become
more
widespread,
but
I.
Don't
think
that
the
landscape
is
going
to
be
qualitatively
different.
B
I
think
that
we
have
broad-based
industry
buy-in
around
declarative
approaches.
I
mean
people
who
have
used
terraform
to
stand
up.
The
exact
set
of
you
know
complex
complex
web
of
AWS
services
that
they
want
like
the
first
time.
They
see
that
and
the
first
time
that
they
know
that
they
can
just
tear
it
down
with
a
single
terraform
command.
B
Once
people
are
given
access
to
that
power,
they
say
they're
like
there's,
no
way
that
we're
going
to
do
things
by
by
clicking
around
in
the
AWS
console
and
spinning
up
services
and
making
sure
they're
connected
together.
I
mean
I.
Think
that,
yes,
like
I,
said
I,
think
the
industry
buy-in
around.
That
is
huge.
B
B
I
mean
one
thing:
I
was
curious
about
was
what
your
kind
of
plans
for
this
the
next
way
repo,
you
know
we
have.
We
have
many
documentations
guides
tutorials
all
across
the
next
space
and
I
was
wondering
what
you're
just
fishing
goals
for
that
or
yeah
yeah
I
mean
that's
a
great
question,
so
so
the
next
way,
I
I,
have
a
lot
of
different
a
lot
of
different
sub
projects
in
there,
some
of
them
some
of
them
I
kind
of
advertise
to
other
people
and
showed
other
people.
B
Some
of
them
are
more
personal,
but
really
I
mean
first
of
all,
I
have
to
say
that
my
goal
is
specifically
not
to
collide
or
or
interfere
with
other
resources
in
the
next
ecosystem.
I
mean
I.
You
know
currently,
I've
I've
been
in
some
of
the
documentation
meetings
of
the
documentation
working
group,
and
this
is
a
big
concern
that
that
we
don't
it's.
It's
really
difficult
to
tell
people
where
to
go
for
information
about
Nix
and
I.
Don't
want
to
compound
that
problem,
so
I
think
my
focus.
B
There
is
much
more
about
concrete
examples,
and
it's
much
more
about
you
know
providing
some
of
the
some
of
the
glue
and
some
of
the
you
know
some
of
the
like,
like
fill
in
the
gaps
kind
of
material
that
that
you
wouldn't
really
expect
in
the
documentation
per
se.
So
so,
for
example,
I
have
this
this
Dev
templates
project.
So
so
you
go.
B
So
so
Kant
has
this
great.
This
great
quote
that
that
examples
of
the
go-kart
of
judgment
that
basically
in
in
refining
our
judgment
and
refining
the
way
that
we
see
the
world
that
that
having
examples
as
fodder,
as
you
know,
Grist
for
the
mill
of
the
understanding
is,
is
really
vital
to
cognition
and
I.
Think
that
that's
what
I'm
trying
to
do
much
more
than
some
planting
existing
sources
of
documentation.
B
B
A
Yeah,
okay
sign
me
up
next
philosophy:
I
like
the
idea
that
would
be
cool,
I
am
looking
I,
don't
see
much
more
questions
coming
in
unless
my
internet
is,
of
course
flaky
as
well,
which
is
very
probable.
So
if
I
did
not
read
your
question
or
didn't
see
your
question
other
than
please
type
it
again
and
I'll
try
to
ask
it
I'll
give
you
guys
about
like
two
more
minutes
for
that
yeah.
B
I
am
yes,
I
I
shared
a
link
to
the
to
the
repo
I
believe
yesterday,
so
yeah,
so
I'm
I
will
make
sure
to
spend
the
rest
of
of
today.
It's
a
it's
about
noon.
It's
about
11
for
me,
I'll
spend
the
rest
of
today
in
the
chat
you
know
just
so.
People
have
follow-up
questions.
Would
love
love,
love,
love
to
keep
engaging
with
people
about
this,
this
stuff
that
we
all
care
about
so
much.
A
Okay,
so
then
I
will
for
the
people
that
I
didn't
see.
The
questioner
didn't
read
the
question
a
lot
I'm
terribly
sorry,
but
you
can
forward
that
question
over
the
Matrix
and
look
you
can
see
it
over
there,
but
I
will.
If
there's
no
further
questions.
I
will
be
wrapping
this
up
so
yeah.
Thank
you
very
much.
Look
for
the
amazing
talk.
I
really
enjoyed
it.
I
should
think
a
lot
of
people
that
are
in
the
devops
movement
also
very
much
enjoyed
it.
A
B
A
B
A
Making
sure
that
these
lectures
are
always
on
time
and
also
making
sure
that
I
get
a
get
to
do
these
things,
because
it's
very
much
fun
to
do
again.
I'm
sorry
for
the
for
the
microphone
quality
today,
but
it
is
what
it
is.
I'll
see
you
all
next
time
we're
working
on
yeah
for
yet
another
lecture,
probably
next
week
keep
an
eye
out
on
Discord
for
that
for
more
questions.