Sometimes I wonder about the carbon footprint of current technologies (e.g. CI/CD that spins up a docker container to run literally 5 command and shut it down again, or the machine ops overhead of writing a GUI app in python vs C)... Is there any study on that?
@matteoscordino Good point, would like to hear that too.. I always feel a bit guilty when travis-ci spins up my tests and runs for over 30 minutes after I fixed a typo in the README.md ..
@proycon Exactly... I remember thinking "what?! A whole machine to run a script and then discard it?!" the first time I heard the concept of containers in the CI context (from a node.js Feb, IIRC).
It feels to me that the a lot of the problems this approach addresses are born out of lazy scripting and bad "housekeeping". A bit like garbage collectors are a solution to badly written memory management...
It's not that much anyway. Unless while compiling, the other tasks don't really require horsepower from the computer. It's usually the disk scratching and the CPU executing some minor stuff.
Using containers it will be even less (no need for a full-blown VM there, just a cgroup). Mass scale, however, different story.
@josejfernandez @matteoscordino @proycon you shouldn’t compare a VM to a container as the simple reason for containers to exists is that VMs are too heavy weight. Also note that you can restrict container usage of hardware resources in a way to slice your physical machine into parts dedicated to run a certain (set of) containers...
@appelgriebsch @josejfernandez @proycon I'm not sure I explained well what I meant.
I'm not talking about containers being a bad thing per se, and I am aware that they're lighter than full VMs.
It's a wider consideration about the energetic cost of abstraction, plus the approach of "treat your machines as cattle, not as pets"
Of course spinning up a VM to run a script and then erasing it is more expensive than doing the same with a container.
@appelgriebsch @josejfernandez @proycon Same goes with the overhead of heavily scripted (Vs compiled) systems, where for each machine cycle that "does work" you have N cycles spent interpreting, garbage collecting, abstracting. I appreciate the saving in man/hours in terms of development (or even just learning), but it does come at an energetic cost. The fact that we can afford it doesn't make it less of a waste, just a less economically expensive one.
We don't produce any waste or directly emit any substance, it all boils down to how much power do the server consumes and how that electricity it's produced.
@josejfernandez @proycon @josejfernandez @proycon E.g. a product I've worked on has comparable functionality in an embedded device that lasts a week on a 80mAh battery and a Linux SBC that constantly burns 200mA. The difference? The former runs handcrafted bare silicon firmware and is quite inflexible, the latter has the app written in node.js and can be changed with a lot less dev time (and by JS devs that are more readily available than low level C devs)
@matteoscordino running on 100% or more renewables. The non green bit is the connectivity to the server, the ISPs etc, that's the biggest footprint and that's the same if your containerised or bare metal.
@matteoscordino I have asked Gandi.net about a CO2 metric for their cloud/VPS setup, and they said they would put it in the idea box. 😅
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.