That seems like a bigger problem for Fire than it does Android TV. Android TV will continue to benefit from the smartphone and tablet ecosystem (which isn't going anywhere). If Fire breaks compatibility then it'll mean a worse experience for Fire users, but it's not going to affect Android TV users.
Although in practice I'd be surprised if Fire didn't continue to ship with an Android compatibility layer for exactly that reason.
Google still sell their own Android TV dongles (Chromecast), and big TV manufacturers still sell it as a smart TV OS (notably Sony).
Fire OS isn't Android TV anyway; as the article says, it's built out of an old fork of AOSP, and has no tie in to Google's services. I don't see that Amazon moving Fire products to a different base makes the slightest difference to the rival Android TV.
Depends on the business really. For my last employer (19,000 deployed PCs, lots of fussy mission critical legacy applications), 2 years would be cutting it extremely fine. For my current employer (30 employees, nothing more complicated than standard office applications in use), you could do the upgrade in a week.
I imagine my current employer won't be worrying about upgrading before 2025.
If you're after something for digital art this probably isn't it, but for note taking and basic handwriting it should be alright. They sell a specific active stylus themselves, so it can't be too useless.
Wine doesn't have any inherent overhead. It's a native reimplementation of the Windows APIs (and not an emulator), so there's no inherent overhead compared to Windows itself. It can be faster or it can be slower, but this has more to do with optimisation and implementation than anything inherent.
Have you tried running the CCTV software in Wine? It doesn't sound like it's likely to be a particularly complicated bit of software, so hopefully Wine will have it running with a couple of clicks.
Four nice sturdy nails placed strategically, pointy end up, immediately behind each tyre. Be content to know that justice will come when the time is right.
If your want something that just works, Ubuntu is pretty hard to beat. Snaps are really not a big deal anymore, performance wise; a lot of the bad rap on slow startups etc. are from years (and many versions) ago.
If you don't want Ubuntu and you don't like Mint, there are also other options in the Ubuntu/Debian family. Pop_OS and Zorin are both popular.
If it's something I think I'm going to reread, sure. If it's something to complete a collection where I already own volumes, maybe.
I read a lot of books from my local library. But like all underfunded local libraries, the selection is rather hit and miss; there are quite a few examples of series where they don't have the complete set. If I continue the series past what they have, I need to buy them. On a few occasions, I've gone back to buy the ones that I've already read just because it pains me to own a partial series.
But in general, I buy fewer books than I used to. Partly because money isn't as free and easy as it used to be, partly because my house is already full of books and I can't just keep buying them until I'm buried alive.
Some of them are more or less historic (for example rpm/dnf and dpkg/apt), where they were developed at a similar time by unrelated projects and have just carried on separately ever since.
Others have been developed to represent very different approaches (such as portage, which is based on the traditional BSD way of managing software by building from source, or snap and flatpak, which containerise applications).
The multitude of systems don't really cause as many problems as you'd think. As a rule, non-containerised packages need to be custom-built for each distro anyway, so it doesn't really make any difference which packaging tool is chosen by that distro. That is, you can't really take a debian .deb package and expect it to work properly on Fedora, even if you install dpkg/apt first.
Zip has a worse compression ratio than 7z, and that's a disadvantage for the average user (for example, a user with an email attachment size limit that they need to stay under).
If Windows natively supports one of the better alternatives, there's no reason to keep using zip. It's a 30 year old format, and it's something that regular users will happily just go with whatever's default.
It's currently on Android 11, which is 3 major versions (and 3 years) behind mainline Android.