121–130 of 231 posts
Earlier quoted context omitted.
Got a link to proof of this?
https://www.mail-archive.com/qemu-devel@nongnu.org/msg766282... for the Qemu patches and https://www.microsoft.com/en-us/software-download/windowsins... for downloading the Windows build
Now come on Windows! Give me a solution for that (although I rarely use it) and I’m sold or maybe I moved the goal post to requiring more than 16gb RAM again but come on everyone you can do it! edit: guys I'm talking about running Windows on a VM on a M1 macbook. Just going down the checkbox of virtualization options. Docker is one checkbox. Now want Windows and Vmware/VirtualBox/Parallels
The WSL 2 version of Docker is a very fast and solid experience for Windows users.
Earlier quoted context omitted.
> Docker on Mac has never felt as snappy as on Linux It's extremely slow compared to Linux and I'm pointing my fingers at the virtualization layer without any hard evidence because it's the most likely suspect. With all this focus on sandboxing apps of late, I'm wondering how far the OSX kernel is from having a feature set that resembles cgroups and network namespaces.
They have containers already in a sense, whatever the iOS Simulator.app uses is not VMs, and it's a container in more ways than just one.
Earlier quoted context omitted.
https://www.mail-archive.com/qemu-devel@nongnu.org/msg766282... for the Qemu patches and https://www.microsoft.com/en-us/software-download/windowsins... for downloading the Windows build
Question, is there persistence with that? Or are changes lost once it is closed?
Wow, that was fast. I was expecting to wait unil January. Key takeaway for me is the ability to run/build both x86 and Arm images on a M1. Can't see any reason M1s can't be used for everyone at my work now. Very nice.
It won't be more than a tech preview until after Go is stable on the M1 which is likely to be January/ February. Once that happens, it should be pretty quick.
Earlier quoted context omitted.
> Just because CorporationX says “don’t worry about it we got you bruh” doesn’t mean technologists - people who actively work with technology and write software - should be excused for just throwing up their hands and saying “it’s just ducking magic I don’t know how it works”. Entire industries are built on the premise that "don't worry about it, we got you". I'm not saying that it's appropriate to be completely blin…
> This is what you said: The “one sentence” I was referring to is right above the bit you quoted: > I’m talking about understanding that containers are inherently tied to the kernel, and thus are limited to running software written for the same kernel as the host running the container.
It explains one aspect/limitation related to the execution of code in a container, but does not foster a deeper understanding of container architecture for the uninformed reader, and is actually somewhat misleading considering Docker's use of a VM behind the scenes in some situations (in which case the "host running the container" is technically the VM, not the user's PC).
I sense that you have useful knowledge to share. I'm afraid you've missed the mark. Instead of spreading vitriol and asking why everyone around you is so dumb, focus that energy on sharing that knowledge!
Perhaps a dumb question but I'm curious why people don't use a VPS or a cloud linux machine more for Docker/K8s development instead of running Docker locally on a Mac. In my experience Docker Desktop has been such a resource hog, and Apple's hypervisor implementation pretty poor. I much prefer to have all that heavy lifting isolated away from my development machine to keep it responsive and cool.
It can get surprisingly expensive when left on 24/7. If someone can come up with a remote (dare I say, serverless?) development environment that could seamlessly suspend/resume or share resources, then it would be a lot more compelling to me.
Earlier quoted context omitted.
Intel's fat margins are largely based on their duopoly on x86. With ARM, it's far more competitive and margins are far lower. With Nvidia owning ARM, it seems likely we'll see more ARM CPUs from them. Samsung, Qualcomm, and Mediatech also have ARM CPUs all the way down to a few dollars per CPU. Intel isn't going to be able to come in and charge $50-500+ unit the way they do with their x86 chips. Unless Intel can rebo…
I don't disagree. In fact, I'm assuming that's a major reason they've not done this sooner. Intel tried to setup a different more efficient architecture with IA64, but they failed there. That being said, with major players like Amazon and Google tinkering with ARM in the cloud and Apple getting ARM into the hands of a lot of developers, we could be on the eve of seeing ARM make a big entrance into the server realm. I…
I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes.
Then I moved into managed languages, where the actual CPU and even underlying OS, only matter to low level coding, again not using the same local OS/CPU combo as the server.
Finally, cross compilation for ARM exists since years.
ARM hasn't taken off, because most of time it doesn't matter enough to displace the existing stacks.
Earlier quoted context omitted.
It won't be more than a tech preview until after Go is stable on the M1 which is likely to be January/ February. Once that happens, it should be pretty quick.
If you can run x86 programs, just use that for Go?