Not all tools are made for inexperienced people. Not everything is idiot proof. This is OK!
In my experience using the AUR:
1. when you first install the package you can read the build script (and you should). These are in a very standard structure, and if the one you are reading is weird and complicated consider not installing it. No one is forcing you to. Almost every build script I read just downloads a build from a tagged github release.
2. when you get an upgrade you are shown the diff. For almost every AUR package I use this is literally just changing the $VERSION variable and the subsequent $HASH of the download. It is trivial to see if anything (in the AUR script) is happening that is sneaky.
It's really not that scary. And if it's considered scary, there are literally dozens of other linux distros (not to mention Windows or MacOS) you could be using instead.
I'm not asking for myself. Yes, I understand the build process, and know what to check. I've also written PKGBUILDs before and have had packages in AUR. I'm sure you understand it too, as well as many people here.
But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
And, again, this attack was a relatively obvious one. Other attacks could be made much harder to notice.
Worse, distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves. Unlike ArchLinux, those sometimes do seem to promote AUR-helpers. In some cases, those distributions are apparently including AUR-sourced packages in their actual repositories.
Questions about these topics often result in typical Archlinux hostility. And in some sense, that's understandable: there are other distributions that most users should be using, and the frustration of people using Archlinux who shouldn't be is wearing. It is nice to have a distribution that offers the flexibility and space for experimentation that Archlinux does. It's one of the reasons I use it on some of my machines, while at the same time recommending against most others using it.
To some extent, this is just a wide cultural difficulty with Linux, and there isn't a clear answer. On one hand, you want enough gatekeeping to keep users away from potentially dangerous systems they have no interest in understanding, and that they'll rely on without understanding in situations where they shouldn't. On the other, you don't want to keep out users who are interested in learning.
> But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
That's where the whole "Not everything is idiot proof" thing comes in. The distribution is pushing the responsibility on users to vet what they do, across everything, not just installing AUR packages, so naturally this also applies to installing 3rd party software.
If you don't know what to look out for, maybe don't install stuff you don't know what it will do. Sucks as an answer if the distribution is looking to "Make it as easy as possible for every user" but that's not Arch Linux ultimately, it does ask you to care about things like that, if you don't want to, it might not be the OS for you. And that's of course OK and not something bad. I know this sounds like gatekeeping, but it's more of a culture difference than anything, and probably not even a problem.
> distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves
That'd suck, but not the impression I've got from CachyOS. There is a FAQ entry that seems to get the gist of AUR correct, that it's basically random software from random users, nothing is assumed safe: https://wiki.cachyos.org/cachyos_basic/faq/#aur-safety-pract...
> this is just a wide cultural difficulty with Linux, and there isn't a clear answer
I don't think "a answer" is needed here. What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing. Some distributions are for making things "easy for newcomers" or some focus on "best UI and UX" and others "most barebones for experienced users to setup themselves", and all of them as valid as the other. The tricky (and slow/time consuming) part is that you have to try a bunch before you find which one(s) aligns with your own perspectives and ideas.
Ultimately, users can learn best together with distributions that align with how they think and want to work.
>What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing.
Oddly enough, when I was writing that, I wasn't thinking about Arch, but Ubuntu. Years ago, I can remember a situation of a PPA being used for developing something I was involved in somehow, and while the PPA specifically noted that users shouldn't use it, they just did anyway, because they wanted what they saw as the latest and greatest versions of those packages. When the PPA owner added a package that set the default wallpaper to a warning about adding the PPA and updating all packages from it blindly, the users blamed them, rather than understanding the message. At the same time, I was actually using that repository legitimately, and it was useful.
So 100%, I agree that it's highly dangerous that the distro's the next tranche of people unfamiliar with linux (gamers dissatisfied with Windows) move over with, are based on hecking Arch. It feels like a massive upcoming footgun.
I think the issue is those repos being based on Arch though, not Arch itself.
To be fair, among all the linux users I know, no one except developers/cs-adjacent would actually get hit by this. The point is that "noob users" use packages that are, to put it short, maintained by a big company. Or it's something that's there in the official repos. And the big companies always maintain their own supply chain till the end, i.e they maintain their aur packages or their curl | bash endpoint themselves. So it ends up being alright.
Stuff that tinkerers use is often some random fork of a fork of a gitHub repo, maintained by someone else, and the aur package maintained by a fourth person. That's where the mess is. Thankfully, these are also the users you can expect to read a pkgbuild diff.
We must live in different realities, because I have the direct opposite experience.
Perhaps we are defining "job" differently? AI can, with much coaching, _perhaps_[1], do some _aspects_ of a programmer's job. But not all of it, or even the most important parts of it.
[1] given that we have spent the past many decades pointing out that developer productivity is possibly impossible to measure, or at least very hard; given "done" vs "done done"; given the history of "rock star" developers creating messes behind them, the difference between short and long term thinking and the external imperceptability of that difference; given all of that, we haven't really had enough time to form a valid opinion on what AI can do, in the long run.
Back when Snowden leaked all of the spying information, the only thing the States cared about was whether they spied on their own citizens. The fact that they spied on the citizens of their allies, including yes, the EU, barely made the news.
I don't think it makes sense the assume the US considers any country its ally.
sorry that's what I meant: I remember watching their depositions or whatever they were called, and their only concern was whether or not they had spied on US citizens. Whether or not they spied on their allies, I do not recall any coverage of from their primary news outlets (or inside their depositions) at all.
I agree with the sentiment and dislike Kissinger, but that quote is always paraphrased and out of context.
The full quote makes it clear Kissinger was saying, in the context of the Vietnam War, that the US should come to the aid of their friends:
> "Word should be gotten to Nixon that if Thieu meets the same fate as Diem, the word will go out to the nations of the world that it may be dangerous to be America's enemy, but to be America's friend is fatal."
I'm well aware of its context and original meaning, and I'm very happy to twist its meaning into something Kissinger would disagree with any chance I get.
It shares that intelligence with the countries it was gathered from. It's been explicitly stated many times that this is an intentional work around for weak constitutional provisions on protection of citizens.
I spy on your guys. You spy on mine. We all share notes.
This isn't a "The US vs. The World" this is "The Wealthy vs. The Poor."
It is endlessly... amusing (?) to me, that we as a community spent decades trying to make it clear that our productivity is not easily measured because what we're doing is complicated and long running, only for AI to come along and suddenly LoC, Nx multipliers, tickets / week etc are held up as useful if not objective measurements.
The reasons we rejected LoC and other measurements have not changed (broadly: code output isn't important, quality output is). AI has all the same problems people do. But for whatever reason we are throwing what we've learnt away. It's kind of embarrassing.
The non-technical people are in charge and they're not tethered to reality in the same way that engineers are. Objective reality will win in the end, but that doesn't prevent damage being done in the short term.
IDK, I do think a lot of it is LLMs enable people who were not in our community to come into it (in an eternal september kind of way) and they are going through all this from first principals and ignoring their elders, but I've also seen technical people suddenly measuring themselves this way. The most optimistic read of this is that they _feel_ productive, and that feels nice, and they want to share how that feels, and so they are reaching for these garbage metrics because they have nothing else.
> The most optimistic read of this is that they _feel_ productive
In addition to "feel productive", two other feels I think are flying under the radar:
1. You get a parasocial relationship with a "friend" (or at least conversation partner) who seems to "understand" you.
2. You get some form of gambling entertainment when you pull the lever and the output keeps landing on different sides of the jackpot you want.
While #2 has some overlap with classic creative struggle, I think it can at least be seen as a kind of junk-food verson, where the frequency is different and the health-promoting parts aren't present.
Maybe a particular group of software engineer cultivated the need for careful measures. But the programming field never escaped the idea of simple metrics.
That's because you would always have loosely involved but aggressive and demanding bosses (there is unfortunately an economic value to the boss whose primary task is forcing more effort out of the employee and who doesn't help coordination or anything else). So at best you had two intersecting clouds of approaches with actual accomplishment intersecting with LoC and related measurements.
The thing AI is that it provides all the tools to satisfy that loosely involved but demanding boss. So suddenly you are going to have a larger demographic of people who like LoC and feature-additions as metrics 'cause now they are easy.
>we as a community spent decades trying to make it clear that our productivity is not easily measured
Did we? All I saw the last decade was increasing worship of the Github activity grid, from both engineers and non-engineers. IMHO the bazaar had already lost its way before this.
LLMs should be treated as untrusted. At all times.
The mind boggles at the attitudes that seem to have have led to LLMs being an excuse to throw any of the "science" in computer science we've managed to get into production out the window and go elbow deep into treating computers like mystical alchemy.
This is perhaps a very American-centric article? I realise that ZIRP was near-global, but "When banks hiked interest rates, almost every tech company immediately laid off 5-20% of their engineers." does not track with my or my friends' experiences.
And, fundamentally, in countries with employee rights, as an employee I do not give two shits about interest rates the company I work at borrows on. My philosophy on software design does not change. You can argue that the company might pick and choose who it makes redundant, and they might value people who produce "more product", but companies have always valued that visibility. It's your responsibility, if you care, to sell your actions in a commercial context. I don't think ZIRP changes that, and I have not personally noticed a change there.
So currently there are people who are buying grey market peptides[1], marked "not for human consumption" and injecting themselves with them based on dubious anecdotes and vibes, to make their skin clearer, build muscle mass, and so on.
Are they are all suddenly turning into zombies? No. Do they have any real idea what that is going to do to their body a few years down the line? Also no. Could it be catastrophic? Maybe!
I think about this when I think about how violently much of the industry has pivoted into AI being the primary generator of code in the last 6ish months. AI is the peptide, your codebase[2] is the body. Literally no one knows how maintainable this approach is, because there simply hasn't been enough time to find out. It could be fine. It could be a complete mess, with your entire engineering team falling asleep at the wheel, lulled into thinking they understand what is being built when they don't, completely impotent to fix or maintain it once the LLM is no longer able to.
I've been thinking the same: the smaller the codebase, the better AI performs. So a way to scale AI is to modularize your architecture to maximize the number of leaf nodes in the dependency tree, and split out separate libraries where it makes sense.
It is huge for token usage also, Claude grepping the codebase for context it doesn't have is the main consumer of input tokens from what I can see.
The whole AI powered utopia is a bet on two possible outcomes:
- humans and companies somehow stop being greedy, selfish and cutting corners to optimize for revenue and time-to-market
- LLMs are the path to artificial superintelligences that will be able to deal with the exponential increase in tech debt from throwing AI slop at the wall (vibecoding) because no one has time to do things “the proper way”
The former is impossible. The latter is extremely unlikely and an existential threat to humanity.
The so called Luddites are the only ones to have even engaged at all with these concerns. Everybody else is just focused on the selfish game (see bet #1) of staying afloat in a rapidly changing ecosystem.
I would say some of the indicators are a little odd.
Some of them are questionable in terms of capturing the spirit of the idea ("violent crime" being the same in the UK and the US is a surprising one to me for example. It's capturing serious assault per 100k, but is then not considering murder as violent crime. You have murder later, but maybe combine / group them?).
Some are confusing because they are not clear politically: everyone wants less violent crime, but I don't know your politics and so have no idea which direction you have weighted net migration and asylum/capita.
It wouldn't be atomic, and so would break transaction semantics.
If you committed a row update but didn't update the index, a subsequent query using the not yet updated index would not find the updated row correctly.
It would also only work for certain types of indexes, you couldn't do it for uniqueness constraint for example.
I do agree that in theory you could have some extension to the index declaration that covers all that, but my worry there would be that it would be non obvious and a foot gun. Doing it the way described above makes that break in semantics clear.
> If you committed a row update but didn't update the index, a subsequent query using the not yet updated index would not find the updated row correctly.
I wonder if you could make it so that queries read from both the index and the unindexed changes. It would be slightly slower but as long as the unindexed changes are kept small it might be fine.
My impression is that InnoDB (MySQL's primary storage engine) is doing something like this. We have never seen any slow-downs on adding to the data set I've discussed in this thread, even at hundreds of millions of rows, and per the nature of the system creating this data the majority of these rows are targeted for additional single-row DML within a few seconds of being inserted, with instantaneous effect.
Yes, many times. Roughly once a week this year my team or an associated team can't ship changes because PRs, GitHub Actions, or some other associated mechanism is down.
In my experience using the AUR:
1. when you first install the package you can read the build script (and you should). These are in a very standard structure, and if the one you are reading is weird and complicated consider not installing it. No one is forcing you to. Almost every build script I read just downloads a build from a tagged github release.
2. when you get an upgrade you are shown the diff. For almost every AUR package I use this is literally just changing the $VERSION variable and the subsequent $HASH of the download. It is trivial to see if anything (in the AUR script) is happening that is sneaky.
It's really not that scary. And if it's considered scary, there are literally dozens of other linux distros (not to mention Windows or MacOS) you could be using instead.
reply