Hacker News new | past | comments | ask | show | jobs | submit login
Is Apple Silicon Ready? (isapplesiliconready.com)
304 points by caiobegotti 56 days ago | hide | past | favorite | 192 comments



Seems a bit dubious to claim M1 isn't ready for web browsers when all of Chrome, Firefox, and Safari have ARM-optimized green checkmarks. Vivaldi, Brave, and Microsoft Edge — who cares? Similarly, the "Finance" tab is 100% green checkmark and also says "Not yet!"


To be fair, I've been having serious trouble with Firefox. The public version (Rosetta 2) has been freezing up on me every third page load, and the nightly version (ARM compiled) has similar issues. But I'm optimistic that these issues will be resolved soon.


That's a good argument for Firefox not getting a green checkmark. Taking as a given that the site operators have decided to give Firefox a green checkmark, I think my complaint makes sense.


You're not wrong, and I suspect the person who you're replying to understands that, but I think most of us here are probably more interested in the actual performance than whether the author here gave a green checkmark.


I'm using safari until Firefox gets ready. I have pihole so I'm mostly unaffected by ads except for YouTube videos - I was reminded that YouTube had ads!

Safari developer mode is actually not that bad. The only thing that's really awful is the complete lack of (useful) plugins.

I was also able to run my web project without any issues with ARM binary.


The BitWarden extension appears to be completely broken, though I'm not sure if that's an M1 issue or a Big Sur issue, I don't have an Intel Mac to compare. So I'm stuck copy and pasting my passwords from another tab. Blegh.


Did you try wipr? It’s great (haven’t tried on M1)


I'm running the native beta version and it has been running fine all day.


This web site feels to me like the Intel ARM knock-off websites that kept equating "the full internet experience" to "running flash" which was something Apple was studiously not doing on iOS.

Bad memories aside, tracking what worked before and is in progress to working again, is useful service. Back during the 68K -> PowerPC switch this kind of information was very helpful.


That was a glitch, we've fixed it.


Some of these feel unfair, too.

OBS recommends against Big Sur because of a tiny corner of functionality (the browser view). But OBS otherwise works on Big Sur and on Apple Silicon under Rosetta2.

Matlab works but isn't officially supported until mid-December, but has the red dot and not the yellow triangle.


I thought that when I saw the site. Surely it should be "Are these software developers ready?". It's not as snappy or click-baity though. The truth is that this is a really useful site, despite its name.


Even worse looking at the design tab. All but Sketch and Pixelmator Classic have optimized versions, and both of those work via Rosetta2


Pixelmator Classic is being abandoned? I bought it but use it far too rarely to even think about buying Pixelmator Pro or whatever they're calling the latest version now.


I felt the same, but when I saw they offer an upgrade price (by bundling it with classic for a hefty discount) I decided it was worth supporting a good Mac app even if I rarely use it.


Oh, 50% discount. I might bite. Sad thing is they had no way to tell their app store customers about this (at least not the very infrequent users like me), and I had to find out from a random HN discussion.


And I only discovered it indirectly through Gruber: reading about ML Super Resolution on Daring Fireball intrigued me enough to go check out the price on Pro.

https://daringfireball.net/linked/2020/11/19/pixelmator-pro-...


Brave is Chromium, and over ten million people use it every month.

Also, Firefox isn't natively supported outside of beta.


Edge has a higher usage share of the desktop market than Firefox.



That's for May 2019. Here's October 2020:

https://bit.ly/2IQgrix

In the last month Edge went from 0.67% to 2.09%.

  May 2019
    Firefox 6.52%
    Edge 0.03%
  
  September 2020
    Firefox 5.89%
    Edge 0.67%
  
  October 2020
    Firefox 5.75%
    Edge 2.09%


Huh, I had no idea Edge was even available on non-Windows platforms!


It's coming for Linux too [0].

Unfortunately, they'll be removing the webRequest API [1] which was the only reason I would have wanted to use it. This will happen probably whenever Google deprecates Manifest v2 and Manifest v3 becomes the only interface for extensions, which will stop uBlock Origin from working.

Other than that, when I tried Edge it didn't work perfectly on every site. But, it will be nice to have another non-Google browser to choose from.

[0] https://blogs.windows.com/msedgedev/2020/10/20/microsoft-edg...

[1] https://www.theregister.com/2020/10/15/microsoft_adopting_go...


Isn't edge a Google browser?


It is.

Edge is just a reskinned Chrome now.


No, they replaced all the Google services with Microsoft implementations.


Do you have a source? The first example I found is a bit dated (2016), but contradicts that claim: https://zdnet1.cbsistatic.com/hub/i/r/2016/06/18/77931904-cb...

This source (2020) also claims that global Firefox use is about 4% while Edge is under 3%, contradicting the claim (even including non-MacOS devices): https://gs.statcounter.com/

Another 2020 source gives 5.5% to Firefox and 0.5% to Edge on MacOS, also contradicting the claim: https://netmarketshare.com/?options=%7B%22filter%22%3A%7B%22...


Naturally it increased after it switched to Chromium and became the Windows default.

Choose your own source:

https://duckduckgo.com/?q=edge+surpasses+firefox


Apple M1 silicon will mostly or entirely run MacOS, not Windows.


You never know - would you say that 20 years ago that very significant push for Linux will be done by Microsoft?


This conversation is around whether Apple Silicon is ready. In that context, Edge is far behind Firefox.


On the Mac? Sounds unlikely


Yeah, I hate to throw anecdata around, but I didn't even know it existed for the Mac. Is Edge 'built in' to some other product, so it scores points on a technicality?


Many corporations are pushing Edge over Chrome, on both windows and Mac, for their employees.


Great comment, thanks. It particularly makes sense for a Windows shop that still officially supports Macs. Hadn't even crossed my mind.


Edge? As a Mac user for many years, I can't recall any time I might have even considered using Edge for anything. I guess they ported it to Mac not too long ago, but who cares?


Same, but in Windows. (Well, Linux is my daily driver, but when I boot into Windows, Firefox is still there).


I do use Edge one time when I first load a Windows machine. To download Firefox or Chrome...


In my small universe, this was the week of ARM. I submitted multiple PRs to OS projects to get ARM compilations working. I started moving AWS instances off of Intel instances to the new Graviton2 instances.

I'm still surprised there isn't more server takeup of ARM considering the incredible power numbers. Cloudflare announced their current builds and it's all Epyc2 and no ARM. What about Azure and Google Cloud? Are ARM servers easy to launch and superior on a cost/performance perspective?


