LaggyKar

Yes, using KDE Connect, which has had this functionality for ages. Though you’re best off using the F-Droid version since Google has severely limited the Play Store version using SAF. Seems like they’ve they’ve given Microsoft a pass here even though they’ve blocked KDE Connect from doing the exact same thing for years.

It’s 401 unauthorized or 403 forbidden, not 403 unauthorized

Harvesting IP addresses shouldn’t be a problem, since the firewall shouldn’t allow packets from a peer you haven’t talked to first. But true, if you can be attacked in response by a server you’re connecting to that would be bad.

This would presumably mainly be an issue for computers open to the internet. So not so much for home PCs, unless the router’s firewall is opened up.

How would that bypass the firewall?

This TV Streamer costs significantly more than a CCwGTV combined with an adapter.

Apparently so it does, and it says “HDMI Freesync” rather than “HDMI [2.1] VRR”. FreeSync HDMI is a completely different protocol and is supposed to work under Linux. Found a thread here, can you try cat /sys/kernel/debug/dri/0/HDMI-A-1/vrr_range and edid-decode < /sys/class/drm/card0-HDMI-A-1/edid? Though there is no solution there.

I thought that there was VRR support over HDMI even for versions below 2.1 spec.

Yes, there is FreeSync HDMI, which is supposed to be supported on Linux, and which is unrelated to HDMI 2.1 VRR. Don’t see anything about the monitor supporting that though (LG 24GS60F based on your previous post). Nor anything about HDMI 2.1 VRR, it probably only supports VRR via DisplayPort Adaptive Sync.

Until services stop supporting it.

None of which changes the fact that it’s more expensive and clunkier, and none of which feels necessary.

You can get an Ethernet adapter for the Chromecast

A more expensive, clunkier product, with a bunch of needless fluff in it.

So you need to change two settings instead of one to side load. Seems rather pointless.

If you develop on windows, Adoptium.net will give you prebuilt openjdk.

Only if you know it exists. It’s not something that comes up when searching for it.

It’s better in one way, in that updates are applied on reboot rather than pulling the rug put from under running applications. But I agree that it doesn’t go all the way, as it doesn’t provide a verifiable base system with clearly separated modifications. OSTree would be great.

Another possibility would be to distribute a base image as a btrfs send stream (possibly differential against previous versions) containing a compose-fs image and associated files. And then OS extensions could be installed with systemd-sysext.

Oh, I thought that was just a grouping

What’s the difference between case 2 and 3? Those look the same to me. The three cases look like:

• ¬complete ∧ ¬cancelled ∧ ¬null
• (¬complete ∧ ¬cancelled) ∨ null
• ¬(complete ∨ cancelled) ∨ null

Figured I’d do the math on the power required.

In the article, they show a iPhone 15 Pro, which has a 3274 mAh battery, so let’s go with that. Assuming a 3.7 V battery and a 1 minute charging time, that’s 3274 mAh × 3.7 V / 1 min ≈ 727 W.

I used to use it, but then I switched to MPV, as it works a lot better with hardware acceleration. MPV supports more methods for hardware decoding (e.g. nvdec), and also MPV will keep the frames in VRAM when doing hardware decoding, and do additional processing and presentation using the GPU, while VLC copies everything back to system RAM and processes the frame on the CPU.

At the time I switched hardware decoding with copy-back would actually result in twice the CPU usage compared to software decoding, but that was a long time ago. Also, I would get tearing in VLC and not in MPV.

You’re right, that might work