WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

00:00:00.212 --> 00:00:01.420
DAVID J. MALAN: Hello, world!

00:00:01.420 --> 00:00:04.900
This is CS50 Live, CS50's
episodic show wherein

00:00:04.900 --> 00:00:08.440
we not only look at recent news
in tech, but also explain it.

00:00:08.440 --> 00:00:12.820
This week's focus, user
error on a massive scale.

00:00:12.820 --> 00:00:15.305
But first, a look back at
our earliest of seasons.

00:00:21.039 --> 00:00:21.580
Hello, world!

00:00:21.580 --> 00:00:22.120
This is--

00:00:22.120 --> 00:00:22.460
ROBOT: CS--

00:00:22.460 --> 00:00:23.380
RAMON GALVAN: 50 Live.

00:00:23.380 --> 00:00:25.619
I'm Ramon Galvan, filling
in today for David--

00:00:25.619 --> 00:00:27.160
DAVID J. MALAN: Who's lost his voice.

00:00:27.160 --> 00:00:29.910
RAMON GALVAN: Today he'll be the
Andy Richter to my Conan O'Brien.

00:00:29.910 --> 00:00:31.855
[MUSIC PLAYING]

00:00:54.660 --> 00:00:57.328
DAVID J. MALAN: And of course,
who could forget Season 2?

00:00:57.328 --> 00:00:58.822
[NO SPEECH]

00:01:07.300 --> 00:01:10.610
CS50 Live first looks today at GitLab.

00:01:10.610 --> 00:01:15.965
GitLab is a popular source code
hosting site, much like GitHub.com,

00:01:15.965 --> 00:01:19.460
that developers can use in order
to store their code centrally,

00:01:19.460 --> 00:01:21.800
in order to version control
it, share multiple copies,

00:01:21.800 --> 00:01:23.660
as well as share it with other users.

00:01:23.660 --> 00:01:27.470
Unfortunately, GitLab ran into
a bit of an issue very recently.

00:01:27.470 --> 00:01:30.412
The whole incident started
when they saw this.

00:01:30.412 --> 00:01:32.120
They support a feature
known as Snippets,

00:01:32.120 --> 00:01:34.160
whereby users can
create snippets of code,

00:01:34.160 --> 00:01:37.490
much like GitHub Gist, whereby users
can upload small snippets of code

00:01:37.490 --> 00:01:39.050
to share them with other people.

00:01:39.050 --> 00:01:43.100
Unfortunately, having some
1.5 million snippets of code

00:01:43.100 --> 00:01:45.260
created over the course
of just a few days?

00:01:45.260 --> 00:01:46.010
Not normal.

00:01:46.010 --> 00:01:48.680
In fact, this seemed to be the
result of some spamming behavior

00:01:48.680 --> 00:01:50.750
by some adversarial folks online.

00:01:50.750 --> 00:01:55.460
Moreover, GitLab also notice that one or
more spammers seemed to be using GitLab

00:01:55.460 --> 00:01:59.060
inappropriately, as a content
delivery network, or CDN,

00:01:59.060 --> 00:02:02.000
whereby they were serving up
files in ways that they shouldn't.

00:02:02.000 --> 00:02:04.580
Now unfortunately,
these kinds of attacks

00:02:04.580 --> 00:02:08.180
resulted in a bit of a ripple
effect on their back-end databases.

00:02:08.180 --> 00:02:10.437
Particularly, GitLab
posted the following.

00:02:10.437 --> 00:02:12.770
"We are experiencing issues
with our production database

00:02:12.770 --> 00:02:14.664
and are working to recover."

00:02:14.664 --> 00:02:16.580
Now unfortunately, just
minutes later did they

00:02:16.580 --> 00:02:19.730
post, "We accidentally
deleted production data

00:02:19.730 --> 00:02:22.430
and might have to restore from backup."

00:02:22.430 --> 00:02:23.840
Now what exactly happened?

00:02:23.840 --> 00:02:27.560
Well, it's quite common for databases
to be replicated from one to another

