I am also in agreement.

What you have been witnessing  for the last 20 years or so, is the conflict between the users / hobbyists and lone developers - and the corporations who are now paying for most of it, hiring developers, making donations in return for influence and staffing "foundations" to better control of said projects.

Their business agendas and requirements are often completely at odds with the "UNIX philosophy" of building stuff that works reliably and is modular and simple to configure. Their end product is the opposite to what the tradional user has wanted since day one, hence the aim has been, through deceptive marketing and smears, to paint all of this as "progress" and those who oppose it as luddites. The moves to destroy RMS was by the same people, for the same reasons. For example we didn't hear much about the real benefits of systemd in the early days, we did hear a lot about how sysvinit was "old" and antiquated. Much of this came from corporate mouthpieces, and there were many users who swallowed it and became useful idiots. Some of these even joined the "sysvinit needs replacing" herd and embraced other alternative init systems - simply because they had bought into the "sysvinit is old" propaganda being produced by the systemd backers! Back then the roadmap for systemd was for distributions to abandon sysvinit and "trust" poettering in going ahead with adopting a complex, work in progress, mess, all based on a vague vision or idea. Or that's how it was presented on the surface.

We know that "Big Tech" has very little interest in making anything serviceable or configurable by the user / owner of the device. Big Tech produces locked down, black box stuff which phones home and functions as a surveillance and data mining engine.

Now consider that these very same people are paying for and contributing to Linux, systemd, wayland, Debian, etc. They are the investors in and of course the advocates of LLMs and are pushing code generated by these into the FOSS projects which they control.

Unless someone has the time, money and resources to fork the Linux kernel, the idea of forking everything is a pipe dream.

The BSDs port the Linux DRM/KMS drivers for Intel and AMD, and there is enough work involved there for a team of people.  Any Linux fork would be doing the same and would also be tracking Linux bugs and CVEs. I'm not sure a fork would achieve anything useful and its why others have looked into BSD kernels, but there has been no progress there either. Ultimately much of it is vapour and I have seen a lot of talk and not much else.

Personally I'm in a limbo situation with OS, where I will likely head back to OpenBSD after a 6 year gap...  I see little point in using Linux over Windows (likely as intended) and FreeBSD's slow move towards pkgbase has been something I have been pessimistic about now for a few years. I'm not alone, but as ever the naysayers are being shouted down by its patronising advicates. The way I see, as with the parrots who lined up to accept and promote systemd, they're digging their own graves. The FreeBSD "community" has also deteriorated over the years - that doesn't really seal it for me, but perhaps it's just that extra push, to aid in the decision making

It's not a fork.

Honestly, I think Devuan should just follow Debian's versioning and be done with it.

Less confusion all round.

Thanks for posting that.

It's a real pity that, apart from a few "conspiracy theorists" like me, that almost no one really cares...

His second note states very bluntly that Intel used his OS as a base to develop an Orwellian "spy engine", to place within every x86 PC.

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?