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)

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)
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)
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)

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

https://wiki.archlinux.org/index.php/USB_flash_installation_media#Using_Rufus

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)

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)

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)

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)

Read this: https://www.reddit.com/r/ManjaroLinux/comments/b5fzj4/make_sure_you_burned_the_iso_in_dd_mode/ejdcz9y?utm_source=share&utm_medium=web2x Tonij (talk) 17:32, 2 August 2019 (UTC)

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)

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 [https://www.phoronix.com/scan.php?page=news_item&px=GRUB-Boots-LUKS2-Disk-Encrypt]}}, but since it starts with a list, it becomes a little more annoying:
{{Warning|1=<nowiki></nowiki>
* list item
* list item [https://www.phoronix.com/scan.php?page=news_item&px=GRUB-Boots-LUKS2-Disk-Encrypt]
}}
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)
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)
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)
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 https://wiki.archlinux.org/index.php/User_talk:Newsboost (+ 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)

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)

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)
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)
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)

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."

Thoughts?

Forgonewarrior (talk) 08:37, 10 April 2021 (UTC)

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 https://github.com/systemd/systemd/issues/19229. -- nl6720 (talk) 08:46, 10 April 2021 (UTC)

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 ~~~~!

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)

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 https://www.rodsbooks.com/refind/configfile.html. 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)
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)

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)

"Excellent work"

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

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 extensions.gnome.org? Thanks! Cont999 (talk) 19:56, 20 September 2022 (UTC)

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