One of the things that people should know about SourceHut is that even though it is "Free Software", it is not a very "free" platform. Certain types of projects are a red line to the owner and will be removed[0].
I'll be honest, I do not trust cryptocurrency stuff and don't believe that it has utility. I hold none, I don't use it. That being said, this makes me wonder what the next category of projects that SourceHut will ban is.
What is the point of a free software forge if you can't host certain types of (legal) projects? It's hard to take a platform seriously, to move all of your work there when the administrators can (and most importantly, actually do) ban your projects based solely on their personal views.
I'm actually pretty fine with this, because they are pretty open about one point:
> We will exercise discretion when applying this rule. If you believe that your use-case for cryptocurrency or blockchain is not plagued by these social problems, you may ask for permission to host it on SourceHut, or appeal its removal, by contacting support.
First of all, it says that you can talk with a real human about this, second they are very open it.
When contrasted with a certain forge owned by Microsoft, which reaps my source code w/o my consent & regardless of its license to train a model which do not approve, Source Hut's stance is much more acceptable.
I'm fine with companies having opinions, and I love it when they're open about them instead of being faceless and do unpredictable things to benefit themselves.
And lastly, nobody forces you to work with a company you don't agree with. I don't work with GitHub anymore, and you're not preferring SourceHut. That's OK.
This comes up over and over on different platforms. It's sad to me how many services that are built on open source software don't allow you to use a custom domain. It's not that hard. Let's Encrypt makes it almost trivial.
Having tried GitHub, GitLab, Source Hut, Codeberg, and BitBucket (RIP), I think the only serious options are GitHub, GitLab self hosted, and Source Hut.
GitHub owned by MSFT aside, and also putting their AI push _also_ aside, GitHub has things like Sponsors, Dependabot, and code scanning that you won't find anywhere else. They sure are luring you into ecosystems that require a huge escape velocity, but GitHub serves as less-friction entry point to open source software.
GitLab self hosting is also nice and flexible, but it has a more "enterprise open source" feeling to it. Debian and Drupal can take advantage of it, but I don't see myself hosting mini projects like my mini CSS library that is also used by three other strangers.
Source Hut is really nice too. Admittedly I don't like email based workflows, so I haven't really thought about moving anything there. But Source Hut has "unlisted" repos, which I thought was really clever and missing from other forges.
Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again.
I'm looking forward to the federation work that is being done for forgejo, that will be big if it works out as it seems like it will.
Also, the founder has an unfortunate history of just up and abandoning his projects when they stop being fun for him. I used his media host/imgur alternative in the past, and it spontaneously just disappeared one day. I'd rather that not happen to my source code
> abandoning his projects when they stop being fun for him
I would call expecting any developer to do it differently quite an entitled opinion. And DeVault has a way better track record on successful projects (some of which continue being successful after he moved on with the help of the communities he fostered) than any of us really.
Experience shows that it's very difficult to make a business work on top of open source software and he is doing it as we speak. Your complaint smells like a petty grudge in the face of all the other things that could be said about his projects.
Git is decentralized. Ticketing systems and mailing lists as found on SourceHut and many other forges aren’t.
And if SourceHut disappears, what would you do with the repository? You’d upload it to a new forge, but how would you tell users where to find it, how would the users know this is the original source and not a hostile fork? It’s better to pick a stable, trustworthy. and 21st-century place like GitHub or GitLab instead of SourceHut.
I'd don't really see a difference between sending an email to a list or to a maintainer. Maybe that's an argument for not adding and adapting to unnecessary concepts like a web based pull request.
> How do you build any sort of community without a place for discussion?
There exist many ways for this. Why does this have to be the same provider (if you don't want to self-host this functionality) as the one that hosts the server for the VCS?
> Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again.
Perhaps the maintainers of the respective project consider filtering out contributions from "hipster programmers" actually desirable for the project. :-)
Are the hipsters the ones using email or refusing to use email? I could see a dude rolling up on a penny farthing to explain why email is the one true workflow. But he'll be embarrassed when a more powerful hipster shows up using a telegraph to send diffs by wire.
Having been using gitea at work for a while as an "internal mini-github" (along with a github organisation for stuff that isn't purely internal or would otherwise benefit for that) I have to say it ... hasn't annoyed me noticeably.
So I think I'd put gitea* on that list as well.
(I don't think I disagree with your opinions about the ones you -have- listed)
* and I mean that to include forgejo, I think, though I haven't tried it so YMMV
What irks me about GitHub is their LFS offering, which supports uploading/tracking files, but not deleting them. If you want to remove files from their LFS (and stop paying for it), you are supposed - and I am not kidding - delete the whole repo. (And they don't mention it on their LFS setup page.)
GitHub Sponsors is pretty great. Seems like a perfectly ethical way for open source developers to earn money. Doesn't depend on copyright, artificial scarcity, advertising. I really like it.
I'm surprised the author rejected using GitLab because of its Open Core model, but decided foe using Drone CI, which appears to be following a similar model.
The whole article feels really inconsistent on what the author likes and dislikes and his reasonings behind such things. Really off putting article imo.
What I understood is that the author is not happy about the “Open Core” model and would prefer truly OSS, but the real deal breaker is maintaining Gitlab.
My experience self hosting Gitlab was pretty terrible, it requires a lot of attention on your part, and internally the project feels like a bunch of fragile scripts.
There’s also little documentation for when things go wrong, with was almost every single update.
In the end I switched to Gitea as well and I’ve been happy with it for years at this point.
I found it difficult to find documentation on how to run gitlab in docker without nginx (I use caddy for reverse proxy) and enable the registry. For anyone having the same problem, here's a working Dockerfile. https://gitlab.tandav.me/tandav/notes/-/issues/5516
I've tried github actions, drone, woodpecker and gitlab. In my opinion gitlab has a much more flexible CI system.
If drone’s open core is a problem, there is always woodpecker, which was forked from the original drone before they changed their license a few years ago.
I was hoping for an evaluation of Radicle--the only forge that seemed to be doing something exciting and "new", and one I haven't had the time to really analyze yet--but... no such luck :(.
But honestly, I also wouldn't write about this without a lot of usage experience. For sure it's different from github/-lab etc. exciting and new, as you say.
The latter is Web3/crypto la la land, and the former.. dunno, got to read the code, but I would like to know about the project, its goals, and who is behind it.
Yeah, I don't think there is any meaningful distinction there. I think Pierre is just framing things in terms of solving for teams that work with product + design + engineering to ship something to users that involves all of those parties, whereas GitHub has primarily catered to engineering.
Today in software companies there is basically a gap where each discipline kinda prefers to work in it's own software silo (eg. Asana / Figma / GitHub), but that doesn't really make a lot of sense from a fundamental standpoint where all of those aspects of a team want to work very closely together. You end up kinda syncing a lot of info/state across the silos, or via meetingss/slack etc, so I think Pierre is trying to bring all that into one tool with some opinionated workflow. Makes a lot of sense from my perspective, curious how it ends up working out.
I'm not sure you'd want any forge evaluated by this author: they're extremely caustic, negative, and critical. Jaded people in tech like this I just try and avoid, especially when they come out against unalloyed good tech like containerization. Containers are just namespaces with additions. They've allowed us to narrow the gap of capability between the big three OSes, even if the other two need to virtualize Linux to do so.
There's also nothing wrong with LLMs. How you choose to integrate them into your life or forge is a choice but at the end of the day they're just another tool in the toolbelt. Pick what you want or need and leave the rest. I'm not forced to use Copilot but I appreciate it when I need it.
I also checked out SourceHut, but they're unfortunately not compatible with my email provider, and after some discussion with Drew (the founder) it started to sound like I'm not welcome unless I bring a real legal name and human identity. I understand how that type of collaboration can be valued and desired, but it excludes me, so I didn't pursue SourceHut any further. Something to think about if you ever consider it - no pseudonyms, no custom emails, use your real name and personal email address, or you'll be actively rejected by their software.
SourceHut staff here. We don't have any requirement for "real legal" names or anything -- and in fact I find these requirements very harmful in general (glad we finally got rid of them in the kernel). I know multiple people collaborating on SourceHut with a pseudonym and this causes no issue at all. SourceHut does assume a stable email address but that's about it.
It's not a requirement, but I heavily got the vibe that pseudonyms are not welcome. To quote Drew, "You should be using your real email address with the mailing lists, so that people can reach you and treat you as a human being, not as a proxy of one."
I'm just not comfortable putting myself out there like that. I get it's not technically against the rules to do it differently, but it's just... frowned upon.
Other justifications included that my peers would be sharing their real names and personal email addresses, so I'm being non-courteous by not doing the same... I dunno. It wasn't a particularly productive email chain, but it told me all I needed to know.
Pseudonyms are fine, hapaxnyms are what's cautioned against. Given that you use "Logan Dark" in several places surely you recognize why this is useful?
You don't have to make Gitlab/GitHub YAML files complicated if you don't want to. The "script" section can be just a call to a normal shell/Python/Typescript CI script. It's pretty widely known that you should keep as much stuff out of the YAML as possible, so you can run CI locally.
That was definitely the most bullshit criticism in the article. Clearly not even something they actually care about because they settled on Drone CI which is configured in exactly the same way.
> You don't have to make Gitlab/GitHub YAML files complicated if you don't want to. The "script" section can be just a call to a normal shell/Python/Typescript CI script.
It took me an embarrassingly long time to learn that you don't need to use their little action plugins for everything.
Once I figured that out, and figured out how to run CI in a container specified by the repo, I was actually quite happy to transition my CI away from Jenkins (which was always pretty rough, but I knew I could keep the builds running locally that way).
I guess the real proof will be if I'm able to ever leave GitHub, but I feel pretty good about the amount of lock-in vs the benefits of the service.
It uses GitHub's devcontainer plugin. There's a devcontainer config at .devcontainer/devcontainer.json, which says to use the image specified by .ci/Dockerfile.
So when I'm developing on any Linux system, I can run
And have a shell with my LaTeX environment all ready to go.
I can also create a GitHub codespace from the devcontainer config. I'm excited to explore more of the possibilities with devcontainers. I've included Dockerfiles with all my projects for quite a while now, it's cool to have some kind of standard written down that tooling can be written for.
I think the GitHub YAML a slight improvement over the old Jenkins configs it replaced:
For one, there's no out-of-band Jenkins UI I need to configure the pipeline in. The syntax is probably a slight improvement over Jenkins. I'm also happy to use opaque plugins for certain things, like uploading to S3.
Thank you for sharing! This shows nicely how you can keep the GitHub YAML at minimum by referring to an action (in this case devcontainers/ci) which configures itself based on the content of the repo.
You still need some high level structure to define jobs running on different platforms and their dependencies, so that jobs can run in parallel. Doesn't need to be written in YAML of course, or even declarative style.
> Hyper Performant & Hackable Code Forge Built on Open Standards. Ayllu is a lightweight code forge designed to enable individuals and community projects to develop software in collaboration across open internet standards.
If your goal is to put some code out there just to share it with others, any of those will work. There's also Bitbucket, Sourceforge, and self-hosted Fossil. The blog author seems to be looking for more of an "enterprise" open source option. You could even use Gitolite or GitWeb if you're willing to self-host.
Nothing says "unmaintained," or inertia, quite still like having a project hosted on Sourceforge. I'm sure there's a few exceptions that are thriving on Sourceforge, but... it's kind of a relic at this point. It'd be cool if it could have a revival, but I think they've tried that a few times and never quite got there. I certainly wouldn't put anything new there, myself.
I’ve been moving into a self-hosted direction for a lot of my stuff as a lot of it really wasn’t being used by anyone but myself anyhow. My latest two projects are darcs on my home server using just SSH+Nginx for HTTP with an apply hook that run `nix flake check` & on the server end, a hook that runs `nix build` which not only checks the build, but also has the derivation in Nix store for me to pick up later as that server doubles as a substitutor. Collaboration can still be done via email of patches or DMing a pull request from someone else’s remote repo. It’s crazy how much we’ve been defaulting to tools that are so complicated--especially ones that require accounts to participate & have a social media features tacked on everywhere to cause the sorts of social media anxiety it does everywhere else. When the amount of collaborators is low, self-hosting is hardly a barrier that needs extra scaling.
Weird the author said email was a pain, but last patch I received it was as easy as `himalaya read --raw X | git am` to apply & pointing out that modern email clients do a bad job supporting this seems more damning of those clients than the workflow.
You might want to try out self hosting hydra! It's pretty sweet for your usecase (building and caching Nix stuff, in a smart way). It can even run arbitrary commands (e.g. moving a release branch)
Perhaps I'm being too nitpicky, and there's nothing inherently wrong with their final choices, but their criticisms of the other systems alongside their reasons for choosing what they did are contradictory; overall the article was internally inconsistent.
Gitlab was dismissed for the SaaS being only open-core, despite opting for self-hosting in the end. Codeberg was dismissed for having limited CI, but in the end they went for a separate standalone CI anyway (& almost the same platform as Codeberg, just with the added overhead of self-hosting).
Yes, they dismissed Gitlab in part because of the self-hosted argument: "I know I can download GitLab and set it up on my own server. However, I’m a software developer, not a sysadmin. I want to spend my time developing software, not putting out fires and paying AWS bills for the rest of time."
Yet they ended up choosing a self-hosted option, Gitea, because it was recommended by an acquaintance and they set up a couple lightsail servers on AWS to run it.
It's totally fine for the author to share their preferences; they're just exhibiting the internal inconsistencies and irrational behavior we're probably all guilty of at one point or another.
To be honest gitlab can be a very painful beast to maintain if you just want to use it for yourself, especially if it's exposed to the public internet. The update rate is a bit insane, and while the updates are usually easy you still end up having to update almost every week or so, and I think monthly for critical security updates.
Coincidentally, I've been mulling the same idea for a week now. A self-hostable source forge + registry to serve artifacts would be amazing.
I think the only thing you'd lose is the 'social' aspects of GitHub, but I believe that can be made up with a combination of rss feeds (?), ActivityPub etc.
I think we've been thinking similarly. Decentralization will have it's costs. I've been thinking Opt-In centralized search for personal repos, maybe as a gitea (or other self hosted options) plug-in. But as you suggest, maybe existing features can be leveraged to prove the social/discoverability.
The author is too quick to dismiss Gitlab IMHO. I use Gitlab on the job, and Github for my hobby stuff, and Gitlab feels in many ways like a Github for professional use. The Gitlab CI system alone is a difference like night and day compared to GH Actions.
> Let me be clear, GitHub is still far and away the best website for open source discover
We need to separate discovery from hosting across the web. It's convenient to implement them together, but certainly not necessary. Bring back the link aggregators!
This is one of the first times I've seen someone who has casual access to Kubernetes.
They spent a lot of the post saying how they didn't really want to run stuff,
> However, I’m a software developer, not a sysadmin. I want to spend my time developing software, not putting out fires and paying AWS bills for the rest of time.
But then their friend convinced them to "kubectl apply" a couple of manifests & they got a bunch of stuff spin up quickly, on what should be a reliable-ish maintained-by-other-people cluster. This is the first time I've seen a win like this & it feels like such a sweet spot!
It's actually no longer experimental as of the Gitea 1.21.0 release. (It was released in Gitea 1.19.0 as experimental pending some hardening and additional features that they wanted to add, which have now been completed.) It is still under active development, but is a lot more mature now.
Like you, I have been using it since it was experimental, and it has been very nice.
My only complaint with Gitea Actions was that it required Docker specifically, not other OCI-compatible runtimes, but they recently added support for rootless Podman, so even that is no longer a complaint.
This seems pretty filled with arbitrary back-reasoning for decisions they've already made based on guy feelings.
They don't like "AI-powered" because it is a vague, ill-defined term... except it's extremely obvious and well defined what GitHub means by that (and they've even used copilot and liked it!)
Gitlab CI is rejected because it uses YAML for config... like every other CI system they mention.
Gitlab isn't ok because it's open core, but Drone CI is.
Could have been an interesting comparison but it wasn't.
I’ve kind of anticipated this sentiment and have been thinking about providing Gitea hosting. Though I’ve been a little discouraged by Gitea’s release of their own cloud hosting service.
This blog post and the revenue growth at Gitlab over the last two quarters appear to be evidence of people wanting to moving away from GitHub (though their earnings report attribute the growth to other initiatives, clearly I had no real insight on this). As an extension of my self hosting of Mastodon efforts from last year I rolled up my other minor hosting efforts into https://hawt.cloud as a place to experiment with providing services like this.
This all ties in with the “Open Web” or “Small Web” sentiments I’ve seen expressed recently. The hyperscalers are locking more and more up into their ecosystems but there should still exist small vendors/hosting/service providers. They’ll never scale or be as reliable as the big guys but if they cease to exist a lot will be lost.
I just went back to kind of "anonymous ftp" via my gemini site on sdf.org. I find it far easier to maintain. When I make a change, a script packages up the change and sends it to sdf.
My github repositories were changed to point to it. The latest change by Microsoft made me move, I was considering a move when Copilot became a thing. 2FA got me off my butt to finally move.
In my case I had to give them my cell phone, I have multiple platforms and no one M/S recommended solution would not work for all. I would not give MS my cell.
One time I wanted to test some specific flows with Gitlab, so I had the stupid idea to try to run my own self hosted instance on a Digital Ocean pod.
It was not really complicated to install but the resources that it is using are insane.
First, it would not even start if you don't have a dozen of Gb of ram available.
Also, even if completely empty, the thing would take 30 mins to warm up doing I don't know what before being available for initial setup.
In honest opinion, trying so much to copy GitHub, Gitlab became a heavy bloated software stack.
The PR workflow is already overkill for about 90% of contributors and not what Git was designed for, anyway, so you can just ditch it. You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed.
> The PR workflow is [...] not what Git was designed for
I would agree... in its GitHub incarnation.
> You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed.
Which is... where? The PR+fork model is what that implements: fork for the always-on storage so that upstream can fetch from it, PR for upstream to be notified about, discuss around, follow subsequent updates of, and track integration of the changeset.
The problem in the GitHub model is that it's all happening on a single centralised platform, removing the distributed benefits of Git at great benefit to GitHub through network effects, stifling competition.
What I propose is that the always-on storage need not be at GitHub, and there'd be a notification system towards GitHub to point to that always-on storage. Could be a bare GitHub repo with GitWeb (which is something one has to set up) + a curl to an upstream API endpoint, but sooner or later people are going to want to have a bit more than that, so having a forge do that (either a self-hosted one like Gitea/Forgejo or any hosted one like SourceHut/Codeberg/GitLab/Bitbucket) is practical.
This essentially makes forges interoperable, restoring the distributed nature of git development that GitHub killed by centralising git hosting.
(Of course you can s/GitHub/whatever-derivative/g above, I just focused on GitHub for the sake of simplicity because it's the monopolistic elephant in the room)
> Which is... where? The PR+fork model is what that implements
We agree that GitHub's fork+PR workflow gives you the functional equivalent. But it is sufficient, not necessary.
If you're working on a 600 MB repo and want to submit changes comprising 100 lines of additions and deletions as a first-time (and possibly one-time) contributor, forcing you to coordinate an additional always-on third copy of that repo is, as I said, total overkill for your ~5KB of changes—and that's before we even address that this is something that's required from every contributor.
> I would agree... in its GitHub incarnation
No, you're missing the point. Git wasn't even designed for Github-style pull requests (no matter where they're hosted). That's why Git doesn't actually have them. Only GitHub does (and everyone who decided to copy them).
It's not just the fact that everyone centralizes around a single site that's the problem. It's that fork+PR for every single change from every single contributor is fundamentally the wrong model to begin with. "Pull requests" are for frequent collaborators, like the core development team on a given project: they all have each other's repos in their remotes for pushing and pulling to/from whomever they're working with on a given thing when they're working together. Non-core contributors shouldn't even be worrying about the question of "where" to host things—they don't need to host things—who'd want to pull from them, and why? (And why burden them with provisioning hundreds of megabytes—or, in aggregate, gigabytes—of always-on online storage? Again: complete overkill.)
Given the rise of “AI-powered” forges, i.e. platforms that add the source of projects hosted there to their AI models, is it ok to upload GPL-licensed code there?
> I hope they haven’t started down the slow and painful process of enshittification by following vague, ill-defined industry trends!
Has anyone else found themselves wondering if GitHub switched to a different web framework?
I feel like they moved further down the client-side rendering rabbit hole recently. Their UI feels increasingly janky to me. Several times a day I get a view of completely un-styled HTML that eventually organizes itself into the appropriate presentation.
For many scenarios, the GH web UI used to be preferable over navigating through visual studio because of how responsive it was. Now, I find the exact opposite to be true. I avoid the GH web UI as much as possible. VS2022 isn't great, but at least it's not implemented using react on top of some bullshit chrome wrapper.
No, but Microsoft has an AI term of service which forbids use of Microsoft AI for AI development.
“””
AI Services
q. AI Services. "AI services" are services that are labeled or described by Microsoft as including, using, powered by, or being an Artificial Intelligence ("AI") system.
iii. Limits on use of data from the AI Services. You may not use the AI services, or data from the AI services, to create, train, or improve (directly or indirectly) any other AI service.
“””
If you ask GitHub Copilot Chat about the issue, it/they suggest seeking professional legal advice. To use GitHub Copilot. An AI trained on our AI code from GitHub. To write AI code. For paying customers.
Satya Nadella is King Midas. I emailed him and their legal team about it many times and he could have personally gone into the codebase and deleted this service term by now. I reported them to the State of Washington Attorney General (you can, too), and to the Federal Trade Commission Antitrust Team (you can, too), and to the Department of Justice Antitrust Enforcement Division (you can, too). Unclear how to report this to the EU Parliament AI Act folks, but maybe they posted new info since I last checked.
It’s a single line of text, certainly unfair and unreasonable and almost surely illegal in pretty much every relevant jurisdiction, so there’s certainly no an argument to be made that the fix is too technically challenging, even in light of Microsoft’s historical ineptitude.
We could check to see if Washington State has laws against contractual restraint of trade like California does.
(Hint, Hint.)
It’s hard to build a community around an open source if you’re not on GitHub imo. And if you’re not building an open source, than iiuc GitHub can’t use your code for copilot training so the main reason for not choosing GitHub according to the post isn’t relevant.
I'm not a huge fan of the term either but source control is only a small part of the development process.
Most of these systems are an amalgamation of scm, ci/cd, issues, wikis, project management, security integrations, static site hosting, review workflows, management of release artifacts etc etc.
Onedev has pretty good features built-in. They even seem to have a paid option now too which adds some additional features, though I wonder what the division between paid and unpaid features will look like as the project ages. To be fair though, there only seems to be one person consistently working on it.
Also there is just something about its sidebar-centric UI I just don't like. It's not as bad as gitlab but still, it bugs me every time I use it.
I think it's time we collectively mature past the point where taking unsubstantiated pot-shots at tools we don't "love" is seen as a value add to commentary.
In this case calling k8s a "nightmare" is a strong red flag akin to the mantra of "java is slow". It lacks the nuance of hands on XP and reeks of rules of thumb miss applied to the point of catchphrases.
Sad to see this down voted. I agree. They also sound insufferable. Maybe it's just their writing style, trying to be inflammatory for engagement, but they are not someone I would want to work with.
You and the parent seem to dislike the author sharing their opinions on things on their own blog. And yet you're happy to share your own dismissive opinions on the author here.
FWIW I find the author's obviously subjective opinions on their tools much more valuable than your obviously subjective opinions of this author.
They’re not saying that the author can’t post whatever they want on their blog.
They’re saying that we, as a community, should not elevate unsubstantiated writing that comes across as “I don’t truly understand these things or have deep experience, but this is what everyone else says on every other blog post or comment, and I’m parroting it”.
I would add on to it that I feel there’s sometimes a real thing in these discussions where reviews like these often come from people just tinkering and looking for the next thing to mindlessly experiment with. It’s not always representative of real world trade offs.
(I say all this as someone who self hosts a Gitea instance)
I have (with a team) built a couple on-prem Kubernetes clusters that handle billions of requests per day, as well as written Kubernetes controllers and operators.
Kubernetes is a nightmare, and I'm glad that some people are not afraid to point out the state of the emperor's outfit.
I disagree and think it's time we all moved on from kneejerk hating anything either a. new or b. misunderstood. That includes things like AI, containers and Kubernetes.
Kubernetes started in a rough shape but it has been chiseled over the years to be boring tech that just works and provides a layer of abstraction to build abstractions on top of.
I've been working with Kubernetes for the past 6 years. It's fine. It does its job. Let's all move on from the outrage.
> You and the parent seem to dislike the author sharing their opinions on things on their own blog
At least w.r.t. the original comment, this seems like a misunderstanding. GP was saying that, absent any explanation for why the author came to the opinions they did, the article doesn't say much of value. They don't dislike the author sharing their opinions on the author's own blog.
I don't care if the author shares their opinions, but I'm free to share mine as well, and I agreed with the parent comment at the time it was downvoted.
I've just been noticing a trend of people, like the article author, who are quick to dismiss things for reasons that are inconsistent and dogmatic. Why be so close minded? I think it's okay to be dismissive of the dismissive. Which, I didn't really dismiss him did I? I read his entire article.
Is not hard for me to see a case being built around the idea of finding value in having code to stay excluded from the surface exposed to AI so it becomes impossible for it to predate it.
It's a type of "security" that doesn't find an answer in "better AIs" or "AIs with improved alignment". The value comes out of being safe from the risk that can come out of the humans in control of these AIs.
I comes out of staying away and making impossible for any and all AIs to touch it.
Like the difference between food from a chef and hyperindustrialized food.
What if you want chef food only?
In the same way, exclusively human software creations.
I like this analogy but I guess I see it more like man inventing the knife, so he doesn't have to rip the animal to shreds with his bare hands anymore.
Except the knives do not have the capacity to give parts of the protein to other knives users surreptitiously and it's in AI's very nature to absolutely do that.
I'll be honest, I do not trust cryptocurrency stuff and don't believe that it has utility. I hold none, I don't use it. That being said, this makes me wonder what the next category of projects that SourceHut will ban is.
What is the point of a free software forge if you can't host certain types of (legal) projects? It's hard to take a platform seriously, to move all of your work there when the administrators can (and most importantly, actually do) ban your projects based solely on their personal views.
[0]: https://sourcehut.org/blog/2022-10-31-tos-update-cryptocurre...