ReginaldBull

You say I didn't respect people's time???? It's the opposite - they didn't respect what I had to offer. AI-supported or not - makes no difference. I was my time, my app, I offered it to the community, and the repo maintainer canceled my PR only because he read "Claude" in the description. This is what I call disrespectful. The repo-maintainer acts God-like and that’s not OK!

Time is over for conventional programming. I agree if you argue 30 years means nothing these days. But these days we have tools like Fable and these tools are really capable of doing their job quite well. Better than 90% of conventional programmers. You just have to push them in the right direction. However, in my case, they blocked me because they read the word "Claude" - that’s what I'm complaining about. > but without the author being necessarily capable of reviewing the output I'm capable of reviewing the code, but honestly, I don't do it anymore — those days are over too. I've defined a set of skills that lay out how I want the code written, plus a bunch of hooks that run security checks and so on. I develop with Claude, and Codex reviews the code. From time to time, especially before a release, I ask Fable to run a security scan, check the tests, and so forth. That's it. That's how development works today, and how it'll work for the next few years.

Yes — and as I wrote in the post, I'm already on that route. But step back and look at what that means: even more effort to bring one small free app to Unraid. The hurdles should be as low as possible, not higher every year. And in my opinion, this is the real issue: the classic maintainer system is outdated. Relying on a single volunteer's gut feeling, energy and mood to decide what the community gets is a bottleneck — the maintainer in question even admitted on the PR that it was about effort and lost interest, not quality. These days the heavy lifting should be automated: a service that checks defined criteria — does it build, is the source public and licensed, does the image pass a security scan, is the template valid — and gives a rating. Humans then only look at the edge cases instead of playing god over every submission. The official CA submission portal already works exactly in that direction (automated validation and scanning). That's the model — not a private repo where disclosed AI assistance gets you closed unseen.

I want to put a question to this community, based on something that happened to me this week. I built a small stock/ETF quote app (FastAPI + Vue, single Docker image), MIT-licensed, public source, tested and running in production on my own Unraid server. I wrote a CA template for it following the selfhosters templating guide and submitted it to their community template repo - for free, because I thought others might find it useful. The PR was closed within one minute of the first comment, unreviewed, as "pure AI slop": https://github.com/selfhosters/unRAID-CA-templates/pull/684 Why? Because my PR description said it was drafted with Claude, and my commits carry Co-Authored-By: Claude trailers. Nobody looked at the source, the template, or the app. The second maintainer confirmed it: the trailers themselves were the reason - "just a trust thing." Here's my problem with that, and I say this as someone who has written software for over 30 years, with a GitHub account dating back to 2009: those trailers are disclosure. I design, review, and test everything I ship. If I had quietly stripped the attribution, the PR would have passed. A policy that rejects disclosed AI assistance while waving through hidden AI assistance doesn't protect anyone from bad software — it just teaches developers to stop being transparent. That's the opposite of trust. I'm not arguing anyone must accept AI-assisted contributions. Review them. Test them. Reject them on merit. That's what maintaining means. What I'm questioning is rejection by label, unseen — and I hope that as more of the software this community runs on is built with AI in the loop (it already is, whether disclosed or not), we find a better answer than this. I've written about the episode in more detail on Reddit: https://www.reddit.com/r/unRAID/comments/1uxy2d7/rejected_from_a_ca_template_repo_because_my/ The app itself will come to CA through my own template repo via the official submission portal, so this isn't a request for help — it's a question about what kind of contribution culture we want. I'm genuinely interested in how other developers and users here see it.

I tried several approaches but the last few were writing to the array. The problem occurred when writing (reading?) huge files. 1TB. What I tried to do is writing back a 1TB backup from a physical HD to a vdisk. (As you can see in den background of my last SS) Even copying the empty vdisk (empty but size 1TB) from one disk to another one blocked my server for almost one day!

I switched to Unraid a few weeks ago, and I'm really impressed of what Unraid can do, but moving large files in Unraid seems to be a pain in the ass. The other day, I move a ~1TB file from cache to one of my array-disks. First I thought the whole system crashed because I was not able to access the system via SSH, Web and even the root login, directly at the machine, was not possible. At the machine, the system asked for the login but never came to the point where it asks for the PW because the whole system was so slow that it got a timeout and jumped back to login. It took almost 24h!!!!! until it has copied the file. I had no way to get access to the system. However - the system runs on a AMD Ryzen 7 5700G with Radeon Graphics @ 3800 MHz, but this should be enough... I added to SS. The one from 24 09 08 shows what happened in v7, the second SS 24 09 10 shows the same process under Unraid 6.12.13 However - switching back to v6 solved my problem, I just want to let you know there is a problem with v7 unraid-diagnostics-20240908-1010.zip