evanelias

I'm curious, is your database work all hand-coded? Tidesdb is extremely impressive in any case, and I just saw Turborel which looks interesting. Your commit rate is pretty intense -- speaking as a hand-coding dinosaur myself, if this is all by hand too I'm now even more impressed (and a bit jealous for your level of productivity!)

You're misstating history here. For electing the president, the framers didn't mandate a popular vote at all, even at a state level -- but nor did they forbid one.

Instead, they left it up to the individual states to decide how to select electors, and initially most of them opted to have the state legislature choose the electors, not a popular vote of the state's citizens. It took decades for all states to converge on having a state-wide popular vote decide electors, and even today, "faithless" (rogue) electors -- who vote against the popular will -- are not punished in a number of states!

Given that the Constitution explicitly gives power to the individual states to decide how to select electors, there's nothing inherently "changing the formula" in a state deciding to select electors based on the entire country's popular vote tally, instead of just the state's vote tally.

Rather, the main argument against this is whether it violates the Compact Clause in article 1 by virtue of being a compact between states.

Framing this as a change "to give a strategic advantage to one side" is disingenuous. The current formula gives a strategic advantage to one side. In our lifetimes, there have only been 2 US presidential elections where the electoral college winner lost the popular vote, and both were Republicans. No other democracy in the world still uses an indirect "electoral college" system for electing the head of its executive branch.

The Constitution does not specify the size of the Supreme Court, which actually changed multiple times throughout the 1800s.

Why do you specifically call out Democrats here? The most recent court size increase was during the presidency of Grant, a Republican.

Anyway, regarding the original topic of the National Popular Vote compact, the Constitution does not specify how each state chooses its electors in the Electoral Collage. Initially, most state legislatures chose their electors without any popular vote at all!

Eventually all states switched to a popular vote system, individually, but this took several decades to occur. That initial switch seems more substantial than what is proposed in the National Popular Vote compact, so why are you confidently proclaiming that it would result in a civil war?

In my experience, the bigger issue with Verizon's battery backups was that when the battery starts failing, the device beeps loudly every minute. That's especially problematic in apartments, as it tends to be within earshot of the bedroom. And the battery backup system is present in the ONT box even if you don't have phone service, or ever want it; and even if you own your home, it takes a lot of complaining to get Verizon to remove it. Horrendously stupid design.

The burst of the dotcom bubble, in terms of market peak to trough, took two and a half years before the bottom was hit.

No, GP is correct. In the pilot, the ship was in the process of being decommissioned from military use and converted to a museum. It wasn't already a museum prior to the events in the pilot (if that's what you meant -- maybe I'm not really sure what your comment was saying.)

