This just changed! The archinstall package is included on install media now and is not considered experimental (according to the wiki page history, that happened on 2022-07-08).
In my experience, Arch's main focus is on upholding a simple consistent architecture. There are tools that do something like the bare minimum required work, and then excellent documentation so that the end user can correctly perform the remaining required work manually (or via their own scripts).
As a result, there are certain features that will probably never be implemented. For example, if you wait too long between upgrades, your signing keys will be out of date. The solution is to upgrade the "archlinux-keyring" package first. Should pacman automatically do this? It would be nice, but it would also introduce a special case into pacman. Would that special case be abused to do unexpected things?
Another example is installers. Writing a basic installer for a single machine is easy. Writing an installer that covers any machine is very hard. Writing an installer that covers any machine with any configuration the user might want is impossible.
Put another way, everyone likes that Arch has up to date packages and an excellent wiki. Would either of these exist if there was a bunch of extra complexity that needed to be integrated? Is there any need for an excellent wiki if installers automatically resolve all your problems?
This is a cop out. An installer doesn't need to cover every option a user might want. An installer only covering popular options/configurations is only a problem if the installer is the only way to install the system. If it's just an option itself during the install there's no issue. The weird corner case can still be handled manually while more common options can be handled by an installer.
Most if not all Arch devs are likely advanced users, they didn’t need to maintain a user friendly installer for themselves so the old one got out of date and was removed.
What’s probably changed recently is that Arch has grown enough to get devs/trusted users who actually wanted to write and maintain an installer, so now it has one.
I find the Arch dev justification/perspective for most things much better than many users on the forums who tend to pick up the basic idea and cargo cult it whilst losing the context behind it.
It can be hard to resist some analysis paralysis when faced with an incredibly broad problem. There's a strong urge to find one solution to cover all cases. Trying to do everything at once being so overwhelming that it's impossible to get even started on it.
Of course, you're correct that the best thing to carve out the most common cases and then iterate. I've found that it takes time and experience to gain the wisdom to learn the perfect is the enemy of the good.
it has an installer again. maybe the userbase will change.
[0]https://wiki.archlinux.org/title/Arch_Linux#User_centrality
An installer, if anything, improves "user centrality" because you're making it more accessible and usable to most users with just the most common few options.
Not having an installer improves "dev centrality" (the few users who matter are the devs and other advanced users), over and against user centrality.
You could use the same thinking to argue against having a package manager. You might have to install a package manually anyway, so why bother providing packages at all?
There are other distributions that focus on other things and people can choose. If Arch chose to implement lots of convenience functions, that choice could be to the detriment of other strong aspects of the distribution.
I though it is all about doing it the upstream way.
So, would it add a bunch of extra complexity? Not really; it's actually tiny compared to making a package manager and maintaining its library.
Would it take away from maintaining the package library? I guess a bit.
Would there still be a need for documentation? Of course.
Also, the amount of patches, workarounds and custom configuration files in most packages and maintainer scripts is just wild. Coming from more than ten years of Arch, it took me a while to learn to check the debian packaging source if upstream doesn't match the behaviour on my system.
Used it to create a dual boot on my main machine and works a charm.
I already run Ubuntu on my NUC, and when I was looking around to install on my former gamebox (i.e. computer with a graphics card unlike NUC with onboard graphics only) I wanted something with good steam/nvidia integration. It came down to either Pop! OS or Endeavor... because while I develop software I also want to play games without futzing around too much.
Very happy with Endeavour: pacman or yay for nearly everything, no hassle graphics drivers updates (system always suggests a reboot after and I always do that).
My only real complaint was that I wanted to do a fairly extensive change to the sway configs, and tracking down where they put all the config files took a bit of time.
At some point I'm tempted to get a fat server going so I can do my dev work remotely to it using a super light weight / long battery life laptop, but that's a complication too far at the moment.
A setup like that would be quite cool -- if it weren't for one problem: All the "super light weight / long battery life" laptops have tiny (= max 13-14 inch) screens; there don't seem to be any 16(or more!)-inch ones. OK, just the bigger screen and housing means a machine like that couldn't be as super light weight as a smaller one, but they could still be quite light weight...
Only machines like that don't seem to exist. Or does anybody know of some?
...and that's a feature. There's nothing wrong with Arch doing its thing, there's always Debian/Ubuntu/Fedora/Manjaro/whatever - and Gentoo for those with taste.
I don’t see what the size of the distro has to do with it. Regardless of size, if there are users who have the time commitment and knowledge necessary to get commit rights and build and maintain an installer (as there is now), then it will have one. Otherwise it will not.
There’s no user hostility necessary for this sequence of events to happen.
A small amount of elitism is okay. For example, the Arch Wiki requires users to run a simple command before it allows them to create an account:
pacman -V|base32|head -1
I think most people who want easy access to Arch just go with Manjaro, which is close enough and gives you access to the AUR.
That usually happens when a package depends on a specific version of a dependency, with e newer (major) version in the repo.
It should only be an issue if you're using AUR packages or other package management systems. Official packages are updated for new dependencies afaik.
Same for me after more than a decade on Ubuntu. Switched to Manjaro Sway so I could have a better life in Wayland.
Pros: Documentation is excellent. Better than even Gentoo or Ubuntu's docs.
Cons: Arch doesn't have an installer, and seems almost militantly against providing one, or a lot of other little utilities that could improve the user experience. I get the same sort of 'I suffered, therefore you must suffer, learn to RTFM noob' elitism that I saw with slackware 20 years ago. I'm a grizzled vet, I can figure this stuff out, but it doesn't help your average technically literate joe.
Updates seem to break for odd reasons. I had to uninstall nodejs to be able to do a system update. Why? There should be some sort of automated way to address this.