User talk:nl6720

From ArchWiki

Improving style on external github links

This might be a question better directed at the bureaucrats or site admins, but I'm curious as to your opinion on this as one of the most active maintainers of the site, and you seem to be particularly involved when it comes to link styling. According to Help:Editing#Links, "It is often more useful to give the link an alternative label rather than displaying the URL." (regarding external site links). However, I noticed that on any section that lists a number of applications, such as List of applications, virtually every single one of the external links uses the URL instead of an alternative label.

For sites that are specific to an individual application, I think it is appropriate to show the full url. However, for common sites that are used as a homepage for a number of applications, such as github repositories, it might be a better styling practice to set an alternative label like "github" or "github repository". Help:Editing#Links is not particularly strict on external links, but I personally think it would look significantly cleaner this way. Let me know what you think, I'd like to potentially bring this up with others as well. Also let me know if there's someone specific (such as a bureaucrat or admin that specializes in styling) I should discuss this with.

If the others are on board with this suggestion, I'd be more than willing to start applying this to a number of different pages. I think it would make for a good starter project for me to work on. As a long term aspiration of sorts, I am interested in prospect of eventually becoming a maintainer (I know that I have a long ways to go). I think it'd be a great way to improve my skills at technical documentation, while contributing to one of the most useful sites for linux documentation. -- Aeros167 (talk) 21:32, 9 June 2019 (UTC)Reply[reply]

The List of applications page uses Template:App, so you can propose changes in Template talk:App or Help talk:Style. Personally I don't agree to this change, I don't see a need to hide the URL by using a link title in Template:App. If the link was in a block of text, then I could agree to it, but not when specifically listing the URL. -- nl6720 (talk) 07:20, 10 June 2019 (UTC)Reply[reply]
Ah no problem, it was just an idea. If the current template is already well established with a fairly recent dedicated page, it will likely stay the same. I'll keep that in mind though for replacing the URL with the substitute if it's in a block of text, I find the text substitutions to be quite useful within those contexts especially. Are there any other frequently used Template pages that would be useful to be aware of? I checked Template (similar to how Help directs to all pages in the help category) but that seems to be a dead end. -- Aeros167 (talk) 09:40, 10 June 2019 (UTC)Reply[reply]
AFAIK templates are not categorized so you can find a list of them in Special:UncategorizedTemplates. A more useful list, separating them by usage, is available in Help:Template#List of templates. -- nl6720 (talk) 10:13, 10 June 2019 (UTC)Reply[reply]

Is there any reason why you chose to remove the note about ISO Image mode?

The note that says DD Image mode has to be used is not correct. ISO image mode will work for most people. You only need to use DD Image mode if the drive doesn't boot. Tonij (talk) 17:12, 2 August 2019 (UTC)Reply[reply]

DD Image mode writes the iso to the drive as it was intended by Arch developers while using ISO image mode means trusting that Rufus correctly copies the bootloader configuration. Any messing with the boot setup is bound to result in some incompatibilities, which is exactly what happens with the crap known as UNetbootin, luckily Rufus has not deteriorated to such extent. I restored Special:Diff/578638 in Special:Diff/578856. Frankly, I'm not a fan of Rufus since it keeps hiding useful features. [1][2] -- nl6720 (talk) 18:51, 2 August 2019 (UTC)Reply[reply]

Also if someone is using GPT, they never had any intention of booting in BIOS. What is the point of saying that they should use MBR in that situation? Tonij (talk) 17:22, 2 August 2019 (UTC)Reply[reply]

That's an unfounded claim. The installation media should be bootable for both BIOS and UEFI systems and that means using MBR in Rufus. Any other specialization is outside the scope of the USB flash installation media article. -- nl6720 (talk) 18:51, 2 August 2019 (UTC)Reply[reply]

Read this: Tonij (talk) 17:32, 2 August 2019 (UTC)Reply[reply]

dm-crypt/Encrypting an entire system