Ehh, maybe that notion times ten. These recent episodes are far goofier and more nonsensical than that TNG episode. (and again, my view on them is far less harsh than many of the reviews I've seen online...)

At least the TNG duds attempted some kind of sci fi technobabble explanation for whatever hijinks were occurring. With this season of SNW, we're getting plot devices like "missing resistance leader just happened to look identical to Enterprise's first officer by complete coincidence!" and "spooky derelict ship is haunted, no explanation even attempted!" ... there are worse ones I could reference but they're spoilers. I'm genuinely starting to wonder if an LLM is writing these scripts.

re: taking it seriously, I meant more in terms of whether it is "good art" vs disposable entertainment. On the whole, I felt that TNG and DS9 both eventually found the right balance of drama and humor, often with an intelligent underlying message about aspects of our society and culture. The modern Star Trek shows are sorely lacking in that area!

The difference is the sheer number of gimmick episodes: so far half the episodes this season fall into that category. Did you actually watch that puppet episode you're quoting? Gimmick aside, it had one of the dumbest endings of any Star Trek episode I can think of.

The current season has been rather divisive, to say the least. I mean some of these episodes currently have IMDB ratings in the mid 4's to mid 5's range out of 10: https://www.imdb.com/title/tt12327578/episodes/?season=4

Personally I didn't hate the gimmick episodes, but enjoying them sort of requires no longer taking the show seriously at all.

In this specific case (Tailwind Labs) I don't understand this sentiment at all. It was a completely bootstrapped company! Its entire existence is due to the many years of difficult work by its founders.

What exact outcome would correctly align with "good leadership" in your view? It sounds like you think the CEO/cofounder should have "gone down with the ship" here -- how does that help anyone if it means the entire company would have failed?

Interesting, I wouldn't have expected that auto_increment replication problem to occur for InnoDB tables that have a clustered index key (the old PK converted to UNIQUE), that is indeed surprising. Maybe the SQL layer does something dumb here and thinks the table doesn't have a defined ordering because it has no explicit PK -- even though internally in the storage engine it would still have the table organized by the old PK if it was a UNIQUE KEY over non-NULLable columns.

But even that aside, I still say the binlog_format is irrelevant and the core problem here is 100% the ALTER to add the auto_increment: it resulted in different IDs on the replica than on the primary. That's a problem if you refer to IDs externally anywhere, regardless of whether it's 6 child tables or an external cache or logging etc. As soon as you promote a replica for any reason (not just an upgrade, any failover reason whatsoever) this would be a massive problem as all the IDs would now refer to different rows. And even before a failover event, if you do any reads from the replica for any purpose (read scaling, backups, OLAP queries), the data is going to be wrong.

Essentially for the 6 child tables, it wouldn't have mattered if their UPDATEs had all used ROW or all used STATEMENT; either way you would have still had a fundamental data inconsistency between primary and replica here for the parent table. If these 6 tables' UPDATEs all used ROW, they would refer to the IDs from the primary which are locally "wrong" on the replica. Or if they all used STATEMENT then the data on the replica would be consistent locally but completely different than what's on the primary.

Huh, if the table effectively already had a clustered index key (from the old PK) then I'm surprised that the auto_inc values would be assigned non-deterministically. I would have naively assumed that the values would be assigned in clustered index key order. Maybe this is one of those cases where too much logic is handled outside the storage engine?

Anyway yes nice to see you here too Fernando! Good call on the noop pt-osc, I always forget about all the cool tricks that tool can do when applied in non-obvious ways.

No, the binlog format is actually irrelevant here; the post author was just incorrect about that part. ALTER TABLE always gets replicated as a statement, regardless of the binlog format.

Auto_increment only has broken replication semantics in the very specific situation the author encountered: a table has data, but no primary key (and also no alternative unique index which could serve as the clustered index key) and then an attempt is made to alter the table to add an auto_increment primary key.

Basically that form of ALTER TABLE statement is telling the database to add a sequential ID to each existing row, but without providing any deterministic way that those numbers should be assigned. So each replica may choose a different numbering, causing the problem experienced by the author.

It's a foot gun, but not a common one in production at any real scale where you'd have a replica in the first place. InnoDB tables really should always have primary keys, and there are various ways to ensure that happens (sql_require_primary_key option, generated invisible primary key option, external linters, etc).

I agree the root cause here is the lack of a primary key to begin with. But as far as I know, DDL is always replicated as just a statement, regardless of session binlog_format. So I believe the only real fix here is the general approach suggested in the manual [1], i.e. create a new empty table that has the auto_increment PK added and then populate it from the old table.

[1] https://dev.mysql.com/doc/refman/9.7/en/replication-features...

That's largely a fantasy in the NYC metro area as well. Unless you're talking about a tiny condo, and/or your office is extremely close to a major transit hub.

NATURAL JOIN is actually in the SQL standard; it's not specific to MySQL.

I'm not aware of any databases that allow UNION to take table names directly, although in many cases you can use the TABLE keyword as a shortcut for "SELECT * FROM".

My sense is that a lot of this activity isn't even legitimate use. As one example: my company has a GitHub app, and last night some bot added my app to 1700 repos. Then the bot immediately started rapid-firing commits which each affected hundreds of files, triggering a deluge of GitHub webhooks to my servers.

The repo names all matched other GitHub apps, so my sense is this bot had added 1700 GitHub apps to 1700 repos, with that number rapidly increasing at the upper bound of whatever GitHub's rate limit is.

My systems caught it quickly and auto-booted the bot, but the whole situation is ridiculous.

Unless I'm missing something, your linked comments seem to be responding only to the title of the article, without addressing any of the actual points being made in the body of the article?

> Mass layoffs are going on for a couple years. I couldn't figure out why it is only making noise now?

This specific infamous mass-layoff-via-Zoom happened back in December 2021, and a lot of noise was made about it at the time.

For reference, https://news.ycombinator.com/item?id=29460985 (453 comments) discusses the initial layoff, and https://news.ycombinator.com/item?id=29515050 (97 comments) discusses the CEO temporarily stepping back.

Actually, Zuckerberg's Facemash site was online for less than 3 days. It's worth mentioning that the events depicted in The Social Network regarding Facemash's traffic level supposedly crashing the Harvard FAS network were fictional. Administrative staff from FASCS (arts+sciences IT department) were alerted because the site content severely violated student privacy, not due to the network traffic.

I was about to post the same; they adopted the pass/fail first semester policy in 1971.

But then I was just horrified to read apparently they got rid of that system in 2017 [1], and now it's a normal letter grade?! Assuming that Hopkins still skews quite harshly on grading, that's an awful regression.

[1] https://www.jhunewsletter.com/article/2016/05/university-to-...

> The barber example is not theft. You cannot steal a haircut. You may be harming the barber, but it's not theft. [...] Words matter!

Then why is it legally considered "theft of services", which is a crime that directly includes the word "theft" in the name? https://en.wikipedia.org/wiki/Theft_of_services

In theory you can do filesystem-copy-speed population of large seed data using InnoDB's transportable tablespaces feature. For the test db use-case specifically though, unfortunately it's far less ergonomic than Postgres template databases.

Case sensitivity/insensitivity is a property of the collation, which is configurable on a per-column basis.

In Postgres the default collation is case-sensitive, and in MySQL the default collation is case-insensitive, but this does not mean one is "correct behavior" and the other is not. MySQL's out-of-the-box collation support is arguably a lot more thorough than Postgres's!

Regardless of whether they are "truly" stateless, if they have no identity documentation -- which your AI answer repeatedly indicates is a situation applying to a larger number of Roma -- and they refuse to say where they're from (or they say they're from that country; or they name a country that isn't where they're from; or the named country refuses to take them) then once again, where are they being deported to exactly?