The blog post that announces Cloudflare's current builds [1] says they "looked very seriously at ARM-based CPUs and continue to keep our software up to date for the ARM architecture so that we can use ARM-based CPUs when the requests per watt is interesting to us"

[1] https://blog.cloudflare.com/technical-details-of-why-cloudfl...


Is this about availability? Meaning that purchasing the Arm Neoverse that Graviton2 is based on, is too difficult if not operating at massive scale?

This Anandtech review has a page called "An X86 Massacre":

https://www.anandtech.com/show/15578/cloud-clash-amazon-grav...

Are giants like Apple and AWS just making it impossible for a player like Cloudflare to buy enough of the leading-edge Arm processors? And Epyc performs so well, and it's easy to buy, so they wait another year?


> This Anandtech review has a page called "An X86 Massacre":

Note that Anandtech was only comparing against chips that had already been replaced. They did that comparison like a few days before Amazon started offering Epyc Rome instances. See https://www.phoronix.com/scan.php?page=article&item=epyc-vs-... for a more like for like comparison, and the results are brutal for the N1:

"When taking the geometric mean of all these benchmarks, the EPYC 7742 without SMT enabled was about 46% faster than the Graviton2 bare metal performance. The EPYC 7742 with SMT (128 threads) increased the lead to about 51%, due to not all of the benchmarks being multi-thread focused."


Is there any vendor that sell pre-build arm neoverse right now? I only found thunderx2 arm servers, but can't seem to find any arm neoverse server sold anywhere. Thunderx3 is using neoverse architecture, but I can't find it sold anywhere right now.


Availability of ARM servers is trending down to zero. It's pretty funny to see all these people talk about meaningless things like benchmarks when ARM vendors can't even get the business side to work out.


Performance on ARM is bad compare to intel on GCP / AWS. The "incrediable" numbers are on M1 for Apple only which cloud provider don't have, also on servers Intel / AMD are still faster, no one cares about power consuption when renting a server.


AWS claims far superior performance per dollar with the Graviton2 processors vs the Intel equivalent processors. Look at the SPEC cpu2017 charts in this presentation:

https://pages.awscloud.com/rs/112-TZM-766/images/2020_0501-C...

This will catalyze giant migrations of workloads away from AWS Intel instances to the Graviton2 processors. Additionally, it seems clear that AWS will begin running all of the managed services (e.g., RDS, caches, mail, load balancers) with the superior ARM processors. The world is changing!


> This will catalyze giant migrations of workloads away from AWS Intel instances to the Graviton2 processors.

Or just from Intel instances to Epyc Rome instances. Which is a less significant migration with basically all of the same advantages.


I assume it's almost zero migration for 99% of use cases from an Intel instance to an Epyc Rome instance.

But if they figured out performance with Graviton2, what makes you think ARM isn't the clear future for server performance per dollar?


What makes you think ARM is the clear future? It's easier to do a wide decoder thanks to ARMv8's fixed-length instructions, but that's more or less the only difference that results from the ISA. And only Apple is even taking advantage of that currently - all the ARM CPU designs are 4-wide decode. Same as pretty much every modern x86 CPU.

Do you think Amazon will be better at design & fabrication than Intel (when they get their shit together) or AMD? Do you expect Amazon to actually throw Apple's level of R&D money & acquisitions at the problem? And when/if they do, why would you expect any meaningful difference at the end of the day on anything? People love to talk about supposed ARM power efficiency, but the 64-core Epyc Rome at 200w is around 3w per CPU core. Which is half the power draw of an M1 firestorm core. The M1's firestorm is also faster in such a comparison, but the point is power isn't a magical ARM advantage, and x86 isn't inherently some crazy power hog.

Phoronix put Graviton2 to the test vs. Epyc Rome and the results ain't pretty: https://www.phoronix.com/scan.php?page=article&item=epyc-vs-...

"When taking the geometric mean of all these benchmarks, the EPYC 7742 without SMT enabled was about 46% faster than the Graviton2 bare metal performance. The EPYC 7742 with SMT (128 threads) increased the lead to about 51%, due to not all of the benchmarks being multi-thread focused."

Graviton2 being a bit cheaper doesn't mean much when you need 50% more instances.

But right now there's only a single company that makes ARM look good and that's Apple. And Apple hasn't been in the server game for a long, long time now. Everyone else's ARM CPU cores pretty much suck. Maybe Nvidia's recent acquisition will change things, who knows. But at the end of the day if AMD keeps things up, or Intel gets back on track, there really doesn't look to be a bright future for ARM outside of Apple's ecosystem and the existing ARM markets.


I think the M1 will wake Amazon up (if they aren't already) to the incredible advantage of being able to customize a CPU to your needs. See the discussion about speed gains Apple got from accelerating common calls in their OS. You will never convince a bin part/least common denominator manufacturer like Intel or AMD to do that.

Just because other ARM cores suck today doesn't mean they have to forever. Apple's don't. They took it seriously. Perhaps Amazon is too and we are just at the start of their journey. It took Apple over 10 years to get to where we are with the M1.

You cited one of the significant contributors to performance - the 8-wide decode. x86 is hamstrung to 4 because of legacy. We aren't at the beginning of the story with ARM for performance, but ARM certainly isn't nearly as hamstrung out the gate by the legacy of x86 either.

Heck, is there anyone making a pure 64 bit x64 chip? There's a bunch of overhead right there.

Your right that ARM isn't magical - but ARM does have the potential for significantly more runway and headroom. The trade off is backwards compatibility. As most code continues to move further and further away from direct hardware interaction, is that backwards compatibility as valuable overall as it was 20 years ago? 10 years ago?

I guess we will find out :)


