It seems that 18.04 was the last release for 32-bit x86 (i386): https://askubuntu.com/questions/1376090/latest-version-of-ubuntu-for-i386-architecture-32-bit

But you could just go for Debian which still supports it.

This seems very one-sided. Sure, the disclosure was not handled perfectly. However, this post completely ignores the terrible response by the CUPS team.

The point on NAT is certainly fair and prevented this from being a much bigger issue. Still, many affected systems were reachable from the internet.

Lastly, the author tries to downplay the impact of an arbitrary execution vulnerabilty because app armour might prevent it from fully compromising the system. Sure, so I guess we don’t need to fix any of those vulnerabilities /s.

This article is conflating terms that I need help distinguishing between. The other commenter mentioned that Ubuntu is a type of Debian but this article lists Debian and Ubuntu as distributions.

I’d say that the article is correct in calling them separate distributions.They are certainly related (both part of the Debian family), but I think most people would consider them to be separate distributions. Software built for Ubuntu 24.04 may work on Debian 12, but it might also not. For a beginner, I think it’s most useful to consider them to be separate things.

It sounds like a weird idea at first, but maybe it could actually work. Kind-of like running two trains on top of each other instead of after each other. I guess the downside would be the need for bespoke rolling stock and larger platforms. I think, it would generally be preferable to double the frequency or run longer trains. But it could be interesting if you’ve already exhausted those.

The main downside of double-decker train cars is the time it takes passengers to to board them. And, since this is one of the main factors limiting metro frequencies and thus capacity, they’re not that suitable for subways. To maximize metro capacity, you want long trains with many doors and very high frequency.

Double-decker cars are much more suitable for lower-frequency service (S-Bahn, regional, long-distance,…) where they’re also commonly used.

Of course, you could still use double-decker cars in a metro (and maybe some places do), it’s just suboptimal.

I think when I messed it up, it worked when I tried switching to the proprietary drivers for the second time. I think you can try that without much risk.

In my case I ended up disabling Secure Boot anyway because it just got too annoying (a BIOS update breaking it was the final straw for me). The security benefit after you’ve enrolled a MOK seems dubious anyway. It would be nice if distros could ship signed kernels with the open-source Nvidia driver but I guess that’s not happening.

No, they’re almost entirely unrelated. Almost all CPUs will idle close to 0 W (with correctly working drivers). The main idle power contribution comes from the mainboard and other devices (e.g. disks). The Mini PCs you mentioned should have a very low total idle power, probably below 10W.

Check out Wolfgang on YouTube, he has some great videos on the topic: https://youtu.be/Ppo6C_JhDHM

I’ve also recently built my own NAS and I’ve gone through similar considerations. One of my mayor decisions was not to use btrfs because it’s not recommended for Raid Z1/Raid 5. With that, I landed on ZFS and TrueNAS Scale. Note that RAID expansion should be landing in both very soon.

Things with TrueNAS were pretty easy, very quick, and everything worked nicely. However, I noticed that it was constantly accessing the disks and preventing them from spinning down. I really wanted to keep the power consumption low (<20 W idle), so I eventually decided to just go with Vanilla Debian + ZFS. I can recommend that if you want to tinker with things yourself. Otherwise, I’d recommend TrueNAS Scale.

As for migration, you might be able to create a degraded pool initially, copy over the data, and add the parity disk last. Raid expansion would ofc also help there…

What kind of junk energy is there to harvest from a car (in meaningful amounts)? I guess breaking is the obvious answer, but that’s already covered by regenerative breaking. Most car-based energy harvesting systems seem to employ speedbumps that clearly take useful (kinetic) energy away from the car (probably at a very poor efficiency).

How would a turbine that takes energy from the air current generated by a passing car decrease the energy of the car?

Not sure where you got that idea from, but how would that generate a meaningful amount of energy? It seems very unlikely that such a system would ever recover the energy spent on its construction.

Sure, but those are completely different approaches. Dams have the advantage that they have a much larger capture area for water and that they can accelerate the water beyond the 10 m/s terminal velocity of raindrops.

Raindrop energy harvesting is a rubbish idea. The raindrops simply don’t have a meaningful amount of energy to begin with: https://news.ycombinator.com/item?id=36907674

Did you perform a full shutdown of Windows (Windows doesn’t fully release the partition on a normal shutdown)?

