Americans can never call out human rights abuses because of slavery. The British can never because of colonialism. Period. Forever.
If you find this line of argumentation compelling there’s no discussing anything with you.
Americans can never call out human rights abuses because of slavery. The British can never because of colonialism. Period. Forever.
If you find this line of argumentation compelling there’s no discussing anything with you.
Using such a TV as a computer monitor sounds dicey. There will eventually be a data breach of the uploaded screenshots, assuming they aren't able to fingerprint entirely on device.
(Relatedly, there's an empty niche in the market for a USB-C power bank that can act as a UPS: able to charge and discharge at the same time without interrupting the discharge port when the charge port is disconnected)
I think there's a soft version of this already available. The term is "pass-through" charging. The power bank that I have [1] will charge itself and the devices at the same time (albeit at reduced rates suitable for overnight charging).
I agree that it would be super useful to have a device that is explicitly designed to provide maybe 5V/5A for a Raspberry Pi 5 without interruption, and perhaps double as a power bank.
That's not to say that a boost converter doesn't have value, but it still leaves a gap where there could be confusion.
The confusion or complexity even multiplies if the device has additional USB-C for data transfer. In that case, you either have to mark one port as being the "power in" port, or you have to support power in and data out on all the ports, which gets complicated and expensive.
It would be a great move by the USB IF to think through this sort of thing more carefully. Right now the USB-c connector is so overloaded in terms of power, display modes, thunderbolt, speeds, etc. that it's very hard to predict whether two USB-c devices will connect and at what power or speed and with what capabilities. For power, it would be helpful to require supplies to have a standardized status LED so that e.g. green means that the supply is providing the highest power allowed by the device (not the supply), yellow means there's been a compromise, and red suggests an error condition.
One big issue that came up (and killed the idea) is that if you are not battery powered, then putting a USB-C power input on your device that will only work if you can negotiate 12V+ with adequate current will just cause confusion. In my case, I don't think I could even boot to an error message on 5V.
Phones and the like don't have this issue, since they are still usable (charging slowly) on 5V, but can make use of higher voltages and currents to charge faster.
So I guess my question for the implementer is how booting & negotiating on 5V and then accepting higher voltage is likely to work in practice.
Saying that 2xRTT is a deal-breaker is like saying TCP in general is a deal breaker.
State per client is pretty simple. Use a bloom filter to decide if a client IP is ok for UDP, and slowly set bits to zero at random to force gradual eviction. With a secret nonce per server, the attacker can't engineer collisions except by controlling lots of IPs. For IPv6, just treat blocks above a certain size (e.g. a /48) as equivalent.
And again, this should be the default. Someone that is seriously trying to run an open resolver should have their own fork of the source code and adjust this as they need. The small-time operators that accidentally make their resolvers open won't notice a bloom filter or a slow initial lookup.
If this were the default on DNS servers, then DNS amplification attacks would be nearly impossible. They rely on spoofing a DNS request from the victim, and amplify because the response may be many times larger than the request. If TCP were required to be used before UDP responses can be received, then the victim would have to be first tricked into making a DNS request over TCP to each public DNS server.
The DNS Cookies standard (RFC 7873) doesn't do much to stop this, since it is impractical to fail queries from non-cookie clients.
DNS over TCP is supposed to be supported, so implementing this will push firewall admins in the right direction (allow both TCP/UDP outbound on 53).
I'm not sure it's fair to call reencodes expensive. Sure, its relatively expensive to using ffprobe, but any 4 series nvidia gpu with 2 nvenc engines can handle five? simultaneous realtime encodes, or will get up to near 180fps if it isn't being streamed. Our "we have aja at home" box with four of them churned through something like 20,000 hours of video in just under two weeks.
The PSNR/bitrate is much lower for HW encode, but the encode rate is typically realtime or better. That's a great tradeoff if you are transcoding so that a device with limited bandwidth can receive the video while streaming, or so that you can encode a raw livestream from a video capture or camera. It's not so great if you are saving to disk and planning to watch multiple times.
Other devices like an nVidia Shield or the XBOX require that you press power/home a couple of times to take control of the receiver and switch inputs.