Talk:Laptop

RUN+="<command>" won't work reliably

In the example:

/etc/udev/rules.d/lowbat.rules

# Suspend the system when battery level drops to 2%
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"

RUN
...
Starting daemons or other long running processes is not appropriate for
udev; the forked processes, detached or not, will be unconditionally killed
after the event handling has finished.

There's no garantee that systemctl will finish execution. Its possible to use ENV{SYSTEMD_WANTS}="systemd-suspend.service" but I have not personally tested this. All these udev rules should be reworked to trigger one-shot systemd services ideally, which also brings along all the benefits of have systemd units (logging, debugging, etc).

-- Simongmzlj

First of all, RUN+= is not deprecated. Missing features do not predicate deprecation. I've removed the accuracy note from the page: [1].

The ENV{SYSTEMD_WANTS}="suspend.target" should be used ideally, but it has to be combined with TAG+="systemd".

-- Lahwaacz (talk) 19:38, 26 September 2013 (UTC)

Isn't the point that systemctl may not finish executing - certainly may not finish quickly enough for udev's liking? It is a matter of what is suitable in a udev rule due to the nature of udev. --cfr (talk) 01:47, 8 November 2013 (UTC)

systemd-tmpfiles

Re [2], how is this any different from other tmpfiles entries? -- Alad (talk) 10:51, 23 August 2016 (UTC)

For example in Maximizing_performance#systemd-tmpfiles you're writing the desired value to the "special" file, but here you're just toggling the state for the event you write to the file. It would work assuming that systemd-tmpfiles is run just once after boot, but that's not the case. -- Lahwaacz (talk) 11:05, 23 August 2016 (UTC)

Old laptop pages

There are a whole bunch of incredibly old (ca 2010 or even older) laptop pages. They are usually horribly outdated, full of dead/broken links and not pleasant to look at. In my opinion laptop pages which did not have a major, relevant edit in the last 5 years or so should be archived. This definition is not accurate, but if there are ancient laptop pages which still get maintenance they should not be archived. Here is a list of ancient pages I found so far, I still need to tag them with Template:Out of date and link to this discussion:

• Acer Aspire 7720
• ASUS F5R
• ASUS Eee PC 1005P
• ASUS N53JN
• ASUS UL30A
• Dell Inspiron 1564
• Lenovo ThinkPad T61
• IBM ThinkPad X60s, might be an example of "is still kind-of active"
• Lenovo ThinkPad T400
• Lenovo ThinkPad T420
• Lenovo ThinkPad T520

Some devices are also still semi popular, especially ThinkPads.

There are a whole lot more but this single discussion will probably grow too large if I keep on adding links.

-- NetSysFire (talk) 19:48, 2 March 2021 (UTC)

There is no expiration date for laptops—except, in context of Arch Linux, when the architecture is too old and there is no more support for it, but then, Template:Archive would be preferred IMHO.

What do you think by marking them "Out of date"? There may be nothing to update in these pages, if laptop material hasn't changed, isn't it? Do they need links updates? Do they need restyling (Template:Laptop style)? -- Audeoudh (talk) 08:13, 31 March 2021 (UTC)

Most need both restyling and updating. The problem is that they are usually extremely ugly, full of outdated information that is not useful at all anymore and they also contain pointless config/shell dumps. The problem is that we can not update them easily without the hardware, this does not apply to fixing style problems and more of course. In my honest opinion this is a waste of time though, since no one uses these ancient devices anymore. These pages are now cluttering the statistics with broken/dead links and other issues.

When a page gets archived, it is not deleted and can still be viewed (when you are logged in at least). And User:DerpishCat and I only marked pages with Template:Out of date when the last relevant edit (which did not fix style issues or whatever) was at least 9 years ago.

-- NetSysFire (talk) 16:23, 31 March 2021 (UTC)

I propose that dealing with laptop pages which are just hopeless can be done by redirecting them to Laptop instead of ArchWiki:Archive. Thoughts?

