User talk:Waldo Lemmer

From Gentoo Wiki
(Redirected from User talk:Glibg10b)
Jump to:navigation Jump to:search
Note
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (~~~~), and indent successive comments with colons (:). Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.

SELinux/Installation

Talk status
This discussion is done as of 2024-04-11.

May I ask why you undid the changes made by WavyEbuilder? --Lars Hint (talk) 06:54, 11 April 2024 (UTC)

I don't know how that happened. I undid my undo. Thanks for alerting me — Waldo Lemmer 07:10, 11 April 2024 (UTC)
Looks like I didn't undo my undo. There seem to be conflicts. I'll try to do it manually. — Waldo Lemmer 07:14, 11 April 2024 (UTC)
Could you double-check that everything looks fine now? — Waldo Lemmer 07:27, 11 April 2024 (UTC)
Everything seems to be okay now. ^_^ --Lars Hint (talk) 07:47, 11 April 2024 (UTC)

Double redirects

Talk status
This discussion is done as of 2024-04-21.

Answering to your question: If you open the page and click "Tools" (top right menu, next to notifications) -> "What links here", you will see all the references to that page. However, some pages that are not directly linked to will also be shown. This is due to Template:See also. If there is a link in the description of a page mentioned in "See also", that page will be displayed. This leads to another problem: if you fix a problematic page, "See also" is not updated automatically, but uses a cached value, so every page that links to the problematic page has to be updated somehow. Help:Redirects#Double_redirects also suggests using Special:DoubleRedirects, but this special page does not work as expected, almost all types of double redirects are not shown there. --Lars Hint (talk) 10:01, 21 April 2024 (UTC)

The technical aspects (and limitations) of MediaWiki are interesting to me, so thanks for this info. Just yesterday I discovered a template loop that caused a portion of a page to repeat itself 22 times (Special:Diff/1293610).
But if Special:DoubleRedirects doesn't work properly (which I'm curious to know why), then how do you find double redirects?
By the way, I've experienced this "caching" first-hand. My self-hosted wiki transcludes Special:RecentChanges from this wiki, but it only updates when I add an edit.
— 10:44, 21 April 2024 (UTC)
Oh, I see. "What links here" shows double redirects in the form of nested lists. I'll be sure to fix these when I spot them.
Waldo Lemmer 10:51, 21 April 2024 (UTC)
Yes, they are nested, as in this example: Special:WhatLinksHere/Embedded_Handbook/Boards/Hammer_Board_and_Nail_Board: The page User:Ris/link_audit/broken_links refers to the page using a double redirect, so User:Ris/link_audit/broken_links needs to be fixed. So every time a page is opened, it is necessary to manually check which links lead to it. It's amazing, right? MediaWiki has made a lot of great design decisions, so no one wants to use the wiki and contribute here. I'm mostly frustrated with the categories. It would be much easier and more intuitive if it were possible to filter results by category. For example, a laptop page could belong to the categories "Laptops" and "Lenovo", and filtering category "Lenovo Laptops" could only show pages belonging to the "Laptops" category that at the same time belong to "Lenovo". But no, that's too easy, better to force us create tons of workaround categories. --Lars Hint (talk) 11:16, 21 April 2024 (UTC)
Yes, categories would make for the perfect tagging system. Pages can already include multiple categories at once. It's a shame they don't let you use them as tags, and for some reason intend for them to be used in a hierarchy (i.e. "Laptops" should not include "Thinkpad P50", but should instead include it indirectly through "Lenovo Laptops").
Imagine if we could see a list of all laptops on the wiki. With everything arranged in a hierarchy, that's currently not possible without external software.
Waldo Lemmer 11:40, 21 April 2024 (UTC)
Initially all laptops were in the "Laptops" category, until I sorted them by company. There were some problems with the original structure: some pages belong to userspaces, causing alphabetical ordering to be broken (caused duplicate pages); some pages did not have a company prefix (with the new structure this problem is completely fixed); some laptops were sold by different companies until these companies were merged with others (e.g. IBM ThinkPad T42); laptop-related pages were mixed with laptop pages, creating a mess; people rarely used blueprints. The same problems exist in Category:Embedded systems. I tried to make Category:Boards, but I'm so frustrated I don't want to continue. Some of the devices out there are not even boards, but something else. If Gentoo is installed on a router, for example, and used as a PC, the router is no longer a router, but a board. That doesn't make sense. And what about single board computers? Aren't they desktop computers? The line between a motherboard and just a board is also implicit. What to do with company names? Some of them no longer exist or have been rebranded. I think I understand why Matthew Marchese (maffblaster) gave up on the Embedded Handbook. There's a bunch of duplicate articles out there, especially on the Raspberry Pi, all because of poor organization. Or even because of conflicts between authors. --Lars Hint (talk) 13:08, 21 April 2024 (UTC)

If Gentoo is installed on a router, for example, and used as a PC, the router is no longer a router, but a board. That doesn't make sense. And what about single board computers? Aren't they desktop computers? The line between a motherboard and just a board is also implicit. What to do with company names? Some of them no longer exist or have been rebranded.

