►
From YouTube: 2021-07-21 meeting
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
A
A
B
C
B
C
All
right,
so
I
think
we
have
the
the
main
things
are
the
aprs
that
are
open,
so
rasmus.
I
think
this
is
the
the
big
rename.
I
was
just
looking
at
the
the
files
that
we
have
here
and
just
by
the
amount
of
it,
so
you
are
renaming
not
only
the
binaries.
I
suppose.
D
C
I
see
I
see
okay
yeah,
I
I
I
just
had
checked
the
net
the
kind
of
the
number
of
files
here
and
I
was
thinking
that
was
covering
the
all
all
the
the
other
stuff.
You
know.
C
D
C
C
C
The
next
one
is
a
whip,
yet
I
took
a
quick
pass
very
quick
just
to
anticipate
some
stuff,
but.
D
E
B
C
C
So
so,
basically
you
are
saying
avoiding
the
idea
of
having
to
kind
of
do
local
network
in
that
sense,
to
avoid
all
all
that
set
up-
and
let's
say
fleekness
of
the
test.
E
I
think
it
would
need
anyway,
some
kind
of
of
networking
so
and
think
it
will.
It
can
also
be
flaky
or
just
thinking
that
not
coupling
to
some
concrete
exporter
just
in
case,
for
example,
if
there's
a
backing
exporter
or
tests
are
failing,
but
it's
just
it
doesn't
have
to
be
in
this
pr
just
something
to
consider
before
we
create
too
much
integration
tests.
C
So
I
think
if
we
want
to
do
that,
we
should
do
kind
of
rather
soon
than
later.
You
know,
because
that's.
F
G
C
C
C
Okay,
these
were
the
apis
that
we
have
hoping.
I
had
looked
at
a
little
bit
at
some
more
cases
about
configuring,
different
different
configurations
of
packages
importing-
and
one
thing
that
I
I
keep
I
mentioned
this
before.
I
did
this
a
little
bit
for
the
dotnet
framework,
but
I
wanted
to
experiment
also
changing
the
runtime
json
for
net
core.
C
So
with
those
in
theory,
we
need
the
files,
but
in
theory
we
could
also
solve
the
problem
of
not
having
the
projects
to
build,
but
we
could
kind
of
redirect
also
for
net
core.
You
know
it
requires
that
we
update
the
runtime
json.
So
if
you
wanted
that
to
be
really
a
solution,
we'll
need
to
write
some
tool
for
that,
but
that
also
allows
us
to
even
in
that
case
may
work
even
without
the
the
build
project.
So
I
I
didn't
have
time
really
to
dig
deep
into
that.
C
So
then
we
in
principle-
and
I
I
don't
think
right
now-
we
have
the
the
the
the
cycle
strong,
invest
on
that,
but
in
principle
we
could
have
solutions
both
for
both
cases
about
not
have
the
projects
for
net
framework.
We
could
use
the
redirects.
We
know
that
there
are
some
limitations
there.
If
the
machine
is
locked
down
and
this
kind
of
thing,
but
even
without
the
source,
you
can
do
that
and
dot
net
core
similar.
C
You
know,
I
think,
in
two
weeks
I
should
have
time
to
kind
of
write
those
and
put
in
a
doc
in
a
readme,
so
for
the
time
being
is
where
I
want
to
stop
with
that.
You
know.
I
don't
want
to
write
the
code
for
anything
of
that
right
now.
I
I
don't
have
the
cycle
for
that,
but
then
we
at
least
document
the
solutions
and
in
the
future
you
can
invest
on
that.
C
Yeah
this
was
something
that
is
in
my
mind,
as
I
said,
I
I
plan
to
get
to
that.
Do
you
guys
want
to
bring
anything
else
up.
C
I
think
we
are
going
through
one
of
those
moments
that
the
activity
has
been
a
little
bit
concentrated
with
erasmus
right
now.
C
C
C
Yes,
we
need
logging
to
you
know
by
the
way.
We
have
a
question
about
that
right,
because
the
sdk
uses
event
source
to
to
do
logging,
and
we
probably
should
find
something
consistent.
So
the
logs
are
published
to
the
same
location,
so
we
probably
need
to
add
an
event
source
for
for
the
auto
instrumentation
that
we
can
integrate
with
them.
F
Yeah,
so
ceralog
should
have
an
event
source
plugin,
which
we
might
just
be
able
to
leverage.
F
Right,
well,
probably
a
little
bit
of
vendoring
too.
C
Sure
you
can
do
about
that.
I
I
I
know
what
we
can
do,
but
I
I
don't
think
anybody's
gonna
like
it.
We
can
make
it
double
events
and
then
publish
them.
F
I
mean
the
the
other
alternative
is
yes,
the
sdk
is
using
event
source
for
for
its
logging,
but
I
personally
find
the
file
logs
much
easier
to
get
and
to
to
debug
problems,
whereas
with
the
sdk
you
have
to
opt
in
to
to
the
logging,
you
have
to
drop
a
file.
F
You
got
to
go
through
all
of
these
hoops
and
it's
not
always
clear
where
you
need
to
drop
that
file,
and
so
it's
it
can
be
frustrating
to
to
walk
somebody
through
trying
to
enable
the
logging,
whereas
if
we
do
what
the
tracer
is
currently
doing,
we'll
just
always
have
logs
available
it's
more
straightforward,
and
perhaps
we
could
have
a
discussion
with
the
sdk
people
about
having
an
additional
way
to
to
log
things.
C
Yeah
that
that's
a
very
good
point,
because
just
having
the
files
enabled
there,
I
in
the
fork
that
we
use
a
lot
of
times.
The
first
thing
that
I
do
is
ask:
oh,
please
send
the
logs
you
know
and
the
logs
are
red
there.
You
know
rotating
everything,
so
you
you
don't
need
to
ask
for
enable
that
before
you
ask
for
the
log.
That's
a
very
good
point.
Chris.
C
But
in
that
sense
should
we
look
at
perhaps
enabling
the
sdk
logging
from
default
and
having
some
information.
C
Okay,
so
so,
perhaps
that
what
we
do
for
for
the
time,
then
we
we
kind
of
relieve
the
user
from
those
steps,
because
especially
being
auto
instrumentation,
where
they
are
looking
for
less
manual
steps.
We
kind
of
should
add
that
to
the
part
of
our
sdk.
F
There
may
be
some
some
complexities
there.
It's
probably
been
about
six
months
since
I
played
with
that
logging
feature.
But
if
I
remember
right,
it
writes
a
fixed
size,
log
file
to
disk,
and
then
it
just
circularly
overwrites,
that's
that
file,
and
I
don't
remember
if
there's
much
control
over
where
that
log
file
can
be
written.
C
The
top
of
my
mind
either
I
did
that
in
the
past,
but
yeah
didn't
use
for
two
years
or
something
so.
F
C
No
way
that
I
remember
that
yeah,
but
but
this
is
a
very
good
good,
good
things
I,
when
I
play
with
the
applications,
I
will
try
to
play
with
the
logs
too
to
get
a
feeling
for
that,
but
I
I'll
try
to
focus
really
more
on
what
I
talked
about
about
the
paths
for
our
red
butte
applications
right,
so
I'll
try
to
focus
more
on
that.
D
I
just
one
dot
about:
maybe
you
can
bubble
up
the
looking
from
native
level
and
use
manage
level.
C
Because
he's
too
little
and
I'm
I'm
I-
we
are
moving
today
to
the
other
temporary
house
until
my
house
is
really
done
and
there
is
vacuum
cleaner
and
stuff
going
on,
and
here's
in
painting
and.
C
So
you
you
mean,
publish
the
event,
says
etw
and
capture
on
the
manage
and
system.
E
C
Event
pipe
to
using
our,
I
set
it
to
double,
but
my
my
mind
was
really
thick
and
event
pipe.
C
F
Are
you
just
saying
that
you're
just
talking
about
marshalling
up
the
the.
F
F
That
it's
harder
to
direct
a
customer
to
go
and
enable
some
sort
of
logging
when
they're
trying
to
reproduce
an
issue,
even
if
you're
simply
just
trying
to
request
more
detailed
logs
oftentimes.
Those
detailed
logs
can
impact
performance,
and
so
they
don't
want
to
do
that
on
a
production
system.
F
C
B
C
Yeah,
so
I
I
think
we
then
perhaps
should
really
look
at
perhaps
having
the
the
setting
up
the
sdk
in
a
way
that
is
most
following
the
the
pattern
that
we
already
have
for
the
files.
You
know,
I
don't
know
if
that
will
be
possible
or
or
requires
some.
E
It
will
be
possible
for
sure
I
remember
that
when
I
was
creating
an
anti-ransomware
on
using.net
framework
with
etw,
it
was
possible.
To
sum
I
was
just
doing
it
for
debugging
purposes,
because
it
was
easier
to
I
would
just
using.
It
was
easier
for
me
to
write
just
hook
and
use
a
normal,
lock
files
than
using
purview.
For
me,
then
yeah,
and
I
also
agree
that
the
very
yeah
basically
her
view
and
those
stuff
is
very
powerful.
C
Yeah
yeah
makes
sense
okay,
so
I
think
this
is
something
that
we
have
to
explore
before
we
kind
of
at
least
settle
on
a
model
before
we
really
think
in
doing
the
the
switch
to
through
this
to
the
sdk
plc
branch.
You
know
at
least
we
should
kind
of
agree.
Okay,
we
like
the
files.
We
would
like
to
have
a
way
to
already
enable
the
sdk
to
produce
the
needed
files
trendy,
but
especially
first
releases.
You
know
later
we
can
follow
all
the
pattern,
but
the
first
release.
F
Has
anybody
started
to
play
around
with
metrics
in.net.
C
I
I'm
back
at
doing
stuff
at
the
collector
right
now.
I
have
some
stuff
that
I
want
to
stream
to
the
collector,
so
I
I'm
kind
of
slow
on
my.net
side
so.
F
Yeah
I
I've
just
had
a
teammate
working
on
the
otlpa
exporter
for
metrics
for
for
dotnet,
so.
C
One
thing
that
I
one
question
that
I
have
in
that
regard
and
cjo
already
mentioned
to
me:
that's
gonna,
we
are
gonna,
have
some
adapter
it's
because
there
was
some
initial
investment
on
that
dot-net
diagnostic
receiver,
that
uses
event
pipe
because
metrics
right
now
are
published
as
as
via
via
that,
and
we
we
have
the
initial
work
done
there,
so
we
eventually
plan
to
do
more
investment
there
to
collect
other
information.
C
But
then,
with
this
change
to
these
metrics
I
and
I'm
not
following
clothes.
I
would
like
to
know
if
that
it's
really
a
plan
that
we
should
keep
long
term.
You
know
because-
and
this
is
more
for
the
collector,
but
I
I
think
it
affects
everyone
here,
because
right
now,
the
windows
experience
is
very
good
for
the
customers,
with
the
collector
for
m.net
core
and
framework,
because
the
collector
is
able
to
pull
all
those
metrics
from
performance
counters,
but
on
linux
is
not
that
good
because
we
don't
have
those
counters.
C
So
the
way
that
we
were
looking
forward
was
via
the
diagnostic
reserve
receiver,
but
my
understanding
is
that
their
runtime
is
also
part
of
this
metric
change.
The
api,
so
I'm
not
sure
if
they
are
going
to
continue
to
publish
as
event
pipeline
or
you
need
some
shin
from
any
side
to
send
those
as
event
pipe.
C
So
I
have
that
in
my
backlog,
to
check
with
siege
and
check
the
directions,
but
right
now
I
don't
know
that
if
any
anyone
is
aware
of
that,
you'll
be
great
to
update
the
the
people
around
here.
F
C
Because
the
the
the
thing
is
that
my
understanding
is
that
the
runtime
is
involved
in
this
new
metro
api
and
there
will
be
changes
there.
What
I
I
is
not
clear
to
me
is
because
cjo
mentioned
to
me
that
there
will
be
a
shim
from
open
telemetry
to
publish
the
the
metric
is
that
current
comes
via
event,
pipe
the
counters,
for
instance,
and
my
my
understanding
is
that
then
it
becomes
a
requirement
to
have
the
open
telemetry
stuff
and
for
some
cases.
C
F
F
Whereas
for
your
bigger
more
long
long
lived
applications,
it
might
be
more
convenient
to
just
have
it
within
your
with
an
in-process
receiver,
which
is
what
that
shim
would
be
doing
and
then
just
have
it
all
sit
up
together.
And
then
you
don't
need
a
collector
to
pull
that
information.
You
can
just
send
it
up,
and
so
I
I
see
value
in
both
use
cases,
but
that's
just
my
opinion.
C
I'd
see
dave
one
question
that
I
have
perhaps,
but
I
as
far
as
I
understand,
but
it's
that
microsoft
is
still
gonna,
be
publishing
those
metrics
via
event
pipe.
I
I
didn't
hear
anything
different
than
that,
but
I
I
was
just
wondering
if
this
new
api
for
metrics,
that
is
going
to
also
be
part
of
their
runtime,
somehow
changes
anything
of
that
picture.
H
So
I
don't
know
about
specific
details,
but
the
the
metric
stuff
is
happening
with
event
sources
which,
by
which
makes
it
work
with
event,
pipe
or
etw,
because
event
sources
are
plugged
into
both
systems,
and
so
it
should
work,
although
I'm
not
involved
in
that
work,
so
I
I
can't
tell
you
any
of
the
details.
Noah
is
the
one
that's
driving
that
work
so
noah's,
actually
a
really
good
person
to
ask
if
you
have
specific
technical
questions.
C
Okay,
yeah
right
now,
I'm
not
at
the
level
to
know
the
details
enough
to
have
a
direct
question,
but
then,
if
something
comes,
if
I
eventually
reach
that
point,
then
I'll
ping,
nowhere.
F
F
Be
simple
enough
to
test
that
you
could
just
create
a
simple.net
6,
app
that
writes
the
metrics
using
the
new
api
and
just
run.net
counters,
and
and
give
it
the
name
of
your
source
yeah,
pretty
quick
to
validate.