261–270 of 313 posts
Earlier quoted context omitted.
You forgot X11 and Motif. Without that Windows would be useless back in the day.
Not really, because there were plenty of Win32 X Servers. Back in the day I was using Hummingbird.
Earlier quoted context omitted.
Apple has Hypervisor.framework which has been updated for ARM Mac[1]. Xhyve and HyperKit (used by Docker for Mac) uses Hypervisor.framework exclusively. The last time I tried Hypervisor.framework on x86-64, the CPU performance was quite fine (matches that of VMware/VirtualBox), but I/O was pretty abysmal. Emulating x86-64 on ARM is probably going to be a role of something similar to QEMU. [1]: https://developer.apple…
Parallels already announced they’re going to have an option. TBD on what it looks like. https://www.parallels.com/blogs/apple-silicon-wwdc/
Are there any excited embedded developers in the crowd? I have done a little embedded work and cross compiling has always been a huge pain in the ass to setup. I know some people have even gone as far as purchasing expensive niche workstations with ARM CPUs specifically to avoid this problem. I feel like having a mainstream ARM platform like the MBP will make compiling software for ARM-based single board computers a…
I'm actually not worried, for a few reasons; - I already do cross-arch development day-in and day out between x86 and ARM, and have only run into hard blockers on a library or tool a handful of times. The solve was generally pretty straightforward to either use an ARM-compatible alternative, or to cross-compile it myself. - We've done this many many times before and it's not that bad. I know I'm not the only one old…
In fact, let's bring back Ultrix/OSF/1, DG-UX, Solaris! (... we can skip HP/UX and SCO because they're truly awful). Note that OpenVMS has already apparently made it's x86_64 comeback!
This seems like a weird benchmark, reading from /dev/urandom and gzipping random data does not seem like something most folks will want to do. It even appears like /dev/urandom speeds differ greatly on various architectures [0] and there are issues with /dev/random being fundamentally slow due to the entropy pool [1] (but I guess this is why the author uses /dev/urandom). It would be better to measure something more…
Author here. I'm glad somebody said something! Yes the gzip perf test is pretty silly, but illustrates a significant difference. /dev/urandom throughput on this setup was about 100 MB / s so it wasn't a bottleneck for this test - the bottlneck was gzip. Feel free to come up with a performance test yourself! I personally want to know what an HTTP test would look like. You can run an ARM image by running: docker run -i…
> Emulators can run a different architecture between the host and the guest, but simulate the guest operating system at about 5x-10x slowdown.
I think this is a misleading statement because it implies that there is a constant performance overhead associated with CPU emulation. In reality, the performance relies heavily on the workload, more so with JIT-ed emulators.
Regarding this specific benchmark, I think there are two main factors contributing to the poor performance. The first factor is that the benchmark completes in a short period of time. With JITs, performance tends to improve for long running processes because JITs can cache translation results allowing you to amortize the translation overhead. Another factor is that your benchmark is especially heavy on I/O, meaning that it spends a lot of time translating syscalls instead of running native instructions.
I'd also like to add that CPU emulators sans syscall translation should work for any binaries, even those targeted for Linux. It would require a copy of the Linux kernel, but Docker won't work without it anyways.
> Why can't you update the Docker image to also support ARM? You theoretically could switch your backend to run ARM Linux. However, this would take months No need to take months. `docker buildx` can build multi-arch images without using real ARM instances.
Earlier quoted context omitted.
Not really, because there were plenty of Win32 X Servers. Back in the day I was using Hummingbird.
You forgot about porting and compiling software which depended on X11 and Motif. Linux won because of that.
I used to admin UNIX and develop for it from Windows NT/2000 workstations.
Also the FOSS version of Motif only appeared when Motif wasn't that much relevant and most enterprise shops were migrating to CORBA and Web as integration points.
Earlier quoted context omitted.
If Microsoft had been more serious regarding POSIX personality, Linux would never had taken off. Most devs only want some kind of CLI and POSIX like capabilities.
> Most devs only want some kind of CLI and POSIX like capabilities. which is why WSL is so great...
An approach already taken by other UNIX clones with their Linux compatibility syscalls layer.