> I think the M1 will wake Amazon up (if they aren't already) to the incredible advantage of being able to customize a CPU to your needs. See the discussion about speed gains Apple got from accelerating common calls in their OS. You will never convince a bin part/least common denominator manufacturer like Intel or AMD to do that.

AMD has a semi-custom division that will do exactly that for anyone capable of paying: https://www.amd.com/en/products/semi-custom-solutions


> See the discussion about speed gains Apple got from accelerating common calls in their OS. You will never convince a bin part/least common denominator manufacturer like Intel or AMD to do that.

Of course you will because that happens all the time. How do you think we ended up with VT-x and friends? Intel took a use case that reached enough usage and added specialized instructions for it. This has happened a ton over the years on x86. See also AES-NI for a more application-specific addition. In addition to obviously the huge amount of SIMD experimentation.

This is not fruit Apple discovered. AMD & Intel haven't been leaving this performance on the table the last 20+ years. Hell the constant addition of instructions for certain workloads is a major reason x86 is as huge & complex as it is.


AWS Graviton is not competing with the top of the range Intel or AMD CPU's. With Graviton, AWS targets medium range EC2 instances that can now be had 30% cheaper with either with the same performance range or surpassing it at a lower power consumption - a win for the customer and a cheaper power bill for AWS. Graviton might also be already used to power serverless and fully managed product AWS offerings (Lambda, Aurora, MKS etc etc) – something we might never even know about unless AWS tells us. Any cloud product that does not require direct shell access can be transparently migrated to run on any ISA, not just ARM. I think we will also start seeing more AMD cloud offerings in the top performance tier soon due to the AMD CPU’s being so good.

In terms of a viable contender to Intel and ARM incumbents, I can only realistically think of the POWER architecture. Google was experimenting with POWER8 designs a few years back with a view to use POWER based blades for GCP – similar to what AWS has done with Graviton. There have not been any further news since then, so it is unknown whether (or when) we can have POWER powered compute instances in GCP. POWER is the only other mature architecture with plenty of experience and expertise available out there (compilers, toolchains, virtual machines etc etc).

Whether RISC-V will become the next big thing is yet to be seen, with the ISA fragmentation being the culprit. The 64 bit RISC-V ISA is yet to hit the v1.0 milestone, so we won’t know it for another few years. Unless a new string force appears on stage to push the RISC-V architecture.


Graviton2 isn't low power. It's still a 105w soc. And since you need more of them, that's more motherboards, more RAM, more drives, more networking, and more power supplies. Which all has both up-front costs and ongoing power costs.

It's only being positioned as a lower cost mid tier offering because it's uncompetitive otherwise. It's almost certainly not even cheaper to make. The monolithic design will be more expensive than AMD's chiplets. Cheaper for Amazon maybe, as obviously AMD is taking a profitable slice, but that's a slice that can easily be adjusted should Graviton start looking stronger at some point.


Not low power, but lower power. 110W (Graviton2 64 physical cores) vs 180W (AMD EPYC 7571, 32 physical cores / 64 HT cores) vs 210W (Intel Xeon Platinum 8259CL); source: https://www.anandtech.com/show/15578/cloud-clash-amazon-grav... Also, please do remember that Graviton2 is a 2018 design, and EPYC Rome is a 2019 design.

At the cloud data centre scale, the difference of 110W (Graviton2) vs 180W (AMD) is substantial as bills pile up quickly.

I am not sure what your point is, anyway. As a business customer, if it is going to cost me 30% less money to run the same workload regardless of the ISA, I will take it. A lesser power bill for the cloud provider that results from a more efficient ISA is a mere comforting thought. No more no less (to an extent). Philosophically and ethically, yes, I would rather run my workload on an ISA of my choice, but we can't have that anymore, and Intel is at blame here why. Not that I personally have the intention to blame anyone.


> 180W (AMD EPYC 7571, 32 physical cores / 64 HT cores)

Wrong CPU, that's the old Zen1 14nm Epyc. The one that Graviton2 is going up against is the 64-core Epyc 7742 (or any of the other Zen 2 7nm Epycs).

And you can't call Graviton2 110W when you need 50% more of them vs. everyone else, and you can't ignore the power from the rest of the system. You need 50% more machines. That's going to be equivalent if not more total power usage for Graviton2 than Epyc 7742 for equivalent compute performance. Baseline power usage of a server is fairly high. It's not the rounding error it is on a laptop or even desktop.

EDIT: also as far as comforting thoughts go, manufacturing 50% more machines is vastly more environmental impactful than the power difference.

> I am not sure what your point is, anyway. As a business customer, if it is going to cost me 30% less money to run the same workload regardless of the ISA, I will take it.

I'm saying that 30% less cost is a temporary fantasy since all signs point to the Graviton2 being more expensive to manufacturer & deploy vs. the competition. If you're not coupled to ISA, sure take it while it lasts. Why not be subsidized by Amazon for a bit? But if you're talking long-term trends, which we are, it's not a pretty picture. Pace of improvement isn't compelling, either. The CPU core in the N1 is basically a Cortex A76. ARM claims a 20% increase in IPC going from an A76 to an A77. Not bad. But AMD just delivered a 20% IPC increase going from Zen 2 to Zen 3, too. So... the gap ain't shrinking.

Although 30% less per instance but you need 50% more instances also doesn't work out. That ends up being overall more expensive. Depending on your workload that it might be even less close. In things like PostgreSQL & OpenSSL graviton2 gets absolutely slaughtered.


I've heard some of the big tech players are actually limited by power and cooling in their DCs, so ARM, even if it's slower, could be a win.


For sure limited by all sorts of factors: density, providers, backups, UPSes, diesel availability, generators, fire codes, etc.

Plus every watt costs money so the movement to performance per watt is huge for DCs!


Performance per dollar is pretty great on AWS. For an example: https://www.honeycomb.io/blog/observations-on-arm64-awss-ama...


Thanks for that link. I'm seeing similar results. The Arm instances are a no-brainer for a massive amount of workloads. Yes, leaving the Intel instances will take many, many years, but I don't see any future for buying any more Intel-based reserved instances from AWS. The Arm instances are just a clear winner when measured on performance per dollar.


I did not realize AWS had its own ARM chipset, so thanks for bringing Graviton to my attention.

I was wondering how other companies will compete with Apple's data center advantage--presumably Apple will replace most x86 infrastructure with cheaper, lower power, faster Apple Silicon.

Even if Graviton2 work is far behind the M1, it seems like Amazon can catch up. Particularly if they are able to hire away engineers from Apple's team. Even if Amazon trails Apple by years in performance per watt, it can still likely offer a compelling change from what Intel or AMD may be able to accomplish in the same time period.


Scaleway tried ARM and failed: https://www.theregister.com/2020/04/21/scaleway_arm64_cloud_...

But as you can see at the end of the article, other providers are considering/using ARM more.


Hmm, I was trying to rent some arm servers on scaleway but they were always out of stock. The article mentioned difficulties operating those servers reliably and they can't just buy hardware from different vendor because there is no other vendor that sells arm server at that moment (pretty much only thunderx server was available for purchase). Maybe things will be different this time and a bunch of new arm server vendors would show up due to renewed interest in arm servers.


I tried ARM on Scaleway and the main benefit was network capacity. Performance was not so good.


Seems like they were just too early and didn't have the capability of an AWS-scale company to work directly with ARM?

It seems like the first-gen of Graviton wasn't great, but then they seem to have made huge leaps with Graviton2.

https://pages.awscloud.com/rs/112-TZM-766/images/2020_0501-C...


I totally thought this was going to be one of those static sites with a single answer in h1 fonts ("Is it snowing in San Francisco?" "No") but instead this is much more useful.


It's unfortunate that the middle status (warning triangle with a exclamation mark) has a green background rather than a yellow background like warning triangles everywhere else. Makes the table less clear.


we've fixed the warning color, thanks for your feedback.


I've been through enough Mac upgrades by now to learn that I'm going to have a better time waiting for M2. I'm not really interested in jumping on this particular early adopter train. As a developer, who knows what random tweaks and system behaviors I rely on to get my job done, but that will be completely broken on a new Mac.

I certainly am heartened by all the news about processing power improvements. I'll just join the rest of y'all young whippersnappers after you pay the early adopter tax for me.


> I've been through enough Mac upgrades by now to learn that I'm going to have a better time waiting for M2.

If this was a brand new chip, yes, but Apple's chips have had years worth of proofing in iPads etc.

https://en.wikipedia.org/wiki/Apple-designed_processors


Great idea, thanks for putting it together. Ordering by "Apple silicon optimised" doesn't seem to work as I expected it. Is it a bug?

Great to see Office 2019 (not 365) works - was putting off picking up a license for that reason.


Afaik only 365 and 2021 will be ARM native and 2019 won't be.

Also be aware that unlike the Windows Office, Mac Office is supported only for 5 years and for the 2019 release, 2 years are already gone (it will be supported till Oct 2023, Mac Office 2016 is already unsupported since last October).



Sublime Text seems to be incorrectly marked as having native builds: https://doesitarm.com/app/sublime-text/


Based on the linked forum discussion, they do have native builds:

> We currently have a private beta for experimental arm64 linux support (no 32bit). If you have a valid Sublime Text 3 license and are willing and able to test on your arm64 device....


Also, if the site did have a mistake, you could just open a pull request, which is why I prefer this site over isapplesiliconready



For Linux.


Table suggests that Docker can run under Rosetta 2, but the Docker blog post that it links to suggests Rosetta is not enough. Can someone confirm if it’s actually possible to run Docker using Rosetta on M1 Macs?


It isn't, at least not in any way most developers use it. You cannot use docker to start a *nix container on a mac, whether its for a arm or x86 OS.

some context: https://www.reddit.com/r/docker/comments/jxc1ge/docker_and_a...


The Docker client works. It is useful, but it's not the same as Docker working.


I guess the Docker client works, but you still need a GNU/Linux running Docker. It's usually a VM on the same host but it doesn't have to be.


It might be that you can use docker-machine to set up a remote Docker machine and then use a native docker CLI to control that remote instance.


"Docker" on macOS is a Linux VM running docker.

Presumably ARM docker images could run in an ARM Linux VM.


It’s not. The client might be but the actual VM is a total mess right now.


Beta software (like Firefox) shouldn't have got green checkmarks. It's not "ready" yet.


Thanks for the feedback, we've fixed it.


For Android Developers, running Android Studio on M1 Macs is turning out to be a nightmare. The UI is sluggish and gradle builds are drastically slow.

Seems like JetBrains still needs to get their softwares ready for Apple Silicon: https://youtrack.jetbrains.com/issue/JBR-2526


Unrelated to the link but related to Apple's CPU foray:

Any thoughts or info on the security implications of a first generation CPU design? Is it safe to assume that a design focused on cutting edge performance may have compromised on security in some form? Does the fact that this is first gen indicate opportunity for hackers to discover low hanging fruit vulnerabilities possibly to the benefit of nation state or private actors?

I feel like the long term path for silicon will converge on extreme compartmentalization of general purpose computing hardware inside chips, designed from the ground up to achieve physical process isolation purpose built per task, with highly secure hardware IPC all on a single high perf die.

Interested to learn what Apple has done to build a "more secure" CPU design. edit: A quick web search yields relevant results on this topic already, e.g. work by Chinese based Tencent Security.


This isn't a first-generation CPU design. It's just another iteration of the ARM chips that Apple has been building since acquiring PA Semi 12 years ago.


Corrected: First generation chip purpose-built for Mac.


It's not purpose-built for Mac. All available indications are that it's the same chip as they've been shipping in devices for years, just "harder better faster stronger".

This is barely different than AMD releasing yet another line of Zen chips or Intel shipping a new Core i9.


... the first one that shipped. I suspect they've been building things like the A12X mini DTK for a few years now.


> I suspect they've been building things like the A12X mini DTK for a few years now.

They have. And they've been shipping the chips in iPads.


The DTK did reveal one interesting detail though. It didn't support virtualisation which would indicate that the M1 is their first generation part with virtualisation support, so there definitely have been some fairly large changes, even if it's not fair to call it a first generation part in it's entirety.


Apple's site says it is their first "chip" designed specifically for Mac:

https://www.apple.com/mac/m1/

I may be making a few semantical errors, regarding "first gen", et al


"first gen" usually insinuates, among other things, concepts like unproven, untested, extra risk, etc.

The M1 is part of a technical lineage that is over 10 years old at this point. It's hardly "first gen" from what people usually intend when using the phrase "first gen".

This also is Apple's 4th rodeo in changing the instruction sets that Mac's run on, and since the last transition their tooling, expertise in frameworks, compilers and other aspects of their ecosystem have also matured significantly - as evidenced by all the reports of the incredibly seamlessness of Rosetta 2 for the vast majority of applications (including terminal apps like Homebrew which still boggles my mind).

I figured there would at least be one or two earth shattering issues - but surprisingly no, seems to be pretty transparent for the vast majority of use cases. It's pretty mind boggling when you really think about it.


They're not technically lying, but you're better off thinking of it as 90% their iphone/ipad chip with a few tweaks for mac rather than a completely new design.


_Very_ few tweaks in this one, probably. In particular, note the two screens limitation. You know what else is limited to two screens...?



isn't this more like "is this app ready for apple silicon"?


The title is an odd construction, and did throw me off at first.

"Is Apple Silicon ready?"

Ready for what? Apple Silicon is the fixed quantity in this equation, while the software is what is changing to be ready for Apple Silicon, so the construction feels backward. An alternate construction could be "Is it Apple Silicon-ready," which I suppose one could stretch the title to read as a shortening of, but it's still awkward either way.

All that said – this is the best UI I've seen yet for an Apple Silicon compatibility list, confusing title or not.


It is exactly that.


it's more like "is Apple silicon ready to be used by x?"


I can only imagine the horror it must be to be maintaining mac x86 software that turns out to not work with Rosetta (Like some of the examples listed).

I do windows desktop work and try to picture what would happen if our customers were suddenly moving to Win10 on Arm and expecting our software to work. We have dozens and dozens of third party binary dependencies, each of which could turn out to be the one that doesn’t translate. Not all of them could realistically be replaced or updated. The situation would basically be one where Microsoft had announced the death of our software and probably business.


Long-time Mac developers are familiar with these transitions, and everyone had the opportunity to pick up development hardware this summer, so while it’s certainly not something to treat lightly, everyone with customers should have known what they were up against by now.


Yeah but if I have a 10mb binary dependency on an x86 lib with no source code and the company that made it is long since gone, then deprecating x86 would make me sweat a bit.


I would think the apps will come and get optimised. That is just a matter of chicken and egg, sometimes you just have to release, and go from there.

What I am worried about is if the GPU is anything worthwhile. All the focus in the reviews is on the CPU, but the GPU seems where it mostly falls short. Not enough external screens for example, though that can be fixed in a newer generation. But is it faster than what Apple hardware included in Intel, with AMD graphics? Some people will feel the regression in speed and capabilities quite hard. I don't see much focus on that in media publications.


It’s at least as impressive, if not more https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...


It’s a fair bet that it’s substantially inferior to a dedicated gpu at present. They didn’t release an M1 in any premium sku that would be head to head with a dgpu.

However, given the investment in both the neural engine and integrated gpu - I wouldn’t be surprised to see something interesting in 6-24 months.


I do believe benchmarks have shown it to be equivalent to a 1050 Ti which is not a pushover card by any means.


It's amazing how fast applications are being transitioned to apple silicon. If this was any other company introducing a new architecture, I am sure adoption wouldn't have been this fast.


Apple has the advantage of a long track record of pulling the plug on old tech. No one thinks for a moment that they’re going to try to straddle the middle of the road by offering both platforms any longer than they have to.

Being a decisive, opinionated company means that you anger a lot of people, but it also means you’re predictable once you’ve announced something like this.


Very cool. Small suggestion: it would be nice to be able to filter by "all apps that have native support or work properly under Rosetta", and maybe also the inverse of that.


this is a sheet for tracking game compatibility and performance (including FPS, settings, system specs and sources) that I set up yesterday

https://docs.google.com/spreadsheets/d/1er-NivvuIheDmIKBVRu3...

first results are impressive, there are reports of games that were unplayable on the 2020 Intel MacBook Air that now run well on the M1 MacBook Air


Weird that node is listed as not running under Apple Silicon, since I've been running node 15 compiled for Apple Silicon without problems for a while now :)


Did you compile it or is there a prebuilt avail?


Probably not but for better or worse, Apple is a big enough juggernaut that existing software that’s not ready it now has significant motivation to become ready.


Users will most likely blame the software for not working and not the hardware since all their other software will be working pretty soon.


Why is World of Warcraft listed under "Developers"?

Actually…


You can script Lua, no? Or is that some other game.


I am using Postgresql (last version) and I am having a lot of table corruptions. I neved had this problem, only now that I switched to new Mac book pro.

PG::InternalError: ERROR: could not read block 38 in file "base/84897/85294": Bad address


Aplogies for the meta: does anyone know/how do I find out what component library is used on the site? It looks to me some kind of material design flavor.

Context: I'm after a flexible material-like table component for a personal project.


Very cool idea! Useful for evaluating whether or not to order a new MBP now or later.

One minor bug - Sketch shows under all apps, but not under design apps (I thought it was missing altogether because I didn't see it under Design).


I got an SSL error on this page. This is the second time that’s happened today. And I can’t remember this happening on my phone in the past. Is this something on my end or are others seeing it too?


SSL on the site is fine for me. It is a Let's Encrypt cert, if that matters.


I was seeing a mcafee cert... wonder if Centurylink is playing games.


OpenSSL is partially working on M1 it seems... :)


Missing 'Java' under programming languages / runtime. Last I heard it's being worked upon.


Constant software compatibility issues is what caused people to avoid WindowsRT.. depending on how soon Apple resolves these issues will determine if people stick with M1 or migrate to Windows 10. My company runs on Windows with lots of 3rd party domain specific windows apps. We use Mac laptops because the hardware is nice, but it's probably not going to be an option for us in the future.


Please add/track Figma :)


