HN user
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.
There are no beefy 32-bit ARM servers.
"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"
https://amperecomputing.com/solutions/arm-native
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 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.
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
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.
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, ICQ also died of spam...
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."
You're using 100GbE ... in an end-user PC? What would you even saturate that with?
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.
He said where untrusted parties aren't able to run rsync.
If I was running an rsync daemon facing the public, it would be in a chroot with dropped privileges.
If you're hosting it yourself, I would expect that you also make backups of your whole server and/or database if one is involved. A custom backup feature built into the app seems redundant.
O(n) is generally indistinguishable from O(log n) so if there is any chance of different behavior than the expected optimum, go with the better algorithm.
Why was the solution not to get rid of the linked list and replace it with a red/black tree?
Its true that rich people often (always?) "have debts", but not true that they are "in debt" overall, otherwise they wouldn't really be rich anymore. Poor and middle-class people are often in debt in the sense that they have borrowed against their future earnings. For things like a house, borrowed over 30 years, the inflation on that amount really does benefit them. By the end of the loan, people who stayed in one house barely notice the cost of the mortgage, and if the intrest rate is low enough they may choose to deliberately not pay it off as they invest their current cash elsewhere. For things like a credit card, no the inflation doesn't really help anyhing.
If deflation were expected, rich people really would just leave money in a bank account (as long as investing gave smaller returns, or seemed too risky.) The inflation is an incentive for cash-rich people to put that cash to use instead of sitting on it. This can be a huge driver for the economy.
I think every single thing Trump did during the last 3 months hurt his campaign, actually. It had just already gotten to the point where nothing he said mattered, because people were choosing him based on their experience in 2019
The most common design for a Web app on Linux in the last 20 years is to have a pool of worker processes, each single-threaded and ready to serve one request. The processes might be apache ready to invoke PHP, or mod-perl, or a pool of ruby-on-rails or perl or python processes receiving the requests directly. Java tends to be threads instead of processes. I've personally never needed to go past about 100 workers, but I've talked to people who scale up to thousands, and they happen to be using MySQL. I've never used pgbouncer, but understand that's the tool to reach for rather than configuring Pg to allow thousands of connections.
I might not be understanding what you're pointing out here. It sounds to me like sqlalchemy is talking about a pool of connections within one process, in which case releasing back to that pool does not close the connection by that process to the database. Parent comment is talking about one connection per process with 50k processes. My comment was that you don't need that many processes if each process can handle hundreds of web requests asynchronously.
If you are saying that a connection pool can be shared between processes without pgbouncer, that is news to me.
Try s6 or runit, and mdev from busybox. Mdev is not a "full featured" udev replacement, but that's sort of the point. It does just enough to get the job done and is extensible with scripts.
If you want to do the size of embedded where this matters, you also probably want a smaller libc like musl, and then buildroot and busybox are your friends.
Actually pub/sub works best when you can commit it in a transaction along with your data changes. When they are separate systems, you get a race condition where you could commit the change but crash before the event gets published.
Because there's an overhead to make a connection, authenticate, set the default parameters on the connection, etc. I've never seen a framework that closed db connections between requests.
Of course, the better design is to write a nonblocking worker that can run async requests on a single connection, and not need a giant pool of blocking workers, but that is a major architecture plan that can't be added late in a project that started as blocking worker pools. MySQL has always fit well with those large blocking worker pools. Postgres less so.