Is the current state of the AUR, despite the previous waves of attacks, and its troubled history, not evidence enough? The Arch team has never made the AUR a priority and I don't see why they would start now.
The way I see it there are three possibilities:
They do nothing.
They shut it down.
They give it up for adoption.
What is not going to happen is the Arch team putting time and effort into overhauling the AUR.
Who's "they"? Because it's not Arch. Arch doesn't want to have anything to do with AUR, and neither does any of the Arch-derived distros. They're all perfectly happy taking advantage of it, of course, but not the responsibility.
Remove unmaintained packages and block the name for several months.
Alright, but that would mean most of AUR. Have a look at the package statistics box on the AUR homepage. Most packages fall under that definition in one way or another. The vast majority of the AUR is package some random person added once then never bothered with ever again.
Frankly I'm surprised that the AUR has survived for so long in its current form, for what is basically a shell script distribution system with zero supervision and zero safety guards.
This kind of detail only matters if due process is still being observed.
There's a scene that comes to mind from "The Yellow Tie" (2025) where a street patrol in Nazi Germany makes the protagonist strip naked just to have a laugh, then as they leave they wonder if they should've shot him anyway, despite not doing anything wrong.
Unfortunately most companies don't have a software culture or even understand it. Heck there are entire nations (like Japan) that are culturally at odds with software. It doesn't stop them from making software (you can't NOT make software in today's day and age), they just go about it in furtive, roundabout and ultimately very inefficient ways.
It's weird because modern software development borrows heavily from industrial process optimizations (some of which were invented and perfected in Japan, ironically) and there are clear, proven benefits to cooperation upstream in projects like Linux... and yet they still fight it every step of the way in the name of "IP".
It doesn't help either that there are countries (US, Japan, what do you know) that nurture the concept of software patents that have a chilling effect on sharing.
Literally all knowledge and understanding requires memorization of some sort and the understanding of reality and prior information.
But is that what schools are teaching? When's the last time you heard of a school that prioritizes the way its students think and focuses on improving their reasoning and cognitive skills?
I'm not knocking memorization but it shouldn't be the main or only token by which learning is evaluated.
I would say try Manjaro with the KDE desktop. It's based on Arch so it will update indefinitely, it's one of the few distros out there that has system recovery snapshots enabled by default, and it was designed to work best the less you tinker with it (it really wants you to leave it alone so it can manage things for you).
Why go to school if you’re just going to use AI? What are you paying for?
You could also ask what good is a school that only teaches you things that can be reliably answered by AI.
Or, if you prefer, why is the school curriculum defining and evaluating progress in a way that can be passed by an AI.
IMHO it shows that certain subjects rely way too much on rote memorization and loose cognitive associations and should maybe take this moment to rethink their approach.
Sharing code makes sense for everybody. It lets them spend a lot less resources on fixing shit if everyone else is also doing that somewhere upstream. With FOSS you can have your cake and eat it too. At some point Google calculated that committing one developer upstream for the Linux kernel can save a company the equivalent of a couple dozen specialist developers downstream in bug prevention and feature alignment across vendors alone.
Unfortunately many companies continue to think about code as if it were potatoes. It doesn't fucking matter who owns the code, it's a functional spec. But hey, look at all the trouble we have explaining why standards are good – nevermind opening code.
In Docker's case is a non-issue because they were careful to use completely different names for all their packages. It's only when the external repo uses the same names as the core that the dependency resolver can get confused.
Rant:
apt should either completely forbid external repos from using core package names (like Arch does), or look at both the package name and repo URL when deciding if a package is the same, not just package name.
I'm guessing that letting external repos "hijack" a package name was once upon a time seen as a feature and then they never got around to fixing it.
You say that but sometimes they come up with stuff that's really useful and it can be very annoying to not have it. Like when they integrated compose into the main.
Also, if you later decide to switch to the official version you'll have to handle the upgrade carefully or you risk wiping out all your images, containers, networks, volumes etc. Which can be fine if you have backups of all the relevant functional definitions and the volumes and so on, but obviously a huge pain if it catches you unprepared.
Mind you, this can also happen by tinkering with stuff in /etc/docker/daemon.json, which is how I originally learned to back up my shit.
Debian's versions lag badly behind Docker's. You'd always be missing the latest features. Docker introduces them at a steady pace and it can get annoying to see people talking about a new useful improvement and then months passing before it gets to you.
Is the current state of the AUR, despite the previous waves of attacks, and its troubled history, not evidence enough? The Arch team has never made the AUR a priority and I don't see why they would start now.
The way I see it there are three possibilities:
What is not going to happen is the Arch team putting time and effort into overhauling the AUR.
Because they're sponsored by the US, who is also behind this?
And you're gonna see the Arch team wash their hands of the whole thing, like they did in the past whenever the AUR was in trouble.
That's not real ownership.
The orphan package criteria is misleading. If you look at the infobox you'll see that there are only 69 package "maintainers" for 100k+ packages.
I see. I'm in Europe and it's not very common there so that's why.
Who's "they"? Because it's not Arch. Arch doesn't want to have anything to do with AUR, and neither does any of the Arch-derived distros. They're all perfectly happy taking advantage of it, of course, but not the responsibility.
Alright, but that would mean most of AUR. Have a look at the package statistics box on the AUR homepage. Most packages fall under that definition in one way or another. The vast majority of the AUR is package some random person added once then never bothered with ever again.
Frankly I'm surprised that the AUR has survived for so long in its current form, for what is basically a shell script distribution system with zero supervision and zero safety guards.
Are they? Off the top of my head Germany is the only country I can think of that uses such a font (FE-Schrift).
They can also look for older R models, used. I have an R2 Arc Mini that can do 6 drives and it's not too big.
If you think you might need more, get one with more slots up-front. Trying to add more HDD to a case that wasn't designed for them sucks.
This kind of detail only matters if due process is still being observed.
There's a scene that comes to mind from "The Yellow Tie" (2025) where a street patrol in Nazi Germany makes the protagonist strip naked just to have a laugh, then as they leave they wonder if they should've shot him anyway, despite not doing anything wrong.
Unfortunately most companies don't have a software culture or even understand it. Heck there are entire nations (like Japan) that are culturally at odds with software. It doesn't stop them from making software (you can't NOT make software in today's day and age), they just go about it in furtive, roundabout and ultimately very inefficient ways.
It's weird because modern software development borrows heavily from industrial process optimizations (some of which were invented and perfected in Japan, ironically) and there are clear, proven benefits to cooperation upstream in projects like Linux... and yet they still fight it every step of the way in the name of "IP".
It doesn't help either that there are countries (US, Japan, what do you know) that nurture the concept of software patents that have a chilling effect on sharing.
But is that what schools are teaching? When's the last time you heard of a school that prioritizes the way its students think and focuses on improving their reasoning and cognitive skills?
I'm not knocking memorization but it shouldn't be the main or only token by which learning is evaluated.
I would say try Manjaro with the KDE desktop. It's based on Arch so it will update indefinitely, it's one of the few distros out there that has system recovery snapshots enabled by default, and it was designed to work best the less you tinker with it (it really wants you to leave it alone so it can manage things for you).
You could also ask what good is a school that only teaches you things that can be reliably answered by AI.
Or, if you prefer, why is the school curriculum defining and evaluating progress in a way that can be passed by an AI.
IMHO it shows that certain subjects rely way too much on rote memorization and loose cognitive associations and should maybe take this moment to rethink their approach.
And completely redundant because there are already FOSS game managers that support GoG they could contribute to?
Sharing code makes sense for everybody. It lets them spend a lot less resources on fixing shit if everyone else is also doing that somewhere upstream. With FOSS you can have your cake and eat it too. At some point Google calculated that committing one developer upstream for the Linux kernel can save a company the equivalent of a couple dozen specialist developers downstream in bug prevention and feature alignment across vendors alone.
Unfortunately many companies continue to think about code as if it were potatoes. It doesn't fucking matter who owns the code, it's a functional spec. But hey, look at all the trouble we have explaining why standards are good – nevermind opening code.
In Docker's case is a non-issue because they were careful to use completely different names for all their packages. It's only when the external repo uses the same names as the core that the dependency resolver can get confused.
Rant:
aptshould either completely forbid external repos from using core package names (like Arch does), or look at both the package name and repo URL when deciding if a package is the same, not just package name.I'm guessing that letting external repos "hijack" a package name was once upon a time seen as a feature and then they never got around to fixing it.
You say that but sometimes they come up with stuff that's really useful and it can be very annoying to not have it. Like when they integrated compose into the main.
Also, if you later decide to switch to the official version you'll have to handle the upgrade carefully or you risk wiping out all your images, containers, networks, volumes etc. Which can be fine if you have backups of all the relevant functional definitions and the volumes and so on, but obviously a huge pain if it catches you unprepared.
Mind you, this can also happen by tinkering with stuff in
/etc/docker/daemon.json, which is how I originally learned to back up my shit.Debian's versions lag badly behind Docker's. You'd always be missing the latest features. Docker introduces them at a steady pace and it can get annoying to see people talking about a new useful improvement and then months passing before it gets to you.