The Week in Green Software: Automating the Software Carbon Index

This Week in Green Software brings a conversation with Arne Tarara, CEO of Green Coding Berlin. Join host Chris Adams as they discuss the new programming language Mojo and its efficiency, as well as other news from the world of sustainable software development. Together they share their thoughts on progress in Grid Forecasting in order to reduce high-carbon electricity use, in particular a new announcement made by Apple in this field. Finally, Arne and Chris share what’s on their wishlist for green software in this latest episode of TWiGS.

TRANSCRIPT BELOW:

Arne Tarara: You can also say, "why don't you use C?" Right? This would be the direct response to people. And then there's always people saying, "yeah, but Python developers are easier to get. The development speed is so much faster. So obviously you have a time to product, but you also have a time to fix." Like, software sustainability is not only about green stuff, it's also about maintainability.

Chris Adams: Hello, and welcome to Environment Variables, brought to you by the Green Software Foundation. On our show, you can expect candid conversations with top experts in their field who have a passion for how to reduce the greenhouse gas emissions of software. I'm your host, Chris Adams. 

Hello, and welcome to This Week in Green Software, where we bring you the latest news and updates from the world of sustainable software development. I'm your host, Chris Adams. In this episode, we're going to talk about working out the carbon footprint of any open source project on GitHub, myths around decarbonizing cloud platforms, and how to make your code 68, 000 times more efficient with one weird trick. But before we dive in, let me introduce my guest for this episode of This Week in Green Software. With us today, around the corner, we have Arne Tarara. Hey, Arne.

Arne Tarara: Hey, Chris. Yeah. Hi, I'm Arne Tarara. Uh, I'm the CEO at Green Coding Berlin, and I'm super excited to be on the show. Some regular listeners might've heard the name before, very often in a slightly, I would say more humoristic sense, because the name is more expressive than it is creative and I heard Asim lately making a pun about it, but in all fairness, he was not the first.

But on the flip side, the name says exactly what we're doing on a daily basis. Like we are a very small team. We have four people of senior engineers that work on open source tools that allow companies and engineers to measure and quantify carbon and energy costs of software. I think our most relevant software, the Green Metrics Tool, we will talk about later, but apart from that, to give a bit more insight, what we're doing is we consult companies and also work in government initiatives like, for instance, the Germany's Blue Angel Certification for Software, which I think was also slightly mentioned in the last episode, and with software open source communities like, for instance, Wagtail, that I know Chris, you're also involved with, and advancing the software industry as a whole through the open source tools and research that we're doing.

Chris Adams: Cool. Thanks for joining us. Arne, just before we dive into the world of technology, how was your weekend anyway? 

Arne Tarara: We have the luck currently in Berlin, as you probably also know, that it's very sunny. We just... We had this very rainy phase before, and so my partner and I ventured out into the Tempelhofer Feld, which is this super big area. I have to make a guess, but I would say it's something like one or two square kilometers at least.

It's really big, so you can sometimes not really see the end of the other side, because there might even be some mist, or I don't know what's going on. And there was this kite festival, so there was this advertisement in the newspaper about it, and I was directly hooked. You get these 50 meter long kites.

It's, well, something like a bear or something like a, um, I actually don't know what this animal is called in English, but we call it a rochen, I think a stingray is the English term. So it's like super cool looking, like you look up and 50 percent of your view field is full of this kite. It was really nice and obviously lots of beer, as usual in Germany, and lots of food.

So it was very nice venturing out, slight sunburn was, I had to take in, but apart from that, super nice weekend.

Chris Adams: Cool. Good stuff. Nice to hear. Okay. If you are new to this podcast, what we typically do is we just run through some stories that we've been collecting over the week and we share some of the kind of takes and reckons on this. What we also do is any links or any stories or things we discuss, we share in the show notes for the podcasts that are going to be available on podcast.greensoftware.foundation. So that's the plan. And I should, just before we go, I should also introduce myself. Sorry. My name is Chris Adams. I am the executive director of the Green Web Foundation, a nonprofit working towards an entirely fossil free internet by 2030. And I'm also one of the chairs of the Policy Working Group. Okay, Anne, are you sitting comfortably?