Edit: adding some context. I am planning to setup a dev machine that I will connect to remotely and would like to babysit very little while having stable and fresh packages. In the Ubuntu world we would go to an LTS release but on the RPM/Dnf world is there any other distro apart from CentOS Stream? And also is CentOS Stream comparable to an LTS release at all considering that they do not have release number?

Wanting both stable and fresh packages is unfortunately somewhat difficult in my experience. I think the primary choice within the Fedora ecosystem is if you want to have fresh packages (Fedora) or if you prefer a slower update cycle and more stable packages (RHEL/Alma/Rocky). In the second case you can also choose if you wish to pay Red Hat for support (RHEL) or not (Alma or Rocky).

One thing that’s quite different in RHEL vs Ubuntu/Debian ist that it gets minor releases that include substantial new features. For example you’ll get new compilers, python versions, drivers, … CentOS Stream gets those slightly ahead of RHEL/Alma/Rocky (a cynical person might say that CentOS Stream is a rolling beta for RHEL). But, IMHO that’s not really a strong reason to use CentOS Stream.

If you’d go with an Ubuntu LTS release, then I’d look into RHEL/Alma/Rocky.

The driver should already be installed but there seems to be an issue with brltty registering the corresponding USB ID when they shouldn’t. You can probably fix it by following this guide: https://koen.vervloesem.eu/blog/how-to-stop-brltty-from-claiming-your-usb-uart-interface-on-linux/ (or this one: https://unix.stackexchange.com/a/670637)

Edit: Perhaps this has since been fixed in Mint 21 / Ubuntu 22.04.

You can make this work using ext and Timeshift rsync. I have also opted to exclude /var/lib/flatpak/ because it’s quite large. With that, my 5 snapshots currently take up about 34 GB.

However, I would recommend backing up your deb applications/packages (typically installed under/usr), as those can be critical for your system.

This “new law” was passed more than a year ago… But, it’s still a step in the right direction.

Ja, ein Teil des Problems ist wohl, dass es deutlich einfacher ist, die Gefahren der Atomkraft zu vermitteln als das bei den CO2 Emissionen oder der Kohleverbrennung ist.

Jeder der nicht exakt der gleichen Meinung ist sofort ein Atomtroll?

Ich würde den Atomausstieg nicht auf ein Einziges Jahr beziehen, sondern auf einen Prozess der gut 20 Jahre gedauert hat. Wikipedia scheint das ähnlich zu sehen:

In Deutschland begann der Atomausstieg unter der ersten rot-grünen Bundesregierung (Kabinett Schröder I) mit der „Vereinbarung zwischen der Bundesregierung und den Energieversorgungsunternehmen vom 14. Juni 2000“. 2002 wurde der Vertrag („Atomkonsens“) durch Novellierung des Atomgesetzes rechtlich abgesichert.[120] In der Folge wurden am 14. November 2003 das Kernkraftwerk Stade (640 MW)[121] und am 11. Mai 2005 das Kernkraftwerk Obrigheim (340 MW)[122] endgültig abgeschaltet.

Der Punkt ist, dass Deutschland im Jahr 2000 ca. 170 TWh/Jahr an relativ sauberem Atomstrom produzierte. Diese Kapazität wurde schnell reduziert während die Erneuerbaren ausgebaut wurden und die Stromproduktion mit Kohle langsam reduziert wurde. 2023 wurden in Deutschland noch 135 TWh Kohlestrom produziert.

Eine alternative Strategie wäre ein Ausbau der Erneuerbaren und ein schneller Ausstieg aus der Kohle gewesen. In einem zweiten Schritt hätte man dann aus der Atomenergie aussteigen können.

Ich denke die zweite Strategie wäre sowohl aus ökologischer als auch aus gesundheitlicher Sicht eine bessere Wahl gewesen. Wenn man von einer Todesrate von 25 Personen pro TWh bei Kohlestrom ausgeht, dann hätte man mit den 170 TWh* Atomstrom ca. 4000 Tote pro Jahr vermeiden können! Aber weil die Atomenergie ein viel besseres Feindbild abgibt, hat man den Ausstieg aus der Kohle verschleppt.

*Ein Weiterbetrieb wäre aber wohl nicht bei allen Kernkraftwerken sinnvoll gewesen.