> You'd think theft would still be illegal regardless of what a privacy policy says.
I wish that were true, but I live in the United States and it is 2026.
The President of the United States rug-pulls memecoin crypto and regularly pardons people like Paul Walczak (who was convicted of massive payroll fraud) in exchange for large donations.
I wouldn't make any assumptions about what is considered theft anymore, at least not when it is being committed by people who have enough money to be above the law.
I think people get hung up on high availability (HA), and ironically don't test their backups. Single node with streaming backups to S3 (simple in a single writer system) can give you a system that will at most lose a few seconds of data (interestingly RDS has a 5 minute window of dataloss).
Multi node systems tend to have more failure modes, so fail more often, high availability is not free.
If you replicate data between two nodes (that are note async backups). You have to maintain strong data consistency. So writes to the database are considered successful only if the data is written to both nodes. If either node became unavailable you'd be unable to write anything without sacrificing consistency, reducing our overall availability rather than improving it. Also increasing latency.
This is why the whole multi node HA push by the industry is so laughable. A lot of time it makes systems more fragile.
I'm surprised the faster decompression speed of zstd wasn't mentioned. Feels like a big win for cache (assuming decompress on read).
A shame browsers don't support concatenating zstd frames (which zstd does support). Then you wouldn't need to decompress, just serve zstd straight to the browsers after concatenating the frames you care about.
Wait, what? Don’t browsers support concatenated zstd streams?
My reading - and I care because I’ve been using concatenation tricks in parquet - is that this is required by the standard.
In the distant past I made a jinja2-like template system for server side rendering that precompressed the static bits and injected the short dynamic bits into the output stream as literals with some basic lz match rewriting in the following chunks etc. This kind of trick ought be better with zstd frames.
There's negative levels for faster decoding and compression. level -1 uses half the CPU of level 1 and with a custom window size can be really good for streaming compression. I think the negative levels go down to -7 if I remember correctly?
I think a lot of the time when people say the network is slow. They really mean their backend is slow.
With a fast backend ~1-5ms response times (not even that fast). Streaming compression over something like SSE to keep your response sub 1kb packet (roughly an ethernet MTU).
With a push based model, pushing data to a user is half their RTT latency. They will only experience their full RTT on actions they trigger.
Now the network to you is distance to the server (not your rail/nextjs backend taking 400ms). Things like 4G and 3G are fine. The real problem is when you have such bad signal you effectively have no down or up.
I don't know how hard it is. But I can certainly say there is no business inscentive for it.
When it comes to improving performance by a few ms, or implementing a new feature, business people will always choose a new feature, unless the current performance is unbearably slow (we're talking regular 1.5s+ wait times for BE response).
And it's not even a modern problem, legacy software written 20 years ago has the same latency than most modern backends from my experience.
> With a fast backend ~1-5ms response times (not even that fast).
Even though benchmarks suggest this sort of performance should be trivial, most real-world servers I have interacted with do not reliably managed to process a request, make a roundtrip to the DB, and return a response in <5ms
Project into sqlite on your app server is the main trick I use. Denormalize if you have to.
Hell, for a lot of projects you don't even need to get that fancy. Run a single server with an embedde database, running Go or Java and you're good to go.
This is why my theory is LLMs are self defeating in large orgs. Or worse terminal for the organisation.
For everyone adding value with LLMs there will be way more destroying value. If you roll a critical failure a mediocre LLM enhanced VP convinces the org to sail aggressively in the wrong direction.
Judging by the amount of insider interviews it's more than just ads.
Longtime subscriber. Pretty disappointed in how biased their coverage is.
The most critical piece they have put out on AI is oh no it's so powerful it's hacking everything. It's like being in a job interview and saying your biggest weakness is you work too hard.
>Longtime subscriber. Pretty disappointed in how biased their coverage is.
>The most critical piece they have put out on AI is oh no it's so powerful it's hacking everything. It's like being in a job interview and saying your biggest weakness is you work too hard.
What do you think they've missed? Otherwise, all you've demonstrated so far is "their stance on AI doesn't match mine", not that they're "biased". If I was reading HN 5 years ago it would be people saying how economist is biased for or against crypto because the most critical/supportive piece doesn't say it'll go to 0, or will replace all of finance, respectively.
But, for me it's not so much that it doesn't match my view. I'm honestly mixed on the whole thing (I am probably most concerned about the finances). It's more that the articles they write seem to align with the eb and flow of anthropics media tempo. This week it's FOMO, next week it's panacea, hack all the things week, followed by mild financial concerns with a but it will be fine tacked at the end. The articles tend to lack concreteness too. Maybe, it's just what reading The Economist is like when it's a domain you actually understand and follow closely?
Honestly, though I could probably say the same for a lot of publications these days.
reply