I hope my drive-by PRs don't come off in the same way.

For example, as the simplest no-description, no-comment example, when I see typos or wording errors in text on a random blog I check if there's a direct way to contribute - to GitHub edit and submit a PR, and when there is, I do that.

There's nothing for me to say or describe, really, and it's not like I interacted with their project or community before or even plan to after. (Sometimes I do look into the issue tracker etc depending on the project or website. But that's beside the raised concern.)

I see it more of a collective and open collaboration. But that's not necessarily visible on the receiving end.

This is great, I was actually planning to try running Minecraft on my nano form factor RK3588S desktop.

I have one of those in my combo edge router and NAS box. Works well enough serving data via NFS at 2.5Gbps from an external USB HDD. Interrupts do use a fair bit of horsepower when it's doing that. Tailscale was a tiny bit slow last I checked but nothing upsetting, and I'm pretty sure that has more to do with a need for further optimization of Tailscale on OpenWrt than with the hardware.

And we have to expect that trend will continue. I haven’t tested frontier capabilities since April but I know for a fact my local drafters are producing far fewer obvious smells than I remember seeing in frontier outputs even just last year.

Current frontier is likely still detectable by an experienced engineer, especially if they’ve seen enough gen code to recognize the patterns, but might otherwise be indistinguishable from junior-level work. That is, I wouldn’t be surprised if the current frontier models didn’t output ANY giveaway “slop” code or outright hallucinations. Symptoms might be more abstract like inelegant architectural decisions, obtuse alg/structure selection, or design choices that demonstrate no grasp of overall objectives.

My point was that from a project maintainer’s perspective, quality is more a side effect, and there’s no effective difference between no AI and no detectable AI. The actual point of a no-vibecode policy is (A) to communicate expectations, ensuring contributors know their PR must pass a sniff test, that their name is on it, so blind PR submission is never a safe choice, and (B) to have a bulletproof policy to refer to in retrospect if ever issues relating to AI use in the project arise.

It's getting harder to tell the difference though. Slop artists can still prompt their agent to follow the codebase's existing style/format.

Has anyone done anything cool with RK3568? I have these Odroid-M1 that are otherwise pretty useless.

That’s pretty much the subtext of bans anyway. To guarantee undetectable use the contributor must treat gen code like a junior’s draft and refactor prior to PR. If it’s undetectable, the end result is the same from the maintainer’s perspective.

And it’s not a new approach. This has long been true for contributions containing “found” code; we define what’s allowed knowing we can’t actually enforce the rule against the most artfully obfuscated violations because, aside from achieving ostensibly the same result, having that tappable sign protects the project from a lot of BS down the line.

Some projects are already quietly saying "just don't tell people it's AI" and to make it look indistinguishable, then get on with life.

Can't say I have any good rebuttals against that tbh.

Yeah, I think calling out the demise of opensource is too early as there isn't enough data to support such a position.

I was thinking the other day how easy it would be for someone malicious to put a back door in whatever AI slop they make

I’d almost rather see all AI generated content be posted to its own separate open source platform “GitSlop” or something

Slop projects and slop submissions existed before the current crop of AI but it's certainly lowered the barrier. That said I suspect there are places AI can help. Simple patches, human guided refactores, test cases. We'll have data points from the projects that turned on the slop cannons and started auto accepting PRs soon enough.

I wish them luck. I hope they make Nvidia hardware obsolete and bring down the AI industry with them.

Its also the reason that I think these massive investments into GPUs for AI processing is stupid. GPUs are great for parallel processing, but there will eventually be something that is specialized for LLM workloads. It happened with crypto mining, it was just a matter of time.

😩 If you want to be absurdly narrow minded and treat OSI like some deity, their word like a holy book, and anything outside of that scripture or benediction as heresy, then maybe you'll see the arrival of AI as some kind of ragnarok.

Opensource will change but it won't be "killed". You can't and won't stop people putting the code for their projects online. The stuff you (or your agent or whatever) publish will continue to be used as an open portfolio.

A good amount of stuff published will be filth and indistinguishable from clonker filth or human filth. Additionally, local AI will also become more common. Making your code indistinguishable will also make the "AI code is unlicensable" argument worthless. Go prove that the trash heap I published was written while drunk and high or by an AI.

Yeah, I like Pixelorama too; I’ve tried it out, and it’s feature-rich and very stable. I discovered Pixelorama while looking for an MIT-licensed open-source alternative on AlternativeTo.net, and I really like it—especially since it’s built with Godot, making it lighter than other pixel art editors like Aseprite (which is written in C++). That’s actually why I created the .pxo format for Fossprite, since so many people love Pixelorama as well. (This reply is based on my personal opinion and was written entirely using Google Translate.)

There is also Pixelorama which can be run in-browse on itch:

https://orama-interactive.itch.io/pixelorama

https://pixelorama.org/

Its pretty good. I made an animated bouncing smiley a few years ago in like an hour or so without any prior knowledge.

In addition to the other comments here, we can't rule out the human love for hobbies either. Did I spend 2 days hand coding an entire blog that I won't show to anyone just for fun to learn some HTML and CSS? Hell yeah I did. Will I use that knowledge to make something less chaotically coded that I can actually be proud of? More than likely.

Obviously that won't be a large percentage of the market if even a noticeable one but, I'd like to think hobbyists will help preserve some good open source projects.

Is Bogdan my enеmy? Does he want the best for me? What's he doing with my teeth? Is he taking them to Australia?

That's what I humanized using AI, OK, I'm using Google Translate, I'm not very good at English.

This reads like an AI assisted comment

Because “browser-based” and “online” aren’t the same thing at all. The browser is just where Fossprite runs, and it doesn’t need an internet connection. Download the single HTML file, turn off your internet, open it locally, and it works. I went with the browser because pretty much everyone already has one, on any operating system, so there’s nothing extra to install. The trade off is that some browser limitations still apply.

Fair point, tbh. Putting everything in one file, plus the AI assisted development, has left me with code that’s hard to read and maintain. Some parts still use minified style names, and that's on me. I went with a single file so people could download it and run it offline, no build step and no dependencies. fwiw, that's a reason, not an excuse for code that’s hard to follow. What I still need to do is split it into clearer modules, rename things properly, and document where the original, adapted, and third-party code begin and end. If you have specific suggestions for making it easier to debug or contribute to, lmk.

why in the browser if its meant to be ised offline?

13k lines of vibe-coded HTML with unreadable JS (1 letter variable names, seriously?), how can you debug that?

Overall I agree, but it is missing and important aspect: maintainability.

This is maybe the most insidious part of LLM use to write code. Since LLMs have no real understanding of the structure of the project they will duplicate functions and generally make a mess that very quickly becomes unmaintainable by humans. The only "solution" LLM users have for that is perpetually rewriting large swaths of the codebase introducing new bugs, removing features and so on.

Since open-source software is usually especially long lived and maintained by a changing group of people, this results in code bases that are like asbestos that no one wants to even touch.