Does this also upgrade easy to new Debian version like Windows does, via simple mouse click?

Debian does not do this, no. That's the "small amount of maintenance once every two years" that I was talking about.

However, I would absolutely disagree that Windows actually does this either. If a person who is not technically inclined upgrades to a whole new version of Windows, and everything works fine without them needing to get help with it, I would say that they've been lucky.

I appreciate that Debian has a disadvantage here, in that the new version happens every two years vs. Windows' semi random two to six years thing.

On the other hand, Debian has the advantage that it tries very very hard to never break in between versions. Windows 10 major updates, for instance, caused people a great deal of trouble, both by inadvertently introducing bugs and by intentionally changing the way features work.

Leaving all settings an apps (including app configs) intact?

I don't really understand this part, so I'm taking it as being about being able to genuinely upgrade in place (thereby keeping your existing files) vs. having to just do a clean install.

So, yes. Upgrading between Debian Stable releases tends to work very well. There are certain other apt distros where people tend to advise you to just reinstall, and this should not be taken as applying to Debian.

I said "a small amount of maintenance" because it typically goes very smoothly - I expect basically to skim the release notes to see if anything significant is changing, switch the codename in sources.list, apt full-upgrade, reboot, and check things seem to be working.

But if we're being strict, "all settings" isn't a standard that's actually possible to achieve. When you get a new version of certain applications (regardless of your OS or how your software is distributed), they perform some sort of migration on their config files on first run. Renaming config options, deleting options that are no longer available, etc.

To be clear, upgrading to a new Debian release does not delete your config files. But it comes with new versions of things, and that does mean changes. No solution for running the exact same software forever can be compatible with the security responsibilities which come with being connected to the internet.

I also have several elderly 70+ relatives with by far good enough laptops without Win11 support and do not want to drive a few 100 km to each of those relatives in my limited spare time just to upgrade to new Linux version of in this case Debian.

Well, whether to do an upgrade in person so you can fix things or whether to take a chance on doing it remotely is just a decision that one has to make. There is nothing about that fact which is specific to Debian or even to Linux.

Personally, I prefer to do operating system upgrades in person - if the system just doesn't come up normally afterwards, because of a weird hardware incompatibility or whatever, or even if my remote support software doesn't work right after the upgrade, I'd like to be able to debug that. It's not likely to break the machine, on a good distro, but people aren't happy if you just break their machine and then go "well, good luck with that, bye bye!".

Debian eases this somewhat by having a one year overlap, during which both the current Stable and the previous Stable release are fully supported.

I also don't think it's particularly practical to be the main source of tech support for family members who I don't see at least once a year. This is not just because of upgrades - sometimes people just do not know if, like, the printer is plugged in, or whatever, and you just have to say "I'll take a look next time I'm there".

Yes, this is exactly what tmpfs does (or, I suppose, ramfs - if you want to absolutely guarantee that those files stay in physical RAM even at the expense of system stability).

However, what exactly do you want this for?

so that I could access these files more quickly when performing I/O-intensive operations on them

When you read or write a file on a conventional on-disk filesystem, Linux keeps a copy in RAM anyway (in the page cache). This means, for example, that if you save a large archive to your downloads and then open it in an archiver application, and you have enough free RAM to hold it, then it is already in RAM and your archiver will open just as fast as if you saved it to a tmpfs.

As such, tmpfs is mostly useful if the file really is temporary, and you will not ever need to write it out to disk.

There is, perhaps, a more fringe use for it, which is when you're not going to do the second I/O-intensive task immediately after the first one, and you want to make sure that your data does not get replaced, in the page cache, by some other files in the meantime.

Using a tmpfs like this is equivalent to asserting that you have a better idea of what it is efficient to cache than the Linux memory management subsystem. The other I/O tasks you perform in the meantime may very well perform worse, because you have taken away some RAM that would otherwise have been used by the page cache. You may well be right, but you should be aware of that trade-off and check that it's actually worthwhile.

If you're able to do a small amount of maintenance once every two years, Debian Stable (with unattended-upgrades enabled) is great for this. Its whole deal is that, once it's working, it's supposed to keep working exactly the same.