My point with all this is that it is VERY important to ask specific questions of the folks like DHH who are promoting mass deportation plans, because otherwise having public support for this kind of thing is exactly how you end up with people getting sent to concentration camps (or worse). They're demanding "just deport them!" while hand-waving away even the most basic details of what that might mean, and simultaneously making disturbing analogies to shooting wolves. It's not hard to connect the dots here.

As for "That seems like a them problem"... For a directly analogous situation currently happening in the world, consider all the people the US has blindly deported to the CECOT prison in El Salvador. Is that a "them problem" too, where a large number of undocumented Venezuelan migrants with tattoos are being sent to a concentration camp for gang members in an entirely different country?

The articles I read yesterday indicated that it would be quite difficult to determine country of origin in many cases, due to complete lack of official identity documentation.

The article I previously mentioned by name literally describes statelessness and why that occurred for Roma in several specific scenarios: https://www.coe.int/en/web/commissioner/-/many-roma-in-europ...

So again I must ask, do you have any links that support what you're saying?

Pardon my skepticism, but cursory web searching and LLM prompting is giving me responses like "a significant portion of the European Roma population faces high rates of statelessness or lacks basic civil documents", while citing real website articles with titles such as "Many Roma in Europe are stateless and live outside social protection".

That aligns 100% with things I've read previously, but that said, I'm not terribly well-informed on the topic and maybe I'm entirely wrong here. Do you have any links/info that support what you're saying?

Which is where, exactly, for the people in question? i.e. what is the legal home country for most Roma in Denmark? Given folks like DHH have such strong opinions about this, I would expect they should be able to detail the specifics of the mass deportation plan they're proposing!