Earlier quoted context omitted.
Wouldn't it be more likely that maintaining backwards compatibility (an important Windows trait, after all) while also implementing all of Powershell would be a considerably more difficult task than just making a new scripting environment?
yes, too much to ask for a multi-trillion company, especially that this company was until recently well known for maintaining crazy level of backward compatibility
HTTP/2 and HTTP/3 explained
131–140 of 155 posts
Re: HTTP/2 and HTTP/3 explained
#132Earlier quoted context omitted.
[flagged]
> Also TCP handles packet loss just fine That's just plain wrong. I commented in more depth in https://news.ycombinator.com/item?id=39709591 . In short, TCP treats packet loss as congestion signal and slows down. If the packet loss was due to congestion that's absolutely the correct response and it increases TCP's "goodput". But if the packet was lost due to noise then it has the opposite effect and goodput plummets…
Re: HTTP/2 and HTTP/3 explained
#133Earlier quoted context omitted.
Yes. And there's almost zero risk to such (ARP poisoning? dns poisoning? etc) MITM attacks when you turn off javascript and don't blindly execute all programs sent to you as an end user. The problem with MITM attacks is when you execute programs or exchange money or other private information. The risks when viewing public documents that don't require execution is minimal. That's my point. One use case "web app stores…
You are wrong. Let's take a wikipedia, without TLS nor JS. I can modify that page and the end user won't even know it is now a bunch of crap. MITM has nothing to do with read-only nor with local execution.
Re: HTTP/2 and HTTP/3 explained
#134Re: HTTP/2 and HTTP/3 explained
#135Earlier quoted context omitted.
Yes. And there's almost zero risk to such (ARP poisoning? dns poisoning? etc) MITM attacks when you turn off javascript and don't blindly execute all programs sent to you as an end user. The problem with MITM attacks is when you execute programs or exchange money or other private information. The risks when viewing public documents that don't require execution is minimal. That's my point. One use case "web app stores…
> The risks when viewing public documents that don't require execution is minimal. If you’re living in a well developed country with strong privacy laws, you might have a point. But most of the people in the world don’t, and in many places simply looking at LGBT communities can land you in jail. Then there’s places like the U.S. with multiple states currently doing their level best to criminalise so much as thinking…
Re: HTTP/2 and HTTP/3 explained
#136Earlier quoted context omitted.
You are wrong. Let's take a wikipedia, without TLS nor JS. I can modify that page and the end user won't even know it is now a bunch of crap. MITM has nothing to do with read-only nor with local execution.
You can just put a bunch of crap in wikipedia itself, TLS doesn't help much here.
Re: HTTP/2 and HTTP/3 explained
#137Re: HTTP/2 and HTTP/3 explained
#138Earlier quoted context omitted.
It doesn't matter. You can provide the numbers when asked by the proponents of HTTP2/3 'do you have proof of your claim??', they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science.
> (...) they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science. This sounds like a bullshit conspiratorial excuse. If you have real world data and you aren't afraid of having peers looking through it, nothing prevents you from presenting it to peers. So where is that data? Instead, you just have vague unsupported unbelievable claims made by random peopl…
Re: HTTP/2 and HTTP/3 explained
#139Re: HTTP/2 and HTTP/3 explained
#140So we squeeze a tiny bit more performance out of existing networks, then that immediately becomes normal again. Except now we have protocols that are difficult to implement, debug and understand.