00:02:27.560 --> 00:02:29.430
so that you have a
primary and a secondary,

00:02:29.430 --> 00:02:32.990
the latter of which is a backup
of the former in real time.

00:02:32.990 --> 00:02:36.140
As part of the diagnosis
challenge for figuring out

00:02:36.140 --> 00:02:39.410
why the databases were slowing
down in terms of this replication,

00:02:39.410 --> 00:02:42.230
one of GitLab's system
administrators very deliberately

00:02:42.230 --> 00:02:44.550
executed a command quite like this.

00:02:44.550 --> 00:02:45.640
Now what is this command?

00:02:45.640 --> 00:02:47.660
Well at the front of
this command is "sudo,"

00:02:47.660 --> 00:02:51.710
which says execute the following
command with administrative, or root,

00:02:51.710 --> 00:02:52.760
privileges.

00:02:52.760 --> 00:02:54.230
What is the command to be executed?

00:02:54.230 --> 00:02:56.270
Well, rm -rf apparently.

00:02:56.270 --> 00:02:59.960
And rm, you might know, is to remove
files or folders from a system.

00:02:59.960 --> 00:03:02.360
-r though means recursively.

00:03:02.360 --> 00:03:05.780
Delete the following thing recursively,
so that any directories inside of that

00:03:05.780 --> 00:03:07.190
also get deleted.

00:03:07.190 --> 00:03:11.900
And unfortunately, the
"f" -rf means forcibly,

00:03:11.900 --> 00:03:15.410
which means don't even prompt
the human to confirm or deny

00:03:15.410 --> 00:03:16.910
that he or she wants to do this.

00:03:16.910 --> 00:03:20.270
Now the system administrator meant
to execute this command deliberately

00:03:20.270 --> 00:03:24.430
on their secondary database,
db2.cluster.gitlab.com,

00:03:24.430 --> 00:03:27.320
so that they could resume then
the replication from their primary

00:03:27.320 --> 00:03:28.712
to their secondary database.

00:03:28.712 --> 00:03:30.920
Unfortunately, it appears
to have been late at night,

00:03:30.920 --> 00:03:33.140
and this was a stressful
situation, and darn it

00:03:33.140 --> 00:03:38.020
if this command weren't executed
on db1.cluster.gitlab.com,

00:03:38.020 --> 00:03:40.130
the actual primary database.

00:03:40.130 --> 00:03:42.830
Now no big deal, surely we have
backups all over the place.

00:03:42.830 --> 00:03:45.100
So we can just restore from
backup, and our customers

00:03:45.100 --> 00:03:47.690
will be perfectly
happy and on their way.

00:03:47.690 --> 00:03:52.370
Unfortunately, out of five backup
or replication techniques deployed,

00:03:52.370 --> 00:03:57.140
GitLab reported that, "None are working
reliably or set up in the first place."

00:03:57.140 --> 00:04:00.650
Indeed, if you'd like to read their
whole post-mortem in which they

00:04:00.650 --> 00:04:04.730
discussed exactly what went wrong, and
how, you can check out this URL here.

00:04:04.730 --> 00:04:06.680
But the moral of the
story, for our purposes,

00:04:06.680 --> 00:04:11.390
is please, please beware
the rm -rf, especially

00:04:11.390 --> 00:04:13.730
if you're not just deleting
some directory of your own,

00:04:13.730 --> 00:04:16.820
potentially your customers as well.

00:04:16.820 --> 00:04:19.550
In other news, you might have
noticed that half of the internet

00:04:19.550 --> 00:04:23.300
went down recently, and somehow
this was Amazon.com's fault. Well,

00:04:23.300 --> 00:04:26.180
it turns out that Amazon is not
just the e-commerce site that you

00:04:26.180 --> 00:04:27.320
might know and use.

00:04:27.320 --> 00:04:29.930
They're also one of the world's
largest cloud providers,

00:04:29.930 --> 00:04:32.840
where cloud computing is
this technique whereby

00:04:32.840 --> 00:04:35.780
other people can run servers,
and have hard drives,

