10000truths

Pooling means you're sending multiple queries (from different HTTP requests) over the same DB connection. A well-designed DB wire protocol will allow for pipelining those queries:

[send Query 1] -> [send Query 2] -> [send Query 3] -> [receive Result 1] -> [receive Result 2] -> [receive Result 3]

But in Postgres and MySQL, pipelined queries are not executed in parallel. They're just queued up for a single thread (per connection) to execute sequentially. Thus, if Query 1 is a transaction that takes too long, then it ends up blocking the execution of Query 2 and Query 3.

Every RDBMS out there has an option to configure a DB-enforced transaction timeout. But that configuration is tied to a connection, not to a transaction. So using that configuration means giving up connection pooling. Which a lot of people don't want to do because it impacts latency and DB resource usage.

Shouldn't the training data be preprocessed to transform time values to a relative coordinate system? I would expect a time-series training pipeline to contain something like:

1. Define {N = context duration, M = forecast duration} upfront

2. Select some time value T

3. Extract historical data whose timestamps lie in time interval (T, T+N+M)

4. Transform timestamp values to (-N, M) interval by subtracting T+N from each timestamp

5. Append timestamp-transformed data to training data

6. Goto 2

Or are you saying that people don't want to define N and M upfront?

A few years ago, I began to see the "labor supply" issues of slavery, and how the South was basically an economic powerhouse fueled chiefly by the labor of its enslaved people--so how do you reconcile that after the fact? How does a Union of freemen compete with that?

A large population of (deliberately kept) illiterate, uneducated people who hate their oppressors is a disadvantage to society, not an advantage. It is low-trust culture distilled to its extreme. A society like that is incapable of innovating or adapting, so it ends up leaning heavily on resource extraction. The cash crops of the South became a weak point that the Unionists exploited to their advantage in the Civil War - when the fields were razed and the shipments were blockaded, it became impossible for the Confederates to continue funding their rebellion.

I began to consider slavery as an institution that compels "employers" to provide all practical necessities for "employees". That is, room and board and clothing are all provided to the workers, in perpetuity, and this in fact granted a lot of stability and assurance.

It is not enough for a society to merely keep its people alive. The other levels of Maslow's hierarchy of needs are also important, or else your society will be unable to sustain itself, partially for the reasons I outlined above.

Now free the slaves. Wonderful! Hurrah for equality and justice! Now, however, every employee, every worker, is totally on their own for those basic necessities of life. They buy their own clothing, they find their own housing, they're paying for all their own food, and that of their families, especially their dependents. I mean, that's a huge, huge difference. How is that even possible? Sometimes it's not. Is it any wonder we've had homelessness, and the rise of the welfare state, and slavery by imprisonment? It's no surprise.

Underlying this flawed argument is the idea that a person cannot be trusted to make their own decisions about what clothes to buy, or what house to live in, or what food to eat. Why should I trust your, or anyone else's, judgment on which people to empower with self-agency? Surely you don't need to be reminded that the colonies revolted against the British for much less egregious violations of that agency?

So yes, freeing the slaves was the right thing to do. Let's never forget that! But we should also consider the economic "downsides" and the other side of the coin, so to speak, when it comes to the labor of free citizens, and what the average worker needs to do, just to survive, outside the confines of those vanished institutions.

Reaching this conclusion requires a naive ignorance of the second-order detriments of institutional slavery in a society, not to mention an utter rejection of basic free market principles. The ability of participants to choose what to do and how to spend is a good thing for an economy.

I know it's not the same but if you give a sculpture a piece of clay they do not need 10000 options to mold it. Even a carpenter or wood smith don't need that many options.

The digital equivalent of those disciplines are only a tiny subset of what people do with Blender, though. If all I need to do is shape a 3D model, I could boot up SketchUp (or a similarly "easy" modeling program) for that.

To extend your analogy: if the sculptor makes a career out of creating hour-long 60-FPS claymations with perfect interpolation between key poses, grandiose scenery, and every frame fully painted in detail, be absolutely assured that the sculptor will have an entire workshop filled with jigs, armatures, robots and any other specialized tools to speed up the process and automate everything that can be automated.

A lot of those options are necessary complexity, not incidental. 3D modeling and animation are just very complex series of tasks, you can't condense the options much without sacrificing functionality for some critical workflow. The only way to satisfy both:

a) Having lots of options

b) Making those options discoverable for beginners

is with some kind of nested categorization scheme. Any UI you create to render that will naturally converge onto a high-fan-out tree-like menu.

If that ends up happening, then the next step would be for the platform to derank listings that contain AI-enhanced photos, to set the proper incentive. That would be up to the platform to enforce, though.

The ID (and therefore the age) is checked when one goes to pick up their firearm at the local FFL dealer, so an age check on the site doesn't add anything useful.

Isn't this exactly the kind of problem that tariffs are meant to address?

I got curious what the wealth distribution looks like when normalized to account for retirement account growth. The historical average of the S&P 500's inflation-adjusted rate of return is ~7%. According to [0], the actual YoY increase of net worth between age bands is less than that:

  Median household net worth by age
  35-44: $135600
  45-54: $247200 (+6.19%)
  55-64: $364500 (+3.96%)
  65-74: $409900 (+1.18%)

  Average household net worth by age
  35-44: $549600
  45-54: $975800 (+5.91%)
  55-64: $1570000 (+4.87%)
  65-74: $1790000 (+1.32%)

May I ask where this was? This seems like the kind of thing that would be highly dependent on the wording of the laws of your municipality or state.

The UNIX pipe has the (for many systems) undesirable negative property of losing data in the pipe when the receiving process terminates: Anything in the kernel buffer of the pipe gets lost.

There are solutions for that, though:

* You can observe and/or persist intermediate data with `tee`

* You can use a named pipe, whose lifetime is bound to an inode instead of the processes

* You can dup the read end of the pipe and pass the extra file descriptor to a crash handler process

None of these are esoteric. You do need a basic understanding of Unix primitives, but any half-decent computer science course will cover them.

It all comes down to cost. At scale, testing hardware is appreciably more expensive than testing software. The former requires specialized machinery that costs the soul of your firstborn, and the logistics overhead for each do-over means long iteration times. The latter can be done with a CI pipeline for pennies worth of compute in a fraction of a working day.

While this is true, the unspoken factor here is compatibility. Fixing the design and operational model of Linux (or any Unix derivative) to a sensible default-nothing architecture requires completely changing the semantics of the OS, which would break so much existing software to the point that one might as well write a new kernel+userspace from scratch. It's a lot easier for a sysadmin to just plop their existing rat's nest in a hardware-accelerated parallel universe and say "job done".

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).

Spamming account creation won't work, because accounts need to have been created in April or earlier.

Pre-creating "sleeper" accounts is a common way of circumventing this, though it does require a degree of long term thinking/planning.

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 idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous.

Does Spring Boot terrify you, then? Or Lua scripts in nginx? Or PHP? All of these use JIT compilation to run code that handles web requests.

Attack surface is a property of the JIT implementation, not of JIT itself. And eBPF is specifically designed to be very simple to implement and audit.

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.

[0] https://en.wikipedia.org/wiki/Wickard_v._Filburn

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.