-- NetSysFire (talk) 10:08, 13 June 2021 (UTC)

I'm not sure of the technical implications below that decision. However,

1. I disagree deleting information at all. Even for obsolete hardware (i.e., unsupported by Arch Linux). Mark them archived, put a big header “this hardware is no more supported by Arch Linux”, or any other solution like that is OK for me as long as we may still reach that pages if we really want them.

2. I won't consider (nor mark) “Out-of-date” a (laptop-)page for which hardware is still supported, whatever is its current state (not modified for many years, ugly, broken links, etc.)—though Template:Laptop style or similar seems OK for me. “Out-of-date” means that information is no more relevant, which is clearly not the case if hardware is still supported (e.g., one of my own laptop, a Dell Inspiron N5010, marked “Out-of-date” but laptop is still running perfectly and information there may be of some use).

-- Audeoudh (talk) 10:03, 14 June 2021 (UTC)

I think redirecting to the Laptop page is more confusing than anything: the general page does not offer specific advice for the model. When dropped to the archive page, it is made clear to the user that no information relevant today is available in the wiki. --Erus Iluvatar (talk) 18:35, 28 June 2022 (UTC)

Please exempt Lenovo ThinkPad T400 and Lenovo ThinkPad T520 from this list. They have since been edited to comply with Help:Laptop page guidelines. -- Flyingpig (talk) 01:19, 30 July 2021 (UTC)

I've been archiving laptop pages marked with Template:Out of date, following NetSysFire. So far only one instance has sparked a discussion (which ended with the related page being nicely rewritten).

From what I've gathered from the discussion an the pages I've encountered so far:

• They mostly contain ancient advice, usually irrelevant to a recent Arch Linux installation (e.g. some still reference rc.conf like Sony Vaio VPCF13, Nokia 6230i, Toshiba Satellite P500-ST2G02, Lenovo ThinkPad T420s or ASUS AT3IONT-I).
• They have been written (long) before we codified the Help:Laptop page guidelines and thus offer no coherent presentation of − or outright miss − information which could be helpful to a potential reader.
• The majority of them concerns hardware which is probably no longer actively used, because even though hardware does not expire, most people replace their laptop instead of upgrading them, and very few people keep the same machine for more than 5 years, even less 10.

See below for a draft to be added at the bottom of Help:Laptop page guidelines.

--Erus Iluvatar (talk) 18:38, 28 June 2022 (UTC)

I strongly disagree with that. My Dell_Latitude_E7440 works great even till now, with the only apparent disadvantage is the 1080p screen compared to modern HiDpi screens. It is 9 years old now. Replacing a laptop even when it is perfectly capable of doing one's work only applies to some rich countries/people. Pages of an "old" laptop should not be archived. Putting a banner stating the last update's date to warn the reader is OK. --Oldherl (talk) 06:16, 11 September 2022 (UTC)

+1 here. Let's use Dell Inspiron 1564 as an example, most of the function works fine and only a very old ATI driver issue exist which is indeed out of date. Because “We don’t cause regressions” is the first rule of Linux kernel development; Linux founder and lead developer Linus Torvalds established it himself and ensures it’s obeyed [3]. So if a laptop mostly work in old kernel and no one continuely report if it works or not, we could just assuem it will still work now. The hardwire will not loose support just because the style is old or the page is not updated in 5 or 10 years. --Fengchao (talk) 00:49, 23 January 2023 (UTC)

This is just inaccurate: some uncommon processors support is broken since nearly two years, but the offending commit has not been reverted, nor has the two line patch been accepted. There is also regular old driver removal. Moreover, the main argument is not that hardware suddenly stops working (though the state of the open source alternative to abandoned proprietary drivers is not always on par for low popularity hardware), but that the advice given on the pages is no longer relevant a decade after it's been written (e.g. asking readers to edit rc.conf, references to HAL, pm-suspend, etc…). These examples are blatant, but more subtle situations exists, where the hardware no longer requires workarounds or configuration and the default behavior is now what anyone would expect, but without the hardware no one can test for it (e.g. acpi_osi hacks, modprobe options for modules, blanket advice to edit /etc/xorg.conf, etc…).