I’ll gladly let you fine folks sort out this mess, and I’ll check back in next year. Thanks!

Seriously though, what’s the plan for Docker? Will all containers need to be built for ARM or will Rosetta 2 be able to run Docker in an x86 VM?

Homebrew is my other benchmark.


> what’s the plan for Docker?

Rosetta doesn’t support virtualisation (which would be needed to run the Linux VM under which the containers run).

So you’d need an ARM version of Docker, and an ARM Linux VM, and since the containers rely on that Linux kernel, I assume ARM containers running ARM software.

https://developer.apple.com/documentation/apple_silicon/abou...

I suppose it might be possible to develop a para-virtualisation framework that runs under Rosetta.


Anybody using it with VSCode? Appreciable perf difference?


It works fine on my M1 MBP. Runs intel though not ARM. Which I think is a mistake in the website showing it doesn't work on Rosetta 2


Agreed on mistake. (Rosetta 2 version runs fine, afaict.)

I haven't stress tested the ARM version, but it is the one I'm currently using and I haven't had any issues so far.


The ARM version crashes for me every time I change something in the settings UI, otherwise it seems to work okay.


Sorting on the columns with checkboxes seems broken.


I wonder why Google didn’t get File Stream ready?


"High risk website blocked"


Can you tell me if Ruby is ready?