This does not sound like a problem you should face alone. Questions like these need discussion. Have you tried talk pages?
If that's not working, and if you'd like, you could take one question at a time to #gentoo-wiki (webchat). We (me, and all other active users on that channel) love the work that you do, so I'm sure people would love to have those discussions with you.
Waldo Lemmer 13:28, 21 April 2024 (UTC)
I tried to talk to M. Marchese (the attempt), but got no response, and after a month of waiting I realized that if you need something, do it yourself. I'm also skeptical of talking because people here are starting to ignore me for some reason (example). Or even respond in a rude manner, even if they are wrong ( example). I've also seen a lot of old closed aggressive conversations here (not towards me). --Lars Hint (talk) 14:00, 21 April 2024 (UTC)
Regarding your first point: Yeah, that's the main weakness of talk pages — nothing's stopping people from ignoring you. However, since IRC basically forces people to respond (because starting a new conversation would be a blatantly rude act and visible to everyone), and because the people who appreciate your work the most (the admins) are the most active members, I think you'll feel welcome and heard there.
Waldo Lemmer 14:39, 21 April 2024 (UTC)

Category templates

Talk status
This discussion is done.

Hello, Waldo! I still can't stop thinking about your words that categories in their current form are not predictable. If looking at a list of all the categories, it's obvious that everyone names the categories whatever they want. Some use capitalization in every word, some don't. This resulted in duplicate categories (e.g. Category:Embedded systems and Category:Embedded Systems). And as I see it, such duplicates are always resolved in favor of using lowercase characters in words. So the question is, do all categories that don't follow this convention need to be renamed? Unfortunately, I've created tons of these categories (as you know). The reason for this was a pre-existing category that used the wrong convention: Category:Brother Printers. Wikipedia also uses lowercase (example: Lenovo laptops). So what do you think about it? --Lars Hint (talk) 13:12, 26 April 2024 (UTC)

Lowercase should be preferred, since that's the convention we use for article titles[1].
As you most certainly know, categories don't work through redirects, so it's not as simple as moving Category:Embedded Systems to Category:Embedded systems; pages need to be moved individually. But moving pages to the correct category is pretty time consuming for little benefit.
I instead suggest transferring the badly named category page's categories to the well-named category page, then making the badly named page a sub-category of the well-named page. This ensures that Special:Ask works correctly, but also means that we don't have to move all members of the category at once — new contributors can handle this task incrementally. Immolo (Immolo) , this would be a great task for Reddit.
Waldo Lemmer 14:09, 26 April 2024 (UTC)
In the case of the categories I created, they all use one of the following templates: {{LaptopCategory}}; {{BoardCategory}}; {{MotherboardCategory}}. I'm not very familiar with creating templates, but it seems to me that it should be possible to define categories via templates? --Lars Hint (talk) 14:26, 26 April 2024 (UTC)
Yes, templates can add pages to categories via {{CatMask}}, and many do (e.g. {{Dirty}}). When all pages under a badly named category, and only those pages, include the same template, we can add them all to a new category by editing the template.
Unfortunately, removing them from the old category would still have to be done manually. And doing that is just as easy as moving the pages to the correct category would have been. So I don't think this is something we should go for.
See my contribs for an example of what I was proposing above.
Waldo Lemmer 14:38, 26 April 2024 (UTC)
But is it possible to dynamically assign categories? For example, the "HP laptops" page uses "Template:LaptopCategory" which will automatically detect the "HP" prefix and put the page in the "HP" category? The same thing could be done with laptops. In this case, the template will identify the company by prefix and assign "Category:HP laptops" to the laptop. --Lars Hint (talk) 14:42, 26 April 2024 (UTC)
Unfortunately, this wiki doesn't support string parser functions. If it did, we could use #sub, #match and #switch together to choose a category based on the first word in the title. Without string parser functoins, I don't think something like this is possible at all.
Waldo Lemmer 14:48, 26 April 2024 (UTC)
But can we at least pass the company as an argument to the template? So that the template still assigns "HP laptops"? --Lars Hint (talk) 15:01, 26 April 2024 (UTC)
Yes, that would be easy to do.
Waldo Lemmer 15:05, 26 April 2024 (UTC)
Great! Can you make such a generic template that will be used by the templates I listed above (+ Template:LaptopPage)? --Lars Hint (talk) 15:09, 26 April 2024 (UTC)
I'm on it :)
Waldo Lemmer 15:10, 26 April 2024 (UTC)
On second thought, I think I should just modify those templates directly.
Just to be sure, you're planning to call these templates with e.g. {{LaptopCategory|HP}}, right?
Edit: Okay, maybe you're thinking {{LaptopPage|HP}} instead. But then what do you mean by "Can you make such a generic template that will be used by the templates I listed above"?
Waldo Lemmer 15:26, 26 April 2024 (UTC)
What I mean is that GenericCompanyRelatedPage defines the logic to be used in the above templates. Just to avoid duplicating template code. But you can do it differently, I don't know what is easier to implement. So it's up to you. --Lars Hint (talk) 15:37, 26 April 2024 (UTC)
And yes, the calls are: LaptopCategory|HP and LaptopPage|HP. Or is it possible to do it like this: LaptopPage|company=HP|arch=ARM ? --Lars Hint (talk) 15:42, 26 April 2024 (UTC)
The template should be able to fill the HP laptops (ARM64) category as well. :) --Lars Hint (talk) 15:50, 26 April 2024 (UTC)
How's this? Check this page's source for the usage. /sandbox won't be required in real use.
Waldo Lemmer 17:00, 26 April 2024 (UTC)
Awesome! --Lars Hint (talk) 17:19, 26 April 2024 (UTC)
I can't believe we finally came up with a working solution to the problem. :D --Lars Hint (talk) 17:26, 26 April 2024 (UTC)
This was actually quite easy (it only took long because I had stuff to do irl). The real concern is how we'll integrate it — {{LaptopCategory}} is currently transcluded by about 20 categories, 3 of which shouldn't use the generic template at all.
Waldo Lemmer 17:40, 26 April 2024 (UTC)
How about making company optional? --Lars Hint (talk) 17:49, 26 April 2024 (UTC)
I mean optional in the LaptopCategory, not in the GenericCompanyRelatedPage --Lars Hint (talk) 17:53, 26 April 2024 (UTC).
It would have to be optional in {{GenericCompanyRelatedPage}} as well. I can do that, but it'll have to wait until tomorrow since I have two assignments due tonight :)
Waldo Lemmer 17:59, 26 April 2024 (UTC)
Thanks for your work. I'm going to try to tinker with the templates myself, maybe something will work out. :D --Lars Hint (talk) 18:04, 26 April 2024 (UTC)
The template is probably ready to be integrated. --Lars Hint (talk) 19:57, 26 April 2024 (UTC)
Awesome!
I didn't check over your code (template code is easier to write than it is to read), but testing shows that it works well. There's no error handling, but we can worry about that later.
Waldo Lemmer 02:46, 27 April 2024 (UTC)
Did you intend for it to add to two categories at once when using arch? See below.
Waldo Lemmer 03:15, 27 April 2024 (UTC)
Where I integrate this, I want to use unnamed parameters instead of named parameters so editors don't need to worry about remembering parameter names: {{LaptopCategory|HP|AMD64}}.
{{GenericCompanyRelatedPage}} is complete, so feel free to use it. I'll be back in about 40 minutes.
Waldo Lemmer 17:38, 27 April 2024 (UTC)
Unfortunately, it is not complete yet. Check: User:Lars_Hint/sandbox, there is no Super Company 3000 laptops (MIPS)'. And I added a new test case that fails. --Lars Hint (talk) 17:53, 27 April 2024 (UTC)