Arne Tarara: Perfect. I'm ready to go.

Chris Adams: In that case, let's begin. Okay, let's look at the first story. The first story we have here is actually the reference for this 68, 000 times faster, uh, trick. Uh, this is about the new programming language called Mojo, which has been addressed, has been published, and is largely, as I understand it, it's like a really, it's like a, a fork, uh, of a much faster fork of Python. So per- Python might been one of the slower languages. There are some clever things that this language does to make it much faster. And Arne, I I know that you're a bit of a Python coder. I figured if there's anything I, I was, when you read about this story, what kind of springs to mind, maybe you could share a little bit or share a few reckons on this one.

Arne Tarara: Mm-hmm.

Yeah, sure. You sent me the headlines before, so I can at least have a quick look into it. And I was also directly surprised 68, times, never seen this before. I think the general term is every... In German, we have this saying, "every statistic is infation." But I hope everybody gets what I mean by that. So a benchmark always only works with the boundary conditions you give it and obviously everybody gets a different result. Nevertheless, what you hear very often if you're in this field for a bit of time is this one study from the Portuguese people who made this Energy Efficiency across Programming Languages, and C was the baseline, which is very often said it's, it's the fastest language because it's also so simple and so near to the OS itself.

And then Python clocked in, I think at 75 times, um, worse than, the task that they gave to C. It's always a bit biased. It was only compute, like no network I/O or nothing. But again, coming back to the topic here in particular, 68, 000 times, was even a bit surprising to me, like, where do they leverage all this performance, and it's actually a three part blog series, and if you, I think it's in the second blog post where they highlight what they have actually been doing, it's like the lift up they get from using just Mojo is something like in the, in the 80 times or 90 times.

So it's not that super different, at least from this initial Portuguese paper. And then they leverage functionalities that you typically can't use in, in Python directly. So they use these vector instructions. Some people you know them as, um, uh, as SSE or I think MMX was also a vector instruction at the time and the.

Yeah, we're still in the 486 processors, so way, way back, uh, but it's basically the same, um, structured set. So you have, you have a broader register set, you can do multiple calculations at the same time and they're getting bigger and bigger over time. So then they feed it in there and then I think they get something like a couple of hundreds and then they parallelize it.

So we just, in the end, the trick, so they use an 88 core processor or 88 thread processor. And then they get 88 times the boost out of it and at some point you arrive, I think over 10 iterations or so, they then arrived at the 68, 000 

Chris Adams: This incredibly large number.

So for people who are Python programmers, this, and you're, and you think about the efficiency of the code that you're using, it's both. You can think of this as like Python plus, and, uh, this isn't open source yet, although the organization and one of the people who's really pushing this does have a track record of open sourcing tools.

So the people who worked on the Swift language have also been working on this part here. And as I understand it, the general idea is to make it as. Essentially take some Python code and do a lot of clever stuff at the compiler level. So as a programmer, you don't necessarily need to do loads and loads of really, know too much about the internals of, of a program.

You let the compiler do a bunch of really clever stuff, which ends up speeding up things impressively. Whether this is, this is also something in my view, there is a bit gimmicky in that sense that this is the only programming, programming language or piece of software I've ever seen where instead of having like .py or .js, they have a fire emoji as the way to actually identify some code. And I'm not sure if there really is a kind of actual more human readable version of this as well, or easier to type kind of extension, but that kind of gives you. It, it, it seemed interesting enough to share with other people and whether some of these ideas will make it into Python mainstream, we, it'll be really interesting because Python for the longest time has been maligned as a very slow language. It does give this idea that, yeah, if you make changes at the kind of compiler level, maybe we don't all need to become green software specialists to actually realize some kind of meaningful reductions in the actual energy usage of the stuff we're using.

Arne Tarara: Yeah, I'm totally on board with this one and I think it's also one of the more interesting and fancy news to share first because it has this major full mouthed promise that you bring with it. Python, the, what I think I can also bring to the table here in terms of discussion because I had it so often is, you can also say, "why don't you use C?" Right?

This would the direct response to people. And then there's always people saying, yeah, but Python developers are easier to get. The development speed is so much faster. So obviously you have a time to product, but you also have a time to fix like software. Sustainability is not only about green stuff, it's also about maintainability.

