I don’t like GC languages. Things written in them often seam to be written like they are the only thing that matter on a system. Thus don’t play well with each other in regards to memory consumption. Memory is not an all you can eat and clean up later. Yes there are environment variables you can use to enforce better behaviour, but that’s a fail. Rewrites into Rust seam to solve this, but I know reason is really that Rust is the new cool thing and programmers like rewrite things, but I’ll take the win.
Also, I don’t like static linking. It doesn’t scale. When a library has a vulnerability, it means everything needs rebuilding. It also means you have lots of duplicates of those libs at different versions. It’s a mess I hoped had died of decades ago.
Also, I don’t like languages each having their own half maintained package manager that is their language only. Just put in the work and get into root distros like Debian, Fedora, etc. Maintain a stable version you back port security fixes to. Only trustworthy packages get in. All languages under one roof.
Also, I don’t like languages that orbit an American tech monopoly.
Also, I think Go is failure and in legacy mode and largely replaced by Rust.
Basically, Go often makes me grumpy. ForgeJo is an exception. I also like a lot of what Codeberg say and do.
It triggers me with things I also didn’t like in other things of the past.
Use the container version. Why would you install it directly anyway? Forgejo is definitely the way to go. When Fedora Project announced they were moving to it, that legitimized it for me. You know it will receive support for a while with them using it.
It’s so easy, why bother? But I have each service in a separate small Debian VM to avoid conflicts. This avoids conflicts, enforces limits, and gives kernel separation. The real kernel isn’t running anything public.
Containers are often used as a way to not have to keep things up to date, or install properly. Don’t have to be, but often are. Also, not have a separate kernel means you aren’t protected from things like the recent exploits when you allow things uploaded to run. Maintaining Debian Stable is easy really. Love me some Debian. 😀
ForgeJo is pretty nice.
I mean it’s Go and not package managed properly in distros, but as a services to run it’s nice.
What’s wrong with Go?
I don’t like GC languages. Things written in them often seam to be written like they are the only thing that matter on a system. Thus don’t play well with each other in regards to memory consumption. Memory is not an all you can eat and clean up later. Yes there are environment variables you can use to enforce better behaviour, but that’s a fail. Rewrites into Rust seam to solve this, but I know reason is really that Rust is the new cool thing and programmers like rewrite things, but I’ll take the win.
Also, I don’t like static linking. It doesn’t scale. When a library has a vulnerability, it means everything needs rebuilding. It also means you have lots of duplicates of those libs at different versions. It’s a mess I hoped had died of decades ago.
Also, I don’t like languages each having their own half maintained package manager that is their language only. Just put in the work and get into root distros like Debian, Fedora, etc. Maintain a stable version you back port security fixes to. Only trustworthy packages get in. All languages under one roof.
Also, I don’t like languages that orbit an American tech monopoly.
Also, I think Go is failure and in legacy mode and largely replaced by Rust.
Basically, Go often makes me grumpy. ForgeJo is an exception. I also like a lot of what Codeberg say and do.
It triggers me with things I also didn’t like in other things of the past.
Use the container version. Why would you install it directly anyway? Forgejo is definitely the way to go. When Fedora Project announced they were moving to it, that legitimized it for me. You know it will receive support for a while with them using it.
It’s so easy, why bother? But I have each service in a separate small Debian VM to avoid conflicts. This avoids conflicts, enforces limits, and gives kernel separation. The real kernel isn’t running anything public.
Because of all the other reasons containers are great. Mainly, avoiding maintaining a fleet of VMs…
Containers are often used as a way to not have to keep things up to date, or install properly. Don’t have to be, but often are. Also, not have a separate kernel means you aren’t protected from things like the recent exploits when you allow things uploaded to run. Maintaining Debian Stable is easy really. Love me some Debian. 😀
That’s misusing containers. You do you.