I installed arm ruby via arm homebrew using `brew install ruby` and it's working. Anything requiring the ffi gem will not compile at the moment though.


In the meantime, you could use the version shipped with macOS:

    ▶ ruby -v
    ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.arm64e-darwin20]


I like the tick next to Firefox and you mouse-over and it says "Beta".


They should probably differentiate between Rosetta 2 issues and Big Sur issues.


A better question is: am I ready for locked-down silicon?


Maybe not 100% yet, but it moves incredibly fast to this goal.


Yes.


Silly title. Apple Silicon is obviously ready. Are these software packages ready is the question.


Is this sponsored by spotify or why are they up at the top? How many people use spotify on a computer?

In any case, the domain nam is incorrect. It should be “isitapplesiliconready”. The chips are clearly ready, it’s just that some developers haven’t recompiled their apps for it yet.


> In MEA and North America we see the highest preponderance of desktop Spotify listening, on 46%, with MEA also reporting the lowest mobile listening figure of 56% (compared to North America’s 61%).

https://www.businessofapps.com/data/spotify-statistics/


It's sorted by "last update".


Lots of people use Spotify desktop app....


Honest question. Why are people here so excited about this?

What I've gathered via osmosis here about Apple silicon is. 1. It will only be in macs, you cant buy the chips or mobos to build your own machine. 2. Theyre very energy efficient. 3. Their performance is okish.