A lot of answers here seem to have understood this as being about the macOS way of packaging applications in .dmg files and extracting them to individual directories.

However, if this is actually about how applications are presented in the GUI, then try PCManFM, a file manager which has a presumably macOS-inspired "Applications" option on its Places sidebar. PCManFM-Qt will probably fit in better on your Plasma desktop than the older GTK version.

EDIT: I wrote this a couple of hours ago and then forgot to press "save", so by the time I actually posted, it had already been discovered that this is a bug in the upstream Makefile (EDIT 2: my first edit incorrectly blamed the packager rather than the upstream authors - I should have read more carefully). I'll leave this comment up because I believe the note at the beginning is important.

I don't want to alarm you too much with this comment, and I do think it's possible that this is just a packaging error. But, with that out of the way...

A couple of comments in this thread have stated that it doesn't particularly matter that this is +x, since you can't actually execute a C header anyway.

I wish to state my strong disagreement with that line of thought. It is a potentially dangerous mistake to assume that a file's name is an honest representation of its contents. A shell script, an ELF binary, or any other type of data can be given a name ending in .h. Even if this particular example turns out to be innocent, this ought to be noted for anybody ending up here from a search engine in the future.

It's not uncommon for malware (typically cryptominers, these days) to be given a name that make it look like it's a normal part of the system. There have been a few posts here, over the past year or so, where it's been clear that that has happened. Admittedly, the examples I've seen have been owned by either the user that was tricked in to installing it or the service that was exploited, rather than installed in a way that implies root access, and they've been given filenames intended to be inconspicuous in a list of running process, rather than in a directory listing. However, I think this is still something that should be investigated.

(Apart from anything else, it's pretty easy for a process to change the way it appears in top. I haven't seen this so far, because cryptominers are generally deployed with the very lazy camouflage of simply renaming a binary that wasn't even designed to run without the machine owner's knowledge. Having one name that blends in on the filesystem and another that blends in on the process list would be an entirely reasonable first step to take if one was designing a less lazy payload.)

I would start by investigating it with the file command, which will readily identify if it's a binary. However, I wouldn't trust the answer completely - I would also like to skim the file in a text editor. (This shouldn't take long: the real thing is only about 450 lines, and one doesn't need to actually read and understand the code to check that it legitimately looks like a C header.)

The reason I don't want to trust file here is that I do not know exactly how it identifies C source code (if anybody does feel like interpreting some magic, here it is). However, given that valid C preprocessor directives are also valid comment lines in a shell script, I wouldn't like to bet that it can't be spoofed. Again, this is pure speculation about what a malware author might choose to do, but it seems possible, to me, that it would be a surprisingly simple trick to pull off.

Apart from a malicious program deliberately concealed on your system, the other major possibilities that occur to me are:

• Filesystem corruption. Seems unlikely that this would be the first issue you'd notice, but who knows.

• User error. I can't immediately see how to make a chmod typo that affect this file in particular, but I could see somebody doing this as a desperate attempt to debug a failing build.

• Package maintainer error.

Regarding that last possibility, it would be useful here to know which distribution you're using. If this also affects other people's systems, it should be reported upstream to avoid worrying anybody else.

Also, it may be possible to check if the package that provides that file is actually installed, and even check if its contents match those provided by the package, but the relevant commands depend on your package manager.