there is no Super Company 3000 laptops (MIPS)'

That category should be added to articles, not categories. The template is intended to be included in categories like Category:Super Company 3000 laptops, Category:Laptops (MIPS) and Category:Super Company 3000 laptops (MIPS)not articles. I should make this clear in the description.
What do you expect it to do when no arguments have been passed?
Waldo Lemmer 18:11, 27 April 2024 (UTC)
The template was supposed to be used in {{LaptopPage}}, {{BoardCategory}}, {{MotherboardCategory}}, {{LaptopCategory}}. Or did I miss something? No arguments - do nothing. --Lars Hint (talk) 18:19, 27 April 2024 (UTC)
I don't see why LaptopPage needs to use this template — this template already serves three purposes; adding another purpose would require another wasteful #if and a fourth parameter. The template should work correctly in the other templates you mentioned, though.
Template inclusion has some overhead, which we want to keep to a minimum. It's therefore the responsibility of the parent template to decide whether to do something or not. It's also just good programming practice to defer tasks to the parent when reasonable — see wikipedia:Separation of concerns. I can implement this behavior in those templates if you'd like me to.
In fact, it would actually be best if Template:GenericCompanyRelatedPage were broken up into three different templates — one for each purpose, with each template requiring zero #ifs. Nested #ifs are expensive[2]. If you agree, then I'll attempt this tomorrow. I would appreciate suggestions for their names.
Waldo Lemmer 19:07, 27 April 2024 (UTC)
By the way, since Template:LaptopCategory and Co would need to take arguments, every category page where they are transcluded would have to be edited. We could spare the wiki an #if by not adding Template:GenericCompanyRelatedPage to Template:LaptopCategory, and instead adding it directly to the category pages, except for the 3 that don't need it.
Waldo Lemmer 19:17, 27 April 2024 (UTC)
The original idea behind GenericCompanyRelatedPage was to fully define category definitions in a single template for easy maintenance. How can it be considered a best programming practice to not include duplicate logic in a single function? Do you really want to bloat 3 templates with the same logic that supposed to be in GenericCompanyRelatedPage? GenericCompanyRelatedPage outside of LaptopCategory? Since when is encapsulation a bad practice? :O --Lars Hint (talk) 19:39, 27 April 2024 (UTC)
It's certainly not easy maintenance — try deciphering the implementation of Template:GenericCompanyRelatedPage and you'll see what I mean. Seriously, give it a try before reading the rest of this reply.
If all suggestions in my previous reply are implemented, all logic will still be contained in three templates, except there won't actually be any logic because I wouldn't have to use #ifs plus logic optimization techniques to try and squeeze three templates into one, like I did here.
I probably didn't make this clear before: Those three templates would all be on the level of complexity of {{CatMask| {{{company}}} {{{type}}} }} {{CatMask| {{{type}}} ({{{arch}}}) }}. There would be no bloat. There would no logic. What we have right now is bloat and logic (but not logical).
Waldo Lemmer 19:52, 27 April 2024 (UTC)
Waldo, with all due respect, maintaining multiple IF conditions cannot be considered a difficult task. The reference you provided says "the checking is extremely fast" and the limit is "500 instances per page". I'm not a mathematician, just a programmer, but 4 < 500. Isn't it? --Lars Hint (talk) 20:16, 27 April 2024 (UTC)
That quote refers to #ifexist. But I don't blame you for missing the fine print near the end of the section I referenced:

Note that nesting #if functions like this gets very resource-intensive very fast. On some wikis, even seven levels of nesting might exceed resource limits.

