> a legitimate business interest to further incentivize the adoption of Apple Silicon devices
Apple has never been about supporting legacy platforms with new features. And with over a quarter of revenue and two fifths of Apple's gross profits coming from services, one could argue the incentives run either way.
Enterprise ARM servers are still a niche product, and so are the ARM developer machines running Linux or Windows. Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.
Forcing people towards Apple silicon is of course an attractive approach when targeting the large portion of the market using their MacBooks as Facebook browsing machines, but (especially with the new MacBook Neo) what's going to happen when a large portion of the market for high-end MBPs disappears because it turned from the default no-brainer into a liability?
Rosetta 2. Rosetta was for Intel to emulate 68k, now if you could get Rosetta 2 to run under Rosetta, then you could run 68k, on an ARM, and if you could get the apple ][ emulator...
>Everything was parallelized on Burla, on a single dynamic cluster that scaled to ~1.7K CPU workers for photo download and CLIP, with 20 A100 GPUs running embedding clusters in parallel on the same cluster.
That's a lot of budget - would have been nice if they'd made an actual donation to the project, instead of pounding the project's servers and bandwidth when there are much better ways to interact with the data.
Totally fair callout. I should’ve been more careful here and leaned on the provided datasets / bulk access instead of pulling things at scale. That’s on me.
I’ll make a donation to support the project regardless. Appreciate you raising it.
"With limited funds, Google founders Larry Page and Sergey Brin initially deployed this system of inexpensive, interconnected PCs to process many thousands of search requests per second from Google users. This hardware system reflected the Google search algorithm itself, which is based on tolerating
multiple computer failures and optimizing around them. This production server was one of about thirty such racks in the first Google data center. Even though many of the installed PCs never worked and were difficult to repair, these racks provided Google with its first large-scale computing system and allowed the company to grow quickly and at minimal cost."
The biggest innovation from Google regarding hardware was understanding that the dropping memory prices had made it feasible to serve most data directly from memory. Even as memory was more expensive, you could serve requests faster, meaning less server capacity, meaning reduced cost. In addition to serving requests faster.
The problem they solved isn't easy. But its not some insane technical breakthrough either. Literally add redundancy, thats the ask. They didnt invent quantum computing to solve the issue did they? Why dunk on sprints?
Wow. What a hand wave away of the intrinsic challenge of writing fault tolerant distributed systems. It only seems easy because of decades of research and tools built since Google did it, but by no means was it something you could trivially add to a project as you can today.
I mean there were mainframes which could be described as that. IBM just fixed it in hardware instead of software so its not like it was an unknown field.
Even if that were actually true (it’s not in important ways) Google showed you could do this cheaply in software instead of expensive in hardware.
You’re still hand waving away things like inventing a way to make map/reduce fault tolerant and automatic partitioning of data and automatic scheduling which didn’t exist before and made map/reduce accessible - mainframes weren’t doing this.
They pioneered how you durably store data on a bunch of commodity hardware through GFS - others were not doing this. And they showed how to do distributed systems at a scale not seen before because the field had bottlenecked on however big you could make a mainframe.
It got them to where they need to be to then worry about ECC. This is like the dudes who deploy their blog on kubernetes just in case it hits front page of new york times or something.
> then had complete regret not doing this with ECC RAM
Yeah, my takeaway is Google made the right choice going with non-ECC RAM so they could scale quickly and validate product-market fit. (This also works from a perspective of social organisation. You want your ECC RAM going where it's most needed. Not every college dropout's Hail Mary.)
reply