Did they remember to cover the other ones mentioned at 4:20 in the video (igloo, starfish, traffic cone, flip-flops, Eiffel tower, cotton candy, fork)?

The seahorse emoji remains my favorite for showing how LLMs are completely incapable of handling obviously false information in their training data.

One of the linked papers makes the claim that the circuitry would be less complex than that needed for floats, but also includes this note:

Floats have one advantage over posits for the hardware designer: the fixed location of bits for the exponent and the fraction mean they can be decoded in parallel. With posits, there is a little serialization in having to determine the regime bits before the other bits can be decoded. There is a simple workaround for this in a processor design, similar to a trick used to speed the exception handling of floats: Some extra register bits can be attached to each value to save the need for extracting size information when decoding instructions.

The proposed system also lacks NaN and separate positive/negative infinities, so it wouldn’t be a drop-in replacement.

I’ve managed to create a compression algorithm that reduces files down to a single bit. I call it “is this file ‘loss.png’?”.

It’s guaranteed 100% lossless with any input!

Ah, Apache Commons: for those who felt Java’s standard library wasn’t bloated enough already.

(I kid, I kid, though it was always funny just how many basic features seemed to be missing from Java back in the day despite its massive bundled library, leading to seemingly every major project adding Commons as a dependency. Not as much as thing these days AFAIK)

I feel obligated to post a link to this excellent (albeit incomplete) writeup of posits and unums, which can more accurately represent common fractions in memory at the same (or lower) bit size compared to traditional floating point.

Said page also includes the single best slightly-above-entry-level explanation of how floating point works I’ve ever seen.

Delicious, nutritious snow.

Flashbacks to the Invincible train scene.

Probably Command & Control for some sort of malware.

CD keys will be a problem for some of those. Were they on the paper sleeve, inside the jewel case, on a sticker in the manual? Who knows? Every publisher seems to have picked a spot at random and losing them makes old PC game collections a minefield of unplayable* discs.

* Without cracks or No-CD patches. Obligatory reminder that piracy = games preservation.

Tangential, but stuff like this makes me wish Intel’s Optane had taken off. It was supposed to have the persistence of an SSD with performance near that of RAM, but it was expensive and the OEMs who included it relegated it to little more than a glorified drive cache.

Imagine being able to allocate some of your spare storage as extra RAM the same way the Pi lets you decide the RAM/VRAM split. Or more realistically, sticking your swapfile on it and your build not taking several days even though you’re only working with a quarter gig of RAM.

Rule 3: SD CARD CORRUPTION

Rookie mistake. Next time store your swapfile on Google Drive so it’s their problem!

The frustrating thing about that is how they didn’t even slow down with their bullshit after that scandal, and some of the most hated DRM in recent history have a direct lineage from Sony:

• SecuROM, a widely hated DRM that limited how many times you could install a game, required online check-ins or it’d lock you out of playing, and blocked common IT tools while running, was also developed by Sony.
• Denuvo, which obfuscates and encrypts the game executable after scattering DRM checks throughout, adding extra CPU overhead and lowering game performance, was later produced by the same (former, now independent) SecuROM team.

Things started going downhill when Lenovo wasn’t fined into oblivion in the 2010s for putting malicious spyware on the laptops they sold their customers. And I mean actual literal spyware, as in “installs a root certificate and decrypts and reads all your ‘secure’ internet traffic, ostensibly so it can place random ads in it”. While also leaving gaping holes for attackers to use, of course, but letting a random program written by someone with ties to Israeli intelligence install backdoors throughout their customer base earned Lenova slightly more money so it’s all good!

And that wasn’t even the first or last time Lenovo have done something like that. They just… got a free pass, and this type of thing gradually became the norm. It’s infuriating.

Since their current cash wouldn’t fit in a 32-bit integer that’d mean it’s at least 64-bit. An integer underflow would require a debt of over 9,223,372,036,854,775,808 units-of-currency before it rolled over to positives.

Man, this bubble is even bigger than I thought! /s

Apparently there are thousands of code modules and Soong keeps literally everything in memory while calculating dependencies? Which makes me wonder what the hell the blueprint files actually do if it’s still so absurdly heavy.

Considering how the requirements went from four gigs to over thirty over the years, it wouldn’t shock me if RAM use grows exponentially with the number of modules and they just put up with it because the Google devs use cloud machines with practically infinite resources for building and therefore don’t have any impetus to fix it.

There’s a breakdown in the link in my previous comment:

Why does AOSP build consume so much memory

From my experience, building a custom ROM based on AOSP indeed requires about 30-40GB of memory. It may be more for ROMs with more requirements, such as LineageOS-based ROMs.

Just lower the number of jobs!

Well, this doesn’t work. Why? The Android build process occurs in multiple stages:

• Build dependency analysis: The build system (Soong) analyzes de build dependencies by parsing the .bp blueprint files. A dependency graph is generated to determine the build order, with relationships between thousands of modules. As far as I know, the number of jobs doesn’t matter: everything is loaded in memory, and that uses about 30 GB of memory or more with Android 14 (this includes RAM and swap). This step uses a huge fixed amount of memory, regardless of the number of jobs.

• Compilation and Linking: these steps can be run in parallel, so the number of jobs will determine how much memory will be needed. From my experience, with 8 jobs, less than 30 GB are used.

• Image generation: It is quite RAM-hungry, but I remember it consumes less than 10 GB on my build setup.

Google recommends at least 64 gigabytes of RAM for building modern versions of Android (though apparently you can get away with 16 gigs with heavy use of memory compression). Has any Android device ever even come close to having that amount?

The language restriction of not knowing the language.

Epic are currently trying to make a push into mobile after preparing the way with all those lawsuits, but their mobile app store shows they learned absolutely nothing from how poorly EGS was received.

How bad is it? So bad it doesn’t even have a library. To know which games you own, you have to browse the list of all apps on the store and find the ones that have their price replaced by a download icon.