@Radical_EgoCom for some background...

https://www.dailymail.co.uk/news/article-8386601/George-Floyd-protester-says-cop-threatened-fire-TEAR-GAS-two-year-old-son.html

@passenger @Radical_EgoCom we are not talking about a "bad apple". There is a whole gang of pigs standing around threatening and acting as if this is somehow normal. It's institutional.

@BikeBaroness @lily this to me is the stronger aspect of the community management model of the fediverse, especially for marginalized and heavily targeted groups.

@codeberg @Edent Using git hosting to publish research results should become a normal thing.

@be @codeberg @civodul as noted it is no longer tied to github, but yes, every imported package is still tied to a specific repo path, and if an essential one goes missing...

@loziniak @codeberg @civodul @be most likely google itself ;). They had already done many similar poor decisions and roadblocks in the past...

I am hearing about people re-licensing and proprietarizing #MIT licensed code.... I suppose, like the BSD license, it permits this. But if so, it makes me not want to use it.

I am now fully amused. I had looked at the fb blacklist for mastodon @bob and @mike given the mastodon reports, I thought I would try creating an account, using an entirely valid email I still had around, my actual name, no proxy, etc. A real valid user in every way. I was immediately banned for "violating community standards" before even leaving the registration page! 🤣 Apparently they also have a double secret blacklist of "undesirables". @facebook clearly is a criminal organization.

What if I wanted to keep a private repo on @codeberg with it to become public upon death or "political captivity"?

This is now turning out to be a great year for telephony development, and switching to @codeberg seemed to have helped.

@be @civodul exactly, a really terrible idea. They have since introduced gopkg.in as a kind of redirect proxy service, that you can use to at least have a fixed path that can then use the real target path instead, but how many well known packages are offered thru that is not known outside of some of google's own core library components. In fact, most of the awful aspects of go really were google decisions.

@codeberg @be @civodul in the beginning, and for a while, they were only able to process "github.com" to git. So you couldnt use gitlab, or codeberg... so while now still lame, it used to be double lame.

@fnetX @be @civodul In any case I absolutely require vendoring when I build stand-alone release tarballs (something go tooling also doesn't itself support), because obviously no arbitrary git repo is guaranteed to remain. So yes, I have a dist target that also dumps in vendored code, and that is also what I do to cache even for local builds.

@be @codeberg @civodul This is why I always use a simple makefile in my go packages, in which I kinda emulates essential cargo behaviors, and gives me a place to specify an explicit package version and other meta information.

@be @codeberg @civodul well, after many long years of google fighting it's community, they eventually grudgingly did introduce a kind of poor modules system, in I think go 1.13 or .14, which essentially does this, but not much else.

@be @codeberg @civodul while crates have toml that specifies the version of your code, go does not. The go module system relies on git tags to specify versions of this otherwise versionless code. This goes back to google wanting everyone to always build from tip, so the version of your code wasn't an important concept in their minds.

@be @civodul yes, that is the one major downside of go. Though maybe google got a taste of their own medicine. Go uses the repository name as part of the import paths for the entire ecosystem. They could of course have hosted it on code, but they got rid of that. So they chose github. They are now very stuck there ;).

@be @civodul consider this:

import "github.com/spf13/pflag"

its a library, like a rust package. It is animated directly from git, using github. In fact, if you move it elsewhere, everyone who has imported it off this git repo would immediately become broken. The entire go ecosystem is built this way importing modules and code from direct git repo references.

@codeberg @be @civodul there are several reasons why vendoring is used. Reproducible builds, something google fought for years against, is one. They wanted everything to always use the tip of main/master at build time. Since go compiles so fast, vendoring is not much overhead. Also vendoring allows builds to happen in fully network isolated environments.

@be @civodul Indeed, this I do love. I can still set a project to edition 2015 or 2018, and still compile old code compatibly, much like C/C++ compilers where you can use -std=... Golang, by contrast, is a "latest tip" language, has frequent releases, and only supports the last 2 major versions.