manv1

The new MBA15 has TB4 not TB3, but no official info yet.

They fixed the keyboard issue with the 16" Macbook Pro Intel series, which came out 4-5 years ago.

Because adding brains and storage to hardware is expensive. And putting simple things on customer prem means less things can go horribly wrong.

And people actually like controlling their hardware from out-of-the-home, which makes doing everything locally even more complicated.

When you start trying to present end-users with a graph of whatever metric you want, you run into issues with storage, response time, CPU usage, storage, the web front-end, storage, etc. Then you have issues updating all that.

And if you want to do something like, say, comparing and benchmarking against other users you can't.

Really, only technical people care about this kind of stuff, and they can go ahead and write their own or use HA.

The whole point of bringing countries like China into the world economic system is to make sure that they realize that aggressive action is counterproductive and they refrain from doing so.

Unfortunately that hasn't really worked with China, which is why the world is starting to decouple from China; the CPP still prioritizes its institutional needs over "The People", which is ironic since they're supposed to be working for "The People."

That's probably why the CPP is scared of the people and tries to control them.

That's a load of bullshit. With Z-Wave I have a pick of over 20-30 vendors. Z-Wave is just as open as Matter. It's just not controlled by Google and/or Apple.

Apple sells its products to its markets, and is mostly uninterested in the data center and embedded market. The support costs are large, and the margins are small-ish.

Which is too bad for the industry, but also lucky for the industry.

I mean, they were the first 64-bit ARM chip, period. In fact, everyone mocked it, but they also trembled in fear because 64-bit.

A friend of mine used to work on a product that was essentially a printer driver.

The problems include (1) QA, (2) reverse engineering the communication protocol, and (3) support.

#1 and #3 are chronic issues in the OSS world. They're also a problem because there are a ton of printers out there, and getting one to develop/test against eventually becomes an expense and space problem.

And, printers are cheap. There's no real financial incentive to do it.

As an aside, I talked to some guy at Chase years ago, and all he wanted was some way to manage all the printers Chase had. That was it. It was like his personal nightmare. It was literally an impossible task, especially since some unknown percentage of them were no longer manufacturer supported...and many didn't have a manufacturer anymore.

This is why financials want you to go all-digital - so they can dump these behemoth printers that cost a fortune to maintain.

Matter will lock you into the ecosystem promoted by Apple and Google instead of the ecosystem promoted by the Z-Wave alliance.

I suspect it's a combination of NIH and the big players wanting to control the certification process and chip supply.

Z-Wave has been working perfectly fine for years. There have been protocol upgrades, new hardware, a pretty large ecosystem, etc. Zigbee apparently suffers from interop problems.

The main reason I prefer mysql over PostgreSQL is that mysql is just more consistent - in its commands, quirks, etc.

Postgres - is it pg, pgsql, psql, postgres, postgresQL? The answer is "yes."

Plus the case behavior for tables and column names drives me crazy. It's like some leftover VMS shit. I mean seriously fix it. Can you or can you not use a capital letter for a table/column name? I can never remember. Or you can, but you have to quote it? Fuck.

Until recently (which to be fair might be 8-10 years ago) postgres' performance monitoring tools sucked compared to mysql. I know at one point in the last 10 years they still used sunos4 as their base configuration because you know, the OS had been EOL for like a decade at that point.

MySQL is fire and forget. psql (or postgres or pg or postgresql?) is not fire and forget. It's twitchy and requires constant vigilance. I don't want a piece of infrastructure that requires constant vigilance.

That's not to say I won't use it. It's geo stuff is really great. It's JSON support is better than MongoDB's, from what I've heard. Row level security is awesome. But are those features good enough to overcome psql's quirks? Sometimes.

Still using it since longer than I can remember. From 68k to M1! It's been launched by "F1" on my keyboard forever.

It's find differences is still unmatched IMO on any platform. "Compare folders" has been a real lifesaver for a ridiculously long time.

"Enshittification" sounds much more clickbaity than "Degeneration."

But a literal reader might think "what's digesting TikTok?" Because technically, enshittification means sucking the nutrients and water out of it. It's what happens to food in your digestive track.

1974 was a long time ago. 32 bits was a big number. The 8080 had 8 bit words and ran at 2Mhz.

For people today, it's hard to understand how expensive everything was back then. 1K of RAM in 1974 cost about $307 dollars. Yeah, you're not going to be putting that into your router. So those extra bits have a super-high hard dollar cost.

We're lucky he didn't go to 16 bits.

Really, the question here is "do you build a general-purpose solution or one customized to your use case?"

I'm not sure where things are these days on the design spectrum, but I think there's still a bias towards "reusable code" and "abstraction."

But why? If it's code for your MVP, the future is uncertain, and time is more important. Are you really going to reuse this? You're probably going to rewrite it in chunks. Design it for that.

One thing to watch out for in a "shared" architecture is update hell...in the sense that you have so many dependencies that you're basically forced to update everything all at once because of the way you've structured things. That's a fucking nightmare, especially if the various parts have different update latencies. Your app needs approval from the app store, so if it shares something with the back end you literally need to trigger your backend update when app approval occurs. And you have to ensure all your clients update at the same, time, which is unlikely.