221–230 of 504 posts
Earlier quoted context omitted.
The ironic thing? GitHub, VS Code, and TypeScript are all Microsoft products.
Only Typescript is in-house. Others are acquisitions. Do you remember Embrace, extend, and extinguish times? https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
Earlier quoted context omitted.
That doesn't work if other teams want to apply their own cURL patches, or update as soon as upstream publishes new security fixes without waiting for you.
That's the point. We don't do that. You link to the system libcurl dynamically and everyone is told to do the same. If you want to use a private curl as an implementation detail then the only safe way to do it is to ship a .so, make sure all the symbols are private and that symbol interposition is switched off. If you ship a .a then the final link can always make symbols public again.
Earlier quoted context omitted.
>saving a few ms per request, or more likely just on the first request. That's not given, either as UDP is normally not prioritized under congestion.
But that will change, as more and more clients will rely on UDP on port 443.
And VPNs are carrying arbitrary traffic. You don't even know what it is. Assigning this anything less than "normal" priority is ridiculous.
In general middleboxes should stop trying to be smart. They will fail, will make things worse, and should embrace being as dumb and simple as possible. Don't try to identify traffic, just forward every packet you can and drop them at random when the pipe is full. The endpoints will figure it out.
For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…
Connection migration sounds like a security nightmare
> Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. > This seems contradictory. What's going on? IT administrators and DevOps engineers such as myself typically terminate HTTP/3 connections at the load balancer, terminate SSL, then pass back HTTP 1.1 (_maybe_ 2 if the service is GRPC or GraphQL) to the backing service. This is way easier to administ…
Earlier quoted context omitted.
I would say that .NET is the best example that Microsoft has not changed: https://isdotnetopen.com/
This link again? I'm baffled by insistent behavior like this. I think it is just alienating people and even if they move ecosystems, the negative impression will stay. If you engage in bad faith behavior in a technical discussion, can you be expected to conduct yourself acceptably in a professional setting? Unlikely. This is a discussion about HTTP/3 support of all things. Why does it happen only when someone leaves…
Earlier quoted context omitted.
Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux
I'm a dabbler in Go, far from an expert. But I'm not familiar with a capability to use, say, native MacOS platform libraries from a go app that I'm compiling in Windows/Linux without using a VM of some sort to compile it. If that's possible I'd love to learn more.
But if it’s native Go code, then cross platform compiling is just an a few environmental variables
GOOS=darwin
GOARCH=arm64Earlier quoted context omitted.
> These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. And yet it's somehow being pushed as a be-all solve-all replacement despite this: --- start quote --- We experimentally demonstrate that QUIC’s performance degradation affects not only bulk file transfers but also other applications inclu…
>And yet it's somehow being pushed as a be-all solve-all replacement But it isn't a be-all solve-all replacement. The whole point of HTTP/3 is that you can still use HTTP/2 all you want in your build-outs, and it uses as appropriate. If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Go nuts. Positively nothing will go awry. E…
Ah yes. Basically back to some links I discussed. Oh, it's amazing but you have to be careful what you deploy, and when, and you have to switch between HTTP/2 and HTTP/3 for some unspecified criteria which may or may not be better in one or another while the article we're in comments to decries "why oh why so few implement HTTP/3"
> HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations.
That is what Google markets it as, for sure.
The rest of that sentence I could not parse.
Earlier quoted context omitted.
> side note: sad that .NET and C# are not considered "major"... Even Microsoft does not use C# for their new projects. See the new TypeScript compiler that is being rewritten in Go. So I think it is safe to say C# is indeed a minor language.
This is an interesting point I hadn't thought of when I saw the announcement of the new TypeScript compiler. It might be overstating the case to say that C# is indeed a minor language, but it's thought-provoking that it wasn't Microsoft's automatic choice here, the way it is for some all-Microsoft in-house IT shops.