msbarnett

> Also this may be not a very popular opinion, but I prefer to design the database without using database-specific features.

The problem with that is that SQL as a standard is so patchy and inconsistently implemented that effectively everything has database-specific features. You discovered that yourself when you inadvertently relied on SQLite's "feature" of letting you store UUID strings in an integer column. No matter how portable you imagine your schema is, it will work very, very differently between any two SQL implementations.

I can't see any value whatsoever in voluntarily tying one hand behind your back performance-wise, honestly. It's not like changing "text" to "uuid" would have noticeably increased the time this port-job took you.

As a wise man once said, if you're doing a job manually while the tool designed for that job is sitting idle beside you, the tool is smarter than you are.

> Yes there might be some use cases that really benefit from Postgres features like GIS and the native JSON type

Or a proper UUID type, materialized views, enforced data-constraints, lateral joins, queries that consider multiple indexes, etc, etc.

It's not like there's just a couple of niches where PostgreSQL's features distinguish it from SQLite. SQLite is appropriate for very simple DB use-cases where you aren't too bothered by silent data inconsistency/corruption, but not a whole lot beyond that. It's a good little piece of software, but it hardly relegates PostgreSQL to "Just GIS things" or "Just JSON use-cases".

> Once again, SQLite happily stored my UUIDs on this column and even indexed them, but to get these across to PostgreSQL I needed to fix the schema and properly declare these keys as strings.

In PostgreSQL you're leaving performance on the table if you store UUIDs as strings instead of as the built in UUID type (128-bit value under the hood)

> So if I tell you that upgrading pretty much all databases is a piece of cake but not include the criteria "unless you want to keep your data" you would say that is a fair statement?

Incredibly bad-faith comparison, this.

Many, many datastore deployments can tolerate 10 minutes of downtime every 4 or 5 years when their PG install finally transitions out of support. Data loss isn’t even in the same universe of problem. It’s reasonable to talk about how easy it is to upgrade if you can tolerate a tiny bit of downtime every few years, since most people can. It’s utterly asinine to compare that to data deletion.

> the GP comment claimed upgrading PG was a piece of cake. You claim it is not a piece of cake. So it sounds like you agree that the claim that upgrading PG was a piece of cake was misleading.

GP claimed upgrading was a piece of cake, not that zero downtime upgrades are a piece of cake. The two claims aren’t interchangeable. The simple upgrade path is always available, though it may have downtime consequences you personally are unwilling to accept. And the complex upgrade path is complex for reasons that have nothing to do with PostgreSQL - it’s just as complex to do a zero downtime upgrade in any data store, because in all cases it requires logical replication.

So if anything it feels like you’re the one being misleading by acting as though GP made a more specific claim than they actually did, and insisting that the hard case is hard because of PG instead of difficulty that’s inherent to the zero downtime requirement.

Broadly speaking, this is opposed in Canada by some due to the perception that the existence of a private parallel system will be weaponized to undermine the public system, as many feel has happened to the NHS in the UK.

"Some cultures use rote memorization to educate humans" != "anything educated via rote memorization necessarily has developed a human-equivalent understanding of the material"

But that's the crux of engineering: these two things are in tension – the part which is designed to fail safely if a jam occurs will, by its very nature, also be subject to wearing down sooner than if it were made of cast iron and caused the entire mixer to fail catastrophically during a jam.

In reality, nothing is so simple as waving your hands and declaring "no plastic 'planned obsolescence' parts!". Everything is a trade-off. A more effective way of pushing companies to position the trade-off in a way that rewards long-term durability would probably be to mandate longer warranty periods, rather than try to dictate what gears ought to be made out of in a vacuum divorced from the tradeoffs involved.

> For most of the world, yes.

This is not really true for most values of "most", and the places it is true, the culture tends to be much different than you would find in California, eg) you are generally not looking at children being assigned hours of homework to perform in which they have no space to work on it, nor ability to work on it without distraction while the rest of the family lives on top of them.

> If one is looking for subsidized housing, isn't that a reasonable compromise?

You may want to look up the history of tenements in the US. Broadly speaking the answer turns out to be: no, this is not a good compromise.

Not sleeping a family of 4 to a single room, 19th Century New York Tenement Style, is considered a luxury now?

