Talk:Laptop

From ArchWiki
Latest comment: 25 January 2023 by Erus Iluvatar in topic Old laptop pages

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)Reply[reply]
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)Reply[reply]

systemd-tmpfiles

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

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)Reply[reply]

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:

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
+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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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.

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 ~~~~!Reply[reply]