I mean if it's a strict 80/20 split the incentives are the same as a 0/100 split no?
The transit agency will choose more expensive features that do not meet a 1x ROI but do meet a 5x ROI.
Readit Newssalmonellaeater commented on US cities pay too much for buses bloomberg.com/news/articl... · Posted by u/pavel_lishin
salmonellaeater commented on The equality delete problem in Apache Iceberg blog.dataengineerthings.o... · Posted by u/dkgs
this use case of postgres + CDC + iceberg feel like the wrong architecture.
postgres is for relational data, ok
CDC is meant to capture changes and process the changes only (in isolation from all previous changes), not to recover the snapshot of the original table by reimplementing the logic inside postgres of merge-on-read
iceberg is columnar storage for large historical data for analytics, its not meant for relational data, and certainly not for realtime
it looks like they need to use time-series oriented db, like timescale, influxdb, etc
It's the wrong architecture from a dependency management perspective. Directly importing a table into Iceberg allows analytics consumers to take dependencies on it. This means the Postgres database schema can't be changed without breaking those consumers. This is effectively a multi-tenant database with extra steps.
This is not to say that this architecture isn't salvageable - if the only consumer of the Iceberg table copy is a e.g. view that downstream consumers must use, then it's easier to change the Postgres schema, as only the view must be adjusted. My experience with copying tables directly to a data warehouse using CDC, though, suggests it's hard to prevent erosion of the architecture as high-urgency projects start taking direct dependencies to save time.
This is the "confused deputy problem". [0]
And capabilities [1] is the long-known, and sadly rarely implemented, solution.
Using the trifecta framing, we can't take away the untrusted user input. The system then should not have both the "private data" and "public communication" capabilities.
The thing is, if you want a secure system, the idea that system can have those capabilities but still be restricted by some kind of smart intent filtering, where "only the reasonable requests get through", must be thrown out entirely.
This is a political problem. Because that kind of filtering, were it possible, would be convenient and desirable. Therefore, there will always be a market for it, and a market for those who, by corruption or ignorance, will say they can make it safe.
If the LLM was as smart as a human, this would become a social engineering attack. Where social engineering is a possibility, all three parts of the trifecta are often removed. CSRs usually follow scripts that allow only certain types of requests (sanitizing untrusted input), don't have access to private data, and are limited in what actions they can take.
There's a solution already in use by many companies, where the LLM translates the input into a standardized request that's allowed by the CSR script (without loss of generality; "CSR script" just means "a pre-written script of what is allowed through this interface"), and the rest is just following the rest of the script as a CSR would. This of course removes the utility of plugging an LLM directly into an MCP, but that's the tradeoff that must be made to have security.
salmonellaeater commented on The future is not self-hosted, but self-sovereign robertmao.com/blog/en/the... · Posted by u/robmao
The thing that got me into self hosting is the phone App Store. I started writing personal applications to do what the media apps on the App Store could not. The results have been amazing and the required effort is less than I expected.
What are some personal applications you created to fill these gaps?
salmonellaeater commented on Shallow water is dangerous too jefftk.com/p/shallow-wate... · Posted by u/surprisetalk
Depends where you live and the age of the child. In the first year, asphyxiation/choking and infectious diseases are more dangerous than the three on that list.
From 1 to 10, falls are by the far the biggest risk.
If you live in the US, firearms trump all of the above, but only in the US.
I think OP was saying those three things were surprisingly dangerous. Kids have a natural fear of heights and falling, while the three on the list not so much.
salmonellaeater commented on Most RESTful APIs aren't really RESTful florian-kraemer.net//soft... · Posted by u/BerislavLopac
Where this kind of API design is useful is when there is a user with an agent (e.g. a browser or similar) who can navigate the API and interact with the different responses based on their media types and what the links are called.
Most web APIs are not designed with this use-case in mind. They're designed to facilitate web apps that are much more specific in what they're trying to present to the user. This is both deliberate and valuable; app creators need to be able to control the presentation to achieve their apps' goals.
REST API design is for use-cases where the users should have control over how they interact with the resources provided by the API. Some examples that should be using REST API design:
- Government portals for publicly accessible information, like legal codes, weather reports, or property records
- Government portals for filing forms and other interactions
- Open data initiatives like Wikipedia and OpenStreetmap
salmonellaeater commented on Why not object capability languages? blog.plan99.net/why-not-c... · Posted by u/mike_hearn
It's unclear to me why the "god object" pattern described in the article isn't a good solution. The pattern in the article is different from the "god object" pattern as commonly known[1], in that the god object in the article doesn't need to be referenced after initialization. It's basically used once during initialization then forgotten.
It's normal for an application to be built from many independent modules that accept their dependencies as inputs via dependency inversion[2]. The modules are initialized at program start by code that composes everything together. Using the "god object" pattern from the article is basically the same thing.
[1] https://en.wikipedia.org/wiki/God_object [2] https://en.wikipedia.org/wiki/Dependency_inversion_principle
salmonellaeater commented on A steam locomotive from 1993 broke my yarn test blog.cloudflare.com/yarn-... · Posted by u/jgrahamc
A useful error message would have made this a 1-minute investigation. The "fix" of trying to detect this specific program is much too narrow. The right fix is to change Yarn to print a message about what it was trying to do (check for a Sapling repo) and what happened instead. This is also likely a systemic problem, so a good engineer would go through the whole program and fix other places that need it.
salmonellaeater commented on Don't Be Afraid of Types lmika.org/2025/03/18/dont... · Posted by u/speckx
> I found that there’s a slight aversion to creating new types in the codebases I work in.
I've encountered the same phenomenon, and I too cannot explain why it happens. Some of the highest-value types are the small special-purpose types like the article's "CreateSubscriptionRequest". They make it much easier to test and maintain these kinds of code paths, like API handlers and DAO/ORM methods.
One of the things that Typescript makes easy is that you can declare a type just to describe some values you're working with, independent of where they come from. So there's no need to e.g. implement a new interface when passing in arguments; if the input conforms to the type, then it's accepted by the compiler. I suspect part of the reason for not wanting to introduce a new type in other languages like Java is the extra friction of having to wrap values in a new class that implements the interface. But even in Typescript codebases I see reluctance to declare new types. They're completely free from the caller's perspective, and they help tremendously with preventing bugs and making refactoring easier. Why are so many engineers afraid to use them? Instead the codebase is littered with functions that take six positional arguments of type string and number. It's a recipe for bugs.
salmonellaeater commented on A 10x Faster TypeScript devblogs.microsoft.com/ty... · Posted by u/DanRosenwasser
That's a pretty misleading clickbait title. TypeScript isn't getting 10x faster; the TypeScript compiler is getting 10x faster.
I would argue it needs editing, as it violates the HN guideline:
> use the original title, unless it is misleading or linkbait; don't editorialize.
My initial interpretation of the title was that the TS team was adding support for another, faster, target such as the .NET runtime or native executables. The title could use some editing.