00:04:35.780 --> 00:04:38.270
and more services
somewhere in the world.

00:04:38.270 --> 00:04:41.210
And you as a customer can
essentially rent those services,

00:04:41.210 --> 00:04:44.700
so that your website your application
isn't hosted by you in your own data

00:04:44.700 --> 00:04:48.800
center, but in Amazon, or Microsoft,
or Google's own data center.

00:04:48.800 --> 00:04:52.940
Now unfortunately, something went wrong
with one of Amazon's cloud services,

00:04:52.940 --> 00:04:55.430
something called S3,
simple storage service.

00:04:55.430 --> 00:04:59.390
Such that the result, according to
one popular ISP called Level Three,

00:04:59.390 --> 00:05:02.870
was outages across
the US, if not beyond,

00:05:02.870 --> 00:05:05.870
because these websites pictured--
here is this heap map--

00:05:05.870 --> 00:05:08.420
were relying on at least
one of Amazon's services.

00:05:08.420 --> 00:05:12.440
In fact you might notice some familiar
names among the websites affected.

00:05:12.440 --> 00:05:17.210
Codecademy, Coursera, Docker, Giphy,
GitLab, GitHub, Heroku, Imgur,

00:05:17.210 --> 00:05:21.650
Kickstarter, Medium, Quora, Slack,
Travis CI, and many, many more.

00:05:21.650 --> 00:05:27.200
In fact, perhaps best was the irony of
a website called, Is It Down Right Now?

00:05:27.200 --> 00:05:28.792
being down right now.

00:05:28.792 --> 00:05:32.000
This is a website that typically allows
you to check other websites are down,

00:05:32.000 --> 00:05:35.300
but if you actually visited that
website during Amazon's outage, would

00:05:35.300 --> 00:05:37.320
you have seen an error like this.

00:05:37.320 --> 00:05:38.150
Now fair is fair.

00:05:38.150 --> 00:05:42.050
Some of CS50's own infrastructure
also went down during this incident,

00:05:42.050 --> 00:05:46.140
and that's because CS50 stores not
only some of its largest video files,

00:05:46.140 --> 00:05:48.740
but also the data related
to its video player,

00:05:48.740 --> 00:05:51.710
on Amazon S3, the cloud
service in question.

00:05:51.710 --> 00:05:54.890
So in fact, during that outage, if you
tried to watch one of CS50's videos

00:05:54.890 --> 00:05:58.154
in its own player, you probably
would have seen an error screen

00:05:58.154 --> 00:05:58.820
quite like this.

00:05:58.820 --> 00:06:01.910
Because the video player, which is
JavaScript, or client-side based,

00:06:01.910 --> 00:06:06.110
wasn't able to pull the requisite
data from Amazon servers.

00:06:06.110 --> 00:06:10.025
Now what is Amazon S3, and what
technically went wrong here?

00:06:10.025 --> 00:06:12.400
Well at first glance, it's
all pretty technical sounding.

00:06:12.400 --> 00:06:14.860
"Amazon S3 is a simple
key-based object store,"

00:06:14.860 --> 00:06:16.592
according to Amazon's documentation.

00:06:16.592 --> 00:06:18.550
"Keys can be any string,
and can be constructed

00:06:18.550 --> 00:06:20.500
to mimic hierarchical attributes."

00:06:20.500 --> 00:06:21.500
But what does that mean?

00:06:21.500 --> 00:06:22.708
Well, let's tease this apart.

00:06:22.708 --> 00:06:25.480
It's a key-based object store.

00:06:25.480 --> 00:06:27.970
Now an object, in this case,
just refers to files, where

00:06:27.970 --> 00:06:30.110
a file is just a whole bunch of bits.

00:06:30.110 --> 00:06:32.740
But Amazon kind of abstracts
away the notion of a file,

00:06:32.740 --> 00:06:35.860
so there isn't really the notion of
files, and folders, and all of that.

00:06:35.860 --> 00:06:39.820
There's just objects, which are,
for all intents and purposes, files.

00:06:39.820 --> 00:06:43.570
But they are accessible via keys,
which typically are strings,

