WEBVTT

00:00:00.000 --> 00:00:04.280
Why are progress bars lying to you? When

00:00:02.120 --> 00:00:06.200
you copy files, your system knows how

00:00:04.280 --> 00:00:07.840
many files there are and how much data

00:00:06.200 --> 00:00:09.880
you're moving, so they should be

00:00:07.840 --> 00:00:11.720
accurate, shouldn't they? If a process

00:00:09.880 --> 00:00:13.240
or an update starts in the background,

00:00:11.720 --> 00:00:15.360
that can cause your transfer speed to

00:00:13.240 --> 00:00:17.520
drop dramatically, and a progress bar

00:00:15.360 --> 00:00:18.920
has no way to predict that. Even with

00:00:17.520 --> 00:00:20.560
nothing going on in the background, you

00:00:18.920 --> 00:00:23.440
can still run into trouble when you're

00:00:20.560 --> 00:00:25.480
copying a combination of large files and

00:00:23.440 --> 00:00:27.040
teeny-weeny files. Program installs tend

00:00:25.480 --> 00:00:29.680
to be a little bit better, but they're

00:00:27.040 --> 00:00:32.400
still flawed because many installers run

00:00:29.680 --> 00:00:33.680
on a checklist. In reality, each step

00:00:32.400 --> 00:00:35.800
can take a different amount of time.

00:00:33.680 --> 00:00:37.920
Decompressing a massive game file, for

00:00:35.800 --> 00:00:39.800
instance, takes way longer than changing

00:00:37.920 --> 00:00:42.800
a couple of registry entries, but many

00:00:39.800 --> 00:00:44.960
installers treat both as equal progress.

00:00:42.800 --> 00:00:47.040
As it turns out, their main purpose is

00:00:44.960 --> 00:00:48.520
to reduce your anxiety, giving you

00:00:47.040 --> 00:00:51.520
visual feedback that your system [music]

00:00:48.520 --> 00:00:51.520
hasn't crashed.