It turns out an astroturf American football field probably weighs 1700 tons, mostly from the 6 inches of stone base under the astroturf. So 3300lbs is .00097 football fields.
Well, I'd say cross-compiling is at least a little problematic... if nothing else, it is a hurdle to running automated tests. And cross-compiling still needs to exist for the people building the package repositories. I'm just sort of advocating that if you have limited amounts of time but want to put together a system image to run in an embedded or embedded-adjacent manner, the least pain / most agile solution is by building on top of a popular binary distro and then using native compilation on appropriate hardware inside a chroot or container that resembles the target.
"Ampere processors natively support both 32 & 64 bit Android applications and require no binary translation for maximum instance density"
...
"Run up to 120+ 3D cloud game instances per socket"
...
"DRAM: 384GB - 512GB"
I've not personally tested this, but it very much appears that just like x86, you can use a 64-bit ARM kernel that has 32-bit support enabled to run a 32-bit userspace, likely compatible with docker, or even just in a chroot. Then with 120 cores, "make -j 120"
It was true in 2005, but still? As I described in another post here, a modern strategy is to get a beefy server than can run the same ABI, then start a docker container and assemble a system from Alpine's package repo, then compile a kernel and a few in-house things, then extract a subset of that into an image. No cross-compile, and most of the useful software is in pre-built binary packages with the compile-time options you would have selected anyway.
Even if you don't have a beefy server of the same architecture, you can probably run it in qemu instead of docker to the same effect. And even if qemu is slow, you can run a build of the kernel and your in-house stuff in parallel on 64 cores and not really be affected by the qemu slowdown.
I'm not familiar with the problems that would cause "target build environment often differs significantly from your server environment". If you have an ARM server, then you should be able to download and run Alpine docker images, and then fetch most system utilities from the Alpine package repo and then compile a kernel and a few other binaries on top of that, then export an image.
The main reason to not run Debian is that Debian usually makes lots of compile-time decisions for you, and chooses to maximize the enabled options of the software. Alpine makes the opposite choices for you, creating very minimal feature sets.
It's been working well for me, but my use cases is a lot more like a custom in-house DDWRT firmware kind of a thing. If you've experienced additional constraints that make this pattern unworkable, I'd be interested to hear about them.
I share some of the same observations that seem to have motivated this project, but my solution was to just use Alpine on the same architecture as the target (possibly via qemu) and then export a subset of it to a filesystem image. I implemented it as a perl module collection with no dependencies other than core perl modules, and then run the export from within the image itself. Among other things, it lets me use strace to find the runtime library dependencies of the things that need to be in the image.
Implementing a WoW classic server is actually fairly easy. The game client comes with the entire engine, art, music, and quest content. The server is basically a fancy IRC server, taking client events and rebroadcasting them to other clients.
Even many of the events are implied, like how regular attacks continue at a fixed frequency once started, so other clients only need to know when the player started attacking and whether they are still in range, and player run speed is a constant so a player running in a straight line doesn't generate additional events.
I even suspect the dice rolls are coming from a shared RNG that each client maintains independently, but haven't researched it.
This is how WoW classic was playable over a 33K modem.
We're talking about hit games created specifically as a sequel to a hit mod of another game, and communication to the community of the hit mod that this is where the developers are going, and that they should move to the standalone game if they want to thank the developers for all that unpaid work they did on the mod over the years.
It was a "hit game" while it was still a mod. They were able to find investment to graduate to a standalone game because they already had a player base in the tens of thousands.
Yeah but for $6/mo you can get a tiny linode or digital ocean droplet, and not worry about hardware failing. It's true that a laptop probably has more resources than the smallest VMs, but no remote management interface and can't scale if you suddenly had a surge of traffic.
Maybe at rendering menus and documents, but flash had graphic routines written in optimized assembly that simply weren't possible with JavaScript on that era of hardware.
I feel like people are talking past each other a bit here. FlashScript was never very fast, and rendering a document as a giant collection of bezier curves was not fast, but the people doing animations with it were getting the equivalent of modern day CSS3 animations + SVG, and it ran nicely on hardware two orders of magnitude slower than what we need for CSS3+SVG
Maybe the large number of standard library functions that operate on globals and require you to remember the "_r" variant of that function exists, or the mess with handling signals, or the fact that Win32 and Posix use significantly different primitives for synchronization? Or maybe just the fact that most libraries for C/++ won't have built-in threading support and you need to synchronize at each call site?
Unless I'm writing Java, I avoid multithreading whenever possible. I hear it's also nice in Go.
The third mitigating feature the article forgot to mention is that tmpfs can get paged out to the swap partition. If you drop a large file there and forget it, it will all end up in the swap partition if applications are demanding more memory.
But then you can just ask it to write that missing library! Some day in the future you can probably ask it to author the whole package and publish it itself.
"Oh sorry, that package doesn't exist yet, but it ought to. One moment... Ok, try installing it now."
In most of the video clips I saw, he was saying "I don't know anything about that", which could be entirely true. Often I see hints that he's attempting to play the Aes Sedai game of "speak no word that is untrue" but he's too dumb to do it well. Anyway, as an extension, both comments can be true, that Trump himself has no plan and is an idiot, but that his administration is enacting Project 2025.
If they cared about fiscal responsibility they wouldn't have passed the 2017 tax cuts, or be trying to renew them now. IMHO taxes were fine in the 2010-2017 era and if we'd just kept that, we'd be close to a balanced budget. Instead, they cut taxes (the popular part) without cutting spending (the unpopular part) and let the debt run wild under the assumption "well the economy will grow so much it will pay for itself". Well, they were half right - it caused so much inflation that the debt is effectively 30% less because dollars are worth 30% less. They want to pile on new spending (deportation) while keeping the tax cuts that they still can't find enough spending cuts to justify. The fiscal arguments are basically a joke at this point.