Make sure you trust iHeartRadio! If you didn't before, start now!
planish
Thanks, Bezos. Thezos.
Why doesn't the new UDP torrent protocol use STUN or any of the server- or peer-assisted ways of punching a UDP hole between two NAT-ed endpoints?
It looks like you might be able to solve the second problem by pinning an up link?
The first problem is maybe that there are 2 bands to use here (5 GHz and 2.4 GHz), but you have 3 links:
- Device to last router
- Last router to middle router
- Middle router to main router
They can't all be on different bands, so if the links that are on the same band end up using overlapping channels, that can cut the maximum throughput down from what it would be for uncontested use of whatever channel width is used.
Also, one of these links is probably on 2.4 GHz. There's really only one 80 MHz channel there, and also you shouldn't just use the whole thing because your neighbors have wifi and you have Bluetooth.
Here's a good reference for channel capacity.
I don't think you are physically able to push more than 600 megabits through this setup, using all of 2.4 GHz and ignoring interference between the links. If you use just half the 2.4 GHz band, and you have to stop half the time while your neighbor and/or one of the other links in the system transmits, maybe you would get 143 Mbps? And Internet is indeed often faster then that now.
Maybe you can move all the links to non-overlapping parts of 5 GHz? But the wifi bands are only so wide and everyone has to share, so it's not really feasible to get them to push as much data as a physically isolated fiber or coax Internet link can physically do.
The C++20 or so STL actually has things in it now.
I'm struggling to understand how there can be so many security flaws, even in things that don't seem to matter for security. I think the bar for a security problem might be too low; a lot of these look like footguns that could give my package a security hole, rather than genuine security flaws in the packages they are reported on.
Here's a progress bar package with a "high" security vulnerability because it contains an internal utility that merges objects and doesn't stop you writing to the prototype. Did the progress bar package ever promise to provide an object merge function that was safe to use on untrusted user input?
Here's a notification UI element that bills using HTML in your notification messages as a feature. It has a "medium" level "XSS" security vulnerability where the message
parameter is not sanitized to remove HTML. A CVE was issued for this.
Here's an arbitrary code execution vulnerability in sqlite3! High severity! The bug is that, if you tell sqlite3 to substitute an object into an SQL statement, it will run the ToString()
method on the object. If an evil hacker has broken into your lead developer's house and written a malicious ToString()
method into one of the classes of object you use as a database query parameter, then that code would run! The fix here was, instead of letting the normal Javascript stringification rules apply, to hardcode all objects to be inserted into the database as "[object Object]", because surely that is what the programmer meant to store.
Often it seems that people will make patch releases that add a "feature" of complaining at install time that that major release/minor release/entire package is bad now and should be replaced with something else. It still works, but it annoys everyone who transitively depends on it forevermore.
If you can already be any size you want I'm sure you can make sure to keep the fat out of your organs.
I understand that keeping backward compatibility forever isn't worth it. But I think it should be kept for longer than it is now.
Why not a fashion choice?
The problem is you cursed somebody out on Xbox Live in 2018 and now your Microsoft account is banned.
I was going to say Nightcrawler and the hotdog finger tax lady