And I think we'll come later into the podcast to this topic because this is one of our research field. It's like software lifecycle. Looking at the software lifecycle in particular, you can only really save Python or C is better for you as a company if you also know. How much does the development cost you in terms of touching code again, in terms of getting developers, et cetera, 

also in cost of runtime.

And I think we'll bring up the notes in there. When we talk about it, but one, maybe what I have here, because you said it's not open source, what I've seen lately, it was on a German news blog, I will put the German link in here, 

is something that is basically, I would say the underlying part of it, like the optimizations that are applied in Mojo are automatic.

But if you want to know where your code is slow and what you can do on a programmer level to also advance yourself as a programmer, there is this, I think it's from the MIT, it's like an open source thing that scans your code in Python and gives you the recommendations that you need to do, which means be offloading to the graphics card or to CUDA, or which would be touching code that is really badly written or is just worse in Python. 

Chris Adams: Maybe this will be a thing that shows up in Copilot or various code rewriting tools that seem be making up into people's different environments for writing applications these days. All right, thanks for that, Arne. Should we look at the next story that we have here?

Arne Tarara: Sure.

Chris Adams: Okay. So this one is, uh, from Scaleway, which is one of the larger French, uh, cloud hosting firms. They have, they have a four-part series specifically about how engineers can make IT more sustainable. And there's a couple of really, in my view, quite interesting tidbits that come out of this based on how they've seen people using their own infrastructure. Arne, was there anything that jumped out at you when you were looking at this stuff in particular?

Arne Tarara: Yeah, actually, I have been following the Scaleway series for a while because, um, as a CEO of a green coding company, I have the most full fledged thing you can do. I have a Google alert that alerts me about new green coding topics. So this one comes up often, like Scaleway is doing actually some PR work in the sector and, um, from what I know from the outside, they seem to be, yeah, very authentic about what they are doing in terms of the data center.

And yeah, they have these series in order to highlight new tips to developers, what should be looked at, or what are typically best practices, et cetera. And what they have been talking about is a study from Google in this latest post where they say that Google with their cloud product assumes, I have to look it up in the article, but it was something like 60, 60 gigatons, 60 megatons of CO2, which just is happening from machines that are idling or storage that is not even read or written to for a while.

And Google is actively, sorry, is actively talking to these customers through There's also something like a notification in the interface that says, "Hey, you have to stale services. They also incur costs, but more problematic for, for us as a whole is they also occur a lot of carbon. Do you still need them?"

Which is obviously a nice story to tell from Google because they're slightly cutting to their own flesh because obviously for storage, they also get money, but their concern seems to be bigger and they're going for the green route. And these numbers are so large very often, right? Like if you, if you look at some tools and they, then you have this milliwatts or something that you're looking at and somebody talks about tonnes of carbon, um, yeah, it directly, I also find it directly interesting. But on the flip side, what we have been looking at into a research project, was leveraging the YouTube API and basically looking at all the videos that nobody's 

Chris Adams: Oh, 

Arne Tarara: because there is, I would say there is more in terms of dead storage, so to say, that nobody's accessing, but it might be the case that somebody accesses it at any time and then Google can, like putting the bad complaining hat on here, then Google can still play out an advertisement.

So maybe this is why they don't clear. And isn't that actually a proverb om English? Like, "sweeping in your own front yard."

Chris Adams: Sweeping your own front yard is, I think there is, we have that content with that, that, that concept. I'm not familiar with the term. Can I just check with you? So one of the things you've mentioned is this thing that Google is doing, which essentially sounds like the cloud version of basically telling people, "hey, you left your lights on when you left, when you left the office today."

So they're telling people that they're leaving things on and that you may be, you know, "do you really need that light to be on?" Essentially. That's one thing they're doing here. And there's this other part, which is that you folks have been looking at which videos are on YouTube, are getting the, getting the views. Is that what you're referring to just then, Arne?

Arne Tarara: The idea was to, um, we never actually executed the research project, so the idea was to query the YouTube API for videos that have, have been uploaded a year ago, but have two views or so, then kind of get an estimation of how many dead videos might there be on YouTube, and then through some papers that have these calculation formulas, like how much that storage costs, which is somewhere on a hard disk or on a tape or whatever, and then just make an estimation how bad it is and make an article about it.

