05-02-2025, 04:04 PM
(This post was last modified: 05-02-2025, 04:07 PM by Dendrocalamus64.)
Since Manjaro Stable hadn't updated in a year, I switched to Manjaro Testing about a month and a half ago, on March 14th.
The wiki has an article on how to do it:
https://wiki.manjaro.org/index.php/Switching_Branches
And I wanted to say nothing had gone wrong. But.
systemd has this truly evil feature, where the default configuration is for it to delete files in /tmp after 10 days, and in /var/tmp/ after 30 days, without any warning that your data is going to start disappearing.
I'd disabled this in Manjaro Stable several years ago, and somehow after moving to Testing this evil gremlin came back again. I lost a lot of files in /var/tmp that I wasn't done with after 30 days.
$ man tmpfiles.d
And I am supposed to know that by telepathy, right?
So I have copied /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and changed contents of the "aging" fields to "-" . We'll see if that keeps the gremlin off. But that should be the default.
And even wiki.archlinux.org now has a JS captcha, what the shit?
![[Image: eoagz0.png]](https://files.catbox.moe/eoagz0.png)
I don't want anything to be able to fingerprint my browser, especially by how it renders fonts. That's a browser bug that needs to be fixed.
And what is JShelter?
https://jshelter.org/
So Arch Wiki now requires support for "modern" features like "fingerprinting, tracking, and data collection".
The wiki has an article on how to do it:
https://wiki.manjaro.org/index.php/Switching_Branches
And I wanted to say nothing had gone wrong. But.
systemd has this truly evil feature, where the default configuration is for it to delete files in /tmp after 10 days, and in /var/tmp/ after 30 days, without any warning that your data is going to start disappearing.
I'd disabled this in Manjaro Stable several years ago, and somehow after moving to Testing this evil gremlin came back again. I lost a lot of files in /var/tmp that I wasn't done with after 30 days.
$ man tmpfiles.d
Quote:Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. Files in /run/tmpfiles.d override files with the
same name in /usr/lib/tmpfiles.d. Packages should install their configuration files in /usr/lib/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for the
local administrator, who may use this logic to override the configuration files installed by vendor packages.
And I am supposed to know that by telepathy, right?
So I have copied /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and changed contents of the "aging" fields to "-" . We'll see if that keeps the gremlin off. But that should be the default.
And even wiki.archlinux.org now has a JS captcha, what the shit?
Quote:Ultimately, this is a hack whose real purpose is to give a "good enough" placeholder solution so that more time can be spent on fingerprinting and identifying headless browsers (EG: via how they do font rendering) so that the challenge proof of work page doesn't need to be presented to users that are much more likely to be legitimate.
I don't want anything to be able to fingerprint my browser, especially by how it renders fonts. That's a browser bug that needs to be fixed.
Quote:Please note that Anubis requires the use of modern JavaScript features that plugins like JShelter will disable. Please disable JShelter or other such plugins for this domain.
And what is JShelter?
https://jshelter.org/
Quote:An anti-malware Web browser extension to mitigate potential threats from JavaScript, including fingerprinting, tracking, and data collection!
So Arch Wiki now requires support for "modern" features like "fingerprinting, tracking, and data collection".
