nrdvana

My email (postfix and dovecot), my personal website (nginx, traefik, and various apps I've written), my IRC web client (thelounge), and git repositories (gitolite) all comfortably run in 1gb of ram. Sadly it isn't enough for GitLab, but I've been meaning to attempt Gitea on it.

Yeah but the one they decided the AI was close to solving may have been so because the researchers' progress on this problem became part of the training data for that AI...

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.

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 interested to hear counterexamples, though.

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.

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

I still hate touch and would still buy a keyboard phone if anyone was making a good one

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.