> For coding, you can use AI to write your code. For software engineering, you can't.
You can 100% use AI for software engineering. Just not by itself, you need to currently be quite engaged in the process to check it and redirect it.
But AI lowers the barrier to writing code and thus it brings people will less rigour to the field and they can do a lot of damage. But it isn't significantly different than programming languages made coding more accessible than assembly language - and I am sure that this also allowed more people to cause damage.
You can use any tools you want, but you have to be rigorous about it no matter the tool.
> For coding, you can use AI to write your code.
For software engineering, you can't.
This is a pretty common sentiment.
I think it equates using AI with vibe-coding, having AI write code without human review.
I'd suggest amending your rule to this:
> For coding, you can use AI.
For software engineering, you can't.
You can use AI in a process compatible with software engineering.
Prompt it carefully to generate a draft, then have a human review and rework it as needed before committing.
If the AI-written code is poorly architected or redundant, the human can use the same AI to refactor and shape it.
Now, you can say this negates the productivity gains.
It will necessarily negate some.
My point is that the result is comparable to human-written software (such as it is).
I absolutely don't care about how people generate code, but they are responsible for every single line they push for review or merge.
That's my policy in each of my clients and it works fine, if AI makes something simpler/faster, good for the author, but there's 0, none, excuses for pushing slop or code you haven't reviewed and tested yourself thoroughly.
If somebody thinks they can offset not just authoring or editing code, but also taking the responsibility for it and the impact it has on the whole codebase and the underlying business problem they should be jobless ASAP as they are de facto delegating the entirety of their job to a machine, they are not only providing 0 value, but negative value in fact.
I disagree with the new rule. The old one is fine and applies to LLMs.
Vibing and good enough is a terrible combination, as unknown elements of the system grow at a faster rate than ever.
Using LLMs while understanding every change and retaining a mental model of the system is fine.
Granted, I see vibe+ignorance way too often as it is the short-term path of least resistance in the current climate of RTO and bums in seats and grind and ever more features.
Humans can and do make mistakes all the time. LLMs can automate most of the boring stuff, including unit tests with 100% coverage. They can cover edge cases you ask them to and they can even come up with edge cases you may not have thought about. This leaves you to do the review.
I think think the underlying problem people have is they don't trust themselves to review code written by others as much as they trust themselves to implement the code from scratch. Realistically, a very small subset of developers do actual "engineering" to the level of NASA / aerospace. Most of us just have inflated egos.
I see no problem modelling the problem, defining the components, interfaces, APIs, data structures, algorithms and letting the LLM fill in the implementation and the testing. Well designed interfaces are easy to test anyway and you can tell at a glance if it covered the important cases. It can make mistakes, but so would I. I may overlook something when reviewing, but the same thing often happens when people work together. Personally I'd rather do architecture and review at a significantly improved speed than gloat I handcrafted each loop and branch as if that somehow makes the result safer or faster (exceptions apply, ymmv).
I don’t think this is uncommon. At one point Lemmy was a project with thousands of stars and literally no working code until finally someone other than the owner adopted it and merged in a usable product.
Wow, and if you go to their website listed in they're profile, not only do almost none of the links work, the one that did just linked out to the generic template that it was straight copied from. Wow.
I'll one up you: at this point I'm becoming pretty sure that this is a person who actually hates LLMs, who is trying to poison the well by trying to give other people reasons to hate LLMs too.
Ah. I remember that guy. Joel. He sold his poker server and bragged around HN long time ago. He is too much of PR stunt guy recently. Unfortunately AI does not lead to people being nice in the end. The way people abuse other people using AI is crazy. Kudos to ocaml owners giving him a proper f-off but polite response.
I agree that's a funny coincidence. But, what about the change it wanted to commit? It is at least slightly interesting. It is doubly interesting that changing line 638 neither breaks nor fixes any test.
Even after the public call-outs you keep dropping blatant ads for your blog and AI in general in your PRs; there's no other word for them than ads. This is why I blocked you on the OCaml forum already.
When I was a kid, every year I'd get so obsessed about Christmas toys that the hype would fill my thoughts to the point I'd feel dizzy and throw up. I genuinely think you're going through the adult version of that: your guts might be ok but your mind is so filled with hype that you're losing self-awareness.
> As a bonus, we look forward to fewer violations (exhibit A, B, C) of our strict no LLM / no AI policy, which I believe are at least in part due to GitHub aggressively pushing the “file an issue with Copilot” feature in everyone’s face.
Also, the big part of that issue is people are incentivized to make their GitHub profile look good to have a higher chance of getting hired. Any non-mainstream platform is not as compelling to get social credits.
> Also, the big part of that issue is people are incentivized to make their GitHub profile look good to have a higher chance of getting hired.
Do people really get hired for bunch of PRs to random repos on GH or just think they will? My impression has always been that GH profile is completely ignored by both recruiters and interviewers.
And this kind of behaviour is a red flag for people who actually go digging through the GitHub profile. Like techical people in the last stages of a hiring process.
GitHub (or any repo host) is/was pretty much the only thing I care about when looking at people's applications, because it's the only thing that has anything to do with incontrovertible reality. I certainly don't give a shit about whether or where you went to university and it's unlikely that I value your tenure at some company highly unless I know the people in that company.
I've seen quite a few HR hiring processes where a mediocre HR person (knows to look for GH profile + activity on that, but not how to evaluate them) is paired with engineers with too little input power. In those processes, people that game their GH profiles tend to benefit.
Issues and Pull requests are only optional features . Open source projects could always use GitHub as just git host/mirror like how torvalds/linux is setup .
PRs are not optional: there is no way to disable them on GitHub. I can't be sure that this is intentional, but it certainly works out well for them that this is one of many properties which make it quite difficult to migrate away from the platform.
Pull requests are not optional on GitHub. Users have been begging for more than a decade for an option to disable pull request for a repository, and GitHub continues to ignore them.
PRs aren't an optional feature, though acting on PRs is obviously optional; nothing prevents you from ignoring or (even automatically) closing all PRs from anyone who is not on a list of approved contributors.
This situation has a strong scam smell. Zig has many thousands of open issues on GitHub (nearly 3,500 issues) that appears ripe to get mostly ignored, closed without resolution, or plain disappear from public view. As pointed out, it is correct to shine a light on and review the situation of issues at Zig's GitHub.
The issues for this language are particularly and unlikely to be followed up on or re-posted at Codeberg. Deceptions or smoke screen claims, can trick the public and sponsors or create false impressions about how far away Zig is (after 9 plus years) from actually being production ready and reaching 1.0.
Not long back we were all urged to take CODE_OF_CONDUCT.md seriously. I've arrived at a place where the next thing I open source will include such a file which discusses not sending slop to the repository.
When the metrics becomes a target, ladida. GitHub profiles are utterly meaningless to me, speaking as someone that was hiring folks in 2023–4.
Perhaps we need an app to keep track of bad job candidates. We can gossip about them and such. I mean, we did that for an entire gender (sex?), let's go make a unicorn.
They've abandoned GitHub for Codeberg because GitHub has ICE as a customer. Codeberg uses Paypal which is a member of the ICE "Virtual Global Taskforce".
There is a purity spiral that organizations can enter when they start doing this, which ends up with you shoving yourself into a cold dark corner of the internet and still not being completely detached from the badness because Cisco provides infrastructure for nearly every major weapons manufacturer and defense department globally.
> There is a purity spiral that organizations can enter when they start doing this
You are the one summoning that spiral by making a cheap gotcha wrt codeberg using Paypal.
The project apparently could and did move because the swith from github to codeberg wasn't that big of an impact, and because, while the new forge is not perfect, they feel the association is less severe. There is no "purity spiral" in that, just a pragmatic choice factoring in ethics.
Right, that seemed like a minor issue. There was also the minor issue of the increase of AI code PRs. Seems like the greater issue was a perception of deterioration of the platform (in their sites for years) and a reasonable path towards migration to another platform.
As I was reading your reply I was half convinced that it was not purity spiral but by the end, even you admit it’s an ethics thing so yeah it is pretty much purity spiral in place. Next they will leave the USA so that they won’t be associated with Trump.
I think there's a difference between providing services to X and a platform using a payment processor that collaborates with X.
You have a point, of course, but for many options, the best we can do is avoid the worst one as there's no perfect solution. I'm not saying that people should leave GitHub because of this, but I can see why some would and why they may pick a different, still not perfect, alternative instead of doing everything themselves.
There's nothing that compels you to "purity spiral" other than attempting to appease cynics who insist that all decisions must be completely binary and consistent, with no room for nuance or practicality, and that anything else is virtue signaling (which is somehow less defensible than enabling harm in the first place).
Reducing harm where feasible is still meaningful, and certainly better than no attempt at all.
I feel like that's the whole point of the OP. I agree with the overall post but mentioning the ICE relationship seems to detract from the main point.
"I hate GitHub because X Y and Z features are bad" is a good reason to move away; "I hate GitHub because one of their thousands of enterprise customers does not align with my political views" is not, in my opinion.
It seems like every organization in America is compromised in some way if you dig deep enough. Certainly you can find reasons for every big tech. There's still a balance to be struck though.
> It seems like every organization in America is compromised in some way if you dig deep enough.
I agree, and my view is that it goes much further. Quoting author Aleksandr Solzhenitsyn:
"The line separating good and evil passes not through states, nor between classes, nor between political parties either—but right through every human heart—and through all human hearts.".
This is indeed the virtue signaling trap. It then calls into question of if such public figures or organizations are really as ethical, as they claim to be or if the reason given is actually valid.
Especially, upon further scrutiny, if that leadership is involved in dirt or makes conflicting statements. The uncovered hypocrisy or deception, greatly undermines public trust and how the foundation is viewed.
You're mad because they left a vendor because they switched to a different vendor that you think is just as bad but also you're accusing them of starting an "inevitable purity spiral?" Which one is it?
I don’t have strong opinions about Zig or Codeberg, but I find the self-described status of the latter’s infrastructure concerning[1]: they’re seemingly running faulty hardware in production with limited redundancy, and are actively soliciting more hardware of unknown quality/reliability/provenance from their community. This is cool for a hobbyist project, but it doesn’t scream “stable platform for a post-GitHub world,” which is how I’ve seen Codeberg (aspirationally) described.
Reading the infra part of the post made me smile, I spent part of my week putting workloads on spot but this is the real spot market. Chaos monkey is running in prod if you are ready for it or not.
Jokes aside, the technical depth it takes to make that one server run is impressive. That makes me more interested in codeberg, not less, though I’m going to keep my own mirror of the zig repo until they get some better hardware.
To be clear, I’m not knocking it; I also like to reuse old computers. But it’s incongruous with replacing GitHub, rather that being a “weirdo hobbyist” version of GitHub.
We always have the option of exiting Codeberg to a self-hosted Forgejo instance if that should become necessary for some reason. (Not that I expect it will, considering Codeberg is a non-profit.)
It seems like they have reliability issues; if I read their status page correctly, they have incidents every few minutes. Or how should one read their all green page?
So much vague outrage over nothing. That CI system created by so called monkeys is the one of the best free CI service in the world. Not everyone has the millions of dollars like Zig Foundation to create their own CI servers.
After that they appreciate GitHub Sponsors, but say it is now a complete liability just because a project leader left. What are the actual changes? Any new rule? But no, it is now a "liability" and we should accept it.
Honestly speaking I like how big projects are exploring new hosting options. But there is no need to attack other platforms like this to promote your new host.
So you just chose to ignore the technical problems we have with GitHub Actions and then say there are no problems. That's certainly a take.
> That CI system created by so called monkeys is the one of the best free CI service in the world.
We self-host all our CI machines so the "free" hosted runners have no relevance here.
> Not everyone has the millions of dollars like Zig Foundation to create their own CI servers.
We don't have "millions of dollars". If only!
I'd also note that we spend our money very efficiently; most of our CI machines are consumer-grade hardware hosted in team member's homes. We don't just throw endless amounts of money at cloud providers.
> After that they appreciate GitHub Sponsors, but say it is now a complete liability just because a project leader left. What are the actual changes? Any new rule? But no, it is now a "liability" and we should accept it.
GitHub Sponsors is a liability because Microsoft can increase their cut at any time, or even axe it outright if they don't think it's profitable for them anymore. This risk is very real considering that, as Andrew pointed out, the feature has been neglected for years. It is objectively less risky for us to have donors use a platform like Every.org.
Anyone who has ever used Gitlab, or dare my foul mouth say Jenkins, has experienced a better system than Github actions.
Unless it's miraculously improved recently as it's been a couple years for me, they didn't even document their regex/pattern matching. Best I could find via searching was that it was whatever Ruby used, which wasn't any kind of real standard.
I don't want to call anyone names, but whoever defends said system deserves some ribbing.
I've used both and I don't know if they've been improved but both were terrible a few years ago (at least in our case). Very unstable and finicky. I last used Jenkins in 2017 and Gitlab in 2021, so I don't know how they are today.
The best free CI system in the world has macOS 15 runners running at 75% capacity due to a background process that consumes 100% CPU [1]. The problem is known to them since May but not fixed half a year later.
The only good thing about it is their very generous limits for "open source" projects (it doesn't even have to be free software AFAIK, just the source has to be visible to everyone).
The CI service itself is an absolute trash fire caused by the usual Microsoft NIH, and if they have financial means not to deal with it anymore, I see no reason for them to waste their limited development time on dealing with it.
Where else would the CI service for a Microsoft product be invented? NIH is a weird insult in this context. If Microsoft had instead acquired a CI service you’d be complaining about how they’re reducing competition.
I'm pretty sure the Zig Foundation does not have millions of dollars, contrary to Microsoft which has a market capitalization in the trillions, but consistently produces flaming garbage, product after product.
GitHub actions may be one if the best free options, but that doesn't make it one of the best paid options. I have seemingly endless headaches with it at work.
the technical issues are completely valid. at the same time, there is a balance between citing reasons for the change and burning bridges with those you leave behind.
the friction caused for the supporters felt a bit tone deaf. although the project itself runs on strong principles so i can imagine they know what they signed up for.
Unsure if this post is being astroturfed or not, but seeing HackerNews root for Microsoft and boo communities that embrace alternatives feels very, anti-hacker in mentality.
I don’t think people are questioning the move away from a gigacorp owned platform, but it’s the approach, the alternative chosen, and the brash language that are being questioned
There was a short time period between when Balmer left and the beginning of Windows desktop enshittification with ads and the (frankly insufferable) AI hype where Microsoft appeared to be on the right path. A saner Microsoft acquiring Github could have actually turned out to be a good thing, but alas...
> Putting aside GitHub’s relationship with ICE, it’s abundantly clear that the talented folks who used to work on the product have moved on to bigger and better things, with the remaining losers eager to inflict some kind of bloated, buggy JavaScript framework on us in the name of progress.
This says more about the author than anything else.
That they don't support a nationalistic paramilitary organization that requires its members to be masked and never known by the public so they cant be held accountable? A nationalized KKK is not something to ever support.
I don't care about ICE one way or another, but calling people "monkeys" and "losers" because they're not building a product to your exact specifications is extremely childish.
It seems to me that the real "losers" are the ones spending so much time bitching and moaning about a software platform they don't like.
I'm happy to see the move. Codeberg is probably a more stable/long-term solution than SourceHut as the founder is slightly unhinged (but love what he has built). Honestly, either would have been great choices.
More opensource projects should move off GitHub. I moved off it myself.
They all seem to do roughly the same things, but with a different web UI. Competition is great! Especially in response to a big corp that has market share. But... there was value in the centralization of GH.
I’m pretty sure Drew has stepped away from SourceHut. It’s kind of a bummer SourceHut stuck so stubbornly to mailing list only workflows. Everything else about the platform is great.
I believe Drew was taking a "break" from it, but not stepping away in any permanent sense. It's probably better for him to stay involved. I'd like to see him push his idea further. It's great to have options.
I agree that there is a steep learning curve compared to Github pull requests or Gitlab merge requests, but like many things the steep learning curve actually hides a very powerful tool. A famous example is the Linux Kernel, a project of such a size that simply can not work with the Github/Gitlab model.
I think it's probably a great filter for getting people who are actually interested in contributing. Lowering the bar for contribution hasn't really turned out to be useful in any real sense, in my experience.
Biggest problem of SourceHut that should be solved first before mass migration of open source - lack of the organizations that would allow multiple contributors working on the project, especially the project with multiple repositories.
Readit News
Hilarious how the offender on "exhibit A" [1] is the same one from the other post that made the frontpage a couple of days ago [2].
[1] https://github.com/ziglang/zig/issues/25974
[2] https://news.ycombinator.com/item?id=46039274
You can 100% use AI for software engineering. Just not by itself, you need to currently be quite engaged in the process to check it and redirect it.
But AI lowers the barrier to writing code and thus it brings people will less rigour to the field and they can do a lot of damage. But it isn't significantly different than programming languages made coding more accessible than assembly language - and I am sure that this also allowed more people to cause damage.
You can use any tools you want, but you have to be rigorous about it no matter the tool.
This is a pretty common sentiment. I think it equates using AI with vibe-coding, having AI write code without human review. I'd suggest amending your rule to this:
> For coding, you can use AI. For software engineering, you can't.
You can use AI in a process compatible with software engineering. Prompt it carefully to generate a draft, then have a human review and rework it as needed before committing. If the AI-written code is poorly architected or redundant, the human can use the same AI to refactor and shape it.
Now, you can say this negates the productivity gains. It will necessarily negate some. My point is that the result is comparable to human-written software (such as it is).
That's my policy in each of my clients and it works fine, if AI makes something simpler/faster, good for the author, but there's 0, none, excuses for pushing slop or code you haven't reviewed and tested yourself thoroughly.
If somebody thinks they can offset not just authoring or editing code, but also taking the responsibility for it and the impact it has on the whole codebase and the underlying business problem they should be jobless ASAP as they are de facto delegating the entirety of their job to a machine, they are not only providing 0 value, but negative value in fact.
Vibing and good enough is a terrible combination, as unknown elements of the system grow at a faster rate than ever.
Using LLMs while understanding every change and retaining a mental model of the system is fine.
Granted, I see vibe+ignorance way too often as it is the short-term path of least resistance in the current climate of RTO and bums in seats and grind and ever more features.
I think think the underlying problem people have is they don't trust themselves to review code written by others as much as they trust themselves to implement the code from scratch. Realistically, a very small subset of developers do actual "engineering" to the level of NASA / aerospace. Most of us just have inflated egos.
I see no problem modelling the problem, defining the components, interfaces, APIs, data structures, algorithms and letting the LLM fill in the implementation and the testing. Well designed interfaces are easy to test anyway and you can tell at a glance if it covered the important cases. It can make mistakes, but so would I. I may overlook something when reviewing, but the same thing often happens when people work together. Personally I'd rather do architecture and review at a significantly improved speed than gloat I handcrafted each loop and branch as if that somehow makes the result safer or faster (exceptions apply, ymmv).
He's got like 50 repos with vibe-coded, non-working Zig and Rust projects. And he clearly manages to confuse people with it:
https://github.com/GhostKellz/zquic/issues/2
(Honestly, that's a lot more patience than I'd be able to give what are mostly AI-generated replies, so kudos to these folk.)
I don't know whether to be worried or impressed.
Yes, I made mistakes along the way.
> Claude discovered a bug in the Zig compiler and is in the process of fixing it!
...a few minutes later...
https://github.com/ziglang/zig/pull/25974
I can see a future job interview scenario:
- "What would you say is your biggest professional accomplishment, Joel?"
- "Well, I almost single-highhandedly drove Zig away from Github"
If you think about it, Joel is net positive to Zig and its community!
the bootlicking behavior must must be like crack for wannabes. jfc
>I did not write a single line of code but carefully shepherded AI over the course of several days and kept it on the straight and narrow.
>AI: I need to keep track of variables moving across registers. This is too hard, let’s go shopping… Me: Hey, don’t any no shortcuts!
>My work was just directing, shaping, cajoling and reviewing.
How people can say that without the slightest bit of reflection on whether they're right or just spitting BS
I don't know enough about the project to know if it makes any sense, but the Zig contributor seemed confused (at least about the title).
But yeah hard to say
I would offer this one instead.
https://github.com/joelreymont/zig/pull/1
When I was a kid, every year I'd get so obsessed about Christmas toys that the hype would fill my thoughts to the point I'd feel dizzy and throw up. I genuinely think you're going through the adult version of that: your guts might be ok but your mind is so filled with hype that you're losing self-awareness.
Also, the big part of that issue is people are incentivized to make their GitHub profile look good to have a higher chance of getting hired. Any non-mainstream platform is not as compelling to get social credits.
Do people really get hired for bunch of PRs to random repos on GH or just think they will? My impression has always been that GH profile is completely ignored by both recruiters and interviewers.
The issues for this language are particularly and unlikely to be followed up on or re-posted at Codeberg. Deceptions or smoke screen claims, can trick the public and sponsors or create false impressions about how far away Zig is (after 9 plus years) from actually being production ready and reaching 1.0.
Perhaps we need an app to keep track of bad job candidates. We can gossip about them and such. I mean, we did that for an entire gender (sex?), let's go make a unicorn.
https://www.ice.gov/news/releases/top-story-industry-partner...
There is a purity spiral that organizations can enter when they start doing this, which ends up with you shoving yourself into a cold dark corner of the internet and still not being completely detached from the badness because Cisco provides infrastructure for nearly every major weapons manufacturer and defense department globally.
You are the one summoning that spiral by making a cheap gotcha wrt codeberg using Paypal.
The project apparently could and did move because the swith from github to codeberg wasn't that big of an impact, and because, while the new forge is not perfect, they feel the association is less severe. There is no "purity spiral" in that, just a pragmatic choice factoring in ethics.
Deleted Comment
You have a point, of course, but for many options, the best we can do is avoid the worst one as there's no perfect solution. I'm not saying that people should leave GitHub because of this, but I can see why some would and why they may pick a different, still not perfect, alternative instead of doing everything themselves.
If this forces them to rethink and build a better GitHub, can't wait.
Reducing harm where feasible is still meaningful, and certainly better than no attempt at all.
> Putting aside GitHub’s relationship with ICE,
and the rest of the article provides technical reasons.
"I hate GitHub because X Y and Z features are bad" is a good reason to move away; "I hate GitHub because one of their thousands of enterprise customers does not align with my political views" is not, in my opinion.
For the record, I do not support ICE
The post ends with an indictment of capitalism.
I agree, and my view is that it goes much further. Quoting author Aleksandr Solzhenitsyn:
"The line separating good and evil passes not through states, nor between classes, nor between political parties either—but right through every human heart—and through all human hearts.".
Especially, upon further scrutiny, if that leadership is involved in dirt or makes conflicting statements. The uncovered hypocrisy or deception, greatly undermines public trust and how the foundation is viewed.
Dead Comment
Deleted Comment
[1]: https://blog.codeberg.org/letter-from-codeberg-onwards-and-u...
Jokes aside, the technical depth it takes to make that one server run is impressive. That makes me more interested in codeberg, not less, though I’m going to keep my own mirror of the zig repo until they get some better hardware.
Status: CI down due to cloud issues.
Seems to be a safer bet to limit hosting related weaknesses and unknowns, considering move from github being quite disruptive already.
We do self-host all our CI machines.
Deleted Comment
After that they appreciate GitHub Sponsors, but say it is now a complete liability just because a project leader left. What are the actual changes? Any new rule? But no, it is now a "liability" and we should accept it.
Honestly speaking I like how big projects are exploring new hosting options. But there is no need to attack other platforms like this to promote your new host.
So you just chose to ignore the technical problems we have with GitHub Actions and then say there are no problems. That's certainly a take.
> That CI system created by so called monkeys is the one of the best free CI service in the world.
We self-host all our CI machines so the "free" hosted runners have no relevance here.
> Not everyone has the millions of dollars like Zig Foundation to create their own CI servers.
We don't have "millions of dollars". If only!
I'd also note that we spend our money very efficiently; most of our CI machines are consumer-grade hardware hosted in team member's homes. We don't just throw endless amounts of money at cloud providers.
> After that they appreciate GitHub Sponsors, but say it is now a complete liability just because a project leader left. What are the actual changes? Any new rule? But no, it is now a "liability" and we should accept it.
GitHub Sponsors is a liability because Microsoft can increase their cut at any time, or even axe it outright if they don't think it's profitable for them anymore. This risk is very real considering that, as Andrew pointed out, the feature has been neglected for years. It is objectively less risky for us to have donors use a platform like Every.org.
What exactly is different about GitHub sponsors here?
Unless it's miraculously improved recently as it's been a couple years for me, they didn't even document their regex/pattern matching. Best I could find via searching was that it was whatever Ruby used, which wasn't any kind of real standard.
I don't want to call anyone names, but whoever defends said system deserves some ribbing.
Dead Comment
[1] https://github.com/actions/runner-images/issues/13358
That is what I meant by the BEST FREE CI provider. It is not the best if you have money for something better.
It really isn't (look at Gitlab's for comparison), the only advantage of Github CI is that it offers free Mac runners.
The CI service itself is an absolute trash fire caused by the usual Microsoft NIH, and if they have financial means not to deal with it anymore, I see no reason for them to waste their limited development time on dealing with it.
With the implication that MS is free to harvest it for LLM training?
Deleted Comment
Deleted Comment
the friction caused for the supporters felt a bit tone deaf. although the project itself runs on strong principles so i can imagine they know what they signed up for.
Dead Comment
Sad state of affairs
> with the remaining rookies eager to inflict some kind of bloated, buggy JavaScript framework on us in the name of progress.
and
> More importantly, Actions is created by monkeys
are juvenile.
Only to the hopelessly naive.
This says more about the author than anything else.
It seems to me that the real "losers" are the ones spending so much time bitching and moaning about a software platform they don't like.
Dead Comment
Dead Comment
This is par for the course for him. He's quite a bit like Linus [1].
He needs to start following his own advice [2].
[1] https://mastodon.social/@andrewrk/112362751644363647
[2] https://andrewkelley.me/post/open-letter-everyone-butted-hea...
Dead Comment
More opensource projects should move off GitHub. I moved off it myself.
Codeberg (Forgejo) is Free software, GitHub isn't. Not everything is about the software features.
https://sourcehut.org/blog/2025-11-20-whats-cooking-q4-2025/
What's this about?
https://news.ycombinator.com/item?id=41837782
https://dmpwn.info/