michaelmior

This depends on what your workflow is. There are use cases for tokenization that don't always involve immediately feeding the text into a model.

Cloudflare did not develop QuePaxa, although I'm sure they did a lot of work to operationalize it. The original protocol is from a SOSP 2023 paper.

https://dl.acm.org/doi/10.1145/3600006.3613150

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.

[0] https://dl.acm.org/doi/10.1145/3600006.3613150

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.

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

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.

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.

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.

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

Humans also tend to forget to update documentation and the same confusion happens. I don't think it's really a new problem.

That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.

I don't think it's that simple, but I do think a lot of the problems mentioned are not inherent to the use of AI.

We have some very heavy users of Codex in my org and we're very happy with the quality (politics aside).

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.

I'm not saying our experience is unimportant. I'm talking about how we communicate what colors are. I'm not an expert by any means, but it seems like the way we communicate a shared understanding of what colors are is based on observing things that are the same color. I just don't think we have a way of communicating our subjective view of what a color looks like without reference to some other color.

The scenario you're describing seems like more of a language thing than a perception thing. We generally learn names of colors by references to common objects. I would argue that if people agree something is "Red, like a strawberry, tomato, or apple" then it doesn't really matter what you're seeing, that color is red.

no reason why future devices couldn't bundle 256GB of mem by default

Cost is a pretty big reason.

This article[0] provides some details. Basically if you go through the lookup process on Apple's website and you don't have an existing D-U-N-S number, you can request one from D&B for free via Apple.

[0] https://support.pushpay.com/s/article/Acquire-your-D-U-N-S-n...

At least part of that in my experience seems to be a desire to cover a number of edge cases that may not be practically relevant.

On this note, one thing I've found Codex to do is worry more than necessary about breaking changes for internal APIs. Maybe a bit more prompting would fix this, but I found even when iteratively implementing larger new features, it worries about breaking APIs that aren't used by anything but the new code yet.

One thing I've found that I've found super helpful for this is converting profiling results to Markdown and feeding it back into the agent in a loop. I've done it with a bit of manual orchestration, but it could probably be automated pretty well. Specifically, pprof-rs[0] and pprof-to-md[1] have worked pretty well for me, YMMV.

[0] https://github.com/tikv/pprof-rs

[1] https://github.com/platformatic/pprof-to-md

I worry about the costs from an energy and environmental impact perspective. I love that AI tools make me more productive, but I don't like the side effects.

This is the literal opposite of professionalism

I'm curious what definition the author is using of professionalism.

I'm surprised that Cloudflare hasn't started hosting a pre-scraped version of websites that use Cloudflare's proxy

It's entirely possible that they're doing this under the hood for cases where they can clearly identify the content they have cached is public.

The problem with that idea, that you are implying E2EE should require age verification.

I can understand why might draw that conclusion, but I would not personally support this.

Surrendering that autonomy is not.

Then you can avoid using platforms that do not offer E2EE.

Would it be a fair argument to say the police have a better opportunity to prevent crimes if they can enter your house without a warrant?

This is a false equivalency. I don't have to use TikTok DMs if I want E2EE. I don't have a choice about laws that allow the police to violate my rights. I'm not claiming that all E2EE apps should be banned.

Right, but this is worlds apart from "sharing the encryption key with a private company", is it not?

Exactly why I suggested that as a possible alternative.

Are you suggesting all messaged photos should be scanned, and potentially viewed by humans, in case it depicts a nude minor?

No, I was not suggesting that.

Yes, but this leaves the only way to identify this behavior as by reporting from a minor. I'm not saying I trust TikTok to only do good things with access to DMs, but I think it's a fair argument in this scenario to say that a platform has a better opportunity to protect minors if messages aren't encrypted.

I'm not saying no E2E messaging apps should exist, but maybe it doesn't need to for minors in social media apps. However, an alternative could be allowing the sharing of the encryption key with a parent so that there is the ability for someone to monitor messages.