About the revert: Ok, thanks. I also had problems with some kind of "escape template-breaking characters" that I couldn't solve before you reverted very fast (so I was looking into changing something wrong with the link, but you very too fast). In the future, there will be a release where LUKS2 can be used... Then the wiki could be updated, I guess. I wasn't sure about how often people updated the wiki (and am not used to this, one time has to be the first), but it seems very frequently you guys update the wiki and thanks a lot for that. I also didn't remove the LUKS1-warning, because some people will use old versions for a long time. Thanks and I'll leave it here until we have a release and people begin using that new release with LUKS2-support (but then you or someone else probably updates the wiki before). Cheers! :-) Newsboost (talk) 17:51, 26 January 2020 (UTC)Reply[reply]

The template-breaking character issue was because of = in the Phoronix URL. Since the URL was in Template:Warning, normally you would need to escape it with e.g. {{Warning|1=text text []}}, but since it starts with a list, it becomes a little more annoying:
* list item
* list item []
Without <nowiki></nowiki> the first item would not get parsed as a list item.
About GRUB, when a new release with LUKS2 support lands in the stable repos, feel free to update the warnings (or remove them if GRUB miraculously gains Argon2 support), until then I think that the dm-crypt pages should retain the current warnings. I'm certain I'm not the only one with such opinion.
That said, this does not prevent you from editing GRUB#Encrypted /boot. Currently it does not give a clear solution for using LUKS2, but only hints about PBKDFs. It should be possible to use GRUB from git with LUKS2 created with the cryptsetup luksFormat --pbkdf pbkdf2, but I couldn't test it since grub-gitAUR didn't build for me when I tried it a few weeks ago.
Anyway, don't get discouraged from editing the wiki just because one of your edits was undone :)
-- nl6720 (talk) 07:11, 27 January 2020 (UTC)Reply[reply]
Yeah, frontend web-devel isn't really my thing, this template-breaking character stuff confused me a lot. So thanks a lot for explaining some details about this, I had major challenges "fixing" that broken template-stuff. About GRUB and LUKS2: I think I'll also skip the grub-git-method (I don't want to risk anything, but after a new release has been out for some weeks it'll be safer to test). I've been so unlucky for the past year that I for various reasons had to reinstall Arch Linux and therefore have been through the encrypted boot-procedure (too) many times recently. I takes me around 30 hours to fully setup an Arch Linux to my taste, incl. getting packages setup, window managers etc up and running so I hope I won't have to do it too many times again in year 2020 (this time I'll take an image with clonezilla and hopefully that can be used to save time in the future). I use luks1 for boot partition /boot, which after unlocking, unlocks my root-partition which is actually contained in a luks2-container with detached header and LVM inside. So I guess I'm not a normal user, anyway, maybe other people could use that procedure I've gathered and am using with the detached header... I'll watch out and hopefully soon I can use luks2 (and maybe detached header, e.g. on USB-stick) for the boot-partition. Once GRUB with LUKS2-support is stable, I'll see if I can contribute a bit about the detached header-setup, which I think is really nice. There are some details I'm not fully into, e.g. Argon2 and pbkdf2 but I'll see if I can contribute somewhere in the future, when something strikes my eyes. So I fully understand you, I think, this just serves as a bit of practice for me so I better know how things work the next time. Thanks a lot for your feedback, I'll have that in mind when I in the future browse and use the wiki! Newsboost (talk) 20:32, 27 January 2020 (UTC)Reply[reply]
Just in case you don't know, the setup for LUKS with a detached header is documented in dm-crypt/Specialties#Encrypted system using a detached LUKS header. -- nl6720 (talk) 10:26, 28 January 2020 (UTC)Reply[reply]
I'm not sure if I've seen that (can't remember). I usually have a folder with text-files that contain instructions for how to setup things and once I've done things a few times, that becomes my only source of "truth" or information (unless a new version of something causes unforeseen problems, in which case I try to solve it and update the instructions again till next time). That being said, I think the arch linux wiki is a great source and many of my own rewritten instructions are based on info from the wiki in some form (sometimes I extend things with detailed examples, I think the wiki isn't suited for that). I'll have in mind that if I notice something on the wiki that other users could benefit from, I'll see if I can contribute. I also copied your comment about the template-stuff to my own (+ a reference to the broken url), so I guess I can always easily find that info again, if something similar appears, i.e. I would then be less dependent on remembering where to find the this conversation)... Now I went through the process of editing here a few times, I think I'll feel more comfortable the next time, thanks :-) Newsboost (talk) 17:01, 28 January 2020 (UTC)Reply[reply]

F2FS warning

Hello, I see you reverted my F2FS warning. Fair point for the doc. I have this link [3] which gives a lot of details on what is going on. Basically, if you shut down your system improperly at the wrong time, F2FS will be corrupt beyond repair. Even fsck.f2fs will error out. I had found a weird, temporary fix allowing to mount the filesystem read only and even to allow the system to boot for a day or so. I've got a write-up (in French) about that on my blog ([4]) This has happened to several users before, and most smartphone manufacturers, Samsung itself included (they created F2FS), don't use it on their phones because of the stability issues. Do you think this data is sufficient? Aviallon (talk) 12:34, 25 September 2020 (UTC)Reply[reply]

I didn't doubt that the issue with F2FS is real. I've had my own issues with this file system (FS#63839) which made me switch to a different one. It's just that without any sort of reference that warning was fairly useless. Your links look good and there's even a kernel bugzilla link in you blog. If you can create a section in F2FS based on you blog post (adjusted for the wiki's style, of course) then it would be perfect :) -- nl6720 (talk) 13:23, 25 September 2020 (UTC)Reply[reply]
Understood! I will do that right away! Does that mean I should only put this information in Known Issues, and that I shouldn't put a warning like with Btrfs ? Aviallon (talk) 13:56, 25 September 2020 (UTC)Reply[reply]
You should definitely document your issue in "Known issues". Now whether it should be also linked from a warning in the intro, I'd say go by the consensus of Talk:F2FS#Adding warning about F2FS potentially being unsafe? -- nl6720 (talk) 14:05, 25 September 2020 (UTC)Reply[reply]

TPM/Data-at-rest encryption with LUKS

Hello, I'm curious about a recent edit you made to TPM#Data-at-rest_encryption_with_LUKS. I am the one who wrote the part that you edited, but I'm fine with most of your changes. The only thing I take issue with is the statement "This means that access to data is not protected in case the hardware gets stolen." This seems to imply that if the hardware is stolen, the data is as good as unencrypted. Given that full disk encryption is mostly useful in the case that the hardware is stolen, this implies that using a TPM to unlock your drive is as good as not encrypting it at all, which I don't think is fair to say.

Cold boot attacks, bus sniffing attacks, and other potential ways of circumventing a TPM are not trivial to perform, and are no comparison at all to the ease with which one can access an unencrypted drive. Furthermore, in the (admittedly unlikely) case where an attacker steals only the drive and not the entire computer, the fact that a TPM was set up to unlock the drive won't help them at all. Perhaps this could be changed to something like "This increases the number of options an attacker has to attempt to steal the data," or even "This makes the data significantly less secure."


Forgonewarrior (talk) 08:37, 10 April 2021 (UTC)Reply[reply]

By "hardware" I meant the whole PC not just the drive. If TPM automatically unlocks the the LUKS encrypted root volume on boot, then the thief just needs to power on the PC to get access to the data. So yes, it is almost as good as unencrypted. Getting passed user login is out of scope, and, while I can't think of a way to sidestep it, relying on it for data safety would be naive. See also -- nl6720 (talk) 08:46, 10 April 2021 (UTC)Reply[reply]

Konsole true color

I have seen your edit in Konsole. You changed TERM=konsole-256color to TERM=konsole-direct. I was the one who added that section.

It seems TERM=konsole-direct is broken. vim and nvim don't display correctly and vis simply segfaults.

But you were right TERM=konsole-256color is not for true color.

I think we should undo your last edit and change the section title from "True-color programs do not display correctly" to "Some color programs do not display correctly".

—This unsigned comment is by ENV25 (talk) 09:30, 17 April 2021 (UTC). Please sign your posts with ~~~~!Reply[reply]

From what I see, nvim with set termguicolors[5] looks the same with TERM=xterm-256color, TERM=konsole-256color and TERM=konsole-direct. -- nl6720 (talk) 13:25, 17 April 2021 (UTC)Reply[reply]

rEFInd Install Script

Hey there, I saw that you removed my edit in rEFInd about the config file location. You mentioned that the config file needs to be in esp (i.e. /boot) instead of esp/EFI/refind/. However, in my installation, placing the configuration file in esp resulted in the configuration file not being loaded. It only loaded when I moved it to esp/EFI/refind/.

According to The configuration file needs to be in the same directory as refind_x64.efi, which in my case (standard installation) was not in esp but esp/EFI/refind/.

Have I perhaps understood the phrasing in the Wikipage wrong? If not, I think a comment on the rEFInd page would be rather helpful for others.

Sunjerry019 (talk) 18:38, 11 Jan 2022 (UTC)

In Special:Diff/707347 you added text about refind.conf to the paragraph that talks about refind_linux.conf. I think you may be confusing the two files. refind.conf (the rEFInd configuration file) needs to be in the same directory as the rEFInd EFI binary (e.g. esp/EFI/rEFInd or esp/EFI/BOOT) and refind_linux.conf (the boot entry configuration file for autodetected kernels) needs to be in the same directory as the kernel(s) (typically /boot, unless you customized /usr/share/libalpm/scripts/mkinitcpio-install). -- nl6720 (talk) 11:30, 12 January 2022 (UTC)Reply[reply]
Ahhh okay yes I was confused between the two. Thanks for the clarification! -- Sunjerry019 (talk) 16:40, 12 Jan 2022 (UTC)

"By default only root can use sudo"

Hi, the title refers to this edit summary. Upon seeing it I was a bit stumped, but then I understood you meant that without any further configuration, sudo could only be used by the root user to change/run a command as another user, hence the change in sign. Is that it?

However, how common is that use case? It is really a thing that some people install sudo but don't configure a regular user account, instead use only root and sudo when they need to do something as another user? Even on a server I can't picture this being a really common case, so I'm a bit wondering about the change here. Sure it is factually correct, but still...

The only guideline I could find about it is Help:Style#Command line text and it is pretty ambivalent, stating "The only exception [to never using sudo with #] is when sudo is used with the -u flag: in this case the prompt can match the others of the same code block, or default to $". But here we have both in the preceding examples, and since it is exceedingly rare to see sudo used with a # I think it'd be better to just leave it at the $ that was used up until that point.

--Neitsab (talk) 22:37, 15 March 2022 (UTC)Reply[reply]

Yes, I meant sudo "without any further configuration" with that edit summary. And you're correct that it goes against Help:Style#Command line text. I've now undid that edit. Sorry about that! By being a bad example I've now tarnished the reputation of the monkey see monkey do wiki editor self-training program :( -- nl6720 (talk) 16:06, 16 March 2022 (UTC)Reply[reply]

"Excellent work"

Very good work on the mediawiki 1.37.2 update, thanks! 😎 (talk) 18:17, 9 April 2022 (UTC)Reply[reply]

Do you think using the AUR to install GNOME extensions is considered correct?

GNOME#Extensions has always been inconsistent, people keep making edits that contradict with each other. One of which is installing GNOME from the AUR. It works and it makes it easy to update when you're using an AUR helper, but a concrete answer is still needed so I could know what changes to make to the section. I already opened a discussion in Talk:GNOME (the discussion could get no spotlight, just like many others), but a word from a Wiki admin who knows all about this would be very appreciated.

Do you think using the AUR to install GNOME extensions is considered a correct way of doing so along with using Thanks! Cont999 (talk) 19:56, 20 September 2022 (UTC)Reply[reply]

Sorry, but I don't use GNOME. Never have, never will. -- nl6720 (talk) 13:30, 21 September 2022 (UTC)Reply[reply]

FAT32 partitions on 4K drives


Unsure why you reverted the note I copied over from Special:Diff/769994/770071 to Advanced Format.

I verified it in a VM and fdisk does fail with WARNING: Number of clusters for 32 bit FAT is less than the suggested minimum for partitions below 257Mb. [6]. --Cvlc (talk) 14:17, 6 March 2023 (UTC)Reply[reply]

There were a few things wrong. It's not the recommended minimum size, AFAIK it's a hard limit and it's not MB, but MiB. Also Advanced Format#File systems has nothing to do with partition size affecting which FAT you can use, it's out of scope there.
IMHO the FAT article would be the place for it, but it's too late once you're past partitioning and at the formatting step. I partially regret removing it from EFI system partition#Create the partition, but it had the same wording issues. And there already is a size recommendation in the page.
-- nl6720 (talk) 14:33, 6 March 2023 (UTC)Reply[reply]
OK. EFI system partition#Create the partition does indeed cover the case with a 300MiB minimum, but it doesn't really reflect that it's a hard limit. But it does link to the right places though so maybe that's enough.
-- Cvlc (talk) 14:56, 6 March 2023 (UTC)Reply[reply]
I thought about adding something like this:
Assuming 1 cluster per sector, matching the FAT cluster size to the drive's logical sector size and rounding up to MiB, it roughly translates to:
  • For 512 byte cluster size: FAT12 for partitions smaller than 2 MiB, FAT for partitions of 2 MiB to less than 32 MiB and FAT32 for partitions of 32 MiB and larger.
  • For 4096 byte cluster size: FAT12 for partitions smaller than 16 MiB, FAT for partitions of 16 MiB to less than 256 MiB and FAT32 for partitions of 256 MiB and larger.
But the issue is that those are the limits per specification, it doesn't account for the required file system metadata and etc.
Interestingly, according to, Microsoft's diskpart requires the partition to be 36 MiB for FAT32 on 512n/512e. This 4 MiB alignment looks similar to 256 MiB→260 MiB for the ESP on 4Kn and makes one wonder where does it come from.
-- nl6720 (talk) 15:10, 6 March 2023 (UTC)Reply[reply]
I like your edit ! --Cvlc (talk) 15:46, 6 March 2023 (UTC)Reply[reply]

About your edit on Reflector

Hi there, I noticed that you reverted my edit on that page. Would you mind elaborating? --Franklin Yu (talk) 00:57, 25 March 2023 (UTC)Reply[reply]

I reverted Special:Diff/773599 because "edit" redirects to "Systemd#Editing provided units" and I didn't see any need to avoid the redirect. It still leads to the exact same page and section. -- nl6720 (talk) 06:35, 25 March 2023 (UTC)Reply[reply]
Thanks! I didn’t know. I thought that it is about editing a file in general. --Franklin Yu (talk) 07:00, 25 March 2023 (UTC)Reply[reply]

Removal of a note on placing swap after boot/ESP

Hello. I noticed you reverted two of my edits:

Layouts offered in Partitioning#Example_layouts are, as far as I understand, examples. Not suggestions or requirements. It’s up to the administrator to decide the layout, isn’t it? And Arch Wiki is in this case offering help in making the decision. So the hint about the order, not expressed anywhere else in these articles, is IMO reasonable. It’s also not out of the blue: it’s triggered by the recent issues with the boot/ESP being too small.

Of course we may accept your line of reasoning, but in this spirit entire sections of this article should be deleted, because they discuss things either already in the examples or opposing examples.

Also: contrary to the revert reason for /boot, examples don’t even discuss a separate boot partition for MBR setup.

I ask for reconsidering the reverts. Both of them. The hint in ESP article was added, because dealing with ESP is a separate topic. The administrator is not expected to read the entire article on partitioning, when setting up ESP. --Mpan (talk) 09:00, 11 February 2024 (UTC)Reply[reply]

If you're partitioning, you rarely create only the ESP and no other partition. The creation of individual partitions (ESP or the /boot partition) does not concern other partitions on the table. That's why I said it's out of scope.
I don't feel like the hint in EFI system partition#Create the partition helped much. If it would instead say that you can sacrifice an adjacent swap partition to increase the ESP size, then I would see some value in it. But then you're also dealing with FAT resizing for which the wiki doesn't even have instructions. And gparted cannot even resize FAT partitions of certain sizes.
-- nl6720 (talk) 09:16, 11 February 2024 (UTC)Reply[reply]
My feeling is that a person reading the ESP article may be making choices about its size. Being aware of how the layout may be a factor is IMO relevant.
But, assuming otherwise, that would only explain the note being inappropiate in the ESP article. Not in the general partitioning article, which discusses both the /boot partition and ESP partition. I still believe that the note should be present at least in the partitioning article.
/boot doesn’t have to be FAT. I any case a filesystem that tiny doesn’t need to be resized either: it can be recreated. Resizing is relevant if size restrictions require the operation to be done in-place.
--Mpan (talk) 03:18, 12 February 2024 (UTC)Reply[reply]
I just don't see how these hints could help anyone. There's no way to know how the partition space recommendations/requirements will change in the future. If you suggest sacrificing the adjacent swap partition to enlarge the /boot partition, then you may end up without any swap partition (sure, there are alternatives, but those are not always feasible). -- nl6720 (talk) 12:46, 13 February 2024 (UTC)Reply[reply]
There is a way: knowing the past. The requirements will grow, likely at steady, slow rate. If I’m wrong on that, the worst outcome is: nothing happens. If I’m right, in the future users have a way to easily remedy the problem and support people have a ready answer to these asking for help.
The boot partition is much smaller than swap and the latter can be easily extended with devices/files placed anywhere. So there is no risk of running out of swap. Even if that was a risk, it’s still better than being unable to update system, because initramfs images do not fit. --Mpan (talk) 11:45, 15 February 2024 (UTC)Reply[reply]
I'd like to chime in to drop a suggestion: How about you (@Mpan) add a EFI system partition#Troubleshooting subsection for the case of initramfs creation/kernel update failing due to space limitations. In that it could explain how to create a new larger ESP and deploy it safely (switch esp), and integrate your tip to reuse an existing swap into it (e.g. in case there is no free space on the main drive). This would be safer, universal and needed anyway, because as nl6720 already said, extending FAT comes with its own caveats. --Indigo (talk) 14:54, 16 February 2024 (UTC)Reply[reply]
Indigo, I’ve already answered this above. I also don’t understand, why is this constantly diverging into tangential topics, which I’m expected to address, while the core subject is avoided.--Mpan (talk) 15:49, 17 February 2024 (UTC)Reply[reply]
The core issue being the hints about future-proofing the partition layout? Sorry, but I just don't find the hints very useful in the places they were added. There were no instructions to act on the suggestions, so all you got was a vague hint. -- nl6720 (talk) 16:24, 17 February 2024 (UTC)Reply[reply]
It’s already covered by the wiki--Mpan (talk) 17:38, 17 February 2024 (UTC)Reply[reply]
See, your tip can be generalised "If a separate swap partition is used, placing it in between other partitions may provide some margin if one of the adjacent partitions has to be resized later.", or phrased more specific "If an LVM and a separate swap partition are used, creating swap as an LVM logical volume offers most flexibility to reallocate space.". This just to emphasize again that there is no single best method to suggest (& users following the example layouts verbatim have it your way). Besides, it's contextually wrong to mention swap in the /boot subsection, when there is a separate subsection covering swap in the article anyway.
I still believe that (a) your intention would be better served with a EFI system partition#Troubleshooting item and (b) advising how to recreate a larger /boot and switch over is way safer than attempting a resize of the (unmounted yet) active one. I don't see what's tangential about that thought, and the more it can be crosslinked, the better. Give it another thought. --Indigo (talk) 22:20, 18 February 2024 (UTC)Reply[reply]