Looking at the page you linked:

• the "System Specs" section is useless and should be relegated to a link in the introduction,
• the "Hardware Details" section is just a lspci/lsusb dump and provides less value than a link to a https://linux-hardware.org/ probe,
• the "What Works", "What Does Not Work" and "What Has Not Been Tested" sections should have been turned into a hardware table, which would be the only content remaining in the page once it is rewritten to abide Help:Laptop page guidelines:

all this could be merged with Laptop/Dell#Inspiron and the page then redirected to it, but it is a time consuming task for very little value added given the low number of readers it will touch. --Erus Iluvatar (talk) 07:26, 23 January 2023 (UTC)

Errr, as a prior VIA software Engineer (leave in 2011), I do not know what I could say here. VIA had a very bad repulation in Linux at that time, one of my job is building close sourced drivers (VX800 including) for different distributions. Lots of things happen to the company including the transition to zhaoxin. But to me it is still a steady improving, people report regression and zhaoxin provide patches. If it is ten years ago, people report issues and we could only provide binary drivers most of the time.

Still, such regression does exist but they are rare and if it is found by users, Archwiki should provide a place to document them. That's why some in this thread want to keep the page for longer. If VIA pages are archived, where to report such issues then? So redirect to Laptop is better, users could add some hardware trouble shooting there.

--Fengchao (talk) 08:29, 23 January 2023 (UTC)

Funny coincidence! To get back on topic, I understand wanting to keep possibly useful content, but without access to the hardware, how would anyone determine what is still relevant today ? See Talk:Laptop/Apple#Webcam from 2022-12, following the accuracy flag from Laptop/Apple#Model list added 2022-06: most users do not keep old hardware around, even less document when it stops needing a workaround, which makes hardware status stay erroneously described for years.

It is perfect fine here, if no one confirm if it works or not, just write not confirmed as it is. Not confirmed is the answer, it is a natural state, so we do not need to try too hard to move it out of the state. From a possibility point of view, if a hardware could install Arch, it has a high possibility that it still could support Arch. And in rare conditions that a hardware does lost support, it has a high possibility that same user hit the issue and reported. And in rare conditions that no user even add a note, it is just no one notice or no one care. We should not delete a page because no one confirm it still works or not 10 years later. If no one ever shout out, just assume it still work works most of time.

Archiving a page is not deleting content! If "no one notice or no one care", why keep the page? If we can assume the hardware works, why should we keep outdated workaround? --Erus Iluvatar (talk) 15:57, 25 January 2023 (UTC)

It is what the Linux kernel work and Archwiki should follow. There are cases that a developer do not have a hardware but the code still support the hardware after 10 years. And when a issue does comes up, the end user need to provide debug trace and help bisecting and verify. There are cases that a hardware is broken for years without any developers notice. Kernel itself do not stop support a hardware if the code is not test on the hardware for 10 years.

--Fengchao (talk) 14:29, 25 January 2023 (UTC)

That's simply not true, there are active efforts in the kernel to remove old or unused code. Here are a few examples to add to the ones I had already listed in our exchange on ArchWiki talk:Translation Team#Address explicitly the fact that creating new pages should be secondary to maintaining existing ones: [4][5][6]

--Erus Iluvatar (talk) 15:57, 25 January 2023 (UTC)

As for where to document hardware issues, I would say it depends on what exactly the issue is. If it's a generic issue we have vendor pages (e.g. Via Technologies, Laptop/Lenovo, even NVIDIA comes to my mind for FS#74886/FS#74891). If it's on a single model, I warmly welcome contributions on old pages (or creation of pages / pulling pages from the archive for old supported models), people might even find the time to update the rest of the page when they find it. Sadly this happens less than once a year: most people simply read the pages and very few even warn when the information is inaccurate through the talk page.

