drewtato

This comment is so interesting because clearly, it's the unvisited color that's broken, you know this, and you even typed it out, but it is so common for visited links to be darker than unvisited links that it makes you assume the opposite.

I'm hoping they mean the prerelease implementation was only creating leaks due to bugs that have been fixed, so a machine that runs the release implementation for the same amount of time wouldn't see such behavior.

This is also important for being able to show normal size text on smaller phones. I've got a 5.8" screen and basically every app is visually broken, with about 10% functionally broken as well. Every web or app designer should get an iPhone Mini or similar, crank the font size accessibility setting, and make sure everything works. In particular, any text that is truncated needs to have a line-wrapped version available somewhere, every page with content needs to be scrollable, and the input box needs to be functional (e.g. it must show at least one line) when the keyboard is out.

On web, use `overflow-wrap: break-word` and make sure your header can shrink.

I agree that memory size isn't going to matter much, but memory speed should be noticeable, especially on large projects.

It's definitely blending between sphere and torus, and then torus and sphere. Otherwise it would keep getting fainter as time went on.

It's nice to have something that the humans know with absolute certainty so that we know much to trust the machines.

My guess is either compression or stuff lingering in RAM. The CPU can't be smart here since it doesn't know what any of the future ifs will be. It doesn't know they're in order, or unique, or even valid instructions. You could (theoretically; the OS probably wouldn't let you) replace an if with an infinite loop while the program is running.

For resolutions over 1080, it's only VP9 (and I guess AV1 for some videos), at least from the user perspective. 1080 and lower have H264, though. And I don't think the resolutions below 1080 are enough to matter for the estimate. They should affect it by less than 2x.

The lots of videos with low view counts are accounted for by the article. It sounds like the only ones not included are private videos, which are probably not that numerous.

I was expecting to find out how much data YouTube has, but that number wasn't present. I've used the stats to roughly calculate that the average video is 500 seconds long. Then using a bitrate of 400 KB/s and 13 billion videos, that gives us 2.7 exabytes.

I got 400KB/s from some FHD 24-30 fps videos I downloaded, but this is very approximate. YouTube will encode sections containing less perceptible information with less bitrate, and of course, videos come in all kinds of different resolutions and frame rates, with the distribution changing over the history of the site. If we assume every video is 4K with a bitrate of 1.5MB/s, that's 10 exabytes.

This estimate is low for the amount of storage YouTube needs, since it would store popular videos in multiple datacenters, in both VP9 and AV1. It's possible YouTube compresses unpopular videos or transcodes them on-demand from some other format, which would make this estimate high, but I doubt it.

The most important thing is to sort by date modified by default. Usually, the file you want is very new.

After that I mostly just use "pic:" or "path:".

Most likely yes.

However, if you don't specify the argument type, it compiles fine. It's rare that you need to specify argument or return types on a closure, so it's not actually a large issue.

This is definitely not helped by Rocket. Even I, knowing Rust well, don't enjoy the way Rocket puts so much logic into attribute macros and function signatures.