961 karma · joined June 17, 2021
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.
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.
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.
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.
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.
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.
It's find differences is still unmatched IMO on any platform. "Compare folders" has been a real lifesaver for a ridiculously long time.
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.
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.
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.
It would be nice to know how much latency there was in the microservice version vs the monolithic version.
You can go and read the Federalist Papers, the notes and minutes of the various conventions, the letters, articles, and books that they've written. Did George Washington chop down a cherry tree? Probably not. Did he thwart a coup attempt? Yes, he most certainly did.
Same with the other guys.
As Revolutionaries go they're the most successful band of revolutionaries by far, in that their work is still going and hasn't failed miserably like the work of those "other" revolutionaries.
The original genesis of the constitutional convention was a trade problem, although I read at one point it started as a navigation/fishing dispute between the Mid-Atlantic states.
In any case, it was interesting that the new constitution was essentially the second american revolution, in that the new government essentially (and potentially illegally) superseded the old government lock stock and barrel.
I know it's been a problem on MacOS forever, like back in the 68k days. Some peripherals never come back from sleep and you have to power cycle them to get them to "wake up." And sometimes MacOS doesn't come back either.
The level of process you're talking about usually isn't in a deck; it's usually "get sample - mail it in - get results."
Decks are pitched to investors, who most of the time have more money than technical skills in the area in question.
That's basically true. I worked on a system that was Java/scala/spring/hibernate and it was just slow. It was slow when it was servicing an empty request, and it just went downhill from there. They just built it wrong...and they went ahead and built it wrong again.
Today, I could replace it was a few hundred lines of node in AWS/Lambda and get multiple orders of magnitude of performance.
Advertising dollars chase the masses, and what the masses want is, well, celebrities, the good looking, the attractive, and the funny. The public is chasing dopamine hits, and advertisers chase the public.
I mean ideally you would want someone on your team who understands how the technology behind your product actually works and how to use it efficiently.
"We built this awesome tower. The foundation? It's great so far, I guess. But we really are tower builders, not foundation builders." - The team behind the Leaning Tower of Pisa
The Leaning Tower stands today, so obviously they built their tower really well. But the problems with the foundation takes away from it somewhat.
It all depends on your database, which is why you need an actual DBA role on your team instead of just using your database like an abstract storage entity.
That said, everything SpaceX does going forward is going to be scrutinized because there's billions of dollars at stake for the other vendors...and they really want SpaceX to fail.
Dust? Problems with the launch pad? Someone will try to escalate that into some kind of apocalyptic scenario. At one point someone will say something about their affect on sea life and migratory bird patterns.
"the Pi has problems with cache coherency on the PCI Express bus beyond 32-bits. And many (well, all nowadays) of the drivers expect that to function."
Yeah, that's a problem.
"there were issues with the BAR (Base Address Register) space allocated on the Pi's OS."
From the GitHub link:
# The default BAR address space available on the CM4 may be too small to allow # some devices to initialize correctly. To avoid 'failed to assign memory'
These don't look like implementation quirks, they are just flat-out errors.