I know it's not nested nearly that deep, but you should remember that this template would be included on hundreds of category pages, and those pages would grow with time while the amount of visitors on this site increases. My point is not that we might exceed some limit, it's simply that the performance impact of an addition of this scale would be non-negligible, and that it should be a design decision: Eliminating this performance impact is better than not doing so when all else is equal.
I don't understand why you're opposed to having three, independent, logic-less templates versus one monolithic template. You sound like you know something about programming. I'm sure you're familiar with the practice of splitting functions into smaller, more digestible, reusable atomic functions.
In order to gain an appreciation for the lack of maintainability of that template, I encourage you to add the two features you want. In the meantime, I need to go to bed since it's past 10 PM here. Hopefully we can both start tomorrow with clear heads :)
Waldo Lemmer 20:36, 27 April 2024 (UTC)
What a donkey I am! :D I won't deny it, that block of text I didn't read. I just quickly ran my eyes over it. It's so inconceivable to me that 7 IF conditions can affect performance that I just didn't expect it. That's why I stopped at 500, assuming that this limitation is imposed on all conditions. It's just nonsense, 7 checks of variables for undefined and that's the end of it. What are the templates compiled into (are they compiled at all?)? Thank you Waldo, you have opened my eyes to how poorly Wikimedia is implemented. I will now expect screw-ups almost everywhere. I wouldn't be surprised if our solution at the end doesn't work for some other unfathomable reason. And yes, we will have to get rid of the if conditions. But I still have to insist that the API should consist of only one template call. If there are two lines that have to be inserted, people are going to get screwed. It's just too much. Plus, if the architecture changes in the future, all the pages with two calls will have to be changed (and people won't bother with them, one line will be somewhere at the beginning, the other in the middle of the article). Things would be simpler if there was only one line. --Lars Hint (talk) 04:48, 28 April 2024 (UTC)
P.S. I wasn't sure of the terms “incomprehensible” and “inconceivable” so I used a translator (I hope they are understandable). But as you suggested, a LaptopRootCategory could be a solution then. --Lars Hint (talk) 05:52, 28 April 2024 (UTC)
Since some templates can display differently depending on when and by whom the page was viewed, it seems like MediaWiki would have to process all templates on each page every time a client requests it. They're probably saved pre-exanded (including all #ifs) after each edit. I know MediaWiki does some caching, but I don't know how that fits in here (maybe it caches per user, per edit)?
Sometimes, MediaWiki just seems like a giant copy-and-paste machine with version-controlled input files.
By the way, MediaWiki's flaws is somewhat of a controversial subject among the admins. But we should be safe here on my talk page.
As for having one interface but three templates, I'm not sure how we will accomplish that without deferring the logic to the parent templates (which is bad, since there are multiple parents &mdash code would be duplicated). Do you have any ideas?
We could always have a different parent template for each combination of inputs. But with 3 parent templates that we know of, that would be 12 templates (since we also need the no-parameter option), plus LaptopPage.
Waldo Lemmer 06:01, 28 April 2024 (UTC)
Actually, looking at Category:Laptops, I don't see why it should include LaptopCategory at all. All laptop pages are in subdirectories which include LaptopCategory. That brings it down to 9 templates (but still with duplication).
Maybe we can stick with the 3 templates, but have an {{Ednote}} in LaptopCategory explaining the templates new subcategories should use? We don't currently have any documentation that subcategories should use LaptopCategory at all, do we?
Waldo Lemmer 06:17, 28 April 2024 (UTC)
No, we don't have that documentation. I just thought it was a good idea to put the category-related logic in the template, even for “root” category pages. But with the latest news, everything is becoming questionable. As you stated in the previous conversations, there is no perfect solution to this problem, and since my suggestions have such a big impact on performance, I leave the decision up to you. :) --Lars Hint (talk) 06:34, 28 April 2024 (UTC)
I don't like any of our current options either. I'll see if I can come up with a better solution.
Waldo Lemmer 06:39, 28 April 2024 (UTC)
Here's the situation. We need this:
Category:HP laptops:
[[Category:HP]]
[[Category:Laptops]]

Category:Laptops (ARM64):
[[Category:Laptops]]
[[Category:ARM64]]

Category:HP laptops (ARM64):
pls use laptop blueprint 👉👈 (Blueprints/Hardware/Laptop)
[[Category:HP laptops]]
[[Category:Laptops (ARM64)]]

Repeat for boards and motherboards
I think we should make the following templates:
Template:CompoundCategory:
[[Category:{{{1}}}}]]
[[Category:{{{2}}}}]]

Template:CompoundCategoryChild:
{{GenericBlueprintRelatedPage|{{{1}}}}}
[[Category:{{{1}}}]]
[[Category:{{{2}}} ({{{3}}})]]

Template:GenericBlueprintRelatedPage:
pls use {{{1}}} blueprint 👉👈 (Blueprints/Hardware/{{{1}}})
Then we can have:
Category:HP laptops:
{{CompoundCategory|HP|Laptops}}

Category:Laptops (ARM64):
{{CompoundCategory|Laptops|ARM64}}

Category:HP laptops (ARM64):
{{CompoundCategoryChild|HP|Laptops|ARM64}}

Repeat for boards and motherboards
Waldo Lemmer 07:07, 28 April 2024 (UTC)
I think we need to rename GenericBlueprintRelatedPage to EncourageBlueprintUsage (or something like that). I like your proposal. :) --Lars Hint (talk) 07:36, 28 April 2024 (UTC)
Since this solution is so simple, I'll start work on all of these :)
Waldo Lemmer 07:39, 28 April 2024 (UTC)
So what will be with the {{LaptopPage}}? Should it be [[Category:{{{1}}} laptops ({{{2}}})]]? --Lars Hint (talk) 10:26, 28 April 2024 (UTC)
Oh, I forgot about those categories. Yes, that's the correct format. The other templates are done. I plan to write something these categories in Help:Categories (unless you know of a better page?).
Waldo Lemmer 10:29, 28 April 2024 (UTC)
I guess you won't be surprised if I say I didn't read the help pages. :D So yes, Help:Categories sounds good. --Lars Hint (talk) 10:36, 28 April 2024 (UTC)
Ris (one of the wiki admins, and a stand-in for maffblaster when he was away) once remarked in #gentoo-wiki (webchat):

