OP seems to be asking for examples with an intent to dismiss and downplay each of them, and not to actually read into them and challenge his existing beliefs about X/Grok/Musk.
Open to changing my mind. I would be interested in reading positive, uplifting news about xAI/Grok/Musk that demonstrated a repeated pattern of ethical, careful, compassionate, attentive, and/or responsible business and engineering practices.
However after looking at all of these articles, these all seem like instances of users misusing the product. The product happens to reply on social media, so media publications immediately capitalized on this.
Seems less like malicious intent from xAI's part and more like a product with young and/or insufficient moderation controls.
I'm a big LXD and now Incus fan. But I went with NixOS rather than IncusOS for my latest build because I prefer the LTS linux kernel over the mainline kernel.
> the courts don’t care if the license is “as-is”.
There isn't any case law to show that. Certainly not in the age of AI. On the criminal side, the CFAA requires "intentionally causes damage" and that's entirely impossible to prove in the age of AI. On the civil side, liability waivers and warranty disclaimers generally cannot shield intentional or willful misconduct or gross negligence.
Yeah I think I've finally had enough. I need to start seriously advocating for alternatives since this is starting to impact our business. It's clearly not getting any better.
If you want a GitHub-like UI (with org/repo structure limitations) use either Forgejo or Gitea.
If you want a similar but different experience use GitLab.
If you want something more akin to the kernel experience (i.e. hosting, flexible repository structure, user auth via ssh keys, and a simple web UI) use gitolite with cgit, or alternatively gitweb.
I mean, technically it's a code review platform, not a complete toolbox like Gitlab and co, but damn if it isn't the most professional feeling experience.
I love gitea, and I use it for my homelab, but the permissions system needs a lot of work. There’s still an open bug which doesn’t let anyone but the repo owner read CI logs regardless of settings.
I used Gitea for a while, but eventually switched to gitolite+cgit. That was down to the org/repo structure not fitting my git hierarchy (I'm using a topic/repo, topic/subtopic/repo style structure) and the lack of organization/topic wide issue tracking/management.
Go ahead. We've been self-hosting Gitea with Drone/Woodpecker for years; either it or Forgejo will do fine if you're okay with their feature set. I sometimes wander into these GitHub threads to have a laugh; our Gitea instance has had several minutes of downtime combined over the last few years, all of them planned (to upgrade Gitea) and in the middle of the night.
Ooh, Woodpecker CI works with Gitea and Forgejo. https://woodpecker-ci.org/ That might be last piece I needed to migrating Git repos from GitHub to a self-hosted forge.
Edit: Actually there's Gitea Actions and Forgejo Actions, that might be enough for my use case.
I’ve found gitea actions (based on ACT, so it’s nearly identical to a GitHub action runner) to work great. Migrating a GitHub workflow is mostly just a file name change.
I struggled with Woodpecker for a bit, but now gitea has Actions that work wonderfully for my use case (and one less tool to support). I believe they also highlight compatibility with a github action protocol of sorts. Might be worth looking into.
It's close in the sense that it's also Jabbascript SPA crap that needs a supercomputer just to (try and fail to) display a diff of a few thousands lines, you mean? We're using it at work and it sucks massively.
I'd rather have the open core one running on my own servers (i.e. GitLab), but performance is a few orders of magnitude away from acceptable for both Git**b.
I run GitLab and its CI on a Xeon server from 2010. It's fine. It runs exactly as fast as anything else on that machine. I've also run it on a tiny AWS instance. Also fine.
I don't like that the idle CPU load is high (for really inane reasons) but it performs perfectly well.
Was thinking the same honestly. GH is very sticky though, especially when you have actions and all kinds of other integrations set up. But it’s just kind of absurd at this point how many outages they have.
> We have resolved a regression present when using merge queue with either squash merges or rebases. If you use merge queue in this configuration, some pull requests may have been merged incorrectly between 2026-04-23 16:05-20:43 UTC.
We had ~8 commits get entirely reverted on our default branch during this time. I've never seen a github incident quite this bad.
Similar here. Somewhat ironic that a tool that was supposed to be preventing merge conflicts was authoring completely mangled commits to our mainline branch.
I've tried using policy tests but as far as I remember you can't test access to specific hostnames, only tags. I know Tailscale ACLs operate on tags but in tests I want to validate that users can access specific things, validating they can access tags isn't very useful. I also don't really think the tests should be in the ACL file itself, I would much prefer if it were external, or if the Tailscale CLI had a command to run ad-hoc reachability testing.
Part of this is fair since there is a cost to operating the control plane.
One way around this is to go back to using check runs. I imagine a third party could handle webhooks, parse the .github/workflows/example.yml, then execute the action via https://github.com/nektos/act (or similar), then post the result.
