You are thinking of the alarm fatigue[1], but it doesn't apply here -- there are no constant alerts warning that you are doing something dangerous to the point you get desensitized and start to ignore them. The correct analogy here are checklists -- things that you need to check if you are to do this "dangerous" activity (AUR usage), akin to pre-flight checklist.
Oh yeah, that's the name of it. But I guess something similar happens with checklists, you do it so many times without anything bad ever appearing that you start to subconsciously assume nothing will ever happen. Why check the rotor of my helicopter when nothing ever happened to it for 5 years? This checklist is a waste of time!
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).
You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)
To be fair, the advice very rarely is for people to jump onto Arch based distros.
The problem is more that the Arch value proposition kinda presupposes the sort of user that's going to "feel superior" about having it installed[0]. It leads to people that have no business installing Arch Linux (as it doesn't match their usecase) installing Arch Linux because it makes them feel cool.
I don't have a good answer for this, besides making it more apparent what people should expect from having Arch installed. My recommendation usually goes something like this:
* Do you want to have the latest version of all software, regardless of the question if it's well-tested beforehand?
* Do you want to have all software distributed in an as-close-to-upstream approach as possible? Be aware that "upstream" configuration can sometimes significantly differ from defaults most people expect. (Sometimes there's reasons for this, sometimes upstream are a bunch of obstinate jerks.)
* Are you comfortable with a terminal?
* Are you comfortable with needing to suddenly learn how to troubleshoot a broken system after a routine update?
Only if the answer to all of those is "yes", then Arch is suitable for you.
And finally, more specific to servers, where the answer should be "no" if you want to use arch:
* Do you have the expectation to never have to touch the OS after it's been configured correctly besides routine maintenance (ie. installing security updates) and maybe a big update twice a year?
I used to use Arch, before realizing that my system was gradually morphing into a bespoke mess that didn't really serve my needs and that while doing something very specific was possible, I also had to configure a bunch of mundane stuff you aren't normally required to think about - there's never a "just install, activate and adjust as needed" with Arch. All I actually wanted was a distro with more recent software than "3 years old" (Debian/Ubuntu's sluggish package inclusion is not really useful for desktops).
So I looked around and realized Fedora worked better for me: professional, clean, recent software (every 9 months updates, feature freezes are smart enough to account for ie. New Python releases) and not prone to sudden surprises.
To be honest, it took me way too long to figure the Arch etc crowd are hobbyists who enjoy having something which always 'needs maintenance' over the weekend. (And maybe they don't want to admit they are hobbyists because what they are doing seems Very Important.)
Sorta like 'car guys' who recommend some old thing you can wrench on.
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.
Hey, your response improves my opinion of 'car guys'. Because the analogy is thin and they are looking directly at what is coming out of the 'sausage machine'. And if the result is good, they could sell the machine for profits! (Unlike computer nerds.)
I'm sticking with "hobbyists/dabblers" here, because almost nobody runs Arch in real production scenarios. Its just a fun high-touch thing people can enjoy fucking around with. Nothing wrong with that.
(That is why someone could trivially trojan hundreds of packages and it's NBD. Because "Nobody Cares." Wipe it and start over, funguy.)
Honestly, it's hard to see how Arch is a usable distro for most potential users without AUR. If you want a large selection of official packages, the Debian world is going to be the better choice.
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.
I think the issue with AUR is that you get your foot in the door with packages like spotify[1]. It does its magic to allow you to install a .deb package on your distro. I don't know how else to install the Spotify desktop app without AUR. But once you're willing to do that, why not go a little further and trust other packages?
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 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.
That is not true, there are plenty of non-FOSS packages in extra/multilib (e.g steam, discord, nvidia). The only criteria is if there is an interested packager to maintain it.
>The large number of packages and build scripts in the various Arch Linux repositories offer free and open source software for those who prefer it, as well as proprietary software packages for those who embrace functionality over ideology.
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.
I don't. The agent was told it needs to provide a website for opting out of the scan, and it seems entirely LLM-like to try to be extra helpful and also spawn opt-out bots on various relevant communication channels. The IRC bot was a subagent as it itself mentioned.
And it stated in the response to the website request that it would do so. So for it to be a fellow IRCer prank, it was a) the LLM's idea; b) only possible because the LLM didn't follow through for whatever reason; and so c) the 'prank' was pretending it did?
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.
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).
With your analogy I would be the one saying that I'm still not convinced that skis are faster than snowshoes.
I still use ChatGPT/Claude/Llama daily for both code generation and other things. And while it sometimes does do exactly what I want it to, and I feel more productive, it still seems to waste my time an almost an equal amount of time, and I have to give up on it and rewrite it manually or do a google search/read the actual documentation. It's good to bounce things off, it's good as starting point to learn new stuff, gives you great direction to explore new things and test things out quickly. My guess on a "happy path" it gives me 1.3 speed up, which is great when that happens, but the caveat is that you are not on a "happy path" most the time, and if you listen to the evangelists it seems like it should be 2x-5x speed up (skis). So where's the disconnect?
I'm not here to disprove your experience, but with 2 years of almost daily usage of skis, how come I feel like I'm still barely breaking even compared with snowshoes? Am I that bad with my prompting skills?
I thoughtfully limit the context of what I'm coding (on 2 of 15 files).
I ./ask a few times to get the context setup. I let it speculate on the path ahead but rein it in with more conservative goals.
I then say "let's carefully and conservatively implement this" (this is really important with sonnet as its way too eager).
I get to compile by doing ./test a few times, there is sometimes a doom loop though so -
I reset the context with a better footing if things are going off track or I just think "its time".
I do not commit until I have a plausible building set of functions (it can probably handle touching 2-3 functions of configs or one complete function but don't get too much more elaborate without care and experience).
I either reset or use the remaining context to create some tests and validate.
I think saying 1.3x more productive is fair with only this loop BUT you have to keep a few things in perspective.
I wrote specs for everything I did, in other words I wrote out in english my goals and expectations of the code, that was highly valuable and something I probably wouldn't have done.
Automatic literate programming!
Sheep shearing is crazy fast with an LLM. Those tasks that would take you off in the weeds do feel 5x faster (with caveats).
I think the 2x-5x faster is true within certain bounds -
What are the things that you were psychologically avoiding /dragging or just skipping because they were too tedious to even think of?
Some people don't have that problem or maybe don't notice, to me its a real crazy benefit I love!
That's were the real speedups happens and its amazing.
Do you mind sharing how much experience you have with the tech stack that have generated code? What I found with LLM is the perspective for AI generated code is different depends on your own experience, and I would like to know whether it is only my experience.
I have more than 20 years with backend development and just some limited experience with frontend tech stacks.
I tried using LLM initially with for frontend in my personal project. I found that code generation by LLM are so good. It produces code that works immediately with my vague prompts. It happily fixes any issue that I found pretty quick and correct. I also have enough knowledge to tweak anything that I need so at the end of the day, I can see that my project work as expected. I feel really productive with it.
Then I slowly start using LLM for my backend projects at work. And I was so suprise that the experience was completely opposite. Both ChatGPT and Claude generated code that either bad practice or have flaw, or just ignore instructions in my prompt to come back to bad solutions after just a few questions. It also fails to apply common practices from architecture perspectives. So the effort to make it work is much more than when I do all coding myself.
At that point, I thought probably there are more frontend projects used to train those models than in backend projects, therefore quality of code in frontend tech is much better. But when using LLM with another language that I did not have much experience for another backend project, I found out why my experience is so much different as I can now observe more clearly on what is bad and good in the generated code.
In my previous backend project, as I have much more knowledge on languages/frameworks/practice, my criteria was also higher. It is not just the code that can run, it must be extensible, in right structure and in good architecture, use correct idiom ... Whereas my frontend experience is more limited, the generated code work as I expected but possibly it also violated all these NFRs that I do not know. It explains why using it with a new program language (something I don't have much experience) in a backend project (my well know domain) I found a mixed experience when it seems to provide me working code, but failed on following good practices.
My hypothesis is LLM can generate code at intemediate level, so if your experience is limited you see it as pure gold. But if your level is much better, those generated code are just garbage. I really want to hear more from other people to validate my hypothesis as it seems people also have opposite experiences with this.
Or you're using skis on gravel. I'm a firm believer that the utility varies greatly depending on the tech stack and what you're trying to do, ranging from negative value to way more than 5x.
I also think "prompting" is a misrepresentation of where the actual skill and experiences matter. It's about being efficient with the tooling. Prompting, waiting for a response and then manually copypasting line by line into multiple places is something else entirely than having two LLMs work in tandem, with one figuring out the solution and the other applying the diff.
Good tooling also means that there's no overhead trying out multiple solutions. It should be so frictionless that you sometimes redo a working solution just because you want to see a different approach.
Finally, you must be really active and can't just passively wait for the LLM to finish before you start analyzing the output. Terminate early, reprompt and retry. The first 5 seconds after submitting is crucial and being able to take a decision just from seeing a few lines of code is a completely new skill for me.
Huh, my recollection is the exact opposite. I remember the good old days when I could use inurl: link: and explore the website contents fully and drill down further if necessary, compared to now, where google seems to always think to know better than you what you are looking for. If you are not happy with the initial results it gave you, you are pretty much out of options, good luck trying to drill down to some specific thing.
But aren't you afraid that whenever you veer discussion from Wikipedia/stackoverflow type explanations it's likely lying to you? This was my general experience -- it's great at querying for stuff which already exists and is popular on the internet and for conversing on a surface level or broad level but as soon you delve into details it starts confidently lying and/or hallucinating things, which undermines my trust in it, which in turn means I need to verify what it says, which means it did not increase my productivity that much after all.
It routinely invents arguments, functions or concepts which don't exist in reality or don't apply to the current context, but look like they could, so you are even more likely to get caught by this.
Haha, yes, it indeed invents arguments that aren't part of specific APIs and would offer to do something that you'd like to do in a very easy way, but since they actually aren't part of the API, well, you're out of luck.
It's just taking the "I wish they'd thought of my use case when designing that API" on the next level by simply pretending in a very sincere and convincing way that your wish came true, then writing a usually-pretty-correct program around that assumption that would actually work _if that wish had come true_ - but unfortunately that API doesn't really accept this convenient parameter, so...it's not that easy in reality.
Not to mention that self sabotaging your good work habits is counter-productive. You may think that you are getting one over them, but it's just as likely that after a few months of doing bare minimum, it will become your new "default" behaviour and carry over to your new job/endeavor.
I think the GP is a bit confused and mixed Lithuania up with its neighbors. Lithuania, unlike its neighbors Estonia and Latvia, gave citizenship automatically to everyone residing in Lithuania right before the independence. While Estonia and Latvia chose to create a naturalization process aimed at excluding ethnic Russians.
[1] https://en.wikipedia.org/wiki/Alarm_fatigue
reply