> IPFS team released Filecoin to let you store files in more than one “cloud” company like AWS or GCP or Azure.

Which again looks like the problem being solved is just financializing something you could already do just fine without the "coin" to begin with.

The central problem with JIRA is that, once you've gotten beyond the overly customizable functionality and difficult-to-reason about permissions, and once you've managed to avoid organizations that go too far off of the deep-end and once you've finally found a happy simplicity in a kanban-ish board,

once you've done all of that, it is still unbelievably, unjustifiably, just incredibly and amazingly so very very goddamn slow.

Yeah but it’s little more than an SEO farm these days.

Looks like this was published 4 days ago. Things might have been rectified since.

The phrase "you can't prove a negative" is really short-hand for "you can't prove a negative existential claim within an effectively infinite scope", ie. I can't prove that Bigfoot doesn't exist anywhere in the universe simply because absence of evidence is not evidence of absence.

But I can easily prove that Bigfoot does not exist within my coffee mug, or that a particular box I have which contains 5 pennies contains no silver dollars, or that the list of suppliers with whom I directly do business does not include "Missouri Correctional Services LLC" (and I think the spirit of GP's suggestion is boycotting companies that directly do business with prison labour, not people who transitively do business with it at a 25 company remove, or something)

> I'm sorry that wasn't good enough for you in a comment where I repeatedly qualified things as "back of the envelope" and "very rough" and so on, and made it clear I picked one particular model out of the blue.

Dude, I was just adding information for the unaware reading this thread, you can unnail yourself from that cross. It wasn’t an attack.

> Also, pilot seniority / pay varies with the route and schedule, not airplane model.

It varies by seniority and model they’re checked out on. Model they are qualified on determines the routes they can bid on - because you recertify every 6 months in simulator on your model, it’s not really possible to maintain a bunch of different active certifications and fly routes with different models routinely, so your model determines your pay. Source: close family member has been a commercial airline pilot for decades and has been actively involved in union negotiations.

> Very rough guesses on labor: figure the two pilots are making $100k/year

Fuel costs still outweigh labour, but a captain on a 767 makes more than double that (~$220,000-$250,000 USD or thereabouts). A first officer would be looking at $120,000ish, I think?

The thing is that a narrow-body like this can land at a much broader ranger of airports than a wide-body like a 747, which forces you to run people from regional airports to a hub and then transfer onto the wide-body. So this gives you the ability to run far more point-to-point routes with a couple of hundred passengers, with less of the scheduling complexities of point-hub-hub-point connections.

Still not following.

"> I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar."

Emphasis mine. How does "the extremely valid "gem is owned by a team, and anyone may push" model" impact this in any way? Why would the MFA tokens need to be shared via 1Password if they are specific to an individual account?

Unless you're sharing the username/password for a master account between everyone with push access to the gem (which, I checked, Capistrano thankfully doesn't appear to be doing), there's no reason whatsover to share the MFA token, so it could happily exist on a separate device. And if you are sharing one username/password between everybody – don't do that. You don't need to do that to accomplish "the extremely valid "gem is owned by a team, and anyone may push" model". That's just a really stupid way to do anything.

GP seems to be thinking that everyone with push rights needs to share the same token, but that's simply incorrect.

Gems can have multiple accounts able to push, and MFA tokens are per-account, not per-gem. So what's the issue exactly?

Investing with Bernie Madoff was historically a lucrative investment, right up until it wasn’t anymore.

WWDC’s keynote revolves around a bunch of Operating System and hardware announcements that I’m interested in as a user of their OS and hardware even though I am not specifically targeting their APIs as a developer.

Google I/O’s keynote (had to look it up) had a bunch of random announcements about their sites, like… automated transcriptions for youtube? Some map stuff? As an occasional user of their sites I really am not interested in any of this. I’m sure it matters to some people, but it isn’t universally interesting, I guess.

The closest Google comes to what Apple does is the Android and Pixel announcements, but Pixel hardware is just one option in the ecosystem rather than the whole thing, so I don’t think it necessarily attracts the same kind of attention.

> TLDR: 2022 and we are still stuck with 100Mbit adapters on macOS

