User talk:Lahwaacz

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)

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)

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)

Root on ZFS draft

Hi, I submitted a Root on ZFS draft to official doc repo.

In the draft, the following directories are separated from root filesystem:

home,root,srv,usr/local,var/log,var/spool,var/tmp

Is this appropriate for Arch Linux? Or do you have any suggestion on the draft? Any comment is appreciated. M0p (talk) 01:28, 23 January 2021 (UTC)

Network configuration edit

Hello

You reversed my edit in the network configuration pages (https://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=next&oldid=788365) because you stated it was out of scope and tlsv1.0 is insecure

I disagree on the first part, many people I know, I first have struggled to configure eduroam on archlinux and this place seems the best fitted

On the second part, I agree tlsv1.0 is outdated and insecure, sadly it's the one used in some schools Ultraxime (talk) 17:11, 4 October 2023 (UTC)

VCS revert

https://wiki.archlinux.org/index.php?title=VCS_package_guidelines&diff=0&oldid=802958

While the VCS page isn't about AUR, I feel that the short Note about not bumping up pkgver needlessly is still a welcome addition to it, and additionally linking to the AUR policy is a fine crosslink.

C0rn3j (talk) 15:42, 11 March 2024 (UTC) C0rn3j (talk) 15:42, 11 March 2024 (UTC)

You can already link to the note in Arch User Repository#Flagging packages out-of-date. — Lahwaacz (talk) 16:58, 11 March 2024 (UTC)

That's exactly the note I linked, VCS package guidelines for AUR deserve such a footnote on this page.

Just today I went to link the VCS page to a friend confused about -git packages, only to again find out that's exactly the page that is missing any kind of mention about it.

Please reconsider. C0rn3j (talk) 11:58, 22 May 2024 (UTC)

You should just direct people to Arch User Repository#Flagging packages out-of-date. The VCS package guidelines page is not about the AUR out of date button and the upgrade process. — Lahwaacz (talk) 10:51, 22 June 2024 (UTC)

Install Arch Linux on a removable medium

Its not an edge case, there is still plenty of BIOS machines. Real edge case is a person who installs arch on USB stick :) it is not a general advice, please read it again carefully.

https://wiki.archlinux.org/index.php?title=Install_Arch_Linux_on_a_removable_medium&oldid=815197 Omeringen (talk) 16:14, 24 August 2024 (UTC)

Workaround to use suspend-then-hibernate with GNOME on lid close

