But that's because it was such a niche until just recently - basically only playing with docker/k8 on Raspberry PI and the likes. With AWS Graviton instances and these new Macs it will quickly change.
Graviton2 is looking really compelling in our tests. At this point we plan to migrate all of our instances over the next year and we’re going to want arm machines locally to develop with. It’s starting to come together.
I think Docker for Mac should just use x86 emulation for the time being -- apparently the new Apple chips don't support virtualization?
x86 emulation gives access to most available Docker images anyways -- and the performance of the new CPUs would seems to indicate that emulation may not be so terrible, at least for the short term.
The M1 does support virtualization. Parallels is already working. I don't know how long it will take to get HyperKit working on Apple Silicon.
QEMU would allow running x86 images on Apple Silicon but I don't know if the performance would be acceptable. You can't use Rosetta 2 with Linux no matter how much you might like to.
EDIT: I don't know about the hardware but their license change, as mentioned by saurian below, didn't add support for this as I had thought and had written in my original comment.
I thought MacStadium just released a blog post--which was on Hacker News--going into detail on the exact opposite: that now Apple has made it very clear that not only can you not provide shared hosting (as you must lease the device to the user in its entirety) but you can't even lease it in less than 24 hour increments (which to me is a kind of ridiculous overreach on what it means to own something; imagine if Toyota sold a car and said "the infotainment unit runs a bunch of software and the license on it prevents ride sharing or per-hour rentals").
Apple would need to implement all the supervisor mode parts of x86, which massively increases complexity. It's a notably different product.
And it would even be virtualiztion, it's not exposing the real host hardware. No real x86 cpu exists to be exposed. It would just be an emulator pretending to be virtualiztion.
The first AS Macs are targeted at people who don't need things like docker. Eventually all the support needed will be available. It's a two year transition, you have to start somewhere.
Still worth sharing so that people are aware. I was in the market for these machines and holding on until their release, but I started going through my tools to see what was supported or not, and no docker is a no-go for me.
If the benchmarks from the other front-page post are true, then not releasing a MBP version would have left them in a position where the AS MBA outperforms their entire MBP line.
Yep, but due to the new high speed on-package RAM architecture they couldn’t support more than 16GB RAM, so couldn’t retire even the 13” Intel MPBs because some people need the RAM. It all makes sense.
I was also surprised, but consider that "Pro" to Apple means photographers, video editors, musicians, etc. just as much as (or perhaps more than) developers.
We don't know yet whether M1 will be able to support a hypervisor, so it's just too soon to say. I know it's not the HN culture, but I encourage everyone to take a deep breath and be patient for the actual hardware to arrive.
I did. But it doesn't matter: not a single consumer outside Apple (and maybe some reviewers under embargo) has a production M1 in their hands today. Nor is there a public datasheet for the processor yet that I could find.
The Apple documentation for Hypervisor.framework now explicitly includes references to Apple Silicon, and even ignoring that, they showed Debian running in Parallels back at WWDC during the announcement. They literally had a giant interstitial during the talk that was titled "Virtualization," complete with a cute little logo/icon and a demo, in classic Apple style.
It absolutely will - this post is referencing a July post which means it's the DTK.
Apple explicitly said that the DTK does not support hypervisors, and that final consumer hardware would. People posting garbage reports like this to HN annoys the hell out of me.
Not very clearly targeted. MacBook Air was probably the most popular laptop on my CS degree, and I bought a low-ish end 13” MBP toward the end of it and still use docker on it constantly. And that’s probably even more common now that they’ve pushed the price of the higher end MacBook Pro range so high. And they’ve replaced Intel Macs with M1 in the store, it’s not additive, I can’t buy an Intel MacBook Pro for less than £1799 from Apple any more.
"Not yet. The OS has the virtualisation functions, but the Apple chips don't have virtualisation support yet."
This is strangely a really big selling point for me as a habit breaker. I spent a good part of the release evening whining about the pitiful memory and the cost of the devices but I am regretting that on reflection. Why? Well I just spent two days arguing with problems with Microsoft's fucked up shit show of mixed platform Windows containers and Docker which ultimately ended up in a completely hosed OS install. Every time I use some heavily marketed stack it turns into this mess eventually if not right away.
My conclusion is doing this on my main computer i.e. my portal to the universe is a functional risk so I'd rather do it somewhere completely different i.e. on a desktop PC hidden away somewhere or Amazon where I can nuke the whole universe and start again without losing access to essential services etc.
So perhaps I don't need a virtualization equipped CPU after all for my computer? Forcing my hand in that direction may be a net gain.
FWIW, that comment was referencing the A12Z in the DTK, not the M1 CPU. It's less clear where the M1 sits on this issue and whether Docker can be ported.
This link is a little confusing because the top comment and much of the conversation is talking about the DTK which was based on the much older A12X CPU and not the M1.
As far as I can tell, the M1 does have virtualization support, Docker just isn't ported yet.
Update: Also, from Apple docs it seems like you won't be able to run emulation and virtualization in the same process. So you can run x86 Mac apps, but it's likely x86 Docker images will be out-of-reach.
I think we made couple of expedient design decisions early on in our build process at work that is going to make producing multi-platform docker images a bit of a chore. I'm not looking forward to what happens on the next machine upgrade cycle. Probably we will end up with most people on the final generation of Intel Macbooks so we have a while to figure it out.
> Probably we will end up with most people on the final generation of Intel Macbooks so we have a while to figure it out.
If the early story around performance of the M1 bears out, I suspect this won't be the case. If their CPU for the base MacBook Air trouncing higher end MacBook Pros, what kind of a beast will their higher end CPUs going to be?
People who really need x86 compatibility will stick with x86 based Macs. Others? I'm not sure. For my current job where everything runs on node.js, the performance and battery life on the new CPU is pretty appealing.
You realize most engineers write software that runs in production on x86 Linux, right?
All that performance is going to be used to run cloud based Linux x86 development environments. Repl.it and Github codespaces are the real winners with the move to Apple Silicon
I'm not entirely sure that's true. Or at least not entirely relevant/ interesting.
First, you have thousands of developers writing code for iOS/ Android & Chromebooks. That right there is a pretty big chunk of developers. And at least for the iOS developers, running on ARM instead of x86 is a significant advantage.
Second, a lot of us are writing software for the web which means primarily writing software that runs in the browser. So long as we have a good running version of node.js and a browser to test with, we are golden. Assuming for a moment here that Google Chrome and Firefox are both going to be ported to ARM, I don't really see why I care about x86 linux except...
Of course you need to serve up your site and that piece is usually running on x86. Only... many of us are already crossing platforms. Our web server is Node on Linux and my dev system is MacOS (no Docker or Linux VM) so I'm already cross platform.
When I was primarily running a Python/ Django shop, it was a similar deal—so long as I was able to get Python running I was good. There are definitely a few places where you notice the difference, but there are definitely places where I can use an extra 50% battery life and a faster CPU as well.
I don't know how many other developers really need x86 and how many don't. I have had jobs where running Docker/ Kubernetes was important, but I've had a fair number where it wasn't as well.
The limit on “emulation and virtualization” just means Apple’s emulator software (Rosetta) doesn’t support x86 virtualization. Someone could write a different emulator that does support it.
> run emulation and virtualization in the same process
To me this says that Rosetta doesn’t convert VT-X commands (et al) to their ARM counterparts.
I don’t see an issue here... sure you’d be left without a dedicated VM framework from Apple, but you should be able to run a qemu process that is emulating a Linux VM. That qemu binary could be either x86 or Arm. But instead of using the Mac OS Hypervisor.Framework, you’d be back to using stock qemu that we used to use. It just isn’t packaged up as nicely at the moment. (And who knows how fast it will run).
I'm not exactly sure what the point of VT-X would be in an emulated environment anyway, and it would be a waste to make Rosetta 2 that much more complicated for it.
Kubernetes itself has been installable / running on ARM for years now (I remember getting it working on Pis back in 2016/2017 and have been running http://www.pidramble.com on K8s since then).
Many, many images are now multi-arch so I encounter failures to deploy things to the Pi much less frequently nowadays.
A12Z/DTK: HW does not support virtualization at all.
Apple M1 / New Apple Products: HW does support virtualization for ARM64 guests (both windows and linux demonstrated).
What about x86 software in the guestOS? Not with Rosetta. Instead, the guest OS will have to provide its own translation (such as windows/arm's current x86->arm64 or upcoming x86_64->arm64 feature). I'm not familiar if there is any usable high performance x86_64->arm translation available for linux.
Docker w/ arm images: needs some work to be able to work on mac/arm virtualization, but it's coming.
Docker w/ arm linux kernel + x86 userland images: Any translation solution would be found within the linux guestOS, not macOS. I don't know if any candidates exist. Maybe qemu?
Docker w/ full x86 image (incl. kernel): I don't think this is possible?
This was a huge reason why I decided to go with a 16" MBP with an i9 vs the M1 today. I assume this will get worked out eventually, but as massive as Apple's gravity is in their ecosystem to pull apps along, they will have a much harder time against the massive library of x86 docker images.
Apropos of yesterday's thread(s?) around running a k3s cluster on Raspberry Pis - when I tried to do something similar, I very quickly ran out of steam trying to find manifests and charts that didn't have some random x86_64 image hardcoded somewhere inside them.
I spent more time trying to figure out ways to get the right images than I did learning k8s, so I kinda put the project down.
I do think this is exactly the sort of thing though that will start to flush that out, long term.
You did the right thing. This is not the right time for software developers to experiment with Apple Silicon, unless they’re willing to help develop software to work with Apple Silicon.
Largely depends on what kind of software developer you are. Not all developers rely on x86.
Our app is React/ Typescript and we don't use Docker/ x86 virtualization at all. I do need MySQL and a few other tools, but I don't expect they will be long coming (or maybe already running in Homebrew is there Homebrew ARM?)
If you make your living writing Mac or iOS software, this is a gift. Might be worth waiting for the next generation with more RAM and even beefier CPUs, but otherwise this is ideal.
One of the formula not working in Homebrew’s core functionality is the gcc compiler, which they expect might be ready by mid-2021. Another is Go, which iirc they’re expecting will begin working around January. Rust and Erlang aren’t ready, MySQL doesn’t even get past the build phase, and Python is only partially working.
You can track progress here. Be advised that packages listed as ‘check again when XYZ is fixed’ may themselves have issues that can’t yet be discovered.
For some reason I'd completely forgotten this was an option. Looking at the discussions on the home-brew boards, it looks like this will be the way to run home-brew for some time.
I would definitely not take for granted that you’ll be able to develop such things on the M1 platform without encountering M1 platform obstacles in unexpected corners of the tool chains for the next thirty days. It might be fine, but if it’s not, you’re out of luck until it is.
Having to deal with this sort of stuff is just a waste of time.
Mac's don't have a monopoly on quality, haven't for a long time.
And since it's a usual response, anyone claiming Linux is too fiddly haven't used it in a long time. And while it can be if you want to roll your own DE its completely optional. Using something like fedora you can literally do almost everything non developer based with point and click.
I moved to Linux last month. I currently run Windows, Linux and MacOS VM on my machine.
From being a Windows guy through all the years, I've found myself increasingly using Linux in this span of time. The only thing preventing me from a complete switch is MS Office. I barely used MacOS, except to diagnose issues on MacOS and run XCode.
May I ask what linux you are using and how you got a Mac VM running? I tried myself and was able to get Catalina running on Ubuntu 20.04 using Openboot. But then Catalina updated itself and crashed after that. I wasn't able to reinstall MacOS successfully anymore, even starting from scratch.
If you could help me out by pointing out which products/technologies you used and maybe a website describing step by step, that would be great.
Ubuntu system. Firstly, I disabled updates, not because of Mac in particular, but I've had issues with Windows updates crashing before, so I don't eagerly update.
I moved to Linux in early 2019 and was surprised that I barely needed Windows anymore. I was already using Libre Office so Ms Office wasn't a sticking point for me. I assume you tried Libre office and its probably not compatible enough for you.
Ms Office is very compatible with Wine - even the newer ones. The only problems seem to be with apps were direct replacements like Skype or are irrelevant like OneDrive.
For setting up wine and managing my apps I use Lutris. It is meant for games but is brilliant for setting up windows apps as well. I wish they would acknowledge that fact in their UI but it doesn't bother me too much that everything is called a game.
I didn't enjoy Libre Office, largely due to the functionality being too low. I work with Excel spreadsheets with lots of macros and formulae, which doesn't port well over to Libre Office.
I can understand this, I make do with Google sheets but it's seriously limited with my bigger spreadsheets, especially if there is lots of custom code / API response parsing involved.
I use Excel pretty intensively, learnt all the shortcuts from my past finance days. I don't think the web version allows for those back-of-the-hand shortcuts.
in my case, they ship a almost up to date kernel, they don't use snaps, vanilla gnome, the distro is very stable. The linux community I follow also likes where the distro is going and the overall "Fedora philosophy".
I guess the flip side is that, hopefully, the Docker ecosystem will start getting a lot better at multi-arch, at least for x86-64 and ARM. I just ordered an M1 MBP and I'll be quite happy to start thwacking bugs in images and upstreaming the fixes.
Not a bit deal. Building ARM images from Dockerfiles is trivial. And it has the benefit of not having to trust an upstream image content.
If you want to go the extra mile, contribute to the project to provide multi arch images support.
What multi-arch goodness of Linux? Linux can't magically run code from any architecture even without Docker in the mix, and unless someone is maintaining packages for your specific architecture, you're building them yourself.
Just a heads up; I haven't tried using my DTK in a while but... development was still VERY rough last time I checked. I was pretty much forced to write code on an x86 machine and schlep it over via ssh to then run it.
Also, be real careful you don't accidentally build for x86 when installing libraries or it all goes to shit. I got bitten by this by using iTerm (building it from source was fine though) and not realizing it was the x86 variant. That is to say, make sure your terminal is the system terminal or built for ARM-- otherwise when you install things using package managers they'll be the x86 variant.
Like, I'm super stoked for the M1, but also just totally fucking irritated about the toolchain changes and MacOS in general... They've not been the best stewards of their software and developer communities as of late, and they're pushing a totally proprietary architecture onto them expecting them to foot the bill (hours spent fixing/debugging) to make their platform usable.
Truly, I get paid to write software that runs on Linux not on Macs. In fact, I've never gotten paid to write software for Macs, because no production systems use Macs. Now it is harder for me to do primary development on a Mac; because I must fix MacOS or live with MacOS only bugs... bugs which only exist on a platform I do not intend to deploy my code to... these aren't just some config bugs either they're going to be a fucking mess of irritating, show-stopping, moving targets with a negative ROI.
I still can't believe they didn't incorporate containers into the OS before switching platforms to keep developers around but that's a totally different rant.
Apple has only ever used portable to refer to their own platforms. Which is a bit of a stretch of the term considering what it means to the rest of the technical world, but there you have it. Per their own definition they have improved portability among their own platforms.
Same reason why I chose the 2020 13” with the highest end Intel I could put in it. In another 3-4 years all this will be worked out and I’ll be happy to move to Apple Silicon
> Docker w/ arm linux kernel + x86 userland images: I don't what existing projects might me candidates, but any translation solution would be found within the linux guestOS, not macOS.
That could be something doing dynarec like box86, which is mindboggingly the only way to run (x86) Zoom on a arm7hf Linux atop a Raspberry Pi 4 (I tried it on a Pi3B: it works but it’s way too slow)
> Docker w/ arm linux kernel + x86 userland images
as mentioned in the issue comments: Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac, so x86 images via qemu on ARM host should not be a problem...
> Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac
it "works", but on my overpowered i7, running a raspberry pi docker image that way with qemu-user-static is... only marginally faster than running the code on an actual rpi 3, which is pretty much potato-levels of power.
Yep, so if you're a developer and buy a Macbook with the M1, all the potential performance gains would be lost when depending on common Docker images. That's quite sad.
(It would at least be a huge problem for me. I mostly develop server software that runs on Kubernetes on AMD64 machines.)
Why not just run the ARM images instead of the x64? Granted not everyone makes ARM images, but in a year or so I fully expect that all serious Docker images will have ARM support (not because of Mac, but rather because of ARM’s progress in the server space). And in the meanwhile, building the image yourself isn’t that hard.
Why would your employer pay you to build and test ARM images when the server they're running on is AMD64? Okay, let's be realistic: they'll probably never find out. But still this is wasted effort when you could just as well use a regular x86 machine for development. Cross compilation will lead to many small problems that add up over time...
More likely than not, those servers are at AWS. And if that's the case, once all the components have ARM images the server instances can be switched over to the M6g instance type for significant cost savings.
Even if not AWS, every cloud provider will have cheaper ARM offerings in a few years. The writing is on the wall at this point. Not to mention that some significant portion of the PC market will certainly follow suit, and now whether you’re developing for desktop, mobile, or server, there’s a good chance you’ll be targeting ARM.
X86 software running in a VM hosted ARM Windows/Linux env, but using Apples translation layer is not something I would expect to work anyway - seems like a weird thing for them to try to do to me.
This will become less of a problem over time as more M1’s make it into the wild.
What gives me pause moreso than this is the absence of the touchscreen and Face ID, which are very obviously coming in the next refresh (iPad app support without touch?).
As impressive as the new MacBooks are, they’re very clearly a stopgap solution so as not to replace everything all at once.
> As impressive as the new MacBooks are, they’re very clearly a stopgap solution so as not to replace everything all at once.
I agree, but at the same time, they pushed it pretty hard by not just doing an Air with the chip like I thought they would, but putting it in a Pro as well (with, according to the early benchmarks I've seen, barely any performance difference. I mean they could at least have put two of them in there)
- Brighter Screen
- Better cooling for extended CPU loads
- Touch Bar (which many don't care for)
- Bigger battery.
The MacBook Air boosted to 16B is likely the biggest bang for the buck unless you are going to be hitting that CPU hard all the time. The iPad has pretty damned good performance without fans so I expect the Air will do quite fine.
In this case the whole Docker universe needs to be ported, including gazillion packages? I am glad if most of the datascience packages compile successfully on x86. Much fun it seems.
Slightly mis-leading headline. The DTK w/ A12Z chip didn't support virtualization, but it appears the new M1 will. Since docker devs haven't gotten their hands on M1 hardware yet, it remains to be seen how much work is needed to make it functional. It may just work out of the box?
I'm actually tempted to get one of the new Macbook Airs. There's something intriguing and fun about navigating the brokenness of a new ecosystem. Does anybody know how Steam handles the new macs?
That’s why I got the Pro (also my laptop is from 2013 and I’m desperate). I love and use Docker every day, and know it’s a mess right now, but I’m still excited to jump in head first.
Edit: This is my personal laptop fwiw. My work one is still Intel.
What is the difference between the M1 Air and the M1 Pro 13"? From what I can tell, they are basically the same spec except for small differences like slightly bigger battery life, active cooling and touchbar in the Pro.
Form factor is similar. Brightness is better as stated. I believe you get better speakers in the Pro, the charger is higher wattage and the GPU in the high end air and Pro is 8 cores while the GPU on the base Air is 7 cores.
This is exactly the reason I picked up an iPad Pro earlier this year. I have ADHD that flares up pretty bad when I’m wading through the boring parts of a project and flipping through open windows, the Dock flashing at me, update notifications popping in randomly, and all the complexity that comes with a desktop OS just wore me down. Add in all the fun stuff 2020 has to offer and I just couldn’t take it anymore.
Not that the transition has been seamless, but I’ve only had to fall back to my Macbook once in the past three months. There’s something about shaking up the routine, plus the forced simplicity and single-tasking has majorly helped my focus. I just wish Cloud9 or Codespaces worked better on an iPad...
This sounds like you would actually _like_ the incompleteness of most linux window managers. On i3 you don't get update notifications, because by default notifications don't work!
I’ve been down that road and combining ADHD with an infinite amount of buttons to press and dials to turn is a recipe for disaster. I just can’t help but push all the buttons and turn all the dials until something breaks, and then I have to spend all day trying to fix it.
>>> Does anybody know how Steam handles the new macs?
Games are mostly C++, based on my experience with C++ codebases I'd say there's about zero chance that a game could be (easily) recompiled and made to work on ARM.
And games won't be ported anyway because it's too much work for too little sales, even if a developer really wanted to make it work they'd need a $2000 new mac to be able to compile/test in the first place.
One of them is used for charging, so you really only have one useable port. Still, TB3 dock should be able to provide enough ports for most people (at the expense of portability).
Not really. You could try to get a $25 hub from Amazon and hope it works, half the reviews seems to disagree on that.
However it still won't give you any HDMI or audio or Ethernet output. If you try to get one more adapter, say HDMI to connect a projector, you won't be able to plug it because there was only one thunderbolt port in the first place.
Prices in France are TTC (Toutes Taxes Comprises, all taxes included), the VAT in France is 20% so if you take 20% off 1400€ you end up with 1159€ which is $1370. So in the end the MBP is a bit cheaper in France than in the US.
Maybe you're talking about indie developers. I don't think studios worry about spending $2000/machine for porting. And a lot of studios also outsource porting
As someone who cross compiles C++ to arm (and others) as part of my $dayjob, I sincerely don't understand this comment. I would like to, as maybe there's something I misunderstand.
Ninja edit: I guess you're suggesting that some parts are in hand rolled x86 assembly, not just pure C++ that would be output as the cross compiler target architecture?
There's usually a million assumptions that are technically undefined behaviour but work, and immediately break if you try to cross-compile by just changing the target system in CMake or w/e.
I could see that if it were being compiled against another libc as well. It's true my experience is with a codebase that has forever been cross compiled. Just altering the output architecture I guess I just haven't seen be an issue. Aarch64 hasn't ever given me an "immediately break" scenario. If it compiles, it works. Ymmv though. Computers are complex.
Are the old x86 Macbook Airs already discontinued or are they still available via some less obvious page on Apple's site? I picked one up last month since I liked the form factor and needed x86. Seems like I may have got it just in time?
If you can burn the cash then go for it, but unless these laptops can support something other than MacOS I'm (with a sad expression) staying away from them.
Obviously if you just make websites it doesn't matter but if I'm buying an ARM device I want to play with the bare metal (you can't even access performance counters in MacOS IIRC)
May I ask what do you enjoy with a Macbook not running MacOS?
I don't like Apple devices myself but I understand that some people like the ecosystem as a whole.
However I don't understand the point of a Mac without MacOS. The hardware is pretty much garbage compared to any laptop of the same price range, let alone high-end laptops like Thinkpads.
(this is a honest question and I am not trying to troll or make fun of anyone, in case anyone doubt of the tone of my post)
Install Linux on them when MacOS is no longer supported on your machine, perhaps? If your laptop still works, you should still be able to use it even if it is no longer supported.
Also, many people like to work with dual boot devices. And no, virtualization is not the same.
The hardware is also not garbage. It may not be competitive, but it is well made.
Apple hardware is pretty nice. Spec out a top-of-the-line Thinkpad X1 Carbon Gen8 against a top-of-the-line MBP13, and you definitely pay more for the MBP13, but it gives you more and superior RAM, more and superior SSD...the configurable ceiling and hardware quality are higher. The X1C-8 gives you more screen resolution, 4G LTE (not that you would need it if you have mobile hotspot with 5G), more ports, WiFi 6....but the central nervous system of the MBP is arguably better.
To answer your question, I don't see much reason to buy a MBP and run it without MacOS, because -- although the build quality is sensational and the MBP travels well -- I'd rather just buy a Lenovo with Windows 10 Pro from the factory, get their top-tier service and repair plan, and still come out cheaper than a new MBP. However, I could see myself converting an old MBP for use as a Windows machine.
You are comparing the specs sheets while I am looking at practical situations.
For the same use cases Linux feels (and is) way more performant and responsive even on a less powerful hardware, and I'm not even talking about Docker.
The MBP keyboard is probably the worse on the market and any lower-end laptop keyboard is more comfortable to use. And nowadays it is not even a complete keyboard since it lack many standard physical keys.
The number of ports is extremely limited and you cannot connect anything without an adapter.
The computer gets hot very easily, and when it does, the keyboard gets extremely hot as well. It is also very noisy compared to any other laptop.
The glossy screen may look cool in a shop but it is very unpractical and uncomfortable.
I do not have any of those problems with my X1, I even have the best keyboard I could hope for a laptop, along with actual features like the Trackpoint, physical camera shutter or the PrivacyGuard.
1. I'm not that much of a linux-guy but almost everything I derive pleasure from in programming is fairly close to the metal, e.g. microarchitectural benchmarking and tracing are probably the two things I've been doing the most recently and you can't even get close to them on MacOS. If I spend that much on a new ARM machine that's what I want to be doing
1.5) I like the GPL, apple doesn't
2. I like apple's hardware in a vacuum. As much as the company leaves a bad taste in my mouth (there is a deeply pretentious streak to Apple's approach to their users), they make nice cases and such.
I don't know about Steam specifically, but in the Apple keynote they said that existing games can run under Rosetta 2 and that some of them even have higher frame rates due to M1 speed despite emulation
Wow, that's doing every filesystem operation as a separate fetch to the server? With no caching? Simple to implement, but about as slow as you could possibly get!
Docker for Mac is a Linux VM with some tools to glue your Mac to that VM. It gives you the illusion that your Mac is running containers, but it's not -- Linux containers are a Linux thing. Some virtualization is going to be necessary unless your host OS is Linux. One could argue that maybe MacOS should somehow run the Linux kernel. Windows tried that as WSLv1 and it didn't work that well; WSLv2 just uses a VM.
The net impact of this is not particularly high. I always write my apps so that they can run on the local machine, and just have my CI system put them in Docker images for deployment. But, that does require some effort, and some language ecosystems or applications make this nearly impossible (relying on details like case-insensitive filenames, OS quirks, etc.)... so people just develop inside a container to work around that. (I would never tolerate it, but it can work OK for things like PHP where your edits take effect in the running container without having to rebuild anything.)
Is it going to be interesting to see how new Apple machines running ARM based processors plays out.
Writing code, and building docker images locally on ARM and building and running the same code on X86 in production could potentially, in some circumstances cause some issues. If not, it's a bit of a pain to potentially build and publish x86 and ARM images so that people can run them anywhere (Some projects are already doing this). Running production on ARM could work if you wanted to, but right now the instance types are very restricted in terms of different combinations of cpu/disk/io.
> building docker images locally on ARM and running it on X86 in production could potentially, in some circumstances cause some issues.
Won't it always cause issues? If you build locally you are packaging ARM binaries in zfs which won't run on x86... unless you somehow signal to docker that you want a different arch when building
If you are developing on Apple silicon, the path of least resistance is to deploy to AWS Graviton2 instances, even if the instance cpu/memory/io combination isn't perfect fit for your usecase.
I agree. However for a lot of people, their workloads have been running on x86 forever, maybe their production instances are not reproducible, and with combinations of cpu/memory/io being limited, at scale this could cost $$$. I’m just curious to see how this will pan out.
I will not be buying one of these first generation M1 devices because of issues like this. But in the long term I actually think it’s going to be a really good thing for the industry if we can get more developers using non-x86 devices and deploying code to non-x86 servers.
Having people working on fast ARM machines will be good, although I do worry that apple will be apple and you'll never be able to run (say) Linux on said ARM chips.
I used to be fairly laissez-faire about it but now I really think it should be legally required for at least some level of freedom for the end users to be supported (technologically rather than as in customer service) by big tech companies selling hardware
Presumably they are locked down. When asked about alternate OS, Craig Federighi said that it will be virtualization rather than booting other OS on the metal, ie Linux (and possibly Windows) VMs rather than Bootcamp. That's one of the big things stopping me from switching from the Intel version.
I would think the bigger problems are drivers & secure boot rather than just instructions. M1 is a regular ARM processor so existing backends at a minimum would work fine even if they're not fully optimized (+ I would be a bit surprised if the M1 support for LLVM isn't upstreamed).
Is that really true that M1 is just an ARM processor? I've heard the difficulty in emulating it is due to Apple specific things, whether they be drivers or new instructions.
If you have code that makes use of custom instructions, even if only sprinkled in a few places, the emulator must support them.
If you have a cpu with those extra instructions that is otherwise backwards compatible, you can run code that doesn't make use of such instructions just fine (of course, you won't benefit from the functionality/performance offered by those new instructions)
I understood this thread to be about running Linux bare metal natively on the M1, so there's no emulation there & new instructions don't matter. Drivers & secure boot are always the biggest problem. It sounds like you can sign your own kernel & add it so in theory secure boot may not be a problem. Then the question is which driver support are missing & need implementation & how close that lines up with existing ARM device trees.
> This work, especially as there's no exploiting security bugs required here, will benefit Linux on those Macs quite a lot.
Right, it sounds like Apple was very careful to provide an out here for enthusiasts by making it possible to sign your own kernel, something you can't do for iPhone/iPad/Watch. Seems like an astute appreciation of differences in their target market.
It's more knobs over csrutil. Chose the bputil manpage as it contains more info on the underlying hardware and security model, and allows you to selectively disable only some of the security bits.
You can't install an operating system that's not signed by Apple. Also, the system partition is read-only (just like Catalina was).
However, as they showed at WWDC [1], you can run Linux and other operating system using Apple's hypervisor. And it will run faster on an M1 Mac than it does natively on comparable Intel hardware.
Yup it almost feels a little short sighted now the way we have embraced taking applications written in architecture independent languages like java, python, etc., and packaging them up in architecture-dependent artifacts.
> But in the long term I actually think it’s going to be a really good thing for the industry if we can get more developers using non-x86 devices and deploying code to non-x86 servers.
Why?
If it's about the dominance of x86, I think in about 15-20 years there will be no other architectures in widespread use except for ARM and maybe RISC-V.
It took ARM 35 years to be an overnight success and x86 has a very large install base. It's not going anywhere. Remember this thread from not too long ago?
What I think is much more interesting is what the software industry will do with all these random coprocessors we find in chips these days. They seem much less stable than an instruction set but amazing speed gains can be had there, so it's enticing. If software libraries can bring the dream of the HAL to reality, that would be pretty cool.
But from threads like these, it's safe to conclude we're not there just yet.
But x86 and Intel are losing badly in the highest growth part of the market: mobile/smart phones.
Now $699 M1-based Mac mini is way faster than any Intel box in that price range and many that cost much more.
The benchmarks that are starting to come out are just nuts, favoring the M1.
Of course not all of the pieces are in place; that takes a while. But those developers that are on top of their game released universal versions of their apps that take full advantage of the M1 SoC and all of its benefits: unified memory, 8 CPU and GPU cores, Neural Engine, etc.
It's day 1 of Big Sur being available and customers haven't gotten their M1 Macs yet, though they'll have them in a few days.
In a couple of months, once the dust has settled and developers have gotten their hands on shipping hardware, people's understanding of what performance is possible on consumer-level hardware will be changed for good.
Mobile phones have had a decade of phenomenal growth and development.
Now people are at home again, and not quite so mobile. Commensurately, we are seeing a breath of life into a laptop/desktop market segment that, with few exceptions, has been marching to a steady drumbeat for at least the past six years.
> But x86 and Intel are losing badly in the highest growth part of the market: mobile/smart phones.
x86 and Intel are making all their money running your k8s on AWS, GCP and other server platforms so you can consume on your locked down ARM device. That's where the big money and margins are.
Apple never really could get a foothold in that market.
x86 and Intel are making all their money running your k8s on AWS, GCP and other server platforms…
ARM is coming for the datacenter too; this will not end well for Intel [1]:
Amazon Web Services launched its Graviton2 processors,
which promise up to 40% better performance from
comparable x86-based instances for 20% less.
Graviton2, based on the Arm architecture, may have a
big impact on cloud workloads, AWS' cost structure,
and Arm in the data center.
I mean, I wouldn't buy first-gen of anything from anybody. When Apple went Intel, I bought year2 or 3 hardware.
What they're showing now is pretty damn impressive. I look forward to the M2 or whatever variants that would be a more direct replacement for the 2019 rMBP I have now (6 cores, 32GB RAM).
But I'm happy to wait. If you don't have virtualization needs, and your use case is pretty straightforward, these are gonna be amazing machines. They're just not the power user machines -- I mean, except for those who insist on bleeding-edge living.
I'm sure plenty of people are saying this but I'm really glad I switched back to Ubuntu about a year ago. The state of non-apple-centric developer tools and environments on macos has been in crazy flux and disrepair since Catalina hit. Feeling real bad for the people who just bought new macbooks only to find docker won't work and so they can't deploy their web app.
> Pretty misleading to include it in the demo if Docker for Mac still doesn't launch next week right?
The M1 hardware hasn't shipped yet. Presumably this criticism is only valid if the hardware has shipped, which it has not. If Apple did indeed have a lot of involvement porting Docker, my assumption is that they'll release that with the machines next week (November 17, 2020), as opposed to before the hardware is generally available.
Why is this even a discussion? There are thousands of applications that don't (yet) work on Apple Silicon. When the hardware actually releases the software will be slowly ported over to it.
https://www.apple.com/mac/m1/ doesn't mention anything about what doesn't work with it. It just says "With the introduction of Rosetta 2, M1 and macOS Big Sur seamlessly run apps that haven’t yet transitioned to Universal versions." The details about what won't work are in the developer documentation, which most people who buy Macs don't read.
It seems to be a trend these days that if something doesn't work right, people take to the public internet in the hopes that it will be fixed faster. I've seen this tactic on internet forums with products, after which companies often contact the reviewer of said products to make things right.
Has there been any word on third-party OS support for the new AS macs? Not just so geeks can run Gentoo on them, but also for corporate customers to virtualize MacOS. I know some fellows who run ESXi/Vcenter on clusters of Minis to run multiple versions of MacOS for QA.
It's bleeding edge new tech that other than the A12x hasn't been available for more than a few months... And I'd argue apple arm silicon is going to be a tectonic industry shift.
While Docker support will surely come, this thread does give me the feeling that Docker on Apple Silicon Macs will take at least several more months still to be released.
I would have expected Apple to be far more proactive in working with Docker, Inc., especially considering they namedropped Docker specifically at the WWDC Apple Silicon announcement. Apple has supplied virtualization capable hardware to certain developers - Parallels certainly - so it's strange to see that Docker seems to have had to sit on their hands until now? I certainly would have expected a Docker release a lot closer to hardware availability.
The fact that a stable golang for Apple Silicon likely won't be out until February is not a great look either. That blocks Docker but a lot of other things also.
I mean, you should expect a lot of startup issues when moving to a new ISA, but it seems Apple could have done a lot more here.
A big part of this is that Docker Desktop is not open source/free software: it's closed and proprietary, so you're at the mercy of Apple/Docker to fix it.
(Additionally, it's terrible spyware, and sends ridiculous amounts of data back to Docker about your system, including network pcap logs(!).)
The DTK notes stated explicitly that virtualization was not supported, and equally explicitly that release hardware would support it.
Just the DTK said explicitly that 4k pages were not supported under rosetta but would be by release - that's what broke chrome and apps that are just glorified copies of chrome.
"At its 2020 Worldwide Developers Conference, Apple announced a non-commercial prototype computer called "Developer Transition Kit" (DTK).[1] It is intended to assist software developers during the transition of the Macintosh platform to the ARM architecture. Described informally as "an iPad in a Mac mini’s body,"[2] the DTK carries a model number of A2330 and identifies itself as "Apple Development Platform."[3][4] It consists of an A12Z processor, 16 GB RAM, 512 GB SSD, and a variety of common I/O ports (USB-C, USB-A, HDMI 2.0, and Gigabit Ethernet) in a Mac mini case"
"..Even that DTK hardware, which is running on an existing iPad chip that we don’t intend to put in a Mac in the future – it’s just there for the transition – the Mac runs awfully nice on that system. It’s not a basis on which to judge future Macs ... but it gives you a sense of what our silicon team can do when they’re not even trying – and they’re going to be trying." - Apple SVP
"The Apple A12Z Bionic is a 64-bit ARM-based system on a chip (SoC) designed by Apple Inc.The chip was unveiled on March 18, 2020, as part of a press release for the iPad Pro (2020), the first device to use it.[1] Apple officials touted the chip as faster than most Windows laptops of the time.
280 comments
[ 4.8 ms ] story [ 284 ms ] thread... but for the current state where ARM-compatible images make up roughly 1% of Docker Hub, I don't even see the point of wanting to use Docker on M1.
AWS is in the process of moving all of their managed services e.g. RDS, ElasticCache over to their Graviton platform.
x86 emulation gives access to most available Docker images anyways -- and the performance of the new CPUs would seems to indicate that emulation may not be so terrible, at least for the short term.
QEMU would allow running x86 images on Apple Silicon but I don't know if the performance would be acceptable. You can't use Rosetta 2 with Linux no matter how much you might like to.
https://news.ycombinator.com/item?id=25064841 This post with 8 votes? Did it come up anywhere that got actual discussion?
A full VM with x86 emulation is not supported though, and from the sounds of it will never be.
Fair point. On an infinite time scale...
Apple would need to implement all the supervisor mode parts of x86, which massively increases complexity. It's a notably different product.
And it would even be virtualiztion, it's not exposing the real host hardware. No real x86 cpu exists to be exposed. It would just be an emulator pretending to be virtualiztion.
Kindly check your attitude at the door.
Apple explicitly said that the DTK does not support hypervisors, and that final consumer hardware would. People posting garbage reports like this to HN annoys the hell out of me.
This is strangely a really big selling point for me as a habit breaker. I spent a good part of the release evening whining about the pitiful memory and the cost of the devices but I am regretting that on reflection. Why? Well I just spent two days arguing with problems with Microsoft's fucked up shit show of mixed platform Windows containers and Docker which ultimately ended up in a completely hosed OS install. Every time I use some heavily marketed stack it turns into this mess eventually if not right away.
My conclusion is doing this on my main computer i.e. my portal to the universe is a functional risk so I'd rather do it somewhere completely different i.e. on a desktop PC hidden away somewhere or Amazon where I can nuke the whole universe and start again without losing access to essential services etc.
So perhaps I don't need a virtualization equipped CPU after all for my computer? Forcing my hand in that direction may be a net gain.
As far as I can tell, the M1 does have virtualization support, Docker just isn't ported yet.
Update: Also, from Apple docs it seems like you won't be able to run emulation and virtualization in the same process. So you can run x86 Mac apps, but it's likely x86 Docker images will be out-of-reach.
https://twitter.com/0xtim/status/1326980313160032256?s=21
(1:40:06) if the timestamp doesn't work
If the early story around performance of the M1 bears out, I suspect this won't be the case. If their CPU for the base MacBook Air trouncing higher end MacBook Pros, what kind of a beast will their higher end CPUs going to be?
People who really need x86 compatibility will stick with x86 based Macs. Others? I'm not sure. For my current job where everything runs on node.js, the performance and battery life on the new CPU is pretty appealing.
All that performance is going to be used to run cloud based Linux x86 development environments. Repl.it and Github codespaces are the real winners with the move to Apple Silicon
I'm not entirely sure that's true. Or at least not entirely relevant/ interesting.
First, you have thousands of developers writing code for iOS/ Android & Chromebooks. That right there is a pretty big chunk of developers. And at least for the iOS developers, running on ARM instead of x86 is a significant advantage.
Second, a lot of us are writing software for the web which means primarily writing software that runs in the browser. So long as we have a good running version of node.js and a browser to test with, we are golden. Assuming for a moment here that Google Chrome and Firefox are both going to be ported to ARM, I don't really see why I care about x86 linux except...
Of course you need to serve up your site and that piece is usually running on x86. Only... many of us are already crossing platforms. Our web server is Node on Linux and my dev system is MacOS (no Docker or Linux VM) so I'm already cross platform.
When I was primarily running a Python/ Django shop, it was a similar deal—so long as I was able to get Python running I was good. There are definitely a few places where you notice the difference, but there are definitely places where I can use an extra 50% battery life and a faster CPU as well.
I don't know how many other developers really need x86 and how many don't. I have had jobs where running Docker/ Kubernetes was important, but I've had a fair number where it wasn't as well.
To me this says that Rosetta doesn’t convert VT-X commands (et al) to their ARM counterparts.
I don’t see an issue here... sure you’d be left without a dedicated VM framework from Apple, but you should be able to run a qemu process that is emulating a Linux VM. That qemu binary could be either x86 or Arm. But instead of using the Mac OS Hypervisor.Framework, you’d be back to using stock qemu that we used to use. It just isn’t packaged up as nicely at the moment. (And who knows how fast it will run).
For the last year she has been working at Apple so I've always suspected that she was developing on M1 hardware but with Linux OS.
https://www.youtube.com/c/HoldenKarau/videos
Many, many images are now multi-arch so I encounter failures to deploy things to the Pi much less frequently nowadays.
A12Z/DTK: HW does not support virtualization at all.
Apple M1 / New Apple Products: HW does support virtualization for ARM64 guests (both windows and linux demonstrated).
What about x86 software in the guestOS? Not with Rosetta. Instead, the guest OS will have to provide its own translation (such as windows/arm's current x86->arm64 or upcoming x86_64->arm64 feature). I'm not familiar if there is any usable high performance x86_64->arm translation available for linux.
Docker w/ arm images: needs some work to be able to work on mac/arm virtualization, but it's coming.
Docker w/ arm linux kernel + x86 userland images: Any translation solution would be found within the linux guestOS, not macOS. I don't know if any candidates exist. Maybe qemu?
Docker w/ full x86 image (incl. kernel): I don't think this is possible?
I spent more time trying to figure out ways to get the right images than I did learning k8s, so I kinda put the project down.
I do think this is exactly the sort of thing though that will start to flush that out, long term.
Our app is React/ Typescript and we don't use Docker/ x86 virtualization at all. I do need MySQL and a few other tools, but I don't expect they will be long coming (or maybe already running in Homebrew is there Homebrew ARM?)
If you make your living writing Mac or iOS software, this is a gift. Might be worth waiting for the next generation with more RAM and even beefier CPUs, but otherwise this is ideal.
There is but it’s highly experimental still, with 50 % of formulae not working yet.
Better to run Homebrew with Rosetta for now.
You can track progress here. Be advised that packages listed as ‘check again when XYZ is fixed’ may themselves have issues that can’t yet be discovered.
https://github.com/Homebrew/brew/issues/7857
For some reason I'd completely forgotten this was an option. Looking at the discussions on the home-brew boards, it looks like this will be the way to run home-brew for some time.
My servers run Linux. Not bsd.
Having to deal with this sort of stuff is just a waste of time.
Mac's don't have a monopoly on quality, haven't for a long time.
And since it's a usual response, anyone claiming Linux is too fiddly haven't used it in a long time. And while it can be if you want to roll your own DE its completely optional. Using something like fedora you can literally do almost everything non developer based with point and click.
From being a Windows guy through all the years, I've found myself increasingly using Linux in this span of time. The only thing preventing me from a complete switch is MS Office. I barely used MacOS, except to diagnose issues on MacOS and run XCode.
If you could help me out by pointing out which products/technologies you used and maybe a website describing step by step, that would be great.
Apart from that, standard QEMU process. This was the guide I used: https://www.funkyspacemonkey.com/how-to-install-macos-catali...
Ms Office is very compatible with Wine - even the newer ones. The only problems seem to be with apps were direct replacements like Skype or are irrelevant like OneDrive.
For setting up wine and managing my apps I use Lutris. It is meant for games but is brilliant for setting up windows apps as well. I wish they would acknowledge that fact in their UI but it doesn't bother me too much that everything is called a game.
If i can't run our own images on a future mac, i will no longer buy one.
I can't force my team to maintain two versions if there is no better business reason.
I'm quite curious how this will play out.
Also, be real careful you don't accidentally build for x86 when installing libraries or it all goes to shit. I got bitten by this by using iTerm (building it from source was fine though) and not realizing it was the x86 variant. That is to say, make sure your terminal is the system terminal or built for ARM-- otherwise when you install things using package managers they'll be the x86 variant.
Like, I'm super stoked for the M1, but also just totally fucking irritated about the toolchain changes and MacOS in general... They've not been the best stewards of their software and developer communities as of late, and they're pushing a totally proprietary architecture onto them expecting them to foot the bill (hours spent fixing/debugging) to make their platform usable.
Truly, I get paid to write software that runs on Linux not on Macs. In fact, I've never gotten paid to write software for Macs, because no production systems use Macs. Now it is harder for me to do primary development on a Mac; because I must fix MacOS or live with MacOS only bugs... bugs which only exist on a platform I do not intend to deploy my code to... these aren't just some config bugs either they're going to be a fucking mess of irritating, show-stopping, moving targets with a negative ROI.
I still can't believe they didn't incorporate containers into the OS before switching platforms to keep developers around but that's a totally different rant.
Yes, I understand why, but still...
That could be something doing dynarec like box86, which is mindboggingly the only way to run (x86) Zoom on a arm7hf Linux atop a Raspberry Pi 4 (I tried it on a Pi3B: it works but it’s way too slow)
https://github.com/ptitSeb/box86
as mentioned in the issue comments: Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac, so x86 images via qemu on ARM host should not be a problem...
it "works", but on my overpowered i7, running a raspberry pi docker image that way with qemu-user-static is... only marginally faster than running the code on an actual rpi 3, which is pretty much potato-levels of power.
(It would at least be a huge problem for me. I mostly develop server software that runs on Kubernetes on AMD64 machines.)
PS C:\Users\hokaa> docker run -it --platform aarch64 ubuntu root@aaf35d3fd9de:/# uname -a Linux aaf35d3fd9de 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
And yes, AFAIK it uses qemu's binary translation.
What gives me pause moreso than this is the absence of the touchscreen and Face ID, which are very obviously coming in the next refresh (iPad app support without touch?).
As impressive as the new MacBooks are, they’re very clearly a stopgap solution so as not to replace everything all at once.
I agree, but at the same time, they pushed it pretty hard by not just doing an Air with the chip like I thought they would, but putting it in a Pro as well (with, according to the early benchmarks I've seen, barely any performance difference. I mean they could at least have put two of them in there)
The Pro adds
- Brighter Screen - Better cooling for extended CPU loads - Touch Bar (which many don't care for) - Bigger battery.
The MacBook Air boosted to 16B is likely the biggest bang for the buck unless you are going to be hitting that CPU hard all the time. The iPad has pretty damned good performance without fans so I expect the Air will do quite fine.
ఠ_ఠ
Edit: This is my personal laptop fwiw. My work one is still Intel.
Is that worth $300, for a larger form factor?
From what we know right now - same processor, different thermal envelope.
Not that the transition has been seamless, but I’ve only had to fall back to my Macbook once in the past three months. There’s something about shaking up the routine, plus the forced simplicity and single-tasking has majorly helped my focus. I just wish Cloud9 or Codespaces worked better on an iPad...
Games are mostly C++, based on my experience with C++ codebases I'd say there's about zero chance that a game could be (easily) recompiled and made to work on ARM.
And games won't be ported anyway because it's too much work for too little sales, even if a developer really wanted to make it work they'd need a $2000 new mac to be able to compile/test in the first place.
Plus another 100 or 200 in adapters. It's beyond me why they would make a laptop with zero USB and zero HDMI ports.
Total is $2000 when converted back in USD.
The 10% might still be to account for the instability of the GBP.
However it still won't give you any HDMI or audio or Ethernet output. If you try to get one more adapter, say HDMI to connect a projector, you won't be able to plug it because there was only one thunderbolt port in the first place.
£75 pounds for basic connectivity https://www.apple.com/uk/shop/product/MUF82ZM/A/usb-c-digita...
£120 pounds for dual display with dual USB. https://www.apple.com/uk/shop/product/HMX02ZM/A/caldigit-thu...
£230 for a dock https://www.apple.com/uk/shop/product/HMX12Z/A/caldigit-ts3-...
That said, it sounds like you're really not interested in this market and I recommend you look elsewhere for a solution.
https://www.amazon.com/Anker-Upgraded-Delivery-Pixelbook-A83...
https://www.amazon.com/Anker-PowerExpand-Adapter-Delivery-Et...
Performance? Who knows.
Ninja edit: I guess you're suggesting that some parts are in hand rolled x86 assembly, not just pure C++ that would be output as the cross compiler target architecture?
https://www.apple.com/shop/refurbished/mac/macbook-air
I've bought a lot of Apple refurbs, they are like new in every respect.
Obviously if you just make websites it doesn't matter but if I'm buying an ARM device I want to play with the bare metal (you can't even access performance counters in MacOS IIRC)
Websites in 2020 is not that simple. At my workplace, we use Docker extensively in our build pipelines
I don't like Apple devices myself but I understand that some people like the ecosystem as a whole.
However I don't understand the point of a Mac without MacOS. The hardware is pretty much garbage compared to any laptop of the same price range, let alone high-end laptops like Thinkpads.
(this is a honest question and I am not trying to troll or make fun of anyone, in case anyone doubt of the tone of my post)
Also, many people like to work with dual boot devices. And no, virtualization is not the same.
The hardware is also not garbage. It may not be competitive, but it is well made.
To answer your question, I don't see much reason to buy a MBP and run it without MacOS, because -- although the build quality is sensational and the MBP travels well -- I'd rather just buy a Lenovo with Windows 10 Pro from the factory, get their top-tier service and repair plan, and still come out cheaper than a new MBP. However, I could see myself converting an old MBP for use as a Windows machine.
For the same use cases Linux feels (and is) way more performant and responsive even on a less powerful hardware, and I'm not even talking about Docker.
The MBP keyboard is probably the worse on the market and any lower-end laptop keyboard is more comfortable to use. And nowadays it is not even a complete keyboard since it lack many standard physical keys.
The number of ports is extremely limited and you cannot connect anything without an adapter.
The computer gets hot very easily, and when it does, the keyboard gets extremely hot as well. It is also very noisy compared to any other laptop.
The glossy screen may look cool in a shop but it is very unpractical and uncomfortable.
I do not have any of those problems with my X1, I even have the best keyboard I could hope for a laptop, along with actual features like the Trackpoint, physical camera shutter or the PrivacyGuard.
1.5) I like the GPL, apple doesn't
2. I like apple's hardware in a vacuum. As much as the company leaves a bad taste in my mouth (there is a deeply pretentious streak to Apple's approach to their users), they make nice cases and such.
Funny how far we've gotten from "It just works"
Someone said WebAssembly? :P
The net impact of this is not particularly high. I always write my apps so that they can run on the local machine, and just have my CI system put them in Docker images for deployment. But, that does require some effort, and some language ecosystems or applications make this nearly impossible (relying on details like case-insensitive filenames, OS quirks, etc.)... so people just develop inside a container to work around that. (I would never tolerate it, but it can work OK for things like PHP where your edits take effect in the running container without having to rebuild anything.)
runV and VMWare Vsphere 7 can run each container in its own VM.
WSL v1 did not run a Linux kernel at all, but v2 does.
And even with WSL1, they didn't implement the cgroups APIs, and couldn't support Linux containers.
Won't it always cause issues? If you build locally you are packaging ARM binaries in zfs which won't run on x86... unless you somehow signal to docker that you want a different arch when building
Obviously they done have access to the shipping m1 devices yet, which are supposed to have the hardware support.
It is always a bit of a gamble to be on the bleeding edge with your production machine!
I used to be fairly laissez-faire about it but now I really think it should be legally required for at least some level of freedom for the end users to be supported (technologically rather than as in customer service) by big tech companies selling hardware
People aren't laughing now, are they?
https://www.youtube.com/watch?v=Hg9F1Qjv3iU&t=3772
See this WWDC session: https://developer.apple.com/videos/play/wwdc2020/10686
and this manpage: https://pastebin.ubuntu.com/p/RwcT8stYMY/
If you have code that makes use of custom instructions, even if only sprinkled in a few places, the emulator must support them.
If you have a cpu with those extra instructions that is otherwise backwards compatible, you can run code that doesn't make use of such instructions just fine (of course, you won't benefit from the functionality/performance offered by those new instructions)
See https://arstechnica.com/gadgets/2020/03/project-sandcastle-b... on details about it. This work, especially as there's no exploiting security bugs required here, will benefit Linux on those Macs quite a lot.
Right, it sounds like Apple was very careful to provide an out here for enthusiasts by making it possible to sign your own kernel, something you can't do for iPhone/iPad/Watch. Seems like an astute appreciation of differences in their target market.
However, as they showed at WWDC [1], you can run Linux and other operating system using Apple's hypervisor. And it will run faster on an M1 Mac than it does natively on comparable Intel hardware.
[1]: https://developer.apple.com/wwdc20/10686
https://twitter.com/never_released/status/132631574108015001...
That is to say, am I supposed to compare based on price, power consumption, process node equivalent, or some other factor?
I ask because it's hard for me to understand the comparison otherwise.
Why?
If it's about the dominance of x86, I think in about 15-20 years there will be no other architectures in widespread use except for ARM and maybe RISC-V.
https://news.ycombinator.com/item?id=22837753
x86 has lock in like that in spades.
What I think is much more interesting is what the software industry will do with all these random coprocessors we find in chips these days. They seem much less stable than an instruction set but amazing speed gains can be had there, so it's enticing. If software libraries can bring the dream of the HAL to reality, that would be pretty cool.
But from threads like these, it's safe to conclude we're not there just yet.
https://news.ycombinator.com/item?id=25057985
Now $699 M1-based Mac mini is way faster than any Intel box in that price range and many that cost much more.
The benchmarks that are starting to come out are just nuts, favoring the M1.
Of course not all of the pieces are in place; that takes a while. But those developers that are on top of their game released universal versions of their apps that take full advantage of the M1 SoC and all of its benefits: unified memory, 8 CPU and GPU cores, Neural Engine, etc.
It's day 1 of Big Sur being available and customers haven't gotten their M1 Macs yet, though they'll have them in a few days.
In a couple of months, once the dust has settled and developers have gotten their hands on shipping hardware, people's understanding of what performance is possible on consumer-level hardware will be changed for good.
There are Hollywood studios already planning to replace their high-end, pro Macs with M1 Mac minis because they'll be faster than what they have: https://appleinsider.com/articles/20/11/12/hollywood-thinks-...
Now people are at home again, and not quite so mobile. Commensurately, we are seeing a breath of life into a laptop/desktop market segment that, with few exceptions, has been marching to a steady drumbeat for at least the past six years.
True. The Mac had its best quarter ever, which should be a good setup for the transition to M1.
x86 and Intel are making all their money running your k8s on AWS, GCP and other server platforms so you can consume on your locked down ARM device. That's where the big money and margins are.
Apple never really could get a foothold in that market.
ARM is coming for the datacenter too; this will not end well for Intel [1]:
[1]: https://www.zdnet.com/article/aws-graviton2-what-it-means-fo...What they're showing now is pretty damn impressive. I look forward to the M2 or whatever variants that would be a more direct replacement for the 2019 rMBP I have now (6 cores, 32GB RAM).
But I'm happy to wait. If you don't have virtualization needs, and your use case is pretty straightforward, these are gonna be amazing machines. They're just not the power user machines -- I mean, except for those who insist on bleeding-edge living.
https://i.imgur.com/bQb1grM.png
Pretty misleading to include it in the demo if Docker for Mac still doesn't launch next week right?
The M1 hardware hasn't shipped yet. Presumably this criticism is only valid if the hardware has shipped, which it has not. If Apple did indeed have a lot of involvement porting Docker, my assumption is that they'll release that with the machines next week (November 17, 2020), as opposed to before the hardware is generally available.
It's bleeding edge new tech that other than the A12x hasn't been available for more than a few months... And I'd argue apple arm silicon is going to be a tectonic industry shift.
Does it ARM? https://news.ycombinator.com/item?id=25075458
I would have expected Apple to be far more proactive in working with Docker, Inc., especially considering they namedropped Docker specifically at the WWDC Apple Silicon announcement. Apple has supplied virtualization capable hardware to certain developers - Parallels certainly - so it's strange to see that Docker seems to have had to sit on their hands until now? I certainly would have expected a Docker release a lot closer to hardware availability.
The fact that a stable golang for Apple Silicon likely won't be out until February is not a great look either. That blocks Docker but a lot of other things also.
I mean, you should expect a lot of startup issues when moving to a new ISA, but it seems Apple could have done a lot more here.
(Additionally, it's terrible spyware, and sends ridiculous amounts of data back to Docker about your system, including network pcap logs(!).)
Just the DTK said explicitly that 4k pages were not supported under rosetta but would be by release - that's what broke chrome and apps that are just glorified copies of chrome.
"..Even that DTK hardware, which is running on an existing iPad chip that we don’t intend to put in a Mac in the future – it’s just there for the transition – the Mac runs awfully nice on that system. It’s not a basis on which to judge future Macs ... but it gives you a sense of what our silicon team can do when they’re not even trying – and they’re going to be trying." - Apple SVP
https://en.wikipedia.org/wiki/Developer_Transition_Kit_(2020...
"The Apple A12Z Bionic is a 64-bit ARM-based system on a chip (SoC) designed by Apple Inc.The chip was unveiled on March 18, 2020, as part of a press release for the iPad Pro (2020), the first device to use it.[1] Apple officials touted the chip as faster than most Windows laptops of the time.
https://en.wikipedia.org/wiki/Apple_A12Z
HTH