the guides are a balancing act. we want things to be accessible, sure, very much so - but I feel they might also act as a filter so that we get more of the people who are independent enough to find and read and follow them, and who also know enough to understand them, and have enough attention span to read a few of A4 sheets of introductory materiel

He also said in a different conversation:

I have just been able to take a look at a hand full of lars's edits, but as the edits seemed fine, and that those edits seemed to make clear that lars has clearly read and taken onboard the guidelines etc. I've sort of decided to leave them to it for now and concentrate on urgent things and hope my first impression that they are doing a good job is not wrong (I think you seem to agree that they are doing a good job - which is reassuring)

If you told him what you just told me, I think it would be pretty eye-opening to him — I've argued to him that the Help pages should be made more brief, but he wants me to focus on the donkey work (i.e. Areas for contribution).
Waldo Lemmer 10:54, 28 April 2024 (UTC)
So are we going to encapsulate your templates with {{LaptopCategory}} and others or is there another side effect? --Lars Hint (talk) 10:36, 28 April 2024 (UTC)
The thing is, that will add complexity because my templates have different interfaces (which is unavoidable). It's not really needed, though — Template:CompoundCategoryChild already includes the blueprint template. And there's no reason to have a different template for each form factor / device type. Besides LaptopPage, we're basically done, although LaptopPage and Co can all use the same template as well for consistency and scalability (maybe I should call it Template:ProductPage).
Waldo Lemmer 11:10, 28 April 2024 (UTC)
I just don't like to pass type=laptops every time. The aditional layer of abstraction (LaptopPage) hides it. --Lars Hint (talk) 11:28, 28 April 2024 (UTC)
I understand. I will implement it. I've highlighted it for myself so I don't forget.
Waldo Lemmer 12:24, 28 April 2024 (UTC)
I see you have changed the logic of {{EncourageBlueprintUsage}}, it has a problem now. Blueprint "Boards" does not exist. There is "Embedded". --Lars Hint (talk) 12:11, 28 April 2024 (UTC)
I had made a redirect. Is it not working somewhere?
Waldo Lemmer 12:25, 28 April 2024 (UTC)
No, I just read your code and saw the problem. Interesting decision to use a redirect. I like it, but wouldn't this cause all board pages to use a double redirect? Is this allowed? --Lars Hint (talk) 12:30, 28 April 2024 (UTC)
A double redirect is a redirect to a redirect, not a link to a redirect.
Waldo Lemmer 12:38, 28 April 2024 (UTC)
I thought these are not allowed too, my bad. :) --Lars Hint (talk) 12:46, 28 April 2024 (UTC)
Fixing links to redirects is a good way to prevent them from becoming double redirects in the future. That will happen if the Embedded page gets moved. Luckily it can be fixed by simply modifying the redirect at Boards, so it's not an issue.
So now we're done template-wise, right?
Waldo Lemmer 12:50, 28 April 2024 (UTC)
As far I understand, we still need the ProductPage template. --Lars Hint (talk) 12:51, 28 April 2024 (UTC)
Will it be based on LaptopPage, or we can apply the deletion flag on the LaptopPage and its subpages? --Lars Hint (talk) 13:10, 28 April 2024 (UTC)
You can add {{delete}} to those :)
Waldo Lemmer 13:32, 28 April 2024 (UTC)
Of course, my bad.
Waldo Lemmer 12:57, 28 April 2024 (UTC)
It's done. I guess I can close this discussion now?
Waldo Lemmer 13:51, 28 April 2024 (UTC)
This problem can be solved by moving the EncourageBlueprintUsage call from CompoundCategoryChild to the additional level of abstraction (BoardCategory, LaptopCategory, etc.).
Do we really want 9 more templates (LaptopCategory, LaptopCategoryChild, LaptopPage, ...)?
Waldo Lemmer 12:39, 28 April 2024 (UTC)
No, we don't. Maintenance would be a time-consuming task. Imagine if we added Smartphones and more ... :D --Lars Hint (talk) 12:44, 28 April 2024 (UTC)
What about the API? LaptopPage|HP|ARM64 or LaptopPage|company=HP|arch=ARM64 ? --Lars Hint (talk) 10:48, 28 April 2024 (UTC)
I prefer the former, but you previously gave reasons for the latter that I can't argue with. Simply put, there's no perfect solution, so it's up to you.
Waldo Lemmer 10:56, 28 April 2024 (UTC)
Let's use unnamed parameters. What scares me is that variable name parsing is probably (my guess) implemented without using HashMap, so it probably also affects performance (worst case scenario). About the guidance, I prefer to learn as I go. I think it would be unwise to ban me. After all, I do more good than harm. I can be emotional on talk pages, but not in articles. --Lars Hint (talk) 11:10, 28 April 2024 (UTC)
Yes, parameters are probably not stored in a hashmap, since arguments can use any keys and parameters can reference any arguments.
I hope it didn't sound like I implied that you might get banned — the admins (and me) are very grateful for your contributions, regardless of whether you read the help pages. As long as you make positive contributions and don't create extra work for others, it really doesn't matter whether you read those pages or not.
Being emotional is good. It means you're passionate about making the wiki better. Luckily you seem to channel that emotion in a productive way — explaining and clarifying your point instead of throwing personal attacks, which some might do.
Waldo Lemmer 11:19, 28 April 2024 (UTC)

Category naming convention

Talk status
This discussion is done.