00:06:43.570 --> 00:06:45.790
much like in a hash table, if familiar.

00:06:45.790 --> 00:06:48.640
You access some value by
way of some unique key.

00:06:48.640 --> 00:06:54.441
So for instance, in CS50, we posted this
first video from fall 2016 at this URL

00:06:54.441 --> 00:06:54.940
here.

00:06:54.940 --> 00:06:57.040
It's an mp4, which is a video file.

00:06:57.040 --> 00:07:00.130
Now it turns out that the
video file actually lives

00:07:00.130 --> 00:07:02.830
on a server that similarly
named, but notice what's

00:07:02.830 --> 00:07:07.930
in it, cdn.cs50.net.s3.amazonaws.com.

00:07:07.930 --> 00:07:12.130
Which is to say that indeed,
within CS50's own CDN--

00:07:12.130 --> 00:07:16.352
content delivery network-- the
data itself comes from Amazon.

00:07:16.352 --> 00:07:18.310
Now what about the key
that uniquely identifies

00:07:18.310 --> 00:07:20.590
our objects, or videos, or other files?

00:07:20.590 --> 00:07:25.210
Well this string here with slashes, and
words, and so forth, looks like a file

00:07:25.210 --> 00:07:27.130
inside of a bunch of folders, but--

00:07:27.130 --> 00:07:29.800
that's fine to think about
it that way-- but it really

00:07:29.800 --> 00:07:33.350
is just a unique string
that resembles a file path.

00:07:33.350 --> 00:07:36.370
We've adopted a scheme whereby
it looks like these are folders,

00:07:36.370 --> 00:07:40.210
simply because it keeps our
data nicely hierarchical.

00:07:40.210 --> 00:07:42.400
So what went wrong,
and what did users see?

00:07:42.400 --> 00:07:44.680
Well, if you visited
Amazon's status page

00:07:44.680 --> 00:07:47.980
on the day in question-- or the
days prior to the days in question--

00:07:47.980 --> 00:07:50.290
you would have seen
beautiful green check marks,

00:07:50.290 --> 00:07:53.830
from February 27 on back,
whereby all was well.

00:07:53.830 --> 00:07:57.580
Green check means good for
the S3 storage service.

00:07:57.580 --> 00:08:00.820
Unfortunately, on February 28,
did this thing rear its head.

00:08:00.820 --> 00:08:03.850
And suffice it to say, red icon bad.

00:08:03.850 --> 00:08:07.954
In fact, in this case it means half of
the internet would appear to be down.

00:08:07.954 --> 00:08:10.120
Now, you can read more on
the details of this story,

00:08:10.120 --> 00:08:12.790
but let's take a look at
a few of the key moments.

00:08:12.790 --> 00:08:17.330
At 2:37 PM Eastern Time on
February 28 did Amazon report this.

00:08:17.330 --> 00:08:19.270
"We can confirm high
error rates for requests

00:08:19.270 --> 00:08:23.320
made to S3 in the US EAST-1 Region.

00:08:23.320 --> 00:08:26.710
We've identified the issue, and are
working to restore normal operations."

00:08:26.710 --> 00:08:27.980
Well what does that mean?

00:08:27.980 --> 00:08:31.709
Well US EAST-1 Region is simply
one of Amazon's data centers.

00:08:31.709 --> 00:08:34.000
Like a lot of cloud providers,
they have data centers--

00:08:34.000 --> 00:08:36.760
buildings with lots of servers
and lots of hard drives and more--

00:08:36.760 --> 00:08:38.110
all over the world.

00:08:38.110 --> 00:08:40.990
And US EAST-1 happens to
be one of the most popular.

00:08:40.990 --> 00:08:44.530
It's physically located in northern
Virginia, in the United States.

00:08:44.530 --> 00:08:48.430
And because CS50 isn't all that far
away, in Cambridge, Massachusetts,

00:08:48.430 --> 00:08:52.810
much of our assets live in
US EAST-1 one by choice.

00:08:52.810 --> 00:08:54.190
In fact, it's a trade-off.

