The new MBA15 has TB4 not TB3, but no official info yet.
HN user
manv1
Computers since the 80s, industry since the 90s.
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.
I think the realtime requirement removes hadoop as an option. They might have considered using HDFS as the data store instead of S3, since putting lots of objects into s3 is expensive. Or just using a big EFS volume instead of S3.
It would be nice to know how much latency there was in the microservice version vs the monolithic version.
You don't need to read the "legends", because their lives and writings exist and are still extant.
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.
There's a ton of stuff about the founding of the US that isn't generally known.
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.
Waking up from sleep is an endemic problem across devices. Just google "waking up from sleep" and you'll see all kinds of stuff for both Windows and MacOS. I'm not sure Linux has deep sleep.
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.
I know of a company that's using dried blood for testing, which apparently is the same as what Theranos was saying from a layman's point of view.
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.
These look exactly the same as the ones by firms that became successful!
This is the same problem with laws. The only people that follow them are legitimate users.
Yeah, the one time I used go it was pretty good. The big question is always whether your stuff spends more time waiting or more time processing. For the former, it's node. For the latter, it's go.
TL; DR: "It's better to design a fast system from the get-go instead of trying to fix a slow system later."
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.
IMO the real problem with Clubhouse was it was for the intelligentsia and their hangers-on. That's not a profitable market.
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 wonder what would happen if the copyright for images generated by the AI were assigned to a corporation...which is the equivalent of an individual.
Quis custodiet ipsos custodes?
That's true, but that's sort of suboptimal.
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.
Really, a better solution might be to spew the results into another table and then schedule downtime and replace the original table (via rename or whatever).
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.
There are a lot of people looking to say bad things about SpaceX, and they're feeding the anti-Musk machine.
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.
FTA there seem to be at least 2 problems:
"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.