On my Debian Unstable system, /usr/include/http_parser.h is part of the package libhttp-parser-dev. I installed it just to check, and, as expected, it is not executable. In fact, find /usr/include/ -executable -type f produces zero results. (I can't see why it should ever show results, but of course I do not have every -dev package installed.)

Are you completely certain that the kernel that's currently running is the same one that you're building against?

For example, could the bootloader be configured to load a previous kernel?

Check the running kernel with uname -v, and check the kernel image you should be using with file /boot/vmlinuz*. Ubuntu kernels include a build timestamp in the version string, and I hope Pop!_OS is the same.

FWIW, I have no idea why there would be a BPF- or BTF-related error with the module, as it's got nothing to do with BPF.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998716 may be of interest. #34 mentions that BPF-related metadata is now part of what makes modules incompatible between different kernel builds, and #49 shows somebody having what seems to be the same issue.

It really sounds as if OP is just trying to load a module from a whole different kernel version, but they say they recompiled it, so I'm at a loss as to what's going on.

Not really, no.

The problems happen because the kernel does not expose a stable interface to modules. When certain kernel internals change, the driver also needs to be changed.

The reason the amdgpu driver doesn't break on kernel upgrades is that it is part of the upstream kernel sources. This means that, when Linux kernel developers make a change that breaks it, they fix it themselves.

If the nvidia module just continues to be released as an "out-of-tree" module (i.e. a third party repo; not part of the Linux kernel sources), then it will still have to play catch-up when the kernel changes.

I haven't seen any indications that nvidia is trying to get this driver in to a state where it would be suitable for upstream. But even if they did, they've only open-sourced the kernel module. I don't think Linux kernel developers will be interested in adopting a driver which can only be used through a set of proprietary userspace libraries.

TL;DR: DKMS works until something changes in the kernel that means the module source needs to be changed too.

All DKMS does is automatically build the module against your new kernel. This is necessary because the kernel doesn't expose a stable binary interface for modules. (In some cases, it's also necessary because a module's licence is not compatible with the kernel's - in this case the module must be built on the user's machine because it's not legal to distribute in compiled form.)

However, the kernel does not offer third-party modules a stable interface at the source code level either. DKMS works when the kernel functions a module calls have not been changed in ways that would break compatibility. Sometimes those functions have been changed, so the module needs to have some actual changes made to the source code to work on a new kernel. That needs to be done by a human software developer, not by DKMS.

But I noticed different countries in the EU also have varying interest rates

Well, that depends on what you mean by "interest rates"! There are a lot of different interest rates, but when people talk about just "the interest rate" in a country, they usually mean the interest rate at which that country's central bank lends to financial institutions.

In the Eurozone, that's the European Central Bank main refinancing operations interest rate (or "MRO rate"). The ECB is the central bank for the whole Eurozone, and it charges the same rate to borrowers in France, Italy, or any other country. Currently, the MRO rate is 4.5%. The MRO rate has a strong influence on the interest rate an ordinary person pays when they borrow Euros, so that rate is also similar across the Eurozone.

Eg. France LT interest rate is 2.82% while Italy's is 3.7%.

These are the current long-term interest rates in those countries, but the phrase "long-term interest rates" relates to the trade in government-issued bonds, not to borrowing from central banks. These numbers do not represent an actual arbitrage opportunity.

You can indeed invest Euros at 3.7%, simply by buying Italian government bonds. However, you can't borrow Euros at 2.82%, not even in France. 2.82% is the return a lender would get by buying an asset that's guaranteed by the French government, so if they agreed to lend to you at that rate, it would mean that they thought you were at least as reliable (i.e. unlikely to default on repayments) as the French government.

The cost to you of borrowing Euros is, inevitably, going to be something over 4.5%. Think of it as the MRO rate, plus however much profit the bank thinks it can make, plus a factor based on how risky the bank thinks you are.