That’s something of an exaggeration. There are a bunch of macs that ship with perfectly good 10GigE ethernet adapters - my Mac Pro's ethernet has been rock solid since the day I bought it.

It seems like you’re more specifically concerned with the quality of support for USB<->ethernet adapters, which is always going to be kind of a crapshoot if you’re looking for 24/7/365 connection stability (on a laptop?)

> An interpreter is still producing x86 instructions at some point, right?

Not dynamically. They just call predefined C (or whatever the interpreter was written in) functions based on some internal mechanism.

> Or else what does the CPU execute?

Usually either the interpreter is just walking the AST and calling C functions based on the parse tree’s node type (this is very slow), or it will convert the AST into an opcode stream (not x86-64 opcodes, just internal names for integers, like OP_ADD = 0, OP_SUB = 1, etc) when parsing the file, and then the interpreter’s “core” will look something like a gigantic switch state statement with case OP_ADD: add(lhs, rhs) type cases. “add” in this case being a C function that implements the add semantics in this language. (The latter approach, where the input file is converted to some intermediate form for more efficient execution after the parse tree is derived, is more properly termed a virtual machine and “interpreter” generally only refers to the AST approach. People tend to use “interpreter” pretty broadly in informal conversations, but Python is strictly speaking a VM, not an interpreter)

In either case, the only thing emitting x86-64 is the compiler that built the interpreter’s binary.

> Am I totally misunderstanding how interpreters work?

You’re confusing them with JITs.

If every interpreter had to roll their own dynamic binary generation, they’d be a hell of a lot less portable (like JITs).

Yes, it includes a runtime JIT component for apps that happen to dynamically generate x86-64, but in all other cases the binary is AOT translated. It does this by inserting (during the AOT translation) function calls to a linked in, in-process translation function whenever it sees mmap’d or malloc’d regions being marked for execute and then jumped to - this data dependency on the jump instructions can be entirely determined from a static analysis of the executable, no violation of fundamental computing science principles required.

So yeah, no real back and forth to the host platform.

It’s doing an AOT translation of x86-64 opcodes to ARM64 equivalents. There isn’t really any back and forth, it just digests the binary all at once.

This would still be pretty slow (see: Microsoft’s version of this under Windows ARM) due to the need to issue a ton of memory fence instructions to make ARM’s looser memory model behave like Intel’s, except that Apple baked the ability to switch the CPU into an Intel-like memory model directly into the silicon.

So in practice it is shockingly fast.

Who said anything about f?

I said "power consumption increases exponentially with clock speed" not "power consumption increases exponentially with f". That any modern processor has to crank up V to crank up its clock speed is a given.

Hence, power consumption is exponential with clock speed (which is achieved by cranking up both V - the polynomial term in P – and f).

(Which, fine, if you want to be pedantic, is polynomial growth, but that changes nothing about the point, which is that you have to burn a shitload more power at 5 GHz than at 3.2 GHz, because your consumption isn't scaling anything close to linear).

> Quick note: AMD's 5nm offerings will not be using a big.LITTLE configuration, so direct comparison with the M1 would probably not be very accurate for the purposes of comparing power consumption.

Ok, but the second we start saying Intel or AMD needs to make architectural changes to match M1 performance/power consumption, that in and of itself is a refutation of the GP's argument that the only reason M1 looks good is the manufacturing node. We're admitting that there's an architectural component to its results.

These graphs look linear to you?

https://blog.stuffedcow.net/2012/07/ivy-bridge-power-consump...

https://qph.cf2.quoracdn.net/main-qimg-61820a6b86759c354d41d...

They're only 1 process node ahead of Intel. Intel 10nm is roughly equivalent transistor density as TSMC 7nm. The M1 was TSMC 5nm.

And given that there's no way a single process node jump is going to give Intel a 75% uplift in instruction per clock (2 nodes wouldn't give them that either, for that matter), Intel is going to have to clock higher for comparable performance and that's still going to put them behind on power consumption (which is exponential in clock speed).

Which is to say, it's completely untrue that the only reason these chips look good for speed/power-consumption is the process node they're on. Apple came up with a super-wide architecture (way wider than anything we've ever seen in x86-64), and they made it pay off by getting good performance out of a much lower maximum clock, which bought them a ton of power efficiency.