You reverted my message stating 'systemctl suspend-then-hibernate works on GNOME'. (It's the last contribution on my user profile)

Of course you can run 'systemctl suspend-then-hibernate' but as I described, there is no way to trigger a suspend-then-hibernate from GNOME. I found a neat way to trigger this anyway and that's what I describe. I thought this trick would be of interest to other people so I thought about contributing and sharing it on the Arch Wiki. Do you disagree that this would be useful information. If so, why? Or might this be of interest on some other page? Starquake (talk) 13:48, 21 October 2024 (UTC)

What I meant is that you can run the systemctl suspend-then-hibernate command even on GNOME. If you are missing a graphical button somewhere, it can't be considered part of the "support in GNOME" and it is not really relevant on the Power management page. — Lahwaacz (talk) 12:41, 27 October 2024 (UTC)

Okay, thanks, I'll see if this would be useful to mention on some other page. Starquake (talk) 17:36, 27 October 2024 (UTC)

makepkg documentation update on correct usage git+http

""unmirroring" a git repository is not a thing" if you think so then please create PKGBUILD file with git+https://gitlab-ci-token:<token>@gitlab.com/project.git you will see immediately that "project" folder contains mirror because git.sh script is cloning with --mirror option. Next internal step after cloning is going to fail with message about its not git repository. To solve this issue you have to at [new_name]::git+http... to be clone from bare to normal mode. Reason why I love arch linux and use it since 2015 commercial is Wiki. Wiki should be up to date and this is my contribution. Please reconsider undo once more.

I literally hit the same problem while rebuilding my custom package and spend hour trying to figure out how to solve the problem which in my opinion should be covered by the Wiki.

https://unix.stackexchange.com/questions/154919/how-to-modify-a-pkgbuild-which-uses-git-sources-to-pull-only-a-shallow-clone Note: now /usr/share/makepkg/source/git.sh should be patched instead that one of popular answers. Lukaszdh (talk) 15:25, 24 November 2024 (UTC)

I cannot reproduce your issue and can't tell if the problem is about the [new_name]:: prefix or something else. There are definitely many existing packages that don't have the prefix and still work. Can you show your full PKGBUILD and the error output you are getting? — Lahwaacz (talk) 15:41, 24 November 2024 (UTC)

From obvious reason I can not share with you repository I've made sample repo which use same principal.

https://gitlab.guns4hire.cc/lukasz.busko/lahwaacz/-/blob/master/pkg/PKGBUILD?ref_type=heads

I was not able to reproduce the issue so it seems that it somehow it is gitlab issue.

The weird thing is that for actual project we are currently getting bare repo instead of normal one every time when attempt is to use PKGBUILD with out <what_ever_name>::. I will update this topic in a few days will try to redo production repo maybe it's gitlab issue after all. Lukaszdh (talk) 21:42, 24 November 2024 (UTC)

Well this repo works just fine for me: I could run makepkg with no issues so it is not a GitLab issue either. What is the version of the tools you are using? — Lahwaacz (talk) 21:53, 24 November 2024 (UTC)

Hey, sorry for delay was very busy. So at the end it looks like gitlab repository issue. When I add next origin for current local repository and then push and clone imagine problem does not exist anymore. Lukaszdh (talk) 23:07, 30 November 2024 (UTC)

Python packaging guidelines: Unpacking wheels

You removed the tip I added in the Python packaging guidelines regarding unpacking wheels, noting the packaging guidelines pages are to be modified by Package Maintainers only.

• I nonspecifically recall previously being advised to offer a more concrete edit for consideration, this was me overcorrecting in the other direction. To avoid a third reiteration, could you please explain what the expected editing procedure is for edits of this scale? I eg see no mention of such a PM-only policy in ArchWiki:Contributing or Help:Editing
• Accepting that my edit may have been against policy -- was there anything substantively wrong with my edit? Or was it merely removed because I had violated policy? In particular, what is blocking restoring it to the page?

Thanks, Gesh (talk) 19:39, 26 January 2025 (UTC)

Hi, the guidelines are supposed to be authoritative even for official packages so major changes need to be discussed and accepted by the team before adding them to the page. The talk page should be used for this purpose, you can draft the addition and have it reviewed by others. Even though your idea was probably not to change the direction of the guidelines, the wording should be much better to document the status quo without potentially arguable recommendations. You can find my view on this by reading the recent comments in Talk:Python package guidelines#Using virtualenvs for tests, doc generation. — Lahwaacz (talk) 21:08, 26 January 2025 (UTC)

SpiderOAK: Don't list date on app list

Hi, thank you for reverting the edit, as it was not what is usually done on that page. I had made that comment because people might consider SpiderOAK with the idea of it being save, private, and secure; but it seems to not be maintained anymore to say the least. Adding the latest-update-date was a way of indicating that the service might not be what it seems. I am fine with leaving the date out; I just wanted to explain why I had put it there.

—This unsigned comment is by Lquidfire (talk) 12:57, 22 February 2025 (UTC). Please sign your posts with ~~~~!

I see you've adopted the AUR package and added a pinned comment, which is the right way to do it. — Lahwaacz (talk) 12:23, 28 February 2025 (UTC)

Is "Don't start with a warning" a general rule?

On Btrfs regarding my last edit you corrected the positioning of the warning with the comment "Don't start with a warning".

Can I consider this a general rule of style or was your correction specific to that case? I'm asking because there are at least 7 other topics in the same article that start with a warning. Or should the positioning of the other warnings be altered too?

My reasoning was to put the warning at the top because the user should know before he tries out the deletion command.

No offense, I'm just trying to learn the style of the wiki. Multifred (talk) 23:43, 2 March 2025 (UTC)

It doesn't make much sense to expect the reader to know what the section is all about just from the title and jump right into a warning. So yeah, the other sections should be checked as well. — Lahwaacz (talk) 06:10, 3 March 2025 (UTC)

Rust packaging guidelines (trimming dependencies)

Thanks for taking the time to check my edit! I figured this was a common issue when packaging Rust programs, that is because Rust compile times are notoriously long and many repositories exist in the form of cargo workspaces (e.g., the limbo^AUR package requires ~60% less time to build with the trimming patch on my machine). Moreover, I've seen this in practice here and there because we don't need to bring in Windows-specific dependencies (see: this changelog on the rust-snapbox package in Ubuntu).

Maybe I can rephrase the section or put it in a more fitting wiki page. What do you think? Yetanotherarto (talk) 22:12, 9 March 2025 (UTC)

Arch packagers consider this an unnecessary maintenance burden. Needless features or components can be (or should be able to) disabled by cargo build flags and pruning Cargo.lock does not affect compile times, only download times.

Anyway, if you want to work on it, start a discussion an the talk page. AUR packages do not serve as a reference for official packages.

— Lahwaacz (talk) 06:19, 10 March 2025 (UTC)

You are right about compile times, that was a typo on my side. I'll open a discussion on the talk page. Thanks for now! Yetanotherarto (talk) 16:25, 10 March 2025 (UTC)

Write cache

Hi! Apologies to take up your time.

I'd like to clarify that my write-cache script is actually a scanner. While it tests and re-applies settings on a 30 second timescale, it's not expecting things to change anywhere that fast, and is meant to catch simple cases like suspensions, reboots, and new hardware additions, while not being intensively hooked into the system. I think it can be better, but this solves my own practical needs well enough, and I'm hoping that it serves as a launch point for the next person who comes along with the same issues as me.

Hope your day goes well! Ethel-Maxwell (talk) 04:35, 14 April 2025 (UTC)

Also, I apologize for modifying the factual accuracy warning myself. I should've left that up to your discretion and choice. Ethel-Maxwell (talk) 04:38, 14 April 2025 (UTC)

What I thought had gone on was that you'd tagged it because the code wasn't using systemd's specific boot and hibernate triggers within the unitfile. This got me defensive since I'd failed to get them working. What I realize now is that a casual reading of what I wrote and a glance at my code can definitely imply that it's just toggling write cache off once every 30 seconds.

Ethel-Maxwell (talk) 04:55, 14 April 2025 (UTC)

Morning-after reflections! (My apologies, I'm very introspective.)

So, to go through your points in detail:

• On applying the setting every 30 seconds; the goal is to catch occasional events within at most 30 seconds, rather than one event that re-asserts every 30 seconds.
• On applying settings during reboot -- that's already handled by the nature of being a systemd unit file.
• On applying settings during suspend, hibernate -- it is possible to convert the service back into a one-shot and set the unit file with some strict ordering regarding running after and around suspensions, but at the current time I can download a ready-made unit file off the internet and still not see any script re-ran after hibernation. (Ran into this with AMDGPU as well). This one is a proper matter of needing more dev time.
• On applying settings upon hardware additions, i.e. sata hotplug and USB keys, a udev rule can be written. This is a proper matter of needing more dev time.

All that said though, on the aspects of being better code, I do have to stand a bit by my inital assessment and say that since this isn't really a code-publishing platform and instead a launching off-point for system administrators ready to roll up the sleeves and get specific with their setup, I make the case that rather than tagging with a factual accuracy dispute (making most readers unwilling to engage with the section), the readers are better equipped with a warning that this is a jumping off point and may not be suitable for their case.

I do support the addition of a tag here in general. If the tag remains a factual accuracy tag though, I'm inclined to more simply remove the code to help the article be more readable for the general public.

Thank you for your time!

Ethel-Maxwell (talk) 00:32, 15 April 2025 (UTC)

Hello! I am writing again about your direct public tagging of the Hdparm article for a factual accuracy error. This is the third day I have woken up without a response, despite being active in the article, in its talk page, and on your user talk page here.

As it is, I have repeatedly made my case for why I find the tag inappropriate, and have repeatedly put in the effort to contact you and get this resolved. Five minutes of time is more than enough to review the three pages and my writings. If you don't follow up with me here, it is my understanding that you have no complaints with any action I've taken thus far, and I am justified in removing your tag with you being the one in error.

I apologize for the stern tone. See you tommorow when I sit down to check my wiki'ing.

I Ethel-Maxwell (talk) 02:11, 16 April 2025 (UTC)

Chill dude, not every editor checks and answers their talk page daily. From memory @Lahwaacz answers within a week. Erus Iluvatar (talk) 06:43, 16 April 2025 (UTC)

Are you willing to review the page in his stead to resolve this today then? I am here on this single issue. Ethel-Maxwell (talk) 23:47, 16 April 2025 (UTC)

Be patient. We are volunteers and no one here is getting paid, yet you act as if we were. NetSysFire (talk) 00:47, 17 April 2025 (UTC)

The accuracy template is intended to improve the content of the section, not to dissuade readers. That's why it is Template:Accuracy and not Template:Warning. Getting it right obviously means investing some time into explaining the motivation and improving the technical solution.

Before the technicalities, maybe you can explain why you want to keep the write cache absolutely disabled on your drives. Does it often fail or what is the concern? As a rule of thumb, the general recommendation is to keep the system on the defaults and trust the manufacturer and kernel programmers they know what they're doing. Modern file systems have a way to control when data actually gets written and to avoid data corruption (read about cache flushing and journaling). There is a warning in the section but I might dispute its accuracy/relevance too...

As for the script, I'd really not want a script to touch my drives every N seconds (whatever the N is). Besides the increased system load, it might also interfere with the disk's standby/suspend and potentially other functionality. hdparm is designed as a oneshot management command and running it in a loop is just weird. The right way to do it is to identify all events that reset the setting and apply the command just once after each event via oneshot service, udev rule, etc. If you don't want to do all of it, that's fine - the wiki can also just describe briefly what is the right way and leave the implementation as an exercise for the reader.

— Lahwaacz (talk) 20:30, 17 April 2025 (UTC)

Gotcha. Thank you for the reply, and I apologize for my impatience. (Up until I had several other users jumping in, I had no clue what kind of social system I was walking into here, and I was panicking and catastrophising. That's definitely on me, and I apologize for any email spam you received. My core stress being that I feared that this would be a factual accuracy tag that never resolves, like most I've seen on the wiki, and worrying that I made this page worse as a result.)

My use case is that I have three systems which can be hit by infrequent power-outtages, and I have tracked down and found corruption from the drive's internal write caching. It seems to interfere with any and all filesystem smarts, as a pretty simple write-reordering is more than enough to defeat the atomicity of filesystem operations no matter the underlying mechanisms that try and guarantee it (i.e. CoW filesystems and journaling), and I have quite a backlog of experiences of NTFS, Ext4, and Btrfs all corrupting during power loss despite never failing when hitting the machine's reset button.

This section on this article is thus far the simplest solution I have found and the only one that does not require me to put money down on excess hardware, and I'm very willing to dig my own grave, vary from manufacturer defaults, and trade performance for system consistency and ease of maintennance. For anybody interested in what other resources I turned up, my next strategy from here has been considering the use of an overlay filesystem or Btrfs seeding (https://btrfs.readthedocs.io/en/stable/Seeding-device.html) to try and aid in system repairability, but these mechanisms have no power of prevention.

My workload is read-heavy in every single case, with writes primarily consisting of simple everyday logging, system management, and the ordinary sprawl of user programs making caches as they run, etc. One such system is for example an SMBv1 share for a dedicated offline network of legacy machines, providing a bulk of large system images so they don't have to be stored locally. Disabling write caching with this script has had no effect on the sustained throughput of my disks when writing new large chunks, or their read performance, and a properly set I/O scheduler has had a much larger effect on system usability than the state of the disk's write cache.

I agree that most people aren't doing this, that nobody should run this script on there system without knowing the trade-offs they are making. This is not a usual and default use-case, but this is just about the only place where this is documented, with straightforward warnings already existing and stressing what kind of a decision this is.

As for the quality of the script itself -- when it comes to overhead, I have some relevant benchmark figures on the performance of 'hdparm -W /path/to/disk':

• in a loop running hdparm -t on a Crucial MX500 disk with nothing else ran, the read throughput is 342 MB/sec. For a Western Digital WD 8TB, the performance is 179MB/s.
• starting a loop of 30,000 hdparm -W (only probing the write cache state, not setting it) operations with zero read timers while the above runs, the read throughput is 317 MB/sec for the SSD, and 177 MB/S for the hard disk. The loops finish in 1m18s for both the SSD and the hard-disk, giving a runtime of 2 milliseconds.
• starting a loop of 30,000 hdparm -W1 or -W0 operations, the read throughput drops to 230MB/sec on the SSD, and 80MB/sec for the hard-disk. The loop takes 10 minutes to complete, giving a runtime of 20 milliseconds.
• in both cases, system usability did not tank, though this might have more to do with the I/O scheduler and Linux's own disk caching.

As such, running one probing hdparm -W command once per 30 seconds on disk uses an estimated 0.06% of the drive's bus time, and there isn't much to worry about in terms of polling overhead.

That said, I do agree that the code isn't the point. I'm very open to wherever you want to take this section.

Apologies again for the panicking and taking up your time!

I Ethel-Maxwell (talk) 03:54, 18 April 2025 (UTC)

Ok, so the warning in that section must stay. I don't want to tell you what to do with your drives, but still it would be nice to at least mention how to proceed if the user wants to run the action only after specific event that resets the setting. Something like "For resets after suspend/hibernation, see Power management/Suspend and hibernate#Sleep hooks" etc. For this it would be good to decouple the action from the loop in the script so that it can be used in different ways. — Lahwaacz (talk) 08:24, 27 April 2025 (UTC)

The thing I think I've failed to communicate here is that the action inside of its loop and the implications making it up have always been spelled out in individual commands, plain english instructions, and textual warnings all in the existing text of the section, long before I ever touched it. Spotlighting out the inner loop would be very redundant, because that text is a better explanation. This is why I argue that if you dislike the loop, it should be removed. I don't have working code that makes it run on events. Yes it would be nice if I did. But I don't see what makes the section factually innacurate if it's correct but a nicer solution could exist.

I now argue that the code be removed, because I do not have time from my day to argue for it. We're caught in the weeds in useless semantics and that's all this code has done, so please remove it, because it's never going to outdo this unproductivity bubble of already wasted time. Ethel-Maxwell (talk) 22:35, 28 April 2025 (UTC)

I want to stress that all I've done is combine existing wiki content and extended it the simplest step forward I could come up with. I did it because I thought it was a non-obvious but very straightforward synthesis of two pages, justifiable by the existing text of the section, already asking that the user be aware and have technical reasons to want to be doing this. But it's too many days and too many emails later, and we're still on the same initial point that you just like the nicer solution that doesn't yet exist. I'm stepping out from this conversation and I'm not returning. Ethel-Maxwell (talk) 22:46, 28 April 2025 (UTC)

Other wlroots based compositors edit

as it stands, you need xdg-portal-gtk to be able to screenshare in other wlroots based compositors ie dwl with out it you can't screenshare, speaking as someone who used a wlroots based compositors you need that, I can't speak for other wlroots based compositors ie river but for me I needed xdg-portal-gtk to be able to screenshare Matthewq337 (talk)

There is a table in XDG Desktop Portal#List of backends and interfaces

Which other portal from xdg-desktop-portal-gtk do you need for screensharing? As it is documented now, it seems completely unrelated to this functionality.

Rename the user

Hello Lahwaacz.👋 Can you please rename my user to Kycko? I want to sync it with my other accounts (GitHub, AUR etc.).

Will there be any problems if we do this? -- Kycok (talk) 18:56, 1 June 2025 (UTC)

Hi, I'm sorry that I did not respond before 🙏 I see that somebody has already renamed your account, so I'm closing this. — Lahwaacz (talk) 17:53, 15 June 2025 (UTC)

Regarding Core Dump undo

Hi. The fact that "you" think "this is not necessary" when i've edited the page to also describe how to get core dump files back is... Well, that's just arrogant. You agree, you disagree or anywhere in between, that's all perfectly fine. But for me finding out how to restore said functionality took many hours! Having it be described on the arch wiki, the golden standard these days for how to do things in linux, is a good thing to have. Mindlessly reverting it because you think it's not useful is so darned disrespectful to me in this case. I can imagine that you might frown upon where i made that edit (top of the page) which seemed to make sense for me as a developer. If you want to change it, reword it, reposition it, all great and constructive! But just removing it with that opinion, yeah that's hitting a nerve. Markg85 (talk) 12:35, 13 September 2025 (UTC)