big_whack

Does email work on iOS?

This is one of the ostensible guiding principles of the Washington Post: "The newspaper’s duty is to its readers and to the public at large, and not to the private interests of its owners."

Independence from ownership isn't really a left/right principle. The Washington Post has their set of guiding principles online - I think from those it's pretty clear why there is discontent.

https://www.washingtonpost.com/about-the-post

Sorry, but someone who is averse to joins is not a non-expert in SQL, they are a total novice. The answer is like any other programming language. You simply must learn the language fundamentals in order to use it.

It's not really a problem of there being combinatorially many ways to join table A to table B, but rather that unless the join is fully-specified those ways will mostly produce different results. Your tool would need to sniff out these ambiguous cases and either fail or prompt the user to specify what they mean. In either case the user isn't saved from understanding joins.

Once you have SQL, you have datalog. Once you have datalog, you have SQL. The problem isn't the target, it is getting sufficiently rigorous and structured output from the LLM to target anything.

I think the problem is the quirkiness on the English side, not the SQL side. You could translate datalog to SQL or vice versa, but understanding intention from arbitrary english is much harder. And often query results must be 100% accurate and reliable.

I don't really know much about India but they seem to have more illegal immigration than the US does and per https://www.bbc.com/news/world-asia-india-50670393 seem like they have discussions about amnesty there too. My assumption would be that any regional economic power with long borders will struggle with illegal immigration.

On the OP's resume, they claim to have written the "highest performing in-memory database in the world". It's here: https://github.com/carrierdb. There are no users.

Perhaps it is the highest-performing in-memory DB in the world, but it's a competitive space and the claim is extremely grandiose. If I were hiring my assumption would be it's BS. I would recommend the OP collapse the resume to a single-page PDF and ensure it contains only supportable claims.

You seem to think you're disagreeing with me but afaict you're just demonstrating my point, unless your point is just about how (int, int) will get packed. That's what I meant about the column order of indexes. If you have two ints and a bigint, but you need to index it like (int, bigint, int), then you aren't gaining anything there either.

As your example shows, there is no benefit in index size (e.g for supporting FKs) in going from int to bigint for a single key. You end up with the same index size no matter what, not twice the size which was what I took your original post to mean.

Postgres pads tuples to 8 bytes alignment so an indexed single-column int takes the same space as an indexed bigint. That's the usual case for indexed foreign keys.

Differences can appear in multicolumn indexes because two ints takes 8 bytes while two bigints takes 16, however the right layout of columns for an index is not always the layout that minimizes padding.

Reconfiguring tables to use a different kind of unique ID (primary key in this context) can be a much bigger pain than an ordinary column rename if it is in use by foreign key constraints.

If you use a surrogate key, you still need a unique constraint in the table (probably the same columns you would otherwise call your natural PK). If your unique constraint isn't sufficient to capture the difference you mention, you need to add more columns.

However, that's strictly better than the natural PK situation, where you would need to not only add new columns to the key, but also add those columns to all referencing tables.

This is an interesting read. I noticed also that Roscoe Bartlett, the rep running that hearing, moved entirely off the grid after retirement.

https://en.wikipedia.org/wiki/Roscoe_Bartlett#Personal_life

My reading dropped off for years until I got a kindle. The kindle made reading way more convenient and portable. Totally changed my life.

Were you working on that at BD? Who is designing kinematics around Atlas? I understood it to have no users.

My guess is orgs that have a real need for a distributed SQL database (which are rare in the space of orgs) will make their choices based on requirements analysis rather than naming.

So probably if you would be turned off enough by the name not to use the software, you don't actually need a distributed SQL database and are not the target customer.

I would distinguish between "local dev environment" and "debugging specific data-dependent customer issue".

My experience is you can usually write the application with no dependencies on customer data, and do local development entirely with synthetic data.

For debugging specific customer escalations or understanding data distributions for your synthetic data modeling, you can use a replica of production. No need to extract just a subset or have devs host it themselves. All access can be controlled and logged this way.

Better than a replica would be something like [1] but that isn't available everywhere.

I agree the problem of "dump a DB sample that respects FK constraints" comes up sometimes and is interesting but I'm not sure I'd use it for the problem you describe.

[1] https://devcenter.heroku.com/articles/heroku-postgres-fork

