A SCSI scanner should at least be a standard so it shouldn't need device specific drivers...
An ancient SCSI scanner from the 80s or 90s should still work today, providing you have a working SCSI controller.

Much worse are the scanners with proprietary interfaces, or proprietary protocols over other interfaces (parallel, usb, even their own proprietary isa/pci controller cards). You may find your scanner wasn't actually SCSI at all if you had to get a specific controller for it, a proper SCSI scanner should work with *ANY* SCSI controller.

Noone is advocating raising prices. They're just advocating for quoting the actual price up front. You would end up paying the exact same amount, it's just declared up front instead of misleading you with artificially lower prices and expecting you to make up the difference with a tip.

Pronunciation of letters is different to the names of the letters...
Or how do you pronounce "what"?

This whole story is about CCTV, therefore NVR or cloud keys as these are where CCTV is hosted.

Having to use a different device in addition to the NVR defeats the point, especially considering a lot of users are on networks where they're forced to use the ISP-supplied gateway.

Even if the gateway does DDNS that's not relevant on a modern IPv6 network as the actual NVR device will have its own address rather than forwarding a port from the gateway address. Keep in mind that a good percentage of the world is stuck behind CGNAT so the gateway has an unreachable legacy address and home devices are only reachable over IPv6 (or not at all if the ISP is so lousy that they've not deployed v6 yet).

Not on mobile. At least when using an iOS device you get a message that video streaming is not supported, and forcing you to use the mobile app.
For other clients the web interface works directly.

There is discussion about the lack of direct connectivity in the mobile app here:

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fcommunity.ui.com%2Fquest...

The ability to directly connect is now available, but hidden away, and it doesn't validate the SSL certificate which introduces a security risk.

I'm looking at one hosting a small number of CCTV cameras right now.
You cannot configure IPv6 on the "cloud key" device or on the dedicated CCTV appliances, it just picks up an address from SLAAC/DHCPv6 but doesn't display it anywhere in the UI.
There is no DDNS support within the cloud key device. There may well be DDNS support if you're using their gateway, but that would be for the gateway itself not for the cloud key where the cctv is hosted.
With IPv6 every device has its own address, so you don't have to resort to multiplexing multiple devices through a single address (or not even being able to do that if you're stuck with CGNAT).
I don't use any of their routing products because the IPv6 support was/is very poor. We only have CCTV and wireless stuff.

Taking the best from everywhere results in a brain drain from the less desirable locations.
Losing their best people results in a country falling behind others.
You get a rapidly growing problem - the country is shit so people leave if they can, only the worst are left behind so the country deteriorates further.

They don't provide cloud *storage* but they do heavily push you towards cloud connectivity.

The mobile app did not support direct connections at all until recently.
Although now it does, it explicitly ignores SSL certs when connecting directly resulting in MITM risk.
Although the controller is reachable via HTTPS, it does not let you view video from a mobile device and forces you to use the app, this appears to be an arbitrary limitation as you can access it just fine from an ipad which is basically a large iphone.
Support for IPv6 is very poor (many users have CGNAT for legacy traffic so IPv6 is the only way to reach devices).
They broke IPv6 completely for a while - the HTTPS service did not listen on the v6 address even when the device did and could be accessed via SSH.
There is no support for custom SSL certs unless you use third party scripts, and the updates keep breaking those scripts.
There is no support for dynamic dns without third party scripts.

Until recently the only way to access the cameras from mobile was through the cloud service, you could access the device over https directly but then it wouldnt let you view video if you were doing so on a mobile device.

The mobile app still defaults to forwarding everything through the cloud, and although there is now an option to connect directly in the most recent versions it does so by ignoring the SSL certificate making you susceptible to MITM attacks.

Their IPv6 support is also very poor, and there are a lot of networks using CGNAT for legacy service so inbound legacy traffic is not possible. There is no option to configure IPv6 through the web interface, no mention of it at all, although the device will acquire an address via SLAAC and DHCPv6.

The controllers themselves don't provide an easy way to load a proper SSL certificate, although it can be achieved with third party scripts.

There's also no built in dynamic dns support which is needed if the ISP keeps changing your prefix.

What I need is something that supports SSL over IPv6, and lets me use a valid cert preferably providing an easy way to request one from letsencrypt or other such services. The unifi stuff can be forced to work with third party scripts, but they still try to push you towards their cloud service and you still have the security risk due to the lack of ssl cert checking in the mobile app.

The chance of someone capable of learning critical skills being born in switzerland is the same as anywhere else, if the swiss are not training their own citizens to perform these critical roles then that's already a failure on their part.

The unifi stuff leans heavily towards cloud, you can force it to do direct connections but its not the default and there are some limitations, and direct access for the mobile app is a relatively new feature.

A (proper) truck GPS will avoid roads that would be unsuitable for trucks, but would be fine for a regular car. This could inconvenience you at times.

No, it is "end to end" encryption exactly as they claimed - one of those ends is their datacenter where the data is processed.

As per the description from the linked blog:

The "chosen recipient" is Kohler's datacenter, so it's behaving exactly as claimed. The application functions by processing the data on their servers, which is also why a monthly fee is charged to provide the service.

You could theoretically avoid this by transmitting the data directly between the camera and your device, and doing the processing on your device, although that might not be practical

There are many much worse examples where data is routed through hosted servers unnecessarily, typically as a kludge to get around NAT restrictions.

Not mine, just astonishing relevant.

It's "licensed" when it suits them, and "sold" when it suits them.. Customer always gets screwed.

Any communication technology can be tracked - cell towers can pinpoint your location, hard lines obviously are laid to a specific address so the idea that your location can be tracked when your using a particular service is nothing new, and many governments already require the ability to locate an individual subscriber when presented by an appropriate warrant or court order.
A service which cannot pinpoint users would be illegal in many countries and would not gain regulatory approval.