00:08:54.190 --> 00:08:57.840
We could absolutely replicate our data
across multiple, multiple regions,

00:08:57.840 --> 00:09:00.340
and have been much more tolerant
against this kind of fault,

00:09:00.340 --> 00:09:02.920
but it's a trade-off between
how much storage you need,

00:09:02.920 --> 00:09:06.190
how much money it might cost, and how
much complexity you have to introduce.

00:09:06.190 --> 00:09:09.650
So we very consciously put
much of our data in US EAST-1

00:09:09.650 --> 00:09:12.260
so that it's as close
to campus as possible.

00:09:12.260 --> 00:09:17.152
Now, Amazon explains that the
reason S3 became inaccessible,

00:09:17.152 --> 00:09:18.860
and in turn, so many
of these customers--

00:09:18.860 --> 00:09:21.670
CS50 among them-- went
offline was as follows.

00:09:21.670 --> 00:09:25.120
"The team was debugging an issue
causing the S3 billing system

00:09:25.120 --> 00:09:27.100
to progress more slowly than expected."

00:09:27.100 --> 00:09:27.830
OK.

00:09:27.830 --> 00:09:31.420
"An authorized S3 team member,
using an established playbook,

00:09:31.420 --> 00:09:36.130
executed a command which was intended
to remove a small number of servers

00:09:36.130 --> 00:09:40.090
for one of the three S3 subsystems
that is used by the building process."

00:09:40.090 --> 00:09:41.440
OK.

00:09:41.440 --> 00:09:45.840
"Unfortunately, one of the inputs to
the command was entered incorrectly,

00:09:45.840 --> 00:09:48.880
and a larger set of servers
was removed than intended."

00:09:48.880 --> 00:09:50.950
In other words because of human error.

00:09:50.950 --> 00:09:54.820
Literally a typographical error in
the equivalent of a terminal window.

00:09:54.820 --> 00:09:58.000
Mistyping a command, did
Amazon take offline--

00:09:58.000 --> 00:10:00.790
not just a few servers meant
to diagnose some problem--

00:10:00.790 --> 00:10:02.950
but a huge number of servers.

00:10:02.950 --> 00:10:06.430
All of which then need to be
rebooted, which takes some time,

00:10:06.430 --> 00:10:08.290
and which explains the downtime.

00:10:08.290 --> 00:10:11.530
In the real world, this might
be like if Amazon were hungry

00:10:11.530 --> 00:10:14.740
for a little bit of
chocolate, and so went over

00:10:14.740 --> 00:10:18.850
to the chocolate serving station,
and picked up this here X-ACTO knife,

00:10:18.850 --> 00:10:21.670
and just wanted to take a tiny
little piece of the internet offline

00:10:21.670 --> 00:10:23.320
so as to enjoy some chocolate.

00:10:23.320 --> 00:10:26.280
And so you might just take
off a little corner like this.

00:10:26.280 --> 00:10:29.090
Mm-mm, that's a good server.

00:10:29.090 --> 00:10:31.420
But that's not what Amazon in fact did.

00:10:31.420 --> 00:10:34.960
Amazon, because of a mistyped command,
for which apparently there was not

00:10:34.960 --> 00:10:37.600
a sufficient prompting
process to say, "Human are you

00:10:37.600 --> 00:10:40.210
sure you want to take
down all these servers?"

00:10:40.210 --> 00:10:50.370
Amazon effectively took out this
here saw, turned it on, and bit off

00:10:50.370 --> 00:10:53.496
half of the internet.

00:10:53.496 --> 00:10:56.032
Mm, that'd good internet.

00:10:56.032 --> 00:11:00.040
But, CS50, to be fair, is not
immune to these kind of mistakes.

00:11:00.040 --> 00:11:03.270
In fact, here on CS50 Live,
we've made our own fair share.

00:11:03.270 --> 00:11:09.540
In fact, why don't we take a look now
at some of CS50 Live's own outtakes.

00:11:09.540 --> 00:11:10.320
Hello, world.