It would take at least 500-1000 years for the life expectancy to rise to 500-1000 years. Pretending that is very soon, or that people in significant number could even afford that ability after the tech existed (which it won't), seems out of touch.

I think your observation is why you read a lot more about Phillips these days than RFK.

RFK's promoters switched to promoting Phillips when they realized RFK was drawing more conservatives for the antivax stuff, than democrats for the Kennedy name.

There's nothing wrong with competition within the party -- that's just a primary. What should clue you off is that Phillips announced yesterday he's considering a third-party run.

RFK's campaign is also a spoiler, propped up in part by the same people. My sense is what happened is they realized he's a little too crazy to be effective, so they are hedging their bets with Phillips.

Exactly the same story though.

That's not really the point, the point is it's not an honest campaign. Elon Musk isn't donating money because he thinks Phillips will win, he's doing it because he thinks it'll help Trump win. Because Phillips needs to act soon, he can't wait as he says until Joe Biden appears unable to win. He needs to make that assessment in a week or two, before the general campaign even really starts -- so it isn't honest.

IMO it is fine to run for president, and to vote for whoever you want. But running a campaign that is really intended to just give the edge to another guy, is dirty politics intended to fool voters with an illusion of choice.

When the richest people in the country engage in those tactics, isn't democratic, it's plainly oligarchic.

Dean Phillips seems relevant to this community. He has proposed cabinet positions for Elon Musk and Bill Ackman, and announced yesterday that he might be interested in running in the general under the No Labels ticket.

My understanding is that to make that work, he would need to switch parties pretty soon in order not to be affected by sore loser laws in many states that would prevent him from switching parties after the primary.

To me he appears to be an obvious Republican spoiler effort pushed by some of the wealthiest people in tech including Musk and Altman. If it were my boss pushing this I would be incensed.

Much cruder fakes than you are describing are a huge problem in practice, costing billions per year in fraud to Americans alone. Just because you can detect them, doesn't mean your grandma can.

The societal implications of undetectable fakes are off the charts.

Do you make your living as an artist?

When I was in college, I think you could have pretty easily hired college students to do food delivery on campus at minimum hourly wage. They would have been happy for the cash.

I see basically zero chance of consumer delivery robots being economical. Self-driving cars also have a low chance of panning out IMO -- it will not take many more incidents to kill the industry -- but if self-driving cars did pan out it would at least be a service I would use.

In contrast to SDCs, the delivery robots I have seen are bulky and take up a lot of sidewalk space. In contrast to delivery people, they don't climb stairs. If they did climb stairs, I don't want to be stuck behind one. As with SDCs, most people hate these things.

I think if they were humanoid-shaped it would help with some issues (take less space, climb stairs) but introduce other issues (less carrying capacity, far more complex/expensive). The only consumer-facing robot I've seen so far that solves a problem in my life, is the Roomba+competitors. I'm pretty skeptical that consumer robotics will be a big part of the future.

I feel like there are a couple different points -

* The immutability, lambda architecture points I agree with. I think the separation of the immutable log from the views is important. Databases are frequently used in ways that go against these principles.

* I am not sold that being unable to express the domain model correctly is really a fair criticism of databases. Most businesses in my experience have a domain that is modeled pretty well in a relational DB. I haven't seen a better general solution yet, though I haven't checked out Rama.

At the low end of the scale, there are a lot of companies (or projects) for which the entire dataset fits in a single managed Postgres instance, without any DBA or scalability needs. They still suffer from complexity due to mutable state, but the architectural separation of source of truth vs "views" can be implemented inside the one database, using an append only table and materialized views. There are some kinds of data that are poorly modeled this way (e.g images) but many kinds that work well.

So I don't really view the architectural ideas as repudiating databases in general, more as repudiating a mutable approach to data management.

A lot of the commenters seem like database fans instinctively jumping to defend databases. The post is talking about contexts where you are dealing with petabytes of data. Building processing systems for petabytes has a separate set of problems from what most people have experienced. Having a single Postgres for your startup is probably fine, that's not the point here.

There is no option to just "put it all in a database". You need to compose a number of different systems. You use your individual databases as indexes, not as primary storage, and the primary storage is probably S3. The post is interesting and the author has been working on this stuff for a while. He wrote Apache Storm and used to promote some of these concepts as the "Lambda architecture" though I haven't seen that term in a while.