XDG Base Directory
Proposition to add 'Organize user configuration' section in 'System maintenance' and make more obvious reference to 'XDG Base Directory support' and 'Dotfiles#Version control'
Of course I agree that there shouldn't be a detailed explanation here, however I think it's also true that currently it's not very easy to reach XDG Base Directory support through links from this article: I think the best path is only from a link in System maintenance#Old configuration files, which is a too specific section. What if we add a new, more explicit section in System maintenance (maybe only under System_maintenance#Tips_and_tricks?) like this:
Organize user configuration
Many applications store user-specific data, such as configuration files, inside the
$HOME folder: in order to facilitate maintenance it is important to organize those files in a rational and easily-accessible way. See XDG Base Directory support for the most commonly followed standard; see Dotfiles#Version control for common helper tools.
- That sounds good, but it'd be even better as part of a larger Backup section, with amongst others a link to Synchronization_and_backup_programs. -- Alad (talk) 19:42, 21 September 2016 (UTC)
- But System_maintenance#Backup already links to Synchronization_and_backup_programs, or were you talking about adding a Backup section to this very article?
- Instead, I propose to:
- Rename System_maintenance#Clean_the_filesystem to #Tidy_up_the_file_systems;
- Rename System_maintenance#Old_configuration_files to #Organize_configuration_files;
- Merge my section above into #Organize_configuration_files;
- Merge the link to Dotfiles#Version control inside System_maintenance#Configuration_files.
- — Kynikos (talk) 11:19, 22 September 2016 (UTC)
Proposition to add a section about how to fix problems when you bork your system
I saw on a recent thread on the ArchLinux subreddit that a lot of people had managed to bork there system. One thing I noticed on this thread was the overwhelming amount of people that ended up reinstalling for what would be a simple to solve problem. The most common issues were accidental rm -rf's and messing up the partition table. What I would like to propose is a section, in an area that would be read by a lot of people, that would go over basic steps to recover simple problems (there is already an article on file recovery, but most people assume they have borked their system before actually checking. Hence why I would like it in a place where a lot of people will see it). An example is that people can fix most file deletion and partition table recoveries using testdisk
- We already have Category:System recovery especially featuring General troubleshooting, I think you may want to propose expanding that article in Talk:General troubleshooting.
- Since you put this discussion here though, I'll just say that this article is not the place for troubleshooting tips: in general, we organize content to group information on the same topic together, we don't try to "bundle" topics with others just to increase their visibility.
- -- Kynikos (talk) 00:16, 23 July 2020 (UTC)
Proposition to encourage users to disable systemd's less than predictable network interface names
The vast majority of users does not benefit from this behavior in any way, shape or form.
They'll have one wired and on wifi NIC - and it is far easier to memorize and handle eth0 and wlan0 than enp123s4p56 and wlu123p456s789 On the other hand, not only chosing a different slot for a wifi dongle, but also unrelated hardware changes or BIOS updates can alter the "predictable" names any time and break the network setup. On top of that it's also prone to race conditions: If the NIC is already in use when systemd tries to rename it, the renaming fails what makes the renaming itself unpredictable, let alone the interface name.
This constantly comes up as help requests in the forum by confused users and then everyone's (rightfully) bitching around that this is a dumb feature - certainly as default behavior. So, ideally users following the installation guide and general recommendations would be made aware of this right ahead instead of running into it.
- The wiki documents the default behaviour, it does not enforce it. If you want to change the default, ask systemd. There is nothing for us to do – the Installation guide already links to Network configuration#Network interfaces which contains a tip on changing interface names. — Lahwaacz (talk) 10:28, 1 January 2022 (UTC)
- Nobody enforces anything. The page is about general recommendations on what you might want to do after the basic installation to improve the system.
- Not sure wheter "ask systemd" was a serious advice…
- Lennart and Kay don't make mistakes, they just expose that the entire rest of the world is too dumb to understand that they're always right by default.
- (and that's not nearly all you can get when googling "systemd predictable bug")
- This page is about general recommendations, not specific warnings about potential problems that users might or might not face long time in the future. Take General recommendations#Package management for example, it says to read the pacman page without even mentioning partial upgrades... The network configuration is pointed out in a similar way in the Installation guide#Network configuration itself, which is much sooner than users will get to this page.
- > But I'm fine with keeping bitching about it. – I respect how you like to spend your free time, but don't do it on this wiki. Closing.
- — Lahwaacz (talk) 13:49, 1 January 2022 (UTC)
- We use VMs at work, on which systemd changes the interface names at boot. (Debian though.)
- One VM has about 10 interfaces (a load balancer which is exposed to the internet on two ports) - we have had recently the issue,
- that at least two network interfaces have been renamed to "renameXY" and the network config didn't match (I suggested to switch to systemd-networkd + Match on MAC because of this).
- This is really troublesome, this is not a "stable" interface naming for me anymore and I also consider to disable this. Loader009 (talk) 13:58, 1 January 2022 (UTC)