Hacker News Reader

Comment by datatrashfire | Hacker News Reader

Just remember, containers don't just run everywhere. Your team will need to devote time to understanding multi-arch images and builds. If you're a python/data science team, I hope you have someone on your team that actually knows how to debug these problems. Otherwise you'll be using your $3k Mac as a thin client to an x86 resource to do your development work.

View on HN

What about an install script that installs the native toolchain to each device?

Does everything need to be a container?

If you don't want your deployments to be even more complex, yes, they probably have to, especially at scale.

What are the reasons for deployments to be more complex by default between machines?

Incredibly large and complex programs are deployed on user devices all the time and most of the time all is needed a "Next Next Next" or copy to a folder.

Yeah, sure you may need a specific runtime to be installed but that can be achieved through a deployment script too. Remember installing DirectX when installing a new game?

Sure, there are cases where specific app may need specific version of it and another app may need a completely incompatible version however this is more of an edge case.

Containers are definitely very powerful in some cases but I find it very distasteful to make EVERYTING into a container. It's not like apps are deployed on a server with custom version of Linux made by North Korea and the other one on a Nintendo. Most of the time, it's the exact same environment everywhere or it is a few command away from being exactly the same.

Containers can run anywhere you have emulation (Docker, Podman, etc. support it) but it’s not like it’s hard to build them, either - that’s the point. I was curious how much of a problem this would be but in practice it’s been something I’ve needed to care about only a couple of times (e.g. Java 8 has some race conditions under emulation causing the JVM to panic).

That's a good point. I have started building x86 images on my m1. It's slooow. I don't have precise benchmarks, but think a 3-5x longer times to build. As far as running the application, will if you're cpu bound, you're not gonna have a good time.

Oh, sure — basically for me it ends up being the case that most of the containers are either native or ephemeral enough that I don't care, and the ones I notice are a quick build away. It's definitely not perfect — I'm hoping GitLab CI lands integrated buildx support soon — but it's been pretty manageable and I think it's a fair tradeoff for everything else being faster & twice the battery life.

Nothing wrong with that though

Yea, I personally think local development is fraught with problems that remote resources solve quite well.

I personally think remote development is fraught with problems that don't exist on local.

Both can be true at the same time…

Worse case scenario too.

Yea it can be picking your own poison in some respects. My preferred workflow is something like spinning up a dedicated dev VM within your provider, install a standard image, then use a local text editor that's saving files over ssh or sftp.

I have found virtually no one has problems with "well I can't get this to run on my machine and here are the n undocumented quirks". Everyone is using a homogeneous environment with local IDE help.

This is in many respects similar to the idea of GitHub codespaces and other remote dev environment tooling that has started to pop up.

While I haven't used any of them, I think the general principle makes a lot of sense. You can also develop on very light local hardware, while taking advantage of an elastic resource depending on what you're doing.

Mind you in that case a cheap Chromebook with a decent screen would fit the bill

In my mind, "decent screen" is retina-quality display, which limits things. I doubt a cheap Chromebook will have one. The Chromebook Pixel has a 13" retina display option, but why not get an M1 Air and get all the functionality of a real, mainstream OS. (Unless Chromebooks have expanded from minimal Linux using a browser?)

Personally, 15" is about the minimum screen I'll accept if I'm going to do actual work on it, and at that size I expect the choices to be sparse to none. Certainly not cheap.

Reply on news.ycombinator.com