User talk:Lahwaacz

From ArchWiki
Jump to navigation Jump to search

bot checking links after move

Hi, re Talk:Touchpad Synaptics#adding libinput alternative. Touchpad Synaptics has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of Touchpad Synaptics and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --Indigo (talk) 07:36, 26 September 2015 (UTC)

Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a UUID page, which was later generalized and renamed to Persistent block device naming and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace [[pacman|Install]] with [[Install]] etc. -- Lahwaacz (talk) 08:01, 26 September 2015 (UTC)
Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [1]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --Indigo (talk) 10:02, 26 September 2015 (UTC)


Hi, about your revert: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- Nudin (talk) 11:33, 1 October 2017 (UTC)

Alright, how is the "more" relevant to systemd-nspawn though? -- Lahwaacz (talk) 17:30, 3 October 2017 (UTC)
Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- Nudin (talk) 22:23, 5 October 2017 (UTC)

Waking from suspend with USB device

Hi Lahwaacz, thanks for your input on this topic. Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [2]. In my case all the driver/*/power/wakeup are all enabled by default and the /proc/acpi/wakeup as well. Anyway I have added a step in my explanations to identify the path awaiting for more clarity.

Kewl (talk) 21:57, 16 January 2018 (UTC)

Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default:
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled
But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.
-- Lahwaacz (talk) 19:14, 19 January 2018 (UTC)

Are supported local/remote destinations important for choosing a backup program?

You reverted my edit adding supported backup destinations to Synchronization_and_backup_programs. This is puzzling to me. Here are some thoughts:

  • if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.
  • Given this, I am very puzzled you would use the term "useless" in the revert message.
  • I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"
  • On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.

Jernst (talk) 17:38, 11 June 2018 (UTC)

No because you can use any remote back-end with any backup application by just running one command / writing the backups to a FUSE (if available).--Larivact (talk) 04:39, 12 June 2018 (UTC)
Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? —This unsigned comment is by Jernst (talk) 18:08, 12 June 2018‎. Please sign your posts with ~~~~!
Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --Larivact (talk) 18:47, 12 June 2018 (UTC)
If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. Jernst (talk) 18:54, 12 June 2018 (UTC)

The pip section in Python package guidelines

Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – flying sheep 08:17, 8 March 2019 (UTC)

Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- Lahwaacz (talk) 19:21, 8 March 2019 (UTC)
That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – flying sheep 11:41, 11 March 2019 (UTC)
If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- Lahwaacz (talk) 13:26, 11 March 2019 (UTC)
Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?flying sheep


Regarding, one person ran into this problem in March of this year and spent too much time diagnosing it:

It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?


Pooryorick (talk) 08:24, 18 July 2019 (UTC)


Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't.

If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.

Eurydice (talk) 00:17, 8 September 2019 (UTC)

The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- Lahwaacz (talk) 06:29, 8 September 2019 (UTC)
You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) Eurydice (talk) 19:37, 8 September 2019 (UTC)
The root= parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. grub-mkconfig automatically detects the root filesystem and adds the appropriate root= parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- Lahwaacz (talk) 20:02, 8 September 2019 (UTC)
It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. Eurydice (talk) 05:38, 9 September 2019 (UTC)

dracut executable link

Hello, your last edit on the dracut page ( that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the executable link just points to the top of the Help:Reading page.

—This unsigned comment is by Krathalan (talk) 17:06, 28 January 2020‎. Please sign your posts with ~~~~!

In that case your browser probably does not work correctly, because the redirect really points to the section. Or MediaWiki, there was a bug several years ago... -- Lahwaacz (talk) 19:41, 28 January 2020 (UTC)
How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. Krathalan (talk) 19:51, 28 January 2020 (UTC)

Getting install.php work in DokuWiki

Hi, than you for having undone my contribution and pointed to the right solution on Dokuwiki#Configuration. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?

Also, I think that, at the end of this same section, one should add something like "verify that php-gd is installed and restart php-fpm.service".

Naturally I can do it myself, but I prefer to ask before. BDumont (talk) 17:31, 19 February 2020 (UTC)

Hi, apparently it depends on whether you had open_basedir set previously or not. I've changed the page, feel free to update the gd extension. -- Lahwaacz (talk) 21:16, 19 February 2020 (UTC)
Thank you! However, while, I didn't have open_basedir set previously, I couldn't access install.php. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is open_basedir. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. BDumont (talk) 08:20, 20 February 2020 (UTC)

Dead link in Simple stateful firewall#See Also

Hi, Jakub. I am about this edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- Duodai (talk) 14:29, 1 March 2020 (UTC)

Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- Lahwaacz (talk) 14:33, 1 March 2020 (UTC)
my guess is it returns captcha for crawlers only -- Ubone (talk) 01:59, 2 March 2020 (UTC)
I'm getting it in my browser... -- Lahwaacz (talk) 07:14, 2 March 2020 (UTC)

SystemD user units depending on graphical session

Hi, regarding reverting my addition to Systemd/User, could you please explain why? I referenced [[3]] which directly contradicts what you said in your summary.

—This unsigned comment is by Fuero (talk) 19:53, 5 May 2020‎. Please sign your posts with ~~~~!

The note in Systemd/User#How it works still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- Lahwaacz (talk) 12:45, 6 May 2020 (UTC)


Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in

The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master

—This unsigned comment is by M.Srikanth (talk) 09:50, 6 May 2020‎. Please sign your posts with ~~~~!

So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- Lahwaacz (talk) 12:15, 6 May 2020 (UTC)

[Bitcoin core] build the code and run the test suites


This week, I managed to build the Bitcoin code and run all the test suites with the help of this page:

Archlinux has two particularities:

  • being in rolling release, it takes to manually use the library Berkeley DB (BDB) v4.8
  • the /tmp directory is by default limited to half the size of the Ram

For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?



Thomasb (talk) 20:29, 9 May 2020 (UTC)

I don't think that this is useful. There is the bitcoin-core-gitAUR package and nothing more should be needed. -- Lahwaacz (talk) 16:53, 26 May 2020 (UTC)

Double linefeed results in extra line

If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.

It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.

Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.

-- Svito (talk) 16:30, 11 May 2020 (UTC)

If this is about [4], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- Lahwaacz (talk) 20:41, 11 May 2020 (UTC)
OFC, I mean the template page render has extra line. -- Svito (talk) 21:21, 11 May 2020 (UTC)
I agree with Svito, isn't it good to delete the extra blank lines? -- Blackteahamburger (talk) 05:39, 12 May 2020 (UTC)
OK, let's do it. [5] -- Lahwaacz (talk) 16:47, 26 May 2020 (UTC)

Re: lighttpd: remove python2 version

Instead of removing the example we could as well add an example using a Python3 library like

—This unsigned comment is by Gruentee (talk) 15:23, 18 May 2020‎. Please sign your posts with ~~~~!

Feel free to add it if you find it useful. -- Lahwaacz (talk) 20:56, 18 May 2020 (UTC)

Xbindkeys removal

Hi, just wondering why you removed my edit from Xbindkeys? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- Malvineous (talk) 02:27, 3 June 2020 (UTC)

Giving examples for all keys on the keyboard is useless, there is Xbindkeys#Identifying keycodes which teaches how to find the keycodes and keysyms of any key. -- Lahwaacz (talk) 06:37, 3 June 2020 (UTC)
So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- Malvineous (talk) 14:03, 4 June 2020 (UTC)
The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- Lahwaacz (talk) 15:15, 12 August 2020 (UTC)

Re: Revert for edit to XDG Base Directory page regarding python_history

I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually override the default behavior. Varriount (talk) 20:44, 20 June 2020 (UTC)

Even maven's note can be shortened. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- Lahwaacz (talk) 10:47, 12 August 2020 (UTC)

Re: Revert for Backlight page

Hi, you reverted my change to Backlight page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.

As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt Anarsoul (talk) 15:56, 30 June 2020 (UTC)

Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- Lahwaacz (talk) 10:32, 12 August 2020 (UTC)

Automatic template correction

Per Help:Template#Style, templates should be used with the capitalization shown in the examples in their pages, so {{AUR|... is correct, while {{aur|... is not.

However, there are pages that don't respect that rule (e.g. Android_Debug_Bridge until recently).

I beleive this correction should be easy to implement using a bot. What do you think?

—This unsigned comment is by Relrel (talk) 07:24, 25 August 2020‎. Please sign your posts with ~~~~!

Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a style linter for the ArchWiki rules. Would you like to help? ;-) – Lahwaacz (talk) 09:21, 25 August 2020 (UTC)

Failed to create tun device

I don't understand your reason for [removing my section in NetworkManager]. Could you elaborate?--Egils (talk) 07:40, 11 September 2020 (UTC)

You can't use systemd-networkd and NetworkManager at the same time. Even if you don't have any .network file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- Lahwaacz (talk) 07:43, 11 September 2020 (UTC)
Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--Egils (talk) 22:27, 11 September 2020 (UTC)
You should really fix the permission problem for networkmanager-openvpn. The tun interface should be managed by OpenVPN which needs rights to create it. -- Lahwaacz (talk) 06:37, 12 September 2020 (UTC)
I don't think this statement is entirely correct. systemd-networkd and NetworkManager can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use NetworkManager on my laptop to handle wifi, while systemd-networkd is in control of virtual ethernet and bridges for all my systemd-nspawn instances. Romstor (talk) 03:24, 12 September 2020 (UTC)

XDG Base Directory: Undo revision 636525

Dear Lahwaacz,

maybe my changes were to rushed and from my point of view only. But I have two points to consider:

  1. If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.
  2. The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.

Grrr (talk) 13:53, 26 September 2020 (UTC)

  1. Quotes are there because $XDG_CONFIG_HOME may contain spaces.
  2. It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.

-- Lahwaacz (talk) 14:22, 26 September 2020 (UTC)

Readability in Wiki

I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks. For example in the introduction of Wayland.

I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people. I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.

G3ro (talk) 14:38, 15 October 2020 (UTC) G3ro

I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- Lahwaacz (talk) 19:15, 15 October 2020 (UTC)
Well I guess it can be about both. But mainly it is about what people see on the page.
There are three seperate topics I mentioned:
1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.
While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.
2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.
3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.
G3ro (talk) 20:33, 15 October 2020 (UTC) G3ro
OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the <br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.
Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for Wayland, the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.
As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.
If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.
-- Lahwaacz (talk) 20:59, 15 October 2020 (UTC)

Xorg parentheses

I actually think that X(org) is very useful to imply that it is one and the same thing.

It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.

G3ro (talk) 13:30, 17 October 2020 (UTC) G3ro

Well the conventions should be established on the Xorg page, not anywhere else... -- Lahwaacz (talk) 13:36, 17 October 2020 (UTC)
Imo the conventions are established by upstream and they use a wide variety of X,, X(org), Xorg etc.
As I said I always prefer X(org) because then it is clear, that both are same thing.
But ultimately it's your decision.
G3ro (talk) 13:43, 17 October 2020 (UTC) G3ro
When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the Xorg page. But feel free to start a discussion about this in Talk:Xorg. -- Lahwaacz (talk) 13:56, 17 October 2020 (UTC)

SSHFS - systemd edit

The edit was removed because "there is no advantage over using fstab entries".

Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.

Reconsider the edit as it presents another option which people can use.

Garnica (talk) 16:22, 22 October 2020 (UTC)

There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: systemd.mount(5). But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- Lahwaacz (talk) 19:22, 22 October 2020 (UTC)
It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. Garnica (talk) 08:08, 24 October 2020 (UTC)
You can configure systemd targets in fstab using the x-systemd.wanted-by and x-systemd.required-by options, there are also nofail and noauto options. Please read the systemd.mount(5) manual.
Using hosts from the user's .ssh/config is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full user@hostname into fstab and you're done.
-- Lahwaacz (talk) 08:47, 24 October 2020 (UTC)

Self-encrypting drives

Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion

All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, Przemub (talk) 13:34, 28 October 2020 (UTC)

OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- Lahwaacz (talk) 14:27, 28 October 2020 (UTC)

Docker#Installation, reverted edit


About your reverted edit on the docker page, the first line of the installation section asks the user to verify operation :

Next start and enable docker.service and verify operation:
# docker info

Except that doing so results in the following :

# docker info
 Debug Mode: false

ERROR: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": dial unix /var/run/docker.sock: connect: permission denied
errors pretty printing info

the reason for which is only given at the end of the section, after talking about breakage from a simultaneous VPN connection... I know because it happened to me yesterday, and I had to go looking for what went wrong, except that everything was fine, which the output doesn't suggest. Which is why I suggest that the note at the end be brought up a couple of lines. Another option is to change "run docker info" to "run (as root) docker info"

Cvlc (talk) 22:33, 6 November 2020 (UTC)

The commands in the Docker#Installation section are supposed to be run as root, see Help:Reading#Regular user or root. Did you try to run them as an unprivileged user? -- Lahwaacz (talk) 23:38, 6 November 2020 (UTC)
Yup. I'd never noticed the #/$ difference, thanks for pointing that out ! -- Cvlc (talk) 01:36, 7 November 2020 (UTC)

Nvidia Installation

The whole guide is unnecessary long and overcomplicated formulated. Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.

G3ro (talk) 20:21, 10 November 2020 (UTC) G3ro

Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- Lahwaacz (talk) 20:36, 10 November 2020 (UTC)

Btrfs layout

Hi, Lahwaacz

Thanks for maintaining Snapper! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.

Cheers, I2Oc9 (talk) 07:26, 3 December 2020 (UTC)

It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in Snapper#Suggested filesystem layout. -- Lahwaacz (talk) 08:24, 3 December 2020 (UTC)
Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.I2Oc9 (talk) 09:02, 3 December 2020 (UTC)
Since last message I've extensively documented the new layout at User:I2Oc9/Btrfs_subvolumes and User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption. Have a look for yourself. Nothing new really, but IMO my take is much more simpler and complete than the supposedly simpler one. That one does not leverage native snapper rollback or grub-btrfs, among other things. I strongly suggest you try if you have time. I2Oc9 (talk) 11:55, 3 December 2020 (UTC)
Actually if you look closely, none of my recovery methods is specific to the new 'complex' layout, it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.
On the other hand, the layout recommendation has been updated by openSUSE [6], why stick with the old one? I2Oc9 (talk) 12:37, 3 December 2020 (UTC)
The main reasons why I reverted your edits on the Snapper page are: 1) it was a huge change which was not discussed previously as required by ArchWiki:Contributing#The 3 fundamental rules, and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in Talk:Snapper first. Your user pages would serve as great drafts.
Note that the current suggested layout is not flat in the sense of your section - it has a separate subvolume for .snapshots so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at /, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that the subvolume configuration must not be changed for rollbacks to work.
Now the openSUSE-specific elements: some Arch packages actually install software into /opt, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at /var/lib/pacman/local/ and it must be rolled back along with the system, so there should be no separate subvolume for /var. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under /var, such as /var/log, /var/tmp, /var/cache/pacman, /var/lib/machines, etc.
Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.
-- Lahwaacz (talk) 09:31, 4 December 2020 (UTC)
Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.
Yes, I get that the current layout is not the one described in this section and indeed properly separates /.snapshot and /. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.
As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted /boot on Btrfs on LUKS1, I really didn't think of any other possibilities.
I will incorporate your recommendations to my user page and add a new section in Talk:Snapper pointing to those pages.
Cheers -- S0x9v (talk) 10:09, 4 December 2020 (UTC)
I've adopted Archlinux Root on ZFS layout to my proposal. S0x9v (talk) 10:56, 4 December 2020 (UTC)

Reflector Revert

Hi Lahwaacz, about your revert, it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in dash#Relinking /bin/sh.

In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).


Denton-l (talk) 01:52, 7 December 2020 (UTC)

firefox zoom

"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work Ubone (talk) 02:38, 26 December 2020 (UTC)

That should be explained in HiDPI#Firefox anyway. -- Lahwaacz (talk) 10:48, 26 December 2020 (UTC)
it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" Ubone (talk) 15:51, 29 December 2020 (UTC)

Gitlab edits

I've made gitlab working it took me 2 days due to fact that gitlab article is outdated and misguided. 1. There is permission problem which been resolved in manner described, some how other options did not work. 2. I've put information about redis because it does not follow arch practise /run/<appname> and gitlab debugging is hard and time wasting.

Please revert changes because it makes article useless for newcomers.

—This unsigned comment is by Lukaszdh (talk) 09:30, 31 December 2020‎. Please sign your posts with ~~~~!

As I said in the edit summaries: the directories in /etc are already owned by gitlab bacause of how the packages are built - see the links to the PKGBUILDs. As for changing the ownership of files in /usr/share - that is simply nonsense, everything that gitlab needs to write should go to /var/lib/gitlab (and it is configured so by default).
GitLab#Redis links to Redis#Configuration which contains everything that is needed. The troubleshooting section is not a shortcut for missed configuration steps.
-- Lahwaacz (talk) 09:39, 31 December 2020 (UTC)
The setup gitlab by Your self and check if article is uptodate. I've set it up with 13.6.3-2 (current).
Lukaszdh (talk) 09:46, 31 December 2020 (UTC)
I see you're not interested in providing useful feedback, so this discussion won't get anywhere. Closing. -- Lahwaacz (talk) 09:56, 31 December 2020 (UTC)

Screen Capture formatting

First of all, sorry for the bad edit on this page, I'll try to better respect the conventions in the future

However I still think that the fact that some methods under Screen capture#Wayland#Screensharing works only on wlroots based compositor should be mentionned. I could try to refactor the entire section to something like

3 Wayland

3.1 Screensharing
3.1.1 Gnome Gnome screencast
3.1.2 Wlroot-based compositor Virtual webcam WebRTC

What do you think of it ?

Totally unrelated but how am I supposed to format such trees ? Using code blocks or as I did ?

Thanks for the time you are spending on this

Ocisra (talk) 09:06, 3 January 2021 (UTC)

Yes, I think indicating this in the section titles would be better. But 4 levels are probably too deep, it might be better to split the Wayland section into two top-level sections, e.g. "Screenshotting in Wayland" and "Screensharing in Wayland" or something like that. -- Lahwaacz (talk) 10:20, 3 January 2021 (UTC)
OK, I'm proposing something in the talk page for anyone to comment or suggest modifications on it and I'll refactor the Wayland part later this week -- Ocisra (talk) 10:44, 3 January 2021 (UTC)
Nice, thanks. -- Lahwaacz (talk) 12:37, 3 January 2021 (UTC)

Intel GVT-g edits

Hello Lahwaacz,

I have noticed that you reverted one of the edits I have performed on Intel_GVT-g.

About this revert: Windows problems are out of scope

While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.

Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.


Wilcomir (talk) 09:14, 3 January 2021 (UTC)

Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- Lahwaacz (talk) 10:34, 3 January 2021 (UTC)


Hello Lahwaacz, you have reverted my edit in the XBOOTLDR section on Systemd-boot.

It is true that XBOOTLDR is not part of the UEFI specification but systemd-boot relies on the UEFI implementation of the device to read the ESP and additional XBOOTLDR partitions. The UEFI provides the filesystem driver (typically VFAT) and loads/mounts partitions on boot. Some UEFI implementations do not load all VFAT partitions on a storage device during fastboot. systemd-boot then cannot find additional boot entries specified by with XBOOTLDR. For example my device (Lenovo T14 Gen 1) does this. I've seen other users with similiar issues: [7].

I think this is useful information, can we undo the revert? Thanks!

0xFelix (talk) 19:26, 7 January 2021 (UTC)

OK, I've added it back with a different/more general wording. -- Lahwaacz (talk) 08:02, 9 January 2021 (UTC)

XDG configuration for Vim

Hi Lahwaacz,

You have reverted the updated Notes for Vim on XDG Base Directory, because "copy-pasted from a blog post".

The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.

Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)

Jorengarenar (talk) 02:05, 12 January 2021 (UTC)

Categorization of Wayland Compositors related to Comparison of Tiling Window Managers edit

Hi, last Sunday, you edited the Comparison of tiling window mangers page removing all Wayland compositors from the list. I understand that Wayland compositors are not window managers. However, for instance the Sway wiki page is listed under the category of "tiling WMs" and Velox under the category "Dynamic WMs".

Would you support adding a new category:tiling Wayland compositors (which, admittedly, would be a very small category) or should we only be categorized as a graphical user interface and listed in Wayland#Tiling. Alternatively, Sway and Cagebreak could be left in the category "tiling WMs" since it is the closest categorization the wiki offers. In any case, I feel it would be useful to have a table or list giving an overview of the features of the different compositors/WMs. The benefit of having a single table for both compositors and WMs would be that more comparisons could be made and that the benefits/drawbacks of switching from Xorg to Wayland could be better assessed. Nevertheless, as you correctly pointed out, this would require a renaming/broadening of the category. What do you think? Do you propose a different course of action? Should I raise a discussion on the talk page of the article?

Project-repo (talk) 11:34, 19 January 2021 (UTC)

I think whatever new comparison should first appear on the Wayland page, so that people can see how it looks and discuss it on the talk page. When there is a comprehensive comparison of wayland compositors, it can be moved elsewhere (e.g. to a new page) if needed.
As for window managers vs Wayland compositors, I think they are two incomparable categories. Usually people choose either X or Wayland and then look for a suitable window manager or compositor. It makes sense to mention counterparts from the other category (like i3 and Sway), but Wayland compositors can't compete with window managers in any comparison and vice versa.
-- Lahwaacz (talk) 18:46, 19 January 2021 (UTC)
Thank you, I will think about useful comparisons of wayland compositors and discuss any such plans on the Wayland talk page. It is difficult for me to simply create an entire comparison because I don't have much experience with most of the wayland compositors.
Do you have any opinions regarding the wiki category for articles about wayland compositors like cagebreak or sway? They are currently categorized as tiling and dynamic WMs, which, as you pointed out, does not quite fit the WM part of the category. I tried to trace the tree of categories upwards and the first non-x-related category is "graphical user interfaces" which seems unreasonably broad. Alternatively, one might add new categories like wayland and wayland compositor.
Project-repo (talk) 19:54, 19 January 2021 (UTC)
You can use Template:Expansion to indicate that some section or table is incomplete. As for the categories, I'd either move the pages to Category:Graphical user interfaces or create a new category for Wayland compositors. -- Lahwaacz (talk) 20:15, 19 January 2021 (UTC)