rossvor

If we are sticking to the CRPG theme. Then the Witcher 3 and Divinity: OG 2, BG3 and Disco Elysium would be the obvious choices. If you told me in beginning of 2010s all of the future hits in this genre will come out outside of US and Bioware/Obsidian will fade away, I would be quite surprised (but maybe shouldn't have, considering their owners and financial situations)

How can you maintain it if you can't read/understand it?

Fair, but based on your experience surely you would agree that 1 year is not really enough time to start seeing codebase design issues from accumulated cruft, misaligned intents and other maintainability issues, this app is still in the honeymoon phase.

>Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.

That only describes a happy path though -- I also had many instances where there's an issue and just describing it to an agent immediately identifies a fix and it all goes faster compared to me having to "load up" the flow of codebase into my brain first. But I also still have instances where it thinks it identifies an issue correctly, spits a fix which doesn't work and looks wrong. You point out that it does not make sense because of X, it agrees and spits out a new fix, which is also wrong and you start out on these back and forth wild goose chases, at this point I usually give up and do it the old fashioned way by understanding what is actually happening. If it is within an agent loop, there may be no back-and-forth to waste your time but then you pay with wasted tokens when it will eventually gives up or you stop it.

>I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)

I would question the last part. In my mind the more you let go of control over your codebase the more likely that it will drift way from a place where it is still comprehensible to you, and also your comprehension skills atrophy, and with that, your ability to ask good questions and to prod your agent in a correct directions weakens, leading to more wild goose chases and burned tokens. This is all keeping in mind that for throw away or small applications, maintainability is not that of important of a value so this doesn't affect all codebases.

For what it is worth, while I'm sure it is right on target for some, I think that's incorrect model of a mean arch user. Updates are once a month thing for me (and the maintenance for that rarely exceeds 10m if that). I barely do any distro level tinkering, after all, I need to spare some time to improve my emacs config ;).

Basically, my model of a mean arch user would be closer to a DIYer -- likes to follow clear manual instructions, likes sturdy and non-ephemeral things, likes to know what the sausage is made of, but prefers if maintenance costs are minimized (since they will be bearing those costs and are responsible for the thing), so makes choices according to that.

I don't have it installed, so I can't comment if it requires constant babysitting, but looks pretty okay to me -- it has no AUR-only dependencies (++), one extra shell script (--), popular (++ given enough eyeballs...). Should be fairly easy to review, anything fishy should be fairly visible in git diff. If I needed it I would be using this PKGBUILD. It's a net gain that it exists there, someone else done most of the work for me.

> Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.

I mean yeah, but everything is trade off of volunteer + user attention. There is no trusted user™ who uses spotify, so it's not in official packages. So you as user need to maintain it yourself or rely on AUR and verify.

Obviously usages vary greatly, but I doubt it's that of big deal for majority of Arch users (maybe it's different for Arch derived distros). My AUR maintained package count has been in single digits for decades (both on my home PC and work station), and I don't think it as a heavy burden to update those packages. There's a certain selection bias going on here -- I drop AUR packages if they become too annoying (if they require updates too frequently or they want a slew of other AUR only packages as dependencies), I either find alternatives or alternative sources for them (e.g. flathub).

Arch still hits the sweet spot for me -- unobtrusive, close to upstream, and well-documented enough to keep full control over your own system. Both for the times when you want to go with the most default path and for the cases when you want to deviate and go play in the weeds.

Nothing here is "fundamentally broken". Any usage of AUR was always one step above executing random shell scripts from the net, and any official Archlinux guides were explicit about it. That's why there are no AUR helper tools in official repos and their usage was always discouraged in forums/wiki.

PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and review before running executable files you download from the net. Common sense stuff. That's always been the trade-off and it hasn't really changed much in last 20 years (even though every few years everyone seems to freak out over it).

Yeah, on second read, I agree with you that IRC chats are not being impersonated. It posted a link (in the PR discussion presumably) to a website where it compiled the report of its IRC interactions in the channel. Would be prankster wouldn't be able to do it.

TBH, I feel that is implausible that an agent would by itself decide to join the IRC and post those messages. My bet is that all of the IRC interactions (including the presumed real human JertLinc3522) were made by someone in the community pranking everyone else/having a bit of fun after they saw the pull request.

In the given list of GNU CVEs in the original article, it included a buffer overrun in tail from 2021. So for a fair comparison 2021 is part of the "window of activity" (the year uu_od CVE was published).