I would vote against unnamed parameters, as it will be difficult to work with the template if more arguments come up in the future. This will be especially a problem if parsing the company name by title prefix is implemented in the future. And yes, two categories are filled intentionally. We could even add one more category for series (as you proposed in the previous discussion). --Lars Hint (talk) 07:00, 27 April 2024 (UTC)

Category arrangement 2.png
Alright, then. I do think Category:HP laptops (AMD64) should belong to Category:HP laptops and Category:AMD64, so pages that belong to Category:HP laptops (AMD64) don't have to also belong to those categories. The same applies to Category:HP Pavilion laptops (AMD64), which should also belong to Category:HP Pavilion laptops.
Waldo Lemmer 08:14, 27 April 2024 (UTC)
Okay, let's do as you suggest. --Lars Hint (talk) 10:17, 27 April 2024 (UTC)
Is there a way to capitalize type (laptops -> Laptops)? --Lars Hint (talk) 10:26, 27 April 2024 (UTC)
Yes, why?
Waldo Lemmer 10:28, 27 April 2024 (UTC)
Because the template should add HP Laptops to Laptops. --Lars Hint (talk) 10:30, 27 April 2024 (UTC)
Wait, what happens if the manufacturer doesn't use the series? --Lars Hint (talk) 10:45, 27 April 2024 (UTC)
We also need Category:HP Laptops (ARM64) because checking all series to find ARM devices is inconvenient. --Lars Hint (talk) 10:51, 27 April 2024 (UTC)
What about this structure: HP laptops -> HP laptops (ARM64) -> HP Pavilion laptops (ARM64) -> laptop page ? --Lars Hint (talk) 10:56, 27 April 2024 (UTC)
The easiest way would be to not use the series at all, they are in the titles anyway. :D --Lars Hint (talk) 11:04, 27 April 2024 (UTC)
I think we should only choose one scheme, otherwise maintenance will be a huge pain. In fact, doing it from smallest to largest seems to be the best usage-wise and maintenance-wise: Laptops -> Laptops (ARM64) -> HP laptops (ARM64).
Waldo Lemmer 11:18, 27 April 2024 (UTC)
You're right, let's keep it simple. --Lars Hint (talk) 11:28, 27 April 2024 (UTC)
But we still need "HP laptops" for articles that cover both architectures. :( --Lars Hint (talk) 11:33, 27 April 2024 (UTC)
Okay, let's not change the scheme. "Checking all series to find ARM devices is inconvenient": We don't have a better solution.
Waldo Lemmer 12:13, 27 April 2024 (UTC)
What about this structure? --Lars Hint (talk) 12:08, 27 April 2024 (UTC)
I remember ruling this out while drawing the above structure, but I don't remember why. I think because it creates more maintenance? But you would know better than I do.
Waldo Lemmer 12:13, 27 April 2024 (UTC)
So which solution do you favor right now (I'm confused)? Laptops -> Laptops (ARM64) -> HP laptops (ARM64)? --Lars Hint (talk) 12:43, 27 April 2024 (UTC)
The one that's currently in use, but lowercase, i.e. Laptops -> HP laptops (which is equivalent to HP -> HP laptops). But maybe you can start a new thread where you list the qualities of a good scheme (you seem to catch things I don't even consider). Then we can use that to grade different schemes and find one that's as close to optimal as we can get.
Waldo Lemmer 12:58, 27 April 2024 (UTC)
Understandable. It is difficult to cooperate with me, given that I change my views to the opposite every second. :) So are we going to modify the {{GenericCompanyRelatedPage}} to implement the Laptops -> HP laptops transition? And then during integration we pass on all the arguments we have talked about for future changes? --Lars Hint (talk) 14:00, 27 April 2024 (UTC)
Category arrangement 3.png
Hey, we haven't decided if this is the best scheme yet! :)
Okay, so the mandatory categories are as follows:
  1. Laptops (ARM64) and HP laptops (ARM64), since finding ARM devices should be convenient.
  2. HP laptops because some articles are architecture-independent.