Yes, something like this. There are different variants you can go, but I think this is the gist.

Chris Adams: Ah, do you know what? That's a very, you've raised a good point about what you do with very infrequently accessed information, and what, how that should be stored. We'll come back to that a little bit later, because there are some guidelines around moving, this is actually one thing that I saw in the Scaleway piece, was basically this idea that if you've got storage, there are ways that you can store it in a way which is going to match it to how often you think something's going to be used.

So if you store something in RAM, for example, really easy to get, but, or if you store something in say object storage, you can put something in a colder form of storage. That's where you might not access it quite so quickly, but it's going to be a lot cheaper and you can go all the way down to storing things on tape, which basically doesn't even need running power at all in many.

So yeah, there are some ideas like that. Okay, cool. Should we look at the next, the next story we had here actually, Arne?

So 

Arne Tarara: Yeah, absolutely. So I think you still mean in the Scaleway article, right? Because it has very many bullet points.

Chris Adams: yeah.

Arne Tarara: The second one that I found most interesting is they talk about this software life cycle and how this is a topic of concern and soon coming because they are a EU company and we have this corporate sustainability reporting 

directive. 

Chris Adams: CSRD, the

Corporate Sustainability Reporting Directive that lands at the end of 2024.

Arne Tarara: Yeah. So, so they are talking about this because as a data center, they are, I think in two ways affected, like they are affected directly and also as a supplier because they host their services for so many companies in there. As I said, this is a, an upcoming thing. So methods will be standardized, how you even look at this stuff, but also software lifecycle will become a different view, I would say, as a developer.

So you not only can say, "I'm looking at what is my software using in the runtime phase." But also if you are a container provider like they for instance are, there is something like a boot phase or there's something like an installation phase if you want to make up phases that are specifically for software.

But if you go through the classic means of a lifecycle assessment, you have something like a removal phase 

what does it cost you to remove stuff from caches? You have something like a development phase. So how much does it cost you to develop the software and also to test the software? So how much do the pipelines cost?

And I found it super interesting that this is now, and this is all pushed forward by one of the bigger data centers because there's so much entailed with the work that we do, for instance, like if you, we mentioned the green or I mentioned the Green Metrics Tool earlier, which is, say our flagship product. This is, in essence, I would say a benchmarking software that has this lifecycle approach integrated because you have to provide it with infrastructure and code, so something like a Docker Compose file for instance, and then it will spin up the containers, it will install all the packages that are in the Docker files or whatever you have, and then it will coin this as the, as the boot phase when the container started, and before that when the containers are created on the system with all the downloading, it will coin it as the installation phase. And even before that, it will also have an idling phase, so it will also tell you what your system is doing, if nothing is happening in particular. Then you go through the classic runtime. So the software is run against whatever it has to do, so if it's a number crunching then it will do that, but if you have a more elaborate scenario, let's say you have something that also GreenFrame uses, which I think was also mentioned on the podcast before, so something like an end-to-end test.

So you have a Selenium test where you instruct the browser, go to this page, click here, upload a form, query an API, behave like a user, so to say. So this is then the runtime, and then later on everything's removed, which is mostly clearing databases and removing caches. And this is the small window that you typically come across when you interface with the software, uh, and when you run the software.

And in order to also give a holistic view for developers and enterprises, then you need something like our pipeline tools. Like we have tools that you can

plug into GitHub and GitLab, and then you see what your pipeline costs on GitHub, for instance, in terms of carbon and CO2. And for development tool, I hope we have something to share soon because this is still internal R&D.

It will be something like a small tool that you have in your top taskbar and it will always scan all the processes you have running on the system and then match them to the software you're currently developing. So every time you change your GitHub repository on the command line, it will attribute it to a different project that you're developing on.

All the auxiliary products will be split on and I think there will be a lot of discussion coming up because the question for me that I have for you is: when you are coding, would you say your Spotify that is running should be attributed to the software development cost or is it something that you should cater for privately, right?

