Apple Plans to Announce Move to Its Own Mac Chips at WWDC
bloomberg.com
bloomberg.com
For better or for worse, my company uses Docker for Mac for the vast majority of the stack that I don't work on but need to actively develop. I'm already paying a huge VM cost and it's pretty terrible. I don't see Apple working on any kind of native containerization solution. Does that mean that I'm going to be eating the current VM cost + x86_64 virtualization cost in the future?
I really want to keep using macOS as a platform. I know I can just stay on the hardware I have, but it's not really practical to be on an end of life architecture. It seems just a tad shortsighted to ditch x86_64 when a lot of people depend on it specifically because it's a shared architecture with other platforms.
The only drawback I've found is I use "puppeteer" a lot which is an API for programmatically using Chrome and Firefox, sometimes I want to see what's going on.
Ive got an 8 core Ryzen 3700x desktop with 32G of RAM and I can bring that to its knees easily. It’s ridiculous.
My preferred environment is yours, inverted. Native Linux (likely Ubuntu 20) with Windows in a VM as necessary. That is making much better use of hardware IMO. It also gives you native Docker, and a ton of easily obtainable software. Much new software development is beginning in Linux or Linux-like environments, including most language development.
Perhaps more importantly, Linux is the deployment target for most cloud based software. The company I work with (Fortune 100) uses Linux as the preferred deployment platform simply due to cost, along with sufficient quality. It's nice to develop, test and deploy all on the same infrastructure.
Software turns out to be very interesting in terms of real lifecycle. Here in 2020, COBOL skills are in (relatively) high demand! While I'm interested to see the "Son of Unix", based on something like Rust and completely cleaned up, rationalized, and secured, Linux and Linux skills will be valuable for decades longer. Windows, I'm not so sure about...
My next development system will likely be a 16/32 core/thread AMD chip. I'd hate to hobble it with the Windows kernel, it's really not aimed at that class system. Linux is.
If anything having a major platform completely switch to arm would be a boon for cross platform support. Something has to bring it into the mainstream and it might as well be the company that gets devs to move mountains for them.
What exactly depends on x64? Hypervisors? JITs? I can't think of that many examples.
The most important software already runs on ARM, because ARM is a really important platform.
Sure, adding yet another platform (macos-aarch64) to everything is going to be some work and some things will fall by the wayside.
It'll still happen for the most part because you know there will be a significant installed base. That's something that other companies (like Microsoft) can't pull off.
They should just buy AMD or something.
What if I as a private citizen just decided to buy a majority stake in AMD? Is that different than a corporation doing the same?
It would probably be shortsighted to do absolutely what you say.
The longsighted game is that they don’t see x86_64 as the long term future so they might as well eat the migration now.
You don't see Apple's solution to a problem which doesn't exist yet on an architecture they haven't announced. Nor do I. I'm not sure why you'd expect to see anything at this point.
> It seems just a tad shortsighted to ditch x86_64 when a lot of people depend on it specifically because it's a shared architecture with other platforms.
A lot of people are interested in how Apple is going to tackle this issue. There are a lot of ways they might address this issue and reverse compatibility. While Bloomberg has been very forthcoming about rumors like this one, they haven't had much in the way of information about how Apple is actually planning on transitioning here.
Apple has done this twice successfully already so it'll be interesting to see how they tackle this. So talking about whether their unknown solution to this issue is a bit premature.
It's a shame really. Apple doesn't do containers. They don't do virtualization. They don't do open source. It's all sort of like the jackling house [1]
It would be SO cool to do FROM macos:10.9 in a native mac dockerfile.
1: https://en.wikipedia.org/wiki/Jackling_House
(don't do = don't do in a direct committed way)
The value proposition of OSX 10.2 when I switched to a Mac was a clean, elegant UI with that unix terminal for developer tasks. The Windows 10 UI is good, and these days the *nix of real interest is Linux, so the WSL handles that side, so for the same logic, I've moved back in the Windows direction.
Meanwhile, my MacBook Pro 16" has daily kernel panics when it is connected to an external display. It has been reported by many people on Macrumors forums and has been happening for months now. No fix...
I was playing around with it a few months ago and filesystem-intensive operations (like running npm install) were horrendously slow. Has that changed with wsl2?
I’ve been considering picking up a ryzen laptop and running Linux on it, and trying that out as a daily driver. But I don’t have any patience these days for the hacky wifi driver installation dance. And I’m nervous after having a Linux laptop cook it’s own battery when it failed to sleep properly in my backpack. It’s been a couple decades - do Linux laptops just work yet?
WSL2 improves that by offering fast fs on linux side. The boundary is still slow. For example, if you go into /mnt/c and use git status on a large repo it will need to go through the boundary. It is slow (not painful but not pleasant)
My current setup has all my source code on the linux fs (/home/user) and I access them using VSCode remote extensions. The performance is fine. I can't really tell if native macos experience or this is faster. I also tried JB iDEA. It works across the filesystem boundary and even if the access is slow, it does not reflect to real world usage much. But you'll feel it if you look for it.
Another option is to run GUI apps on Linux side and use an X11 server on Windows. This just works fine and they recently announced that the WSL will have built in support for Linux GUI apps.
And it's based on Arch, so you'll be able to take advantage of the excellent Arch software repo and wiki (if necessary).
Linux on laptops is fine nowadays. Recent versions of the kernel vastly improved battery life on Intel. It's much better than it was 10 years ago.
Unfortunately, late-2018 MBP with 560X is apparently incapable of setting the right widescreen resolution (5160x2160 or so), an error that was reportedly "fixed" in 10.14.2 beta... yet here I am with 10.15.4 and nope, you either get everything scaled too big, or you get big black bars on the sides.
I had an old 27" dell monitor that I thought was a blurry POS, until I plugged it into a Windows box and realised it was macOS that was the POS
Also setup asked about some tracking stuff and I said no but haven’t done any research to see how they treat it.
Shutup10 is the best AIO, most tested tool I have found for Windows 10 that doesn't break stuff.
There's also custom ISO's with binaries and entire product suites removed which may break some stuff that runs on Windows 10 (eg requiring the Store for some games) - but I'm not comfortable with the level of transparency custom ISO's offer, so I don't do this: https://ameliorated.info/
My recommendations is to get a copy of Windows 10 LTSC (which doesn't include Candy Crush etc) and run shutup10 on it for your work environment. It's the least risky option for an every day driver.
You can use /quiet and /force flags on shutup10 and create a scheduled task to re-run it occasionally.
I counted six toggles related to tracking that were enabled by default in the OOBE. Forget one toggle and you'll spend 20 minutes digging through Control Panel for it. The "NEW" Microsoft, right.
Not sure how this impacts theory of neglect.
Is it correct that the best folks from any given team at Apple are assigned to new, big initiatives?
Yes, they should. The vast majority of QA should be automated unit and integration tests.
> QA is unnecessary
This is objectively false. Even if you perform 99.999% of all QA in an automated way, you're still going to miss those edge cases, like the infamous daily kernel panics due to buggy support for external USB-c displays that only real humans testing your product in the real world with 3rd-party devices can find. QA is still extremely important, and when companies like Apple neglect it, they end up shipping buggy and disappointing products.
1. mac os has been buggy for quite a few releases already
2. outside of drivers and apps, ios and macos are basically the same kernel and userspace/libraries, so there isnt much to port
mac os at large has a quality problem. I have gotten more kernel panics on my personal and work laptops in the last 6 months than I have on my windows machines in the past 5 years.
My 10 year old Macbook pro running lion, if I go to the Safari menu in the corner click it and move the mouse up and down really quickly over the menu items, the responsiveness is instant & there is no flickering.
Doing the same with the * * max spec * * 16" Macbook Pro has flickering. Easily reproducible in this very Safari window if you're reading this on a Mac.
Everything has been downhill this decade with the quality. If the focus was on ARM then hopefully if it was a resource diversion the quality is good after.
Well i hope at least..
Often, the price would give you considerable lower specs than a PC, but the mac would be faster to desktop, faster to start working in an application, smoother IU, longer battery life, etc.
Focus on macs used to be "faster to work with, not faster to calculate with"
It was those things that warranted the higher price tag.
Working on those LC II was more of a need that nothing else was available at the computer lab than anything else.
Modern computers, SSDs, super fast RAM, GPUs etc, all needed for computing. But the older machines with outdated hardware, low and slow RAM, and tiny slow PATA or SCSI HDDs feel so fast. I don't doubt that the Quadra feels just as quick. It's not just Apple, same goes for Windows of the same pre-Y2K era compared to now.
The question is why. Why is the user experience so poor. Why is it all so sluggish now. Have we exchanged performance for developer convenience just to punt out more underperforming software? Is the art of creating fast UI code dying out? Is the shift from C/C++ to Swift/.net interpreted bytecode-type solutions the cause? Too many layers of abstraction, too much cross-platform code with compromises to make it run anywhere?
Whatever it is, we're churning out software quicker now but on faster hardware it runs worse than the older tools. It feels backwards to me.
Generally speaking, yes. We prioritize speed to market over everything always.
I can maybe understand it in the early experimental phase, but there ought to be a point where the software's authors go back and do it properly.
It's worth the effort! If one application is significantly more responsive, people will think it feels nicer to use.
Simple answer: Abstractions.
I haven't run any benchmarks but I would expect the Q950 to be comparable to an early SUN SPARCstation, the Q950 has more RAM too. I do run NetBSD on both of them.
Linux is the new Mac, then. It's really fast even on otherwise low-end hardware, and the price tag is pretty hard to beat.
As a Linux desktop convert I find it hard to disagree. I used and owned macs from the 68k through PPC and one intel (C2D), they were all fast (to use), that last intel one from 2009 still felt slick... but that's where it stopped for me, everything got super bloated and slow afterwards.
I may not be 100% correct here but it seems like most of the problems are with their OS and software, which is a shame because they are the only remaining computer company that has retained control over all of their hardware and software - something that should have always given them an edge in fine tuning, but they seem to be throwing it all away.
> I have seen developers starting to use Linux machines for a few years already. It kind of reminds me of how it felt like when devs started to adopt Macs around 2005/2006 or so when Ruby on Rails became popular. And just like when Macs became popular, mainstream adoption seems to follow: I've already seen a sales guy running Ubuntu Linux (by his own choice) over a year ago.
Note: the driving forces aren't exactly the same, but the feeling is reasonably similar in my opinion.
Also I should note that the adoption of Linux among sales and other non-devs has surprised me.
That is interesting, I've seen colleagues go both ways - well three ways -
Web devs going from windows/mac to linux, then a couple going back to both windows and mac due to needing to use adobe products (used to dual boot and now use WSL).
Most people pick up on and appreciate the difference in speed/responsiveness and ease of doing dev (i.e it has an actual proper built in package manager that is fast, no brew crap). Whether they stay seems to be more to do with dependence - people who really like it even start to re-evaluate if they are truly dependent on software they liked, vs their new found utility.
Media seems to be a big problem, (adobe et al), but sales perhaps not, i mean office is all going cloud these days anyway.
However it's nothing compared to the super bloat of today, and the stupid inefficiencies like 10s of GB of updates.
Whatever you do, don't make Ubuntu your first distro. You'll regret it. You'll spend more time tinkering with it and rescuing it than anything. Manjaro is fast, simple and you won't have to hunt down software because the Arch repositories have everything you need.
I don't prefer laptops, but I did install Manjaro on one laptop - an Acer E5-575G, and it ran perfectly. Everything works: wifi, sleep, even the Fn keyboard controls to adjust volume, brightness, etc.
Of course, there are lots of people who never had a problem with Linux at all ... except that when they share their screen in MS Teams, it's two 4k screens plus laptop display stitched together with a fairly complex fix that involves scripting virtual webcams, or there's no way to use the projector at something less than 100%-scaled 4K that can be done on-the-fly, or wifi stops working until the next reboot when plugging in the USB-C hub at the wrong moment, or the fingerprint sensor either never works, or nondeterministically sometimes works, or company e-mail works fine in Outlook and Apple Mail but not at all in Thunderbird, or the fans run all the time ...
I've never had a smooth ride myself trying Linux on a desktop or laptop, nor have I ever talked to anyone who didn't eventually admit to having issues like that – and while that may be tolerable for someone who values being able to use Linux a lot, it's unacceptable and broken for everyone else. Maybe there are people who actually do have a ride so smooth they never even have to touch a command line at all – but I have strong doubts.
Yet that's one of the bars to clear. With Macbooks, I never have to touch a command line (I can, if I want to, but I know no one outside of my dev/ops/research/nerd bubble who's ever actively used a Terminal). The vast majority (for a very large value of vast) of people out there have never touched a command line before and have zero inclination to change that. They don't have anyone to sysadmin for them, either.
Ubuntu on a Macbook-Air-ish affordable and somewhat stylish laptop, that'd be it, can't use those Airpods. Or any other headphones. Or play any sound at all, because for that particular sound chip, alsa needs this particular config to be set in such and such a way.
To be the "new Mac", it'll have to "(very mostly) just work" like MacOS, Android, iOS, ChromeOS, or even Windows – bonus points if it has a walled garden with lots high-quality apps and no really easy way to break out or actually break things, because that's a big feature for people who just want to _use_ a computer, not build, admin, secure and maintain a complex OS.
And all of this is deeply frustrating, because I _like_ Linux. But I hate having to put in all the work and still lose so much comfort, efficiency, dependability and ability to do things I can do easily on MacOS, on inferior hardware, without a Touchbar, without a proper touchpad – it's just not there yet, not by a long way. And if it's too much hassle for me – someone who's built a Linux router on a 200Mhz Pentium 2 when Pentium 2s were still decent machines and 10mbit LAN was fast – then I guess it's not going to work for the vast majority of people, either.
Last week I had to use OS X for the first time ever, on a friend's iMac. It was irritatingly animated and it required unintuitive steps to open a terminal. Something called Finder ( but I'm not searching ), then clicking down into some folders and finally Terminal.app
All whilst trying to ignore the distraction of various icons bouncing on the dock bar. And occasionally I'd press something my mistake and Finder would minimise itself.
Thankfully I had my phone to hand to look up how to use this intuitive system...
On a new Catalina install, you'd have a hard time to not find crucial apps easily, like Safari, Mail, Calendar, something to write a letter in ... because they are in the Dock already, or prominently in LaunchPad, which works just like the home screen on a phone, and is in the Dock in the leftmost position – and the OS has an onboarding flow that pops up right away and that'll take care of explaining those things. So, if you, as someone with little expertise in IT, open that new Macbook Air, chances are you'll find your way around quite well with the tools you have. The weird @ placement will keep being an annoyance though. Chances are you know how to use the Preferences app on your phone, and you'll probably be able to figure out the System Preferences app in LaunchPad with that knowledge, and it can do everything important. Pretty big deal!
If you need a terminal, you're way way way ahead those people in terms of computer literacy and certainly wouldn't have any serious problems navigating any sensible operating system there is, just some annoyance if it doesn't work like (I assume) the Linux setup you've spent a lot of time dialing in perfectly. Most people wouldn't know that their animations aren't ideal for them the same way I couldn't tell if a certain dentist's drill had somewhat less than ideal ergonomics for a cavity in a specific place. And besides (n=1) I've been using Macs all day for way over a decade and I never found any issues with the animations; maybe I'm part of the majority and that's why people aren't very vocal about the OS animations.
If I extrapolate from my experiences (which are numerous pieces of anecdata, but of course still anecdata), there is a significant number of people who use Macs because they want something stylish and pretty that is easy to use for "casual" computing needs and is fairly frustration-free. If something is wrong, you dig through preferences some and there'll be a radio button to change that. If that projector is at native 4K, you open System Preferences, Displays, click on the icon that has the largest font – that'll do it. And it's built with the knowledge that most users will not be able to do much more than that – so having to resort to a shell and fixing up config files based on a forum post from 2012 isn't going to happen – they'll turn up at the Genius Bar and will be disgruntled customers if the people there can't help.
So, if Linux is to be the new Mac, it'll need to offer that kind of experience as well. Currently, in my experience, it doesn't offer this at all.
The only reason I can imagine buying a Mac again would be for iOS development, but it seems like virtualized MacOS has come a long way—anyone using hackintosh or virtualized macOS for iOS development? Do you run into weird edge case problems due to Xcode not running on its “proper” hardware?
Where I see it winning out in the future is that Proton/WINE on Linux is working pretty dang well and my gaming options on Linux are great. Graphics drivers are good, and my choice of hardware is very broad. GNOME 3 is decent enough, and there is KDE or MATE or Fluxbox/Openbox or whatever.
(sidebar: haven't tried any of the Wayland compositors but they look interesting)
That said Apple doing their own hardware has always been the ultimate goal. End to end control was always the dream.
Ryzen 4000 has something to say about that ;)
I can order a machine that outspecs a MacPro from Dell or Lenovo, but it won't be as tightly integrated as a Mac
The build quality and software is where macOS was always excellent when Jobs was at the helm. Now software is finicky, lacks support for standards and the build quality cannot be trusted as a whole.
The point is precisely that. Average components are blazingly fast these days.
Also, Catalina is doing a lot more work under the hood than Lion.
What I saw was not flickering, but that I could move the pointer faster than a bar could be rendered and that the UI opted not to render it in that case. Is that what you refer to?
Didn't the first retina MacBook Pro ship with Lion?
https://everymac.com/systems/apple/macbook_pro/specs/macbook...
A few years ago I replaced a 2012 MacBook Air with a much more expensive 2016 MacBook Pro (with Retina display) and there was an obvious regression in UI responsiveness. It was bad enough that I regretted giving away the older laptop so quickly.
The difference is almost certainly the higher pixel count. At least as of 2016 the onboard GPUs in intel chips haven’t been fast enough to make the UI feel snappy. I ended up buying an egpu for my desk to make my external displays usable. The experience out of the box using the onboard gpu was awful.
1. MacBook 12" 2015 feels dramatically faster at 1x scaling vs. 2x, even with the same output resolution (2560x1440@1x vs. 1280x720@2x.)
2. Mac with 8GB RX 580 GPU. With >1x scaling, as I add load (i.e. Chrome tabs) it eventually runs out of GPU memory and starts paging to system RAM. The whole thing grinds to a halt at that point.
The rendered pixel count makes this effect worse -- dual 4ks are slower than a 5k, is slower than a single 4k, is slower than dual HDs. This is to be expected, but we're talking about an 8 gigabyte GPU, and the framebuffer sizes should be a tiny drop in the bucket.
None of this happens at 1x scaling. Running a native (2x) scale factor feels a little faster than a downscaled (2x -> 1.5x) scale factor.
As far as I can tell, load and GPU mem usage scales with:
(number of GPU applications * total rendered pixels) ^ k.
At 1x scaling, k is close to 1. At HiDPI, it's greater than 1.
It depends on how many high dpi bitmaps at full depth are kept. Uncompressed HDR 4K gets large pretty quickly.
And then it's not one bitmap, but multiple layers - backgrounds, rendered text...
And this is where I don't know what to think because "keep it all in vRAM" is clearly a terrible algorithm, and I have faith in the macOS developers, and yet my data suggests that this is exactly what they're doing. I don't see things swap out when there's memory pressure; it just keeps on allocating until it's full, then spills over to system memory and makes everything slow.
Counterintuitively, the iGPUs have an advantage here. They always run from system memory but they have a faster path to system memory -- they don't need to operate over PCIe -- so (a) you don't have a large perf gap between the 'full' and 'not full' cases, and (b) spillover doesn't hurt. You use a lot more RAM, but you can buy more of that. I can't easily add RAM to my GPU. At best I can double it, and that just means 70 Chrome tabs instead of 35.
I'd love to hear from someone at Apple who's seen the internals of this.
I think successive software updates have made the situation marginally better - but I might have just acclimatised to it.
I’m very curious what the situation looks like with arm laptops when they launch. How will the graphics performance of an A14x chip compare to my situation at the moment? I assume they’ll be faster than intel iris graphics but slower than an egpu; but it’ll be very interesting to see!
There has never been a hard and fast criteria, beyond that ostensibly the benefits outweighed the detriments. I had a 3rd gen and enjoyed that super crisp display, so it was an okay compromise.
Add that recent software iterations have put dramatically more emphasis on power savings/efficiency, and are much more proactive about frequency scaling, etc.
As an aside, this post will be autodead, and that's cool. Love ya HN.
That's... not how it works. More pixels means more CPU, GPU and memory cycles to fill them and more DAC cycles to read them out and scan them to the display. That's just fundamental.
Computers aren't slow any more. Even laptops can render a menu bar.
Moving frame to frame you see that the blue highlight lags the mouse by one or two frames. Seems okay to me, I don't see any flickering.
Taking a new screen recording I did a quick time-space plot in Matlab.
It appears to be an issue when you move your mouse more than one pixel per frame of the refresh rate.
I simply don't care, even if someone can find an anomaly in frame by frame inspection of rendering.
There are times -- and perhaps this is one -- where it makes sense to drop things in presentation perfection in order to make a UI more responsive and better for the user's overall experience. I'm not a UX expert by any means, but I know for me there is little as infuriating as when I issue some sort of command and get no response -- if the cursor is pointing at something in a menu, that thing had better be selected and I don't really care a whit whether or not the UI representation of it moving there was frame by frame perfection.
You don't have to view this frame to frame to see this you can notice it with every day use.
The thing is a decade old machine running the same software can do better, even if you analyse it frame by frame, its perfection. We've gone downhill.
There are a lot of places you could assign blame for this nonsense, but perhaps a better path would be to just start a new company and release products that don't suck. Surely there is at a small, yet viable market out there for "how macbooks used to be prior to 2014".
I'd throw my wallet at the first company to produce an exact clone of the late 2013 macbook pro running a non-shit variant of OSX. This is easy money sitting on the table, but there's probably more money in shoving 12 month product cadences down everyone's throats.
(I'm not 100% sure whether the 2014 MBP can run Mavericks, it depends on when exactly in 2014 in was released.)
But just for fun, if your benchmark is Power PC support then I am delighted to introduce the latest version of OS X that can run on your hardware: newly-PPC-compatible Snow Leopard! https://forums.macrumors.com/threads/snow-leopard-on-unsuppo...
• Is running an up-to-date web browser (Firefox ESR).
• Has all important data backed up to cold storage regularly.
• Is behind a router. All incoming ports are closed, except one for ssh. I've looked through openssh's CVE list and there's nothing concerning.
• Is running local software which I consider trusted.
I was originally also planning to get a copy of Little Snitch, as an additional form of monitoring. I haven't actually done that yet, but I should.
Some possible attack scenarios I can imagine:
• There's a zero day in Firefox. My vulnerable OS does not offer the extra layers of protection that a newer one might.
• Someone exploits Spectre/Meltdown/etc via Javascript. My attacker is incredibly lucky, and the tiny portion of memory they retrieve just so happens to be the bit that contains something vital like Bitwarden's master password.
• Someone emails me a malicious image which isn't caught by Gmail (personal accounts) or Microsoft Exchange (work account), and it infects my machine upon being rendered by Apple Mail.
• A person I know/trust is tricked into sending me an infected document, likely a PDF or MS Office file. Even though I don't have Acrobat or Microsoft Office installed, the vulnerability is compatible with Preview and/or iWork '09.
None of these scenarios seem particularly likely. The key here is that I'm not important enough to get hit by a targeted attack, and frankly I don't think I would survive one on an up-to-date OS anyway. In exchange for this minor risk, using my computer makes me much happier right now than it did six months ago.
I admittedly didn't test with an HDD though, Snow Leopard would probably have done better there. On the other hand, you give up a lot of good, useful features by going with Snow Leopard. I know a lot of Mac users were annoyed with autosaving when it was first introduced, but I remember typing essays with Pages on Snow Leopard in High School, and losing many hours of work due to the lack of any autosave functionality.
Not the end of the world, but not perfect devices from a hardware quality standpoint.
Revenues for Apple and MS are at record highs.
It’s clear that they are valuing the experience of the majority while rightfully ignoring the vocal minority.
The iPhones and iPads are quite good, however, but I suspect it's because Apple specifically optimised them to be.
Mountain Lion is also a possible candidate (because it fixed the problems with Lion), or Mavericks if you were on memory-constrained hardware (because it introduced memory compression). But it's probably Snow Leopard.
I've seen this work and it makes a big difference.
I dunno about interface responsiveness, but things I actually want to DO -- server virtualization, Lightroom, etc. -- sure do seem faster on my new rMBP than they did on my 5 year old model.
I blame a memory leak in the WindowServer for it. Once it has over couple of GB allocated RAM, then the mouse is basically unusable. Especially text selection by mouse is a nightmare :)
Why is hardware lower quality? Isn't the encoding algorithm deterministic and so the same wether you do it in hardware and software?
You wouldn't want to encode a movie with phone settings. Encoders like NVENC and QuickSync would drastically improve encoding speed at the same cost, albeit likely at slightly higher quality because those chips can be actively cooled and therefore process more data within a time frame.
Software encoders allow complex settings or just spending more time on each frame, as well as they just might have more memory (I'm not an expert, but IIRC h.264 quality levels corresponded to huge jumps in memory usage, which had impact on available hw encoders)
There is no "the encoding algorithm" when it comes to video encoding.
Think of a video codec as being analogous to HTML. HTML isn't defined as "this is the algorithm for producing a HTML file", it's defined as "these are the things a browser will do when you give it this data". How to combine those things to do what you want is up to you.
It's the same for video: the codec standard doesn't tell you how to encode the video, it tells you what you need to support if you want to _decode_ the video.
So different encoders can encode videos in entirely different ways, even when using the same codec. As such, they can have very different performance characteristics.
As for why a software encoder will provide better quality, it's because a software encoder has luxuries like a high-power general-purpose CPU and copious amounts of memory that allow it to do things that are difficult in dedicated hardware.
A hardware encoder on a mobile device for example will often be a tiny tiny piece of silicon in some corner of the SoC, so it'll have limited physical space for complex logic. It'll also have serious power and thermal constraints. These are things a hardware encoder has to work around that a software encoder doesn't.
At the end of the day the enduser doesn’t care about the technical differences.
They just want their videos. Which is why the iPad is so impressive.
Given the technological steps Apple has made, it seems like it is only a matter of if, not when Apple will switch over some computers.
I personally would predict the Macbook Air (potentially a new Macbook), Mac Mini, iMac and potentially the iMac Pro will switch over to Arm first. It seems like a poor risk/return ratio to switch the Macbook Pro and Mac Pro lines to Arm at this point in time. Who knows what the manufacturing yield will be on the initial 5nm chips.
overall I see how moving to ARM is a good move, but it's so annoying at the same time especially since they just fixed up the mbps which drove a lot of people to buy them (including me) I feel more burned than excited wouldn't surprised if the same folks who greenlit the butterfly keyboards were behind this
[0]: https://aws.amazon.com/blogs/aws/new-m6g-ec2-instances-power... [1]: https://www.honeycomb.io/blog/observations-on-arm64-awss-ama...
You are probably thinking of 64-bit ARM, which Apple was very early to use.
Why _web_ developers?
I'd have thought that web developers would be some of the last developers to abandon Macs due to a change in architecture given that lots of web development is done in scripting languages which would need minimal support to move architecture, and the fact that Apple's ARM chips tend to perform well in JS benchmarks.
I'd expect that it would be system software engineers working in languages like C/C++ who would abandon the platform given that the majority of their tools and libraries may need extensive porting work.
Linux is a poor option in this regard.
Docker for Mac runs a Linux VM that in turn runs the containers running on developers laptops.
On the other hand, why not run arm-docker on a virtual arm-linux?? Why does it have to be x86?
Now take away the space, power, and heat constraints of the iPad Pro.
Edit: wow, this touched a nerve and got downvoted into oblivion. Well, here's a benchmark for the latest iPad Pro:
https://browser.geekbench.com/ios_devices/58
And the iMac Pro:
https://browser.geekbench.com/macs/imac-pro-late-2017
The single-core scores are about equal -- even though the iMac Pro is averaging a higher clock rate.
And at 18 cores, the iMac Pro trounces the iPad Pro's 8 cores, but again, heat and space constraints.
Adding more cores isn't necessarily an option for Apple yet either, considering that (from what I understand) their yields are relatively low because it's hard to make chips that large on such a small node. Even more cores means lower yields and greater costs.
I'm not saying the iMac Pro won't get there, but I highly doubt it will be a part of this first wave.
Porting to ARM is not impossible, but it's an additional cost they have to deal with.
If we get the worst case scenario and Apple ships only ARM hardware from January 2021, then I feel like there's going to be some serious problems.
That seems extremely unlikely to me.
I do run OpenJDK on aarch64 and it seems fine but I don't run anything particularly serious.
If Apple ship an AArch64 machine with plenty of RAM then it would make a big difference to what applications people try to use.
Java's actually the easy case. ARM means a lot of docker containers won't work, your development architecture is different than your protection architecture, cython libraries, etc.
This is probably the right move if you want to build a laptop with good battery life, but sort of like removing the escape key, it's problematic for a large segment of Mac buyers.
No it's the compilers in the JDK, at least in my case.
So at the first WWDC the developers get a one year head start to work with Apple to get everything ready for the new platform, and then at the second WWDC Apple finalizes the launch plans and sets the launch dates for new hardware.
It seems likely that Intel editions of the 16" MacBook Pro and the Mac Pro will continue to be sold after September 2021, due to hardware DRM dongle issues — and it's likely that they'll keep around an Intel Mac Mini as well.
Given that ARM is now a datacenter option, it's probably time for the JVM ecosystem to stop being Intel-only in any case, but historical evidence suggests you have at least 15 months before general developers have any hope of buying one of these.
https://www.tomshardware.com/news/apple-may-start-selling-ma...
I'm pretty sure this move is for power consumption and maybe so all Apple products are on the same architecture.
You aren't comparing costs fairly here. A13X costs $30 each + $XXX million to develop. With Intel the development costs are part of the SKU. If Apple launches a series of desktop CPUs, the cost to develop those chips is going to be substantial. Some of that cost will be in common with the iPad/ iPhone, but a good chunk will be unique to their new CPUs. Since Apple ships far fewer Macs than iPhones, the development cost/ unit will be significantly higher.
Maybe some. Just considering the size of the devices, I'd expect the 16" MacBook Pro would have beefier CPU options than the iPad Pro.
- MacBook Air
- High performance MacBook
- iMac / Mac Mini
- iMac Pro/ Mac Pro
If next gen Macs are going to support some kind of x86 emulation/ compatibility layer, performance isn't going to have to be comparable with Intel, it's going to have to be 2-3 times faster so I'm expecting something quite a bit beefier than what the iPad Pro ships with.
Software is expensive, writing, testing , QA.
On the hand, they are spending billions on stupid Apple TV Dramas, I guess they might as well make their own CPU for high end Mac.
This I disagree with. The Intel premium here is likely somewhere in the ballpark of $100-200 per CPU. Spread across 16-20 million Macs sold per year, we're looking at conservatively $2 billion/ year they can invest in CPU design.
More important, Apple will control what features get added to their CPUs and can integrate other functionality into the CPU the way they have with the A-series chips.
And this is a recurring long term investment.
If Apple is transitioning regardless, it's either lose out on potential profits completely or take what they can get for a few years. Making a deal would hurt Intel and get them money. AMD could probably hold out for a guarantee that Apple would buy their chips for the next 3-5 years too (at least on desktop).
All the talk about x86 emulation doesn't seem feasible. x86 is crufty enough when implemented in silicon and would be much, much worse being implemented by a team that hasn't spent their entire life learning all the weird little performance tricks for the architecture. Even if they somehow succeeded, Intel has deep pockets too and lots of lobbyists and would probably push for (and get) an injunction while in court. Even if Intel lost, the injunction would hurt Apple severely during the transition period. Apple would need still-patented x86_64, SSE x.x, AVX, virtualization instructions, etc that are all patented. In addition, if Oracle v Google decided in Oracle's favor, that would open yet another attack avenue.
Throwing in a couple hardware cores shouldn't cost a ton and would stop those legal concerns in their tracks.
Intel must be creating a lot of problems for Apple to warrant this move. Or maybe AMD is not willing to give Apple the same sweet deal Intel gave Apple to get the transition.
There haven't been many interesting CPU changes in a long time, and they're still using TSMC for fabrication. Arguably, you're better off with two vendors. I'm not sure if Apple has genuine roadmap concerns or is falling in the not invented here trap.
Well, eventually, I imagine that Apple will continue to support their x86 Macs for some time, especially as we've recently had the launch of the revamped Mac Pro which is not a cheap machine. But maybe ten years down the line they'll stop updating it and that will be that.
https://youtrack.jetbrains.com/issue/JBR-2310
I lost days of time to what very much appears to be yet another hardware bug in Intel's latest core. If you don't believe me that it's a hardware bug, read the whole thing. It's probably a zero day security vulnerability too.
The only catch is: if Apple also takes the opportunity to iOS-ify Mac and lock it down to the point that it is no longer useful for professional work, I will have to drop the platform entirely. I've seen some decent AMD Ryzen laptops showing up on the market and I could use Linux with a Windows VM for the occasional Zoom call or similar thing.
Honestly though... I think if Apple pulls this off well without alienating their user base, it probably spells the end of the X64 architecture outside cloud and servers. Given that people prefer to deploy to the same architecture they develop on, it probably means X64 will eventually die in those areas too. AArch64 could end up being the core architecture of almost everything by the 2030s.
Does this bug also appear on Linux or Windows?
Read the above sentence again. It escapes VM isolation.
It also crashes the whole machine on a Microsoft Surface tablet with the same chip in it.
So three OSes, and it escapes VM isolation. It's a hardware bug.
Mitigation so far is to try to use exotic JVM options to make the JIT be less clever and not emit whatever the offending code is... but we don't know what it is, so it's shooting in the dark.
The same bit of software:
* Crashes the OS when running native, where OS is Windows, Mac, and Linux.
* Crashes the host OS from inside a VM running Linux or Windows.
I can't think of any explanation other than a hardware bug. How can the same crash happening inside and outside a VM on multiple OSes be anything else?
The other way around works pretty well these days. Windows 10 and their new terminal app plus WSL2 for development is a pretty good combo. Most things work as expceted, and if you use Visual Studio Code it has good integration between the two environments.
Modern processors are crazy complicated.
My personal computer on the other hand uses pretty much only App Store and Homebrew cli utils and is rock solid.
Apple has outlined how it would work: by moving drivers into userspace (https://developer.apple.com/support/kernel-extensions/ , https://developer.apple.com/documentation/driverkit)
I guess that, with a move to ARM, they would enforce this for all drivers, if performance allows it (video drivers might be the exception)
The iOS app had a tiny fraction of the functionality of the full Mac app. Adobe were simply lying when they announced that. Indeed, it's a very poor imitation, just with some of the same codebase underneath (and literally nobody is "wow, Photoshop's famous codebase! That's what I want because it's totally not an infamous piece of garbage that I tolerate because of it's functionality!").
https://devrant.com/rants/1292858/found-this-gem-on-github-a...
https://theblog.adobe.com/adobe-photoshop-aero-gemini-dimens...
Don't forget that most photoshop code also ran on PowerPC and is thus platform agnostic.
My guess is that dropping 32-bit support last year was a way to front-load the developer cost / user pain of the architecture swap in service of a mechanism like this, which presumably only would be practical 64-bit x64 to 64-bit ARM.
That is extremely unlikely.
Anything involving gaming is unlikely to run at even 50% of it's performance.
It is going to be an extremely, extremely rough transition.
Other recent more desktop like games are probably using a big game engine like Unity/Unreal with Metal support and probably also only need a recompile. And older games which are less likely to be recompiled can likely run perfectly fine even at 50% performance on a new ARM MacBook which is very likely way faster than the latest non pro intel MacBooks.
Lol. That isn't true, in any way. There is virtually no commonality.
> Other recent more desktop like games are probably using a big game engine like Unity/Unreal with Metal support and probably also only need a recompile.
Do you really think that's how game engine support works? Heck, if that was remotely the case why does Metal get so little support with titles even on x86?
> And older games which are less likely to be recompiled can likely run perfectly fine even at 50% performance on a new ARM MacBook which is very likely way faster than the latest non pro intel MacBooks.
Any game with graphics performance is not going to run at 50% performance through an emulator. If it's done very well it might run at 20%, much more likely 10%. A "way" faster ARM MacBook isn't going to run five times faster than the Intel equivalent. Different thermal windows aren't magic. A 10% performance improvement is unlikely.
I use Logic to make music. Many of te plugins run on one core, and can take up 100% of it. If performance via emulation is around 50%, that means a lot of drop-outs in the sound, and basically an unworkable situation. Been there, seen it, don't want to go throug it again.
The bigger plugin makers will probably port their products, but it's going to cost the user; the smaller ones may simply give up macOS completely.
On the other hand DAWs are more complete in the box now than ever so this is probably less of an obstacle to switching from the users' point of view than it would have been 5 years ago.
asm: AVX2 version of saoCuStatsE3, (136881c -> 45126c)
~/x265> find source -name '*.cpp' | xargs cat | wc -l
95358
~/x265> find source -name '*.asm' | xargs cat | wc -l
168690
~/x265> find source/common/arm -name '*.S' | xargs cat | wc -l
11014
I've been involved in more than one platform transition, and there are always problems. Plugins are complex.
The writing has been on the wall though - Catalina with all its dropped frameworks & notarization already pushed some developers to give up on the Mac (or tell their customers to just stay on Mojave). Loads of Waves users were unhappy having to upgrade to v11 for Catalina support, and won't be happy paying yet again for Mac ARM support.
Come join us on the dark side. Plenty of us music people already switched from Mac to Windows. Even Linux audio seems to have come a long way, with Bitwig, Reaper, Renoise all supporting Linux now, and even plugin devs like u-he.
There is a huge gap in gameplay, complexity and whatnot between desktop/laptop/console games to those in phones.
Apple's consideration about gaming will be "we have this massive catalogue of titles customers can play already here that we've been marketing, investing in, and pushing for years (and which get us a nice 30% cut of profits...)"
> huge gap in gameplay, complexity and whatnot between desktop/laptop/console games to those in phones
I made no judgement on that, simply that Apple's rationale for gaming is going to be based on the millions of ARM optimised titles they already have ready for the jump.
The mobile gaming market is a lot bigger than the desktop gaming market for Apple - expecting that to not have an out-weighted influence on their decision making is absurd.
The answer is that they're not the right types of title for the Mac demographic, and that the business model isn't there to justify the porting costs (and moving to ARM does very little reduce those, which are mostly UX related).
There are games that run on OS X , but even for me as a relatively hardcore OS X type, I go sit down at my Windows 10 desktop machine when I want to game.
Many users live mostly in the browser, anyways. Photos, Pages, Numbers and Keynote will be native. If they convince Dropbox and Microsoft to have native apps, support iOS apps better than they do now (that should cover casual gaming), and make it cheaper than the ‘equivalent’ x64 one, I think they would have a product.
So it'll be really interesting what they've done, they may well have not merely an emulator but something involving a hardware layer as well. Or I guess maybe they'll just dump BC like some have pessimistically expected, but useful forms of x86-64 becoming open to any player seems like it might be a pretty big deal for the industry doesn't it? As we've reached the flatter part of the S-curve and the ISA lifetime has stretched out far longer then anyone expected at one point, it's actually catching up with old IP law for once. 20 years is a long, long time in tech. But it's not forever, and maybe not so long as it once was even.
Apple still commands only a fraction of the overall PC market, and while that is not growing as whole, their portion could by a great deal.
You’re right that there have been major missteps. But there have also been major corrective steps as well, which are just as important in gauging how the company will behave in the future.
I don't understand what you mean - you absolutely can emulate AArch64 in AMD64. You can emulate any instruction set in any other instruction set.
Zero chance. It's quite likely they don't even have a roadmap for how they'd develop silicon for the higher end chip sector at this point in ARM, never mind getting it done and moving software support in four years.
If this happens it will take fifteen years, and I think Apple may well abandon the entire endeavour (or MacOS) before then.
Why's it surprising? I wouldn't even know where to get an ARM workstation to test my software on.
I'm just not really buying this as the justification, Mac has almost never been about competing on raw performance and moving to ARM could even mean a large performance hit for most software where performance counts for years to come.
Although I guess we also keep getting lectured on how amazingly powerful iPad Pros are yet we never really see them do anything beyond a paint program, GarageBand level music production, basic video editing and keynote.
A good example is when core 2 duo was delayed and Intel forced apple to use 32 bit chips in the MacBook Pro.
Though I don't think I'll be buying one soon. When I travel I have a 2018 MacBook Air and when I'm at home I have a 2013 Mac Pro. Both machines still work great for my needs, and I plan to keep the Mac Pro until Apple stops OS updates for it. When it comes time to replace it, I'll replace it with a Mac Mini, and I don't need a machine that powerful anymore.
Much of the time, this is advantageous (and I prefer someone else managing things for me when it works) but I run into far too many snags where its nice to know I can get something done with local resources that I have control over when needed.
One thing I still find peculiar is, Apple could have had nice ARM-based computers for quite a while. They are actually selling them in the form of the iPad, especially the Pro. But what keeps people to the Mac vs. the iPad is less the hardware, but mostly the software. The decisive difference in practical terms between macOS and iPadOS are the mostly artificial software limitations of iPadOS. While Apple loudly advertices the ability to copy files from an USB stick to "Files", the fun usually stops there. App support for file exchange is still very limited, you cannot even copy music to Files or your iCloud drive and add this to Apple Music or the TV app. So I find it a bit odd that they have to create ARM based MacBooks just as a solution to a basic problem of their software.
I don’t imagine much is going to change right now but I wonder what they might be planning for the next decade.
There won't be any phasing out of macOS -- it really wouldn't make any sense at all. They'd alienate all their devs.
There's been some speculation on Twitter that for WWDC instead of releasing an ARM Mac for development purposes (for the Intel transition then loaned people Intel motherboards mounted in PowerMac G5 cases), they'd release a version of macOS to run on your iPad Pro.
That was when having detailed manuals and being relatively open about your architecture was the norm. I'd bet whatever Apple releases will not be as forthcoming.
Perhaps this is just a game of semantics?
"Its own mac chips" vs "x86+ARM chips co-designed by AMD & Apple, fabricated by TSMC, and slapped with an Apple logo".
From AMD's semi-custom page:
"We are not bound by convention and don’t subscribe to “one-size-fits-all” thinking. We develop customized SOCs leveraging AMD technology including industry-leading x86 and ARM® multi-core CPUs, world-class AMD Radeon® graphics, and multimedia accelerators. We offer the option to further customize each solution to include third-party and/or open market IP or customer designed IP. Discover how you can differentiate with AMD Semi-Custom solutions."
https://www.amd.com/en/products/semi-custom-solutions
I still cannot see a hard switch to ARM without any HW x86 capability in the mix. The impact to user experience would be very dramatic and the PR would be a nightmare to deal with. The way I see this playing out is that the next gen of Apple hardware provides both an x86 and an ARM stack, with subsequent generations potentially being ARM only (i.e. w/ x86 emulation). There is just too much software investment in the x86 ecosystem at this point. You have to give people a path to migrate peacefully or they will never return. This isn't like prior architecture switches. The impact with PPC->x86 was not even 1/100th what the impact would be today if Apple forced a hard x86->ARM switch.
All of that said, I can understand why they would want to keep something like this under wraps until T-minus 0.
> There is just too much software investment in the x86 ecosystem at this point.
But I don't have any confidence in Apple's leadership anymore. There was a lot of software investment in 32 bit apps, too, and they merrily launched a nuke at that entire library.
Do I think they're going to drop X86? No. But is it a possibility? Absolutely.
Keeping compatibility forever has its own drawbacks - maintenance, performance, increased vulnerability surface, regression testing etc.
Legacy support has deteriorated more rapidly recently, it seems.
My gripe is more with how long they supported PowerPC on the Intel side.
Are we going to have Split in platform where developers is expected to debug on both Arch? This isn't the same as moving from PowerPC to x86, where majority of Pro Apps are already on WinTel. ARM is still relatively new on many Pro Apps. Adobe may be slightly better equipped, but not AutoDesk.
If not, would Apple spend additional hundreds of millions on 100W+ CPU design that are sold in tiny quantities?
It is also worth pointing out Mark Gurman has been saying this since before he joined Bloomberg when he was at 9to5Mac. And since 2016 when he joined Bloomberg the rumours were taken more seriously.
And the first rumours to suggest Apple is working on ARM Mac goes back as far as 2010.
It’s better to view Gurman as talent writing for Bloomberg than as Bloomberg itself.
https://www.vox.com/2016/6/1/11835514/bloomberg-mark-gurman-...
Apple has been dreaming about this day for years.
Even Intel's lacklustre results in recent years seem like an unlikely catalyst - Apple couldn't have foreseen 14nm++++++++++++ back in 2015. In 2008 though, Apple acquired PA Semi to design chips. This project has probably been percolating since shortly after that.
> Bloomberg, of course, is the publication that published “The Big Hack” in October 2018 — a sensational story alleging that data centers of Apple, Amazon, and dozens of other companies were compromised by China’s intelligence services. The story presented no confirmable evidence at all, was vehemently denied by all companies involved, has not been confirmed by a single other publication (despite much effort to do so), and has been largely discredited by one of Bloomberg’s own sources. By all appearances “The Big Hack” was complete bullshit. Yet Bloomberg has issued no correction or retraction, and seemingly hopes we’ll all just forget about it. I say we do not just forget about it. Bloomberg’s institutional credibility is severely damaged, and everything they publish should be treated with skepticism until they retract the story or provide evidence that it was true.
[0]: https://daringfireball.net/2020/05/bloomberg_publishes_click...
For Apple, this makes, what, the fourth architecture for Macs?
That's an interesting bet, given how long the two giants have been at this.
Whenever we hit a Moore's Law bottleneck, we see a transition to new CPUs being increasingly optimized for power-efficiency instead. Whether or not FLOPS remain a moving target, FLOPS-per-watt will very likely continue to grow for a few more decades.
> Also, Apple has many billions of dollars to throw at this.
Unless they're planning on selling these chips on the open market, I don't see how "throwing billions of dollars at this" project can be justified to their shareholders, even if it's something they can technically afford to do. As it is, it's a pure cost-center optimization (i.e. removing the need to pay Intel, at the expense of now needing to make the chips themselves.) This presumably balances out slightly positive on their books, not mind-bogglingly positive like a new product line would be. "So"—the prototypal shareholder asks—"why are you putting $bns/yr worth of silicon engineers to work on this, rather than putting them to work on feature cores to create+differentiate a new product line?"
In my mind, it only works out for Apple if it's actually not all that expensive for them to reach parity with Intel/AMD; i.e., if it's something they can do while still having silicon-engineering talent left over to keep doing feature engineering for new hardware. Which is what I find interesting: how did Apple reach this point, where they can leapfrog Intel/AMD without it even being a "drop everything" moonshot project for them?
Great OS (although worse than usual recently), doesn't run any (hyperbole but rooted in truth) software.
If they would just focus on running MORE software, especially games, they could probably grab so much more market share, but they are happy at 10% it seems.
However, the majority of people aren't developers and just want a computer that works. I could see this as a way to _increase_ market share and reduce the barrier to entry to expensive Apple products.
It also makes me wonder if they'll ship a lower wattage Intel part alongside their Arm chips in a transition period. I think that would be kinda cool, and would ease a lot of backwards compatibility woes. Or they could keep things more or less the same and just beef up the T2 with more cores and interconnect bandwidth.
It might not make much sense to ship a dual CPU Macbook Air, but it would certainly be cool to see Arm PCIe addon cards for the Mac Pro, where power and heat concerns are not as significant.
Shitty keyboards and useless touch bar aside, Apple has had a long history of pushing the envelope in radical and beneficial ways.
Everyone who writes software on macOS is probably virtualized already. Really shouldn't be any downside to this for the vast majority of programmers.
My conspiracy theory is that the sketchily rumored “gaming laptop”[1] is actually a hot rod ARM MacBook focused on developers to get the transition off with a bang.
[1] https://www.macrumors.com/2019/12/30/sketchy-rumor-gaming-ma...
They want to sell this transition as letting them build the best Macs ever. A kitbash iPad, despite its virtues, is definitely not that.
Pythonista, Continuous, Codea, Shaderific, Playgrounds
Are enough to keep me busy.
I usually only use tablets when flying, not the ideal place to access Internet (very few Airlines offer that on European flights).
As long as I'm <10ms from the VPS I can't tell any difference between code-server and native VSCode. I really hope their business model is successful.
For the developer model, perhaps they'll revive the Macbook 2015 form factor with an ARM chip instead, to distinguish it from the Intel-based Airs and Pros.
I also expect that you won’t need this box to do ARM development: Why should ARM macOS development on an existing x64 Mac be any different from ARM iPadOS development there?
$999 can buy the MacPro monitor stand...
I suspect it was from some combination of branch prediction and OOO execution being weaker.
However, it doesn't mention CPU performance or IPC, both of which will be extra important due to the binary level compatibility for x86 I would expect them to ship.
After all, modern Intel processors decode x86 to a simpler instruction set used internally anyway.
if apple's making the decision to transition again, they must feel that it's for a very compelling reason once again. we don't have our hands on their current tech to agree whether it makes sense as a cpu upgrade, but likely it would make sense as a battery upgrade. whether that's a good enough reason to risk a transition, we will have to wait and see.
personally, I've been burned too many times on first-gen apple hardware to jump on the bandwagon immediately, so am taking a wait and see approach.
previous transitions that have been successful:
m68k -> ppc
ppc -> x86
x86 -> x64
How is Apple's approach going to be different from Microsoft's? Will they keep backward compatibility? Will the CPU architecture really be a day and night difference or are our expectations too high due to the ubiquity of inflated Geekbench numbers?
This will either make or break the Mac as a platform and I feel like currently, any further investment would be a gamble.
Does somebody have an idea how much approximately would it cost Apple to switch the Apple A14 from ARM to POWER? Usually it is said that the instruction decoder is a small part of a CPU core, and the ISAs are not hugely different (compared to AMD64/Intel, at least).
> Apple’s chip-development group, led by Johny Srouji, decided to make the switch after Intel’s annual chip performance gains slowed. Apple engineers worried that sticking to Intel’s road map would delay or derail some future Macs, according to people familiar with the effort.
Take the cooling/throttling problems as an example.
Goodluck to them on building a better chip.
The overloading of the Control key as the system menu shortcut ("accelerator"?) key when it's also the default Emacs bindngs for readline in Bash -- drives me utterly insane.
If it were consistent, great, but on Windows there are many different text widgets, from PC console, Win32, and other layers. I simply can't develop the muscle memory.
I have a very cheap HP laptop, the trackpad driver is nearly unusable. I installed the Synaptics Control Panel, and use it to "reset" the trackpad each time it wakes from sleep so that I have a chance at scrolling without randomly selecting the entire document's text and deleting it or dragging it to random places. It's horrible.
On the Lenovo x230, the tiny trackpad is a bit better, but tiny, and the physical trackpad buttons give me the chance at dragging etc in the face of such madness. It's all very nerve-wracking.
The trackpad on the MacBooks have never been a problem for me.
Then there's text encoding. The Win-1252 Code Page. Turning UTF-8 into unreadable line noise in unpredictable situations. The CRLF madness that grows back no matter what.
I use WSL2, Terminal, and VS Code, but it's unbelievably exhausting. Digging out of config issues with Code Signing certificate policy required a re-pave and 12 hours of re-installing etc to get back to sanity. Something needed an old VC Runtime DLL, which installed fine, but also seemed to overwrite a Microsoft root CA cert. Differential analysis with a working Windows we couldn't find the broken cert. Various msc tools and System Policy analysis and Troubleshooters and so on couldn't find it. The CERT: filesystem "provider" stopped working. It was a dead machine.
Linux and macOS configs, I generally know where config files are, and can restore from backup.
Want to restore from a Windows Image Backup? Or a copy of the file system from another Windows installation? Go ahead. Try it.
I got heavy into PowerShell, there are some nice bits there, but it still has to fall back to text processing in pipes if some other tool doesn't output the correct data. Usually JSON, but is that schema documented? Certainly have yet to invest the time in Bash tools that might interact with PowerShell.
It just doesn't stop. It just doesn't. I must accept that people are actually getting work done by adding WSL to the mix, but I guess I just break things.
I don't seem to break things as badly on Solaris or Arch or even Gentoo or any of the BSDs.
I have not given up on macOS. On the contrary, I will get another Mac laptop.
It's a lot of work.
Their credibility on issues of tech—particularly Apple—is very suspect. (See also: Gell-Mann Amnesia Effect)
At worst the keyboard "issue" is just a preference.
Yeah, I prefer to have my B key registering 100% of the time instead of 80% of the time.
I've had 3 Macs with these keyboards (should have been two, but one died completely and had to be replaced), all of them had this issue to varying degrees. This was not uncommon for the other Mac users at my workplace.
Even if fiasco is an overstatement, the initial denial of the issue I think is the major source of it becoming a media issue.
We'll probably still have 4-5 years before the Intel Macs are completely abandoned but then this is Apple we are talking about. For all intents and purposes, they might cut the umbilical cord in 6 months.
Adobe is probably the only company which can delay the complete transition for some time.
Edit - removed the line about electron. As others have pointed out, electron already runs on ARM.
No, they're selling the Mac Pro today. Intel support is not going away anytime soon.
Electron already runs on ARM-powered Windows laptops [1].