Can you double-check this list and see if it's correct and/or missing something?
Also keep in mind, using a template, we can automatically add "HP Pavilion laptops (ARM64)" to as many categories as we want — even all ten combinations of them. Of course, that's not the most practical solution, because:
  • Some of those categories would have a large amount of subcategories.
  • New categories would have be manually added to the root category (I think it's Hardware?).
  • MediaWiki's category calculations might bring the wiki down :)
Still, we might as well test this on a small to see what each category would look like in practice.
Waldo Lemmer 14:28, 27 April 2024 (UTC)
Laptops (ARM64), or HP laptops (ARM64) If we choose only HP laptops (ARM64), Category:ARM64 will be flooded (boards, motherboards, laptops). --Lars Hint (talk) 14:56, 27 April 2024 (UTC)
Okay, so if HP laptops (ARM64) is chosen, Laptops (ARM64) should also be chosen. But can we instead choose HP Pavilion laptops (ARM64) + Laptops (ARM64) (+ the other mandatory categories)?
Waldo Lemmer 15:08, 27 April 2024 (UTC)
What if the series doesn't exist (laptop name does not have one)? --Lars Hint (talk) 15:14, 27 April 2024 (UTC)
Noted.
Waldo Lemmer 15:17, 27 April 2024 (UTC)
Which categories are we planning to add to the root category? For architectures there is Category:Computer_architecture. --Lars Hint (talk) 15:23, 27 April 2024 (UTC)
We have Category:Companies. The only one left is Category:Form factors, but currently those sub-categories (e.g. Category:Laptops) are directly under Hardware, which I don't want to mess with since it's on the front page. So I think we're good root-category-wise.
We've ruled out a ton of options. I added a graph of the current situation to the left of the list.
Waldo Lemmer 15:31, 27 April 2024 (UTC)
HP laptops (ARM64) should not belong to ARM64 as it is available through Laptops (ARM64). --Lars Hint (talk) 15:41, 27 April 2024 (UTC)
The same applies to Laptops and HP. So we're done! I'll get started on updating the template.
Waldo Lemmer 15:43, 27 April 2024 (UTC)
So the API will be LaptopPage|company=HP|arch=ARM64? Can I start injecting it into the laptop pages (I will make the dummy template to accept the arguments)? Or should we implement everything and only then start injecting to avoid DoS? --Lars Hint (talk) 15:52, 27 April 2024 (UTC)
Yes, that will be the API. You can start in the sandbox while I implement {{GenericCompanyRelatedPage}}. After that, we should roll out a few changes first and observe their effects before scaling up.
Waldo Lemmer 16:04, 27 April 2024 (UTC)
There will also be a problem with articles not related to laptops, so it's probably still better to include laptop pages in multiple categories, as was done in the beginning. And the subcategories would be treated as a sort of sorting. --Lars Hint (talk) 11:08, 27 April 2024 (UTC)
Could you elaborate (maybe give an example)?
Waldo Lemmer 11:18, 27 April 2024 (UTC)
For example TUXEDO_Software is inside of "TUXEDO laptops", if the categories are in the tree form, the article will be hidden behind two categories, so people may not even know the article exists.
I don't think we should be too picky. The category system is flawed — building a perfect system is impossible. I think we should prioritize ease of maintenance over discoverability, with the constraint that the system should at least be useful.
Waldo Lemmer 12:13, 27 April 2024 (UTC)
I thought we were going to make things lowercase?
Waldo Lemmer 11:18, 27 April 2024 (UTC)
just a typo --Lars Hint (talk) 11:28, 27 April 2024 (UTC)

Motherboards

Talk status
This discussion is still ongoing.

Is there a reason to use ProductPage for motherboards? Motherboards have different sockets depending on the CPU manufacturer and CPU generation. --Lars Hint (talk) 05:46, 29 April 2024 (UTC)

I can modify ProductPage to accept either a socket or an architecture. In other words, it should accept one of arch= or socket=. — 05:58, 29 April 2024 (UTC)
Oh right, it has unnamed parameters. But you know what I mean.
Waldo Lemmer 06:00, 29 April 2024 (UTC)
So using unnamed parameters was a mistake. Let's switch to named parameters. Add the temporary optional parameters: company, type, arch. And I'll update the notebook pages again. It won't take that much time, because all the parameters are already known. :) --Lars Hint (talk) 06:18, 29 April 2024 (UTC)
Why was it a mistake? Parameter 3 can be repurposed for the socket (e.g. ASRock motherboards (AM4)). And if we want to have the arch and socket in separate parameters for some reason, the socket can use the fourth parameter. In either case, existing usages of {{ProductPage}} are unaffected, and the template code needs barely any modification (none in the first case).
Waldo Lemmer 06:27, 29 April 2024 (UTC)
You are right, it is easier to add a 4th parameter. In both cases it will require 2 not nested IF conditions (7 milliseconds in total). But I'm still not sure about sorting by socket. But it definitely doesn't make sense by architecture, I'm more than sure everything there will be AMD64. --Lars Hint (talk) 06:51, 29 April 2024 (UTC)
If we repurpose the third parameter for the socket, then no change is needed — {{ProductPage|ASRock|motherboards|AM4}} produces [[Category:ASRock motherboards (AM4)]].
Whether logic is needed when using a separate fourth parameter depends on the category name format: [[Category:ASRock motherboards (AMD64, AM4)]] or [[Category:ASRock motherboards (AMD64) (AM4)]]. In the former case, no logic is needed if the second parameter contains ", AM4".
Waldo Lemmer 06:57, 29 April 2024 (UTC)
The problem is that if there is a socket with the same name as the architecture, there will be problems. Also, people might think that the socket name is the name of the architecture. But maybe I'm overthinking it. --Lars Hint (talk) 07:07, 29 April 2024 (UTC)
But you are right, the name conflict can be solved by just passing ARM (socket) as the parameter. --Lars Hint (talk) 07:12, 29 April 2024 (UTC)
"if there is a socket with the same name as the architecture, there will be problems" Is there such a socket? And if that happens, which I doubt, we can simply change the socket's name, for example by appending "socket" to it, or making it a subpage of Category:Socket/.
Architectures go in Category:Computer architecture and sockets will go in Category:Sockets. And yes, I think you're overthinking it :)
I will be back in two hours.
Waldo Lemmer 07:15, 29 April 2024 (UTC)
I think we can temporarily freeze the discussion, the category isn't popular anyway. It's difficult for me to understand what is important to others in this case, as I don't buy motherboards. ProductPage does not require any modifications, so everything is fine at the moment. I'm a bit busy today, too. --Lars Hint (talk) 08:21, 29 April 2024 (UTC)
Understandable. Should Boards be on hold as well?
Waldo Lemmer 08:38, 29 April 2024 (UTC)
We can still sort them by architecture, though. For Gentoo, only arch matters in any case. --Lars Hint (talk) 05:55, 29 April 2024 (UTC)

Boards

I think socket type matters much less than architecture for SBCs, since microprocessors are often soldered on and boards come in a wide range of architectures.

Waldo Lemmer 08:39, 29 April 2024 (UTC)

Yes, boards should be sorted by architecture. But be careful, I put redirects on some pages, however the pages contain information that needs to be merged with other pages. There is another problem - the licensing of texts. There are lists of authors at the bottom that also need to be merged. --Lars Hint (talk) 10:55, 29 April 2024 (UTC)
Can you give me an example or two, so I can see what you mean?
Waldo Lemmer 11:55, 29 April 2024 (UTC)
Embedded_Handbook/Boards/Pandaboard and Embedded_Handbook/Boards/TrimSlice. And a few more in the Category:Boards. --Lars Hint (talk) 15:03, 29 April 2024 (UTC)

Chromebooks

What do you think, is it fine if Chromebooks will have two calls of ProductPage? In this case Category:Chromebooks will be sorted as well, and the Chromebooks will be listed under Laptops too. --Lars Hint (talk) 10:55, 29 April 2024 (UTC)

Would Category:Chromebooks represent the company or the form factor? I.e., "Chromebook laptops (AMD64)" or "Acer Chromebooks (AMD64)"? The latter sounds good to me. It will result in "Acer Chromebooks" and "Chromebooks (AMD64)" being created. All good so far.
But {{CompoundCategory}} will assign these two categories to "Acer", "Chromebooks" and "AMD64". This will result in "Acer" and "AMD64" now having Chromebook as well as laptop subcategories, with each Chromebook subcategory being a subset of the corresponding laptop subcategory.
To fix this, we need to ensure that "Acer Chromebooks" is not placed in "Acer" directly and "Chromebooks (AMD64)" not in AMD64. They should still be reachable from "Acer" and "AMD64", respectively, though, so they should be placed in "Acer laptops" and "Laptops (AMD64)", respectively.
In short, do everything as normal, except:
  • "Acer Chromebooks" has [[Category:Acer laptops]] instead of CompoundCategory.
  • "Chromebooks (AMD64)" has [[Category:Laptops (AMD64)]] instead of CompoundCategory.
We should create additional templates for this, with the interfaces {{template 1|company}} and {{template 2|arch}}. What should we call them? They should have "Chromebook" as part of their names, since that will be hard-coded. Or we can make them more generic (i.e. add another parameter to each). But I don't know where else they would be used — Netbooks?
Waldo Lemmer 11:22, 29 April 2024 (UTC)
The form factor (Acer Chromebooks (AMD64)). Is it really a problem that Chromebooks will be listed on the same level as "Laptops"? What about "2 in 1" laptops (tablet and laptop at the same time)? Those should also have 2 calls of ProductPage, and Tablets have the same level as Laptops. And I don't know what to do with Netbooks right now. --Lars Hint (talk) 11:46, 29 April 2024 (UTC)

Is it really a problem that Chromebooks will be listed on the same level as "Laptops"?

It's not a problem. It's just not ideal. But I guess not all future Chromebooks will necessarily be laptops, so we should treat them like any other form factor. So we roll with your plan :)
Waldo Lemmer 11:53, 29 April 2024 (UTC)

