Still better than the old style reports from tools like that. They're typically commercial, and evidently came with some kind of licensing restriction that you couldn't give out their output.
So open source projects would get bug reports like "my commercial static analysis tool says there's a problem in this function, but I can't tell you what the problem is."
The interesting thing here is not their policy -- it won't survive, since they've given themselves the task of judging random people's skills -- but the fact that they have an AI policy for their open source project.
I think every project will need one, not least because of the issues/PRs full of AI slop.
Yup. It's why this, and Mastodon, failed so hard IMHO. It's all on different domains, looks and feels totally different, so the user experience is just terrible.
I thought I did. It worked fantastically well for email and the web, why not this? But it didn't for the reasons I stated (IMHO), and even worse -- even when twitter finally imploded it didn't take over at all.
One solution would be smaller cathedrals. Not everyone wants to go to the bazaar to pick what works for them; but most everyone would benefit if there was a limit to how encompassing a tech company can get.
Network effects are also somehow not working very well for decentralised things, possibly because everyone wants to fork Product X but no one wants to improve it for added discoverability or less bugs.
there are different solutions to different problems.
for example Substack is a good upgrade to social media. It's centralized, but people have to pay their favorite writers. They do this to avoid bs, ads, being a product. The important part of Substack is that if the platform screw the authors over, they have control over their email lists (unlike social media), and they can just move somewhere else.
So a platform like Substack is a move in the right direction vs. something like Twitter.
I think he's just pointing out current problems, as he's done many times. He likes to give talks and publicity to his project, as its maintainer, and that includes this sort of "what's going on with the project" talks.
I don't think he's unhappy. Frankly I think he's doing the right thing, and I say that as the founder of a project where I didn't do that sort of thing, but now realize I should have. This is what gets you contributors/donations/publicity.
Not to one-up you, but my worst nightmare is an open source project where all the maintainers are LLM copy-pasters, with little clue to be had otherwise.
And it's already happened, of course. A project I saw mentioned here on HN a while back seemed interesting, and it was exactly that kind of disaster. They started off as a fork of another project, so had a working codebase. But the project lead is a grade-A asshole who gets off on being grumpy to people, and considers any ideas not his to be ridiculous. Their kernel guy is an actual moron; his output is either (clearly) LLM output or just idiocies. Even the side contributors are 100% chatbot pasters.
The non-compatibility has over the years become the defining feature of GTK/Gnome. The maintainers seem to go out of their way to break API, for no reason at all. That extends to Gnome applications as well.
I recently found a GTK API call that was deprecated in GTK 3.0, only for its replacement to be deprecated by 3.16. These are not thoughtful people, with a vision for the future. They are idiots that inherited something great (GTK 1), and have spent decades thoroughly fucking it up.
IMO Gtk2 is better than Gtk1 as it did a significant number of improvements both in terms of features and usability. Later versions though aren't as great.
And TBH i do not think Gtk was ever "great", it was just fine and its main feature was availability because of the C API. For some time it was also the de-facto GUI API (during Gtk2 times) for Linux until Gtk3 broke that.
Deprecated does not mean removed. Was there any actual API/ABI changes in GTK3?
Also, it is easy to call people idiots, but calling people who GIVE you software you can choose to use or not that is not very productive or even nice.
I could call you names but that would only make this discussion worse.
I absolutely share your frustration at breaking API changes, and the older I (and my software) gets, the more it irritates me. It can be downright enraging to have (my) perfectly working code suddenly broken due to an irrelevant (to me) API change, especially when it requires hunting down a ton of compiler errors. I absolutely wish they would prioritize stability more.
Now that said, I do not think the truth is "The maintainers seem to go out of their way to break API, for no reason at all" or "These are not thoughtful people, with a vision for the future. They are idiots that inherited something great (GTK 1), and have spent decades thoroughly fucking it up." Having worked on numerous long-lived APIs in the past, there is always a tension between backwards compatibility and future development, especially consistency between calls. Especially when there are a lot of different contributors, it's very easy for annoying inconsistencies to pop up, and it feels really great to fix those. It's a constant balancing act between the past and the future, and a tilt too far in one direction comes with some significant downsides. I also think some grace is warranted for people giving their code away freely with no expectation in return.
I wouldn't say that maintainers break API, "for no reason at all", but surely they don't make the stable API a priority either. The fact is, that every API breaking change is an insult to developers/users of that API. But this is an unfortunate state of the Linux desktop.
Yes, no reason at all. I submit as evidence gtk_hbox_new(), there since the very first version of GTK, and deprecated in 3.2, in favor of gtk_box_new(GTK_ORIENTATION_HORIZONTAL).
It's a prime example of something that was entirely unnecessary, could have been hidden from the user with a macro, or (pointlessly) added but keeping the old API in place.
They do this all the time. It's not just the idiocy, it's the blatant hostility towards their users that gets me.
Yes, this is a prime example of completely gratuitous breakage.
The change adds zero value. It's a deliberate API break. And it could have been made a non-breaking change all for the sake of a single one-line macro or inline function.
This isn't unintentional. It's a deliberate choice they have made. And not just this one, it's happened repeatedly over the years.
The thing that really gets me, as an end-user/developer, is that it forces incompatible changes not only in my codebases, but in every other application developer's codebases worldwide. A small change in GTK+ imposes hundreds of thousands of man-hours of maintenance work upon every application developer. And this burdensome work not only takes time, effort and money, it doesn't improve our applications one iota, and on top of that, it breaks backward compatibility so our code will not longer build with older GTK+ versions. Most of us won't be chasing the latest development release, applications might need to target a wide range of distributions with a wide range of GTK+ versions. So it's a logistical nightmare as well.
The lack of concern for the needs of actual application developers is why I eventually had to give up on it entirely. At some point it doesn't make any sense either commercially or for free software development, it's just masochism.
I completely agree. This comment should be carved in stone for future generations to see. API breaking changes should never be made just to chase illusory butterflies.
This is sad. Actually, a long time ago I stopped working on two Linux desktop applications that used KDE framework libraries. I managed to port them from KDE1 to KDE2, but I got frustrated and lost my patience with KDE3 changes which had nothing to do with my application and I just gave up. Sorry to hear that GTK is the same constantly changing target.
After this experience I actually like Web-UIs and CLI apps a lot more.
> I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together.
Yup, that's the answer. Debian is rock solid, and a script with a bunch of iptables and iproute2 commands is so much simpler than the mess that is OpenWRT's network setup. I only use it for dumb APs, and even then it's questionable -- the UI is nice, but configuring it is unnecessarily complex IMHO.
So open source projects would get bug reports like "my commercial static analysis tool says there's a problem in this function, but I can't tell you what the problem is."
reply