Doesnt really seems earth shattering.. Like, if they were a super low energy alternative to the duopoly of amd or intel, that would be pretty cool. But if u buy a mac nowadays, its like a console with set stuff in it that u cant change or upgrade.. Now that stuff will be improved / updated in newer macs, does that not happen regularly anyway?

EDIT: Several people saying the performance is amazing.. Can u link me to some benchmarks? The only numbers I can find are these. "In Geekbench 5, the A14X yields a single-core score of 1,634 and rakes in 7,220 in the multi-core test."

These are very low scores, like, my desktop gets many times that.. My old work low/mid level laptop from 4 years ago had 3000 single core and 11600 multi-core score.


> But if u buy a mac nowadays, its like a console with set stuff in it that u cant change or upgrade

That's how most people buy and treat computers. We're the weird ones who upgrade them and keep using them for 9 years, 3 SSDs, and 4 RAM bumps.

> Their performance is okish

Nope - not even close to merely 'okish'. These first devices (which were clearly targeted as the cheapest, lowest-end devices Apple sells) outperform the vast majority of PCs (and Macs) sold today, and not just by a tiny bit. Look at some of the reviews by developers - in many cases their existing Intel apps and games are running better under Rosetta emulation/bridge/whatever you want to call it then they did on native Intel Macs. Compile times for a $999 MacBook Air beat a $6k+ iMac Pro by 30-40%. Games getting better frame rates under Rosetta than they did on native intel boxes.

The list goes on - these chips are beasts, and this is only the beginning. The high-performance versions of these will make people who bought 8/10/12 core iMac Pros recently weep.


> Their performance is okish

That seems an understatement. The first version, targeted at (for Apple) low-end devices, is much faster than most x86-64 based computers.


And it's an absolute IPC monster. At 3.2ghz it keeps up with high 4.x-ghz x86 cores. It's been a long time since anything's jumped like that from a good starting point.


From an software engineer's point of view, it is always exciting when new technology on market.

For example, I'm excited for Ruby on Rails on production when I was using PHP/Perl at that time. Also when I know how Kubenetes/Docker works after tired of Vmware ESXi.

This time a workable, non-x86 system on market, it has some new features that Intel don't have, that's why I'm excited.


It seems your are comparing geekbench numbers of different geekbench tests. Geekbench 4 would give much higher numbers. As I understand it, the M1 has the highest single core result of all processors, and considering it only has 4 high performance cores, it has astonishing good multicore scores.


Here’s an in-depth piece covering its benchmarks.

https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...


They’ve done a lot for the first time doing this. They’ve done a major transition and now have the freedom to innovate in the right direction for their product, not take what Intel gives them.

This launched strong out of the gate. I figure they will do even better in a generation or two.


It really seems that nearly everything that's not a full native ObjC/Swift stack or is not a web browser (or based on one, like Electron) is not ready yet right now. It really seems Apple did not care enough to get especially golang and Rust stuff stable for their hardware release. I can't escape the impression that they didn't really shower the wider ecosystem in DTKs and software support, although I'd be happy to be proven wrong there.

Oh well, at least Rosetta2 seems to be working really well - you will be able to run a lot of software you need rather well despite not to the fullest potential. The execution on Rosetta2 is really good and that's important. But I think it does go to show that the "Pro" in "Macbook Pro 13" does not mean all that much. At least not if they're going to ship with the majority of pro software not being native, many popular developer toolchains still months to be ready, and very limited I/O and RAM options. The Macbook Air and Mac Mini I fully get for the first releases on new hardware, but the Macbook Pro 13 really feels odd in this lineup if the word Pro is supposed to mean anything.


Well...when was the last time the entry level smallest MacBook Pro was really pro? If it ever was?

Let’s face it, that MacBook Pro is mainly there to make their buyers feel pro, while not really providing performance benefits over the Air.

It’s like you have the stock car (MacBook Air), the “sports” version of that car which just has some stripes sprayed on and a red colored gear shift knob (entry level MacBook Pro), and then the actual race version of that car which has a tuned engine etc. (other MacBook Pro’s).


I don’t think whether it’s “pro” or not is well defined enough to litigate over, but the reviews have made clear the M1 air throttles after a few minutes of max CPU load while the Pro doesn’t, which seems like a big performance difference to me.


I mean, some tests shows that the throttling takes six or seven minutes of pure CPU hammering to turn on. For some tasks, I agree, that can make a difference — but in the context of these devices with these specs, I just don’t see if. Like, if you need that much sustained CPU usage without throttling, I don’t think the M1 is the right chipset for you. The M1X or M3 or whatever they call the ones that they put in the actual high-end machines and not the entry level stuff seems more apt.

The biggest advantage I see between the Pro and the Air, based on everyone I’ve talked to with both, is battery life. That might be worth the $200 or $250 depending on your storage configuration.


> while not really providing performance benefits over the Air

This is true now, but was it true before moving away from Intel?


No, but that wasn’t so much Apple’s choice as it was a consequence of Intel making promises they couldn’t keep.

For a while, the Air has been the form-factor Apple expected to be getting entry-level-MBP perf from, and requesting chips from Intel to satisfy that; and for a while now, the response from Intel has been a chip that thermal-throttles so hard in that form-factor that the performance has bombed it down to a lower class of computer.

The base-model MBP, then, has been Apple’s compromise: it’s the result of them taking those chips that were supposed to be just fine running in an Air, and giving them enough chassis and fans to make them perform the way Intel originally promised they would.

In other words, the base MBP is “a MacBook Air” in terms of what performance Apple targeted the Air to achieve each gen; and the Air itself is the pretty design Apple’s IxD dept put out in anticipation of that target, mated to an altogether-worse processor in order to get it out of the gate.

Now that Apple has a chip with actual thermal headroom, this duality will go away. You’ll get base-MBP perf in Air chassis, and these overlapping categories will merge into one.


> and for a while now, the response from Intel has been a chip that thermal-throttles so hard in that form-factor that the performance has bombed it down to a lower class of computer.

