►
From YouTube: Scalability Team Demo 2022-01-13
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
Okay,
we're
recording
to
this
computer.
I
hope
this
recording
makes
it
yeah.
So
I
put
something
on
the
agenda
about
get
ssh
efficiency.
A
So
this
is
sort
of
left
over
from
the
work
we
did
last
year
to
make
the
transport
used
internally
between
workhorse
and
gateway
more
efficient,
but
so
okay
step
back.
So
we
we
made
this
cache
to
make
git
fetches
for
ci
faster.
Then
we
found
out
that
we
couldn't
get
the
data
off
of
the
gitly
server
fast
enough
because
the
transport
was
inefficient.
A
Then
we
optimized
the
transport,
but
only
forget
http,
because
that
is
the
dominant
workload
on
github.com,
because
ci
our
own
ci
uses
http,
but
it
seems
strange
to
not
deal
with
ssh
and
the
so
that
was
left
over
or
that
was
cut
from
the
epic
because
we
needed
to
keep
the
scope.
Pardon
me.
We
need
to
keep
the
scope
down,
but
I
now
started
working
on
that.
So
that
is
I
I'm
happy
about
that,
because
I
think
it
makes
for
a
more
compelling
story
to
say
to
people
hey.
A
A
So
for
them
it
would
be
really
nice
to
also
have
this
optimized
and
also
ssh
is
like
at
one
point
I
did
a
measurement
where
I
saw
a
thousand
times
more
http
traffic
than
ssh,
but
since
then
I
usually
see
it
now
at
six
factor
six.
So
it's
still
not
it's
not
nothing.
On
gitlab.com,
it's
not
the
majority,
but
it's
not
nothing
so
yeah,
I'm
working
on
that
now
and
it
should
be
fairly
straightforward.
A
I
don't
mean
that
to
sound
like
I'm
smarter
than
people,
but
I
just
I
I'm
it
would.
I
think
it
would
be
annoying
to
find
these
subtle
problems
if
you
don't
already
know
your
way
around.
So
I
guess
maybe
it's
a
mess
I
made
and
I
feel
like
I
can
clean
up
the
mess
myself
and
solving
the
subtle
problems.
A
Oh
yeah,
I
got
a
flame
graph
here,
that's
fun,
so
this
is
a
flame
graph
against
omnibus
and
if
you
look
at
that,
so
this
is
doing
20
shallow
clones
at
once.
That's
sort
of
simulating
a
ci
job
for
the
shuttle
clones
are
about
100
megabytes.
B
A
Yeah,
it's
a
big
fan
of
flame
grouse.
One
thing
I
found
interesting
is
that
I.
B
A
A
A
A
I
don't
know
what
this
is,
but
it
sounds
like
encryption
to
me
and
it's
sending
the
same
amount
of
data,
but
it's
using
way
less
cpu.
So
this
is
430
samples
and
this
one
is
1100
samples,
so
almost
three
times
more
in
sshd,
and
that
has
nothing
to
do
with
the
git
fetch
transfer
or
anything
like
that.
That's
just
because
they
are
different,
different
programs
doing
the
same
job,
so
that
was
yeah.
I
found
that
surprising,
but
yeah.
A
B
Hd
point
I
was
curious,
since
this
was
obviously
a
whole
host
profile.
I'm
assuming
this
is
something
you
captured
on
your
laptop.
A
Oh,
I
did
I
made
a
cloud
vm
and
I
didn't
own
the
version.
Okay.
So
it's
still.
First,
okay,
the
full
gitlab
stack
in
production
mode,
but
it's
not
doing
anything
else
except
my
benchmark.
B
A
No,
it
shouldn't
be
because
it's
yeah,
it's
just
a
vm
that
I
set
up.
You
can
see
like
little
things
like
prometheus
in
there
and
redis
server
and
whatnot,
but
nothing
I
mean
I
am.
Oh,
that's
an
interesting
one.
I
am
running
shd
and
I
use
my
perf
profile
to
x
my
purpose
extracting
the
data
through
ssh,
but
that
happens
after
the
profile
is
done.
A
B
A
Agreed
yeah
yeah,
so
I
don't
think
it's
that
yeah.
So
it's
ssh.
That
was
a
funny
thing
to
see,
but
yeah
gitlab,
shell
and
gitli
are
just
using
way
more
cpu
here
and
it's
that's
not
even
funny
how
smaller
these
two
are
over
here.
A
So
I
think
that
will
be
better
yeah.
I
actually,
I
think
I
even
have
a
flame
graph
for
that.
Sorry,
I'm
rambling,
but
I
do
have
the
flame
graph.
Let's
see
is
this
it
yeah.
So
this
is
a
flame
graph
without
it's
a
different
workload,
but
it's
it
shows
the.
It
shows
the
point-
and
this
is
a
flame
graph
with
the
new
code,
so
gitlab
sshd
is
actually
not
what
we
run
in
production,
but
it's
what
github
shell?
It's
the
combination!
A
A
A
I
guess
that's
the
only
garbage
collection
trace
yeah,
but
the
funny
thing
is
that
in
in
this
trace,
geekly
isn't
garbage
collecting
at
all
or
it.
Well,
I'm
sure
it
is,
but
it's
it
just
doesn't
show
up
in
the
profiles.
A
A
So
next
one
is
you
matt.
B
So
I
don't
know
how
interesting
this
is
going
to
be
to
folks.
So
I'll
just
keep
it
really
short,
and
let
me
know
if
you
want
to
go
into
more
detail.
B
So
so
italy,
okay,
so
italy
giddily,
it
does
not
have
repeatable
builds
right
now.
Reputable
builds
are
desirable
for
a
few
reasons,
one
of
them,
one
of
them
being
when
we
ship
a
binary
it's
if
their
builds
are
repeatable.
Then
it's
much
more
straightforward
for
security
engineers
to
audit
that
the
binaries
that
we're
shipping
are.
B
Exactly
haven't
been
tampered
with
and
really
are
built
from
the
source
code,
as
as
as
we
advertise
in
the
way
that
we
advertise
so
the
currently
our
our
builds
specifically
for
italy
are
not
repeatable
for
as
far
as
I
can
tell
exactly
one
reason
we
set
this:
let's
see
we.
B
So
this
build
time
is
defined
here
in
this.
In
this
make
variable
right
here
and
make
variables
can
be
overridden
on
the
command
line.
We
inject
it
here
when
you
do.
When
you
run
a
go,
build
one
of
the
options
you
can
give
to
the
go
build
invocation.
Is
this
ld
flags
option
which
takes
a
single
space
delimited
string
as
an
argument?
B
So
this
is
part
of
its
argument
is
giving
the
dash
capital
x
option
which,
whose
syntax
is
saying
we're
going
to
override
a
a
go
variable
symbol.
This
is
the
package
path
and
the
name
of
the
variable-
and
this
is
its
value,
so
essentially
the
go.
Binary
is
going
to
contain
this
symbol
with
this
value
and
we
can
make
our
build
repeatable
by
providing
any
constant
string
for
this
value,
so
it
can
get
a
real
timestamp.
It
could
be.
You
know,
foo
bar
in
my
repeatable
build
script.
B
I
just
gave
it
a
dummy
value
of
dummy
time
stamp
placeholder,
but
this
is
this
is
the
syntax
for
for
overriding
a
make
variable
when
make
runs,
and
this
is
just
telling
make
to
run
in
parallel,
and
this
is
the
build
target
whose
name
is
conveniently
built.
B
B
It's
so
we're
going
to
we're
going
to
show
we're
going
to
just
summarize
the
status
of
this
repo
and
then
we're
going
to
do
one
build
and
describe
several
bits
of
metadata
about
it
and
then
we're
going
to
have
a
loop
here
that
does
that
build
repeatedly
and
show
a
one-line
summary
of
the
shell
one
hash
over
all
of
the
the
the
binaries
that
get
built
to
show
with
the
ability.
B
So
that's
that,
let's
run
it,
it
takes
a
couple
minutes
to
run
and
I'll
go
with
the
results.
While
it's
going
scroll
up,
so
it
doesn't
go
off
the
edge.
So
this
is
the
first
line
of
output.
So
we're
just
noting
that
we're
running
on
the
master
branch-
and
this
is
the
modification
commit
and
I've
had
a
local
diff.
This
is
not
related
to
the
repeatable
builds,
but
I've
got
a
local
diff
where
I
removed
this.
B
One
pseudo
target
from
the
make
file,
which
was
inhibiting
makes
parallelism
if
you
run
make
dash
j
and
this,
and
this
target
is
included
in
the
make
file,
then
the
dash
a
gets
basically
ignored
and
every
every
build
target
gets
built
seriously,
which
is
completely
irrelevant
for
for
repeatable
builds,
but
it
was
germaine
to
the
the
past
that
I
wrote
this
for
so
you
can
ignore
that
if
you
please
so
this
is
running
the
initial
build,
because
I've
already
done
a
build
since
the
make
clean
the
output
is
pretty
concise.
B
So
this
is
kind
of
a
quick
output,
and-
and
this
is
this
is
kind
of
the
summary
so
for
each
of
the-
for
each
of
the
10
or
so
binaries
that
we
build
in
this
daily,
build
I'm
going
to
output
the
go
build
id
and
the
new
build
id,
which
this
is
what
it
looks
like
when
there
isn't
gonna
go
a
new
build
id
and
we
ask
to
show
it
there's
a
separate
branch
that
that
does
provide
these
just
for
context,
and
everyone
on
this
call
knows
about
this
right
already
and
then
this
is
the
shot.
B
This
is
the.
This
is
just
a
sha-1
checksum
over
the
the
binary
contents
of
the
the
the
byte
contents
of
each
of
these
buttons,
and
then
this
is
a
hash
over
this
output.
So
it's
effectively
capturing
whether
or
not
any
of
these
binaries
has
changed,
and
so
we're
going
to
compare
this
value
to
the
output
when
we
do
these
runs
repeatedly,
and
so
I'm
scrolling
down
a
little
bit
to
so.
B
We
can
see
the
three
loops
that
we
ran
and
we've
got
as
you
can
see,
we've
got
the
same
value
each
time,
and
thus
the
build
is
repeatable.
I
did
yeah.
So
that's
that's
pretty
convincing.
That's
also
this.
This
is
yeah,
so
this
is.
I
think
this
is
compelling
evidence
that
that
build
timestamp
is
the
only
uncontrolled
source
of
variation.
B
Where
do
we
know
that?
It's
that's
a
great
question.
I
I
didn't
do
this
research
so
repeating
what
I
what
I
heard
from
another
thread
back
in
december.
B
It
sounds
like
the
only
the
only
way
that
we
use
the
val
that
value
the
the
the
the
value
that
gets
statically
bound
into
into
the
binaries
is
to
support
one
of
our
prometheus
metrics.
That
wants
to
have
a
trendline
showing
the
the
timestamp.
A
Yeah,
but
so
I
wonder
if
we
could
just
just
take
the
one
of
the
timestamps
from
the
commit
we're
building.
B
Yes,
so
so
we
could,
we
could
certainly
do
that
and
we
could
all.
I
think
that
would
be
very
reasonable,
so
the
I
think
so
I'm
gonna,
I'm
gonna,
you
don't
you
just
see
the
screen
share
anymore,
sorry,
so
so
this
is
from
back
in
december.
B
So
I
don't
know
if
anything
has
changed
since
since
then,
but
the
last
time
we
talked
the
last
time
I
was
involved
in
the
conversation
about
this
stan
had
made
an
mr
and
then
closed
that,
mr
without
merging
it
to
do
exactly
that
to
I
forget
if
it
was
either
removing
the
build,
timestamp
or
or
setting
it
based
on
yeah,
the
most
recent.
B
Exactly
and
the
reason
we
had
to
close,
that
is
because
this
the
fact
that
every
build
that
the
builds
are
not
repeatable,
which
this
is
the
only
thing
making
sure
that
the
builds
are
are
not
repeatable,
means
that
every
time
we
it's.
This
is
a
chain
of
side
effects
really
and
we
need
to
deal
with
do
with
the
chain
of
side
effects
so
that
we
can
make
the
what
is
the
side
effect.
B
The
side
effect
is
this
is
what's
making
every
time
we.
We
install
a
gitlab
ee
package
on
the
getly
house,
though
the
reason
that
we're
able
to
trigger
the
the
restart
behavior
for
for
the
the
mr
that
you
made
from
the
best
recently
is
because
of
these
build
these
build
time,
stamps
being
guaranteed
different
for
every
single
build.
If
we,
if
we
make
them
non-repeatable,
then
if
we
do,
you
know
you
know
we
deploy.
You
know
once
or
twice
a
day
at
this
point.
So
if,
if.
A
We
go
back
to
that.
The
the
proxy
is
yes,
it
has
deleted
in
the
name,
because
the
I
know
no
longer
exists
and
then.
B
Yeah
well,
and
as
far
as
I
know,
that's
the
main
drawback.
Like
I
mean
the
the
really
the
kind
of
the
ideal
situation
I
I
think
it
would
be
to
to
have
to
have
the
the
package
installer
restart
getting.
B
B
Think
so
I
completely
agree
and
I
think
that's
the
right
path
forward.
We
just
have
to
you
know
we
essentially
just
have
to
do
that
work
and
then
we
can
make
the
build
repeatable
and
that's
what
I
want
to
show.
B
A
B
Yeah
exactly
because,
because
the
the
the
the
dev
package
manager
will
still
unlink
the
the
old
I
node,
even
though
it's
replacing.
A
Okay,
well,
that
sounds
that
sounds
fixable
and
it
also
sounds
like
it's
fixable
like
it.
It's
reasonable
on
its
own.
A
I
mean
restarting
based
on
the
hash,
is
also
fine,
but
what
we
really
care
about
is
whether
the
package
can
be
installed.
So
if
we
know
the
idea
of
if
the
packet
has
a
unique
id,
that's
changing
that's
a
better
signal
for
restart
than
the
the
hash
of
the
binary.
Yes,
true
true
yeah.
B
That's
that
topic
any
and
and
unless
folks
wanted
to
talk
more
about
it,
I'll
move
on
to
the
other
bit.
B
Okay
cool.
So
this
is
this
is
about
stripping
elf
binaries,
so
I'll
I
don't
have
anything
ready
to
screenshot
yet
I'll.
Just
so
I'll.
Just
keep
using
this
one
go.
Binary
is
kind
of
bad!
Oh
wait!
You
know!
I
do
have
something
we'll
do
this!
B
Yes,
so
this
will
work
great.
Okay,
sorry,
I'm
winging
this
so
so
this
is
a
copy
of
our
redis
server,
binary,
built
built
and
distributed
by
our
gitlab
e
package.
And
if
you
run
file
on
it,
you
can
see
that
it's
beautifully
both
not
stripped
and
and
claims
to
include
debug
info.
B
Those
two
things
absolutely
so
so
so
stripped
me
so
there
there
are
a
couple
of
options.
That's
exactly
what
we're
going
to
walk
through.
So
I
know
I
know
the.
B
A
That
it
arranges
the
different
pieces
that
make
up
an
executable
and
it
has
a
table
of
contents
and
headers
and
whatnot.
B
Yes,
exactly
so
we
can
go
into
as
much
detail.
As
is
interesting.
I
usually
use
bin
ls
as
kind
of
an
example,
so
you
can
see
that
it
also
isn't
elf
binary
and
we
can.
B
Correct,
yes,
so,
and
it's
got
a
bunch
of
other
sections,
so
we'll
use
this
to
as
a
contrast.
A
Are
those
numbers
are
those
numbers
sequential
in
the
left,
column.
B
Yes,
exactly
so
so
I'm
going
to
focus
on
the
the
the
one
that's
not
stripped
and
does
have
debug
info
first.
So
the
the
with
debug
info
piece
is
the
easiest
one
to
talk
about
it's
these
sections
that
that
are
named
debug,
something
or
other.
So
there
there
are
so
there's.
A
B
Of
a
bit
of
a
historical
pun,
that
elf
is
the
format
for
the
binary,
and
then
someone
thought
it
would
be
cute
to
to
call
the
debugging.
A
B
So
it's
traditional
but
not
mandatory,
to
have
the
the
dwarf
debugging
infos
embedded
in
elf
binaries,
and
they
don't
have
to
be,
but
they
can
be,
and
it's
typical
to
themselves
and.
A
Just
just
sorry
to
better
understand
what
we're
looking
at
this,
this
table
has
a
column
called
off,
so
I
assume
that's
offset
and
it
appears
to
be
sorted
by
offset.
So
we
can
think
of
this
as
a
map
of
different
sections
of
the
of
the
file.
B
That's
a
yes,
that's
exactly
right!
So
so.
A
We
can
literally
say
that
one
thing
comes
after
the
other,
because
it's
like
the
bytes
of
interp
become
conversed
and
there's
one
c
of
them
and
then
the
next
day
the
rest
comes
after
that.
That's
that's!
What
we're.
B
Doing
yes,
that's
exactly
right,
so
this
is
the
offset
within
the
file,
and
this
is
the
size
of
that
offset
in
bytes
this
column,
and
this
is
the
virtual
address
and
one
of
the
significant.
So
this
is
a
great
time
to
talk
about
this,
so
so
offset
within
okay.
So
these
don't
get
mapped
into
memory.
B
That's
exactly
right!
So
so,
when
you,
when
you
run
a
process,
different
different
pieces
of
the
the
the
binary
will
be
mapped
into.
B
A
Because
the
process
has
the
process
has
its
own
address
space
and
it's
it's
linux's
job
or
something's
job,
to
read
this
and
put
chunks
of
this
file
in
the
editor
space,
where
the
program
expects
it.
B
Yes,
exactly
so
that's
exactly
right,
so
so
in
any
running
process,
we're
gonna
have
essentially
exactly
the
same.
The
same
mappings
into
the
virtual
address
space
of
that
process.
For
this
binary
they'll,
of
course
occupy
different
physical
pages
of
memory,
but
for
from
the
perspective
of
the
process,
it's
virtual.
B
Exactly
right
for
for
any
of
binary,
there's
kind
of
two
views
on
the
same
on
the
same,
the
same
chunks,
so
I'm
going
to
gloss
over
the
difference
between
section
headers
and
program
headers,
but
except
to
say
that
program
headers
are
really
a
collection
of
of
one
or
more
sections,
and
and
some
sections
like
these
debug
infos,
don't
actually
get
included
in
program
headers,
because
they're
not
required
for
the
program
to
run
this.
B
This
section
oriented
view
of
the
binary
shows
us
the
entire
binary,
including
things
that
don't
actually
get
mapped
into
virtual
memory,
which
is
why
we're
able
to
see
these
things
yeah?
Okay,
so
so
this,
so
that
that's
that's
kind
of
a
roundabout
description
for
what
this
this
with
debug
info
refers
to.
It's
essentially
do
we
or
do
we
not
have
sections
that
are
named
debug,
something.
A
B
Yes,
so
so
when
so.
B
There
are
a
bunch
of
different
levels
of
debug
that
we
can
set
sg,
I'm
trying
to
get
to
the
right
section
that
talks
about
it
yeah.
This
is
all
right.
B
Yes,
exactly
yeah,
so
so
there
are
various
levels
that
you
can.
You
can
request.
B
So
so,
let's
go
back
up
to
this
one,
so
the
so
the
debug
infos
can
cover
something,
as
can
cover
a
variety
of
different
types
of
data,
including
things
like
the
complete
function
signatures
so
that
you
know
what
the
arguments
are:
the
to
a
given
function,
potentially
as
detailed
as
the
source,
the
the
source
code
line
numbers
associated
with
individual
assembly
instructions
yeah,
which,
which
is
where
you
get
sections
like
this
yeah,
so
they.
B
B
B
It's
yes
exactly,
so
I'm
going
to
switch
back
to
just
looking
in
this
directory.
This
is
the
original
binary
and
these
files
are
which
you
can
see
are,
except
for
this.
First
one
are
copies
of
the
binary
with
various
levels
of
stripping
or
compressing
applied.
So
we're
going
to
essentially
repeat
this
up.
B
A
B
B
B
Exactly
exactly
and
reddit
the
reddit
server
binary
is
not
a
big
binary,
so
this
is
a
huge
percentage
difference.
It's
like
a
5x
difference,
so
we've
talked
about
the
the
scroll
up
again,
we'll
just
look
at
it
again
here
so
we've
talked
about
this.
Let
me
answer
the
question
about
script
versus
not
script.
Now,
in
fact,
why
don't
we
do
this?
B
So
we'll
run
the
file
on
all
of
these
all
of
these
files,
and
you
can
see
that
I'll
explain
what
we
did
to
generate
each
of
these
files
in
just
a
minute,
but
you
can
see
that
that
only
the
last
one
is
is
considered
stripped.
So
I
know
I
haven't
done
this
yet,
but
this
one
is
removing
all
of
the
debug
infos
and
you
can
see
that
we
no
longer
claim
to
have
debug
infos,
but
we're
still
not
stripped-
and
this
is
this-
is
the
minimum
thing.
B
That's
that's
that
that
provides
useful
information
for
building
flame
graphs,
so
so
going
from
12
megabytes
to
2.1.
Megabytes
is
perfectly
acceptable
in
terms
of
in
terms
of
still
having
useful.
A
It's
still
useful
yeah
because
we
really
only
need
to
know
the
names
of
functions,
the
names
and
addresses
of
functions,
but
nothing
else.
B
We're
gonna,
if
we're
gonna,
do
like
binary
analysis
or
or
or
digging
into
like
if
we
wanted
to
instrument,
calls
to
a
function
based
on
the
second
argument
to
the
function
having
this
particular,
you
know.
B
It's
super
helpful
to
know
more
exactly
you
can
get
by
without
it,
but
it's
so
obnoxious
that
you,
you
wouldn't
yeah
so
yeah
that
the
the
debug
infos
provides
wonderful
support
for
gdb,
but
we
don't,
but
even
outside
of
gdb.
They
can
still
be
useful
for
for
custom
instrumentation,
but
generally
generally,
the
symbols.
A
B
A
A
But
marin
used
to
head
that
team.
It
was
team
leads
of
the
distribution
team
for
a
long
time.
So
I
think
he.
B
Well,
let
me
let
me
let
me
mention
this,
the
the
at
least
for
for
the
debian
packages
and
possibly
farther
for
other
packages
as
well.
I
I
can't
remember
what
the
multiplier
was,
but
it
was
at
least
like
two
or
three
x,
smaller.
A
B
Actually,
no
even
keeping
the
debug
infos
without
changing
without
without
doing
any
additional
stripping.
We,
the
package
is
basically
not
not
very
efficiently
compressed,
and
I
don't
know
omnibus
well
enough
to
know
how
to
set
this
flag.
But
but
when
I
build
the
package
when
I,
when
I
build
a
package
with
with
with
debian
tools
locally,
I
can
produce
effectively.
I
can.
B
I
can
extract
the
contents
of
the
package
of
the
omnibus
get
that
the
e
package
and
re
repackage
it
and
and
get
the
package
much
much
smaller
by
altering
the
compression
level
and
that
that,
I
think,
is
our
quickest
path
to
get
the
packet
smaller.
Well,
if
you
could
actually
yeah
you'd,
probably
be
a
great
person
to
pay
right
on.
A
A
So
omnibus
says
two
main
parts:
there's
the
part
that
does
the
build
and
then
there's
all
the
chef
code
that
runs
after
you've
installed.
That
is
github
control.
Reconfigure.
All
the
build
stuff
is
in
config,
okay
and
config.
Software
has
the
build
definitions
for
all
the
components
so
somewhere
in
here
is
redis
and.
B
What
about
the
higher
level
you
know,
building
of
the
the
the
package
that
contains
all
of
these
components?
Where
would
I
find
that.
A
That
is
encapsulated
into
the
omnibus
jam,
so
that
is
harder
to
get
to.
But
what
you,
the
basic
structure
is
that
you
have
a
build
route
where
you
run
basically
make
somewhere
and
then
you
run
make
install
and
you
can
set
c
flags
beforehand.
You
can
apply
patches.
A
So
if,
if
you
look
around
in
the
config
software
directory,
you
will
find
various
examples
of
how
to
tweak
tweak
these
builds.
But
this
is,
I
don't
know,
debian
builds
well,
but
I
imagine
this
is
roughly
also
what
this
is
just
what
you
need
for
a
package
build
and
the
the
actual
step
where
you
copy
these
files.
Actually,
I
think,
make
install
copies
them
into
on
omnibus
machine.
B
Because
this
is
this
is
a
package
level
compression
that
needs
to
be
turned
on
the
the
I
focused
on
debbie
and
packages,
because
that's
that's
what
that's
what
we
work
with
on
gitlab.com,
but
I
suspect
that
rpms,
for
example,
as
another
packaging
framework,
have
a
similar
option.
Essentially,
this
is
switching
to
xz
compression
and
newer
versions
of
the
debian
packaging
framework
default
using
this,
but
the
version
that
omnibus
uses
doesn't
default
to
it,
but
it's
still
supported.
A
A
Yeah
yeah,
I'm
not
sure,
that's
so
that
sort
of
crosses
over
into
the
omnibus
gem.
A
Okay,
and
I
think
we
actually
have
a
fork
of
that,
but
so
this
somewhere
it's
been
a
long
time
since
I've
been
in
here.
So
I
don't
know
what
happens
where.
But
this.
B
B
A
B
A
So
that
is
a
new
option.
It's
associated
it's
got
added
later,
so
I
it
sounds
to
me
looking
at
this.
That's
the
this
is
going
to
deny
list
xc.
A
So
there
is
a
mechanism
so
in
this
file,
sorry
in
this
file,
we
should
be
able
to
somewhere
say
that
we
want
to
use
a
compression
mechanism-
probably
in
this
block.
A
But
if
we
would
say
xz,
then
I
think
this
thing
is
going
to
reject
it,
but
then
there's
still
one
workaround,
which
is
that
we
have-
and
I
think
we
have
a
fork
of
omnibus.
B
A
B
A
B
B
That's
fantastic,
okay,
so
all
screen
share
again
and
we
can
wrap
up
the
the
bit
about
symbols.
So,
okay
did
I
get
that
right,
yeah,
so
so.
B
Symbols,
okay,
so
so
broadly,
so,
there's
a
few
ways
to
kind
of
talk
about
different
types
of
symbols.
But
in
this
context
I
want
to
differentiate
between
between
dynamic
symbols
which
are
defined
here
and
those
get
resolved
by
the
runtime
linker
versus
versus
symbols
that
were
already
resolved
by
the
static
linking
that
happens
during
the
build
and
those
are
defined
in
this
symbol.
Sorry,
in
this
symbol
table
and
and
this
is
the
the
string
table
that
gives
us
the
names
for
those
symbols.
A
Right
so
symbols
just
for
my
understanding
to
see,
if
that
I
got
it
right,
are
the
names
of
functions,
because
those.
B
B
Exactly
exactly
that's
exactly
it,
and
so
the
difference
between-
and
I
wanted
to
show
this
empirically.
B
This
one
that
is
completely
stripped
we
can
see.
The
only
difference
is
that
we've
ditched
the
symbol
table
and
the
string
table
that
goes
along
with
it
and
just
this
this
is
this
is
also
a
string
table.
This
is
the
section
headers
string
table,
which,
incidentally,
is
what
we
need
to
get
the
names
of
the
sections
and.
B
A
B
That's
exactly
right.
Yes,
so
that's
the
dynamic
symbols.
So
if
we
do
there's
a
few
ways
to
inspect
symbols,
nm
is
the
shortest
one
to
type.
So
that's
what
that
usually
defaults
to.
So
if
we
do
nm
on
redis
server,
which
is
not
strips
again,
so
this
one
is
not
stripped.
B
So
if
we
do
nm
on
the
server,
we
get
a
bunch
of
symbols
and
if
we
do
read
it
and
if
we
do
the
same
thing
on
this,
the
completely
strict
one
we
get
nothing
and
then
m
specifically
says
it
has
no
symbols,
no,
no
normal
symbols,
but
we
can
still
do.
We
can
still
find
the
the
other
2000
dynamic
symbols.
That's
right!
That'll
that'll,
be
consistent
for
all
of
our
weather.
Server
yeah
copy
copies
of
this
binary
because
stripping
does
not
and
cannot
remove
these,
because
these
have
to
be
resolved
at
one
time.
A
B
A
And
they
also
have
a
string
tab.
So
they're,
yes,
is
that
so
you
can.
So
you
can
print
good
error
messages,
because
I
don't
see
how
the.
B
Yeah
not
not
only
so
the
so.
A
lot
of
these
symbols
are
okay,
so
there's
two
reasons
to
have
dynamic
symbols.
One
of
them
is
if,
if
the
symbol
is
part
of
for
the
server
but
gets
exported
in
essence
to
make
it
available
for
for
other
libraries
that
might
want
to
call
it.
For
example,
the
the
build
the
build
framework
is
very
similar
for
for
shared
libraries
versus
executable
binaries
and
just
for
context,
and
the
other
reason
is
I'm
going
to
try
to
find
some
examples.
A
Oh
wait
but
the
the
no
I
I
I
see
why
the
names
have
to
be
there,
because
what
else
are
you
going
to
identify
the
things
in
the
library
spy?
Yes,.
B
B
Yes,
so
you
can
also
look
at
the
spelling
is
slightly
different
for
for
different
tools.
B
Yes,
so
this
is
the
dynamic
linker
is
responsible
for
for
resolving,
what's
called
relocations
and
part
part
of
the
the
the
contents
of
the
binary
is
is
to
effectively
say
here's
how
to
find
this
symbol
that
has
to
be
resolved
by
the
runtime
maker.
So,
for
example,
glibc
is
expected
to
provide
the
right
function,
and
this
this
is
the
the
type
identifier
for
the
kind
of
relocation
that
we're
talking
about.
So
it's
it's
a.
B
So
this
is,
this
is
how
we
this
is,
how
we
access
sort
of
the
top
of
this
list.
B
Yes,
there
are
other.
There
are
other
types
of
publications
like
user
applications
that
are
that
are
relative,
offsets
within
the
binary.
A
B
Don't
have
pretty
names,
but
the
ones
that
this
is.
This
is
to
your
point,
the
ones
that
have
to
look
in
libraries
that
are
that
are
outside
of
this
binary
that
are,
that
have
to
be
brought
in
by
the
dynamic
linker
on
demand.
Those
will
always
have
have
names
and
ends
some
string
that
identifies.
A
B
Of
which
of
the
shared
libraries
is.
B
Exactly
so
that's
so
that's
that's
the
that's
kind
of
a
quick
tour
of
of
stripping
and
oh,
I
didn't
actually
do
any
stripping.
Let
me
let
me
show
you.