Back in the day, I used to look up obvious spammers who had not yet edited in their links on stopforumspam's db and if I got both an email address and IP address hit I would ban both and delete the account. Never ran it server side. It could be quite labour intensive. Some sites simply get indundated, to the point where you need a few dedicated volunteers, those people eventually get bored or burn out and move on. And now there are"AI" scrapers, making sites unusable also.

Times have changed. A lot of people use VPNs for very valid reasons these days, there are also dynamic IP addresss as it is, so automatically banning using SFS is admittedly a bit brutal. I'm not altogether sure the level of traffic here warrants it, but it's up to those running the site. Usually these kind of countermeasures have some kind of message, informing the blocked user and providing some means of making contact? Is that the case here?

It's one of those problems which won"t go away - they use disposable email addresses, so banning only on email address is ineffective. VPN use also means banning IPs is also of little use.

The problem is the modern web - it's become a cesspool. Years ago, Tor and similar software, seemed like ideal solutions for privacy - then nearly every site you visit blocks you and after cycling through exit nodes for a time, most will give up.

So it's not actually stopforumsspam or this site's fault - it's the fault of the people/corporations who have collectively transformed the web into 99% shit.

That's more of a workaround. That error is amdgpu driver related. So the first step should be to compile a newer kernel to see if this has been fixed. There are usually newer kernels in backports, so if you don't want to compile your own, install the latest, reboot and test.

One of the "selling points" often parrotted by systemd fanbois was boot times. I was often told how fast it boots up, and I usually responded with words to the effect that actually it shuts down very quickly. You would gain more from just switching from a hard disk to an SSD if you cared that much about boot time.

All the talk of service supervision and boot times is just a "race to the bottom" against systemd. Stability, simplicity,code correctness, robustness and reliability are worth pursuing. Boot performance and a functionality to babysit and restart equally unreliable crap is not.

I have never needed to use runit or any other alternatives such as OpenRC. Technically both look pretty well designed to me, but the need has never arisen. At home I have always stuck to sysvinit or BSD init. At work I have had to use systemd and write unit files for anything running as a daemon. (would be nice to use one of those there, but it's not worth the trouble).

Personally I think the increased adoption of runit and OpenRC was driven by systemd's anti sysvinit propaganda. Some willingly swallowed this with the added "...but systemd is not the answer" clause. Others utilised it as a means of distancing themselves from the critique being directed at sysvinit in order to undermine it and establish systemd as the de facto standard. Those people who jumped ship and dumped on sysvinit did a lot of the damage in my opinion - they did the devil's work, by word for word repeating sysvinit's supposed deficiencies.  Apparently vindicating the systemd cabal in the process.

The harsh reality is that if you're just a desktop user, and not a server admin, you may see no benefits from something like runit, where the main focus is service supervision, except for perhaps slightly faster boot times.

Flatpak is Flatpack, but if you leave the c out it's way cooler and the fanbois love that...

gnome is a lost cause. I recently installed it in a Debian 13 system and it's truly a GUI designed by people who view their users as total idiots. It's developed from a proprietary mindset and is systemd focused, only a masochist would waste time trying to get it working on a systemd-less Linux distribution - bearing in mind that the upstream are constantly working against you.

The FreeBSD wiki has the same kind of countermeasures. The problem is "AI" scrapers. The maintainers of these pages want to keep AI agents out, to maintain acceptable performance.

https://forums.freebsd.org/threads/what … ost-727321

Historically, the oppressor, the despot, the tyrant, the dictatorship of the elites, has only ever been brought down by armed struggle. That hasn't changed. What has changed is how they remain in power under the illusion of democracy. While the proletariat sit by and do nothing, the ruling classes will continue to exploit them and grind them under foot. It won't happen in my lifetime, but eventually they will see the super rich, megalomaniac, psychopaths and perverts who rule over us for what they really are and it will explode. Hopefully in these times of doublespeak and hypocrisy, unjust wars and double standards, they are just beginning to awaken.

To elaborate: Windows 11 only requires that a PC be secureboot capable, it doesn't have to enabled:

https://support.microsoft.com/en-gb/win … 3abef64fad

We're all 100% stumped too.

Assuming you have already searched and researched, I suggest asking the libreboot people if there are any known issues with suspend on that model?

https://discuss.cachyos.org/t/age-verif … md/26316/6

Looks like one to avoid...

It's a slippery slope. Aside from embedded, systemd/Linux is the only Linux the corporate world cares about. Everyone who wants to avoid this will be compiling their own OS and building their own computer (becoming their own "vendor"), so this is once again, a "dragnet" tactic, which will gather up the vast majority of easy targets and force them into compliance. Corporate mouthpieces in Canonical, Debian and IBM/ Red Hat will spin it to the masses as a good thing, nothing new there.

I have a suspicion that age verification will begin in systemd, then there will be the usual push from the systemd crowd for key parts of it to be moved into the kernel.

Poettering and some other ex Microsofters recently started a new company "Amutable" - I'm not yet clear as to what Amutable will produce - i.e. what is the product, as the website if full of meaningless corpo speak babble - also not clear who is funding it all...

"We are building cryptographically verifiable integrity into Linux systems. Every system starts in a verified state and stays trusted over time."

Amutable looks to be yet another Microsoft proxy (similar to Xamarin). I.e. it's a group working on something which is better to be seen as not being a Microsoft project. That tells you everything you need to know.

Let's see if, ultimately technologies like secureboot and TPM are leveraged - then it will all become clear what this is about.