00:11:10.320 --> 00:11:11.170
This is--

00:11:11.170 --> 00:11:11.670
ROBOT: CS--

00:11:11.670 --> 00:11:11.990
DAVID J. MALAN: 50--

00:11:11.990 --> 00:11:13.040
RAMON GALVAN: Live.

00:11:13.040 --> 00:11:15.623
DAVID J. MALAN: So if you see
me trip, if you see me misspeak,

00:11:15.623 --> 00:11:18.300
if you screw up, all of that is
happening literally right now,

00:11:18.300 --> 00:11:20.205
in Cambridge, Massachusetts.

00:11:20.205 --> 00:11:21.600
Oh hi, world.

00:11:21.600 --> 00:11:22.540
Drumroll.

00:11:22.540 --> 00:11:23.729
Perspect-- or, per second.

00:11:23.729 --> 00:11:25.020
Pause the vizio if you'd like--

00:11:25.020 --> 00:11:27.340
Book redder.

00:11:27.340 --> 00:11:27.990
[INAUDIBLE]

00:11:27.990 --> 00:11:32.580
Mark Zuckerberg's favorite patent,
to protect our nuclear missile.

00:11:32.580 --> 00:11:34.330
Keeping [INAUDIBLE] as usual.

00:11:34.330 --> 00:11:35.250
Bugle itself--

00:11:35.250 --> 00:11:36.000
[INAUDIBLE]

00:11:36.000 --> 00:11:37.230
Good episode for you.

00:11:37.230 --> 00:11:38.280
It's actually quite--

00:11:38.280 --> 00:11:39.700
Fine-- and--

00:11:39.700 --> 00:11:40.980
Then you may recall--

00:11:40.980 --> 00:11:42.720
Ted to this you are here.

00:11:42.720 --> 00:11:44.360
TECHNICIAN: This is CS50-- gah.

00:11:44.360 --> 00:11:46.360
DAVID J. MALAN: And now
I made the blooper reel.

00:11:46.360 --> 00:11:47.130
Fantastic.

00:11:50.974 --> 00:11:52.390
SPEAKER 1: Let me read you ending.

00:11:52.390 --> 00:11:54.150
That should be the ending.

00:11:54.150 --> 00:11:57.560
DAVID J. MALAN: Photos of Jason
Hirschhorn dressed as a pumpkin.

00:11:57.560 --> 00:11:58.680
JASON HIRSCHHORN: Oh boy.

00:11:58.680 --> 00:12:00.430
I don't know if I want
people to see that.

00:12:00.430 --> 00:12:04.020
DAVID J. MALAN: No, now it's photos of
the Jason Hirschhorn dressed as a boy.

00:12:04.020 --> 00:12:05.280
SPEAKER 2: And if you're
interested, I can actually

00:12:05.280 --> 00:12:06.571
show you how it's going to be--

00:12:06.571 --> 00:12:08.250
DAVID J. MALAN: Yeah, absolutely.

00:12:08.250 --> 00:12:09.440
SPEAKER 2: He's a little
off balance this morning,

00:12:09.440 --> 00:12:10.868
he hasn't had his coffee yet.

00:12:10.868 --> 00:12:12.820
[BUS HONKING]

00:12:12.820 --> 00:12:13.796
SPEAKER 3: Whoa!

00:12:13.796 --> 00:12:14.772
Oh god.

00:12:19.994 --> 00:12:20.910
DAVID J. MALAN: From--

00:12:20.910 --> 00:12:21.841
where's he from?

00:12:21.841 --> 00:12:24.840
SPEAKER 4: Right where my arm is, you
can see like the white characters.

00:12:24.840 --> 00:12:26.120
There is the pole.

00:12:26.120 --> 00:12:28.410
DAVID J. MALAN: And they don't know
that this is-- you should point here.

00:12:28.410 --> 00:12:28.993
SPEAKER 4: Oh.

00:12:37.155 --> 00:12:38.780
DAVID J. MALAN: Can you hear me, world?

00:12:38.780 --> 00:12:39.905
RAMON GALVAN: Hello, world.

