HN user
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.
The explainxkcd wiki says that cats were added later, and that permalinks go to a snapshot of the machine. So it's possible all the cats are lower in the machine, or the permalink is from before cats were added. There's some cats at the bottom of the machine right now. https://xkcd.com/2916/#xt=2&yt=105&v=1402
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:".
Nothing's thing was a branded version of Sunbird https://www.sunbirdapp.com/ which is technically similar to the iMessage part of Beeper Cloud. It is essentially a way for you to login with your Apple ID on a Mac Mini in a server farm, and then interact with its desktop iMessage client from an Android app.
This was done because Apple obfuscates how its notification system works, so the cheapest short-term solution is to just use real Apple hardware.
When Nothing released it, it was found to have many flaws, which is where that video comes in. Nothing unreleased it and hasn't followed up since.
Beeper Mini uses the long-term solution of reverse engineering Apple's notification system so that it can run independently of an Apple device.
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.
I get the reason, but there's no need to worry. Most people here know that links aren't personal unless it's a Show/Ask/Tell HN. You can find other examples on the front page.
HN has a thing against questions in titles because a lot of them are clickbait. I don't care about this rule but that's why it was changed.
This is removing the video stream (-vn) so that's not involved. Not sure which parts are in parallel here, but I'm guessing decoding and encoding the audio.
Barely anyone is going to go to the github, especially outside of HN, and only some of those people are going to read past the first image, so it's important that you get the most important information out there immediately. I glanced at the extended explanation and decided it would be faster to figure it out by putting stuff in the website. The instant visual feedback means you don't need to tell users every nuance of every command, but you do need to pick the specific details that users can use to learn everything else.
The syntax definitions on github are 1. not on the site, and 2. not very good, so here's some better ones:
F (fill/forward): draw a pixel and move forward
C (color): change the color
R (rotate): rotate the direction of F by 45 degrees
[ ... ] (loop): anything inside this is executed twice
I think it means error correction would be handled by a higher level.
The image itself links to the full resolution. But this is high-resolution compared to other photos of sprites, not high-resolution compared to photos in general.
Maybe this is too obvious to spend words on, but it's really weird that neither actually define eye rubbing, specifically as being with the eyelids closed. The first one even has a section for the definition of eye rubbing and fully avoids defining it.
They're not even temporarily on Discord. They're straight from Tenor.
The reaction gifs specifically (from the gif picker) are hosted by Tenor. But surely they're deduplicating the other images already. I've never seen any evidence either way.
Making temporary URLs would still help whether they're deduplicating or not. And almost certainly they're spending most of the storage on videos that have only been uploaded once. It takes a lot of 100KB images to equal a 50MB video.
Reading the title, I thought it would be this photo, which memed around Japan internet recently: https://cloudfront-us-east-2.images.arcpublishing.com/reuter...
These two exposures surely overlapped, with the known photo probably exposing for tens of milliseconds on either side of the flash, but the lighthouse exposures might not have overlapped at all, yet captured a far more exact slice of time regardless.
They say at the top that the exploit can install Pegasus, so probably some or all of Pegasus's functionality. That doesn't really narrow it down, but it likely can constantly run in the background, use the sensors, read texts, and send info over the internet at least.
I looked at the demo and apparently everyone is a sociopath? One character is literally described as "a sociopath who has no empathy". So it might be a good idea to check up on them every once in a while.
In video game terminology, higher rank words mean more graphical fidelity. Normally this is "Ultra" but "Super" is also common.
I'm also a fan of the CSS selectors page, but it's an exception. Especially for JS stuff, MDN is usually better.
This depends on how much time you want to spend. If you want the transcode to take less time than the playtime of your videos, it'll probably be best to just use the best hardware encoder you have with high quality settings.
If you have more time, then AV1 is good. Read through the trac page [1] and do test encodes with 5-10 seconds of video to determine what settings give you your desired quality. Note that low `-cpu-used` or `-preset` values will give great quality but take incredibly long. Then, encode a few minutes of video with various settings to determine what settings give you your desired file size.
For human time usage, keep track of the commands and options you use and how those affect the output. If the job will take more than a few hours, write your script to be cancellable and resumable.
This is like shortening github to git