►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
I'm
Eric
and
I'm
gonna
talk
a
really
fast,
so
I
have
a
software
that
I
want
to
build.
That's
why
I
hate
building
software
I
want
to
use
software,
but
sometimes
that
means
I
have
to
compile
software,
sometimes
that
software
isn't
done.
It
doesn't
quite
do
what
I
need
so
I
actually
mean
that
I
need
to
patch
and
then
compile
and
then
build
and
then
maybe
use
software
and
after
I've
done
all
that
work.
Maybe
I
need
to
share
that
software,
so
anyone
else
can
do
it.
A
There
are
many
different
ways
to
go
about
package
management.
This
is
roughly
the
fourth
lightning
talk
at
the
camp
about
package
management,
so
this
was
going
to
aim
to
be
the
most
out
to
space.
The
most
deeply
reconsidering
take
on
this
topic
that
you'll
hear
today
and
try
to
reach
a
little
bit
of
a
different
place
by
going
just
to
the
most
meta
forum
instead
of
the
concrete's
so
yeah.
A
So
despite
some
of
the
first
words
I
use
being
building,
what's
tricky
isn't
building,
we
have
build
tools.
We
have
lots
of
build
tools,
we
have
more
build
tools
and
I
could
possibly
list
I
didn't
even
try.
We've
had
build
tools
of
various
kinds
for
decades.
Building
isn't
the
problem
what's
tricky
is
integrating?
A
What's
tricky
is
figuring
out
how
to
connect
different,
build
processes
together?
What's
tricky
is
figuring
out
how
to
compose
whole
systems?
Out
of
this,
so
in
figuring
out
how
to
integrate
things,
I
think
it's
sometimes
best
to
figure
out
how
to
break
that
problem
down
first,
so
what
is
it
build?
I
would
say-
and
these
are
all
just
opinions
by
the
way,
but
we'll
explore
more
opinions.
Later
a
build
involves
a
bunch
of
files
going
in
conveniently
we
have
a
file
system
called
ipfs,
which
is
really
good
at
identifying
files.
A
A
It
would
mean
we
could
take
a
hash
of
this
whole
instruction
of
a
build
and
we
could
go
from
content-addressable
just
addressing
files
by
the
content
hash
to
computation
addressable.
This
could
be
a
primary
key
into
like
a
totally
different
way
of
doing
computation.
You
could
use
this
for
lots
of
things.
It's
a
very
useful
building
block
to
making
larger
more
interesting
systems.
You
can
share
complete
instructions
for
a
build.
You
can
rebuild
things
later.
A
You
could
share
these
for
bug
reports,
so
they're
context-free,
that's
a
really
useful
thing
and
all
inclusive
good
for
bug,
reporting
good
for
audit
logs
good
for
does
this
go
backwards,
no,
no,
how
to
go
backwards,
having
output
hashes
at
the
end
of
a
process?
Oh
there
we
go
yeah.
If
you
have
the
hash
of
a
file
system
that
comes
out
of
a
build,
it's
really
really
useful
for
checking
reproducibility,
as
opposed
to
assuming
that
processes
are
deterministic
and
reproducible.
So
this
is
a
general
forcing
function
for
sanity.
A
This
helps
us
build
sane
systems,
but
this
was
just
breaking
down
the
concept
of
a
build.
So
now,
let's
try
to
integrate
again.
Let's
try
to
build
a
bigger
system
with
that.
It's
really
useful
to
be
able
to
address,
builds
that
we've
already
drafted
once,
but
this
doesn't
solve
a
lot
of
problems.
This
just
gets
started.
A
Nobody
likes
copying
and
pasting
hashes
and
in
order
to
build
larger
systems
that
have
more
than
one
part
of
a
build
in
them
or
different,
build
tools,
different
compilers,
whatever
we'll
need
a
way
to
describe
multiple
steps
of
builds
and
describe
their
relationships
in
advance,
and
this
will
be
just
essential
to
any
kind
of
productivity,
so
describing
multiple
steps
and
relating
them
in
advanced
means.
We
can't
use
hashes,
we
don't
have
a
thing
to
hash
yet
so
we
have
a
naming
problem.
Hooray
distributive,
naming
problems
are
hard.
A
A
Now
this
is
going
to
go
very
medam,
I'm,
barely
talking
about
package
management
all
for
a
moment
here
there
are
lots
of
different
kinds
of
naming,
sometimes
I
use,
naming
for
labeling,
sometimes
I'm
going
to
want
to
name
nodes
in
a
graph
just
so
that
I
can
identify
different
nodes,
even
when
they're
topologically
identical.
Sometimes
when
I
say
naming
I
mean
I'm
going
to
look
for
updates
the
latest
thing
with
some
name.
Sometimes
I
want
to
use
naming
with
some
sort
of
prefix
pattern
just
to
do.
A
Grouping
and
categorization,
sometimes
I'm,
trying
to
use
it
for
reputation
all
these
are
very
different
user
stories
and
maybe
by
breaking
them
down
well,
some
of
these
we
might
find
to
be
a
lot
easier.
For
example,
naming
just
to
label
things
can
still
be
an
immutable
thing.
You
can
make
immutable
name
references
in
some
context.
If
you
want
to
label
stuff
in
a
graph,
you
only
need
unique
names
within
the
context
of
the
graph,
so
some
of
these
problems
are
much
easier
to
solve
than
others.
A
A
A
So,
for
example,
I
might
make
some
locally
scoped
naming
system
to
connect
a
bunch
of
things
as
a
graph
of
builds,
and
it
would
be
easy.
I
just
use
some
locally
unique
name,
but
to
integrate
into
bigger
systems.
Again.
Part
of
the
problem
becomes
collaboration
with
other
people,
and
now
it's
not
so
easy,
but
we
have
this
full
stack
of
constant
addressable
things.
We
have
this
whole
protocol
called
IP
LD,
which
is
about
helping
us
make
other
content-addressable
messages
easily.
A
So
what
happens?
If
we
take
this
concept
of
locally
scoped
names
in
some
contextually
limited
size
of
graph
and
who
just
keeps
slowly
expanding
that
definition
of
locally
scoped
and
we
make
message
passing
systems
between
different
scopes,
which
are
themselves
all
content,
addressable
messages,
so
we
can
continue
building
bigger
and
bigger
Merkel
trees,
which
are
all
immutable
in
some
scope,
but
give
us
functionally
the
kind
of
composable
in
readable
naming
that
we
want
I'm
almost
out
of
time
already.