131–140 of 313 posts
Once again -- Apple will do what the entire industry without Apple couldn't do. In this case, force a migration to ARM-based servers, so that prod is running on the same architecture as the developer's machine. Apple is finally killing x86.
Earlier quoted context omitted.
Every time Microsoft or Apple majorly screws something up, people say this. It still hasn't happened yet. However, I think Apple has been a far greater threat to Linux adoption than Microsoft. Why? Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux. There is real value in proprietary commercial end-user application software. Most companies wh…
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.
which is why WSL is so great...
It didn’t take months, the time I did it (running Docker on a Pinebook, which was not a great experience). It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built.
> It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built. Why did you have to switch from Alpine to Debian? Alpine supports ARM quite happily, and it looks like they're shipping Docker images for ARM (and other architectures, too).
Mac book was never really a dev platform. Maybe for front or nodejs, or definitly for native apple apps, but seriously, brew and so are so subpar.
Earlier quoted context omitted.
> Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux. The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks. The hardware used to be pretty nice, but honestly I'm still having trouble forgiving them for getting…
>> Because it gives techies the nix environment they want, with the software and hardware support no one will give them on Linux. > The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks. It doesn't have to be the best nix environment. Hell, it doesn't even have to be a good one. It just…
Earlier quoted context omitted.
Apple released a list of open source projects that they have ported to ARM, they intend to upload patches to each of these projects: - Bgfx - Blender - Boost - Skia - Zlib-Ng - Chromium - cmake - Electron - FFmpeg - Halide - Swift Shader - Homebrew - MacPorts - Mono - nginx - map - Node - OpenCV - OpenEXR - OpenJDK - SSE2Neon - Pixar USD - Qt - Python 3 - Redis - Cineform CFHD - NumPy - Go - V8
It’s interesting that Electron is on that list.
Earlier quoted context omitted.
Almost every server applications (databases, webservers, webapps) are available as docker images. It's very easy to deploy those apps using docker, which is why it's taking over sysadmin world by storm. Previously, handling a big web application deployment is a complex task that requires a dedicated team. Now, you can just package your app as a docker image, and other people that know docker will know how to deploy y…
If you use Docker as a production tool instead of prototyping several shit will happen soon.
Develop on the platform you want to deploy to.
EDIT: I suppose I should clarify; I don't totally disagree. I personally run Ubuntu on my laptop and servers. But plenty of people are quite happy developing on Darwin and deploying to some sort of GNU/Linux.
Earlier quoted context omitted.
When was the year of the macOS desktop?
It's not about stealing users from macOS. It's about stealing developers. Hell, Apple is at the mercy of Microsoft and Adobe right now. I'd bet they had to line their pockets very well, so that they don't get any funny ideas. But Apple can't just pay-up every cross-platform software developer. Smaller developers will have to re-evaluate whether macOS remains a viable target platform for them. Which can translate to a…
Didn't think of that. If running Docker is 10 times slower on ARM and virtual box doesn't support the architecture at all, this might indeed end developers using Mac.
I've been developing on a Mac for years, and I've never needed to use Docker or virtualisation to do it. (I've been doing game development, and now web front end development. I'm sure the major game engines and browsers will be ported to run on ARM chips (although it may take a while)). Honest question: What sort of development regularly requires using docker or virtualized OSes?
1) I wanted to provide a Jupyter notebook with IBM DB2 support for a university course. (Why DB2? Because its optimizer can transparently use materialized views for query optimization which PostgreSQL can't AFAIK.) IBM provides a Jupyter magic which requires the Python package ibm_db. ibm_db requires a DYLD_LIBRARY_PATH hack which macOS doesn't support unless you disable System Integrity Protection. I don't want to disable SIP on my system and I can't ask our students to do that. A Docker image provides a convenient solution to the problem.
2) I do a lot of disparate project development using Flink and Hadoop. These get deployed on Linux machines. My preferred way to develop on my Macbook is to boot up a headless Ubuntu system inside VirtualBox, SSH into it, and then start a TMUX session. This has a number of advantages. a) The dev environment more closely resembles the production environment. b) I can setup my TMUX session, save the state of the VM, and then restore it months later to the exact state just by booting up the VM. c) I don't have to pollute my macOS environment with dev tools that I rarely use. It's not strictly necessary but it's actually quite convenient. I can even do development in IntelliJ on macOS, run the services inside the VM, and thanks to remote JVM debugging use the IntelliJ debugger on macOS to step through the code running inside the JVM.