►
From YouTube: NGS weekly meeting #3 - 2021-10-24
Description
Next Generation Shell is a modern programming language for DevOps.
This episode is a status update on recently done and upcoming work on NGS. This time it was more thinking than doing. We discuss the future UI.
A
A
Hello
for
first
time,
listeners
I'll
say
that
next
generation,
shell
or
in
short
ngs,
is
a
modern
programming
language
for
devops.
You
are
now
watching
a
weekly
meeting.
Weekly
meetings
are
about
progress,
updates
and
planned
work
for
the
near
future.
A
I
am
ilya
sher
the
author
of
the
project,
okay,
so
this
week,
due
to
personal
reasons,
there
was
not
much
progress
like
roughly.
B
A
But
I
was
thinking
I
was
thinking
about
ngs
and
I
wrote
some
of
these
things
down
and
my
thoughts
were
primarily
focused
on
the
ui,
because
it's
coming
in
the
near
future.
Let
me
close
my
door
because
my
cat
is
screaming.
A
A
Well,
typically,
you
type
a
comment
in
and
then
you
get
your
a
dump
of
text
on
your
screen,
so
there
are
several
issues
with
this
process.
First,
the
output
is
mixed.
You
can
get
standard
output
and
standard
error.
It's
also
mixed
on
another
dimension.
When
you
can
have
output
from
different
processes
and
third
issue,
the
output
is
not
bound,
so
you
can
get
like
10
000
lines
on
your
screen,
which
is
not
really
processable
by
any
human.
A
So
it's
not
very.
Let's
say
user
experience
friendly
and
the
fourth
issue
with
current
situation
is
that
whatever
you
have
on
the
screen
is
not
actually
interactive.
Sorry
get.
A
Okay,
now
he
can
scream
inside
okay.
So
so,
for
example,
if
you
do
like
ec2
list
instances
with
aws
and
you
have
the
list
of
the
instances
on
your
screen-
and
you
know
next
comma,
which
deals
with
ec2
instance,
will
not
be
completing
the
instance
id
from
your
screen,
because
there
is
no
such
even
concept
that
you
know
to
access
what's
on
your
screen,
so
it
will
be
some
other
type
of
completion,
maybe
from
the
global
list
or
whatever
is
fetched
from
the
api
or
whatever.
A
It's
never
about
interaction
really
with
what's
actually
on
the
screen.
So
due
to
these
limitations,
my
previous
thinking
about
the
ui
and
ngs
was
as
follows.
The
interaction
goes
like
this.
You
type
command
and,
as
a
result
of
that
comment,
is
a
widget
on
your
screen.
The
widget
is
interactive.
Of
course,
it's
bound
in
the
amount
of
text
that
you
can
display,
because
there
is
no
reason
to
display
ten
thousand
lines
to
a
human.
A
It's
like
it
doesn't
do
any
good
and
pretty
much
all
the
issues
are
solved
which
brings
us
to
other
issues,
but
we'll
talk
about
them
in
another
time.
So
the
previous
thinking
was,
you
type
a
command.
You
have
a
widget,
you
interact
with
the
widget.
A
The
result
of
that
interaction
is
new
command,
new
command,
which
is
textual,
and
it
is
executed
as
if
you
typed
the
command
and
in
this
manner
you
get
a
history
and
all
the
all
the
rest
of
the
goodies
which
come
with
a
textual
representation
of
your
operations
like
copy
paste,
send
to
a
friend.
You
know
whatever
history
stuff
like
that.
A
I
would
say
it's
the
concept
of
the
timeline,
so
what
we
have
now,
let's,
let's
take
a
look
at
bash
history,
for
example,
what
do
you
have
in
there?
You
have
commands
and
if
you
have
specifically
configured
you
will
have
timestamps
of
when
this
commas
occurred.
So
you
will
have
like
notoriously
a
minimal
amount
of
context,
actually
zero
context
about
any
of
this.
So
it
will
not
help
you.
For
example,
if
you
have
a
production
issue,
looking
back
at
bash
history
will
not
help
you
much.
It
will
help
you
just
a
bit.
A
A
You
don't
have
any
environment
variables
which
were
involved
in
the
command,
so
you
don't
know
sometimes
the
values
which
were
substituted.
You
don't
know
pretty
much
anything
except
for
the
command,
so
this
is
notoriously
little
context.
So
that's
that's
why
the
bush
history
is
very
limited
in
its
usefulness.
A
So,
let's
take
for
a
moment
and
generalize
the
concept
of
history.
Okay,
first
of
all,
history,
doesn't
let's
get
rid
of
the
constraints
that
it's
about
the
past?
Okay,
because
some
events
are
actually
very
interesting
and
they
are
planning
to
be
in
the
future.
A
For
example,
if
you
work
on
your
system-
and
you
have
plenty
of
downtime-
wouldn't
it
be
convenient
to
actually
see
the
planet's
downtime
on
your
screen
and
actually
how
much
you're
approaching
that,
how
much
time
you
left
have
left,
I
think
it's
very
useful
to
have
future
events
in
the
in
the
timeline.
A
Another
thing
that
this
events,
I'm
not
sure
how
to
actually
call
them
this
items
in
the
timeline.
Let's
call
them
events
for
now
they
could
be
of
different
types.
Well,
it
could
be
a
command
that
you
typed.
It
also
could
be.
Maybe
your
comment
or
other
things.
So
I
would
like
to
share
my
screen
and
show
the
wiki
page
where
I
took
my
notes
and
we'll
see
which
types
of
events
you
know
roughly,
we
can
start
with
screen.
A
Okay,
so
yeah
now
going
a
bit
back,
take
bash
history
and
generalize
this
like
a
lot
on
many
different
dimensions
so
which
events
we
could
potentially
have
on
the
timeline.
Well,
when
you're
on
the
program,
it
started
it
output,
something
it
progressed.
Maybe
it
has
like.
Let's
say
it
works
on
a
10
gigabytes
file
and
then
you
want
to
see
some
progress
so
from
time
to
time.
A
You'll
have
progress,
events,
maybe
or
maybe
some
log,
and
then
the
comment
finishes
and
then
you
have
like
exit
code
in
there,
so
other
things
you
would
like
to
have
is
are
actually
notes.
So
let's
say
you
have
like
emergency
now
and
you
work
on
the
production
and
now
it's
down
and
you
and
you're
in
the
middle
of
something.
Now
you
want
to
take
a
note
because
there's
something
important
that
you
want
to
remember.
A
You
know,
after
all
of
this
finished,
and
you
know
you
do
postmortem
and
you
want
to
remember
something
and
you
don't
want
to
have
like
10
separate
windows
for
all
of
this.
You
want
all
of
it
to
be
on
the
same
timeline.
I
think
it
would
be
convenient.
A
Is
the
the
events
could
come
actually
from
different
sources,
from
example
from
monitoring
system?
So
let's
say
you
started
the.
I
don't
know
deploying
new
ec2
instances.
Why?
For
example,
you
wouldn't
see
you
know
health
checks
from
the
perspective
of
load
balancer,
something
like
that
also
useful,
and
I
think
it's
very
useful
to
have
all
of
these
events
on
the
same
timeline
on
the
same
screen
while
they
are
ordered
by
time
metrics.
A
For
example,
annotation
annotation
is
a
kind
of
a
comment
which
you
write
about
existing
event
schedule
events
we
already
discussed
planned
comments
to
run
so
I
know
many
companies
are
using
things
which
are
called
the
playbooks
or
run
books
or
whatever
it's
it's
a
bunch
of
comments
which
need
to
be
executed
as
part
of
handling
something,
or
it's
just
like
kind
of
logical
unit
of
comments
together.
So
we
can
support
that,
and
you
know
if
you
plan
to
do
something
in
the
future.
A
A
Assigning
some
tasks
to
a
user
or
can
also
be
on
the
same
timeline.
So,
for
example
there.
If
there
are
two
people
which
are
working
now
on
you
know
bringing
production
up
again,
they
can
maybe
assign
you
know
who
will
run
each
command
because
you
know
they
have
more
specialization.
Maybe
you
know
database
will
be
run
by
db
admin
and
you
know
database
comments,
but
they're
still
part
of
the
same
timeline
at
least
visually
synthetic
event.
A
Let's
say
you
know
you
did
the
cd
into
a
directory
and
now
and
just
detected.
You
have
the
10
file
over
there.
Now
it
started
using.
A
Now,
let's
jump
into
sharing,
so
let's
say
we
have,
as
we
told
before,
we
have
like
two
people
working
on
on
a
problem,
so
they
might
have
two
separate
timelines,
but
they
are
working
on
the
same
issue.
So
there
should
be
an
option
when
you
share
your
timeline,
so
the
other
person
can
see
two
timelines
on
the
same
screen
on
the
same
axis
of
time.
So
if
I'm
working
on
something
I
do
want
to
know
what
you
are
doing
on
the
same
machine
or
on
the
same
system.
A
So
that
was
my
thinking,
I'm
I'm
actually
done
with
my
updates.
So
if
you
want
to
ask
something,
it's
a
good
time
or
say
something
also
good.
B
Yeah,
no
so
so
you
know,
ricardo
showed
the
python
notebook
integration
last
week
which,
to
me
solves
a
lot
of
the
issues,
especially
about
history
and
and
collaboration
that
you're
describing
now
and
it's
sort
of
become
also
the
standard
of
of
you
know,
I
think,
of
many
different
devops
stevens.
Certainly
data
operations,
team
and
sort
of
become
you
know
a
way
how
people
collaborate
on
these
types
of
scripty-
I
guess
languages
and
and
and
environments.
A
Well,
a
terminal
window
is
a
complete
up,
so
let's
maybe
compare
to
the
envisioned
ui.
Would
that
be
fair
comparison
yeah?
So
what
I
was
thinking
is,
I
actually
need
to
go
over
again.
I
think
there's
like
there
are
a
couple
of
things
which
are
bothering
me
in
notebooks
like,
for
example,
you
cannot
recreate
a
whatever
you
did
many
times,
because
there
are
some
variables
which
are
set
and
then
you
play
with
it
and
you
change
previous
steps
and
then
it's
complete
mess
and
you
cannot
recreate
whatever
you
did.
A
B
A
Yes,
but
at
least
you
will
have
the
record
of
how
you
have
observed
these
resources,
and
what
did
you
do
to
this
resources,
as
opposed
to,
let's
say,
a
cell
in
notebook
which
you
can
edit
and
you
will
never
have.
You
know
the
previous
content
of
that
cell
anywhere.
A
B
B
A
A
Yes,
except
that
when
you,
even
if
you
put
notebook
into
a
file
and
you
commit
it-
will
be
notoriously
hard
to
to
do
anything
with
this,
because
yeah
so.
B
B
A
Well,
what
I
need
to
do
actually
is
to
dig
more
into
notebooks
and
to
see
whether
the
differences
between
what
I
envision
and
notebooks
are
reconcilable
or
not.
A
Right
now,
I
think
they're,
probably
not,
but
I
need
to
check
again
what
other
things
that
I
have
noticed,
that
this
vision
for
the
ui
is
somewhat
close
to
what
they
call
a
chat.
Ops
today,
right
is
that
you
have
your
chat
and
you
know
the
commands
in
the
same
place.
Well,
the
the.
B
A
A
B
B
No
sharing
of
timeline
and
the
specific
handling
of
credentials
right
because
this
is
not
this
is
not
because
you
know,
devops
people
typically
have
elevated
credentials,
and
so
you
know
the
sensitivity
there
is
very
clear
yeah.
That's
perhaps.
A
B
A
B
Yeah
yeah
we're
in
the
notebook
you
know
set
it.
However,
you
want
to
set
it
and
that's
it,
and
so
what
is
the
chat
I
haven't
heard
about
this
chat?
I
mean
I've
heard
of
chat
bots.
I
haven't
heard
of
chat
bots
before
devops.
A
Chat,
ops,
chat,
ups,
so
yeah
the
main
idea
is
yeah.
You
want
to
communicate
while
you're
working
on
stuff,
but
you
also
want
to
see
the
comments
that
everybody
runs,
so
they
have
kind
of,
let's
say
slack,
and
there
are
several
bots
or
maybe
one
bot
connected
to
slack
and
then,
when
you
want
to
issue
a
command.
You
talk
to
this
bot
so
that
both
will
execute
the
command,
and
I
understand
that
well
at
least
some
of.
A
A
Yeah
yeah,
maybe
yeah.
I
think
that
maybe
some
of
the
boats
actually
allowing
to
run
like
shell
commands
and-
and
the
next
thought
that
I
had
okay.
So
we
have
this
ui.
Why
wouldn't
you,
for
example,
you
know
combine
it
with
bash
right,
why?
Why
do
you
need
to
have
ngs
for
that?
And
while
I
don't
have
like
really
clear
picture,
but
it
sounds
to
me
that
you
were
very
soon
run
to
run
into
a
problem
that
bash
actually
doesn't
support
structured
data
and
all
this
ui
is
about
structured
data.
A
Yeah,
because
this
was
like
kind
of
obvious
question
to
ask:
okay:
now
you
have
this
great
ui.
Why
not
bash
right
and
yes,
yeah?
I
will
need
to
review
notebooks
again
because
I
never
get
get
actually
very
deep
into
that.
I
have
like
some
shallow
understanding
of
what's
going
on.
I
have
seen
that
I
worked
with
it,
but
you
know
not
much
yeah.
So
that's
from
my
side,
the
timeline,
the
timeline
concept.
Actually,
I
was
actually
thinking
how
to
call
this
properly.
I
think
timeline
is
actually
okay
for
a
name.
A
Yeah,
no,
no,
if
and
first
thing
about
the
credentials,
I
I
was
thinking
you
know.
Maybe
there
will
be
a
server
which
runs
a
shell
and
then
you
run
those
comments
on
that.
But
then
okay,
then
your
ssh
to
the
server
and
then
what
okay?
You
have
now
the
permissions
issue,
or
even
you
know,
even
if
it's
a
browser
based,
let's
say
ui,
which.
B
B
Have
the
parse
right
so
I
want
to.
I
want
to
pass
variables
right
or
our
arguments
in
almost
as
native
right,
because
you
know
what's
the
issue
right
like
for
me
right
a
lot
of
times
the
there
are
things
in
python
that
are
just
simply
not
existing
in
ngs
right
because
of
the
community.
Support
of
you
know
vast
amount
of
libraries,
and
you
know
pandas.
A
Yeah,
so
the
first
question
would
be
what
would
be
kind
of
the
main
language
which,
which
would
be
like
the
the
wrapper,
the
shell,
no
not
sure.
B
A
Well,
actually,
yeah.
Well,
we
can
get
some
functionality
by
providing
very
small,
simple
glue
layer
which
will
be
just
able
to
convert
the
data,
so
you
run
in
js.
You
get
some
data
back.
This
data
back
would
be
converted
to
python
data
structures
and
on
the
other
way,
when
you
pass
the
data
from
python
to
js,
this
will
be.
A
Yes,
yes,
yes,
this
guys
next
question
will
be:
what
do
you
do
with
objects,
but
that's
maybe
for
later.
It
actually
reminds
me
very
much
of
my
project
that
I
already
did
when
it
was
around
2000
sometime
I
took
two
languages.
One
of
them
was
php
because
of
the
amount
of
libraries
and
another
one
of
them
was
a
lisp
because
of
the
strength
of
the
language
itself,.
B
A
I
did
I
did
exactly
this
small
wrappers
like
which
would
be
able
to
convert
the
data
structures
in
both
directions,
and
then
you
just
call
a
function,
and
you
know
it
converts
the
data
on
the
way
there
converts
to
the
data
the
way
back.
Well,
that
project
was
a
toy
project
that
didn't
actually
went
anywhere,
but
the
idea,
I
think,
while
it's
not
like
superb
integration,
it
gives
you
quite
a
bit.
B
Well,
I
mean
to
me
right:
it's
like
kind
of
you
know,
there
is
potentially
two
directions
you
can
take
right.
One
is
like
more
of
a
devops
direction,
like
you
know,
handling
of
chat,
bots
on
handheld
enough
credentials
and
stuff
like
that.
They
they
they
the
issue
with
right.
It
will
have
a
lot
of
value
for
some
people
and
have
zero
value
for
other
people,
because
maybe
they
work
differently
right.
So
it's
very
attached
to
the
very
work
that
you
do
right,
how
you
deploy,
how
your.
B
A
B
There
is
the
way
that
you
know
we
do
that
right,
but
then
there
imagine
other
people
do
it
in
a
completely
different
way,
and
so
then
your
tooling
has
to
kind
of
match
what
they
do
right
and
if
they
don't,
then,
if
they
you
know,
and
then
people
evolve
for
whatever
you
know
legacy
they
had,
and
you
know
whatever
right
and
their
problems
are
very
specific
to
their
very
specific
way.
B
A
Yeah
we
can
maybe
probably
guess
you
know
that
if
you
take
a
look
at
typical
bars
script
right
it,
you
know
very
many
times
it
starts
with.
You
know,
defining
log
function,
dividing
and
defining
error
function
and
all
that
stuff
so
that
there
may
be.
Maybe
we
can
factor
out
some
very,
very,
very
common
things
that
are
like
many
people.
Many
teams
need
right,
but
then
yeah
it's
it's
it's
a
hard
decision.
What
to
include
actually
yeah.
I
agree
it.
B
Yeah
I
mean
I
I
don't
know
if
you're
gonna
be
able
to
find
this.
You
know
great
generalization
of
hey
everybody.
You
know
it's
not
like
you're
building
c.
You
know
that
everybody
takes
code
and
runs
it
through
gcc
and
then
links
it
right
and
then
you
know
they
have
exit,
and
then
they
package
that
exit
right,
like
people
really
use
these
services
in
different
ways.
B
B
A
Yeah,
okay,
so
let's
maybe
try
to
wrap
this
up
because
half
an
hour,
that's
I
think.
Maybe
people
will
be
like
dozing.
B
A
B
A
Not
much
worse
than
others
yeah,
I
would
like
to
focus
on
the
devops
things
so
building.
A
Yeah,
that
was
the
intention
from
the
beginning.
It
did
not
change.
I
I
think
that
the
the
space
of
the
interactive
shells,
I
think
it's
completely
horrible.
You
know
what
we
have
today
and
I
would
like
to
fix
that.
B
A
Actually,
the
alternative
alternative
shells
which
are
modern
shells,
are
also
kind
of
ignoring
this
user
experience
problem
almost
completely
yeah.
They
they
look
better,
they
have
like
maybe
better
completion.
The
completion
looks
better,
but
you
know
the
interactivity
of
what's
on
the
screen.
No,
nobody
does
that.