Honestly, I simply owned the domain name and think it's mildly amusing. I wouldn't necessarily say I think it's better by any means. Not yet, at least.
There are several things I dislike about some of the existing services though:
1. Most are extremely invasive in regards to personal data and reading their terms makes it clear what their goal is (selling your data either directly or via buyout).
2. Everything constantly tries to push you through their loop: internal messaging, apps, whatever. I'm tired of it. This allows a recruiter to email a person directly.
It's all hosted on free tiers at the moment, so It's really no consequence to me one way or another.
Some changes certainly can be. If the model produces the exact same output for a fixed seed across a variety of inputs after a code change, I think it's reasonable to expect that the change is correct. There are also mathematical transformations that can be applied in some cases that are provably correct. (Not suggesting there's necessarily anything of this nature that will lead to 1,000x improvement though.)
Worth noting if it wasn't obvious from the article that Cloudflare did not develop QuePaxa. It's from an SOSP paper back in 2023[0]. The article is discussing what is the first known large-scale public deployment of the protocol.
Right. But given that the entire point revolves around QuePaxa, it's strange to see no discussion on it. If that weren't the point, the article would be "Why Cloudflare implemented and deployed Paxos".
Which would also be a good read, but this article also isn't that. It doesn't discuss their experience deploying the protocol, aside from the following statement:
> Meerkat is not deployed to production, but we have run multiple proofs-of-concept with up to 50 replicas distributed around the world, to great success. Leaders in our proof-of-concept clusters constantly fail, and the cluster keeps operating with no increase in error-rate.
I think it would've been more interesting to read why Cloudflare chose the specific algorithm they did, see an example of a pathological but common situation Cloudflare sees at their scale that makes other protocols unsuitable for them, therefore they made X choice and this led to Y gains in production (or on dummy workloads, or whatever). As it stands, there's nothing here actually specific to Cloudflare's workload or deployment. It doesn't even state their use-case beyond "small pieces of control plane state (e.g., leadership for replicated databases)"
But it's not a large-scale public deployment yet either. The article says towards the end that they just ran a proof of concept.
Maybe the blog post is just premature. It would be much more valuable if they posted it after actually having run it in production and validated the strengths and weaknesses with real world data.
The tool looks very cool! But IMO you can't get an ER diagram from SQL since entities are fundamentally different from tables. They are certainly very similar, but SQL alone doesn't give you enough information to create an ER diagram.
That's not to say that the tool is useless or that diagrams of this sort are unhelpful. I'll admit I'm being pedantic and others will probably disagree.
> entities are fundamentally different from tables
Isn't the fact that they are _mostly_ interchangeable the foundational principle of hundreds of ORMs? Of course the DDL doesn't say much about the entity's lifecycle, but if the bar is set at representing its relationships, fields and cardinality as a graph, it seems sufficient?
I think most successful ORMs have an additional layer of semantics beyond what can be directly expressed in SQL. For example, Active Record has multiple types of associations (belongs_to, has_one, has_many, etc.) that I would argue align more closely to the ER model than the relational model. Of course you can come up with a set of conventions to go from ER to relational when everything is fed through the ORM, but you are losing some semantic information in the process. (That is, if you just look at the SQL table definitions, you don't have the same information about relationships).
I don't see a problem with the tool either really, it's just a pet peeve of mine to call what it produces an ER diagram when it's really a diagram of the relational model defined by the SQL.
To make parent’s point more exact: from Chen’s definition, these ER diagrams derived from SQL are the “physical” (most low-level) diagrams, you cannot recreate the “logic” or “conceptual” diagrams from it.
I guess nowadays few people care about this difference.
the use case for sql to er, is to study a database new to you
so the db already exist, but they have no er, and maybe even little docs
so it act more like an exploratory tool, ideally, it should allow you to create views and add notes, so you dont have to look at the full er at once, especially if the number of table is huge, and if many of those tables are missing foreign keys
Can you please elaborate on the differences? They are practically interchangeable, but conceptually there might be another layer on top of entities and relationships for somewhat richer semantics (like describing a relation, or additional annotations on the entity)
One example is that in ER cardinality is specified on the relation. In SQL cardinality is implemented and can be largely reversed to ER by looking at where foreign keys are.
Many to many will lead to an extra table (which can have additional properties, requiring this table to be modelled as an entity), one to many leads to the inclusion of a foreign key to another unique key (referring all columns of that key, _id is an implementation decision, compound primary keys are possible). One to one can be implemented in multiple ways, like one to many with a uniqueness constraint by the referring table or even by merging entities to a single table.
The raw SQL can be revealing but when entities have merged into one table it’s harder to tell what is what, unless a certain set of columns appears over different tables.
Aside from what else is mentioned in the sibling comment, inheritance is another big one. Inheritance is not explicit in SQL and in fact, when going from ER to SQL, there are multiple choices you can make about how to materialize the inheritance hierarchy.
Another is that in ER diagrams, relationships themselves can have attributes. Personally I think it tends to make more sense to convert relationships to entities in this case most of the time, but it can be useful.
Finally, relationships in ER diagrams can be N-ary and connect more than two entities while foreign keys in SQL always reference one other table. Of course you can have multiple foreign keys on a table to represent this, but not without some loss of semantics.
Inheritance is one case. In an ER diagram, you may have Employee and Client entities which both inherit from a Person entity. You could choose to have these represented as a single table (with nullable fields where not relevant). They could be three completely separate tables with common fields duplicated across the tables. Or there could be three tables where one table has the common fields from Person with Employee and Client having foreign keys to this table along with whatever unique fields they have.
MacOS, Ghostty, Neovim, Pi (with a fair bit of customization to each). I'm relatively new to Pi after using Codex pretty heavily, but it's nice to be able to customize things to how I want.
I agree, I think for agents though, documentation does more harm than good. When I'm writing code with an agent I tell it to skip documentation entirely (reading or writing it) and it leads to more accurate outcomes.
When agents write most of our code, I question if we will still even need documentation.
I think that's a fair take. I think we definitely still need specs that describe the desired behavior as an artifact. But documentation describing the implementation definitely feels less important.
If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem.
setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd
Could even run it as a daemon unprivileged from a home directory with "systemd --user"
That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.
The way many including me manage systems without root privileges at runtime is by compiling immutable rootfs images that run in ram with kernel, init, mounting filesystems and assigning any users and privilege assignments, then drop to user privs.
That stuff needs to change very seldom, so when you do need to change it you just generate a new tiny rootfs image in a few seconds and reboot to pivot to it or maybe have a kexec trigger if you are feeling fancy.
For my primary workstation the entire disk is my home partition and I boot my latest rootfs from a flash drive. In other cases network boot.
For that you really only need CAP_NET_BIND_SERVICE.
The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.
The problem in most of those cases is not specifically AI. Many of the issues you cited are related to Anthropic specifically and many could have been avoided with better testing.
Yes, I am assuming the AI/LLM of choice you've implemented in your software engineering org is Claude because as far as I can tell there aren't really alternatives that come close to its quality in software.
reply