DaPorkchop_

How to grow boobs (in Minecraft)

It's not their fault, they've all got the mispeling vyrus.

Or worse, Excel, which translates the function names but doesn't do it automatically, so you can only open a spreadsheet if your Excel is configured to the same language as the spreadsheet was created in.

Same for German literature, tbh

I don't recall the name, but I saw something some time ago which got infinite google drive storage by creating a bunch of empty folders and packing the data into the folder names. The storage limit is the sum of the size of all your files, so if there are no files then you don't have any storage used, even if you have 100Gb of folder names.

There are stilly plenty of native libraries and the JVM itself. For instance, the networking library (Netty) uses off-heap memory which it preallocates in fairly large blocks. The server will spawn quite a few threads both for networking and for handling async chunk loading+generation, each of which will add likely multiple megabytes of off-heap memory for stack space and thread-locals and GC state and system memory allocator state and I/O buffers. And none of this is accounting for the memory used by the JVM itself, which includes up to a few hundred megabytes of space for JIT-compiled code, JIT compiler state such as code profiling information (in practice a good chunk of opcodes need to track this), method signatures and field layouts and superclass+superinterface information for every single loaded class (for modern Minecraft, this is well into the 10s of thousands), full uncompressed bytecode for every single method in every single loaded class. If you're using G1 or Shenandoah (you almost certainly are), add the GC card table, which IIRC is one byte per alignment unit of heap space (so by default, one byte per 8 bytes of JVM heap) (I don't recall if this is bitpacked, I don't think it is for performance reasons). I could go on, but you get the picture.

At a 50°F ambient temperature the fan probably doesn't have to move all too much air all too often.

/dev/sda1

The server can just reject any password hash it receives which isn't exactly hash-sized.

That sounds like a rule from The Password Game

Then you can salt+hash it again on the server.

Wait, really? I always thought bcrypt was just a general-purpose hash algorithm, never realized that it had an upper data size limit like that.