131–140 of 211 posts
Earlier quoted context omitted.
This is an unhelpful and useless comment
And so is yours? I do often find myself wondering whether Docker saved developers or system administrators any time. Is Docker really better than building an AMI and provisioning EC2 instances on-demand?
Earlier quoted context omitted.
And money
I use a shitbox of a thinkpad with my dev environment in the cloud, but they run Linux so I can just as easily run it locally if I have no connection. I buy them for $300-500 on eBay, upgrade them to at least 16gb of RAM and a 1TB Samsung SATA SSD. I have 2 cold spares ready to go, credentials loaded, just need to update and sync a few git repos. 14 inch 1080p IPS displays, i5 processor, 16GB of RAM. The money I save…
Earlier quoted context omitted.
I'm not sure I understand the question? I close the lid. How do you do it?
It a jab at Linux/PC. Apple's completely vertical stack means that their machines never have issues sleeping. The huge variety of machines that Linux (and Windows) is expected to run on can cause problems entering S-states reliably. This issue is pretty uncommon (excluding the Windows modern sleep disaster), but that doesn't prevent comments like the GP throwaway.
That being said, it happened on my m1 MacBook a few weeks ago - so seems like Apple is no better ;)
Earlier quoted context omitted.
A customer's Mac with a M1 is only 50% faster than my Intel laptop from 2014 at running Rails tests, because they run in a docker container: 50s vs 75s. The difference between the two machines should be much more than that (CPU, RAM, data bus, etc.)
You should try running your dependencies on docker but ruby on the host machine.
Earlier quoted context omitted.
I used to be on the side of relying on native tools/libs, and managing them in a similar way to what you to describe, but it all became too much to handle, with dependencies across projects breaking with regularity. Maybe I wasn't doing it right, but switching to Docker to sequester my projects and their dependencies has saved me so much time and hassle, especially with the amount of repos I work on throughout the ye…
My point was that you can do this without docker. On Linux you can use separate chroots for each project, on OSX you could probably do that too but since prebuilt tools for generating a darwin rootfs are rarer prefixes are easier.
but it has really hit me recently how so many “indispensable” projects are just something that’s existed for decades re-written at a higher abstraction-level with a nicer UX.
I wish I had more classic Unix sysadmin experience. But unfortunately the gains are real, and I can’t justify investing time into learning the older tech (let’s say, using chroot instead of docker), when the newer is so much faster to learn, and has (comparative to modern hardware) such small overhead (if you’re not on MacOS :P)
I am excited about the rust-rewrite movement for shell though - precisely because it’s a chance to bring all the ux lessons we’ve learned in the last decades to cli-tools.
Stuff like charm.sh is super exciting.
Earlier quoted context omitted.
It cost money sounds like the big one
Even after building and selling developer tools for a decade, it always surprises and enrages me to see how miserly developers are.
If spending was our thing perhaps we'd have gotten into woodworking, or photography, or whatever it is that can take a good chunk of change to get into deeply instead.
Earlier quoted context omitted.
This is an unhelpful and useless comment
And so is yours? I do often find myself wondering whether Docker saved developers or system administrators any time. Is Docker really better than building an AMI and provisioning EC2 instances on-demand?
With a docker compose file in place, all I need to do is run "docker-compose" and everything is up and running.
It's such an upgrade over what we had before.
Earlier quoted context omitted.
For many Mac is the only sensible option. There's one developer in our company that uses Linux and it's a lot of pain to setup. Mac has the best balance between coding, utility tools and "other work stuff". Windows probably on par if not more for "work stuff" but falls badly in the coding & tooling department. Linux is OK ish for coding and utility but falls behind for "other work stuff" and certainly a pain to just…
> but falls badly in the coding & tooling department. That's more perception than reality, often from people who simply don't know how to use Windows. Visual Studio, Visual Studio Code, and IntelliJ IDEA blow any Linux text editor out of the water for developer productivity. For Linux workloads there is the Windows Subsystem for Linux (WSL 2), which now even supports GUIs with GPU acceleration! Visual Studio Code can…
Of all things in this comment this one is the funniest, because Emacs was able to do it for years (decades?).
Earlier quoted context omitted.
For many Mac is the only sensible option. There's one developer in our company that uses Linux and it's a lot of pain to setup. Mac has the best balance between coding, utility tools and "other work stuff". Windows probably on par if not more for "work stuff" but falls badly in the coding & tooling department. Linux is OK ish for coding and utility but falls behind for "other work stuff" and certainly a pain to just…
> but falls badly in the coding & tooling department. That's more perception than reality, often from people who simply don't know how to use Windows. Visual Studio, Visual Studio Code, and IntelliJ IDEA blow any Linux text editor out of the water for developer productivity. For Linux workloads there is the Windows Subsystem for Linux (WSL 2), which now even supports GUIs with GPU acceleration! Visual Studio Code can…
The inability to get something akin to VT220 terminal access and shell scripts on a POSIX-based system without resorting to a virtual machine (a la WSL2) is a deal-breaker for me. The steps for using scripting languages (e.g. Node, Python, Ruby) is typically entirely different on Windows than it is from all other server and desktop platforms.
For those who can spend their time nearly 100% inside an Electron-based or Java-based IDE however, it matters a lot less whether that IDE is running Windows, MacOS or Linux.
> On Windows, x86 and x64 Linux Docker containers run in process isolation at full speed, unlike on Macs where there is CPU emulation required.
You do realize they didn't require us to all burn our old Intel-based Macintosh computers, right? Apple even still sells Intel-based Macs.
Windows requires emulation to run aarch64-based containers. Except on Windows for ARM of course, where presumably they run full speed but those x86/x64 containers above require CPU emulation.
Funny that this came up — shameless plug: I've actually been working on a new Linux+Docker+Kubernetes solution for macOS recently! Already added quite a few improvements over existing apps including Docker Desktop, Rancher, Colima, etc: - Fast networking: 30 Gbps! vs. 150 Mbps with Docker VPNKit. Full VPN compatibility, IPv6, ping, ICMP and UDP traceroute, and half-open TCP connections. - Bidirectional filesystem sha…