The filesystem metadata is not fully rewriiten by a kernel update. I assume from your post that you don't know what it is? It is the information relating to files and directories which is not part of those objects data. This includes things like file sizes, modified date, file permissions, etc. There is nothing which should be rewrilting this. It's read by those utils you mentioned.

Utils such as df, just read this metadata, so I would suggest that you're barking up the wrong tree. The metadata  won't have changed between boots/kernels.

So far all of your responses have been "already done that" with no real specifics. The big question is : Booting from that 6.1.176 kernel apparently frees up 400MB which is then lost when reverting to the previous 6.1.174 kernel. But how are you doing that? You need both kernels installed simultaneously. Then you need to reboot into each and check. If you're doing any package management operations between each boot, this obscures your results.

Does booting from any newer kernel also free up this same amount of space? Does the latest stable kernel give the same result? Does the latest 6.1.177 kernel also apparently free up 400MB.

In all tests, are you booting single user mode and comparing all results there?

Have you compared the sizes or kernel image, initrd, kernel modules for each?

Or cut out the drama, get the previous kernel and boot from that.  Also install the latest stable kernel and boot from that - compare the results...

If you were to report a bug, those are the kind of steps which would be expected as a bare minimum.

"I don't know squat about writing man pages though, the raw format is weird. Seems like they could have just used .txt files."

As in a MS DOS / Windows format?

EDX-0, you missed the point, then went off on a tangent.

They're rewriting in rust, and the replacements are permissive licensed, rather than GPL. There are those still in the GNU/Linux camp who aren't comfortable with that and would question the motives. This has nothing to do with the licence of similar utilities in any of the BSDs.

Also: https://learn.microsoft.com/en-us/windo … s/overview

sysvinit is still maintained. Until it's no longer maintained, it will still be around. Is it any good? Is anything? Is vi any good if you love emacs? It worked for years, it was versatile and you had the freedom to use it or not - and if you wanted e.g. service supervision, you installed and configured something to do that.

You could say the same for C - it's ancient, but still used for all meaningul systems programming. Other languages have come and gone, some have lingered around, but theyre used for application programming. Look at Qt for example, it's written in C++. Also there's the likes of C#, java and (I hesitate to mention it) rust. It took over 30 years to get the Linux kernel and BSD kernels to get to where they are now. Similar with the NT kernel. No one is going to commit commercial suicide and rewrite these in the latest fad language. It's the same with sysvinit - you can write as many init replacements as you like, but unless one comes along with clear technical merits which leads to widespread adoption, people won't switch. That's why the corporate backers of systemd used a clear strategy of funding/hiring to get distributions to move - to a solution which, at the time, wasn't very mature and had an awful lot of issues.

One of the pillars of free software used to be freedom of choice - so someone could work on a project, they and others could use the result, without people calling for it's obsolescence or sneering. The corporations had a lot of willing useful idiots to assist with this.

The first step is:

% man man

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.