I think it's totally fair, but I would assume that most Spring projects make significant DX tradeoffs compared to a full JS stack or serve an API rather than html.
1. Spring + Handlebars: You can either write the html template in a string loosing syntax highlighting and other LSP stuff, load it from a file loosing colocation.
2. Handlebars + webcomponents. They simply bundle all the web components into a single file, which breaks down when they get large and you don't need every component on every route.
3. Tailwind: Looking online you can get it working with spring boot, but the route chosen here is a script to run the cli, which again means every route ships every tailwind class used anywhere.
Maybe he was a great guy. But people change. It seems as though having your brains marinated in money is highly neurotoxic, no matter how you started off.
(Anyway: the main offence is using the term "jerk" instead of "wanker").
“But although the cliche says that power always corrupts, what is seldom said ... is that power always reveals. When a man is climbing, trying to persuade others to give him power, concealment is necessary. ... But as a man obtains more power, camouflage becomes less necessary.” — https://www.goodreads.com/quotes/1127738-but-although-the-cl...
> Most of us aren't good people at heart.
“The line separating good and evil passes not through states, nor between classes, nor between political parties either -- but right through every human heart -- and through all human hearts. This line shifts. Inside us, it oscillates with the years. And even within hearts overwhelmed by evil, one small bridgehead of good is retained”
> db9 is a PostgreSQL-compatible distributed SQL database. Your data is stored in a distributed TiKV cluster, and each database (tenant) gets its own isolated keyspace. [0]
I feel like the lede is a bit buried here, bordering on deceptive.
That or the architecture doc is wrong. Both plausible I guess, in this day and age.
Hello, the developer of db9 here. You’re right, that section is indeed a bit too brief. We will add more architecture documentation later.
What I wanted to convey is that, unlike a standard PostgreSQL, db9 is more like a pg SQL-compatible layer built on top of a large distributed KV store.
I also shared a brief introduction in this tweet, which might help clarify things. https://x.com/dxhuang/status/2032016443114733744
"Compatible" isn't mentioned on the homepage, though, despite multiple opportunities to do so -- "Create, manage and query serverless PostgreSQL", "Run history, status, and metadata live in Postgres", "Full Postgres. Fully typed.".
This lack of detail may cause folks to form the incorrect impression that this is PostgreSQL, or a fork of it, or some module or plugin for it. Folks will be upset to learn that they were misinformed. Some will assign deception as the cause, whether that is true or not.
I think your interests would be best served by trying to make that distinction clear and prominently so. So for example "A PostgreSQL-compatible, fully serverless database", or similar.
it has nothing to do with TiDB, db9 is built from scratch.A good way to think about it is that db9 is similar to tidb-server, it provides a PostgreSQL wire protocol and SQL layer, while the actual data lives in the underlying KV layer.
If it is based on TiKV, why is it built from scratch when TiDB exists? To achieve faster boot times? I think the bigger offering here is distributed-, not serverless Postgres!
Doltgres actually is a true versioned Postgres under the hood (or MySql).
This sounds really interesting, and I like the ease with which I could spin something up here and get embeddings for sure! But I would think the actual runtime perf of this would be “fine” for some text, but nowhere near Postgres level for all sorts of other stuff, right?
I am a huge fan of Postgres as a database, and of SQL, etc. but I don’t think I understand the benefit of using Postgres’ wire format here since it’s not Postgres behind the scenes. I guess that lets you use psql as the client?
PG compatible means if you built your application or analytics queries for PG SQL, it's very easy to migrate to XYZ database that takes PG SQL as input and returns the same results in most cases. The wire format means you can point your code at the database and get the same responses as normal SQL.
I agree with the commentary above that it's much clearer to describe something as "PG SQL/wire format compatible".
> I don’t think I understand the benefit of using Postgres’ wire format here since it’s not Postgres behind the scenes. I guess that lets you use psql as the client?
clients can continue using PG drivers, so author doesn't need to build and distribute his own drivers for N programming languages and M OSes.
I would be interested in a layperson summary of how this code deals with whacky distributions produced by computer systems. I am too stupid to understand anything more complex than introductory SPC which struggles with non-normal distributions.
My guess is that it's a response to "Chainguard are growing so fast that VCs have fought each other to give them hundreds of millions in 3 years despite having no AI play".
The problem is that Shopify is leveraged by DHH (who is on their board) to be the financial support referenced elsewhere in today’s discourse. Shopify is a bad actor here
Oh, this old chestnut. "Just do what the distros do".
OK, sure, let's pencil this out.
Debian has ~1k volunteers overseeing ~20k packages. Say the ratio is 20:1.
npm alone -- not counting other ecosystems, just npm -- has 3 million packages.
So you'd need 150k volunteers. One hundred and fifty thousand unpaid individuals, not counting original authors.
For one repo.
"Nonsense", you riposte. "Only maybe 100k of these packages are worth it!"
Cool, cool. Then you'd need "only" 5 thousand volunteers. Debian maxed out at 1k and it is probably the source of the most-used software in history. But sure, we'll find 5 thousand qualified people willing to do it for free.
Oh, but how do you identify those 100k packages? OK, let's use download count. Or maybe reference count. Network centrality perhaps? Great, great. But some of them will be evicted from this paradise of rigorous repackaging. What replaces them? Oh, shoot, we need humans to go over up to 3 million packages to find the ones we want to keep.
What I need distro boosters to understand is that the universe of what is basically a package manager for large C libraries is at least two orders of magnitude smaller than everything else, bordering on three if you roll all the biggest repos together. The dynamics at language ecosystem scale are simply different. Yelling at the cloud that it should actually be a breeze isn't going to change things.
There are probably 5k libraries and frameworks worth paying attention from OSS community and organization structure similar to Eclipse Foundation or Apache. The rest is either junk, low risk solo maintained project or corporate stuff maintained by someone on salary.
> Oh, this old chestnut. "Just do what the distros do"... The dynamics at language ecosystem scale are simply different.
The reason for the unwieldy scale might be the lack of proper package inspection and maintenance, which the dreaded old chestnuts do provide.
With proper package management, the number of packages will go down while their quality will go up, it's a win-win.
Can that be done for all packages at once? No, just give a mark of quality to the packages whose authors or maintainers cared to move to the new process. The rest produce a warning - "package not inspected for quality". Done!
Yes, I'm perfectly fine with setting up and recruiting volunteers for important software initiatives and no, I'm not going to do that for npm before they fix the mess they themselves created, there are more productive ways to get the job done without using npm. It's good that we have choices.
What I advised doesn't require "thousands of volunteers", you can start with one but that's not going to be me because you might be right - what Linux bistros are doing might be impossible in the npm community given the widespread 'do-first-think-later' attitude. As I said, it's good we have other choices.
1. "2FA doesn't work". Incorrect. MFA relying on SMS or TOTP is vulnerable to phishing. Token or device based is not. And indeed GitHub sponsored a program to give such tokens away to critical developers.
In 2021.
2. "There's no signing". Sigstore support shipped in like 2023.
The underlying view is that "Microsoft isn't doing anything". They have been. For years. Since at least 2022, based on my literal direct interactions with the individuals directly tasked to do the things that you say aren't or haven't been done.
I have no association with npm, GitHub or Microsoft. My connection was through Shopify and RubyGems. But it really steams me to see npm getting punched up with easily checked "facts".
reply