00:12:39.905 --> 00:12:41.760
Welcome to CS50 Live, I'm Ramona Galvan.

00:12:41.760 --> 00:12:43.090
DAVID J. MALAN: And I--

00:12:43.090 --> 00:12:45.560
And I'm David Malan.

00:12:45.560 --> 00:12:48.607
RAMON GALVAN: And today I'm
hosting today's episode.

00:12:48.607 --> 00:12:49.690
DAVID J. MALAN: But with--

00:12:49.690 --> 00:12:52.566
RAMON GALVAN: [BEEP] OK, OK.

00:12:52.566 --> 00:12:54.930
TECHNICIAN: Don't say [BEEP] on the air.

00:12:54.930 --> 00:12:58.490
RAMON GALVAN: He'll be the Robin to my
Batman, the Andy Richter to my Conan,

00:12:58.490 --> 00:12:59.820
the Cheech to my Chong today.

00:12:59.820 --> 00:13:02.320
It's most definitely a serious
thing that we're doing today.

00:13:02.320 --> 00:13:03.507
This is not a joke.

00:13:03.507 --> 00:13:06.340
Dropbox had made quite a fuss lately,
but I know nothing about this.

00:13:06.340 --> 00:13:07.310
What is this about?

00:13:07.310 --> 00:13:08.650
That was all above me.

00:13:08.650 --> 00:13:13.600
And this-- is something I don't know of.

00:13:13.600 --> 00:13:15.720
We also took a tour of Third Glass--

00:13:15.720 --> 00:13:16.462
Third Deg--

00:13:16.462 --> 00:13:17.920
DAVID J. MALAN: [BEEP] right there!

00:13:17.920 --> 00:13:22.591
Allows you to swipe credit cards on your
iPhone in order to process payments.

00:13:22.591 --> 00:13:24.440
RAMON GALVAN: I have a flip phone.

00:13:24.440 --> 00:13:25.315
Let's play the clip.

00:13:27.870 --> 00:13:30.650
DAVID J. MALAN: To host the first ever--

00:13:30.650 --> 00:13:31.390
RAMON GALVAN: OK.

00:13:31.390 --> 00:13:32.560
To host the first ever--

00:13:35.590 --> 00:13:37.410
DAVID J. MALAN: I was
in graduate school.

00:13:37.410 --> 00:13:39.076
RAMON GALVAN: And I was in fourth grade.

00:13:39.076 --> 00:13:41.740
Although I loved Zamyla, I
would much rather not spend--

00:13:41.740 --> 00:13:42.760
DAVID J. MALAN: Spend half
as much time with her.

00:13:42.760 --> 00:13:43.676
RAMON GALVAN: Exactly.

00:13:49.870 --> 00:13:52.000
DAVID J. MALAN: Come on out, Zamyla!

00:13:52.000 --> 00:13:53.860
RAMON GALVAN: This was CS50.

00:13:53.860 --> 00:13:55.546
DAVID J. MALAN: And this was terrifying.

00:13:55.546 --> 00:13:56.920
RAMON GALVAN: This is terrifying.

00:13:56.920 --> 00:13:59.590
Made a nice little teaser reel
girl to kind of encapsulate

00:13:59.590 --> 00:14:02.110
the debauchery that took place.

00:14:02.110 --> 00:14:04.180
DAVID J. MALAN: I love you.

00:14:04.180 --> 00:14:07.870
RAMON GALVAN: I love you,
unlike David who circles you.

00:14:13.250 --> 00:14:16.420
DAVID J. MALAN: Rumors that-- oh

00:14:16.420 --> 00:14:17.860
That's it for CS50 Live.

00:14:17.860 --> 00:14:21.610
Thanks so much to CS50 Live's whole
team, Arturo, and Ian, and Christian,

00:14:21.610 --> 00:14:25.810
and Doug, and Marina, Marinda, Dan
Coffey, and Cynthia for our brand

00:14:25.810 --> 00:14:26.770
new set.

00:14:26.770 --> 00:14:29.350
This was CS50.