https://wiki.archlinux.org/api.php?action=feedcontributions&user=Jasonwryan&feedformat=atomArchWiki - User contributions [en]2024-03-29T11:53:46ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Doas&diff=764489Doas2023-01-20T06:41:33Z<p>Jasonwryan: /* doas persist feature */ grammar</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:Commands]]<br />
[[ja:Doas]]<br />
[[ru:Doas]]<br />
[[zh-hans:Doas]]<br />
{{Related articles start}}<br />
{{Related|Users and groups}}<br />
{{Related|sudo}}<br />
{{Related|List of applications/Security#Privilege elevation}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:doas|OpenDoas]] is a portable version of OpenBSD's doas command, known for being substantially smaller in size compared to [[sudo]]. Like ''sudo'', ''doas'' is used to assume the identity of another user on the system.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|opendoas}} package.<br />
<br />
== Usage ==<br />
<br />
To begin using ''doas'' as a non-privileged user, it must be properly configured. See [[#Configuration]].<br />
<br />
To use ''doas'', simply prefix a command and its arguments with {{ic|doas}} and a space:<br />
<br />
$ doas ''cmd''<br />
<br />
For example, to use [[pacman]]:<br />
<br />
$ doas pacman -Syu<br />
<br />
To get to an interactive shell with root prompt:<br />
<br />
$ doas -s<br />
<br />
For more information, see {{man|1|doas}}.<br />
<br />
== Configuration ==<br />
<br />
After installing OpenDoas, it will be attached with [[PAM]], but no default configuration or examples are included. <br />
<br />
To allow members of group [[wheel]] to run commands as other users, create a configuration file with the following content:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit :wheel<br />
<br />
}}<br />
{{Note|The configuration file must end with a newline.}}<br />
<br />
The owner and group for {{ic|/etc/doas.conf}} should both be {{ic|0}}, file permissions should be set to {{ic|0400}}:<br />
<br />
# chown -c root:root /etc/doas.conf<br />
# chmod -c 0400 /etc/doas.conf<br />
<br />
To check {{ic|/etc/doas.conf}} for syntax errors, run:<br />
<br />
# doas -C /etc/doas.conf && echo "config ok" || echo "config error" <br />
<br />
{{Warning|It is imperative that {{ic|/etc/doas.conf}} is free of syntax errors!}}<br />
<br />
To allow members of the {{ic|plugdev}} group to run [[smartctl]] without password as [[Root user]]:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit nopass :plugdev as root cmd /usr/bin/smartctl<br />
}}<br />
<br />
The general syntax form of {{ic|/etc/doas.conf}} is:<br />
<br />
permit|deny [options] identity [as target] [cmd command [args ...]]<br />
<br />
For more details please read {{man|5|doas.conf}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== doas persist feature ===<br />
<br />
''doas'' provides a persist feature: after the user successfully authenticates, they will not be prompted for a password again for some time. It is disabled by default, enable it with the {{ic|persist}} option:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit persist :wheel<br />
}}<br />
<br />
{{Note|The persist feature is disabled by default and because it is new and potentially dangerous. In the original ''doas'', a kernel API is used to set and clear timeouts. This API is OpenBSD specific and no similar API is available on other operating systems. As a workaround, the persist feature is implemented using timestamp files similar to ''sudo''.}}<br />
<br />
=== Smooth transition sudo to doas ===<br />
<br />
For a smooth transition from ''sudo'' to ''doas'' and to stay downward compatible, you could add to your environment:<br />
<br />
alias sudo='doas'<br />
alias sudoedit='doas rnano'<br />
<br />
Or alternatively, symlink ''doas'' to where ''sudo'' would normally be (but it does not provide {{ic|sudoedit}} command):<br />
<br />
# ln -s $(which doas) /usr/bin/sudo<br />
<br />
{{AUR|opendoas-sudo}} provides this symlink as well.<br />
<br />
{{Note|By default ''sudo'' preserves some environment variables while ''doas'' does not, most notably XAUTHORITY, LANG and LC_ALL. This means you will not be able to start graphical applications under X nor to access the user's locale without further configuration. For instance, to allow members of the ''wheel'' group to run graphical applications and to access the user's locale using the setenv option:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit setenv { XAUTHORITY LANG LC_ALL } :wheel<br />
}}<br />
}}<br />
<br />
=== Bash tab completion ===<br />
<br />
By default Bash will only tab complete files and directories within the current or referenced directory. To tell Bash to complete arguments as if they were separate commands (also leveraging the tab completion settings of other commands) the following can be added to either the users {{ic|.bashrc}}, or the global {{ic|/etc/bash.bashrc}}:<br />
<br />
{{hc|~/.bashrc|<br />
complete -cf doas<br />
}}</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Doas&diff=764487Doas2023-01-20T06:39:41Z<p>Jasonwryan: /* Configuration */ grammar</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:Commands]]<br />
[[ja:Doas]]<br />
[[ru:Doas]]<br />
[[zh-hans:Doas]]<br />
{{Related articles start}}<br />
{{Related|Users and groups}}<br />
{{Related|sudo}}<br />
{{Related|List of applications/Security#Privilege elevation}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:doas|OpenDoas]] is a portable version of OpenBSD's doas command, known for being substantially smaller in size compared to [[sudo]]. Like ''sudo'', ''doas'' is used to assume the identity of another user on the system.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|opendoas}} package.<br />
<br />
== Usage ==<br />
<br />
To begin using ''doas'' as a non-privileged user, it must be properly configured. See [[#Configuration]].<br />
<br />
To use ''doas'', simply prefix a command and its arguments with {{ic|doas}} and a space:<br />
<br />
$ doas ''cmd''<br />
<br />
For example, to use [[pacman]]:<br />
<br />
$ doas pacman -Syu<br />
<br />
To get to an interactive shell with root prompt:<br />
<br />
$ doas -s<br />
<br />
For more information, see {{man|1|doas}}.<br />
<br />
== Configuration ==<br />
<br />
After installing OpenDoas, it will be attached with [[PAM]], but no default configuration or examples are included. <br />
<br />
To allow members of group [[wheel]] to run commands as other users, create a configuration file with the following content:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit :wheel<br />
<br />
}}<br />
{{Note|The configuration file must end with a newline.}}<br />
<br />
The owner and group for {{ic|/etc/doas.conf}} should both be {{ic|0}}, file permissions should be set to {{ic|0400}}:<br />
<br />
# chown -c root:root /etc/doas.conf<br />
# chmod -c 0400 /etc/doas.conf<br />
<br />
To check {{ic|/etc/doas.conf}} for syntax errors, run:<br />
<br />
# doas -C /etc/doas.conf && echo "config ok" || echo "config error" <br />
<br />
{{Warning|It is imperative that {{ic|/etc/doas.conf}} is free of syntax errors!}}<br />
<br />
To allow members of the {{ic|plugdev}} group to run [[smartctl]] without password as [[Root user]]:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit nopass :plugdev as root cmd /usr/bin/smartctl<br />
}}<br />
<br />
The general syntax form of {{ic|/etc/doas.conf}} is:<br />
<br />
permit|deny [options] identity [as target] [cmd command [args ...]]<br />
<br />
For more details please read {{man|5|doas.conf}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== doas persist feature ===<br />
<br />
''doas'' provides a persist feature: after the user successfully authenticates, do not ask for a password again for some time. It is disabled by default, enable it with the {{ic|persist}} option:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit persist :wheel<br />
}}<br />
<br />
{{Note|The persist feature is disabled by default and because it is new and potentially dangerous. In the original ''doas'', a kernel API is used to set and clear timeouts. This API is OpenBSD specific and no similar API is available on other operating systems. As a workaround, the persist feature is implemented using timestamp files similar to ''sudo''.}}<br />
<br />
=== Smooth transition sudo to doas ===<br />
<br />
For a smooth transition from ''sudo'' to ''doas'' and to stay downward compatible, you could add to your environment:<br />
<br />
alias sudo='doas'<br />
alias sudoedit='doas rnano'<br />
<br />
Or alternatively, symlink ''doas'' to where ''sudo'' would normally be (but it does not provide {{ic|sudoedit}} command):<br />
<br />
# ln -s $(which doas) /usr/bin/sudo<br />
<br />
{{AUR|opendoas-sudo}} provides this symlink as well.<br />
<br />
{{Note|By default ''sudo'' preserves some environment variables while ''doas'' does not, most notably XAUTHORITY, LANG and LC_ALL. This means you will not be able to start graphical applications under X nor to access the user's locale without further configuration. For instance, to allow members of the ''wheel'' group to run graphical applications and to access the user's locale using the setenv option:<br />
<br />
{{hc|/etc/doas.conf|<br />
permit setenv { XAUTHORITY LANG LC_ALL } :wheel<br />
}}<br />
}}<br />
<br />
=== Bash tab completion ===<br />
<br />
By default Bash will only tab complete files and directories within the current or referenced directory. To tell Bash to complete arguments as if they were separate commands (also leveraging the tab completion settings of other commands) the following can be added to either the users {{ic|.bashrc}}, or the global {{ic|/etc/bash.bashrc}}:<br />
<br />
{{hc|~/.bashrc|<br />
complete -cf doas<br />
}}</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Maintenance_Team&diff=764479ArchWiki talk:Maintenance Team2023-01-19T22:45:05Z<p>Jasonwryan: /* Dealing with deceased users */ Agree with linking</p>
<hr />
<div>{{Note|This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.}}<br />
<br />
== Reorganization ==<br />
<br />
The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.<br />
<br />
However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:<br />
<br />
# I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".<br />
# ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.<br />
# ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of [[ArchWiki talk:Administrators]] (e.g. update the link in [[ArchWiki:Contributing#Complaining]]).<br />
# ✓ I'd like to deprecate [[ArchWiki:Reports]], and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to ''also'' report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes. <br> Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation. <br> Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.<br />
# Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: [https://github.com/kynikos/wiki-monkey/issues/175 #175], [https://github.com/kynikos/wiki-monkey/issues/176 #176], [https://github.com/kynikos/wiki-monkey/issues/197 #197] and [https://github.com/kynikos/wiki-monkey/issues/198 #198].<br />
# ✓ The [[ArchWiki:Maintenance_Team#Current_patrols]] list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.<br />
# ✓ [[ArchWiki:Maintenance_Team#Statistics]] was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.<br />
<br />
Opinions needed. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:11, 6 May 2015 (UTC)<br />
<br />
:: Point 1) Sounds good to me.<br />
:: Point 2) Agreed.<br />
:: Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.<br />
:: Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much. <br />
:: Points 6 & 7) Agreed<br />
:: -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 10:11, 7 May 2015 (UTC)<br />
<br />
:::1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account<br />
:::4,7. I'm neutral on this... I think having [[ArchWiki:Reports]] as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)<br />
:::6. Yep, and not including active members as well. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:10, 7 May 2015 (UTC)<br />
<br />
::::Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.<br />
::::Is it also the time to consider [[ArchWiki_talk:Administrators#Meaning_of_Administrator]] at this point?<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 7 May 2015 (UTC)<br />
<br />
:::::About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.<br />
:::::Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping [[ArchWiki:Reports]] would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to [[ArchWiki:Reports]] too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.<br />
:::::[[ArchWiki_talk:Administrators#Meaning_of_Administrator]] could surely be implemented in this article, it's very related indeed.<br />
:::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 8 May 2015 (UTC)<br />
<br />
::::::I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only. <br />
::::::How about doing it like you propose, but changing procedure for the reports that ''may'' still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 10 May 2015 (UTC)<br />
<br />
:::::::My idea (which I hadn't eleaborated yet here) was to allow the creation of ''quick'' reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from [[ArchWiki:Reports]] as an example of how it could look instead in the affected article's talk page:<br />
::::::::<h2>Quick report</h2><br />
::::::::''[This is an automatic [[ArchWiki:Reports|report]] about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]''<br />
::::::::''Comment'': I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp<br />
:::::::The whole thing could be manually added simply with: <br />
:::::::{{bc|<nowiki>{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~</nowiki>}}<br />
:::::::The link to [[ArchWiki:Reports]] (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.<br />
:::::::If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), [[Special:Diff]] could be used instead of the full link, and it could create the report in full text (i.e. like using the template with ''subst''). <br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:54, 11 May 2015 (UTC)<br />
<br />
::::::::Now in this case I'd like to nominate "(4) to deprecate [[Archwiki:Reports]]" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:48, 11 May 2015 (UTC)<br />
<br />
:::::::::Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:55, 12 May 2015 (UTC)<br />
<br />
:::::::::For the moment I've done points 6 and 7. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:43, 24 May 2015 (UTC)<br />
<br />
::::::::::I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:14, 29 July 2015 (UTC)<br />
<br />
:::::::::::Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in [[ArchWiki:Reports]]' table, which are probably even worse when it comes to [https://github.com/kynikos/wiki-monkey/issues/216 breakability], so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.<br />
:::::::::::I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).<br />
:::::::::::To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:54, 11 August 2015 (UTC)<br />
<br />
::::::::::::Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 13 September 2016 (UTC)<br />
<br />
:::::::::::::I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:51, 14 September 2016 (UTC)<br />
<br />
::::::::::::::I've flagged the page for archiving for now [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=450811&oldid=450669]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:40, 14 September 2016 (UTC)<br />
<br />
:I'd like to know if there's still consensus on 1?<br />
:If it were to be implemented, here's a list of things to do:<br />
:# Replace {{ic|1=$wgGroupPermissions['maintainer'] = array();}} with {{ic|1=$wgGroupPermissions['moderator'] = array();}} in [https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/templates/LocalSettings.php.j2 LocalSettings.php] and get it deployed.<br />
:# Ask DevOps to run {{ic|php maintenance/MigrateUserGroup.php 'maintainer' 'moderator'}}. See [[mw:Manual:migrateUserGroup.php]].<br />
:# Move [[MediaWiki:Grouppage-maintainer]] to [[MediaWiki:Grouppage-moderator]].<br />
:# Delete [[MediaWiki:Group-maintainer]] and [[MediaWiki:Group-maintainer-member]].<br />
:# Create [[MediaWiki:Group-moderator]] and [[MediaWiki:Group-moderator-member]].<br />
:# Update [[ArchWiki:Access levels and roles]], [[ArchWiki:Maintenance Team]] and [[Special:WhatLinksHere/ArchWiki:Maintenance Team|other pages]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:26, 26 October 2021 (UTC)<br />
<br />
== Regular Wiki Cleanup Days ==<br />
<br />
I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 19:45, 11 October 2016 (UTC)<br />
<br />
== Admin guidance ==<br />
<br />
Show we add some guidence that an admin should follow, the responsibilty they should take? <br />
<br />
Example:<br />
* Encourage contribution from Arch users. <br />
* Guide new contributor to follow Arch Wiki Style.<br />
--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:23, 11 July 2014 (UTC)<br />
<br />
:Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in [[#Meaning of Administrator]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:06, 12 July 2014 (UTC)<br />
<br />
:"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:53, 28 April 2021 (UTC)<br />
<br />
== Convention for splitting sections to new page ==<br />
<br />
Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring [[ArchWiki:Contributing]]. For exemple current [[OpenSSH#Tips_and_tricks]], or [[pacman#Troubleshooting]].<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with [[Template:Move]] and start a discussion in their talk pages (not here).<br />
:Otherwise you can try to propose some generic guidelines, for the moment we have a [[Help:Procedures#Split section to a new subpage|procedure]] to implement a split after an agreement has been reached.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::Maybe not generic criterias, but specific ones. For example sections like {{ic|Tips and tricks}} or {{ic|Troubleshooting}} can expand quickly. A generic rule like: {{ic|if more than 10 subsections are listed, you can move the section in a subarticle without asking first}} -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
::Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::That's not enough, because e.g. [[Chromium/Tips and tricks]] is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have [[ArchWiki:Contributing#The 3 fundamental rules]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:59, 16 June 2019 (UTC)<br />
<br />
::::In case the [[Chromium]] page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The [[Template:Move]] description suggest it is only for renaming articles ? -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:18, 17 June 2019 (UTC) <br />
<br />
:::::I've fixed the [[Template:Move]] description, the template has frequently been used to flag sections to be split, e.g. [[Network configuration#Device driver]], [[Arch terminology#Arch Linux]] or [[List of applications#Network managers]], which works pretty fine. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 17 June 2019 (UTC)<br />
<br />
Also, the {{ic|related articles}} sidebar can appear to be a little bloated on some articles (for exemple [[pacman]]). Should there be a dedicated side bar for subarticles (not sure about the name) like [[pacman/Tips_and_tricks]] in [[pacman]] ?<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:I don't find [[pacman]]'s related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in [[ArchWiki:Sandbox]] -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in [[Help talk:Style]], I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.<br />
:::About separators, I don't like them in this context regardless of the links order :)<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:26, 17 June 2019 (UTC)<br />
<br />
== Remove redirect page with bad title ==<br />
<br />
This topic is similar to above [[#Removing unnecessary redirects / pages]] but with a different target redirections. <br />
<br />
Background: <br />
* The [[Help:Article naming guidelines]] changes along the years, so there exist many Old_Title -> New_Title redirections.<br />
* Many new users contribute to Arch Wiki before they notice there is [[Help:Article naming guidelines]], so there exist many Bad_Title -> Good_Title redirections.<br />
* The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.<br />
<br />
Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes:<br />
Installation guide<br />
Installation Guide<br />
Installation guide(Català)<br />
Installation guide (Català)<br />
Installation Guide (Català)<br />
<br />
Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?<br />
<br />
{{Unsigned|14:21, 14 May 2020 (UTC)|Fengchao}}<br />
<br />
:I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 09:21, 7 June 2020 (UTC)<br />
<br />
:I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to [[Flatpak]] which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:30, 9 May 2021 (UTC)<br />
<br />
:One such redirect (that I think should be deleted) is [[Keeping Docs and Info Files]]. No other wiki pages link to it either. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:44, 9 May 2021 (UTC)<br />
<br />
::That one contains a history, so it should be kept (or archived at most). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:37, 15 May 2021 (UTC)<br />
<br />
:::What about renaming it (to something like [[Keeping documentation and information files]]) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:14, 15 May 2021 (UTC)<br />
<br />
::::I think "info" here was referring to [[info]], but it's still better than the old title which I now deleted. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:01, 7 June 2021 (UTC)<br />
<br />
:::::Thanks. I guess the "bad" title wasn't as bad as I thought then. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 15:17, 7 June 2021 (UTC)<br />
<br />
:Guys, I have made some mess while moving a page into a user subpage, so some redirect pages ought to be deleted:<br />
:* [https://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Dm-crypt/Device encryption (Русский)]<br />
:* [https://wiki.archlinux.org/index.php?title=User:User:Dimadenisjuk/Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no User:User:Dimadenisjuk/Dm-crypt/Device encryption (Русский)]<br />
:-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 06:26, 8 June 2021 (UTC)<br />
<br />
::Both pages are now deleted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:11, 8 June 2021 (UTC)<br />
<br />
:::Thanks. I have found that there are a lot of badly named redirects in the Russian AW ([https://wiki.archlinux.org/index.php?title=Pacman/Tips_and_tricks_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Pacman/Tips and tricks (Русский)], [https://wiki.archlinux.org/index.php?title=Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)/%D0%A1%D0%BE%D0%B2%D0%B5%D1%82%D1%8B_%D0%B8_%D0%BF%D1%80%D0%B8%D1%91%D0%BC%D1%8B&redirect=no Pacman (Русский)/Советы и приёмы], etc.), so later I shall create a list of such pages and put it here.<br />
:::-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 10:44, 8 June 2021 (UTC)<br />
<br />
:Here is one, please delete it: [[RTorrent(简体中文)]]。 -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:27, 22 June 2021 (UTC)<br />
<br />
::Done. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:47, 24 June 2021 (UTC)<br />
<br />
: I'm joining in here with two more pages that should be deleted : [[Securing arch linux]] and [[Arch Linux Server]], neither have an history and both are needlessly using Arch Linux in the page title without being used anywhere. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:05, 4 March 2022 (UTC)<br />
:: And one more [[Etkinleştir]] --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:29, 4 March 2022 (UTC)<br />
<br />
:::All done, thank you. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:16, 20 March 2022 (UTC)<br />
<br />
:::: Thank you ! I've stumbled upon one more : [[Expansão]], which links to [[Template:Expansion]] but is not used anywhere as this template should not be used on translations. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:41, 20 March 2022 (UTC)<br />
<br />
:::::Done. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:18, 20 March 2022 (UTC)<br />
<br />
: Three unnecessary redirects from today: [[ASUS B9450CEA]], [[ASUS B9450]] and [[ASUS ExpertBook B940CEA]] and three older ones: [[Partial upgrades]], [[TUXEDO InfinityBook S 14 v6]] and [[Lenovo ThinkPad X1 Titanium Gen 1]] --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 17:32, 25 July 2022 (UTC)<br />
<br />
::I removed all the laptop redirects. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:34, 26 July 2022 (UTC)<br />
<br />
::: Thank you! Should I ask about [[partial upgrades]]? It was flagged with [[Template:Style]] since 2018, we have [[partial upgrade]] already, only two user pages use it, and it has no history as far as I can tell. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:27, 26 July 2022 (UTC)<br />
<br />
::::It was created by [[User:Kynikos]], so I'll leave it up to him to decide what to do with it. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:48, 26 July 2022 (UTC)<br />
<br />
:::::Good work everyone, I've deleted [[partial upgrades]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:19, 21 August 2022 (UTC)<br />
<br />
:::::: Thank you! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 14:20, 21 August 2022 (UTC)<br />
<br />
: One more redirect with no history nor page linking to it: [[Terminal as a Transparent Wallpaper]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:25, 3 August 2022 (UTC)<br />
<br />
::Removed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:56, 3 August 2022 (UTC)<br />
<br />
::: Thanks! Three other old and unused redirect without history, but for these I am not sure they deserve deletion: [[:/etc/fstab]], [[OS X]] and [[:/]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:30, 7 August 2022 (UTC)<br />
<br />
::: Here are a few more redirects with no history, flagged with [[Template:Remove]] for a while: [[:Category:Dynamic WMs]], [[:Category:Tiling WMs]], [[:Category:Stacking WMs]], [[:Category:Lietuviškai]], [[:Category:Slovenský]] and [[:Category:Česky]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:15, 10 August 2022 (UTC)<br />
<br />
:::: Deleted. Can you update the backlinks of the first three? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:50, 11 August 2022 (UTC)<br />
<br />
::::: Thank you! I have found [[:Category:Stacking WMs (Italiano)]] while doing so, it can probably be deleted too. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:04, 11 August 2022 (UTC)<br />
<br />
:::::: Thanks, deleted that one too. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:19, 11 August 2022 (UTC)<br />
<br />
: Two more candidates for deletion: [[Xterm Automatic Transparency]] and [[Configuring Terminal as a Transparent Wallpaper]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:05, 11 August 2022 (UTC)<br />
<br />
::Both deleted. Please fix [[Special:WhatLinksHere/Configuring Terminal as a Transparent Wallpaper]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:47, 12 August 2022 (UTC)<br />
<br />
:::Thank you! User page updated to the right redirect, the last link is this discussion. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:17, 12 August 2022 (UTC)<br />
<br />
: One new redirect which is unused and without history: [[Workstation]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 20:13, 17 August 2022 (UTC)<br />
<br />
::It's gone. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:08, 18 August 2022 (UTC)<br />
<br />
:::Thanks! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 14:57, 18 August 2022 (UTC)<br />
<br />
: On today's menu: <br />
:* [[XPS 15 9560]], [[MSI GS66 11UH/11UG/11UE]], [[MSI Modern 15]], [[MSI GE75 8SX]], [[Acer aspire one]], [[Acer aspire E5-575]], [[Acer Chromebook 14 cb3-431 (Edgar)]], [[Machine Check Exceptions]], [[Machine Check Exception]], [[Macbook air]], [[Macbookair]]<br />
:* all the pages from [[Special:PrefixIndex/asus]] ('''except''' [[Asus Eee PC 1005HA (Español)]], [[Asus Eee PC 900A (Italiano)]] and [[Asus M50Vm (Русский)]])<br />
:--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:14, 19 August 2022 (UTC)<br />
<br />
::I deleted some of them.<br />
::[[MSI GE75 8SX]] has history, so it cannot be deleted. It was moved by copy-pasting instead of doing it properly.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 20 August 2022 (UTC)<br />
<br />
::: Thanks! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:32, 20 August 2022 (UTC)<br />
<br />
::Deleted the Asus stuff. Please fix [[Special:WhatLinksHere/Asus EEE PC 1025c]], [[Special:WhatLinksHere/Asus EEE PC 1215n]], [[Special:WhatLinksHere/Asus Eee PC]] and [[Special:WhatLinksHere/Asus x205ta]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:55, 31 August 2022 (UTC)<br />
<br />
:::Thank you very much, the pages in user space are fixed! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:31, 31 August 2022 (UTC)<br />
<br />
: Three more redirects with no history: [[Dv7-2120so]], [[Install and configure xorg]] and [[IPv6 - Disabling the Module]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 15:20, 30 August 2022 (UTC)<br />
<br />
:I have encountered three ancient redirects that are unused and have no history: [[Internet Access]], [[Dialup Access]] and [[Direct Modem Connection]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:36, 5 September 2022 (UTC)<br />
<br />
:More redirects I have stumbled upon today: [[Automatic Configuration with Cdist]], [[Tiling window managers]] (we already have [[tiling window manager]]), [[Official Repositories Web Interface]], [[Lenovo Ideapad Z580]] --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:26, 15 September 2022 (UTC)<br />
<br />
:One more today: [[MBA]] --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:43, 30 September 2022 (UTC)<br />
<br />
:One more while fixing broken section links: [[CloudCross (portugues)]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:58, 18 October 2022 (UTC)<br />
<br />
::It's gone. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:01, 18 October 2022 (UTC)<br />
<br />
::: /o\ I never said thanks! I found an other one today: [[Alacrity]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:17, 21 October 2022 (UTC)<br />
<br />
::::Done. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:57, 21 October 2022 (UTC)<br />
<br />
::::: Thanks! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 05:35, 22 October 2022 (UTC)<br />
<br />
== Are there statistics of page access? ==<br />
<br />
Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:05, 28 June 2020 (UTC)<br />
<br />
:I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:43, 28 June 2020 (UTC)<br />
<br />
::I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:00, 28 June 2020 (UTC)<br />
<br />
:::Agreed. Would be nice to review and assist with what matters most to our users. [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 05:13, 11 July 2020 (UTC)<br />
<br />
::::In the meantime, we can have a good approximation with [[Special:MostLinkedPages]] and [[Special:MostRevisions]], possibly with [[Special:MostTranscludedPages]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 16:24, 12 July 2022 (UTC)<br />
<br />
== Acceptable user names and signatures ==<br />
<br />
=== <s>ASCII only</s> ===<br />
<br />
I've just blocked [[User:🥚]] for a week until we make a decision on a general policy, they had only edited their User page, so it's borderline spam or a joke, but that's not my main point.<br />
<br />
I think the user name is practically unsearcheable without copy-pasting, and too hard to address for example in talk pages, it may mess up logs, bots etc.<br />
<br />
1) I propose to limit user names to ascii characters, plus possibly the other languages' characters that we support, but exclude emoticons and other fancy unicode characters. We'd either need a comprehensive definition or reserve the right to decide case by case.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Well, it messed up wiki-scripts and it took me more than an hour to figure out the problem... [https://github.com/lahwaacz/wiki-scripts/commit/25c11f36712df03c705d7cd1d3a8c673fc87360f] To actually limit the user names, we could write an abuse filter with some regex matching (assuming that the extension actually works). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:00, 11 August 2020 (UTC)<br />
<br />
::If we find an exact character set, sure we can try with an abuse filter. For the moment I'm also adding a reference to [[w:Wikipedia:Username_policy#Non-script_usernames]] (and the rest of the page): we may even default to using that page too. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 11 August 2020 (UTC)<br />
<br />
:::Yes, I think that would be a good policy for us too. It's certainly much better than writing our own from scratch :) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:11, 11 August 2020 (UTC)<br />
<br />
::I don't really see an issue with these kind of usernames; if some script can't parse them, then it's the fault of the script not the username. There hasn't yet been a influx of users with malicious intents and ''not-easily typable'' usernames, so I'd rather we don't take a heavy handed approach. Let's not overreact over an egg. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:40, 12 August 2020 (UTC)<br />
<br />
:::Ok that bots are supposed to be able to handle unicode, and the "too hard" in my OP should have better been "needlessly hard", of course we can find our way around [https://xkcd.com/1953/ weird] usernames, still assuming that MediaWiki and the extensions that we use are "ok" with that too (MW is mainly developed around Wikipedia, and adopting a looser username policy may end up into unexplored territory).<br />
:::In general though I think nobody whose goal is constructive interaction with the community would choose a clearly deliberately hard-to-handle username. After all, the purpose of a username is to make oneself easily identifiable by the other members of the community, it's not there only for aesthetic or artistic reasons.<br />
:::I wouldn't see adopting [[w:Wikipedia:Username_policy]] as heavy handed, the restrictions on misleading and disruptive usernames make a lot of sense to me, still leaving a lot of freedom of choice.<br />
:::I'd also be ok to take this to a vote.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
::::I updated [[Special:AbuseFilter/16]] to allow only usernames with ASCII characters in range 0x20–0x7E. Let's see if anyone complains. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:56, 2 February 2022 (UTC)<br />
<br />
:::::I disabled [[Special:AbuseFilter/16|filter 16]] and instead updated filters [[Special:AbuseFilter/15|15]], [[Special:AbuseFilter/5|5]] and [[Special:AbuseFilter/15|6]]. Let's hope I didn't break anything. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:19, 7 February 2022 (UTC)<br />
<br />
::::::Closing since {{ic|[^\x20-\x7E]}} in [[Special:AbuseFilter/15|AbuseFilter/15]] accomplishes the task. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:53, 24 September 2022 (UTC)<br />
<br />
=== Ban custom signatures ===<br />
<br />
2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Or at least ban custom signatures that hide or change the real username. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
:[[User:😎]] just registered, although this is just a test account of [[User:Klausenbusk]], who is a member of the devops team, this is still relevant. I am still in favor of adopting the blocklist used by Wikipedia, as mentioned in [[#Abusefilter]].<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:34, 5 June 2021 (UTC)<br />
<br />
=== Reserve a class of usernames for official purposes ===<br />
<br />
3) Related: reserve a class of usernames that may be used for official purposes, eg., legal, privacy, policy, security. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:16, 25 August 2021 (UTC)<br />
<br />
=== Obscene usernames ===<br />
<br />
I'd like to point out that a user was just deleted for having an obscene username (credits to me for finding and annoying the wiki admins with it). Having a wikipedia-like automated check if the username matches a regex would definitely help with detection of that. [[Wikipedia:Wikipedia:Usernames for administrator attention]].<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 15:38, 26 December 2021 (UTC)<br />
<br />
:I don't see any automation on that wikipedia page. If you give us a regex, we could try blocking that with AbuseFilter (assuming it actually works...). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:12, 29 December 2021 (UTC)<br />
<br />
::The automation is doing a bot, which does regex matching. The bot reports it on the aforementioned page so it can be reviewed since false positives are a thing. We are not as big as wikipedia anyways, so just having something report it might even be a bit too much. The other part is users reporting accounts since a bot can not possibly catch everything. There is a list of regexes that the bot uses though: [[Wikipedia:User:AmandaNP/UAA/Blacklist]]<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:53, 29 December 2021 (UTC)<br />
<br />
:::I tried those patterns in [[Special:AbuseFilter/test]] using {{bc|<nowiki><br />
_regex := "INSERT_REGEX_HERE";<br />
action === 'createaccount' & accountname irlike _regex<br />
</nowiki>}}<br />
:::From 2021-12-22 it matched only three account creations.<br />
::: ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:58, 29 December 2021 (UTC)<br />
<br />
::::A little while ago I created <s>[[Special:AbuseFilter/16]]</s>. It blocks usernames matching [[w:User:AmandaNP/UAA/Blacklist]] and a few other words, <s>but not Unicode ranges</s>. So far it has 49 hits. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:40, 2 February 2022 (UTC)<br />
<br />
:::::The account name regex matching is part of [[Special:AbuseFilter/15|AbuseFilter/15]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:07, 24 September 2022 (UTC)<br />
<br />
:::Using [[Wikipedia:User:AmandaNP/UAA/Blacklist]] results in blocking more than we may want. The user caught in [[Special:AbuseLog/36741]] reported the issue in [[ArchWiki:IRC|#archlinux-wiki]]. As can be seen in [https://wiki.archlinux.org/index.php?title=Special:AbuseLog&wpSearchFilter=15], some names that do not deserve being blocked.<br />
:::Should we curate the Wikipedia regex or build our own?<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:07, 24 September 2022 (UTC)<br />
<br />
::::I [[Special:AbuseFilter/history/15/diff/prev/237|removed a few things]] from [[Special:AbuseFilter/15|AbuseFilter/15]] for now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:22, 24 September 2022 (UTC)<br />
<br />
:::::[[Special:AbuseFilter/history/15/diff/prev/240|Removed one more]] following a request on [[ArchWiki:IRC|#archlinux-wiki]].<br />
::::: Perhaps using [[Wikipedia:User:AmandaNP/UAA/Blacklist]] in AbuseFilter was not the best idea.<br />
::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:15, 30 November 2022 (UTC)<br />
<br />
== Visual editor ==<br />
<br />
''[Moved from [[Help talk:Editing#Visual Editor]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:22, 23 September 2020 (UTC)]''<br />
<br />
:Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 12:54, 18 September 2020 (UTC)<br />
<br />
::AFAIK no one has proposed adding a visual editor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:28, 18 September 2020 (UTC)<br />
<br />
:::Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 17:39, 23 September 2020 (UTC)<br />
<br />
::::You already have :) And I gathered that you're talking about [[mw:Extension:VisualEditor|Extension:VisualEditor]].<br />
::::MediaWiki 1.35.0 [https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-September/000259.html will be released this week], so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.<br />
::::The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create [[mw:Help:TemplateData|TemplateData]] for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:43, 24 September 2020 (UTC)<br />
<br />
== Outdated pages in the DeveloperWiki ==<br />
<br />
I have encountered [[DeveloperWiki:Linux Conferences]] which is horribly outdated. I hereby request the deletion of the page. I asked about this in the [[ArchWiki:IRC|IRC channel]] and was advised to take this here by [[User:Svito]], which also mentioned that it might make sense to discuss some other, more general questions here:<br />
<br />
# Who is responsible for those?<br />
# Where to nag people to update/archive them? (My comment on this: I already asked on the talk page of a [[DeveloperWiki:Articles Linked from Website|DeveloperWiki article]] to remove a bit from the page because it has a dead link (as you all might have noticed, I like to fix dead and broken links).)<br />
# There are some pages in the DeveloperWiki with one or multiple issues (mostly broken/dead links and outdated stuff), what should be done about that? It clutters the statistics a bit in my opinion<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:23, 15 February 2021 (UTC)<br />
<br />
:# [https://archlinux.org/people/developers/ Developers] are responsible for DeveloperWiki.<br />
:# Refer to 1.<br />
:# Generally we try to refrain from touching DeveloperWiki (that's why it's in such a horrible shape). If you want to change something in a page, it's better to ask a [[Special:ListUsers/archdev|developer]] to do it.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:21, 15 February 2021 (UTC)<br />
<br />
::The DeveloperWiki is basically a wild west. Discussions on talk page will be ignored for the most. The pages are not updated for ages. As the pages are public, the users may want to improve/update the content on such pages if they find it relevant. But users basically are unable to do so. For example, I wanted to update info in the [[DeveloperWiki:UID_/_GID_Database]]. I asked in irc channel my request, but I was told "The devwiki isn't there to teach the general userbase about anything". Then I cannot see a reason to show the page to non-developers users. And I was told "Why hide it?".<br />
::From the reader's perspective of view, such pages are uneditable junk. And no one is going to update it: developers do not care or do not have time, and the developers users are a really little number of people.<br />
::So I think either some pages should be hidden (so in the main wiki userspace users will create an "updatable" version) or info on such pages should be editable in some way (probably by moving some pages to normal namespace). What do you think? [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 16:25, 8 May 2021 (UTC)<br />
<br />
:::Pages in the DeveloperWiki are written by developers for developers, i.e. not for general userbase. From my point of view, they are already "hidden" behind the DeveloperWiki: prefix. If this is not obvious enough, maybe we should make it more understandable somehow.<br />
:::As for the [[DeveloperWiki:UID_/_GID_Database]] page, its purpose is/was to allocate numbers for specific packages. That's it. The documentation of what these users and groups are for and how they should be used belongs to separate pages dedicated to the relevant package. If it is a general system group, it would be described in [[Users and groups#Group list]].<br />
:::— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:18, 8 May 2021 (UTC)<br />
<br />
::::In theory, my understanding was the pool of people both qualified to edit it, and capable of actually doing so, was supposed to be greatly expanded by allowing TUs to do so, but this was waiting on "permission models" of some sort? [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 01:21, 31 May 2021 (UTC)<br />
<br />
:::::I don't think giving TUs access to DeveloperWiki was ever considered from the wiki administrator side. The "privileged" [[ArchWiki:Access levels and roles|access level]] was created and assigned to developers with a different motivation. Though now that it exists, it can be used for such purpose, but such decision must come from developers. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:14, 31 May 2021 (UTC)<br />
<br />
::::::The problem with that, unless we create yet another access level, is that 59 TUs would get "privileged", which can edit the same pages as cosysop (reserved to wiki maintainers). So we'd undo the whole effort of not giving unnecessary wiki-wide permissions to accounts that only need it to edit a few select pages. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:22, 12 June 2021 (UTC)<br />
<br />
:[[User:Jelly]] composed [https://md.archlinux.org/KtVq1GIiSCSQHewRI1IazA a list of pages that can be removed]. I think we can mark them for archiving (or redirection if possible) and per [[ArchWiki:Archive]], archive them after a week. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:40, 15 August 2021 (UTC)<br />
<br />
:: This discussion has been inactive for a while, let's consider it closed ? The page that started the topic is [[Special:Diff/698384|archived]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:04, 4 March 2022 (UTC)<br />
<br />
:::The marked pages in the linked list have not been archived (or even flagged for archiving) yet. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:40, 4 March 2022 (UTC)<br />
<br />
:::: My bad, you are right there are many pages left on the link... But from the content of some of them I think they are still in use (the first that comes to my mind is [[DeveloperWiki:Building in a clean chroot]]). We have to migrate them then ? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 14:15, 4 March 2022 (UTC)<br />
<br />
:::::It says: ''Pages checked are marked for removal''. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:18, 4 March 2022 (UTC)<br />
<br />
:It is possible to move the DeveloperWiki out of ArchWiki. DeveloperWiki should not actually be a part of ArchWiki. ArchWiki is not a place just for developers. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 19:17, 4 March 2022 (UTC)<br />
<br />
::I don't think we should do that. Arch Linux developers are part of Arch Linux, so there's no harm in them having their little corner in the ArchWiki. That said, for projects on [https://gitlab.archlinux.org gitlab.archlinux.org], some already use the project specific wikis available there. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 19:24, 4 March 2022 (UTC)<br />
<br />
== Creation of a hardware team ==<br />
<br />
As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The [[Help:Laptop page guidelines|Laptop page guidelines]] have been created and all uncompliant pages have been flagged.<br />
<br />
There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are [[Dell TB16|docks]] on the wiki, [[TerraTec Cinergy T RC MKII USB Stick|exotic USB devices]], [[Hauppauge Nova-T Stick|more exotic USB devices]], [[Vertex VW110L - Ufon|modems]] and more. Also tablet PCs and apparently ARM-devices (yes [[User:nl6720]], I agree that they do not belong here but they are still hardware pages).<br />
<br />
Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.<br />
<br />
There are currently maybe two people (me and [[User:DerpishCat]]) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.<br />
<br />
The goals are:<br />
# Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how<br />
# Make current tasks public so others know what we need help with<br />
# Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.<br />
<br />
The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g [[Help:Style]], some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:49, 7 April 2021 (UTC)<br />
<br />
:So you want to create [[ArchWiki:Hardware Team]]? With only two team members, I think it's a little too soon for that.<br />
:If you simply want a central discussion page, you can use [[Category talk:Hardware]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:59, 7 April 2021 (UTC)<br />
<br />
== Abusefilter ==<br />
<br />
As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.<br />
<br />
I am in favor of adopting [https://en.wikipedia.org/wiki/User:AmandaNP/UAA/Blacklist the "block"list that Wikipedia uses], with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:<br />
<br />
* If certain derivatives (e.g Manjaro) or other distros are in the name.<br />
* Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.<br />
* This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.<br />
<br />
Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like [https://en.wikipedia.org/wiki/User:ClueBot_NG ClueBot NG] but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.<br />
<br />
It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:50, 28 April 2021 (UTC)<br />
<br />
:We should also enable [[mw:Extension:AntiSpoof]]. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 30 April 2021 (UTC)<br />
<br />
::I agree with that. That looks like it will be beneficial, too.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:01, 30 April 2021 (UTC)<br />
<br />
== Visited links are gray ==<br />
<br />
This makes the links blend in with the regular text on the page, especially when using [https://darkreader.org/ Dark Reader].<br />
{{Unsigned|07:30, 16 May 2021 (UTC)|Glibg10b}}<br />
<br />
: From an accssibility/usability perspective, this is a terrible choice; something with some contrast for colourblind or visually impaired people would be a much better choice. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 06:00, 31 May 2021 (UTC)<br />
<br />
:: Which color would you prefer for visited links? The [https://archlinux.org/ archweb] site currently uses the same color for visited and unvisited links, which effectively disabled highlighting visited links... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:52, 4 June 2021 (UTC)<br />
<br />
::: Sorry, I missed this reply :p I would probably opt for the standard purple: it should provide sufficient contrast for low/impaired vision readers and will be familiar to anyone from the early web. No idea how graphic designers will react to it tho... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:22, 2 March 2022 (UTC)<br />
<br />
== How to change packaging policies ==<br />
<br />
I recently made a note about the [[Talk:Wine package guidelines|Wine Package Guidelines talk page]] because I want to modify them slightly. I'm new to editing here, so I was wondering if there was a proper procedure for doing this. Do I simply take initiative and watch for if people complain?<br />
<br />
[[User:VinceUB|VinceUB]] ([[User talk:VinceUB|talk]]) 07:42, 5 August 2021 (UTC)<br />
<br />
== Long, cluttered and hard to maintain pages ==<br />
<br />
Unfortunately there are some pages on here which are hard to maintain because:<br />
* It is hard to validate the information without the specific hardware or software (which tends to be proprietary and may cost a lot)<br />
* No one knows if this still applies since the information may be ancient and the above still applies<br />
* There is so much content that transformed the page into something that is not feasible to maintain.<br />
<br />
These are pages where lots of users contributed their individual solutions to and this basically spiralled out of control. The worst pages in this category are:<br />
<br />
* [[Mac]]<br />
* [[Steam/Game-specific troubleshooting]]<br />
* Some laptop vendor pages, but this might be a different although vaguely similar topic. These have grown into spreadsheets and some are pretty bad.<br />
** [[Laptop/Acer]] is by far the worst.<br />
<br />
Other pages which are not as bad yet but should be monitored:<br />
<br />
* [[PCI passthrough via OVMF/Examples]] - was pruned recently<br />
* Laptop vendor pages (e.g [[Laptop/Lenovo]]) - mentioned in [[Category talk:Hardware]], part of a bigger problem<br />
* [[Dotfiles]]<br />
<br />
Both lists are unfortunately yet incomplete I suspect.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 01:23, 10 August 2021 (UTC)<br />
<br />
:The same applies to almost all troubleshooting sections and pages: [[Network configuration/Wireless#Troubleshooting drivers and firmware]], [[Bluetooth#Troubleshooting]], [[PulseAudio/Troubleshooting]], [[Firefox#Troubleshooting]], [[NVIDIA/Troubleshooting]] etc. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:56, 10 August 2021 (UTC)<br />
<br />
::At least for troubleshooting sections, [[Help:Style#"Troubleshooting" section]] says to link the bug or create a bug report if there isn't any. There's nothing we can do for sections that don't include any bug links. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:50, 10 August 2021 (UTC)<br />
<br />
== User menu for logged out users ==<br />
<br />
ArchWiki is now using the [[mw:Reading/Web/Desktop Improvements|new Vector skin]] [https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/1ab66fbe90a32284d6b72995bdb7ae43f0d31069 by default]. That includes the [[mw:Reading/Web/Desktop Improvements/Features/User menu|user menu]].<br />
<br />
For logged out users, the user menu shows "Pages for logged out editors ([[Help:Introduction|learn more]])".<br />
<br />
The text can be customized in [[MediaWiki:vector-anon-user-menu-pages]] and the link title in [[MediaWiki:vector-anon-user-menu-pages-learn]]. The "learn more" link is hardcoded to [[Help:Introduction]] in MediaWiki 1.37, but it will use [[MediaWiki:vector-intro-page]] in some future release (see [[phab:T290813]]). There's also [[MediaWiki:vector-anon-user-menu-pages-label]], but I'm not sure where that is shown.<br />
<br />
So now we should decide what to do with these:<br />
<br />
* [[MediaWiki:vector-anon-user-menu-pages]]<br />
* [[MediaWiki:vector-anon-user-menu-pages-learn]]<br />
* [[MediaWiki:vector-anon-user-menu-pages-label]]<br />
* <s>[[Help:Introduction]]</s><br />
* [[MediaWiki:vector-intro-page]]<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:59, 21 December 2021 (UTC)<br />
<br />
:[[Help:Introduction]] could probably be redirected to [[{{ns:PROJECT}}:Contributing]]. ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:50, 26 December 2021 (UTC)<br />
<br />
::I moved it to [[MediaWiki:vector-intro-page]], the target is still the same: [[ArchWiki:Contributing]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:54, 6 July 2022 (UTC)<br />
<br />
== Syntax highlighting in code blocks ==<br />
<br />
MediaWiki since version 1.21 has the [https://www.mediawiki.org/wiki/Extension:SyntaxHighlight SyntaxHighlight] extension bundled. It adds the '''<nowiki><syntaxhighlight></nowiki>''' block, which lets editors add code blocks with syntax highlighting in specified language for easier readibility. As ArchWiki is a highly technical wiki, with configuration file and script snippets sprinkled everywhere, I was surprised to find this wasn't enabled yet.<br />
<br />
Is there a specific reason for this omission? If not, I'd happily welcome this addition to the wiki. -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 12:39, 15 February 2022 (UTC)<br />
<br />
:I wouldn't say there's a "specific reason for this omission". It simply was never enabled. Even if we do get it enabled, we would not want it to be used directly in pages, only through templates. I think it should be possible to adjust [[Template:bc]] and [[Template:hc]] to add an additional parameter to specify syntax highlighting language. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:36, 17 February 2022 (UTC)<br />
<br />
::That sounds reasonable, I understand that the parameter would be directly passed to the tag and would have to be one from the list of languages that '''SyntaxHighlight''' supports. Assuming that approach, I looked at the extension's parameters to check which ones also would be useful to expose via template on ArchWiki. So:<br />
::* '''lang''' - specifies lexer to use for highlighting, e.g. ''python, cfg, pacmanconf'' or one of [https://pygments.org/docs/lexers/ many others]. Would be useful in '''<nowiki>{{bc}}</nowiki>''', '''<nowiki>{{hc}}</nowiki>''', possibly even '''<nowiki>{{ic}}</nowiki>''' (for e.g. shell one-liners, using ''shell-session'' lexer so the '''#''' prompt is correctly interpreted)<br />
::* '''highlight''' - highlights specified line(s), e.g. ''3-5, 7''. I can see this being useful in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>''' for e.g. showing context of a config file section while highlighting the important/modified lines. <br />
::* '''line''' and '''start''' parameters enable showing line numbers and choose the start of the shown numeration, respectively. I don't see it being particularly useful on ArchWiki, especially since the '''highlight''' parameter works fine without them. If one finds a plausible usecase, I guess they could be exposed in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>'''.<br />
::* '''class''', '''style''' and '''inline''' parameters control style and are already covered by the existing templates, so no need to consider them (except maybe when modifying the templates' code).<br />
::I wanted to be helpful and try my hand at drafting what the new template code could look like. However, I can't tell whether the '''<nowiki><pre></nowiki>''' hack used in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>''' will still be needed with the extension enabled without trying it out. If not, this change would certainly make these templates' code easier to read and understand. -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 10:39, 17 February 2022 (UTC)<br />
<br />
:::I don't think we should care about any parameter other than {{ic|lang}}.<br />
:::Also adding {{ic|wfLoadExtension( 'SyntaxHighlight_GeSHi' );}} to [https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/templates/LocalSettings.php.j2 LocalSettings.php] will not be enough. The extension requires <s>{{Pkg|python-pygments}}</s> {{Pkg|python}}. ''I think'', it would need to be added to https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/tasks/main.yml#L20.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:26, 21 February 2022 (UTC)<br />
<br />
::::Actually, I was wrong. pygmentize is shipped in {{ic|extensions/SyntaxHighlight_GeSHi/pygments/pygmentize}}, so only {{Pkg|python}} is needed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:34, 21 February 2022 (UTC)<br />
<br />
:::::Thinking about it more, it doesn't feel quite right to have a python binary running on the server just to provide syntax highlighting for a few code blocks. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:14, 10 April 2022 (UTC)<br />
<br />
:::::: There is another way: [https://www.mediawiki.org/wiki/Extension:Highlightjs_Integration Highlightjs integration], which, instead of doing the highlighting server-side via pygmentize, shift the burden to the client using highlight.js. AFAIK, it's intended to be a drop-in replacement for SyntaxHighlight, so the syntax and functionality should be nearly identical. Obvious cons of this solution are:<br />
::::::* not being bundled with Mediawiki, which adds more maintenance weight of downloading and updating the plugin separately<br />
::::::* making ArchWiki pages heavier due to added JS<br />
::::::But if including Python binary is the main issue, highlight.js is an alternative to that. -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 07:47, 10 April 2022 (UTC)<br />
<br />
:::::::It's not a real issue, but just my subjective feeling. Last time I asked, DevOps were ok with python on the server. I'll go with whatever solution other Maintenance Team members support. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:59, 11 April 2022 (UTC)<br />
<br />
::::::::I would love to see some kind of syntax highlighting extension in the wiki. However I also think it makes sense to have '''lang''', '''highlight''' and '''line''' as options to configure. They are vital configuration options to any good syntax highlighting. [[User:Segaja|Segaja]] ([[User talk:Segaja|talk]]) 20:07, 4 July 2022 (UTC)<br />
<br />
::::::::: I opened a MR to enable the extension: <s>https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/667</s> ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:22, 29 December 2022 (UTC)<br />
<br />
::::::::::👍 from me for enabling with the '''lang''' parameter, '''line''' is of dubious use since every change would have to be reflected on all text referencing the line number, while '''highlight''' is clashing a little with our existing usage of bold. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:38, 30 December 2022 (UTC)<br />
<br />
:::::::::::After some testing I got: {{ic|<nowiki>{{#tag:syntaxhighlight|{{{1|{{META Error}}}}}|lang={{#if:{{{lang}}}|{{{lang}}}|text}}}}</nowiki>}}. The issue with it is that you can't use MediaWiki markup inside it :/ ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:17, 30 December 2022 (UTC)<br />
<br />
::::::::::::Now that's something of a blocker since we rely on italics for pseudo variables :/ --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 13:33, 30 December 2022 (UTC)<br />
<br />
::::::::::As [https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/667#note_84746 pointed out by Lahwaacz], there are issues with [[mw:Extension:SyntaxHighlight|Extension:SyntaxHighlight]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:55, 5 January 2023 (UTC)<br />
<br />
== Adding code of conduct and terms of service links in the footer ==<br />
<br />
According to [[mw:Manual:Footer#Add links to the footer]] additional footer links can be created by editing {{ic|LocalSettings.php}}. I think it would be a good idea to links to the [[archlinux-service-agreements:code-of-conduct|code of conduct]] and [[archlinux-service-agreements:terms-of-service|terms of service]].<br />
<br />
I've prepared <s>https://github.com/archlinux/archwiki/pull/53</s> https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/583. Thoughts?<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:06, 21 February 2022 (UTC)<br />
<br />
:I like the idea. What determines the order of the links? Can we order the three "Terms" links alphabetically? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 25 June 2022 (UTC)<br />
<br />
::No idea. From what I understand, the hook simply appends. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:57, 25 June 2022 (UTC)<br />
<br />
:::Seems like so, it's still better than nothing. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:57, 31 December 2022 (UTC)<br />
<br />
== Moving pages to User page ==<br />
<br />
In [[Help:Procedures#Remove_an_entire_page]], it says:<br />
<br />
* New but inappropriate page:<br />
** if inappropriate because of spam or other clearly malicious content (evaluation is made by an Administrator), it is [[mw:Help:Sysop deleting and undeleting|deleted]] right away;<br />
** in the other cases, e.g. irrelevance to Arch, the article should be:<br />
*** marked with [[Template:Merge]]; or<br />
*** marked with [[Template:Redirect]]; or<br />
*** marked to be moved as a subpage of its author's User page with [[Template:Move]] (or moved right away).<br />
* Old article become obsolete:<br />
*# mark with with one of the following, in order of preference:<br />
*#* [[Template:Merge]];<br />
*#* [[Template:Redirect]];<br />
*#* [[Template:Archive]];<br />
*# wait at least 7 days;<br />
*# in absence of objecting discussions, or when these eventually resolve in favor of removal, perform the proposed action;<br />
*#* when redirecting, consider following [[#Deal with talk pages after redirecting a page to another]] and [[#Fix double redirects]];<br />
*#* when archiving, follow the instructions in [[ArchWiki:Archive]].<br />
<br />
Here is my understanding of above rule:<br />
1. If an article could be markd with [[Template:Merge]] or [[Template:Redirect]], prefer such action. Only use [[Template:Move]] when an redirect is not appropriate. So could we both agree that Redirect is better than User page? Maybe we can make it more clear here.<br />
2. If an article is an old page/is already edited by more than one contributor, it should not be moved to author's User page. We can relax this rule and create a rule fix both new and old pages as long as a [[Template:Move]] is only used as the last option. <br />
<br />
So in my opinion, below pages could/should be merged and redirected: <br />
* [[NVIDIA instalación de controlador privativo]] was in direct contradiction of the existing [[NVIDIA]] page and did not follow most rules<br />
* [[Adding a trusted CA certificate (简体中文)]] which put into the main space a translation of a user page On the other recently created pages, I see <br />
* the move of [[User:Dginovker/System76 Pangolin]] took 5 months<br />
* the move of [[User:KevinSanchez/FastGit]] waited nearly a year<br />
* the move of [[User:Dragonwater/不支持 Linux 的电脑 (简体中文)]] waited a month<br />
* the move of [[User:Tsuibin/Devtools]] was done the next day, but the page creator has never contributed again to improve his copy/paste from the man page<br />
* the move of [[User:CodeLog/Stress++]] took two years<br />
* the move of [[User:Darksaber/NetSim]] too nearly a month<br />
* the move of [[User:ArcherBTW/Brook]] took 8 months<br />
* the move of [[Special:Undelete/User:Olliver/Olliver's New Install Guide]] was done on the next day, since it was an unsupported installation guide<br />
* the move of [[User:Jak/Dell XPS 17]] took nearly two years<br />
* the move of [[Special:PermanentLink/718030|User:Lanems/Logitech Wireless Mouse M720 connect via bluetooth]] took two weeks<br />
<br />
Remove directly:<br />
* [[Jujudusud]] was an obvious mistake<br />
* the move of [[User:Dybdeskarphet/Template:Expansion (Türkçe)]] took two months<br />
* the move of [[User:JrEvans/Tips]] was done in the hour, since it clearly does not belong in the main space<br />
<br />
Remove user's page to reduce duplication:<br />
* the move of [[User:Taslack/MSI GS75]] took 5 months and was followed in the next month by the creation of a proper [[MSI GS75]] cited above<br />
--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 06:17, 6 October 2022 (UTC)<br />
<br />
: For the pages where you have preferred a redirect/merge, I <br />
:would not have the same reading for the following: <br />
:* [[NVIDIA instalación de controlador privativo]] could indeed be made as a redirect to [[NVIDIA (Español)]], except the target page already redirects to [[NVIDIA]], so it would only amount to create a new unused redirect of uncertain value… <br />
:* [[Adding a trusted CA certificate (简体中文)]] does not belong in the main space, since it is a translation of a page which has always been in userspace… <br />
:* [[User:Dginovker/System76 Pangolin]] has no where to be merged to, since [[Laptop/Other]] does not have a dedicated section for System76 laptops… It also has only a single sentence of low documentary value, for which an equivalent is already present on [[AMDGPU]] and [[ATI]]. <br />
:* [[User:KevinSanchez/FastGit]] was initially flagged for archival, since the page had nothing Arch-specific in it, and there is no good place to redirect it to. Maybe it could have fit somewhere in [[List of applications]]? But where?<br />
:* [[User:Tsuibin/Devtools]] is a copy/paste from {{man|7|devtools}}, it has no good place to be merged/redirected to.<br />
:* [[User:CodeLog/Stress++]] was initially flagged for merging with [[Stress testing]], but creating a redirect for a single package mentioned in a page feels weird to me<br />
:* [[User:Darksaber/NetSim]] is a two line page, has nowhere to be merge to, and describes a proprietary software, that is made to run on Windows and is untested by the page author on Wine, I fail to see how this would be relevant ever to Arch Linux<br />
:* [[Special:Undelete/User:Olliver/Olliver's New Install Guide]] would only amount to create a new unused redirect of poor value… <br />
:* [[User:Jak/Dell XPS 17]] was flagged by its creator as a work in progress 2020-09-02. It might have been better as a redirection to [[Dell XPS 17 (9700)]], but it would have poor value<br />
:* [[User:Lanems/Logitech Wireless Mouse M720 connect via bluetooth]] is written like a blogpost, only contains the authors notes on his device and simply links to a YouTube video about Debian. To me this should have been deleted outright as spam/promotional content<br />
:am unsure: <br />
:* [[User:ArcherBTW/Brook]] was initially flagged for merging with [[List of applications/Security]], but it would have been better to redirect to [[List of applications#Proxy servers]]. Is this software popular enough to warrant a dedicated redirect? No other pages on the wiki talk about it. <br />
:* [[User:Dragonwater/不支持 Linux 的电脑 (简体中文)]] translates to "Computers that do not support Linux". There is no English page with this title, but the content might have been a better fit for a new section in [[rEFInd]] instead of creating a dedicated page for it. <br />
: For the page you would have removed, I'm agreeing with you on all of them. <br />
: To get back at the rewording of the rules, how about simply adding "in order of preference" to highlight the fact that moving to userspace is the last resort? <br />
: I'm agreeing with you that pages that have become obsolete or have multiple contributors (but I would like to highlight the fact that I think a contribution to the content is different than a simple fix to the style) should not be moved to a user's page. <br />
: --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:28, 6 October 2022 (UTC)<br />
:: Great! I always think moving some pages into user's page is something like a technical debt. It make maintaining easy right now but someday later we have to face them. But I do not have enough time/evidence to convince other admins. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 05:04, 12 October 2022 (UTC)<br />
<br />
:::I understand what you're getting to, and I'm glad to see you want the whole wiki to get better, but I'm not sharing that analysis. User pages are not visible by default in searches, are not indexed by search engines, and touching them sends a mail to the account owner by default: unless they require an intervention (e.g. archiving a page, mass replacing links) I believe they should stay how their "owner" set them, even if they become outdated or wrong. If anything, they behave like the Developer's wiki namespace to me: a place to be actively ignored. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:11, 12 October 2022 (UTC)<br />
<br />
::::Just because they don't show up in search by default doesn't mean they're not there, rotting, just outside everyone's sight. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:49, 12 October 2022 (UTC)<br />
<br />
::::: That's true, but do we want to do something about it, and if so, what exactly do we consider acceptable actions on a user's page? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 15:13, 12 October 2022 (UTC)<br />
<br />
::::::It is just a dark corner.<br />
::::::*Some pages are complete not related to Arch, so it should be discouraged.<br />
::::::*Some pages are related to Arch but not fit main pages. Some pages are draft dropped by owner or moved by maintainers from main namespace. Sometime it still contains valuable information sometime it does not.<br />
::::::Because we have rule or consensus that a user's page is unremovable, unarchivable or even un-editable by anyone else, they are keeping growing which is a bad thing in years later. I am thinking to relax the un-editable rule. For example if a page is marked as draft or moved from main pages, just treat them as normal pages. Thoughts?<br />
::::::--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:21, 13 October 2022 (UTC)<br />
<br />
::::::: Yeah, it reminds me of the laptop pages before we started caring again for them. <br />
::::::: Given how ''that'' can of worms is going on, I'm not sure we have any valuable content to be found in the userspace, but if only one page has something that is missing from the main pages it should be done. <br />
::::::: Do we start enforcing the code of conduct for user pages? This would mean that [[User:Cmsigler/RISC-V]], [[User:VARGUX]] or [[User:Pongo1231/Arch on Steam Deck]] should not exist then, since the first one is about an unsupported architecture, the second is an unofficial installation guide and the last one documents a derivative distribution. <br />
::::::: I'm of the opinion that some leeway should be given for these situation, in particular for the unsupported architectures, since we may want to expand on day beyond x86_64. <br />
::::::: On drafts, I'm not sure editing the user's pages would do any good: either it has content that is missing from a main page and that should be merged directly without touching the userspace or it is shaped enough to be moved back into the main space before updating it within the mainspace. This does not apply to active drafts, where contacting the "owner" of the page one way or an other before working with him on the draft feels like a better approach. <br />
::::::: Deleting, moving back to mainspace and archiving in a single day / with a week long delay feels fine to me for pages that were at one point in the main space and got moved to the userspace. <br />
::::::: --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:40, 13 October 2022 (UTC)<br />
<br />
:::::::: It is like a round trip. What I propose is that we should not increase non-usefully pages into user's page because currently no one care about them. Whenever I saw someone moved some pages into user's talk page, I always wonder why such page is moved here instead of just archive/delete them? What value the original author what to add? Does the page still contain a tiny usefully info so that even the maintainer can not just archive it.<br />
:::::::: For user's pages the user added themself, we can add somewhere that it should related to linux/Arch linux. I think unofficially supported packages/arch/distro is fine.<br />
:::::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 05:35, 25 October 2022 (UTC)<br />
<br />
:::::::::I'm not strictly against that, but in my mind archiving was reserved for old articles that had become obsolete. I.e. it is not a catch-all for bad content but a repository of previously good pages that are no longer relevant. <br />
:::::::::E.g. I don't see a good reason to archive [[User:Dginovker/System76 Pangolin]], [[User:Tsuibin/Devtools]] or [[User:Darksaber/NetSim]]. <br />
:::::::::On the opposite side, [[User:Edvinonan/NVIDIA instalación de controlador privativo]] would have only amounted to create yet an other unused redirect of disputable value, since nothing is this page is worth keeping but the name could be used to redirect to [[NVIDIA#Installation]]. We already have [[#Remove redirect page with bad title|a good amount]] of bad redirects and I'm not too happy about creating new ones instead of signaling to the writer that his page is not following [[Help:Editing#Creating pages]]. <br />
:::::::::Speaking of "caring about" user pages, I'd be OK to help do ''something'' about them, but I don't really see ''what'' can be done without being over reaching. <br />
:::::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:18, 25 October 2022 (UTC)<br />
<br />
== Procee update for bad translations ==<br />
During the migration of zh-hans translation to its own wiki, I found some translated pages are redirected to English pages. The redirect process follow [[ArchWiki:Translation Team#Dealing with old translations]] so it is perfect fine from a maintainer's view:<br />
* They are out of date, or many sections are not translated at all.<br />
* It seem no one care about them for at least a year<br />
* They are maintaince burden, consume valuable time to fix out-of-date link/packages<br />
<br />
But as a translator, I find maybe we are push too hard on translations. Some pages should be keep because:<br />
* Although some sections are out of date, other sections especially installation and configuration sections are mostly fine. <br />
* No one care about the out of date pages because lack of time and because sometime the out of date sections are not important enough. <br />
* If the pages are redirecd to English pages, the interlanguage link is gone. Some non-English readers just want to find how to install and use the default configuration. <br />
<br />
Below is my thoughts about dealing with above problem:<br />
* Maintainers should mark the page with out-of-date/bad translations, the same as current process<br />
* If a translation page is marked as out-of-date, it is local teams responsibility for further manual edits. I means the wiki bots will process them as before but wiki maintains could just ignore them.<br />
* The choice whether to redirect it to English page should be made by local team. The choice should be made case by case based on page content, not by a fix flag time. <br />
<br />
Any thougts? --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:14, 11 December 2022 (UTC)<br />
<br />
:In no particular order, here are a few remarks and questions. <br />
:*The rule has been discussed over the course of 2021 in [[Special:PermanentLink/750896#Dealing_with_ancient_translations]] and had received either explicit approbation or indifference, then was applied in the first half of 2022. Rules should always be open to modification and be challenged when required, but this feels like a recent enough addition so the consensus would probably not change. <br />
:: > This case is a little special. The above discussion lack input from i18n translation team. So below is my input as zh-hans translator, not as a administor.<br />
::: Thanks for your input, since I'm the major contributor to the French translation team in the last year, I can see the fear of "having the rug pulled out from under you". --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:46, 12 December 2022 (UTC)<br />
:*Keeping existing pages up to date '''should be prioritized''' by the translators over creating new pages. Especially when using the proper [[Template:TranslationStatus]], following the changes of the original page is less time consuming than the whole translation of a new page.<br />
:: > It should base on a contributor's interest. Some contributor only want to translate large trunk of text. They do not want to compare between two different text. A wiki should encourge both type. A wiki fix this problem by enlarge both type of user base. <br />
::: I think the maintenance side of the translation is not being given enough importance to the eyes of contributors, but I'm not saying it should be the only thing they are allowed to do. For example, see the tip in [[Help:Procedures#Request solving]] where we suggest an order of importance in handling the tasks from [[ArchWiki talk:Requests]] --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:46, 12 December 2022 (UTC)<br />
:*If the page is not redirected to English page, the interlanguage link stays, but the reader is provided with out of date information. This should be evaluated on a page-by-page basis, but packages can be merged or change name, and the page then requires maintenance to be of any use regarding the "Installation" section. The same reasoning applies to the configuration when major changes occur, be they from upstream or packaging changes. Some of these could be handled by a non-native speaking maintainer, while more involved updates would require a translator. <br />
:: > As said before, an out of date flag should be added on top of the page. The user will be informed by this flag.<br />
::: I don't have a counter-argument to that, let's just hope it does not cause non-English speaker complaints about the relevance of the information we provide. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:46, 12 December 2022 (UTC)<br />
:*IMO, the translator/maintainer relationship should be symbiotic: the more eyes on a page and its translation, the better it gets in the end. If we bar maintainers of touching pages when they are out of date, we let pages rot unnecessarily (e.g. when a simple change can be reflected on the translations like a package changing name, or the removal of an out of date section) and adds more work on the shoulder of translators which diminishes the time they can dedicate to other tasks (which fits in nicely with your remark about translation not being updated because of the lack of time). <br />
:: > Maintainers should not changing/rediect a page without reading both language. For example, I can read both zh-hans and English, so I could redirect a page based on my reading and how out of date the page really is, not based on a flag date. <br />
::: I don't share that analysis. After enough time has passed, translations are far enough from the active page that starting from scratch is faster than salvaging what's already there. Any page in that state should be allowed to be redirected to the English page. I would love to have your view on ne last two points I have raised. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:46, 12 December 2022 (UTC)<br />
:*What do we do for translations where there are no active translators? <br />
:**E.g. the Greek translation has a single contributor in the last years and they have not edited since 2021-12-03. <br />
:**The [[Installation guide (Ελληνικά)]] is "only" two years out of date for now, when can we consider as a rule of thumb that a page is abandoned? <br />
:**Judging on by-content basis sounds good and well, but how can one judge the content of a translation if they do not speak the language '''and''' there are no translators left to decide? <br />
:**Do we have to wait like what happened to [[General recommendations (Ελληνικά)]] (or [[MySQL (Italiano)]]) which went mostly untouched for 10 years? <br />
:*Do we let local teams do nothing with the pages forever? As discussed in [[#Moving pages to User page]], letting old pages pile up and grow in number is like leaving around technical debt in a software project: it will one day have to be dealt with. <br />
:**[[Special:PermanentLink/713400|XScreenSaver (Español)]] was flagged since 2017, not updated since 2013 and looked nothing like the English page, [[Ext4 (Español)]] had no updates since roughly 2012, was flagged since 2020-12-12. The Spanish translation team is not inactive, but I'm not sure how the "noise" of maintainers asking about their old and non prioritized pages flagged with [[Template:Bad translation]] would be received as opposed to simply redirecting pages to up to date information if no one has cared for them in a long while.<br />
:**Pages flagged with [[Template:Translateme]] or [[Template:Bad translation]] often stay flagged for years without being updated. Two more examples other than the Spanish pages above: [[QEMU (简体中文)]] was flagged 2017-11-28 but only got updated between 2020-09 to 2021-01, [[CUPS (简体中文)]] was flagged in 2012 but only got updated in 2020. <br />
:**[[Cursor themes (简体中文)]] received no updates since 2014, was flagged since 2021-07-06 when it got redirected 2022-01-21, though happily a translator picked the page 2022-07-21 in the end. I think this is a good example of my point about prioritizing updating pages as opposed to creating translations for pages who do not already have one: if this page had been updated regularly, less total translation time would have been needed since it would have avoided the start from scratch in 2022. <br />
:--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 11:49, 11 December 2022 (UTC)<br />
:: The Chinese translation team checkd such redirected pages and the conclusion is that most of them is still usefully to Chinese users. So they build a bot to recover all such page in new zh-hans wiki. If a translator found them too hard to diff, they will re-sync and re-translate them.<br />
:: I discussed with current zh-hans wiki admins the reason why they want a seperate wiki with so much maintain effort. There are many reasons that I could argue with they. But below is the most significant reason that I could say nothing:<br />
:: "We feel current Arch Wiki is very hard to contribute to. It weight too much on perfectionism insteaf of usefully to end user." <br />
:: The departure is done for zh-hans. I think the move is good for both. Large maintaince burden is reduced for Arch wiki and zh-han team could make the contribution much easier and pages could be kept as long as they are usefull.<br />
:: The question is does other i18n team have such feeling? <br />
:: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:59, 12 December 2022 (UTC)<br />
<br />
:::Do they have specific examples of our perfectionism being the enemy of contribution? I'd love to see us improve that situation, since we are nothing without user contribution, and having too high of a barrier to entry would be detrimental to that. <br />
:::On the other hand, I can remember multiple exchange with users (though outside of translations) who simply disagree with established style rules (the most common ones being [[Help:Style#Package management instructions]] and [[Help:Style#systemd units operations]]) and where refusing to bend the rules is a net positive for the coherence/structure of the wiki as a whole. <br />
:::Thanks for sharing the sentiment so that we can make things better. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:16, 12 December 2022 (UTC)<br />
:::: Partial translated pages and some out of date pages are not perfect but very usefully to users. Partial translation is still greate contribution which are valuable and should be kept with best effort. The Chinese team create a bot script to recovery all pages that are redirect to English page (See [https://wiki.archlinuxcn.org/wzh/index.php?title=Special:%E7%94%A8%E6%88%B7%E8%B4%A1%E7%8C%AE/Y7n05h.bot&target=Y7n05h.bot&dir=prev&offset=2022-11-25+18%3A11%3A35%2B00&limit=250 those history]). It is waste of time of both maintainer's and translators. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 01:25, 13 December 2022 (UTC) <br />
:::::In the first pages on your link I find [[zh-hans:Kodi]] fully untranslated, [[zh-hans:Xen]] with only the section titles translated, what benefit do they provide? I also stumbled upon [[zh-hans:SonyEricsson samba sharing]] which is archived in English, is that voluntary to resurrect outdated content and add maintenance burden on your side? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:19, 13 December 2022 (UTC)<br />
:::::: The page template is there so that a newly translator has less to check (interlanguag link, category, headers) before a first contribution. It is not perfect, but it indeed make a easier start. <br />
:::::: For [[zh-hans:SonyEricsson samba sharing]], sure there are other such pages too. The bot recovered about 400 pages from history. And the bot creator forget to filter out the pages redirect to Archive. It take long time for someone to dig out the pages and remove them again. I will contact the team to see if they could create another bot to clear such pages. But so what, no one read them and no one is harm by it. Just take it easy.<br />
:::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 14:03, 13 December 2022 (UTC)<br />
:::::::I don't agree with that methodology, but I'm leaving you handle wiki.archlinuxcn.org as you intend on this point. I will just point out that for this specific page, it is a good example of what I see as wasted time, since the page was untranslated since 2015, as [[Special:Diff/563637]] shows, you replaced the whole content with the updated one from the English page on 2019-01-18 (un-doing the work that had been done to translate the section titles in Chinese), but no one worked on the translation again until it got redirected to the updated English page. The version imported in archlinuxcn.org is thus providing broken package links to the reader, and is [[Special:Diff/562357/753031|quite different]] compared to the English one. <br />
:::::::Sorry if my last question in particular, or even my general tone came out as vindictive, that is not my intention. I'm just having a hard time understanding how you balance the quality of translations we offer to readers of various languages with the expressed desire of keeping where possible the contributions, so I'm trying to pry a little to see what your reasoning is. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:37, 13 December 2022 (UTC)<br />
:::There is an opposite situation in Russian ArchWiki: no one reads russian articles because they are "out-of-date by default", regardless of their usefulness ¯\_(ツ)_/¯ -- [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 09:56, 12 December 2022 (UTC)<br />
:::: When I first come to Arch Wiki more than 10 years ago, Chinese forum has the same saying. "If you encounter any problems read English pages first". I am proud to say that this is not the case anymore. I think here are the most things that are done right:<br />
:::: 1. Use [[:Template:TranslationStatus]] to "Show translation status of i18n pages. Record the last translated history id of the English page. Provide a link to check diff after last translation id". Compared with just an out of date notice, a reader could know how old the translated page is. If the time is long ago, the reader could check how much the English page has changed. And for a tranlator, the could compare the history by a simple click.<br />
:::: 2. Make every page an contribution invitation. Also in [[:Template:TranslationStatus]], there is a link to Chines Translation Team. If readers want to contribute, they could find the how to easily. I myself subscribe to new page creation notice to make sure all newly created translation pages have TranslationStatus.<br />
:::: 3. There are an active local irc/matrix channel. Users will be guide to wiki pages. If an user report an issue about the wiki, it will be fixed. So we are somewhat confident that the hot pages and hot sections that most users read are fine. With enough eyes, all out of date info are shallow. We should fix out of date pages by attracting more users to contribute, not by removing the pages. <br />
::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:24, 13 December 2022 (UTC)<br />
<br />
:::::: This is all great for active teams, but does not provide a solution for translations where no one speaking the language is still active on the team. See the previous state of many Italian or Greek page. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:07, 13 December 2022 (UTC)<br />
::::::: Fine, then we can relax the rule. Maintainers first requst for reply in local teams page, if indeed no one is active and no one answers, maintains could just remove all out-of date i18n pages. I am totally fine with such conditions. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 14:03, 13 December 2022 (UTC)<br />
:::::::: That's a middle ground that sounds reasonable to me. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:54, 13 December 2022 (UTC)<br />
::::::::: As I see, there are three possible statuses:<br />
:::::::::* out-of-date but still useful (as decided by the local team);<br />
:::::::::* so critically out-of-date that it's better to delete the translation (as decided by the local team, or in case if the local team doesn't respond);<br />
:::::::::* out-of-date, but no one has yet decided if it's useful or not.<br />
::::::::: Perhaps it would be a good idea to create templates for all these statuses? The existing [[Template:Translateme]] and [[Template:Bad translation]] don't distinguish between them.<br />
::::::::: A notable example is [[Font configuration (Русский)]]. It was deleted ([[Special:Diff/722157]]), but I immediately reverted the deletion ([[Special:Diff/722168]]) because it was still useful. In this case, I could add an "out-of-date-but-useful" template so that ArchWiki maintainers know that it is not necessary to delete this translation. Such template can be used as a response from the local team.<br />
::::::::: -- [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 21:43, 13 December 2022 (UTC)<br />
<br />
::::::::::Maybe we can get away with repurposing the existing template as follows? <br />
::::::::::* [[Template:Translateme]] for the pages where an answer from the translation team is expected, <br />
::::::::::* [[Template:Keep translation]] for the pages where the translation team considers the page is still valuable, <br />
::::::::::* [[Template:Bad translation]] for the pages to remove if no one updates or changes to [[Template:Keep translation]] in 6 months. <br />
::::::::::: -1 from me for any large trunk of remove if a maintainer do not know the removed text. If maintainer do fully understand the translated text, it is Ok for me. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 15:04, 14 December 2022 (UTC)<br />
::::::::::::We're back to square one here… You were saying it was OK for you to redirect a page "if indeed no one is active and no one answers, maintains could just remove all out-of date i18n pages". What am I misunderstanding in your answer? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 15:23, 14 December 2022 (UTC)<br />
::::::::::The circuit for an out of date translation should then be a first flag with a [[Template:Translateme]], without answer in 6 months it can be updated to [[Template:Bad translation]], and the redirect can happen 6 months afterwards unless the flag is changed to [[Template:Keep translation]]. <br />
::::::::::We should have a provision somewhere on what delay is considered acceptable to replace a [[Template:Keep translation]] with [[Template:Translateme]], otherwise we can run into situations where pages stay in a bad state indefinitely. <br />
::::::::::This would mean only a single template has to be created, and the text of the existing ones only needs small changes. <br />
::::::::::Maybe we should also put an emphasis on the fact that the templates should be preferably put in the offending sections instead of flagging a whole page when a single section needs an update? (I think I'm guilty of doing that on some pages)<br />
::::::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 09:07, 14 December 2022 (UTC)<br />
::::::::::: I think we'd better create a list in local translation team's page. At least some translators will check the page frequently. But for old pages that only a few people need, maybe it will sit there for years before anyone even notice. I myself only monitor English pages and remove zh-hans pages from my watchlist. And now I start watch zh-hans too ... --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 15:04, 14 December 2022 (UTC)<br />
::::::::::::The issue with a list on the local translation team's page is that it's not obvious if all translators will follow it or not. It will also be kind of a clutter depending on what you expect the maintainers to put in the list? It would probably need at least a link to the out of date page, since when it is out of sync and a description of what is out of date on the page. Meanwhile a template on the page can easily be found with a category, e.g. [[:Category:Pages or sections flagged with Template:Bad translation (简体中文)]], and be tracked by translators that way. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 15:41, 14 December 2022 (UTC)<br />
::::::::::::: It should be opt-in instead of opt-out. We first check with each translation team whether they agree a maintainer could redirect a whole page to English once the page is out-of-date for 6 monthes and a maintainer will do the redirect even without understanding the tobe removed translation. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:39, 15 December 2022 (UTC)<br />
:::::::::::::: My proposal is for 6+6months, so a year total. I don't think giving a translation team a whole year to update a page is asking too much. If this is opt-in, we stay with the status quo of out of date and partially translated pages going nowhere for decades. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:09, 15 December 2022 (UTC)<br />
::::::::::::::: I changed my proposal based on my analysis of recent pages flag as bad translations. If the page is partially translated, it should be marked as Translateme and stay there as long as it is not critically outdated. When it is changed to Bad Translation, in the template comment, it must list the reason why it is [[[[ArchWiki:Translation Team#Dealing with old translations critically outdated]] and if no one fix them, the whole page will be redirect to Englih in 6 month. If a page is really critically outdated, 6 monthes are more than enough. My concern here is that some pages are not truely critically outdated. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 14:24, 5 January 2023 (UTC)<br />
::::::::::::::::That sounds reasonable, that means we only need to make sure we're on the same page for the definition of "critically". --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 15:34, 5 January 2023 (UTC)<br />
<br />
== About Partial translations ==<br />
(Split from [[#Procee update for bad translations]])<br />
:*Partial translations '''should not be kept at all''', since they should not exist if the translator followed [[ArchWiki:Translation Team#Create a new page and its translation]]. Some leeway can be given, but the existing rule of 2 years before redirecting seems too long to me. <br />
:: > This rule should be changed too. A partical translations should be kept if the translated part is useful to a user that can not read English.<br />
::: I would love to have other people chiming in on this one, I do not share the view that a partial translation is more than maintenance burden. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:46, 12 December 2022 (UTC)<br />
:::: We could divide ArchWiki pages into different classes. Some pages (e.g. [[Help:Editing]], [[ArchWiki:About]], [[Main page]]) are fundation pages that should be kept up-to-date and fully translated. Some pages (e.g. pages in [[:Category:Laptops]], [[:DeveloperWiki]]) are out-of-date quickly themself so that a translation may not be needed. But there are still large number of pages sitting in between. <br />
:::::# Some pages are very long (e.g. [[Virtualbox]]), when translate those pages, a translator may translate only the Installation and Configuration sections while leave Tips and tricks or Troubleshooting untranslated. Most users will leave the page after reading Installating and Configuration anyway. I fear that few readers will read such pages carefully from top to bottom unless they are a translator :) Translation team is always lack of manpower so valuable resources should be used to translated the partitions that users read the most, not the Troubleshooting sections a user rarely read unless they encounting the trouble.<br />
:::::# Some pages/sections are moving fast and the English sections are a mess/out-of-date , (In my memory, [[Xorg]],[[Wireless]],[[Systemd]] are some example). When translate such pages/sections, I usually translate only the fixed part and waiting for the sections to evolve into a good/steady state. Sometime this process may take years.<br />
:::::# Some contributors' English is not good enough to fully translate a page. So a translator may only translate Installation section, and leaving other parts for other more capable ones. We could not/should not say to them: "Don't start contribution unless you are capable of fully translate the page". This rule weight two much on perfectionism than contribution. So a page may started partically translated by such contributors and then no further contributor are interest or having enough time. But what's the matter than, just leaving them there. <br />
::::: Partical translation and partical sections are easier to sync with English pages, just copy and paste the whole sections. Chinese translation team are always in shortage of manpower. If we have to choose between the two below, we choose 2.<br />
:::::# Fully translate a page one by one even though some sections are rarely read by a reader.<br />
:::::# Partial translate a page and translate only the hot sections.<br />
::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:47, 13 December 2022 (UTC)<br />
<br />
::::::My main issue with that is the inevitable situation where the partially translated page gets out of sync with the existing page, a "drive-by" contributor translates the out of date content and updates the [[Template:TranslationStatus]] to the latest revision of the English page, and the resulting page is now a complete mess to untangle. <br />
::::::Right now the simple fix is a member of the maintenance team updating the English text, but there are too many pages to do that reliably since they are not listed by a category. <br />
::::::My solution would be to have only the translated sections in the i18n page and a link to the relevant sections for the untranslated ones. <br />
::::::See [[Window manager (Français)]] for an example of such page.<br />
::::::It would also avoid the presence of templates which should not be used on translations. <br />
::::::It should also always be tracked by a Translateme template. <br />
::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:32, 13 December 2022 (UTC)<br />
::::::: When I create [[Template:TranslationStatus]] ten years ago, I write Chinese first and translate them into English. The Chinese word “同步” make it very clear that they should import the diff from English one and then translate. "同步" was translated into English as "synchronize the translation". Maybe the translated one is not as clear as what we really want. So should we change them to something like "import the content from English one and then translate them"? It will help prevent users from translate before sync with English page. <br />
::::::: Link directly into English one is indeed another solution when a translator know he/she will not complet the translation. We should document them somewhere and from my memory, it is what a maintainer will do years ago. We just change that section into English when we are sure that it is wrong (for example contain kernel26, rc.conf) and only remove the wrong sections, not a whole page. So from my point of view, the most valuable contribution of a maintainer is to make sure everyone's contribution is kept and not accidentally deleted by someone else. When some readers contribute translation, we should not just delete the whole page because some part are out of date. It is a wiki after all, even Englih pages have lots of out-of-date sections, should we just delete them. My answer is "No". <br />
::::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:50, 13 December 2022 (UTC)<br />
<br />
::::::::I would have to dig into my edit history to find the pages which were translated from the text on the page without having synced the content first, but an update of [[Template:TranslationStatus]] might be in order to make abundantly clear that any non-translated content should indeed be checked against the English page first. I'm not sure what the best wording would be. <br />
::::::::I'd be happy to have historical contributors chiming in if they remember the reason why we stopped linking to the English page when a section should be skipped during translation. <br />
::::::::Linking to the English page does not avoid partially updated pages for partial translations, though. For example, a page is beginning to be translated up to and including section X, leaving Y and Z pointing to the English page. Someone then translates section Y and Z from English, but does not update what has changed from the English page up to the section X. We need to make it clear in the [[Template:TranslationStatus]] that in this situation the page is still not fully in sync. <br />
::::::::My issue with trying to keep every contributions at all cost is that when most of the page is in various bad states, it's really hard to make sense of the hodgepodge for someone trying to clean up and get it in sync. This is then actively worse, since it becomes off-putting for the maintenance oriented contributors, and starts a self-perpetuating circle. Especially if we have more people willing to translate whole/new pages instead of maintaining existing ones, it might be more efficient to redirect the whole page when it's getting out of date, so that starting from scratch invites a translator. <br />
::::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:06, 13 December 2022 (UTC)<br />
::::::::: The intention is great but if the action is based on flag time instead of understanding of both language, the result will be bad. Many pages are redirected because just a small part are out-of-date for a year, not because it is too hard to sync with English page. See [https://wiki.archlinuxcn.org/wzh/index.php?title=CDemu&diff=20177&oldid=19549 this] change as example, I just update a tiny section and the whole page is up to date again. Whether a translated page should be deleted and re-translated again should be made by a translator. I myself sometime just recopy all English sections when a page structure are changed greatly. That is OK as long as I understand both pages.<br />
::::::::: Some redirect could be summarized as: Large trunk of translated text are removed to prevent that maybe someone in the future do not know they should sync with English first. Really harm is done to prevent a rare possibility. Just leave them there and give more guide if needed. Trust every contributor, every translator. Do not make decision for them, they will learn along the way and become a better contributor.<br />
::::::::: Most of the time, it take much less time to translate based on previous work instead of start from scratch again. At least it the consensus from Chinese team. That's why a bot is created to recover all of the redirected zh-hans pages even when there are a small percent of them should indeed be archived.<br />
::::::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 23:41, 13 December 2022 (UTC)<br />
<br />
::::::::::''> Most of the time, it take much less time to translate based on previous work instead of start from scratch again.'' After redirecting a translated page, its history is of course still there so translators don't have to start from scratch. Is it really so hard to find the previous outdated translation? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:45, 14 December 2022 (UTC)<br />
::::::::::: The reality is yes, it is indeed hard. Before the Chinese team recover all the pages, I told two translators that there are already an old version that they could base on. They just thought no one ever translate them when they see the page is just a redirection. I myself is confused about the redirection too. I dig into history because I did translated the page years ago. The reality is most new contributors are not familiar with the wiki. Not like us, they know nothing about history, template, category, interlanguage, style. Each one is a little tiny thing for us, but huge obstacles for them. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 14:22, 14 December 2022 (UTC)<br />
::::::::::My apologies if I redirected pages that were deemed useful to your translation team. I sincerely believe that most of the pages I redirected were not in a state where the offered more value than pointing the reader to the up to date English page, but if I have made some wrong calls, know that it is not as a lack of respect for the hard work every contributor has made to the pages up to that point. <br />
::::::::::On the example you have chosen, it's not simply that [[CDemu]] was out of date, it's also that it was partially translated and not finished since 2012 when I redirected it in 2022-08. <br />
::::::::::From a quick look at [[zh-hans:CDemu]], the introduction mentions dbus and libmirage, but I do not see those terms used on the English page (it looks like they were removed [[Special:Diff/76924|in 2009]]). The diff you have linked is similar to the updates the English page has seen since 2013, but the two pages still do not look like each other in the end (e.g. there is still a ''systemctl'' command on your page, which is not present in the English page per [[Help:Style#systemd units operations]]), and the page is still not fully translated since [[Special:Diff/182548|your update from 2012]]. <br />
::::::::::This is very similar to what I'm warning about: you have updated some of the page, but not what was already translated. The end result is a page in a mixed state, where the [[Template:TranslationStatus]] shows it should be similar to the English page from 2013 but it's not the case, and it's visibly not up to date either.<br />
::::::::::I do not see a redirect as ''removing'' anything: it's easy to revert in the event that the page can be salvaged. I see no ''harm'' done in that action. <br />
::::::::::: It is hard to find. As my reply above, how could a newly contributor knew that he should dig the history and find something useful when the page is a redirection? If follow your logic, I could delete text of all wikis and it is not a deletion, it is no harm to ArchWiki because it is easy to revert? --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 14:31, 14 December 2022 (UTC)<br />
::::::::::::Now you're putting words in my mouth: I did not say redirecting everything indiscriminately was without consequence, just that in the case of old/inadequate translations it is not the insurmountable mountain you seem to make it. Yes, digging into history is a part of wiki editing, understanding when and why a change was made on a page is frequently useful, no it is not something that is obvious at first, neither is our template system, neither is following the style rules, neither is MediaWiki formatting, all those things are learned gradually by new contributors, yes we should accompany them along the way, but no we should not keep everything "as is" at all cost if a better solution exists. The wiki does not revolve solely about its contributors, the readers deserve quality content too. As you said elsewhere, it's a delicate balance to find. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 14:51, 14 December 2022 (UTC)<br />
::::::::::The "rare possibility" you mention is much more common than you think. Again, I would have to dig through my history to find all the pages where I have seen it happen, but I can promise you it is far from uncommon. <br />
::::::::::As the quasi-single contributor to the French pages in the last twelve months, I can attest to the fact that very out of date pages are really not faster to update than fully starting from a blank slate. It's too bad that wiki.archlinux.fr is no longer reachable to compare the state of disrepair it was in to what the French pages look like now, and the diffs needed to get there, but you can take my word for it: I've spent many hours on the first pages trying to save what existed before picking up the speed when I changed my way of working and started fresh on all pages. <br />
::::::::::I'm happy to see your translation team has found a way to revert to a state which fits you more on wiki.archlinuxcn.org --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:40, 14 December 2022 (UTC)<br />
::::::::::: For [[zh-hans:CDemu]], then what is the matter here. Does it hurt anyone because the page contain a systemctl command? I leave it here because I thought the English wording ("which contains also a handy cdemu-daemon.service") is not clear and not follow the [[Help:Style]]. I do not have enough time right now to fix it and just leave it to someone else. When English page is updated, than Chinese one will follow. I though you still not get my point. [[zh-hans:CDemu]] is not perfect, but should we redirect it to English one and remove large trunk of translate work because it is not a perfect translation? --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 14:31, 14 December 2022 (UTC)<br />
<br />
::::::::::::I did not say it was an issue, I just pointed out that the page you chose as an example of a wrong redirection to English displays the symptoms of rushed editing (which I'm all too often guilty of) and fits right into the warning I'm trying (and I fear, failing) to convey to you: partially updating a translation is setting the future contributor up for failure. <br />
::::::::::::By your reasoning, we could also add a {{ic|pacman -Syu cdemu-client}} too, what harm does it do? We have a set of rules to stay coherent in the way we convey information to our readers. If we don't follow our own rules ([[zh-hans:Help:Style]] has not removed the guideline about ''systemctl'') how can we ask our contributors to do the same? <br />
::::::::::::: Yes, that is exactly what I want to convery. We do not. We should not require a new contributor read [[Help:Style]] before contribution. I used to guide some users to [[Help:Style]] only after they contribute long enough. For systemctl and pacman command, they are the standard style more than 10 years ago, they are all over the place, no one is harmed by them. Left some junior jobs there make it more to contributors. Maybe use this method, French translation team could attract more contributors. Below is what Chinese translation team told in local chat channel what the different between the two wiki: "In zh-hans wiki, just contribute your knowledge right away, style is much much less important than knowledge here.".<br />
:::::::::::::--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:05, 15 December 2022 (UTC)<br />
::::::::::::::So you do not hold yourself to a higher standard than new contributors?! If it was an update made by any small volume translator I would simply fix it after them (as I daily do). <br />
::::::::::::::"they are the standard style more than 10 years ago, they are all over the place": I am proud to say that there should be not a single English page in that situation, because I have fixed them every time I've seen them. <br />
::::::::::::::I believe in leading by the example, instead of leaving the trash to be picked by newcomers. <br />
::::::::::::::The French translation is at its present state because there simply is no one interested in working on it other than me (believe me, I regularly talk about it on our IRC channel), the French community is also much smaller than the English or Chinese one, and all the historical contributors burned out. <br />
::::::::::::::Form is not above function, but it should be regarded as an integral part of conveying information: just because we should not judge a book by its cover does not mean it's pointless to make it nice looking. <br />
::::::::::::::Edit: you did not address my first point, you got yourself caught by a partially updated page, where the translated content still contains information that was removed in 2009 from the English page. <br />
::::::::::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:27, 15 December 2022 (UTC)<br />
::::::::::::I completely understand what you mean about perfect being the enemy of good, but sometimes I think we don't hold ourselves to a high enough standard. Leaving a page partially translated for ''10 years'' does not feel right to me, no matter how you want to describe it. <br />
::::::::::::You are right that [[CDemu]] is not well enough written though: I've fixed it.<br />
::::::::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 15:18, 14 December 2022 (UTC)<br />
::::::::::::: When view a half translated page, I though mostly the already translated part, how it will give help to the user while you thought mostly the untranslated part, not perfect and some sections even contains ugly styles. ArchWiki need both type as long as we do not fight with each other :)<br />
::::::::::::::Sorry if you see me as "fighting", I'm just trying to promote the idea that "we can do better" and not wallow in "it's good enough". <br />
::::::::::::::Edit: For example, when I see [[User:Lahwaacz]] editing with clockwork regularity, tirelessly educating users that made unhelpful edits, always checking over new contributors edits and improving them, it makes me want to be as knowledgeable as he his. <br />
::::::::::::::On the opposite side, when I find a neglected translation, I've been fixing them right and left where I can but got discouraged so I limit myself to flagging them (even more so when I do not speak the language at all) so that the translation team hopefully does something. Months pass and nothing gets better. <br />
::::::::::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:27, 15 December 2022 (UTC)<br />
::::::::::::::: If I have 100 hours a day, I will do better. After a week There are still more than 200 pages wating for me to check and redirect to zh-hans wiki so I will skip any problems I meet until it is done.<br />
::::::::::::::: And left some junior jobs for starter is the experience I learn from KDE community. There are many junior jobs in KDE bugzilla that could be fix with very little code. I could never contribute to KDE without such junior bugs. I copy the method here and use it to attract more translators. <br />
::::::::::::::: The French translation team is like a Cathedral model, its page size is small but every existing page is perfect and clean. The Chinese translation team is like a Bazaar model, it like a mess from an out-sider, some pages are perfect while others are in a very poor state. But as already proven by open source world, sometime Bazaar model will grow much faster. So let's back to the topic by a vote. <br />
::::::::::::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:39, 15 December 2022 (UTC)<br />
<br />
::::::::::::::::I feel the need to explicitly point out that I'm not criticizing your hard work, just pointing out that the way we currently handle translations leads to pages staying in a bad state for years (some even a decade). <br />
::::::::::::::::I had heard of the 15-Minute Bug Initiative from KDE, but I don't think this is applicable here, since we have no central point yet to direct new contributors to easy picks. <br />
::::::::::::::::It's not only the French translation that focuses on fully translated pages: see the Russian, Polish, Spanish or Portuguese pages. <br />
::::::::::::::::See [[Wikipedia:List of languages by number of native speakers#Top languages by population]], you have the chance to be in the translation team with the highest number of speakers on earth, and I guess this plays a non-negligible role in the popularity of your translation effort. <br />
::::::::::::::::: Yes, what I want you understand is that some rule you thought and argue about perfect fix a small team, but they will not fix a dynamic community of tens of contributors. It is too dynamic so we have to choose the Bazaar model. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:18, 16 December 2022 (UTC) <br />
:::::::::::::::::: I get your point, but I disagree on your conclusion. Even in the bazaar model, there are self-imposed rules (e.g. see [https://www.phoronix.com/news/Linux-Kernel-Deprecates-80-Col the kernel coding style for column length]). Dynamism does not have to prioritize quantity over quality. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:10, 16 December 2022 (UTC)<br />
::::::::::::::::::: There is a rule, or a warning [https://wiki.archlinuxcn.org/wiki/Help:%E7%BF%BB%E8%AF%91 in Chinese translation page]("Warning: If you do not intend to translate most of the page, try not to create new Chinese Simplified pages. It takes a lot of effort to check for updates to English pages, and pages without translations add to the maintenance burden. When cleaning up history pages, administrators may change pages that have not been translated for a long time to redirect to English pages."). But I could not force every translator to follow it, or even read them. Give the team size, partital translation is unavoidable. We have to face the reality.<br />
::::::::::::::::::: If I can set up a rule, I will create a rule that every contributors only touch the one they most good at. For me it is Chinese & English, for you it is English and French. Giving the same time, this will benefit the wiki most. Sadly, I could not force you to do such things. Then just imaging there are 100 French contributors and everyone have their own opinion. The end result will be a mess. <br />
::::::::::::::::::: --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:33, 16 December 2022 (UTC)<br />
::::::::::::::::::::I think it is our role as maintainers/administrators to enforce the rules. When bad pages are created in English, they are dealt with (see [[Special:Log/delete]] for example). Why should translations become exempt of this reasoning? <br />
::::::::::::::::::::Playing devil's advocate here on your suggested rule: restricting people to only the area they are familiar with hinders them on learning in new areas. <br />
::::::::::::::::::::As with every community project, some kind of consensus needs to be reached where the majority decides of the course of action. See the Debian/Devuan split for an example of dissenting opinions leaving a project where they did not feel like their voices were heard. Yet the Debian project lives on and is not a mess as far as I can tell.<br />
::::::::::::::::::::--[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 14:48, 16 December 2022 (UTC)<br />
::::::::::::::::::::: [https://wiki.archlinuxcn.org/wzh/index.php?title=%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96&curid=3268&diff=20856&oldid=20128 this] is an live example that a partial translated page attracted a [https://wiki.archlinuxcn.org/wiki/Special:%E7%94%A8%E6%88%B7%E8%B4%A1%E7%8C%AE/Fukujusou.cn new contributor]. Translating some existing text is much easier than start a new page. Most Chinese contributor come from such road: Start from some partial translated sections, then learn Style/Category/Interlanguage link/TranslationStatus much later. That is why partial translation could be seen as bait for new contributors. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:10, 21 December 2022 (UTC) <br />
<br />
::::::::::::::::::::::And [[Special:Diff/761373/761388|this]] is an example of a [[Special:Contributions/Taidson|new contributor]] creating and fully finishing a translation in two days. I'm happy that you have found a different way to work on translations for your team, but I maintain my disagreement on the method. I'd be tempted to link to [[Wikipedia:Broken windows theory]] but the parallel has its flaws. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 17:41, 21 December 2022 (UTC)<br />
<br />
::::::::::::::::Before casting my vote, I need some clarity on the consequences of each options: <br />
::::::::::::::::*Majority of Yes: <br />
:::::::::::::::::*We allow partial translations, details on how they are handled need to be discussed? <br />
:::::::::::::::::*We allow partial translations, un-translated sections link to the English section?<br />
:::::::::::::::::: Compared with below, it a choice between maintaince and readbility. It will increase another page jump. The most complains I always heard of about ArchWiki is that there are too many subpage jumps. When a new Arch users want to install it through [[Installaiton guide]], they usually need to dig into pages after pages to fully understand what should be done. I myself find it like a maze, especially in partition section. We kill Beginner's Guide to reduce duplication and maintaince burden. How much damage it is done for Arch Linux is another hot topic that I leave for future. But right now I hope to reduce page jump unless necessary. <br />
:::::::::::::::::::People always complain about things that are unfamiliar to them (then change of default CSS on the wiki has been an other example). The relatively strict adherence to the DRY principle has allowed us to stay relevant over time by minimizing the maintenance cost of the ever growing number of pages (and from what I can tell, this approach has been discussed at length). You're regularly pointing out our time is limited: I am not OK with voluntarily increasing our maintenance burden for a benefit I do not see. Furthermore, your argument to allow partial translation is that the untranslated parts are not the "hot" part of the page, thus very few readers will be bothered by the additional page to go through. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 09:06, 16 December 2022 (UTC)<br />
:::::::::::::::::*We allow partial translations, un-translated sections are copied from the English page at a given date, and can be updated until they get translated? <br />
:::::::::::::::::: I like this options most. It increase a little maintaince burden but the reader do not need to jump back and force. <br />
::::::::::::::::*Equality: <br />
:::::::::::::::::*We keep the current rule of giving two years for a translation team to complete a page? <br />
::::::::::::::::*Majority of No: <br />
:::::::::::::::::*We strictly forbid any partial translation in the main namespace, ongoing translations need to be in the user namespace or on a sub-page of the translation team's page? <br />
::::::::::::::::I would also like to know who you expect to be voting on this? Only maintainers and admins, other translation team members? <br />
::::::::::::::::: Everyone could give their vote here. <br />
::::::::::::::::Thank you again for the time you have taken for our exchange. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:15, 15 December 2022 (UTC)<br />
<br />
Should a partial translation be allowed in ArchWiki, please give your vote and comment:<br />
* Yes<br />
** Yes, and a maintainer could swap out-of-date translations into English direrctly. But non out-of-date translations shoud be kept. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:39, 15 December 2022 (UTC)<br />
** Yes, and a maintainer could link out-of-date sections into English page.<br />
<br />
* No<br />
** No - Move them to user namespace<br />
** No - Move them to sub-page of the translation team<br />
I vote for this last option, hoping it does not hinder collaboration, while keeping the main namespace from accumulating out of date content when translations stall. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 14:53, 16 December 2022 (UTC)<br />
<br />
I vote to maintain the status-quo. In practice, old partial translations neither update their translations nor their English content, so this becomes a maintanence burden for the regular maintenance team as well. It's hard to tell how useful measures like moving old pages to sub-pages of the translation team are, since most translation teams haven't engaged in this discussion. And the team requesting to make changes to the existing wiki rules has already left the wiki for an external domain. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:31, 16 December 2022 (UTC)<br />
::: As I said in the begining, for such pages, a maintainer could just stop keeping it up-to-date if he could not read the content. Or he could just swap or link the out of date sections into English. But for already translated part, especially hot sections like Installations and Configurations should be kept. I am totally fine that an out of date sections are removed. But currently, I see some translations are cempletely removed just because some sections are not in sync with English. Compared with the Installation, the out of date sections are far from important. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:13, 17 December 2022 (UTC)<br />
<br />
== Replace PNG images with SVG ==<br />
<br />
[[Special:ListFiles]] lists many PNG files from the Tango icon set. Since there are SVG versions in [[commons:Tango icons]], I think we should use those. They will look better on higher DPI screens. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:25, 30 December 2022 (UTC)<br />
<br />
:When [[User:Lahwaacz]] tried to upload SVG format histograms, we discovered that [[mw:Manual:Image administration#SVG|it's not that simple]].<br />
:For it to work, we need [[mw:Extension:NativeSvgHandler]] and {{ic|$wgFileExtensions[] {{=}} 'svg';}} in [https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/templates/LocalSettings.php.j2 LocalSettings.php].<br />
:I created https://github.com/archlinux/archwiki/pull/65 to add the extension.<br />
:-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:15, 2 January 2023 (UTC)<br />
<br />
:To increase the fun, Extension:DarkMode [https://github.com/wikimedia/mediawiki-extensions-DarkMode/blob/REL1_39/resources/ext.DarkMode.less#L158-L161 sets SVG image background to white]. {{ic|<nowiki>.client-darkmode #mw-content-text .image img[src*='svg'] { background-color:#090603; }</nowiki>}} can be added to [[MediaWiki:Common.css]] as a workaround. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:21, 2 January 2023 (UTC)<br />
<br />
== Dealing with deceased users ==<br />
<br />
As you might already know, [[User:Jonathon]] has sadly passed away. See https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/UA6NYEGLXKTDW6PE22E3EJTGB27O46XR/<br />
<br />
My proposal is, I already reached out to his brother and he would be fine with that, is to create a userpage for him which reads something like "This user has passed away and his contributions will never be forgotten.", signed by the maintenance team and fully protected. Same for the talk page maybe?<br />
Additionally also block the user because unfortunately the account will never be used again, but wikipedia does not do that for example: [[Wikipedia:Deceased Wikipedians]]<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 11:15, 11 January 2023 (UTC)<br />
<br />
:I don't see a need to protect his user page or block the account. And I'm quite sure we don't want a policy for these kind of situations, the less bureaucracy the better. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:45, 11 January 2023 (UTC)<br />
<br />
:Since [https://archlinux.org/news/in-memory-of-jonathon-fernyhough/ the news item] is out, how about linking to it from his user page? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:42, 13 January 2023 (UTC)<br />
::This seems both appropriate, and a nice gesture. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 22:44, 19 January 2023 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Dwm&diff=750840Dwm2022-10-03T00:50:35Z<p>Jasonwryan: /* Using Tilda with dwm */ A full tilda config is bloat</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Dynamic window managers]]<br />
[[Category:Suckless]]<br />
[[de:Dwm]]<br />
[[ja:Dwm]]<br />
[[pt:Dwm]]<br />
[[zh-hans:Dwm]]<br />
{{Related articles start}}<br />
{{Related|dmenu}}<br />
{{Related|Window manager}}<br />
{{Related articles end}}<br />
[https://dwm.suckless.org/ dwm] is a dynamic window manager for [[Xorg]]. It manages windows in tiled, stacked, and full-screen layouts, as well as many others with the help of optional patches. Layouts can be applied dynamically, optimizing the environment for the application in use and the task being performed. dwm is extremely lightweight and fast, written in C and with a stated design goal of remaining under 2000 source lines of code. It provides [[multihead]] support for [[xrandr]] and Xinerama.<br />
<br />
== Installation ==<br />
<br />
The prescribed way to install dwm is as follows: <br />
<br />
$ git clone git://git.suckless.org/dwm<br />
$ cd dwm<br />
$ make<br />
# make install<br />
<br />
dwm can also be installed with the AUR packages {{AUR|dwm}} or {{AUR|dwm-git}}. Make any required [[#Configuration]] changes '''before''' building and installing, see [[makepkg]].<br />
<br />
=== Configuration ===<br />
<br />
dwm is configured at compile-time by editing some of its source files, specifically {{ic|config.h}}. For detailed information on these settings see the included, well-commented {{ic|config.def.h}} as well as the [https://dwm.suckless.org/customisation/ customisation section] on the dwm website.<br />
<br />
The official website has a number of [https://dwm.suckless.org/patches/ patches] that can add extra functionality to dwm. These patches primarily make changes to the {{ic|dwm.c}} file but also make changes to the {{ic|config.h}} file where appropriate. For information on applying patches, see the [[Patching packages]] article.<br />
<br />
== Starting ==<br />
<br />
Select ''Dwm'' from the menu in a [[display manager]] of choice. Alternatively, to start dwm with [[startx]] append {{ic|exec dwm}} to {{ic|~/.xinitrc}} and prepend other programs to execute them as well, for example:<br />
<br />
redshift -O3500; xset r rate 300 50; exec dwm<br />
<br />
== Usage ==<br />
<br />
See the [https://dwm.suckless.org/tutorial dwm tutorial] for information on basic dwm usage.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Statusbar configuration ===<br />
<br />
For more examples of status bars see [https://dwm.suckless.org/status_monitor/].<br />
<br />
{{Note|The following requires the {{Pkg|xorg-xsetroot}} package to be installed.}}<br />
<br />
dwm reads the name of the root window and redirects it to the statusbar. The root window is the window within which all other windows are drawn and arranged by the window manager. Like any other window, the root window has a title/name, but it is usually undefined because the root window always runs in the background. <br />
<br />
The information that you want dwm to show in the statusbar should be defined with {{ic|xsetroot -name ""}} command in {{ic|~/.xinitrc}} or {{ic|~/.xprofile}} (if you are using a [[display manager]]). For example: <br />
{{bc|xsetroot -name "Thanks for all the fish!"}}<br />
<br />
Dynamically updated information should be put in a loop which is forked to background - see the example below:<br />
{{bc|<br />
# Statusbar loop<br />
while true; do<br />
xsetroot -name "$( date +"%F %R" )"<br />
sleep 1m # Update time every minute<br />
done &<br />
<br />
# Autostart section<br />
pcmanfm & <br />
<br />
exec dwm<br />
}}<br />
In this case the date is shown in [[wikipedia:ISO_8601|ISO 8601]] format and [[PCManFM]] is launched at startup. <br />
<br />
{{note|It is not recommended to set the update interval equal to zero or remove the "sleep" line entirely since this will cause CPU usage to rise substantially (you can assess the effect with ''top'' and [[powertop]]).}}<br />
<br />
==== Conky statusbar ====<br />
<br />
[[Conky]] can be printed to the statusbar with {{Ic|xsetroot -name}}:<br />
(conky | while read LINE; do xsetroot -name "$LINE"; done) &<br />
exec dwm<br />
<br />
If you do not want to spawn too many PIDs by 'xsetroot' command, you can compile this C program:<br />
#include <string.h><br />
#include <stdlib.h><br />
#include <stdio.h><br />
#include <X11/Xlib.h><br />
<br />
int main(int argc, char * argv[])<br />
{<br />
Display * dpy = NULL;<br />
Window win = 0;<br />
size_t length = 0;<br />
ssize_t bytes_read = 0;<br />
char * input = NULL;<br />
<br />
dpy = XOpenDisplay(getenv("DISPLAY"));<br />
if (dpy == NULL)<br />
{<br />
fprintf(stderr, "Can't open display, exiting.\n");<br />
exit(1);<br />
}<br />
win = DefaultRootWindow(dpy);<br />
<br />
while ((bytes_read = getline(&input, &length, stdin)) != EOF)<br />
{<br />
input[strlen(input) - 1] = '\0';<br />
XStoreName(dpy, win, input);<br />
XFlush(dpy);<br />
fprintf(stderr, "Input: %s", input);<br />
fprintf(stderr, "\nbytes read: %ld\n", bytes_read);<br />
}<br />
free(input);<br />
return 0;<br />
}<br />
<br />
Save this code to file dwm-setstatus.c, compile:<br />
$ gcc dwm-setstatus.c -lX11 -o dwm-setstatus<br />
move 'dwm-setstatus' within your $PATH (/usr/local/bin, for example)<br />
# mv dwm-setstatus /usr/local/bin<br />
and run:<br />
$ conky | dwm-setstatus<br />
<br />
To do this, conky needs to be told to output text to the console only. The following is a sample conkyrc for a dual core CPU, displaying several usage statistics:<br />
{{bc|<br />
<nowiki>conky.config = {<br />
out_to_console = true,<br />
out_to_x = false,<br />
background = false,<br />
update_interval = 2,<br />
total_run_times = 0,<br />
use_spacer = 'none',<br />
};<br />
conky.text = [[<br />
$mpd_smart :: ${cpu cpu1}% / ${cpu cpu2}% ${loadavg 1} ${loadavg 2 3} :: ${acpitemp}c :: $memperc% ($mem) :: ${downspeed eth0}K/s ${upspeed eth0}K/s :: ${time %a %b %d %I:%M%P}<br />
]];</nowiki><br />
}}<br />
<br />
For icons and color options, see [[dzen]].<br />
<br />
=== Restart dwm ===<br />
<br />
To restart dwm without logging out or closing applications, change or add a startup script so that it loads dwm in a ''while'' loop, for example:<br />
{{bc|<br />
while true; do<br />
# Log stderror to a file <br />
dwm 2> ~/.dwm.log<br />
# No error logging<br />
#dwm >/dev/null 2>&1<br />
done<br />
}}<br />
<br />
dwm can now be restarted without destroying other X windows by pressing the usual Mod-Shift-Q combination.<br />
<br />
It is a good idea to place the above startup script into a separate file, {{ic|~/bin/startdwm}} for instance, and execute it through {{ic|~/.xinitrc}}. Consider running the script with {{ic|exec}} to avoid security implications with remaining logged in after the X server is terminated; see [[Xinit#Autostart X at login]] for more information. From this point on, when you wish to end the X session, simply execute {{Ic|pkill dwm}}, or bind it to a convenient keybind. Alternatively, you could setup your dwm session script so that it relaunches dwm only if the binary changes. This could be useful in the case where you change a setting or update the dwm code base.<br />
<br />
{{bc|1=<br />
# relaunch DWM if the binary changes, otherwise bail<br />
csum=""<br />
new_csum=$(sha1sum $(which dwm))<br />
while true<br />
do<br />
if [ "$csum" != "$new_csum" ]<br />
then<br />
csum=$new_csum<br />
dwm<br />
else<br />
exit 0<br />
fi<br />
new_csum=$(sha1sum $(which dwm))<br />
sleep 0.5<br />
done<br />
}}<br />
<br />
=== Bind the right Alt key to Mod4 ===<br />
<br />
When using Mod4 (the Super/Windows Key) as the {{Ic|MODKEY}}, it may be equally convenient to have the right {{ic|Alt}} key ({{ic|Alt_R}}) act as {{ic|Mod4}}. This will allow you to perform otherwise awkward keystrokes one-handed, such as zooming with {{ic|Alt_R}}+{{ic|Enter}}. <br />
<br />
First, find out which keycode is assigned to {{ic|Alt_R}}:<br />
xmodmap -pke | grep Alt_R<br />
<br />
Then simply add the following to the startup script (e.g. {{ic|~/.xinitrc}}), changing the keycode ''113'' if necessary to the result gathered by the previous {{Ic|xmodmap}} command:<br />
xmodmap -e "keycode 113 = Super_L" # reassign Alt_R to Super_L<br />
xmodmap -e "remove mod1 = Super_L" # make sure X keeps it out of the mod1 group<br />
<br />
After doing so, any functions that are triggered by the {{ic|Super_L}} key press will also be triggered by an {{ic|Alt_R}} key press.<br />
<br />
{{note|There is a {{ic|#define}} option in [[#Configuration|config.h]] which also allows you to switch the modkey.}}<br />
<br />
=== Use both Alt keys as Meta in DWM ===<br />
<br />
:Use xmodmap to assign Alt_L as a secondary meta key in DWM (provided already using Mod1Mask (Alt_R))<br />
<br />
{{hc|~/.xinitrc|<nowiki><br />
/usr/bin/xmodmap -e "clear mod5"<br />
/usr/bin/xmodmap -e "keycode 108 = Alt_L"<br />
</nowiki>}}<br />
{{User:cirrus|00:25, 24 November 2020 (GMT)}}<br />
<br />
=== Space around font in dwm's bar ===<br />
<br />
By default, dwm's bar adds 2px around the size of the font. To change this, modify the following line in {{ic|dwm.c}}:<br />
{{bc|1=bh = dc.h = dc.font.height + 2;}}<br />
<br />
=== Disable focus follows mouse ===<br />
<br />
To disable focus follows mouse behaviour comment out the following line in definiton of struct handler in {{ic|dwm.c}} <br />
{{bc|1=[EnterNotify] = enternotify, }}<br />
Note that this change can cause some difficulties; the first click on an inactive window will only bring the focus to it. To interact with window contents (buttons, fields etc) you need to click again. Also, if you have several monitors, you may notice that the keyboard focus does not switch to another monitor activated by clicking.<br />
<br />
=== Floating layout for some windows ===<br />
<br />
For some windows, such as preferences dialogs, it does not make sense for these windows to be tiled - they should be free-floating instead. For example, to make Firefox's preferences dialog float, add the following to your rules array in {{ic|config.h}}:<br />
<br />
{ "Firefox", NULL, "Firefox Preferences", 1 << 8, True, -1 },<br />
<br />
=== Using Tilda with dwm ===<br />
<br />
[[Tilda]] works best when added to all tags, and configured to be floating. To do so, add the following to your rules array in {{ic|config.h}}:<br />
<br />
{ "Tilda", NULL, NULL, 0, True, -1 },<br />
<br />
Launch tilda with -C option:<br />
<br />
$ tilda -C<br />
<br />
Now you can configure Tilda, the following options are provided as a recommendation:<br />
<br />
{{bc|Font: Clean 9<br />
Appearance: Height: 50%, Width: 70%, Centered Horizontally<br />
Extras: Enable Transparency Level 15<br />
Animated Pulldown: 1500 usec, Orientation: Top<br />
Colors: Built-in Scheme "Green on Black"<br />
Scrolling: Scrollbar is on the left, 2000 lines scrollback<br />
Key Binding: F9<br />
}}<br />
<br />
It is important you enable the pulldown-animation, otherwise Tilda will keep jumping down each time you unhide it, must be a dwm issue.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Fixing misbehaving Java applications ===<br />
<br />
Try setting {{ic|1=export _JAVA_AWT_WM_NONREPARENTING=1}}. <br />
Setting {{ic|1=wmname "LG3D"}} using {{Pkg|wmname}} may help too.<br />
Also see the [[Java#Gray window, applications not resizing with WM, menus immediately closing|Java]] page.<br />
<br />
=== Fixing gaps around terminal windows ===<br />
<br />
If there are empty gaps of desktop space outside terminal windows, it is likely due to the terminal's font size. Either adjust the size until finding the ideal scale that closes the gap, or toggle {{Ic|resizehints}} to ''0'' in {{ic|config.h}}.<br />
<br />
This will cause dwm to ignore resize requests from all client windows, not just terminals. The downside to this workaround is that some terminals may suffer redraw anomalies, such as ghost lines and premature line wraps, among others.<br />
<br />
Alternatively, if you use the [[st]] terminal emulator, you can apply the [https://st.suckless.org/patches/anysize/ anysize] patch and recompile st.<br />
<br />
== See also ==<br />
<br />
* [https://dwm.suckless.org/ dwm's official website]<br />
* [https://www.youtube.com/watch?v=GQ5s6T25jCc Introduction to dwm video]<br />
* [[dmenu]] - Simple application launcher from the developers of dwm<br />
* The [https://bbs.archlinux.org/viewtopic.php?id=57549/ dwm thread] on the forums<br />
* [https://bbs.archlinux.org/viewtopic.php?id=92895/ Hacking dwm thread]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=57768/ Wallpaper thread] in the forums for a selection of dwm wallpapers<br />
* [https://bbs.archlinux.org/viewtopic.php?id=74599 Show off your dwm configuration forum thread]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=User_talk:Jasonwryan&diff=744644User talk:Jasonwryan2022-09-03T01:24:34Z<p>Jasonwryan: /* Doubt regarding revert */</p>
<hr />
<div>== [[Color Bash Prompt]] ==<br />
[https://wiki.archlinux.org/index.php?title=Color_Bash_Prompt&diff=298644&oldid=298623 why]??? --[[User:Grufo|Grufo]] <sup>[ [[Special:Contributions/Grufo|contribs]] | [[User_talk:Grufo|talk]] ]</sup> 14:06, 18 February 2014 (UTC)<br />
: For the reasons I outlined on the talk page: the material I moved is (a) unecessarily complex, (b) is essentially a series of variations on a theme; the basics are now explained at the top of the page--with some cleanup still needed, and (c) people can read the BBS thread to see specific examples *once they have grapsed the basics*...<br />
<br />
: I also think that, for customizing a prompt, the directions should be on $HOME, *not* /etc, with a note at the end of the article that any systemwide changes can be added to these files. [[User:Jasonwryan|jasonwryan]] ([[User talk:Jasonwryan|talk]]) 16:28, 18 February 2014 (UTC)<br />
<br />
== qutebrowser "new" config example ==<br />
<br />
As these are your dotfiles, would you mind checking if [[Special:Diff/653810|this]] is (still) correct?<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:14, 2 March 2021 (UTC)<br />
: Yep: thanks! -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 02:58, 2 March 2021 (UTC)<br />
<br />
== Doubt regarding revert ==<br />
<br />
Can you please explain why you reverted my edit in Dual-Boot with Windows page? (https://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=744619&oldid=744555). My edit seems correct, as the article "an" mustn't be used before a consonant like M from MBR. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 20:04, 2 September 2022 (UTC)<br />
: Sure, for a couple of reasons. First, it was a low value edit that does not contribute to the accuracy or legibility of the article. It was probably well intentioned, but could be interpreted as pedantry. Which leads to the second reason, that sort of grammatical bikeshedding only produces friction, it doesn't make working on the wiki more enjoyable for anyone. Finally, when in doubt about those grammatical edge cases, either let them lie or err on the side of the version that reads best: MBR is an abbreviation, and the initial sound is a vowel (em), therefore it makes more sense to use "an". [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 22:19, 2 September 2022 (UTC)<br />
:: Understood. I edited directly instead of asking because I was sure it was correct (and it seems I was wrong). When updating pages translation, sometimes I find small mistakes like style or typos, so I use this moment to fix before forgetting about it. I try to avoid this situation again. Regards. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:49, 3 September 2022 (UTC)<br />
::: No problem. Thanks for working on the wiki! [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 01:24, 3 September 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=User_talk:Jasonwryan&diff=744643User talk:Jasonwryan2022-09-03T01:24:09Z<p>Jasonwryan: /* Doubt regarding revert */ Concluded</p>
<hr />
<div>== [[Color Bash Prompt]] ==<br />
[https://wiki.archlinux.org/index.php?title=Color_Bash_Prompt&diff=298644&oldid=298623 why]??? --[[User:Grufo|Grufo]] <sup>[ [[Special:Contributions/Grufo|contribs]] | [[User_talk:Grufo|talk]] ]</sup> 14:06, 18 February 2014 (UTC)<br />
: For the reasons I outlined on the talk page: the material I moved is (a) unecessarily complex, (b) is essentially a series of variations on a theme; the basics are now explained at the top of the page--with some cleanup still needed, and (c) people can read the BBS thread to see specific examples *once they have grapsed the basics*...<br />
<br />
: I also think that, for customizing a prompt, the directions should be on $HOME, *not* /etc, with a note at the end of the article that any systemwide changes can be added to these files. [[User:Jasonwryan|jasonwryan]] ([[User talk:Jasonwryan|talk]]) 16:28, 18 February 2014 (UTC)<br />
<br />
== qutebrowser "new" config example ==<br />
<br />
As these are your dotfiles, would you mind checking if [[Special:Diff/653810|this]] is (still) correct?<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:14, 2 March 2021 (UTC)<br />
: Yep: thanks! -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 02:58, 2 March 2021 (UTC)<br />
<br />
== Doubt regarding revert ==<br />
<br />
Can you please explain why you reverted my edit in Dual-Boot with Windows page? (https://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=744619&oldid=744555). My edit seems correct, as the article "an" mustn't be used before a consonant like M from MBR. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 20:04, 2 September 2022 (UTC)<br />
: Sure, for a couple of reasons. First, it was a low value edit that does not contribute to the accuracy or legibility of the article. It was probably well intentioned, but could be interpreted as pedantry. Which leads to the second reason, that sort of grammatical bikeshedding only produces friction, it doesn't make working on the wiki more enjoyable for anyone. Finally, when in doubt about those grammatical edge cases, either let them lie or err on the side of the version that reads best: MBR is an abbreviation, and the initial sound is a vowel (em), therefore it makes more sense to use "an". [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 22:19, 2 September 2022 (UTC)<br />
:: Understood. I edited directly instead of asking because I was sure it was correct (and it seems I was wrong). When updating pages translation, sometimes I find small mistakes like style or typos, so I use this moment to fix before forgetting about it. I try to avoid this situation again. Regards. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:49, 3 September 2022 (UTC)<br />
::: No problem. Thanks for working on the wiki! 01:23, 3 September 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=User_talk:Jasonwryan&diff=744639User talk:Jasonwryan2022-09-02T22:20:11Z<p>Jasonwryan: /* Doubt regarding revert */ Clarifiy reason</p>
<hr />
<div>== [[Color Bash Prompt]] ==<br />
[https://wiki.archlinux.org/index.php?title=Color_Bash_Prompt&diff=298644&oldid=298623 why]??? --[[User:Grufo|Grufo]] <sup>[ [[Special:Contributions/Grufo|contribs]] | [[User_talk:Grufo|talk]] ]</sup> 14:06, 18 February 2014 (UTC)<br />
: For the reasons I outlined on the talk page: the material I moved is (a) unecessarily complex, (b) is essentially a series of variations on a theme; the basics are now explained at the top of the page--with some cleanup still needed, and (c) people can read the BBS thread to see specific examples *once they have grapsed the basics*...<br />
<br />
: I also think that, for customizing a prompt, the directions should be on $HOME, *not* /etc, with a note at the end of the article that any systemwide changes can be added to these files. [[User:Jasonwryan|jasonwryan]] ([[User talk:Jasonwryan|talk]]) 16:28, 18 February 2014 (UTC)<br />
<br />
== qutebrowser "new" config example ==<br />
<br />
As these are your dotfiles, would you mind checking if [[Special:Diff/653810|this]] is (still) correct?<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:14, 2 March 2021 (UTC)<br />
: Yep: thanks! -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 02:58, 2 March 2021 (UTC)<br />
<br />
== Doubt regarding revert ==<br />
<br />
Can you please explain why you reverted my edit in Dual-Boot with Windows page? (https://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=744619&oldid=744555). My edit seems correct, as the article "an" mustn't be used before a consonant like M from MBR. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 20:04, 2 September 2022 (UTC)<br />
: Sure, for a couple of reasons. First, it was a low value edit that does not contribute to the accuracy or legibility of the article. It was probably well intentioned, but could be interpreted as pedantry. Which leads to the second reason, that sort of grammatical bikeshedding only produces friction, it doesn't make working on the wiki more enjoyable for anyone. Finally, when in doubt about those grammatical edge cases, either let them lie or err on the side of the version that reads best: MBR is an abbreviation, and the initial sound is a vowel (em), therefore it makes more sense to use "an". [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 22:19, 2 September 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=744619Dual boot with Windows2022-09-02T19:09:54Z<p>Jasonwryan: Reverted edits by Josephgbr (talk) to last revision by Erus Iluvatar</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Installation process]]<br />
[[fr:Dual boot with Windows]]<br />
[[ja:Windows と Arch のデュアルブート]]<br />
[[pt:Dual boot with Windows]]<br />
[[zh-hans:Dual boot with Windows]]<br />
This is an article detailing different methods of Arch/Windows coexistence.<br />
<br />
== Important information ==<br />
<br />
=== Windows UEFI vs BIOS limitations ===<br />
<br />
Microsoft imposes limitations on which firmware boot mode and partitioning style can be supported based on the version of Windows used:<br />
<br />
{{Note|The following points only list configurations supported by the [[Wikipedia:Windows Setup|Windows Setup]] even though Windows itself may still work on these unsupported configurations. A good example of this is Windows 11 which still works on a BIOS/MBR configuration once the Windows Setup check is bypassed.}}<br />
<br />
* '''Windows XP''' both '''x86 32-bit''' and '''x86_64''' (also called x64) (RTM and all Service Packs) versions do not support booting in [[UEFI]] mode (IA32 or x86_64) from any disk ([[MBR]] or [[GPT]]) OR in BIOS mode from GPT disk. They support only BIOS boot and only from MBR disk.<br />
* '''Windows Vista''' or '''7''' '''x86 32-bit''' (RTM and all Service Packs) versions support booting in BIOS mode from MBR disks only, not from GPT disks. They do not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. They support only BIOS boot and only from MBR disk.<br />
* '''Windows Vista RTM x86_64''' (only RTM) version support booting in BIOS mode from MBR disks only, not from GPT disks. It does not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. It supports only BIOS boot and only from MBR disk.<br />
* '''Windows Vista''' (SP1 and above, not RTM) and '''Windows 7''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR disk only. They do not support IA32 (x86 32-bit) UEFI boot from GPT/MBR disk, x86_64 UEFI boot from MBR disk, or BIOS boot from GPT disk.<br />
* '''Windows 8/8.1''' and '''10''' '''x86 32-bit''' support booting in IA32 UEFI mode from GPT disk only, OR in BIOS mode from MBR disk only. They do not support x86_64 UEFI boot from GPT/MBR disk, x86_64 UEFI boot from MBR disk, or BIOS boot from GPT disk. On market, the only systems known to ship with IA32 (U)EFI are some old Intel Macs (pre-2010 models?) and Intel Atom System-on-Chip (Clover trail and Bay Trail) Windows Tablets, which boot ONLY in IA32 UEFI mode and ONLY from GPT disk.<br />
* '''Windows 8/8.1''' and '''10''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR disk only. They do not support IA32 UEFI boot, x86_64 UEFI boot from MBR disk, or BIOS boot from GPT disk.<br />
* '''Windows 11''' only supports '''x86_64''' and a boot in UEFI mode from GPT disk. <br />
<br />
In case of pre-installed Systems:<br />
<br />
* All systems pre-installed with Windows XP, Vista or 7 32-bit, irrespective of Service Pack level, bitness, edition (SKU) or presence of UEFI support in firmware, boot in BIOS/MBR mode by default.<br />
* MOST of the systems pre-installed with Windows 7 x86_64, irrespective of Service Pack level, bitness or edition (SKU), boot in BIOS/MBR mode by default. Very few recent systems pre-installed with Windows 7 are known to boot in x86_64 UEFI/GPT mode by default.<br />
* ALL systems pre-installed with Windows 8/8.1, 10 and 11 boot in UEFI/GPT mode. Up to Windows 10, the firmware bitness matches the bitness of Windows, ie. x86_64 Windows boot in x86_64 UEFI mode and 32-bit Windows boot in IA32 UEFI mode.<br />
<br />
The best way to detect the boot mode of Windows is to do the following[https://www.eightforums.com/tutorials/29504-bios-mode-see-if-windows-boot-uefi-legacy-mode.html]:<br />
<br />
* Boot into Windows<br />
* Press {{ic|Win+R}} keys to start the Run dialog<br />
* In the Run dialog type {{ic|msinfo32.exe}} and press Enter<br />
* In the '''System Information''' windows, select ''System Summary'' on the left and check the value of '''BIOS mode''' item on the right<br />
* If the value is {{ic|UEFI}}, Windows boots in UEFI/GPT mode. If the value is {{ic|Legacy}}, Windows boots in BIOS/MBR mode.<br />
<br />
In general, Windows forces type of partitioning depending on the firmware mode used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If Windows is booted in Legacy BIOS mode, it can be installed only to an MBR disk. This is a limitation enforced by Windows Setup, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI/MBR or BIOS/GPT configuration. Thus Windows only supports either UEFI/GPT boot or BIOS/MBR configuration.<br />
<br />
{{Tip|Windows 10 version 1703 and newer supports converting from BIOS/MBR to UEFI/GPT using [https://docs.microsoft.com/en-us/windows/deployment/mbr-to-gpt MBR2GPT.EXE].}}<br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on which [[boot loader]] is used and/or how the boot loader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of boot loader depends on the firmware type and disk [[partitioning]] configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI/GPT boot or BIOS/MBR boot. See https://support.microsoft.com/kb/2581408 for more information.<br />
<br />
=== Install media limitations ===<br />
<br />
Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) provide only IA32 UEFI firmware without Legacy BIOS (CSM) support (unlike most of the x86_64 UEFI systems), due to Microsoft Connected Standby Guidelines for OEMs. Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO ({{Bug|53182}}), the official install media cannot boot on these systems. See [[Unified Extensible Firmware Interface#UEFI firmware bitness]] for more information and available workarounds.<br />
<br />
=== Bootloader UEFI vs BIOS limitations ===<br />
<br />
Most of the linux bootloaders installed for one firmware type cannot launch or chainload bootloaders of the other firmware type. That is, if Arch is installed in UEFI/GPT or UEFI/MBR mode in one disk and Windows is installed in BIOS/MBR mode in another disk, the UEFI bootloader used by Arch cannot chainload the BIOS installed Windows in the other disk. Similarly if Arch is installed in BIOS/MBR or BIOS/GPT mode in one disk and Windows is installed in UEFI/GPT in another disk , the BIOS bootloader used by Arch cannot chainload UEFI installed Windows in the other disk. <br />
<br />
The only exceptions to this are [[GRUB]] in Apple Macs in which GRUB in UEFI mode can boot BIOS installed OS via {{ic|appleloader}} command (does not work in non-Apple systems), and [[rEFInd]] which technically supports booting legacy BIOS OS from UEFI systems, but [https://rodsbooks.com/refind/using.html#legacy does not always work in non-Apple UEFI systems] as per its author Rod Smith. <br />
<br />
However if Arch is installed in BIOS/GPT in one disk and Windows is installed in BIOS/MBR mode in another disk, then the BIOS boot loader used by Arch CAN boot the Windows in the other disk, if the boot loader itself has the ability to chainload from another disk. <br />
<br />
{{Note|To dual-boot with Windows on same disk, Arch should follow the same firmware boot mode and partitioning combination used by the Windows installation.}}<br />
<br />
[[Wikipedia:Windows Setup|Windows Setup]] creates a 100 MiB [[EFI system partition]] (except for [[Advanced Format]] 4K native drives where it creates a 300 MiB ESP), so multiple [[kernel]] usage is limited. Workarounds include:<br />
<br />
* Mount ESP to {{ic|/efi}} and use a [[boot loader]] that has file system drivers and is capable of launching kernels that reside on other partitions.<br />
* Expand the EFI system partition, typically either by decreasing the Recovery partition size or moving the Windows partition ('''UUIDs will change''').<br />
* Backup and delete unneeded fonts in {{ic|''esp''/EFI/Microsoft/Boot/Fonts/}} [https://support.microsoft.com/en-us/help/3086249/we-couldn-t-update-system-reserved-partition-error-installing-windows].<br />
* Backup and delete unneeded language directories in {{ic|''esp''/EFI/Microsoft/Boot/}} (e.g. to only keep {{ic|en-US}}).<br />
<br />
=== UEFI Secure Boot ===<br />
<br />
All pre-installed Windows 8/8.1, 10 and 11 systems by default boot in UEFI/GPT mode and have UEFI Secure Boot enabled by default. This is mandated by Microsoft for all OEM pre-installed systems.<br />
<br />
Arch Linux install media does not support Secure Boot yet. See [[Secure Boot#Booting an installation medium]]. <br />
<br />
It is advisable to disable UEFI Secure Boot in the firmware setup manually before attempting to boot Arch Linux. Windows 8/8.1, 10 and 11 SHOULD continue to boot fine even if Secure boot is disabled. The only issue with regards to disabling UEFI Secure Boot support is that it requires physical access to the system to disable secure boot option in the firmware setup, as Microsoft has explicitly forbidden presence of any method to remotely or programmatically (from within OS) disable secure boot in all Windows 8/8.1 and above pre-installed systems<br />
<br />
{{Note|<br />
* If Windows used Bitlocker and stored the key in the TPM for automatic unlock on boot, it fails to boot when Secure Boot is disabled, instead showing a Bitlocker recovery screen. This is not permanent however, and you can easily boot Windows again by simply re-enabling Secure Boot.<br />
* On Windows 11, disabling Secure Boot prevents Windows Hello, WSM (Windows Subsystem for Android) and Windows Updates from working}}<br />
<br />
=== Fast Startup and hibernation ===<br />
<br />
There are two OSs that can be hibernated, you can hibernate Windows and boot Linux (or another OS), or you can hibernate Linux and boot Windows, or hibernate both OSs.<br />
<br />
{{Warning|Data loss can occur if Windows hibernates and you dual boot into another OS and make changes to files on a filesystem (such as NTFS) that can be read and written to by Windows and Linux, and that has been mounted by Windows [https://superuser.com/questions/39532/hibernating-and-booting-into-another-os-will-my-filesystems-be-corrupted/136814#136814]. Similarly, data loss can occur if Linux hibernates, and you dual boot into another OS etc. Windows may hibernate even when you press shutdown, see section [[#Windows settings]].}}<br />
<br />
For the same reason, if you share one EFI System Partition between Windows and Linux, then the EFI System Partition may be damaged if you hibernate (or shutdown with Fast Startup enabled) Windows and then start Linux, or hibernate Linux and then start Windows.<br />
<br />
{{Pkg|ntfs-3g}} added a [https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/559270a8f67c77a7ce51246c23d2b2837bcff0c9/ safe-guard] to prevent read-write mounting of hibernated NTFS filesystems, but the NTFS driver within the Linux kernel has no such safeguard.<br />
<br />
Windows cannot read filesystems such as ext4 by default that are commonly used for Linux. These filesystems do not have to be considered, unless you install a Windows driver for them.<br />
<br />
==== Windows settings ====<br />
<br />
Fast Startup is a feature in Windows 8 and above that hibernates the computer rather than actually shutting it down to speed up boot times.<br />
<br />
There are multiple options regarding the Windows settings for Fast Startup and hibernation that are covered in the next sections.<br />
* disable Fast Startup and disable hibernation<br />
* disable Fast Startup and enable hibernation<br />
* enable Fast Startup and enable hibernation<br />
<br />
The procedure of disabling Fast Startup is described in the tutorials for [https://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html Windows 8], [https://www.tenforums.com/tutorials/4189-turn-off-fast-startup-windows-10-a.html Windows 10] and [https://www.elevenforum.com/t/turn-on-or-off-fast-startup-in-windows-11.1212/ Windows 11]. In any case if you disable a setting, make sure to disable the setting and then shut down Windows, before installing Linux; note that rebooting is not sufficient.<br />
<br />
===== Disable Fast Startup and disable hibernation =====<br />
<br />
This is the safest option, and recommended if you are unsure about the issue, as it requires the least amount of user awareness when rebooting from one OS into the other. You may share the same EFI System Partition between Windows and Linux.<br />
<br />
===== Disable Fast Startup and enable hibernation =====<br />
<br />
This option requires user awareness when rebooting from one OS into the other.<br />
If you want to start Linux while Windows is hibernated, which is a common use case, then<br />
* you must use a separate EFI System Partition (ESP) for Windows and Linux, and ensure that Windows does not mount the ESP used for Linux. As there can only be one ESP per drive, the ESP used for Linux must be located on a separate drive than the ESP used for Windows. In this case Windows and Linux can still be installed on the same drive in different partitions, if you place the ESP used by linux on another drive than the Linux root partition.<br />
* you can not read-write mount any filesystem in Linux, that is mounted by Windows while Windows is hibernated. You should be extremely careful about this, and also consider [[Automount]] behaviour.<br />
* If you shut down Windows fully, rather than hibernating, then you can read-write mount the filesystem.<br />
<br />
{{Note|You can avoid this issue for a drive by mounting a drive as an external drive in Windows and ejecting the drive in Windows before hibernating.}}<br />
<br />
===== Enable Fast Startup and enable hibernation =====<br />
<br />
The same considerations apply as in case "Disable Fast Startup and enable hibernation", but since Windows can not be shut down fully, only hibernated, you can never read-write mount any filesystem that was mounted by Windows while Windows is hibernated.<br />
<br />
{{Note|Windows updates may re-enable Fast Startup, as reported in [https://tedstechshack.com/2017/07/03/warning-multi-booting-uefi-system-windows-10-fast-startup-doubt-reboot/].}}<br />
<br />
=== Windows filenames limitations ===<br />
<br />
Windows is limited to filepaths being shorter than [https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation 260 characters].<br />
<br />
Windows also puts [https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conventions certain characters off limits] in filenames for reasons that run all the way back to DOS:<br />
<br />
* {{ic|<}} (less than)<br />
* {{ic|>}} (greater than)<br />
* {{ic|:}} (colon)<br />
* {{ic|"}} (double quote)<br />
* {{ic|/}} (forward slash)<br />
* {{ic|\}} (backslash)<br />
* {{ic|{{!}}}} (vertical bar or pipe)<br />
* {{ic|?}} (question mark)<br />
* {{ic|*}} (asterisk)<br />
<br />
These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running {{ic|chkdsk}} will most likely cause them to be deleted. This can lead to potential data-loss.<br />
<br />
[[NTFS-3G]] applies Windows restrictions to new file names through the {{ic|windows_names}} option: {{man|8|ntfs-3g|Windows_Filename_Compatibility}} (see [[fstab]]).<br />
<br />
== Installation ==<br />
<br />
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create and resize partitions for Linux while leaving the existing Windows partitions untouched. The Windows installation will create the [[EFI system partition]] which can be used by your Linux [[boot loader]].<br />
<br />
=== Windows before Linux ===<br />
<br />
==== BIOS systems ====<br />
<br />
===== Using a Linux boot loader =====<br />
<br />
You may use any multi-boot supporting BIOS [[boot loader]].<br />
<br />
===== Using the Windows Vista/7/8/8.1 boot loader =====<br />
<br />
This section explains how to : install a linux bootloader on a partition instead of the MBR ; copy this bootloader to a partition readable by the windows bootloader ; use the windows bootloader to start said copy of the linux bootloader. <br />
<br />
{{Note|Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but usage of an extended partition has been documented as working.}}<br />
<br />
* When installing the boot loader, install it on your {{ic|/boot}} partition rather than the MBR. For details on doing this with GRUB, see [[GRUB/Tips and tricks#Install to partition or partitionless disk]], for Syslinux, see the note at [[Syslinux#Manual install]], for LILO see [[LILO#Install to partition or partitionless disk]].<br />
<br />
* Make a copy of the VBR: {{bc|1=dd if=/dev/''disk'' of=''/path/to/''linux.bin bs=512 count=1}} where {{ic|/dev/''disk''}} is the path of the partition on which your bootloader is installed and {{ic|/path/to/}} is the mounted filesystem on which you want the copy to be readable by the Windows bootloader. <br />
<br />
* On Windows, the linux.bin file should now be accessible. Run '''cmd''' with administrator privileges (navigate to ''Start > All Programs > Accessories'', right-click on ''Command Prompt'' and select ''Run as administrator''): {{bc|bcdedit /create /d "Linux" /application BOOTSECTOR}} BCDEdit will return a [[wikipedia:Universally_unique_identifier|UUID]] for this entry. This will be refered to as {{ic|''UUID''}} in the remaining steps. {{bc|1=bcdedit /set ''UUID'' device partition=c: (or the drive letter on which linux.bin is kept)<nowiki> <br />
</nowiki>bcdedit /set ''UUID'' path ''\path\to\''linux.bin<nowiki> <br />
</nowiki>bcdedit /displayorder ''UUID'' /addlast<nowiki> <br />
</nowiki>bcdedit /timeout 30}}<br />
<br />
On reboot, both Windows and Linux should now show up in the Windows bootloader. <br />
<br />
{{Note|On some hardware, the Windows boot loader is used to start another OS with a second power button (e.g. Dell Precision M4500).}}<br />
<br />
For more details, see https://www.iceflatline.com/2009/09/how-to-dual-boot-windows-7-and-linux-using-bcdedit/<br />
<br />
==== UEFI systems ====<br />
<br />
If you already have Windows installed, it will already have created some partitions on a [[GPT]]-formatted disk:<br />
<br />
* a [[Wikipedia:Windows Recovery Environment|Windows Recovery Environment]] partition, generally of size 499 MiB, containing the files required to boot Windows (i.e. the equivalent of Linux's {{ic|/boot}}),<br />
* an [[EFI system partition]] with a [[FAT32]] filesystem,<br />
* a [[Wikipedia:Microsoft Reserved Partition|Microsoft Reserved Partition]], generally of size 128 MiB,<br />
* a Microsoft basic data partition with a NTFS filesystem, which corresponds to {{ic|C:}},<br />
* potentially system recovery and backup partitions and/or secondary data partitions (corresponding often to {{ic|D:}} and above).<br />
<br />
Using the Disk Management utility in Windows, check how the partitions are labelled and which type gets reported. This will help you understand which partitions are essential to Windows, and which others you might repurpose. The Windows Disk Management utility can also be used to shrink Windows (NTFS) partitions to free up disk space for additional partitions for Linux.<br />
<br />
{{Warning|The first 4 partitions in the above list are essential, do not delete them.}}<br />
<br />
You can then proceed with [[partitioning]], depending on your needs.<br />
<br />
Mind that an additional EFI system partition should not be created, as it may [https://support.microsoft.com/en-us/help/2879602/unable-to-boot-if-more-than-one-efi-system-partition-is-present prevent Windows from booting]. Simply [[EFI system partition#Mount the partition|mount the existing partition]].<br />
<br />
{{Note|It only appears when Linux is installed on the second hard disk and a new EFI system partition is created on the second hard disk.}}<br />
<br />
The boot loader needs to support chainloading other EFI applications to do dual boot Windows / Linux.<br />
<br />
{{Tip|[[rEFInd]] and [[systemd-boot]] will autodetect ''Windows Boot Manager'' ({{ic|\EFI\Microsoft\Boot\bootmgfw.efi}}) and show it in their boot menu automatically. For [[GRUB]] follow either [[GRUB#Windows installed in UEFI/GPT mode]] to add boot menu entry manually or [[GRUB#Detecting other operating systems]] for a generated configuration file.}}<br />
<br />
Computers that come with newer versions of Windows often have [[Secure Boot]] enabled. You will need to take extra steps to either disable Secure Boot or to make your installation media compatible with secure boot (see above and in the linked page).<br />
<br />
=== Linux before Windows ===<br />
<br />
Even though the recommended way to setup a Linux/Windows dual booting system is to first install Windows, it can be done the other way around. In contrast to installing Windows before Linux, you will have to set aside a partition for Windows, say 40GB or larger, in advance. Or have some unpartitioned disk space, or create and resize partitions for Windows from within the Linux installation, before launching the Windows installation.<br />
<br />
==== UEFI firmware ====<br />
<br />
Windows will use the already existing [[EFI system partition]]. In contrast to what was [[#UEFI systems|stated earlier]], it is unclear if a single partition for Windows, without the Windows Recovery Environment and without Microsoft Reserved Partition, will not do.<br />
<br />
Follows an outline, assuming [[Secure Boot]] is disabled in the firmware.<br />
<br />
# Boot into windows installation. Watch to let it use only the intended partition, but otherwise let it do its work as if there is no Linux installation.<br />
# Follow the [[#Fast Startup and hibernation]] section.<br />
# Fix the ability to load Linux at start up, perhaps by following [[#Cannot boot Linux after installing Windows]]. It was already mentioned in [[#UEFI systems]] that some Linux boot managers will autodetect ''Windows Boot Manager''. Even though newer Windows installations have an advanced restart option, from which you can boot into Linux, it is advised to have other means to boot into Linux, such as an arch installation media or a live CD.<br />
<br />
===== Windows 10 with GRUB =====<br />
<br />
The following assumes [[GRUB]] is used as a boot loader (although the process is likely similar for other boot loaders) and that Windows 10 will be installed on a GPT block device with an existing EFI system partition (see the "System partition" section in the [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions Microsoft documentation] for more information).<br />
<br />
Create with program {{ic|gdisk}} on the block device the following three new partitions. See [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions] for more precise partition sizes.<br />
<br />
{| class="wikitable"<br />
! Min size !! Code !! Name !! File system<br />
|-<br />
| 16 MB || 0C01 || Microsoft reserved || N/A<br />
|-<br />
| ~40 GB || 0700 || Microsoft basic data || NTFS<br />
|-<br />
| 300 MB || 2700 || Windows RE || NTFS<br />
|-<br />
|}<br />
<br />
Create NTFS file systems on the new Microsoft basic data and Windows RE (recovery) partitions using the ''mkntfs'' program from package {{Pkg|ntfs-3g}}.<br />
<br />
Reboot the system into a Windows 10 installation media. When prompted to install select the custom install option and install Windows on the Microsoft basic data partition created earlier. This should also install Microsoft EFI files in the EFI partition.<br />
<br />
After installation (set up of and logging into Windows not required), reboot into Linux and [[GRUB#Generate the main configuration file|generate a GRUB configuration]] for the Windows boot manager to be available in the GRUB menu on next boot.<br />
<br />
=== Troubleshooting ===<br />
<br />
==== Couldn't create a new partition or locate an existing one ====<br />
<br />
See [[#Windows UEFI vs BIOS limitations]].<br />
<br />
==== Cannot boot Linux after installing Windows ====<br />
<br />
See [[Unified Extensible Firmware Interface#Windows changes boot order]].<br />
<br />
==== Restoring a Windows boot record ====<br />
<br />
By convention (and for ease of installation), Windows is usually installed on the first partition and installs its partition table and reference to its bootloader to the first sector of that partition. If you accidentally install a bootloader like GRUB to the Windows partition or damage the boot record in some other way, you will need to use a utility to repair it. Microsoft includes a boot sector fix utility {{Ic|FIXBOOT}} and an MBR fix utility called {{Ic|FIXMBR}} on their recovery discs, or sometimes on their install discs. Using this method, you can fix the reference on the boot sector of the first partition to the bootloader file and fix the reference on the MBR to the first partition, respectively. After doing this you will have to [[GRUB#Installation|reinstall GRUB]] to the MBR as was originally intended (that is, the GRUB bootloader can be assigned to chainload the Windows bootloader).<br />
<br />
If you wish to revert back to using Windows, you can use the {{Ic|FIXBOOT}} command which chains from the MBR to the boot sector of the first partition to restore normal, automatic loading of the Windows operating system.<br />
<br />
Of note, there is a Linux utility called {{Ic|ms-sys}} (package {{AUR|ms-sys}} in AUR) that can install MBR's. However, this utility is only currently capable of writing new MBRs (all OS's and file systems supported) and boot sectors (a.k.a. boot record; equivalent to using {{Ic|FIXBOOT}}) for FAT file systems. Most LiveCDs do not have this utility by default, so it will need to be installed first, or you can look at a rescue CD that does have it, such as [https://partedmagic.com/ Parted Magic].<br />
<br />
First, write the partition info (table) again by:<br />
<br />
# ms-sys --partition /dev/sda1<br />
<br />
Next, write a Windows 2000/XP/2003 MBR:<br />
<br />
# ms-sys --mbr /dev/sda # Read options for different versions<br />
<br />
Then, write the new boot sector (boot record):<br />
<br />
# ms-sys -(1-6) # Read options to discover the correct FAT record type<br />
<br />
{{Ic|ms-sys}} can also write Windows 98, ME, Vista, and 7 MBRs as well, see {{Ic|ms-sys -h}}.<br />
<br />
==== The EFI system partition created by Windows Setup is too small ====<br />
<br />
[[Wikipedia:Windows Setup|Windows Setup]] creates a 100 MiB [[EFI system partition]] (except for [[Advanced Format]] 4K native drives where it creates a 300 MiB ESP). This is generally too small to fit everything you need. You can try different tools to resize this partition, but there are usually other partitions in the way, making it, at the very least, difficult. One option is to use the Arch install media to create a single [[EFI system partition]] of your preferred size '''before''' you install Windows on the drive. Windows Setup will use the EFI system partition you made instead of creating its own.<br />
<br />
== Time standard ==<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC, following [[System time#UTC in Microsoft Windows]]. Some versions of Windows revert the hardware clock back to ''localtime'' if they are set to synchronize the time online. This issue appears to be fixed in Windows 10.<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable all [[System time#Time synchronization|time synchronization daemons]]. This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
== Bluetooth pairing ==<br />
<br />
When it comes to pairing Bluetooth devices with both the Linux and Windows installation, both systems have the same MAC address, but will use different link keys generated during the pairing process. This results in the device being unable to connect to one installation, after it has been paired with the other. To allow a device to connect to either installation without re-pairing, follow [[Bluetooth#Dual boot pairing]].<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=140049 Booting Windows from a desktop shortcut]<br />
* [https://github.com/kaipee/grub-reboot2win One-time boot into Windows partition from desktop shortcut]<br />
* [https://github.com/ValdikSS/windows2usb Windows 7/8/8.1/10 ISO to Flash Drive burning utility for Linux (MBR/GPT, BIOS/UEFI, FAT32/NTFS)]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Help_talk:Style&diff=731771Help talk:Style2022-06-05T22:24:23Z<p>Jasonwryan: /* American vs. British English Usage */ Use british, everyone else does</p>
<hr />
<div>==Read this first==<br />
[[Help:Style]] is an official document of the ArchWiki, and it is actively monitored for malicious, unapproved, or poor quality edits. This is necessary to ensure sufficient stability over time, since frequent, undiscussed changes to its rules would defeat the purpose of the guide itself.<br />
<br />
It is probably needless to say that the active supervision of the article makes this very talk page the most important and effective place for discussing every possible improvement to the guide, from the correction of small typos to major changes like the introduction of new rules. Every report or discussion is welcome and will be answered as soon as possible. However, if an existing style rule is under dispute, its current state remains enforced until it is changed, if that ever happens.<br />
<br />
This guide was born after several months of discussions among the administrators and the most active contributors at the time, and it is a compromise among their ideas and those of who has been contributing until now. While new ideas and proposals that are coherent with the guide will probably be accepted and implemented, it is also likely that the requests that aim to radically change the way a particular style issue is already addressed will be discarded. We all must acknowledge the fact that it is reasonably unrealistic to think that all the ArchWiki users will ever completely agree over all the style rules, that is why it becomes necessary that final decisions be made by the administrators: we hope that this concept will be peacefully accepted by everybody, so that we can all collaborate in a more constructive way.<br />
<br />
Thank you for reading this notice and for contributing to the ArchWiki! -- [[ArchWiki:Administrators|The ArchWiki Administrators]] 21:27, 14 January 2012 (EST)<br />
<br />
{{Tip|A way to speed up the addition or modification of style rules is to provide some text that, if approved, can be directly copy-pasted in the guide, just like patches work for bug reports.}}<br />
__TOC__<br />
== Related links ==<br />
<br />
=== See also or Related in Article Summary? ===<br />
<br />
I think we'd better be coherent whether to keep links, references etc. either in a "See also" section at the bottom of the article, or in one (or more) boxes under the Article Summary at the top right of the article.<br />
<br />
See also [[#Article summary templates]].<br />
<br />
-- [[User:Kynikos|Kynikos]] 15:15, 21 September 2011 (EDT)<br />
<br />
:This is more a reminder than other, but I'm starting to like the idea of adding the rule to keep related ArchWiki articles in the Article Summary box only, and external links in See also sections only. Well, this way the "See also" default may even be changed (with bots, don't worry!) to a non-imperative, descriptive title like "Additional resources", "External links" or something like that. -- [[User:Kynikos|Kynikos]] 07:06, 14 December 2011 (EST)<br />
:Also remember that many external links in summaries can be found with [[Special:WhatLinksHere/Template:Article_summary_link]]. -- [[User:Kynikos|Kynikos]] 07:41, 24 January 2012 (EST)<br />
<br />
'''Advantages of links in See also:'''<br />
*There is more space for link descriptions<br />
*It is likely one will read or skim the article before actively looking for additional reading material. This naturally leaves the reader at the end of the article. It is convenient for the reader in this case if links are at the end of the article. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*It ''seems'' more common (elsewhere) to have links at the end of articles (when they are not inline with the rest of the text). Following common convention it may be better from a usability perspective. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*:Especially for people used to Wikipedia, which uses the same wiki software. [[User:Vadmium|Vadmium]] 11:12, 26 October 2011 (EDT).<br />
*I am not sure how much we care about this but it having the links at the end could be more friendly to small form factor screens and screen readers. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*As a section, "See also" gets its own TOC entry granting easy access from near the top of the article. Alternatively one may press the END key. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*More formatting options here than in summary. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*More inclined to put external, or less closely related stuff here. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*''See also'' section would not be skipped if you start reading the main text sequentially from the top. [[User:Vadmium|Vadmium]].<br />
*''[add more advantages...]''<br />
<br />
'''Advantages of links in Article Summary:'''<br />
*Immediately visible<br />
*Beyond some minor editing inconvenience, is there any real disadvantage of having the most ''interesting'' links in both locations? It could be advantageous for the reader to have some links in both locations. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*I think putting very closely related links in the summary gives the topic more cohesion, and as James Eder said, they could be included at the bottom as well. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*It would theoretically be more effective in preventing duplication of content within the wiki, as (unexperienced) editors would have a clearer view of the articles where related content could already exist (true especially with series (or "rings") of articles on the same subject). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:46, 29 September 2013 (UTC)<br />
*''[add more advantages...]''<br />
<br />
=== Lists ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Sound_system&curid=10626&diff=201543&oldid=197917], I was wondering if related links in "See also" sections or article summaries should be avoided if already present in the body of the article. I'd prefer having complete lists of related articles even if that implies duplicating some of them. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:> I'd prefer having complete lists of related articles even if that implies duplicating some of them<br />
:I'd prefer this way as well. Sadly listing ''all'' related articles may occupy most of vertical space, so there should be clear guidelines regarding choise of related links. And editors often don't have time to read even [[Help:Style]]... On the other hand, defining simple rule like "only links not present in text" can eliminate the very requirement for any additional rules. --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:: "only links not present in text" is too strict I think. Related links make some page more "visible" to readers. For example, I often click on them to learn more info about the same topic. But to be honest, I rarely click on the "in page links" even the links shown clearly in "See Also". They are much harder to be found and clicked. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:50, 19 May 2012 (UTC)<br />
<br />
=== Definition ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Boot_Debugging&diff=prev&oldid=201554], I was wondering if we needed a definition of what are the conditions under which an article can be considered related to another one. Honestly I can't think of something suitable at the moment, if somebody has good ideas, they're welcome here. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:Few ideas:<br />
:* Alternatives to software, described in article<br />
:* Methods and techniques alternative to ones described in article<br />
:* Software <-> it's use case<br />
:* software/technique <-> it's developer<br />
:--[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
<br />
==List of Applications and See also==<br />
# I suggest for lists like [[List_of_Applications/Multimedia]] to use capital letter for the first letter of the description, NO dots at the end (this behaviour seems to be preminent in Wikipedia) and to avoid totally articles ('A ..' is annoying). Is it ok?<br />
# In the same list it may be fair to put <nowiki>{{Grp|group}}</nowiki> beside items that have their one.<br />
# The '''See also''' section should be treated as above lists.<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 18:00, 19 May 2013 (UTC)<br />
<br />
:I support 1. and 2. except for the dots at the end of descriptions, which I would require instead, since sometimes the App template has long descriptions, even made of several sentences, and including all the puntuation only omitting the final dot would look weird to me.<br />
:About 3. I don't understand what you mean, can you be more specific?<br />
:However I'm also wondering if these rules should be hosted here (if they refer to the use of Template:App) or in [[Talk:List of Applications]] (if they refer only to [[List of Applications]] and subpages).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:23, 26 May 2013 (UTC)<br />
::About 3: I just mean that a section like [[Aria2#See_also]] must have capitalized letters and no dots (or whatever the standard would be).<br />
::About the hosting place: page like [[CD_Burning#Burning_CDs_with_a_GUI]] or [[Conky#AUR_packages]] are not directly related to [[List of Applications]], so I think it is worth to host a rule here. Plus this rule would apply also to any other list, like [[E4rat#Process]] --[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 16:53, 26 May 2013 (UTC)<br />
:::Still about 3: I see, usually See-also links have much shorter descriptions, in that case I would apply a no-dot policy. Still open to more opinions though.<br />
:::Hosting place: a rule about lists of applications would probably best fit in [[Template:App]], also in light of my plans to decentralize style rules in general. A rule about See also sections would instead fit this guide indeed, at least for the moment.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:17, 28 May 2013 (UTC)<br />
<br />
== One link to the package in a paragraph is enough ==<br />
Do we need multiple links to the same package, wiki article etc. in the same paragraph? I understand that if the article is very long, the links may be used in different sections, but isn't "[[Arch_boot_process#Init_process|In the past, Arch used SysVinit as the init process. Now on new installs, Systemd is used by default. Existing SysVinit users are recommended to switch to systemd.]]" with 2 links to SysVinit and 2 links to systemd a bit too much? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 23:15, 21 May 2013 (UTC)<br />
:First thing, probably in the title you mean links to articles in general, not only packages, right?<br />
:However, I definitely agree, I guess we could extend the rule to the same section or even the whole article, but I'd like to exclude some cases, like "See also" sections (see [[#Lists of related links]]), and to make the rule compatible with [[Help:Style#Official packages]] and similar.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:11, 22 May 2013 (UTC)<br />
::Just a reminder: this is affected by [[Help:Style/Formatting_and_Punctuation#First_instances]], not sure if it sould be mentioned directly on [[Help:Style]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:35, 1 September 2013 (UTC)<br />
<br />
== git/vcs/source builds ==<br />
<br />
In some article there are source build instruction like [[Jumanji#Method_2:_From_Source]] and [https://wiki.archlinux.org/index.php?title=Logitech_Unifying_Receive&direction=prev&oldid=260677#From_AUR] or AUR git references like [https://wiki.archlinux.org/index.php?title=Bumblebee&oldid=259841#Installation]. I think they are pointless because:<br />
* of course you can build application on your own, there is no need to say that.<br />
* there is plenty of git/patched/vcs variants in AUR. One can decide to install them by their choice.<br />
What about a rule to forbid git/source references unless they are the only chance?<br />
::(oh no, another time) -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 21:15, 2 June 2013 (UTC)<br />
:IMHO 'make && make install' instructions should go.<br />
:I have nothing against describing different AUR packages, whether VCS or not. PKGBUILDs are sometimes pretty complex and it's not obvious what's the difference between the various AUR versions of a package - if any.<br />
:Please sign your talk page edits [[Help:Discussion#Join_a_discussion]]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:21, 2 June 2013 (UTC)<br />
::Yes, manual compilation instructions can be removed, but ''only'' when an AUR package is available. A rule may be added for this.<br />
::No, please don't remove links to "alternative" versions of packages in [[AUR]]; treat every AUR package as the others, there are not AUR packages more "official" than others: if they all install the same application, they _can_ (i.e. ''not'' _must_) be mentioned in the same article.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:05, 3 June 2013 (UTC)<br />
::Just mentioning a recent related example, [https://wiki.archlinux.org/index.php?title=Isync&diff=262333&oldid=253631], that I consider perfectly reasonable. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:10, 12 June 2013 (UTC)<br />
<br />
== Distinguish fragment identifier interwiki links? ==<br />
<br />
Similarly to [[#Visited_links_color]], can we distinguish [[Wikipedia:Fragment identifier|fragment identifier]] interwiki links (those written as {{ic|<nowiki>[[#foo]]</nowiki>}}) from other interwiki links (generally pointing to some other page)? I find something like {{ic|<nowiki>[[#PolicyKit authorization|PolicyKit authorization]]</nowiki>}} [https://wiki.archlinux.org/index.php?title=Libvirt&diff=next&oldid=274533] kind of confusing, it should be clear that the link points to a section on current page and not to separate page. Possibilities:<br />
<br />
# prefer {{ic|<nowiki>[[#foo]]</nowiki>}} instead of {{ic|<nowiki>[[#foo|foo]]</nowiki>}} - this does not solve something like {{ic|<nowiki>[[#Run daemon|run the daemon]]</nowiki>}}, also note that the fragment is case-sensitive<br />
# add some icon (superscript?) in front of/behind the link, I was thinking about the arrow shown in [https://wiki.archlinux.org/index.php?title=Help_talk:Style&action=history history pages] (but without the link to the section)<br />
# use some other color<br />
<br />
I'd vote for the second, it seems to be the most universal. Or does anybody have some other suggestion?<br />
<br />
(Looking at the second link in this post, something similar could be done for links to Wikipedia. In this case, I propose adding superscript {{ic|W}} behind the link.)<br />
<br />
Sorry if this has already been discussed somewhere else, I don't have the time to search it right now.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 7 October 2013 (UTC)<br />
<br />
:Talking of distinguishing links, external https links are not distinguished either:<br />
::[http://foobar.org http]<br />
::[https://foobar.org https]<br />
:Perhaps a bug?<br />
: -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:10, 10 October 2013 (UTC)<br />
<br />
::About the little icons next to links, I guess we could do it easily with CSS attribute selectors in the skin files.<br />
::About the https icon in particular, it looks it was disabled on purpose for some reason: [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/tree/skins/archlinux/arch.css] (line 67) I'd be curious to know why.<br />
::Of course to implement all this, a bug report should be opened and very likely patches should be prepared, so if you think you have the time to work on it, the project is at [https://github.com/archlinux/archwiki] with links to clone the repo. I'd be interested in giving a hand of course :)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:53, 10 October 2013 (UTC)<br />
<br />
:::Thanks for pointing me to the right direction, here's the commit about the https links: [https://github.com/archlinux/archwiki/commit/e8b7a08c663a0fb392a24c67ec1dea59057f480a/skins/archlinux/archlinux.css].<br />
:::Let's see if I can get to this again this weekend...<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:05, 10 October 2013 (UTC)<br />
<br />
::::I sent an email to [[User:Pierre|Pierre]] about the commit in November and did not receive any reply, so I submitted a bug report: {{Bug|38769}} - hopefully it won't be missed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:00, 2 February 2014 (UTC)<br />
<br />
:::::We'll see, I've submitted a patch, but unfortunately wiki bugs, even if easy to fix, have a [https://bugs.archlinux.org/task/35545 long life]... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:17, 3 February 2014 (UTC)<br />
<br />
::::::Interesting, the https links are now ''sometimes'' equipped with a lock icon. It seems that some domains are excluded by the following CSS (which I got with the help of Firebug): {{bc|<nowiki><br />
#bodyContent a.external[href^="http://archlinux.org"],<br />
#bodyContent a.external[href^="http://www.archlinux.org"],<br />
#bodyContent a.external[href^="http://wiki.archlinux.org"],<br />
#bodyContent a.external[href^="http://aur.archlinux.org"],<br />
#bodyContent a.external[href^="http://bbs.archlinux.org"],<br />
#bodyContent a.external[href^="http://bugs.archlinux.org"],<br />
#bodyContent a.external[href^="https://archlinux.org"],<br />
#bodyContent a.external[href^="https://www.archlinux.org"],<br />
#bodyContent a.external[href^="https://wiki.archlinux.org"],<br />
#bodyContent a.external[href^="https://aur.archlinux.org"],<br />
#bodyContent a.external[href^="https://bbs.archlinux.org"],<br />
#bodyContent a.external[href^="https://bugs.archlinux.org"] {<br />
background: none repeat scroll 0 0 rgba(0, 0, 0, 0);<br />
padding-right: 0;<br />
}<br />
</nowiki>}}<br />
::::::Another interesting thing about this is that I could not find the snippet anywhere in the [https://github.com/archlinux/archwiki git]...<br />
::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:44, 14 December 2014 (UTC)<br />
<br />
:::::::Eheh maybe you should have looked at [[Special:RecentChanges]] :) (still working on it, this may have numerous applications/consequences) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:51, 14 December 2014 (UTC)<br />
<br />
::::::::Well that is the last place I would search in, mystery solved. Thanks for testing the [[MediaWiki:Archlinux.css|workaround]], you surely got me on that one. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:35, 14 December 2014 (UTC)<br />
<br />
== Problem with keyboard keys style ==<br />
<br />
I could use some help with [[Keyboard Shortcuts]]:<br />
<br />
<s>According to [[Help:Style#Keyboard_keys]], {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} should be {{ic|Ctrl+Alt++}}, but is that clear enough? (see [[Keyboard_Shortcuts#X11]])</s><br />
<br />
Also, what would be the preferred style for showing multiple shortcuts for some modifier combination?:<br />
<br />
* {{ic|Alt}}+{{ic|.}}or{{ic|_}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}}/{{ic|-}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|F1}}, {{ic|F2}}, {{ic|F3}}, ...<br />
<br />
(note: someone used {{ic|&uArr; Shift}} on that page, the arrow looks really funny :D )<br />
<br />
'''Edit:''' the {{ic|Ctrl+Alt++}} shortcut was either dropped from X or is specific to NVIDIA, so I've [https://wiki.archlinux.org/index.php?title=Keyboard_Shortcuts&diff=288958&oldid=288082 removed it] from the list of standard shortcuts. The only references I found were about 6 years old, the original is probably [http://ubuntuforums.org/showthread.php?t=83973 this].<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:22, 16 December 2013 (UTC)<br />
<br />
:(I don't wanna know where you've downloaded the font you're using with your browser... XD )<br />
:Oh well, even though {{ic|Ctrl+Alt++}} was (luckily?) outdated in that context, that's certainly a big flaw in the style rule... What do we want to do, switch to the {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} format? It would invalidate many of the style edits that have been done in the last months, but a bug is a bug ^^ Any better ideas?<br />
:About variable combinations, maybe we can just give some examples but leave the choice up to the editor?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:48, 17 December 2013 (UTC)<br />
<br />
::I would not change the rule for just one shortcut (resp. two: {{ic|Ctrl+Alt+-}}), converting it back would be really exhausting. If another instance appears, I'd create an exception for it. Or, even better, just link to an external documentation :P<br />
::Regarding the second problem I agree with leaving it up to the editor. Examples could be:<br />
::* press {{ic|Alt+.}} or {{ic|Alt+_}}<br />
::* press {{ic|Ctrl+Alt+F''N''}} to switch to the {{ic|''N''}}-th virtual console<br />
::i.e. basically use the full, expanded form or the [[Help:Style/Formatting_and_Punctuation#Pseudo-variables_in_file.2Fcommand_line_contents|pseudo-variables]].<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 18 December 2013 (UTC)<br />
<br />
:::Well, let's just suspend this discussion until a similar problem is found again then, if ever. I'll think about closing it next time I'll come here to do some general clean up. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:25, 19 December 2013 (UTC)<br />
<br />
::::Putting spaces around the {{ic|+}} character would mitigate some of the confusion in the example Lahwaacz pointed out, but this would unfortunately require a lot of work to bring everything up to a new standard.<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:32, 11 January 2014 (UTC)<br />
<br />
:::::Um... {{ic|Ctrl + +}} doesn't look much clearer than {{ic|Ctrl++}} to me, if one day we'll need to change the rule for keys, we'll better do it the safest way, which probably is {{ic|Ctrl}}+{{ic|+}}, since as you point out it's going to be "a lot of work" in any case. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:51, 12 January 2014 (UTC)<br />
<br />
:I'm very late to the party, but [[:User:NetSysFire|NetSysFire]] suggested the use of {{ic|Minus}}/{{ic|Plus}} in place of {{ic|-}}/{{ic|+}}. I think this looks clear enough (see [[Special:PermanentLink/662898#Zoom in/out keyboard shortcuts don't work on some apps|GNOME/Troubleshooting]]) while also adhering to the existing guidelines. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 19:36, 19 April 2021 (UTC)<br />
<br />
=== kbd tag ===<br />
<br />
Huh, what about [https://wiki.archlinux.org/index.php?title=Kernel_parameters&diff=next&oldid=445462]? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:02, 10 August 2016 (UTC)<br />
<br />
:I remember discussing whether to favor the html rendering correctness to the detriment of wiki syntax Simplicity or vice versa, I think it was something about indentation, I don't have the time to search for the discussion but IIRC we decided to keep the wiki syntax simple and be less strict with the html output, so I endorse [https://wiki.archlinux.org/index.php?title=Kernel_parameters&diff=next&oldid=446131]. – [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:27, 10 August 2016 (UTC)<br />
<br />
::Give a suggestion, how about creating [[Template:Keyboard key]] (or a shorter name?)? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 01:32, 13 July 2020 (UTC)<br />
<br />
== Grammar errors throughout Help:Style ==<br />
<br />
I've found a large amount of grammar errors throughout [[Help:Style]], and it would be quite tedious to list a before and after for each one here in order to get them fixed. Would it be possible to either temporarily unlock [[Help:Style]] for editing (and closely monitor it for unauthorized changes), or if you don't want to unlock it for editing, should I just provide a pastebin with the revised wiki markup that you can copy/paste into the locked page? The downside to the latter option is that one really large change can be a pain to sort through in the history due to the lack of more verbose comments; although, if it's mostly simple grammar fixes, I guess this wouldn't be too big of a problem, as the change comments would likely be quite minimal.<br />
<br />
-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 03:41, 11 January 2014 (UTC)<br />
<br />
:It would be awesome if you could fix those errors, it will also be a good chance for me to improve my English: the article is unlocked now. Just make sure not to alter the explicit ''and'' implicit meaning of rules, e.g. [https://wiki.archlinux.org/index.php?title=Help:Style&diff=178056&oldid=178055] ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:16, 12 January 2014 (UTC)<br />
<br />
:I have a general question: what are the rules for using mdash ("&mdash;") vs. ndash ("&ndash;") in English literature? Is there supposed to be a space around them or not?<br />
:(I did not intend to challenge your work, I'm just curious - the rule is very likely to be different from those used in Czech...)<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:57, 11 February 2014 (UTC)<br />
<br />
::There is not supposed to be a ''full'' space around the em dash ("&mdash;") or the en dash ("&ndash;"). Ideally, the [https://en.wikipedia.org/wiki/Space_(punctuation)#Hair_spaces_around_dashes em and en dashes will be surrounded with a hair space], which is just wide enough to put a one pixel space between the dash and the adjacent characters, which makes it easier to read because the dash doesn't look like it's part of an adjacent character. I did not put hair spaces in my edits because I generally find it tedious to do.<br />
::As for when you should use the em dash vs. the en dash... the em dash is used for large pauses in speech or for side notes&#8202;&mdash;&#8202;notice the hair spaces around these em dashes&#8202;&mdash;&#8202;and the en dash is used for numeric ranges (e.g. 47&#8202;&ndash;&#8202;83).<br />
::The hyphen looks similar to the en dash (&nbsp;- &ndash;&nbsp;&nbsp;&larr; hyphen on the left, en dash on the right), but the hyphen is only supposed to be used between certain compound adjectives and nouns.<br />
::There's also the minus sign ("&minus;"), which looks very much like an en dash (&nbsp;&minus; &ndash;&nbsp;&nbsp;&larr; minus sign on the left, en dash on the right). It should only be used in mathematical formulas or when writing negative values (e.g. 47 &minus; 83 = &minus;36)<br />
::If you haven't noticed, I'm a bit of a typography geek. haha<br />
::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:02, 13 February 2014 (UTC)<br />
<br />
:::Thanks for this nice explanation! It is a shame that the wiki markup language does not have special syntax for this punctuation, entering the HTML codes is ''really'' PITA. There are some packages for LaTeX that translate "--" into en dash and "---" into em dash. But typographically, TeX is on completely different level than wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:08, 13 February 2014 (UTC)<br />
<br />
::::We could possibly add MediaWiki templates for the em dash and en dash. Adding a template for the minus sign seems like it might be overkill. For example, <nowiki>{{emdash}}</nowiki> or <nowiki>{{em dash}}</nowiki> would output {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots, of course)<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 23:59, 18 February 2014 (UTC)<br />
<br />
:::::I say let's keep it simple, who would use those templates in practice? They would also go against our decision to e.g. use typewriter quotes instead of typographic, see [[Help:Style/Formatting_and_Punctuation#Quote_marks]]. As Lahwaacz mentioned, a wiki is not TeX, it's designed to keep source and rendered text similar, and punctuation templates would reduce readability of source text. MediaWiki takes care of translating source text characters into HTML entities when needed, and in my view we shouldn't try to bypass such feature except when really needed (see also [[Help:Template#HTML_entities]]). If you want to use some particular punctuation marks, IMHO you should enter them directly, possibly assigning them as special combinations to your keyboard map. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:00, 19 February 2014 (UTC)<br />
<br />
::::::Regarding source text readability, why not just input the unicode character itself — like this? (Notice that it works also for the hair spaces, though they are not very "hairy" in the source...) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:01, 19 February 2014 (UTC)<br />
<br />
::::::I would use those templates. :)<br />
::::::I agree that <nowiki>{{em dash}}</nowiki> would be less readable than a directly-entered "—" character; however, <nowiki>{{em dash}}</nowiki> is a ''lot'' more readable than {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots), which is why I support the idea. I feel that directly-entered em dashes with the surrounding hair spaces (using the Unicode characters directly) is less maintainable than <nowiki>{{em dash}}</nowiki> because subsequent edits may remove one or both of the hair spaces without editors realizing that they did so.<br />
::::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 01:14, 20 February 2014 (UTC)<br />
<br />
:::::::Ok, I admit that to me all this seems overly complicated as in not Simple, however, as [[Help:Style/Formatting_and_Punctuation#General_rules]] says, "for cases not covered in this guide, [[Wikipedia:Wikipedia:Manual of Style]] is the authority reference", and to me it seems very sensible to stick with that rule instead of attempting to create our own punctuation guides. In particular, [[Wikipedia:Wikipedia:Manual_of_Style#Punctuating_a_sentence_.28em_or_en_dashes.29]] says "do not use spaced em dashes", while they do have a <nowiki>{{spaced ndash}}</nowiki> template, so IMO that's what we should follow. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 20 February 2014 (UTC)<br />
<br />
::::::::If we decide for the templates way, which subset of the [[Wikipedia:Category:Wikipedia_formatting_and_function_templates|Wikipedia formatting and function templates]] should be used on ArchWiki?<br />
::::::::I don't like the templates either, this had better be solved upstream (either directly in the parser core or via an extenasion. The only mention of upstream dealing with this I found is [https://meta.wikimedia.org/wiki/MediaWiki_feature_request_and_bug_report_discussion/Archive#.22Incorrect.22_quotes this] rather old discussion, so it's probably going nowhere. (Extending the parser should not be that hard, a couple of regular expressions should do it for the dashes -- I'm surprised that it's not done yet...)<br />
::::::::Suggestions so far: 1) use HTML entities (such as {{ic|&amp;mdash;}}), 2) use templates (such as {{ic|<nowiki>{{em dash}}</nowiki>}}), 3) use the Unicode characters directly, 4) use some extension (none found yet), 5) drop the typography rules completely (use plain spaced hyphen "{{ic| - }}" or commas) -- this could be called "wait for upstream to implement the necessary change" :P<br />
::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:43, 20 February 2014 (UTC)<br />
<br />
:::::::::Well, as I've said I'm for 3), with the possible advice of setting key combinations for the most frequent cases (e.g. {{ic|AltGr}} + {{ic|-}}<sup>I'm aware of [[#Problem_with_keyboard_keys_style|1]]</sup> for the em dash). Just out of curiosity, _personally_ I tend to use ~5) because in my native language all the cases where English requires dashes are covered by commas or parentheses, so I'll be seen rarely, if ever, using dashes in my contributions.<br />
:::::::::Even if there was an extension to parse "--" and "---", we'd still find resistance for having it installed in our wiki... Maybe upstream they're just waiting for your patch! ;)<br />
:::::::::About Wikipedia's "formatting and function" templates, for sure we're discarding the "function" ones, and about the others I'd say let's create them one at a time whenever one is needed, but only if method 3) and method 1), in that order, would require too much typing effort for that case.<br />
:::::::::For completeness' sake, there's also a suggestion 6) to use a (theoretical) external editor that turns "--" and "---" into proper dashes before sending the text to the server, and does the opposite when retrieving a page for editing.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:38, 21 February 2014 (UTC)<br />
<br />
:::::::::A little note, the Colemak layout already comes with en dash and em dash respectively preset to {{ic|AltGr+-}} and {{ic|AltGr+Shift+-}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 10 June 2014 (UTC)<br />
<br />
== References ==<br />
<br />
=== Rule suggestion: reference links ===<br />
<br />
First of all, sorry if there is already some similar rule about this, I don't know (yet) what I've forgotten since last year :/<br />
<br />
The suggestion:<br />
:"When adding troubleshooting sections to new problems, always add reference links into the article, whenever such links are available."<br />
<br />
(There is (at least) one implied meaning: "...and not just in the edit summary" :) )<br />
<br />
These links will be mostly links to our [https://bugs.archlinux.org/ bug tracker] or the [https://bbs.archlinux.org/ forums]. The rule should probably include some examples.<br />
<br />
The reason behind this is quite obvious: the users (and maintainers) will easily know if the problem is still valid or already fixed.<br />
<br />
Finally, some reference links for completeness: [https://wiki.archlinux.org/index.php?title=Chromium&diff=296005&oldid=295185], [https://wiki.archlinux.org/index.php?title=MPlayer&diff=296894&oldid=296809]<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:48, 11 February 2014 (UTC)<br />
<br />
:The style guide should be currently freely editable, even though discussing any changes beforehand is a ''must'' (so thank you for doing it). You can go ahead and add a few examples, with the only recommendation to be as synthetic as possible, in accordance with the rest of the guide. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:09, 12 February 2014 (UTC)<br />
<br />
=== Citations and reasoning ===<br />
<br />
Currently we have the following clauses on referencing content:<br />
* [[Help:Style#Language register]]: Remember not only to answer how, but also why. Explanatory information always goes further toward imparting knowledge than does instruction alone.<br />
* [[Help:Style#"Known issues" sections]]: If a bug report exists for the known issue, it is very desirable that you provide a link to it; otherwise, if it does not exist, you should report it yourself, thus increasing the chances that the bug will be fixed.<br />
* [[Help:Style#"Troubleshooting" sections]]: You can also report temporary workarounds for known bugs, but in this case, it is very desirable that you provide a link to the bug report. In case it has not been reported yet, you should report it yourself, thus increasing the chances that the bug will be properly fixed. <br />
* [[Help:Style#Hypertext metaphor]]: If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information.<br />
With an ever increasing number of edits, as well as the [[ArchWiki_talk:Maintenance_Team#Reorganization|suggested deprecation]] of ArchWiki:Reports, I think it is time to revisit and generalize this topic. I see following issues with the present set of rules:<br />
* It assumes editors already know how to properly create and explain content. While linking to bug reports indeed qualifies as a necessity (further motivated in [[Help:Style#"Troubleshooting"]]) editors should understand to not blindly copy information contained within.<br />
* The presence of an explanation is alone not enough, it should also provide a clear relation between ''cause'' and ''symptom'' of the issue at hand.<br />
* The reference to upstream documentation should be more explicit; for example, only ''linking'' to it for "general information" does not imply the understanding needed to write Arch-specific adaptations.<br />
Considering the scope of this rule I would consider a separate section; we can draft it below. Related discussion: [[ArchWiki_talk:Administrators#Cite_extension]]<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:04, 7 June 2015 (UTC)<br />
<br />
:So, to put it in other words, is your proposal to aggregate all the bits from the 4 linked sections above into a unified section (I guess "Citations and reasoning" would also be the title you have in mind) and expand it with your last 3 points? I do support elaborating on this very important style issue, but wouldn't the new section overlap too much with [[Help:Style#Hypertext metaphor]]? Maybe we could more simply expand that, or split its items into subsections? Also I think that it still makes sense to keep reminding to link to bug reports directly in [[Help:Style#"Known issues" sections]] and [[Help:Style#"Troubleshooting" sections]], so perhaps those sections should display a link to the new centralized guidelines.<br />
:If I haven't interpreted correctly what you had in mind, I'll wait for your initial draft below to understand better.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:03, 8 June 2015 (UTC)<br />
<br />
::<s>For Troubleshooting, I propose to simply expand [[Help:Style#Hypertext metaphor]] with a paragraph on involving upstream, or invonvovled Arch projects. We've been encouraging this for some time, and it seems to works well enough. See below.</s> -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:26, 5 November 2015 (UTC)<br />
<br />
::It looks like I forgot what was written above ... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:30, 5 November 2015 (UTC)<br />
<br />
=== Positioning of numbered external links ===<br />
<br />
See [[Help talk:Style/Formatting and punctuation#Positioning of numbered external links]].<br />
<br />
== Slashes in titles ==<br />
<br />
=== Localized subpages ===<br />
<br />
''[Moved to [[Help talk:I18n#Localized subpages]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:23, 21 August 2019 (UTC)]''<br />
<br />
=== Preferred subpage method ===<br />
<br />
Options:<br />
<br />
* Page/subpage (examples: [[Perl Background Rotation/Tips]], [[List of applications/Utilities]])<br />
* Page - subpage (ex: [[Btrfs - Tips and tricks]]<br />
* Page subpage (ex: [[GNOME tips]], [[pacman tips]])<br />
* No subpages (using sections instead)<br />
<br />
See also: [[#Slashes_in_titles]] --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:16, 2 July 2014 (UTC)<br />
<br />
:I think, current method (number one) is good. The third one is bad (for example, it's very bad for ''List of applications Utilities''). You can add another method with colon symbol: ''Page:subpage''. But I'm ok with the first one -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:56, 4 July 2014 (UTC)<br />
<br />
::As [[mw:Help:Subpages|subpages]] are a feature of MediaWiki, the ''only'' way to have a full subpage experience is the first option. Unfortunately, it is currently disabled in the ''Main:'' namespace on Arch wiki (see [[#Slashes in titles]]). Until it is enabled, all options have equal weight, but using anything different than slashes does not make sense if we want to eventually switch to them. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:20, 4 July 2014 (UTC)<br />
<br />
:::As Lahwaacz says, using the slash form is the way to go for forward compatibility, do we want to write a rule and already start changing the existing non-compliant titles (e.g. [[pacman tips]])? The problem is that without the little navigation links under the title, it's not immediate to understand the meaning of the slash, especially for short titles, which at the moment look neater with a simple space. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:59, 5 July 2014 (UTC)<br />
<br />
::::My vote goes for option #4 (using sections like Wikipedia):<br />
::::# Doesn't to pollute the "Related articles" column with number_of_subpages<sup>2</sup> lines (or equivalent) with added complexity of maintaining all that<br />
::::# Doesn't pollute the category pages<br />
::::# It's easier to find information (i.e. {{ic|Ctrl+f}} or {{ic|/}} or by looking at TOC)<br />
::::# No confusion caused by non-existent separator character<br />
::::# Is just simple. Remember KISS? :)<br />
::::[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:08, 8 July 2014 (UTC)<br />
<br />
:::::OK, let's compare us to Wikipedia (see [[wikipedia:Wikipedia:Subpages]] for reference). Basically, it forbids using subpages in the ''Main:'' namespace. The history section states, that subpages were once used to create hierarchies of articles, but then it was superseded by categories and disambiguations. On Arch wiki, the hierarchy of categories was designed as a ''tree'' (although in practice with some "converging branches", see [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=324150#Category_pages_-_tree_or_otherwise.3F #Category pages - tree or otherwise?]) and we don't use disambiguations at all. Unlike Wikipedia, so far this system works quite well on Arch wiki, which I think is mainly due to the type of content, amount of content and greater devotion and attention to detail of the [[ArchWiki:Maintenance Team|Maintenance Team]] :)<br />
:::::Sometimes an article is too long to be kept on just one page, and the easiest solution is to split some ''section'' into a separate article, which will effectively create a ''subpage''. I don't really see how this could be avoided without completely rewriting it, disambiguations or categories won't help here.<br />
:::::But I could agree that the usage of subpages should be regulated, for example [[PulseAudio/Troubleshooting]] would be good, while [[Kernels/Compilation/Traditional]] would be wrong (see the Wikipedia case). I don't know yet about [[Color Bash Prompt]] and something like [[Bash/Color prompt]].<br />
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:00, 9 July 2014 (UTC)<br />
<br />
::::::Well, solution #4 would be ideal, but in practice I think we can't really help splitting articles, both for length issues and because it's hard to understand when to stop merging articles back to their "parents". Take for example [[dm-crypt]]: it has several quite long subpages, would an article that merges all of them be clearer to read? I wouldn't see it as an improvement. And then why not merge [[dm-crypt]] and the others back to [[Disk encryption]]?<br />
::::::A subpage system is much more manageable, especially from the point of view of the maintainers, rather than the readers, so we just have to stick with it and make it as efficient and organized as possible.<br />
::::::@Lahwaacz How would you rename [[Kernels/Compilation/Traditional]]? [[Kernels/Compilation]] is the only child of [[Kernels]] (and currently only a redirect), so probably all those [https://wiki.archlinux.org/index.php?title=Special%3APrefixIndex&prefix=Kernels%2F&namespace=0 subpages] could be moved to [[Kernels/Traditional compilation]] and so on. Maybe we could limit the depth of subpages to just 1 in general?<br />
::::::About [[Color Bash Prompt]], I think its natural subpage version would be more [[Bash/Prompt color]], or, considering the actual content of the article, [[Bash/Prompt customization]] (I think we're using the AE spelling everywhere, but that's something else that's not regulated yet), [[Bash/Prompt style]] or similar.<br />
::::::-- 09:57, 10 July 2014 (UTC)<br />
<br />
:::::::Yes, [[Kernels/Traditional compilation]] looks good. About [[Color Bash Prompt]], I think that "color" is either a verb (as in "colorize") or an adjective, so I used it the same. But your alternatives are better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:21, 10 July 2014 (UTC)<br />
<br />
::::::::Thanks, what about limiting the depth of subpages to 1? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:13, 12 July 2014 (UTC)<br />
<br />
:::::::::I wouldn't mind more levels, provided that the first/previous level is wide enough. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:49, 12 July 2014 (UTC)<br />
<br />
== Lists, colons, indentation ==<br />
<br />
As a continuation of [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=316593#Block_quotations Block quotations], let's clarify our position to multi-line blocks inside lists and indentation (definition lists without definition terms). I have slightly mentioned this in the previous discussion, and I'd like to finish it here.<br />
<br />
The markup lists are designed to be simple, and apparently are unsuitable for more complex lists, e.g. with multi-line blocks inside. [[wikipedia:Wikipedia:Manual_of_Style/Lists#Bulleted_and_numbered_lists|Wikipedia says]]: "Do not use lists if a passage is read easily as plain paragraphs." I think that most of the "incorrectness" on Arch wiki comes from disobeying this quote. We should probably recommend using the lists only in simple cases, one or two paragraphs in each item at most (use &lt;br> tags to separate them).<br />
<br />
Other common case, unfortunately falling into the non-simple category regarding markup, is that a [[template:note|note]] or [[template:tip|tip]] is presented inside a list. The "common" syntax has been<br />
{{bc|<nowiki><br />
* some text<br />
: {{Note|text to note}}<br />
</nowiki>}}<br />
but I've recently seen a number of edits changing it to<br />
{{bc|<nowiki>* some text {{Note|text to note}}</nowiki>}}<br />
which is something I don't like, because even though the latter renders correct HTML, it makes the wikitext unreadable. As much as we don't like it, definition lists without definition terms are a ''feature'', and the [[mw:Help:Lists|MediaWiki's manual]] is full of such tricks. To achieve a fully correct HTML output only with markup syntax, we would need to fix the parser/renderer anyway, so I think we should focus more on wikitext readability.<br />
<br />
The only way to achieve correct HTML, is to use HTML tags in wikitext, which brings me to the next problem: [https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=321689]. The edit clearly breaks the (future) rule "Do not use lists if a passage is read easily as plain paragraphs.", so the problem is reduced to usage of manual numbering - is it acceptable or do we tolerate HTML tags in such cases?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:11, 29 June 2014 (UTC)<br />
<br />
:I agree, look at [https://wiki.archlinux.org/index.php?title=Compiz_%28Espa%C3%B1ol%29&oldid=273960 this page broken by a "Translateme" template inside a list]. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 08:30, 29 June 2014 (UTC)<br />
<br />
::I've used the {{ic|<nowiki>* some text {{Note|text to note}}</nowiki>}} trick several times myself, but after reading Lahwaacz's reasoning I won't anymore <small><small>(when I'll remember)</small></small>, as I agree completely: we should aim for the ''cleanest'' source text that results in the ''wanted'' appearance of the page. If the generated HTML is not correct it's indeed a problem of MediaWiki, we shouldn't try to work around it.<br />
::Yes, we should encourage preferring paragraphs or even subsections to lists with long/complex items. About ordered lists, manual numbering looks quite ugly to me, and I feel the same about mixing HTML and wiki markup: I think most (hopefully all) of the cases where it would be needed are better solved in some other way. For example in the QEMU case reported above, the items of that list don't need to be numbered, bullets or subsections should be used. Another notable example is [[Arch_packaging_standards#Submitting_packages_to_the_AUR]], where bullet points would be more appropriate.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:49, 30 June 2014 (UTC)<br />
<br />
:Maybe we can create a template for items? I mean something like this:<br />
:{{bc|<nowiki>* First item<br />
* Second item<br />
* {{Template_name|<br />
Third item<br />
<br />
{{Note|bla-bla}}<br />
<br />
Bla-bla-bla<br />
}}<br />
*Fourth item<br />
</nowiki>}}<br />
:And there will be a good readability of wikitext as well as correct indentations<br />
:-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:47, 4 July 2014 (UTC)<br />
<br />
::This still seems too complicated to me. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:15, 5 July 2014 (UTC)<br />
<br />
::I don't think such template is possible, the blank lines would still break the list (test it for [[Template:bc]] without &lt;nowiki> tags). All the templates for lists on Wikipedia work the other way, template arguments are turned into list items. See for example [[wikipedia:Template:Ordered list]], but it relies on [[mw:Extension:Scribunto|Lua scripting]], which is not available on Arch wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:42, 5 July 2014 (UTC)<br />
<br />
== See also links ==<br />
<br />
This is a low priority discussion, more of a reminder, however I'd like to recommend a unified style for external links in See also sections, because at the moment the various articles are inconsistent about that. These are some options:<br />
<br />
* [https://www.archlinux.org/ Arch Linux home page]<br />
* Arch Linux home page: https://www.archlinux.org/<br />
* Arch Linux home page — https://www.archlinux.org/<br />
* https://www.archlinux.org/ — Arch Linux home page<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:36, 1 July 2014 (UTC)<br />
<br />
:I vote for the first style. It's compact and IIRC already more popular than the other styles. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:00, 1 July 2014 (UTC)<br />
<br />
::Agreed with axper, +1 to the first style. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:28, 1 July 2014 (UTC)<br />
<br />
:::I like the first style too. Also, I think this is how the Wikipedia does it. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:35, 1 July 2014 (UTC)<br />
<br />
::::I'd prefer the first style too, but I forgot that links in See also section can be accompanied by descriptions, these are some examples of how the style can vary: [[Core utilities#See also]], [[Secure Shell#See also]], [[Systemd#See also]], [[KDE#See also]] (funny), [[Xfce#See also]], [[List of applications#See also]]. I haven't made up my mind yet. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:48, 5 July 2014 (UTC)<br />
<br />
::::Meahwhile I've run into a non-standard section in [[Cursor Themes]] and I've changed it [https://wiki.archlinux.org/index.php?title=Cursor_Themes&diff=323541&oldid=323304 like this]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:01, 6 July 2014 (UTC)<br />
<br />
:::::+1 for the first style. Yet the examples show how useful a description can be, I vote for making it optional. Having an optional description behind the link looks much neater as well imo, rather than trying to use the link title to transport it in those cases. <br />
:::::Focussing on the links in [[Systemd#See also]]: some are indeed a little dated (already), but it would be a pity to loose them. I was wondering for a moment whether it would make sense to foster grouping them, e.g. <br />
::::::* systemd tips and tricks: <br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions systemd FAQ]<br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks systemd tips and tricks]<br />
::::::** [http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]<br />
::::::* systemd project information: <br />
::::::** [http://0pointer.de/blog/projects/systemd.html Lennart's blog story] - on the motivation to create systemd <br />
::::::** ...<br />
::::::** [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::But then again there are few cases with that many links and the description can be useful/enough to transport that information too. Some sort of grouping happens automatically by editors keeping relevant links together and ordering most relevant (e.g. project home pages) first. <br />
:::::In my view the whole could be clarified by just appending some examples to [[Help:Style#.22See_also.22_sections]] ala: <br />
::::::Examples: <br />
::::::* [https://www.archlinux.org/ Arch Linux home page]<br />
::::::* [http://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml man Xcursor] — for more information about cursors in X (supported directories, formats, compatibility, etc.).<br />
::::::* [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:28, 11 August 2014 (UTC)<br />
<br />
== OK to put category pages in related articles list? ==<br />
<br />
Recently I made some edits which replaced links to multiple articles with a single link to a category page. That category page contains all those articles.<br />
* [[:Category:Hypervisors]]<br />
* [[:Category:Network managers]]<br />
<br />
Are people OK with this? If so, maybe edit [[Help:Style#Related_articles_box]] here to instead say:<br />
<br />
{{META Box||<br />
* Provides a simple list of related internal pages.<br />
* Optionally included right below categories (or interlanguage links, or Article status templates, if present).<br />
* It can only be made of [[Template:Related articles start]], [[Template:Related]] and [[Template:Related articles end]]. See also the guidelines in those pages.<br />
* Non-English pages can make use of [[Template:Related2]] for translating the anchor text.<br />
* Use the [[#"See also" sections|"See also" section]] for a more complete and detailed list that also includes link descriptions and interwiki or external links.<br />
}}<br />
<br />
(change the word "article" to "page")<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:33, 10 July 2014 (UTC)<br />
<br />
:My first thought when reading this was "when the article is not included in the given category and it is still relevant, it should be included, otherwise not". On second thought, if the category is relevant enough, the article can be simple put into that category. The big problem is that related articles are at the top and related categories at the bottom.<br />
:We can either 1) leave pages at the top and categories at the bottom, 2) include every category into the 'Related articles' box at the top, 3) move the list of categories to the top (how?), 4) move the 'Related articles' box to the bottom (merge into 'See also' again).<br />
:Yep, so far I don't like either one of them for some reason or another...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:25, 10 July 2014 (UTC)<br />
<br />
::About axper's proposed amendment, I agree, if a group of articles don't have a generic overview (e.g. unlike [[window managers]]), then linking to the category that groups them can be useful, if the edited article is not part of such category. Of course if the article itself is part of the category, there's the problem of duplicating the category link in the source text. This reminds me of an old idea of mine that I explained in [https://wiki.archlinux.org/index.php?title=Help_talk:Style/Article_summary_templates&oldid=287617#A_crazy_idea_.28about_Summary_templates.2C_Overview_templates_and_categories.29]: translated to the "modern" wiki, it could mean replacing the normal categorization system with a [[Template:Category]] to be added to the Related articles box, when present, so that the article gets categorized under some categories, but their links are also shown somehow in the floated box. For example:<br />
{{hc|Current system|<nowiki><br />
[[Category:Foo]]<br />
[[Category:Bar]]<br />
{{Related articles start}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
{{hc|New system|<nowiki><br />
{{Related articles start}}<br />
{{Category|Foo}}<br />
{{Category|Bar}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:33, 12 July 2014 (UTC)<br />
<br />
:::The problem is that it involves more writing when there are no related articles (it is necessary to add <nowiki>{{Related articles start}}</nowiki> and <nowiki>{{Related articles end}}</nowiki> around the cats). Or would we use the current system for such pages? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 12 July 2014 (UTC)<br />
<br />
::::I was just brainstorming, I'm not sure, maybe we could start using the RA box on every article? [[Wiki Monkey]] should have all the libraries needed to automate the migration, both for articles with an RA box and for those without, so the "extra writing" disadvantage wouldn't really apply. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:24, 13 July 2014 (UTC)<br />
<br />
== Convention on added/removed text in Hc Templates ==<br />
<br />
I just [https://wiki.archlinux.org/index.php?title=Nautilus&diff=prev&oldid=324433 used] the following way to clarify removed/added text in [[Nautilus#Use delete key to move to trash in Nautilus 3.6 and above]]:<br />
<br />
{{hc|~/.config/nautilus/accels|<br />
''<s>; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")</s>''<br />
(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")<br />
}}<br />
<br />
Is there already a policy on this? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 23:29, 10 July 2014 (UTC)<br />
<br />
:Nope, there's no policy on that (yet?). Your version is certainly an improvement, compared to the previous {{ic|-+}} system, although in my opinion there's no need to add italic to the stricken line (keep it simple). What I think I've seen around more often, though, is a more verbose:<br />
<br />
::In {{ic|~/.config/nautilus/accels}}, replace:<br />
::{{bc|; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")}}<br />
::with:<br />
::{{bc|(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")}}<br />
<br />
:Your version has the advantage of using [[Template:hc]], thus making it ''visually'' clearer that those lines are two versions of the same line, and belong to the same file. The "verbose" version has the advantage of giving clearer ''written'' instructions about what has to be done.<br />
:Replacing lines doesn't seem to be very frequent in articles, maybe standardizing this would be too much. If we decided to use the "stricken" version, it would probably be worth adding a note in [[Help:Reading#Append, create, edit and source]].<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:30, 11 July 2014 (UTC)<br />
<br />
I disagree with both of the previously suggested styles as neither explains ''what'' is changed and ''why''. They're both barely better than telling someone to paste some sed command in their terminal as they rely on the ''current'' content of the file (which can change with updates) and they don't immediately convey what needs to be done. My preferred approach depends a lot on the context, but for this case I would do something like:<br />
<br />
Create a shortcut to the action {{ic|<Actions>/DirViewActions/Trash}} with the key {{ic|Delete}} e.g.<br />
{{hc|~/.config/nautilus/accels|<br />
...<br />
(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")<br />
...}}<br />
<br />
This is more broadly informative. If the keyboard shortcut format changes in some way or if the commented line is removed, it will still be clear what needs to be done. --[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 17:28, 8 October 2014 (UTC)<br />
<br />
== Questionable edits ==<br />
<br />
There are several kinds of questionable edits made almost regularly to the wiki. They are '''not''' breaking any rules (yet?), I just find them useless, counter-productive, or even annoying. I'd like to discuss them to see how others feel. Of course feel free to add a section of your own. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
=== Underscores vs. slashes in kernel module names ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=USB_storage_devices&diff=next&oldid=328933] vs. [https://wiki.archlinux.org/index.php?title=Advanced_Linux_Sound_Architecture&diff=311976&oldid=310951]<br />
<br />
From {{ic|modprobe(8)}}: ''"there is no difference between _ and - in module names (automatic underscore conversion is performed)"''. Not only the naming is inconsistent across the wiki, this could lead to edit wars.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Let's just pick one style and go with it. I vote for undescores, since that's how {{ic|lsmod}} prints them, consistency would be nice.<br />
:I wouldn't consider these 2 edits questionable, rather it's lack of [[Help:Style]] rules about this particular subject.<br />
:[[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:04, 10 August 2014 (UTC)<br />
<br />
::+1 for regulating this with underscores as per axper's lsmod argument. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
=== Alphabetical order ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=Xorg&diff=prev&oldid=327850]<br />
<br />
Unless in lists (such as [[List of applications]]), alphabetical sorting of sections or other items is useless, I'd even say wrong. Alphabetical sorting is good for finding things, but we have full-text searching nowadays. Even ''chronological'' sorting (assuming that new sections are added to the bottom) is more useful for ''Troubleshooting'' sections.<br />
<br />
Also, have you ever read a book with chapters sorted alphabetically?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think as long as the sorted sections are ''equivalent'' (as in, alphabetical order does not break logical order), you could probably make an argument for both. Should a rule for chronological sorting be found useful, however, I wouldn't object to it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:41, 9 August 2014 (UTC)<br />
<br />
::Yes, I'd expect a section about a ''new'' bug I am looking a solution for to be at the end of the article. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:20, 10 August 2014 (UTC)<br />
<br />
:::First, the example edit should have been split (i.e. one section moved at a time).<br />
:::About the issue, I don't think that alphabetical order can make sense in Troubleshooting or Tips and tricks sections, since the first word of the headings is often incomparable (can be an article, a noun, etc.); chronological order would be better, for example a rule could recommend adding sections at the bottom (or top) of such section groups, unless some similar ones already exist, and in that case I guess keeping similar sections next to each other would be preferable.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::::+1, Lahwaacz is right. And one example for keeping similar sections next to each other: [[GNOME#Extensions]] -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 12:21, 20 August 2014 (UTC)<br />
<br />
=== Concision ===<br />
<br />
(without example)<br />
<br />
Several times recently I was ''amazed'' as to how can be a concise article made even more concise. I think that we need more ''precision over concision''. I think that the ''good'' wiki pages are usually verbose, as the topic is usually too complex to be described concisely. As tempting as it may be, having an expert making it more concise is not helpful for the majority of others.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think there's a difference between concision in ''style'' and concision in ''content''. Former is a matter of correct writing (convey information that helps understanding, not make it difficult); see [https://wiki.archlinux.org/index.php?title=Skype&diff=prev&oldid=328283] for a simple example. Latter should be avoided, and flagged (for example [https://wiki.archlinux.org/index.php?title=PPTP_Server&curid=9499&diff=329500&oldid=329283]) where appropriate. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:24, 9 August 2014 (UTC)<br />
<br />
::We can indeed put some recommendation like that in the guide, but this is something that the wiki staff will always have to keep an eye on, because experience is the only way to judge, case by case, what's too verbose and what's too concise. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::Thanks for this hint. I've never recognized concision as a [[wikipedia:Concision|term]] and always associated it only with removing of content, either large parts or nuances that might have been intended by the previous editor. Although the [[Help:Style#Language register|language]] should be concise, let's not take it too far. And especially watch out for the nuances. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:08, 10 August 2014 (UTC)<br />
<br />
=== "as of version X.XX..." ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=Core_utilities&diff=424410&oldid=424178]<br />
<br />
For some reason users really want to put in when a feature was added to a program. I find this useless because an Arch system always uses the latest version. I think these comments are more appropriate for the talk page or even the user forums. For me the wiki shouldn't be a changelog. I do think it could be appropriate to use when its clear there are issues that are buggy and in progress, but once they are resolved, the note should be removed. [[User:Rdeckard|Rdeckard]] ([[User talk:Rdeckard|talk]]) 20:22, 6 March 2016 (UTC)<br />
<br />
:I agree that it is useless for features. But I think it is very important for bugs and perhaps even missing features.[https://wiki.archlinux.org/index.php?title=SSH_keys&diff=next&oldid=422817] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:46, 6 March 2016 (UTC)<br />
<br />
::+1. For [https://wiki.archlinux.org/index.php?title=SSH_keys&diff=next&oldid=422817] see also [https://wiki.archlinux.org/index.php/Talk:SSH_keys#PuTTY_elliptic_curve_support]. Another missing features example is [https://wiki.archlinux.org/index.php?title=Solid_State_Drives/NVMe&curid=21993&diff=424474&oldid=417803]. Such is difficult to track for readers who may have encountered the issue in the past and, in this case, perhaps used a different boot loader just because of it. Perhaps one could say "as of notes" are less useful to keep for missing features in the "Installation" sections, but the further down in the article they are (e.g. in a "troubleshooting" section) the more useful they are for awareness of updates. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:48, 7 March 2016 (UTC)<br />
<br />
:::Yes, to generalize, I'd say that "as of" notes are indeed useful next to information that is ''expected'' (or maybe ''reasonably wished/feared'') ''to change'' in the future. Certainly, added features don't fall in that category, so I agree with the [https://wiki.archlinux.org/index.php?title=Core_utilities&diff=424410&oldid=424178 Core utilities], [https://wiki.archlinux.org/index.php?title=GDM&diff=prev&oldid=424423 GDM] and [https://wiki.archlinux.org/index.php?title=Makepkg&diff=prev&oldid=424425 makepkg] edits, but I would undo the [https://wiki.archlinux.org/index.php?title=Python&diff=prev&oldid=424426 Python] edit, and, as noted by Indigo, check the [https://wiki.archlinux.org/index.php?title=SSH_keys&diff=next&oldid=422817 SSH keys] edit against [[Talk:SSH_keys#PuTTY_elliptic_curve_support]]. Since we are in the talk page of the style guide, is there a proposal for the addition of a new rule to discuss? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:53, 8 March 2016 (UTC)<br />
<br />
:::: I think a possible style rule could be that adding edits about when changes to a program occurred is mostly appropriate when it's about a bug, or about a product in heavy development that's expected to change soon. Just listing off when features were added to a stable program adds noise and should be avoided. [[User:Rdeckard|Rdeckard]] ([[User talk:Rdeckard|talk]]) 02:24, 19 March 2016 (UTC)<br />
<br />
::::: (Welcome to the team, Rdeckard!). Yes, though, take the putty example: it's long a missing feature, putty is not really what one would call heavy development. When the feature finally hits stable, an "as of" might help (an ssh client is an application where I would expect a lot users prefer to use stable and wait). Maybe it is easier to suggest a time-period, i.e. "as of notices" older than (half) a year after a bug or missing feature (which has been tagged as such in the content) has been fixed can safely be removed because of the rolling repos Arch uses. <br />
::::: As for the place to put it: we actually have [[Help:Style#.22Known issues.22 sections]] in the guide, but it is rarely used - which is understandable in my view, because mentioning a bug where the related configuration or features are described makes sense. Question is whether we need this style section at all (then an "as of" addition could be added to it), or it should be removed entirely and integrated into the more commonly used [[Help:Style#.22Troubleshooting.22_sections]]. (+1)<br />
::::: --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:26, 19 March 2016 (UTC)<br />
<br />
:Restarting this discussion because I just did a bunch of "as of" edits. It is a tricky issue because there definitely isn't a simple policy that always applies. That being said I think that most "as of"s should probably go. Here are the main use cases that I've observed:<br />
:# noting when a feature was added/removed<br />
:# noting when a default option was changed<br />
:# noting when a bug was introduced/fixed<br />
:# noting when the editor last verified the information (workaround was effective, desired feature was missing, etc.)<br />
:Number 4 is easy: "as of" is unnecessary. First of all it is redundant since the article history shows when the information was added (and thus verified). Secondly it adds very little value to the reader of the article. If I'm having a problem and a troubleshooting section has a potential solution it doesn't matter if it was working "as of" 100 years ago, I'm going to give it a shot (and then update the article if it no longer works). Lastly it encourages useless edits. If I see an old "as of" and check that it is still the case, does it really add value to the article if I just update the date to show that it still works? Where do we draw the line for that? Should we go around adding "as of" to every single thing that we verify as working? "As of March 3, 2017 sudo can be installed via {{pkg|sudo}}."<br />
:Number 3 is also easy: "as of" is unnecessary. In almost every case it is more useful to simply link to the bug report (ours or upstream). The obvious advantage being that upstream bug reports often include all the information the reader may want: when it was reported, what versions it affects, potential workarounds/solutions, if/when the bug was fixed, etc. Adding "as of" in this case is just sparing the reader an extra click, which goes against the hypertext metaphor.<br />
:Number 2 is a little tricky. If it is the case where the option change might require user intervention (e.g. a breaking change in config) then the "as of" is needed. However in most cases I've seen it is still not used well in the article. You'll see something like "As of version X the default is blah ...''much later in the article''... if you are upgrading from an older version, you may need to...". I think the "as of" is misplaced here: users who installed after the change likely don't care about the new default since they don't have to worry about breakage. In this case the "as of" should be placed in the later section dealing with the issue: "The default is blah ...''much later in the article''... if you are upgrading from version X, you may need to...". If the default change requires no intervention, I see no need for the "as of": users who run the default likely don't care and users who do not use the defaults are likely unaffected.<br />
:Number 1 is also difficult. I think feature removal is slightly easier because if the removal was an intentional design decision by the developers (i.e. not a bug) then the "as of" is not needed. Arch doesn't support users who want to keep old software around, so it is sufficient for the article to simply say that the feature was removed (not when). Because it was an upstream design decision, users reading the article can safely assume that the software will no longer support that feature. For feature addition I think the same logic as number 2 applies. If the new feature might change how upgrading users use the software it should be mentioned in the relevant section.<br />
:The only rule of thumb that I think applies in all of these cases is that often an editor adds an "as of" when there is actually something more specific they are trying to communicate: "as of X the default was changed '''so if you upgrade you have to'''...", "as of X this feature was removed '''so instead you may need to install'''...". By all means keep the the more specific information, ditch the "as of" if possible.<br />
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:14, 3 March 2017 (UTC)<br />
<br />
::Very good. One comment: I think a regular case is that someone put a work-around/troubleshooting item into the wiki for a missing feature/default. Later the feature/default is added/changed. I think procedure should be to put a [[:Template:Remove]] to the workaround first, so that users who might have implemented it get info. Then purge it later. (Obviously, there may be simple cases too.) <br />
::Two questions. 1: Do you think we should put a "as of" style suggestion with good/bad examples of usage into the style guide? If yes, where? <br />
::Question 2: Look at the above [[SSH keys#ECDSA]] example. Coincidentally, the referred to putty package finally gained the feature two weeks ago. How would you handle that, taking into account implementing the feature took a couple of years. <br />
::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:47, 3 March 2017 (UTC)<br />
<br />
:::I think the "as of" there is needed, but again I think it is misused. Right now it is an example of case 4 i.e. "when I edited this article in March 2016 the feature wasn't there yet". This is redundant and not very useful. A much better "as of" would be to mention that ECDSA support has actually been in the development snapshot since November 2014! That is much more useful. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 23:19, 3 March 2017 (UTC)<br />
<br />
::::I agree, somewhat. The "feature not there" info was useful in so far, as there will be users who configure their Arch openssh server (defaulting to ECDSA) but may latter want to connect via another platform's client (i.e. useful to avoid the pitfall with putty as a common client failing to support the server default). Of course it would have been even more useful with the development version info being merged over from the talk page, or the info moved/crosslinked from [[putty]]. But ok. My question was for the new status quo: How would you phrase it now, with the new stable version supporting ECDSA? Keep the note with an "as of putty 0.68 (Feb 2017) ECDSA is available", or simply drop it because it does not matter anymore? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 02:36, 4 March 2017 (UTC)<br />
<br />
:::::Putty is an exceptional case because there we have to deal with compatibility with other OSes (where the always up-to-date assumption does not apply). So the "as of" there is useful, again as long as it actually mentions when the feature was added.<br />
:::::Also, regarding "as of" in the style guide I think it sufficient to mention the two clear-cut cases: do not use "as of" if you are just noting the last time you personally checked something and do not use "as of" for bug reports, just link to the report itself.[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 18:37, 4 March 2017 (UTC)<br />
<br />
::::::: I've handled the Putty example with [https://wiki.archlinux.org/index.php?title=PuTTY&curid=15652&diff=469978&oldid=469692] and [https://wiki.archlinux.org/index.php?title=SSH_keys&curid=1156&diff=469983&oldid=468807] I agree it could be done the other way too. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:29, 6 March 2017 (UTC) <br />
<br />
::::::Great write up above. I'm in agreement that we should tell users not to note the date, time, or program version in their edits if they are just telling us the last time everything worked for them. I also like the idea of encouraging users to link to bug reports instead of giving specific versions. We also need to use the "Known Issues" more often in our articles. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 21:11, 4 March 2017 (UTC)<br />
<br />
::::::: To make a start with mentioning "as of", I put in [https://wiki.archlinux.org/index.php?title=Help%3AStyle&type=revision&diff=469988&oldid=469986] and [https://wiki.archlinux.org/index.php?title=Help:Style&diff=next&oldid=469988] (the latter addition may be a bit sublime). Perhaps you have an idea to make it more prominent or concise along above. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:29, 6 March 2017 (UTC)<br />
<br />
== Some style/grammar guidelines ==<br />
<br />
I have noticed that most, but not all, articles follow these guidelines. I'm somewhat surprised that they are not mentioned here (maybe I just can't find them)? Anyway:<br />
* Write in second person rather than third. For example "It is recommended that you do ''foo'' in order to enable ''bar'' on your system" is preferred over "It is recommended that users do ''foo'' in order to enable ''bar'' on their systems."<br />
* If possible, do not "recommend" anything. Arch users are expected to read and understand instructions, not follow them blindly; everything on the wiki is implicitly "recommended" and can be ignored by savvy users. If a choice is involved simply explain why users might want to make a choice. So "If you need ''baz'', do ''foo'' in order to enable ''bar'' on your system." is preferred over "It is recommended that you do ''foo'' in order to enable ''bar'' on your system". Recommendations are only needed in situations where the choice may be unclear and it is easy to choose poorly (and then a [[Template:Warning]] might be in order).<br />
* Write in an active voice. For example "''foo'' modifies ''bar''" is preferred over "''foo'' is used to modify ''bar''".<br />
[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 20:13, 4 March 2016 (UTC)<br />
<br />
:[[Help:Style#Language register]] says: "Articles should be written using formal, professional, and concise language." It is certainly possible to make the writing formal and professional enough (at least for this wiki) using second or third person, but recommending to use one over another is too strong, because the best wording usually depends on context. If the whole page is already written in second person, the next modifications usually also use second person to blend in, and vice versa.<br />
:The text should be professional, but also feel natural. For example, the [[Linux Containers]] page excessively uses "users" to refer to the reader: "Users may use other programs to achieve the same results." Simply using "you" instead of "users" might look better, but I'd write "Other programs may be used to achieve the same results."<br />
:As for recommendations, there is nothing wrong with them - they only have to stay objective, expressing personal preference is not allowed (also as per the Language register). In your examples, "It is recommended that you do ''foo'' in order to enable ''bar'' on your system" would be fine if it was followed by an explanation of ''why'' it is recommended.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:22, 4 March 2016 (UTC)<br />
<br />
::Actually [[Linux Containers]] contains a random mix of second and third person. At a glance you've got "Install the...", "Verify that...", "Users may...", "Users are..." "Disable the...". You even have weird sentences that combine them "For users already using netctl to manage an adapter, simply switch-to it" (I guess you're switching on behalf of the users?). I agree that certain situations require third person, but this is clearly a case of different authors following different writing styles, resulting in strange repeated switching of perspectives. Considering that this problem is present on ''a lot'' of articles and we both agree that each article should maintain a consistent perspective, there are a lot of edits to be done. I was just figuring that while we're doing all of these edits, why not make them all consistent across articles?<br />
::Let me try to better convey my point about recommendations. I agree that recommendations are fine as long as you explain why, but they are also usually unnecessary if you explain why. For example, [[Secure Shell]] says<br />
:::''It is also recommended to disable password logins entirely. This will greatly increase security.''<br />
::That's fine, but it reads just as well like so:<br />
:::''Disabling password logins entirely greatly increases security.''<br />
::Greatly increasing security is obviously good, so recommending it doesn't really add anything.<br />
::But still, there are certainly exceptions. I suppose that's the case with all of my suggestions: they aren't hard and fast rules, they're more like guidelines that should be kept in mind. If that's not the kind of stuff we want in the style guide, I understand.<br />
::[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 06:52, 5 March 2016 (UTC)<br />
<br />
:::In this case I have to say I generally tend to agree with Silverhammermba: IMHO adding guidelines on these issues would still help resolve possible (minor) edit wars in the future; of course they wouldn't mean that non-complying edits would be rejected, like with all the other rules, but if e.g. two users disagree about the way to phrase something, we have something to resolve the dispute.<br />
:::About the first problem, though, I tend to prefer third-person or passive-voice writing, and if "Users may use other programs to achieve the same results." doesn't sound as good as when using "You...", I do think that "Other programs could be used to achieve the same results." would sound even better. But I wouldn't generalize, since for example most of the very rules in this guide are better put with an imperative (i.e. second-person) form. For this reason I'd propose to add, in [[Help:Style#Language register]]:<br />
::::* When editing content, be consistent with the style used in the rest of the article. For example, if the reader is always addressed using the second person, this style should be adopted by the added content; the same goes if third person or passive voice are clearly dominant throughout the article.<br />
:::And about recommendations, even though I'm surely guilty of giving many in my edits, I agree that a rule like the following could belong in the style guide:<br />
::::* When offering a choice among different options (pieces of software, methods to do something, etc.) do not explicitly recommend one over the others, but objectively describe the advantages and disadvantages of each, thus helping the reader to make the best decision for his personal case.<br />
:::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:29, 6 March 2016 (UTC)<br />
<br />
::::About "be consistent with the style...", in my experience [[w:Mirroring (psychology)]] is a strong phenomenon among editors, so I'm unsure if an explicit mention is needed in [[Help:Style]].<br />
::::About "objectively describe", +1 from me. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 03:56, 6 March 2016 (UTC)<br />
<br />
:::::Recommending ''mirroring'' would avoid the mixtures such as [[Linux Containers]], but also conserve the (bad) style on other pages. Mirroring is a good fallback solution for situations when you have no idea, but I think the guidelines have to state what is right.<br />
:::::Also +1 for the second part about recommendations.<br />
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 6 March 2016 (UTC)<br />
<br />
::::::I remember writing this even when we were developing this page 5 years ago: this guide is only in theory aimed at ''teaching'' contributors what is the recommended style for the wiki; in practice, only a tiny minority of them reads any part of it, and it is indeed ''mirroring'' what accounts for the majority of the style-compliant edits (regarding any style rule, not only these ones). The real, ''practical'' aim of this guide is to solve disputes, as I said, and to give an ''official'' justification to the style-fixing edits made by the wiki staff and the other proactive users.<br />
::::::That is why explicitly defining what is good and what is wrong, whenever an issue is presented, is always pertinent here. I have [https://wiki.archlinux.org/index.php?title=Help%3AStyle&action=historysubmit&type=revision&diff=424477&oldid=423038 added] the two new clauses: perhaps that's not the most suitable section, if somebody wants to move them somewhere else, please go ahead, otherwise the next one who agrees can close the discussion :)<br />
::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:20, 7 March 2016 (UTC)<br />
<br />
== Example usage ==<br />
<br />
I recently removed a newly added example from [[Apple Keyboard]] ([https://wiki.archlinux.org/index.php?title=Apple_Keyboard&diff=470290&oldid=470270], [https://wiki.archlinux.org/index.php?title=Apple_Keyboard&diff=prev&oldid=470270], see also [[User_talk:Pypi#Apple_Keyboard]]).<br />
I generally prefer to avoid examples which I feel are covered elsewhere, since they can be prone to bit rot and linking to a page on the topic both encourages understanding and is more robust, however I can't find an "official" stand on this.<br />
Have I missed a section explaining proper usage of examples? If not, is there some other reasons for/against that kind of usage of examples? Would it be useful for the style guide to be adjusted to include some "rules of thumb" for dealing with examples?<br />
-- [[User:Pypi|Pypi]] ([[User talk:Pypi|talk]]) 21:17, 10 March 2017 (UTC)<br />
<br />
:You're right, we're not explicit about examples at the moment: I'd say currently the most related sections are [[Help:Style#Hypertext metaphor]] about content centralization, and [[Help:Style#Package management instructions]]/[[Help:Style#systemd units operations]] about examples only for those specific cases.<br />
:[[Help:Style#Hypertext metaphor]] allows (obviously) to write Arch-specific adaptations (examples?) of external generic documentation: by analogy (and coherence), this could be seen applicable to topic-specific adaptations (examples?) of instructions which are centrally (and generally) discussed in a "main" article. If we wrote a rule about examples, and perhaps we do need it, it should probably still be quite loose I think, and describe sort of a minimum level of complexity that the adaptation of generic instructions should have to be allowed in an article in addition to a link to the centralized article.<br />
:Regarding the specific reverted edit, I tend to agree with you, the example looked quite trivial, so I've tried to instead [https://wiki.archlinux.org/index.php?title=Apple_Keyboard&type=revision&diff=470393&oldid=470290 clarify] the paragraph.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:48, 11 March 2017 (UTC)<br />
<br />
== Long form of uncommon command ==<br />
<br />
We mention as a sub-point about shortening "prefer using the long form of uncommon command options instead of their single-character counterpart."<br />
<br />
Then I see sometimes: use {{ic|-p1}} (or {{ic|--parameter1}}) and {{ic|-p2}} (or {{ic|--parameter2}})... this easily become quite heavy.<br />
Should we mention that if the long form is used, the corresponding short form does not need to be indicated?<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 20:16, 9 January 2018 (UTC)<br />
<br />
:The correct form should be "use {{ic|-p1}}/{{ic|--parameter1}} and {{ic|-p2}}/{{ic|--parameter2}}...". See [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:33, 10 January 2018 (UTC)<br />
<br />
::Ok sounds good, I think both forms should be presented if it adds something, this is what [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]] probably already means with the "have to". -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 11:10, 10 January 2018 (UTC)<br />
<br />
::Shall we regroup all the comments on parameters in the same section [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]] i.e. moving the point about "prefer using the long form of uncommon command options instead of their single-character counterpart" into [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]] ? I would also add if one form is provided long for uncommon or short for common, it is better to stick to it and it is not necessary to indicate all the possible spelling of an option. -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 19:12, 10 January 2018 (UTC)<br />
<br />
:::Both forms should be presented if you explain the option itself, like in your example. Command line examples usually use short forms except for the ''uncommon options'', but nothing actually forbids the use of long forms.<br />
:::I don't think moving "prefer using the long form of uncommon command options instead of their single-character counterpart" to [[Help:Style/Formatting and punctuation]] would be correct, since it's not about formatting or punctuation. How about simply adding a link in [[Help:Style#Spelling]] to [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]]. E.g. "In the same fashion, prefer using the long form of uncommon command options instead of their single-character counterpart. See also [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]]". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:23, 11 January 2018 (UTC)<br />
::::It is a good idea it would have helped to know there was also a point about it in [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]] -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 16:07, 11 January 2018 (UTC)<br />
<br />
:::::[[Special:Diff/507313|Done]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:03, 13 January 2018 (UTC)<br />
::::::Great, thanks -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 10:05, 13 January 2018 (UTC)<br />
<br />
:::::::Thanks guys, do you think we can clarify in a few words when it's ok to represent both the short and long forms of a command option, and explicitly discourage from doing it by default? Or perhaps we should simply discourage it in general? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:37, 13 January 2018 (UTC)<br />
::::::::Yes this was my initial idea I can't imagine cases where this adds much value and this is quite heavy to read. Common we use the short form, uncommon the long form and it is not recommended to indicate the different possible variations of an option nor to switch from one form to another across the page. -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 14:50, 13 January 2018 (UTC)<br />
<br />
:::::::::I see no need to discourage presenting both forms, it's not that much harder to read. I think this should be separated by usage:<br />
:::::::::* in text use both (e.g. "... use {{ic|-v}}/{{ic|--verbose}} for ...")<br />
:::::::::* in command line use short options unless they could cause confusion (e.g. efibootmgr {{ic|-l}} and {{ic|-L}}) and be consistent in using only long or short options<br />
:::::::::-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:55, 13 January 2018 (UTC)<br />
<br />
== Transclusion ==<br />
<br />
:''[Moved from [[User talk:Lahwaacz#Transclusion]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:37, 15 April 2018 (UTC)]''<br />
<br />
[[Special:Diff/517439]] "transclusion is useless and visual duplication confusing"<br />
<br />
I guess this should be mentioned in [[Help:Style]].<br />
<br />
What about [[Special:Diff/516574]]?<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:40, 14 April 2018 (UTC)<br />
<br />
:IIRC we discussed transclusion at least during the Beginners' Guide merge, and we discarded it in general for lack of arguments in favor of it when compared with simple linking. I'm in favor of adding a style rule to forbid transclusion with the obvious exception for templates. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:37, 15 April 2018 (UTC)<br />
<br />
::This also depends on [[Talk:List of applications#Link subpages instead of transcluding them]], otherwise we would need another exception. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:19, 23 February 2020 (UTC)<br />
<br />
== Categorization of redirects ==<br />
<br />
[[User:Larivact|Larivact]] has found a good use case for categorizing redirects in [[:Category:Commands]] so I think we should adjust [[Help:Style#Redirect pages]] appropriately. My suggestion:<br />
<br />
* Redirect pages should contain only the redirect code and nothing else. The only exceptions are:<br />
** Redirect pages with descriptive titles can be categorized to help users navigate to a specific section of a long page. Examples are [[alias]], [[chown]] or other pages in [[:Category:Commands]]. Note that the category of the redirect page should not be same as the category of the target page itself.<br />
** ...<br />
<br />
There may be more exceptions though, I think that most redirects should still be uncategorized.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:54, 23 October 2018 (UTC)<br />
<br />
:> Note that the category of the redirect page should not be same as the category of the target page itself.<br />
<br />
:[[Awk]] and [[Core utilities]] are both in [[:Category:Commands]]. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 10:11, 24 October 2018 (UTC)<br />
<br />
::Practically all commands mentioned in [[Core utilities]] currently have redirects in [[:Category:Commands]] or subcategories.<br />
::I agree that multiple redirects to the same target should be allowed to appear in the same category if they have equal relevance and different meanings relative to each other (it would be arbitrary to choose one over the others).<br />
::However, if there ''is'' already an article that lists (a subset of) the items that belong in a category, what's the disadvantage of requiring to only add that article to the category and forbid adding any redirects to it?<br />
::A possible exception is if the main article is not a list of peer items that would belong in its category, but one or more redirects to some of its sections exist, and they are relevant enough to appear alongside the main title in the category.<br />
::[[w:Wikipedia:Redirect#Categorizing_redirect_pages]] and [[w:Wikipedia:Categorizing_redirects]] are easy ways to find inspiration for this style rule.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:00, 17 November 2018 (UTC)<br />
<br />
::: It may well be that these categories (those quoted directly below too) are more the exceptions to the rule themselves, not? Sticking to the [[awk]] example, [https://www.google.com/search?q=awk+site%3Awiki.archlinux.org] scores [[AWK]] here as top result, which (curiously;) has not been categorized yet. This non-categorization also makes sense to me, because semantically AWK refers to [[:Category:Programming languages]] language more than the gnu awk. Now, categorizing any of the two awk redirects into programming languages would be misleading (in my view) for the content at hand in [[:Core utilities#Essentials]].<br />
:::Of course, the categories set for the [[alias]] and [[chown]] examples above make perfect sense. Maybe change the first bullet sentence like so: <br />
::::"Redirect pages with descriptive titles can be categorized to help users navigate to a specific section of a long target page, as long as contextual coverage for the redirected term's additional category is warranted. Examples are..." <br />
:::Elaborating an example what to avoid would make it too complicated I am sure. Can be handled case by case. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:30, 17 November 2018 (UTC)<br />
<br />
::::I find your clause hard to understand. We could allow redirects only in "set categories", ie. disallow them in topic categories. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 06:27, 18 November 2018 (UTC)<br />
<br />
:::::I meant it the other way - if there is a category which represents some set and a page which lists some elements of this set, then the page does not belong into that category. For example, "Core utilities" ''is not'' a command. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:50, 18 November 2018 (UTC)<br />
<br />
::::::Thanks for clarifying, that makes way more sense. I put [[Archiving and compression]], [[Core utilities]] and [[File permissions and attributes]] back in [[:Category:Command-line]]. Now that we have cleared that up, can we add your proposed exception? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:34, 18 November 2018 (UTC)<br />
<br />
:::::::Another point: replace "should not" with "must not" in the last sentence of the bullet. <br />
:::::::Otherwise ok with me. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:16, 18 November 2018 (UTC)<br />
<br />
::::::::I'd also drop "with descriptive titles" (which titles are not descriptive?), and at the end I'd also clarify that instead multiple redirects to the same page can be put in the same category, since it doesn't feel obvious to me. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:58, 19 November 2018 (UTC)<br />
<br />
:Just mentioning that at least [[:Category:Configuration files]] is involved too, and redirects have also been added to some subcategories of [[:Category:Commands]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 16 November 2018 (UTC) (Edit: 17:00, 17 November 2018 (UTC))<br />
<br />
:I'm late to this discussion, so of course I won't question too much, but in order to understand how to best phrase the new style rule, I'd be curious to read a couple of points that show ''why'' this solution is considered better (easier to manage, simpler, etc.) than lists of links in regular articles, e.g. [[Commands]], [[Configuration files]], [[List of commands]], [[List of configuration files]]... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 16 November 2018 (UTC)<br />
<br />
::Using categories for categorization is the way MediaWiki is designed for. Category indexes are automatically generated meaning that you don't have to edit two pages when you recategorize a redirect. Link pile pages would not integrate as well with category pages, be not as compact (category indexes have a column layout), and could become unsorted. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 14:04, 16 November 2018 (UTC)<br />
<br />
:::Thanks, as I said I won't question further. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:00, 17 November 2018 (UTC)<br />
<br />
== dd block size units ==<br />
<br />
GNU Coreutils' [[dd]] supports specifying the block size in KiB, MiB, TiB, PiB, EiB, ZiB and YiB.[https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html]<br />
<br />
{{hc|1=$ dd if=/dev/zero of=/dev/zero bs=64KiB count=1|2=<br />
1+0 records in<br />
1+0 records out<br />
65536 bytes (66 kB, 64 KiB) copied, 7.583e-05 s, 864 MB/s<br />
}}<br />
<br />
Since "KiB" is less ambiguous than "K", I'd like to replace all our {{ic|1=bs=}} usage with *iB. The problem then is [[BusyBox]], it doesn't support it:<br />
<br />
{{hc|1=$ busybox dd if=/dev/zero of=/dev/zero bs=64KiB count=1|2=<br />
dd: invalid number '64KiB'<br />
}}<br />
<br />
Should that stop me from changing wiki articles?<br />
<br />
(A related discussion about the units also happened before in [[User talk:Neven#"M" unit in dd]])<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:15, 20 March 2019 (UTC)<br />
<br />
== Should the style of redirection be specified? ==<br />
<br />
[[Help:Style#Redirect pages]] should this paragraph specify a style, such as using {{ic|<nowiki>#redirect [[Penguin]] </nowiki>}} instead of {{ic|<nowiki>#REDIRECT [[Penguin]]</nowiki>}} or {{ic|<nowiki>#redirect: [[Penguin]]</nowiki>}}? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 14:41, 30 April 2020 (UTC)<br />
<br />
:[[mw:Help:Redirects#Creating a redirect]] says that "REDIRECT" is case-insensitive, though there should not be colon after it. I don't know if it's worth adding a style rule just for this. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:23, 30 April 2020 (UTC)<br />
<br />
::Some redirection pages use colons at the back. Do I think it should at least stipulate that colons should not be used at the back? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 23:44, 30 April 2020 (UTC)<br />
<br />
:::[[Help:Style#Redirect pages]] links to [[Help:Editing#Redirects]], personally I've always considered the style used in [[Help:Editing]] and related Help pages as the recommended standard throughout the wiki, so much that not long after creating this very page I already started thinking that style rules should have actually been spread and mixed in a series of "Editing" articles by topic, e.g. article structure, usage of templates etc. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:31, 20 June 2020 (UTC)<br />
<br />
::::Nothing prevents us from reorganizing all the style/editing/etc. guides now :) -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:32, 21 June 2020 (UTC)<br />
<br />
:::::See also this [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=559648#Better_structuring old discussion]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:05, 21 June 2020 (UTC)<br />
<br />
== Should categories use sentence case? ==<br />
<br />
The sentence case information in [[Help:Style#Title]] is only for article pages, should categories also follow?<br />
<br />
If so, then [[Help:Style#Category pages]] should include information about sentence case. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 09:58, 13 August 2020 (UTC)<br />
<br />
:Categories should also use sentence case. We can't link from [[Help:Style#Category pages]] to [[Help:Style#Title]] since the rule about singular form usage doesn't apply to category pages. I guess we will need to create a separate "Title" subsection in [[Help:Style#Category pages]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:06, 13 August 2020 (UTC)<br />
<br />
::We also have [[Help:Category]] and in particular [[Help:Category#i18n category name]] already addressing titles. I think that, in agreement with [[#Should the style of redirection be specified?]] and related, this could be a good chance to aggregate Category-page style rules there. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:12, 14 August 2020 (UTC)<br />
<br />
:::Sounds good to me. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 04:14, 15 August 2020 (UTC)<br />
<br />
== Troubleshooting style ==<br />
<br />
The troubleshooting section of many Arch articles are inconsistent and don't follow any established guidelines. A simple guideline would be to list a 1) problem, 2) cause, and 3) solution. For example, the section "Muted audio device" in PulseAudio/Troubleshooting is currently formatted as:<br />
<br />
{{bc|<br />
Muted audio device<br />
<br />
If one experiences no audio output via any means while using [[ALSA]], attempt to unmute the sound card. To do this, launch {{ic|alsamixer}} and make sure each column has a green {{ic|00}} under it (this can be toggled by pressing {{ic|m}}):<br />
<br />
$ alsamixer -c 0<br />
<br />
Note|alsamixer will not tell you which output device is set as the default. One possible cause of no sound after install is that PulseAudio detects the wrong output device as a default. Install {{Pkg|pavucontrol}} and check if there is any output on the pavucontrol panel when playing a ''.wav'' file.<br />
}}<br />
<br />
Here are some proposed styles that allow for a sense of consistency and succinctness:<br />
<br />
[[User:Majamin|Majamin]] ([[User talk:Majamin|talk]]) 21:48, 22 August 2020 (UTC)<br />
<br />
:I don't think that enforcing any style or formatting for troubleshooting sections is realistic. Your suggestions might work for the simplest cases, but most of the troubleshooting content on the wiki is too complex to be formatted into a 3-point list or a 3-column table. Consider e.g. [[Xorg#Troubleshooting]], [[NVIDIA/Troubleshooting]], [[Network configuration#Troubleshooting]], [[Network configuration/Wireless#Troubleshooting]], [[Network configuration/Wireless#Troubleshooting drivers and firmware]], [[Bluetooth#Troubleshooting]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:06, 22 August 2020 (UTC)<br />
<br />
::I respectfully disagree. There are some very well written troubleshooting articles in the topics you mentioned, and would be difficult to reformat into the PCS framework (my wording), but I think that the trouble would be worth it. [https://media-exp1.licdn.com/dms/image/C5112AQEsXKD0CXyYxg/article-inline_image-shrink_1000_1488/0?e=1603324800&v=beta&t=ZWls1y7EQZHIhCEf69e7x10yVjcMTx7zIrYbEIdu9A0 Here is an example of a well-written troubleshooting chart for a car]. I believe that we could adopt a similar format to simplify troubleshooting steps. There are times when additional tables and notes are required. Perhaps these could be left to the end of a certain section as notes (similar to note section in Proposals 1 and 2 below). My proposal would make these sections longer, but I believe that the consistent format would ensure ease of reading. With a consistent framework, one could also make the sections more modular. [[User:Majamin|Majamin]] ([[User talk:Majamin|talk]]) 22:09, 22 August 2020 (UTC)<br />
<br />
=== Style Proposal 1 - Simple problem, cause, solution style ===<br />
<br />
; Problem: no audio output<br />
; Cause: output devices are muted<br />
; Solution: launch alsamixer with {{ic|alsamixer -c 0`}} in a console and unmute all devices<br />
<br />
{{Note|alsamixer will not tell you which output device is set as the default. One possible cause of no sound after install is that PulseAudio detects the wrong output device as a default. Install {{Pkg|pavucontrol}} and check if there is any output on the pavucontrol panel when playing a ''.wav'' file.}}<br />
<br />
=== Style Proposal 2 - Table style ===<br />
<br />
{| class="wikitable"<br />
! Problem !! Cause !! Solution<br />
|-<br />
| No audio output || Output devices are muted || launch alsamixer with {{ic|alsamixer -c 0`}} in a console and unmute all devices<br />
|}<br />
<br />
{{Note|alsamixer will not tell you which output device is set as the default. One possible cause of no sound after install is that PulseAudio detects the wrong output device as a default. Install {{Pkg|pavucontrol}} and check if there is any output on the pavucontrol panel when playing a ''.wav'' file.}}<br />
<br />
== Using remarks or footnotes ==<br />
<br />
Sometimes it makes sense to add remarks and other hints.<br />
<br />
There are three possible ways to achieve this:<br />
<br />
# Using Unicode characters[https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts]. [[HP_ZBook_14u_G6|Example page using this]] (see the table on the right)<br />
# A custom wiki plugin<br />
# Using {{ic|<nowiki><sup></sup></nowiki>}} and an ordered list. [[Domain_name_resolution#DNS_servers|Example page using this]]<br />
<br />
The first way is problematic because it requires special fonts.<br />
The second one is also problematic because it requires time, effort and quite possibly maintenance. It may not be worth it.<br />
The third way is the easiest one, it looks better than the Unicode characters and does not require special fonts. Although this does require usage of HTML tags, which is discouraged. But this behavior can not be achieved with mediawiki markup (yet), unfortunately.<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 22:08, 7 September 2020 (UTC)<br />
<br />
:I support the third way too: HTML tags are [[Help:Style#HTML tags|discouraged]] to the advantage of wiki markup, but they're not forbidden when no simpler alternative is available. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:34, 23 March 2021 (UTC)<br />
<br />
== systemd user units operations ==<br />
<br />
[[Special:PermanentLink/687874#systemd units operations|Help:Style#systemd units operations]] provides examples of operations of system units, but I think it might also be helpful to provide some examples for operations on [[systemd/User]] units as well. Possibly something similar to below:<br />
<br />
:To have Redshift launched on login, [[enable]] the {{ic|redshift.service}} or {{ic|redshift-gtk.service}} [[user unit]].<br />
<br />
-- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 20:41, 22 July 2021 (UTC)<br />
<br />
:It's still weird, because the text behind [[enable]] does not talk about user units, and [[user unit]] talks about the whole concept of a user session manager, not only user units. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:32, 23 July 2021 (UTC)<br />
<br />
::Regarding [[user unit]]; what about linking to [[systemd/User#How it works]] since it mentions that "other units can be controlled manually with {{ic|systemctl --user}}"? A redirect already exists for this too, [[systemctl --user]]. Alternatively, I guess [[systemd#Using units]] could be changed to mention the {{ic|--user}} option for user units, in which case, "user unit" doesn't need to be formatted as a link. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 15:01, 23 July 2021 (UTC)<br />
<br />
:::I think both targets can be improved, then the wording for the operations will not matter (so much) and we can formalize the example. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:56, 23 July 2021 (UTC)<br />
<br />
::::Okay, I've made a [[Special:Diff/689171|revision]] to [[systemd#Using units]] that mentions user units. I haven't made a revision to [[user unit]] since the other revision mentions [[systemctl --user]]. It feels unnecessary to me to use the [[user unit]] redirect in the example above following this change. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 20:42, 23 July 2021 (UTC)<br />
<br />
== Lock keys in "Keyboard keys" section ==<br />
<br />
As mentioned on IRC, [[{{ARTICLEPAGENAME}}#Keyboard keys]] does not mention conventions for [[w:lock key|lock key]]s like [[w:Caps Lock|Caps Lock]]. Wikipedia prefers {{ic|Caps Lock}} to {{ic|CapsLock}} (with [[w:Template:key press]]), but I use and prefer {{ic|CapsLock}} since the former can look weird in key combinations on the ArchWiki due to the space between "Caps" and "Lock". The ArchWiki similarly prefers {{ic|PageUp}} to {{ic|Page Up}} (or its abbreviation, {{ic|PgUp}}). See also [[w:Page Up]].<br />
<br />
I think there are about four possible choices for formatting lock keys (when using monospace):<br />
<br />
# {{ic|CapsLk}} (or {{ic|ScrLk}} for [[w:Scroll Lock|Scroll Lock]])<br />
# {{ic|CapsLock}}<br />
# {{ic|Caps Lock}}<br />
# {{ic|Caps_Lock}}<br />
<br />
As mentioned, I prefer the second option (mostly because that's what I typically use). I also prefer it over the fourth option with the underscore since the Caps Lock key on my keyboard is marked as "CapsLock". I don't have an opinion on the first option.<br />
<br />
-- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 19:33, 25 August 2021 (UTC)<br />
<br />
== Date format guideline ==<br />
<br />
I think that the Style guide should specify a preferred date/time format, particularly for places where dates need to be sortable. Currently I've encountered a mix of YYYY-MM-DD, YYYY.MM.DD, DD.MM.YYYY, MM/YY styles depending on the preference of the author. While it's probably a pointless task to enforce it everywhere, it'd be nice to have a guideline to adhere to. I'd suggest YYYY-MM-DD, as it's ISO 8601 standard and nicely sortable.<br />
<br />
My use case at the moment: [[Laptop/Acer]] page and family (while these pages have plenty of other unrelated problems, let's focus on the date column right now). Entries are currently timestamped with chaotic formats and to improve usability, I have made the tables sortable and I was going to normalize the dates to make the sorting work correctly. I dropped in to see what [[Help:Style]] has to say about it - I wanted to make sure I'd adhere to the norm. Sadly, I found nothing - hence my suggestion to give ISO 8601 the official blessing of the Style guide :)<br />
<br />
[[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 10:14, 16 February 2022 (UTC)<br />
<br />
:Sounds reasonable and I agree that ISO 8601 date should be preferred for sorting reasons. I guess such a rule would belong in [[Help:Style#Spelling]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:29, 17 February 2022 (UTC)<br />
<br />
:: What about [[Help:Style#Language_register]]? There's already a bullet point there about avoiding imprecision when referencing time, which could be changed to: ''Do not use indefinite time references such as "currently", "at the time of writing" or "soon"; replace them with definite expressions such as "as of May 2015" etc. When giving all-numeric dates, use [https://en.wikipedia.org/wiki/ISO_8601#Dates ISO 8601 date format] e.g. 2015-05-01, 2019-01. This is especially important in sortable context such as tables.'' -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 10:57, 17 February 2022 (UTC)<br />
<br />
:::While the text in [[Help:Style#Language register]] will need updating to honor the new rule, I do not think the new rule itself belongs in that section. IMHO it's more of a spelling thing, than a language/wording thing. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:47, 17 February 2022 (UTC)<br />
<br />
== Acknowledge "Configuration" and "Usage" as standard sections ==<br />
<br />
The style guide currently does not recognize "Configuration" or "Usage" as standard sections. I propose that these be added, with the following relationship between the sections:<br />
* ''Usage'' information is required to use the software.<br />
* ''Configuration'' information is helpful to customize the software, especially for common use cases.<br />
* ''Tips and Tricks'' information is either advanced, or only applicable for common cases.<br />
<br />
I believe that these sections are sufficiently ubiquitous on the wiki. Here are some instances of sections that either literally are ''Usage'' sections, or function as one:<br />
* [[KDE#Starting_Plasma]]<br />
* [[GNOME#Starting]]<br />
* [[Dolphin#Usage]]<br />
* [[Docker#Usage]]<br />
* [[Makepkg#Usage]] (this page breaks the structure; this is a rare case in which usage comes ''after'' configuration)<br />
<br />
Here are some examples of the ''Configuration'' section:<br />
* [[KDE#Configuration]]<br />
* [[GNOME#Configuration]]<br />
* [[GNOME/Files#Configuration]] (Dolphin and Nautilus' sections are not analogous, so this one doesn't work out so nice)<br />
* [[Docker#Configuration]]<br />
* [[Makepkg#Configuration]]<br />
* [[Firefox#Configuration]]<br />
* [[Chromium#Configuration]]<br />
* [[Mkinitcpio#Configuration]]<br />
* [[Booster#Configuration]]<br />
* [[NVIDIA#Xorg configuration]]<br />
* [[Bluetooth#Configuration]]<br />
<br />
Here is some proposed wording for each section. ''"Tips and tricks" section'' is a modification of the existing section, but I removed the {{ic|The various tips and tricks should be organized in subsections}} bullet as to lax the requirement for the tips and tricks to be related to each other (logically related configuration options are more likely to belong in ''Configuration'').<br />
<br />
===== "Usage" section =====<br />
<br />
* ''Usage'' sections are used for describing how to use the software, and any configuration steps that are required to get started.<br />
<br />
===== "Configuration" section =====<br />
<br />
* ''Configuration'' sections are used for describing how to customize the behavior of software. This info should not be so critical for using the program that it belongs in ''Usage'', but not so advanced or obscure that it belongs in ''Tips and tricks''.<br />
* There is a higher expectation for hierarchical organization in subsections than with ''Tips and tricks''.<br />
<br />
===== "Tips and tricks" section =====<br />
<br />
* ''Tips and tricks'' sections provide advanced tips or examples of using the software.<br />
* Use the standard title of ''Tips and tricks''.<br />
<br />
Thanks, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 02:29, 17 March 2022 (UTC)<br />
<br />
:I don't really agree that "Usage" should be for mandatory instructions while "Configuration" for optional. For pages about services it would usually be the other way around. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:57, 18 March 2022 (UTC)<br />
<br />
::This is a good point. I had dismissed the possibility of this being a problem because of the services that have a usable default configuration (such as [[Docker#Usage]], [[CUPS#Usage]], kinda [[OpenSSH#Server_usage]]). I see what you mean now, with services like [[Pi-hole]] requiring "Configuration", then "Usage". In fact, I think I'm seeing more occurrences of articles that don't have a "Usage" section at all, since that can happen for services. Thanks, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 18:43, 18 March 2022 (UTC)<br />
<br />
== American vs. British English Usage ==<br />
<br />
There exist [[Wikipedia:American_and_British_English_spelling_differences|spelling differences between American and British English]]. One which comes up often on the ArchWiki is [[Special:Search/behavior|"behavior"]] (American English), as opposed to [[Special:Search/behaviour|"behaviour"]] (British English). Less objectively, the difference relates to the [[Wikipedia:Serial_comma|serial comma]] (usually "Oxford comma"), which Wikipedia says is much more common place in American English.<br />
<br />
At a minimum, I think there should be a consensus on which spelling to use, added to [[Help:Style#Spelling]]. A hard fast rule might not be as necessary (or applicable to this exact page) for Oxford commas, but it is somewhat relevant to mention. Thanks, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 19:02, 5 June 2022 (UTC)<br />
: British spelling is commonly used throughout Europe and the Commonwealth, whereas american spelling is used in, well, America. Like the imperial measurement system, it should remain there. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 22:23, 5 June 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Maintenance_Team&diff=720889ArchWiki talk:Maintenance Team2022-03-02T00:22:39Z<p>Jasonwryan: /* Visited links are gray */ Purple</p>
<hr />
<div>{{Note|This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.}}<br />
<br />
== Reorganization ==<br />
<br />
The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.<br />
<br />
However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:<br />
<br />
# I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".<br />
# ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.<br />
# ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of [[ArchWiki talk:Administrators]] (e.g. update the link in [[ArchWiki:Contributing#Complaining]]).<br />
# ✓ I'd like to deprecate [[ArchWiki:Reports]], and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to ''also'' report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes. <br> Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation. <br> Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.<br />
# Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: [https://github.com/kynikos/wiki-monkey/issues/175 #175], [https://github.com/kynikos/wiki-monkey/issues/176 #176], [https://github.com/kynikos/wiki-monkey/issues/197 #197] and [https://github.com/kynikos/wiki-monkey/issues/198 #198].<br />
# ✓ The [[ArchWiki:Maintenance_Team#Current_patrols]] list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.<br />
# ✓ [[ArchWiki:Maintenance_Team#Statistics]] was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.<br />
<br />
Opinions needed. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:11, 6 May 2015 (UTC)<br />
<br />
:: Point 1) Sounds good to me.<br />
:: Point 2) Agreed.<br />
:: Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.<br />
:: Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much. <br />
:: Points 6 & 7) Agreed<br />
:: -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 10:11, 7 May 2015 (UTC)<br />
<br />
:::1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account<br />
:::4,7. I'm neutral on this... I think having [[ArchWiki:Reports]] as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)<br />
:::6. Yep, and not including active members as well. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:10, 7 May 2015 (UTC)<br />
<br />
::::Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.<br />
::::Is it also the time to consider [[ArchWiki_talk:Administrators#Meaning_of_Administrator]] at this point?<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 7 May 2015 (UTC)<br />
<br />
:::::About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.<br />
:::::Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping [[ArchWiki:Reports]] would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to [[ArchWiki:Reports]] too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.<br />
:::::[[ArchWiki_talk:Administrators#Meaning_of_Administrator]] could surely be implemented in this article, it's very related indeed.<br />
:::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 8 May 2015 (UTC)<br />
<br />
::::::I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only. <br />
::::::How about doing it like you propose, but changing procedure for the reports that ''may'' still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 10 May 2015 (UTC)<br />
<br />
:::::::My idea (which I hadn't eleaborated yet here) was to allow the creation of ''quick'' reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from [[ArchWiki:Reports]] as an example of how it could look instead in the affected article's talk page:<br />
::::::::<h2>Quick report</h2><br />
::::::::''[This is an automatic [[ArchWiki:Reports|report]] about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]''<br />
::::::::''Comment'': I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp<br />
:::::::The whole thing could be manually added simply with: <br />
:::::::{{bc|<nowiki>{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~</nowiki>}}<br />
:::::::The link to [[ArchWiki:Reports]] (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.<br />
:::::::If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), [[Special:Diff]] could be used instead of the full link, and it could create the report in full text (i.e. like using the template with ''subst''). <br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:54, 11 May 2015 (UTC)<br />
<br />
::::::::Now in this case I'd like to nominate "(4) to deprecate [[Archwiki:Reports]]" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:48, 11 May 2015 (UTC)<br />
<br />
:::::::::Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:55, 12 May 2015 (UTC)<br />
<br />
:::::::::For the moment I've done points 6 and 7. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:43, 24 May 2015 (UTC)<br />
<br />
::::::::::I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:14, 29 July 2015 (UTC)<br />
<br />
:::::::::::Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in [[ArchWiki:Reports]]' table, which are probably even worse when it comes to [https://github.com/kynikos/wiki-monkey/issues/216 breakability], so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.<br />
:::::::::::I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).<br />
:::::::::::To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:54, 11 August 2015 (UTC)<br />
<br />
::::::::::::Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 13 September 2016 (UTC)<br />
<br />
:::::::::::::I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:51, 14 September 2016 (UTC)<br />
<br />
::::::::::::::I've flagged the page for archiving for now [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=450811&oldid=450669]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:40, 14 September 2016 (UTC)<br />
<br />
:I'd like to know if there's still consensus on 1?<br />
:If it were to be implemented, here's a list of things to do:<br />
:# Replace {{ic|1=$wgGroupPermissions['maintainer'] = array();}} with {{ic|1=$wgGroupPermissions['moderator'] = array();}} in [https://github.com/archlinux/archwiki/blob/master/LocalSettings.archlinux.org.php LocalSettings.php] and get it deployed.<br />
:# Ask DevOps to run {{ic|php maintenance/MigrateUserGroup.php 'maintainer' 'moderator'}}. See [[mw:Manual:migrateUserGroup.php]].<br />
:# Move [[MediaWiki:Grouppage-maintainer]] to [[MediaWiki:Grouppage-moderator]].<br />
:# Delete [[MediaWiki:Group-maintainer]] and [[MediaWiki:Group-maintainer-member]].<br />
:# Create [[MediaWiki:Group-moderator]] and [[MediaWiki:Group-moderator-member]].<br />
:# Update [[ArchWiki:Access levels and roles]], [[ArchWiki:Maintenance Team]] and [[Special:WhatLinksHere/ArchWiki:Maintenance Team|other pages]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:26, 26 October 2021 (UTC)<br />
<br />
== Regular Wiki Cleanup Days ==<br />
<br />
I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 19:45, 11 October 2016 (UTC)<br />
<br />
== Admin guidance ==<br />
<br />
Show we add some guidence that an admin should follow, the responsibilty they should take? <br />
<br />
Example:<br />
* Encourage contribution from Arch users. <br />
* Guide new contributor to follow Arch Wiki Style.<br />
--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:23, 11 July 2014 (UTC)<br />
<br />
:Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in [[#Meaning of Administrator]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:06, 12 July 2014 (UTC)<br />
<br />
:"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:53, 28 April 2021 (UTC)<br />
<br />
== <s>Cite extension</s> ==<br />
<br />
''[Moved from [[User talk:Kynikos#Cite extension]]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 15 January 2015 (UTC)]''<br />
<br />
I'm feeling bad about not having a way to cite my sources properly in my article. As I do for the LibreOffice Newsletter I'm in charge of I'll do as it for my Arch Linux articles:<br />
<br />
{{bc|<nowiki><br />
<br />
Some text<ref name=myRefName /><br />
<br />
== References ==<br />
<br />
<ref name=myRefName>[http://someURL The link]</ref><br />
<br />
</nowiki>}}<br />
<br />
I don't know if this system suits you. Let me know. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 01:07, 10 December 2014 (UTC)<br />
<br />
:Unfortunately you cannot use the ref tag in this wiki, since it requires the Cite extension, which we don't have installed. Generally we don't require to support every statement with citations, unlike for example on Wikipedia, but it will be very useful if you will add references to external sources simply using links on keywords, like [https://www.archlinux.org this], or this<sup>[https://www.archlinux.org]</sup> (see the source text for the implementation; we don't have style rules about this for the moment). If you want to mention the generic sources that you use for writing the article, you should just add them to [[Dynamic Kernel Module Support#See also]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 10 December 2014 (UTC)<br />
<br />
::I don't like this idea very much. The ''See also'' section sounds like we invite the user to read these documents to provide more detailed information to the reader, implying the Arch Linux documentation is not complete enough. This isn't actually what we want to do in this case: we just adapted an existing article to build a section of the Arch Linux documentation page. And yes, I would really like to have citations like in Wikipedia, but without the need to cite every assumptions we make obviously. Would you mind installing the Cite extension? -- [[User:wget|wget]] ([[User talk:wget|talk]]) 12:00, 11 December 2014 (UTC)<br />
<br />
:::Unfortunately installing extensions requires write access to the repository, which is restricted to Developers, and a feature request should be opened in the bug tracker. I don't see other alternatives to the methods I proposed above.<br />
:::That said, ArchWiki articles are not intended to be "complete" as in "it shouldn't be necessary to read anything else in order to understand every detail of the topic"; if the topic has good upstream/official documentation, there's no point in duplicating it, see also [[Help:Style#Hypertext metaphor]].<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:12, 12 December 2014 (UTC)<br />
<br />
:::: Hi Kynikos. Happy New Year! Any news about the citation extension? Yet again today, I wanted to write on the wiki that yaourt does support bash and zsh completion, and to link these assumptions to the source code. The cite extension is indeed very useful, especially in the case (like this one) when upstream has not good documentation. If you haven't already reported the feature request on the bug tracker, are you willing to support the one I'm gonna write? Otherwise, I don't see the interest in writing that request: devs will unlikely accept it without your support. Thanks in advance. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 23:50, 6 January 2015 (UTC)<br />
<br />
:::::Happy New Year mate :) Honestly I don't see the need for the cite extension here: can't you just use simple inline links as I proposed above? (And as it's done in every article?) Sorry, but unless you prove that you really have no way to add that link without the extension, I can't support your request... Just try to amend the article with inline links and let's see how it looks, ok? I'll try to help you fix the style, if needed ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:34, 7 January 2015 (UTC)<br />
<br />
:::::Yesterday again, I was cleaning/updating the [[Browser plugins]] and wanted to put a link to the official where I took that information from. That link concerned two locations in that article: [[Browser plugins#Disable the "Press ESC to exit full screen mode" message|Disable the "Press ESC to exit full screen mode" message]] and [[Browser plugins#Multiple monitor full-screen fix|Multiple monitor full-screen fix]], the solution using inline links was to duplicate that URL which I didn't. Regarding the [https://lists.archlinux.org/pipermail/arch-general/2014-December/038000.html your message], the problem seems to be a lack of workforce then. A possible solution would be merging wikis and forums of the [[International communities|native languages communities]] into Arch Linux infrastructure, bringing along all these admins/maintainers to the Arch infra. But for that a bunch of work needs to be done first: easy multilanguage support (especially regarding links) on the Wiki (maybe native language staff can help for that). -- [[User:wget|wget]] ([[User talk:wget|talk]]) 14:59, 8 January 2015 (UTC)<br />
<br />
::::::I see, actually if you want to use the same link in two different sections, there's nothing against it; even if there was the Cite extension installed, you'd have to duplicate the &lt;ref> tag, right? There are already many articles with multiple instances of the same internal or external links, I don't see any harm with that, as long as the duplicated links are found in indipendent parts of an article.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Yes, just the <ref> tag will need to be duplicated, but the URL, authors, description, etc. will not. That ref will just act as a very short reference to the long <ref> tag written at the end of the article. See [https://wiki.documentfoundation.org/LOWN/5 this example], this is the way we are working at TheDocumentFoundation. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::In general, also expanding on what I wrote in my arch-general post that you linked, my position is that it's too late to install the Cite extension now, because that would only introduce a new style standard for external links that would make all the existing articles style-obsolete, in practice starting a very long — if not infinite — transition period over which articles would have both inline and referenced links, which I wouldn't see as an improvement at all.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Don't underestimate my patience or my scripting abilities ;-), I'm the kind of guy a bit maniac, with obsessive need to get everything neat. So transition period isn't really a problem ;-) -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Eheh I understand, I guess I'm a bit like that myself :P Well, considering that we've got this far, I'm going to move this branch of the discussion to [[ArchWiki talk:Administrators]] and see what are the opinions of the rest of the team. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:::::::::Maybe I'm missing something obvious, but I dislike the Wikipedia citation style simply because it needs 3 clicks instead of one: one to see the link, a second to open it, and a third to return to the article. That said I'm a proponent of requiring citations for statements made on this wiki: [[Help_talk:Style#Citations and reasoning]] (one of these days I'll get to making a draft). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:31, 29 October 2015 (UTC)<br />
<br />
::::::::::What I was saying is that if Wikipedia-style citations had been used from the beginning of this wiki, I think we'd probably be used to them by now; it's true that they require more effort to follow a link if you don't use the mouseover tooltip (e.g. when using pentadactyl, vimfx etc.; tooltips can also be set to appear on click though); on the other hand, though, they encourage the maintenance of a comprehensive list of external reference links at the bottom of each article. Anyway, as I've repeated multiple times, now I'm against introducing Wikipedia-style citations.<br />
::::::::::Regarding requiring citations, I'll wait for your draft, but I think making them a requirement could be too much: what do we do with unreferenced statements? Delete them? Or fill articles with "Citation needed" templates? Wikipedia needs citations more than us because it deals with topics that can be easily discussed from biased standpoints; also, it doesn't allow original research, see also [[Wikipedia:Wikipedia:Verifiability]]. In this wiki, I'd talk more of a recommendation, and well specify what kind of statements should better be referenced.<br />
::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:27, 30 October 2015 (UTC)<br />
<br />
::::::Please see it like this: using inline or referenced links are just two different style conventions: the ArchWiki happens to use the first one, let's just stick to it and concentrate on the rest, ok? :)<br />
<br />
::::::There is indeed a lack of workforce on the back-end, although I have to acknowledge the fact that Pierre has recently finally pushed MediaWiki 1.24 in the repo, which means it will reach the server very soon; anyway, his policy regarding internationalization has always been the opposite of your proposal, i.e. encourage localized versions to host their own wiki, so your idea would find some opposition there; but even if it didn't, I think you're greatly overrating the state of the external Arch wikis: of them, only the German and French wikis are actually alive, and the German wiki is already maintained by Pierre himself :)<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Didn't know much about the wiki infrastructure and native language frequentations, but what I've seen on the #archlinux-fr freenode IRC channel, there are some people involved with the French wiki who could be returned to the official wiki, recovering a bit more workforce. Its a great subject for discussion between officials (Pierre) and third parties IMHO. Yes, I'm in complete favour of federating around a same well defined goal: "Unity makes strength", "United we stand, divided we fall" is my country motto. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Well, my personal opinion, which is not an official position because we've never discussed this among the admins, is that I'd be in favour of returning all the translations in the same wiki, but only after implementing [[Help talk:I18n#Language namespace(s) in place of suffixes?]] and proving that it works efficiently with the languages that are already hosted here; we should also prove that we can merge the databases of the external wikis safely and effectively. Only after that we could discuss the return of the external languages, stressing the fact that the admins coming from the other wikis should be willing to adapt to the English wiki customs, which I wouldn't take for granted.<br />
::::::::For the first step I'll need to complete some adaptations to my bot, but that's not on high priority at the moment: I have a todo list that I follow more or less strictly, and I promise I'll get there :)<br />
::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:: Another advantage of being able to use <nowiki><ref></nowiki> is that one could also add meta information to the URL that's being linked to in order to prevent [https://en.wikipedia.org/wiki/Wikipedia:Bare_URLs link rot]. Not all URLs are descriptive enough to figure out where they might have gone when they're not reachabe anymore and the Wayback Machine wasn't able to crawl the site. -- [[User:Ckujau|Ckujau]] ([[User talk:Ckujau|talk]]) 17:07, 16 July 2017 (UTC)<br />
<br />
:: Cite is included in MediaWiki 1.21 and above according to the [https://www.mediawiki.org/wiki/Extension:Cite#Installation MediaWiki Extension:Cite docs]. This wiki is running 1.37.1 (see [[Special:Version]]). If my understanding of the docs is correct then Maintainer should be able to add {{ic|wfLoadExtension( 'Cite' );}} to LocalSettings.php without any need to maintain any additional dependencies. -- [[User:TylerSzabo|TylerSzabo]] ([[User talk:TylerSzabo|talk]]) 17:34, 11 February 2022 (UTC)<br />
<br />
: Moving here from the forum: a six years ago the main concern was maintenance, but now as highlighted by TylerSzabo, Cite is shipped by default with MediaWiki (same for syntax highlighting as said by Zaroth), what about enabling it? --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 20:01, 19 February 2022 (UTC)<br />
<br />
::Nothing has changed on my opinion from 6 years ago, still -1 from me. And as Kynikos pointed out, we'd have 2 different ways of linking references, with a never-ending transition period. I think it's high time to close this discussion. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:04, 19 February 2022 (UTC)<br />
<br />
::: I see that there are already two ways of linking references, [https://www.archlinux.org this], and this<sup>[https://www.archlinux.org]</sup>, enabling Cite would be a "more elegant" solution for the second one, limit the "link rot" (once a link is checked, multiple references to it are ok) and would allow for the use of footnotes. And to be honest I don't understand the problem with a "transition period", why not using both solutions? --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 20:28, 19 February 2022 (UTC)<br />
<br />
:::: Both ways are against [[Help:Style]]: the former contains "this" as a link label and the latter uses HTML tags. We would prefer not to add yet another way which would have to be handled by the style rules. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 19 February 2022 (UTC)<br />
<br />
:::: And would adding style rules be a problem? (I'm not ironic, I don't understand) --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 21:32, 19 February 2022 (UTC)<br />
<br />
::::: They would have to be created in the first place, of course assuming we could agree what they should look like. And that is not all, many other style rules would need to be adapted for consistency (especially because it adds a special section for the footnotes, which conflicts with our rule about [[Help:Style#"See also" section]]). And then we would have to make effort to make all pages consistent with the new style rules... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:45, 19 February 2022 (UTC)<br />
<br />
:::::: Yes but I don't see why it should be a problem: rules and guidelines are not immutable (and allowing both styles wouldn't create a problem with changing the old content). Also, regarding the "See also" I think that footnotes and "See also" should serve different purposes: "See also" should contain link to ''additional'' information, for users who want to deepen the topic (in other words "information and resources about the topic of the page, not already included in the page itself"); while footnotes should be used for further explanations (the usual use in text) and for references (in other words "where this information already in the page comes from"). I don't know if I've made myself clear --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 22:11, 19 February 2022 (UTC)<br />
<br />
== <s>Scribunto</s> ==<br />
<br />
I would like the [[mw:Scribunto]] extension to be installed to the ArchWiki, so that we can improve existing templates and create new useful templates, which currently cannot be implemented. For example we currently cannot [[Help talk:Template#Creation of Template:Info|implement Template:Info]]. Furthermore [[mw:Lua scripting]] would make template code more readable and facilitate maintenance by allowing for translated templates without duplicating the template logic.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 20:07, 17 August 2018 (UTC)<br />
<br />
:Frankly, I don't know how to feel about this. Obviously it would help to fix a lot of problems, but I wouldn't overestimate its usefulness. Lua modules still have to deal with arguments in the MediaWiki markup and the output is integrated back into the MediaWiki markup, so some problems will inherently persist. And since the core markup language sucks, combining it with a perfect scripting language would still be a sucking experience...<br />
:Another thing is that WMF moved to Lua primarily due to [[mw:Lua_scripting#Rationale|performance reasons]] and I don't think that our wiki has any performance problems with the current templates.<br />
:The last thing is a question whether we really ''need'' to invent more and more complicated templates or whether we can keep them simple like they are now. For example, we can say that [[Template:hc]] cannot be used inside lists, which covers at least 99% of the use cases, and for the remaining 1% I'm sure it is possible to adjust the surrounding content of the page to look good even if the template is not inside a list. Having a limited language for writing templates really helps to control the complexity of the resulting templates.<br />
:More opinions needed (especially from the [[archwiki:administrators|administrators]] and [[archwiki:maintainers|maintainers]]).<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:40, 23 August 2018 (UTC)<br />
<br />
::Since nobody else requested this, I'm closing this old discussion. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:56, 20 February 2022 (UTC)<br />
<br />
== <s>Patch Vector skin to display categories at the top of the page</s> ==<br />
<br />
Categories on the ArchWiki are currently displayed at the bottom of the page. While this is the MediaWiki default, it does make the categories of an article less accessible, especially if the article is long. Because categories provide such a great way to find related articles, I think they deserve to be prominently placed at the top, right below the page heading. This is also more consistent with our convention to keep categories at the top of the source text. I initially [[Mediawiki talk:Common.css#Move categories under h1|tried to implement the change using CSS]] but had to figure out that the two ways to move catlinks to the top with CSS, absolute and flex positioning, cannot be implemented cleanly as both don't work with margin collapsing. [[User:Kynikos|Kynikos]] [https://phabricator.wikimedia.org/T192223 asked WikiMedia] if they would accept a Vector skin patch to implement the feature as an option, to which they didn't respond. I managed to patch the Vector skin to implement the desired change. Although we would need to maintain the patch ourselves, I think it is doable (the patch only changes 10 lines) and warranted as it would improve ArchWiki for every reader (that uses the default skin).<br />
<br />
I submitted my patch as [https://github.com/archlinux/archwiki/pull/18 a pull request] to the ArchWiki GitHub repository.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:01, 18 August 2018 (UTC)<br />
<br />
:Now that my patch was declined the only way left appears to be upstream. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:39, 18 November 2018 (UTC)<br />
<br />
== Convention for splitting sections to new page ==<br />
<br />
Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring [[ArchWiki:Contributing]]. For exemple current [[OpenSSH#Tips_and_tricks]], or [[pacman#Troubleshooting]].<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with [[Template:Move]] and start a discussion in their talk pages (not here).<br />
:Otherwise you can try to propose some generic guidelines, for the moment we have a [[Help:Procedures#Split section to a new subpage|procedure]] to implement a split after an agreement has been reached.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::Maybe not generic criterias, but specific ones. For example sections like {{ic|Tips and tricks}} or {{ic|Troubleshooting}} can expand quickly. A generic rule like: {{ic|if more than 10 subsections are listed, you can move the section in a subarticle without asking first}} -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
::Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::That's not enough, because e.g. [[Chromium/Tips and tricks]] is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have [[ArchWiki:Contributing#The 3 fundamental rules]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:59, 16 June 2019 (UTC)<br />
<br />
::::In case the [[Chromium]] page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The [[Template:Move]] description suggest it is only for renaming articles ? -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:18, 17 June 2019 (UTC) <br />
<br />
:::::I've fixed the [[Template:Move]] description, the template has frequently been used to flag sections to be split, e.g. [[Network configuration#Device driver]], [[Arch terminology#Arch Linux]] or [[List of applications#Network managers]], which works pretty fine. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 17 June 2019 (UTC)<br />
<br />
Also, the {{ic|related articles}} sidebar can appear to be a little bloated on some articles (for exemple [[pacman]]). Should there be a dedicated side bar for subarticles (not sure about the name) like [[pacman/Tips_and_tricks]] in [[pacman]] ?<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:I don't find [[pacman]]'s related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in [[ArchWiki:Sandbox]] -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in [[Help talk:Style]], I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.<br />
:::About separators, I don't like them in this context regardless of the links order :)<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:26, 17 June 2019 (UTC)<br />
<br />
== Remove redirect page with bad title ==<br />
<br />
This topic is similar to above [[#Removing unnecessary redirects / pages]] but with a different target redirections. <br />
<br />
Background: <br />
* The [[Help:Article naming guidelines]] changes along the years, so there exist many Old_Title -> New_Title redirections.<br />
* Many new users contribute to Arch Wiki before they notice there is [[Help:Article naming guidelines]], so there exist many Bad_Title -> Good_Title redirections.<br />
* The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.<br />
<br />
Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes:<br />
Installation guide<br />
Installation Guide<br />
Installation guide(Català)<br />
Installation guide (Català)<br />
Installation Guide (Català)<br />
<br />
Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?<br />
<br />
{{Unsigned|14:21, 14 May 2020 (UTC)|Fengchao}}<br />
<br />
:I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 09:21, 7 June 2020 (UTC)<br />
<br />
:I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to [[Flatpak]] which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:30, 9 May 2021 (UTC)<br />
<br />
:One such redirect (that I think should be deleted) is [[Keeping Docs and Info Files]]. No other wiki pages link to it either. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:44, 9 May 2021 (UTC)<br />
<br />
::That one contains a history, so it should be kept (or archived at most). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:37, 15 May 2021 (UTC)<br />
<br />
:::What about renaming it (to something like [[Keeping documentation and information files]]) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:14, 15 May 2021 (UTC)<br />
<br />
::::I think "info" here was referring to [[info]], but it's still better than the old title which I now deleted. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:01, 7 June 2021 (UTC)<br />
<br />
:::::Thanks. I guess the "bad" title wasn't as bad as I thought then. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 15:17, 7 June 2021 (UTC)<br />
<br />
:Guys, I have made some mess while moving a page into a user subpage, so some redirect pages ought to be deleted:<br />
:* [https://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Dm-crypt/Device encryption (Русский)]<br />
:* [https://wiki.archlinux.org/index.php?title=User:User:Dimadenisjuk/Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no User:User:Dimadenisjuk/Dm-crypt/Device encryption (Русский)]<br />
:-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 06:26, 8 June 2021 (UTC)<br />
<br />
::Both pages are now deleted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:11, 8 June 2021 (UTC)<br />
<br />
:::Thanks. I have found that there are a lot of badly named redirects in the Russian AW ([https://wiki.archlinux.org/index.php?title=Pacman/Tips_and_tricks_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Pacman/Tips and tricks (Русский)], [https://wiki.archlinux.org/index.php?title=Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)/%D0%A1%D0%BE%D0%B2%D0%B5%D1%82%D1%8B_%D0%B8_%D0%BF%D1%80%D0%B8%D1%91%D0%BC%D1%8B&redirect=no Pacman (Русский)/Советы и приёмы], etc.), so later I shall create a list of such pages and put it here.<br />
:::-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 10:44, 8 June 2021 (UTC)<br />
<br />
:Here is one, please delete it: [[RTorrent(简体中文)]]。 -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:27, 22 June 2021 (UTC)<br />
<br />
::Done. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:47, 24 June 2021 (UTC)<br />
<br />
== Are there statistics of page access? ==<br />
<br />
Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:05, 28 June 2020 (UTC)<br />
<br />
:I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:43, 28 June 2020 (UTC)<br />
<br />
::I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:00, 28 June 2020 (UTC)<br />
<br />
:::Agreed. Would be nice to review and assist with what matters most to our users. [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 05:13, 11 July 2020 (UTC)<br />
<br />
== Acceptable user names and signatures ==<br />
<br />
I've just blocked [[User:🥚]] for a week until we make a decision on a general policy, they had only edited their User page, so it's borderline spam or a joke, but that's not my main point.<br />
<br />
I think the user name is practically unsearcheable without copy-pasting, and too hard to address for example in talk pages, it may mess up logs, bots etc.<br />
<br />
1) I propose to limit user names to ascii characters, plus possibly the other languages' characters that we support, but exclude emoticons and other fancy unicode characters. We'd either need a comprehensive definition or reserve the right to decide case by case.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Well, it messed up wiki-scripts and it took me more than an hour to figure out the problem... [https://github.com/lahwaacz/wiki-scripts/commit/25c11f36712df03c705d7cd1d3a8c673fc87360f] To actually limit the user names, we could write an abuse filter with some regex matching (assuming that the extension actually works). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:00, 11 August 2020 (UTC)<br />
<br />
::If we find an exact character set, sure we can try with an abuse filter. For the moment I'm also adding a reference to [[w:Wikipedia:Username_policy#Non-script_usernames]] (and the rest of the page): we may even default to using that page too. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 11 August 2020 (UTC)<br />
<br />
:::Yes, I think that would be a good policy for us too. It's certainly much better than writing our own from scratch :) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:11, 11 August 2020 (UTC)<br />
<br />
::I don't really see an issue with these kind of usernames; if some script can't parse them, then it's the fault of the script not the username. There hasn't yet been a influx of users with malicious intents and ''not-easily typable'' usernames, so I'd rather we don't take a heavy handed approach. Let's not overreact over an egg. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:40, 12 August 2020 (UTC)<br />
<br />
:::Ok that bots are supposed to be able to handle unicode, and the "too hard" in my OP should have better been "needlessly hard", of course we can find our way around [https://xkcd.com/1953/ weird] usernames, still assuming that MediaWiki and the extensions that we use are "ok" with that too (MW is mainly developed around Wikipedia, and adopting a looser username policy may end up into unexplored territory).<br />
:::In general though I think nobody whose goal is constructive interaction with the community would choose a clearly deliberately hard-to-handle username. After all, the purpose of a username is to make oneself easily identifiable by the other members of the community, it's not there only for aesthetic or artistic reasons.<br />
:::I wouldn't see adopting [[w:Wikipedia:Username_policy]] as heavy handed, the restrictions on misleading and disruptive usernames make a lot of sense to me, still leaving a lot of freedom of choice.<br />
:::I'd also be ok to take this to a vote.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
::::I updated [[Special:AbuseFilter/16]] to allow only usernames with ASCII characters in range 0x20–0x7E. Let's see if anyone complains. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:56, 2 February 2022 (UTC)<br />
<br />
:::::I disabled [[Special:AbuseFilter/16|filter 16]] and instead updated filters [[Special:AbuseFilter/15|15]], [[Special:AbuseFilter/5|5]] and [[Special:AbuseFilter/15|6]]. Let's hope I didn't break anything. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:19, 7 February 2022 (UTC)<br />
<br />
2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Or at least ban custom signatures that hide or change the real username. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
:[[User:😎]] just registered, although this is just a test account of [[User:Klausenbusk]], who is a member of the devops team, this is still relevant. I am still in favor of adopting the blocklist used by Wikipedia, as mentioned in [[#Abusefilter]].<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:34, 5 June 2021 (UTC)<br />
<br />
3) Related: reserve a class of usernames that may be used for official purposes, eg., legal, privacy, policy, security. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:16, 25 August 2021 (UTC)<br />
<br />
:I'd like to point out that a user was just deleted for having an obscene username (credits to me for finding and annoying the wiki admins with it). Having a wikipedia-like automated check if the username matches a regex would definitely help with detection of that. [[Wikipedia:Wikipedia:Usernames for administrator attention]].<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 15:38, 26 December 2021 (UTC)<br />
<br />
::I don't see any automation on that wikipedia page. If you give us a regex, we could try blocking that with AbuseFilter (assuming it actually works...). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:12, 29 December 2021 (UTC)<br />
<br />
:::The automation is doing a bot, which does regex matching. The bot reports it on the aforementioned page so it can be reviewed since false positives are a thing. We are not as big as wikipedia anyways, so just having something report it might even be a bit too much. The other part is users reporting accounts since a bot can not possibly catch everything. There is a list of regexes that the bot uses though: [[Wikipedia:User:AmandaNP/UAA/Blacklist]]<br />
:::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:53, 29 December 2021 (UTC)<br />
<br />
::::I tried those patterns in [[Special:AbuseFilter/test]] using {{bc|<nowiki><br />
_regex := "INSERT_REGEX_HERE";<br />
action === 'createaccount' & accountname irlike _regex<br />
</nowiki>}}<br />
::::From 2021-12-22 it matched only three account creations.<br />
:::: ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:58, 29 December 2021 (UTC)<br />
<br />
:::::A little while ago I created [[Special:AbuseFilter/16]]. It blocks usernames matching [[w:User:AmandaNP/UAA/Blacklist]] and a few other words, but not Unicode ranges. So far it has 49 hits. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:40, 2 February 2022 (UTC)<br />
<br />
== Visual editor ==<br />
<br />
''[Moved from [[Help talk:Editing#Visual Editor]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:22, 23 September 2020 (UTC)]''<br />
<br />
:Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 12:54, 18 September 2020 (UTC)<br />
<br />
::AFAIK no one has proposed adding a visual editor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:28, 18 September 2020 (UTC)<br />
<br />
:::Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 17:39, 23 September 2020 (UTC)<br />
<br />
::::You already have :) And I gathered that you're talking about [[mw:Extension:VisualEditor|Extension:VisualEditor]].<br />
::::MediaWiki 1.35.0 [https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-September/000259.html will be released this week], so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.<br />
::::The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create [[mw:Help:TemplateData|TemplateData]] for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:43, 24 September 2020 (UTC)<br />
<br />
== Old redirects with broken section links ==<br />
<br />
While fixing dead/broken links I noticed there are quite a few redirects with broken section links. I fixed some of them but there are a handful of old redirects where I would think that archiving is better than fixing them.<br />
I already archived [[Aion]] after discussing this in the wiki IRC channel.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Page<br />
! Last human edit<br />
! Why I am in favor of archiving (or deleting)<br />
|-<br />
| [[Daemon/List]] ||rowspan="3"|August 2015 ||rowspan="4"|There is no list containing daemons anymore. This has become irrelevant because systemd manages them now and as the page mentions, systemctl can be used to get a list of installed service units.<br />
|-<br />
| [[Daemons list]]<br />
|-<br />
| [[Daemons List]]<br />
|-<br />
| [[Daemons List (Español)]] || August 2018<br />
|-<br />
| [[How to customize Motd]] || May 2015 || The only relevant mention I found about the MOTD is a redirect I fixed, [[Motd]], which leads to a section that basically says "edit /etc/motd".<br />
|-<br />
| [[Check if you can resolve domain names]] || May 2018 || I am still unsure about this one. The section has become [https://wiki.archlinux.org/index.php?title=Domain_name_resolution&diff=prev&oldid=547539 "Resolve a domain name using NSS"] but this is not a good hypertext metaphor/topic reference in my opinion.<br />
|-<br />
| [[Network interface controller]] || October 2018 || Links to a section that has been split off into two separate pages. Ethernet and wireless configuration are now separate.<br />
|-<br />
| [[NOOK HD+]] || Feburary 2014 || Links to a section which contained (android-)device specific ADB instructions which were removed, seem to be obsolete and the device is nowhere else mentioned.<br />
|-<br />
| [[Webmail with Thunderbird]] || June 2012 || Severely outdated and broken<br />
|-<br />
| [[wbar]] || August 2014 || Abandoned project, has also been removed from the AUR<br />
|}<br />
<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 11:03, 26 January 2021 (UTC)<br />
<br />
* I've deleted [[Daemon/List]] and [[Daemons List]] (no history) and archived [[Daemons list]] and [[Daemons List (Español)]]<br />
* I've deleted [[How to customize Motd]]<br />
* [[Check if you can resolve domain names]] is still linked from several pages, I'll delete it when it's unused because the title is terrible<br />
* I think [[Network interface controller]] should be redirected where [[Network interface]] links (and the term should actually be used there, e.g. as a link to [[w:Network interface controller|Network interface controller]])<br />
* I've archived [[NOOK HD+]] because there is some history<br />
* [[Webmail with Thunderbird]] had been already archived<br />
* I've archived [[wbar]]<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:24, 9 May 2021 (UTC)<br />
<br />
::I replaced all the things linking to [[check if you can resolve domain names]].<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 12:43, 12 May 2021 (UTC)<br />
<br />
== Outdated pages in the DeveloperWiki ==<br />
<br />
I have encountered [[DeveloperWiki:Linux Conferences]] which is horribly outdated. I hereby request the deletion of the page. I asked about this in the [[ArchWiki:IRC|IRC channel]] and was advised to take this here by [[User:Svito]], which also mentioned that it might make sense to discuss some other, more general questions here:<br />
<br />
# Who is responsible for those?<br />
# Where to nag people to update/archive them? (My comment on this: I already asked on the talk page of a [[DeveloperWiki:Articles Linked from Website|DeveloperWiki article]] to remove a bit from the page because it has a dead link (as you all might have noticed, I like to fix dead and broken links).)<br />
# There are some pages in the DeveloperWiki with one or multiple issues (mostly broken/dead links and outdated stuff), what should be done about that? It clutters the statistics a bit in my opinion<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:23, 15 February 2021 (UTC)<br />
<br />
:# [https://archlinux.org/people/developers/ Developers] are responsible for DeveloperWiki.<br />
:# Refer to 1.<br />
:# Generally we try to refrain from touching DeveloperWiki (that's why it's in such a horrible shape). If you want to change something in a page, it's better to ask a [[Special:ListUsers/archdev|developer]] to do it.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:21, 15 February 2021 (UTC)<br />
<br />
::The DeveloperWiki is basically a wild west. Discussions on talk page will be ignored for the most. The pages are not updated for ages. As the pages are public, the users may want to improve/update the content on such pages if they find it relevant. But users basically are unable to do so. For example, I wanted to update info in the [[DeveloperWiki:UID_/_GID_Database]]. I asked in irc channel my request, but I was told "The devwiki isn't there to teach the general userbase about anything". Then I cannot see a reason to show the page to non-developers users. And I was told "Why hide it?".<br />
::From the reader's perspective of view, such pages are uneditable junk. And no one is going to update it: developers do not care or do not have time, and the developers users are a really little number of people.<br />
::So I think either some pages should be hidden (so in the main wiki userspace users will create an "updatable" version) or info on such pages should be editable in some way (probably by moving some pages to normal namespace). What do you think? [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 16:25, 8 May 2021 (UTC)<br />
<br />
:::Pages in the DeveloperWiki are written by developers for developers, i.e. not for general userbase. From my point of view, they are already "hidden" behind the DeveloperWiki: prefix. If this is not obvious enough, maybe we should make it more understandable somehow.<br />
:::As for the [[DeveloperWiki:UID_/_GID_Database]] page, its purpose is/was to allocate numbers for specific packages. That's it. The documentation of what these users and groups are for and how they should be used belongs to separate pages dedicated to the relevant package. If it is a general system group, it would be described in [[Users and groups#Group list]].<br />
:::— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:18, 8 May 2021 (UTC)<br />
<br />
::::In theory, my understanding was the pool of people both qualified to edit it, and capable of actually doing so, was supposed to be greatly expanded by allowing TUs to do so, but this was waiting on "permission models" of some sort? [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 01:21, 31 May 2021 (UTC)<br />
<br />
:::::I don't think giving TUs access to DeveloperWiki was ever considered from the wiki administrator side. The "privileged" [[ArchWiki:Access levels and roles|access level]] was created and assigned to developers with a different motivation. Though now that it exists, it can be used for such purpose, but such decision must come from developers. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:14, 31 May 2021 (UTC)<br />
<br />
::::::The problem with that, unless we create yet another access level, is that 59 TUs would get "privileged", which can edit the same pages as cosysop (reserved to wiki maintainers). So we'd undo the whole effort of not giving unnecessary wiki-wide permissions to accounts that only need it to edit a few select pages. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:22, 12 June 2021 (UTC)<br />
<br />
:[[User:Jelly]] composed [https://md.archlinux.org/KtVq1GIiSCSQHewRI1IazA a list of pages that can be removed]. I think we can mark them for archiving (or redirection if possible) and per [[ArchWiki:Archive]], archive them after a week. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:40, 15 August 2021 (UTC)<br />
<br />
== Creation of a hardware team ==<br />
<br />
As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The [[Help:Laptop page guidelines|Laptop page guidelines]] have been created and all uncompliant pages have been flagged.<br />
<br />
There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are [[Dell TB16|docks]] on the wiki, [[TerraTec Cinergy T RC MKII USB Stick|exotic USB devices]], [[Hauppauge Nova-T Stick|more exotic USB devices]], [[Vertex VW110L - Ufon|modems]] and more. Also tablet PCs and apparently ARM-devices (yes [[User:nl6720]], I agree that they do not belong here but they are still hardware pages).<br />
<br />
Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.<br />
<br />
There are currently maybe two people (me and [[User:DerpishCat]]) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.<br />
<br />
The goals are:<br />
# Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how<br />
# Make current tasks public so others know what we need help with<br />
# Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.<br />
<br />
The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g [[Help:Style]], some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:49, 7 April 2021 (UTC)<br />
<br />
:So you want to create [[ArchWiki:Hardware Team]]? With only two team members, I think it's a little too soon for that.<br />
:If you simply want a central discussion page, you can use [[Category talk:Hardware]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:59, 7 April 2021 (UTC)<br />
<br />
== Abusefilter ==<br />
<br />
As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.<br />
<br />
I am in favor of adopting [https://en.wikipedia.org/wiki/User:AmandaNP/UAA/Blacklist the "block"list that Wikipedia uses], with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:<br />
<br />
* If certain derivatives (e.g Manjaro) or other distros are in the name.<br />
* Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.<br />
* This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.<br />
<br />
Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like [https://en.wikipedia.org/wiki/User:ClueBot_NG ClueBot NG] but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.<br />
<br />
It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:50, 28 April 2021 (UTC)<br />
<br />
:We should also enable [[mw:Extension:AntiSpoof]]. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 30 April 2021 (UTC)<br />
<br />
::I agree with that. That looks like it will be beneficial, too.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:01, 30 April 2021 (UTC)<br />
<br />
== <s>Commercial self-promotion on the ArchWiki</s> ==<br />
<br />
See [[Special:Diff/670967|670967]], this is clearly ''commercial'' self-promotion here (Sidenote: using "latest" as the archiso version gets old really quickly). This is a very new account and also their first edit.<br />
<br />
I did not undo this because this is not clearly defined anywhere. I would like your opinions on this.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 09:32, 14 May 2021 (UTC)<br />
: Looks like spam to me... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]])<br />
<br />
: This is still a concern, see [[Special:Diff/715117]], another clearly commercial promotion with a new account on their first edit. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 20:22, 19 February 2022 (UTC)<br />
<br />
::I've blocked both accounts. Even if one may argue the links are "related" to Arch, the code of conduct clearly mentions: [https://terms.archlinux.org/docs/code-of-conduct/#spamadvertisingsolicitation]<br />
:::Promoting web-invites, blog posts or commercial promotions are actively discouraged, or outright prohibited. '''Registering just to promote your issue/cause, FOSS-related or not, treats the community as a resource and is not acceptable;''' if unsure about the appropriateness of your content, contact the support staff before posting.<br />
::-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:52, 19 February 2022 (UTC)<br />
<br />
::: I'm sorry to react here even though you've closed the topic, but I have another example of promotional content : [[Bilibili (简体中文)]] (and the translation [[Bilibili]]). The original page was created as the first contribution of the user in 2015-03-11, without any other contribution afterwards. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:45, 20 February 2022 (UTC)<br />
<br />
:::: If the user hasn't edited in 7 years, banning them after that time probably won't do much... I've flagged [[Bilibili_(简体中文)]] for deletion, using your removal template for [[Bilibili]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 20 February 2022 (UTC)<br />
<br />
::::: Thank you very much ! There are two broken redirect ([[哔哩哔哩]] and [[B 站]]) left to those deleted pages which will need to be removed too. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 05:45, 27 February 2022 (UTC)<br />
<br />
:::::: Now they are gone. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:15, 27 February 2022 (UTC)<br />
<br />
:Credits to [[User:Klausenbusk]] for finding them, but we got some more: [[Special:Diff/483786|483786]], [[Special:Diff/696889|696889]]<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 17:53, 21 February 2022 (UTC)<br />
<br />
:: [https://youtu.be/-DT7bX-B1Mg?t=25 And it's gone] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:40, 22 February 2022 (UTC)<br />
<br />
== Visited links are gray ==<br />
<br />
This makes the links blend in with the regular text on the page, especially when using [https://darkreader.org/ Dark Reader].<br />
{{Unsigned|07:30, 16 May 2021 (UTC)|Glibg10b}}<br />
<br />
: From an accssibility/usability perspective, this is a terrible choice; something with some contrast for colourblind or visually impaired people would be a much better choice. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 06:00, 31 May 2021 (UTC)<br />
<br />
:: Which color would you prefer for visited links? The [https://archlinux.org/ archweb] site currently uses the same color for visited and unvisited links, which effectively disabled highlighting visited links... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:52, 4 June 2021 (UTC)<br />
<br />
::: Sorry, I missed this reply :p I would probably opt for the standard purple: it should provide sufficient contrast for low/impaired vision readers and will be familiar to anyone from the early web. No idea how graphic designers will react to it tho... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:22, 2 March 2022 (UTC)<br />
<br />
== Delete Improving performance (简体中文) tmp ==<br />
<br />
This page was originally moved to [[User:Dragonwater/Improving performance (简体中文) tmp]], but due to [[User:Dragonwater|Dragonwater]]'s editing, this page still exists, so please delete it. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 11:31, 4 June 2021 (UTC)<br />
<br />
:xx Talk before move page that created just before. xx<br />
:Everyone's works needs be respect. I hope maintenance members modify/move/delete pages with cautious. I just don't want get a contradiction just because page has a state changed or see my pages are move/delete when save. This is not a rule surely, but makes better.<br />
:-- [[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 11:50, 4 June 2021 (UTC)<br />
<br />
::If I understood it correctly, trailing " tmp" in article's name means the article is intended as a draft. Such ''temporary'' pages must not appear in the main namespace. [[User:Blackteahamburger|Blackteahamburger]] was right moving this draft into your personal subpage where you can finish the translation. After completing the translation, you can publish the clean version in the main namespace by choosing the [[Help:I18n#Page titles|appropriate name]]. Second page creation is an accident, there is no crime in it.<br />
::-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 16:03, 4 June 2021 (UTC)<br />
<br />
::: I know I make a wrong, but I hope members inform me before move a page that likely editing.<br />
::: I'm sorry for what mistake I make. Edit contradiction always be annoying, a page missing even more.<br />
::: [[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 03:36, 5 June 2021 (UTC)<br />
<br />
::::In fact, this cannot be done because there is no way to know if anyone is editing. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:20, 5 June 2021 (UTC)<br />
<br />
== How to change packaging policies ==<br />
<br />
I recently made a note about the [[Talk:Wine package guidelines|Wine Package Guidelines talk page]] because I want to modify them slightly. I'm new to editing here, so I was wondering if there was a proper procedure for doing this. Do I simply take initiative and watch for if people complain?<br />
<br />
[[User:VinceUB|VinceUB]] ([[User talk:VinceUB|talk]]) 07:42, 5 August 2021 (UTC)<br />
<br />
== Long, cluttered and hard to maintain pages ==<br />
<br />
Unfortunately there are some pages on here which are hard to maintain because:<br />
* It is hard to validate the information without the specific hardware or software (which tends to be proprietary and may cost a lot)<br />
* No one knows if this still applies since the information may be ancient and the above still applies<br />
* There is so much content that transformed the page into something that is not feasible to maintain.<br />
<br />
These are pages where lots of users contributed their individual solutions to and this basically spiralled out of control. The worst pages in this category are:<br />
<br />
* [[Mac]]<br />
* [[Steam/Game-specific troubleshooting]]<br />
* Some laptop vendor pages, but this might be a different although vaguely similar topic. These have grown into spreadsheets and some are pretty bad.<br />
** [[Laptop/Acer]] is by far the worst.<br />
<br />
Other pages which are not as bad yet but should be monitored:<br />
<br />
* [[PCI passthrough via OVMF/Examples]] - was pruned recently<br />
* Laptop vendor pages (e.g [[Laptop/Lenovo]]) - mentioned in [[Category talk:Hardware]], part of a bigger problem<br />
* [[Dotfiles]]<br />
<br />
Both lists are unfortunately yet incomplete I suspect.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 01:23, 10 August 2021 (UTC)<br />
<br />
:The same applies to almost all troubleshooting sections and pages: [[Network configuration/Wireless#Troubleshooting drivers and firmware]], [[Bluetooth#Troubleshooting]], [[PulseAudio/Troubleshooting]], [[Firefox#Troubleshooting]], [[NVIDIA/Troubleshooting]] etc. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:56, 10 August 2021 (UTC)<br />
<br />
::At least for troubleshooting sections, [[Help:Style#"Troubleshooting" section]] says to link the bug or create a bug report if there isn't any. There's nothing we can do for sections that don't include any bug links. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:50, 10 August 2021 (UTC)<br />
<br />
== User menu for logged out users ==<br />
<br />
ArchWiki is now using the [[mw:Reading/Web/Desktop Improvements|new Vector skin]] [https://github.com/archlinux/archwiki/commit/5b43f15fb1f079e8a20ae4be8f3581a62b4fb5be by default]. That includes the [[mw:Reading/Web/Desktop Improvements/Features/User menu|user menu]].<br />
<br />
For logged out users, the user menu shows "Pages for logged out editors ([[Help:Introduction|learn more]])".<br />
<br />
The text can be customized in [[MediaWiki:vector-anon-user-menu-pages]] and the link title in [[MediaWiki:vector-anon-user-menu-pages-learn]]. The "learn more" link is hardcoded to [[Help:Introduction]] in MediaWiki 1.37, but it will use [[MediaWiki:vector-intro-page]] in some future release (see [[phab:T290813]]). There's also [[MediaWiki:vector-anon-user-menu-pages-label]], but I'm not sure where that is shown.<br />
<br />
So now we should decide what to do with these:<br />
<br />
* [[MediaWiki:vector-anon-user-menu-pages]]<br />
* [[MediaWiki:vector-anon-user-menu-pages-learn]]<br />
* [[MediaWiki:vector-anon-user-menu-pages-label]]<br />
* [[Help:Introduction]]<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:59, 21 December 2021 (UTC)<br />
<br />
:[[Help:Introduction]] could probably be redirected to [[{{ns:PROJECT}}:Contributing]]. ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:50, 26 December 2021 (UTC)<br />
<br />
== Syntax highlighting in code blocks ==<br />
<br />
MediaWiki since version 1.21 has the [https://www.mediawiki.org/wiki/Extension:SyntaxHighlight SyntaxHighlight] extension bundled. It adds the '''<nowiki><syntaxhighlight></nowiki>''' block, which lets editors add code blocks with syntax highlighting in specified language for easier readibility. As ArchWiki is a highly technical wiki, with configuration file and script snippets sprinkled everywhere, I was surprised to find this wasn't enabled yet.<br />
<br />
Is there a specific reason for this omission? If not, I'd happily welcome this addition to the wiki. -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 12:39, 15 February 2022 (UTC)<br />
<br />
:I wouldn't say there's a "specific reason for this omission". It simply was never enabled. Even if we do get it enabled, we would not want it to be used directly in pages, only through templates. I think it should be possible to adjust [[Template:bc]] and [[Template:hc]] to add an additional parameter to specify syntax highlighting language. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:36, 17 February 2022 (UTC)<br />
<br />
::That sounds reasonable, I understand that the parameter would be directly passed to the tag and would have to be one from the list of languages that '''SyntaxHighlight''' supports. Assuming that approach, I looked at the extension's parameters to check which ones also would be useful to expose via template on ArchWiki. So:<br />
::* '''lang''' - specifies lexer to use for highlighting, e.g. ''python, cfg, pacmanconf'' or one of [https://pygments.org/docs/lexers/ many others]. Would be useful in '''<nowiki>{{bc}}</nowiki>''', '''<nowiki>{{hc}}</nowiki>''', possibly even '''<nowiki>{{ic}}</nowiki>''' (for e.g. shell one-liners, using ''shell-session'' lexer so the '''#''' prompt is correctly interpreted)<br />
::* '''highlight''' - highlights specified line(s), e.g. ''3-5, 7''. I can see this being useful in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>''' for e.g. showing context of a config file section while highlighting the important/modified lines. <br />
::* '''line''' and '''start''' parameters enable showing line numbers and choose the start of the shown numeration, respectively. I don't see it being particularly useful on ArchWiki, especially since the '''highlight''' parameter works fine without them. If one finds a plausible usecase, I guess they could be exposed in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>'''.<br />
::* '''class''', '''style''' and '''inline''' parameters control style and are already covered by the existing templates, so no need to consider them (except maybe when modifying the templates' code).<br />
::I wanted to be helpful and try my hand at drafting what the new template code could look like. However, I can't tell whether the '''<nowiki><pre></nowiki>''' hack used in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>''' will still be needed with the extension enabled without trying it out. If not, this change would certainly make these templates' code easier to read and understand. -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 10:39, 17 February 2022 (UTC)<br />
<br />
:::I don't think we should care about any parameter other than {{ic|lang}}.<br />
:::Also adding {{ic|wfLoadExtension( 'SyntaxHighlight_GeSHi' );}} to [https://github.com/archlinux/archwiki/blob/master/LocalSettings.archlinux.org.php LocalSettings.archlinux.org.php] will not be enough. The extension requires <s>{{Pkg|python-pygments}}</s> {{Pkg|python}}. ''I think'', it would need to be added to https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/tasks/main.yml#L20.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:26, 21 February 2022 (UTC)<br />
<br />
::::Actually, I was wrong. pygmentize is shipped in {{ic|extensions/SyntaxHighlight_GeSHi/pygments/pygmentize}}, so only {{Pkg|python}} is needed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:34, 21 February 2022 (UTC)<br />
<br />
== Adding code of conduct and terms of service links in the footer ==<br />
<br />
According to [[mw:Manual:Footer#Add links to the footer]] additional footer links can be created by editing {{ic|LocalSettings.php}}. I think it would be a good idea to links to the [[archlinux-service-agreements:code-of-conduct|code of conduct]] and [[archlinux-service-agreements:terms-of-service|terms of service]].<br />
<br />
I've prepared https://github.com/archlinux/archwiki/pull/53. Thoughts?<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:06, 21 February 2022 (UTC)<br />
<br />
== Syntax highlighting for JavaScript and CSS pages ==<br />
<br />
I would like to enable [[mw:Extension:CodeEditor|Extension:CodeEditor]] in ArchWiki. As it's wiki page says, it provides syntax highlighting for JavaScript, CSS and Lua. Although its use is limited, it could be useful when editing [[MediaWiki:Common.css]], [[MediaWiki:Common.js]] and [[Special:AbuseFilter|abuse filters]].<br />
<br />
As usual: 👍/subscribe/approve https://github.com/archlinux/archwiki/pull/54.<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:36, 21 February 2022 (UTC)<br />
<br />
:Wait, abuse filters are in Lua (or Javascript)? I've never noticed... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:10, 25 February 2022 (UTC)<br />
<br />
::[[mw:Extension:AbuseFilter/Rules format]] says ''The rules are a custom language. They are formatted similar to conditionals in a C/Java/Perl-like language''. It looks like [https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/master/modules/mode-abusefilter.js] provides the necessary integration with CodeEditor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:33, 26 February 2022 (UTC)<br />
<br />
== Semi-protect [[Arch Linux on a VPS]] ==<br />
<br />
As you might have seen, there were some problems with that page because it attracted people using this page as an ad board. It was the very first edit for most of the now banned users, so I hereby request that this page should be semi-protected to deter others with the same interests.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:36, 26 February 2022 (UTC)<br />
<br />
:Well, that page is essentially an ad board. IMHO there's no difference if editors add their favorite VPS there or the providers add themselves. The end result is the same. (Semi-)protecting it will just lead to users starting discussions in the talk page, asking to list a provider and I'm sure no one is actually interested in curating any lists on that page. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:41, 26 February 2022 (UTC)<br />
<br />
::Could it be restricted only to users with at least a few days/weeks old account or a few non-reverted edits ? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:17, 26 February 2022 (UTC)<br />
<br />
:::What's what "{{int:restriction-level-autoconfirmed}}"[https://github.com/archlinux/archwiki/blob/master/LocalSettings.archlinux.org.php#L285-L288] would do.<br />
:::I'm just saying that users will not just give up after not being able to make the edit themselves. They'll start a discussion about it in the talk page.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:54, 27 February 2022 (UTC)<br />
:::: At least forcing a discussion on the Talk page will require *some* moderation of the proposed entry, ie., reduce the likelihood of "This is the bestest image"--type edits. Either way, given this is a potential revenue stream for people, there is bound to be attempted abuse. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 17:15, 1 March 2022 (UTC)<br />
<br />
::::: I'm also in favor of semi-protecting the page. If anything, if these entries by commercial accounts are first posted on the talk page, we have some more to check them for authenticity. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:37, 1 March 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Maintenance_Team&diff=720875ArchWiki talk:Maintenance Team2022-03-01T17:15:39Z<p>Jasonwryan: /* Semi-protect Arch Linux on a VPS */ Agree</p>
<hr />
<div>{{Note|This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.}}<br />
<br />
== Reorganization ==<br />
<br />
The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.<br />
<br />
However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:<br />
<br />
# I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".<br />
# ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.<br />
# ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of [[ArchWiki talk:Administrators]] (e.g. update the link in [[ArchWiki:Contributing#Complaining]]).<br />
# ✓ I'd like to deprecate [[ArchWiki:Reports]], and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to ''also'' report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes. <br> Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation. <br> Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.<br />
# Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: [https://github.com/kynikos/wiki-monkey/issues/175 #175], [https://github.com/kynikos/wiki-monkey/issues/176 #176], [https://github.com/kynikos/wiki-monkey/issues/197 #197] and [https://github.com/kynikos/wiki-monkey/issues/198 #198].<br />
# ✓ The [[ArchWiki:Maintenance_Team#Current_patrols]] list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.<br />
# ✓ [[ArchWiki:Maintenance_Team#Statistics]] was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.<br />
<br />
Opinions needed. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:11, 6 May 2015 (UTC)<br />
<br />
:: Point 1) Sounds good to me.<br />
:: Point 2) Agreed.<br />
:: Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.<br />
:: Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much. <br />
:: Points 6 & 7) Agreed<br />
:: -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 10:11, 7 May 2015 (UTC)<br />
<br />
:::1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account<br />
:::4,7. I'm neutral on this... I think having [[ArchWiki:Reports]] as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)<br />
:::6. Yep, and not including active members as well. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:10, 7 May 2015 (UTC)<br />
<br />
::::Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.<br />
::::Is it also the time to consider [[ArchWiki_talk:Administrators#Meaning_of_Administrator]] at this point?<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 7 May 2015 (UTC)<br />
<br />
:::::About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.<br />
:::::Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping [[ArchWiki:Reports]] would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to [[ArchWiki:Reports]] too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.<br />
:::::[[ArchWiki_talk:Administrators#Meaning_of_Administrator]] could surely be implemented in this article, it's very related indeed.<br />
:::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 8 May 2015 (UTC)<br />
<br />
::::::I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only. <br />
::::::How about doing it like you propose, but changing procedure for the reports that ''may'' still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 10 May 2015 (UTC)<br />
<br />
:::::::My idea (which I hadn't eleaborated yet here) was to allow the creation of ''quick'' reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from [[ArchWiki:Reports]] as an example of how it could look instead in the affected article's talk page:<br />
::::::::<h2>Quick report</h2><br />
::::::::''[This is an automatic [[ArchWiki:Reports|report]] about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]''<br />
::::::::''Comment'': I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp<br />
:::::::The whole thing could be manually added simply with: <br />
:::::::{{bc|<nowiki>{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~</nowiki>}}<br />
:::::::The link to [[ArchWiki:Reports]] (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.<br />
:::::::If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), [[Special:Diff]] could be used instead of the full link, and it could create the report in full text (i.e. like using the template with ''subst''). <br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:54, 11 May 2015 (UTC)<br />
<br />
::::::::Now in this case I'd like to nominate "(4) to deprecate [[Archwiki:Reports]]" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:48, 11 May 2015 (UTC)<br />
<br />
:::::::::Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:55, 12 May 2015 (UTC)<br />
<br />
:::::::::For the moment I've done points 6 and 7. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:43, 24 May 2015 (UTC)<br />
<br />
::::::::::I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:14, 29 July 2015 (UTC)<br />
<br />
:::::::::::Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in [[ArchWiki:Reports]]' table, which are probably even worse when it comes to [https://github.com/kynikos/wiki-monkey/issues/216 breakability], so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.<br />
:::::::::::I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).<br />
:::::::::::To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:54, 11 August 2015 (UTC)<br />
<br />
::::::::::::Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 13 September 2016 (UTC)<br />
<br />
:::::::::::::I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:51, 14 September 2016 (UTC)<br />
<br />
::::::::::::::I've flagged the page for archiving for now [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=450811&oldid=450669]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:40, 14 September 2016 (UTC)<br />
<br />
:I'd like to know if there's still consensus on 1?<br />
:If it were to be implemented, here's a list of things to do:<br />
:# Replace {{ic|1=$wgGroupPermissions['maintainer'] = array();}} with {{ic|1=$wgGroupPermissions['moderator'] = array();}} in [https://github.com/archlinux/archwiki/blob/master/LocalSettings.archlinux.org.php LocalSettings.php] and get it deployed.<br />
:# Ask DevOps to run {{ic|php maintenance/MigrateUserGroup.php 'maintainer' 'moderator'}}. See [[mw:Manual:migrateUserGroup.php]].<br />
:# Move [[MediaWiki:Grouppage-maintainer]] to [[MediaWiki:Grouppage-moderator]].<br />
:# Delete [[MediaWiki:Group-maintainer]] and [[MediaWiki:Group-maintainer-member]].<br />
:# Create [[MediaWiki:Group-moderator]] and [[MediaWiki:Group-moderator-member]].<br />
:# Update [[ArchWiki:Access levels and roles]], [[ArchWiki:Maintenance Team]] and [[Special:WhatLinksHere/ArchWiki:Maintenance Team|other pages]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:26, 26 October 2021 (UTC)<br />
<br />
== Regular Wiki Cleanup Days ==<br />
<br />
I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 19:45, 11 October 2016 (UTC)<br />
<br />
== Admin guidance ==<br />
<br />
Show we add some guidence that an admin should follow, the responsibilty they should take? <br />
<br />
Example:<br />
* Encourage contribution from Arch users. <br />
* Guide new contributor to follow Arch Wiki Style.<br />
--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:23, 11 July 2014 (UTC)<br />
<br />
:Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in [[#Meaning of Administrator]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:06, 12 July 2014 (UTC)<br />
<br />
:"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:53, 28 April 2021 (UTC)<br />
<br />
== <s>Cite extension</s> ==<br />
<br />
''[Moved from [[User talk:Kynikos#Cite extension]]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 15 January 2015 (UTC)]''<br />
<br />
I'm feeling bad about not having a way to cite my sources properly in my article. As I do for the LibreOffice Newsletter I'm in charge of I'll do as it for my Arch Linux articles:<br />
<br />
{{bc|<nowiki><br />
<br />
Some text<ref name=myRefName /><br />
<br />
== References ==<br />
<br />
<ref name=myRefName>[http://someURL The link]</ref><br />
<br />
</nowiki>}}<br />
<br />
I don't know if this system suits you. Let me know. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 01:07, 10 December 2014 (UTC)<br />
<br />
:Unfortunately you cannot use the ref tag in this wiki, since it requires the Cite extension, which we don't have installed. Generally we don't require to support every statement with citations, unlike for example on Wikipedia, but it will be very useful if you will add references to external sources simply using links on keywords, like [https://www.archlinux.org this], or this<sup>[https://www.archlinux.org]</sup> (see the source text for the implementation; we don't have style rules about this for the moment). If you want to mention the generic sources that you use for writing the article, you should just add them to [[Dynamic Kernel Module Support#See also]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 10 December 2014 (UTC)<br />
<br />
::I don't like this idea very much. The ''See also'' section sounds like we invite the user to read these documents to provide more detailed information to the reader, implying the Arch Linux documentation is not complete enough. This isn't actually what we want to do in this case: we just adapted an existing article to build a section of the Arch Linux documentation page. And yes, I would really like to have citations like in Wikipedia, but without the need to cite every assumptions we make obviously. Would you mind installing the Cite extension? -- [[User:wget|wget]] ([[User talk:wget|talk]]) 12:00, 11 December 2014 (UTC)<br />
<br />
:::Unfortunately installing extensions requires write access to the repository, which is restricted to Developers, and a feature request should be opened in the bug tracker. I don't see other alternatives to the methods I proposed above.<br />
:::That said, ArchWiki articles are not intended to be "complete" as in "it shouldn't be necessary to read anything else in order to understand every detail of the topic"; if the topic has good upstream/official documentation, there's no point in duplicating it, see also [[Help:Style#Hypertext metaphor]].<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:12, 12 December 2014 (UTC)<br />
<br />
:::: Hi Kynikos. Happy New Year! Any news about the citation extension? Yet again today, I wanted to write on the wiki that yaourt does support bash and zsh completion, and to link these assumptions to the source code. The cite extension is indeed very useful, especially in the case (like this one) when upstream has not good documentation. If you haven't already reported the feature request on the bug tracker, are you willing to support the one I'm gonna write? Otherwise, I don't see the interest in writing that request: devs will unlikely accept it without your support. Thanks in advance. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 23:50, 6 January 2015 (UTC)<br />
<br />
:::::Happy New Year mate :) Honestly I don't see the need for the cite extension here: can't you just use simple inline links as I proposed above? (And as it's done in every article?) Sorry, but unless you prove that you really have no way to add that link without the extension, I can't support your request... Just try to amend the article with inline links and let's see how it looks, ok? I'll try to help you fix the style, if needed ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:34, 7 January 2015 (UTC)<br />
<br />
:::::Yesterday again, I was cleaning/updating the [[Browser plugins]] and wanted to put a link to the official where I took that information from. That link concerned two locations in that article: [[Browser plugins#Disable the "Press ESC to exit full screen mode" message|Disable the "Press ESC to exit full screen mode" message]] and [[Browser plugins#Multiple monitor full-screen fix|Multiple monitor full-screen fix]], the solution using inline links was to duplicate that URL which I didn't. Regarding the [https://lists.archlinux.org/pipermail/arch-general/2014-December/038000.html your message], the problem seems to be a lack of workforce then. A possible solution would be merging wikis and forums of the [[International communities|native languages communities]] into Arch Linux infrastructure, bringing along all these admins/maintainers to the Arch infra. But for that a bunch of work needs to be done first: easy multilanguage support (especially regarding links) on the Wiki (maybe native language staff can help for that). -- [[User:wget|wget]] ([[User talk:wget|talk]]) 14:59, 8 January 2015 (UTC)<br />
<br />
::::::I see, actually if you want to use the same link in two different sections, there's nothing against it; even if there was the Cite extension installed, you'd have to duplicate the &lt;ref> tag, right? There are already many articles with multiple instances of the same internal or external links, I don't see any harm with that, as long as the duplicated links are found in indipendent parts of an article.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Yes, just the <ref> tag will need to be duplicated, but the URL, authors, description, etc. will not. That ref will just act as a very short reference to the long <ref> tag written at the end of the article. See [https://wiki.documentfoundation.org/LOWN/5 this example], this is the way we are working at TheDocumentFoundation. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::In general, also expanding on what I wrote in my arch-general post that you linked, my position is that it's too late to install the Cite extension now, because that would only introduce a new style standard for external links that would make all the existing articles style-obsolete, in practice starting a very long — if not infinite — transition period over which articles would have both inline and referenced links, which I wouldn't see as an improvement at all.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Don't underestimate my patience or my scripting abilities ;-), I'm the kind of guy a bit maniac, with obsessive need to get everything neat. So transition period isn't really a problem ;-) -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Eheh I understand, I guess I'm a bit like that myself :P Well, considering that we've got this far, I'm going to move this branch of the discussion to [[ArchWiki talk:Administrators]] and see what are the opinions of the rest of the team. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:::::::::Maybe I'm missing something obvious, but I dislike the Wikipedia citation style simply because it needs 3 clicks instead of one: one to see the link, a second to open it, and a third to return to the article. That said I'm a proponent of requiring citations for statements made on this wiki: [[Help_talk:Style#Citations and reasoning]] (one of these days I'll get to making a draft). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:31, 29 October 2015 (UTC)<br />
<br />
::::::::::What I was saying is that if Wikipedia-style citations had been used from the beginning of this wiki, I think we'd probably be used to them by now; it's true that they require more effort to follow a link if you don't use the mouseover tooltip (e.g. when using pentadactyl, vimfx etc.; tooltips can also be set to appear on click though); on the other hand, though, they encourage the maintenance of a comprehensive list of external reference links at the bottom of each article. Anyway, as I've repeated multiple times, now I'm against introducing Wikipedia-style citations.<br />
::::::::::Regarding requiring citations, I'll wait for your draft, but I think making them a requirement could be too much: what do we do with unreferenced statements? Delete them? Or fill articles with "Citation needed" templates? Wikipedia needs citations more than us because it deals with topics that can be easily discussed from biased standpoints; also, it doesn't allow original research, see also [[Wikipedia:Wikipedia:Verifiability]]. In this wiki, I'd talk more of a recommendation, and well specify what kind of statements should better be referenced.<br />
::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:27, 30 October 2015 (UTC)<br />
<br />
::::::Please see it like this: using inline or referenced links are just two different style conventions: the ArchWiki happens to use the first one, let's just stick to it and concentrate on the rest, ok? :)<br />
<br />
::::::There is indeed a lack of workforce on the back-end, although I have to acknowledge the fact that Pierre has recently finally pushed MediaWiki 1.24 in the repo, which means it will reach the server very soon; anyway, his policy regarding internationalization has always been the opposite of your proposal, i.e. encourage localized versions to host their own wiki, so your idea would find some opposition there; but even if it didn't, I think you're greatly overrating the state of the external Arch wikis: of them, only the German and French wikis are actually alive, and the German wiki is already maintained by Pierre himself :)<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Didn't know much about the wiki infrastructure and native language frequentations, but what I've seen on the #archlinux-fr freenode IRC channel, there are some people involved with the French wiki who could be returned to the official wiki, recovering a bit more workforce. Its a great subject for discussion between officials (Pierre) and third parties IMHO. Yes, I'm in complete favour of federating around a same well defined goal: "Unity makes strength", "United we stand, divided we fall" is my country motto. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Well, my personal opinion, which is not an official position because we've never discussed this among the admins, is that I'd be in favour of returning all the translations in the same wiki, but only after implementing [[Help talk:I18n#Language namespace(s) in place of suffixes?]] and proving that it works efficiently with the languages that are already hosted here; we should also prove that we can merge the databases of the external wikis safely and effectively. Only after that we could discuss the return of the external languages, stressing the fact that the admins coming from the other wikis should be willing to adapt to the English wiki customs, which I wouldn't take for granted.<br />
::::::::For the first step I'll need to complete some adaptations to my bot, but that's not on high priority at the moment: I have a todo list that I follow more or less strictly, and I promise I'll get there :)<br />
::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:: Another advantage of being able to use <nowiki><ref></nowiki> is that one could also add meta information to the URL that's being linked to in order to prevent [https://en.wikipedia.org/wiki/Wikipedia:Bare_URLs link rot]. Not all URLs are descriptive enough to figure out where they might have gone when they're not reachabe anymore and the Wayback Machine wasn't able to crawl the site. -- [[User:Ckujau|Ckujau]] ([[User talk:Ckujau|talk]]) 17:07, 16 July 2017 (UTC)<br />
<br />
:: Cite is included in MediaWiki 1.21 and above according to the [https://www.mediawiki.org/wiki/Extension:Cite#Installation MediaWiki Extension:Cite docs]. This wiki is running 1.37.1 (see [[Special:Version]]). If my understanding of the docs is correct then Maintainer should be able to add {{ic|wfLoadExtension( 'Cite' );}} to LocalSettings.php without any need to maintain any additional dependencies. -- [[User:TylerSzabo|TylerSzabo]] ([[User talk:TylerSzabo|talk]]) 17:34, 11 February 2022 (UTC)<br />
<br />
: Moving here from the forum: a six years ago the main concern was maintenance, but now as highlighted by TylerSzabo, Cite is shipped by default with MediaWiki (same for syntax highlighting as said by Zaroth), what about enabling it? --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 20:01, 19 February 2022 (UTC)<br />
<br />
::Nothing has changed on my opinion from 6 years ago, still -1 from me. And as Kynikos pointed out, we'd have 2 different ways of linking references, with a never-ending transition period. I think it's high time to close this discussion. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:04, 19 February 2022 (UTC)<br />
<br />
::: I see that there are already two ways of linking references, [https://www.archlinux.org this], and this<sup>[https://www.archlinux.org]</sup>, enabling Cite would be a "more elegant" solution for the second one, limit the "link rot" (once a link is checked, multiple references to it are ok) and would allow for the use of footnotes. And to be honest I don't understand the problem with a "transition period", why not using both solutions? --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 20:28, 19 February 2022 (UTC)<br />
<br />
:::: Both ways are against [[Help:Style]]: the former contains "this" as a link label and the latter uses HTML tags. We would prefer not to add yet another way which would have to be handled by the style rules. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 19 February 2022 (UTC)<br />
<br />
:::: And would adding style rules be a problem? (I'm not ironic, I don't understand) --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 21:32, 19 February 2022 (UTC)<br />
<br />
::::: They would have to be created in the first place, of course assuming we could agree what they should look like. And that is not all, many other style rules would need to be adapted for consistency (especially because it adds a special section for the footnotes, which conflicts with our rule about [[Help:Style#"See also" section]]). And then we would have to make effort to make all pages consistent with the new style rules... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:45, 19 February 2022 (UTC)<br />
<br />
:::::: Yes but I don't see why it should be a problem: rules and guidelines are not immutable (and allowing both styles wouldn't create a problem with changing the old content). Also, regarding the "See also" I think that footnotes and "See also" should serve different purposes: "See also" should contain link to ''additional'' information, for users who want to deepen the topic (in other words "information and resources about the topic of the page, not already included in the page itself"); while footnotes should be used for further explanations (the usual use in text) and for references (in other words "where this information already in the page comes from"). I don't know if I've made myself clear --[[User:D1nuc0m|D1nuc0m]] ([[User talk:D1nuc0m|talk]]) 22:11, 19 February 2022 (UTC)<br />
<br />
== <s>Scribunto</s> ==<br />
<br />
I would like the [[mw:Scribunto]] extension to be installed to the ArchWiki, so that we can improve existing templates and create new useful templates, which currently cannot be implemented. For example we currently cannot [[Help talk:Template#Creation of Template:Info|implement Template:Info]]. Furthermore [[mw:Lua scripting]] would make template code more readable and facilitate maintenance by allowing for translated templates without duplicating the template logic.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 20:07, 17 August 2018 (UTC)<br />
<br />
:Frankly, I don't know how to feel about this. Obviously it would help to fix a lot of problems, but I wouldn't overestimate its usefulness. Lua modules still have to deal with arguments in the MediaWiki markup and the output is integrated back into the MediaWiki markup, so some problems will inherently persist. And since the core markup language sucks, combining it with a perfect scripting language would still be a sucking experience...<br />
:Another thing is that WMF moved to Lua primarily due to [[mw:Lua_scripting#Rationale|performance reasons]] and I don't think that our wiki has any performance problems with the current templates.<br />
:The last thing is a question whether we really ''need'' to invent more and more complicated templates or whether we can keep them simple like they are now. For example, we can say that [[Template:hc]] cannot be used inside lists, which covers at least 99% of the use cases, and for the remaining 1% I'm sure it is possible to adjust the surrounding content of the page to look good even if the template is not inside a list. Having a limited language for writing templates really helps to control the complexity of the resulting templates.<br />
:More opinions needed (especially from the [[archwiki:administrators|administrators]] and [[archwiki:maintainers|maintainers]]).<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:40, 23 August 2018 (UTC)<br />
<br />
::Since nobody else requested this, I'm closing this old discussion. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:56, 20 February 2022 (UTC)<br />
<br />
== <s>Patch Vector skin to display categories at the top of the page</s> ==<br />
<br />
Categories on the ArchWiki are currently displayed at the bottom of the page. While this is the MediaWiki default, it does make the categories of an article less accessible, especially if the article is long. Because categories provide such a great way to find related articles, I think they deserve to be prominently placed at the top, right below the page heading. This is also more consistent with our convention to keep categories at the top of the source text. I initially [[Mediawiki talk:Common.css#Move categories under h1|tried to implement the change using CSS]] but had to figure out that the two ways to move catlinks to the top with CSS, absolute and flex positioning, cannot be implemented cleanly as both don't work with margin collapsing. [[User:Kynikos|Kynikos]] [https://phabricator.wikimedia.org/T192223 asked WikiMedia] if they would accept a Vector skin patch to implement the feature as an option, to which they didn't respond. I managed to patch the Vector skin to implement the desired change. Although we would need to maintain the patch ourselves, I think it is doable (the patch only changes 10 lines) and warranted as it would improve ArchWiki for every reader (that uses the default skin).<br />
<br />
I submitted my patch as [https://github.com/archlinux/archwiki/pull/18 a pull request] to the ArchWiki GitHub repository.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:01, 18 August 2018 (UTC)<br />
<br />
:Now that my patch was declined the only way left appears to be upstream. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:39, 18 November 2018 (UTC)<br />
<br />
== Convention for splitting sections to new page ==<br />
<br />
Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring [[ArchWiki:Contributing]]. For exemple current [[OpenSSH#Tips_and_tricks]], or [[pacman#Troubleshooting]].<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with [[Template:Move]] and start a discussion in their talk pages (not here).<br />
:Otherwise you can try to propose some generic guidelines, for the moment we have a [[Help:Procedures#Split section to a new subpage|procedure]] to implement a split after an agreement has been reached.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::Maybe not generic criterias, but specific ones. For example sections like {{ic|Tips and tricks}} or {{ic|Troubleshooting}} can expand quickly. A generic rule like: {{ic|if more than 10 subsections are listed, you can move the section in a subarticle without asking first}} -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
::Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::That's not enough, because e.g. [[Chromium/Tips and tricks]] is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have [[ArchWiki:Contributing#The 3 fundamental rules]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:59, 16 June 2019 (UTC)<br />
<br />
::::In case the [[Chromium]] page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The [[Template:Move]] description suggest it is only for renaming articles ? -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:18, 17 June 2019 (UTC) <br />
<br />
:::::I've fixed the [[Template:Move]] description, the template has frequently been used to flag sections to be split, e.g. [[Network configuration#Device driver]], [[Arch terminology#Arch Linux]] or [[List of applications#Network managers]], which works pretty fine. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 17 June 2019 (UTC)<br />
<br />
Also, the {{ic|related articles}} sidebar can appear to be a little bloated on some articles (for exemple [[pacman]]). Should there be a dedicated side bar for subarticles (not sure about the name) like [[pacman/Tips_and_tricks]] in [[pacman]] ?<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:I don't find [[pacman]]'s related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in [[ArchWiki:Sandbox]] -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in [[Help talk:Style]], I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.<br />
:::About separators, I don't like them in this context regardless of the links order :)<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:26, 17 June 2019 (UTC)<br />
<br />
== Remove redirect page with bad title ==<br />
<br />
This topic is similar to above [[#Removing unnecessary redirects / pages]] but with a different target redirections. <br />
<br />
Background: <br />
* The [[Help:Article naming guidelines]] changes along the years, so there exist many Old_Title -> New_Title redirections.<br />
* Many new users contribute to Arch Wiki before they notice there is [[Help:Article naming guidelines]], so there exist many Bad_Title -> Good_Title redirections.<br />
* The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.<br />
<br />
Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes:<br />
Installation guide<br />
Installation Guide<br />
Installation guide(Català)<br />
Installation guide (Català)<br />
Installation Guide (Català)<br />
<br />
Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?<br />
<br />
{{Unsigned|14:21, 14 May 2020 (UTC)|Fengchao}}<br />
<br />
:I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 09:21, 7 June 2020 (UTC)<br />
<br />
:I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to [[Flatpak]] which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:30, 9 May 2021 (UTC)<br />
<br />
:One such redirect (that I think should be deleted) is [[Keeping Docs and Info Files]]. No other wiki pages link to it either. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:44, 9 May 2021 (UTC)<br />
<br />
::That one contains a history, so it should be kept (or archived at most). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:37, 15 May 2021 (UTC)<br />
<br />
:::What about renaming it (to something like [[Keeping documentation and information files]]) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:14, 15 May 2021 (UTC)<br />
<br />
::::I think "info" here was referring to [[info]], but it's still better than the old title which I now deleted. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:01, 7 June 2021 (UTC)<br />
<br />
:::::Thanks. I guess the "bad" title wasn't as bad as I thought then. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 15:17, 7 June 2021 (UTC)<br />
<br />
:Guys, I have made some mess while moving a page into a user subpage, so some redirect pages ought to be deleted:<br />
:* [https://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Dm-crypt/Device encryption (Русский)]<br />
:* [https://wiki.archlinux.org/index.php?title=User:User:Dimadenisjuk/Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no User:User:Dimadenisjuk/Dm-crypt/Device encryption (Русский)]<br />
:-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 06:26, 8 June 2021 (UTC)<br />
<br />
::Both pages are now deleted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:11, 8 June 2021 (UTC)<br />
<br />
:::Thanks. I have found that there are a lot of badly named redirects in the Russian AW ([https://wiki.archlinux.org/index.php?title=Pacman/Tips_and_tricks_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Pacman/Tips and tricks (Русский)], [https://wiki.archlinux.org/index.php?title=Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)/%D0%A1%D0%BE%D0%B2%D0%B5%D1%82%D1%8B_%D0%B8_%D0%BF%D1%80%D0%B8%D1%91%D0%BC%D1%8B&redirect=no Pacman (Русский)/Советы и приёмы], etc.), so later I shall create a list of such pages and put it here.<br />
:::-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 10:44, 8 June 2021 (UTC)<br />
<br />
:Here is one, please delete it: [[RTorrent(简体中文)]]。 -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:27, 22 June 2021 (UTC)<br />
<br />
::Done. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:47, 24 June 2021 (UTC)<br />
<br />
== Are there statistics of page access? ==<br />
<br />
Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:05, 28 June 2020 (UTC)<br />
<br />
:I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:43, 28 June 2020 (UTC)<br />
<br />
::I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:00, 28 June 2020 (UTC)<br />
<br />
:::Agreed. Would be nice to review and assist with what matters most to our users. [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 05:13, 11 July 2020 (UTC)<br />
<br />
== Acceptable user names and signatures ==<br />
<br />
I've just blocked [[User:🥚]] for a week until we make a decision on a general policy, they had only edited their User page, so it's borderline spam or a joke, but that's not my main point.<br />
<br />
I think the user name is practically unsearcheable without copy-pasting, and too hard to address for example in talk pages, it may mess up logs, bots etc.<br />
<br />
1) I propose to limit user names to ascii characters, plus possibly the other languages' characters that we support, but exclude emoticons and other fancy unicode characters. We'd either need a comprehensive definition or reserve the right to decide case by case.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Well, it messed up wiki-scripts and it took me more than an hour to figure out the problem... [https://github.com/lahwaacz/wiki-scripts/commit/25c11f36712df03c705d7cd1d3a8c673fc87360f] To actually limit the user names, we could write an abuse filter with some regex matching (assuming that the extension actually works). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:00, 11 August 2020 (UTC)<br />
<br />
::If we find an exact character set, sure we can try with an abuse filter. For the moment I'm also adding a reference to [[w:Wikipedia:Username_policy#Non-script_usernames]] (and the rest of the page): we may even default to using that page too. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 11 August 2020 (UTC)<br />
<br />
:::Yes, I think that would be a good policy for us too. It's certainly much better than writing our own from scratch :) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:11, 11 August 2020 (UTC)<br />
<br />
::I don't really see an issue with these kind of usernames; if some script can't parse them, then it's the fault of the script not the username. There hasn't yet been a influx of users with malicious intents and ''not-easily typable'' usernames, so I'd rather we don't take a heavy handed approach. Let's not overreact over an egg. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:40, 12 August 2020 (UTC)<br />
<br />
:::Ok that bots are supposed to be able to handle unicode, and the "too hard" in my OP should have better been "needlessly hard", of course we can find our way around [https://xkcd.com/1953/ weird] usernames, still assuming that MediaWiki and the extensions that we use are "ok" with that too (MW is mainly developed around Wikipedia, and adopting a looser username policy may end up into unexplored territory).<br />
:::In general though I think nobody whose goal is constructive interaction with the community would choose a clearly deliberately hard-to-handle username. After all, the purpose of a username is to make oneself easily identifiable by the other members of the community, it's not there only for aesthetic or artistic reasons.<br />
:::I wouldn't see adopting [[w:Wikipedia:Username_policy]] as heavy handed, the restrictions on misleading and disruptive usernames make a lot of sense to me, still leaving a lot of freedom of choice.<br />
:::I'd also be ok to take this to a vote.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
::::I updated [[Special:AbuseFilter/16]] to allow only usernames with ASCII characters in range 0x20–0x7E. Let's see if anyone complains. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:56, 2 February 2022 (UTC)<br />
<br />
:::::I disabled [[Special:AbuseFilter/16|filter 16]] and instead updated filters [[Special:AbuseFilter/15|15]], [[Special:AbuseFilter/5|5]] and [[Special:AbuseFilter/15|6]]. Let's hope I didn't break anything. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:19, 7 February 2022 (UTC)<br />
<br />
2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Or at least ban custom signatures that hide or change the real username. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
:[[User:😎]] just registered, although this is just a test account of [[User:Klausenbusk]], who is a member of the devops team, this is still relevant. I am still in favor of adopting the blocklist used by Wikipedia, as mentioned in [[#Abusefilter]].<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:34, 5 June 2021 (UTC)<br />
<br />
3) Related: reserve a class of usernames that may be used for official purposes, eg., legal, privacy, policy, security. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:16, 25 August 2021 (UTC)<br />
<br />
:I'd like to point out that a user was just deleted for having an obscene username (credits to me for finding and annoying the wiki admins with it). Having a wikipedia-like automated check if the username matches a regex would definitely help with detection of that. [[Wikipedia:Wikipedia:Usernames for administrator attention]].<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 15:38, 26 December 2021 (UTC)<br />
<br />
::I don't see any automation on that wikipedia page. If you give us a regex, we could try blocking that with AbuseFilter (assuming it actually works...). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:12, 29 December 2021 (UTC)<br />
<br />
:::The automation is doing a bot, which does regex matching. The bot reports it on the aforementioned page so it can be reviewed since false positives are a thing. We are not as big as wikipedia anyways, so just having something report it might even be a bit too much. The other part is users reporting accounts since a bot can not possibly catch everything. There is a list of regexes that the bot uses though: [[Wikipedia:User:AmandaNP/UAA/Blacklist]]<br />
:::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:53, 29 December 2021 (UTC)<br />
<br />
::::I tried those patterns in [[Special:AbuseFilter/test]] using {{bc|<nowiki><br />
_regex := "INSERT_REGEX_HERE";<br />
action === 'createaccount' & accountname irlike _regex<br />
</nowiki>}}<br />
::::From 2021-12-22 it matched only three account creations.<br />
:::: ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:58, 29 December 2021 (UTC)<br />
<br />
:::::A little while ago I created [[Special:AbuseFilter/16]]. It blocks usernames matching [[w:User:AmandaNP/UAA/Blacklist]] and a few other words, but not Unicode ranges. So far it has 49 hits. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:40, 2 February 2022 (UTC)<br />
<br />
== Visual editor ==<br />
<br />
''[Moved from [[Help talk:Editing#Visual Editor]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:22, 23 September 2020 (UTC)]''<br />
<br />
:Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 12:54, 18 September 2020 (UTC)<br />
<br />
::AFAIK no one has proposed adding a visual editor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:28, 18 September 2020 (UTC)<br />
<br />
:::Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 17:39, 23 September 2020 (UTC)<br />
<br />
::::You already have :) And I gathered that you're talking about [[mw:Extension:VisualEditor|Extension:VisualEditor]].<br />
::::MediaWiki 1.35.0 [https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-September/000259.html will be released this week], so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.<br />
::::The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create [[mw:Help:TemplateData|TemplateData]] for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:43, 24 September 2020 (UTC)<br />
<br />
== Old redirects with broken section links ==<br />
<br />
While fixing dead/broken links I noticed there are quite a few redirects with broken section links. I fixed some of them but there are a handful of old redirects where I would think that archiving is better than fixing them.<br />
I already archived [[Aion]] after discussing this in the wiki IRC channel.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Page<br />
! Last human edit<br />
! Why I am in favor of archiving (or deleting)<br />
|-<br />
| [[Daemon/List]] ||rowspan="3"|August 2015 ||rowspan="4"|There is no list containing daemons anymore. This has become irrelevant because systemd manages them now and as the page mentions, systemctl can be used to get a list of installed service units.<br />
|-<br />
| [[Daemons list]]<br />
|-<br />
| [[Daemons List]]<br />
|-<br />
| [[Daemons List (Español)]] || August 2018<br />
|-<br />
| [[How to customize Motd]] || May 2015 || The only relevant mention I found about the MOTD is a redirect I fixed, [[Motd]], which leads to a section that basically says "edit /etc/motd".<br />
|-<br />
| [[Check if you can resolve domain names]] || May 2018 || I am still unsure about this one. The section has become [https://wiki.archlinux.org/index.php?title=Domain_name_resolution&diff=prev&oldid=547539 "Resolve a domain name using NSS"] but this is not a good hypertext metaphor/topic reference in my opinion.<br />
|-<br />
| [[Network interface controller]] || October 2018 || Links to a section that has been split off into two separate pages. Ethernet and wireless configuration are now separate.<br />
|-<br />
| [[NOOK HD+]] || Feburary 2014 || Links to a section which contained (android-)device specific ADB instructions which were removed, seem to be obsolete and the device is nowhere else mentioned.<br />
|-<br />
| [[Webmail with Thunderbird]] || June 2012 || Severely outdated and broken<br />
|-<br />
| [[wbar]] || August 2014 || Abandoned project, has also been removed from the AUR<br />
|}<br />
<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 11:03, 26 January 2021 (UTC)<br />
<br />
* I've deleted [[Daemon/List]] and [[Daemons List]] (no history) and archived [[Daemons list]] and [[Daemons List (Español)]]<br />
* I've deleted [[How to customize Motd]]<br />
* [[Check if you can resolve domain names]] is still linked from several pages, I'll delete it when it's unused because the title is terrible<br />
* I think [[Network interface controller]] should be redirected where [[Network interface]] links (and the term should actually be used there, e.g. as a link to [[w:Network interface controller|Network interface controller]])<br />
* I've archived [[NOOK HD+]] because there is some history<br />
* [[Webmail with Thunderbird]] had been already archived<br />
* I've archived [[wbar]]<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:24, 9 May 2021 (UTC)<br />
<br />
::I replaced all the things linking to [[check if you can resolve domain names]].<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 12:43, 12 May 2021 (UTC)<br />
<br />
== Outdated pages in the DeveloperWiki ==<br />
<br />
I have encountered [[DeveloperWiki:Linux Conferences]] which is horribly outdated. I hereby request the deletion of the page. I asked about this in the [[ArchWiki:IRC|IRC channel]] and was advised to take this here by [[User:Svito]], which also mentioned that it might make sense to discuss some other, more general questions here:<br />
<br />
# Who is responsible for those?<br />
# Where to nag people to update/archive them? (My comment on this: I already asked on the talk page of a [[DeveloperWiki:Articles Linked from Website|DeveloperWiki article]] to remove a bit from the page because it has a dead link (as you all might have noticed, I like to fix dead and broken links).)<br />
# There are some pages in the DeveloperWiki with one or multiple issues (mostly broken/dead links and outdated stuff), what should be done about that? It clutters the statistics a bit in my opinion<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:23, 15 February 2021 (UTC)<br />
<br />
:# [https://archlinux.org/people/developers/ Developers] are responsible for DeveloperWiki.<br />
:# Refer to 1.<br />
:# Generally we try to refrain from touching DeveloperWiki (that's why it's in such a horrible shape). If you want to change something in a page, it's better to ask a [[Special:ListUsers/archdev|developer]] to do it.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:21, 15 February 2021 (UTC)<br />
<br />
::The DeveloperWiki is basically a wild west. Discussions on talk page will be ignored for the most. The pages are not updated for ages. As the pages are public, the users may want to improve/update the content on such pages if they find it relevant. But users basically are unable to do so. For example, I wanted to update info in the [[DeveloperWiki:UID_/_GID_Database]]. I asked in irc channel my request, but I was told "The devwiki isn't there to teach the general userbase about anything". Then I cannot see a reason to show the page to non-developers users. And I was told "Why hide it?".<br />
::From the reader's perspective of view, such pages are uneditable junk. And no one is going to update it: developers do not care or do not have time, and the developers users are a really little number of people.<br />
::So I think either some pages should be hidden (so in the main wiki userspace users will create an "updatable" version) or info on such pages should be editable in some way (probably by moving some pages to normal namespace). What do you think? [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 16:25, 8 May 2021 (UTC)<br />
<br />
:::Pages in the DeveloperWiki are written by developers for developers, i.e. not for general userbase. From my point of view, they are already "hidden" behind the DeveloperWiki: prefix. If this is not obvious enough, maybe we should make it more understandable somehow.<br />
:::As for the [[DeveloperWiki:UID_/_GID_Database]] page, its purpose is/was to allocate numbers for specific packages. That's it. The documentation of what these users and groups are for and how they should be used belongs to separate pages dedicated to the relevant package. If it is a general system group, it would be described in [[Users and groups#Group list]].<br />
:::— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:18, 8 May 2021 (UTC)<br />
<br />
::::In theory, my understanding was the pool of people both qualified to edit it, and capable of actually doing so, was supposed to be greatly expanded by allowing TUs to do so, but this was waiting on "permission models" of some sort? [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 01:21, 31 May 2021 (UTC)<br />
<br />
:::::I don't think giving TUs access to DeveloperWiki was ever considered from the wiki administrator side. The "privileged" [[ArchWiki:Access levels and roles|access level]] was created and assigned to developers with a different motivation. Though now that it exists, it can be used for such purpose, but such decision must come from developers. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:14, 31 May 2021 (UTC)<br />
<br />
::::::The problem with that, unless we create yet another access level, is that 59 TUs would get "privileged", which can edit the same pages as cosysop (reserved to wiki maintainers). So we'd undo the whole effort of not giving unnecessary wiki-wide permissions to accounts that only need it to edit a few select pages. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:22, 12 June 2021 (UTC)<br />
<br />
:[[User:Jelly]] composed [https://md.archlinux.org/KtVq1GIiSCSQHewRI1IazA a list of pages that can be removed]. I think we can mark them for archiving (or redirection if possible) and per [[ArchWiki:Archive]], archive them after a week. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:40, 15 August 2021 (UTC)<br />
<br />
== Creation of a hardware team ==<br />
<br />
As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The [[Help:Laptop page guidelines|Laptop page guidelines]] have been created and all uncompliant pages have been flagged.<br />
<br />
There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are [[Dell TB16|docks]] on the wiki, [[TerraTec Cinergy T RC MKII USB Stick|exotic USB devices]], [[Hauppauge Nova-T Stick|more exotic USB devices]], [[Vertex VW110L - Ufon|modems]] and more. Also tablet PCs and apparently ARM-devices (yes [[User:nl6720]], I agree that they do not belong here but they are still hardware pages).<br />
<br />
Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.<br />
<br />
There are currently maybe two people (me and [[User:DerpishCat]]) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.<br />
<br />
The goals are:<br />
# Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how<br />
# Make current tasks public so others know what we need help with<br />
# Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.<br />
<br />
The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g [[Help:Style]], some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:49, 7 April 2021 (UTC)<br />
<br />
:So you want to create [[ArchWiki:Hardware Team]]? With only two team members, I think it's a little too soon for that.<br />
:If you simply want a central discussion page, you can use [[Category talk:Hardware]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:59, 7 April 2021 (UTC)<br />
<br />
== Abusefilter ==<br />
<br />
As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.<br />
<br />
I am in favor of adopting [https://en.wikipedia.org/wiki/User:AmandaNP/UAA/Blacklist the "block"list that Wikipedia uses], with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:<br />
<br />
* If certain derivatives (e.g Manjaro) or other distros are in the name.<br />
* Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.<br />
* This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.<br />
<br />
Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like [https://en.wikipedia.org/wiki/User:ClueBot_NG ClueBot NG] but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.<br />
<br />
It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:50, 28 April 2021 (UTC)<br />
<br />
:We should also enable [[mw:Extension:AntiSpoof]]. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 30 April 2021 (UTC)<br />
<br />
::I agree with that. That looks like it will be beneficial, too.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:01, 30 April 2021 (UTC)<br />
<br />
== <s>Commercial self-promotion on the ArchWiki</s> ==<br />
<br />
See [[Special:Diff/670967|670967]], this is clearly ''commercial'' self-promotion here (Sidenote: using "latest" as the archiso version gets old really quickly). This is a very new account and also their first edit.<br />
<br />
I did not undo this because this is not clearly defined anywhere. I would like your opinions on this.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 09:32, 14 May 2021 (UTC)<br />
: Looks like spam to me... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]])<br />
<br />
: This is still a concern, see [[Special:Diff/715117]], another clearly commercial promotion with a new account on their first edit. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 20:22, 19 February 2022 (UTC)<br />
<br />
::I've blocked both accounts. Even if one may argue the links are "related" to Arch, the code of conduct clearly mentions: [https://terms.archlinux.org/docs/code-of-conduct/#spamadvertisingsolicitation]<br />
:::Promoting web-invites, blog posts or commercial promotions are actively discouraged, or outright prohibited. '''Registering just to promote your issue/cause, FOSS-related or not, treats the community as a resource and is not acceptable;''' if unsure about the appropriateness of your content, contact the support staff before posting.<br />
::-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:52, 19 February 2022 (UTC)<br />
<br />
::: I'm sorry to react here even though you've closed the topic, but I have another example of promotional content : [[Bilibili (简体中文)]] (and the translation [[Bilibili]]). The original page was created as the first contribution of the user in 2015-03-11, without any other contribution afterwards. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:45, 20 February 2022 (UTC)<br />
<br />
:::: If the user hasn't edited in 7 years, banning them after that time probably won't do much... I've flagged [[Bilibili_(简体中文)]] for deletion, using your removal template for [[Bilibili]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 20 February 2022 (UTC)<br />
<br />
::::: Thank you very much ! There are two broken redirect ([[哔哩哔哩]] and [[B 站]]) left to those deleted pages which will need to be removed too. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 05:45, 27 February 2022 (UTC)<br />
<br />
:::::: Now they are gone. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:15, 27 February 2022 (UTC)<br />
<br />
:Credits to [[User:Klausenbusk]] for finding them, but we got some more: [[Special:Diff/483786|483786]], [[Special:Diff/696889|696889]]<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 17:53, 21 February 2022 (UTC)<br />
<br />
:: [https://youtu.be/-DT7bX-B1Mg?t=25 And it's gone] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:40, 22 February 2022 (UTC)<br />
<br />
== Visited links are gray ==<br />
<br />
This makes the links blend in with the regular text on the page, especially when using [https://darkreader.org/ Dark Reader].<br />
{{Unsigned|07:30, 16 May 2021 (UTC)|Glibg10b}}<br />
<br />
: From an accssibility/usability perspective, this is a terrible choice; something with some contrast for colourblind or visually impaired people would be a much better choice. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 06:00, 31 May 2021 (UTC)<br />
<br />
:: Which color would you prefer for visited links? The [https://archlinux.org/ archweb] site currently uses the same color for visited and unvisited links, which effectively disabled highlighting visited links... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:52, 4 June 2021 (UTC)<br />
<br />
== Delete Improving performance (简体中文) tmp ==<br />
<br />
This page was originally moved to [[User:Dragonwater/Improving performance (简体中文) tmp]], but due to [[User:Dragonwater|Dragonwater]]'s editing, this page still exists, so please delete it. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 11:31, 4 June 2021 (UTC)<br />
<br />
:xx Talk before move page that created just before. xx<br />
:Everyone's works needs be respect. I hope maintenance members modify/move/delete pages with cautious. I just don't want get a contradiction just because page has a state changed or see my pages are move/delete when save. This is not a rule surely, but makes better.<br />
:-- [[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 11:50, 4 June 2021 (UTC)<br />
<br />
::If I understood it correctly, trailing " tmp" in article's name means the article is intended as a draft. Such ''temporary'' pages must not appear in the main namespace. [[User:Blackteahamburger|Blackteahamburger]] was right moving this draft into your personal subpage where you can finish the translation. After completing the translation, you can publish the clean version in the main namespace by choosing the [[Help:I18n#Page titles|appropriate name]]. Second page creation is an accident, there is no crime in it.<br />
::-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 16:03, 4 June 2021 (UTC)<br />
<br />
::: I know I make a wrong, but I hope members inform me before move a page that likely editing.<br />
::: I'm sorry for what mistake I make. Edit contradiction always be annoying, a page missing even more.<br />
::: [[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 03:36, 5 June 2021 (UTC)<br />
<br />
::::In fact, this cannot be done because there is no way to know if anyone is editing. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:20, 5 June 2021 (UTC)<br />
<br />
== How to change packaging policies ==<br />
<br />
I recently made a note about the [[Talk:Wine package guidelines|Wine Package Guidelines talk page]] because I want to modify them slightly. I'm new to editing here, so I was wondering if there was a proper procedure for doing this. Do I simply take initiative and watch for if people complain?<br />
<br />
[[User:VinceUB|VinceUB]] ([[User talk:VinceUB|talk]]) 07:42, 5 August 2021 (UTC)<br />
<br />
== Long, cluttered and hard to maintain pages ==<br />
<br />
Unfortunately there are some pages on here which are hard to maintain because:<br />
* It is hard to validate the information without the specific hardware or software (which tends to be proprietary and may cost a lot)<br />
* No one knows if this still applies since the information may be ancient and the above still applies<br />
* There is so much content that transformed the page into something that is not feasible to maintain.<br />
<br />
These are pages where lots of users contributed their individual solutions to and this basically spiralled out of control. The worst pages in this category are:<br />
<br />
* [[Mac]]<br />
* [[Steam/Game-specific troubleshooting]]<br />
* Some laptop vendor pages, but this might be a different although vaguely similar topic. These have grown into spreadsheets and some are pretty bad.<br />
** [[Laptop/Acer]] is by far the worst.<br />
<br />
Other pages which are not as bad yet but should be monitored:<br />
<br />
* [[PCI passthrough via OVMF/Examples]] - was pruned recently<br />
* Laptop vendor pages (e.g [[Laptop/Lenovo]]) - mentioned in [[Category talk:Hardware]], part of a bigger problem<br />
* [[Dotfiles]]<br />
<br />
Both lists are unfortunately yet incomplete I suspect.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 01:23, 10 August 2021 (UTC)<br />
<br />
:The same applies to almost all troubleshooting sections and pages: [[Network configuration/Wireless#Troubleshooting drivers and firmware]], [[Bluetooth#Troubleshooting]], [[PulseAudio/Troubleshooting]], [[Firefox#Troubleshooting]], [[NVIDIA/Troubleshooting]] etc. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:56, 10 August 2021 (UTC)<br />
<br />
::At least for troubleshooting sections, [[Help:Style#"Troubleshooting" section]] says to link the bug or create a bug report if there isn't any. There's nothing we can do for sections that don't include any bug links. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:50, 10 August 2021 (UTC)<br />
<br />
== User menu for logged out users ==<br />
<br />
ArchWiki is now using the [[mw:Reading/Web/Desktop Improvements|new Vector skin]] [https://github.com/archlinux/archwiki/commit/5b43f15fb1f079e8a20ae4be8f3581a62b4fb5be by default]. That includes the [[mw:Reading/Web/Desktop Improvements/Features/User menu|user menu]].<br />
<br />
For logged out users, the user menu shows "Pages for logged out editors ([[Help:Introduction|learn more]])".<br />
<br />
The text can be customized in [[MediaWiki:vector-anon-user-menu-pages]] and the link title in [[MediaWiki:vector-anon-user-menu-pages-learn]]. The "learn more" link is hardcoded to [[Help:Introduction]] in MediaWiki 1.37, but it will use [[MediaWiki:vector-intro-page]] in some future release (see [[phab:T290813]]). There's also [[MediaWiki:vector-anon-user-menu-pages-label]], but I'm not sure where that is shown.<br />
<br />
So now we should decide what to do with these:<br />
<br />
* [[MediaWiki:vector-anon-user-menu-pages]]<br />
* [[MediaWiki:vector-anon-user-menu-pages-learn]]<br />
* [[MediaWiki:vector-anon-user-menu-pages-label]]<br />
* [[Help:Introduction]]<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:59, 21 December 2021 (UTC)<br />
<br />
:[[Help:Introduction]] could probably be redirected to [[{{ns:PROJECT}}:Contributing]]. ❄️❄️ [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:50, 26 December 2021 (UTC)<br />
<br />
== Syntax highlighting in code blocks ==<br />
<br />
MediaWiki since version 1.21 has the [https://www.mediawiki.org/wiki/Extension:SyntaxHighlight SyntaxHighlight] extension bundled. It adds the '''<nowiki><syntaxhighlight></nowiki>''' block, which lets editors add code blocks with syntax highlighting in specified language for easier readibility. As ArchWiki is a highly technical wiki, with configuration file and script snippets sprinkled everywhere, I was surprised to find this wasn't enabled yet.<br />
<br />
Is there a specific reason for this omission? If not, I'd happily welcome this addition to the wiki. -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 12:39, 15 February 2022 (UTC)<br />
<br />
:I wouldn't say there's a "specific reason for this omission". It simply was never enabled. Even if we do get it enabled, we would not want it to be used directly in pages, only through templates. I think it should be possible to adjust [[Template:bc]] and [[Template:hc]] to add an additional parameter to specify syntax highlighting language. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:36, 17 February 2022 (UTC)<br />
<br />
::That sounds reasonable, I understand that the parameter would be directly passed to the tag and would have to be one from the list of languages that '''SyntaxHighlight''' supports. Assuming that approach, I looked at the extension's parameters to check which ones also would be useful to expose via template on ArchWiki. So:<br />
::* '''lang''' - specifies lexer to use for highlighting, e.g. ''python, cfg, pacmanconf'' or one of [https://pygments.org/docs/lexers/ many others]. Would be useful in '''<nowiki>{{bc}}</nowiki>''', '''<nowiki>{{hc}}</nowiki>''', possibly even '''<nowiki>{{ic}}</nowiki>''' (for e.g. shell one-liners, using ''shell-session'' lexer so the '''#''' prompt is correctly interpreted)<br />
::* '''highlight''' - highlights specified line(s), e.g. ''3-5, 7''. I can see this being useful in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>''' for e.g. showing context of a config file section while highlighting the important/modified lines. <br />
::* '''line''' and '''start''' parameters enable showing line numbers and choose the start of the shown numeration, respectively. I don't see it being particularly useful on ArchWiki, especially since the '''highlight''' parameter works fine without them. If one finds a plausible usecase, I guess they could be exposed in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>'''.<br />
::* '''class''', '''style''' and '''inline''' parameters control style and are already covered by the existing templates, so no need to consider them (except maybe when modifying the templates' code).<br />
::I wanted to be helpful and try my hand at drafting what the new template code could look like. However, I can't tell whether the '''<nowiki><pre></nowiki>''' hack used in '''<nowiki>{{bc}}</nowiki>''' and '''<nowiki>{{hc}}</nowiki>''' will still be needed with the extension enabled without trying it out. If not, this change would certainly make these templates' code easier to read and understand. -- [[User:Zaroth|Zaroth]] ([[User talk:Zaroth|talk]]) 10:39, 17 February 2022 (UTC)<br />
<br />
:::I don't think we should care about any parameter other than {{ic|lang}}.<br />
:::Also adding {{ic|wfLoadExtension( 'SyntaxHighlight_GeSHi' );}} to [https://github.com/archlinux/archwiki/blob/master/LocalSettings.archlinux.org.php LocalSettings.archlinux.org.php] will not be enough. The extension requires <s>{{Pkg|python-pygments}}</s> {{Pkg|python}}. ''I think'', it would need to be added to https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/tasks/main.yml#L20.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:26, 21 February 2022 (UTC)<br />
<br />
::::Actually, I was wrong. pygmentize is shipped in {{ic|extensions/SyntaxHighlight_GeSHi/pygments/pygmentize}}, so only {{Pkg|python}} is needed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:34, 21 February 2022 (UTC)<br />
<br />
== Adding code of conduct and terms of service links in the footer ==<br />
<br />
According to [[mw:Manual:Footer#Add links to the footer]] additional footer links can be created by editing {{ic|LocalSettings.php}}. I think it would be a good idea to links to the [[archlinux-service-agreements:code-of-conduct|code of conduct]] and [[archlinux-service-agreements:terms-of-service|terms of service]].<br />
<br />
I've prepared https://github.com/archlinux/archwiki/pull/53. Thoughts?<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:06, 21 February 2022 (UTC)<br />
<br />
== Syntax highlighting for JavaScript and CSS pages ==<br />
<br />
I would like to enable [[mw:Extension:CodeEditor|Extension:CodeEditor]] in ArchWiki. As it's wiki page says, it provides syntax highlighting for JavaScript, CSS and Lua. Although its use is limited, it could be useful when editing [[MediaWiki:Common.css]], [[MediaWiki:Common.js]] and [[Special:AbuseFilter|abuse filters]].<br />
<br />
As usual: 👍/subscribe/approve https://github.com/archlinux/archwiki/pull/54.<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:36, 21 February 2022 (UTC)<br />
<br />
:Wait, abuse filters are in Lua (or Javascript)? I've never noticed... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:10, 25 February 2022 (UTC)<br />
<br />
::[[mw:Extension:AbuseFilter/Rules format]] says ''The rules are a custom language. They are formatted similar to conditionals in a C/Java/Perl-like language''. It looks like [https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/master/modules/mode-abusefilter.js] provides the necessary integration with CodeEditor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:33, 26 February 2022 (UTC)<br />
<br />
== Semi-protect [[Arch Linux on a VPS]] ==<br />
<br />
As you might have seen, there were some problems with that page because it attracted people using this page as an ad board. It was the very first edit for most of the now banned users, so I hereby request that this page should be semi-protected to deter others with the same interests.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:36, 26 February 2022 (UTC)<br />
<br />
:Well, that page is essentially an ad board. IMHO there's no difference if editors add their favorite VPS there or the providers add themselves. The end result is the same. (Semi-)protecting it will just lead to users starting discussions in the talk page, asking to list a provider and I'm sure no one is actually interested in curating any lists on that page. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:41, 26 February 2022 (UTC)<br />
<br />
::Could it be restricted only to users with at least a few days/weeks old account or a few non-reverted edits ? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 19:17, 26 February 2022 (UTC)<br />
<br />
:::What's what "{{int:restriction-level-autoconfirmed}}"[https://github.com/archlinux/archwiki/blob/master/LocalSettings.archlinux.org.php#L285-L288] would do.<br />
:::I'm just saying that users will not just give up after not being able to make the edit themselves. They'll start a discussion about it in the talk page.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:54, 27 February 2022 (UTC)<br />
:::: At least forcing a discussion on the Talk page will require *some* moderation of the proposed entry, ie., reduce the likelihood of "This is the bestest image"--type edits. Either way, given this is a potential revenue stream for people, there is bound to be attempted abuse. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 17:15, 1 March 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Main_page&diff=718363Talk:Main page2022-02-14T06:22:52Z<p>Jasonwryan: Reverted edits by Mattrobby (talk) to last revision by Lahwaacz</p>
<hr />
<div>== Instructions on checking the user name ==<br />
<br />
The issue with [[Special:ListUsers]] is that it displays results even when the name in question is not available. For example, [https://wiki.archlinux.org/index.php?title=Special%3AListUsers&username=foobarthisnamedoesnotexist&group=&limit=2000 foobarthisnamedoesnotexist] still lists all user names starting with ''foo''. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:36, 26 May 2016 (UTC)<br />
<br />
:You can go to [[User:Foobarthisnamedoesnotexist]] instead, but no idea how to describe the 4 possible cases (account does not exist, account exists but the page doesn't, the page exists but account doesn't, both things exist). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:49, 26 May 2016 (UTC)<br />
<br />
::There's also [https://wiki.archlinux.org/index.php?title=Special%3APrefixIndex&namespace=2&hideredirects=1 Special:PrefixIndex], e.g. [https://wiki.archlinux.org/index.php?title=Special%3APrefixIndex&prefix=foobarthisnamedoesnotexist&namespace=2&hideredirects=1 foobarthisnamedoesnotexist], but the downside is that it also shows subpages. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:39, 27 May 2016 (UTC)<br />
<br />
:::Well, it's a little like letting new users play dice to find a free name first, but still useful to work around the issue, e.g. <br />
::::"In order to create an account, [https://wiki.archlinux.org/index.php?title=Special%3APrefixIndex&namespace=2&hideredirects=1 check] if your desired user name or a suitable [[Special:ListUsers|alternative]] is available." <br />
:::Actually, what should be the primary place to inform about how to register? The main page? Then, we should crosslink it from [[ArchWiki:Contributing#Improving]] and maybe even add a redirect for "account registration". --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:14, 27 May 2016 (UTC)<br />
<br />
::::The PrefixIndex shows existing user pages, not user accounts. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:22, 27 May 2016 (UTC)<br />
<br />
:::::Ok, yes, it's no help then. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:38, 27 May 2016 (UTC)<br />
<br />
== Interlanguage links need to be sorted alphabetically ==<br />
<br />
See [[Help:Style#Interlanguage links]]. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 15:14, 13 July 2020 (UTC)<br />
<br />
:[https://wiki.archlinux.org/index.php?title=Main_page&type=revision&diff=625113&oldid=613560 Solved]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 23:19, 13 July 2020 (UTC)<br />
<br />
::@Kynikos Can you give me the Bots user group? I want to automatically update interlanguage links in the translated version of the [[Main page]]. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 02:45, 14 July 2020 (UTC)<br />
<br />
:::That'd be for a separate bot account, if you meant to save several dozens or hundreds of edits; there's no problem if you sync the interlanguage links in Main-page translations with your main account. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 23:00, 14 July 2020 (UTC)<br />
<br />
::::I mean this, please give my main user Bots user group, otherwise 30 seconds is too slow. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 01:10, 15 July 2020 (UTC)<br />
<br />
:::::Ooh, ok, the 30-second delay is a deliberate limitation [https://github.com/kynikos/wiki-monkey/wiki/Usage#bot-interface built into] Wiki Monkey for non-bot users to discourage using it for extensive undiscussed changes.<br />
:::::If you don't want or can't have continuous access to internet to leave the bot perform the edits while you do something else (which is how Wiki Monkey's bot was intended to be used by regular users), I guess I can put your User in the Bots group temporarily, if you give me a time window when you intend to run the bot.<br />
:::::I think Lahwaacz also periodically runs wiki-script's [https://github.com/lahwaacz/wiki-scripts/blob/master/interlanguage.py interlanguage.py] script, but I'm not sure if it can be restricted to only a particular title.<br />
:::::We can also discuss supporting a [[User:Blackteahamburger.bot]] with bot rights, if you're interested in running automated maintenance jobs more regularly.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 23:43, 15 July 2020 (UTC)<br />
<br />
::::::Lahwaacz said that the bot cannot parse the magic word at the top of the page [https://wiki.archlinux.org/index.php?title=Talk:Main_page&oldid=624327#Update_the_interlanguage_link_for_the_localized_version_of_this_page], so the bot cannot work. I can use SimpleReplace plugin to update interlanguage links.<br />
<br />
::::::I am really interested in running automatic maintenance tasks, but I don’t know how to do it :( <br />
<br />
::::::-- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 01:29, 16 July 2020 (UTC)<br />
<br />
:::::::Did you like any of the options that I proposed above? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:43, 18 July 2020 (UTC)<br />
<br />
:::::::I don't really like using SimpleReplace extensively, because it is too error-prone (parsing the MediaWiki markup properly with regular expressions is extremely hard or even impossible). But I think the [https://github.com/kynikos/wiki-monkey/wiki/Plugin%3A-SynchronizeInterlanguageLinks SynchronizeInterlanguageLinks] plugin would actually work here, I'm only not sure if it would give the same results as wiki-scripts for any page. [https://github.com/lahwaacz/wiki-scripts/blob/master/interlanguage.py interlanguage.py] from wiki-scripts does not work here because of [https://github.com/earwig/mwparserfromhell/issues/10 mwparserfromhell's issue] so the ultimate solution would be fixing that. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 18 July 2020 (UTC)<br />
<br />
::::::::The [https://github.com/kynikos/wiki-monkey/wiki/Plugin%3A-SynchronizeInterlanguageLinks SynchronizeInterlanguageLinks] plugin sometimes does not completely update the interlanguage links [https://wiki.archlinux.org/index.php?title=Main_page_(Hrvatski)&diff=624349&oldid=624305], so it is better to fix the problem. (SimpleReplace plugin does make mistakes sometimes...) -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 01:09, 19 July 2020 (UTC)<br />
<br />
:::::::::After so many years, it would be easier to rewrite [https://github.com/kynikos/wiki-monkey/wiki/Plugin%3A-SynchronizeInterlanguageLinks SynchronizeInterlanguageLinks] from scratch than fixing it... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:29, 19 July 2020 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Samba&diff=716128Samba2022-02-06T02:30:30Z<p>Jasonwryan: /* Troubleshooting */ Added Section - IOS Files can no longer copy-to Samba share on Archlinux 46 beginning with IOS 14.</p>
<hr />
<div>[[Category:Network sharing]]<br />
[[Category:Servers]]<br />
[[de:Samba]]<br />
[[fr:Samba]]<br />
[[ja:Samba]]<br />
[[ru:Samba]]<br />
[[zh-hans:Samba]]<br />
[[zh-hant:Samba]]<br />
{{Related articles start}}<br />
{{Related|Active Directory Integration}}<br />
{{Related|Samba/Active Directory domain controller}}<br />
{{Related|NFS}}<br />
{{Related articles end}}<br />
[https://www.samba.org/ Samba] is the standard Windows interoperability suite of programs for Linux and Unix. Since 1992, Samba has provided secure, stable and fast file and print services for all clients using the [[wikipedia:Server_Message_Block|SMB/CIFS]] protocol, such as all versions of DOS and Windows, OS/2, Linux and many others.<br />
<br />
To share files through Samba, see [[#Server]] section; to access files shared through Samba on other machines, please see [[#Client]] section.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{Pkg|samba}} package.<br />
<br />
Samba is configured in the {{ic|/etc/samba/smb.conf}} configuration file, which is extensively documented in {{man|5|smb.conf}}.<br />
<br />
Because the {{Pkg|samba}} package does not provide this file, one needs to create it '''before''' starting {{ic|smb.service}}.<br />
<br />
A documented example as in {{ic|smb.conf.default}} from the [https://git.samba.org/samba.git/?p=samba.git;a=blob_plain;f=examples/smb.conf.default;hb=HEAD Samba git repository] may be used to setup {{ic|/etc/samba/smb.conf}}. <br />
<br />
{{Note|<br />
* The default configuration sets {{ic|log file}} to a non-writable location, which will cause errors - apply one of the following workarounds:<br />
** Change the log file location to a writable path: {{ic|1=log file = /var/log/samba/%m.log}}<br />
** Change logging to a non-file backend solution: {{ic|1=logging = syslog}} with {{ic|1=syslog only = yes}}, or use {{ic|1=logging = systemd}}<br />
* If required; the {{ic|workgroup}} specified in the {{ic|[global]}} section has to match the Windows workgroup (default {{ic|WORKGROUP}}).<br />
}}<br />
<br />
{{Tip|Whenever you modify the {{ic|smb.conf}} file, run the {{man|1|testparm}} command to check for syntactic errors.}}<br />
<br />
==== Enabling and starting services ====<br />
<br />
To provide basic file sharing through SMB, [[enable/start]] {{ic|smb.service}}. See {{man|8|smbd}} for details.<br />
<br />
If you want to make your server accessible via NetBIOS host name, set the desired name in the {{ic|netbios name}} option in {{ic|smb.conf}} and [[enable/start]] {{ic|nmb.service}}. See {{man|8|nmbd}} for details.<br />
<br />
{{Note|{{ic|nmb.service}} is not required. However, it is needed to access Samba servers by hostname (e.g. {{ic|smb://hostname/}}) for some hosts. If your network is only composed of machines running Windows 10 or later, consider [[#Windows 1709 or up does not discover the samba server in Network view|installing a WSD daemon as well]] for your server to appear in the "Network" view.}}<br />
<br />
==== Configure firewall ====<br />
<br />
If you are using a [[firewall]], do not forget to open required ports (usually 137-139 + 445). For a complete list, see [https://www.samba.org/~tpot/articles/firewall.html Samba port usage].<br />
<br />
===== UFW Rule =====<br />
<br />
A [[Ufw]] App Profile for SMB/CIFS is included by default with the default installation of UFW in {{ic|ufw-fileserver}}.<br />
<br />
Allow Samba by running {{ic|ufw allow CIFS}} as root.<br />
<br />
If you deleted the profile, create/edit {{ic|/etc/ufw/applications.d/samba}} and add the following content:<br />
<br />
[Samba]<br />
title=LanManager-like file and printer server for Unix<br />
description=The Samba software suite is a collection of programs that implements the SMB/CIFS protocol for unix systems, allowing you to serve files and printers to Windows, NT, OS/2 and DOS clients. This protocol is sometimes also referred to as the LanManager or NetBIOS protocol.<br />
ports=137,138/udp|139,445/tcp<br />
<br />
Then load the profile into UFW run {{ic|ufw app update Samba}} as root.<br />
<br />
Then finally, allow Samba by running {{ic|ufw allow Samba}} as root.<br />
<br />
===== firewalld service =====<br />
<br />
To configure [[firewalld]] to allow Samba in the '''home''' zone, run:<br />
<br />
# firewall-cmd --permanent --add-service={samba,samba-client,samba-dc} --zone=home<br />
<br />
The three service listed are:<br />
<br />
* {{ic|samba}}: for sharing files with others.<br />
* {{ic|samba-client}}: to browse shares on other machines on the network.<br />
* {{ic|samba-dc}}: for [[Samba/Active Directory domain controller]].<br />
<br />
{{ic|--permanent}} ensures the changes remain after {{ic|firewalld.service}} is [[restart]]ed.<br />
<br />
=== Usage ===<br />
<br />
==== User management ====<br />
<br />
The following section describes creating a local (tdbsam) database of Samba users. For user authentication and other purposes, Samba can also be bound to an Active Directory domain, can itself serve as an Active Directory domain controller, or can be used with an LDAP server.<br />
<br />
===== Adding a user =====<br />
<br />
Samba requires a Linux user account - you may use an existing user account or create a [[Users and groups#User management|new one]].<br />
<br />
{{Note|The [[user]]/[[user group]] ''nobody'' should already exist on the system, it's used as the default {{ic|guest account}} and may be used for shares containing {{ic|1=guest ok = yes}}, thus preventing the need of user login on that share.}}<br />
<br />
Although the user name is shared with Linux system, Samba uses a password separate from that of the Linux user accounts. Replace {{ic|samba_user}} with the chosen Samba user account:<br />
<br />
# smbpasswd -a ''samba_user''<br />
<br />
Depending on the [https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#SERVERROLE server role], existing [[File permissions and attributes]] may need to be altered for the Samba user account.<br />
<br />
If you want the new user only to be allowed to remotely access the file server shares through Samba, you can restrict other login options:<br />
<br />
* disabling shell - {{ic|usermod --shell /usr/bin/nologin --lock ''samba_user''}}<br />
* disabling SSH logons - edit {{ic|/etc/ssh/sshd_config}}, change option {{ic|AllowUsers}}<br />
<br />
Also see [[Security]] for hardening your system.<br />
<br />
===== Listing users =====<br />
<br />
Samba users can be listed using the {{man|8|pdbedit}} command:<br />
<br />
# pdbedit -L -v<br />
<br />
===== Changing user password =====<br />
<br />
To change a user password, use {{ic|smbpasswd}}:<br />
<br />
# smbpasswd ''samba_user''<br />
<br />
==== Creating an anonymous share ====<br />
<br />
1. Create a Linux user which anonymous Samba users will be mapped to.<br />
<br />
# useradd guest -s /bin/nologin<br />
<br />
{{Note|The username can be any valid Linux username, not just "guest". This user does not need to be a Samba user.}}<br />
<br />
2. Add the following to {{ic|/etc/samba/smb.conf}}:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
...<br />
[global]<br />
security = user<br />
map to guest = bad user<br />
guest account = guest<br />
<br />
[guest]<br />
comment = guest<br />
path = /tmp/<br />
public = yes<br />
only guest = yes<br />
writable = yes<br />
printable = no<br />
}}<br />
<br />
Any anonymous users will now be mapped to the Linux user {{ic|guest}} and have the ability to access any directories defined in {{ic|guest.path}}, for example, {{ic|/tmp/}} in the configuration above.<br />
<br />
Make sure shares have been properly defined as per the ''Share Definitions'' section of [https://git.samba.org/samba.git/?p=samba.git;a=blob_plain;f=examples/smb.conf.default;hb=HEAD smb.conf.default].<br />
<br />
=== Enable symlink following ===<br />
<br />
{{Warning|Enabling the {{ic|follow symlinks}} option can be a security risk.}}<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
...<br />
[global]<br />
follow symlinks = yes<br />
wide links = yes<br />
unix extensions = no<br />
}}<br />
<br />
Then, [[restart]] {{ic|smb.service}}.<br />
<br />
{{Note|When using [[AppArmor]], if the symlink points to a directory outside the user's home or the [[#Enable Usershares|usershare]] directory, then you need to [[#Permission issues on AppArmor|modify the AppArmor profile permissions]].}}<br />
<br />
=== Advanced Configuration ===<br />
<br />
==== Enable Usershares ====<br />
<br />
{{Note|This is an optional feature. Skip this section if you do not need it.}}<br />
<br />
[https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html Usershares]<br />
is a feature that gives non-root users the capability to add, modify, and delete their own share definitions. <br />
<br />
# Create a directory for usershares: {{bc|# mkdir /var/lib/samba/usershares}}<br />
# Create a [[user group]]: {{bc|# groupadd -r sambashare}}<br />
# Change the owner of the directory to {{ic|root}} and the group to {{ic|sambashare}}: {{bc|# chown root:sambashare /var/lib/samba/usershares}}<br />
# Change the permissions of the {{ic|usershares}} directory so that users in the group {{ic|sambashare}} can create files. This command also sets [[Wikipedia:Sticky bit|sticky bit]], which is important to prevent users from deleting usershares of other users: {{bc|# chmod 1770 /var/lib/samba/usershares}}<br />
<br />
Set the following parameters in the {{ic|smb.conf}} configuration file: <br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
usershare path = /var/lib/samba/usershares<br />
usershare max shares = 100<br />
usershare allow guests = yes<br />
usershare owner only = yes<br />
}}<br />
<br />
Add the user to the ''sambashare'' group. Replace {{ic|''your_username''}} with the name of your user:<br />
<br />
# gpasswd sambashare -a ''your_username''<br />
<br />
[[Restart]] {{ic|smb.service}} and {{ic|nmb.service}} services.<br />
<br />
Log out and log back in.<br />
<br />
If you want to share paths inside your home directory you must make it accessible for the group ''others''.<br />
<br />
In the GUI, you can use [[Thunar]] or [[Dolphin]] - right click on any directory and share it on the network. <br />
<br />
In the CLI, use one of the following commands, replacing italic ''sharename'', ''user'', ... :<br />
<br />
# net usershare add ''sharename'' ''abspath'' [''comment''] [''user'':{R|D|F}] [guest_ok={y|n}]<br />
# net usershare delete ''sharename''<br />
# net usershare list ''wildcard-sharename''<br />
# net usershare info ''wildcard-sharename''<br />
<br />
==== Set and forcing permissions ====<br />
<br />
Permissions may be applied to both the server and shares:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
;inherit owner = unix only ; Inherit ownership of the parent directory for new files and directories<br />
;inherit permissions = yes ; Inherit permissions of the parent directory for new files and directories<br />
create mask = 0664<br />
directory mask = 2755<br />
force create mode = 0644<br />
force directory mode = 2755<br />
...<br />
<br />
[media]<br />
comment = Media share accessible by ''greg'' and ''pcusers''<br />
path = ''/path/to/media''<br />
valid users = ''greg @pcusers''<br />
force group = ''+pcusers''<br />
public = no<br />
writable = yes<br />
create mask = 0664<br />
directory mask = 2775<br />
force create mode = 0664<br />
force directory mode = 2775<br />
<br />
[public]<br />
comment = Public share where ''archie'' has write access<br />
path = ''/path/to/public''<br />
public = yes<br />
read only = yes<br />
write list = ''archie''<br />
printable = no<br />
<br />
[guests]<br />
comment = Allow all users to read/write<br />
path = ''/path/to/guests''<br />
public = yes<br />
only guest = yes<br />
writable = yes<br />
printable = no<br />
}}<br />
<br />
See {{man|5|smb.conf}} for a full overview of possible permission flags and settings.<br />
<br />
==== Restrict protocols for better security ====<br />
<br />
{{Warning|By default, Samba versions prior to 4.11 allow connections using the outdated and insecure SMB1 protocol. When using one these Samba versions, it is highly recommended to set {{ic|1=server min protocol = SMB2_02}} to protect yourself from ransomware attacks. In Samba 4.11 and newer, SMB2 is the default min protocol, so no changes are required there.}}<br />
<br />
[[Append]] {{ic|server min protocol}} and {{ic|server max protocol}} in {{ic|/etc/samba/smb.conf}} to force usage of a minimum and maximum protocol:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
server min protocol = SMB2_02<br />
; server max protocol = SMB3<br />
}}<br />
<br />
See {{ic|server max protocol}} in {{man|5|smb.conf}} for an overview of supported protocols.<br />
<br />
For compatibility with older clients and/or servers, you might need to set {{ic|1=client min protocol = CORE}} or {{ic|1=server min protocol = CORE}}, but please note that this makes you vulnerable to exploits in SMB1 including ransomware attacks.<br />
<br />
{{Tip|Use {{ic|1=server min protocol = SMB3_00}} when clients should only connect using the latest SMB3 protocol, e.g. on clients running Windows 8 and later.}}<br />
<br />
[[#Manual mounting|Clients]] using {{ic|mount.cifs}} may need to specify the correct {{ic|1=vers=*}}, e.g.:<br />
<br />
# mount -t cifs //''SERVER''/''sharename'' /mnt/''mountpoint'' -o username=''username'',password=''password'',iocharset=''utf8'',vers=''3.1.1''<br />
<br />
See {{man|8|mount.cifs}} for more information.<br />
<br />
==== Use native SMB transport encryption ====<br />
<br />
Native SMB transport encryption is available in SMB version 3.0 or newer. Clients supporting this type of encryption include Windows 8 and newer, Windows server 2012 and newer, and smbclient of Samba 4.1 and newer.<br />
<br />
To use native SMB transport encryption by default, set the {{ic|server smb encrypt}} parameter globally and/or by share. Possible values are {{ic|off}}, {{ic|enabled}} (default value), {{ic|desired}}, or {{ic|required}}:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
server smb encrypt = desired<br />
}}<br />
<br />
To configure encryption for on the client side, use the option {{ic|client smb encrypt}}.<br />
<br />
See {{man|5|smb.conf}} for more information, especially the paragraphs ''Effects for SMB1'' and ''Effects for SMB2''.<br />
<br />
{{Tip|When [[#Manual mounting|mounting]] a share, specify the {{ic|seal}} mount option to force usage of encryption.}}<br />
<br />
==== Disable printer sharing ====<br />
<br />
By default Samba shares printers configured using [[CUPS]].<br />
<br />
If you do not want printers to be shared, use the following settings:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
load printers = no<br />
printing = bsd<br />
printcap name = /dev/null<br />
disable spoolss = yes<br />
show add printer wizard = no<br />
}}<br />
<br />
==== Block certain file extensions on Samba share ====<br />
<br />
{{Note|Setting this parameter will affect the performance of Samba, as it will be forced to check all files and directories for a match as they are scanned.}}<br />
<br />
Samba offers an option to block files with certain patterns, like file extensions. This option can be used to prevent dissemination of viruses or to dissuade users from wasting space with certain files. More information about this option can be found in {{man|5|smb.conf}}.<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
...<br />
[myshare]<br />
comment = Private<br />
path = /mnt/data<br />
read only = no<br />
veto files = /*.exe/*.com/*.dll/*.bat/*.vbs/*.tmp/*.mp3/*.avi/*.mp4/*.wmv/*.wma/<br />
}}<br />
<br />
==== Improve throughput ====<br />
<br />
{{Warning|Beware this may lead to corruption/connection issues and potentially cripple your TCP/IP stack.}}<br />
<br />
The default settings should be sufficient for most users. However setting the 'socket options' correct can improve performance, but getting them wrong can degrade it by just as much. Test the effect before making any large changes.<br />
<br />
Read the {{man|5|smb.conf}} man page before applying any of the options listed below.<br />
<br />
The following settings should be [[Append|appended]] to the {{ic|[global]}} section of {{ic|/etc/samba/smb.conf}}.<br />
<br />
SMB3 multi-channel may improve performance, however it may result in data corruption under some rare conditions. Future releases may improve this situation:<br />
<br />
server multi channel support = yes<br />
<br />
Setting a deadtime is useful to stop a server's resources from being exhausted by a large number of inactive connections:<br />
<br />
deadtime = 30<br />
<br />
The usage of sendfile may make more efficient use of the system CPU's and cause Samba to be faster:<br />
<br />
use sendfile = yes<br />
<br />
Setting min receivefile size allows zero-copy writes directly from network socket buffers into the filesystem buffer cache (if available). It may improve performance but user testing is recommended:<br />
<br />
min receivefile size = 16384<br />
<br />
Reading/writing files asynchronously may improve performance instead of using synchronous writes:<br />
<br />
aio read size = 1<br />
aio write size = 1<br />
<br />
Increasing the receive/send buffers size and socket optimize flags might be useful to improve throughput. It is recommended to test each flag separately as it may cause issues on some networks:<br />
<br />
socket options = IPTOS_LOWDELAY TCP_NODELAY IPTOS_THROUGHPUT SO_RCVBUF=131072 SO_SNDBUF=131072<br />
<br />
{{Note|Network-interface adjustments may be needed for some options to work, see [[Sysctl#Networking]].}}<br />
<br />
==== Enable access for old clients/devices ====<br />
<br />
Latest versions of Samba no longer offer older authentication methods and protocols which are still used by some older clients (IP cameras, etc). These devices usually require Samba server to allow NTMLv1 authentication and NT1 version of the protocol, known as CIFS. For these devices to work with latest Samba, you need to add these two configuration parameters into {{ic|[global]}} section:<br />
<br />
server min protocol = NT1<br />
ntlm auth = yes<br />
<br />
Anonymous/guest access to a share requires just the first parameter. If the old device will access with username and password, you also need the add the second line too.<br />
<br />
==== Enable Spotlight searching ====<br />
<br />
Spotlight allows supporting clients (e.g. MacOS Finder) to quickly search shared files.<br />
<br />
Install and start/enable [[OpenSearch]]. Install {{aur|fs2es-indexer}}, configure the directories you want to index in {{ic|/etc/fs2es-indexer/config.yml}}, and start/enable {{ic|fs2es-indexer.service}} for periodic indexing.<br />
<br />
Edit {{ic|smb.conf}} as described in the [https://wiki.samba.org/index.php/Spotlight_with_Elasticsearch_Backend#Samba Samba wiki] to enable Spotlight per share, and restart {{ic|smb.service}} to apply the changes.<br />
<br />
== Client ==<br />
<br />
Install {{Pkg|smbclient}} for an {{ic|ftp}}-like command line interface. See {{man|1|smbclient}} for commonly used commands.<br />
<br />
For a lightweight alternative (without support for listing public shares, etc.), [[install]] {{Pkg|cifs-utils}} that provides {{ic|/usr/bin/mount.cifs}}.<br />
<br />
Depending on the [[desktop environment]], GUI methods may be available. See [[#File manager configuration]] for use with a file manager.<br />
<br />
{{Note|<br />
* {{Pkg|smbclient}} requires a {{ic|/etc/samba/smb.conf}} file (see [[#Installation]]), which you can create as an empty file using the {{ic|touch}} utility.<br />
* After installing {{Pkg|cifs-utils}} or {{Pkg|smbclient}}, load the {{ic|cifs}} [[kernel module]] or reboot to prevent mount fails.<br />
}}<br />
<br />
=== List public shares ===<br />
<br />
The following command lists public shares on a server:<br />
<br />
$ smbclient -L ''hostname'' -U%<br />
<br />
Alternatively, running {{ic|$ smbtree -N}} will show a tree diagram of all the shares. It uses broadcast queries and is therefore not advisable on a network with a lot of computers, but can be helpful for diagnosing if you have the correct sharename. The {{ic|-N}} ({{ic|-no-pass}}) option suppresses the password prompt.<br />
<br />
=== NetBIOS/WINS host names ===<br />
<br />
Samba clients handle NetBIOS host names automatically by default (the behavior is controlled by the {{ic|name resolve order}} option in {{ic|smb.conf}}). Other programs (including {{ic|mount.cifs}}) typically use [[Name Service Switch]], which does not handle NetBIOS by default.<br />
<br />
The {{Pkg|smbclient}} package provides a libnss driver to resolve NetBIOS host names. To use it, [[install]] it along with the {{Pkg|samba}} package (which provides the ''winbindd'' daemon), [[start/enable]] {{ic|winbind.service}} and add {{ic|wins}} to the {{ic|hosts}} line in {{man|5|nsswitch.conf}}:<br />
<br />
{{hc|/etc/nsswitch.conf|2=<br />
...<br />
hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns '''wins'''<br />
...<br />
}}<br />
<br />
{{Note|Due to a current mistake in {{ic|winbind.service}}, you may have to modify the unit file as described in this [https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1789097 bug-report]}}<br />
<br />
Now, during host resolving (e.g. when using {{ic|mount.cifs}} or just {{ic|ping ''netbios-name''}}), ''winbindd'' will resolve the host name by sending queries using NetBIOS Name Service (NBNS, also known as WINS) protocol.<br />
<br />
By default it sends a broadcast query to your local network. If you have a WINS server, you can add {{ic|1=wins server = ''wins-server-ip''}} to {{ic|smb.conf}} and [[restart]] {{ic|winbind.service}}, then ''winbindd'' and other Samba clients will send unicast queries to the specified IP.<br />
<br />
If you want to resolve your local host name (specified in the {{ic|netbios name}} option in {{ic|smb.conf}}), [[start/enable]] {{ic|nmb.service}}, which will handle incoming queries.<br />
<br />
You can test WINS resolution with {{ic|nmblookup}}. By default it sends broadcast queries to your local network regardless of the {{ic|wins server}} option.<br />
<br />
Note that WINS resolution requires incoming traffic originating from port 137.<br />
<br />
==== Disable NetBIOS/WINS support ====<br />
<br />
When not using NetBIOS/WINS host name resolution, it may be preferred to disable this protocol:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
disable netbios = yes<br />
dns proxy = no<br />
}}<br />
<br />
Finally [[disable]]/[[stop]] {{ic|winbind.service}}.<br />
<br />
=== Manual mounting ===<br />
<br />
Create a mount point for the share:<br />
<br />
# mkdir /mnt/''mountpoint''<br />
<br />
Mount the share using {{ic|mount.cifs}} as {{ic|type}}. Not all the options listed below are needed or desirable:<br />
<br />
# mount -t cifs //''SERVER''/''sharename'' /mnt/''mountpoint'' -o username=''username'',password=''password'',workgroup=''workgroup'',iocharset=''utf8'',uid=''username'',gid=''group''<br />
<br />
The options {{ic|uid}} and {{ic|gid}} corresponds to the local (e.g. client) [[user]]/[[user group]] to have read/write access on the given path.<br />
<br />
{{Note|<br />
* If the {{ic|uid}} and {{ic|gid}} being used does not match the user of the server, the {{ic|forceuid}} and {{ic|forcegid}} options may be helpful. However note permissions assigned to a file when {{ic|forceuid}} or {{ic|forcegid}} are in effect may not reflect the the real (server) permissions. See the ''File And Directory Ownership And Permissions'' section in {{man|8|mount.cifs|FILE AND DIRECTORY OWNERSHIP AND PERMISSIONS}} for more information.<br />
* To allow users to mount it as long as the mount point resides in a directory controllable by the user; i.e. the user's home, append the {{ic|users}} mount option. The option is user'''s''' (plural). For other filesystem types handled by mount, this option is usually ''user''; sans the "'''s'''".<br />
* To mount a Windows share without authentication, use {{ic|1="username=*"}}.<br />
}}<br />
<br />
{{Warning|Using {{ic|uid}} and/or {{ic|gid}} as mount options may cause I/O errors, it is recommended to set/check correct [[File permissions and attributes]] instead.}}<br />
<br />
* {{ic|''SERVER''}} — The server name.<br />
* {{ic|''sharename''}} — The shared directory.<br />
* {{ic|''mountpoint''}} — The local directory where the share will be mounted.<br />
* {{ic|[-o ''options'']}} — See {{man|8|mount.cifs}} for more information.<br />
<br />
{{Note|<br />
* Abstain from using a trailing {{ic|/}}. {{ic|//''SERVER''/''sharename'''''/'''}} will not work.<br />
* If your mount does not work stable, stutters or freezes, try to enable different SMB protocol version with {{ic|1=vers=}} option. For example, {{ic|1=vers=2.0}} for Windows Vista mount.<br />
* If having timeouts on a mounted network share with cifs on a shutdown, see [[wpa_supplicant#Problem with mounted network shares (cifs) and shutdown]].<br />
}}<br />
<br />
==== Storing share passwords ====<br />
<br />
Storing passwords in a world readable file is not recommended. A safer method is to use a credentials file instead, e.g. inside {{ic|/etc/samba/credentials}}:<br />
<br />
{{hc|/etc/samba/credentials/share|2=<br />
username=''myuser''<br />
password=''mypass''<br />
}}<br />
<br />
For the mount command replace {{ic|1=username=myuser,password=mypass}} with {{ic|1=credentials=/etc/samba/credentials/share}}.<br />
<br />
The credential file should explicitly readable/writeable to root:<br />
<br />
# chown root:root /etc/samba/credentials<br />
# chmod 700 /etc/samba/credentials<br />
# chmod 600 /etc/samba/credentials/share<br />
<br />
=== Automatic mounting ===<br />
<br />
{{Note|You may need to [[enable]] {{ic|systemd-networkd-wait-online.service}} or {{ic| NetworkManager-wait-online.service}} (depending on your setup) to proper enable booting on start-up.}}<br />
<br />
==== Using NetworkManager and GIO/gvfs ====<br />
<br />
[[NetworkManager#Network services with NetworkManager dispatcher|NetworkManager]] can be configured to run a script on network status change. This script uses the ''gio'' command so that it mounts the Samba shares automatically, the same way your file manager does, as explained [[#File manager configuration|below]]. The script also safely unmounts the Samba shares before the relevant network connection is disabled by listening for the {{ic|pre-down}} and {{ic|vpn-pre-down}} events. Make the script is [[executable]] after creating it.<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/30-samba.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Find the connection UUID with "nmcli con show" in terminal.<br />
# All NetworkManager connection types are supported: wireless, VPN, wired...<br />
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"<br />
<br />
# The user the share will be mounted under<br />
USER="yourusername"<br />
# The path that appears in your file manager when you manually mount the share you want<br />
SMB_URL="smb://servername/share"<br />
<br />
# Get runtime user directory. If it does not exist, do nothing and just exit<br />
XDG_RUNTIME_DIR=$(loginctl show-user --property=RuntimePath --value "$USER") || exit 0<br />
<br />
if [ "$CONNECTION_UUID" = "$WANTED_CON_UUID" ]; then<br />
<br />
# Script parameter $1: NetworkManager connection name, not used<br />
# Script parameter $2: dispatched event<br />
<br />
case "$2" in<br />
"up")<br />
su $USER -c "DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus gio mount $SMB_URL"<br />
;;<br />
"pre-down"|"vpn-pre-down")<br />
su $USER -c "DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus gio mount -uf $SMB_URL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
Create a symlink inside {{ic|/etc/NetworkManager/dispatcher.d/pre-down}} to catch the {{ic|pre-down}} events:<br />
<br />
# ln -s /etc/NetworkManager/dispatcher.d/30-samba.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-samba.sh<br />
<br />
{{Note|Since this script uses the user bus, it will only work if the user has active sessions. This means that the share will not mount automatically after boot if the connection is established before you are logged in.}}<br />
<br />
==== As mount entry ====<br />
<br />
This is a simple example of a {{ic|cifs}} [[fstab|mount entry]] that requires authentication:<br />
<br />
{{hc|/etc/fstab|2=<br />
//''SERVER''/''sharename'' /mnt/''mountpoint'' cifs _netdev,nofail,username=''myuser'',password=''mypass'' 0 0<br />
}}<br />
<br />
{{Note|Spaces in sharename should be replaced by {{ic|\040}} (ASCII code for space in octal). For example, {{ic|//''SERVER''/share name}} on the command line should be {{ic|//''SERVER''/share\040name}} in {{ic|/etc/fstab}}.}}<br />
<br />
{{Tip|Use {{ic|x-systemd.automount}} if you want them to be mounted only upon access. See [[Fstab#Remote file system]] for details.}}<br />
<br />
==== As systemd unit ====<br />
<br />
Create a new {{ic|.mount}} file inside {{ic|/etc/systemd/system}}, e.g. {{ic|mnt-myshare.mount}}. See {{man|5|systemd.mount}} for details.<br />
<br />
{{Note|Make sure the filename corresponds to the mountpoint you want to use.<br />
E.g. the unit name {{ic|mnt-myshare.mount}} can only be used if are going to mount the share under {{ic|/mnt/myshare}}. Otherwise the following error might occur: {{ic|1=systemd[1]: mnt-myshare.mount: Where= setting does not match unit name. Refusing.}}.}}<br />
<br />
{{ic|1=What=}} path to share<br />
<br />
{{ic|1=Where=}} path to mount the share<br />
<br />
{{ic|1=Options=}} share mounting options<br />
<br />
{{Note|<br />
* Network mount units automatically acquire {{ic|After}} dependencies on {{ic|remote-fs-pre.target}}, {{ic|network.target}} and {{ic|network-online.target}}, and gain a {{ic|Before}} dependency on {{ic|remote-fs.target}} unless {{ic|nofail}} mount option is set. Towards the latter a {{ic|Wants}} unit is added as well.<br />
* [[Append]] {{ic|noauto}} to {{ic|Options}} preventing automatically mount during boot (unless it is pulled in by some other unit).<br />
* If you want to use a hostname for the server you want to share (instead of an IP address), add {{ic|1=nss-lookup.target}} to {{ic|1=After}}. This might avoid mount errors at boot time that do not arise when testing the unit.<br />
}} <br />
<br />
{{hc|/etc/systemd/system/mnt-myshare.mount|2=<br />
[Unit]<br />
Description=Mount Share at boot<br />
<br />
[Mount]<br />
What=//server/share<br />
Where=/mnt/myshare<br />
Options=_netdev,credentials=/etc/samba/credentials/myshare,iocharset=utf8,rw<br />
Type=cifs<br />
TimeoutSec=30<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
{{Tip|<br />
* In case of an unreachable system, [[append]] {{ic|1=ForceUnmount=true}} to {{ic|[Mount]}}, allowing the share to be (force-)unmounted.<br />
* If your share has groups with read-only access, [[append]] {{ic|1=uid=''username''}} or {{ic|1=gid=''group''}} to {{ic|1=Options=}}, to specify your user / group allowing writing to the share.<br />
}}<br />
<br />
To use {{ic|mnt-myshare.mount}}, [[start]] the unit and [[enable]] it to run on system boot.<br />
<br />
===== automount =====<br />
<br />
To automatically mount a share (when accessed, like autofs), one may use the following automount unit:<br />
<br />
{{hc|/etc/systemd/system/mnt-myshare.automount|2=<br />
[Unit]<br />
Description=Automount myshare<br />
<br />
[Automount]<br />
Where=/mnt/myshare<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
[[Disable]]/[[stop]] the {{ic|mnt-myshare.mount}} unit, and [[enable]]/[[start]] {{ic|mnt-myshare.automount}} to automount the share when the mount path is being accessed.<br />
<br />
{{Tip|[[Append]] {{ic|TimeoutIdleSec}} to enable auto unmount. See {{man|5|systemd.automount}} for details.}}<br />
<br />
==== smbnetfs ====<br />
<br />
{{Note|1=smbnetfs needs an intact Samba server setup.<br />
<br />
See above on how to do that.}}<br />
<br />
First, check if you can see all the shares you are interested in mounting:<br />
<br />
$ smbtree -U ''remote_user''<br />
<br />
If that does not work, find and modify the following line<br />
in {{ic|/etc/samba/smb.conf}} accordingly:<br />
<br />
domain master = auto<br />
<br />
Now [[restart]] {{ic|smb.service}} and {{ic|nmb.service}}.<br />
<br />
If everything works as expected, [[pacman#Installing specific packages|install]] {{Pkg|smbnetfs}} from the official repositories.<br />
<br />
Then, add the following line to {{ic|/etc/fuse.conf}}:<br />
<br />
user_allow_other<br />
<br />
Now copy the directory {{ic|/etc/smbnetfs/.smb}} to your home directory:<br />
<br />
$ cp -a /etc/smbnetfs/.smb ~<br />
<br />
Then create a link to {{ic|smb.conf}}:<br />
<br />
$ ln -sf /etc/samba/smb.conf ~/.smb/smb.conf<br />
<br />
If a username and a password are required to access some of the shared folders, edit {{ic|~/.smb/smbnetfs.auth}}<br />
to include one or more entries like this:<br />
<br />
{{hc|~/.smb/smbnetfs.auth|<br />
auth "hostname" "username" "password"<br />
}}<br />
<br />
It is also possible to add entries for specific hosts to be mounted by smbnetfs, if necessary.<br />
More details can be found in {{ic|~/.smb/smbnetfs.conf}}.<br />
<br />
If you are using the [[Dolphin]] or [[GNOME Files]], you may want to add the following to {{ic|~/.smb/smbnetfs.conf}} to avoid "Disk full" errors as smbnetfs by default will report 0 bytes of free space:<br />
<br />
{{hc|~/.smb/smbnetfs.conf|<br />
free_space_size 1073741824<br />
}}<br />
<br />
When you are done with the configuration, you need to run<br />
<br />
$ chmod 600 ~/.smb/smbnetfs.*<br />
<br />
Otherwise, smbnetfs complains about 'insecure config file permissions'.<br />
<br />
Finally, to mount your Samba network neighbourhood to a directory of your choice, call<br />
<br />
$ smbnetfs ''mount_point''<br />
<br />
===== Daemon =====<br />
<br />
The Arch Linux package also maintains an additional system-wide operation mode for smbnetfs. To enable it, you need to make the<br />
said modifications in the directory {{ic|/etc/smbnetfs/.smb}}.<br />
<br />
Then, you can start and/or enable the {{ic|smbnetfs}} [[daemon]] as usual. The system-wide mount point is at {{ic|/mnt/smbnet/}}.<br />
<br />
==== autofs ====<br />
<br />
See [[Autofs]] for information on the kernel-based automounter for Linux.<br />
<br />
=== File manager configuration ===<br />
<br />
==== GNOME Files, Nemo, Caja, Thunar and PCManFM ====<br />
<br />
In order to access samba shares through GNOME Files, Nemo, Caja, Thunar or PCManFM, install the {{Pkg|gvfs-smb}} package, available in the [[official repositories]].<br />
<br />
Press {{ic|Ctrl+l}} and enter {{ic|smb://''servername''/''share''}} in the location bar to access your share.<br />
<br />
The mounted share is likely to be present at {{ic|/run/user/''your_UID''/gvfs}} or {{ic|~/.gvfs}} in the filesystem.<br />
<br />
==== KDE ====<br />
<br />
KDE applications (like Dolphin) has the ability to browse Samba shares built in. Use the path {{ic|smb://''servername''/''share''}} to browse the files. If you want to access files from on non-KDE application, you can install {{Pkg|kio-fuse}}.<br />
<br />
To use a GUI in the KDE System Settings, you will need to install the {{Pkg|kdenetwork-filesharing}} package.<br />
<br />
==== Other graphical environments ====<br />
<br />
There are a number of useful programs, but they may need to have packages created for them. This can be done with the Arch package build system. The good thing about these others is that they do not require a particular environment to be installed to support them, and so they bring along less baggage.<br />
<br />
* {{AUR|pyneighborhood}} is available in the official repositories.<br />
* LinNeighborhood, RUmba, xffm-samba plugin for Xffm are not available in the official repositories or the AUR. As they are not officially (or even unofficially supported), they may be obsolete and may not work at all.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Discovering network shares ===<br />
<br />
If nothing is known about other systems on the local network, and automated tools such as [[#smbnetfs|smbnetfs]] are not available, the following methods allow one to manually probe for Samba shares.<br />
<br />
1. First, [[install]] the {{Pkg|nmap}} and {{Pkg|smbclient}} packages.<br />
<br />
2. {{ic|nmap}} checks which ports are open:<br />
<br />
# nmap -p 139 -sT "192.168.1.*"<br />
<br />
In this case, a scan on the 192.168.1.* IP address range and port 139 has been performed, resulting in:<br />
<br />
{{hc|$ nmap -sT "192.168.1.*"|<nowiki><br />
Starting nmap 3.78 ( http://www.insecure.org/nmap/ ) at 2005-02-15 11:45 PHT<br />
Interesting ports on 192.168.1.1:<br />
(The 1661 ports scanned but not shown below are in state: closed)<br />
PORT STATE SERVICE<br />
'''139/tcp open netbios-ssn'''<br />
5000/tcp open UPnP<br />
<br />
Interesting ports on 192.168.1.5:<br />
(The 1662 ports scanned but not shown below are in state: closed)<br />
PORT STATE SERVICE<br />
6000/tcp open X11<br />
<br />
Nmap run completed -- 256 IP addresses (2 hosts up) scanned in 7.255 seconds<br />
</nowiki>}}<br />
<br />
The first result is another system; the second happens to be the client from where this scan was performed.<br />
<br />
3. Now that systems with port 139 open are revealed, use {{man|1|nmblookup}} to check for NetBIOS names: <br />
<br />
{{hc|$ nmblookup -A 192.168.1.1|<br />
Looking up status of 192.168.1.1<br />
PUTER <00> - B <ACTIVE><br />
HOMENET <00> - <GROUP> B <ACTIVE><br />
PUTER <03> - B <ACTIVE><br />
'''PUTER <20> - B <ACTIVE>'''<br />
HOMENET <1e> - <GROUP> B <ACTIVE><br />
USERNAME <03> - B <ACTIVE><br />
HOMENET <1d> - B <ACTIVE><br />
MSBROWSE <01> - <GROUP> B <ACTIVE><br />
}}<br />
<br />
Regardless of the output, look for '''<20>''', which shows the host with open services.<br />
<br />
4. Use {{ic|smbclient}} to list which services are shared on ''PUTER''. If prompted for a password, pressing enter should still display the list:<br />
<br />
{{hc|$ smbclient -L \\PUTER|<nowiki><br />
Sharename Type Comment<br />
--------- ---- -------<br />
MY_MUSIC Disk<br />
SHAREDDOCS Disk<br />
PRINTER$ Disk<br />
PRINTER Printer<br />
IPC$ IPC Remote Inter Process Communication<br />
<br />
Server Comment<br />
--------- -------<br />
PUTER<br />
<br />
Workgroup Master<br />
--------- -------<br />
HOMENET PUTER<br />
</nowiki>}}<br />
<br />
=== Remote control of Windows computer ===<br />
<br />
Samba offers a set of tools for communication with Windows. These can be handy if access to a Windows computer through remote desktop is not an option, as shown by some examples.<br />
<br />
Send shutdown command with a comment:<br />
<br />
$ net rpc shutdown -C "comment" -I IPADDRESS -U USERNAME%PASSWORD<br />
<br />
A forced shutdown instead can be invoked by changing -C with comment to a single -f. For a restart, only add -r, followed by a -C or -f.<br />
<br />
Stop and start services:<br />
<br />
$ net rpc service stop SERVICENAME -I IPADDRESS -U USERNAME%PASSWORD<br />
<br />
To see all possible net rpc command:<br />
<br />
$ net rpc<br />
<br />
== Troubleshooting ==<br />
<br />
=== Failed to start Samba SMB/CIFS server ===<br />
<br />
Possible solutions:<br />
<br />
* Check {{ic|smb.conf}} on syntactic errors with {{man|1|testparm}}.<br />
* Set correct permissions for {{ic|/var/cache/samba/}} and [[restart]] {{ic|smb.service}}:<br />
<br />
# chmod 0755 /var/cache/samba/msg<br />
<br />
=== Permission issues on SELinux ===<br />
<br />
[[SELinux]] not allow samba to access user home directories by default, to solve this, run:<br />
<br />
# setsebool -P samba_enable_home_dirs 1<br />
<br />
Similarly, {{ic|samba_export_all_ro}} and {{ic|samba_export_all_rw}} make [[Samba]] has the ability to read or "read and write" all files.<br />
<br />
=== Permission issues on AppArmor ===<br />
<br />
If using a [[#Creating an anonymous share|share path]] located outside of a home or usershares directory, whitelist it in {{ic|/etc/apparmor.d/local/usr.sbin.smbd}}. E.g.:<br />
<br />
{{hc|/etc/apparmor.d/local/usr.sbin.smbd|<br />
"/data/" rk,<br />
"/data/**" lrwk,<br />
}}<br />
<br />
=== No dialect specified on mount ===<br />
<br />
The client is using an unsupported SMB/CIFS version that is required by the server.<br />
<br />
See [[#Restrict protocols for better security]] for more information.<br />
<br />
=== Unable to overwrite files, permissions errors ===<br />
<br />
{{Accuracy|An user should set/check for server/client permissions, instead of using incorrect/possible insecure flags.}}<br />
<br />
Possible solutions:<br />
<br />
* Append the mount option {{ic|nodfs}} to the {{ic|/etc/fstab}} [[#As mount entry|entry]].<br />
* Add {{ic|1=msdfs root = no}} to the {{ic|[global]}} section of the server's {{ic|/etc/samba/smb.conf}}.<br />
<br />
=== Windows clients keep asking for password even if Samba shares are created with guest permissions ===<br />
<br />
Set {{ic|map to guest}} inside the {{ic|global}} section of {{ic|/etc/samba/smb.conf}}:<br />
<br />
map to guest = Bad User<br />
<br />
From Samba 4.10.10 you should use {{ic|Bad Password}} instead {{ic|Bad User}}.<br />
<br />
=== Windows 7 connectivity problems - mount error(12): cannot allocate memory ===<br />
<br />
A known Windows 7 bug that causes "mount error(12): cannot allocate memory" on an otherwise perfect cifs share on the Linux end can be fixed by setting a few registry keys on the Windows box as follows:<br />
<br />
* {{ic|HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache}} (set to {{ic|1}})<br />
* {{ic|HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size}} (set to {{ic|3}})<br />
<br />
Alternatively, start Command Prompt in Admin Mode and execute the following:<br />
<br />
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v "LargeSystemCache" /t REG_DWORD /d 1 /f<br />
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v "Size" /t REG_DWORD /d 3 /f<br />
<br />
Do one of the following for the settings to take effect:<br />
<br />
* Restart Windows<br />
* Restart the Server service via services.msc<br />
* From the Command Prompt run: 'net stop lanmanserver' and 'net start lanmanserver' - The server may automatically restart after stopping it.<br />
<br />
{{Note|Googling will reveal another tweak recommending users to add a key modifying the "IRPStackSize" size. This is incorrect for fixing this issue under Windows 7. Do not attempt it.}}<br />
<br />
[https://web.archive.org/web/20150819153712/http://alan.lamielle.net/2009/09/03/windows-7-nonpaged-pool-srv-error-2017/ Original article].<br />
<br />
=== Windows 10 1709 and up connectivity problems - "Windows cannot access" 0x80004005 ===<br />
<br />
This error affects some machines running Windows 10 version 1709 and later. It is not related to SMB1 being disabled in this version but to the fact that Microsoft disabled insecure logons for guests on this version for some, but not others.<br />
<br />
To fix, open Group Policy Editor ({{ic|gpedit.msc}}). Navigate to ''Computer configuration\administrative templates\network\Lanman Workstation > Enable insecure guest logons'' and enable it.<br />
Alternatively,change the following value in the registry:<br />
<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]<br />
"AllowInsecureGuestAuth"=dword:1<br />
<br />
=== Error: Failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL ===<br />
<br />
If you are a home user and using samba purely for file sharing from a server or NAS, you are probably not interested in sharing printers through it. If so, you can prevent this error from occurring by adding the following lines to your {{ic|/etc/samba/smb.conf}}:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
load printers = No<br />
printing = bsd<br />
printcap name = /dev/null<br />
disable spoolss = Yes<br />
}}<br />
<br />
[[Restart]] the samba service, {{ic|smb.service}}, and then check your logs:<br />
<br />
# cat /var/log/samba/smbd.log<br />
<br />
and the error should now no longer be appearing.<br />
<br />
=== Sharing a folder fails ===<br />
<br />
It means that while you are sharing a folder from ''Dolphin'' (file manager) and everything seems ok at first, after restarting ''Dolphin'' the share icon is gone from the shared folder, and also some output like this in terminal (''Konsole'') output:<br />
<br />
‘net usershare’ returned error 255: net usershare: usershares are currently disabled<br />
<br />
To fix it, enable usershare as described in [[#Enable Usershares]].<br />
<br />
=== "Browsing" network fails with "Failed to retrieve share list from server" ===<br />
<br />
And you are using a firewall (iptables) because you do not trust your local (school, university, hotel) network. This may be due to the following: When the smbclient is browsing the local network it sends out a broadcast request on udp port 137. The servers on the network then reply to your client but as the source address of this reply is different from the destination address iptables saw when sending the request for the listing out, iptables will not recognize the reply as being "ESTABLISHED" or "RELATED", and hence the packet is dropped. A possible solution is to add:<br />
<br />
iptables -t raw -A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns<br />
<br />
to your iptables setup.<br />
<br />
For [[Uncomplicated Firewall]], you need to add {{ic|nf_conntrack_netbios_ns}} to the end of the following line in {{ic|/etc/default/ufw}}<br />
<br />
IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_irc nf_nat_irc"<br />
<br />
and then run the following commands as root:<br />
<br />
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper<br />
ufw allow CIFS<br />
ufw reload<br />
<br />
To make this change persistent across reboots, add the following line at the end of {{ic|/etc/ufw/sysctl.conf}}:<br />
<br />
net.netfilter.nf_conntrack_helper=1<br />
<br />
=== Protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE ===<br />
<br />
The client probably does not have access to shares. Make sure clients' IP address is in {{ic|1=hosts allow =}} line in {{ic|/etc/samba/smb.conf}}.<br />
<br />
Another problem could be, that the client uses an invalid protocol version. To check this try to connect with the {{ic|smbclient}} where you specify the maximum protocol version manually:<br />
<br />
$ smbclient -U <user name> -L //<server name> -m <protocol version: e. g. SMB2> -W <domain name><br />
<br />
If the command was successful then create a configuration file:<br />
<br />
{{hc|~/.smb/smb.conf|output=<br />
[global]<br />
workgroup = <domain name><br />
client max protocol = SMB2<br />
}}<br />
<br />
=== Connection to SERVER failed: (Error NT_STATUS_UNSUCCESSFUL) ===<br />
<br />
You are probably passing a wrong server name to {{ic|smbclient}}. To find out the server name, run {{ic|hostnamectl}} on the server and look at "Transient hostname" line<br />
<br />
=== Connection to SERVER failed: (Error NT_STATUS_CONNECTION_REFUSED) ===<br />
<br />
Make sure that the server has started. The shared directories should exist and be accessible.<br />
<br />
=== Protocol negotiation failed: NT_STATUS_CONNECTION_RESET ===<br />
<br />
Probably the server is configured not to accept protocol SMB1. Add option {{ic|1=client max protocol = SMB2}} in {{ic|/etc/samba/smb.conf}}.<br />
Or just pass argument {{ic|-m SMB2}} to {{ic|smbclient}}.<br />
<br />
=== Password Error when correct credentials are given (error 1326) ===<br />
<br />
[https://www.samba.org/samba/history/samba-4.5.0.html Samba 4.5] has NTLMv1 authentication disabled by default. It is recommend to install the latest available upgrades on clients and deny access for unsupported clients.<br />
<br />
If you still need support for very old clients without NTLMv2 support (e.g. Windows XP), it is possible force enable NTLMv1, although this is '''not recommend''' for security reasons:<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
lanman auth = yes<br />
ntlm auth = yes<br />
}}<br />
<br />
If NTLMv2 clients are unable to authenticate when NTLMv1 has been enabled, create the following file on the client:<br />
{{hc|/home/user/.smb/smb.conf|2=<br />
[global]<br />
sec = ntlmv2<br />
client ntlmv2 auth = yes<br />
}}<br />
<br />
This change also affects samba shares mounted with '''mount.cifs'''. If after upgrade to Samba 4.5 your mount fails, add the '''sec=ntlmssp''' option to your mount command, e.g.<br />
<br />
mount.cifs //server/share /mnt/point -o sec=ntlmssp,...<br />
<br />
See the {{man|8|mount.cifs}} man page: '''ntlmssp''' - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message. The default in mainline kernel versions prior to v3.8 was '''sec=ntlm'''. In v3.8, the default was changed to '''sec=ntlmssp'''.<br />
<br />
=== Mapping reserved Windows characters ===<br />
<br />
Starting with kernel 3.18, the cifs module uses the [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2baa2682531ff02928e2d3904800696d9e7193db "mapposix" option by default].<br />
When mounting a share using unix extensions and a default Samba configuration, files and directories containing one of the seven reserved Windows characters {{ic|: \ * < > ? |}} are listed but cannot be accessed.<br />
<br />
Possible solutions are:<br />
<br />
* Use the undocumented {{ic|nomapposix}} mount option for cifs<br />
<br />
# mount.cifs //server/share /mnt/point -o nomapposix<br />
<br />
* Configure Samba to remap {{ic|mapposix}} ("SFM", Services for Mac) style characters to the correct native ones using [https://www.mankier.com/8/vfs_fruit fruit]<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
vfs objects = catia fruit<br />
fruit:encoding = native<br />
}}<br />
<br />
* Manually remap forbidden characters using [https://www.mankier.com/8/vfs_catia catia]<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
vfs objects = catia<br />
catia:mappings = 0x22:0xf022, 0x2a:0xf02a, 0x2f:0xf02f, 0x3a:0xf03a, 0x3c:0xf03c, 0x3e:0xf03e, 0x3f:0xf03f, 0x5c:0xf05c, 0x7c:0xf07c, 0x20:0xf020<br />
}}<br />
<br />
The latter approach (using catia or fruit) has the drawback of filtering files with unprintable characters.<br />
<br />
=== Folder shared inside graphical environment is not available to guests ===<br />
<br />
This section presupposes:<br />
<br />
# Usershares are configured following [[#Enable Usershares|previous section]]<br />
# A shared folder has been created as a non-root user from GUI<br />
# Guests access has been set to shared folder during creation<br />
# Samba service has been restarted at least once since last {{ic|/etc/samba/smb.conf}} file modification<br />
<br />
For clarification purpose only, in the following sub-sections is assumed:<br />
<br />
* Shared folder is located inside user home directory path ({{ic|/home/yourUser/Shared}})<br />
* Shared folder name is ''MySharedFiles''<br />
* Guest access is read-only.<br />
* Windows users will access shared folder content without login prompt<br />
<br />
==== Verify correct samba configuration ====<br />
<br />
Run the following command from a terminal to test configuration file correctness:<br />
<br />
$ testparm<br />
<br />
==== Verify correct shared folder creation ====<br />
<br />
Run the following commands from a terminal:<br />
<br />
$ cd /var/lib/samba/usershare<br />
$ ls<br />
<br />
If everything is fine, you will notice a file named {{ic|mysharedfiles}}<br />
<br />
Read the file contents using the following command:<br />
<br />
$ cat mysharedfiles<br />
<br />
The terminal output should display something like this:<br />
<br />
{{hc|/var/lib/samba/usershare/mysharedfiles|2=<br />
path=/home/yourUser/Shared<br />
comment=<br />
usershare_acl=S-1-1-0:r<br />
guest_ok=y<br />
sharename=MySharedFiles<br />
}}<br />
<br />
==== Verify folder access by guest ====<br />
<br />
Run the following command from a terminal. If prompted for a password, just press Enter:<br />
<br />
$ smbclient -L localhost<br />
<br />
If everything is fine, MySharedFiles should be displayed under {{ic|Sharename}} column<br />
<br />
Run the following command in order to access the shared folder as guest (anonymous login)<br />
<br />
$ smbclient -N //localhost/MySharedFiles<br />
<br />
If everything is fine samba client prompt will be displayed:<br />
<br />
smb: \><br />
<br />
From samba prompt verify guest can list directory contents:<br />
<br />
smb: \> ls<br />
<br />
If the {{ic|NTFS_STATUS_ACCESS_DENIED}} error is displayed, the issue is likely to be with Unix directory permissions. Ensure that your samba user has access to the folder and all parent folders. You can test this by sudoing to the user and attempting to list the mount directory, and all of its parents.<br />
<br />
=== Mount error: Host is down ===<br />
<br />
This error might be seen when mounting shares of Synology NAS servers. Use the mount option {{ic|1=vers=1.0}} to solve it.<br />
<br />
{{Note|SMB version 1 is known to have security vulnerabilities and was used in successful ransomware attacks.}}<br />
<br />
=== Software caused connection abort ===<br />
<br />
File managers that utilizes {{Pkg|gvfs-smb}} can show the error {{ic|Software caused connection abort}} when writing a file to a share/server. This may be due to the server running SMB/CIFS version 1, which many routers use for USB drive sharing (e.g. Belkin routers). To write to these shares specify the CIFS version with the option {{ic|1=vers=1.0}}. E.g.:<br />
<br />
{{hc|/etc/fstab|2=<br />
//SERVER/sharename /mnt/mountpoint cifs _netdev,guest,file_mode=0777,dir_mode=0777,vers=1.0 0 0<br />
}}<br />
<br />
This can also happen after updating Samba to version 4.11, which deactivates SMB1 as default, and accessing any Samba share. You can reenable it by adding<br />
<br />
{{hc|/etc/samba/smb.conf|2=<br />
[global]<br />
client min protocol = CORE<br />
}}<br />
<br />
=== Connection problem (due to authentification error) ===<br />
<br />
Be sure that you do not leave any space characters before your username in Samba client configuration file as follows:<br />
<br />
{{hc|~/.samba|2=<br />
username= user<br />
password=pass<br />
}}<br />
<br />
The correct format is:<br />
<br />
{{hc|~/.samba|2=<br />
username=user<br />
password=pass<br />
}}<br />
<br />
=== Windows 1709 or up does not discover the samba server in Network view ===<br />
<br />
With Windows 10 version 1511, support for SMBv1 and thus NetBIOS device discovery was disabled by default. Depending on the actual edition, later versions of Windows starting from version 1709 ("Fall Creators Update") do not allow the installation of the SMBv1 client anymore. This causes hosts running Samba not to be listed in the Explorer's "Network (Neighborhood)" views. While there is no connectivity problem and Samba will still run fine, users might want to have their Samba hosts to be listed by Windows automatically. {{AUR|wsdd}} implements a Web Service Discovery host daemon. This enables (Samba) hosts, like your local NAS device, to be found by Web Service Discovery Clients like Windows. The default settings should work for most installations, all you need to do is start enable {{ic|wsdd.service}}.<br />
<br />
If the default configuration (advertise itself as the machine hostname in group "WORKGROUP") should be all you need in most cases. If you need, you can change configuration options by passing additional arguments to wsdd by adding them in {{ic|/etc/conf.d/wsdd}} (see the manual page for wsdd for details).<br />
<br />
{{AUR|wsdd2}} does the same thing, but is written in C instead of Python. By default, it will look for the {{ic|netbios name}} and {{ic|workgroup}} values in {{ic|smb.conf}}.<br />
<br />
=== IOS Files can no longer copy-to Samba share on Archlinux beginning with IOS 14.5===<br />
<br />
Beginning with IOS 14.5 attempting to transfer from a device running IOS using the "Files" app to a samba share on Archlinux will result in the error:<br />
<br />
The operation couldn't be completed<br />
Operation canceled<br />
<br />
To correct this problem, add add the following to the global section of your {{ic|smb.conf}} and restart samba (e.g. {{ic|sudo systemctl restart smb}}).<br />
Comment optional:<br />
<br />
## addition for IOS Files transfer-to server<br />
vfs object = fruit streams_xattr<br />
<br />
See https://apple.stackexchange.com/q/424681 Apple.Stackexchange.com - "The operation couldn't be completed"/"Operation canceled" error message when saving to a Samba share via Files app.<br />
<br />
== See also ==<br />
<br />
* [https://www.samba.org/ Official website]<br />
* [https://www.samba.org/samba/docs/SambaIntro.html Samba: An Introduction]<br />
* [https://www.samba.org/samba/docs/Samba-HOWTO-Collection.pdf Samba 3.2.x HOWTO and Reference Guide] (outdated but still most extensive documentation)<br />
* [[Wikipedia:Samba (software)|Wikipedia]]<br />
* [[Gentoo:Samba/Guide]]<br />
* [[Debian:Samba/ServerSimple]]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_boot_process&diff=709925Talk:Arch boot process2022-01-13T21:31:03Z<p>Jasonwryan: /* SecureBoot support in the Feature Comparison table */ Agreed</p>
<hr />
<div>== SecureBoot support in the Feature Comparison table ==<br />
<br />
I'd like to add a column describing whether each bootloader can be adapted to work with SecureBoot or not.<br />
For example, EFISTUB cannot, since the cmdline is stored in firmware, not signed,and can be altered by an attacker. systemd-boot OTOH, is very easy to sign, and can load bundles with a signed initfs and cmdline. Any objections to this? [[User:Hobarrera|WhyNotHugo]] ([[User talk:Hobarrera|talk]]) 17:59, 14 July 2021 (UTC)<br />
: Sounds like a good idea! I'd only include the primary bootloaders though. See discussion below about proposed changes to the table. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 21:30, 13 January 2022 (UTC)<br />
<br />
== Removal of bootloaders in the AUR ==<br />
<br />
I think the feature table should only really concern itself with bootloaders that people actually use. Currently unexperienced people are guided to the table and met with a lot of information. It doesn't help that everything is added. Legacy stuff should go as well. We could have a legacy table if people see the need, but honestly who uses most of that after? Certainly not based off on this list?<br />
[[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 21:07, 13 January 2022 (UTC)<br />
: Agreed. I don't see the need for a legacy table, but perhaps some of the more experimental/alternative bootloaders could be included in a separate section (not a table), that links to their wiki or upstream documentation. Anyone wanting to play with one of those will presumably be competent enough to work it out for themselves... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 21:28, 13 January 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_boot_process&diff=709924Talk:Arch boot process2022-01-13T21:29:18Z<p>Jasonwryan: /* Removal of bootloaders in the AUR */ Agreed</p>
<hr />
<div>== SecureBoot support in the Feature Comparison table ==<br />
<br />
I'd like to add a column describing whether each bootloader can be adapted to work with SecureBoot or not.<br />
For example, EFISTUB cannot, since the cmdline is stored in firmware, not signed,and can be altered by an attacker. systemd-boot OTOH, is very easy to sign, and can load bundles with a signed initfs and cmdline. Any objections to this? [[User:Hobarrera|WhyNotHugo]] ([[User talk:Hobarrera|talk]]) 17:59, 14 July 2021 (UTC)<br />
<br />
== Removal of bootloaders in the AUR ==<br />
<br />
I think the feature table should only really concern itself with bootloaders that people actually use. Currently unexperienced people are guided to the table and met with a lot of information. It doesn't help that everything is added. Legacy stuff should go as well. We could have a legacy table if people see the need, but honestly who uses most of that after? Certainly not based off on this list?<br />
[[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 21:07, 13 January 2022 (UTC)<br />
: Agreed. I don't see the need for a legacy table, but perhaps some of the more experimental/alternative bootloaders could be included in a separate section (not a table), that links to their wiki or upstream documentation. Anyone wanting to play with one of those will presumably be competent enough to work it out for themselves... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 21:28, 13 January 2022 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch-based_distributions&diff=701778Talk:Arch-based distributions2021-11-13T00:53:55Z<p>Jasonwryan: /* Redirects for Arch-based distributions */ Delete them ALL</p>
<hr />
<div>== Excluded projects ==<br />
<br />
Following projects are excluded since they were found to misuse the [[DeveloperWiki:TrademarkPolicy|Arch Linux trademark]]:<br />
<br />
* 3du Arch, [https://sourceforge.net/projects/threeduarch/]<br />
* Archcraft, [https://archcraft.io/]<br />
* Arch Installer, [https://devmasters.pl/archinstaller/]<br />
* Arch Rescue Kit, [https://sourceforge.net/projects/archrescue/]<br />
* Arch USB OS, [https://sourceforge.net/projects/arch-linux-usb-os/]<br />
* CondresOS, [https://sourceforge.net/projects/condres-os-gnu-linux/], [https://www.codelinsoft.it/sito/support/wiki/how-to-switch-from-condres-to-archlinux-without-problems.html]<br />
* Happy Hacking Linux, [http://kodfabrik.com/happy-hacking-linux/]<br />
* Namib, [https://sourceforge.net/projects/namib-gnu-linux/], [https://www.namiblinux.org/]<br />
* Zen Installer, [https://sourceforge.net/projects/revenge-installer/] <sup>*2016, previously OBRevenge, Revenge OS</sup><br />
<br />
If trademark misuse problems have been addressed since, please create a separate thread below.<br />
<br />
-- [[ArchWiki:Maintenance Team]]<br />
<br />
== miraclx/ArtanOS ==<br />
<br />
I have been fixing a few dead links and unfortunately there are very few traces left of miraclx OS/ArtanOS.<br />
<br />
If you have any clues to where it went, please help us find a non-dead URL! Unfortunately none of the pages were archived by the Wayback Machine, most likely because they were hosted on github and gitlab before these were archived as a whole. The "best" clue I found so far is https://github.com/miraclx/artlock-classic but all the relevant links in there are dead and not archived.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 07:56, 27 July 2021 (UTC)<br />
<br />
== Redirects for Arch-based distributions ==<br />
<br />
There are a few redirects, e.g [[FaunOS]] and [[BlackArch]] but e.g no [[Manjaro]] (see [[Special:WhatLinksHere/Arch-based distributions]]). Do we want those kind of redirects? If not, those existing ones need to be deleted.<br />
<br />
In my opinion it makes sense to have some for the most popular ones, but it is hard to define "popular".<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:21, 13 November 2021 (UTC)<br />
<br />
: I would remove all of them. Defining what is "popular" is a movable feast and will only encourage bikeshedding. A simple policy of disallowing pages of Arch-based distributions means they are all treated equally, ie., deleted. -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:53, 13 November 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=DeveloperWiki_talk:TrademarkPolicy&diff=698491DeveloperWiki talk:TrademarkPolicy2021-10-07T07:47:20Z<p>Jasonwryan: All policies should be maintained in the same place</p>
<hr />
<div>== Move to GitLab ==<br />
<br />
The Code of Conduct, a similarly important document, got moved to GitLab. Since the trademark policy is so important, it might make sense moving it to GitLab, too.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 05:49, 17 July 2021 (UTC)<br />
<br />
:: Privacy Policy is hosted there as well; it makes sense that all of the policies are maintained in the same place. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 07:47, 7 October 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=695289Talk:Arch compared to other distributions2021-09-11T06:14:44Z<p>Jasonwryan: /* Comparison with Arch-based distributions */ Get a blog</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
::: I second this. The second paragraph in [[#Arch-based]] is just a lengthy liability waiver that should not be necessary for the terms compared on this page. If the content needs such waiver, don't add it to the page. Furthermore, the split into [[#Beginner-friendly]] and [[#Added-platforms]] reads as these are the only two categories. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 7 September 2021 (UTC)<br />
<br />
:::: I don't, particularly, feel that it is necessary. There's plenty of other such warnings elsewhere, and it does distract from the comparison. I included it to exhaustively cover the feedback on concerns about implying endorsement or support. I think a single sentence summary of that warning would suffice. Something like, "These distributions are ''not'' Arch, have their own communities and support, and are not endorsed in any way by Arch." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:31, 8 September 2021 (UTC)<br />
<br />
::: Regarding, "If it does nothing to advance Arch..." I think this is getting at the core of why I keep refining this comparison. In advocating for a more streamlined install process being made more prominent for Arch, the response has been tepid at best. Pointing to how Arch only intends to serve the needs of existing users, and concerns that if the install is made too easy there might be the unintended side-effect of people running Arch and not knowing how to maintain it. It's a, decidedly, whether intentional or not beginner-hostile approach. If Arch doesn't want beginners, why then would it be so afraid to point out other communities that might better suit them? And if Arch does want beginners, how can that be made more clear? Answering this clearly does feel like it would be of great benefit to advancing Arch. There is obviously a great demand by people who want the conveniences offered by Arch without the immediate desire to fully plumb the system themselves from the outset, for whatever reason that might be. Arch seems to want just to ignore this fact. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:52, 8 September 2021 (UTC)<br />
<br />
:::: Making an attempt to list derivative distros because of slights with the installation process is hardly a good motivation. It's driving away users while making the assumption users can't decide for themselves, or are unable to investigate what product suits their needs. <br />
:::: On that regard, there's [[Frequently_asked_questions#Why_would_I_not_want_to_use_Arch?]] already. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:45, 8 September 2021 (UTC)<br />
<br />
::::: Oh no, that's not what I mean! I'm only highlighting that there's an inherent tension between making beginner-hostile design decisions (whether intentional or not), and not wanting to point out where other distros have been more inviting of newcomers (in both their philosophical stance and their design choices). It smells of, "We don't want you here and we don't care where you go." Which is a bit rude. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:15, 8 September 2021 (UTC)<br />
<br />
::::: There's also something to be said here about a potentially missed opportunity. Suppose a Linux beginner hears about Arch from a friend. They come to this site. They want to see how Arch compares to other options and find this page. Being a beginner, they skip right down to Beginner-friendly. They see nothing about Arch being beginner friendly, or anything Arch-like, and instead opt to use Ubuntu. They spend a couple of years on Ubuntu before realizing it's no longer suiting their needs and is just ''too opinionated''; they want something more versatile. They remember Arch, and come back here. But given that they're so familiar now with Debian-based systems, they instead decide to go upstream to being a Debian user. They go on to be a prolific package maintainer. See what I'm getting at? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:22, 8 September 2021 (UTC)<br />
<br />
:::::: Or even consider, perhaps, someone more persistent. They're convinced they're a tenacious beginner who can get through the [[Installation_guide]]. They get the ISO spun up on their laptop. They spend a few hours thumbing back and forth between wiki pages on their phone and the prompt on their laptop screen. They made a few mistakes and lose the whole day, still not getting to a functional desktop. Meanwhile their friend who just spent 5 minutes clicking through the installer for one of the beginner-friendly Arch derivatives is talking about how quick and easy it was to get their oh-my-zsh environment ported over and they're already setup with everything they needed for their OSS - code environment with a few quick pacman pulls. They get frustrated, wipe the disk, and think, "This is a lot for someone who doesn't even know if they want to use Linux." They think maybe they'll come back to Arch when they know they've got a couple of days to really dig through the wiki. It doesn't happen for years, and they still wind up mostly just setting up the same configuration they're used to, wondering why there isn't at least an option to do it more automatically like nearly every other major distro has. They later try LFS and then at least know what they're getting into and why. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:13, 9 September 2021 (UTC)<br />
<br />
::::::: Or even if they didn't make any mistakes, the sheer amount of choices and requisite research can compound into a week-long process or more depending on how broad and deep your search goes. It's great for someone who already knows what they want, or really wants to understand the lay of the land, but not good at all for someone simply looking for an impression and a functional desktop. I think it would just be best if Arch has something more polite and helpful to offer those people, even if it's a simple acknowledgment that other communities are better oriented to their current needs. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:05, 9 September 2021 (UTC)<br />
<br />
: To summarize some of my recent arguments for Arch to have more favorable things to say and offer to newcomers:<br />
:# Pointing out Arch-like distros to Linux newbies may lead to future, highly valuable, Arch users. Newbies may become more seasoned and want more flexibility with time, eventually coming upstream. Pointing them to Ubuntu and the like instead just smells of, "We want nothing to do with the uninitiated, ever."<br />
:# Making design decisions which effectively require one to be highly familiar with Linux in order to successfully install a robust pure Arch system, without making that clear from the outset, is a disservice to all potential users. All respected courses and manuals have clear prerequisite knowledge outlined in their most prominent opening materials, something Arch is missing currently. Pointing to alternatives with less steep learning curves and orders of magnitude less prerequisite knowledge required to reach a state of being able to have a graphical browser and access to basic productivity tools (e.g. OpenOffice) is a signal of awareness of variable needs and respect to a broad audience.<br />
:# Contrasting Arch-like distros which offer curated desktop collections is one way of highlighting the prerequisite knowledge needed to successfully install Arch.<br />
:# I'll point to this line from [[Arch_Linux#Pragmatism|Arch Linux's Core Principles]], "''Evidence-based technical analysis and debate are what matter, not politics or popular opinion.''" This is one of my central arguments. I'm offering what I feel is very clear evidence of this being valuable, and expecting either consensus or continued technical debate which respects the [https://en.wikipedia.org/wiki/De-escalation#/media/File:Graham's_Hierarchy_of_Disagreement-en.svg tenets of productive non-confrontational argument].<br />
: -- [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:28, 11 September 2021 (UTC)<br />
<br />
: Now to offer some new arguments.<br />
:# It has been suggested that this debate amounts to [https://en.wikipedia.org/wiki/Law_of_triviality bike-shedding]. I'd like to offer a counterargument to that notion. To summarize, bike-shedding is a term which represents an idea that can be summarized as, "Disproportionate, large, amounts of debate tends to happen around things of relatively little consequence." I believe this topic is of significant consequence and have offered several concrete reasons why already. I'll add another next.<br />
:# In researching this section, I looked at Google Trends data. [https://entvibes.com/archwiki/Arch%20vs%20Manjaro%20Linux%20-%20Google%20Trends%20since%202016%20-%202021-09-11.png This chart] highlights that Manjaro has gained significant ground on Arch in the last few years in terms of total global interest. In investigating why this might be, I looked at data by country. Some notes:<br />
:## Of the top 10 countries where searches for Arch are most dominant, they tend to be among the most economically and technologically advanced in the world. This list is dominated by the likes of Japan, Switzerland, and Sweden.<br />
:## Of the top 10 countries where searches for Manjaro are most dominant, they tend to be in more developing regions. Bangladesh, Philippines, Kenya...<br />
:# To me, this highlights that there is indeed a major developmental divide which the contrast in approach for what amounts to extremely similar operating systems at their core has brought about. Arch has adopted an approach which seems to have isolated developing nations.<br />
:## As an organization representing itself to [https://en.wikipedia.org/wiki/Software_in_the_Public_Interest Software in the Public Interest], Arch bears a responsibility to be cognizant of and helpful towards those who stand to gain the most from increased access to personal computing.<br />
: -- [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:04, 11 September 2021 (UTC)<br />
<br />
: [https://entvibes.com/archwiki/2020%20Software%20in%20the%20Public%20Interest%20Report%20-%20Arch%20Linux%20-%202021-09-11.png This] is the executive summary offered by Arch Linux to Software in the Public Interest for 2020. I'll highlight some points below, and offer commentary.<br />
:# "''In 2020, we worked on usability and community outreach.''" What I'm proposing specifically addresses improving usability and being responsive to community needs.<br />
:# "'''We ... work towards a more unified and automated experience.''" Again, proposals to streamline the install process and highlight automatic options are in line with this executive direction.<br />
:# "''Our installation medium has been extended to be accessible for blind and visually impaired...''" This is great progress and highlights community and developmental interest in providing better support to marginalized communities. Better serving the developing world is a worthy prospect in line with this interest as well.<br />
: -- [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:26, 11 September 2021 (UTC)<br />
<br />
: I'll add a personal story here too. A reason I personally like Arch is that I feel it exists as a stepping stone in the path to fully understanding the Linux architecture. The logical path for one to take is from a beginner-friendly distribution like Ubuntu or Manjaro, where things are setup for you in nearly all regards, to something like Arch. Arch presumes far less, while still making it easy to be productive. The next step would be towards something like Linux From Scratch, where nothing is truly decided for you and all steps are logically laid out and explained. The end would be towards getting your hands dirty in patching and modifying the kernel. Arch could do well to proudly highlight this path and embrace its role within it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:53, 11 September 2021 (UTC)<br />
:: I also don't feel this positioning precludes Arch from expanding its accessibility to initiates. If Arch feels it can better serve them than existing Arch derivatives, without diluting its current value proposition, then by all means that is an option. Otherwise, forsaking, shunning, and ignoring those who have taken up that torch doesn't read well. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:04, 11 September 2021 (UTC)<br />
<br />
::This discussion has been closed. Get a blog. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 06:14, 11 September 2021 (UTC)<br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
:: Fair point. Updated [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:53, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]], to access our high-quality and well-curated [[official repositories]], or [[Arch_User_Repository#Installing_and_upgrading_packages|makepkg]] to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
:: I did mention them as "conveniences." Open to a rephrase if the statement seems misleading. It seems a shame not to mention pacman, since that's really what drove the creation of Arch to begin with. The AUR helpers are just the correlate for the AUR. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:59, 7 September 2021 (UTC)<br />
<br />
::: You misinterpreted my comment: pacman is not the problem, just the AUR helpers. As I said, they are not necessary for the AUR: makepkg is. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:26, 7 September 2021 (UTC)<br />
<br />
:::: Oh I know pacman is not the problem. I'm just saying that the way it's written out as, "conveniences to access the official repositories and AUR, respectively," only really works if I include the AUR helpers. Attempting a rewrite. I think I, a bit reluctantly, agree that pointing out the AUR helpers, potentially to beginners, might be too much of a footgun. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:46, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about [[Desktop_environment#Officially_supported|which desktop environment]] to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
<br />
:: Some I've specifically included because I want to tie them into the relevant documentation for the Arch wiki, for those curious why particular software was chosen who want to look into it. (e.g., the combination of btrfs and TimeShift). Is that not appropriate? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:03, 7 September 2021 (UTC)<br />
<br />
::: What is achieved by linking to other wiki pages? People curious about derivatives can read the rationale ''on the derivative websites''. We aren't in the business of promoting those distributions. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:29, 7 September 2021 (UTC)<br />
<br />
:::: It makes it easy for Archers (DIY'er/Tinkerers) to think, "Huh, I wonder why they all seem to be using those. Guess I'll look at the wiki page and maybe try them out." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:49, 7 September 2021 (UTC)<br />
<br />
::::: Archers who want to try out different DEs etc, can just install them on their Arch installation, that's the whole point of Arch Linux... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:16, 7 September 2021 (UTC)<br />
<br />
:::::: Yes, we agree on this. That's why I've included the internal wikilinks for archers to read about, and potentially setup, on their Arch installs. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:14, 8 September 2021 (UTC)<br />
<br />
:::::: So, all of it can be removed and this discussion can actually be closed so that the staff can go back to doing actual volunteer work on the wiki, and stop bikeshedding this proposal? Great. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:26, 8 September 2021 (UTC)<br />
<br />
:: Here's a use case for this section which is more of an anti-advertisement: Having a place to point people who, wondering about migrating away from an Arch-derived distro, want to know how pure Arch compares. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:52, 7 September 2021 (UTC)<br />
<br />
::: Again, pure Arch is comprehensively described in the main pages of the wiki: if people who want to migrate from derivatives can't understand that, including all of this is not going to make any difference. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:18, 7 September 2021 (UTC)<br />
<br />
:::: Sure, this is just a topical summary which directly highlights the difference in philosophy and technical choices. Same could be said about basically all the other distros on this page. Why have the page at all then? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:23, 8 September 2021 (UTC)<br />
<br />
::::: Well, the other entries are actual distributions, not just someone's version of Arch Linux. In any event, I am done arguing about this: the sheer volume of pointless discussion for a proposal that amounts to nothing more than advertising for derivatives is evidence enough that this has no benefit, direct or indirect, to Arch. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:37, 8 September 2021 (UTC)<br />
<br />
:: Some of the content feels a bit redundant after the long intro I've now added. Attempting a trim on this update. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 09:04, 7 September 2021 (UTC)<br />
<br />
===== Manjaro =====<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
:: Can we nuke all this stuff? It screams of content that requires a lot of upkeep (package count, etc), general advertising and a tremendous amount of fluff. Arch ethos is to keep it simple. None of this is remotely simple.<br />
:: [[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 01:42, 8 September 2021 (UTC)<br />
<br />
::: I included info about package coverage, in rough approximations, because there was some open consideration of what overlap these have with more general-purpose distributions. It's not essential, but has already been researched and is of relevance to defining the class. Simply removing the content if it proves out of date without a maintainer would be understandable. These are also just comparisons to Arch. LFS is arguably "simpler" than Arch and distributions which are considerably smaller than Arch are also, by necessity, simpler than Arch... Arch isn't all about simplicity. Even the decision to break away from CRUX was over the concern of added complexity created by the envisioned metadata-included creation of pacman. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:28, 8 September 2021 (UTC)<br />
<br />
::: Also, I agree and appreciate that simplicity is in the ethos of Arch. Not trying to contest that at all. Just pointing out that it does necessitate some definition. For instance, I suggested "lightweight" as an alternative name for what is now proposed as "minimal-size". This was criticized as, "meaningless." Arch is trademarked as "A simple, lightweight distribution." Certainly, we don't want to face the same criticism from the outside. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:29, 8 September 2021 (UTC)<br />
<br />
::: That, "defining what Arch means by simple and lightweight," is part of where I see the value in this page. It's a concrete comparison of the tradeoffs Arch makes vs other projects so that the casual outside observer can clearly see how Archers prioritize simplicity and lightness vs other goals. So minimal-size is a category that specifically helps to define how Arch compares to other projects which more highly priotize "minimalism" or "lightweightness" or whatever you want to call it (currently the idea is that "Minimal-size" is the most apt short description). [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:38, 8 September 2021 (UTC)<br />
<br />
::: As a specific example of defining what Archers mean by simple: An Archer might argue that the convenience and stability gained by having a package manager which is better at keeping track of all the moving components in the system and how they interrelate ultimately provides for a simpler overall experience which more than offsets the engineering complexity of it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:46, 8 September 2021 (UTC)<br />
<br />
::: And a specific example of how that definition can help in shaping the future of the distro: I'm currently advocating for an automated install process which covers, at least, the most common use-cases outlined in the [[Installation_guide]]. The argument being around how the added complexity of having an automated process which better keeps track of all the moving components in the system and how they interrelate ultimately provides for a simpler overall experience which more than offsets the engineering complexity of it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:10, 8 September 2021 (UTC)<br />
<br />
:::: I would like to see more actual ''comparisons'' to Arch, rather than merely listing features of other distributions. For example, Void Linux uses pull requests to accept packages into their repositories, while Arch has the AUR with user-submitted packages, which are then cherry-picked to the repositories. Alpine uses APKBUILD, which is very similar to PKGBUILD but is strictly limited to POSIX shell features, e.g. no arrays. And so on.<br />
<br />
:::::Those are great details to include! Please do. My draft only serves as a foundation. I'd like to see more detailed comparison too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 22:55, 8 September 2021 (UTC)<br />
<br />
:::: Personally I would also skip Tiny Core Linux and Puppy Linux. You even admit to their limited relevance in the distro landscape. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 8 September 2021 (UTC)<br />
<br />
::::: Yeah, I've noticed you feel strongly that distros included here should have broad relevance as basically being very general purpose or being generally ubiquitous to those familiar with Linux. I feel like there's some opportunity to cherry-pick a few less ubiquitous distros specifically for the purpose of highlighting implementations which stretch the boundaries of what people might typically do with Linux. For Arch, aiming to be incredibly versatile and fostering of regular tinkering and expansion of the idea of what you can achieve with your system, I feel like it's a worthwhile thing to point these out! For instance, Tiny Core I think gives a wow moment to a lot of people when they realize a whole functional graphical desktop can fit in 11MB, and that adding Wi-Fi and non-US keyboards adds a whole order of magnitude in size and complexity. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:02, 8 September 2021 (UTC)<br />
<br />
:::::: It's also a very poignant contrast! Arch is ''A simple, lightweight distribution'', but within the confines of being totally general-purpose. Tiny Core, by comparison, is '''''maximally''''' simple and lightweight as an absolute first priority. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:46, 8 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
:::The starting point for an "Archer thinking about security" is the [[Security]] page. It would be better to describe the interesting concepts and features on that (or another relevant) page, rather than comparing Arch to security-oriented Linux distributions. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:39, 7 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
:::This draft could still use some more direct comparisons to Arch.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 22:38, 8 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
:::The currently proposed content is missing any comparison with Arch, so it is out of this page's scope. Providing quick summaries of 3 BSDs is pointless, they can be found elsewhere. This page is about giving comparisons (with Arch!), not summaries. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:32, 7 September 2021 (UTC)<br />
<br />
::::Agreed! I thought the NetBSD note about being most-portable was a poignant self-evident contrast to Arch only supporting one platform, which is why I wanted to include that one specifically. If the choice is between none and all of the well known ones, I'd rather include all though. Here's a quick whack at a comparison. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 22:47, 8 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability. Arch is also focused on being very general-purpose, and the Linux kernel is arguably the best refined kernel for SMP scalability in the open source world currently.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits. Arch tries to maintain security by keeping the core distribution tightly controlled through highly trusted users and rigorous review, but doesn't centrally focus on security as the main goal of the release.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms]. Arch instead only supports x86_64, in order to provide focus on the core use-case: contemporary desktop, mobile, and server.<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
:::::I don't know about those corporate details you mention. But Fedora and openSUSE, the underpinnings for RHEL and SLES respectively, are already mentioned on this page. As such, the main distinction points for these distros are already listed. openSUSE Leap is even 100% binary compatible to SLES nowadays. [https://www.suse.com/c/introducing-suse-linux-enterprise-15-sp3/] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:39, 8 September 2021 (UTC)<br />
<br />
::::::Yeah, that's why I thought it best to only include a bare-bones summary of the primary detail which provides such a sharp contrast to the rolling release model of Arch here. As you've said, the other more detailed contrasts to Arch are better highlighted in the comparisons to the community versions of these distros. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 22:33, 8 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Installation_guide&diff=695081Talk:Installation guide2021-09-09T03:31:14Z<p>Jasonwryan: /* Add information about packages included in the installation environment */ Let the bikeshedding continue</p>
<hr />
<div>== Read this first before adding new suggestions ==<br />
<br />
* systemd tools such as ''hostnamectl'', ''timedatectl'' and ''localectl'' [https://github.com/systemd/systemd/issues/798#issuecomment-126568596 do not work] in the installation chroot environment, so please do not propose to use them in the guide unless you can prove that they have been made to work also in that case. See [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=388727#General_problems], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=404695#Replace_commands_with_their_systemd_equivalents], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=418662#Utilizing_systemd_tools] and [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=434985#change_configuration_system_from_old_way_to_new_way.28using_systemd_commands.29] for some past discussions about this issue.<br />
* {{ic|localectl list-keymaps}} does not work due to bug {{Bug|46725}}. For the chosen replacement command, see [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=435044#localectl].<br />
* {{ic|localhost}} must be set explicitely in {{ic|/etc/hosts}}, as it is otherwise resolved over the network. See {{Bug|56684}}.<br />
* Due to the wide variety of available boot loaders, the installation guide refers to [[Arch_boot_process#Boot_loader]] instead of making a specific recommendation for the installed system. See [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=687325#Bootloader], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=690612#Make_the_Boot_Loader_Section_slightly_more_detailed_to_provide_a_high_level_overview_for_new_users], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=678949#Expand_Boot_loader_section], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=660151#Expand_Boot_loader_section_to_include_example_commands], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=581427#Boot_loader_installation] for some past discussions on this topic.<br />
-- [[ArchWiki:Administrators|The ArchWiki Administrators]] 22:17, 2 September 2016 (UTC)<br />
__TOC__<br />
<br />
== Link to the German version ==<br />
<br />
Instead of [[de:Arch Install Scripts]] you could choose [[de:Anleitung für Einsteiger]] it means "Beginner's Guid" and is a very <br />
detailed artikel for very new arch users and the future experts.<br />
<br />
:Thank you, [https://wiki.archlinux.org/index.php?title=Installation_guide&type=revision&diff=509961&oldid=508505 done]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 6 February 2018 (UTC)<br />
<br />
::This was already proposed last year and rejected: [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=466950#Suggesting_different_page_for_German_translation]. I don't see what has changed since then. If someone adds me as admin to the german wiki or changes the protection settings, I can update [[de:Arch Install Scripts]] as required. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:13, 6 February 2018 (UTC)<br />
<br />
:::I see, I didn't remember that discussion so I've reverted the change, hopefully you'll make it to update the translation, let's leave this open until the problem is solved, otherwise this kind of suggestion will keep appearing recurrently. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:53, 7 February 2018 (UTC)<br />
<br />
::::Apparently since last year the translation has been halved in size, but its scope is still much larger than the [[Install guide]] (or even the old [[Beginners' guide]]). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 9 May 2021 (UTC)<br />
<br />
== Why should a static IP be preferred over 127.0.1.1 in /etc/hosts? ==<br />
<br />
"If the system has a permanent IP address, it should be used instead of 127.0.1.1."<br />
<br />
I think the ArchWiki should not just say do X but also why. [[User:Alad|Alad]] as you added this, perhaps you can explain?--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:14, 21 May 2018 (UTC)<br />
<br />
:In [[Network_configuration#Local hostname resolution]]: "For a system with a permanent IP address, that permanent IP address should be used instead of 127.0.1.1." -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:48, 22 May 2018 (UTC)<br />
<br />
::[https://wiki.archlinux.org/index.php?title=Network_configuration&diff=340138&oldid=333485 First] appearance in our wiki, cited [https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution source], also [https://wiki.archlinux.org/index.php?title=Talk:Network_configuration&oldid=360328#Hostname_resolution discussion]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:26, 22 May 2018 (UTC)<br />
<br />
:::Clear enough, close. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 01:58, 10 August 2020 (UTC)<br />
<br />
::::This should be explained in the guide or at least in [[Network_configuration#Local hostname resolution]]. Explaining stuff in the edit summary or on talk pages is not enough. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:43, 10 August 2020 (UTC)<br />
<br />
== Wording in example layout table and size of EFI partition ==<br />
<br />
=== Formatting the ESP ===<br />
<br />
I believe myself that the partition table should be modified. When Going through the install, it was confusing how swap was the last partition, usually suppose to be the partition before Root, as if the computer loads up swap before user login. Didn't realize that a GPT disk needed to be formatted until reading this guide: https://wiki.archlinux.org/index.php/EFI_system_partition . Would recommend at least linking to this section of the document or even input Format partition section within the Wiki. [[User:Shaggy|Shaggy]] ([[User talk:Shaggy|talk]]) 20:15, 29 June 2020 (UTC)Shaggy<br />
<br />
:The order of partitions is irrelevant and it has (mostly) no effect on booting. The fact that the [[ESP]] needs to formatted after its creation cannot be simply stated, as it could be misinterpreted as requiring to always format it, even if is an existing partition that already has a file system.<br />
:After reading [https://bbs.archlinux.org/viewtopic.php?pid=1912222#p1912222 an anecdote], I think moving swap before root should be considered :D<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:39, 1 July 2020 (UTC)<br />
<br />
:I've been thinking, how about placing the {{ic|mkfs.fat -F32 /dev/sdxY}} command in [[Installation guide#Format the partitions]]. [[EFI system partition#Format the partition]] could instead be modified to omit the FAT type (i.e {{ic|mkfs.fat /dev/sdxY}}). FAT32 is a recommendation, but not mandatory, thus it's more appropriate for the [[Installation guide]], and this would allow to document the 2 MiB FAT12 formatted ESP, used by [[User:Eschwartz]] and others, in the [[EFI system partition]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:14, 13 August 2020 (UTC)<br />
<br />
::I guess that's reasonable, if you add the note that an existing EFI partition may have to be preserved. (cf. [[User:Alad/Beginners'_guide#Format_the_partitions]]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:10, 14 April 2021 (UTC)<br />
<br />
== HiDPI on the console ==<br />
<br />
With an ever increasing number of [[HiDPI]] displays, including at the begging of the article a section about adjusting the scaling factor or changing the font can be helpful, see [[HiDPI#Linux_console]]. [[User:Goetzc|Goetzc]] ([[User talk:Goetzc|talk]]) 02:21, 8 August 2019 (UTC)<br />
<br />
:It could be added as an example for {{ic|setfont}} in [[Installation_guide#Set_the_keyboard_layout]]. The issue I have is that [[HiDPI#Linux_console]] mentions that {{ic|tty2-6}} may be unusable, while the Installation guide specifically instructs to change ttys as required in [[Installation_guide#Boot_the_live_environment]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:07, 7 September 2019 (UTC)<br />
<br />
::May be as an example for the line "See README.bootparams for a list of boot parameters" [[Installation_guide#Boot_the_live_environment]], it could be specified to hit {{ic|e}} button to edit the boot entry and add the following parameters to the boot line, like {{ic|1=video=1920x1080}} if you have HiDPI display. -- [[User:Xzorg6|Xzorg6]] ([[User talk:Xzorg6|talk]]) 22:41, 15 December 2019 (UTC)<br />
<br />
:::{{ic|1=video=}} will just change the resolution. To get a bigger font on the console, you need {{ic|1=CONFIG_FONT_TER16x32=y}} in the kernel config and {{ic|1=fbcon=font:TER16x32}} in the kernel command line. Since the official kernels don't enable {{ic|CONFIG_FONT_TER16x32}}, someone will need to open a bug report asking for it. After that, the instructions for setting the {{ic|1=fbcon=font:TER16x32}} [[kernel parameter]] could be added to the wiki. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:52, 16 December 2019 (UTC)<br />
<br />
::::{{Pkg|linux}} 5.5.6.arch1-1 <s>(currently in testing)</s> has {{ic|1=CONFIG_FONT_TER16x32=y}} ({{Bug|64861}}). <s>If if gets move to core before March, then</s> the March iso will have it. It's probably a good idea to start drafting a [[Template:Tip|tip]] to place in [[Installation guide#Boot the live environment]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:12, 26 February 2020 (UTC)<br />
<br />
::::And just after I wrote this, the package was moved to core. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:27, 26 February 2020 (UTC)<br />
<br />
:::::I'm seeing multiple claims[https://bbs.archlinux.org/viewtopic.php?id=253319][https://www.reddit.com/r/archlinux/comments/fbi4vx/text_size_during_boot_changed_since_my_last/][https://www.reddit.com/r/archlinux/comments/fgct3t/how_to_get_currently_loaded_console_font_of_the/] that people with HiDPI screens are getting the TER16x32 font. I was not aware that the kernel chooses a font depending on screen size. Can anyone confirm that this really is the case? If it really works that way and unless {{Bug|65680}} messes this up, then there's nothing to add to the Installation guide about this topic. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:02, 11 March 2020 (UTC)<br />
<br />
::::::As per https://lkml.org/lkml/2019/6/18/966 the decision to use ter16x32 is not based on screen size but only resolution.So even though a 1080p screen may be hidpi it does not use ter16x32 [[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 10:17, 11 May 2020 (UTC)<br />
<br />
:::::::At least that part is now clear, thanks. The first step should be to get [[HiDPI#Linux console]] up to date. After that, as I've said before, a tip for the installation guide can be drafted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:04, 11 May 2020 (UTC)<br />
<br />
:::::::: I fixed the page and removed the template [[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 12:25, 11 May 2020 (UTC)<br />
<br />
== First mention of /mnt in example partition layout ==<br />
<br />
{{ic|/mnt}} is mentioned at mount point in [[Installation_guide#Partition_the_disks]], while {{ic|/mnt}} is made explicit two sections later in [[Installation_guide#Mount_the_file_systems]]. As I recall it, this was changed because some users blindly copy pasted commands and mounted /boot on the live system, instead of /mnt/boot. Some options:<br />
<br />
* Introduce another column describing the mount point on the installed system. <br />
* Actually explain /mnt early.<br />
* Revert the "mount point" to not include /mnt.<br />
<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:03, 7 September 2019 (UTC)<br />
<br />
:I don't understand what's the actual problem here... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 8 September 2019 (UTC)<br />
<br />
::From what I read on [[ArchWiki:IRC|#archlinux-wiki]], this comes from https://www.reddit.com/r/archlinux/comments/d0v0j3/is_it_just_me_or_is_the_prospect_of_installing/ where the user was confused by the lack of root mountpoint (i.e. {{ic|/mnt}} vs {{ic|/}}). A question could be raised, if we should concern ourselves with users who have strong opinions about the wiki content yet can't be bothered to propose improvements in the talk pages...<br />
::About Alad's proposed options: I disagree with the first option, I think it will just complicate things even further. I support the third option and maybe adjusting the column header like in [[Special:Diff/581800]].<br />
::I'd actually would like to go even further and change the commands run from outside chroot to be visually distinct, e.g.: {{bc|1=<span style="color: #ff0000;">root@archiso #</span> mount /dev/sd''X1'' /mnt}}<br />
::I think it would better solve the underlying issue. <br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:26, 8 September 2019 (UTC)<br />
<br />
:::I'm not overly fond of the longer column name. For the last proposed option, I may agree if this is formalized in [[Help:Style]], so that it is not specfic to the [[Installation guide]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:20, 10 September 2019 (UTC)<br />
<br />
::::Adding it [[Help:Style]] was my intention, since other articles, too, will need to use that style for some commands. I'm thinking of creating a template for it: [[Special:Permalink/581945]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:19, 11 September 2019 (UTC)<br />
<br />
:::::Sounds good to me, I'd just prefer the regular (non-bold) font for the prompt as above. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:54, 13 September 2019 (UTC)<br />
<br />
::::::[[Special:Permalink/582327]]. Are there any other opinions about creating such a template? Or should I take this discussion to [[Help talk:Template]] per [[Help:Template#Creation]]? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:31, 14 September 2019 (UTC)<br />
<br />
:::::::# How are you going to call the template? This template would probably add to the [[Help:Template#Code formatting templates]] series, should it be named in a consistent fashion?<br />
:::::::# Should this template support custom prompts, and if so, should it be called "pc" (from "(custom) prompted" code)?<br />
:::::::# I don't like the red color too much, if bold is not an option maybe we can go green|purple|blue, something that recalls less a warning of some kind? Or can we just leave it with the default font color? Or a slightly fainter black?<br />
:::::::# I haven't looked well into it, but maybe we can instead add an optional argument to [[Template:bc]] and [[Template:hc]] that prefixes a custom (colored) prompt? I wouldn't see a problem with repeating "root@archiso #" in every instance, or we may derive the new template from those two at that point.<br />
:::::::# The template should probably be derived from [[Template:bc]] in any case, for simpler code, see [[User:Kynikos/Template:Sandbox2]].<br />
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:36, 16 September 2019 (UTC)<br />
<br />
::::::::# Initially I was going to call it [[Template:Archiso]] since it would be [[Archiso]]-specific, but I'm starting to think that creating a more general-purpose template would be better. It could then be used in [[PostgreSQL]] and the {{ic|[postgres]$}} convention would get formalized in [[Help:Style]]. Now the issue is the {{ic|[user@peer-a]#}} in [[Template:hc]] used in [[WireGuard]]. I'd rather not create two new templates, but I'm having trouble getting [[Template:Sandbox]] to work :(<br />
::::::::# I like your "[[Template:pc]]" suggestion.<br />
::::::::# Be glad I didn't post my first draft that was ''slightly more'' colorful. From your offered colors, I'd choose purple.<br />
::::::::# I'd rather not mess with the established templates just for this change, so I'd prefer creating a new template.<br />
::::::::# I didn't even think about using [[Template:bc]]. Is it a good idea to do that? The new template might need to be updated if [[Template:bc]] is ever changed in an incompatible way.<br />
:::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:33, 17 September 2019 (UTC)<br />
<br />
:::::::::Yeah, after viewing your attempts and looking into it myself, I think modifying bc/hc is out of discussion, it would add too much code/style for so little use.<br />
:::::::::Thinking about this again one day after, I feel I'm realizing that my concerns in general may descend from the fact that we're going to create a template to represent (block) code, even though we already have 2 which basically do the same thing, including allowing to include a prompt; the only addition of this "Archiso" or "pc" template would be the formatting around the prompt, so why not keep it simple (I know, "simplicity" is often subjective and controversial) and instead either make a [[Template:Archiso]] to be used like {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or [[Template:ps]] (or [[Template:PS]]) to be used like {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}? They also work with [[Template:hc]] and space-prefixed code blocks!<br />
:::::::::Putting the choice of color aside, if the above idea of a standalone prompt template isn't welcome, I think my second choice would be to make two [[Template:pbc]] and [[Template:phc]] that work like {{ic|<nowiki>{{pbc|$|ls}}</nowiki>}} and {{ic|<nowiki>{{phc|$|ls|...}}</nowiki>}}, with the style rule to use them only in case of complex prompts. I'd still derive them from bc/hc to inherit any changes that we'd decide to make to them, and avoid repeating that ugly &lt;pre> hack even more.<br />
:::::::::Otherwise I give up and accept the [[Template:Archiso]] that works like {{ic|<nowiki>{{Archiso|mount /dev/sdX1 /mnt}}</nowiki>}}, in the hope that one day we won't need an analogous "hc" version.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 17 September 2019 (UTC)<br />
<br />
::::::::::I can't say I really like the idea of {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}. I'd prefer creating [[Template:pbc]] and [[Template:phc]].<br />
::::::::::I still don't get what's wrong with [[Template:Sandbox]]. It should just work:<br />
<br />
<pre<noinclude></noinclude> {{#if: code|style="margin-bottom: 0; border-bottom:none; padding-bottom:0.8em;"}}>prompt # command</pre<noinclude></noinclude>><noinclude><!-- The &lt;noinclude>&lt;/noinclude> hack is needed to allow wiki markup inside the pre tags; reference: http://www.gossamer-threads.com/lists/wiki/mediawiki/118688#118688 --><br />
{{#if: code|<pre<noinclude></noinclude> style="margin-top: 0; border-top-style:dashed; padding-top: 0.8em;">code</pre<noinclude></noinclude>>}}<br />
<br />
:::::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 04:43, 18 September 2019 (UTC)<br />
<br />
:::::::::::FWIW (and a bit of fun) I've fixed [[Template:Sandbox]], although I'm not sure if we really need that level of automation ^^ I stick to my position above, is there a third (or more) opinion? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:48, 18 September 2019 (UTC)<br />
<br />
:::::::::I think you like the [https://wiki.archlinux.org/index.php?title=User_talk:Nl6720&diff=447834&oldid=447833 #800080] shade of purple, right? ;-) [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:39, 21 September 2019 (UTC)<br />
<br />
::::::::::Yes, I do like that one :D but I think it would be too bright for this template. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:52, 21 September 2019 (UTC)<br />
<br />
== Buggy graphics driver ==<br />
<br />
Can there be a hint that nomodeset parameter could be used if the graphics driver is buggy (I've heard nouveau may be buggy sometimes)<br />
[[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 04:47, 12 May 2020 (UTC)<br />
<br />
== GitLab blobs in Lynx ==<br />
<br />
Links to files (blobs) on gitlab.archlinux.org are not readable in Lynx (or any other console web browser); see https://gitlab.com/gitlab-org/gitlab/-/issues/26567.<br />
<br />
Should the Installation guide link to raw files instead?<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:29, 4 August 2020 (UTC)<br />
<br />
:Maybe you could ask svenstaro to add it to https://gitlab.com/gitlab-org/gitlab/-/issues/232073... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:36, 4 August 2020 (UTC)<br />
<br />
::It has been filed under [https://gitlab.com/gitlab-org/gitlab/-/issues/232073#nice-to-have nice to have]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:19, 4 August 2020 (UTC)<br />
<br />
== RAM usage ==<br />
<br />
Attempting to boot the ISO with 532MB RAM (VM) and it hangs at attempting to mount the ISO.<br />
Changing RAM to 544MB allows the Arch ISO to boot, so I suspect the amount of RAM needed on the page isn't accurate. [[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]]) 14:11, 17 August 2020 (UTC)<br />
<br />
:[https://wiki.archlinux.org/index.php?title=Installation_guide&diff=632251&oldid=631819 Updated again]. Note that after installation the system can still easily get under 512 MB. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:05, 17 August 2020 (UTC)<br />
<br />
:: Lahwaacz, it's missing fullstop "{{ic|.}}" in the end of this sentence. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 23:49, 17 August 2020 (UTC)<br />
<br />
::: Actually not missing (found it just now), but should it be after the reference link? -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 23:51, 17 August 2020 (UTC)<br />
<br />
::::It's used the same way also in [[Installation guide#Select the mirrors]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:01, 18 August 2020 (UTC)<br />
<br />
:::::From what I've seen, most wiki pages use it the same way. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:52, 19 August 2020 (UTC)<br />
<br />
::::::There is actually an open discussion about this: [[Help talk:Style/Formatting and punctuation#Reference links before or after punctuation marks?]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:05, 19 August 2020 (UTC)<br />
<br />
== Boot issues faced when installing on modern machines. ==<br />
<br />
One may encounter "Invalid signature" when trying to boot from the installation media on a machine with secure boot on and keys not cleared. <br />
<br />
Also, after installing on a NVME SSD, one need to set the drive to AHCI mode instead of Intel Optimized (in bios configuring panel), otherwise you just can't boot into the system.<br />
<br />
[[User:Sffred|Sffred]] ([[User talk:Sffred|talk]]) 00:05, 24 September 2020 (UTC) Sffred 1600905886<br />
<br />
:AHCI is a SATA controller operation mode, it shouldn't have anything to do with NVMe. You can add a section to [[Partitioning#Troubleshooting]] about changing the SATA mode if Linux doesn't see SATA disks, but make sure you're using the correct terms. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:27, 25 September 2020 (UTC)<br />
<br />
::Some motherboards support SATA over the [[w:M.2|M.2]] port, which may be the source of this confusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:33, 25 September 2020 (UTC)<br />
<br />
:::[[w:M.2#Storage interfaces]] lists "PCI Express using AHCI" as an option, but it's unclear if such a mode is actually implemented by any firmware, and even if it was, it should not be recommended as it would drastically reduce the drive's speed. From what I could find[https://forums.anandtech.com/threads/nvme-drive-booting-in-ahci-mode.2500796/post-39852218][https://lore.kernel.org/linux-pci/20190620061038.GA20564@lst.de/T/][https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aecec8b60422118b52e3347430ba9382e57d6d76], it looks like manufacturers simply interpret "SATA mode" being set to "AHCI" on NVMe controllers to mean "use native operating mode without firmware RAID". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:33, 25 September 2020 (UTC)<br />
<br />
:::While on the topic of SATA (and non-SATA) operating modes, any thoughts about the backup GPT header corruption warning in [[GPT fdisk#Convert between MBR and GPT]]? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:37, 25 September 2020 (UTC)<br />
<br />
::::Sorry, I have no idea... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:57, 26 September 2020 (UTC)<br />
<br />
:I added a note about [[Secure Boot]] to [[Installation guide#Boot the live environment]]. If anyone's wondering why it says "installation image'''s'''" then that's because of {{ic|ipxe.efi}} (the EFI binary for [[Netboot]]). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:52, 28 September 2020 (UTC)<br />
<br />
== Swap partition vs swap file ==<br />
<br />
Would it be reasonable to stop suggesting using swap partitions and instead recommend creating a swap file? Will genfstab work in a chroot environment to create a correct fstab?<br />
[[User:Managor|Managor]] ([[User talk:Managor|talk]]) 12:50, 3 February 2021 (UTC)<br />
<br />
:There's no reason why swap files should be given preference over swap volumes, using one or the other (or both) is a choice left to the user. [[Installation guide#Example layouts]] already mentions swap files, although, maybe some reference to them could also be added to [[Installation guide#Format the partitions]] and [[Installation guide#Mount the file systems]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:51, 4 February 2021 (UTC)<br />
<br />
== /etc/hosts: dual ip4/ip6 localhost prevents ip4 from working ==<br />
<br />
I recently set up a new system with /etc/hosts copied from the guide:<br />
{{bc|<br />
127.0.0.1 localhost<br />
::1 localhost<br />
127.0.1.1 myhostname.localdomain myhostname<br />
}}<br />
<br />
I found localhost did not resolve to {{ic|127.0.0.1}} which caused some docker comms to fail etc.<br />
<br />
Removing or renaming the ip6 binding allowed ip4 localhost to work again, so perhaps the following should be used in the guide instead:<br />
{{bc|<br />
127.0.0.1 localhost<br />
::1 ip6-localhost<br />
127.0.1.1 myhostname.localdomain myhostname<br />
}}<br />
<br />
{{unsigned|09:18, 19 February 2021|Alexheretic}}<br />
<br />
== Post-installation ==<br />
<br />
I skipped steps in the guide so I faced a weird crash in gnome without any explanations. I suggest a note.<br />
<br />
{{Note|Many of them assume that you have your timezone or locales set up. Make sure you have followed all the steps.}}<br />
<br />
[[User:Escope|Escope]] ([[User talk:Escope|talk]]) 10:11, 2 April 2021 (UTC)<br />
<br />
:The reader is supposed to follow all the steps. If we apply that to other pages, the pages need a boatload of notes to make sure the reader did not skip any steps. A common functional system has properly configured locales and timezones.<br />
:Since this is GNOME-specific however I would at most add a section into [[GNOME/Troubleshooting]] or even [[General troubleshooting]], but I still think this is out of scope to be honest. Many applications may not work properly when the timezones or locales are not correctly configured.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 15:30, 2 April 2021 (UTC)<br />
<br />
::The reader is not supposed to follow all the steps in case one doesn't worthy of attention. In my humble opinion, that's why it has huge advantage over the "Next-Next-Finish" approach. Unconfigured locales or timezones are obvious to many people, but my inexperience made me spend some time to sorting out. The other pages are highly deep and clear about the steps and why they are needed, my eyes enjoy such notes, pages are boatloaded already and I like it a lot =D. Thank you for your attention to this little change.<br />
<br />
::-- [[User:Escope|Escope]] ([[User talk:Escope|talk]]) 00:23, 3 April 2021 (UTC)<br />
<br />
:::If you're inexperienced, what makes you think you can judge if a step is necessary or not? You thought you knew better than the people that wrote the guide and found out that you didn't. Not something that needs changed here IMO.<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 01:57, 3 April 2021 (UTC)<br />
<br />
:::The ArchWiki should also be about the why-aspect. I am in favor of adding e.g a note about why they are needed and why some applications may crash or behave strangely without properly configured timezones/locales. If you know e.g a nice blog post about this topic, why not add something like this?<br />
:::{{Note|Some applications may behave in strange ways or even crash when the timezones and/or locales are not properly configured. See [https://xkcd.com/1084/ this informative blog post] to know why that is.}}<br />
:::The note needs obviously some rewording, but something like this would fit in well in my opinion.<br />
:::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:02, 3 April 2021 (UTC)<br />
<br />
::::Adding a '''brief''' "why" would be ok, but using [[Template:Note]] would be too much. I've also always wanted to emphasize the "and" in [[Installation guide#Localization]], since it's easy to miss (even some of the translated installation guides do not mention {{ic|en_US.UTF-8 UTF-8}}). --- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:48, 3 April 2021 (UTC)<br />
<br />
:::::People who want to know the "why" can already consult the relevant articles. That said, consistency is lacking: some sections explain in detail why a step should be performed (such as [[Installation_guide#Verify_signature]]), whereas [[Installation_guide#Configure_the_system]] is mostly a checklist of steps with brief instructions how. The solution isn't obvious: adding notes all over would likely more distract than clarify. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:41, 14 April 2021 (UTC)<br />
<br />
::::::I'm definitely apposed to adding notes, but I don't see why we couldn't add brief "why"s without them. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:55, 15 April 2021 (UTC)<br />
<br />
== Network Configurarion localdomain ==<br />
Hello!<br />
<br />
Is ".localdomain" string to be added as it is? Isn't localdomain supposed to be set by user like ''myhostname''?<br />
<br />
If yes, then that should be reflected in the Installation Guide as:<br />
<br />
...<br />
<br />
Add matching entries to {{man|5|hosts}}:<br />
<br />
{{hc|/etc/hosts|<br />
127.0.0.1 localhost<br />
::1 localhost<br />
127.0.1.1 ''myhostname''.''localdomain'' ''myhostname''<br />
}}<br />
...<br />
<br />
[[User:Rootkea|Rootkea]] ([[User talk:Rootkea|talk]]) 04:42, 9 April 2021 (UTC)<br />
<br />
:[[w:.local]] serves a special purpose, but {{ic|.localdomain}} indeed seems a placeholder with no special meaning. I'll make the change, thanks. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:44, 14 April 2021 (UTC)<br />
<br />
::The question now is, if it's a placeholder, what do you replace it with? Not every system has (or needs) a real domain name. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:00, 15 April 2021 (UTC)<br />
<br />
::So I don't need a hostname, I can just put localhost , right? [[User:Highfrequencyhertz|Highfrequencyhertz]] ([[User talk:Highfrequencyhertz|talk]]) 19:18, 10 June 2021 (UTC)<br />
<br />
:::FWIW, I don't have anything related to localhost in my /etc/hosts on a laptop... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:39, 10 June 2021 (UTC)<br />
<br />
::::Should a note be added to the wiki explaining that it is optional or not needing to be substituted by anything? I think that leaving it as is could be confusing. [[User:Highfrequencyhertz|Highfrequencyhertz]] ([[User talk:Highfrequencyhertz|talk]]) 02:41, 12 June 2021 (UTC)<br />
<br />
:::::Indeed, this confused me while updating this section in [[Installation guide (Français)]]. I think this needs to be expanded to explain why one should fill it or not (but nothing more in the "Installation guide" IMO). Maybe this could link to [[Network configuration#Local hostname resolution]] have it explained there. [[User:Nophke|Nophke]] ([[User talk:Nophke|talk]]) 07:29, 9 July 2021 (UTC)<br />
<br />
== fstab is optional in some cases ==<br />
<br />
When using a GPT-partitioned disk, partition with the right partition types, and booting with systemd, [[Systemd#GPT_partition_automounting|creating fstab is optional]].<br />
<br />
Could a hint on this be added to the fstab section? [[User:Hobarrera|Hugo Osvldo Barrera]] ([[User talk:Hobarrera|talk]]) 19:23, 8 July 2021 (UTC)<br />
<br />
:This is a very specific case (for [[systemd-boot]]), while an explicitly generated fstab works with any boot loader. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:43, 9 July 2021 (UTC)<br />
<br />
::It seems that [[REFInd#LoaderDevicePartUUID|Refind can set the LoaderDevicePartUUID variable too]], so should work as well. It's only optional for those boot loaders though, you're right. What I have in mind is a note with a link to the above link, so that readers can figure out if it's optional for them or not, not an actual statement that it's always optional, since that would not be accurate. [[User:Hobarrera|WhyNotHugo]] ([[User talk:Hobarrera|talk]]) 11:51, 9 July 2021 (UTC)<br />
<br />
== Add link to ALSA firmware in the Install essentials packages section ==<br />
<br />
With sof-firmware gaining more and more traction on newer systems it might be useful to add a link or piece of information that this might be necessary for newer laptops/cards, see [[Advanced_Linux_Sound_Architecture#ALSA_firmware]]. We currently get pretty much daily reports on the BBS where someone wonders where their sound card has gone. I know this is "technically" included in the "install additional firmware not included in linux-firmware" line, but since this is something that hasn't really been necessary for years this is potentially something not everyone is immediately aware of. [[User:V1del|V1del]] ([[User talk:V1del|talk]]) 17:15, 13 August 2021 (UTC)<br />
<br />
:Even with a link to [[Advanced_Linux_Sound_Architecture#ALSA_firmware]], it might be confusing that it applies based on the hardware, even when the user wants to use [[PulseAudio]] or [[Pipewire]]. Is there a better place where audio firmware could be described? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:00, 13 August 2021 (UTC)<br />
<br />
::I tried to have some sort of "standardized" snippet on laptop pages when it needs ALSA firmware, but the ArchWiki is not a hardware db and we cannot document all pieces of hardware. Audio is not essential for some users but a few depend on screenreaders, which is crucial to accessibility.<br />
::In the end it might not cause harm to install sof-firmware when in doubt.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 01:17, 14 August 2021 (UTC)<br />
<br />
:::I mean if we cover firmware in e.g. [[Sound system]] and link to that instead of ALSA, it would seem much more general. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:19, 14 August 2021 (UTC)<br />
<br />
::::Well for this particular case you can fairly easily identify whether you have a need for sof-firmware with an {{ic|<nowiki>lsmod | grep snd_sof</nowiki>}} or a {{ic|<nowiki>dmesg | grep -i sof</nowiki>}}, but yes might be helpful to move that somewhere else if we want to ensure to have hardware based separation here. [[User:V1del|V1del]] ([[User talk:V1del|talk]]) 12:04, 14 August 2021 (UTC)<br />
<br />
:::::I [[Special:Diff/692787|added]] {{Pkg|sof-firmware}} as an example (and the aforementioned link) so that there's at least something for now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:20, 25 August 2021 (UTC)<br />
<br />
== Add a link to [[Solid_state_drive]] or storage device specific pages before/during partitioning step ==<br />
Some pages like [[Solid_state_drive]] are nearly impossible to get to from just following the Installation Guide. This is problematic as some recommendations from these pages are only relevant '''before''' installation, as it is too late afterwards (notably for setting native sector size as in [[Solid_state_drive#Native_sector_size]]. I believe there should be a note in the partitioning step, something like modifying this line: <br />
* If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now.<br />
to <br />
* If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now. Also check [[Improving_performance#Partitioning]] or [[Solid_state_drive]] for storage device specific information.<br />
As an alternative, this could be added to [[Partitioning]], but it's already quite big...<br />
-- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 15:47, 29 August 2021 (UTC)<br />
<br />
== <s>Point out archinstall</s> ==<br />
[[Archinstall]] has been canonicalized as an official install path, so that should be reflected here. I suggest that the document be split into three main sections, the first titled, "Prerequisites", second titled "Guided install - archinstall", and the final titled "Manual install". Most of the current document would be moved under the manual install section. I'm happy to write a first draft for these changes if this sounds good. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:48, 2 September 2021 (UTC)<br />
<br />
:It's already in [[:Category:Installation process]], which is linked from the installation guide, together with [[systemd-firstboot]], [[archboot]] and other methods. If you want to draft an expanded process for the guided installer, [[Archinstall]] is the place for it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:07, 2 September 2021 (UTC)<br />
<br />
::Yes, understand that there are many ways to install Arch. In April it was announced on main page news, "Arch now includes a guided installer". That implies this is ''the'' canonical guided installer. Not specifically addressing it here is in conflict with that, creates confusion, and seems a missed opportunity (as a Linux user since before Arch existed, I've lost track of the number of times I've heard people complain about Arch's manual-only onboarding.) [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:03, 2 September 2021 (UTC)<br />
<br />
:::The [https://archlinux.org/news/installation-medium-with-installer/ announcement] does not imply that Archinstall is the canonical installer, guided or whatever. It only says that the installation medium ''provides'' another installation method and it even explicitly says that the ''default'' installation method is still the one described on this page ([[Installation guide]]). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:41, 2 September 2021 (UTC)<br />
<br />
::::You're right, it's not implied, it is explicit [verbatim quote, emphasis mine]: "This '''''addition to''' the '''default''' method'' of installation". Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:17, 2 September 2021 (UTC)<br />
<br />
:::::As I said before, it's already addressed. Every page in [[:Category:Installation process]] is an "addition" to the installation guide, and that category is linked from the guide. There's no reason to single out archinstall from say, the bootstrap image or [[archboot]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:04, 2 September 2021 (UTC)<br />
<br />
::::::This does not reflect the clear tone of the announcement, and feels like a disservice to the community. Arch had a guided installer as default until 2012, when the primary maintainer stepped down due to burnout. The wiki became the de-facto source of truth soon after, due to the lack of a mature, supported, guided installer option. The announcement that there's again a maintained guided installer as a default option is something many would welcome. Please please update the install guide. Again, I'm happy to write a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:35, 3 September 2021 (UTC)<br />
<br />
:::::::Again: '''there is no guided installer as a default option'''. You are misinterpreting the announcement where the word "addition" means "supplement", not "inclusion". It is an additional installation option, '''not''' part of the default installation option. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:17, 3 September 2021 (UTC)<br />
<br />
::::::::Is this what Giancarlo has explicitly said to you or your own interpretation of the announcement? The wording is clear, and it's a great stretch to try to interpret it the way you are proposing. I would not be alone, or even in the minority, in assuming that "addition to" means inclusion, especially given that both to title and first sentence iterate that it "'''''now''' provides a guided installer''" (the implicit statement being that it did not previously, and this is a change to the status quo). [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:25, 3 September 2021 (UTC)<br />
<br />
:::::::::It seems to me you're interpreting things into the announcement. Archinstall is part of the installation process. Will it eventually become the indicated method of installation? I don't know, but I don't think so. Heck, in the future we might even have an ISO with archinstall gui, who knows? All I'm saying is, as of now, archinstall is an addition, nothing more, nothing less. It '''is''' official, but that doesn't mean it's the indicated method on the installation guide. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 12:48, 3 September 2021 (UTC)<br />
<br />
::::::::::Thanks for clarifying. Please note I'm not suggesting it become ''the'' method. I'm just suggesting it have a prominent mention in the guide before the manual process. Note also what I've written below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:18, 3 September 2021 (UTC)<br />
<br />
:::::::::::Instead of trying to create conflict where there is none, or trying creative interpretations of the announcement, I think it would be more productive for you and for us if you tell us '''why''' you think archinstall should be prominently mentioned on the installation guide page. --[[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 01:13, 4 September 2021 (UTC)<br />
<br />
::::::::::::I've attempted to do that in the section I wrote yesterday immediately below this. If you have questions or feel I should expand this rationale, I'm all ears. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:04, 4 September 2021 (UTC)<br />
::::::::::::I'm also trying very deliberately to avoid conflict by simply addressing the topics at hand in a clear and straightforward, unemotional manner. I've received significant pre-emptive resistance and denial to good-faith proposals to improve the state of the distro and documentation, with little justification, and have taken care to point out how this behavior is limiting progress. I feel like I shouldn't have to point out that in the spirit of creating an open and inclusive community, it is wise as a community ambassador to try and ensure that you are maintaining an unbiased and open-minded forum. I'm a new user who has actively contributed valuable technical content, and is offering to contribute more, and am being treated with defensive emotional remarks (not on your part, Giancarlo... this has been in my dialogue with Alad and Lahwaacz) while offering no malice or ill-intent in return. I'm sincere in my desire to help and hope that this is clear. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:17, 4 September 2021 (UTC)<br />
<br />
:::::::::::::Now you're escalating to making personal attacks on staff. More-so, in a public setting you're implying one staff member should perform punitive action on another merely because you don't get things your way. This will be your first and only warning on this kind of behavior. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
::::::::::::: In [https://en.wikipedia.org/wiki/De-escalation de-escalation], the most important thing is to stay high on the [https://en.wikipedia.org/wiki/De-escalation#/media/File:Graham's_Hierarchy_of_Disagreement-en.svg pyramid]. I'm guilty of falling down it some, as everyone is, on occasion. I want nothing to happen against you or Lahwaacz; I wish you very well and hope you've been having an enjoyable weekend. I'm trying only to encourage that we stick to the topics at hand and not hold too tightly to our beliefs. I'm happy to have my mind changed! It means I've learned something. :D [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:24, 5 September 2021 (UTC)<br />
<br />
::::::::::::: Also, my sincere apology if this has come across as an attack! I don't want any of this to be personal. I appreciate deeply the care and commitment that goes into maintaining a clear body of knowledge for an important topic, and want to thank you both for the degree that you clearly show of caring in that same way. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:38, 5 September 2021 (UTC)<br />
<br />
::::::::::::: I'll point out one of my own failings in my discussions with you. I've been lazy in my use of language. Sometimes I say I've refuted something, when really I mean that I've offered a convincing counterargument (following the notation of the pyramid). I'll try to be more conscious of this going forward. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
:Further rationale for including the archinstall process here: Having a primary, guided, install path is a nearly universally accepted practice in the OS world; Arch is not Linux-From-Scratch. Arch never deliberately avoided having one for a philosophical reason, it simply had a role in providing and maintaining one go unfilled for the last nine years. In researching the reaction online to the archinstall announcement, the dominant reaction was one of relief. For those concerned, I saw comments suggesting that the support burden might be increased by switching back to a guided installer. Others suggested that, "If people are too dumb to follow the wiki, they shouldn't be using Arch." Both concerns are ill conceived though. I'll address them below:<br />
<br />
* Support burden<br />
** The original impetus to fork CRUX and create Arch in 2002 was to make pacman. Pacman automates package management, and the key innovation was better tracking of what files come from what package. Pacman, along with rolling-release, are the true defining features of Arch. Pacman makes the system far less prone to breakage, because as is said in [[System_maintenance#Use_the_package_manager_to_install_software|System maintenance]], "If you install things manually you will, sooner or later, forget what you did, forget where you installed to, install conflicting software, install to the wrong locations, etc." This is even more important and even more true for the initial install! Having a guided install which is handled by a tested, repeatable, automated process will only be better for support! This is a pretty universally accepted principle in software development.<br />
* Hazing / too dumb<br />
** This attitude just creates an elitist community which is looked on with scorn from the outside. It is not a good look for Arch, which I'll remind means "the primary," with the intent of being the absolute best there is. It is not in line with the [https://terms.archlinux.org/docs/code-of-conduct/#respect-other-users Code of conduct], which states unequivocally, "Arch Linux is a respectful, inclusive community. Anti-social or offensive behaviour will not be tolerated."<br />
-- [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:45, 3 September 2021 (UTC)<br />
<br />
:This whole argument is completely tangential. The installation guide is the primary installation method because it is the most universal, whereas other methods can only cover specific use-cases. As pointed out above, Archinstall is ''one'' of those additional installation methods. Users who want a guided install path have other available options, like [[systemd-firstboot]] and [[Archboot]]. If that's not clear enough from [[:Category:Installation process]], that should be discussed there. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:39, 3 September 2021 (UTC)<br />
:: Regarding, "because it is the most universal." Then preface the section on archinstall with a paragraph like this: "Archinstall is the preferred guided installer process. However, we have just recently added it as a process, and it is not yet as applicable to all use cases as the manual process. Below are some reasons you may prefer or need to use the manual process below instead: ..." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 20:14, 3 September 2021 (UTC)<br />
<br />
::: No, archinstall is not the preferred guided installer process, it is one possible guided installer process of three (the others being archboot and systemd-boot, as pointed out multiple times). Also, as any guided installer, it can never be applicable to all use cases. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:25, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "Users have other guided install options." Systemd-firstboot is not arch specific and is very limited in what it can achieve. It's not an installer for Arch, more a post-install tool. Archboot is ''unofficial'', per it's own wiki page. Archinstall is the only official guided installer, per the announcement (and Giancarlo's reiteration above, with emphasis). [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:36, 3 September 2021 (UTC)<br />
::::: systemd-firstboot is very similar in principle to archinstall- both offers a series of prompts to automate steps for installing a system. Archboot is not more or less unofficial than archinstall. Every mirror includes an ISO containing it, and a developer maintains it. Otherwise, your choice which of the three you prefer is exactly that - your choice. Other users have to decide that for themselves. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]])<br />
<br />
::::Regarding, "It can never cover all use cases." Yes, sure. But is there anything in the manual guide that couldn't theoretically be included in an automatic guide? Feature parity ought to be an achievable goal. People with use cases outside of what's covered in the guide are probably confident enough forging their own path anyway. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:42, 3 September 2021 (UTC)<br />
:::::There's a huge amount of options one can achieve by doing a manual install, starting from what's linked in the install guide and eventually reaching most pages in the wiki. An automated installer can never achieve that. It might ''try'', but doing so is going to add a major maintenance effort to the installer authors and not achieve parity anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
::: If you want to go into detail why someone may prefer the installation guide over archinstall, then that belongs in [[Archinstall]]. Right now, the latter only mentions specific choices for boot loader and network configuration, and I'm sure there's more to tell. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:25, 3 September 2021 (UTC)<br />
::::I am proposing that I write out those details, yes. I'm just saying the appropriate place is on [[Installation guide]], as that's what people are pointed at when they boot the ISO. That's what people are referencing when they're thinking, "How should I install this?" A clear decision flow which includes all official options should be on Installation_guide, not elsewhere. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:53, 3 September 2021 (UTC)<br />
<br />
:::::No, the appropriate place is whatever article is relevant to what you want to add. We're not going to add all the details for say, [[Install from SSH]] either. If you want some "clear decision flow which includes all official options" you can, as I already pointed out, propose something on [[Category talk:Installation process]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
: Another reason prioritizing a mature default guided install is a good idea for Arch - Currently, if I want someone to try Arch I either have to offer them a pre-built VM of my own cooking, or try to convince them to spend an hour or more wading through the wiki to get to a point they can start exploring pacman and AUR and appreciating the rolling-release model, or just tell them, "boot up one of the popular Arch derivatives' live environments and ignore their chrome." I'd much rather just point them here and say "Run archinstall, it takes 5 minutes and has sensible defaults." It's interesting to note that interest in Arch has been on a [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png consistent downtrend since 2012], when the existing guided installer was deprecated. Wider interest and adoption can pull in more developers. Just in the last few months, NixOS has overtaken pacman/AUR in package coverage, both in terms of being [https://repology.org/repositories/statistics/newest up to date] and in terms of [https://repology.org/repositories/statistics/total total repositories]. Arch risks losing relevance if package maintenance falls behind the competition. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:55, 4 September 2021 (UTC)<br />
::To further drive this, also note from [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png this chart] that interest in distros which rely upon pacman/AUR is at a boiling point! The whole Arch ecosystem is now arguably the largest of all the Linux ecosystems there are in terms of total interest. Ignoring the factors of the rapidly growing success of derivatives could compromise Arch's future. With the meteoric rise of strong competition to pacman/AUR, this is pressing and critical. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:22, 4 September 2021 (UTC)<br />
<br />
:::The main reason, at least for me, that archinstall was added to the repositories and to the ISO, was that the archiso was not very accessible. Having a guided installer, plus the accessibility improvements made to the ISO, can allow more people to install Arch. However, archinstall has one unintended "feature": People will install Arch using it, without reading any documentation, just to find out that keeping an Arch system going is the hard part, not installing it. Arch is not a company, a business and one of the reasons it is great, is that it's one of the few standing truly community driven distributions out there. With that being said, I think we could add to the ISO some documentation also mentioning archinstall. However, I think the installation guide should remain as it is. It already mentions on the first paragraph that there are other methods for installation. --[[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 14:24, 4 September 2021 (UTC)<br />
::::Regarding, "People might install without knowing how to maintain." I think people find that with any Linux if they are unfamiliar and unwilling to learn. Arch at least has one of the largest communities, some of the best documentation, and one of the harder to break environments (though perhaps a warning which requires overriding if you try to run 'pacman -Sy' would be a nice touch... even one well informed may slip up and commit an error with a simple typo, currently). It's also why I see it being practical to still lean on encouraging people to figure out more by pointing them to the guide and using that as the decision flow tool (with a good heaping of reminding that it's important to develop an understanding of the architecture and means of configuring the major components if you want to get the most out of the system). [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:49, 4 September 2021 (UTC)<br />
::::Regarding, "Might be better to just mention archinstall on the ISO boot." If the direction is to include mention of archinstall in the ISO boot message, I'd be happy if the decision on whether to use it or the manual process has a decision tree written out on the archinstall page instead. I still think having one source with a simple decision flow for all the supported install approaches is the better solution though. That way one who does go to the install guide before downloading and booting the ISO has everything clearly laid out for them in a flow that addresses the most pressing questions one might have if they, with no previous knowledge of Arch, had jumped from the main page, to the download page, to the first link there, [[Installation guide]]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:49, 4 September 2021 (UTC) <br />
::FWIW: If you need a VM image, you can use the officael VM images from the [https://gitlab.archlinux.org/archlinux/arch-boxes arch-boxes] project. [[User:Klausenbusk|Klausenbusk]] ([[User talk:Klausenbusk|talk]]) 15:40, 4 September 2021 (UTC)<br />
<br />
== Add information about packages included in the installation environment ==<br />
:Currently, the install section only has this to say about packages beyond core which are available in the live environment, "''For comparison, packages available in the live system can be found in [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64].''" It's just a link to a list of over 100 packages, with no explanation of why they're included or what they do. Perhaps a page which categorizes them, includes a brief summary of each, and includes a link out to more about the package would help those looking to better understand the live environment and considering which packages to include in their install. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:22, 9 September 2021 (UTC)<br />
:: This would create a significant maintenance overhead for little actual benefit. Anyone actually interested in what specific packages do can easily research them; we even have links to the man pages now to facilitate this. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 02:30, 9 September 2021 (UTC)<br />
<br />
::: To me, this statement reads as self-contradictory. If it is so easy, then the maintenance would be equal, since what I'm proposing is effectively just the notes from someone following the process you propose. One person doing it once for the benefit of all is much simpler than everyone who ever takes an interest in this doing it from scratch. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:01, 9 September 2021 (UTC)<br />
<br />
:::: It's easy to look up the packages ''where that information is maintained'' (ie., https://archlinux.org/packages/) . It is a maintenance overhead to maintain two separate lists, one the canonical source and the second a mirror--on the wiki. Is that simple enough to understand? Or do you still consider that a contradiction? [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:31, 9 September 2021 (UTC)<br />
<br />
::: To put it more concisely, tl;dr exists as a popular package and is a widely appreciated idiom precisely because topical summaries are mindful of the constraints one has on time and interest. Or, for the algorithm-minded, breadth-first search is preferred in most cases to depth-first search.<br />
<br />
:::: I have no idea what ''any'' of the above means... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:31, 9 September 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Installation_guide&diff=695078Talk:Installation guide2021-09-09T02:30:54Z<p>Jasonwryan: /* Add information about packages included in the installation environment */ Nope: more maintenance for no gain</p>
<hr />
<div>== Read this first before adding new suggestions ==<br />
<br />
* systemd tools such as ''hostnamectl'', ''timedatectl'' and ''localectl'' [https://github.com/systemd/systemd/issues/798#issuecomment-126568596 do not work] in the installation chroot environment, so please do not propose to use them in the guide unless you can prove that they have been made to work also in that case. See [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=388727#General_problems], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=404695#Replace_commands_with_their_systemd_equivalents], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=418662#Utilizing_systemd_tools] and [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=434985#change_configuration_system_from_old_way_to_new_way.28using_systemd_commands.29] for some past discussions about this issue.<br />
* {{ic|localectl list-keymaps}} does not work due to bug {{Bug|46725}}. For the chosen replacement command, see [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=435044#localectl].<br />
* {{ic|localhost}} must be set explicitely in {{ic|/etc/hosts}}, as it is otherwise resolved over the network. See {{Bug|56684}}.<br />
* Due to the wide variety of available boot loaders, the installation guide refers to [[Arch_boot_process#Boot_loader]] instead of making a specific recommendation for the installed system. See [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=687325#Bootloader], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=690612#Make_the_Boot_Loader_Section_slightly_more_detailed_to_provide_a_high_level_overview_for_new_users], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=678949#Expand_Boot_loader_section], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=660151#Expand_Boot_loader_section_to_include_example_commands], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=581427#Boot_loader_installation] for some past discussions on this topic.<br />
-- [[ArchWiki:Administrators|The ArchWiki Administrators]] 22:17, 2 September 2016 (UTC)<br />
__TOC__<br />
<br />
== Link to the German version ==<br />
<br />
Instead of [[de:Arch Install Scripts]] you could choose [[de:Anleitung für Einsteiger]] it means "Beginner's Guid" and is a very <br />
detailed artikel for very new arch users and the future experts.<br />
<br />
:Thank you, [https://wiki.archlinux.org/index.php?title=Installation_guide&type=revision&diff=509961&oldid=508505 done]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 6 February 2018 (UTC)<br />
<br />
::This was already proposed last year and rejected: [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=466950#Suggesting_different_page_for_German_translation]. I don't see what has changed since then. If someone adds me as admin to the german wiki or changes the protection settings, I can update [[de:Arch Install Scripts]] as required. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:13, 6 February 2018 (UTC)<br />
<br />
:::I see, I didn't remember that discussion so I've reverted the change, hopefully you'll make it to update the translation, let's leave this open until the problem is solved, otherwise this kind of suggestion will keep appearing recurrently. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:53, 7 February 2018 (UTC)<br />
<br />
::::Apparently since last year the translation has been halved in size, but its scope is still much larger than the [[Install guide]] (or even the old [[Beginners' guide]]). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 9 May 2021 (UTC)<br />
<br />
== Why should a static IP be preferred over 127.0.1.1 in /etc/hosts? ==<br />
<br />
"If the system has a permanent IP address, it should be used instead of 127.0.1.1."<br />
<br />
I think the ArchWiki should not just say do X but also why. [[User:Alad|Alad]] as you added this, perhaps you can explain?--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:14, 21 May 2018 (UTC)<br />
<br />
:In [[Network_configuration#Local hostname resolution]]: "For a system with a permanent IP address, that permanent IP address should be used instead of 127.0.1.1." -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:48, 22 May 2018 (UTC)<br />
<br />
::[https://wiki.archlinux.org/index.php?title=Network_configuration&diff=340138&oldid=333485 First] appearance in our wiki, cited [https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution source], also [https://wiki.archlinux.org/index.php?title=Talk:Network_configuration&oldid=360328#Hostname_resolution discussion]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:26, 22 May 2018 (UTC)<br />
<br />
:::Clear enough, close. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 01:58, 10 August 2020 (UTC)<br />
<br />
::::This should be explained in the guide or at least in [[Network_configuration#Local hostname resolution]]. Explaining stuff in the edit summary or on talk pages is not enough. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:43, 10 August 2020 (UTC)<br />
<br />
== Wording in example layout table and size of EFI partition ==<br />
<br />
=== Formatting the ESP ===<br />
<br />
I believe myself that the partition table should be modified. When Going through the install, it was confusing how swap was the last partition, usually suppose to be the partition before Root, as if the computer loads up swap before user login. Didn't realize that a GPT disk needed to be formatted until reading this guide: https://wiki.archlinux.org/index.php/EFI_system_partition . Would recommend at least linking to this section of the document or even input Format partition section within the Wiki. [[User:Shaggy|Shaggy]] ([[User talk:Shaggy|talk]]) 20:15, 29 June 2020 (UTC)Shaggy<br />
<br />
:The order of partitions is irrelevant and it has (mostly) no effect on booting. The fact that the [[ESP]] needs to formatted after its creation cannot be simply stated, as it could be misinterpreted as requiring to always format it, even if is an existing partition that already has a file system.<br />
:After reading [https://bbs.archlinux.org/viewtopic.php?pid=1912222#p1912222 an anecdote], I think moving swap before root should be considered :D<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:39, 1 July 2020 (UTC)<br />
<br />
:I've been thinking, how about placing the {{ic|mkfs.fat -F32 /dev/sdxY}} command in [[Installation guide#Format the partitions]]. [[EFI system partition#Format the partition]] could instead be modified to omit the FAT type (i.e {{ic|mkfs.fat /dev/sdxY}}). FAT32 is a recommendation, but not mandatory, thus it's more appropriate for the [[Installation guide]], and this would allow to document the 2 MiB FAT12 formatted ESP, used by [[User:Eschwartz]] and others, in the [[EFI system partition]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:14, 13 August 2020 (UTC)<br />
<br />
::I guess that's reasonable, if you add the note that an existing EFI partition may have to be preserved. (cf. [[User:Alad/Beginners'_guide#Format_the_partitions]]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:10, 14 April 2021 (UTC)<br />
<br />
== HiDPI on the console ==<br />
<br />
With an ever increasing number of [[HiDPI]] displays, including at the begging of the article a section about adjusting the scaling factor or changing the font can be helpful, see [[HiDPI#Linux_console]]. [[User:Goetzc|Goetzc]] ([[User talk:Goetzc|talk]]) 02:21, 8 August 2019 (UTC)<br />
<br />
:It could be added as an example for {{ic|setfont}} in [[Installation_guide#Set_the_keyboard_layout]]. The issue I have is that [[HiDPI#Linux_console]] mentions that {{ic|tty2-6}} may be unusable, while the Installation guide specifically instructs to change ttys as required in [[Installation_guide#Boot_the_live_environment]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:07, 7 September 2019 (UTC)<br />
<br />
::May be as an example for the line "See README.bootparams for a list of boot parameters" [[Installation_guide#Boot_the_live_environment]], it could be specified to hit {{ic|e}} button to edit the boot entry and add the following parameters to the boot line, like {{ic|1=video=1920x1080}} if you have HiDPI display. -- [[User:Xzorg6|Xzorg6]] ([[User talk:Xzorg6|talk]]) 22:41, 15 December 2019 (UTC)<br />
<br />
:::{{ic|1=video=}} will just change the resolution. To get a bigger font on the console, you need {{ic|1=CONFIG_FONT_TER16x32=y}} in the kernel config and {{ic|1=fbcon=font:TER16x32}} in the kernel command line. Since the official kernels don't enable {{ic|CONFIG_FONT_TER16x32}}, someone will need to open a bug report asking for it. After that, the instructions for setting the {{ic|1=fbcon=font:TER16x32}} [[kernel parameter]] could be added to the wiki. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:52, 16 December 2019 (UTC)<br />
<br />
::::{{Pkg|linux}} 5.5.6.arch1-1 <s>(currently in testing)</s> has {{ic|1=CONFIG_FONT_TER16x32=y}} ({{Bug|64861}}). <s>If if gets move to core before March, then</s> the March iso will have it. It's probably a good idea to start drafting a [[Template:Tip|tip]] to place in [[Installation guide#Boot the live environment]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:12, 26 February 2020 (UTC)<br />
<br />
::::And just after I wrote this, the package was moved to core. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:27, 26 February 2020 (UTC)<br />
<br />
:::::I'm seeing multiple claims[https://bbs.archlinux.org/viewtopic.php?id=253319][https://www.reddit.com/r/archlinux/comments/fbi4vx/text_size_during_boot_changed_since_my_last/][https://www.reddit.com/r/archlinux/comments/fgct3t/how_to_get_currently_loaded_console_font_of_the/] that people with HiDPI screens are getting the TER16x32 font. I was not aware that the kernel chooses a font depending on screen size. Can anyone confirm that this really is the case? If it really works that way and unless {{Bug|65680}} messes this up, then there's nothing to add to the Installation guide about this topic. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:02, 11 March 2020 (UTC)<br />
<br />
::::::As per https://lkml.org/lkml/2019/6/18/966 the decision to use ter16x32 is not based on screen size but only resolution.So even though a 1080p screen may be hidpi it does not use ter16x32 [[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 10:17, 11 May 2020 (UTC)<br />
<br />
:::::::At least that part is now clear, thanks. The first step should be to get [[HiDPI#Linux console]] up to date. After that, as I've said before, a tip for the installation guide can be drafted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:04, 11 May 2020 (UTC)<br />
<br />
:::::::: I fixed the page and removed the template [[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 12:25, 11 May 2020 (UTC)<br />
<br />
== First mention of /mnt in example partition layout ==<br />
<br />
{{ic|/mnt}} is mentioned at mount point in [[Installation_guide#Partition_the_disks]], while {{ic|/mnt}} is made explicit two sections later in [[Installation_guide#Mount_the_file_systems]]. As I recall it, this was changed because some users blindly copy pasted commands and mounted /boot on the live system, instead of /mnt/boot. Some options:<br />
<br />
* Introduce another column describing the mount point on the installed system. <br />
* Actually explain /mnt early.<br />
* Revert the "mount point" to not include /mnt.<br />
<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:03, 7 September 2019 (UTC)<br />
<br />
:I don't understand what's the actual problem here... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 8 September 2019 (UTC)<br />
<br />
::From what I read on [[ArchWiki:IRC|#archlinux-wiki]], this comes from https://www.reddit.com/r/archlinux/comments/d0v0j3/is_it_just_me_or_is_the_prospect_of_installing/ where the user was confused by the lack of root mountpoint (i.e. {{ic|/mnt}} vs {{ic|/}}). A question could be raised, if we should concern ourselves with users who have strong opinions about the wiki content yet can't be bothered to propose improvements in the talk pages...<br />
::About Alad's proposed options: I disagree with the first option, I think it will just complicate things even further. I support the third option and maybe adjusting the column header like in [[Special:Diff/581800]].<br />
::I'd actually would like to go even further and change the commands run from outside chroot to be visually distinct, e.g.: {{bc|1=<span style="color: #ff0000;">root@archiso #</span> mount /dev/sd''X1'' /mnt}}<br />
::I think it would better solve the underlying issue. <br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:26, 8 September 2019 (UTC)<br />
<br />
:::I'm not overly fond of the longer column name. For the last proposed option, I may agree if this is formalized in [[Help:Style]], so that it is not specfic to the [[Installation guide]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:20, 10 September 2019 (UTC)<br />
<br />
::::Adding it [[Help:Style]] was my intention, since other articles, too, will need to use that style for some commands. I'm thinking of creating a template for it: [[Special:Permalink/581945]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:19, 11 September 2019 (UTC)<br />
<br />
:::::Sounds good to me, I'd just prefer the regular (non-bold) font for the prompt as above. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:54, 13 September 2019 (UTC)<br />
<br />
::::::[[Special:Permalink/582327]]. Are there any other opinions about creating such a template? Or should I take this discussion to [[Help talk:Template]] per [[Help:Template#Creation]]? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:31, 14 September 2019 (UTC)<br />
<br />
:::::::# How are you going to call the template? This template would probably add to the [[Help:Template#Code formatting templates]] series, should it be named in a consistent fashion?<br />
:::::::# Should this template support custom prompts, and if so, should it be called "pc" (from "(custom) prompted" code)?<br />
:::::::# I don't like the red color too much, if bold is not an option maybe we can go green|purple|blue, something that recalls less a warning of some kind? Or can we just leave it with the default font color? Or a slightly fainter black?<br />
:::::::# I haven't looked well into it, but maybe we can instead add an optional argument to [[Template:bc]] and [[Template:hc]] that prefixes a custom (colored) prompt? I wouldn't see a problem with repeating "root@archiso #" in every instance, or we may derive the new template from those two at that point.<br />
:::::::# The template should probably be derived from [[Template:bc]] in any case, for simpler code, see [[User:Kynikos/Template:Sandbox2]].<br />
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:36, 16 September 2019 (UTC)<br />
<br />
::::::::# Initially I was going to call it [[Template:Archiso]] since it would be [[Archiso]]-specific, but I'm starting to think that creating a more general-purpose template would be better. It could then be used in [[PostgreSQL]] and the {{ic|[postgres]$}} convention would get formalized in [[Help:Style]]. Now the issue is the {{ic|[user@peer-a]#}} in [[Template:hc]] used in [[WireGuard]]. I'd rather not create two new templates, but I'm having trouble getting [[Template:Sandbox]] to work :(<br />
::::::::# I like your "[[Template:pc]]" suggestion.<br />
::::::::# Be glad I didn't post my first draft that was ''slightly more'' colorful. From your offered colors, I'd choose purple.<br />
::::::::# I'd rather not mess with the established templates just for this change, so I'd prefer creating a new template.<br />
::::::::# I didn't even think about using [[Template:bc]]. Is it a good idea to do that? The new template might need to be updated if [[Template:bc]] is ever changed in an incompatible way.<br />
:::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:33, 17 September 2019 (UTC)<br />
<br />
:::::::::Yeah, after viewing your attempts and looking into it myself, I think modifying bc/hc is out of discussion, it would add too much code/style for so little use.<br />
:::::::::Thinking about this again one day after, I feel I'm realizing that my concerns in general may descend from the fact that we're going to create a template to represent (block) code, even though we already have 2 which basically do the same thing, including allowing to include a prompt; the only addition of this "Archiso" or "pc" template would be the formatting around the prompt, so why not keep it simple (I know, "simplicity" is often subjective and controversial) and instead either make a [[Template:Archiso]] to be used like {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or [[Template:ps]] (or [[Template:PS]]) to be used like {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}? They also work with [[Template:hc]] and space-prefixed code blocks!<br />
:::::::::Putting the choice of color aside, if the above idea of a standalone prompt template isn't welcome, I think my second choice would be to make two [[Template:pbc]] and [[Template:phc]] that work like {{ic|<nowiki>{{pbc|$|ls}}</nowiki>}} and {{ic|<nowiki>{{phc|$|ls|...}}</nowiki>}}, with the style rule to use them only in case of complex prompts. I'd still derive them from bc/hc to inherit any changes that we'd decide to make to them, and avoid repeating that ugly &lt;pre> hack even more.<br />
:::::::::Otherwise I give up and accept the [[Template:Archiso]] that works like {{ic|<nowiki>{{Archiso|mount /dev/sdX1 /mnt}}</nowiki>}}, in the hope that one day we won't need an analogous "hc" version.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 17 September 2019 (UTC)<br />
<br />
::::::::::I can't say I really like the idea of {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}. I'd prefer creating [[Template:pbc]] and [[Template:phc]].<br />
::::::::::I still don't get what's wrong with [[Template:Sandbox]]. It should just work:<br />
<br />
<pre<noinclude></noinclude> {{#if: code|style="margin-bottom: 0; border-bottom:none; padding-bottom:0.8em;"}}>prompt # command</pre<noinclude></noinclude>><noinclude><!-- The &lt;noinclude>&lt;/noinclude> hack is needed to allow wiki markup inside the pre tags; reference: http://www.gossamer-threads.com/lists/wiki/mediawiki/118688#118688 --><br />
{{#if: code|<pre<noinclude></noinclude> style="margin-top: 0; border-top-style:dashed; padding-top: 0.8em;">code</pre<noinclude></noinclude>>}}<br />
<br />
:::::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 04:43, 18 September 2019 (UTC)<br />
<br />
:::::::::::FWIW (and a bit of fun) I've fixed [[Template:Sandbox]], although I'm not sure if we really need that level of automation ^^ I stick to my position above, is there a third (or more) opinion? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:48, 18 September 2019 (UTC)<br />
<br />
:::::::::I think you like the [https://wiki.archlinux.org/index.php?title=User_talk:Nl6720&diff=447834&oldid=447833 #800080] shade of purple, right? ;-) [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:39, 21 September 2019 (UTC)<br />
<br />
::::::::::Yes, I do like that one :D but I think it would be too bright for this template. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:52, 21 September 2019 (UTC)<br />
<br />
== Buggy graphics driver ==<br />
<br />
Can there be a hint that nomodeset parameter could be used if the graphics driver is buggy (I've heard nouveau may be buggy sometimes)<br />
[[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 04:47, 12 May 2020 (UTC)<br />
<br />
== GitLab blobs in Lynx ==<br />
<br />
Links to files (blobs) on gitlab.archlinux.org are not readable in Lynx (or any other console web browser); see https://gitlab.com/gitlab-org/gitlab/-/issues/26567.<br />
<br />
Should the Installation guide link to raw files instead?<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:29, 4 August 2020 (UTC)<br />
<br />
:Maybe you could ask svenstaro to add it to https://gitlab.com/gitlab-org/gitlab/-/issues/232073... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:36, 4 August 2020 (UTC)<br />
<br />
::It has been filed under [https://gitlab.com/gitlab-org/gitlab/-/issues/232073#nice-to-have nice to have]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:19, 4 August 2020 (UTC)<br />
<br />
== RAM usage ==<br />
<br />
Attempting to boot the ISO with 532MB RAM (VM) and it hangs at attempting to mount the ISO.<br />
Changing RAM to 544MB allows the Arch ISO to boot, so I suspect the amount of RAM needed on the page isn't accurate. [[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]]) 14:11, 17 August 2020 (UTC)<br />
<br />
:[https://wiki.archlinux.org/index.php?title=Installation_guide&diff=632251&oldid=631819 Updated again]. Note that after installation the system can still easily get under 512 MB. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:05, 17 August 2020 (UTC)<br />
<br />
:: Lahwaacz, it's missing fullstop "{{ic|.}}" in the end of this sentence. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 23:49, 17 August 2020 (UTC)<br />
<br />
::: Actually not missing (found it just now), but should it be after the reference link? -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 23:51, 17 August 2020 (UTC)<br />
<br />
::::It's used the same way also in [[Installation guide#Select the mirrors]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:01, 18 August 2020 (UTC)<br />
<br />
:::::From what I've seen, most wiki pages use it the same way. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:52, 19 August 2020 (UTC)<br />
<br />
::::::There is actually an open discussion about this: [[Help talk:Style/Formatting and punctuation#Reference links before or after punctuation marks?]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:05, 19 August 2020 (UTC)<br />
<br />
== Boot issues faced when installing on modern machines. ==<br />
<br />
One may encounter "Invalid signature" when trying to boot from the installation media on a machine with secure boot on and keys not cleared. <br />
<br />
Also, after installing on a NVME SSD, one need to set the drive to AHCI mode instead of Intel Optimized (in bios configuring panel), otherwise you just can't boot into the system.<br />
<br />
[[User:Sffred|Sffred]] ([[User talk:Sffred|talk]]) 00:05, 24 September 2020 (UTC) Sffred 1600905886<br />
<br />
:AHCI is a SATA controller operation mode, it shouldn't have anything to do with NVMe. You can add a section to [[Partitioning#Troubleshooting]] about changing the SATA mode if Linux doesn't see SATA disks, but make sure you're using the correct terms. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:27, 25 September 2020 (UTC)<br />
<br />
::Some motherboards support SATA over the [[w:M.2|M.2]] port, which may be the source of this confusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:33, 25 September 2020 (UTC)<br />
<br />
:::[[w:M.2#Storage interfaces]] lists "PCI Express using AHCI" as an option, but it's unclear if such a mode is actually implemented by any firmware, and even if it was, it should not be recommended as it would drastically reduce the drive's speed. From what I could find[https://forums.anandtech.com/threads/nvme-drive-booting-in-ahci-mode.2500796/post-39852218][https://lore.kernel.org/linux-pci/20190620061038.GA20564@lst.de/T/][https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aecec8b60422118b52e3347430ba9382e57d6d76], it looks like manufacturers simply interpret "SATA mode" being set to "AHCI" on NVMe controllers to mean "use native operating mode without firmware RAID". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:33, 25 September 2020 (UTC)<br />
<br />
:::While on the topic of SATA (and non-SATA) operating modes, any thoughts about the backup GPT header corruption warning in [[GPT fdisk#Convert between MBR and GPT]]? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:37, 25 September 2020 (UTC)<br />
<br />
::::Sorry, I have no idea... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:57, 26 September 2020 (UTC)<br />
<br />
:I added a note about [[Secure Boot]] to [[Installation guide#Boot the live environment]]. If anyone's wondering why it says "installation image'''s'''" then that's because of {{ic|ipxe.efi}} (the EFI binary for [[Netboot]]). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:52, 28 September 2020 (UTC)<br />
<br />
== Swap partition vs swap file ==<br />
<br />
Would it be reasonable to stop suggesting using swap partitions and instead recommend creating a swap file? Will genfstab work in a chroot environment to create a correct fstab?<br />
[[User:Managor|Managor]] ([[User talk:Managor|talk]]) 12:50, 3 February 2021 (UTC)<br />
<br />
:There's no reason why swap files should be given preference over swap volumes, using one or the other (or both) is a choice left to the user. [[Installation guide#Example layouts]] already mentions swap files, although, maybe some reference to them could also be added to [[Installation guide#Format the partitions]] and [[Installation guide#Mount the file systems]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:51, 4 February 2021 (UTC)<br />
<br />
== /etc/hosts: dual ip4/ip6 localhost prevents ip4 from working ==<br />
<br />
I recently set up a new system with /etc/hosts copied from the guide:<br />
{{bc|<br />
127.0.0.1 localhost<br />
::1 localhost<br />
127.0.1.1 myhostname.localdomain myhostname<br />
}}<br />
<br />
I found localhost did not resolve to {{ic|127.0.0.1}} which caused some docker comms to fail etc.<br />
<br />
Removing or renaming the ip6 binding allowed ip4 localhost to work again, so perhaps the following should be used in the guide instead:<br />
{{bc|<br />
127.0.0.1 localhost<br />
::1 ip6-localhost<br />
127.0.1.1 myhostname.localdomain myhostname<br />
}}<br />
<br />
{{unsigned|09:18, 19 February 2021|Alexheretic}}<br />
<br />
== Post-installation ==<br />
<br />
I skipped steps in the guide so I faced a weird crash in gnome without any explanations. I suggest a note.<br />
<br />
{{Note|Many of them assume that you have your timezone or locales set up. Make sure you have followed all the steps.}}<br />
<br />
[[User:Escope|Escope]] ([[User talk:Escope|talk]]) 10:11, 2 April 2021 (UTC)<br />
<br />
:The reader is supposed to follow all the steps. If we apply that to other pages, the pages need a boatload of notes to make sure the reader did not skip any steps. A common functional system has properly configured locales and timezones.<br />
:Since this is GNOME-specific however I would at most add a section into [[GNOME/Troubleshooting]] or even [[General troubleshooting]], but I still think this is out of scope to be honest. Many applications may not work properly when the timezones or locales are not correctly configured.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 15:30, 2 April 2021 (UTC)<br />
<br />
::The reader is not supposed to follow all the steps in case one doesn't worthy of attention. In my humble opinion, that's why it has huge advantage over the "Next-Next-Finish" approach. Unconfigured locales or timezones are obvious to many people, but my inexperience made me spend some time to sorting out. The other pages are highly deep and clear about the steps and why they are needed, my eyes enjoy such notes, pages are boatloaded already and I like it a lot =D. Thank you for your attention to this little change.<br />
<br />
::-- [[User:Escope|Escope]] ([[User talk:Escope|talk]]) 00:23, 3 April 2021 (UTC)<br />
<br />
:::If you're inexperienced, what makes you think you can judge if a step is necessary or not? You thought you knew better than the people that wrote the guide and found out that you didn't. Not something that needs changed here IMO.<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 01:57, 3 April 2021 (UTC)<br />
<br />
:::The ArchWiki should also be about the why-aspect. I am in favor of adding e.g a note about why they are needed and why some applications may crash or behave strangely without properly configured timezones/locales. If you know e.g a nice blog post about this topic, why not add something like this?<br />
:::{{Note|Some applications may behave in strange ways or even crash when the timezones and/or locales are not properly configured. See [https://xkcd.com/1084/ this informative blog post] to know why that is.}}<br />
:::The note needs obviously some rewording, but something like this would fit in well in my opinion.<br />
:::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:02, 3 April 2021 (UTC)<br />
<br />
::::Adding a '''brief''' "why" would be ok, but using [[Template:Note]] would be too much. I've also always wanted to emphasize the "and" in [[Installation guide#Localization]], since it's easy to miss (even some of the translated installation guides do not mention {{ic|en_US.UTF-8 UTF-8}}). --- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:48, 3 April 2021 (UTC)<br />
<br />
:::::People who want to know the "why" can already consult the relevant articles. That said, consistency is lacking: some sections explain in detail why a step should be performed (such as [[Installation_guide#Verify_signature]]), whereas [[Installation_guide#Configure_the_system]] is mostly a checklist of steps with brief instructions how. The solution isn't obvious: adding notes all over would likely more distract than clarify. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:41, 14 April 2021 (UTC)<br />
<br />
::::::I'm definitely apposed to adding notes, but I don't see why we couldn't add brief "why"s without them. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:55, 15 April 2021 (UTC)<br />
<br />
== Network Configurarion localdomain ==<br />
Hello!<br />
<br />
Is ".localdomain" string to be added as it is? Isn't localdomain supposed to be set by user like ''myhostname''?<br />
<br />
If yes, then that should be reflected in the Installation Guide as:<br />
<br />
...<br />
<br />
Add matching entries to {{man|5|hosts}}:<br />
<br />
{{hc|/etc/hosts|<br />
127.0.0.1 localhost<br />
::1 localhost<br />
127.0.1.1 ''myhostname''.''localdomain'' ''myhostname''<br />
}}<br />
...<br />
<br />
[[User:Rootkea|Rootkea]] ([[User talk:Rootkea|talk]]) 04:42, 9 April 2021 (UTC)<br />
<br />
:[[w:.local]] serves a special purpose, but {{ic|.localdomain}} indeed seems a placeholder with no special meaning. I'll make the change, thanks. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:44, 14 April 2021 (UTC)<br />
<br />
::The question now is, if it's a placeholder, what do you replace it with? Not every system has (or needs) a real domain name. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:00, 15 April 2021 (UTC)<br />
<br />
::So I don't need a hostname, I can just put localhost , right? [[User:Highfrequencyhertz|Highfrequencyhertz]] ([[User talk:Highfrequencyhertz|talk]]) 19:18, 10 June 2021 (UTC)<br />
<br />
:::FWIW, I don't have anything related to localhost in my /etc/hosts on a laptop... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:39, 10 June 2021 (UTC)<br />
<br />
::::Should a note be added to the wiki explaining that it is optional or not needing to be substituted by anything? I think that leaving it as is could be confusing. [[User:Highfrequencyhertz|Highfrequencyhertz]] ([[User talk:Highfrequencyhertz|talk]]) 02:41, 12 June 2021 (UTC)<br />
<br />
:::::Indeed, this confused me while updating this section in [[Installation guide (Français)]]. I think this needs to be expanded to explain why one should fill it or not (but nothing more in the "Installation guide" IMO). Maybe this could link to [[Network configuration#Local hostname resolution]] have it explained there. [[User:Nophke|Nophke]] ([[User talk:Nophke|talk]]) 07:29, 9 July 2021 (UTC)<br />
<br />
== fstab is optional in some cases ==<br />
<br />
When using a GPT-partitioned disk, partition with the right partition types, and booting with systemd, [[Systemd#GPT_partition_automounting|creating fstab is optional]].<br />
<br />
Could a hint on this be added to the fstab section? [[User:Hobarrera|Hugo Osvldo Barrera]] ([[User talk:Hobarrera|talk]]) 19:23, 8 July 2021 (UTC)<br />
<br />
:This is a very specific case (for [[systemd-boot]]), while an explicitly generated fstab works with any boot loader. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:43, 9 July 2021 (UTC)<br />
<br />
::It seems that [[REFInd#LoaderDevicePartUUID|Refind can set the LoaderDevicePartUUID variable too]], so should work as well. It's only optional for those boot loaders though, you're right. What I have in mind is a note with a link to the above link, so that readers can figure out if it's optional for them or not, not an actual statement that it's always optional, since that would not be accurate. [[User:Hobarrera|WhyNotHugo]] ([[User talk:Hobarrera|talk]]) 11:51, 9 July 2021 (UTC)<br />
<br />
== Add link to ALSA firmware in the Install essentials packages section ==<br />
<br />
With sof-firmware gaining more and more traction on newer systems it might be useful to add a link or piece of information that this might be necessary for newer laptops/cards, see [[Advanced_Linux_Sound_Architecture#ALSA_firmware]]. We currently get pretty much daily reports on the BBS where someone wonders where their sound card has gone. I know this is "technically" included in the "install additional firmware not included in linux-firmware" line, but since this is something that hasn't really been necessary for years this is potentially something not everyone is immediately aware of. [[User:V1del|V1del]] ([[User talk:V1del|talk]]) 17:15, 13 August 2021 (UTC)<br />
<br />
:Even with a link to [[Advanced_Linux_Sound_Architecture#ALSA_firmware]], it might be confusing that it applies based on the hardware, even when the user wants to use [[PulseAudio]] or [[Pipewire]]. Is there a better place where audio firmware could be described? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:00, 13 August 2021 (UTC)<br />
<br />
::I tried to have some sort of "standardized" snippet on laptop pages when it needs ALSA firmware, but the ArchWiki is not a hardware db and we cannot document all pieces of hardware. Audio is not essential for some users but a few depend on screenreaders, which is crucial to accessibility.<br />
::In the end it might not cause harm to install sof-firmware when in doubt.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 01:17, 14 August 2021 (UTC)<br />
<br />
:::I mean if we cover firmware in e.g. [[Sound system]] and link to that instead of ALSA, it would seem much more general. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:19, 14 August 2021 (UTC)<br />
<br />
::::Well for this particular case you can fairly easily identify whether you have a need for sof-firmware with an {{ic|<nowiki>lsmod | grep snd_sof</nowiki>}} or a {{ic|<nowiki>dmesg | grep -i sof</nowiki>}}, but yes might be helpful to move that somewhere else if we want to ensure to have hardware based separation here. [[User:V1del|V1del]] ([[User talk:V1del|talk]]) 12:04, 14 August 2021 (UTC)<br />
<br />
:::::I [[Special:Diff/692787|added]] {{Pkg|sof-firmware}} as an example (and the aforementioned link) so that there's at least something for now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:20, 25 August 2021 (UTC)<br />
<br />
== Add a link to [[Solid_state_drive]] or storage device specific pages before/during partitioning step ==<br />
Some pages like [[Solid_state_drive]] are nearly impossible to get to from just following the Installation Guide. This is problematic as some recommendations from these pages are only relevant '''before''' installation, as it is too late afterwards (notably for setting native sector size as in [[Solid_state_drive#Native_sector_size]]. I believe there should be a note in the partitioning step, something like modifying this line: <br />
* If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now.<br />
to <br />
* If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now. Also check [[Improving_performance#Partitioning]] or [[Solid_state_drive]] for storage device specific information.<br />
As an alternative, this could be added to [[Partitioning]], but it's already quite big...<br />
-- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 15:47, 29 August 2021 (UTC)<br />
<br />
== <s>Point out archinstall</s> ==<br />
[[Archinstall]] has been canonicalized as an official install path, so that should be reflected here. I suggest that the document be split into three main sections, the first titled, "Prerequisites", second titled "Guided install - archinstall", and the final titled "Manual install". Most of the current document would be moved under the manual install section. I'm happy to write a first draft for these changes if this sounds good. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:48, 2 September 2021 (UTC)<br />
<br />
:It's already in [[:Category:Installation process]], which is linked from the installation guide, together with [[systemd-firstboot]], [[archboot]] and other methods. If you want to draft an expanded process for the guided installer, [[Archinstall]] is the place for it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:07, 2 September 2021 (UTC)<br />
<br />
::Yes, understand that there are many ways to install Arch. In April it was announced on main page news, "Arch now includes a guided installer". That implies this is ''the'' canonical guided installer. Not specifically addressing it here is in conflict with that, creates confusion, and seems a missed opportunity (as a Linux user since before Arch existed, I've lost track of the number of times I've heard people complain about Arch's manual-only onboarding.) [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:03, 2 September 2021 (UTC)<br />
<br />
:::The [https://archlinux.org/news/installation-medium-with-installer/ announcement] does not imply that Archinstall is the canonical installer, guided or whatever. It only says that the installation medium ''provides'' another installation method and it even explicitly says that the ''default'' installation method is still the one described on this page ([[Installation guide]]). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:41, 2 September 2021 (UTC)<br />
<br />
::::You're right, it's not implied, it is explicit [verbatim quote, emphasis mine]: "This '''''addition to''' the '''default''' method'' of installation". Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:17, 2 September 2021 (UTC)<br />
<br />
:::::As I said before, it's already addressed. Every page in [[:Category:Installation process]] is an "addition" to the installation guide, and that category is linked from the guide. There's no reason to single out archinstall from say, the bootstrap image or [[archboot]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:04, 2 September 2021 (UTC)<br />
<br />
::::::This does not reflect the clear tone of the announcement, and feels like a disservice to the community. Arch had a guided installer as default until 2012, when the primary maintainer stepped down due to burnout. The wiki became the de-facto source of truth soon after, due to the lack of a mature, supported, guided installer option. The announcement that there's again a maintained guided installer as a default option is something many would welcome. Please please update the install guide. Again, I'm happy to write a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 04:35, 3 September 2021 (UTC)<br />
<br />
:::::::Again: '''there is no guided installer as a default option'''. You are misinterpreting the announcement where the word "addition" means "supplement", not "inclusion". It is an additional installation option, '''not''' part of the default installation option. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:17, 3 September 2021 (UTC)<br />
<br />
::::::::Is this what Giancarlo has explicitly said to you or your own interpretation of the announcement? The wording is clear, and it's a great stretch to try to interpret it the way you are proposing. I would not be alone, or even in the minority, in assuming that "addition to" means inclusion, especially given that both to title and first sentence iterate that it "'''''now''' provides a guided installer''" (the implicit statement being that it did not previously, and this is a change to the status quo). [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:25, 3 September 2021 (UTC)<br />
<br />
:::::::::It seems to me you're interpreting things into the announcement. Archinstall is part of the installation process. Will it eventually become the indicated method of installation? I don't know, but I don't think so. Heck, in the future we might even have an ISO with archinstall gui, who knows? All I'm saying is, as of now, archinstall is an addition, nothing more, nothing less. It '''is''' official, but that doesn't mean it's the indicated method on the installation guide. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 12:48, 3 September 2021 (UTC)<br />
<br />
::::::::::Thanks for clarifying. Please note I'm not suggesting it become ''the'' method. I'm just suggesting it have a prominent mention in the guide before the manual process. Note also what I've written below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:18, 3 September 2021 (UTC)<br />
<br />
:::::::::::Instead of trying to create conflict where there is none, or trying creative interpretations of the announcement, I think it would be more productive for you and for us if you tell us '''why''' you think archinstall should be prominently mentioned on the installation guide page. --[[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 01:13, 4 September 2021 (UTC)<br />
<br />
::::::::::::I've attempted to do that in the section I wrote yesterday immediately below this. If you have questions or feel I should expand this rationale, I'm all ears. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:04, 4 September 2021 (UTC)<br />
::::::::::::I'm also trying very deliberately to avoid conflict by simply addressing the topics at hand in a clear and straightforward, unemotional manner. I've received significant pre-emptive resistance and denial to good-faith proposals to improve the state of the distro and documentation, with little justification, and have taken care to point out how this behavior is limiting progress. I feel like I shouldn't have to point out that in the spirit of creating an open and inclusive community, it is wise as a community ambassador to try and ensure that you are maintaining an unbiased and open-minded forum. I'm a new user who has actively contributed valuable technical content, and is offering to contribute more, and am being treated with defensive emotional remarks (not on your part, Giancarlo... this has been in my dialogue with Alad and Lahwaacz) while offering no malice or ill-intent in return. I'm sincere in my desire to help and hope that this is clear. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:17, 4 September 2021 (UTC)<br />
<br />
:::::::::::::Now you're escalating to making personal attacks on staff. More-so, in a public setting you're implying one staff member should perform punitive action on another merely because you don't get things your way. This will be your first and only warning on this kind of behavior. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
::::::::::::: In [https://en.wikipedia.org/wiki/De-escalation de-escalation], the most important thing is to stay high on the [https://en.wikipedia.org/wiki/De-escalation#/media/File:Graham's_Hierarchy_of_Disagreement-en.svg pyramid]. I'm guilty of falling down it some, as everyone is, on occasion. I want nothing to happen against you or Lahwaacz; I wish you very well and hope you've been having an enjoyable weekend. I'm trying only to encourage that we stick to the topics at hand and not hold too tightly to our beliefs. I'm happy to have my mind changed! It means I've learned something. :D [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:24, 5 September 2021 (UTC)<br />
<br />
::::::::::::: Also, my sincere apology if this has come across as an attack! I don't want any of this to be personal. I appreciate deeply the care and commitment that goes into maintaining a clear body of knowledge for an important topic, and want to thank you both for the degree that you clearly show of caring in that same way. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:38, 5 September 2021 (UTC)<br />
<br />
::::::::::::: I'll point out one of my own failings in my discussions with you. I've been lazy in my use of language. Sometimes I say I've refuted something, when really I mean that I've offered a convincing counterargument (following the notation of the pyramid). I'll try to be more conscious of this going forward. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
:Further rationale for including the archinstall process here: Having a primary, guided, install path is a nearly universally accepted practice in the OS world; Arch is not Linux-From-Scratch. Arch never deliberately avoided having one for a philosophical reason, it simply had a role in providing and maintaining one go unfilled for the last nine years. In researching the reaction online to the archinstall announcement, the dominant reaction was one of relief. For those concerned, I saw comments suggesting that the support burden might be increased by switching back to a guided installer. Others suggested that, "If people are too dumb to follow the wiki, they shouldn't be using Arch." Both concerns are ill conceived though. I'll address them below:<br />
<br />
* Support burden<br />
** The original impetus to fork CRUX and create Arch in 2002 was to make pacman. Pacman automates package management, and the key innovation was better tracking of what files come from what package. Pacman, along with rolling-release, are the true defining features of Arch. Pacman makes the system far less prone to breakage, because as is said in [[System_maintenance#Use_the_package_manager_to_install_software|System maintenance]], "If you install things manually you will, sooner or later, forget what you did, forget where you installed to, install conflicting software, install to the wrong locations, etc." This is even more important and even more true for the initial install! Having a guided install which is handled by a tested, repeatable, automated process will only be better for support! This is a pretty universally accepted principle in software development.<br />
* Hazing / too dumb<br />
** This attitude just creates an elitist community which is looked on with scorn from the outside. It is not a good look for Arch, which I'll remind means "the primary," with the intent of being the absolute best there is. It is not in line with the [https://terms.archlinux.org/docs/code-of-conduct/#respect-other-users Code of conduct], which states unequivocally, "Arch Linux is a respectful, inclusive community. Anti-social or offensive behaviour will not be tolerated."<br />
-- [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:45, 3 September 2021 (UTC)<br />
<br />
:This whole argument is completely tangential. The installation guide is the primary installation method because it is the most universal, whereas other methods can only cover specific use-cases. As pointed out above, Archinstall is ''one'' of those additional installation methods. Users who want a guided install path have other available options, like [[systemd-firstboot]] and [[Archboot]]. If that's not clear enough from [[:Category:Installation process]], that should be discussed there. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:39, 3 September 2021 (UTC)<br />
:: Regarding, "because it is the most universal." Then preface the section on archinstall with a paragraph like this: "Archinstall is the preferred guided installer process. However, we have just recently added it as a process, and it is not yet as applicable to all use cases as the manual process. Below are some reasons you may prefer or need to use the manual process below instead: ..." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 20:14, 3 September 2021 (UTC)<br />
<br />
::: No, archinstall is not the preferred guided installer process, it is one possible guided installer process of three (the others being archboot and systemd-boot, as pointed out multiple times). Also, as any guided installer, it can never be applicable to all use cases. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:25, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "Users have other guided install options." Systemd-firstboot is not arch specific and is very limited in what it can achieve. It's not an installer for Arch, more a post-install tool. Archboot is ''unofficial'', per it's own wiki page. Archinstall is the only official guided installer, per the announcement (and Giancarlo's reiteration above, with emphasis). [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:36, 3 September 2021 (UTC)<br />
::::: systemd-firstboot is very similar in principle to archinstall- both offers a series of prompts to automate steps for installing a system. Archboot is not more or less unofficial than archinstall. Every mirror includes an ISO containing it, and a developer maintains it. Otherwise, your choice which of the three you prefer is exactly that - your choice. Other users have to decide that for themselves. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]])<br />
<br />
::::Regarding, "It can never cover all use cases." Yes, sure. But is there anything in the manual guide that couldn't theoretically be included in an automatic guide? Feature parity ought to be an achievable goal. People with use cases outside of what's covered in the guide are probably confident enough forging their own path anyway. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:42, 3 September 2021 (UTC)<br />
:::::There's a huge amount of options one can achieve by doing a manual install, starting from what's linked in the install guide and eventually reaching most pages in the wiki. An automated installer can never achieve that. It might ''try'', but doing so is going to add a major maintenance effort to the installer authors and not achieve parity anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
::: If you want to go into detail why someone may prefer the installation guide over archinstall, then that belongs in [[Archinstall]]. Right now, the latter only mentions specific choices for boot loader and network configuration, and I'm sure there's more to tell. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:25, 3 September 2021 (UTC)<br />
::::I am proposing that I write out those details, yes. I'm just saying the appropriate place is on [[Installation guide]], as that's what people are pointed at when they boot the ISO. That's what people are referencing when they're thinking, "How should I install this?" A clear decision flow which includes all official options should be on Installation_guide, not elsewhere. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:53, 3 September 2021 (UTC)<br />
<br />
:::::No, the appropriate place is whatever article is relevant to what you want to add. We're not going to add all the details for say, [[Install from SSH]] either. If you want some "clear decision flow which includes all official options" you can, as I already pointed out, propose something on [[Category talk:Installation process]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
: Another reason prioritizing a mature default guided install is a good idea for Arch - Currently, if I want someone to try Arch I either have to offer them a pre-built VM of my own cooking, or try to convince them to spend an hour or more wading through the wiki to get to a point they can start exploring pacman and AUR and appreciating the rolling-release model, or just tell them, "boot up one of the popular Arch derivatives' live environments and ignore their chrome." I'd much rather just point them here and say "Run archinstall, it takes 5 minutes and has sensible defaults." It's interesting to note that interest in Arch has been on a [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png consistent downtrend since 2012], when the existing guided installer was deprecated. Wider interest and adoption can pull in more developers. Just in the last few months, NixOS has overtaken pacman/AUR in package coverage, both in terms of being [https://repology.org/repositories/statistics/newest up to date] and in terms of [https://repology.org/repositories/statistics/total total repositories]. Arch risks losing relevance if package maintenance falls behind the competition. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:55, 4 September 2021 (UTC)<br />
::To further drive this, also note from [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png this chart] that interest in distros which rely upon pacman/AUR is at a boiling point! The whole Arch ecosystem is now arguably the largest of all the Linux ecosystems there are in terms of total interest. Ignoring the factors of the rapidly growing success of derivatives could compromise Arch's future. With the meteoric rise of strong competition to pacman/AUR, this is pressing and critical. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:22, 4 September 2021 (UTC)<br />
<br />
:::The main reason, at least for me, that archinstall was added to the repositories and to the ISO, was that the archiso was not very accessible. Having a guided installer, plus the accessibility improvements made to the ISO, can allow more people to install Arch. However, archinstall has one unintended "feature": People will install Arch using it, without reading any documentation, just to find out that keeping an Arch system going is the hard part, not installing it. Arch is not a company, a business and one of the reasons it is great, is that it's one of the few standing truly community driven distributions out there. With that being said, I think we could add to the ISO some documentation also mentioning archinstall. However, I think the installation guide should remain as it is. It already mentions on the first paragraph that there are other methods for installation. --[[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 14:24, 4 September 2021 (UTC)<br />
::::Regarding, "People might install without knowing how to maintain." I think people find that with any Linux if they are unfamiliar and unwilling to learn. Arch at least has one of the largest communities, some of the best documentation, and one of the harder to break environments (though perhaps a warning which requires overriding if you try to run 'pacman -Sy' would be a nice touch... even one well informed may slip up and commit an error with a simple typo, currently). It's also why I see it being practical to still lean on encouraging people to figure out more by pointing them to the guide and using that as the decision flow tool (with a good heaping of reminding that it's important to develop an understanding of the architecture and means of configuring the major components if you want to get the most out of the system). [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:49, 4 September 2021 (UTC)<br />
::::Regarding, "Might be better to just mention archinstall on the ISO boot." If the direction is to include mention of archinstall in the ISO boot message, I'd be happy if the decision on whether to use it or the manual process has a decision tree written out on the archinstall page instead. I still think having one source with a simple decision flow for all the supported install approaches is the better solution though. That way one who does go to the install guide before downloading and booting the ISO has everything clearly laid out for them in a flow that addresses the most pressing questions one might have if they, with no previous knowledge of Arch, had jumped from the main page, to the download page, to the first link there, [[Installation guide]]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:49, 4 September 2021 (UTC) <br />
::FWIW: If you need a VM image, you can use the officael VM images from the [https://gitlab.archlinux.org/archlinux/arch-boxes arch-boxes] project. [[User:Klausenbusk|Klausenbusk]] ([[User talk:Klausenbusk|talk]]) 15:40, 4 September 2021 (UTC)<br />
<br />
== Add information about packages included in the installation environment ==<br />
:Currently, the install section only has this to say about packages beyond core which are available in the live environment, "''For comparison, packages available in the live system can be found in [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64].''" It's just a link to a list of over 100 packages, with no explanation of why they're included or what they do. Perhaps a page which categorizes them, includes a brief summary of each, and includes a link out to more about the package would help those looking to better understand the live environment and considering which packages to include in their install. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:22, 9 September 2021 (UTC)<br />
:: This would create a significant maintenance overhead for little actual benefit. Anyone actually interested in what specific packages do can easily research them; we even have links to the man pages now to facilitate this. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 02:30, 9 September 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694963Talk:Arch compared to other distributions2021-09-08T00:37:27Z<p>Jasonwryan: /* Beginner-friendly */ This is a waste of time and goodwill</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
::: I second this. The second paragraph in [[#Arch-based]] is just a lengthy liability waiver that should not be necessary for the terms compared on this page. If the content needs such waiver, don't add it to the page. Furthermore, the split into [[#Beginner-friendly]] and [[#Added-platforms]] reads as these are the only two categories. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 7 September 2021 (UTC)<br />
<br />
:::: I don't, particularly, feel that it is necessary. There's plenty of other such warnings elsewhere, and it does distract from the comparison. I included it to exhaustively cover the feedback on concerns about implying endorsement or support. I think a single sentence summary of that warning would suffice. Something like, "These distributions are ''not'' Arch, have their own communities and support, and are not endorsed in any way by Arch." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:31, 8 September 2021 (UTC)<br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
:: Fair point. Updated [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:53, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]], to access our high-quality and well-curated [[official repositories]], or [[Arch_User_Repository#Installing_and_upgrading_packages|makepkg]] to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
:: I did mention them as "conveniences." Open to a rephrase if the statement seems misleading. It seems a shame not to mention pacman, since that's really what drove the creation of Arch to begin with. The AUR helpers are just the correlate for the AUR. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:59, 7 September 2021 (UTC)<br />
<br />
::: You misinterpreted my comment: pacman is not the problem, just the AUR helpers. As I said, they are not necessary for the AUR: makepkg is. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:26, 7 September 2021 (UTC)<br />
<br />
:::: Oh I know pacman is not the problem. I'm just saying that the way it's written out as, "conveniences to access the official repositories and AUR, respectively," only really works if I include the AUR helpers. Attempting a rewrite. I think I, a bit reluctantly, agree that pointing out the AUR helpers, potentially to beginners, might be too much of a footgun. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:46, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about [[Desktop_environment#Officially_supported|which desktop environment]] to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
<br />
:: Some I've specifically included because I want to tie them into the relevant documentation for the Arch wiki, for those curious why particular software was chosen who want to look into it. (e.g., the combination of btrfs and TimeShift). Is that not appropriate? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:03, 7 September 2021 (UTC)<br />
<br />
::: What is achieved by linking to other wiki pages? People curious about derivatives can read the rationale ''on the derivative websites''. We aren't in the business of promoting those distributions. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:29, 7 September 2021 (UTC)<br />
<br />
:::: It makes it easy for Archers (DIY'er/Tinkerers) to think, "Huh, I wonder why they all seem to be using those. Guess I'll look at the wiki page and maybe try them out." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:49, 7 September 2021 (UTC)<br />
<br />
::::: Archers who want to try out different DEs etc, can just install them on their Arch installation, that's the whole point of Arch Linux... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:16, 7 September 2021 (UTC)<br />
<br />
:::::: Yes, we agree on this. That's why I've included the internal wikilinks for archers to read about, and potentially setup, on their Arch installs. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:14, 8 September 2021 (UTC)<br />
<br />
:::::: So, all of it can be removed and this discussion can actually be closed so that the staff can go back to doing actual volunteer work on the wiki, and stop bikeshedding this proposal? Great. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:26, 8 September 2021 (UTC)<br />
<br />
:: Here's a use case for this section which is more of an anti-advertisement: Having a place to point people who, wondering about migrating away from an Arch-derived distro, want to know how pure Arch compares. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:52, 7 September 2021 (UTC)<br />
<br />
::: Again, pure Arch is comprehensively described in the main pages of the wiki: if people who want to migrate from derivatives can't understand that, including all of this is not going to make any difference. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:18, 7 September 2021 (UTC)<br />
<br />
:::: Sure, this is just a topical summary which directly highlights the difference in philosophy and technical choices. Same could be said about basically all the other distros on this page. Why have the page at all then? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:23, 8 September 2021 (UTC)<br />
<br />
::::: Well, the other entries are actual distributions, not just someone's version of Arch Linux. In any event, I am done arguing about this: the sheer volume of pointless discussion for a proposal that amounts to nothing more than advertising for derivatives is evidence enough that this has no benefit, direct or indirect, to Arch. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:37, 8 September 2021 (UTC)<br />
<br />
:: Some of the content feels a bit redundant after the long intro I've now added. Attempting a trim on this update. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 09:04, 7 September 2021 (UTC)<br />
<br />
===== Manjaro =====<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
:::The starting point for an "Archer thinking about security" is the [[Security]] page. It would be better to describe the interesting concepts and features on that (or another relevant) page, rather than comparing Arch to security-oriented Linux distributions. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:39, 7 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
:::The currently proposed content is missing any comparison with Arch, so it is out of this page's scope. Providing quick summaries of 3 BSDs is pointless, they can be found elsewhere. This page is about giving comparisons (with Arch!), not summaries. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:32, 7 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694961Talk:Arch compared to other distributions2021-09-08T00:26:02Z<p>Jasonwryan: /* Beginner-friendly */ We're done here</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
::: I second this. The second paragraph in [[#Arch-based]] is just a lengthy liability waiver that should not be necessary for the terms compared on this page. If the content needs such waiver, don't add it to the page. Furthermore, the split into [[#Beginner-friendly]] and [[#Added-platforms]] reads as these are the only two categories. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 7 September 2021 (UTC)<br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
:: Fair point. Updated [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:53, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]], to access our high-quality and well-curated [[official repositories]], or [[Arch_User_Repository#Installing_and_upgrading_packages|makepkg]] to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
:: I did mention them as "conveniences." Open to a rephrase if the statement seems misleading. It seems a shame not to mention pacman, since that's really what drove the creation of Arch to begin with. The AUR helpers are just the correlate for the AUR. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:59, 7 September 2021 (UTC)<br />
<br />
::: You misinterpreted my comment: pacman is not the problem, just the AUR helpers. As I said, they are not necessary for the AUR: makepkg is. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:26, 7 September 2021 (UTC)<br />
<br />
:::: Oh I know pacman is not the problem. I'm just saying that the way it's written out as, "conveniences to access the official repositories and AUR, respectively," only really works if I include the AUR helpers. Attempting a rewrite. I think I, a bit reluctantly, agree that pointing out the AUR helpers, potentially to beginners, might be too much of a footgun. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:46, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about [[Desktop_environment#Officially_supported|which desktop environment]] to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
<br />
:: Some I've specifically included because I want to tie them into the relevant documentation for the Arch wiki, for those curious why particular software was chosen who want to look into it. (e.g., the combination of btrfs and TimeShift). Is that not appropriate? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:03, 7 September 2021 (UTC)<br />
<br />
::: What is achieved by linking to other wiki pages? People curious about derivatives can read the rationale ''on the derivative websites''. We aren't in the business of promoting those distributions. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:29, 7 September 2021 (UTC)<br />
<br />
:::: It makes it easy for Archers (DIY'er/Tinkerers) to think, "Huh, I wonder why they all seem to be using those. Guess I'll look at the wiki page and maybe try them out." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:49, 7 September 2021 (UTC)<br />
<br />
::::: Archers who want to try out different DEs etc, can just install them on their Arch installation, that's the whole point of Arch Linux... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:16, 7 September 2021 (UTC)<br />
<br />
:::::: Yes, we agree on this. That's why I've included the internal wikilinks for archers to read about, and potentially setup, on their Arch installs. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:14, 8 September 2021 (UTC)<br />
<br />
:::::: So, all of it can be removed and this discussion can actually be closed so that the staff can go back to doing actual volunteer work on the wiki, and stop bikeshedding this proposal? Great. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:26, 8 September 2021 (UTC)<br />
<br />
:: Here's a use case for this section which is more of an anti-advertisement: Having a place to point people who, wondering about migrating away from an Arch-derived distro, want to know how pure Arch compares. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:52, 7 September 2021 (UTC)<br />
<br />
::: Again, pure Arch is comprehensively described in the main pages of the wiki: if people who want to migrate from derivatives can't understand that, including all of this is not going to make any difference. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:18, 7 September 2021 (UTC)<br />
<br />
:::: Sure, this is just a topical summary which directly highlights the difference in philosophy and technical choices. Same could be said about basically all the other distros on this page. Why have the page at all then? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:23, 8 September 2021 (UTC)<br />
<br />
:: Some of the content feels a bit redundant after the long intro I've now added. Attempting a trim on this update. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 09:04, 7 September 2021 (UTC)<br />
<br />
===== Manjaro =====<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
:::The starting point for an "Archer thinking about security" is the [[Security]] page. It would be better to describe the interesting concepts and features on that (or another relevant) page, rather than comparing Arch to security-oriented Linux distributions. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:39, 7 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
:::The currently proposed content is missing any comparison with Arch, so it is out of this page's scope. Providing quick summaries of 3 BSDs is pointless, they can be found elsewhere. This page is about giving comparisons (with Arch!), not summaries. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:32, 7 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694930Talk:Arch compared to other distributions2021-09-07T18:19:26Z<p>Jasonwryan: /* Beginner-friendly */ Nope</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
:: Fair point. Updated [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:53, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]], to access our high-quality and well-curated [[official repositories]], or [[Arch_User_Repository#Installing_and_upgrading_packages|makepkg]] to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
:: I did mention them as "conveniences." Open to a rephrase if the statement seems misleading. It seems a shame not to mention pacman, since that's really what drove the creation of Arch to begin with. The AUR helpers are just the correlate for the AUR. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:59, 7 September 2021 (UTC)<br />
<br />
::: You misinterpreted my comment: pacman is not the problem, just the AUR helpers. As I said, they are not necessary for the AUR: makepkg is. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:26, 7 September 2021 (UTC)<br />
<br />
:::: Oh I know pacman is not the problem. I'm just saying that the way it's written out as, "conveniences to access the official repositories and AUR, respectively," only really works if I include the AUR helpers. Attempting a rewrite. I think I, a bit reluctantly, agree that pointing out the AUR helpers, potentially to beginners, might be too much of a footgun. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:46, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about [[Desktop_environment#Officially_supported|which desktop environment]] to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
<br />
:: Some I've specifically included because I want to tie them into the relevant documentation for the Arch wiki, for those curious why particular software was chosen who want to look into it. (e.g., the combination of btrfs and TimeShift). Is that not appropriate? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:03, 7 September 2021 (UTC)<br />
<br />
::: What is achieved by linking to other wiki pages? People curious about derivatives can read the rationale ''on the derivative websites''. We aren't in the business of promoting those distributions. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:29, 7 September 2021 (UTC)<br />
<br />
:::: It makes it easy for Archers (DIY'er/Tinkerers) to think, "Huh, I wonder why they all seem to be using those. Guess I'll look at the wiki page and maybe try them out." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:49, 7 September 2021 (UTC)<br />
<br />
::::: Archers who want to try out different DEs etc, can just install them on their Arch installation, that's the whole point of Arch Linux... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:16, 7 September 2021 (UTC)<br />
<br />
:: Here's a use case for this section which is more of an anti-advertisement: Having a place to point people who, wondering about migrating away from an Arch-derived distro, want to know how pure Arch compares. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:52, 7 September 2021 (UTC)<br />
<br />
::: Again, pure Arch is comprehensively described in the main pages of the wiki: if people who want to migrate from derivatives can't understand that, including all of this is not going to make any difference. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:18, 7 September 2021 (UTC)<br />
<br />
:: Some of the content feels a bit redundant after the long intro I've now added. Attempting a trim on this update. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 09:04, 7 September 2021 (UTC)<br />
<br />
===== Manjaro =====<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694928Talk:Arch compared to other distributions2021-09-07T18:16:48Z<p>Jasonwryan: /* Beginner-friendly */ Missing the point</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
:: Fair point. Updated [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:53, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]], to access our high-quality and well-curated [[official repositories]], or [[Arch_User_Repository#Installing_and_upgrading_packages|makepkg]] to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
:: I did mention them as "conveniences." Open to a rephrase if the statement seems misleading. It seems a shame not to mention pacman, since that's really what drove the creation of Arch to begin with. The AUR helpers are just the correlate for the AUR. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:59, 7 September 2021 (UTC)<br />
<br />
::: You misinterpreted my comment: pacman is not the problem, just the AUR helpers. As I said, they are not necessary for the AUR: makepkg is. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:26, 7 September 2021 (UTC)<br />
<br />
:::: Oh I know pacman is not the problem. I'm just saying that the way it's written out as, "conveniences to access the official repositories and AUR, respectively," only really works if I include the AUR helpers. Attempting a rewrite. I think I, a bit reluctantly, agree that pointing out the AUR helpers, potentially to beginners, might be too much of a footgun. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:46, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about [[Desktop_environment#Officially_supported|which desktop environment]] to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
<br />
:: Some I've specifically included because I want to tie them into the relevant documentation for the Arch wiki, for those curious why particular software was chosen who want to look into it. (e.g., the combination of btrfs and TimeShift). Is that not appropriate? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:03, 7 September 2021 (UTC)<br />
<br />
::: What is achieved by linking to other wiki pages? People curious about derivatives can read the rationale ''on the derivative websites''. We aren't in the business of promoting those distributions. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:29, 7 September 2021 (UTC)<br />
<br />
:::: It makes it easy for Archers (DIY'er/Tinkerers) to think, "Huh, I wonder why they all seem to be using those. Guess I'll look at the wiki page and maybe try them out." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:49, 7 September 2021 (UTC)<br />
<br />
::::: Archers who want to try out different DEs etc, can just install them on their Arch installation, that's the whole point of Arch Linux... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:16, 7 September 2021 (UTC)<br />
<br />
:: Here's a use case for this section which is more of an anti-advertisement: Having a place to point people who, wondering about migrating away from an Arch-derived distro, want to know how pure Arch compares. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:52, 7 September 2021 (UTC)<br />
<br />
:: Some of the content feels a bit redundant after the long intro I've now added. Attempting a trim on this update. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 09:04, 7 September 2021 (UTC)<br />
<br />
===== Manjaro =====<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694830Talk:Arch compared to other distributions2021-09-07T08:29:28Z<p>Jasonwryan: /* Beginner-friendly */ We don't promote derivatives</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
:: Fair point. Updated [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:53, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]] and [[AUR_helpers#Comparison_tables|yay/paru/others]], to access our high-quality and well-curated [[official repositories]], or to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
:: I did mention them as "conveniences." Open to a rephrase if the statement seems misleading. It seems a shame not to mention pacman, since that's really what drove the creation of Arch to begin with. The AUR helpers are just the correlate for the AUR. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:59, 7 September 2021 (UTC)<br />
<br />
::: You misinterpreted my comment: pacman is not the problem, just the AUR helpers. As I said, they are not necessary for the AUR: makepkg is. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:26, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about which desktop environment to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
<br />
:: Some I've specifically included because I want to tie them into the relevant documentation for the Arch wiki, for those curious why particular software was chosen who want to look into it. (e.g., the combination of btrfs and TimeShift). Is that not appropriate? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:03, 7 September 2021 (UTC)<br />
<br />
::: What is achieved by linking to other wiki pages? People curious about derivatives can read the rationale ''on the derivative websites''. We aren't in the business of promoting those distributions. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:29, 7 September 2021 (UTC)<br />
<br />
===== Manjaro =====<br />
* Is targeted as a beginner-friendly desktop distribution, with a graphical installer.<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Is a beginner friendly desktop distribution with a [https://calamares.io/ Calamares] based graphical installer.<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Has option to automatically setup non-free Nvidia drivers<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Is a beginner-friendly desktop distribution, with a graphical installer.<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694829Talk:Arch compared to other distributions2021-09-07T08:26:43Z<p>Jasonwryan: /* Beginner-friendly */ AUR helpers</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
:: Fair point. Updated [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:53, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]] and [[AUR_helpers#Comparison_tables|yay/paru/others]], to access our high-quality and well-curated [[official repositories]], or to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
:: I did mention them as "conveniences." Open to a rephrase if the statement seems misleading. It seems a shame not to mention pacman, since that's really what drove the creation of Arch to begin with. The AUR helpers are just the correlate for the AUR. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:59, 7 September 2021 (UTC)<br />
<br />
::: You misinterpreted my comment: pacman is not the problem, just the AUR helpers. As I said, they are not necessary for the AUR: makepkg is. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 08:26, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about which desktop environment to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
<br />
:: Some I've specifically included because I want to tie them into the relevant documentation for the Arch wiki, for those curious why particular software was chosen who want to look into it. (e.g., the combination of btrfs and TimeShift). Is that not appropriate? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 08:03, 7 September 2021 (UTC)<br />
<br />
===== Manjaro =====<br />
* Is targeted as a beginner-friendly desktop distribution, with a graphical installer.<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Is a beginner friendly desktop distribution with a [https://calamares.io/ Calamares] based graphical installer.<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Has option to automatically setup non-free Nvidia drivers<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Is a beginner-friendly desktop distribution, with a graphical installer.<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694801Talk:Arch compared to other distributions2021-09-07T03:35:45Z<p>Jasonwryan: /* Comparison with Arch-based distributions */ This is counter-productive</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
:: After reviewing this, I'm not convinced that it adds anything of benefit to Arch, or to the Arch wiki. If anywhere, it would make sense on a website like wikipedia, where the geneaology of Linux can be recorded. But if they are not supported by Arch, why would we spend effort documenting them and then having to maintain the list? If it does nothing to advance Arch, and only increases the maintenance burden, it should not proceed. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:35, 7 September 2021 (UTC) <br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. If imitation is the sincerest form of flattery, then the success of these distros is quite flattering to Arch. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]] and [[AUR_helpers#Comparison_tables|yay/paru/others]], to access our high-quality and well-curated [[official repositories]], or to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about which desktop environment to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
===== Manjaro =====<br />
* Is targeted as a beginner-friendly desktop distribution, with a graphical installer.<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Is a beginner friendly desktop distribution with a [https://calamares.io/ Calamares] based graphical installer.<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Has option to automatically setup non-free Nvidia drivers<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Is a beginner-friendly desktop distribution, with a graphical installer.<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694800Talk:Arch compared to other distributions2021-09-07T03:13:51Z<p>Jasonwryan: /* Beginner-friendly */ These are just ads</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. If imitation is the sincerest form of flattery, then the success of these distros is quite flattering to Arch. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]] and [[AUR_helpers#Comparison_tables|yay/paru/others]], to access our high-quality and well-curated [[official repositories]], or to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about which desktop environment to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
: The three sections below (Manjaro et al), read like ads for these distributions: their feature lists should reside on their websites, not ours. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:13, 7 September 2021 (UTC)<br />
===== Manjaro =====<br />
* Is targeted as a beginner-friendly desktop distribution, with a graphical installer.<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Is a beginner friendly desktop distribution with a [https://calamares.io/ Calamares] based graphical installer.<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Has option to automatically setup non-free Nvidia drivers<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Is a beginner-friendly desktop distribution, with a graphical installer.<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694799Talk:Arch compared to other distributions2021-09-07T03:10:55Z<p>Jasonwryan: /* Arch-based */ Remove editorialising</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. If imitation is the sincerest form of flattery, then the success of these distros is quite flattering to Arch. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
: "If imitation... " is just editorialising. Please remove it. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:10, 7 September 2021 (UTC)<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]] and [[AUR_helpers#Comparison_tables|yay/paru/others]], to access our high-quality and well-curated [[official repositories]], or to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about which desktop environment to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
===== Manjaro =====<br />
* Is targeted as a beginner-friendly desktop distribution, with a graphical installer.<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Is a beginner friendly desktop distribution with a [https://calamares.io/ Calamares] based graphical installer.<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Has option to automatically setup non-free Nvidia drivers<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Is a beginner-friendly desktop distribution, with a graphical installer.<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&diff=694798Talk:Arch compared to other distributions2021-09-07T03:07:17Z<p>Jasonwryan: /* Beginner-friendly */ Remove AUR helper reference</p>
<hr />
<div>== <s>Comparison with Arch-based distributions</s> ==<br />
<br />
I'd like to add the following section. It seems only appropriate to address the most-similar distributions here too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 1 September 2021 (UTC)<br />
<br />
:Thanks for the proposal. However, by the logic of including Arch derivatives we'd have to include niche offshoots from Ubuntu/Fedora/Gentoo/etc. as well. That's outside of the scope of this page. There's also [[Arch-based distributions]] already. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:08, 1 September 2021 (UTC)<br />
<br />
::I don't follow how a comparison to Arch derivates would imply a need to include non-Arch major distro derivatives. This is the Arch wiki, not a distro review site. The most important thing is just to have a comparison to the most popular other distros of the major types available. The fact that some of the most popular distros available are Arch derivatives and that Arch derivatives are a major un-addressed class of distros is the logic to include them here. Another unaddressed class that would be nice to add is "minimalist" distros, e.g. Alpine. Arch-derivates just seemed like the biggest gap to address first. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:41, 2 September 2021 (UTC)<br />
<br />
:::Alpine and Void might be listed somewhere. For these distributions one might point out fundamental differences, instead of what theme or aur helper are used for a "more user-friendly" experience. I don't think "minimalist" is a good description for those though. They might fit in the General section instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::Regarding, "Don't think minimalist is a good description." Then "lightweight". Alpine and its ilk make significant compromises in the name of being as small as possible, and that is their primary fundamental difference. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 11:58, 2 September 2021 (UTC)<br />
<br />
:::::Lightweight holds even less meaning than minimalist. I don't see where these compromises imply that Void/Alpine are no longer general-purpose distributions - other entries in that list make compromises in turn (Debian and Fedora with their free software guidelines, Slackware with no dependency resolution, etc). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::I'm not saying they're not general purpose (though the unusual choice of musl libc comes with its share of compat issues). I'm saying that their raison d'etre is being as small as possible. Minimal, if you will. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 15:51, 2 September 2021 (UTC)<br />
<br />
::::::Minimal size, then, to make it concrete? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 2 September 2021 (UTC)<br />
<br />
::::::Yes, perfect. In keeping with the naming conventions on the page, the section would be, "Minimal-size".[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:09, 3 September 2021 (UTC)<br />
<br />
:::::::I opened a new talk item: [[#Add_Alpine,_Void]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:23, 3 September 2021 (UTC)<br />
<br />
::::Regarding, "point out only fundamental differences". The more similar things are, the more one must split hairs to suss out their defining factors. Naturally, the differences will be more subtle when addressing Arch derivatives. Still, what I've pointed out are the primary advertised and touted differences. They're significant enough that many people choose them over pure Arch, so worthy of analysis, and there's no better place than here for that. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:09, 2 September 2021 (UTC)<br />
<br />
:::::That still doesn't change that listed factors are purely superficial and that the main difference is a change in philosophy (the "Is targeted as a beginner-friendly desktop distribution, with a graphical installer.") Former only adds a maintenance burden to update features for derivatives that may cease to exist or entirely change focus next year, and adds little of note when exhaustive resources are already available (from the homepage of whatever derivative involved, or wikipedia). <br />
::::::Regarding, "... only adds a maintenance burden." I have already shouldered that burden for the time-being in pre-emptively writing the section out. If it proves out of date, without a maintainer, simply removing the section in a year or so would be understandable. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:57, 3 September 2021 (UTC)<br />
:::::Latter could at most be included as an extension of the phrase "Community ports that support architectures other than x86_64 can be found listed among the Arch-based distributions.". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
::::::Yes, perhaps there ought to be two sub-sections for Arch-derivatives. The one I've created already, which is based on prominence or popularity, and another which cherry-picks based on support factors. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
:::::::There's not going to be any subsection for Arch derivatives. I'm really done going in circles about this. The only thing that ''might'' be changed is "Community ports that support architectures other than x86_64 or ''are aimed at beginning users'' can be found listed among the Arch-based distributions." in the introduction. Or one might add a link to [[Arch-based distributions]] in [[Arch_compared_to_other_distributions#Beginner-friendly]] instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:16, 3 September 2021 (UTC)<br />
<br />
::The introduction also says "In all of the following only Arch Linux is compared with other distributions." Hence, Arch does not compare itself with its derivatives – they compare themselves with Arch. Just pick any of the [[Arch-based distributions]] and on its homepage you will likely find its characteristics and difference from the base distribution (maybe except for the projects that claim to "be Arch"...) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 1 September 2021 (UTC)<br />
<br />
:::One could have said the same thing about the USA when they seceded from Britain. It would be a fool's gambit now to try to make that argument. Regarding, "You can just look it up." Yes, that's true. This isn't a simple LMGTFY though. In order to write this up I had to go to DistroWatch and hunt down the three most popular Arch-derivatives, and then I had to spend another hour or more digging through notes and images to synthesize a summary and tie it in to relevant points for the Arch wiki. There's worthwhile info here for long time Arch veterans. Now one can, at a glance, see that it's quite popular and in-demand to configure a system running Arch with XFCE, btrfs, Timeshift, and LUKS. Perhaps one hasn't thought much about their filesystem or desktop config since ext4 became default and wants to see what the fuss is about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:54, 2 September 2021 (UTC)<br />
::: Regarding, "Arch is compared to other distributions ... [later] ... except projects that claim to 'be Arch'." I think that answers itself. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:58, 2 September 2021 (UTC)<br />
<br />
:::: None of those points from your digging are relevant to Arch wiki. They're superficial aspects (what Arch repos does it use, what DEs, themes or AUR helpers does it use by default, etc.) bound to frequent change, and apart from "user-friendliness" don't discuss fundamental differences, unlike the other distributions listed. If you really want to know about these details, there's already [[w:Comparison_of_Linux_distributions]]. It's linked from the introduction. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 2 September 2021 (UTC)<br />
<br />
::::I've just above pointed out how I've tied specific, non-superficial, technical choices made by the derivatives into relevant documentation for the Arch wiki and given an explicit use-case for this information being relevant here. The response is a straw-man. I also hope from reading my other comments you've realized that I'm well versed in the Linux distro landscape and history and don't need to have wiki tables pointed to me. I feel this contribution offers significant value and don't feel there's been a solid refutation of that value proposition being offered. The premature closing of this topic before discussion had really begun also implies a prejudice and anti-community-participation position. I'm a new user who has been very actively contributing the last several days, and have been very patient with what is increasingly feeling like hostility or condescension. Can we please address this? [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:35, 3 September 2021 (UTC)<br />
<br />
::::: There have been previous "efforts" to document Arch-based derivatives in greater detail. Due to sheer amount of them and their fleeting nature, this didn't get anywhere - even summary tables (e.g. in old revisions of [[Arch-based distributions]] like [https://wiki.archlinux.org/index.php?title=Arch-based_distributions&oldid=437778]) were removed with time, only leaving sourceforge links where the last time of activity was detailed. In this discussion, you proposed to do said documentation of derivatives (by whatever definition of "significant value"), ''and'' put it on an unrelated page where Arch is compared to different families of distributions. That's why it was closed, not because of "prejudice" or "anti-community-participation". Also, your claims of hostility are absurd, especially after you got a note on [[User talk:Einr#About recent undone edits]]. If you want to keep acting like all this is done in bad faith, that's up to you - but in that case, don't expect people to keep thinking you are making these propositions in good faith either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:18, 3 September 2021 (UTC)<br />
:::::: Regarding, "Fleeting nature makes maintenance hard." Yes, that's part of why I chose only to focus on distros which have a significant critical mass. Manjaro has been around for nearly a decade. The others are newer, but have quickly become among the top of all Linux distros, with enough momentum they are likely to continue on in prominence for years to come. See these charts I made yesterday [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20HPD%20-%202011%20to%202021%20-%202021-09-04%20102028.png Arch and Derivatives - DistroWatch HPD - 2011 to 2021] and [https://entvibes.com/archwiki/Arch%20and%20Derivatives%20-%20DistroWatch%20Rank%20-%202011%20to%202021%20-%202021-09-03%20155710.png Arch and Derivatives - DistroWatch Rank - 2011 to 2021]. There's been a dramatic uptick in the total share of Linux distro interest around Arch and Arch-based distros in the last few years. That should be a point of pride! The continual slide of Arch down the chart, and the position that Arch is a DIY'er/tinkerer/look-under-the-hood/not-strongly-opinionated distro, which isn't seeking market share in and of itself, seem consistent too. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:38, 4 September 2021 (UTC)<br />
::::::: It's a notable correlation too that peak interest in Arch was in 2012, just before the existing guided install was deprecated. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:39, 4 September 2021 (UTC)<br />
<br />
:::::::: Arch is indeed not looking for market share, see [[Arch_Linux#User_centrality]]. As such I'm puzzled that your main motivation - here and in other discussions such as [[Talk:Installation guide]] - is about popularity. Considering this fundamental difference in views it should be no surprise this discussion isn't getting anywhere. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
::::::::: There's a nice note in the LFS section of this page, "''Historically, Arch was sometimes humorously described simply as "Linux, with a nice package manager."'' " That, I think, gets at the core of what I've been driving. It's not really about popularity as it is about package maintenance and the keys to catalyzing it. So I doubt we really have as much fundamentally different in our view as you imagine it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:43, 5 September 2021 (UTC)<br />
<br />
:::::: Regarding, "Closed because you proposed to do..." - A quick review of the [https://wiki.archlinux.org/index.php?title=Talk:Arch_compared_to_other_distributions&oldid=693779 edit history] reveals this to be false. You immediately closed the topic after I'd already written the section out saying it should be added to ''this'' page. Your reasoning was around an implied need to then include the derivates of other major distros. I refuted that argument and didn't have my refutation clearly addressed. The topic remained closed, regardless. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
:::::: Regarding, "Not because ''prejudice'' or ''anti-community-participation''." - This is a talk page which is to invite discussion. Surely you might be able to understand how one might feel like there's a mentality of prejudice or a discouragement of community participation when such happens: Immediately closing a topic because ''any reason'' and then not reopening it when ''any reason'' has a reasonable refutation offered and not addressed. Personally, I would err on the side of never closing a talk topic before there's an opportunity for discourse. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:05, 4 September 2021 (UTC)<br />
<br />
::::::: There's many reasons to not include Arch-based derivatives. For the first reply I chose the most obvious one hoping you'd spend your time on less controversial topics. Instead, we now have a pages long discussion where nobody budges an inch. Discussion closed or not, it's equally pointless. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:06, 5 September 2021 (UTC)<br />
<br />
:::::::: I've been trying to very logically and plainly address those concerns, and feel like I'm not getting appropriate responses. If you responded with a convincing argument that Archers shouldn't care that ''lots'' of other sort-of-Archers seem to want a streamlined install process, pre-configured btrfs/Timeshift, etc. I might have dropped it by now. Where it sits, it feels a lot like a parental, "because I said so." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:59, 5 September 2021 (UTC)<br />
<br />
:::: Please keep your off-topic stints from the wiki, especially if they are [https://terms.archlinux.org/docs/code-of-conduct/#controversycontroversial-topics political]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:10, 2 September 2021 (UTC)<br />
<br />
:::::Unclear what is off topic here. Alluding that forking bears a semblance to secession, and drawing parallels from history also does not carry a political tone. The argument, to put it more plainly, is that simply being a derivative work does not make something unworthy of comparison to its progenitor; particularly when that derivative rises to a position of relative prominence.[[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:23, 2 September 2021 (UTC)<br />
<br />
::::::To put it more plainly, keep your arguments strictly technical. Nobody here is interested in "historical" analogs that only distract from the discussion at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 2 September 2021 (UTC)<br />
<br />
:::::::Sure. I thought my comparison was clear (It's perhaps the most prominent event of modern history. 200 years ago, many a Brit would turn their nose up at America. Now they are the most closely allied superpowers. The intent was to imply that perhaps that, as Britain has learned from partnership with America, perhaps Arch can learn something from its derivatives.). I see how it can be misunderstood though. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:25, 3 September 2021 (UTC)<br />
<br />
:While there's still some disagreement about where the information ought to go (I'm still of the mind that this page is the most clear and obvious spot), the discussion above did highlight there's some agreement we could do better to point out the Arch-derivatives which hope to extend the platform support offered by Arch. A draft below of the proposed content to achieve that. Taking care to drive that they are ''not'' Arch, and not supported by the Arch community, and adding some other details to incorporate feedback from the above discussion. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 02:29, 7 September 2021 (UTC)<br />
<br />
=== Arch-based ===<br />
<br />
These distributions are what in the open source world is generally called ''downstream''. This means that they take Arch as their core and then make certain changes or additions. Typically they still include default configurations for access to all of the Core/Community/Extra packages and AUR. They may also have their own additions configured in. If imitation is the sincerest form of flattery, then the success of these distros is quite flattering to Arch. Differences between Arch and its most prominent children are highlighted below.<br />
<br />
Please note these distributions are run by independent teams with no association to Arch; they are ''not'' Arch. As such, the Arch community and development team offer no support of them, and no endorsement of them. We cannot offer any guarantees or assurances about their quality or security. The information below only exists to highlight their differences to Arch. The documentation and communities around those distributions are the best source of help, should you choose to use any of these distributions.<br />
<br />
==== Beginner-friendly ====<br />
<br />
Arch is, among its highest values, a DIY and tinkering-friendly distribution. The community takes pride in understanding the inner-workings of their systems. This wiki is a testament to that, with extensive details about myriad system configuration offerings; starting from the beginning, the [[Installation guide]], which allows you to reach deep across the wiki just in your initial system setup. Arch encourages you to truly make the system ''yours''. It aims to be robust and offer great conveniences still, namely through the inclusion of [[pacman]] and [[AUR_helpers#Comparison_tables|yay/paru/others]], to access our high-quality and well-curated [[official repositories]], or to access the open-access community-driven [[AUR|Arch User Repositories]]. Between the two, Arch provides access to one of the largest and most up to date package management ecosystems in the Linux world.<br />
<br />
: I disagree strongly with the proposal to mention AUR helpers here as it a) implies they are official, and b) somehow necessary for package management on Arch. They are neither. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 03:06, 7 September 2021 (UTC)<br />
<br />
The beginner-friendly distributions below seek to leverage Arch's widely appreciated package ecosystem, while catering more to a different community: people who are looking for a quick-to-install, curated graphical desktop offering. For some more familiar with Linux, this may simply be an issue of convenience or liking the particular choices made by the distribution. For beginners, this offers a lower barrier of entry to get a taste of the Linux experience; this is the more common perspective, so has been selected to classify these distributions in contrast to Arch. While Arch doesn't offer a strong opinion about which desktop environment to use, these distributions are more opinionated about such things, and offer defaults from that down even to particular filesystem choices and system configuration tweaks. Those choices are highlighted below for the most prominent distributions.<br />
<br />
===== Manjaro =====<br />
* Is targeted as a beginner-friendly desktop distribution, with a graphical installer.<br />
* Is not configured with direct access to primary Arch package repositories. They maintain a separate release channel which includes Arch packages, but trails behind them with a review period.<br />
* Installs a desktop environment by default: XFCE. KDE and GNOME are also primary supported options included in the install process.<br />
* Includes pacman, but also has its own ''pamac'' GUI interface to pacman.<br />
* Includes a GUI-based hardware device manager of their own development.<br />
<br />
===== EndeavourOS =====<br />
* Is a beginner friendly desktop distribution with a [https://calamares.io/ Calamares] based graphical installer.<br />
* Has a space/astronaut theme. Installs a desktop environment: [[XFCE]] is default and they have an "EndeavourOS theme"<br />
* Includes [[btrfs]] (with {{AUR|timeshift}} snapshotting) and [[LUKS]] encryption as options in the installer.<br />
* Has direct access to primary Arch packages by default.<br />
* Has option to automatically setup non-free Nvidia drivers<br />
* Main Arch add-on beyond the installer and optional XFCE theme is a "Welcome" GUI app with post-install options like an automatic source-speed tester to update to the fastest mirrors. Otherwise tries to do things the Arch way and is command-line-centric.<br />
<br />
===== Garuda =====<br />
* Is a beginner-friendly desktop distribution, with a graphical installer.<br />
* Has a dark/neon, clean-cyberpunk, theme. Default is a KDE Plasma install.<br />
* Sets up [[btrfs]] with {{AUR|timeshift}} snapshotting and [[Btrfs#Compression|Zstd compression]] by default.<br />
* Several Garuda-created GUI tools:<br />
** Garuda Settings Manager - GUI for managing drivers and kernels<br />
** Garuda Assistant - GUI for high level tasks like system updates and mirrorlist testing<br />
** Garuda Boot Options - GUI for GRUB management<br />
** Garuda Network Assistant - GUI for common network tasks<br />
* Has direct access to all main Arch repos, with one added of their own<br />
* Performance-focused tweaks by default, e.g.:<br />
** [[Improving_performance#zram_or_zswap|Zram]] setup by default<br />
** [[Improving_performance#Improving_system_responsiveness_under_low-memory_conditions|nohang]] setup by default<br />
<br />
==== Added-platforms ====<br />
<br />
These Arch-derived distributions exist to serve the gap created by the fact that x86_64 is the only supported Arch hardware platform. These distributions provide support to other platforms, and are briefly noted below. Again, they are not Arch and carry all the same caveats as have been highlighted above about Arch derivatives.<br />
<br />
* Arch Linux ARM - Offers support to ARM devices, such as the Raspberry Pi<br />
* Arch Linux 32 - Offers support for i686 devices<br />
<br />
== Add Alpine, Void ==<br />
<br />
Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the [[Arch compared to other distributions#General]] section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in [[Arch compared to other distributions#General]].<br />
<br />
Either way we should think of a write-up and probably include these distributions in the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 3 September 2021 (UTC)<br />
<br />
:I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png here]. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 03:57, 5 September 2021 (UTC)<br />
<br />
Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:40, 5 September 2021 (UTC)<br />
<br />
:We are not done reviewing it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:42, 5 September 2021 (UTC)<br />
<br />
=== Draft: Minimal-size ===<br />
<br />
These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.<br />
<br />
These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.<br />
<br />
==== Alpine Linux ====<br />
<br />
* Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the [https://www.cymune.com/blog-details/Attack-Surface-Reduction "attack surface"] (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.<br />
* A minimal install is ~130MiB on disk.<br />
* Userland binaries compiled with [[Wikipedia:Position-independent code|position-independent executables]], to limit available exploits.<br />
* Achieves very small size in part by foregoing the usual choice of [[GNU#Toolchain|glibc]], and instead uses [[C#Alternative_libc_implementations|musl libc]].<br />
* [[BusyBox]] based, also to reduce size and complexity.<br />
* Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce [https://www.musl-libc.org/faq.html compatibility issues] for some applications.<br />
** Package coverage: Over [https://repology.org/repository/alpine_3_14 5000 core projects], and [https://repology.org/repository/alpine_edge over 7500] in edge.<br />
** Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x<br />
* [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] for [[init]]<br />
* Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.<br />
<br />
==== Void Linux ====<br />
<br />
* Is a general-purpose distribution with a focus on being fast and as small as possible.<br />
* Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)<br />
* i686 and x86_64 support<br />
* Built around both musl and glibc.<br />
* [[Runit]] for [[init]] system (Arch uses [[systemd]] by default)<br />
* Using [https://github.com/void-linux/xbps xbps] package manager.<br />
** Over [https://repology.org/repository/void_x86_64 7000 packages], comparable size to OpenBSD Ports.<br />
<br />
==== Puppy Linux ====<br />
* Is an end-user, desktop-focused, portable-first distribution.<br />
** Boots into a [[ramdisk]], primary intent to boot quickly off a USB stick.<br />
* Small size to enable quick portable boot off USB<br />
** ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)<br />
* Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for [https://www.raspberrypi.org/ RasPi]/[[ARM]])<br />
* One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has [https://entvibes.com/archwiki/Small%20Linux%20Distros%20-%20Google%20Trends%20-%202021-09-05%20134735.png faded in prominence since].<br />
<br />
==== Tiny Core Linux ====<br />
* Is an extremely small graphical Linux desktop<br />
** ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)<br />
* Achieves small size by cherry-picking some of the smallest tools available for each purpose:<br />
** [[BusyBox]], [https://www.irif.fr/~jch/software/kdrive.html Tiny X], [https://www.fltk.org/ Fltk], and [https://github.com/tinycorelinux/flwm Flwm]<br />
* Can be used as a portable OS, in similar manner to Puppy Linux<br />
* Is limited in scope. Monolithic package updated twice a year since 2009.<br />
** Repo browser not online. State of package repositories unclear.<br />
* Ports for: i686, x86_64, ARM, RasPi<br />
<br />
== Add Security distros ==<br />
<br />
Next unaddressed class of distribution is security. Alpine can be linked in. Kali, Tails, and Qubes are the shoe-ins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 12:43, 5 September 2021 (UTC)<br />
<br />
:That category is too niche to be included here. Besides Qubes those are also derivatives of Debian, and listing those in detail is out of scope for this page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:53, 5 September 2021 (UTC)<br />
<br />
::The way I see this page is, "Distros that might be of particular interest to Archers." Yes there are piles of distros out there, and many are derivatives, but there's some very interesting nuggets that the Archer (a DIY'er/Tinkerer) might want to investigate in particular. That's where I see these fitting in here. Qubes has a great concept of isolation. TAIL's amnesiac nature is notable and makes you think more about all the things happening on your filesystems. Kali is a curated pentesting suite. I see this section as being shorter with just the highlights, similar to the BSD one. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 13:32, 5 September 2021 (UTC)<br />
<br />
== Add NixOS Somewhere ==<br />
<br />
I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 14:07, 5 September 2021 (UTC)<br />
<br />
:[[Arch compared to other distributions#General]]? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 5 September 2021 (UTC)<br />
<br />
::Yep, sure. I'll start working up a draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 01:19, 6 September 2021 (UTC)<br />
<br />
=== NixOS ===<br />
<br />
* While most distributions ''include'' a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. [https://nixos.org/manual/nix/stable/#ch-about-nix Nix], the package management system, aims to be a subsystem which can be installed on practically ''any'' Linux distribution. The aim being to be a universally applicable dependency management system for developers.<br />
** Allows use as a continuous-integration environment.<br />
** Allows replacement of language-specific package managers.<br />
** Allows use of a single tool for all project build, machine configuration, and cloud deployment management.<br />
** Is a developer-centric OS.<br />
* Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable [https://reproducible-builds.org/ Reproducible Builds].<br />
** Making [https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723 progress] in this.<br />
** This is a major security consideration for any software available in binary form.<br />
** Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.<br />
*** Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of [[Btrfs#Snapshots|btrfs]], along with judicious configuration of software like [[Synchronization_and_backup_programs#File-based_increments|TimeShift]] can allow most of this benefit.<br />
* Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.<br />
** A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual [https://nixos.org/blog/announcements.html#21.05 releases] have a release manager who actively tracks this and doles out praise and recognition for contributing.<br />
<br />
== Add particularly interesting note about NetBSD ==<br />
<br />
While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.<br />
<br />
This was just [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&type=revision&diff=694206&oldid=694205 reverted].<br />
The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"<br />
<br />
This justification doesn't stand up for several reasons:<br />
# This page is littered with references to platform support.<br />
# Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.<br />
# The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is ''the'' portable OS as far as the *NIX world is concerned.<br />
<br />
Please only revert content when there's a ''very'' clear and widely acceptable reason not to include it. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:37, 5 September 2021 (UTC)<br />
<br />
:The page used to have a detailed list of BSDs. That quickly turned into an ad board. [https://wiki.archlinux.org/index.php?title=Arch_compared_to_other_distributions&oldid=418996#The_*BSDs] So we have no interest in having anything more than what the page has now. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:51, 5 September 2021 (UTC)<br />
<br />
::Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 05:06, 6 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
[Ed: This was in the BSDs section]<br />
* NetBSD is notable for it's portability-focused design. It runs on [https://www.netbsd.org/ports/ more platforms] than possibly any other OS.<br />
<br />
=== Proposed content ===<br />
* As in the Linux world, there are many BSD derivatives. The top three are summarized below.<br />
** FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability.<br />
** OpenBSD - Security-centric. Absolute focus on ongoing code audits.<br />
** NetBSD - Possibly the most portable OS. Runs on [https://www.netbsd.org/ports/ an extensive variety of platforms].<br />
<br />
== Add corpo distros ==<br />
<br />
:What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:24, 6 September 2021 (UTC)<br />
<br />
:Just throwing up a quick draft. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 06:38, 6 September 2021 (UTC)<br />
<br />
::I don't think we should promote/advertise commercial distributions by mentioning them here. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:02, 6 September 2021 (UTC)<br />
<br />
:::Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 23:55, 6 September 2021 (UTC)<br />
<br />
:::As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:04, 7 September 2021 (UTC)<br />
<br />
:::Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."<br />
<br />
::::An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 00:44, 7 September 2021 (UTC)<br />
<br />
=== Enterprise-commercial ===<br />
<br />
These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Official_repositories&diff=694221Talk:Official repositories2021-09-05T07:24:14Z<p>Jasonwryan: /* Add context about package ecosystem */ Talk before editing</p>
<hr />
<div>== Add context about package ecosystem ==<br />
<br />
I recently had the content below [https://wiki.archlinux.org/index.php?title=Official_repositories&diff=prev&oldid=694214 reverted].<br />
<br />
The justification was: "AUR does not belong to the description of *official* repositories"<br />
<br />
It's unclear what the issue here is. Is the sentence ambiguous somehow? I'm not insinuating in any way that AUR is *official*, and surely the big red warning on top of the AUR page is sufficient to make that clear. People generally mention pacman ''and'' (whether through yay or paru) AUR in one breath, and collectively they do represent the Arch package ecosystem as described. I'm happy to rephrase it if the content is unclear. This context is valuable information to include here for people wanting to understand the state of Arch packaging at a glance. [[User:Einr|Einr]] ([[User talk:Einr|talk]]) 07:15, 5 September 2021 (UTC)<br />
<br />
=== Reverted content ===<br />
<br />
Combined with the [https://repology.org/repository/aur AUR], Arch is proud to be home to one of the [https://repology.org/repository/arch largest and most up-to-date] package repository ecosystems [https://entvibes.com/archwiki/Arch%20and%20AUR%20on%20Repology%20-%20highlighted%20-%202021-09-05%20162239.png in the Linux world].<br />
<br />
: This is why you should discuss in the Talk page ''before'' editing. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 07:24, 5 September 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=693176Gopher2021-08-28T01:35:44Z<p>Jasonwryan: /* Gopher server */ Added motsognir</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== Gopher clients ==<br />
<br />
Browsing gopherspace requires a client. There are a number to choose from in the AUR, including:<br />
<br />
* {{AUR|bombadillo}}<br />
* {{AUR|castor}}<br />
* {{AUR|cgo-git}}<br />
* {{AUR|ddwarf}}<br />
<br />
Search the AUR for [https://aur.archlinux.org/packages/?O=0&K=gopher a full list].<br />
<br />
A good starting point to explore gopherspace is http://gopher.quux.org:70/<br />
<br />
== Gopher server ==<br />
<br />
Creating your own gopherspace is relatively straightforward. Install and configure a gopher server, and add your own content.<br />
<br />
There are a number of gopher servers, including:<br />
<br />
* {{AUR|geomyidae}}<br />
* {{AUR|motsognir}}<br />
* {{AUR|sgopherd-git}}<br />
* {{AUR|stagit-gopher}}<br />
<br />
=== Adding content ===<br />
<br />
Gopher is a plain text protocol. Begin by creating a [[Wikipedia:gophermap|gophermap]] that defines the homepage of your gopherhole and includes links to the rest of your content. A {{ic|gophermap}} includes item types that describe the content in the file. An example might look like this:<br />
<br />
{{bc|<nowiki><br />
iWelcome to this Gopherhole!<br />
<br />
0This is a text file in a link file.txt<br />
9This is a pdf file in a link file.pdf<br />
1This is a link to a directory subdir<br />
<br />
IAn image img.gif<br />
<br />
0A file on another server /gopher/relevance.txt gopher.floodgap.com 70<br />
hA HTTP link to a website URL:https://archlinux.org<br />
</nowiki>}}<br />
<br />
The format for the file is the ''item type'' as the very first character, the ''display string'' (i.e., the description text to display), a ''selector'' (i.e., a file-system pathname), ''host name'' (i.e., the domain name of the server on which the item resides), and ''port'' (i.e., the port number used by that server). The ''item type'' and ''display string'' are joined without a space; the other fields are separated by the tab character.<br />
<br />
A full list of the available item types can be found on [https://en.wikipedia.org/wiki/Gopher_(protocol)#Item_types Wikipedia].<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check the {{AUR|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=693175Gopher2021-08-28T01:31:24Z<p>Jasonwryan: /* Adding content */ Canonical reference</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== Gopher clients ==<br />
<br />
Browsing gopherspace requires a client. There are a number to choose from in the AUR, including:<br />
<br />
* {{AUR|bombadillo}}<br />
* {{AUR|castor}}<br />
* {{AUR|cgo-git}}<br />
* {{AUR|ddwarf}}<br />
<br />
Search the AUR for [https://aur.archlinux.org/packages/?O=0&K=gopher a full list].<br />
<br />
A good starting point to explore gopherspace is http://gopher.quux.org:70/<br />
<br />
== Gopher server ==<br />
<br />
Creating your own gopherspace is relatively straightforward. Install and configure a gopher server, and add your own content.<br />
<br />
There are a number of gopher servers, including:<br />
<br />
* {{AUR|geomyidae}}<br />
* {{AUR|sgopherd-git}}<br />
* {{AUR|stagit-gopher}}<br />
<br />
=== Adding content ===<br />
<br />
Gopher is a plain text protocol. Begin by creating a [[Wikipedia:gophermap|gophermap]] that defines the homepage of your gopherhole and includes links to the rest of your content. A {{ic|gophermap}} includes item types that describe the content in the file. An example might look like this:<br />
<br />
{{bc|<nowiki><br />
iWelcome to this Gopherhole!<br />
<br />
0This is a text file in a link file.txt<br />
9This is a pdf file in a link file.pdf<br />
1This is a link to a directory subdir<br />
<br />
IAn image img.gif<br />
<br />
0A file on another server /gopher/relevance.txt gopher.floodgap.com 70<br />
hA HTTP link to a website URL:https://archlinux.org<br />
</nowiki>}}<br />
<br />
The format for the file is the ''item type'' as the very first character, the ''display string'' (i.e., the description text to display), a ''selector'' (i.e., a file-system pathname), ''host name'' (i.e., the domain name of the server on which the item resides), and ''port'' (i.e., the port number used by that server). The ''item type'' and ''display string'' are joined without a space; the other fields are separated by the tab character.<br />
<br />
A full list of the available item types can be found on [https://en.wikipedia.org/wiki/Gopher_(protocol)#Item_types Wikipedia].<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check the {{AUR|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=693174Gopher2021-08-28T01:30:00Z<p>Jasonwryan: /* Adding content */ typo</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== Gopher clients ==<br />
<br />
Browsing gopherspace requires a client. There are a number to choose from in the AUR, including:<br />
<br />
* {{AUR|bombadillo}}<br />
* {{AUR|castor}}<br />
* {{AUR|cgo-git}}<br />
* {{AUR|ddwarf}}<br />
<br />
Search the AUR for [https://aur.archlinux.org/packages/?O=0&K=gopher a full list].<br />
<br />
A good starting point to explore gopherspace is http://gopher.quux.org:70/<br />
<br />
== Gopher server ==<br />
<br />
Creating your own gopherspace is relatively straightforward. Install and configure a gopher server, and add your own content.<br />
<br />
There are a number of gopher servers, including:<br />
<br />
* {{AUR|geomyidae}}<br />
* {{AUR|sgopherd-git}}<br />
* {{AUR|stagit-gopher}}<br />
<br />
=== Adding content ===<br />
<br />
Gopher is a plain text protocol. Begin by creating a [[Wikipedia:gophermap|gophermap]] that defines the homepage of your gopherhole and includes links to the rest of your content. A {{ic|gophermap}} includes item types that describe the content in the file. An example might look like this:<br />
<br />
{{bc|<nowiki><br />
iWelcome to this Gopherhole!<br />
<br />
0This is a text file in a link file.txt<br />
9This is a pdf file in a link file.pdf<br />
1This is a link to a directory subdir<br />
<br />
IAn image img.gif<br />
<br />
0A file on another server /gopher/relevance.txt gopher.floodgap.com 70<br />
hA HTTP link to a website URL:https://archlinux.org<br />
</nowiki>}}<br />
<br />
The format for the file is the ''item type'' as the very first character, the ''display string'' (i.e., the description text to display), a ''selector'' (i.e., a file-system pathname), ''host name'' (i.e., the domain name of the server on which the item resides), and ''port'' (i.e., the port number used by that server). The ''item type'' and ''display string'' are joined without a space; the other fields are separated by the tab character.<br />
<br />
A full list of the available item types can be found at https://johngodlee.github.io/2019/11/20/gopher.html.<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check the {{AUR|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=693173Gopher2021-08-28T01:28:28Z<p>Jasonwryan: /* Gopher server */ Expanded format</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== Gopher clients ==<br />
<br />
Browsing gopherspace requires a client. There are a number to choose from in the AUR, including:<br />
<br />
* {{AUR|bombadillo}}<br />
* {{AUR|castor}}<br />
* {{AUR|cgo-git}}<br />
* {{AUR|ddwarf}}<br />
<br />
Search the AUR for [https://aur.archlinux.org/packages/?O=0&K=gopher a full list].<br />
<br />
A good starting point to explore gopherspace is http://gopher.quux.org:70/<br />
<br />
== Gopher server ==<br />
<br />
Creating your own gopherspace is relatively straightforward. Install and configure a gopher server, and add your own content.<br />
<br />
There are a number of gopher servers, including:<br />
<br />
* {{AUR|geomyidae}}<br />
* {{AUR|sgopherd-git}}<br />
* {{AUR|stagit-gopher}}<br />
<br />
=== Adding content ===<br />
<br />
Gopher is a plain text protocol. Begin by creating a [[Wikipedia:gophermap|gophermap]] that defines the homepage of your gopherhole and includes links to the rest of your content. A {{ic|gophermap}} includes item types that describe the content in the file. An example might look like this:<br />
<br />
{{bc|<nowiki><br />
iWelcome to this Gopherhole!<br />
<br />
0This is a text file in a link file.txt<br />
9This is a pdf file in a link file.pdf<br />
1This is a link to a directory subdir<br />
<br />
IAn image img.gif<br />
<br />
0A file on another server /gopher/relevance.txt gopher.floodgap.com 70<br />
hA HTTP link to a website URL:https://archlinux.org<br />
</nowiki>}}<br />
<br />
The format for the file is the ''item type'' as the very first character, the ''display string'' (i.e., the description text to display), a ''selector'' (i.e., a file-system pathname), ''host name'' (i.e., the domain name of the server on which the item resides), and ''port'' (i.e., the port number used by that server). The ''item type'' and ''display string'' are joined without a space; the other fields are separated by the tab character.<br />
<br />
A full list of the available itemtypes can be found at https://johngodlee.github.io/2019/11/20/gopher.html.<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check the {{AUR|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=693133Gopher2021-08-27T22:11:11Z<p>Jasonwryan: /* See also */ gofish is dead</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== Gopher clients ==<br />
<br />
Browsing gopherspace requires a client. There are a number to choose from in the AUR, including:<br />
<br />
* {{AUR|bombadillo}}<br />
* {{AUR|castor}}<br />
* {{AUR|cgo-git}}<br />
* {{AUR|ddwarf}}<br />
<br />
Search the AUR for [https://aur.archlinux.org/packages/?O=0&K=gopher a full list].<br />
<br />
A good starting point to explore gopherspace is http://gopher.quux.org:70/<br />
<br />
== Gopher server ==<br />
<br />
Creating your own gopherspace is relatively straightforward. Install and configure a gopher server, and add your own content.<br />
<br />
There are a number of gopher servers in the AUR, including:<br />
<br />
* {{AUR|geomyidae}}<br />
* {{AUR|sgopherd-git}}<br />
* {{AUR|stagit-gopher}}<br />
<br />
=== Adding content ===<br />
<br />
Gopher is a plain text protocol. Begin by creating a {{ic|gophermap}} that defines the homepage of your gopherhole and includes links to the rest of your content. A {{ic|gophermap}} includes itemtypes that describe the content in the file. An example might look like.<br />
<br />
iWelcome to this Gopherhole!<br />
<br />
0This is a text file in a link file.txt<br />
9This is a pdf file in a link file.pdf<br />
1This is a link to a directory subdir<br />
<br />
IAn image img.gif<br />
<br />
0A file on another server /gopher/relevance.txt gopher.floodgap.com 70<br />
hA HTTP link to a website URL:https://archlinux.org<br />
<br />
{{note|The fields in a gophermap are TAB seperated}}<br />
<br />
A full list of the available itemtypes can be found here: https://johngodlee.github.io/2019/11/20/gopher.html<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check {{aur|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Gopher&diff=693132Talk:Gopher2021-08-27T22:09:48Z<p>Jasonwryan: /* Page rewrite */ Closed</p>
<hr />
<div>== <s>Page rewrite</s> ==<br />
<br />
This page is almost completely redundant now. The AUR go-fish package is no longer a gopher server, and go-fish itself is dead. I'm proposing to rewrite the page to be more generic, and not rely on a single application, and to include some relevant information about configuring content, etc. Any objections? [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 23:17, 18 August 2021 (UTC)<br />
<br />
:According to the sourceforge site go-fish is dead since 2012. The majority of the article is about go-fish and it has a couple of style issues, too. I would encourage rewriting the article.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:04, 19 August 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=693131Gopher2021-08-27T22:07:10Z<p>Jasonwryan: Created gophermap instructions</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== Gopher clients ==<br />
<br />
Browsing gopherspace requires a client. There are a number to choose from in the AUR, including:<br />
<br />
* {{AUR|bombadillo}}<br />
* {{AUR|castor}}<br />
* {{AUR|cgo-git}}<br />
* {{AUR|ddwarf}}<br />
<br />
Search the AUR for [https://aur.archlinux.org/packages/?O=0&K=gopher a full list].<br />
<br />
A good starting point to explore gopherspace is http://gopher.quux.org:70/<br />
<br />
== Gopher server ==<br />
<br />
Creating your own gopherspace is relatively straightforward. Install and configure a gopher server, and add your own content.<br />
<br />
There are a number of gopher servers in the AUR, including:<br />
<br />
* {{AUR|geomyidae}}<br />
* {{AUR|sgopherd-git}}<br />
* {{AUR|stagit-gopher}}<br />
<br />
=== Adding content ===<br />
<br />
Gopher is a plain text protocol. Begin by creating a {{ic|gophermap}} that defines the homepage of your gopherhole and includes links to the rest of your content. A {{ic|gophermap}} includes itemtypes that describe the content in the file. An example might look like.<br />
<br />
iWelcome to this Gopherhole!<br />
<br />
0This is a text file in a link file.txt<br />
9This is a pdf file in a link file.pdf<br />
1This is a link to a directory subdir<br />
<br />
IAn image img.gif<br />
<br />
0A file on another server /gopher/relevance.txt gopher.floodgap.com 70<br />
hA HTTP link to a website URL:https://archlinux.org<br />
<br />
{{note|The fields in a gophermap are TAB seperated}}<br />
<br />
A full list of the available itemtypes can be found here: https://johngodlee.github.io/2019/11/20/gopher.html<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check {{aur|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [http://gofish.sourceforge.net/ GoFish Homepage]<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=693130Gopher2021-08-27T21:48:19Z<p>Jasonwryan: Replaced specific application with generic client information</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== Gopher clients ==<br />
<br />
Browsing gopherspace requires a client. There are a number to choose from in the AUR, including:<br />
<br />
* {{AUR|bombadillo}}<br />
* {{AUR|castor}}<br />
* {{AUR|cgo-git}}<br />
* {{AUR|ddwarf}}<br />
<br />
Search the AUR for [https://aur.archlinux.org/packages/?O=0&K=gopher a full list].<br />
<br />
A good starting point to explore gopherspace is http://gopher.quux.org:70/<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check {{aur|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [http://gofish.sourceforge.net/ GoFish Homepage]<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Maintenance_Team&diff=692920ArchWiki talk:Maintenance Team2021-08-25T20:16:52Z<p>Jasonwryan: /* Acceptable user names and signatures */ Added class of official uses</p>
<hr />
<div>{{Note|This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.}}<br />
<br />
== Reorganization ==<br />
<br />
The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.<br />
<br />
However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:<br />
<br />
# I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".<br />
# ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.<br />
# ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of [[ArchWiki talk:Administrators]] (e.g. update the link in [[ArchWiki:Contributing#Complaining]]).<br />
# ✓ I'd like to deprecate [[ArchWiki:Reports]], and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to ''also'' report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes. <br> Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation. <br> Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.<br />
# Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: [https://github.com/kynikos/wiki-monkey/issues/175 #175], [https://github.com/kynikos/wiki-monkey/issues/176 #176], [https://github.com/kynikos/wiki-monkey/issues/197 #197] and [https://github.com/kynikos/wiki-monkey/issues/198 #198].<br />
# ✓ The [[ArchWiki:Maintenance_Team#Current_patrols]] list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.<br />
# ✓ [[ArchWiki:Maintenance_Team#Statistics]] was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.<br />
<br />
Opinions needed. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:11, 6 May 2015 (UTC)<br />
<br />
:: Point 1) Sounds good to me.<br />
:: Point 2) Agreed.<br />
:: Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.<br />
:: Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much. <br />
:: Points 6 & 7) Agreed<br />
:: -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 10:11, 7 May 2015 (UTC)<br />
<br />
:::1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account<br />
:::4,7. I'm neutral on this... I think having [[ArchWiki:Reports]] as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)<br />
:::6. Yep, and not including active members as well. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:10, 7 May 2015 (UTC)<br />
<br />
::::Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.<br />
::::Is it also the time to consider [[ArchWiki_talk:Administrators#Meaning_of_Administrator]] at this point?<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 7 May 2015 (UTC)<br />
<br />
:::::About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.<br />
:::::Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping [[ArchWiki:Reports]] would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to [[ArchWiki:Reports]] too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.<br />
:::::[[ArchWiki_talk:Administrators#Meaning_of_Administrator]] could surely be implemented in this article, it's very related indeed.<br />
:::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 8 May 2015 (UTC)<br />
<br />
::::::I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only. <br />
::::::How about doing it like you propose, but changing procedure for the reports that ''may'' still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 10 May 2015 (UTC)<br />
<br />
:::::::My idea (which I hadn't eleaborated yet here) was to allow the creation of ''quick'' reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from [[ArchWiki:Reports]] as an example of how it could look instead in the affected article's talk page:<br />
::::::::<h2>Quick report</h2><br />
::::::::''[This is an automatic [[ArchWiki:Reports|report]] about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]''<br />
::::::::''Comment'': I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp<br />
:::::::The whole thing could be manually added simply with: <br />
:::::::{{bc|<nowiki>{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~</nowiki>}}<br />
:::::::The link to [[ArchWiki:Reports]] (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.<br />
:::::::If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), [[Special:Diff]] could be used instead of the full link, and it could create the report in full text (i.e. like using the template with ''subst''). <br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:54, 11 May 2015 (UTC)<br />
<br />
::::::::Now in this case I'd like to nominate "(4) to deprecate [[Archwiki:Reports]]" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:48, 11 May 2015 (UTC)<br />
<br />
:::::::::Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:55, 12 May 2015 (UTC)<br />
<br />
:::::::::For the moment I've done points 6 and 7. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:43, 24 May 2015 (UTC)<br />
<br />
::::::::::I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:14, 29 July 2015 (UTC)<br />
<br />
:::::::::::Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in [[ArchWiki:Reports]]' table, which are probably even worse when it comes to [https://github.com/kynikos/wiki-monkey/issues/216 breakability], so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.<br />
:::::::::::I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).<br />
:::::::::::To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:54, 11 August 2015 (UTC)<br />
<br />
::::::::::::Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 13 September 2016 (UTC)<br />
<br />
:::::::::::::I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:51, 14 September 2016 (UTC)<br />
<br />
::::::::::::::I've flagged the page for archiving for now [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=450811&oldid=450669]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:40, 14 September 2016 (UTC)<br />
<br />
== Regular Wiki Cleanup Days ==<br />
<br />
I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 19:45, 11 October 2016 (UTC)<br />
<br />
== Admin guidance ==<br />
<br />
Show we add some guidence that an admin should follow, the responsibilty they should take? <br />
<br />
Example:<br />
* Encourage contribution from Arch users. <br />
* Guide new contributor to follow Arch Wiki Style.<br />
--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:23, 11 July 2014 (UTC)<br />
<br />
:Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in [[#Meaning of Administrator]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:06, 12 July 2014 (UTC)<br />
<br />
:"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:53, 28 April 2021 (UTC)<br />
<br />
== Cite extension ==<br />
<br />
''[Moved from [[User talk:Kynikos#Cite extension]]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 15 January 2015 (UTC)]''<br />
<br />
I'm feeling bad about not having a way to cite my sources properly in my article. As I do for the LibreOffice Newsletter I'm in charge of I'll do as it for my Arch Linux articles:<br />
<br />
{{bc|<nowiki><br />
<br />
Some text<ref name=myRefName /><br />
<br />
== References ==<br />
<br />
<ref name=myRefName>[http://someURL The link]</ref><br />
<br />
</nowiki>}}<br />
<br />
I don't know if this system suits you. Let me know. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 01:07, 10 December 2014 (UTC)<br />
<br />
:Unfortunately you cannot use the ref tag in this wiki, since it requires the Cite extension, which we don't have installed. Generally we don't require to support every statement with citations, unlike for example on Wikipedia, but it will be very useful if you will add references to external sources simply using links on keywords, like [https://www.archlinux.org this], or this<sup>[https://www.archlinux.org]</sup> (see the source text for the implementation; we don't have style rules about this for the moment). If you want to mention the generic sources that you use for writing the article, you should just add them to [[Dynamic Kernel Module Support#See also]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 10 December 2014 (UTC)<br />
<br />
::I don't like this idea very much. The ''See also'' section sounds like we invite the user to read these documents to provide more detailed information to the reader, implying the Arch Linux documentation is not complete enough. This isn't actually what we want to do in this case: we just adapted an existing article to build a section of the Arch Linux documentation page. And yes, I would really like to have citations like in Wikipedia, but without the need to cite every assumptions we make obviously. Would you mind installing the Cite extension? -- [[User:wget|wget]] ([[User talk:wget|talk]]) 12:00, 11 December 2014 (UTC)<br />
<br />
:::Unfortunately installing extensions requires write access to the repository, which is restricted to Developers, and a feature request should be opened in the bug tracker. I don't see other alternatives to the methods I proposed above.<br />
:::That said, ArchWiki articles are not intended to be "complete" as in "it shouldn't be necessary to read anything else in order to understand every detail of the topic"; if the topic has good upstream/official documentation, there's no point in duplicating it, see also [[Help:Style#Hypertext metaphor]].<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:12, 12 December 2014 (UTC)<br />
<br />
:::: Hi Kynikos. Happy New Year! Any news about the citation extension? Yet again today, I wanted to write on the wiki that yaourt does support bash and zsh completion, and to link these assumptions to the source code. The cite extension is indeed very useful, especially in the case (like this one) when upstream has not good documentation. If you haven't already reported the feature request on the bug tracker, are you willing to support the one I'm gonna write? Otherwise, I don't see the interest in writing that request: devs will unlikely accept it without your support. Thanks in advance. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 23:50, 6 January 2015 (UTC)<br />
<br />
:::::Happy New Year mate :) Honestly I don't see the need for the cite extension here: can't you just use simple inline links as I proposed above? (And as it's done in every article?) Sorry, but unless you prove that you really have no way to add that link without the extension, I can't support your request... Just try to amend the article with inline links and let's see how it looks, ok? I'll try to help you fix the style, if needed ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:34, 7 January 2015 (UTC)<br />
<br />
:::::Yesterday again, I was cleaning/updating the [[Browser plugins]] and wanted to put a link to the official where I took that information from. That link concerned two locations in that article: [[Browser plugins#Disable the "Press ESC to exit full screen mode" message|Disable the "Press ESC to exit full screen mode" message]] and [[Browser plugins#Multiple monitor full-screen fix|Multiple monitor full-screen fix]], the solution using inline links was to duplicate that URL which I didn't. Regarding the [https://lists.archlinux.org/pipermail/arch-general/2014-December/038000.html your message], the problem seems to be a lack of workforce then. A possible solution would be merging wikis and forums of the [[International communities|native languages communities]] into Arch Linux infrastructure, bringing along all these admins/maintainers to the Arch infra. But for that a bunch of work needs to be done first: easy multilanguage support (especially regarding links) on the Wiki (maybe native language staff can help for that). -- [[User:wget|wget]] ([[User talk:wget|talk]]) 14:59, 8 January 2015 (UTC)<br />
<br />
::::::I see, actually if you want to use the same link in two different sections, there's nothing against it; even if there was the Cite extension installed, you'd have to duplicate the &lt;ref> tag, right? There are already many articles with multiple instances of the same internal or external links, I don't see any harm with that, as long as the duplicated links are found in indipendent parts of an article.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Yes, just the <ref> tag will need to be duplicated, but the URL, authors, description, etc. will not. That ref will just act as a very short reference to the long <ref> tag written at the end of the article. See [https://wiki.documentfoundation.org/LOWN/5 this example], this is the way we are working at TheDocumentFoundation. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::In general, also expanding on what I wrote in my arch-general post that you linked, my position is that it's too late to install the Cite extension now, because that would only introduce a new style standard for external links that would make all the existing articles style-obsolete, in practice starting a very long — if not infinite — transition period over which articles would have both inline and referenced links, which I wouldn't see as an improvement at all.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Don't underestimate my patience or my scripting abilities ;-), I'm the kind of guy a bit maniac, with obsessive need to get everything neat. So transition period isn't really a problem ;-) -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Eheh I understand, I guess I'm a bit like that myself :P Well, considering that we've got this far, I'm going to move this branch of the discussion to [[ArchWiki talk:Administrators]] and see what are the opinions of the rest of the team. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:::::::::Maybe I'm missing something obvious, but I dislike the Wikipedia citation style simply because it needs 3 clicks instead of one: one to see the link, a second to open it, and a third to return to the article. That said I'm a proponent of requiring citations for statements made on this wiki: [[Help_talk:Style#Citations and reasoning]] (one of these days I'll get to making a draft). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:31, 29 October 2015 (UTC)<br />
<br />
::::::::::What I was saying is that if Wikipedia-style citations had been used from the beginning of this wiki, I think we'd probably be used to them by now; it's true that they require more effort to follow a link if you don't use the mouseover tooltip (e.g. when using pentadactyl, vimfx etc.; tooltips can also be set to appear on click though); on the other hand, though, they encourage the maintenance of a comprehensive list of external reference links at the bottom of each article. Anyway, as I've repeated multiple times, now I'm against introducing Wikipedia-style citations.<br />
::::::::::Regarding requiring citations, I'll wait for your draft, but I think making them a requirement could be too much: what do we do with unreferenced statements? Delete them? Or fill articles with "Citation needed" templates? Wikipedia needs citations more than us because it deals with topics that can be easily discussed from biased standpoints; also, it doesn't allow original research, see also [[Wikipedia:Wikipedia:Verifiability]]. In this wiki, I'd talk more of a recommendation, and well specify what kind of statements should better be referenced.<br />
::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:27, 30 October 2015 (UTC)<br />
<br />
::::::Please see it like this: using inline or referenced links are just two different style conventions: the ArchWiki happens to use the first one, let's just stick to it and concentrate on the rest, ok? :)<br />
<br />
::::::There is indeed a lack of workforce on the back-end, although I have to acknowledge the fact that Pierre has recently finally pushed MediaWiki 1.24 in the repo, which means it will reach the server very soon; anyway, his policy regarding internationalization has always been the opposite of your proposal, i.e. encourage localized versions to host their own wiki, so your idea would find some opposition there; but even if it didn't, I think you're greatly overrating the state of the external Arch wikis: of them, only the German and French wikis are actually alive, and the German wiki is already maintained by Pierre himself :)<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Didn't know much about the wiki infrastructure and native language frequentations, but what I've seen on the #archlinux-fr freenode IRC channel, there are some people involved with the French wiki who could be returned to the official wiki, recovering a bit more workforce. Its a great subject for discussion between officials (Pierre) and third parties IMHO. Yes, I'm in complete favour of federating around a same well defined goal: "Unity makes strength", "United we stand, divided we fall" is my country motto. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Well, my personal opinion, which is not an official position because we've never discussed this among the admins, is that I'd be in favour of returning all the translations in the same wiki, but only after implementing [[Help talk:I18n#Language namespace(s) in place of suffixes?]] and proving that it works efficiently with the languages that are already hosted here; we should also prove that we can merge the databases of the external wikis safely and effectively. Only after that we could discuss the return of the external languages, stressing the fact that the admins coming from the other wikis should be willing to adapt to the English wiki customs, which I wouldn't take for granted.<br />
::::::::For the first step I'll need to complete some adaptations to my bot, but that's not on high priority at the moment: I have a todo list that I follow more or less strictly, and I promise I'll get there :)<br />
::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:: Another advantage of being able to use <nowiki><ref></nowiki> is that one could also add meta information to the URL that's being linked to in order to prevent [https://en.wikipedia.org/wiki/Wikipedia:Bare_URLs link rot]. Not all URLs are descriptive enough to figure out where they might have gone when they're not reachabe anymore and the Wayback Machine wasn't able to crawl the site. -- [[User:Ckujau|Ckujau]] ([[User talk:Ckujau|talk]]) 17:07, 16 July 2017 (UTC)<br />
<br />
== Scribunto ==<br />
<br />
I would like the [[mw:Scribunto]] extension to be installed to the ArchWiki, so that we can improve existing templates and create new useful templates, which currently cannot be implemented. For example we currently cannot [[Help talk:Template#Creation of Template:Info|implement Template:Info]]. Furthermore [[mw:Lua scripting]] would make template code more readable and facilitate maintenance by allowing for translated templates without duplicating the template logic.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 20:07, 17 August 2018 (UTC)<br />
<br />
:Frankly, I don't know how to feel about this. Obviously it would help to fix a lot of problems, but I wouldn't overestimate its usefulness. Lua modules still have to deal with arguments in the MediaWiki markup and the output is integrated back into the MediaWiki markup, so some problems will inherently persist. And since the core markup language sucks, combining it with a perfect scripting language would still be a sucking experience...<br />
:Another thing is that WMF moved to Lua primarily due to [[mw:Lua_scripting#Rationale|performance reasons]] and I don't think that our wiki has any performance problems with the current templates.<br />
:The last thing is a question whether we really ''need'' to invent more and more complicated templates or whether we can keep them simple like they are now. For example, we can say that [[Template:hc]] cannot be used inside lists, which covers at least 99% of the use cases, and for the remaining 1% I'm sure it is possible to adjust the surrounding content of the page to look good even if the template is not inside a list. Having a limited language for writing templates really helps to control the complexity of the resulting templates.<br />
:More opinions needed (especially from the [[archwiki:administrators|administrators]] and [[archwiki:maintainers|maintainers]]).<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:40, 23 August 2018 (UTC)<br />
<br />
== Patch Vector skin to display categories at the top of the page ==<br />
<br />
Categories on the ArchWiki are currently displayed at the bottom of the page. While this is the MediaWiki default, it does make the categories of an article less accessible, especially if the article is long. Because categories provide such a great way to find related articles, I think they deserve to be prominently placed at the top, right below the page heading. This is also more consistent with our convention to keep categories at the top of the source text. I initially [[Mediawiki talk:Common.css#Move categories under h1|tried to implement the change using CSS]] but had to figure out that the two ways to move catlinks to the top with CSS, absolute and flex positioning, cannot be implemented cleanly as both don't work with margin collapsing. [[User:Kynikos|Kynikos]] [https://phabricator.wikimedia.org/T192223 asked WikiMedia] if they would accept a Vector skin patch to implement the feature as an option, to which they didn't respond. I managed to patch the Vector skin to implement the desired change. Although we would need to maintain the patch ourselves, I think it is doable (the patch only changes 10 lines) and warranted as it would improve ArchWiki for every reader (that uses the default skin).<br />
<br />
I submitted my patch as [https://github.com/archlinux/archwiki/pull/18 a pull request] to the ArchWiki GitHub repository.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:01, 18 August 2018 (UTC)<br />
<br />
:Now that my patch was declined the only way left appears to be upstream. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:39, 18 November 2018 (UTC)<br />
<br />
== Convention for splitting sections to new page ==<br />
<br />
Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring [[ArchWiki:Contributing]]. For exemple current [[OpenSSH#Tips_and_tricks]], or [[pacman#Troubleshooting]].<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with [[Template:Move]] and start a discussion in their talk pages (not here).<br />
:Otherwise you can try to propose some generic guidelines, for the moment we have a [[Help:Procedures#Split section to a new subpage|procedure]] to implement a split after an agreement has been reached.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::Maybe not generic criterias, but specific ones. For example sections like {{ic|Tips and tricks}} or {{ic|Troubleshooting}} can expand quickly. A generic rule like: {{ic|if more than 10 subsections are listed, you can move the section in a subarticle without asking first}} -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
::Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::That's not enough, because e.g. [[Chromium/Tips and tricks]] is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have [[ArchWiki:Contributing#The 3 fundamental rules]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:59, 16 June 2019 (UTC)<br />
<br />
::::In case the [[Chromium]] page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The [[Template:Move]] description suggest it is only for renaming articles ? -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:18, 17 June 2019 (UTC) <br />
<br />
:::::I've fixed the [[Template:Move]] description, the template has frequently been used to flag sections to be split, e.g. [[Network configuration#Device driver]], [[Arch terminology#Arch Linux]] or [[List of applications#Network managers]], which works pretty fine. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 17 June 2019 (UTC)<br />
<br />
Also, the {{ic|related articles}} sidebar can appear to be a little bloated on some articles (for exemple [[pacman]]). Should there be a dedicated side bar for subarticles (not sure about the name) like [[pacman/Tips_and_tricks]] in [[pacman]] ?<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:I don't find [[pacman]]'s related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in [[ArchWiki:Sandbox]] -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in [[Help talk:Style]], I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.<br />
:::About separators, I don't like them in this context regardless of the links order :)<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:26, 17 June 2019 (UTC)<br />
<br />
== Remove redirect page with bad title ==<br />
<br />
This topic is similar to above [[#Removing unnecessary redirects / pages]] but with a different target redirections. <br />
<br />
Background: <br />
* The [[Help:Article naming guidelines]] changes along the years, so there exist many Old_Title -> New_Title redirections.<br />
* Many new users contribute to Arch Wiki before they notice there is [[Help:Article naming guidelines]], so there exist many Bad_Title -> Good_Title redirections.<br />
* The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.<br />
<br />
Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes:<br />
Installation guide<br />
Installation Guide<br />
Installation guide(Català)<br />
Installation guide (Català)<br />
Installation Guide (Català)<br />
<br />
Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?<br />
<br />
{{Unsigned|14:21, 14 May 2020 (UTC)|Fengchao}}<br />
<br />
:I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 09:21, 7 June 2020 (UTC)<br />
<br />
:I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to [[Flatpak]] which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:30, 9 May 2021 (UTC)<br />
<br />
:One such redirect (that I think should be deleted) is [[Keeping Docs and Info Files]]. No other wiki pages link to it either. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:44, 9 May 2021 (UTC)<br />
<br />
::That one contains a history, so it should be kept (or archived at most). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:37, 15 May 2021 (UTC)<br />
<br />
:::What about renaming it (to something like [[Keeping documentation and information files]]) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:14, 15 May 2021 (UTC)<br />
<br />
::::I think "info" here was referring to [[info]], but it's still better than the old title which I now deleted. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:01, 7 June 2021 (UTC)<br />
<br />
:::::Thanks. I guess the "bad" title wasn't as bad as I thought then. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 15:17, 7 June 2021 (UTC)<br />
<br />
:Guys, I have made some mess while moving a page into a user subpage, so some redirect pages ought to be deleted:<br />
:* [https://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Dm-crypt/Device encryption (Русский)]<br />
:* [https://wiki.archlinux.org/index.php?title=User:User:Dimadenisjuk/Dm-crypt/Device_encryption_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no User:User:Dimadenisjuk/Dm-crypt/Device encryption (Русский)]<br />
:-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 06:26, 8 June 2021 (UTC)<br />
<br />
::Both pages are now deleted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:11, 8 June 2021 (UTC)<br />
<br />
:::Thanks. I have found that there are a lot of badly named redirects in the Russian AW ([https://wiki.archlinux.org/index.php?title=Pacman/Tips_and_tricks_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)&redirect=no Pacman/Tips and tricks (Русский)], [https://wiki.archlinux.org/index.php?title=Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)/%D0%A1%D0%BE%D0%B2%D0%B5%D1%82%D1%8B_%D0%B8_%D0%BF%D1%80%D0%B8%D1%91%D0%BC%D1%8B&redirect=no Pacman (Русский)/Советы и приёмы], etc.), so later I shall create a list of such pages and put it here.<br />
:::-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 10:44, 8 June 2021 (UTC)<br />
<br />
:Here is one, please delete it: [[RTorrent(简体中文)]]。 -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:27, 22 June 2021 (UTC)<br />
<br />
::Done. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:47, 24 June 2021 (UTC)<br />
<br />
== Are there statistics of page access? ==<br />
<br />
Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:05, 28 June 2020 (UTC)<br />
<br />
:I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:43, 28 June 2020 (UTC)<br />
<br />
::I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:00, 28 June 2020 (UTC)<br />
<br />
:::Agreed. Would be nice to review and assist with what matters most to our users. [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 05:13, 11 July 2020 (UTC)<br />
<br />
== Acceptable user names and signatures ==<br />
<br />
I've just blocked [[User:🥚]] for a week until we make a decision on a general policy, they had only edited their User page, so it's borderline spam or a joke, but that's not my main point.<br />
<br />
I think the user name is practically unsearcheable without copy-pasting, and too hard to address for example in talk pages, it may mess up logs, bots etc.<br />
<br />
1) I propose to limit user names to ascii characters, plus possibly the other languages' characters that we support, but exclude emoticons and other fancy unicode characters. We'd either need a comprehensive definition or reserve the right to decide case by case.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Well, it messed up wiki-scripts and it took me more than an hour to figure out the problem... [https://github.com/lahwaacz/wiki-scripts/commit/25c11f36712df03c705d7cd1d3a8c673fc87360f] To actually limit the user names, we could write an abuse filter with some regex matching (assuming that the extension actually works). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:00, 11 August 2020 (UTC)<br />
<br />
::If we find an exact character set, sure we can try with an abuse filter. For the moment I'm also adding a reference to [[w:Wikipedia:Username_policy#Non-script_usernames]] (and the rest of the page): we may even default to using that page too. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 11 August 2020 (UTC)<br />
<br />
:::Yes, I think that would be a good policy for us too. It's certainly much better than writing our own from scratch :) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:11, 11 August 2020 (UTC)<br />
<br />
::I don't really see an issue with these kind of usernames; if some script can't parse them, then it's the fault of the script not the username. There hasn't yet been a influx of users with malicious intents and ''not-easily typable'' usernames, so I'd rather we don't take a heavy handed approach. Let's not overreact over an egg. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:40, 12 August 2020 (UTC)<br />
<br />
:::Ok that bots are supposed to be able to handle unicode, and the "too hard" in my OP should have better been "needlessly hard", of course we can find our way around [https://xkcd.com/1953/ weird] usernames, still assuming that MediaWiki and the extensions that we use are "ok" with that too (MW is mainly developed around Wikipedia, and adopting a looser username policy may end up into unexplored territory).<br />
:::In general though I think nobody whose goal is constructive interaction with the community would choose a clearly deliberately hard-to-handle username. After all, the purpose of a username is to make oneself easily identifiable by the other members of the community, it's not there only for aesthetic or artistic reasons.<br />
:::I wouldn't see adopting [[w:Wikipedia:Username_policy]] as heavy handed, the restrictions on misleading and disruptive usernames make a lot of sense to me, still leaving a lot of freedom of choice.<br />
:::I'd also be ok to take this to a vote.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Or at least ban custom signatures that hide or change the real username. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
:[[User:😎]] just registered, although this is just a test account of [[User:Klausenbusk]], who is a member of the devops team, this is still relevant. I am still in favor of adopting the blocklist used by Wikipedia, as mentioned in [[#Abusefilter]].<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:34, 5 June 2021 (UTC)<br />
<br />
3) Related: reserve a class of usernames that may be used for official purposes, eg., legal, privacy, policy, security. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:16, 25 August 2021 (UTC)<br />
<br />
== Visual editor ==<br />
<br />
''[Moved from [[Help talk:Editing#Visual Editor]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:22, 23 September 2020 (UTC)]''<br />
<br />
:Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 12:54, 18 September 2020 (UTC)<br />
<br />
::AFAIK no one has proposed adding a visual editor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:28, 18 September 2020 (UTC)<br />
<br />
:::Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 17:39, 23 September 2020 (UTC)<br />
<br />
::::You already have :) And I gathered that you're talking about [[mw:Extension:VisualEditor|Extension:VisualEditor]].<br />
::::MediaWiki 1.35.0 [https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-September/000259.html will be released this week], so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.<br />
::::The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create [[mw:Help:TemplateData|TemplateData]] for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:43, 24 September 2020 (UTC)<br />
<br />
== Define a clear, comprehensive and professional model of documentation ==<br />
<br />
In the beginning of [[ArchWiki:Contributing]] it's written:<br />
<br />
"ArchWiki strives to be a clear, comprehensive and professional model of documentation. "<br />
<br />
However, when I suggested edits to various pages, it turned out that other users had very different views of what makes a page better or worse. Could we create a more concrete and detailed document on the principles of a good page and good wiki?<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 16:21, 17 November 2020 (UTC)<br />
<br />
== Old redirects with broken section links ==<br />
<br />
While fixing dead/broken links I noticed there are quite a few redirects with broken section links. I fixed some of them but there are a handful of old redirects where I would think that archiving is better than fixing them.<br />
I already archived [[Aion]] after discussing this in the wiki IRC channel.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Page<br />
! Last human edit<br />
! Why I am in favor of archiving (or deleting)<br />
|-<br />
| [[Daemon/List]] ||rowspan="3"|August 2015 ||rowspan="4"|There is no list containing daemons anymore. This has become irrelevant because systemd manages them now and as the page mentions, systemctl can be used to get a list of installed service units.<br />
|-<br />
| [[Daemons list]]<br />
|-<br />
| [[Daemons List]]<br />
|-<br />
| [[Daemons List (Español)]] || August 2018<br />
|-<br />
| [[How to customize Motd]] || May 2015 || The only relevant mention I found about the MOTD is a redirect I fixed, [[Motd]], which leads to a section that basically says "edit /etc/motd".<br />
|-<br />
| [[Check if you can resolve domain names]] || May 2018 || I am still unsure about this one. The section has become [https://wiki.archlinux.org/index.php?title=Domain_name_resolution&diff=prev&oldid=547539 "Resolve a domain name using NSS"] but this is not a good hypertext metaphor/topic reference in my opinion.<br />
|-<br />
| [[Network interface controller]] || October 2018 || Links to a section that has been split off into two separate pages. Ethernet and wireless configuration are now separate.<br />
|-<br />
| [[NOOK HD+]] || Feburary 2014 || Links to a section which contained (android-)device specific ADB instructions which were removed, seem to be obsolete and the device is nowhere else mentioned.<br />
|-<br />
| [[Webmail with Thunderbird]] || June 2012 || Severely outdated and broken<br />
|-<br />
| [[wbar]] || August 2014 || Abandoned project, has also been removed from the AUR<br />
|}<br />
<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 11:03, 26 January 2021 (UTC)<br />
<br />
* I've deleted [[Daemon/List]] and [[Daemons List]] (no history) and archived [[Daemons list]] and [[Daemons List (Español)]]<br />
* I've deleted [[How to customize Motd]]<br />
* [[Check if you can resolve domain names]] is still linked from several pages, I'll delete it when it's unused because the title is terrible<br />
* I think [[Network interface controller]] should be redirected where [[Network interface]] links (and the term should actually be used there, e.g. as a link to [[w:Network interface controller|Network interface controller]])<br />
* I've archived [[NOOK HD+]] because there is some history<br />
* [[Webmail with Thunderbird]] had been already archived<br />
* I've archived [[wbar]]<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:24, 9 May 2021 (UTC)<br />
<br />
::I replaced all the things linking to [[check if you can resolve domain names]].<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 12:43, 12 May 2021 (UTC)<br />
<br />
== Outdated pages in the DeveloperWiki ==<br />
<br />
I have encountered [[DeveloperWiki:Linux Conferences]] which is horribly outdated. I hereby request the deletion of the page. I asked about this in the [[ArchWiki:IRC|IRC channel]] and was advised to take this here by [[User:Svito]], which also mentioned that it might make sense to discuss some other, more general questions here:<br />
<br />
# Who is responsible for those?<br />
# Where to nag people to update/archive them? (My comment on this: I already asked on the talk page of a [[DeveloperWiki:Articles Linked from Website|DeveloperWiki article]] to remove a bit from the page because it has a dead link (as you all might have noticed, I like to fix dead and broken links).)<br />
# There are some pages in the DeveloperWiki with one or multiple issues (mostly broken/dead links and outdated stuff), what should be done about that? It clutters the statistics a bit in my opinion<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:23, 15 February 2021 (UTC)<br />
<br />
:# [https://archlinux.org/people/developers/ Developers] are responsible for DeveloperWiki.<br />
:# Refer to 1.<br />
:# Generally we try to refrain from touching DeveloperWiki (that's why it's in such a horrible shape). If you want to change something in a page, it's better to ask a [[Special:ListUsers/archdev|developer]] to do it.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:21, 15 February 2021 (UTC)<br />
<br />
::The DeveloperWiki is basically a wild west. Discussions on talk page will be ignored for the most. The pages are not updated for ages. As the pages are public, the users may want to improve/update the content on such pages if they find it relevant. But users basically are unable to do so. For example, I wanted to update info in the [[DeveloperWiki:UID_/_GID_Database]]. I asked in irc channel my request, but I was told "The devwiki isn't there to teach the general userbase about anything". Then I cannot see a reason to show the page to non-developers users. And I was told "Why hide it?".<br />
::From the reader's perspective of view, such pages are uneditable junk. And no one is going to update it: developers do not care or do not have time, and the developers users are a really little number of people.<br />
::So I think either some pages should be hidden (so in the main wiki userspace users will create an "updatable" version) or info on such pages should be editable in some way (probably by moving some pages to normal namespace). What do you think? [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 16:25, 8 May 2021 (UTC)<br />
<br />
:::Pages in the DeveloperWiki are written by developers for developers, i.e. not for general userbase. From my point of view, they are already "hidden" behind the DeveloperWiki: prefix. If this is not obvious enough, maybe we should make it more understandable somehow.<br />
:::As for the [[DeveloperWiki:UID_/_GID_Database]] page, its purpose is/was to allocate numbers for specific packages. That's it. The documentation of what these users and groups are for and how they should be used belongs to separate pages dedicated to the relevant package. If it is a general system group, it would be described in [[Users and groups#Group list]].<br />
:::— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:18, 8 May 2021 (UTC)<br />
<br />
::::In theory, my understanding was the pool of people both qualified to edit it, and capable of actually doing so, was supposed to be greatly expanded by allowing TUs to do so, but this was waiting on "permission models" of some sort? [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 01:21, 31 May 2021 (UTC)<br />
<br />
:::::I don't think giving TUs access to DeveloperWiki was ever considered from the wiki administrator side. The "privileged" [[ArchWiki:Access levels and roles|access level]] was created and assigned to developers with a different motivation. Though now that it exists, it can be used for such purpose, but such decision must come from developers. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:14, 31 May 2021 (UTC)<br />
<br />
::::::The problem with that, unless we create yet another access level, is that 59 TUs would get "privileged", which can edit the same pages as cosysop (reserved to wiki maintainers). So we'd undo the whole effort of not giving unnecessary wiki-wide permissions to accounts that only need it to edit a few select pages. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:22, 12 June 2021 (UTC)<br />
<br />
:[[User:Jelly]] composed [https://md.archlinux.org/KtVq1GIiSCSQHewRI1IazA a list of pages that can be removed]. I think we can mark them for archiving (or redirection if possible) and per [[ArchWiki:Archive]], archive them after a week. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:40, 15 August 2021 (UTC)<br />
<br />
== Creation of a hardware team ==<br />
<br />
As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The [[Help:Laptop page guidelines|Laptop page guidelines]] have been created and all uncompliant pages have been flagged.<br />
<br />
There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are [[Dell TB16|docks]] on the wiki, [[TerraTec Cinergy T RC MKII USB Stick|exotic USB devices]], [[Hauppauge Nova-T Stick|more exotic USB devices]], [[Vertex VW110L - Ufon|modems]] and more. Also tablet PCs and apparently ARM-devices (yes [[User:nl6720]], I agree that they do not belong here but they are still hardware pages).<br />
<br />
Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.<br />
<br />
There are currently maybe two people (me and [[User:DerpishCat]]) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.<br />
<br />
The goals are:<br />
# Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how<br />
# Make current tasks public so others know what we need help with<br />
# Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.<br />
<br />
The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g [[Help:Style]], some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:49, 7 April 2021 (UTC)<br />
<br />
:So you want to create [[ArchWiki:Hardware Team]]? With only two team members, I think it's a little too soon for that.<br />
:If you simply want a central discussion page, you can use [[Category talk:Hardware]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:59, 7 April 2021 (UTC)<br />
<br />
== Abusefilter ==<br />
<br />
As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.<br />
<br />
I am in favor of adopting [https://en.wikipedia.org/wiki/User:AmandaNP/UAA/Blacklist the "block"list that Wikipedia uses], with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:<br />
<br />
* If certain derivatives (e.g Manjaro) or other distros are in the name.<br />
* Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.<br />
* This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.<br />
<br />
Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like [https://en.wikipedia.org/wiki/User:ClueBot_NG ClueBot NG] but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.<br />
<br />
It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:50, 28 April 2021 (UTC)<br />
<br />
:We should also enable [[mw:Extension:AntiSpoof]]. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 30 April 2021 (UTC)<br />
<br />
::I agree with that. That looks like it will be beneficial, too.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:01, 30 April 2021 (UTC)<br />
<br />
== Commercial self-promotion on the ArchWiki ==<br />
<br />
See [[Special:Diff/670967|670967]], this is clearly ''commercial'' self-promotion here (Sidenote: using "latest" as the archiso version gets old really quickly). This is a very new account and also their first edit.<br />
<br />
I did not undo this because this is not clearly defined anywhere. I would like your opinions on this.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 09:32, 14 May 2021 (UTC)<br />
: Looks like spam to me... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]])<br />
<br />
== Visited links are gray ==<br />
<br />
This makes the links blend in with the regular text on the page, especially when using [https://darkreader.org/ Dark Reader].<br />
{{Unsigned|07:30, 16 May 2021 (UTC)|Glibg10b}}<br />
<br />
: From an accssibility/usability perspective, this is a terrible choice; something with some contrast for colourblind or visually impaired people would be a much better choice. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 06:00, 31 May 2021 (UTC)<br />
<br />
:: Which color would you prefer for visited links? The [https://archlinux.org/ archweb] site currently uses the same color for visited and unvisited links, which effectively disabled highlighting visited links... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:52, 4 June 2021 (UTC)<br />
<br />
== Delete Improving performance (简体中文) tmp ==<br />
<br />
This page was originally moved to [[User:Dragonwater/Improving performance (简体中文) tmp]], but due to [[User:Dragonwater|Dragonwater]]'s editing, this page still exists, so please delete it. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 11:31, 4 June 2021 (UTC)<br />
<br />
:xx Talk before move page that created just before. xx<br />
:Everyone's works needs be respect. I hope maintenance members modify/move/delete pages with cautious. I just don't want get a contradiction just because page has a state changed or see my pages are move/delete when save. This is not a rule surely, but makes better.<br />
:-- [[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 11:50, 4 June 2021 (UTC)<br />
<br />
::If I understood it correctly, trailing " tmp" in article's name means the article is intended as a draft. Such ''temporary'' pages must not appear in the main namespace. [[User:Blackteahamburger|Blackteahamburger]] was right moving this draft into your personal subpage where you can finish the translation. After completing the translation, you can publish the clean version in the main namespace by choosing the [[Help:I18n#Page titles|appropriate name]]. Second page creation is an accident, there is no crime in it.<br />
::-- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 16:03, 4 June 2021 (UTC)<br />
<br />
::: I know I make a wrong, but I hope members inform me before move a page that likely editing.<br />
::: I'm sorry for what mistake I make. Edit contradiction always be annoying, a page missing even more.<br />
::: [[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 03:36, 5 June 2021 (UTC)<br />
<br />
::::In fact, this cannot be done because there is no way to know if anyone is editing. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:20, 5 June 2021 (UTC)<br />
<br />
== Who, when and how to contact ==<br />
<br />
To solve the expansion template in [[ArchWiki:Maintenance Team#Members]] ("Explain who should be contacted with which issues"), I propose moving the contact related instructions to a separate top level section and make it into a list. Additionally, I added links to [[ArchWiki talk:Requests]] and [[ArchWiki:IRC]]. See draft below. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:39, 13 June 2021 (UTC)<br />
<br />
: Maybe we should mention [[Help talk:Style]] before [[ArchWiki talk:Maintenance Team]] as another general talk page? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:07, 1 August 2021 (UTC)<br />
<br />
::Sure. Just find a way to shoehorn it in. :) . -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:23, 4 August 2021 (UTC)<br />
<br />
:::I've added a suggestion to the draft, feel free to improve or accept it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:34, 8 August 2021 (UTC)<br />
<br />
:I added a bullet point about privacy requests. The username is a placeholder until we decide on it.<br />
:I'm also thinking that maybe "This allows making reasonable assumptions about the link between the username and email address" should be omitted.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:19, 25 August 2021 (UTC)<br />
<br />
=== Draft ===<br />
<br />
==== Who, when and how to contact ====<br />
<br />
All members of the Maintenance Team provide ways to contact them personally if you desire so. Nevertheless, prefer using the following methods instead.<br />
<br />
* For page-specific comments, use its talk page which can be accessed from the [[Help:Discussion|discussion]] tab above each page.<br />
* For generic requests regarding wiki content, use [[ArchWiki talk:Requests]].<br />
* To discuss style conventions used on the wiki pages, use [[Help talk:Style]].<br />
* To discuss wiki content organization, or if you require assistance from the Maintenance Team, use [[ArchWiki talk:Maintenance Team]].<br />
* For privacy requests (e.g. wiki account deletion), send an email from wiki interface using ''<nowiki>[[Special:EmailUser/INSERT_USERNAME_OF_DEDICATED_USER_HERE]]</nowiki>''. This allows making reasonable assumptions about the link between the username and email address. This is the only accepted method for sending privacy requests regarding the wiki.<br />
* For other matters (not related to privacy) that cannot be discussed publicly, contact the ArchWiki Administrators by sending an email from wiki interface using [[Special:EmailUser/WikiSysop]]. This method allows making reasonable assumptions about the link between the username and email address.<br />
* Casual, non-binding discussions with wiki contributors (which may include members of the Maintenance Team) can also be held in the [[ArchWiki:IRC|#archlinux-wiki IRC channel]].<br />
<br />
==== Members ====<br />
<br />
Maintainers belong to a particular group of wiki users with [[Special:ListGroupRights|special rights]]. Administrators and bureaucrats are maintainers with higher access levels, see [[ArchWiki:Access levels and roles]].<br />
<br />
== How to change packaging policies ==<br />
<br />
I recently made a note about the [[Talk:Wine package guidelines|Wine Package Guidelines talk page]] because I want to modify them slightly. I'm new to editing here, so I was wondering if there was a proper procedure for doing this. Do I simply take initiative and watch for if people complain?<br />
<br />
[[User:VinceUB|VinceUB]] ([[User talk:VinceUB|talk]]) 07:42, 5 August 2021 (UTC)<br />
<br />
== Long, cluttered and hard to maintain pages ==<br />
<br />
Unfortunately there are some pages on here which are hard to maintain because:<br />
* It is hard to validate the information without the specific hardware or software (which tends to be proprietary and may cost a lot)<br />
* No one knows if this still applies since the information may be ancient and the above still applies<br />
* There is so much content that transformed the page into something that is not feasible to maintain.<br />
<br />
These are pages where lots of users contributed their individual solutions to and this basically spiralled out of control. The worst pages in this category are:<br />
<br />
* [[Mac]]<br />
* [[Steam/Game-specific troubleshooting]]<br />
* Some laptop vendor pages, but this might be a different although vaguely similar topic. These have grown into spreadsheets and some are pretty bad.<br />
** [[Laptop/Acer]] is by far the worst.<br />
<br />
Other pages which are not as bad yet but should be monitored:<br />
<br />
* [[PCI passthrough via OVMF/Examples]] - was pruned recently<br />
* Laptop vendor pages (e.g [[Laptop/Lenovo]]) - mentioned in [[Category talk:Hardware]], part of a bigger problem<br />
* [[Dotfiles]]<br />
<br />
Both lists are unfortunately yet incomplete I suspect.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 01:23, 10 August 2021 (UTC)<br />
<br />
:The same applies to almost all troubleshooting sections and pages: [[Network configuration/Wireless#Troubleshooting drivers and firmware]], [[Bluetooth#Troubleshooting]], [[PulseAudio/Troubleshooting]], [[Firefox#Troubleshooting]], [[NVIDIA/Troubleshooting]] etc. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:56, 10 August 2021 (UTC)<br />
<br />
::At least for troubleshooting sections, [[Help:Style#"Troubleshooting" section]] says to link the bug or create a bug report if there isn't any. There's nothing we can do for sections that don't include any bug links. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:50, 10 August 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=692343Gopher2021-08-21T06:07:30Z<p>Jasonwryan: Reverted edits by Lahwaacz.bot (talk) to last revision by Flyingpig</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
{{Related articles start}}<br />
{{Related|Gemini}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== GoFish server ==<br />
<br />
[http://gofish.sourceforge.net/ GoFish] is a basic gopher server that allows you to run your own gopherspace. The setup is somewhat like other servers, but generally requires less resources to function.<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{AUR|gofish-bin}}{{Broken package link|package not found}} package.<br />
<br />
=== Configuration ===<br />
<br />
There are some basic settings for the server you can change in the {{ic|/etc/gofish.conf}} file, but the defaults will work. If you do not alter any settings, the root of the gopher server will be {{ic|/var/gopher}} and it will run on port 70. (Note that Firefox can only use the gopher protocol on port 70, so changing it will mean your users must use some other client.)<br />
<br />
To run the server, [[start]] {{ic|gofish.service}}.<br />
<br />
You can now connect to your server and see what you have by navigating to gopher://127.0.0.1<br />
<br />
=== .cache ===<br />
<br />
Unlike FTP which automatically shows all files, gopher relies on a file called {{ic|.cache}} in each directory to determine how the page will be shown to the end user. Although GoFish comes with the {{man|5|dotcache|url=}} man page for the {{ic|.cache}} files, it can be a little confusing. GoFish also comes with a program to autogenerate {{ic|.cache}} files for all the directories and files in your server root.<br />
<br />
mkcache -r<br />
<br />
This will create all the needed {{ic|.cache}} files recursively, but you may want to edit some names. A sample {{ic|.cache}} file will look something like this:<br />
<br />
iHello none example.com 70<br />
0ReadMe 0/ReadMe.txt example.com 70<br />
1Ebooks 1/ebooks example.com 70<br />
<br />
The gopher protocol uses number prefixes to describe filetype. {{ic|0}} is a plain text file, {{ic|1}} is a directory and {{ic|9}} is a binary file. The {{ic|i}} indicates an image, and if it is linked to {{ic|none}}, it will show up as plain text. This is good for introducing your site. See the {{man|5|dotcache|url=}} man page for more info on the prefixes. After the prefix number is the name that will appear in the client, and it does not need to be the same as the file it links to. In the second section, we see the "path" to the file. There is not a directory named {{ic|0}} or {{ic|1}} in the file system, it is only added in the URI to let the gopher server and end user know what sort of file it is. The third section is whatever domain name the site is, and the fourth is the port it is on, default is 70. The space between each of the 4 sections must be a tab, not a space or it will not be parsed correctly.<br />
<br />
Now let us look at the {{ic|.cache}} file in the ebooks directory.<br />
<br />
9Book 1 9/ebooks/Book1.chm example.com 70<br />
9Book 2 9/ebooks/Book2.pdf example.com 70<br />
<br />
Notice that the URI is {{ic|9/ebooks/Book1.chm}}, NOT {{ic|1/ebooks/9Book1.chm}} . There is always only one prefix number for the last item in the URI. Also notice that a chm file nor a pdf file is really a binary, but it is still given the prefix of {{ic|9}}. In the GoFish server, any file that is not a text file or a directory is given the binary prefix. Remember that if there are files within your server's root, people can download or view them even if they are not in your {{ic|.cache}} file, so be careful.<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check {{aur|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [http://gofish.sourceforge.net/ GoFish Homepage]<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Gopher&diff=692121Talk:Gopher2021-08-18T23:18:41Z<p>Jasonwryan: Page needs a total rewrite</p>
<hr />
<div>This page is almost completely redundant now. The AUR go-fish package is no longer a gopher server, and go-fish itself is dead. I'm proposing to rewrite the page to be more generic, and not rely on a single application, and to include some relevant information about configuring content, etc. Any objections? [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 23:17, 18 August 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=691716Gopher2021-08-14T08:37:24Z<p>Jasonwryan: Reverted edits by Lahwaacz.bot (talk) to last revision by Jasonwryan</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== GoFish server ==<br />
<br />
[http://gofish.sourceforge.net/ GoFish] is a basic gopher server that allows you to run your own gopherspace. The setup is somewhat like other servers, but generally requires less resources to function.<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{AUR|gofish-bin}}{{Broken package link|package not found}} package.<br />
<br />
=== Configuration ===<br />
<br />
There are some basic settings for the server you can change in the {{ic|/etc/gofish.conf}} file, but the defaults will work. If you do not alter any settings, the root of the gopher server will be {{ic|/var/gopher}} and it will run on port 70. (Note that Firefox can only use the gopher protocol on port 70, so changing it will mean your users must use some other client.)<br />
<br />
To run the server, [[start]] {{ic|gofish.service}}.<br />
<br />
You can now connect to your server and see what you have by navigating to gopher://127.0.0.1<br />
<br />
=== .cache ===<br />
<br />
Unlike FTP which automatically shows all files, gopher relies on a file called {{ic|.cache}} in each directory to determine how the page will be shown to the end user. Although GoFish comes with the {{man|5|dotcache|url=}} man page for the {{ic|.cache}} files, it can be a little confusing. GoFish also comes with a program to autogenerate {{ic|.cache}} files for all the directories and files in your server root.<br />
<br />
mkcache -r<br />
<br />
This will create all the needed {{ic|.cache}} files recursively, but you may want to edit some names. A sample {{ic|.cache}} file will look something like this:<br />
<br />
iHello none example.com 70<br />
0ReadMe 0/ReadMe.txt example.com 70<br />
1Ebooks 1/ebooks example.com 70<br />
<br />
The gopher protocol uses number prefixes to describe filetype. {{ic|0}} is a plain text file, {{ic|1}} is a directory and {{ic|9}} is a binary file. The {{ic|i}} indicates an image, and if it is linked to {{ic|none}}, it will show up as plain text. This is good for introducing your site. See the {{man|5|dotcache|url=}} man page for more info on the prefixes. After the prefix number is the name that will appear in the client, and it does not need to be the same as the file it links to. In the second section, we see the "path" to the file. There is not a directory named {{ic|0}} or {{ic|1}} in the file system, it is only added in the URI to let the gopher server and end user know what sort of file it is. The third section is whatever domain name the site is, and the fourth is the port it is on, default is 70. The space between each of the 4 sections must be a tab, not a space or it will not be parsed correctly.<br />
<br />
Now let us look at the {{ic|.cache}} file in the ebooks directory.<br />
<br />
9Book 1 9/ebooks/Book1.chm example.com 70<br />
9Book 2 9/ebooks/Book2.pdf example.com 70<br />
<br />
Notice that the URI is {{ic|9/ebooks/Book1.chm}}, NOT {{ic|1/ebooks/9Book1.chm}} . There is always only one prefix number for the last item in the URI. Also notice that a chm file nor a pdf file is really a binary, but it is still given the prefix of {{ic|9}}. In the GoFish server, any file that is not a text file or a directory is given the binary prefix. Remember that if there are files within your server's root, people can download or view them even if they are not in your {{ic|.cache}} file, so be careful.<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check {{aur|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [http://gofish.sourceforge.net/ GoFish Homepage]<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Gopher&diff=691694Gopher2021-08-14T08:10:25Z<p>Jasonwryan: The linked AUR package has the same name, but a completely different function</p>
<hr />
<div>[[Category:Protocols]]<br />
[[ja:Gopher]]<br />
[[pt:Gopher]]<br />
[[Wikipedia:Gopher (protocol)|Gopher]] is a protocol for information transfer over the internet that was very popular before HTTP took over as the dominant protocol, but there is still a community of gopher users that prefer the simplicity of the protocol over the more complex and large protocols more often encountered. Note that not all browsers support gopher, or have incomplete support.<br />
<br />
== GoFish server ==<br />
<br />
[http://gofish.sourceforge.net/ GoFish] is a basic gopher server that allows you to run your own gopherspace. The setup is somewhat like other servers, but generally requires less resources to function.<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{AUR|gofish-bin}}{{Broken package link|package not found}} package.<br />
<br />
=== Configuration ===<br />
<br />
There are some basic settings for the server you can change in the {{ic|/etc/gofish.conf}} file, but the defaults will work. If you do not alter any settings, the root of the gopher server will be {{ic|/var/gopher}} and it will run on port 70. (Note that Firefox can only use the gopher protocol on port 70, so changing it will mean your users must use some other client.)<br />
<br />
To run the server, [[start]] {{ic|gofish.service}}.<br />
<br />
You can now connect to your server and see what you have by navigating to gopher://127.0.0.1<br />
<br />
=== .cache ===<br />
<br />
Unlike FTP which automatically shows all files, gopher relies on a file called {{ic|.cache}} in each directory to determine how the page will be shown to the end user. Although GoFish comes with the {{man|5|dotcache|url=}} man page for the {{ic|.cache}} files, it can be a little confusing. GoFish also comes with a program to autogenerate {{ic|.cache}} files for all the directories and files in your server root.<br />
<br />
mkcache -r<br />
<br />
This will create all the needed {{ic|.cache}} files recursively, but you may want to edit some names. A sample {{ic|.cache}} file will look something like this:<br />
<br />
iHello none example.com 70<br />
0ReadMe 0/ReadMe.txt example.com 70<br />
1Ebooks 1/ebooks example.com 70<br />
<br />
The gopher protocol uses number prefixes to describe filetype. {{ic|0}} is a plain text file, {{ic|1}} is a directory and {{ic|9}} is a binary file. The {{ic|i}} indicates an image, and if it is linked to {{ic|none}}, it will show up as plain text. This is good for introducing your site. See the {{man|5|dotcache|url=}} man page for more info on the prefixes. After the prefix number is the name that will appear in the client, and it does not need to be the same as the file it links to. In the second section, we see the "path" to the file. There is not a directory named {{ic|0}} or {{ic|1}} in the file system, it is only added in the URI to let the gopher server and end user know what sort of file it is. The third section is whatever domain name the site is, and the fourth is the port it is on, default is 70. The space between each of the 4 sections must be a tab, not a space or it will not be parsed correctly.<br />
<br />
Now let us look at the {{ic|.cache}} file in the ebooks directory.<br />
<br />
9Book 1 9/ebooks/Book1.chm example.com 70<br />
9Book 2 9/ebooks/Book2.pdf example.com 70<br />
<br />
Notice that the URI is {{ic|9/ebooks/Book1.chm}}, NOT {{ic|1/ebooks/9Book1.chm}} . There is always only one prefix number for the last item in the URI. Also notice that a chm file nor a pdf file is really a binary, but it is still given the prefix of {{ic|9}}. In the GoFish server, any file that is not a text file or a directory is given the binary prefix. Remember that if there are files within your server's root, people can download or view them even if they are not in your {{ic|.cache}} file, so be careful.<br />
<br />
== Overbite for Firefox ==<br />
<br />
[https://gopher.floodgap.com/overbite/ The Overbite Project] enables gopherspace in some browsers and devices, including Mozilla Firefox. Check {{aur|firefox-extension-overbitenx}} or [https://addons.mozilla.org/firefox/addon/overbitewx/ overbitewx] add-on.<br />
<br />
{{Note|OverbiteNX and OverbiteWX are successors of the previous Firefox addon OverbiteFF, as noted in these extensions' websites.}}<br />
<br />
== HTTP access via Gopher proxy ==<br />
<br />
You can use https://gopher.floodgap.com/gopher/gw to browse the Gopher network via HTTP, e.g. using a browser not Gopher-enabled.<br />
<br />
== See also ==<br />
<br />
* [http://gofish.sourceforge.net/ GoFish Homepage]<br />
* [https://gopher.floodgap.com/gopher/gw?gopher/1/new Example of Gopher websites]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Maintenance_Team&diff=674680ArchWiki talk:Maintenance Team2021-05-31T06:00:17Z<p>Jasonwryan: /* Visited links are gray */ This needs fixing</p>
<hr />
<div>{{Note|This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.}}<br />
<br />
== Reorganization ==<br />
<br />
The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.<br />
<br />
However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:<br />
<br />
# I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".<br />
# ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.<br />
# ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of [[ArchWiki talk:Administrators]] (e.g. update the link in [[ArchWiki:Contributing#Complaining]]).<br />
# ✓ I'd like to deprecate [[ArchWiki:Reports]], and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to ''also'' report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes. <br> Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation. <br> Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.<br />
# Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: [https://github.com/kynikos/wiki-monkey/issues/175 #175], [https://github.com/kynikos/wiki-monkey/issues/176 #176], [https://github.com/kynikos/wiki-monkey/issues/197 #197] and [https://github.com/kynikos/wiki-monkey/issues/198 #198].<br />
# ✓ The [[ArchWiki:Maintenance_Team#Current_patrols]] list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.<br />
# ✓ [[ArchWiki:Maintenance_Team#Statistics]] was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.<br />
<br />
Opinions needed. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:11, 6 May 2015 (UTC)<br />
<br />
:: Point 1) Sounds good to me.<br />
:: Point 2) Agreed.<br />
:: Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.<br />
:: Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much. <br />
:: Points 6 & 7) Agreed<br />
:: -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 10:11, 7 May 2015 (UTC)<br />
<br />
:::1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account<br />
:::4,7. I'm neutral on this... I think having [[ArchWiki:Reports]] as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)<br />
:::6. Yep, and not including active members as well. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:10, 7 May 2015 (UTC)<br />
<br />
::::Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.<br />
::::Is it also the time to consider [[ArchWiki_talk:Administrators#Meaning_of_Administrator]] at this point?<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 7 May 2015 (UTC)<br />
<br />
:::::About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.<br />
:::::Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping [[ArchWiki:Reports]] would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to [[ArchWiki:Reports]] too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.<br />
:::::[[ArchWiki_talk:Administrators#Meaning_of_Administrator]] could surely be implemented in this article, it's very related indeed.<br />
:::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 8 May 2015 (UTC)<br />
<br />
::::::I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only. <br />
::::::How about doing it like you propose, but changing procedure for the reports that ''may'' still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 10 May 2015 (UTC)<br />
<br />
:::::::My idea (which I hadn't eleaborated yet here) was to allow the creation of ''quick'' reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from [[ArchWiki:Reports]] as an example of how it could look instead in the affected article's talk page:<br />
::::::::<h2>Quick report</h2><br />
::::::::''[This is an automatic [[ArchWiki:Reports|report]] about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]''<br />
::::::::''Comment'': I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp<br />
:::::::The whole thing could be manually added simply with: <br />
:::::::{{bc|<nowiki>{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~</nowiki>}}<br />
:::::::The link to [[ArchWiki:Reports]] (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.<br />
:::::::If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), [[Special:Diff]] could be used instead of the full link, and it could create the report in full text (i.e. like using the template with ''subst''). <br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:54, 11 May 2015 (UTC)<br />
<br />
::::::::Now in this case I'd like to nominate "(4) to deprecate [[Archwiki:Reports]]" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:48, 11 May 2015 (UTC)<br />
<br />
:::::::::Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:55, 12 May 2015 (UTC)<br />
<br />
:::::::::For the moment I've done points 6 and 7. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:43, 24 May 2015 (UTC)<br />
<br />
::::::::::I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:14, 29 July 2015 (UTC)<br />
<br />
:::::::::::Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in [[ArchWiki:Reports]]' table, which are probably even worse when it comes to [https://github.com/kynikos/wiki-monkey/issues/216 breakability], so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.<br />
:::::::::::I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).<br />
:::::::::::To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:54, 11 August 2015 (UTC)<br />
<br />
::::::::::::Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 13 September 2016 (UTC)<br />
<br />
:::::::::::::I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:51, 14 September 2016 (UTC)<br />
<br />
::::::::::::::I've flagged the page for archiving for now [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=450811&oldid=450669]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:40, 14 September 2016 (UTC)<br />
<br />
== Regular Wiki Cleanup Days ==<br />
<br />
I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 19:45, 11 October 2016 (UTC)<br />
<br />
== Admin guidance ==<br />
<br />
Show we add some guidence that an admin should follow, the responsibilty they should take? <br />
<br />
Example:<br />
* Encourage contribution from Arch users. <br />
* Guide new contributor to follow Arch Wiki Style.<br />
--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:23, 11 July 2014 (UTC)<br />
<br />
:Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in [[#Meaning of Administrator]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:06, 12 July 2014 (UTC)<br />
<br />
:"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:53, 28 April 2021 (UTC)<br />
<br />
== Cite extension ==<br />
<br />
''[Moved from [[User talk:Kynikos#Cite extension]]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 15 January 2015 (UTC)]''<br />
<br />
I'm feeling bad about not having a way to cite my sources properly in my article. As I do for the LibreOffice Newsletter I'm in charge of I'll do as it for my Arch Linux articles:<br />
<br />
{{bc|<nowiki><br />
<br />
Some text<ref name=myRefName /><br />
<br />
== References ==<br />
<br />
<ref name=myRefName>[http://someURL The link]</ref><br />
<br />
</nowiki>}}<br />
<br />
I don't know if this system suits you. Let me know. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 01:07, 10 December 2014 (UTC)<br />
<br />
:Unfortunately you cannot use the ref tag in this wiki, since it requires the Cite extension, which we don't have installed. Generally we don't require to support every statement with citations, unlike for example on Wikipedia, but it will be very useful if you will add references to external sources simply using links on keywords, like [https://www.archlinux.org this], or this<sup>[https://www.archlinux.org]</sup> (see the source text for the implementation; we don't have style rules about this for the moment). If you want to mention the generic sources that you use for writing the article, you should just add them to [[Dynamic Kernel Module Support#See also]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 10 December 2014 (UTC)<br />
<br />
::I don't like this idea very much. The ''See also'' section sounds like we invite the user to read these documents to provide more detailed information to the reader, implying the Arch Linux documentation is not complete enough. This isn't actually what we want to do in this case: we just adapted an existing article to build a section of the Arch Linux documentation page. And yes, I would really like to have citations like in Wikipedia, but without the need to cite every assumptions we make obviously. Would you mind installing the Cite extension? -- [[User:wget|wget]] ([[User talk:wget|talk]]) 12:00, 11 December 2014 (UTC)<br />
<br />
:::Unfortunately installing extensions requires write access to the repository, which is restricted to Developers, and a feature request should be opened in the bug tracker. I don't see other alternatives to the methods I proposed above.<br />
:::That said, ArchWiki articles are not intended to be "complete" as in "it shouldn't be necessary to read anything else in order to understand every detail of the topic"; if the topic has good upstream/official documentation, there's no point in duplicating it, see also [[Help:Style#Hypertext metaphor]].<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:12, 12 December 2014 (UTC)<br />
<br />
:::: Hi Kynikos. Happy New Year! Any news about the citation extension? Yet again today, I wanted to write on the wiki that yaourt does support bash and zsh completion, and to link these assumptions to the source code. The cite extension is indeed very useful, especially in the case (like this one) when upstream has not good documentation. If you haven't already reported the feature request on the bug tracker, are you willing to support the one I'm gonna write? Otherwise, I don't see the interest in writing that request: devs will unlikely accept it without your support. Thanks in advance. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 23:50, 6 January 2015 (UTC)<br />
<br />
:::::Happy New Year mate :) Honestly I don't see the need for the cite extension here: can't you just use simple inline links as I proposed above? (And as it's done in every article?) Sorry, but unless you prove that you really have no way to add that link without the extension, I can't support your request... Just try to amend the article with inline links and let's see how it looks, ok? I'll try to help you fix the style, if needed ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:34, 7 January 2015 (UTC)<br />
<br />
:::::Yesterday again, I was cleaning/updating the [[Browser plugins]] and wanted to put a link to the official where I took that information from. That link concerned two locations in that article: [[Browser plugins#Disable the "Press ESC to exit full screen mode" message|Disable the "Press ESC to exit full screen mode" message]] and [[Browser plugins#Multiple monitor full-screen fix|Multiple monitor full-screen fix]], the solution using inline links was to duplicate that URL which I didn't. Regarding the [https://lists.archlinux.org/pipermail/arch-general/2014-December/038000.html your message], the problem seems to be a lack of workforce then. A possible solution would be merging wikis and forums of the [[International communities|native languages communities]] into Arch Linux infrastructure, bringing along all these admins/maintainers to the Arch infra. But for that a bunch of work needs to be done first: easy multilanguage support (especially regarding links) on the Wiki (maybe native language staff can help for that). -- [[User:wget|wget]] ([[User talk:wget|talk]]) 14:59, 8 January 2015 (UTC)<br />
<br />
::::::I see, actually if you want to use the same link in two different sections, there's nothing against it; even if there was the Cite extension installed, you'd have to duplicate the &lt;ref> tag, right? There are already many articles with multiple instances of the same internal or external links, I don't see any harm with that, as long as the duplicated links are found in indipendent parts of an article.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Yes, just the <ref> tag will need to be duplicated, but the URL, authors, description, etc. will not. That ref will just act as a very short reference to the long <ref> tag written at the end of the article. See [https://wiki.documentfoundation.org/LOWN/5 this example], this is the way we are working at TheDocumentFoundation. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::In general, also expanding on what I wrote in my arch-general post that you linked, my position is that it's too late to install the Cite extension now, because that would only introduce a new style standard for external links that would make all the existing articles style-obsolete, in practice starting a very long — if not infinite — transition period over which articles would have both inline and referenced links, which I wouldn't see as an improvement at all.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Don't underestimate my patience or my scripting abilities ;-), I'm the kind of guy a bit maniac, with obsessive need to get everything neat. So transition period isn't really a problem ;-) -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Eheh I understand, I guess I'm a bit like that myself :P Well, considering that we've got this far, I'm going to move this branch of the discussion to [[ArchWiki talk:Administrators]] and see what are the opinions of the rest of the team. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:::::::::Maybe I'm missing something obvious, but I dislike the Wikipedia citation style simply because it needs 3 clicks instead of one: one to see the link, a second to open it, and a third to return to the article. That said I'm a proponent of requiring citations for statements made on this wiki: [[Help_talk:Style#Citations and reasoning]] (one of these days I'll get to making a draft). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:31, 29 October 2015 (UTC)<br />
<br />
::::::::::What I was saying is that if Wikipedia-style citations had been used from the beginning of this wiki, I think we'd probably be used to them by now; it's true that they require more effort to follow a link if you don't use the mouseover tooltip (e.g. when using pentadactyl, vimfx etc.; tooltips can also be set to appear on click though); on the other hand, though, they encourage the maintenance of a comprehensive list of external reference links at the bottom of each article. Anyway, as I've repeated multiple times, now I'm against introducing Wikipedia-style citations.<br />
::::::::::Regarding requiring citations, I'll wait for your draft, but I think making them a requirement could be too much: what do we do with unreferenced statements? Delete them? Or fill articles with "Citation needed" templates? Wikipedia needs citations more than us because it deals with topics that can be easily discussed from biased standpoints; also, it doesn't allow original research, see also [[Wikipedia:Wikipedia:Verifiability]]. In this wiki, I'd talk more of a recommendation, and well specify what kind of statements should better be referenced.<br />
::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:27, 30 October 2015 (UTC)<br />
<br />
::::::Please see it like this: using inline or referenced links are just two different style conventions: the ArchWiki happens to use the first one, let's just stick to it and concentrate on the rest, ok? :)<br />
<br />
::::::There is indeed a lack of workforce on the back-end, although I have to acknowledge the fact that Pierre has recently finally pushed MediaWiki 1.24 in the repo, which means it will reach the server very soon; anyway, his policy regarding internationalization has always been the opposite of your proposal, i.e. encourage localized versions to host their own wiki, so your idea would find some opposition there; but even if it didn't, I think you're greatly overrating the state of the external Arch wikis: of them, only the German and French wikis are actually alive, and the German wiki is already maintained by Pierre himself :)<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Didn't know much about the wiki infrastructure and native language frequentations, but what I've seen on the #archlinux-fr freenode IRC channel, there are some people involved with the French wiki who could be returned to the official wiki, recovering a bit more workforce. Its a great subject for discussion between officials (Pierre) and third parties IMHO. Yes, I'm in complete favour of federating around a same well defined goal: "Unity makes strength", "United we stand, divided we fall" is my country motto. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Well, my personal opinion, which is not an official position because we've never discussed this among the admins, is that I'd be in favour of returning all the translations in the same wiki, but only after implementing [[Help talk:I18n#Language namespace(s) in place of suffixes?]] and proving that it works efficiently with the languages that are already hosted here; we should also prove that we can merge the databases of the external wikis safely and effectively. Only after that we could discuss the return of the external languages, stressing the fact that the admins coming from the other wikis should be willing to adapt to the English wiki customs, which I wouldn't take for granted.<br />
::::::::For the first step I'll need to complete some adaptations to my bot, but that's not on high priority at the moment: I have a todo list that I follow more or less strictly, and I promise I'll get there :)<br />
::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:: Another advantage of being able to use <nowiki><ref></nowiki> is that one could also add meta information to the URL that's being linked to in order to prevent [https://en.wikipedia.org/wiki/Wikipedia:Bare_URLs link rot]. Not all URLs are descriptive enough to figure out where they might have gone when they're not reachabe anymore and the Wayback Machine wasn't able to crawl the site. -- [[User:Ckujau|Ckujau]] ([[User talk:Ckujau|talk]]) 17:07, 16 July 2017 (UTC)<br />
<br />
== Scribunto ==<br />
<br />
I would like the [[mw:Scribunto]] extension to be installed to the ArchWiki, so that we can improve existing templates and create new useful templates, which currently cannot be implemented. For example we currently cannot [[Help talk:Template#Creation of Template:Info|implement Template:Info]]. Furthermore [[mw:Lua scripting]] would make template code more readable and facilitate maintenance by allowing for translated templates without duplicating the template logic.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 20:07, 17 August 2018 (UTC)<br />
<br />
:Frankly, I don't know how to feel about this. Obviously it would help to fix a lot of problems, but I wouldn't overestimate its usefulness. Lua modules still have to deal with arguments in the MediaWiki markup and the output is integrated back into the MediaWiki markup, so some problems will inherently persist. And since the core markup language sucks, combining it with a perfect scripting language would still be a sucking experience...<br />
:Another thing is that WMF moved to Lua primarily due to [[mw:Lua_scripting#Rationale|performance reasons]] and I don't think that our wiki has any performance problems with the current templates.<br />
:The last thing is a question whether we really ''need'' to invent more and more complicated templates or whether we can keep them simple like they are now. For example, we can say that [[Template:hc]] cannot be used inside lists, which covers at least 99% of the use cases, and for the remaining 1% I'm sure it is possible to adjust the surrounding content of the page to look good even if the template is not inside a list. Having a limited language for writing templates really helps to control the complexity of the resulting templates.<br />
:More opinions needed (especially from the [[archwiki:administrators|administrators]] and [[archwiki:maintainers|maintainers]]).<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:40, 23 August 2018 (UTC)<br />
<br />
== Patch Vector skin to display categories at the top of the page ==<br />
<br />
Categories on the ArchWiki are currently displayed at the bottom of the page. While this is the MediaWiki default, it does make the categories of an article less accessible, especially if the article is long. Because categories provide such a great way to find related articles, I think they deserve to be prominently placed at the top, right below the page heading. This is also more consistent with our convention to keep categories at the top of the source text. I initially [[Mediawiki talk:Common.css#Move categories under h1|tried to implement the change using CSS]] but had to figure out that the two ways to move catlinks to the top with CSS, absolute and flex positioning, cannot be implemented cleanly as both don't work with margin collapsing. [[User:Kynikos|Kynikos]] [https://phabricator.wikimedia.org/T192223 asked WikiMedia] if they would accept a Vector skin patch to implement the feature as an option, to which they didn't respond. I managed to patch the Vector skin to implement the desired change. Although we would need to maintain the patch ourselves, I think it is doable (the patch only changes 10 lines) and warranted as it would improve ArchWiki for every reader (that uses the default skin).<br />
<br />
I submitted my patch as [https://github.com/archlinux/archwiki/pull/18 a pull request] to the ArchWiki GitHub repository.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:01, 18 August 2018 (UTC)<br />
<br />
:Now that my patch was declined the only way left appears to be upstream. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:39, 18 November 2018 (UTC)<br />
<br />
== Convention for splitting sections to new page ==<br />
<br />
Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring [[ArchWiki:Contributing]]. For exemple current [[OpenSSH#Tips_and_tricks]], or [[pacman#Troubleshooting]].<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with [[Template:Move]] and start a discussion in their talk pages (not here).<br />
:Otherwise you can try to propose some generic guidelines, for the moment we have a [[Help:Procedures#Split section to a new subpage|procedure]] to implement a split after an agreement has been reached.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::Maybe not generic criterias, but specific ones. For example sections like {{ic|Tips and tricks}} or {{ic|Troubleshooting}} can expand quickly. A generic rule like: {{ic|if more than 10 subsections are listed, you can move the section in a subarticle without asking first}} -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
::Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::That's not enough, because e.g. [[Chromium/Tips and tricks]] is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have [[ArchWiki:Contributing#The 3 fundamental rules]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:59, 16 June 2019 (UTC)<br />
<br />
::::In case the [[Chromium]] page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The [[Template:Move]] description suggest it is only for renaming articles ? -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:18, 17 June 2019 (UTC) <br />
<br />
:::::I've fixed the [[Template:Move]] description, the template has frequently been used to flag sections to be split, e.g. [[Network configuration#Device driver]], [[Arch terminology#Arch Linux]] or [[List of applications#Network managers]], which works pretty fine. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 17 June 2019 (UTC)<br />
<br />
Also, the {{ic|related articles}} sidebar can appear to be a little bloated on some articles (for exemple [[pacman]]). Should there be a dedicated side bar for subarticles (not sure about the name) like [[pacman/Tips_and_tricks]] in [[pacman]] ?<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:I don't find [[pacman]]'s related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in [[ArchWiki:Sandbox]] -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in [[Help talk:Style]], I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.<br />
:::About separators, I don't like them in this context regardless of the links order :)<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:26, 17 June 2019 (UTC)<br />
<br />
== Remove redirect page with bad title ==<br />
<br />
This topic is similar to above [[#Removing unnecessary redirects / pages]] but with a different target redirections. <br />
<br />
Background: <br />
* The [[Help:Article naming guidelines]] changes along the years, so there exist many Old_Title -> New_Title redirections.<br />
* Many new users contribute to Arch Wiki before they notice there is [[Help:Article naming guidelines]], so there exist many Bad_Title -> Good_Title redirections.<br />
* The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.<br />
<br />
Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes:<br />
Installation guide<br />
Installation Guide<br />
Installation guide(Català)<br />
Installation guide (Català)<br />
Installation Guide (Català)<br />
<br />
Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?<br />
<br />
{{Unsigned|14:21, 14 May 2020 (UTC)|Fengchao}}<br />
<br />
:I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 09:21, 7 June 2020 (UTC)<br />
<br />
:I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to [[Flatpak]] which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:30, 9 May 2021 (UTC)<br />
<br />
:One such redirect (that I think should be deleted) is [[Keeping Docs and Info Files]]. No other wiki pages link to it either. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:44, 9 May 2021 (UTC)<br />
<br />
::That one contains a history, so it should be kept (or archived at most). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:37, 15 May 2021 (UTC)<br />
<br />
:::What about renaming it (to something like [[Keeping documentation and information files]]) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:14, 15 May 2021 (UTC)<br />
<br />
== Are there statistics of page access? ==<br />
<br />
Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:05, 28 June 2020 (UTC)<br />
<br />
:I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:43, 28 June 2020 (UTC)<br />
<br />
::I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:00, 28 June 2020 (UTC)<br />
<br />
:::Agreed. Would be nice to review and assist with what matters most to our users. [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 05:13, 11 July 2020 (UTC)<br />
<br />
== Acceptable user names and signatures ==<br />
<br />
I've just blocked [[User:🥚]] for a week until we make a decision on a general policy, they had only edited their User page, so it's borderline spam or a joke, but that's not my main point.<br />
<br />
I think the user name is practically unsearcheable without copy-pasting, and too hard to address for example in talk pages, it may mess up logs, bots etc.<br />
<br />
1) I propose to limit user names to ascii characters, plus possibly the other languages' characters that we support, but exclude emoticons and other fancy unicode characters. We'd either need a comprehensive definition or reserve the right to decide case by case.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Well, it messed up wiki-scripts and it took me more than an hour to figure out the problem... [https://github.com/lahwaacz/wiki-scripts/commit/25c11f36712df03c705d7cd1d3a8c673fc87360f] To actually limit the user names, we could write an abuse filter with some regex matching (assuming that the extension actually works). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:00, 11 August 2020 (UTC)<br />
<br />
::If we find an exact character set, sure we can try with an abuse filter. For the moment I'm also adding a reference to [[w:Wikipedia:Username_policy#Non-script_usernames]] (and the rest of the page): we may even default to using that page too. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 11 August 2020 (UTC)<br />
<br />
:::Yes, I think that would be a good policy for us too. It's certainly much better than writing our own from scratch :) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:11, 11 August 2020 (UTC)<br />
<br />
::I don't really see an issue with these kind of usernames; if some script can't parse them, then it's the fault of the script not the username. There hasn't yet been a influx of users with malicious intents and ''not-easily typable'' usernames, so I'd rather we don't take a heavy handed approach. Let's not overreact over an egg. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:40, 12 August 2020 (UTC)<br />
<br />
:::Ok that bots are supposed to be able to handle unicode, and the "too hard" in my OP should have better been "needlessly hard", of course we can find our way around [https://xkcd.com/1953/ weird] usernames, still assuming that MediaWiki and the extensions that we use are "ok" with that too (MW is mainly developed around Wikipedia, and adopting a looser username policy may end up into unexplored territory).<br />
:::In general though I think nobody whose goal is constructive interaction with the community would choose a clearly deliberately hard-to-handle username. After all, the purpose of a username is to make oneself easily identifiable by the other members of the community, it's not there only for aesthetic or artistic reasons.<br />
:::I wouldn't see adopting [[w:Wikipedia:Username_policy]] as heavy handed, the restrictions on misleading and disruptive usernames make a lot of sense to me, still leaving a lot of freedom of choice.<br />
:::I'd also be ok to take this to a vote.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Or at least ban custom signatures that hide or change the real username. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
== Switch to another editor ==<br />
<br />
There is a request to switch to another editor: {{Bug|55828}}. Apparently the original "2006-core-Editor" was removed in MW 1.30 and now there is only a plain textarea without any toolbar with various markup buttons. Some users may find it difficult to format an article without knowing the MediaWiki markup, but I'm not fond of enabling something that provides buttons to insert &lt;code>, &lt;pre> and even other HTML tags. Users should always learn the markup and [[Help:Style]] (at least basics) if they want to contribute regularly. What do you think? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:22, 12 September 2020 (UTC)<br />
<br />
:I've only taken a quick look at the proposed extension, but it seems it can be customised to a great extent, so I'd be in favour only if we adapt it to comply with our style rules.<br />
:[devil's_advocate]$ Requiring people to edit without UI aids may end up resulting in more typos/syntax mistakes, or simply discouraging contributions. Also, we're in 2020 and we must assume that there are people who want to contribute through smartphones, and entering non-alphanumeric characters on a thumb keyboard can be exhausting. <br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:21, 13 September 2020 (UTC)<br />
<br />
::I'm not against switching the editor. The only issue I see with the proposed [[mw:Extension:WikiEditor|Extension:WikiEditor]] is that it has a "Reference" button that inserts {{ic|<nowiki><ref></ref></nowiki>}} and ArchWiki doesn't enable [[mw:Extension:Cite|Extension:Cite]]. Changing the toolbar requires [[mw:Extension:WikiEditor#Configuration|editing a file in the extension's directory]] which is not really pretty or feasible.<br />
::We could also wait for MediaWiki 1.35 and use the "2017 wikitext editor", but that's part of [[mw:Extension:VisualEditor|Extension:VisualEditor]] and I don't know if it's possible to disable the visual editing mode.<br />
::On the topic of editor improvements, both of the aforementioned editors support syntax highlighting using [[mw:Extension:CodeMirror|Extension:CodeMirror]]. If we're changing the editor, I'd like to enable syntax highlighting for it too.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:36, 13 September 2020 (UTC)<br />
<br />
:::Draft PR: https://github.com/archlinux/archwiki/pull/32 -- 09:19, 13 September 2020 (UTC)<br />
<br />
:::VisualEditor requires setting up Parsoid and RESTBase, which seems too complicated. The "2017 wikitext editor" probably works without that, but we would still have to find the configuration to disable the "visual" mode (if it is even possible). It also probably still includes the {{ic|<nowiki><ref></ref></nowiki>}} button.<br />
:::The [[mw:Extension:WikiEditor|Extension:WikiEditor]] might be configurable with a site-wide javascript: [[mw:Extension:WikiEditor/Toolbar_customization#Removing_things]] I think that would be good enough for us...<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 13 September 2020 (UTC)<br />
<br />
::::According to [[mw:Parsoid]], "Parsoid (the PHP version) is natively bundled in MediaWiki 1.35". That's why I said if we want the "2017 wikitext editor", we should wait till MediaWiki 1.35 is released. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:39, 13 September 2020 (UTC)<br />
<br />
::::According to the docs, it should be possible to remove the button with: {{bc|<nowiki><br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'main',<br />
'group': 'insert',<br />
'tool': 'reference'<br />
});<br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'help',<br />
'page': 'reference'<br />
});<br />
</nowiki>}}<br />
::::But I could only get it to work this way: {{bc|<nowiki><br />
$( '#wpTextbox1' ).on( 'wikiEditor-toolbar-doneInitialSections', function () {<br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'main',<br />
'group': 'insert',<br />
'tool': 'reference'<br />
});<br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'help',<br />
'page': 'reference'<br />
});<br />
} );<br />
</nowiki>}}<br />
::::Unfortunately the button is visible for a moment before it's removed.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:11, 13 September 2020 (UTC)<br />
<br />
::::MediaWiki 1.35 is out, so it's time for some testing.<br />
::::It is possible to disable visual editing mode of [[mw:Extension:VisualEditor|Extension:VisualEditor]] and use only the "2017 wikitext editor": {{bc|<nowiki><br />
wfLoadExtension( 'VisualEditor' );<br />
$wgDefaultUserOptions['visualeditor-enable'] = 0;<br />
$wgHiddenPrefs[] = 'visualeditor-enable';<br />
$wgVisualEditorEnableWikitext = true;<br />
$wgDefaultUserOptions['visualeditor-newwikitext'] = 1;<br />
$wgHiddenPrefs[] = 'visualeditor-newwikitext';<br />
</nowiki>}}<br />
::::And unlike with [[mw:Extension:WikiEditor|Extension:WikiEditor]], in 2017 wikitext editor there is no "reference/cite" button if [[mw:Extension:Cite|Extension:Cite]] is not enabled.<br />
::::I haven't gotten far with the visual mode. <s>I followed [[mw:Parsoid/PHP]] and since I'm using {{Pkg|mediawiki}}, I set {{ic|1=$PARSOID_INSTALL_DIR = '/usr/share/webapps/mediawiki/vendor/wikimedia/parsoid';}}. Unfortunetly I'm stuck with {{ic|Error contacting the Parsoid/RESTBase server (HTTP 403)}}</s> :(<br />
::::-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:59, 26 September 2020 (UTC)<br />
<br />
:::::Actually Parsoid doesn't need configuring. I missed the obvious thing that [[mw:RESTBase|RESTBase]] needs to be installed separately, that's too much of a hassle for me. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:50, 27 September 2020 (UTC)<br />
<br />
::::::Unless someone is willing to research how to set up [[mw:RESTBase|RESTBase]] for Arch Wiki, we can't use the 2017 wikitext editor or Visual Editor. So, how about we switch (at least for now) to [[mw:Extension:WikiEditor|Extension:WikiEditor]] with [[mw:Extension:CodeMirror|Extension:CodeMirror]] for syntax highlighting? 👍 on https://github.com/archlinux/archwiki/pull/32 if you agree. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:05, 1 January 2021 (UTC)<br />
<br />
:::::::I just tried that "2010 wikitext editor" and besides the &lt;ref>&lt;/ref> button there are other things that I'm not very happy about: picture upload dialogue, buttons for subscripts, superscripts and font sizes, and a "References" section in the help overview... But I guess we can hide all that when the extension is enabled. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 9 January 2021 (UTC)<br />
<br />
::::::::"References" would be removed from Help with [[MediaWiki:Common.js|site-wide JS]] as shown above. I agree about removing "Images and media" (picture upload), "Picture gallery" and maybe font size, but I don't see much of an issue with subscript and superscript. We do use them in some pages. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:36, 9 January 2021 (UTC)<br />
<br />
:::https://github.com/archlinux/archwiki/pull/32 has been merged. Deployment is still pending: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/366.<br />
:::I updated [[MediaWiki:Common.js]] to remove the reference button and its help. Do we want to remove anything else? E.g. image upload, big text, small text or picture gallery?<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:15, 30 April 2021 (UTC)<br />
<br />
::::I'm for removing everything related to images to clean up the interface and font sizes (big/small text) to avoid "style abuse". But we can wait until it's deployed and it actually starts causing problems... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:42, 8 May 2021 (UTC)<br />
<br />
== Visual editor ==<br />
<br />
''[Moved from [[Help talk:Editing#Visual Editor]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:22, 23 September 2020 (UTC)]''<br />
<br />
:Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 12:54, 18 September 2020 (UTC)<br />
<br />
::AFAIK no one has proposed adding a visual editor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:28, 18 September 2020 (UTC)<br />
<br />
:::Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 17:39, 23 September 2020 (UTC)<br />
<br />
::::You already have :) And I gathered that you're talking about [[mw:Extension:VisualEditor|Extension:VisualEditor]].<br />
::::MediaWiki 1.35.0 [https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-September/000259.html will be released this week], so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.<br />
::::The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create [[mw:Help:TemplateData|TemplateData]] for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:43, 24 September 2020 (UTC)<br />
<br />
== Define a clear, comprehensive and professional model of documentation ==<br />
<br />
In the beginning of [[ArchWiki:Contributing]] it's written:<br />
<br />
"ArchWiki strives to be a clear, comprehensive and professional model of documentation. "<br />
<br />
However, when I suggested edits to various pages, it turned out that other users had very different views of what makes a page better or worse. Could we create a more concrete and detailed document on the principles of a good page and good wiki?<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 16:21, 17 November 2020 (UTC)<br />
<br />
== Bullying on ArchWiki ==<br />
<br />
As it was discussed above, I wanted to make a complaint about the user [[User:Scimmia|Scimmia]]. I registered on ArchWiki in November this year. I used that extensively and spotted several things which could be improved. I proposed several things on talk pages, but all my proposals were rejected, and in majority of cases it was done by Scimmia. Here I’m not arguing that they should be accepted, but my complaint is about the form of communication used by Scimmia.<br />
<br />
I copy several examples of conversations below, all markup is mine.<br />
<br />
On the 16th of November I give a detailed explanation on a suggested edit here (https://wiki.archlinux.org/index.php?title=Talk:EFISTUB&oldid=641787#Expand_'preparing_for_EFISTUB'), and receive a brief answer<br />
<br />
“'''Nothing about this edit makes sense'''. You're assuming what kernel was installed, and '''adding no useful information'''. Scimmia (talk) 14:30, 17 November 2020 (UTC)”<br />
<br />
...<br />
<br />
“See, '''you're not even aware''' of the different kernels available in Arch. '''You should really stop making suggestions based on ignorance'''. Scimmia (talk) 15:00, 17 November 2020 (UTC)”<br />
<br />
...<br />
<br />
“No, this is Arch, we must NOT assume lack of knowledge. '''Arch assumes users are experienced Linux users'''. Scimmia (talk) 15:14, 17 November 2020 (UTC)”<br />
<br />
When after a long discussion with a moderator I give another example of usage, <br />
“"change a boot disk for the OS or want install a different boot loader" - this is not a user error.”, Scimmia replies<br />
<br />
“It is '''if you have no idea what you're doing'''. Scimmia (talk) 16:28, 17 November 2020 (UTC)”<br />
<br />
The same day I propose a concrete change for a similar page (https://wiki.archlinux.org/index.php?title=Talk:GRUB&oldid=641780#Add_information_how_to_generate_the_bootable_files)<br />
The next answer is <br />
<br />
“'''Nothing about this makes sense'''. You deleted your kernel, then expect the docs to know that '''you screwed up'''? Scimmia (talk) 14:34, 17 November 2020 (UTC)”<br />
<br />
...<br />
<br />
“I propose that if you format the boot partition, '''you have some idea what you're doing'''. Scimmia (talk) 15:05, 17 November 2020 (UTC)”<br />
The answers by Scimmia, if not rude, were rather unpleasant. It seemed that they are mostly not relevant to the discussion, very brief and careless, and he wrote them just to oppose, regardless of the arguments (which sometimes were self-contradictory).<br />
<br />
https://wiki.archlinux.org/index.php?title=Talk:General_recommendations&oldid=641904#Leave_codecs_section<br />
<br />
“So your argument is based on the assumption that the software will just '''magically''' find '''whatever''' you have installed without any internal coding for it? '''Think again'''. Scimmia (talk) 13:28, 18 November 2020 (UTC)”<br />
<br />
(which is wrong, because this is how dynamic libraries work)<br />
<br />
“'''Mods, I think it's obvious''' at this point that '''this argument comes from ignorance''', nothing more. Can '''we just delete''' the section and close this? Scimmia (talk) 15:08, 18 November 2020 (UTC)”<br />
<br />
After Scimmia reverted my edits several times, I made an appeal to moderators (https://wiki.archlinux.org/index.php?title=Talk:General_recommendations&oldid=641904#Mods_intervention_needed)<br />
<br />
The moderator made no remark about Scimmia’s behaviour (although there were definitely two participants in the “edit war”), and made a humiliating remark how I should improve “my behaviour”:<br />
<br />
“Here are some links '''for you to read''' and '''improve your behavior''': Code of conduct#Respect other users, Code of conduct#Respect the staff, Code of conduct#No trolling, Code of conduct#Ineffective discussion ("bikeshed"). -- Lahwaacz (talk) 20:01, 18 November 2020 (UTC)”<br />
<br />
I got very tired of Scimmia’s remarks to each of my talk or propositions. I thought that I could find a compromise with him, and wrote to his talk page (https://wiki.archlinux.org/index.php?title=User_talk:Scimmia&oldid=641860),<br />
<br />
“Question<br />
<br />
I'm not sure where I should ask this, but will try it here. I wrote to some moderators asking where to complain about people's actions. While they are replying to this, can I ask you?<br />
<br />
Could you please not get involved in my discussions (talks) on wiki pages and in my edits? If my edits are counterproductive, other people will revert them, won't they?..<br />
<br />
You are number one user who replied most to me during my presence in Arch Wiki, you wrote a lot to me, and I feel your manner highly toxic personally for me at this given moment. Thank you for understanding, no offense meant. Ynikitenko (talk) 18:41, 18 November 2020 (UTC)<br />
<br />
Doesn't work that way. If you '''keep suggesting bad edits''' based on a '''lack of understanding''' of the subjects in question, '''I'll keep responding or reverting'''. As for complaining to the mods, please do, all it does is highlight '''your bad edits'''.<br />
Scimmia (talk) 21:09, 18 November 2020 (UTC)”<br />
<br />
So again I received a bunch of offences and accusations in bad edits.<br />
<br />
The next day I created another discussion (https://wiki.archlinux.org/index.php?title=Talk:General_recommendations&oldid=641904#Links_to_other_multimedia_pages)<br />
<br />
Another administrator replied to my suggestion, and I replied him. Right after my reply Scimmia intervened again:<br />
<br />
“'''Why is this still going on?''' The decision has been made, the section is gone, and the user arguing the other side '''doesn't know how libraries work'''. Just '''let this die'''. Scimmia (talk) 14:32, 19 November 2020 (UTC)”<br />
<br />
I repeat, that this rude comment was posted not after another moderator’s reply, but in 8 minutes after mine.<br />
<br />
Again, the administrator who previously supported Scimmia’s actions, classified this discussion as “ineffective”, even though it was a discussion on importance of codecs (and depending on that, presence of a link to them on that page).<br />
<br />
“Discussion pages on the wiki are intended for discussing what is written on the relevant wiki page. They are not intended for general discussions. In particular, this discussion page is not intended for discussions such as '''explaining you how libraries work''', how Arch Linux packagers choose to implement dependencies between packages, how Ubuntu or any other Linux distribution (let alone operating system) does something differently, etc. <br />
This discussion has become ineffective, so I've split it from the previous (unrelated) discussion and closed it too. Use a different forum for general discussion. <br />
-- Lahwaacz (talk) 14:56, 19 November 2020 (UTC)”<br />
<br />
In [[Code of conduct#Respect_other_users]] it’s written, that “Arch Linux is a respectful, inclusive community. Anti-social or offensive behaviour '''will not be tolerated'''.”<br />
<br />
I think this is a good time to show how this will not be tolerated. <br />
<br />
I find Arch Forum and Arch bug tracker pretty useful, and I get if not 100% great, but never offensive responses there. I never faced such accusations of ignorance on any other technical site in 15 years, neither in ArchWiki from other users. I admit that my very first suggestion on a talk page in ArchWiki was wrong, because of a bug in my installation media, but I don’t think this justifies the manner in which Scimmia replied to majority of my later suggestions.<br />
<br />
I also mentioned above that all my edits and proposals were rejected. I think this is probably because of the setting what Arch Wiki is. [[ArchWiki:Contributing#The_most_important_task]] is declared as this: “add your favorite articles to your watchlist and protect them against counter-productive edits.” (markup removed by me). This is because ArchWiki is perfect. Written by professionals. For professionals.<br />
<br />
After these “discussions” I had no interest in doing anything more on ArchWiki, but I wanted to at least flag a complaint about such behaviour. This was disrupted by an administrator, who warned me to think twice, because Scimmia is from the staff, and staff must be respected (however vague that may be in this case). Lahwaacz didn’t reply to my questions, and I think respect he promotes so much includes willingness to answer another person. No moderator saw anything bad about Scimmia’s behaviour, no one noted anything about Lahwaacz’s actions. I think that a supportive collective is good, but probably not for complaints about collective’s members from outsiders.<br />
<br />
If ArchWiki doesn’t invite any new users to participate, this should be honestly said in its documents and organization, and not imposed through '''permanent humiliation'''. <br />
<br />
Definition from the American Psychological Association:<br />
<br />
“Bullying is a form of aggressive behavior in which someone intentionally and repeatedly causes another person injury or discomfort. Bullying can take the form of physical contact, words or more subtle actions.<br />
<br />
…<br />
<br />
The bullied individual typically has trouble defending him or herself and does nothing to “cause” the bullying.” (other sources mention an imbalance of power in the situation of bullying)<br />
<br />
https://www.apa.org/topics/bullying<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 15:17, 31 December 2020 (UTC)<br />
<br />
: Most of this page is now you complaining about Scimmia. Nothing in Scimmia's comments to your edits appear to me to be anything more than frustration with someone repeatedly making low quality edits. Perhaps, rather than spamming the wiki with your sense of entitlement and victimhood, you might devote some energy to reading documentation in order to increase your own knowledge? You aren't being "bullied": you are being a nuisance. -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:14, 31 December 2020 (UTC)<br />
<br />
::Sorry, Jasonwryan. You don't have to read this whole page if it's inconvenient for you. You can use navigation at the top of the page to select topics to your liking, or just to relax and have some rest. Probably I should had written a complaint long before your friend Scimmia generated so many offensive, nonsensical and rude remarks.<br />
::I doubted whether I should answer such a comment at all, but it shows that absence of any respect is not so uncommon in this wiki, so I'll have to write to other Arch people outside that. You may reread your comment and the definition of "bullying" above, and see that this is exactly the case. I hope that I don't have to make a special complaint to administrators about your behaviour (that is that they see it themselves, not that it's normal).<br />
::-- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 20:33, 31 December 2020 (UTC)<br />
<br />
:::Since you're now resorting to threats, it's clear there's nothing be achieved here. Closing the discussion. Happy new year. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:46, 31 December 2020 (UTC)<br />
<br />
::::I would not call that resorting to threats. As I wrote in the post here, I have a strong feeling that ArchWiki administrators are absolutely unwilling to find any problem in their or their colleague's behaviour. I wrote to Levente Polyak, because when I listened to his talk at the Arch Conference this year, he specifically mentioned the value of the community. I don't think that this can be a really bad thing for ArchWiki maintainers, but you can judge that yourself. I don't think that this discussion should be closed based on that. <br />
::::Thank you, and happy new year to you too and all who develops Arch Wiki. I would gladly had written this complaint before, but first I was very confused with the reply of Lahwaacz and made a separate complaint, then I wanted to live through all those emotions before the complaint, then I was busy; and I didn't want to start this discussion in 2021.<br />
::::P.S. And no, this topic doesn't occupy most of this page, this is just false.<br />
::::[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 21:00, 31 December 2020 (UTC)<br />
<br />
I'm reopening this complaint, because it was closed wrongly. There is nothing that prohibits complaining to the Arch maintainer (he didn't reply yet). Honestly I've no idea why this could be bad. I explained why I wanted to ask him about this case, but I'd still want to get an answer from ArchWiki administrators. Since we've a long way ahead of us together, it's better to solve problems than to ignore them. I understand that the complaint is sensitive, but I think someone can abstract out and solve this objectively. There is no one else to solve this issue except the administration command.<br />
<br />
If you think this section should be closed, close it with another reason. <br />
So I hope someone from Arch Wiki administrators (who reads this and understands), or the collective gives a reply. When it's closed by one admin (wrongly), I'm afraid that the admin who replies to complaints or the collective may miss this.<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 19:43, 7 January 2021 (UTC)<br />
<br />
:I have read the complaint and the edit made by the user at the first link (article about EFISTUB). I can confirm that the edit was useless. In the talk page he was informed about his mistake (about assuming that there are no other kernels, or that the user have no idea about boot partition when changing disk). There was no bulling there.<br />
:Some of my edits are also reverted by lahwaacz (or other users). I do not treat this as "bulling" at all, because he cares about explaining _why_ he does a revert (btw, thank you for that, lahwaacz). And still, if you are absolutely sure of your edit or have another thought about how to improve the info, you are welcome to discuss it in talk pages. No need to start an edit war.<br />
:I think this discussion may be closed now. [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 23:51, 8 May 2021 (UTC)<br />
<br />
== Old redirects with broken section links ==<br />
<br />
While fixing dead/broken links I noticed there are quite a few redirects with broken section links. I fixed some of them but there are a handful of old redirects where I would think that archiving is better than fixing them.<br />
I already archived [[Aion]] after discussing this in the wiki IRC channel.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Page<br />
! Last human edit<br />
! Why I am in favor of archiving (or deleting)<br />
|-<br />
| [[Daemon/List]] ||rowspan="3"|August 2015 ||rowspan="4"|There is no list containing daemons anymore. This has become irrelevant because systemd manages them now and as the page mentions, systemctl can be used to get a list of installed service units.<br />
|-<br />
| [[Daemons list]]<br />
|-<br />
| [[Daemons List]]<br />
|-<br />
| [[Daemons List (Español)]] || August 2018<br />
|-<br />
| [[How to customize Motd]] || May 2015 || The only relevant mention I found about the MOTD is a redirect I fixed, [[Motd]], which leads to a section that basically says "edit /etc/motd".<br />
|-<br />
| [[Check if you can resolve domain names]] || May 2018 || I am still unsure about this one. The section has become [https://wiki.archlinux.org/index.php?title=Domain_name_resolution&diff=prev&oldid=547539 "Resolve a domain name using NSS"] but this is not a good hypertext metaphor/topic reference in my opinion.<br />
|-<br />
| [[Network interface controller]] || October 2018 || Links to a section that has been split off into two separate pages. Ethernet and wireless configuration are now separate.<br />
|-<br />
| [[NOOK HD+]] || Feburary 2014 || Links to a section which contained (android-)device specific ADB instructions which were removed, seem to be obsolete and the device is nowhere else mentioned.<br />
|-<br />
| [[Webmail with Thunderbird]] || June 2012 || Severely outdated and broken<br />
|-<br />
| [[wbar]] || August 2014 || Abandoned project, has also been removed from the AUR<br />
|}<br />
<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 11:03, 26 January 2021 (UTC)<br />
<br />
* I've deleted [[Daemon/List]] and [[Daemons List]] (no history) and archived [[Daemons list]] and [[Daemons List (Español)]]<br />
* I've deleted [[How to customize Motd]]<br />
* [[Check if you can resolve domain names]] is still linked from several pages, I'll delete it when it's unused because the title is terrible<br />
* I think [[Network interface controller]] should be redirected where [[Network interface]] links (and the term should actually be used there, e.g. as a link to [[w:Network interface controller|Network interface controller]])<br />
* I've archived [[NOOK HD+]] because there is some history<br />
* [[Webmail with Thunderbird]] had been already archived<br />
* I've archived [[wbar]]<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:24, 9 May 2021 (UTC)<br />
<br />
::I replaced all the things linking to [[check if you can resolve domain names]].<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 12:43, 12 May 2021 (UTC)<br />
<br />
== Outdated pages in the DeveloperWiki ==<br />
<br />
I have encountered [[DeveloperWiki:Linux Conferences]] which is horribly outdated. I hereby request the deletion of the page. I asked about this in the [[ArchWiki:IRC|IRC channel]] and was advised to take this here by [[User:Svito]], which also mentioned that it might make sense to discuss some other, more general questions here:<br />
<br />
# Who is responsible for those?<br />
# Where to nag people to update/archive them? (My comment on this: I already asked on the talk page of a [[DeveloperWiki:Articles Linked from Website|DeveloperWiki article]] to remove a bit from the page because it has a dead link (as you all might have noticed, I like to fix dead and broken links).)<br />
# There are some pages in the DeveloperWiki with one or multiple issues (mostly broken/dead links and outdated stuff), what should be done about that? It clutters the statistics a bit in my opinion<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:23, 15 February 2021 (UTC)<br />
<br />
:# [https://archlinux.org/people/developers/ Developers] are responsible for DeveloperWiki.<br />
:# Refer to 1.<br />
:# Generally we try to refrain from touching DeveloperWiki (that's why it's in such a horrible shape). If you want to change something in a page, it's better to ask a [[Special:ListUsers/archdev|developer]] to do it.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:21, 15 February 2021 (UTC)<br />
<br />
::The DeveloperWiki is basically a wild west. Discussions on talk page will be ignored for the most. The pages are not updated for ages. As the pages are public, the users may want to improve/update the content on such pages if they find it relevant. But users basically are unable to do so. For example, I wanted to update info in the [[DeveloperWiki:UID_/_GID_Database]]. I asked in irc channel my request, but I was told "The devwiki isn't there to teach the general userbase about anything". Then I cannot see a reason to show the page to non-developers users. And I was told "Why hide it?".<br />
::From the reader's perspective of view, such pages are uneditable junk. And no one is going to update it: developers do not care or do not have time, and the developers users are a really little number of people.<br />
::So I think either some pages should be hidden (so in the main wiki userspace users will create an "updatable" version) or info on such pages should be editable in some way (probably by moving some pages to normal namespace). What do you think? [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 16:25, 8 May 2021 (UTC)<br />
<br />
:::Pages in the DeveloperWiki are written by developers for developers, i.e. not for general userbase. From my point of view, they are already "hidden" behind the DeveloperWiki: prefix. If this is not obvious enough, maybe we should make it more understandable somehow.<br />
:::As for the [[DeveloperWiki:UID_/_GID_Database]] page, its purpose is/was to allocate numbers for specific packages. That's it. The documentation of what these users and groups are for and how they should be used belongs to separate pages dedicated to the relevant package. If it is a general system group, it would be described in [[Users and groups#Group list]].<br />
:::— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:18, 8 May 2021 (UTC)<br />
<br />
::::In theory, my understanding was the pool of people both qualified to edit it, and capable of actually doing so, was supposed to be greatly expanded by allowing TUs to do so, but this was waiting on "permission models" of some sort? [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 01:21, 31 May 2021 (UTC)<br />
<br />
== Creation of a hardware team ==<br />
<br />
As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The [[Help:Laptop page guidelines|Laptop page guidelines]] have been created and all uncompliant pages have been flagged.<br />
<br />
There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are [[Dell TB16|docks]] on the wiki, [[TerraTec Cinergy T RC MKII USB Stick|exotic USB devices]], [[Hauppauge Nova-T Stick|more exotic USB devices]], [[Vertex VW110L - Ufon|modems]] and more. Also tablet PCs and apparently ARM-devices (yes [[User:nl6720]], I agree that they do not belong here but they are still hardware pages).<br />
<br />
Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.<br />
<br />
There are currently maybe two people (me and [[User:DerpishCat]]) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.<br />
<br />
The goals are:<br />
# Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how<br />
# Make current tasks public so others know what we need help with<br />
# Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.<br />
<br />
The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g [[Help:Style]], some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:49, 7 April 2021 (UTC)<br />
<br />
:So you want to create [[ArchWiki:Hardware Team]]? With only two team members, I think it's a little too soon for that.<br />
:If you simply want a central discussion page, you can use [[Category talk:Hardware]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:59, 7 April 2021 (UTC)<br />
<br />
== Abusefilter ==<br />
<br />
As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.<br />
<br />
I am in favor of adopting [https://en.wikipedia.org/wiki/User:AmandaNP/UAA/Blacklist the "block"list that Wikipedia uses], with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:<br />
<br />
* If certain derivatives (e.g Manjaro) or other distros are in the name.<br />
* Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.<br />
* This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.<br />
<br />
Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like [https://en.wikipedia.org/wiki/User:ClueBot_NG ClueBot NG] but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.<br />
<br />
It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:50, 28 April 2021 (UTC)<br />
<br />
:We should also enable [[mw:Extension:AntiSpoof]]. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 30 April 2021 (UTC)<br />
<br />
::I agree with that. That looks like it will be beneficial, too.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:01, 30 April 2021 (UTC)<br />
<br />
== Commercial self-promotion on the ArchWiki ==<br />
<br />
See [[Special:Diff/670967|670967]], this is clearly ''commercial'' self-promotion here (Sidenote: using "latest" as the archiso version gets old really quickly). This is a very new account and also their first edit.<br />
<br />
I did not undo this because this is not clearly defined anywhere. I would like your opinions on this.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 09:32, 14 May 2021 (UTC)<br />
: Looks like spam to me... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]])<br />
<br />
== Visited links are gray ==<br />
<br />
This makes the links blend in with the regular text on the page, especially when using [https://darkreader.org/ Dark Reader].<br />
{{Unsigned|07:30, 16 May 2021 (UTC)|Glibg10b}}<br />
<br />
: From an accssibility/usability perspective, this is a terrible choice; something with some contrast for colourblind or visually impaired people would be a much better choice. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 06:00, 31 May 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Maintenance_Team&diff=674677ArchWiki talk:Maintenance Team2021-05-31T05:57:34Z<p>Jasonwryan: /* Commercial self-promotion on the ArchWiki */ Agree, its spam</p>
<hr />
<div>{{Note|This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.}}<br />
<br />
== Reorganization ==<br />
<br />
The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.<br />
<br />
However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:<br />
<br />
# I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".<br />
# ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.<br />
# ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of [[ArchWiki talk:Administrators]] (e.g. update the link in [[ArchWiki:Contributing#Complaining]]).<br />
# ✓ I'd like to deprecate [[ArchWiki:Reports]], and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to ''also'' report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes. <br> Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation. <br> Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.<br />
# Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: [https://github.com/kynikos/wiki-monkey/issues/175 #175], [https://github.com/kynikos/wiki-monkey/issues/176 #176], [https://github.com/kynikos/wiki-monkey/issues/197 #197] and [https://github.com/kynikos/wiki-monkey/issues/198 #198].<br />
# ✓ The [[ArchWiki:Maintenance_Team#Current_patrols]] list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.<br />
# ✓ [[ArchWiki:Maintenance_Team#Statistics]] was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.<br />
<br />
Opinions needed. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:11, 6 May 2015 (UTC)<br />
<br />
:: Point 1) Sounds good to me.<br />
:: Point 2) Agreed.<br />
:: Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.<br />
:: Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much. <br />
:: Points 6 & 7) Agreed<br />
:: -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 10:11, 7 May 2015 (UTC)<br />
<br />
:::1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account<br />
:::4,7. I'm neutral on this... I think having [[ArchWiki:Reports]] as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)<br />
:::6. Yep, and not including active members as well. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:10, 7 May 2015 (UTC)<br />
<br />
::::Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.<br />
::::Is it also the time to consider [[ArchWiki_talk:Administrators#Meaning_of_Administrator]] at this point?<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 7 May 2015 (UTC)<br />
<br />
:::::About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.<br />
:::::Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping [[ArchWiki:Reports]] would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to [[ArchWiki:Reports]] too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.<br />
:::::[[ArchWiki_talk:Administrators#Meaning_of_Administrator]] could surely be implemented in this article, it's very related indeed.<br />
:::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 8 May 2015 (UTC)<br />
<br />
::::::I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only. <br />
::::::How about doing it like you propose, but changing procedure for the reports that ''may'' still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 10 May 2015 (UTC)<br />
<br />
:::::::My idea (which I hadn't eleaborated yet here) was to allow the creation of ''quick'' reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from [[ArchWiki:Reports]] as an example of how it could look instead in the affected article's talk page:<br />
::::::::<h2>Quick report</h2><br />
::::::::''[This is an automatic [[ArchWiki:Reports|report]] about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]''<br />
::::::::''Comment'': I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp<br />
:::::::The whole thing could be manually added simply with: <br />
:::::::{{bc|<nowiki>{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~</nowiki>}}<br />
:::::::The link to [[ArchWiki:Reports]] (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.<br />
:::::::If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), [[Special:Diff]] could be used instead of the full link, and it could create the report in full text (i.e. like using the template with ''subst''). <br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:54, 11 May 2015 (UTC)<br />
<br />
::::::::Now in this case I'd like to nominate "(4) to deprecate [[Archwiki:Reports]]" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:48, 11 May 2015 (UTC)<br />
<br />
:::::::::Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:55, 12 May 2015 (UTC)<br />
<br />
:::::::::For the moment I've done points 6 and 7. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:43, 24 May 2015 (UTC)<br />
<br />
::::::::::I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:14, 29 July 2015 (UTC)<br />
<br />
:::::::::::Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in [[ArchWiki:Reports]]' table, which are probably even worse when it comes to [https://github.com/kynikos/wiki-monkey/issues/216 breakability], so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.<br />
:::::::::::I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).<br />
:::::::::::To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:54, 11 August 2015 (UTC)<br />
<br />
::::::::::::Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:49, 13 September 2016 (UTC)<br />
<br />
:::::::::::::I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:51, 14 September 2016 (UTC)<br />
<br />
::::::::::::::I've flagged the page for archiving for now [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=450811&oldid=450669]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:40, 14 September 2016 (UTC)<br />
<br />
== Regular Wiki Cleanup Days ==<br />
<br />
I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 19:45, 11 October 2016 (UTC)<br />
<br />
== Admin guidance ==<br />
<br />
Show we add some guidence that an admin should follow, the responsibilty they should take? <br />
<br />
Example:<br />
* Encourage contribution from Arch users. <br />
* Guide new contributor to follow Arch Wiki Style.<br />
--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:23, 11 July 2014 (UTC)<br />
<br />
:Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in [[#Meaning of Administrator]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:06, 12 July 2014 (UTC)<br />
<br />
:"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:53, 28 April 2021 (UTC)<br />
<br />
== Cite extension ==<br />
<br />
''[Moved from [[User talk:Kynikos#Cite extension]]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 15 January 2015 (UTC)]''<br />
<br />
I'm feeling bad about not having a way to cite my sources properly in my article. As I do for the LibreOffice Newsletter I'm in charge of I'll do as it for my Arch Linux articles:<br />
<br />
{{bc|<nowiki><br />
<br />
Some text<ref name=myRefName /><br />
<br />
== References ==<br />
<br />
<ref name=myRefName>[http://someURL The link]</ref><br />
<br />
</nowiki>}}<br />
<br />
I don't know if this system suits you. Let me know. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 01:07, 10 December 2014 (UTC)<br />
<br />
:Unfortunately you cannot use the ref tag in this wiki, since it requires the Cite extension, which we don't have installed. Generally we don't require to support every statement with citations, unlike for example on Wikipedia, but it will be very useful if you will add references to external sources simply using links on keywords, like [https://www.archlinux.org this], or this<sup>[https://www.archlinux.org]</sup> (see the source text for the implementation; we don't have style rules about this for the moment). If you want to mention the generic sources that you use for writing the article, you should just add them to [[Dynamic Kernel Module Support#See also]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 10 December 2014 (UTC)<br />
<br />
::I don't like this idea very much. The ''See also'' section sounds like we invite the user to read these documents to provide more detailed information to the reader, implying the Arch Linux documentation is not complete enough. This isn't actually what we want to do in this case: we just adapted an existing article to build a section of the Arch Linux documentation page. And yes, I would really like to have citations like in Wikipedia, but without the need to cite every assumptions we make obviously. Would you mind installing the Cite extension? -- [[User:wget|wget]] ([[User talk:wget|talk]]) 12:00, 11 December 2014 (UTC)<br />
<br />
:::Unfortunately installing extensions requires write access to the repository, which is restricted to Developers, and a feature request should be opened in the bug tracker. I don't see other alternatives to the methods I proposed above.<br />
:::That said, ArchWiki articles are not intended to be "complete" as in "it shouldn't be necessary to read anything else in order to understand every detail of the topic"; if the topic has good upstream/official documentation, there's no point in duplicating it, see also [[Help:Style#Hypertext metaphor]].<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:12, 12 December 2014 (UTC)<br />
<br />
:::: Hi Kynikos. Happy New Year! Any news about the citation extension? Yet again today, I wanted to write on the wiki that yaourt does support bash and zsh completion, and to link these assumptions to the source code. The cite extension is indeed very useful, especially in the case (like this one) when upstream has not good documentation. If you haven't already reported the feature request on the bug tracker, are you willing to support the one I'm gonna write? Otherwise, I don't see the interest in writing that request: devs will unlikely accept it without your support. Thanks in advance. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 23:50, 6 January 2015 (UTC)<br />
<br />
:::::Happy New Year mate :) Honestly I don't see the need for the cite extension here: can't you just use simple inline links as I proposed above? (And as it's done in every article?) Sorry, but unless you prove that you really have no way to add that link without the extension, I can't support your request... Just try to amend the article with inline links and let's see how it looks, ok? I'll try to help you fix the style, if needed ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:34, 7 January 2015 (UTC)<br />
<br />
:::::Yesterday again, I was cleaning/updating the [[Browser plugins]] and wanted to put a link to the official where I took that information from. That link concerned two locations in that article: [[Browser plugins#Disable the "Press ESC to exit full screen mode" message|Disable the "Press ESC to exit full screen mode" message]] and [[Browser plugins#Multiple monitor full-screen fix|Multiple monitor full-screen fix]], the solution using inline links was to duplicate that URL which I didn't. Regarding the [https://lists.archlinux.org/pipermail/arch-general/2014-December/038000.html your message], the problem seems to be a lack of workforce then. A possible solution would be merging wikis and forums of the [[International communities|native languages communities]] into Arch Linux infrastructure, bringing along all these admins/maintainers to the Arch infra. But for that a bunch of work needs to be done first: easy multilanguage support (especially regarding links) on the Wiki (maybe native language staff can help for that). -- [[User:wget|wget]] ([[User talk:wget|talk]]) 14:59, 8 January 2015 (UTC)<br />
<br />
::::::I see, actually if you want to use the same link in two different sections, there's nothing against it; even if there was the Cite extension installed, you'd have to duplicate the &lt;ref> tag, right? There are already many articles with multiple instances of the same internal or external links, I don't see any harm with that, as long as the duplicated links are found in indipendent parts of an article.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Yes, just the <ref> tag will need to be duplicated, but the URL, authors, description, etc. will not. That ref will just act as a very short reference to the long <ref> tag written at the end of the article. See [https://wiki.documentfoundation.org/LOWN/5 this example], this is the way we are working at TheDocumentFoundation. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::In general, also expanding on what I wrote in my arch-general post that you linked, my position is that it's too late to install the Cite extension now, because that would only introduce a new style standard for external links that would make all the existing articles style-obsolete, in practice starting a very long — if not infinite — transition period over which articles would have both inline and referenced links, which I wouldn't see as an improvement at all.<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Don't underestimate my patience or my scripting abilities ;-), I'm the kind of guy a bit maniac, with obsessive need to get everything neat. So transition period isn't really a problem ;-) -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Eheh I understand, I guess I'm a bit like that myself :P Well, considering that we've got this far, I'm going to move this branch of the discussion to [[ArchWiki talk:Administrators]] and see what are the opinions of the rest of the team. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:::::::::Maybe I'm missing something obvious, but I dislike the Wikipedia citation style simply because it needs 3 clicks instead of one: one to see the link, a second to open it, and a third to return to the article. That said I'm a proponent of requiring citations for statements made on this wiki: [[Help_talk:Style#Citations and reasoning]] (one of these days I'll get to making a draft). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:31, 29 October 2015 (UTC)<br />
<br />
::::::::::What I was saying is that if Wikipedia-style citations had been used from the beginning of this wiki, I think we'd probably be used to them by now; it's true that they require more effort to follow a link if you don't use the mouseover tooltip (e.g. when using pentadactyl, vimfx etc.; tooltips can also be set to appear on click though); on the other hand, though, they encourage the maintenance of a comprehensive list of external reference links at the bottom of each article. Anyway, as I've repeated multiple times, now I'm against introducing Wikipedia-style citations.<br />
::::::::::Regarding requiring citations, I'll wait for your draft, but I think making them a requirement could be too much: what do we do with unreferenced statements? Delete them? Or fill articles with "Citation needed" templates? Wikipedia needs citations more than us because it deals with topics that can be easily discussed from biased standpoints; also, it doesn't allow original research, see also [[Wikipedia:Wikipedia:Verifiability]]. In this wiki, I'd talk more of a recommendation, and well specify what kind of statements should better be referenced.<br />
::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:27, 30 October 2015 (UTC)<br />
<br />
::::::Please see it like this: using inline or referenced links are just two different style conventions: the ArchWiki happens to use the first one, let's just stick to it and concentrate on the rest, ok? :)<br />
<br />
::::::There is indeed a lack of workforce on the back-end, although I have to acknowledge the fact that Pierre has recently finally pushed MediaWiki 1.24 in the repo, which means it will reach the server very soon; anyway, his policy regarding internationalization has always been the opposite of your proposal, i.e. encourage localized versions to host their own wiki, so your idea would find some opposition there; but even if it didn't, I think you're greatly overrating the state of the external Arch wikis: of them, only the German and French wikis are actually alive, and the German wiki is already maintained by Pierre himself :)<br />
::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:18, 9 January 2015 (UTC)<br />
<br />
:::::::Didn't know much about the wiki infrastructure and native language frequentations, but what I've seen on the #archlinux-fr freenode IRC channel, there are some people involved with the French wiki who could be returned to the official wiki, recovering a bit more workforce. Its a great subject for discussion between officials (Pierre) and third parties IMHO. Yes, I'm in complete favour of federating around a same well defined goal: "Unity makes strength", "United we stand, divided we fall" is my country motto. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 21:20, 13 January 2015 (UTC)<br />
<br />
::::::::Well, my personal opinion, which is not an official position because we've never discussed this among the admins, is that I'd be in favour of returning all the translations in the same wiki, but only after implementing [[Help talk:I18n#Language namespace(s) in place of suffixes?]] and proving that it works efficiently with the languages that are already hosted here; we should also prove that we can merge the databases of the external wikis safely and effectively. Only after that we could discuss the return of the external languages, stressing the fact that the admins coming from the other wikis should be willing to adapt to the English wiki customs, which I wouldn't take for granted.<br />
::::::::For the first step I'll need to complete some adaptations to my bot, but that's not on high priority at the moment: I have a todo list that I follow more or less strictly, and I promise I'll get there :)<br />
::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:51, 15 January 2015 (UTC)<br />
<br />
:: Another advantage of being able to use <nowiki><ref></nowiki> is that one could also add meta information to the URL that's being linked to in order to prevent [https://en.wikipedia.org/wiki/Wikipedia:Bare_URLs link rot]. Not all URLs are descriptive enough to figure out where they might have gone when they're not reachabe anymore and the Wayback Machine wasn't able to crawl the site. -- [[User:Ckujau|Ckujau]] ([[User talk:Ckujau|talk]]) 17:07, 16 July 2017 (UTC)<br />
<br />
== Scribunto ==<br />
<br />
I would like the [[mw:Scribunto]] extension to be installed to the ArchWiki, so that we can improve existing templates and create new useful templates, which currently cannot be implemented. For example we currently cannot [[Help talk:Template#Creation of Template:Info|implement Template:Info]]. Furthermore [[mw:Lua scripting]] would make template code more readable and facilitate maintenance by allowing for translated templates without duplicating the template logic.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 20:07, 17 August 2018 (UTC)<br />
<br />
:Frankly, I don't know how to feel about this. Obviously it would help to fix a lot of problems, but I wouldn't overestimate its usefulness. Lua modules still have to deal with arguments in the MediaWiki markup and the output is integrated back into the MediaWiki markup, so some problems will inherently persist. And since the core markup language sucks, combining it with a perfect scripting language would still be a sucking experience...<br />
:Another thing is that WMF moved to Lua primarily due to [[mw:Lua_scripting#Rationale|performance reasons]] and I don't think that our wiki has any performance problems with the current templates.<br />
:The last thing is a question whether we really ''need'' to invent more and more complicated templates or whether we can keep them simple like they are now. For example, we can say that [[Template:hc]] cannot be used inside lists, which covers at least 99% of the use cases, and for the remaining 1% I'm sure it is possible to adjust the surrounding content of the page to look good even if the template is not inside a list. Having a limited language for writing templates really helps to control the complexity of the resulting templates.<br />
:More opinions needed (especially from the [[archwiki:administrators|administrators]] and [[archwiki:maintainers|maintainers]]).<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:40, 23 August 2018 (UTC)<br />
<br />
== Patch Vector skin to display categories at the top of the page ==<br />
<br />
Categories on the ArchWiki are currently displayed at the bottom of the page. While this is the MediaWiki default, it does make the categories of an article less accessible, especially if the article is long. Because categories provide such a great way to find related articles, I think they deserve to be prominently placed at the top, right below the page heading. This is also more consistent with our convention to keep categories at the top of the source text. I initially [[Mediawiki talk:Common.css#Move categories under h1|tried to implement the change using CSS]] but had to figure out that the two ways to move catlinks to the top with CSS, absolute and flex positioning, cannot be implemented cleanly as both don't work with margin collapsing. [[User:Kynikos|Kynikos]] [https://phabricator.wikimedia.org/T192223 asked WikiMedia] if they would accept a Vector skin patch to implement the feature as an option, to which they didn't respond. I managed to patch the Vector skin to implement the desired change. Although we would need to maintain the patch ourselves, I think it is doable (the patch only changes 10 lines) and warranted as it would improve ArchWiki for every reader (that uses the default skin).<br />
<br />
I submitted my patch as [https://github.com/archlinux/archwiki/pull/18 a pull request] to the ArchWiki GitHub repository.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:01, 18 August 2018 (UTC)<br />
<br />
:Now that my patch was declined the only way left appears to be upstream. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:39, 18 November 2018 (UTC)<br />
<br />
== Convention for splitting sections to new page ==<br />
<br />
Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring [[ArchWiki:Contributing]]. For exemple current [[OpenSSH#Tips_and_tricks]], or [[pacman#Troubleshooting]].<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with [[Template:Move]] and start a discussion in their talk pages (not here).<br />
:Otherwise you can try to propose some generic guidelines, for the moment we have a [[Help:Procedures#Split section to a new subpage|procedure]] to implement a split after an agreement has been reached.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::Maybe not generic criterias, but specific ones. For example sections like {{ic|Tips and tricks}} or {{ic|Troubleshooting}} can expand quickly. A generic rule like: {{ic|if more than 10 subsections are listed, you can move the section in a subarticle without asking first}} -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
::Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::That's not enough, because e.g. [[Chromium/Tips and tricks]] is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have [[ArchWiki:Contributing#The 3 fundamental rules]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:59, 16 June 2019 (UTC)<br />
<br />
::::In case the [[Chromium]] page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The [[Template:Move]] description suggest it is only for renaming articles ? -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:18, 17 June 2019 (UTC) <br />
<br />
:::::I've fixed the [[Template:Move]] description, the template has frequently been used to flag sections to be split, e.g. [[Network configuration#Device driver]], [[Arch terminology#Arch Linux]] or [[List of applications#Network managers]], which works pretty fine. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:16, 17 June 2019 (UTC)<br />
<br />
Also, the {{ic|related articles}} sidebar can appear to be a little bloated on some articles (for exemple [[pacman]]). Should there be a dedicated side bar for subarticles (not sure about the name) like [[pacman/Tips_and_tricks]] in [[pacman]] ?<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 22:01, 15 June 2019 (UTC)<br />
<br />
:I don't find [[pacman]]'s related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:03, 16 June 2019 (UTC)<br />
<br />
::I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in [[ArchWiki:Sandbox]] -- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 10:58, 16 June 2019 (UTC)<br />
<br />
:::I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in [[Help talk:Style]], I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.<br />
:::About separators, I don't like them in this context regardless of the links order :)<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:26, 17 June 2019 (UTC)<br />
<br />
== Remove redirect page with bad title ==<br />
<br />
This topic is similar to above [[#Removing unnecessary redirects / pages]] but with a different target redirections. <br />
<br />
Background: <br />
* The [[Help:Article naming guidelines]] changes along the years, so there exist many Old_Title -> New_Title redirections.<br />
* Many new users contribute to Arch Wiki before they notice there is [[Help:Article naming guidelines]], so there exist many Bad_Title -> Good_Title redirections.<br />
* The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.<br />
<br />
Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes:<br />
Installation guide<br />
Installation Guide<br />
Installation guide(Català)<br />
Installation guide (Català)<br />
Installation Guide (Català)<br />
<br />
Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?<br />
<br />
{{Unsigned|14:21, 14 May 2020 (UTC)|Fengchao}}<br />
<br />
:I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 09:21, 7 June 2020 (UTC)<br />
<br />
:I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to [[Flatpak]] which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:30, 9 May 2021 (UTC)<br />
<br />
:One such redirect (that I think should be deleted) is [[Keeping Docs and Info Files]]. No other wiki pages link to it either. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:44, 9 May 2021 (UTC)<br />
<br />
::That one contains a history, so it should be kept (or archived at most). — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:37, 15 May 2021 (UTC)<br />
<br />
:::What about renaming it (to something like [[Keeping documentation and information files]]) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 18:14, 15 May 2021 (UTC)<br />
<br />
== Are there statistics of page access? ==<br />
<br />
Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 00:05, 28 June 2020 (UTC)<br />
<br />
:I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:43, 28 June 2020 (UTC)<br />
<br />
::I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 10:00, 28 June 2020 (UTC)<br />
<br />
:::Agreed. Would be nice to review and assist with what matters most to our users. [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 05:13, 11 July 2020 (UTC)<br />
<br />
== Acceptable user names and signatures ==<br />
<br />
I've just blocked [[User:🥚]] for a week until we make a decision on a general policy, they had only edited their User page, so it's borderline spam or a joke, but that's not my main point.<br />
<br />
I think the user name is practically unsearcheable without copy-pasting, and too hard to address for example in talk pages, it may mess up logs, bots etc.<br />
<br />
1) I propose to limit user names to ascii characters, plus possibly the other languages' characters that we support, but exclude emoticons and other fancy unicode characters. We'd either need a comprehensive definition or reserve the right to decide case by case.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Well, it messed up wiki-scripts and it took me more than an hour to figure out the problem... [https://github.com/lahwaacz/wiki-scripts/commit/25c11f36712df03c705d7cd1d3a8c673fc87360f] To actually limit the user names, we could write an abuse filter with some regex matching (assuming that the extension actually works). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:00, 11 August 2020 (UTC)<br />
<br />
::If we find an exact character set, sure we can try with an abuse filter. For the moment I'm also adding a reference to [[w:Wikipedia:Username_policy#Non-script_usernames]] (and the rest of the page): we may even default to using that page too. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:18, 11 August 2020 (UTC)<br />
<br />
:::Yes, I think that would be a good policy for us too. It's certainly much better than writing our own from scratch :) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:11, 11 August 2020 (UTC)<br />
<br />
::I don't really see an issue with these kind of usernames; if some script can't parse them, then it's the fault of the script not the username. There hasn't yet been a influx of users with malicious intents and ''not-easily typable'' usernames, so I'd rather we don't take a heavy handed approach. Let's not overreact over an egg. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:40, 12 August 2020 (UTC)<br />
<br />
:::Ok that bots are supposed to be able to handle unicode, and the "too hard" in my OP should have better been "needlessly hard", of course we can find our way around [https://xkcd.com/1953/ weird] usernames, still assuming that MediaWiki and the extensions that we use are "ok" with that too (MW is mainly developed around Wikipedia, and adopting a looser username policy may end up into unexplored territory).<br />
:::In general though I think nobody whose goal is constructive interaction with the community would choose a clearly deliberately hard-to-handle username. After all, the purpose of a username is to make oneself easily identifiable by the other members of the community, it's not there only for aesthetic or artistic reasons.<br />
:::I wouldn't see adopting [[w:Wikipedia:Username_policy]] as heavy handed, the restrictions on misleading and disruptive usernames make a lot of sense to me, still leaving a lot of freedom of choice.<br />
:::I'd also be ok to take this to a vote.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:44, 11 August 2020 (UTC)<br />
<br />
:Or at least ban custom signatures that hide or change the real username. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:59, 13 August 2020 (UTC)<br />
<br />
== Switch to another editor ==<br />
<br />
There is a request to switch to another editor: {{Bug|55828}}. Apparently the original "2006-core-Editor" was removed in MW 1.30 and now there is only a plain textarea without any toolbar with various markup buttons. Some users may find it difficult to format an article without knowing the MediaWiki markup, but I'm not fond of enabling something that provides buttons to insert &lt;code>, &lt;pre> and even other HTML tags. Users should always learn the markup and [[Help:Style]] (at least basics) if they want to contribute regularly. What do you think? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:22, 12 September 2020 (UTC)<br />
<br />
:I've only taken a quick look at the proposed extension, but it seems it can be customised to a great extent, so I'd be in favour only if we adapt it to comply with our style rules.<br />
:[devil's_advocate]$ Requiring people to edit without UI aids may end up resulting in more typos/syntax mistakes, or simply discouraging contributions. Also, we're in 2020 and we must assume that there are people who want to contribute through smartphones, and entering non-alphanumeric characters on a thumb keyboard can be exhausting. <br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:21, 13 September 2020 (UTC)<br />
<br />
::I'm not against switching the editor. The only issue I see with the proposed [[mw:Extension:WikiEditor|Extension:WikiEditor]] is that it has a "Reference" button that inserts {{ic|<nowiki><ref></ref></nowiki>}} and ArchWiki doesn't enable [[mw:Extension:Cite|Extension:Cite]]. Changing the toolbar requires [[mw:Extension:WikiEditor#Configuration|editing a file in the extension's directory]] which is not really pretty or feasible.<br />
::We could also wait for MediaWiki 1.35 and use the "2017 wikitext editor", but that's part of [[mw:Extension:VisualEditor|Extension:VisualEditor]] and I don't know if it's possible to disable the visual editing mode.<br />
::On the topic of editor improvements, both of the aforementioned editors support syntax highlighting using [[mw:Extension:CodeMirror|Extension:CodeMirror]]. If we're changing the editor, I'd like to enable syntax highlighting for it too.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:36, 13 September 2020 (UTC)<br />
<br />
:::Draft PR: https://github.com/archlinux/archwiki/pull/32 -- 09:19, 13 September 2020 (UTC)<br />
<br />
:::VisualEditor requires setting up Parsoid and RESTBase, which seems too complicated. The "2017 wikitext editor" probably works without that, but we would still have to find the configuration to disable the "visual" mode (if it is even possible). It also probably still includes the {{ic|<nowiki><ref></ref></nowiki>}} button.<br />
:::The [[mw:Extension:WikiEditor|Extension:WikiEditor]] might be configurable with a site-wide javascript: [[mw:Extension:WikiEditor/Toolbar_customization#Removing_things]] I think that would be good enough for us...<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 13 September 2020 (UTC)<br />
<br />
::::According to [[mw:Parsoid]], "Parsoid (the PHP version) is natively bundled in MediaWiki 1.35". That's why I said if we want the "2017 wikitext editor", we should wait till MediaWiki 1.35 is released. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:39, 13 September 2020 (UTC)<br />
<br />
::::According to the docs, it should be possible to remove the button with: {{bc|<nowiki><br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'main',<br />
'group': 'insert',<br />
'tool': 'reference'<br />
});<br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'help',<br />
'page': 'reference'<br />
});<br />
</nowiki>}}<br />
::::But I could only get it to work this way: {{bc|<nowiki><br />
$( '#wpTextbox1' ).on( 'wikiEditor-toolbar-doneInitialSections', function () {<br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'main',<br />
'group': 'insert',<br />
'tool': 'reference'<br />
});<br />
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {<br />
'section': 'help',<br />
'page': 'reference'<br />
});<br />
} );<br />
</nowiki>}}<br />
::::Unfortunately the button is visible for a moment before it's removed.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:11, 13 September 2020 (UTC)<br />
<br />
::::MediaWiki 1.35 is out, so it's time for some testing.<br />
::::It is possible to disable visual editing mode of [[mw:Extension:VisualEditor|Extension:VisualEditor]] and use only the "2017 wikitext editor": {{bc|<nowiki><br />
wfLoadExtension( 'VisualEditor' );<br />
$wgDefaultUserOptions['visualeditor-enable'] = 0;<br />
$wgHiddenPrefs[] = 'visualeditor-enable';<br />
$wgVisualEditorEnableWikitext = true;<br />
$wgDefaultUserOptions['visualeditor-newwikitext'] = 1;<br />
$wgHiddenPrefs[] = 'visualeditor-newwikitext';<br />
</nowiki>}}<br />
::::And unlike with [[mw:Extension:WikiEditor|Extension:WikiEditor]], in 2017 wikitext editor there is no "reference/cite" button if [[mw:Extension:Cite|Extension:Cite]] is not enabled.<br />
::::I haven't gotten far with the visual mode. <s>I followed [[mw:Parsoid/PHP]] and since I'm using {{Pkg|mediawiki}}, I set {{ic|1=$PARSOID_INSTALL_DIR = '/usr/share/webapps/mediawiki/vendor/wikimedia/parsoid';}}. Unfortunetly I'm stuck with {{ic|Error contacting the Parsoid/RESTBase server (HTTP 403)}}</s> :(<br />
::::-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:59, 26 September 2020 (UTC)<br />
<br />
:::::Actually Parsoid doesn't need configuring. I missed the obvious thing that [[mw:RESTBase|RESTBase]] needs to be installed separately, that's too much of a hassle for me. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:50, 27 September 2020 (UTC)<br />
<br />
::::::Unless someone is willing to research how to set up [[mw:RESTBase|RESTBase]] for Arch Wiki, we can't use the 2017 wikitext editor or Visual Editor. So, how about we switch (at least for now) to [[mw:Extension:WikiEditor|Extension:WikiEditor]] with [[mw:Extension:CodeMirror|Extension:CodeMirror]] for syntax highlighting? 👍 on https://github.com/archlinux/archwiki/pull/32 if you agree. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:05, 1 January 2021 (UTC)<br />
<br />
:::::::I just tried that "2010 wikitext editor" and besides the &lt;ref>&lt;/ref> button there are other things that I'm not very happy about: picture upload dialogue, buttons for subscripts, superscripts and font sizes, and a "References" section in the help overview... But I guess we can hide all that when the extension is enabled. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 9 January 2021 (UTC)<br />
<br />
::::::::"References" would be removed from Help with [[MediaWiki:Common.js|site-wide JS]] as shown above. I agree about removing "Images and media" (picture upload), "Picture gallery" and maybe font size, but I don't see much of an issue with subscript and superscript. We do use them in some pages. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:36, 9 January 2021 (UTC)<br />
<br />
:::https://github.com/archlinux/archwiki/pull/32 has been merged. Deployment is still pending: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/366.<br />
:::I updated [[MediaWiki:Common.js]] to remove the reference button and its help. Do we want to remove anything else? E.g. image upload, big text, small text or picture gallery?<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:15, 30 April 2021 (UTC)<br />
<br />
::::I'm for removing everything related to images to clean up the interface and font sizes (big/small text) to avoid "style abuse". But we can wait until it's deployed and it actually starts causing problems... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:42, 8 May 2021 (UTC)<br />
<br />
== Visual editor ==<br />
<br />
''[Moved from [[Help talk:Editing#Visual Editor]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:22, 23 September 2020 (UTC)]''<br />
<br />
:Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 12:54, 18 September 2020 (UTC)<br />
<br />
::AFAIK no one has proposed adding a visual editor. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:28, 18 September 2020 (UTC)<br />
<br />
:::Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- [[User:FOSS ভক্ত|FOSS ভক্ত]] ([[User talk:FOSS ভক্ত|talk]]) 17:39, 23 September 2020 (UTC)<br />
<br />
::::You already have :) And I gathered that you're talking about [[mw:Extension:VisualEditor|Extension:VisualEditor]].<br />
::::MediaWiki 1.35.0 [https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-September/000259.html will be released this week], so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.<br />
::::The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create [[mw:Help:TemplateData|TemplateData]] for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:43, 24 September 2020 (UTC)<br />
<br />
== Define a clear, comprehensive and professional model of documentation ==<br />
<br />
In the beginning of [[ArchWiki:Contributing]] it's written:<br />
<br />
"ArchWiki strives to be a clear, comprehensive and professional model of documentation. "<br />
<br />
However, when I suggested edits to various pages, it turned out that other users had very different views of what makes a page better or worse. Could we create a more concrete and detailed document on the principles of a good page and good wiki?<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 16:21, 17 November 2020 (UTC)<br />
<br />
== Bullying on ArchWiki ==<br />
<br />
As it was discussed above, I wanted to make a complaint about the user [[User:Scimmia|Scimmia]]. I registered on ArchWiki in November this year. I used that extensively and spotted several things which could be improved. I proposed several things on talk pages, but all my proposals were rejected, and in majority of cases it was done by Scimmia. Here I’m not arguing that they should be accepted, but my complaint is about the form of communication used by Scimmia.<br />
<br />
I copy several examples of conversations below, all markup is mine.<br />
<br />
On the 16th of November I give a detailed explanation on a suggested edit here (https://wiki.archlinux.org/index.php?title=Talk:EFISTUB&oldid=641787#Expand_'preparing_for_EFISTUB'), and receive a brief answer<br />
<br />
“'''Nothing about this edit makes sense'''. You're assuming what kernel was installed, and '''adding no useful information'''. Scimmia (talk) 14:30, 17 November 2020 (UTC)”<br />
<br />
...<br />
<br />
“See, '''you're not even aware''' of the different kernels available in Arch. '''You should really stop making suggestions based on ignorance'''. Scimmia (talk) 15:00, 17 November 2020 (UTC)”<br />
<br />
...<br />
<br />
“No, this is Arch, we must NOT assume lack of knowledge. '''Arch assumes users are experienced Linux users'''. Scimmia (talk) 15:14, 17 November 2020 (UTC)”<br />
<br />
When after a long discussion with a moderator I give another example of usage, <br />
“"change a boot disk for the OS or want install a different boot loader" - this is not a user error.”, Scimmia replies<br />
<br />
“It is '''if you have no idea what you're doing'''. Scimmia (talk) 16:28, 17 November 2020 (UTC)”<br />
<br />
The same day I propose a concrete change for a similar page (https://wiki.archlinux.org/index.php?title=Talk:GRUB&oldid=641780#Add_information_how_to_generate_the_bootable_files)<br />
The next answer is <br />
<br />
“'''Nothing about this makes sense'''. You deleted your kernel, then expect the docs to know that '''you screwed up'''? Scimmia (talk) 14:34, 17 November 2020 (UTC)”<br />
<br />
...<br />
<br />
“I propose that if you format the boot partition, '''you have some idea what you're doing'''. Scimmia (talk) 15:05, 17 November 2020 (UTC)”<br />
The answers by Scimmia, if not rude, were rather unpleasant. It seemed that they are mostly not relevant to the discussion, very brief and careless, and he wrote them just to oppose, regardless of the arguments (which sometimes were self-contradictory).<br />
<br />
https://wiki.archlinux.org/index.php?title=Talk:General_recommendations&oldid=641904#Leave_codecs_section<br />
<br />
“So your argument is based on the assumption that the software will just '''magically''' find '''whatever''' you have installed without any internal coding for it? '''Think again'''. Scimmia (talk) 13:28, 18 November 2020 (UTC)”<br />
<br />
(which is wrong, because this is how dynamic libraries work)<br />
<br />
“'''Mods, I think it's obvious''' at this point that '''this argument comes from ignorance''', nothing more. Can '''we just delete''' the section and close this? Scimmia (talk) 15:08, 18 November 2020 (UTC)”<br />
<br />
After Scimmia reverted my edits several times, I made an appeal to moderators (https://wiki.archlinux.org/index.php?title=Talk:General_recommendations&oldid=641904#Mods_intervention_needed)<br />
<br />
The moderator made no remark about Scimmia’s behaviour (although there were definitely two participants in the “edit war”), and made a humiliating remark how I should improve “my behaviour”:<br />
<br />
“Here are some links '''for you to read''' and '''improve your behavior''': Code of conduct#Respect other users, Code of conduct#Respect the staff, Code of conduct#No trolling, Code of conduct#Ineffective discussion ("bikeshed"). -- Lahwaacz (talk) 20:01, 18 November 2020 (UTC)”<br />
<br />
I got very tired of Scimmia’s remarks to each of my talk or propositions. I thought that I could find a compromise with him, and wrote to his talk page (https://wiki.archlinux.org/index.php?title=User_talk:Scimmia&oldid=641860),<br />
<br />
“Question<br />
<br />
I'm not sure where I should ask this, but will try it here. I wrote to some moderators asking where to complain about people's actions. While they are replying to this, can I ask you?<br />
<br />
Could you please not get involved in my discussions (talks) on wiki pages and in my edits? If my edits are counterproductive, other people will revert them, won't they?..<br />
<br />
You are number one user who replied most to me during my presence in Arch Wiki, you wrote a lot to me, and I feel your manner highly toxic personally for me at this given moment. Thank you for understanding, no offense meant. Ynikitenko (talk) 18:41, 18 November 2020 (UTC)<br />
<br />
Doesn't work that way. If you '''keep suggesting bad edits''' based on a '''lack of understanding''' of the subjects in question, '''I'll keep responding or reverting'''. As for complaining to the mods, please do, all it does is highlight '''your bad edits'''.<br />
Scimmia (talk) 21:09, 18 November 2020 (UTC)”<br />
<br />
So again I received a bunch of offences and accusations in bad edits.<br />
<br />
The next day I created another discussion (https://wiki.archlinux.org/index.php?title=Talk:General_recommendations&oldid=641904#Links_to_other_multimedia_pages)<br />
<br />
Another administrator replied to my suggestion, and I replied him. Right after my reply Scimmia intervened again:<br />
<br />
“'''Why is this still going on?''' The decision has been made, the section is gone, and the user arguing the other side '''doesn't know how libraries work'''. Just '''let this die'''. Scimmia (talk) 14:32, 19 November 2020 (UTC)”<br />
<br />
I repeat, that this rude comment was posted not after another moderator’s reply, but in 8 minutes after mine.<br />
<br />
Again, the administrator who previously supported Scimmia’s actions, classified this discussion as “ineffective”, even though it was a discussion on importance of codecs (and depending on that, presence of a link to them on that page).<br />
<br />
“Discussion pages on the wiki are intended for discussing what is written on the relevant wiki page. They are not intended for general discussions. In particular, this discussion page is not intended for discussions such as '''explaining you how libraries work''', how Arch Linux packagers choose to implement dependencies between packages, how Ubuntu or any other Linux distribution (let alone operating system) does something differently, etc. <br />
This discussion has become ineffective, so I've split it from the previous (unrelated) discussion and closed it too. Use a different forum for general discussion. <br />
-- Lahwaacz (talk) 14:56, 19 November 2020 (UTC)”<br />
<br />
In [[Code of conduct#Respect_other_users]] it’s written, that “Arch Linux is a respectful, inclusive community. Anti-social or offensive behaviour '''will not be tolerated'''.”<br />
<br />
I think this is a good time to show how this will not be tolerated. <br />
<br />
I find Arch Forum and Arch bug tracker pretty useful, and I get if not 100% great, but never offensive responses there. I never faced such accusations of ignorance on any other technical site in 15 years, neither in ArchWiki from other users. I admit that my very first suggestion on a talk page in ArchWiki was wrong, because of a bug in my installation media, but I don’t think this justifies the manner in which Scimmia replied to majority of my later suggestions.<br />
<br />
I also mentioned above that all my edits and proposals were rejected. I think this is probably because of the setting what Arch Wiki is. [[ArchWiki:Contributing#The_most_important_task]] is declared as this: “add your favorite articles to your watchlist and protect them against counter-productive edits.” (markup removed by me). This is because ArchWiki is perfect. Written by professionals. For professionals.<br />
<br />
After these “discussions” I had no interest in doing anything more on ArchWiki, but I wanted to at least flag a complaint about such behaviour. This was disrupted by an administrator, who warned me to think twice, because Scimmia is from the staff, and staff must be respected (however vague that may be in this case). Lahwaacz didn’t reply to my questions, and I think respect he promotes so much includes willingness to answer another person. No moderator saw anything bad about Scimmia’s behaviour, no one noted anything about Lahwaacz’s actions. I think that a supportive collective is good, but probably not for complaints about collective’s members from outsiders.<br />
<br />
If ArchWiki doesn’t invite any new users to participate, this should be honestly said in its documents and organization, and not imposed through '''permanent humiliation'''. <br />
<br />
Definition from the American Psychological Association:<br />
<br />
“Bullying is a form of aggressive behavior in which someone intentionally and repeatedly causes another person injury or discomfort. Bullying can take the form of physical contact, words or more subtle actions.<br />
<br />
…<br />
<br />
The bullied individual typically has trouble defending him or herself and does nothing to “cause” the bullying.” (other sources mention an imbalance of power in the situation of bullying)<br />
<br />
https://www.apa.org/topics/bullying<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 15:17, 31 December 2020 (UTC)<br />
<br />
: Most of this page is now you complaining about Scimmia. Nothing in Scimmia's comments to your edits appear to me to be anything more than frustration with someone repeatedly making low quality edits. Perhaps, rather than spamming the wiki with your sense of entitlement and victimhood, you might devote some energy to reading documentation in order to increase your own knowledge? You aren't being "bullied": you are being a nuisance. -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:14, 31 December 2020 (UTC)<br />
<br />
::Sorry, Jasonwryan. You don't have to read this whole page if it's inconvenient for you. You can use navigation at the top of the page to select topics to your liking, or just to relax and have some rest. Probably I should had written a complaint long before your friend Scimmia generated so many offensive, nonsensical and rude remarks.<br />
::I doubted whether I should answer such a comment at all, but it shows that absence of any respect is not so uncommon in this wiki, so I'll have to write to other Arch people outside that. You may reread your comment and the definition of "bullying" above, and see that this is exactly the case. I hope that I don't have to make a special complaint to administrators about your behaviour (that is that they see it themselves, not that it's normal).<br />
::-- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 20:33, 31 December 2020 (UTC)<br />
<br />
:::Since you're now resorting to threats, it's clear there's nothing be achieved here. Closing the discussion. Happy new year. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:46, 31 December 2020 (UTC)<br />
<br />
::::I would not call that resorting to threats. As I wrote in the post here, I have a strong feeling that ArchWiki administrators are absolutely unwilling to find any problem in their or their colleague's behaviour. I wrote to Levente Polyak, because when I listened to his talk at the Arch Conference this year, he specifically mentioned the value of the community. I don't think that this can be a really bad thing for ArchWiki maintainers, but you can judge that yourself. I don't think that this discussion should be closed based on that. <br />
::::Thank you, and happy new year to you too and all who develops Arch Wiki. I would gladly had written this complaint before, but first I was very confused with the reply of Lahwaacz and made a separate complaint, then I wanted to live through all those emotions before the complaint, then I was busy; and I didn't want to start this discussion in 2021.<br />
::::P.S. And no, this topic doesn't occupy most of this page, this is just false.<br />
::::[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 21:00, 31 December 2020 (UTC)<br />
<br />
I'm reopening this complaint, because it was closed wrongly. There is nothing that prohibits complaining to the Arch maintainer (he didn't reply yet). Honestly I've no idea why this could be bad. I explained why I wanted to ask him about this case, but I'd still want to get an answer from ArchWiki administrators. Since we've a long way ahead of us together, it's better to solve problems than to ignore them. I understand that the complaint is sensitive, but I think someone can abstract out and solve this objectively. There is no one else to solve this issue except the administration command.<br />
<br />
If you think this section should be closed, close it with another reason. <br />
So I hope someone from Arch Wiki administrators (who reads this and understands), or the collective gives a reply. When it's closed by one admin (wrongly), I'm afraid that the admin who replies to complaints or the collective may miss this.<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 19:43, 7 January 2021 (UTC)<br />
<br />
:I have read the complaint and the edit made by the user at the first link (article about EFISTUB). I can confirm that the edit was useless. In the talk page he was informed about his mistake (about assuming that there are no other kernels, or that the user have no idea about boot partition when changing disk). There was no bulling there.<br />
:Some of my edits are also reverted by lahwaacz (or other users). I do not treat this as "bulling" at all, because he cares about explaining _why_ he does a revert (btw, thank you for that, lahwaacz). And still, if you are absolutely sure of your edit or have another thought about how to improve the info, you are welcome to discuss it in talk pages. No need to start an edit war.<br />
:I think this discussion may be closed now. [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 23:51, 8 May 2021 (UTC)<br />
<br />
== Old redirects with broken section links ==<br />
<br />
While fixing dead/broken links I noticed there are quite a few redirects with broken section links. I fixed some of them but there are a handful of old redirects where I would think that archiving is better than fixing them.<br />
I already archived [[Aion]] after discussing this in the wiki IRC channel.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Page<br />
! Last human edit<br />
! Why I am in favor of archiving (or deleting)<br />
|-<br />
| [[Daemon/List]] ||rowspan="3"|August 2015 ||rowspan="4"|There is no list containing daemons anymore. This has become irrelevant because systemd manages them now and as the page mentions, systemctl can be used to get a list of installed service units.<br />
|-<br />
| [[Daemons list]]<br />
|-<br />
| [[Daemons List]]<br />
|-<br />
| [[Daemons List (Español)]] || August 2018<br />
|-<br />
| [[How to customize Motd]] || May 2015 || The only relevant mention I found about the MOTD is a redirect I fixed, [[Motd]], which leads to a section that basically says "edit /etc/motd".<br />
|-<br />
| [[Check if you can resolve domain names]] || May 2018 || I am still unsure about this one. The section has become [https://wiki.archlinux.org/index.php?title=Domain_name_resolution&diff=prev&oldid=547539 "Resolve a domain name using NSS"] but this is not a good hypertext metaphor/topic reference in my opinion.<br />
|-<br />
| [[Network interface controller]] || October 2018 || Links to a section that has been split off into two separate pages. Ethernet and wireless configuration are now separate.<br />
|-<br />
| [[NOOK HD+]] || Feburary 2014 || Links to a section which contained (android-)device specific ADB instructions which were removed, seem to be obsolete and the device is nowhere else mentioned.<br />
|-<br />
| [[Webmail with Thunderbird]] || June 2012 || Severely outdated and broken<br />
|-<br />
| [[wbar]] || August 2014 || Abandoned project, has also been removed from the AUR<br />
|}<br />
<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 11:03, 26 January 2021 (UTC)<br />
<br />
* I've deleted [[Daemon/List]] and [[Daemons List]] (no history) and archived [[Daemons list]] and [[Daemons List (Español)]]<br />
* I've deleted [[How to customize Motd]]<br />
* [[Check if you can resolve domain names]] is still linked from several pages, I'll delete it when it's unused because the title is terrible<br />
* I think [[Network interface controller]] should be redirected where [[Network interface]] links (and the term should actually be used there, e.g. as a link to [[w:Network interface controller|Network interface controller]])<br />
* I've archived [[NOOK HD+]] because there is some history<br />
* [[Webmail with Thunderbird]] had been already archived<br />
* I've archived [[wbar]]<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:24, 9 May 2021 (UTC)<br />
<br />
::I replaced all the things linking to [[check if you can resolve domain names]].<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 12:43, 12 May 2021 (UTC)<br />
<br />
== Outdated pages in the DeveloperWiki ==<br />
<br />
I have encountered [[DeveloperWiki:Linux Conferences]] which is horribly outdated. I hereby request the deletion of the page. I asked about this in the [[ArchWiki:IRC|IRC channel]] and was advised to take this here by [[User:Svito]], which also mentioned that it might make sense to discuss some other, more general questions here:<br />
<br />
# Who is responsible for those?<br />
# Where to nag people to update/archive them? (My comment on this: I already asked on the talk page of a [[DeveloperWiki:Articles Linked from Website|DeveloperWiki article]] to remove a bit from the page because it has a dead link (as you all might have noticed, I like to fix dead and broken links).)<br />
# There are some pages in the DeveloperWiki with one or multiple issues (mostly broken/dead links and outdated stuff), what should be done about that? It clutters the statistics a bit in my opinion<br />
<br />
[[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:23, 15 February 2021 (UTC)<br />
<br />
:# [https://archlinux.org/people/developers/ Developers] are responsible for DeveloperWiki.<br />
:# Refer to 1.<br />
:# Generally we try to refrain from touching DeveloperWiki (that's why it's in such a horrible shape). If you want to change something in a page, it's better to ask a [[Special:ListUsers/archdev|developer]] to do it.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:21, 15 February 2021 (UTC)<br />
<br />
::The DeveloperWiki is basically a wild west. Discussions on talk page will be ignored for the most. The pages are not updated for ages. As the pages are public, the users may want to improve/update the content on such pages if they find it relevant. But users basically are unable to do so. For example, I wanted to update info in the [[DeveloperWiki:UID_/_GID_Database]]. I asked in irc channel my request, but I was told "The devwiki isn't there to teach the general userbase about anything". Then I cannot see a reason to show the page to non-developers users. And I was told "Why hide it?".<br />
::From the reader's perspective of view, such pages are uneditable junk. And no one is going to update it: developers do not care or do not have time, and the developers users are a really little number of people.<br />
::So I think either some pages should be hidden (so in the main wiki userspace users will create an "updatable" version) or info on such pages should be editable in some way (probably by moving some pages to normal namespace). What do you think? [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 16:25, 8 May 2021 (UTC)<br />
<br />
:::Pages in the DeveloperWiki are written by developers for developers, i.e. not for general userbase. From my point of view, they are already "hidden" behind the DeveloperWiki: prefix. If this is not obvious enough, maybe we should make it more understandable somehow.<br />
:::As for the [[DeveloperWiki:UID_/_GID_Database]] page, its purpose is/was to allocate numbers for specific packages. That's it. The documentation of what these users and groups are for and how they should be used belongs to separate pages dedicated to the relevant package. If it is a general system group, it would be described in [[Users and groups#Group list]].<br />
:::— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:18, 8 May 2021 (UTC)<br />
<br />
::::In theory, my understanding was the pool of people both qualified to edit it, and capable of actually doing so, was supposed to be greatly expanded by allowing TUs to do so, but this was waiting on "permission models" of some sort? [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 01:21, 31 May 2021 (UTC)<br />
<br />
== Creation of a hardware team ==<br />
<br />
As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The [[Help:Laptop page guidelines|Laptop page guidelines]] have been created and all uncompliant pages have been flagged.<br />
<br />
There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are [[Dell TB16|docks]] on the wiki, [[TerraTec Cinergy T RC MKII USB Stick|exotic USB devices]], [[Hauppauge Nova-T Stick|more exotic USB devices]], [[Vertex VW110L - Ufon|modems]] and more. Also tablet PCs and apparently ARM-devices (yes [[User:nl6720]], I agree that they do not belong here but they are still hardware pages).<br />
<br />
Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.<br />
<br />
There are currently maybe two people (me and [[User:DerpishCat]]) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.<br />
<br />
The goals are:<br />
# Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how<br />
# Make current tasks public so others know what we need help with<br />
# Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.<br />
<br />
The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g [[Help:Style]], some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 00:49, 7 April 2021 (UTC)<br />
<br />
:So you want to create [[ArchWiki:Hardware Team]]? With only two team members, I think it's a little too soon for that.<br />
:If you simply want a central discussion page, you can use [[Category talk:Hardware]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:59, 7 April 2021 (UTC)<br />
<br />
== Abusefilter ==<br />
<br />
As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.<br />
<br />
I am in favor of adopting [https://en.wikipedia.org/wiki/User:AmandaNP/UAA/Blacklist the "block"list that Wikipedia uses], with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:<br />
<br />
* If certain derivatives (e.g Manjaro) or other distros are in the name.<br />
* Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.<br />
* This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.<br />
<br />
Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like [https://en.wikipedia.org/wiki/User:ClueBot_NG ClueBot NG] but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.<br />
<br />
It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 14:50, 28 April 2021 (UTC)<br />
<br />
:We should also enable [[mw:Extension:AntiSpoof]]. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 30 April 2021 (UTC)<br />
<br />
::I agree with that. That looks like it will be beneficial, too.<br />
::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 10:01, 30 April 2021 (UTC)<br />
<br />
== Commercial self-promotion on the ArchWiki ==<br />
<br />
See [[Special:Diff/670967|670967]], this is clearly ''commercial'' self-promotion here (Sidenote: using "latest" as the archiso version gets old really quickly). This is a very new account and also their first edit.<br />
<br />
I did not undo this because this is not clearly defined anywhere. I would like your opinions on this.<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 09:32, 14 May 2021 (UTC)<br />
: Looks like spam to me... [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]])<br />
<br />
== Visited links are gray ==<br />
<br />
This makes the links blend in with the regular text on the page, especially when using [https://darkreader.org/ Dark Reader].<br />
{{Unsigned|07:30, 16 May 2021 (UTC)|Glibg10b}}</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Dotfiles&diff=654810Dotfiles2021-03-13T18:33:18Z<p>Jasonwryan: /* User repositories */ Fixed dead link [jwr]</p>
<hr />
<div>[[Category:Configuration files]]<br />
[[Category:Configuration management]]<br />
[[es:Dotfiles]]<br />
[[ja:ドットファイル]]<br />
[[pt:Dotfiles]]<br />
{{Related articles start}}<br />
{{Related|XDG Base Directory support}}<br />
{{Related|X resources}}<br />
{{Related articles end}}<br />
User-specific application configuration is traditionally stored in so called [[Wikipedia:dotfile|dotfiles]] (files whose filename starts with a dot). It is common practice to track dotfiles with a [[version control system]] such as [[Git]] to keep track of changes and synchronize dotfiles across various hosts. There are various approaches to managing your dotfiles (e.g. directly tracking dotfiles in the home directory v.s. storing them in a subdirectory and symlinking/copying/generating files with a [[shell]] script or [[#Tools|a dedicated tool]]). Apart from explaining how to manage your dotfiles this article also contains [[#User repositories|a list of dotfile repositories]] from Arch Linux users.<br />
<br />
== Tracking dotfiles directly with Git ==<br />
<br />
The benefit of tracking dotfiles directly with Git is that it only requires [[Git]] and does not involve symlinks. The disadvantage is that [[#Host-specific configuration|host-specific configuration]] generally requires merging changes into multiple [[Git#Branching|branches]].<br />
<br />
The simplest way to achieve this approach is to initialize a [[Git]] repository directly in your home directory and ignoring all files by default with a {{man|5|gitignore}} pattern of {{ic|*}}. This method however comes with two drawbacks: it can become confusing when you have other Git repositories in your home directory (e.g. if you forget to initialize a repository you suddenly operate on your dotfile repository) and you can no longer easily see which files in the current directory are untracked (because they are ignored).<br />
<br />
An alternative method without these drawbacks is the "bare repository and alias method" popularized by [https://news.ycombinator.com/item?id=11070797 this Hacker News comment], which just takes three commands to set up:<br />
<br />
$ git init --bare ~/.dotfiles<br />
$ alias config='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'<br />
$ config config status.showUntrackedFiles no<br />
<br />
You can then manage your dotfiles with the created [[alias]]. If you are using [[Bash]] and would like bash completion for this alias, simply install {{AUR|bash-complete-alias}}, then add the alias and the following line to your {{ic|~/.bashrc}}.<br />
<br />
$ complete -F _complete_alias config<br />
<br />
{{Tip|To avoid accidentally commiting confidential information, see [[Git#Filtering confidential information]].}}<br />
<br />
== Host-specific configuration ==<br />
<br />
A common problem with synchronizing dotfiles across various machines is host-specific configuration.<br />
<br />
With [[Git]] this can be solved by maintaining a master branch for all shared configuration, while each individual machine has a machine-specific branch checked out. Host-specific configuration can be committed to the machine-specific branch; when shared configuration is modified in the master branch, the per-machine branches need to be rebased on top of the updated master.<br />
<br />
In configuration scripts like [[Command-line shell#Configuration files|shell configuration files]] conditional logic can be used. For example, [[Bash]] scripts (i.e. {{ic|.bashrc}}) can apply different configuration depending on the machine name (or type, custom variable, etc.):<br />
<br />
if <nowiki>[[ "$(hostname)" == "archlaptop" ]];</nowiki> then<br />
# laptop specific commands here<br />
else<br />
# desktop or server machine commands<br />
fi<br />
<br />
Similar can also be achieved with [[.Xresources]].[https://jnrowe.github.io/articles/tips/Sharing_Xresources_between_systems.html]<br />
<br />
If you find rebasing Git branches too cumbersome, you may want to use a [[#Tools|tool]] that supports ''file grouping'', or if even greater flexibility is desired, a tool that does ''processing''.<br />
<br />
== Tools ==<br />
<br />
;File grouping<br />
:How configuration files can be grouped to configuration groups (also called profiles or packages).<br />
;Processing<br />
:Some tools process configuration files to allow them to be customized depending on the host.<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
! Name !! Package !! Written in !! File grouping !! Processing<br />
|-<br />
! [https://github.com/kesslern/dot-templater dot-templater]<br />
| {{AUR|dot-templater-git}} || Rust || directory-based || custom syntax<br />
|-<br />
! [https://github.com/SuperCuber/dotter dotter]<br />
| {{AUR|dotter-rs}} || Rust || configuration file || Handlebars<br />
|-<br />
! [https://deadc0de.re/dotdrop/ dotdrop]<br />
| {{AUR|dotdrop}} || Python || configuration file || Jinja2<br />
|-<br />
! [https://github.com/jbernard/dotfiles dotfiles]<br />
| {{AUR|dotfiles}} || Python || {{Grey|[https://github.com/jbernard/dotfiles/pull/24 No]}} || {{Grey|No}}<br />
|-<br />
! [https://github.com/EvanPurkhiser/dots Dots]<br />
| {{AUR|dots-manager}} || Python || directory-based || custom append points<br />
|-<br />
! [https://github.com/twpayne/chezmoi chezmoi]<br />
| {{Pkg|chezmoi}} || Go || directory-based || Go templates<br />
|-<br />
! [https://www.gnu.org/software/stow/ GNU Stow]<br />
| {{Pkg|stow}} || Perl || directory-based[http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html] || {{Grey|No}}<br />
|-<br />
! [https://github.com/lra/mackup Mackup]<br />
| {{AUR|mackup}} || Python || automatic per application || {{Grey|No}}<br />
|-<br />
! [https://github.com/darkfeline/mir.qualia mir.qualia]<br />
| {{AUR|mir.qualia}} || Python || {{Grey|No}} || custom blocks<br />
|-<br />
! [https://github.com/thoughtbot/rcm rcm]<br />
| {{AUR|rcm}} || Perl || directory-based (by host or tag) || {{Grey|No}}<br />
|}<br />
<br />
=== Tools wrapping Git ===<br />
<br />
If you are uncomfortable with [[Git]], you may want to use one of these tools, which abstract the version control system away (more or less).<br />
<br />
{| class="wikitable sortable" style="text-align:center;"<br />
! Name !! Package !! Written in !! File grouping !! Processing<br />
|-<br />
! [https://github.com/kazhala/dotbare dotbare]<br />
| {{AUR|dotbare}} || Shell ({{Pkg|fzf}}) || repository-wise || {{Grey|No}}<br />
|-<br />
! [https://github.com/kobus-v-schoor/dotgit dotgit]<br />
| {{AUR|dotgit}} || Python || filename-based || {{Grey|No}}<br />
|-<br />
! [https://github.com/andsens/homeshick homeshick]<br />
| {{AUR|homeshick-git}} || Bash || repository-wise || {{Grey|No}}<br />
|-<br />
! [https://github.com/technicalpickles/homesick homesick]<br />
| {{AUR|homesick}} || Ruby || repository-wise || {{Grey|No}}<br />
|-<br />
! [https://github.com/pearl-core/pearl Pearl]<br />
| {{AUR|pearl-git}} || Python || repository-wise || {{Grey|No}}<br />
|-<br />
! [https://github.com/RichiH/vcsh vcsh]<br />
| {{AUR|vcsh}} || Shell || repository-wise || {{Grey|No}}<br />
|-<br />
! [https://yadm.io yadm]<sup>(1)</sup><br />
| {{AUR|yadm}} || Python, Shell || filename-based<br>(by class, OS, hostname & user) [https://yadm.io/docs/alternates] || Jinja2, Shell<br>(optional) [https://yadm.io/docs/templates]<br />
|}<br />
<br />
# Supports encryption of confidential files with [[GPG]]. [https://thelocehiliosan.github.io/yadm/docs/encryption]<br />
<br />
== User repositories ==<br />
<br />
{| class="wikitable sortable" style="text-align:center"<br />
! Author || Shell (Shell framework) || WM / DE || Editor || Terminal || Multiplexer || Audio || Monitor || Mail || IRC || File Manager<br />
|-<br />
! [https://github.com/alfunx/.dotfiles alfunx]<br />
| zsh || awesome || vim || kitty || tmux || ncmpcpp/mpd || htop/lain || thunderbird || ||<br />
|-<br />
! [https://gitlab.com/altaway/dotfiles altaway]<br />
| zsh || bspwm || neovim || alacritty || bspwm || mpv || ytop || gnus+message || rcirc || broot<br />
|-<br />
! [https://gitlab.com/Ambrevar/dotfiles Ambrevar]<br />
| Eshell || EXWM || Emacs || Emacs (Eshell) || Emacs TRAMP + dtach || EMMS || conky/dzen || mu4e || Circe ||<br />
|-<br />
! [https://github.com/ask1234560/dotfiles_bspwm ananthu]<br />
| zsh || bspwm || neovim || alacritty || || mpv || htop, polybar || neomutt || weechat || ranger<br />
|-<br />
! [https://github.com/awalGarg/dotfiles awal]<br />
| fish || i3 || vim || st || tmux || || i3status || || The Lounge ||<br />
|-<br />
! [https://github.com/ayekat/dotfiles ayekat]<br />
| zsh || karuiwm || vim || rxvt-unicode || tmux || ncmpcpp/mpd || karuibar || mutt || irssi ||<br />
|-<br />
! [https://github.com/bamos/dotfiles bamos]<br />
| zsh || i3/xmonad || vim/emacs || rxvt-unicode || tmux || mpv/cmus || conky/xmobar || mutt || ERC ||<br />
|-<br />
! [https://github.com/benmezger/dotfiles benmezger] <br />
| [https://github.com/benmezger/dotfiles zsh/bash/fish] || [https://github.com/benmezger/dotfiles/tree/main/dot_config/i3 i3-gaps] || [https://github.com/benmezger/dotfiles/tree/main/dot_doom.d emacs] || [https://github.com/benmezger/dotfiles/blob/main/dot_Xresources rxvt-unicode] || [https://github.com/benmezger/dotfiles/blob/main/dot_tmux.conf tmux] || || [https://github.com/benmezger/dotfiles/blob/main/dot_config/i3/status.toml.tmpl i3status-rs] || mu4e/neomutt || weechat ||<br />
|-<br />
! [https://github.com/pbrisbin/dotfiles brisbin33]<br />
| [https://github.com/pbrisbin/oh-my-zsh zsh] || [https://github.com/pbrisbin/xmonad-config xmonad] || [https://github.com/pbrisbin/vim-config vim] || rxvt-unicode || screen || || dzen || [https://github.com/pbrisbin/mutt-config mutt] || [https://github.com/pbrisbin/irssi-config irssi] ||<br />
|-<br />
! [https://gitlab.com/BVollmerhaus/dotfiles BVollmerhaus]<br />
| [https://gitlab.com/BVollmerhaus/dotfiles/-/tree/master/config/fish fish] || [https://gitlab.com/BVollmerhaus/dotfiles/blob/master/config/i3/config i3-gaps] || [https://gitlab.com/BVollmerhaus/dotfiles/blob/master/config/kak/kakrc kakoune] || [https://gitlab.com/BVollmerhaus/dotfiles/-/blob/master/config/kitty/kitty.conf kitty] || || || [https://gitlab.com/BVollmerhaus/dotfiles/blob/master/config/polybar/config polybar] || || || [https://gitlab.com/BVollmerhaus/dotfiles/-/tree/master/config/ranger ranger]<br />
|-<br />
! [https://github.com/cinelli/dotfiles cinelli]<br />
| zsh || dwm || vim || termite-git || || pianobar || htop || mutt-kz || weechat ||<br />
|-<br />
! [https://github.com/dikiaap/dotfiles dikiaap]<br />
| zsh || i3-gaps || neovim || alacritty || tmux || || i3blocks || || ||<br />
|-<br />
! [https://github.com/Earnestly/dotfiles Earnestly]<br />
| zsh || i3/orbment || vim/emacs || termite || tmux || mpd || conky || mutt || weechat ||<br />
|-<br />
! [https://github.com/ErikBjare/dotfiles ErikBjare]<br />
| zsh || xmonad/xfce4 || vim || terminator || tmux || || xfce4-panel || || weechat ||<br />
|-<br />
! [https://github.com/falconindy/dotfiles falconindy]<br />
| bash || i3 || vim || rxvt-unicode || || ncmpcpp || conky || mutt || ||<br />
|-<br />
! [https://github.com/filiparag/dotfiles filiparag]<br />
| fish || bspwm || vim || alacritty || tmux || mpv, [https://github.com/altdesktop/playerctl playerctl] || htop, polybar || [https://www.nongnu.org/mailnotify/ mail-notification] || || [https://wiki.lxde.org/en/PCManFM pcmanfm]<br />
|-<br />
! [https://gitlab.com/gardenappl/dotfiles gardenapple]<br />
| fish || Sway || neovim || termite || || || htop || [https://aerc-mail.org/ aerc] || ||<br />
|-<br />
! [https://github.com/graysky2/configs/tree/master/dotfiles graysky]<br />
| zsh || xfce4 || vim || terminal || || ncmpcpp || custom || thunderbird || ||<br />
|-<br />
! [https://github.com/hugdru/dotfiles hugdru]<br />
| zsh || awesome || neovim || rxvt-unicode || tmux || || || thunderbird || weechat ||<br />
|-<br />
! [https://github.com/insanum/dotfiles insanum]<br />
| bash || herbstluftwm || vim || evilvte || tmux || || dzen || mutt-kz || ||<br />
|-<br />
! [https://hg.sr.ht/~jasonwryan/shiv jasonwryan]<br />
| bash/zsh || dwm || vim || rxvt-unicode || tmux || ncmpcpp || custom || mutt || irssi ||<br />
|-<br />
! [https://github.com/JDevlieghere/dotfiles/ jdevlieghere]<br />
| zsh || xmonad || vim || terminal || tmux || || htop || mutt || weechat ||<br />
|-<br />
! [https://github.com/jelly/Dotfiles jelly]<br />
| zsh || i3 || vim || termite || tmux || ncmpcpp || || mutt-kz-git || weechat ||<br />
|-<br />
! [https://github.com/JonasDe/dotfiles JonasDe] <br />
| zsh || i3 || vim || rxvt-unicode || tmux || || || || ||<br />
|-<br />
! [https://github.com/Jorengarenar/dotfiles Jorengarenar] <br />
| bash || i3 || vim || xterm || || mpv || i3blocks || aerc || weechat ||<br />
|-<br />
! [https://github.com/LukeSmithxyz/voidrice LukeSmithxyz]<br />
| zsh || dwm || neovim || st || || ncmpcpp || dwmblocks || mutt || || lf<br />
|-<br />
! [https://github.com/markuszoppelt/dotfiles MarkusZoppelt]<br />
| zsh || gnome || vim || terminal || tmux || || || || || <br />
|-<br />
! [https://github.com/maximbaz/dotfiles maximbaz]<br />
| zsh || sway || kakoune || kitty || || || waybar || neomutt || || nnn<br />
|-<br />
! [https://git.mehalter.com/mehalter/dotfiles mehalter]<br />
| zsh || i3-gaps || neovim || termite || tmux || cmus || gotop || neomutt || weechat || ranger<br />
|-<br />
! [https://github.com/meskarune/.dotfiles meskarune]<br />
| bash || herbstluftwm || vim || rxvt-unicode || screen || || conky || || weechat ||<br />
|-<br />
! [https://github.com/neersighted/dotfiles neersighted]<br />
| fish || i3 || neovim || alacritty || tmux || ncmpcpp || || || ||<br />
|-<br />
! [https://github.com/oibind/dotfiles oibind]<br />
| fish || awesome || neovim || st || tmux || || htop-vim || || weechat || lf<br />
|-<br />
! [https://github.com/ok100/configs OK100]<br />
| bash || dwm || vim || rxvt-unicode || || cmus || conky, dzen || mutt || weechat ||<br />
|-<br />
! [https://github.com/pablox-cl/dotfiles pablox-cl]<br />
| zsh (zplug) || gnome3 || neovim || kitty || || || || || ||<br />
|-<br />
! [https://gitlab.com/peterzuger/dotfiles peterzuger]<br />
| zsh || i3-gaps || emacs || rxvt-unicode || screen || moc || htop || || ||<br />
|-<br />
! [https://github.com/potamides/dotfiles potamides]<br />
| bash || awesome || neovim || termite || tmux || ncmpcpp || conky,htop || mutt || weechat || ranger<br />
|-<br />
! [https://github.com/reisub0/dot reisub0]<br />
| fish || qtile || neovim || kitty || || mpd || conky || || ||<br />
|-<br />
! [https://github.com/shubhamgupta2956/dotfiles shubhamgupta2956]<br />
| zsh || i3-gaps-rounded || vim || terminator || || cmus || htop, i3blocks, gotop || || || ranger, nautilus<br />
|-<br />
! [https://github.com/sistematico/majestic sistematico]<br />
| zsh/fish/bash || [https://github.com/Airblader/i3 i3-gaps] || vim/nano || termite || tmux || ncmpcpp || polybar || mutt || weechat ||<br />
|-<br />
! [https://git.sitilge.id.lv/sitilge/dotfiles sitilge]<br />
| zsh || sway || neovim || alacritty || || || htop || thunderbird || ||<br />
|-<br />
! [https://github.com/thiagowfx/dotfiles thiagowfx]<br />
| bash || i3 || vim/emacs || tilix || || || i3blocks || || ||<br />
|-<br />
! [https://github.com/vodik/dotfiles vodik]<br />
| zsh || xmonad || vim || termite-git || tmux || ncmpcpp || custom || mutt || weechat ||<br />
|-<br />
! [https://github.com/w0ng/dotfiles w0ng]<br />
| zsh || dwm || vim || rxvt-unicode || tmux || ncmpcpp || custom || mutt || irssi ||<br />
|-<br />
! [https://github.com/whitelynx/dotfiles whitelynx]<br />
| fish || i3 || neovim || kitty || || || i3pystatus || || ||<br />
|-<br />
! [https://github.com/wolfcore/dotfiles wolfcore] <br />
| bash || dwm || vim || rxvt-unicode || tmux || cmus || custom || || weechat ||<br />
|-<br />
! [https://github.com/zendeavor zendeavor]<br />
| [https://github.com/zendeavor/config-stuff/tree/sandbag/zsh zsh] || [https://github.com/zendeavor/config-stuff/blob/sandbag/i3/config i3] || [https://github.com/zendeavor/dotvim/tree/sandbag vim] || [https://github.com/zendeavor/config-stuff/blob/sandbag/X11/Xresources#L14 rxvt-unicode] || [https://github.com/zendeavor/config-stuff/tree/sandbag/tmux tmux] || [https://github.com/zendeavor/config-stuff/blob/sandbag/ncmpcpp/config ncmpcpp] || [https://github.com/zendeavor/config-stuff/blob/sandbag/i3/i3status.conf i3status] || || [https://github.com/zendeavor/config-stuff/tree/kiwi/weechat weechat] ||<br />
|}<br />
<br />
== See also ==<br />
<br />
* [[gregswiki:DotFiles]]<br />
* [http://wiki.haskell.org/Xmonad/Config_archive XMonad Config Archive]<br />
* [http://dotshare.it dotshare.it]<br />
* [https://dotfiles.github.io/ dotfiles.github.io]<br />
* [https://terminal.sexy/ terminal.sexy] - Terminal color scheme designer</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Zsh&diff=654643Talk:Zsh2021-03-12T18:37:22Z<p>Jasonwryan: /* Warning about third party extensions (OMZ) */ Closed</p>
<hr />
<div>== Same directory in newly opened tab ==<br />
<br />
I had to append the following to my zshrc<br />
<br />
{{hc|~/.zshrc|<br />
<truncated><br />
. /etc/profile.d/vte.sh<br />
}}<br />
<br />
such that a newly opened tab opened in the previous working directory (using gnome-terminal). [[User:MrWhite|MrWhite]] ([[User talk:MrWhite|talk]]) 13:14, 5 November 2017 (UTC)<br />
<br />
== <s>Warning about third party extensions (OMZ)</s> ==<br />
The number of people that blindly install Oh-My-Zsh and then find some aspect of their shell broken is staggering. I propose a warning above this section noting that these tools introduce a huge amount of complexity and abstraction, which in many cases results in unexpected and unfortunate behaviours. Essentially, if you install these, expect breakage, and if you want support, your first debug step should be to remove them. -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:16, 9 March 2021 (UTC)<br />
<br />
:I agree with this. In my opinion Oh-My-Zsh is almost comparable to an install script: the user does not know their own shell.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 23:00, 9 March 2021 (UTC)<br />
<br />
:I've previously thought about something like this, but I couldn't find any authoritative source that advises against these frameworks & etc. I agree about adding something to steer people away from them, but I'm not sure if it should be a warning. There really isn't any danger involved, so a note should suffice. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:33, 10 March 2021 (UTC)<br />
::Done, as a note, -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 18:37, 12 March 2021 (UTC)</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Zsh&diff=654642Zsh2021-03-12T18:35:31Z<p>Jasonwryan: /* Third-party extensions */ Added note about potential risks</p>
<hr />
<div>[[Category:Command-line shells]]<br />
[[cs:Zsh]]<br />
[[de:Zsh]]<br />
[[es:Zsh]]<br />
[[fa:Zsh]]<br />
[[fr:Zsh]]<br />
[[ja:Zsh]]<br />
[[ru:Zsh]]<br />
[[zh-hans:Zsh]]<br />
[https://www.zsh.org/ Zsh] is a powerful [[shell]] that operates as both an interactive shell and as a scripting language interpreter. While being compatible with the POSIX sh (not by default, only if issuing {{ic|emulate sh}}), it offers advantages such as improved [http://zsh.sourceforge.net/Guide/zshguide06.html tab completion] and [http://zsh.sourceforge.net/Doc/Release/Expansion.html globbing].<br />
<br />
The [http://zsh.sourceforge.net/FAQ/zshfaq01.html#l4 Zsh FAQ] offers more reasons to use Zsh.<br />
<br />
== Installation ==<br />
<br />
Before starting, users may want to see what shell is currently being used:<br />
<br />
$ echo $SHELL<br />
<br />
[[Install]] the {{Pkg|zsh}} package. For additional completion definitions, install the {{pkg|zsh-completions}} package as well.<br />
<br />
=== Initial configuration ===<br />
<br />
Make sure that Zsh has been installed correctly by running the following in a terminal:<br />
<br />
$ zsh<br />
<br />
You should now see ''zsh-newuser-install'', which will walk you through some basic configuration. If you want to skip this, press {{ic|q}}. If you did not see it, you can invoke it manually with:<br />
<br />
$ autoload -Uz zsh-newuser-install<br />
$ zsh-newuser-install -f<br />
<br />
{{Note|Make sure your terminal's size is at least 72×15 otherwise ''zsh-newuser-install'' will not run.}}<br />
<br />
=== Making Zsh your default shell ===<br />
<br />
Change your shell to {{ic|/usr/bin/zsh}}. See [[Command-line shell#Changing your default shell]].<br />
<br />
{{Tip|If replacing {{Pkg|bash}}, users may want to move some code from {{ic|~/.bashrc}} to {{ic|~/.zshrc}} (e.g. the prompt and the [[Bash#Aliases|aliases]]) and from {{ic|~/.bash_profile}} to {{ic|~/.zprofile}} (e.g. [[xinit#Autostart X at login|the code that starts the X Window System]]).}}<br />
<br />
== Startup/Shutdown files ==<br />
<br />
{{Tip|<br />
* See [http://zsh.sourceforge.net/Guide/zshguide02.html A User's Guide to the Z-Shell] for explanation on interactive and login shells, and what to put in your startup files.<br />
* You could consider [[Command-line shell#Standardisation|implementing a standard path]] for your Zsh configuration files.<br />
}}<br />
<br />
{{Note|<br />
* If {{ic|$ZDOTDIR}} is not set, {{ic|$HOME}} is used instead.<br />
* If option {{ic|RCS}} is unset in any of the files, no configuration files will be read after that file.<br />
* If option {{ic|GLOBAL_RCS}} is unset in any of the files, no global configuration files ({{ic|/etc/zsh/*}}) will be read after that file.<br />
}}<br />
<br />
When starting, Zsh will read commands from the following files in this order by default, provided they exist. <br />
<br />
* {{ic|/etc/zsh/zshenv}} Used for setting [[environment variables]] for all users; it should not contain commands that produce output or assume the shell is attached to a TTY. When this file exists it will '''''always''''' be read, this cannot be overridden.<br />
* {{ic|$ZDOTDIR/.zshenv}} Used for setting user's environment variables; it should not contain commands that produce output or assume the shell is attached to a TTY. When this file exists it will '''''always''''' be read.<br />
* {{ic|/etc/zsh/zprofile}} Used for executing commands at start for all users, will be read when starting as a '''''login shell'''''. Please note that on Arch Linux, by default it contains [https://github.com/archlinux/svntogit-packages/blob/packages/zsh/trunk/zprofile one line] which sources {{ic|/etc/profile}}. See warning below before wanting to remove that!<br />
** {{ic|/etc/profile}} This file should be sourced by all POSIX sh-compatible shells upon login: it sets up {{ic|$PATH}} and other environment variables and application-specific ({{ic|/etc/profile.d/*.sh}}) settings upon login.<br />
* {{ic|$ZDOTDIR/.zprofile}} Used for executing user's commands at start, will be read when starting as a '''''login shell'''''. Typically used to autostart graphical sessions and to set session-wide environment variables.<br />
* {{ic|/etc/zsh/zshrc}} Used for setting interactive shell configuration and executing commands for all users, will be read when starting as an '''''interactive shell'''''.<br />
* {{ic|$ZDOTDIR/.zshrc}} Used for setting user's interactive shell configuration and executing commands, will be read when starting as an '''''interactive shell'''''.<br />
* {{ic|/etc/zsh/zlogin}} Used for executing commands for all users at ending of initial progress, will be read when starting as a '''''login shell'''''.<br />
* {{ic|$ZDOTDIR/.zlogin}} Used for executing user's commands at ending of initial progress, will be read when starting as a '''''login shell'''''. Typically used to autostart command line utilities. Should not be used to autostart graphical sessions, as at this point the session might contain configuration meant only for an interactive shell.<br />
* {{ic|$ZDOTDIR/.zlogout}} Used for executing commands when a '''''login shell''''' '''exits'''.<br />
* {{ic|/etc/zsh/zlogout}} Used for executing commands for all users when a '''''login shell''''' '''exits'''.<br />
<br />
See [https://blog.flowblok.id.au/2013-02/shell-startup-scripts.html#implementation the graphic representation].<br />
<br />
{{Note|<br />
* {{ic|$HOME/.profile}} is not a part of the Zsh startup files and '''is not sourced''' by Zsh unless Zsh is invoked as {{ic|sh}} or {{ic|ksh}} and started as a login shell. For more details about the sh and [[ksh]] compatibility modes refer to {{man|1|zsh|COMPATIBILITY}}.<br />
* The paths used in Arch's {{Pkg|zsh}} package are different from the default ones used in the [[man page]]s ({{Bug|48992}}).<br />
}}<br />
<br />
{{Warning|Do not remove the default [https://github.com/archlinux/svntogit-packages/blob/packages/zsh/trunk/zprofile one line] in {{ic|/etc/zsh/zprofile}}, otherwise it will break the integrity of other packages which provide some scripts in {{ic|/etc/profile.d/}}.}}<br />
<br />
== Configure Zsh ==<br />
<br />
Although Zsh is usable out of the box, it is almost certainly not set up the way most users would like to use it. But due to the sheer amount of customization available in Zsh, configuring Zsh can be a daunting and time-consuming experience.<br />
<br />
=== Simple .zshrc ===<br />
<br />
Included below is a sample configuration file. It provides a decent set of default options as well as giving examples of many ways that Zsh can be customized. In order to use this configuration save it as a file named {{ic|.zshrc}}.<br />
<br />
{{Tip|Apply the changes without needing to logout and then back in by running {{ic|source ~/.zshrc}}.}}<br />
<br />
Here is a simple {{ic|.zshrc}}:<br />
<br />
{{hc|~/.zshrc|<br />
autoload -Uz compinit promptinit<br />
compinit<br />
promptinit<br />
<br />
# This will set the default prompt to the walters theme<br />
prompt walters<br />
}}<br />
<br />
=== Configuring $PATH ===<br />
<br />
Zsh ties the {{ic|PATH}} variable to a {{ic|path}} array. They are automatically synchronized. This allows us to easily manipulate {{ic|PATH}} by simply modifying the array. See [http://zsh.sourceforge.net/Guide/zshguide02.html#l24 A User's Guide to the Z-Shell] for details.<br />
<br />
The line {{ic|typeset -U PATH path}}, where the {{ic|-U}} stands for unique, instructs the shell to discard duplicates from both {{ic|$PATH}} and {{ic|$path}}:<br />
<br />
{{hc|~/.zshenv|2=<br />
typeset -U PATH path<br />
path=("$HOME/.local/bin" ''/other/things/in/path'' "$path[@]")<br />
export PATH<br />
}}<br />
<br />
=== Command completion ===<br />
<br />
Perhaps the most compelling feature of Zsh is its advanced autocompletion abilities. At the very least, enable autocompletion in {{ic|.zshrc}}. To enable autocompletion, add the following to your {{ic|~/.zshrc}}:<br />
<br />
{{hc|~/.zshrc|<br />
autoload -Uz compinit<br />
compinit<br />
}}<br />
<br />
The above configuration includes ssh/scp/sftp hostnames completion but in order for this feature to work, users must not enable ssh's hostname hashing (i.e. option {{ic|HashKnownHosts}} in ssh client configuration).<br />
<br />
For autocompletion with an arrow-key driven interface, add the following to:<br />
<br />
{{hc|~/.zshrc|<br />
zstyle ':completion:*' menu select<br />
}}<br />
<br />
To activate the menu, press {{ic|Tab}} twice.<br />
<br />
For autocompletion of command line switches for aliases, add the following to:<br />
<br />
{{hc|~/.zshrc|<br />
setopt COMPLETE_ALIASES<br />
}}<br />
<br />
For enabling autocompletion of privileged environments in privileged commands (e.g. if you complete a command starting with [[sudo]], completion scripts will also try to determine your completions with sudo), include:<br />
<br />
{{hc|~/.zshrc|<br />
zstyle ':completion::complete:*' gain-privileges 1<br />
}}<br />
<br />
{{Warning|This will let Zsh completion scripts run commands with sudo privileges. You should not enable this if you use untrusted autocompletion scripts.}}<br />
<br />
{{Note|This special kind of context-aware completion is only available for a small number of commands.}}<br />
<br />
=== Key bindings ===<br />
<br />
Zsh does not use [[readline]], instead it uses its own and more powerful Zsh Line Editor (ZLE). It does not read {{ic|/etc/inputrc}} or {{ic|~/.inputrc}}. Read [https://sgeb.io/posts/2014/04/zsh-zle-custom-widgets/ A closer look at the zsh line editor and creating custom widgets] for an introduction to ZLE configuration.<br />
<br />
ZLE has an [[Emacs]] mode and a [[vi]] mode. If one of the {{ic|VISUAL}} or {{ic|EDITOR}} [[environment variables]] contain the string {{ic|vi}} then vi mode will be used; otherwise, it will default to Emacs mode. Set the mode explicitly with {{ic|bindkey -e}} or {{ic|bindkey -v}} respectively for Emacs mode or vi mode.<br />
<br />
Key bindings are assigned by mapping an escape sequence matching a keypress to a ZLE widget. The available widgets, with descriptions of their actions and their default keybindings, are listed in {{man|1|zshzle|STANDARD WIDGETS}} and {{man|1|zshcontrib|ZLE FUNCTIONS}}.<br />
<br />
The recommended way to set key bindings in Zsh is by using string capabilities from {{man|5|terminfo}}. For example[https://web.archive.org/web/20180704181216/http://zshwiki.org/home/zle/bindkeys][https://www.zsh.org/mla/users/2010/msg00065.html]:<br />
<br />
{{hc|~/.zshrc|2=<br />
# create a zkbd compatible hash;<br />
# to add other keys to this hash, see: man 5 terminfo<br />
typeset -g -A key<br />
<br />
key[Home]="${terminfo[khome]}"<br />
key[End]="${terminfo[kend]}"<br />
key[Insert]="${terminfo[kich1]}"<br />
key[Backspace]="${terminfo[kbs]}"<br />
key[Delete]="${terminfo[kdch1]}"<br />
key[Up]="${terminfo[kcuu1]}"<br />
key[Down]="${terminfo[kcud1]}"<br />
key[Left]="${terminfo[kcub1]}"<br />
key[Right]="${terminfo[kcuf1]}"<br />
key[PageUp]="${terminfo[kpp]}"<br />
key[PageDown]="${terminfo[knp]}"<br />
key[Shift-Tab]="${terminfo[kcbt]}"<br />
<br />
# setup key accordingly<br />
[[ -n "${key[Home]}" ]] && bindkey -- "${key[Home]}" beginning-of-line<br />
[[ -n "${key[End]}" ]] && bindkey -- "${key[End]}" end-of-line<br />
[[ -n "${key[Insert]}" ]] && bindkey -- "${key[Insert]}" overwrite-mode<br />
[[ -n "${key[Backspace]}" ]] && bindkey -- "${key[Backspace]}" backward-delete-char<br />
[[ -n "${key[Delete]}" ]] && bindkey -- "${key[Delete]}" delete-char<br />
[[ -n "${key[Up]}" ]] && bindkey -- "${key[Up]}" up-line-or-history<br />
[[ -n "${key[Down]}" ]] && bindkey -- "${key[Down]}" down-line-or-history<br />
[[ -n "${key[Left]}" ]] && bindkey -- "${key[Left]}" backward-char<br />
[[ -n "${key[Right]}" ]] && bindkey -- "${key[Right]}" forward-char<br />
[[ -n "${key[PageUp]}" ]] && bindkey -- "${key[PageUp]}" beginning-of-buffer-or-history<br />
[[ -n "${key[PageDown]}" ]] && bindkey -- "${key[PageDown]}" end-of-buffer-or-history<br />
[[ -n "${key[Shift-Tab]}" ]] && bindkey -- "${key[Shift-Tab]}" reverse-menu-complete<br />
<br />
# Finally, make sure the terminal is in application mode, when zle is<br />
# active. Only then are the values from $terminfo valid.<br />
if (( ${+terminfo[smkx]} && ${+terminfo[rmkx]} )); then<br />
autoload -Uz add-zle-hook-widget<br />
function zle_application_mode_start { echoti smkx }<br />
function zle_application_mode_stop { echoti rmkx }<br />
add-zle-hook-widget -Uz zle-line-init zle_application_mode_start<br />
add-zle-hook-widget -Uz zle-line-finish zle_application_mode_stop<br />
fi<br />
}}<br />
<br />
==== History search ====<br />
<br />
You need to set up the {{ic|key}} array and make sure that ZLE enters application mode to use the following instructions; see [[#Key bindings]].<br />
<br />
To enable history search add these lines to {{ic|.zshrc}} file:<br />
<br />
{{hc|~/.zshrc|<br />
autoload -Uz up-line-or-beginning-search down-line-or-beginning-search<br />
zle -N up-line-or-beginning-search<br />
zle -N down-line-or-beginning-search<br />
<br />
[[ -n "${key[Up]}" ]] && bindkey -- "${key[Up]}" up-line-or-beginning-search<br />
[[ -n "${key[Down]}" ]] && bindkey -- "${key[Down]}" down-line-or-beginning-search<br />
}}<br />
<br />
By doing this, only the past commands matching the current line up to the current cursor position will be shown when {{ic|Up}} or {{ic|Down}} keys are pressed.<br />
<br />
==== Shift, Alt, Ctrl and Meta modifiers ====<br />
<br />
xterm-compatible terminals can use extended key-definitions from {{man|5|user_caps}}. Those are combinations of {{ic|Shift}}, {{ic|Alt}}, {{ic|Ctrl}} and {{ic|Meta}} together with {{ic|Up}}, {{ic|Down}}, {{ic|Left}}, {{ic|Right}}, {{ic|PageUp}}, {{ic|PageDown}}, {{ic|Home}}, {{ic|End}} or {{ic|Del}}. Refer to the [https://sourceforge.net/p/zsh/code/ci/master/tree/Functions/Misc/zkbd zkbd source] for a list of recommended names for the modifier keys and key combinations.<br />
<br />
For example, for {{ic|Ctrl+Left}} to move to the beginning of the previous word and {{ic|Ctrl+Right}} to move to the beginning of the next word:<br />
<br />
{{hc|~/.zshrc|2=<br />
key[Control-Left]="${terminfo[kLFT5]}"<br />
key[Control-Right]="${terminfo[kRIT5]}"<br />
<br />
[[ -n "${key[Control-Left]}" ]] && bindkey -- "${key[Control-Left]}" backward-word<br />
[[ -n "${key[Control-Right]}" ]] && bindkey -- "${key[Control-Right]}" forward-word<br />
}}<br />
<br />
=== Prompts ===<br />
<br />
Zsh offers the options of using a prompt theme or, for users who are dissatisfied with the themes (or want to expand their usefulness), the possibility to build a custom prompt.<br />
<br />
==== Prompt themes ====<br />
<br />
Prompt themes are a quick and easy way to set up a colored prompt in Zsh. See {{man|1|zshcontrib|PROMPT THEMES}} for more information about them.<br />
<br />
To use a theme, make sure that prompt theme system is set to autoload in {{ic|.zshrc}}. This can be done by adding these lines to:<br />
<br />
{{hc|~/.zshrc|<br />
autoload -Uz promptinit<br />
promptinit<br />
}}<br />
<br />
Available prompt themes are listed by running the command:<br />
<br />
$ prompt -l<br />
<br />
For example, to use the {{ic|walters}} theme, enter:<br />
<br />
$ prompt walters<br />
<br />
To preview all available themes, use this command:<br />
<br />
$ prompt -p<br />
<br />
===== Manually installing prompt themes =====<br />
<br />
It is possible to install themes manually, without external configuration manager tools. For a local installation, first create a folder and add it to the {{ic|fpath}} array, eg:<br />
<br />
$ mkdir ~/.zprompts<br />
$ fpath=("$HOME/.zprompts" "$fpath[@]")<br />
<br />
Now create a symbolic link of your theme file in this folder:<br />
<br />
$ ln -s mytheme.zsh ~/.zprompts/prompt_mytheme_setup<br />
<br />
If instead you wish to install a theme globally, do:<br />
<br />
# ln -s mytheme.zsh /usr/share/zsh/functions/Prompts/prompt_mytheme_setup<br />
<br />
Now you should be able to activate it using:<br />
<br />
$ prompt mytheme<br />
<br />
If everything works, you can edit your {{ic|.zshrc}} accordingly.<br />
<br />
===== Adding prompt themes without a separate file for each one =====<br />
<br />
In addition to adding a prompt theme through its own file, it is possible to add themes from within another file (like your {{ic|.zshrc}}), eg:<br />
<br />
{{hc|~/.zshrc|2=<br />
# Load promptinit<br />
autoload -Uz promptinit && promptinit<br />
<br />
# Define the theme<br />
prompt_mytheme_setup() {<br />
PS1="%~%# "<br />
}<br />
<br />
# Add the theme to promptsys<br />
prompt_themes+=( mytheme )<br />
<br />
# Load the theme<br />
prompt mytheme<br />
}}<br />
<br />
==== Customized prompt ====<br />
<br />
{{Expansion|Add a simple colorless {{ic|PROMPT}} example.}}<br />
<br />
Additionally to a primary left-sided prompt {{ic|PS1}} ({{ic|PROMPT}}, {{ic|prompt}}) that is common to all shells, Zsh also supports a right-sided prompt {{ic|RPS1}} ({{ic|RPROMPT}}). These two variables are the ones you will want to set to a custom value.<br />
<br />
Other special purpose prompts, such as {{ic|PS2}} ({{ic|PROMPT2}}), {{ic|PS3}} ({{ic|PROMPT3}}), {{ic|PS4}} ({{ic|PROMPT4}}), {{ic|RPS1}} ({{ic|RPROMPT}}), {{ic|RPS2}} ({{ic|RPROMPT2}}) and {{ic|SPROMPT}}, are explained in {{man|1|zshparam|PARAMETERS USED BY THE SHELL}}.<br />
<br />
All prompts can be customized with prompt escapes. The available prompt escapes are listed in {{man|1|zshmisc|EXPANSION OF PROMPT SEQUENCES}}.<br />
<br />
===== Colors =====<br />
<br />
Zsh sets colors differently than [[Bash/Prompt customization|Bash]], you do not need to use convoluted ANSI escape sequences or terminal capabilities from {{man|5|terminfo}}. Zsh provides convenient prompt escapes to set the foreground color, background color and other visual effects; see {{man|1|zshmisc|Visual effects}} for a list of them and their descriptions.<br />
<br />
[http://zsh.sourceforge.net/FAQ/zshfaq03.html#l42 Colors] can be specified using a decimal integer, the name of one of the eight most widely-supported colors or as a # followed by an RGB triplet in hexadecimal format. See the description of fg=colour in {{man|1|zshzle|CHARACTER HIGHLIGHTING}} for more details.<br />
<br />
Most terminals support the following colors by name:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name !! Number<br />
|-<br />
| {{ic|black}} || {{ic|0}}<br />
|-<br />
| {{ic|red}} || {{ic|1}}<br />
|-<br />
| {{ic|green}} || {{ic|2}}<br />
|-<br />
| {{ic|yellow}} || {{ic|3}}<br />
|-<br />
| {{ic|blue}} || {{ic|4}}<br />
|-<br />
| {{ic|magenta}} || {{ic|5}}<br />
|-<br />
| {{ic|cyan}} || {{ic|6}}<br />
|-<br />
| {{ic|white}} || {{ic|7}}<br />
|}<br />
<br />
Color numbers 0–255 for terminal emulators compatible with xterm 256 colors can be found in the [https://upload.wikimedia.org/wikipedia/commons/1/15/Xterm_256color_chart.svg xterm-256color chart].<br />
<br />
With a correctly set TERM environment variable, the terminal's supported maximum number of colors can be found from the {{man|5|terminfo}} database using {{ic|echoti colors}}. In the case of [https://gist.github.com/XVilka/8346728 24-bit colors], also check the COLORTERM environment variable with {{ic|print $COLORTERM}}. If it returns {{ic|24bit}} or {{ic|truecolor}} then your terminal supports 16777216 (2<sup>24</sup>) colors even if terminfo shows a smaller number.<br />
<br />
{{Note|<br />
* The colors 0–15 may differ between terminal emulators and their used color schemes.<br />
* Many terminal emulators display bold with a brighter color.<br />
}}<br />
<br />
{{Tip|<br />
* Prompt escapes can be tested with command {{ic|print -P ''"prompt escapes"''}}, for example: {{bc|$ print -P '%B%F{red}co%F{green}lo%F{blue}rs%f%b'}}<br />
* If you use 24-bit colors, you might want to load the {{ic|zsh/nearcolor}} module in terminals that do not support them. E.g.: {{bc|<nowiki>[[ "$COLORTERM" == (24bit|truecolor) || "${terminfo[colors]}" -eq '16777216' ]] || zmodload zsh/nearcolor</nowiki>}} See {{man|1|zshmodules|THE ZSH/NEARCOLOR MODULE}} for details about the {{ic|zsh/nearcolor}} module.<br />
}}<br />
<br />
===== Example =====<br />
<br />
This is an example of a two-sided prompt:<br />
<br />
PROMPT='%F{green}%n%f@%F{magenta}%m%f %F{blue}%B%~%b%f %# '<br />
RPROMPT='[%F{yellow}%?%f]'<br />
<br />
And here is how it will be displayed:<br />
<br />
<div style="font-family: monospace; white-space: pre; padding: 1em; background-color: #000; border: 1px solid #bcd; color: #c0c0c0; overflow: hidden;"><span style="float:left;"><span style="color: #008000;">username</span>@<span style="color: #800080;">host</span> <span style="color: #0000ff;">~</span> % </span><span style="float:right;">[<span style="color: #808000;">0</span>]</span></div><br />
<br />
To use colors from the 16-255 range and 24-bit true color, you can use the number from 0 to 255 assigned to the wanted color and its hexadecimal color code, respectively:<br />
<br />
PROMPT='%F{2}%n%f@%F{5}%m%f %F{4}%B%~%b%f %# '<br />
RPROMPT='[%F{3}%?%f]'<br />
<br />
PROMPT='%F{#c0c0c0}%n%f@%F{#008000}%m%f %F{#800080}%B%~%b%f %# '<br />
RPROMPT='[%F{#0000ff}%?%f]'<br />
<br />
=== Sample .zshrc files ===<br />
<br />
* To get the same setup as the [https://archlinux.org/download/ monthly ISO releases] (which use Zsh by default), install {{Pkg|grml-zsh-config}}. It includes the many tweaks and advanced optimizations from [https://grml.org/zsh/ grml].<br />
* https://github.com/MrElendig/dotfiles-alice/blob/master/.zshrc - basic setup, with dynamic prompt and window title/hardinfo.<br />
* https://github.com/slashbeast/conf-mgmt/blob/master/roles/home_files/files/DOTzshrc - zshrc with multiple features, be sure to check out comments into it. Notable features: confirm function to ensure that user want to run poweroff, reboot or hibernate, support for GIT in prompt (done without vcsinfo), tab completion with menu, printing current executed command into window's title bar and more.<br />
<br />
See [[dotfiles#User repositories]] for more.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Autostart X at login ===<br />
<br />
See [[xinit#Autostart X at login]].<br />
<br />
=== Restore terminal settings after a program exits abnormally ===<br />
<br />
Many programs change the terminal state, and often do not restore terminal settings on exiting abnormally (e.g. when crashing or encountering SIGINT). <br />
<br />
This can typically be solved by executing {{man|1|reset}}:<br />
<br />
$ reset<br />
<br />
The following sections describe ways to avoid the need to manually reset the terminal.<br />
<br />
==== The ttyctl command ====<br />
<br />
The [http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-tty_002c-freezing ttyctl] command can be used to "freeze/unfreeze" the terminal. To freeze the interactive shell on launch, use the following:<br />
<br />
{{hc|~/.zshrc|<br />
ttyctl -f<br />
}}<br />
<br />
==== Resetting the terminal with escape sequences ====<br />
<br />
[https://www.in-ulm.de/~mascheck/various/alternate_charset/ Alternate linedrawing character set] can screw up the terminal in a way which ttyctl cannot prevent.<br />
<br />
A simple solution is to output the escape sequences that reset the terminal from the {{ic|precmd}} hook function, so that they are executed every time before the prompt is drawn. For example, using [https://www.in-ulm.de/~mascheck/various/alternate_charset/#solution the escape sequence] {{ic|\e[0m\e(B\e)0\017\e[?5l\e7\e[0;0r\e8}}:<br />
<br />
{{hc|~/.zshrc|2=<br />
<br />
autoload -Uz add-zsh-hook<br />
<br />
function reset_broken_terminal () {<br />
printf '%b' '\e[0m\e(B\e)0\017\e[?5l\e7\e[0;0r\e8'<br />
}<br />
<br />
add-zsh-hook -Uz precmd reset_broken_terminal<br />
}}<br />
<br />
To test if it works, run: <br />
<br />
$ print '\e(0\e)B'<br />
<br />
=== Remembering recent directories ===<br />
<br />
==== Dirstack ====<br />
<br />
Zsh can be configured to remember the DIRSTACKSIZE last visited folders. This can then be used to ''cd'' them very quickly. You need to add some lines to your configuration file:<br />
<br />
{{hc|~/.zshrc|<nowiki><br />
autoload -Uz add-zsh-hook<br />
<br />
DIRSTACKFILE="${XDG_CACHE_HOME:-$HOME/.cache}/zsh/dirs"<br />
if [[ -f "$DIRSTACKFILE" ]] && (( ${#dirstack} == 0 )); then<br />
dirstack=("${(@f)"$(< "$DIRSTACKFILE")"}")<br />
[[ -d "${dirstack[1]}" ]] && cd -- "${dirstack[1]}"<br />
fi<br />
chpwd_dirstack() {<br />
print -l -- "$PWD" "${(u)dirstack[@]}" > "$DIRSTACKFILE"<br />
}<br />
add-zsh-hook -Uz chpwd chpwd_dirstack<br />
<br />
DIRSTACKSIZE='20'<br />
<br />
setopt AUTO_PUSHD PUSHD_SILENT PUSHD_TO_HOME<br />
<br />
## Remove duplicate entries<br />
setopt PUSHD_IGNORE_DUPS<br />
<br />
## This reverts the +/- operators.<br />
setopt PUSHD_MINUS<br />
</nowiki>}}<br />
<br />
Now use<br />
<br />
$ dirs -v<br />
<br />
to print the dirstack. Use {{ic|cd -<NUM>}} to go back to a visited folder. Use autocompletion after the dash. This proves very handy if using the autocompletion menu.<br />
<br />
{{Note|This will not work if you have more than one ''zsh'' session open, and attempt to {{ic|cd}}, due to a conflict in both sessions writing to the same file.}}<br />
<br />
==== cdr ====<br />
<br />
cdr allows you to change the working directory to a previous working directory from a list maintained automatically. It stores all entries in files that are maintained across sessions and (by default) between terminal emulators in the current session.<br />
<br />
See {{man|1|zshcontrib|REMEMBERING RECENT DIRECTORIES}} for setup instructions.<br />
<br />
=== Help command ===<br />
<br />
Unlike [[Bash]], Zsh does not enable a built in {{ic|help}} command, instead it provides {{ic|run-help}}. By default {{ic|run-help}} is an alias to {{ic|man}}, it can be either executed manually by prepending it to a command or it can be invoked for the currently typed command with the keyboard shortcuts {{ic|Alt+h}} or {{ic|Esc}} {{ic|h}}.<br />
<br />
Since by default it is just an alias to [[man]], it will only work on external commands. To improve its functionality, so that it works on shell builtins and other shell features, you need to use the {{ic|run-help}} function. See {{man|1|zshcontrib}} for more information on the {{ic|run-help}} and its assistant functions.<br />
<br />
First load the {{ic|run-help}} function and then remove the existing {{ic|run-help}} alias. For convenience {{ic|help}} can be aliased to {{ic|run-help}}. For example, add following to your {{ic|zshrc}}:<br />
<br />
{{bc|1=<br />
autoload -Uz run-help<br />
unalias run-help<br />
alias help=run-help<br />
}}<br />
<br />
Assistant functions have to be enabled separately:<br />
<br />
autoload -Uz run-help-git run-help-ip run-help-openssl run-help-p4 run-help-sudo run-help-svk run-help-svn<br />
<br />
For example, {{ic|run-help git commit}} command will now open the [[man page]] {{man|1|git-commit}} instead of {{man|1|git}}.<br />
<br />
=== Persistent rehash ===<br />
<br />
Typically, compinit will not automatically find new executables in the {{ic|$PATH}}. For example, after you install a new package, the files in {{ic|/usr/bin/}} would not be immediately or automatically included in the completion. Thus, to have these new executables included, one would run:<br />
<br />
$ rehash<br />
<br />
This 'rehash' can be set to happen automatically.[https://github.com/robbyrussell/oh-my-zsh/issues/3440] Simply include the following in your {{ic|zshrc}}:<br />
<br />
{{hc|~/.zshrc|<br />
zstyle ':completion:*' rehash true<br />
}}<br />
<br />
==== On-demand rehash ====<br />
<br />
As above, however [[pacman]] can be configured with [[Pacman#Hooks|hooks]] to automatically request a {{ic|rehash}}, which does not incur the performance penalty of constant rehashing as above. To enable this, create the {{ic|/etc/pacman.d/hooks}} directory, and a {{ic|/var/cache/zsh}} directory, then create a hook file:<br />
<br />
{{hc|head=/etc/pacman.d/hooks/zsh.hook|output=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Type = Path<br />
Target = usr/bin/*<br />
[Action]<br />
Depends = zsh<br />
When = PostTransaction<br />
Exec = /usr/bin/install -Dm644 /dev/null /var/cache/zsh/pacman<br />
}}<br />
<br />
This keeps the modification date of the file {{ic|/var/cache/zsh/pacman}} consistent with the last time a package was installed, upgraded or removed. Then, {{ic|zsh}} must be coaxed into rehashing its own command cache when it goes out of date, by adding to your {{ic|~/.zshrc}}:<br />
<br />
{{hc|~/.zshrc|<nowiki><br />
zshcache_time="$(date +%s%N)"<br />
<br />
autoload -Uz add-zsh-hook<br />
<br />
rehash_precmd() {<br />
if [[ -a /var/cache/zsh/pacman ]]; then<br />
local paccache_time="$(date -r /var/cache/zsh/pacman +%s%N)"<br />
if (( zshcache_time < paccache_time )); then<br />
rehash<br />
zshcache_time="$paccache_time"<br />
fi<br />
fi<br />
}<br />
<br />
add-zsh-hook -Uz precmd rehash_precmd<br />
</nowiki>}}<br />
<br />
If the {{ic|precmd}} hook is triggered before {{ic|/var/cache/zsh/pacman}} is updated, completion may not work until a new prompt is initiated. Running an empty command, e.g. pressing {{ic|enter}}, should be sufficient.<br />
<br />
==== Alternative on-demand rehash using SIGUSR1 ====<br />
<br />
As above, however the hook file looks like this:<br />
<br />
{{hc|/etc/pacman.d/hooks/zsh-rehash.hook|output=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Type = Path<br />
Target = usr/bin/*<br />
<br />
[Action]<br />
Depends = zsh<br />
Depends = procps-ng<br />
When = PostTransaction<br />
Exec = /usr/bin/pkill zsh --signal=USR1<br />
}}<br />
<br />
{{Warning|This sends SIGUSR1 to all running {{ic|zsh}} instances. Note that the default behavior for SIGUSR1 is terminate so when you first configure this all running {{ic|zsh}} instances of all users (including login shells) will terminate if they have not sourced the trap below.}}<br />
<br />
{{hc|~/.zshrc|<br />
TRAPUSR1() { rehash }<br />
}}<br />
<br />
The ''function trap'' above can be replaced with a ''list trap'' {{ic|trap 'rehash' USR1}}. See {{man|1|zshmisc|Trap Functions}} for differences between types of traps.<br />
<br />
This method will instantly {{ic|rehash}} all {{ic|zsh}} instances, removing the need to press enter to trigger {{ic|precmd}}.<br />
<br />
=== Bind key to ncurses application ===<br />
<br />
Bind a ncurses application to a keystroke, but it will not accept interaction. Use {{ic|BUFFER}} variable to make it work. The following example lets users open [[ncmpcpp]] using {{ic|Alt+\}}:<br />
<br />
{{hc|~/.zshrc|2=<br />
ncmpcppShow() {<br />
BUFFER="ncmpcpp"<br />
zle accept-line<br />
}<br />
zle -N ncmpcppShow<br />
bindkey '^[\' ncmpcppShow<br />
}}<br />
<br />
An alternate method, that will keep everything you entered in the line before calling application:<br />
<br />
{{hc|~/.zshrc|2=<br />
ncmpcppShow() {<br />
ncmpcpp <$TTY<br />
zle redisplay<br />
}<br />
zle -N ncmpcppShow<br />
bindkey '^[\' ncmpcppShow<br />
}}<br />
<br />
=== File manager key binds ===<br />
<br />
Key binds like those used in graphic file managers may come handy. The first comes back in directory history ({{ic|Alt+Left}}), the second let the user go to the parent directory ({{ic|Alt+Up}}). They also display the directory content.<br />
<br />
{{hc|~/.zshrc|<nowiki><br />
cdUndoKey() {<br />
popd<br />
zle reset-prompt<br />
print<br />
ls<br />
zle reset-prompt<br />
}<br />
<br />
cdParentKey() {<br />
pushd ..<br />
zle reset-prompt<br />
print<br />
ls<br />
zle reset-prompt<br />
}<br />
<br />
zle -N cdParentKey<br />
zle -N cdUndoKey<br />
bindkey '^[[1;3A' cdParentKey<br />
bindkey '^[[1;3D' cdUndoKey<br />
</nowiki>}}<br />
<br />
=== xterm title ===<br />
<br />
If your terminal emulator supports it, you can set its title from Zsh. This allows dynamically changing the title to display relevant information about the shell state, for example showing the user name and current directory or the currently executing command.<br />
<br />
The xterm title is set with the [https://www.tldp.org/HOWTO/Xterm-Title-3.html#ss3.1 xterm escape sequence] {{ic|\e]2;}}{{ic|\a}}. For example:<br />
<br />
$ print -n '\e]2;My xterm title\a'<br />
<br />
will set the title to<br />
<br />
My xterm title<br />
<br />
A simple way to have a dynamic title is to set the title in the {{ic|precmd}} and {{ic|preexec}} hook functions. See {{man|1|zshmisc|Hook Functions}} for a list of available hook functions and their descriptions.<br />
<br />
By using {{ic|print -P}} you can additionally take advantage of Zsh's prompt escapes.<br />
<br />
{{Tip|<br />
* Title printing can be split up in multiple commands as long as they are sequential.<br />
* [[GNU Screen]] sends the xterm title to the hardstatus ({{ic|%h}}). If you want to use Screen's [https://www.gnu.org/software/screen/manual/html_node/String-Escapes.html string escapes] (e.g. for colors) you should set the hardstatus with the {{ic|\e_}}{{ic|\e\\}} escape sequence. Otherwise, if string escapes are used in {{ic|\e]2;}}{{ic|\a}}, the terminal emulator will get a garbled title due to it being incapable of interpreting Screen's string escapes.<br />
}}<br />
<br />
{{Note|<br />
* Do not use the {{ic|-P}} option of {{ic|print}} when printing variables to prevent them from being parsed as prompt escapes.<br />
* Use the {{ic|q}} [http://zsh.sourceforge.net/Doc/Release/Expansion.html#Parameter-Expansion-Flags parameter expansion flag] when printing variables to prevent them from being parsed as escape sequences.<br />
}}<br />
<br />
{{hc|~/.zshrc|<nowiki><br />
autoload -Uz add-zsh-hook<br />
<br />
function xterm_title_precmd () {<br />
print -Pn -- '\e]2;%n@%m %~\a'<br />
[[ "$TERM" == 'screen'* ]] && print -Pn -- '\e_\005{g}%n\005{-}@\005{m}%m\005{-} \005{B}%~\005{-}\e\\'<br />
}<br />
<br />
function xterm_title_preexec () {<br />
print -Pn -- '\e]2;%n@%m %~ %# ' && print -n -- "${(q)1}\a"<br />
[[ "$TERM" == 'screen'* ]] && { print -Pn -- '\e_\005{g}%n\005{-}@\005{m}%m\005{-} \005{B}%~\005{-} %# ' && print -n -- "${(q)1}\e\\"; }<br />
}<br />
<br />
if [[ "$TERM" == (alacritty*|gnome*|konsole*|putty*|rxvt*|screen*|tmux*|xterm*) ]]; then<br />
add-zsh-hook -Uz precmd xterm_title_precmd<br />
add-zsh-hook -Uz preexec xterm_title_preexec<br />
fi<br />
</nowiki>}}<br />
<br />
==== Terminal emulator tab title ====<br />
<br />
Some terminal emulators and multiplexers support setting the title of the tab. The escape sequences depend on the terminal:<br />
<br />
{| class="wikitable sortable"<br />
! Terminal<br />
! Escape sequences<br />
! Description<br />
|-<br />
! [[GNU Screen]]<br />
| {{ic|\ek}}{{ic|\e\\}}<br />
| Screen's window title ({{ic|%t}}).<br />
|-<br />
! Konsole<br />
| {{ic|\e]30;}}{{ic|\a}}<br />
| Konsole's tab title.<br />
|}<br />
<br />
=== Shell environment detection ===<br />
<br />
See [https://gitlab.com/jdorel-documentation/shell-environment-detection a repository about shell environment detection] for tests to detect the shell environment. This includes login/interactive shell, Xorg session, TTY and SSH session.<br />
<br />
=== /dev/tcp equivalent: ztcp ===<br />
<br />
Use the {{ic|zsh/net/tcp}} module:<br />
<br />
$ zmodload zsh/net/tcp<br />
<br />
You can now establish TCP connections:<br />
<br />
$ ztcp example.com 80<br />
<br />
=== Shortcut to exit shell on partial command line ===<br />
<br />
By default, {{ic|Ctrl+d}} will not close your shell if the command line is filled, this fixes it:<br />
<br />
{{hc|.zshrc|<br />
exit_zsh() { exit }<br />
zle -N exit_zsh<br />
bindkey '^D' exit_zsh<br />
}}<br />
<br />
== Third-party extensions ==<br />
<br />
=== Configuration frameworks ===<br />
{{Note|These frameworks introduce a level of abstraction and unnecessary complexity that can, and in the case of Oh-My-Zsh often does, lead to undefined behaviour. Install at your own risk, and in case of shell breakage, your ''first'' debugging step should be to revert to the plain shell.}}<br />
<br />
* {{App|oh-my-zsh|A popular, community-driven framework for managing your Zsh configuration. It comes bundled with a ton of helpful functions, helpers, plugins, themes.|https://github.com/ohmyzsh/ohmyzsh|{{AUR|oh-my-zsh-git}}}}<br />
* {{App|Prezto|A configuration framework for Zsh. It comes with modules, enriching the command line interface environment with sane defaults, aliases, functions, auto completion, and prompt themes.|https://github.com/sorin-ionescu/prezto|{{AUR|prezto-git}}}}<br />
* {{App|ZIM|A configuration framework with blazing speed and modular extensions. Zim is very easy to customize, and comes with a rich set of modules and features without compromising on speed or functionality.|https://github.com/zimfw/zimfw|{{AUR|zsh-zim-git}}}}<br />
<br />
=== Plugin managers ===<br />
<br />
* {{App|Antibody|A performance-focused plugin manager similar to Antigen.|https://github.com/getantibody/antibody|{{AUR|antibody}}}}<br />
* {{App|zinit (previously "zplugin")|Flexible Zsh plugin manager with clean fpath, reports, completion management, turbo mode|https://github.com/zdharma/zinit|{{AUR|zsh-zplugin-git}}}}<br />
* {{App|Antigen|A plugin manager for Zsh, inspired by oh-my-zsh and vundle. [https://github.com/zsh-users/antigen/issues/673 ABANDONED]|https://github.com/zsh-users/antigen|{{AUR|antigen-git}}}}<br />
* {{App|zgen|A lightweight and simple plugin manager for Zsh. [https://github.com/tarjoilija/zgen/issues/123 ABANDONED]|https://github.com/tarjoilija/zgen|{{AUR|zgen-git}}}}<br />
* {{App|zplug|A next-generation plugin manager for Zsh. [https://github.com/zplug/zplug/issues/403#issuecomment-477520784 ABANDONED]|https://github.com/zplug/zplug|{{AUR|zplug}}}}<br />
<br />
=== Fish-like syntax highlighting and autosuggestions ===<br />
<br />
[[Fish]] provides very powerful shell syntax highlighting and autosuggestions. To use both in Zsh, you can install {{pkg|zsh-syntax-highlighting}}, {{pkg|zsh-autosuggestions}}, and finally [[source]] one or both of the provided scripts from your zshrc:<br />
<br />
source /usr/share/zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh<br />
source /usr/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh<br />
<br />
=== The "command not found" handler ===<br />
<br />
{{Move|#Tips and tricks|The custom function using {{ic|pacman -F}} is not a "third-party extension". Only pkgfile stuff belongs in this section.}}<br />
<br />
[[pacman]] includes functionality to search for packages containing a file. The following command-not-found handler will use pacman directly to search for matching packages when an unknown command is executed.<br />
<br />
{{hc|1=~/.zshrc|2=<br />
command_not_found_handler() {<br />
local pkgs cmd="$1" files=()<br />
printf 'zsh: command not found: %s' "$cmd" # print command not found asap, then search for packages<br />
files=(${(f)"$(pacman -F --machinereadable -- "/usr/bin/${cmd}")"})<br />
if (( ${#files[@]} )); then<br />
printf '\r%s may be found in the following packages:\n' "$cmd"<br />
local res=() repo package version file<br />
for file in "$files[@]"; do<br />
res=("${(0)file}")<br />
repo="$res[1]"<br />
package="$res[2]"<br />
version="$res[3]"<br />
file="$res[4]"<br />
printf ' %s/%s %s: /%s\n' "$repo" "$package" "$version" "$file"<br />
done<br />
else<br />
printf '\n'<br />
fi<br />
return 127<br />
}<br />
}}<br />
<br />
{{Note|The files database of pacman is separate from the normal sync database and it needs to be fetched using {{ic|pacman -Fy}}. See [[pacman#Search for a package that contains a specific file]] for details.}}<br />
<br />
Alternatively, [[pkgfile]] includes a Zsh script file that provides a {{ic|command_not_found_handler}} function that will automatically search the pkgfile database when entering an unrecognized command.<br />
<br />
You need to [[source]] the script to enable it. For example:<br />
<br />
{{hc|~/.zshrc|<br />
source /usr/share/doc/pkgfile/command-not-found.zsh<br />
}}<br />
<br />
{{Note|The pkgfile database may need to be updated before this will work. See [[pkgfile#Installation]] for details.}}<br />
<br />
== Uninstallation ==<br />
<br />
Change the default shell before removing the {{Pkg|zsh}} package.<br />
<br />
{{Warning|Failure to follow the below procedure may result in users no longer having access to a working shell.}}<br />
<br />
Run following command:<br />
<br />
$ chsh -s /bin/bash ''user''<br />
<br />
Use it for every user with ''zsh'' set as their login shell (including root if needed). When completed, the {{Pkg|zsh}} package can be removed.<br />
<br />
Alternatively, change the default shell back to Bash by editing {{ic|/etc/passwd}} as root.<br />
<br />
{{Warning|It is strongly recommended to use {{man|8|vipw}} when editing {{ic|/etc/passwd}} as it helps prevent invalid entries and/or syntax errors.}}<br />
<br />
For example, change the following:<br />
<br />
''username'':x:1000:1000:''Full Name'',,,:/home/''username'':/bin/zsh<br />
<br />
To this:<br />
<br />
''username'':x:1000:1000:''Full Name'',,,:/home/''username'':/bin/bash<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:Zsh]]<br />
* [http://zsh.sourceforge.net/Intro/intro_toc.html An Introduction to the Z Shell]<br />
* [http://zsh.sourceforge.net/Guide/zshguide.html A User's Guide to ZSH]<br />
* [http://zsh.sourceforge.net/Doc/Release/index-frame.html The Z Shell Manual] (different format available [http://zsh.sourceforge.net/Doc/ here])<br />
* [http://zsh.sourceforge.net/FAQ/zshfaq01.html Zsh FAQ]<br />
* [http://zshwiki.org/home/ Zsh Wiki]<br />
* {{man|1|zsh-lovers}} (available as {{pkg|zsh-lovers}} package)<br />
* [[Gentoo: Zsh/Guide]]<br />
* [http://www.bash2zsh.com/zsh_refcard/refcard.pdf Bash2Zsh Reference Card]</div>Jasonwryanhttps://wiki.archlinux.org/index.php?title=Talk:Zsh&diff=654340Talk:Zsh2021-03-09T20:16:57Z<p>Jasonwryan: OMZ is harmful warning</p>
<hr />
<div>== Same directory in newly opened tab ==<br />
<br />
I had to append the following to my zshrc<br />
<br />
{{hc|~/.zshrc|<br />
<truncated><br />
. /etc/profile.d/vte.sh<br />
}}<br />
<br />
such that a newly opened tab opened in the previous working directory (using gnome-terminal). [[User:MrWhite|MrWhite]] ([[User talk:MrWhite|talk]]) 13:14, 5 November 2017 (UTC)<br />
<br />
== Warning about third party extensions (OMZ) ==<br />
The number of people that blindly install Oh-My-Zsh and then find some aspect of their shell broken is staggering. I propose a warning above this section noting that these tools introduce a huge amount of complexity and abstraction, which in many cases results in unexpected and unfortunate behaviours. Essentially, if you install these, expect breakage, and if you want support, your first debug step should be to remove them. -- [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 20:16, 9 March 2021 (UTC)</div>Jasonwryan