> - .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM?
I don't see a reason to ever pass them. Sensitive production values should never be accessible to everyone, and for development the team should be able to create them themselves.
I usually keep very stupid values in .env.example, with the instructions to `cp .env.example .env`. In development it doesn't matter if the password is "password". In production the privileged admin sets up actual values.
> - non-sensitive environment variables also need a home. I don't like the idea of cluttering the project with a .env.local or worse like .env.development.local
`cp .env.example .env` and the application uses .env just like in production, only with dummy values.
I see this a lot, and I think it's sort of naive. Nature itself is doomed due to the way the universe works. It's also far more brutal and arbitrary than we could imagine being. The only way to even have a chance at avoiding the doom that "nature" is facing is for something to evolve that can manipulate and forestall this inevitability.
I don't know if humanity is what can do that, and likely nobody knows. But nature is not going to survive either once you broaden the time horizon a bit.
I don't really understand what point you're trying to make. Yes the planet is doomed sooner or later. But I'm talking about nature as in trees, animals, etc. The natural eco-system. And it existed and evolved and adapted naturally long before humans and will continue long after we're gone.
In philosophy there is a debate regarding the meaning of the word nature and if humans should be considered a part of it, and I see the points, but that's a different discussion.
My point is the whole "nature existed and will continue to exist" thing is honestly trite. Nature created us, we're just another output in the universal system. There's no real point behind the whole statement that nature will exist without us, and it contributes nothing to any discussion besides unnecessary smugness.
Of course there's reason to discuss if endless parking lots and industrial complexes are necessary. Claiming they're part of nature is like claiming HIV is a natural part of the human body. It exists yes but maybe we're better off without it?
I see humanity as it exists today as a cancer on the planet and it's not out of smugness. The pursuit of infinite growth is ruining everything that's beautiful around us.
We can discuss the semantics of the word nature all you want but it is just shifting the focus from the actual problem, which is how we destroy everything we touch. Which is also what I'm assuming GP means.
It's the takeaway from the story in OP and the poem with the same title, so I'd say it's very much on-topic. Your only contribution is "acktually, humans are nature too and once the universe collapses everything is doomed" and shut down any other discussion as "silly".
As long as "it" happens before we poison or otherwise harm our planet beyond some "tipping point" after which Earth becomes "inhospitable" to most/all "complex" life in general.
The world has been much more inhospitable than it is today and I'm sure it will recover. The problem I see with us is how we destroy everything in our path on an industrial scale. As long as the wheels keep spinning we extract everything we can, see water use for data centers as the latest example.
Other species co-exist in the eco-system, we destroy it.
I'm not OP but probably the licensing drama. Gitea is now open core if I remember correctly. Some details are available here[1]. I also used to run Gitea, but I don't any more. The open-source churn is getting tedious and difficult to keep up with.
I'm a project lead of Gitea, and former elected board member of Codeberg. Gitea remains opensource (feel free to check out the repo and you can see that the license remiains as is), and maintains yearly community elections. The codeberg board was informed a full year prior to their "we just found out blog post", and so "catching the whole community by surprise" is very much not accurate since they very much knew. As well, we (the company) were very public with our activities prior to our blog post announcing things, including working to support other open source projects migrate, and posting about it through various channels (social media, chat, etc..).
How portable do you need it to be? I use pass[1] and it is good. Just a shell script wrapper to gpg and the passwords are encrypted files you can backup and sync anyway you want.
Another vote for pass. I've been using it for ten years with a git repository. I sync to all my machines and use https://github.com/agrahn/Android-Password-Store on Android. Not a solution for non-technical people though...
There are more secure alternatives. Are you sure those you listed actually use it on the servers? I would guess that at least Spotify and Netflix uses some other container runtime than Docker on their production servers.
For a long time Docker was helpful and opened exposed ports on the firewall. So you wanted to access your redis ports locally and exposed it on the container? Now everything in there is accessible on the open internet.
I believe they've fixed it but I haven't used Docker in years so I wouldn't know.
I don't see a reason to ever pass them. Sensitive production values should never be accessible to everyone, and for development the team should be able to create them themselves.
I usually keep very stupid values in .env.example, with the instructions to `cp .env.example .env`. In development it doesn't matter if the password is "password". In production the privileged admin sets up actual values.
> - non-sensitive environment variables also need a home. I don't like the idea of cluttering the project with a .env.local or worse like .env.development.local
`cp .env.example .env` and the application uses .env just like in production, only with dummy values.