Although Spotify might help you concentrating, this is a discussion to be had, I think, but I think the interesting part is, I haven't seen any tool out there that does something like this, that works alongside a developer on its own machine, maps it to the project, and then integrates it with a bigger picture of the pipeline, runtime, installation, etc. to give a full picture of the software.

Chris Adams: So this thing here of expanding what people talk about when they measure it to look at the life cycle at the beginning and the end. This is actually... I think this actually may be one of the next kind of frontiers of what we have, because when a lot of the time people are talking about, there is this kind of risk, kind of received wisdom that it makes a lot of sense to use serverless tools because you switch things off all the time, you're only paying for the actual requests you're using. And this is kind of this idea that that's going to be clearly the greenest way to think about this. Obviously, there's going to be an impact associated with keeping caches warm so you can serve responses and everything like that. Just like you said. I think. This is interesting, I'm looking forward to seeing some of this come out the door, actually, because the example you mentioned of, does the music you're listening to, does that count when you're writing some software, the only organization I can think of that's been including anything like that so far, is Mozilla, when they started trying to work out the environmental impact of the Firefox browser itself, where 98 percent of the environmental impact of their, of their reported organizational footprint was associated with the end-users. And for that, they basically looked at the entire computer being used. So rather than actually splitting up to say, here's just Firefox's part, they looked at the entire machine thinking, well, you need an entire computer to be using this. So that's how we're going to report that. And whether they're going to do that going forward is another matter, because if you have a way to cut down the biggest chunk by a significant amount, I can totally see a lot of effort and a lot of temptation to do that, especially when other organizations aren't currently reporting that, for example. So yeah, thanks for the thought provoking point, actually, there, Arne. Okay, shall we have a look at one of the next stories that came

Arne Tarara: Sure, uh, do you wanna, do you wanna go through and then I chip in, 

Chris Adams: Yeah. Yeah. Okay, Arne, next story. This one is from Apple. They made a big splashy release last week about A, unveiling their first carbon neutral Apple watch, but also they've done some work to start mainstreaming grid forecasting. Have you, did you get a chance to look at any of this stuff? Cause I think this is really interesting seeing such a large company really try to start talking about this, especially when an organization is based in the home, but also to have it run through the entire system. I want to see how you thought about some of this because Apple has generally been quite a leader on a bunch of this stuff, but I know there's been some pushback in a number of sustainability circles talking about the idea of branding a piece of electronics as carbon neutral these days.

Arne Tarara: Yeah, I mean, I got the article actually from a co-worker who is a big Apple fanboy, if you want to put it like so, but saying that, I also use myself a Mac because I just think it's the best machine for me. And I was actually pretty happy about the news statement, I looked into the official Apple statement directly, so what they had in their newsroom, and although I don't use an Apple Watch, I think all the moves they had made total sense, like they switched the armband, which was leather, for something which is way more sustainable but also carbon neutral to produce in the end. I think they cut down on the cost for making the casing and then on top of that the whole story spun around the the Apple Watch, as I read it, at least, on top of that they introduced this functionality that you can actually look when is the best time to charge all your other electronic devices.

So you have it basically in arm's reach to save carbon, so to say. And I found this pretty cool because also the GSF had this hackathon, I think in 2022, if I'm not mistaken, to also use the open source SDK in order to, in order to get the grid intensity and write an application around it. And I found it very lacking that in my operating system, I don't know, for instance, when to plug in the laptop or when compute intensive task.

So we handed in at the time a small tool where you, whenever you run an intensive task, it will give you an info that this resource is currently blocked, like a network, for instance, and you can unblock it if you're on a green carbon or not. And I think this gives a very strong intention to people and drives this whole topic forward.

The downside that I've read, because you mentioned some people give pushbacks on this, is that obviously you can make the argument that Apple, as a big company with so many money reserves, can do so much more, and they focus on this small Apple Watch. But if you, I think the podcast is also about opinions and if you ask my opinion, I think it's a really cool way to do it.

They probably can do more, but it's still the best that I've seen lately from a big company because I know how slow enterprises can be and how heavy it is to push such a project. So, yeah, for me, it's a positive news, I have to say.