Are we talking about the same computer, where the fan is not even thermally connected with the CPU heatsink[1]? That's Apple's fsckup, not Intels.

[1] https://www.youtube.com/watch?v=iiCBYAP_Sgg


I would argue yes. The two port MacBook Pro, in my opinion, was launched to replace the MacBook Air when it came out in 2016 [1]. It didn’t have a Touch Bar, for example, and based on my conversations with Apple at that time, I feel very strongly it was meant to replace the Air in the lineup (the 12” MacBook was another attempt to replace the Air, that one I think we can blame a lot more of on Intel). Apple never told me this outright, but that was absolutely the impression I got about how it was being positioned against the MacBook Pro with four ports and it was how I reviewed the first release of that model.

For a variety of reasons, it didn’t work. Not only was the price higher, the port selection (just two TB3s at a time when the industry hadn’t moved en masse to USB-C, remember, this was four years ago) was really limiting. And of course, the keyboard drama.

It is my contention, though I have no proof, that Apple didn’t want to release the redesigned Retina MacBook Air in 2018, but had to based on continued sales of the older model and the lack of love for the Touch Bar free MacBook Pro. (Recall, even after the redesign, Apple was still selling a Broadwell-based MacBook Air, technically into 2019. That was essentially the same MacBook Air that was first released in March 2015.)

Once the MacBook Air was redesigned, the two-port MBP never made any sense, even with the re-added Touch Bar. In fact, every single year, when I participate in Jason Snell's Apple Report card [2], I comment on this weirdness in the lineup. I don’t think the two-port MacBook Pro needs to exist.

[1]: https://gizmodo.com/the-pricey-touch-bar-free-macbook-pro-wa... [2]: https://sixcolors.com/tag/reportcard/


It's early days, but so far this transition has gone massively better than any previous similar processor transition. The PowerPC->Intel transition was much worse.

Not sure what you expected, but having seen previous transitions, this is smooth as butter. If you are a Pro, you know that jumping onto a platform early is fraught with potential gotchas.

> the Macbook Pro 13 really feels odd in this lineup if the word Pro is supposed to mean anything.

There has always been a bit of a blurry line between pro and non-pro Apple products. This model year it means just as much as it has on many other model years. Apple left the "higher end" Intel builds in their product line to address the needs of developers who want 32GB or RAM or many other configurations.

This Pro is exactly the machine that the developers porting Go or Rust over to MacOS will likely be using.


I don't believe I'm saying, suggesting or hinting that this is not going smoothly for a transition like this. If you read my comment as somehow saying this transition is not going smoothly, I'd like to understand why you'd think that and I'll update my comment.

What I'm commenting on is that anything that is not already completely bought into Apple's stack is not there yet, and that reveals where Apple's priorities are. Anything that's cross platform or depends on cross platform components needs to play catch up now. It's fine if they have priorities though?


> What I'm commenting on is that anything that is not already completely bought into Apple's stack is not there yet, and that reveals where Apple's priorities are.

Not remotely.

It reveals who priorities updating their software to Apple's new platform. Apple can't control who ports a given piece of software to their new platform and how quickly it gets done. The surface area is too large.

All Apple can do is get the tools out there for the people who are doing the porting.

Most likely Go and Rust aren't ported simply because porting languages is hard and time consuming.

> Anything that's cross platform or depends on cross platform components needs to play catch up now.

I'm not sure why this is remotely surprising or noteworthy. Apple needed Xcode, Swift, and Objective C running in order to build MacOS. There would not be a platform to try to port to if Apple's toolchain wasn't working prior to day 1.

Rust, Go, React Native, are all by necessity going to be rely on Apple's toolchain to run on Apple, so by nature they take longer to build.


> Most likely Go and Rust aren't ported simply because porting languages is hard and time consuming.

So, to be clear, Rust is ported. It's not a tier 1 target yet, but it does work. Time is not the only issue here, as elaborated downthread. For the gory details, see https://github.com/rust-lang/rust/issues/73908


> I'm not sure why this is remotely surprising or noteworthy.

It might not be for you, but then I'm curious why it's noteworthy enough to have two layers of comments about it. If you don't want to talk about that then by all means let's not.

