4 ms·

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 s

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.

daibo 5y ago
Nothing wrong with that though
- datatrashfire 5y ago
  Yea, I personally think local development is fraught with problems that remote resources solve quite well.
  - frant-hartm 5y ago
    I personally think remote development is fraught with problems that don't exist on local.
    - kergonath 5y ago
      Both can be true at the same time…
      - ungamedplayer 5y ago
        Worse case scenario too.
    - datatrashfire 5y ago
      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.
- hackerfromthefu 5y ago
  Mind you in that case a cheap Chromebook with a decent screen would fit the bill
  - prewett 5y ago
    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.
mrtksn 5y ago
What about an install script that installs the native toolchain to each device? Does everything need to be a container?
- oblio 5y ago
  If you don't want your deployments to be even more complex, yes, they probably have to, especially at scale.
  - mrtksn 5y ago
    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.
acdha 5y ago
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).
- datatrashfire 5y ago
  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.
  - acdha 5y ago
    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.

daibo 5y ago

Nothing wrong with that though

datatrashfire 5y ago
Yea, I personally think local development is fraught with problems that remote resources solve quite well.
- frant-hartm 5y ago
  I personally think remote development is fraught with problems that don't exist on local.
  - kergonath 5y ago
    Both can be true at the same time…
    - ungamedplayer 5y ago
      Worse case scenario too.
  - datatrashfire 5y ago
    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.
hackerfromthefu 5y ago
Mind you in that case a cheap Chromebook with a decent screen would fit the bill
- prewett 5y ago
  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.

mrtksn 5y ago

What about an install script that installs the native toolchain to each device? Does everything need to be a container?

oblio 5y ago
If you don't want your deployments to be even more complex, yes, they probably have to, especially at scale.
- mrtksn 5y ago
  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.

acdha 5y ago

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).

datatrashfire 5y ago
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.
- acdha 5y ago
  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.