With the number of vulnerabilities found in this over the last three years, it may be better to direct your concerns to the upstream project itself rather than Debian.

https://www.cvedetails.com/vulnerabilit … oject.html

Currently, the backports version is the same as the version in unstable, so the solution seems to be to install the bacports version and follow that. I thought it was commonly known that, with few exceptions, Debian "freezes" packages at a specific version and any security patches are backported as necessary. So any newer version will never  be available in stable. As it stands, there is no DSA for this as yet. You would have to search the mailing lists / ask the maintainer.

What many of you fail to realise is that it's all for profit. "AI" is just the last product from Big Tech, it is being heavily invested in, it's a bubble and it will burst at some point. It exists to make money for shareholders. But the immense amount of hype surrounding it, means that your boss is slowly becoming convinced that it can do your job. It probably can't - or maybe it can do aspects of your job well enough, that you can be laid off. You can then run along and babble about "AI" geing a great "tool", while the billionaires laugh at the real "tools" who bought into it all.

As Altoid said, it will run amok, because as with everything else, the risks are all acceptable, and the "running amok" is actually part of the plan - we're now at the stage where the big players want it regulated, so that they can maintain ownership, control and exclude competition. To be seen as viable "AI", and boost share value, LLMs are going to need be "headline news".

I can probably guess why that thread was closed, the mindset behind closing it, etc, but that hardly matters. As you're really just promoting the other site after all. It's all very silly and juvenile, but typical of Linux forums, where there's lots of drama and chat and conflict.

This site was always about one individual imposing their will and ideology on those they regard as inferior and misguided - i.e. the Devuan users / other people in general.

The other site mainly consists of a group of "can do" oriented people who don't seem to have any clear direction. In my view it's a "talking shop" and in particular an echo chamber for one individual (a staff member) who can't tolerate any opinions that don't match their worldview - would be good if they proved me wrong. I suppose we'll find out. But yes, not so different to here really. Most people start these types of sites start with the best of intentions, then the cliques form, etc.

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.