In the event that you did not see my answer below, I will reiterate that a redirection to the generic Laptop page is more confusing than archiving (I have personally experienced this with an EeePC) which clearly indicates to the reader that no relevant device-specific advice remains. See fglrx or ATI Rage: they do not redirect to ATI.

--Erus Iluvatar (talk) 09:47, 23 January 2023 (UTC)

And I'm still using a Toshiba Satellite L300 from 2008, but this is not what this discussion is about.

The combination of factor outlined above explains why some pages are in a state that gives no helpful content to a potential reader.

Keep in mind that the proposed draft requires the page to be old and not in line with the rules applicable to hardware pages: a page that is simply old would not be affected, nor one that still receives frequent contributions (e.g. the one you linked).

Compare it to Toshiba Satellite P500-ST2G02 for example: the last content addition was in 2012.

What are your thoughts about simply flagging pages for archival (hence giving a simple 1 week countdown to protest) instead of giving contributors a year to get the page in shape? --Erus Iluvatar (talk) 07:06, 11 September 2022 (UTC)

Since this looks like it's not getting traction, how about we just follow the rules applicable to other pages, i.e. flagging them for archival and if no one yells in a week, making good on that promise? --Erus Iluvatar (talk) 18:36, 23 August 2022 (UTC)

As discussed in other topics, I will give my -1 for time based archive action. If anyone find the info in old laptops are indeed out of date, just flag the out of date section. If the style does not follow latest rule, flag them with style flag. If no one could determine if the information are out of date or not, just leave it there, do not archive it. At the same time, I think if a laptop does not need any specific action, we could redirect them to Laptop because it is indeed supported by Arch through general information. --Fengchao (talk) 00:18, 23 January 2023 (UTC)

As answered above, redirecting to Laptop is confusing, and if it is not possible to redirect to the model list table for de manufacturer the page should be archived. Most listed bugs on outdated pages are fixed, sometimes since a decade, but the pages did not get updated. With the same reasoning as the one we have exchanged on other topics: they are needing a disproportionate amount of time compared to the few readers they might reach today. --Erus Iluvatar (talk) 06:38, 23 January 2023 (UTC)

In freesoftware/opensource world, it is wrong to assume a hardware will quickly loose support during software evolve. At lease in Linux world, old hardware are supported much much longer. That is one of the reason that people choose Linux. In Archwiki, I always see below trend instead:

1. When new hardware comes out, there are many specific issues so specific actions needed(acpi, harddisk, video ...). So those pages contains very specific useful information. With out them, Arch could not install or some hardwares will not function.
2. Kernel/drivers catch up slowly but steadly, specific actions are not needed one by one. So sections are gradually linked to gereral pages instead.
3. After years, all funcitons just works without any specific actions so we could just redirect the page to Laptop.

Note the difference here: software does evolve, but to a better state, not a unsupported state. No one edit the page mostly because the hardware just works, not because it could not install or continue use Arch anymore.

--Fengchao (talk) 01:10, 23 January 2023 (UTC)

Old hardware pages draft

While hardware has no expiration date, software evolves rapidly around it. With less and less users able to confirm if old advice is still relevant as time passes, hardware pages which are:

• flagged with Template:Laptop style and Template:Out of date, the second of which should link to this rule and state "This page is ancient. On {{#time: Y-m-d|now + 1 year}}, this page will be archived, since the validity of its content for an up to date Arch Linux installation can not be verified.";
• have not seen any content update in the last 5 years (i.e. we do not count style or typo fixes as being an update);
• have not been updated for 1 year after flagging (again, not counting minor typo or style fixes);

will be archived.

Is a maintainer responsible for the accuracy of a old content?

I think it is a big and fundamental topic, so I just start it here and maybe it should be moved to Maintenance Team. My answer here is that it is not a maintainer's responsiblity to make every page accurate. A wiki page is not a official supported announcement. If it just fine that some sections are out of date but no one notice, no one fix it or no one discuss it in talk. It is just a reality of a wiki. If a maintainer could not determine or do not have enough time to determine if a section is out of date or not, just leave it there for someone more familiar with the topic to come up. A maintainer should not just archive or remove a section because it is 5 years old or 10 years old. If no one shout out, just leave it here. I mean it is like how to view a suspect. It should be Innocent until proven guilty that is if no one give enough evidence that the section is wrong, it should not be deleted. --Fengchao (talk) 14:12, 25 January 2023 (UTC)