Chris Adams: Okay, cool. Thank you for this. All right. So we've shared a couple of links to both, uh, the wide story about why this won't be carbon neutral, as well as why this is considered carbon neutral, as well as talking about some of the most recent things they've done about essentially exposing the grid intensity or, um, in America to pins.

So, so you can basically make somewhat more informed decisions about when and how you use various kinds of electronics. Okay. All right. I'm going to come for one story, which is actually. This is something that, this is the culmination of some work with the Google Summer of Code. This is from Wagtail. So there's a story about Wagtail 5.1 gets greener and leaner. This one here is, this is basically a follow on from a project that, um, we did where we work. We did a works with a open source project called Wagtail. It's a very, it's a quite well known piece of software that's used on the NASA website, on Google's blog, on Mozilla's website, for example. And, um, we basically had a early career technologist work to include AVIF encoding into the actual platform. Because when Wagtail looked at all of their, the emissions associated with the work that they're doing, from the software point of view, the images was the biggest thing for them to work on. And this got merged into the project. And I figure this might be one that is, might be worth talking about because I know that we were using, uh, the sustainable web design methodology to work this out, but there's some other work we're doing now for trying to understand the environmental impact of the project at various other places. And the other being is if you work on a high profile Python project here, then you've got a kind of reference, reference for other projects to follow on from here. So Arne, anything catches your eye or any reckons that you're in for this one here? Because. We did start looking at some of the code that you had and we were using, we were looking at a Green Metrics Tool to come up with some green metrics with a tool,

Arne Tarara: Yeah, true to the name, so to say. Yeah, I'm actually super excited about the project. Can you, can you actually tell me right away, because I think this is also the most interesting for the listeners, in which version will it be integrated?

Chris Adams: It's already out, so we started in summer, uh, uh, we got the first part finished and merged in. And, uh, then it was released, I think in, I think it was in the middle of August is when it came out actually. So the release date for this was 1st of August. So the project started in, I think, midway through June and, uh, then yeah, it got, it was merged in time to make it to the release, uh, and then came out in the 1st of August. There's a bunch of other part on there, and if you look at the Wagtail sustainability kind of section in the docs, it's really good and it has a bunch of really useful guidance. And there's also a roadmap of new things uh, following on from this, like different places you can scale down the project with the idea being that if you got something here, then it can be adopted by other similar projects who are trying to adopt this 'cause you do see, you, you do start to see some open source projects trying to optimize for this. Like WordPress is an example of doing things in this field as well now.

Arne Tarara: Yeah, I think I see it here now, because my question was mostly related to the version number of the Wagtail, and I think 5.1, 

Chris Adams: That's correct. 

Arne Tarara: it, yeah, sorry, I did overlook it first, but now I see it, because you pinged us, like, a year ago or so, and we had this mini project with Thibaud, which is one of the main maintainers of Wagtail, by creating something like a, Wagtail comes along with these super nice bakeries, so it has like a reference implementation. We were super interested to look at it with the Green Metrics Tool to just see, "okay, how much does a typical visit to a Wagtail site cost?" And then Thibaud implemented all these pages, a contact page, he implemented a caching system. 

You could go to a list page and whatever page types Wagtail has. But I think our project is still on the 4. branch, so we have to update that in order to look at the whole AVIF thing, because the interesting point that I see here, and I think this is also what, what I think Wagtail wanted to do in particular, is to estimate also the net gains of it, because 

Chris Adams: AVIF 

Arne Tarara: is obviously better, this is why it was developed, and it's also way newer than JPEG, right?

So in all fairness, it's just a newer standard, so chances are high that it can be more efficient. But the question is, "at what cost does this come along?" Because AVIF is a stronger compression, it needs more CPU, it might need more memory to do it, but on the, on the gain side, you then save the network transfer, but is it really worth the cost implementing that?

Chris Adams: This is exactly the thing. Yeah.

Arne Tarara: Yeah, and we had this software lifecycle topic before. I think this touches all in the same domain. You have to broaden your picture as wide as you can in order to make the boundary there where the optimizations or losses that you are creating through the, um, code that you write are not outside of this boundary and you create a false closed picture of it.