(Note that, in the previous paragraph, I am talking about a very short-term loan. It is sometimes possible to get long-term credit, such as a five-year fixed-rate mortgage, at below the current central bank rate. All this means is that the lender is betting that the base rate is going to drop far enough that they're coming out ahead before the end of the contract.)

App Images aren't distro specific

They depend on the system libc version, which can cause problems with sufficiently old distros.

More importantly for this post, distros promoted as "lightweight" sometimes use alternatives to glibc.

There is absolutely no run Fornite on Linux and play on normal servers.

This is not a compatibility issue, and there's nothing that can be done about this from the Linux end. There are other EAC and BattlEye games that already work just fine in Proton. However, the anti-cheat in Fortnite is intentionally configured to keep Linux players out. Tim Sweeney himself has confirmed this.

It may available through one of those cloud gaming services, (i.e. it runs on some server somewhere and streams the video you) but you're not running it on Linux, on your own hardware.

So what now?

That depends on why you are running such an old distro in the first place.

For instance, do you have specific compatibility issues that you're trying to work around? Or is it just resistance to going through with the upgrade process?

If you're not constrained by some sort of compatibility thing, the obvious choice is to just do both upgrades now, so you've got that out of the way and don't have to do it again as soon.

(Plus, Bookworm is a better distro! Both because of two years of improvements and in terms of compatibility with software designed for modern systems.)

Those look incredible!

What type of flour is that please?

There doesn't seem to be a proper metapackage, but they do have installation instructions for Debian on GitHub.

The capability is usually set by a postinst script. It's possible for it to fail if the configure stage of an update has been blocked, e.g. by power failure or by other broken packages.

On the other hand, your log doesn't appear to show ping being upgraded, and iputils-ping hasn't been changed on Stable since Bookworm was released...

Commands that might show something interesting:

# which ping have you got?
apt policy inetutils-ping iputils-ping
# is the postinst working?
apt install --reinstall iputils-ping

Train them by giving them food when they pick the right colour, then see how similar you can make the colours before they stop picking the right one.

https://www.researchgate.net/publication/259883148_A_Different_Form_of_Color_Vision_in_Mantis_Shrimp

uBlock Origin.

(The inferior adblocker that's just called "uBlock" still exists, although I'm not sure if it even supports Firefox any more.)

50% isn't really acceptable. Unless you deal with RO water and it's sometimes 2 and sometimes 3.

I did test with tap water instead of nutrients, but it's pretty hard water. I got, for example, 0.65 mS/cm and 1.0 mS/cm from the same glass, just a few second apart.

Theoretically the bubble shouldn't be that big of a deal

I think we must have somewhat different theories about how the EC meter works...

I for example use an equally cheap EC meter, but that works well for me. Ebay 404465635798.

Anyway, thanks for the recommendation! I'd seen those ones around, and I was wondering if they were legit, partly because of the price.

I bought a combo like this on amazon for about 24€. The PH-meter broke after 2 years. Never had any issues with the EC-meter though.

Thanks! Does that photo show the same brand that you've got? I've seen that style of meter sold with various different brands, and (like BallOk8356 says in this thread) I'm not sure whether it's just people rebadging stuff from the same manufacturer, or whether there are inferior copies around.

Shaking/stirring the meter in the solution before you take the measurement should help you getting rid of the airbubble.

As I said in the post, I've tried this! I think the reason it's not working is that the slots in the plastic just don't come up high enough to let the air out on mine.

[Image] 

Edit: Also calibration helps if you get different readings all the time.

It has a calibration screw on the back, but as far as I understand, this should be for fixing inaccuracy rather than imprecision. Like, if it was consistently reading 20% over the true answer, I could calibrate it, but I don't see how it can fix a random error.

Maybe I could install a lightweight distro like Lubuntu, and then go from there?

As far as I can see, that's just "starting a real Xorg server" with extra steps. (Unless Chrome really can't run without those dbus services it's trying to call!)

I just tested that locally and Lubuntu seems to be doing the job.

Whether it works on DO will depend on whether Xorg works on DO.

I edited the previous comment a bit after you had already read it - sorry about that.

Are you quite certain Chrome needs to be headful? If you mention the problem you had with headless mode, somebody might be able to find another way around it.

Why exactly do you need Chrome to be headful?

For example, is graphics performance going to be important? If not, you could try --disable-gpu.

If you do need fast graphics, and your machine has a GPU, you could try starting a real Xorg server instead of Xvfb (or a simple Wayland compositor - since you presumably only want to display a single window, Cage may be appropriate). You do not need to install a whole desktop environment to do this.

(How easily this can be done without physically connecting a monitor depends on the graphics driver - on some cards, you can just set an option in Xorg.conf to make it pretend there's a monitor, but on some others you kind of just have to get a dummy plug.)

Are the locations of this sort of thing planned and announced in advance? Is there any way to see them other than luck?