As stated in ArchWiki:Contributing#Improving this task of verifying that the information we provide is up to date is everyone's responsibility.

For any other kind of page, the validity of information can be easily checked, since it's mostly software related, so anyone can test if our advice is still applicable. For a hardware page, unless contributors have scrupulously linked relevant bug reports, no one without the hardware can prove the content is outdated.

I will also point out that as opposed to a trial, no one is losing their life if an un-used laptop page is archived, and if someone is interested they can pull the page out of the archive to update it.

Maybe we should find a way to enforce Help:Style#"Known issues" section more strictly for laptop pages? --Erus Iluvatar (talk) 15:24, 25 January 2023 (UTC)

An other possible solution would be to ask for user contributions on our forums or even though unofficial communities like Reddit, stating we have accumulated more than 400 ancient hardware pages and would appreciate if people who still own the hardware have the time to post a http://linux-hardware.org/ probe with a quick confirmation of what does or does not work in the talk page ? --Erus Iluvatar (talk) 15:32, 25 January 2023 (UTC)

This is a good idea to increase the engagement of users. But after this activity, we still should not delete a page if no one ever update it. Only archive it by the content, not by how long not updating.

Verifying that the information we provide is up to date is everyone's responsibility.

This is exactly what I want to highlight. Every page is the Collective Intelligence of the community so if some user(maintainer including) do not have the hardware, just leave it. Let who do have it to help verifing. If no one in the community has the hardware(very hard to tell), it means the Collective Intelligence do not have the information. Maintainers should not be blame for this. But there is always a gap betweeen knowledge of Arch community and ArchWiki. This is what a maintainer should worry about the most. So if:

• A user find a issue and add a section in the page, it is reverted because he do not find or add a bug report. (Enlarge the gap -1 from me).
• A user find a issue he want to add it to the page, find it is somehow archived and open ArchWiki:Archive. He do not know if he could recreate the page or not. He just leave.(Enlarge the gap)

--Fengchao (talk) 00:53, 26 January 2023 (UTC)

We're a community project : I would jokingly suggest we might not want to pick up documenting manufacturer's hardware when even they stopped supporting them :D

From what I know, linux kernel support hardware much longer than a manufacturer does. It is one of advantage of opensoure. So we should just follow upstream (kernel/opensource driver). If a kernel or opensource driver remove support of a device, we could archive the page dircetly. --Fengchao (talk) 14:30, 26 January 2023 (UTC)

Hence why I said "jokingly" :P I'm very happy to have hardware long outlive the economically viable duration its manufacturer designed it for, thanks to the open source movement. I will point out that we don't support i686 hardware for example, even though the kernel still supports it. This discussion would become moot as soon as we begin requiring x86_64-v3 for example. --Erus Iluvatar (talk) 17:30, 26 January 2023 (UTC)