Um, this is actually super interesting and we really have to update our code so let me write it right now and then I'll write Thibaud an email right after the call if we can get this pushed to the 5.1 branch and then make the measurements available as soon as we can, because we have this in so many other places.

Have you, for instance, read the article on the Green Software article blog recently about a super cool product from Cast? I hope I pronounced it correctly. They are a member of the Green Software Foundation and they have developed basically a tool that can look at a code repository, look at a running piece of code also, it's like an agent you can plug into.

At least that's how I understood it. So there might be small bits and pieces that I didn't get correct. But the end result is you get a dashboard with so many green coding optimizations that you can do. 

Chris Adams: Hmm. 

Arne Tarara: there's also another project, I think it's called EcoCode, which is Python, JavaScript, supports a couple of languages and taps into SonarQube, like this many enterprises I see use it, typical static code analyzer.

But the question that I have always, when I use these tools is, "how much costs do these tools need in order for the optimizations that they give you?" We also contacted Cast about it and we had a video call and we pitched them a joint research project about it and yeah, this is still, this contact is still in the works if that is going to happen or not, but I think this is a very interesting thing to get all these recommendations and then you can do 50 recommendations on it.

You have to sync in 20 developer hours, your product gets 1. 0.1 percent better. But SonarQube used, I don't know, five, five kilowatts of energy. Too much, obviously, now, but a tough question to ask because sometimes the optimizations might not even worth taking you don't save anything in the long run, right?

This is why I'm super interested in the AVIF case because I think this will be a net gain and it's even better if you can underlie it with some hard numbers.

Chris Adams: This is exactly the reason, this is actually where the next step for some of this is to, after doing this work, there were some trade offs associated with this, and we'll share a link to some of the issues where we explore some of this. One of the key things is that, okay, we might have made this part a bit more efficient. But have we just shifted all the work onto an end-user's device, and are we making them do the work for this now? This is, this really speaks to this idea of, okay, where in the boundary does this actually take place? Cause if you assume that you have some responsibility, then you do have it, but you can end up with a scenario where just by making your thing super efficient, you just push all the load onto someone else's kind of balance sheet, as it were. This is some of the problems when we think about carbon accounting that we need to kind of address, especially in the kind of digital realm, because yeah, how you design a system can very much change whose computers are doing all the hard work to actually make an experience possible. But yeah, I'll happily share the links for that because there's a bunch of stuff. I don't know of many other projects that are in the open that are doing this right now, and it wouldn't be that difficult to actually get the numbers out because there's actually decent data set available for that already. Okay. All right then. I think we're coming up to time. So maybe we'll just do a quick run through of some of the events that are coming up. And then Arne, I think, um, we might have just one, one, one little question and then we might wrap up actually. So the Green Software Foundation runs a series of meetups as well as having events in the future. And in the last month, we've seen a new number of new meetup groups open up. There's one in Karlsruhe, Germany. Arne, can you tell me what the deal with Karlsruhe is? Because I see it showing up in a few places and I've never been there. And I'm a little unclear cause I, I used to know of it as like, uh, old and previously industrial area. Is there like a science area behind it? Or is it like a tech, a real tech sector in the country?

Arne Tarara: Yeah, I actually can't tell you how it came to be. Karlsruhe is really... I know Aydin as a friend who is, who's running this meetup over there and he has a big software company where they develop software for other people. And he told me that the, how do you say, like the industry share of IT in Karlsruhe is above 50%.

I think I have 60 in my head, it might slightly more or less, which is crazy. 

Chris Adams: So half companies are tech companies in this one city.

Arne Tarara: Yeah, and this also entails the money that flows into the city in particular through taxes and stuff. So IT is a big topic over there and they have something like the CyberForum, which is I think even Germany wide known, how do you say, group of people who are in something like a industry, yeah, I don't want to put a name on this one in particular, but the CyberForum is very big. So if you advertise something there, you reach a lot of people that also work for big enterprises and there's a lot of IT stuff going on there, which might be under the radar when people always hype Berlin or something as a hotspot for developers.

So it's a big area and he has very good topics on the meetup groups. I think there's even something out with the Cloud Native Sustainability Week. I think you also wanted to touch on that, right?

