User talk:Lahwaacz/Recommended package management practices

From ArchWiki
Jump to navigation Jump to search

Merge smaller sections in Upgrading the system

To improve overview, Read_before_upgrading_the_system, Act_on_alerts_during_an_upgrade and Deal_promptly_with_new_configuration_files could be merged, instead of putting each under a seperate header. However, we'd have to clarify on "alerts" (most likely messages in .install files), emphasize on before/during upgrades, and find a matching title. Thoughts? -- Alad (talk) 20:47, 17 October 2015 (UTC)

I'm still thinking how to describe the partial upgrades. I don't want to make it look like Pacman#Upgrading_packages, which looks rather unclear to me. I think it's good that the headings stand out so much. To make the sections a little longer, we could probably merge in some details from Pacman#Upgrading_packages and Pacman#Package_updates_have_broken_my_system. I think that we can decide later on top of the big picture. -- Lahwaacz (talk) 21:10, 17 October 2015 (UTC)
I don't think it's necessary to merge all the smaller sections. I suspect that many users don't really need an explanation for these practices, they just need to know what the practices are. Having the big headers makes it easy to glance over the article and get a good summary. Silverhammermba (talk) 22:50, 18 October 2015 (UTC)

Problematic recommendations

A few sections are kinda rubbing me the wrong way. In particular: Use proven software packages, Use recommended configurations, and Choose open-source drivers. I think these sections go against the Arch philosophy of pragmatism and versatility, by making it appear that Arch is only recommended for users who want to use mainstream, open source software with little freedom in program configuration.

First, I think the ALSA vs. Pulse story is kind of distracting from the point, but mainly I think that Arch is a really popular distribution for people who want to try the latest and greatest stuff. So saying that only the tried-and-true packages are recommended is a little too stingy. Sure, if you're a sysadmin using Arch to build a reliable computing service you should probably only use proven software, but that's far too specific a use case to be a general recommendation. Any software that has an official Arch package should be recommended, and unsupported packages are a different matter entirely.

Second, the wiki's recommended configurations are by no means exhaustive, and one of the main advantages of Linux is allowing users to engineer novel solutions using existing packages. So again, saying that users should only stick to the recommended stuff makes it sound like Arch can't be reliably used for nonstandard applications. Which I hope isn't the case.

Third, while I'm all about open source, closed source drivers are unfortunately an inevitability for a large number of users. Saying that open source drivers are recommended is - for many users - equivalent to saying that not being able to play 3D games is recommended, or that not having wifi is recommended. If someone posts on the forum with a problem from a closed-source driver, switching to open source is often not a possibility and they just have to live with the broken driver due to some other need.

Silverhammermba (talk) 23:24, 18 October 2015 (UTC)

I agree with the first two points, but I'm not convinced on the third one. For example, Catalyst is not supported on Arch, and the gap with the OSS Radeon driver keeps decreasing [1]. It also mentions "wherever possible" - this is in line with e.g the Broadcom article, which suggests to avoid the proprietary drivers if the OSS ones do. -- Alad (talk) 06:13, 19 October 2015 (UTC)
Thanks for your critique, it's very appreciated. You are absolutely right about "proven software" and "recommended configurations", so I've removed the corresponding sections (and dealt with the original in Enhance system stability: [2], [3]). But I agree with Alad on the open-source drivers and in fact, I'm thinking about generalizing it to all open-source software, for the case where suitable alternative to given proprietary software exists. The point is not only stability, but also security (e.g. FlashPlayer and Skype). Of course it's the users' choice to pick software for their system and the section should be probably emphasize that. At the very least, I think FOSS deserves at least this little advertisement :) Lahwaacz (talk) 10:52, 19 October 2015 (UTC)
Good points, I do agree with you when you put it that way. Maybe I'm being too pedantic, but perhaps then the wording should be something like "Try open source alternatives before installing proprietary software". It's a subtle difference, but I think it's a little more welcoming. For example, it's the difference between "Google Chrome is not recommended on Arch" and "Try Chromium as your web browser first, and only switch to Google Chrome if you find that you miss the proprietary features". Silverhammermba (talk) 13:13, 19 October 2015 (UTC)