On a more serious tone, as with every community project, contributions are interest-based, pages are created and archived regularly. While I completely understand that most people on this topic are opposed to a purely time-based archival (I mean, who has not met a pesky bot on some project's bug tracker who automatically closed every inactive issue regardless of the status of the bug), I also see that in most software project, things are allowed to die, as opposed to stay in limbo forever. We too, should act as our software landscape: hoarding out of date content is not our mission, and every scrap of decade-old page does not need to be considered valuable without the shadow of a doubt.

You mix time based judgement and content based judgement. decade-old page - Time based. considered valuable - Property of the content. Some content is still valuable for the device user. Many users including me have a more than 10 years old laptop that works perfectly in Arch. If the page only contain general info, it is not valuable. But if the page contain a specific acpi parameter or special firmware requirement, it is valuable to those hardware user. --Fengchao (talk) 14:30, 26 January 2023 (UTC)

And yet, you were the one to point out earlier that a common trend ends up at "After years, all funcitons just works without any specific actions so we could just redirect the page". The only issue we are having is that you see me redirecting old pages as purely time based, while my reasoning is that after enough time, the page content is no longer relevant, even if I do not have the hardware to test it. I do agree (even if do not like it) that a page that is clearly providing unambiguously relevant content must stay, even if it has a poor style. --Erus Iluvatar (talk) 17:30, 26 January 2023 (UTC)

No one is to blame about the current situation, that's just how things have naturally evolved, but now that we have "shed the light" to the "dust in the corner", we should try to find something adequate to do about it instead of letting it stay there and pile up.

A good example of regular cleaning is the AUR Cleanup Day, where users are encouraged to point to obsolete packages that can safely be removed.

ArchWiki and AUR has very different develop and maintain model. An AUR package is personal owned but a wiki page does not. If no one take up the owner of the package, it should be removed. But if no one take up ownership/edit a wiki, it should be kept. See the difference here? --Fengchao (talk) 14:30, 26 January 2023 (UTC)

As far as I know, orphaned package are not systematically removed. Also, while AUR packages have a "maintainer" (which does not own anything), one can request that a package be orphaned if said maintainer does not update it. When one maintainer deletes all his packages, people can pick them back up afterwards. Our pages do not belong to anyone, which on one hand is great since if someone wants to update a page then can simply do it, but on the other hand for laptop pages this is rarely possible without the hardware, so we are stuck with pages rotting away. I do not think the two situations are so different. --Erus Iluvatar (talk) 17:30, 26 January 2023 (UTC)

Just by our registration captcha, friction to entry is already high and "enlarges the gap" as you say: would you want to get back to manually handling the regular spam attacks? As with everything, we have to find a balance between a fully open approach and a fully curated experience.

I agree with you here. If my memory is right, there were many -1 for current captcha. So I hate those spam attacks, their damage here is much larger than most think.--Fengchao (talk) 14:31, 26 January 2023 (UTC)

As asked in the other topic above, If "no one notice or no one care", why keep the page? If we can assume the hardware works, why should we keep outdated workaround?

"no one notice or no one care" - It is a history state. Maybe no one notice or no one care now, but someone may come up in the future. If the page is gone, the possibility of someone come up is lower. So for below choices, I select 2.

1. Some page is not updated in 10 years. Archive the page.
2. Some page is not updated in 10 years. Keep the page as long as no one report issue of it. If someone does find some issue, he could just edit the page right away instead of dig the history of a Archived page.

--Fengchao (talk) 14:31, 26 January 2023 (UTC)

With that reasoning, once no one has the hardware in a working state, no one can edit the page? The content of the page is not lost when we archive it, but that is where they belong once they reach the "history state". --Erus Iluvatar (talk) 17:30, 26 January 2023 (UTC)

No, many time it could still be updated, for example by a contributor very familiar with the issue. There are different severity level of out of date. For a troubleshooting section（which should be the main part of a laptop page), an out of date trouble shooting section will do much less harm. Readers do not have the problem so they do not take the solution. They just skip them. If the problem is still valid, they will benefit. So if no one is currently sure if it is out of date, just keep it. Trust the readers. If they are bitten severe by an out of date section, most of them will report the issue. What I am trying to convey here is that stall is really not a big problem. In my mind, the most active edited page need more attention, it means readers need is still not fulfilled. --Fengchao (talk) 13:52, 30 January 2023 (UTC)

I would very much like to avoid having our readers being "bitten severe by an out of date section", that's the whole reasoning behind wanting to archive presumably irrelevant content. As you pointed out yourself for user pages, this can be compared to technical debt on a software level and will have to be dealt with some day. --Erus Iluvatar (talk) 14:57, 30 January 2023 (UTC)

As long as it is indeed a debt. Anyone could mark questionable sections and delete them later. We could do below actions to impove the situation:

1. Encourage contribution to general topic instead of Laptop page.

2. Only add solution for what does not work.

3. Encourage report latest information in talk page.

But time based remove/archive is too aggressive. It is not suitable for wiki document.

--Fengchao (talk) 13:23, 22 February 2023 (UTC)

And yet, we have pages that still reference rc.conf or rc.d that were not marked until I got to them last year.

For 1 and 2, I think that's already what we ask (see Help:Laptop page guidelines#General).

For 3, it's the same issue as why I consider them "debt": after enough time has passed, we encounter the usual issue of people now coming back when/if issues are fixed upstream instead of worked around. I don't see an easy way to tackle that. The simplest would probably be to require a bug report with every workaround, but IMO that's already asking a little much from our contributors (i.e. not every wiki writer has the time or knowledge to debug an issue with the upstream).

I'll say it again, with a large enough time buffer (we're talking about multiple years here, not archiving a page a few months after the end of the manufacturer's support) and the requirement that the page has stayed inactive for the whole duration, no major downsides are apparent to me. Laptop pages are by their very nature limited in time, as opposed to software which stays working and used as long as there is anyone interest in maintaining it.

--Erus Iluvatar (talk) 14:32, 22 February 2023 (UTC)

How would you defind inactive, if a page fulfill user's need and no edit is needed, would you treat it as inactive? --Fengchao (talk) 09:45, 26 February 2023 (UTC)

See the proposal from #Old hardware pages draft: pages that have been flagged with Template:Laptop style and Template:Out of date, have not seen any content update in the last 5 years (i.e. we do not count style or typo fixes as being an update) and have not been updated for 1 year after flagging (again, not counting minor typo or style fixes). --Erus Iluvatar (talk) 10:22, 26 February 2023 (UTC)

Then we must determine whether if a page could be flaged by out of date just by its time and noted as ancient. Like this one. Combined with above proposal it is a remove by time rule. So I will give -1 to above flag. A page should only be flaged as out of date because of the issue with the content, not just because it is ancient. --Fengchao (talk) 13:01, 27 February 2023 (UTC)

What a great example you've picked! The page only describes 3 topics:

• outdated acpi_osi and acpi_backlight workarounds that should be irrelevant since those fixes are upstreamed eventually,
• a network adapter bug that has been solved for ages: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/557048
• a random xorg.conf dump for the obsolete synaptics driver.

I should have spent 15 more minutes on the page to add more explanations in the out of date flag. I've flagged it for merging today.

To quote what you said before in this exchange: "After years, all funcitons just works without any specific actions so we could just redirect the page". Call that "remove by time" if you want, but these ancient pages provide no relevant content to the readers a decade later. What suggestions would you make to avoid them staying un-cared for?

--Erus Iluvatar (talk) 15:08, 27 February 2023 (UTC)

Yes. Merge by content is great. Archive by inactive time is not.

We could add a Note says something like "This model is very old. Please leave a note in talk page if below special actions is not needed anymore.

--Fengchao (talk) 01:57, 28 February 2023 (UTC)

That's what flagging with a Template:Out of date was intended to do, raise visibly on the page that the content has been written many years ago but never checked since. If no one can help with the content for a year after flagging, it's usually there is no one to do so, what then?

--Erus Iluvatar (talk) 06:59, 28 February 2023 (UTC)

For now, I'll stick to merging old pages to the respective vendor model tables if they provide clear enough information on the status of most required items but do not contain anything else requiring a dedicated page, while leaving the pages with too little content to be dealt with later.

--Erus Iluvatar (talk) 07:28, 26 January 2023 (UTC)

Audio mute LED

Regarding 'reloading the module without rebooting', the right way to do this is systemctl isolate emergency.target, but this currently fails because sulogin does not allow root login when the root account is disabled. If this problem gets resolved, feel free to update the page and delete this note. —This unsigned comment is by PBS (talk) 11:28, 14 November 2021 (UTC). Please sign your posts with ~~~~!