Category:Computers and Category:Desktops and Category:Mini_PCs

I think we need to eliminate Category:Computers. The definition of "Computer" is unclear. I also doubt that Category:Desktops should exist. Gentoo Wiki:Article Blueprints says "Desktops (Motherboards)". What about Category:Mini PCs? How the template will handle it? mini pcs -> 'Mini pcs'? --Lars Hint (talk) 14:59, 29 April 2024 (UTC)

I agree about Computers. But I think keeping Desktops is reasonable — they're basically just non-portable laptops without peripherals. Every prebuilt PC has its quirks when installing Gentoo and has to be categorized somewhere. But maybe Mini PCs should go under Desktops.
They're called SFF PCs nowadays, anyway.
Whoops, I got this wrong. Mini PCs are not like small desktop PCs. Their architecture is more similar to that of laptops. I think they deserve their own category instead of Desktops. Or maybe both. — 08:19, 30 April 2024 (UTC)
Case is not an issue. I should modify the template documentation to note that names should look like "mini PCs", although I don't know how to phrase that.
Waldo Lemmer 15:16, 29 April 2024 (UTC)

make.conf

Talk status
This discussion is still ongoing as of 2024-05-04.

Pretty user page, I'm jealous :) Could I politely ask you remove the make.conf you use please, this isn't because of the issues I have with setting it systemwide as it's your system not mine however, others might see this as a good idea to run as a new user and think Gentoo is broken because everything breaks around them :)

As for the article you want to write about it, I highly advise you speak to Sam before starting to make sure it can stay up as it really hits hard when you spend a day writing some cool and it has to be removed.

Otherwise keep up the good work please <3

Immolo (talk) 19:33, 4 May 2024 (UTC)

I agree, I'll remove it.
As for the article I want to write, it's about creating custom profiles based on existing ones. That bullet point applies to the item above it, not below it. But thanks for the advice :)
Waldo Lemmer 19:45, 4 May 2024 (UTC)
Thanks! Ah I see about the profiles. I recommend users normally follow Profile_(Portage)#Profiles_for_developers_and_power_users as while at the start it does seem a little overwhelming, it actually explains the whole process from beginner to expert that it was all I needed to start writing my own profiles for Gentoo when I started. If you have some ideas on how to improve that though then do please catch me on IRC one day to discuss as this is one of my interests in Gentoo that I try to follow closely.
Immolo (talk) 22:09, 6 May 2024 (UTC)
You're right, I should probably direct my energy in that page's direction. That's where I learned to create profiles.
Still, I think my motivations for modifying an existing profile should be documented somewhere. Maybe I'll do it on that page :)
Waldo Lemmer 02:45, 7 May 2024 (UTC)
Please do edit if you can think of a better way to do it, I just have a huge interest in this so want to try and help.
Immolo (talk) 12:22, 7 May 2024 (UTC)

References