5 ms·

I would like to defend arch here. In my experience, Arch's main focus is on upholding a simple consistent architecture. There are tools that do something like

I would like to defend arch here. 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?

arccy 4y ago
also, keys: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/GZ4TANWQMKONQNPDVK4Y6I6FGOGYKQ36/ https://lists.archlinux.org/archives/list/arch-dev-public@li...
giantrobot 4y ago
> 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. 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.
- chrsig 4y ago
  I'd call it more likely a form a neurosis than a cop-out. 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.
  - __del__ 4y ago
    arch used to have an installer. it didn't work for everyone, and caused a lot of complaining. turned out most people could do the steps themselves. it has an installer again. maybe the userbase will change.
- ratorx 4y ago
  I think the historical opposition of Arch devs to an installer is more maintenance. Most advanced users end up scripting their own specific system or getting a muscle memory for installing it (and that’s if they install Arch frequently at all). 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.
- superduperuser 4y ago
  Being that Arch is maintained with arch users in mind[0], building an installer for that user base would have to entail a wide range of option for unique use cases because that's whats expected of their users[1]. There isn't a "cop-out" or "plea" to users outside of the community because it was never a goal to appease them. [0]https://wiki.archlinux.org/title/Arch_Linux#User_centrality https://wiki.archlinux.org/title/Arch_Linux#User_centrality [1] https://wiki.archlinux.org/title/Arch_Linux#Versatility https://wiki.archlinux.org/title/Arch_Linux#Versatility
sam_lowry_ 4y ago
>Arch's main focus is on upholding a simple consistent architecture I though it is all about doing it the upstream way.
- wyclif 4y ago
  That's the flip side of the coin.
wolletd 4y ago
I love that Arch has no extra configuration system. I'm building Debian images at work for like three years now and still don't really get how debconf works. 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.
WfAjWDYpDHDYCN5 4y ago
They're talking about an installer for Arch itself (which could and should support the bare minimum options that most users want), which is what it didn't have until recently; not installers for packages within Arch, which it has always had. 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.

arccy 4y ago

also, keys: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/GZ4TANWQMKONQNPDVK4Y6I6FGOGYKQ36/ https://lists.archlinux.org/archives/list/arch-dev-public@li...

giantrobot 4y ago

> 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. 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.

chrsig 4y ago
I'd call it more likely a form a neurosis than a cop-out. 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.
- __del__ 4y ago
  arch used to have an installer. it didn't work for everyone, and caused a lot of complaining. turned out most people could do the steps themselves. it has an installer again. maybe the userbase will change.
ratorx 4y ago
I think the historical opposition of Arch devs to an installer is more maintenance. Most advanced users end up scripting their own specific system or getting a muscle memory for installing it (and that’s if they install Arch frequently at all). 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.
superduperuser 4y ago
Being that Arch is maintained with arch users in mind[0], building an installer for that user base would have to entail a wide range of option for unique use cases because that's whats expected of their users[1]. There isn't a "cop-out" or "plea" to users outside of the community because it was never a goal to appease them. [0]https://wiki.archlinux.org/title/Arch_Linux#User_centrality https://wiki.archlinux.org/title/Arch_Linux#User_centrality [1] https://wiki.archlinux.org/title/Arch_Linux#Versatility https://wiki.archlinux.org/title/Arch_Linux#Versatility

sam_lowry_ 4y ago

>Arch's main focus is on upholding a simple consistent architecture I though it is all about doing it the upstream way.

wyclif 4y ago
That's the flip side of the coin.

wolletd 4y ago

I love that Arch has no extra configuration system. I'm building Debian images at work for like three years now and still don't really get how debconf works. 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.

WfAjWDYpDHDYCN5 4y ago

They're talking about an installer for Arch itself (which could and should support the bare minimum options that most users want), which is what it didn't have until recently; not installers for packages within Arch, which it has always had. 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.