Chris Adams: Yeah, we'll touch on that. Okay. So there's, okay. Thanks for the kind of minor geography lesson there. Thank you, Arne. So we have, um, new meetup groups being opening up in Scotland, in Brighton, in Oslo, Norway, and Belfast, Ireland. So if you're in any of those countries or cities, that might be something for you. And the other thing you did mention, Arne, is this Cloud Native Sustainability Week. So the second week of October, we'll share a link to this, there's a series of events all through that, like really chock full of events for people who have an interest inside this. And then finally, on the 16th of November, there is the big event from the Green Software Foundation called Decarb. So if you go to decarb.greensoftware.foundation you can learn a little bit more about that event taking place there with a bunch of speakers. And if you have something that you want to share to an audience, the CFP is still open. That's what we have going on there. Arne, I've really enjoyed nerding out with you and a bunch of this stuff. We normally have a kind of little wrap up question towards the end. And I'll just share it with you to give us a nice kind of wrap up for this. So do you have a green tech wishlist? And if so, what's at the top of it for you these days?

Arne Tarara: Yeah, so my, we touched about this Apple topic before and I think I mentioned that I would really like to have the possibility in my operating system to directly see if any code that I can run now will be greener or less green because of the grid and everything that is entailed to it. So this would be something that I would really like to see Apple also integrate into macOS and also be super reliant on the data that I get.

But on the other side, we are working in an R&D company and we typically, as a team, develop the tools that we really want to have, so in a very beneficial position that we can usually 

Chris Adams: scratch your own itches basically here.

Arne Tarara: so it's very often happening that at least we can do a prototype if we think a topic is interesting, but I think when I talk, look at enterprises and stuff like this, the easiest thing to do and which is very easy in reach is like combining the grid and the operating system to give developers the empowerment to choose at least on that.

Chris Adams: Alright, okay, so you said something interesting there. Right now, with cloud computing, I can do this really easily, right? Not really easily. It's doable, where you can get a, uh, hour by hour figure of the carbon intensity of the power you're using, so you can work out the average carbon intensity of an application or something, right? But I can't do that with my own laptop. I can't do that with my home. And I feel that, in the same way that you... If we're going to be doing, if we're going to talk, talk about how green the energy is, and we've, we've accepted that the energy will be greener at certain times of day, and less green at other times of day, then I don't know of any organizations that currently give me a figure of showing this was the average carbon intensity of the power you've used last month, or even every day. I would love that to exist, and I'm pretty sure that can be buildable, but I haven't seen it being done at a kind of personal or house level. That's my kind of wish list for someone to make, because it's totally buildable, but it doesn't exist yet, and I don't have the time to build it myself.

Alright! Right. We could, it's a doable thing. 

Arne Tarara: totally know what you mean. I know you come initially from the UK and then just did you know that Octopus, which is I think UK based initially, and they already have that because the grid in the UK is so much more smart than the German one is, that they just came to Germany also. Have you had a notice of that? 

Chris Adams: I did know about that and Octopus, they, so they are, they're one of the people who do expose this. And actually I didn't think about that, but they do, they may well have APIs that can expose that. So if you're listening to this podcast and you use Octopus, please do set, or if you work for Octopus, please do tell us if this is, it can actually be exposed because I think it'd be a nice bit of nerdy fun to share with people.

Arne Tarara: Yeah, super nice.

Chris Adams: All right, Arne, thank you very much for coming onto the show and thank you for working on all the various open source tools that we've used in the organization I work in. And yeah, have a lovely week and hopefully you get to enjoy some more kite surfing and gigantic kites in the Tempelhofer Feld of Berlin.

Arne Tarara: Chris, thank you so much for the invitation and also good week to you.

Chris Adams: Cheers, Arne. Okay, bye.

Arne Tarara: Ciao.

Chris Adams: Hey everyone, thanks for listening. Just a reminder to follow Environment Variables on Apple Podcasts, Spotify, Google Podcasts, or wherever you get your podcasts.

And please, do leave a rating and review if you like what we're doing, it helps other people discover the show, and of course, we'd love to have more listeners. To find out more about the Green Software Foundation, please visit greensoftware.foundation. That's greensoftware.foundation in any browser.

Thanks again, and see you in the next episode!