Apple has priorities, and these have results. I think it would be interesting to talk about that, as Apple could have invested time and money in getting some more things going (I'm thinking virtualization and Docker related things especially - you know, the stuff they demoed at WWDC!), but they didn't. It's fine they didn't, but we can still talk about that can't we?


> It might not be, but then I'm curious why it's noteworthy enough to have two layers of comments about it.

You noted it, I was trying to explain something which seems to me exceedingly obvious.

> Apple has priorities, and these have results.

The reason these tools were built/ run first is due to the priorities and constraints of outside individuals, not Apple's. If you build a graphics editor or a text editor using Apple's toolchain and most of your clients run Apple, porting is likely high priority and not super hard.

A lot of these things you are complaining about are just really hard problems.

Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go.

Go isn't available because porting languages to a new processor is non-trivial.

Rust has the above issues, plus didn't Mozilla lay off a huge chunk of the Rust team?


Well we can talk about this!

> Docker requires a hypervisor which wasn't part of the A12Z processor they shipped in the DTK. It also depends on Go.

Apple did have prerelease hardware that supported virtualization, which they supplied to Parallels. Docker has not worked with this hardware based on their press release and GitHub issue [1][2], although they may have received some specs. In any case, Docker depends on Golang with won't release until February.

If Apple did make Docker a priority (which you'd expect given the namedrop at WWDC), this seems quite strange to me.

[1]: https://www.docker.com/blog/apple-silicon-m1-chips-and-docke...

[2]: https://github.com/docker/for-mac/issues/4733

> Go isn't available because porting languages to a new processor is non-trivial.

I'm sorry, I don't buy this at face value for Go and Rust. I believe these teams could support a new architecture very well very quickly with the right tools and support, like how their stuff also runs on weird things like S390. They show day in day out their stuff is very flexible. By no means do I want to suggest it's a trivial matter, but these toolchains are made to be portable and currently support both much more exotic and very similar systems to aarch64 macOS at the same time - like x86-64 macOS and arm64 iOS. Rust's current bottleneck may be due to CI sure, but then the question becomes why weren't DTKs used for CI?

It seems that if Rust and Go developers were approached with the right tools and support, they wouldn't have had to figure things out now. Is it that bad that they have to figure things out now? Not really - but I do think it could have been avoided, and we wouldn't have had to wait for a golang release in February and a Docker release after that.


> Rust's current bottleneck may be due to CI sure, but then the question becomes why weren't DTKs used for CI?

Rust's CI is pretty demanding, both in general, as well as given that it's core to our stability story, we need it to be reliable, and something we can rely on for a long time. DTKs are by very nature not a long-term thing, but a short term stopgap.


> Rust has the above issues, plus didn't Mozilla lay off a huge chunk of the Rust team?

Mozilla laid off a huge chunk of the people they paid to work on Rust, but that was a very small (but important!) portion of the overall Rust team.


> if you're going to ship with the majority of pro software not being native

Shipping this gets M1 hardware in the hands of developers who can then use it to test their software. You mentioned Rust, which is currently blocked on getting hardware hooked up to CI (https://github.com/rust-lang/rust/issues/73908)

Also, such an impressive release of hardware shows third party devs that Apple is serious about transitioning, and doing so quickly. Before this laptop was released we didn’t know what the performance delta would be.


Isn’t this the modus operandi with a lot of stuff Apple does — release new things that the market hasn’t quite adapted to yet, and let the market catch up?

Removal of the audio jack in for headphones comes to mind.


Other than Windows/Bootcamp being dropped, what is there to catch up with?

For the machines these machines replace, non-native apps still run significantly faster under Rosetta 2 than they do on the current hardware.

When native ARM versions of those apps are released, you'll get another speed boost.

I fail to see what is negative or needs "catching up".

Just because M1 Mac's can compete with the all but the fastest laptops and majority of desktops already doesn't mean that's their intended use. These are Apple's entry level models. And the spank the vast majority of other machines even when running code not yet optimized for them.

There is catching up, but it isn't by Apple.


Putting aside the fact that the “Pro” label hasn’t really meant professionals for over a decade (I would say you can see the beginning of the distinction becoming “plus” rather than “pro” with the unibody MacBook/MacBook Pro from 2008 and 2009), I think you misunderstand how the DTK program works.

Anyone could request one and I’m not aware of any developer I know, no matter how small, not being able to buy one from Apple. I was able to get one and I don’t even have anything in the App Store at the moment. As for Apple gifting them to OSS projects, I mean, I guess that would be nice, but frankly the corporate stewards of Go and Rust can buy their own, just as Electron and others did. I imagine some Debian people may have been given loaner machines or stuff gratis, given the custom Debian build proof of concept at WWDC, but I have no insight into that.

The real challenges with AS are going to be for anything that uses virtualization or lots of lower level libraries that need to be compiled for ARM64 and to be honest, that was clear to anyone who watched any of the Apple Silicon sessions at WWDC and read the accompanying documentation.

You’re exactly right that many popular developer toolchains aren’t ready right now. Most of us didn’t expect that and some of us were screaming that loudly (and getting yelled at and called haters by fanbois even though we almost exclusively use Macs and Apple hardware) to prepare people for exactly this reality. The support will come over time and it’s also clear to me at least, that the way at least some stuff works, might not be as nice as the way it was under Intel or even PPC, just because of changing priorities with macOS, and we'll need to come to terms with that too.

You'll notice the 13” MacBook Pro that was replaced in the lineup, a device I’ve always found odd period (just get a MacBook Air), is the tweener device with two ports, and originally , no Touch Bar. This isn’t the much more powerful 13” MacBook Pro that got a big update on Intel alongside the fixed keyboard this May. This is the one that got a fixed keyboard but was still running a two year old 8th-gen Intel processor, AKA, the MacBook Pro you shouldn’t buy and should really just get a MacBook Air instead (the Intel MacBook Air refresh was running a newer processor than the two-port MBP).

Honestly, this is a huge boon for non Apple Silicon ARM64 projects and libraries because a lot of developers won’t do this sort of work for Raspberry Pi or Pinebook or any number of ARM boards, but they will for Apple. And that will trickle downstream.


There is a range of machines in the MacBook Pro lineup. They only replaced their lowest spec MacBook Pro with the new M1 machine. And the lower model always had 2 thunderbolt ports and 16 gigs of lpddr4 ram maximum. The “higher end” models still have Intel chips, and when they get replaced with Apple silicon we’ll see higher specs and by that point better compatibility from compilers and whatnot.

This is the first, and worst / “least pro” Apple silicon machine Apple will ever make. But it absolutely won’t be the last.


> I can't escape the impression that they didn't really shower the wider ecosystem in DTKs and support, although I'd be happy to proven wrong there.

That’s interesting. I was shocked at how many green check marks there are for a chip that was announced in June. It takes time to write and test an application. A lot of teams must’ve really prioritized it.

Also, Apple Silicon compatibility is not enough. One needs Big Sur compatibility too.


I don't think the chip's announcement time really should go into anyone's consideration time here, since it's Apple's own choice to go for these timelines and release a "Pro" product in November :)

I mean this point is largely moot by Rosetta covering all the basics well and still making the Macbook Pro 13 a serviceable Pro computer for a lot of (but not all) use cases. It just seems strange to me that popular developer things like Go, Rust, Docker, virtualization of any kind are still months away despite these being super important use cases of the Mac. Maybe Apple just doesn't feel that way, or have the numbers showing that my impression isn't true, but it feels strange that they're letting the community just figure it out by themselves now.


Is this really a knock on Apple though? It’s not like all this is up to them. Personally I want MATLAB support but Apple doesn’t get to dictate Mathworks schedule.


> I can't escape the impression that they didn't really shower the wider ecosystem in DTKs and software support, although I'd be happy to be proven wrong there.

From all appearances, practically anybody who applied for a DTK got one so in many cases I would take lack of a green checkmark as the dev not applying for a DTK.


I got a DTK and the app I said I would use it for still isn't ready; it just means that the process is complex for some apps.


> I would take lack of a green checkmark as the dev not applying for a DTK.

Not entirely true. A lot of software is simply hard to port or has a lot of dependencies which need to be ported.

A lot of developers already have a full plate and porting to a new platform is low on their list of priorities. As the user-base expands, it will move up on their list of priorities.


Or got a DTK but didn’t get around to using it. I know I stopped counting how many unused eval boards I have...


>At least not if they're going to ship with the majority of pro software not being native,

Complaining about Pro software not being native on Apples entry level machines.

Probably the best praise you could heap on the M1 even though it's obvious you didn't intend to :)


Can it virtualize x86 operating systems? That's when it will be ready.

If you only use the latest version of <whatever javascript lib you're using> it's fine now, i guess.

If you maintain legacy apps, you now need an x86 box. And then you have to ask yourself, why buy a Mac too? They need to fix that somehow. They have enough money to sponsor something based on QEMU, for example. They're just cheap.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: