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.
It has real value for as long as there are people who need a currency that isn't controlled by a government. In other words, it's an investment in the working capital of the criminal underworld. (and tinfoil-hatters) The money you put in is probably used to commit crimes of some sort, and the money you take out was probably the result of some crime. But with coins like Bitcoin that have a distributed trust in all miners to maintain the algorithm, I don't think you can say it's a scam.
The ones I think are truly scams are the "stablecoins" and "exchange tokens", which are nothing more than a fiat currency offered by an entity smaller than a government with less accountability than a government, and no way to ensure the value/supply/demand of their coin. So yes, I think FTX was a scam to the extent that they traded FTT while printing or consuming it however they liked.
Wikipedia has a very thorough write-up https://en.wikipedia.org/wiki/Daylight_saving_time with 171 sources. What degree of certainty are you looking for? It mentions many examples of business (with emphasis on golf and golfers) who pushed to restore DST for the modern era even after the original energy-saving reasons had become obsolete.
Indeed its hard to generalize across all people. But I doubt many of those you list react favorably to the early times. Either way, they are likely not the ones wishing for permanent DST, because for some of them (like the ones waking up at clock 4:30am) it means they will go to sleep when the sun is still up (at solar 7pm) instead of after sunset.
I'm against DST because I think if people are going to wake up at solar 6am and go to work at solar 7am they ought to call it 6am and 7am instead of calling it 7am and 8am.
"Work is defined to start at 8am so lets have everyone call solar 7am '8am' so we can get everyone to go to work an hour earlier."
Now "high noon" will occur at 1pm and the middle of the night will be 1am. In Ohio (or west edge of any time zone) the middle of the day will be 2pm and middle of the night 2am. Sunburn zone in ohio? 12pm-4pm.
Sorry, the "farming" myth is one of my ocd triggers. DST is for golf courses and has never had anything to do with farming. Businesses want more daylight hours after office people get out of work to get those people to spend more money. This is the original trigger that caused the golf lobby to push congress to enact daylight savings.
The problem is the "consistent yardstick" actually. People are accustomed to start work at "8am", and react badly to being told to start work at "7am". So we change the clock so that their yardstick "8am" occurs at solar 7am and people get out of work earlier. And people now are like "lets keep summer time" which is the exact equivalent of "lets always go to work at solar 7am".
The law they passed is exactly equivalent to passing a law that puts us on winter time and starts a new requirement that schools and businesses open at 7am. We're just giving a new name to 8am.
It will all become more ridiculous 20 years from now when popular demand has lead to offices and schools opening at 9am in the winter and people start calling for a new daylight savings time to get more hours of light in the evening.
Counter anecdote: the last traditional forum that I have any interaction with was so plagued by spam that they turned off registration and the new registration system is “send an email to the admin asking for an account”. Needless to say, they aren’t a growing community anymore. They also don’t use SSL because none of their admins are fluent enough to set up LetsEncrypt. Don’t forget that lots of non-technical or less-technical people like to have forums too.