I'd be interested to see a Linux distribution whose entire shtick is to run well-behaved under a kernel with overcommit disabled. But it would be a huge undertaking. Besides the obvious issue with fork(), there are a lot of programs and libraries out there that implicitly rely on overcommit due to not checking malloc() for failure.
It's not as ludicrous as you think, for two reasons:
1. Bandwidth requirements scale quadratically with player count, since the state of each player needs to be broadcast to every player. You can optimize this with clever tricks like server-side occlusion culling, but that's heavily dependent on your specific game's mechanics, and it still doesn't address the worst case scenario of lots of players clustering in a small visible area.
2. Players are not the only entity that need to be synced. Every server-side entity affecting a client needs to have its state broadcast to that client. A dynamically destructible environment that physically interacts with players is a perfect example of this - launch a rocket at a building, compute the Voronoi fractures server-side based on impact location, sync thousands of pieces of flying concrete debris (each with its own rigid body) across all players.
I'm not sure why the author didn't attempt to dive deeper into the error message he saw. amd_vcn_dec sounds like it's an issue with the GPU's video decoding logic. If there's a timeout when trying to process a decode request, it may be that power management for the GPU is buggy somehow. Given that this is a server build and idle power consumption is likely not a big deal, I'd suggest pinning the GPU power state to see if it resolves the issue (see amdgpu.ppfeaturemask and amdgpu.runpm kernel parameters).
1. For the vast majority of CRUD apps, active sessions will be a very small fraction of the actual storage requirements. A SaaS with 100K MAU may have only 100 or so active users at any given time.
2. Sessions by definition are ephemeral. A database should not be necessary at all, an in-memory cache should suffice.
3. If you really need to distribute session data across multiple nodes, just propagate them asynchronously. Authentication and authorization are semantically idempotent operations. Having to possibly re-auth when making a cross-region request within milliseconds of logging in might be mildly annoying for the user, but consistency isn't a deal breaker here.
The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.
Queues fix throughput volatility (not throughput mismatch) at the cost of added latency. If your widget producer is producing 1000 widgets every half-hour and 0 every other half-hour, and your widget consumer needs to consume 100 widgets every six minutes, a 1000-widget queue solves the problem, in exchange for a half-hour increase in end-to-end processing time. But, as the title and article allude, your widget producer and widget consumer still need to process widgets at the same rate on average. The longer the time window needed for those averages to match, the larger your queue needs to be (and the higher the latency).
That's also why queues are inappropriate for addressing traffic spikes caused by market dynamics (celebrity news, sales events etc.). Those dynamics typically occur over the course of several hours, whereas a web request's latency SLA is on the order of several seconds.
The government may use as wide of an interpretation of commerce as they can get away with. We've seen this happen before [0]. Sure, Let's Encrypt isn't taking money from the entities they offer certificates to. But the OFAC desk jockey assigned to that case only has to concoct some sufficiently plausible-sounding trail of money connecting the backing 501(c)3 and a sanctioned entity in order to levy penalties, and the legal team will not like that risk, even if it's unlikely for OFAC to win on appeal in a court.
> That's what favorable tax treatment of long term capital gains is supposed to be for. But that's not what that tax treatment is used for.
The minimum duration for that qualification is one year. One year is nowhere near "long term" for a public works project. The Columbia shuttle took almost a decade to build. The interstate highway system took over three decades (and requires costly and ongoing maintenance).
> It shouldn't require socialism to get anything long term done.
What it ultimately requires is a trifecta of power (to fund the thing), vision (to plan the thing) and longevity (to see the thing through). Those three requirements could be satisfied by a government body or by a munificent billionaire, but democratically-minded people tend to put more faith in the former than in the latter.
One of the important functions of a government is to act as a backstop for capital-intensive investments with long-term ROIs. The interstate highway system started as Eisenhower's proposal, GPS and the moon mission were funded to one-up the Soviets, Arpanet/Internet was a DoD brainchild, and so on. All of that was enabled by Congresspeople who were willing to carve out a good chunk of the federal budget for large-scale, high-risk, long-tail-reward projects. That sort of thinking has not existed in Congress for some time (least of all during the current "starve the NSF" administration).
No. A mistake is unintentional. Go's rejection of a C runtime dependency is a deliberate trade off, and one that has served it well for its design goals.
That's because of people who treat AI like a magical "give me a finished product" button. Someone whipping up PowerPoint slides tends to care more about saving time than maintaining quality - the (usually watermarked) stock photos of yore weren't exactly the zenith of artistic presentation either.
Like any other tool, the quality of output is proportional to the quality of input. You'll get much better results if you provide specifics (detailed description of what you want, reference pictures, iterative clarifications etc.) and have it work on bite-sized pieces of the process (outlining, shading etc.), with manual verification and touch-ups in between. But all that still requires time, taste and experience, which deflates the "AI will replace skilled labor" hype.
> Inflation is caused by the government, not wealth creation. The US had zero net inflation from 1800-1914, despite incredible amounts of wealth creation. The inflation since 1914 is caused by government deficits.
> Government deficits are not caused by rich people. They're caused by the people you voted for.
I do not dispute this, but the deficit is exacerbated by a lack of tax revenue. Scrutiny will naturally move towards the people who are most able to fill the coffers.
> No, they're not. Their availability and price is determined by the Law of Supply and Demand.
I misspoke. What I meant to say is that the demand is fixed (i.e. inelastic). As you said, you can only eat so much - a poor person's subsistence will make up a much larger portion of their monthly budget than a that of a rich person.
The inequality doesn't come from the creation of wealth so much as the destruction of it. Inflation and rising prices of staple goods (there is some covariance, but the latter seems to be outpacing the former) impact poor people disproportionately hard because staple goods are more or less fixed costs. The marginal utility of an extra dollar is much higher for someone on the poverty line vs. someone who is a multi-millionaire.
SQL was designed with tabular data and a relational model in mind, and free-form documents have neither of those properties. You can shoehorn full-text search functionality into SQL - that's what the likes of MySQL/PostgreSQL/SQLite do - and it's good enough in cases where search isn't a core competency. But it's awkward to use and subject to the limitations of a syntax catered to declarative queries and rigid schemas.
Sounds like the goal here is to augment search with a sort of query language. One that's more structured than a mere list of keywords?
Ribbing aside, the "rethinking" here sounds a lot like an AI-specific spin on the "bring the code to the data, instead of data to the code" paradigm. I imagine that the same multitenancy caveats of allowing arbitrary user-defined queries against a relational database (execution limits, access controls, etc.) will apply here as well.
To be fair, my MacBook Pro had the same issue - if the battery was dead, charging via USB-C wouldn't work, it would need the MagSafe charger. Presumably because the USB controller needs power in order to negotiate power delivery.