Hardware is tangible, software is intangible.

Hardware is physical elecronics: PCBs, ICs, etc.

Software is, when all is said and done, machine code, 1s and 0s.

To get a basic understanding of firmware, read up on EPROMs and EEPROMs. Nowadays "firmware" can be any number of things e.g. the OS of a printer, TV or network adapter flashed on to some kind of EPROM, but really it's still software. The "firmware image" which is flashed to the chip is a binary and thus software.

Historically, firmware was very simple code, often written in assember, to run with limited resources for a very specific taske - nowadays the Intel Management Engine OS for example, which was found to be based on MINIX 3.0 and a typical UEFI are very large and complex.

If you use google services, you will always be fighting this kind of thing, unless you allow their scripts, etc.

Your script / ad blocking triggers this and google tries to make it such a pain in the arse that you give up and disable it, to allow their content.

Google are in the advertising / profiling / data mining business. If you use their "free" services, then google want to capture that data. This is why those services are "free".

You were never going to get the source code for their, most likely proprietary, banking app. I'm somewhat surprised that you were ever under that illusion?

It's likely that a third party develop the app, and that your bank don't have access to the sources anyway.

Which desktop were you using to start with?

You don't seem to be requesting assistance in diagnosing the crashes, so I assume that you have that in hand or are willing to live with it - or you presume that this desktop is the root cause?

In case you do want to diagnose the problem, we would need more details of the crashes, when they occur, what's running, etc? Also what crashes? Is there a kernel panic or does X just segfault for example?

Is your desktop running under X or a wayland compositor? In either case, hardware acceleration can be a factor and thus GPU drivers. You would need to provide a lot more in the way of details...

Failing all that, it could be a hardware issue, as suggested above.

While I can understand their embracing of LLMs being a good enough reason to switch, syslog-ng is a product with proprietary and free versions, all hosted on MS github, so I'm not sure how long their current "on the fence" LLM usage stance will last:

https://www.syslog-ng.com/community/b/b … ent-and-ai

In the long term, providing a Linux distribution, whilst avoiding LLM generated code may become next to impossible, especially considering the Linux kernel and it's corporate contributors, who have no qualms at all in using it.

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