pykka VS gitlab

A friend of mine recently let the domain used for documentation of Pykka, a Python actor library, expire. Some of course registered the domain, resurected the content and injected ads/spam/SEO junk.

Since the documentation is Apache License 2.0 there isn't much one can do, other than complain to the hosting about misuse of the project name/branding. But so far we haven't heard back from the hosting provider's abuse contact point (https://github.com/jodal/pykka/issues/216 if anyone is interested).

Spoken like someone who has not tried what you are describing. There are two moving parts to your response: a locally hosted runner awaits jobs from GitLab itself, which doesn't help running _locally_, and the other part is that --back when it existed! -- trying $(gitlab-runner exec) was not a full fledged implementation of the GitLab CI concepts, making it the uncanny valley of "run something locally."

However, as of v16 there is no more exec https://gitlab.com/gitlab-org/gitlab/-/issues/385235 which I guess is good and bad. Good in that it not longer sets improper expectations that it could have plausibly done anything, and bad in that now it joins GitHub Actions in not having any _local_ test strategy aside from "boot up gitlab/gitlab-ce && echo good luck"

https://gitlab.com/gitlab-org/gitlab/-/compare/v17.1.6-ee......

The merge commit with calling out environment stop actions:

https://gitlab.com/gitlab-org/gitlab/-/issues/327121 is the first one, and I'm having trouble locating up the second (possibly due to the search pollution from the first one) but there are a bunch of "Exiftool has been updated to version [0-9.]+ in order to mitigate security issues" style lines in their security releases feed so it's possible they were bitten by upstream Exiftool CVEs

Anyway, turns out that shelling out to an external binary fed with bytes from the Internet is good fun

I'm not sure I personally agree with this, and I'm not 100% sure the developer community at-large does either...

Let's take a few examples, which I've shared elsewhere in similar discussions:

- GitLab: Open Source or Open Core? Most would say Open Source, but (I assume) you would argue Open Core [0].

- Plausible: Open Source or Open Core? They say Open Source, but it's actually Open Core [1].

- Cal.com: Open Source or Open Core? They say Open Source, but once again, Open Core [2].

- Posthog: Open Source or Open Core? They say Open Source, still Open Core [3].

- Sidekiq: Open Source or Open Core? Once again: Open Core [4].

Yet, every dev I know would consider these projects Open Source. So there's a disconnect somewhere.

Under this mindset, very few open source startups are actually open source, yet everybody says they are?

I'm not trying to argue either way; I'm trying to point out a disconnect here.

[0]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/LICENS...

[1]: https://github.com/plausible/analytics/blob/2dd2f058d1dcae6f...

[2]: https://github.com/calcom/cal.com/blob/main/packages/feature...

[3]: https://github.com/PostHog/posthog/blob/master/ee/LICENSE

[4]: https://github.com/sidekiq/sidekiq/blob/main/COMM-LICENSE.tx...

The article is singling out GitHub in the title and for most of the article, only in the very last line they declare that this behavior is a common design flow and not limited to GitHub:

> Finally, while our research focused on GitHub, it’s important to note that some of these issues exist on other version control system products

For example, Gitlab only recently solved this: https://gitlab.com/gitlab-org/gitlab/-/issues/408137

Also, I don't appreciate the fearmongering. Multiple times they repeated statements like how you can "Access Private Repo Data" when it's a rather special case related to forks. They clarify that later but I found these statements repeated in that fashion, whether intentionally or not, very cheap. Especially for a tech blog, where the material itself is good and could stand on its own.

However, it's not possible to do a bulk removal or have a more sophisticated control of these branches.

Gitlab 1 2 3 4

Since the relevant code appears to be in the "ee" directory <https://gitlab.com/gitlab-org/gitlab/-/blob/v16.11.0-ee/ee/l...> and is not present in the foss repo, I'm guessing the answer is no, at least for now. They do have a history of "releasing" features from EE back to CE but my suspicion is not for LLM stuff