> Arenas make lots of sense for video games, but their applicability for these other applications is much more dubious.
It's a fairly common pattern in non-video contexts to preallocate arenas of different sizes for different workload pools (e.g. different routes for a server).
It's also fairly common to allocate per-work-item (e.g. request/session/batch job) arenas for "general-purpose" scratch allocations that are small (your header parsing, auth context retrieval, etc.) and then default to a global manual/refcounting allocator for one-off large data actions like your holiday change. Since most business applications are returning summary/small aggregates over the large data action (in this example, something like "holiday updated successfully", not the entire history of the PTO table or the database connection's internal state), the copy cost of moving data between the global dynamic allocator and the arena for result transmission tends to be small.
That's not a terrible approach in some situations. If the large majority of code only needs the scratch arena and/or some per-handle allocators stored on e.g. the database connection pool, it can work well. But if, over time, the amount of bookkeeping required to maintain data tagging/movement between arenas/allocators becomes severe, it's worth stopping, stepping back, and considering that you've kind of walked backwards into inventing a shitty generational GC.
Does that extend to medical systems? If someone hacks my pacemaker and destabilizes my heart, or my pharmacy/hospital and prevents me from receiving medical care, is that something that should be legally permitted on the basis that "medical device makers/pharmacies/hospitals should try harder, and should somehow compensate their patients if a hack occurs"?
Anything network connected that can be reached by an adversary. And, I did not say it shoukd be legal or illegal, just that the fault lies with who administers/secures those systems, not with whoever breaches them.
> How do you compensate someone who's dead?
In some countries where I lived, there were pricelists based on nationality that insurance would pay out in case of accidental death. If you live in a more homogenous country, you can use other factors to determine what the payout should be.
All true, but there's a wrinkle with delegating auth in computer systems--the same wrinkle that comes up when thinking about digital data as property/copyrightable etc.: when you delegate auth, you copy the access; you don't loan it. So every digital delegated-auth scenario is like your "make a copy of your house keys" example, not your "loan out your debit card" example.
If we extend the metaphor, this would be like making a copy of your keys and handing those out every time someone other than you needed access to your house. Dinner guest? Key copy. Neighbor dropping off a borrowed tool? Key copy. Relative from out of town visiting? Key copy.
In the same way that I think most homeowners would look askance at passing out so many copies of their keys, delegated digital auth is troublesome. Nontechnical users are unlikely to pay attention to "what clients are using delegated credentials for which actions" dashboards. Revocation, while technically easy, isn't something that I think most casual users will be mindful of, resulting in endless growth in the list of principals with access to a resource (just like the "sharing passwords" scenario we have now). Time-based auto-revocation will be an annoyance for delegates who only need to access a resource rarely, resulting in exasperated administrators rubber-stamping new-delegate-credentials requests.
I don't know if there's a good solve here. Shared passwords might be the local maximum of convenience and security, but that feels pretty bad.
> That's why all your LLM requests to build something substantial should start with "run prior work research first".
Yes, but I think there are incentives to not do this for many LLM providers. Doing prior-work research is slow (web searches aren't fast, LLMs are rate-limited or blocked from plenty of pages, etc.), and sometimes contradictory which annoys LLM users, many of whom like faster gratification cycles from the agent slot machine handle.
Also, writing a bunch of bespoke code instead of leveraging prior art makes a lot of users feel like they own something novel/big/important, and also poses a larger maintenance surface for the LLM to make future changes (which costs tokens).
I don't think there's, like, a conspiracy at LLM providers to set up system prompts/RAG/etc. to discourage research-and-use-prior-art-by-default approaches. Rather, OpenAI/Anthropic/Google/etc. are optimizing for real but sometimes misleading success metrics which often lead away from a research-first approach.
I posted this because it seemed timely given that 'CGamesPlay and I were discussing this exact kind of system two weeks ago on the thread about why kernel.org's cgit (git web UI) hosting system was becoming expensive to operate due to LLM scraper load: https://news.ycombinator.com/item?id=49504674
But this is not a good analogy. Rust is being talked about explicitly as "better C++", with a huge and vocal group of online people going around and saying that the world will end if we don't rewrite everything in Rust, or that no new C++ project should be started today with Rust being available.
Very few people, if any, put R against Fortran in this way, so the fact that Fortran libraries weren't rewritten in R doesn't contradict anyone's expectations.
I ... what? I've never heard anyone conflate the two--not teenagers, non-technical adults, or software people. Most folks know that "GIF" means "moving image that can be easily shared but has no sound and usually crap quality", not a video/audio clip.
> It would set a terrible precedent for them to do so unilaterally.
Speaking generally (not about Automattic), big SaaS have law enforcement desks that work on exactly this type of thing, and the "terrible precedent" is already widely set. Plenty of law enforcement outreach (which includes lawyers, courts, and actual law enforcement officials) results in pre-emptive compliance by SaaS companies. I would be massively surprised if Slack has not already done this in many cases, because most huge companies routinely do.
That's neither generally good nor generally bad; whether it's the right move depends on the charge, requested actions by law enforcement, status of legal proceedings, and the values/diligence by which the SaaS business assesses the legitimacy and likely cost/benefit of a law enforcement request. Note that "pre-emptive compliance" doesn't always mean an email saying "hey, the FBI said you suck so we terminated your account". There's a broad spectrum of tools available to a SaaS ranging from sending that email, to holding bespoke contract re-negotiations (which are functionally always in process between a SaaS and a huge customer) hostage to endless redlining rounds, to enforcing ToS violations that the SaaS previously turned a blind eye towards due to customer size.
> Whatever the legal process this battle follows, it will be a year or two before it's even possible for a final ruling + court order
Preliminary injunctions can be issued in days to weeks, not months to years, in all sorts of civil and criminal cases in all sorts of jurisdictions. Those can take the form of "don't change stuff with your admin access" or "grant admin control to someone else"-type orders. In cases where a service administrator is materially involved, injunctions are also easy to get on the basis of evidence preservation.
That's a pretty sharp tool. Failure to comply with those opens individuals and businesses up to way more legal penalties and tighter timeframes. Even if an injunction is later vacated/dismissed/modified, the legal argument that you violated it because you knew that would happen is an extremely tough sell.
It's a fairly common pattern in non-video contexts to preallocate arenas of different sizes for different workload pools (e.g. different routes for a server).
It's also fairly common to allocate per-work-item (e.g. request/session/batch job) arenas for "general-purpose" scratch allocations that are small (your header parsing, auth context retrieval, etc.) and then default to a global manual/refcounting allocator for one-off large data actions like your holiday change. Since most business applications are returning summary/small aggregates over the large data action (in this example, something like "holiday updated successfully", not the entire history of the PTO table or the database connection's internal state), the copy cost of moving data between the global dynamic allocator and the arena for result transmission tends to be small.
That's not a terrible approach in some situations. If the large majority of code only needs the scratch arena and/or some per-handle allocators stored on e.g. the database connection pool, it can work well. But if, over time, the amount of bookkeeping required to maintain data tagging/movement between arenas/allocators becomes severe, it's worth stopping, stepping back, and considering that you've kind of walked backwards into inventing a shitty generational GC.
reply