Coelacanthus

And snapshot can benefit backup. Since some software need to be shudown to do backup, minimize the down time is important. The snapshot can make down time is almost stop and restart time, and the software can be online again and we can do backup on snapshot in background.

For forecast, you can selfhost a Open-Meteo. But note this need a lot of RAM and storage to run the weather model.

https://github.com/open-meteo/open-meteo

HM-SMR works better than normal DM-SMR, but it’s rare and limit the filesystem choice: none on Windows and f2fs or btrfs on Linux.

Suggest use fsfreeze --freeze to block all access operation to create a stable image without unmount the SD card. (And release it later using fsfreeze --unfreeze.)

BTW, this feature was created by XFS and was moved to VFS in Linux 2.6.29 so all filesystems supported by Linux gained this feature.

1. Thread and Zigbee use the same physical layer and MAC layer (IEEE 802.15.4), so in most case it can use the same hardware and just with different firmware (if manufacturer want).
   There is even a project to run both Zigbee coordinator and Thread border router on the same chip. It works! Although it causes some issue so Home Assistant no longer recommand this “multiprotocol” way, but this is a strong demonstration of the interchangeability between Zigbee and Thread.
2. Thread Group members is almost the same companies who found Connectivity Standards Alliance (former Zigbee Alliance). When Connected Home over IP (CHIP) project was renamd to Matter at 2019, they create Thread Group to unify the home connectivity: Only use one network layer named IPv6 and one application layer named Matter. Zigbee can’t reach this target since it use its own network layer and application layer. So they invent Thread, which still based on IEEE 802.15.4, but with IPv6 as network layer and can transport Matter on it.

1. IPP Everywhere also include full autodiscovery stuff (mDNS and DNS-SD, of course, Apple call this combination as Bonjour). So I said raster is the only difference.
2. Raster is unimportant in Linux situation because CUPS support both PWG Raster (It’s actually a subset of original CUPS Raster) and Apple Raster. Whichever one your device supports, CUPS will work fine.

I think network printer made by big manufacturer recent years should be fine with IPP driverless. They found Printer Working Group of IEEE, this organization maintains IPP standard and IPP Everywhere™ Certification. AirPrint can be treated as Apple version of IPP Everywhere, the difference between them is AirPrint requires Apple Raster but IPP Everywhere requires PWG Raster (and JPEG JFIF file format if color printer).

https://www.pwg.org/ipp/everywhere.html

and even without it, you’ll get 150mA @ 5V by default out of the USB 3 host upstream and up to 900mA with some pretty basic USB negotiation in a protocol that dates from USB 1.0

That’s wrong. With USB Type-C, you can get the power up to 3A @ 5V with just two 5.1kΩ resistor on CC pins.

Oh. It’s great. But it seems there is only armv7a build on IzzyOnDroid repo while upstream has four architecture builds. cc @[email protected] Is it a misconfiguration on IzzyOnDroid side?

NVS 3100M has codename NV50 (Tesla), so you can see the feature matrix.
https://nouveau.freedesktop.org/FeatureMatrix.html
https://nouveau.freedesktop.org/PowerManagement.html
So you can see almost other things has been done but the power management especially Automatic Reclocking still unfinished. So the feature set and stability should be fine and the performance will be bad.

EDIT: I figured out that for whatever reason, the Flathub version just doesn’t function properly. When I install the tarball from Yubico’s website, the executable DOES work right,

It looks like because the sandbox of Flatpak prevent the program access the unix domain socket of pcscd.

but I can’t seem to figure out how to make the .desktop file install into the programs list.

There is a document on Arch Wiki.

https://wiki.archlinux.org/title/Desktop_entries

Without it, the program just fallback to UTC. /etc/localtime and $TZ are two ways to specify timezone for programs. The program look up the later first, if it’s empty and then use /etc/localtime. In theory, $TZ has better performance because of the glibc will not look up the last modified time of /etc/localtime when every calling of localtime lookup.

IMAPSync is a great tool! It works perfect when migrate mails from one provider to another. In fact, some providers suggest users use this tool rather than implement migration feature by themselves. e.g. Migadu.

In my opinion, that’s because X11 lacks proper abstract for many things like screenshot, screencast, color managerment and etc, so the applications have to use many X11 implementation details to implement these features. It leads to high-coupling code with X11 so move their code to wayland and ensuring it works correctly and is consistent with the old behavior is difficult.

I use Yubikey 5 NFC and Canokey Pigeon, both works out of box on Linux.