HN user
Yes, when I don't have any out of band method for obtaining the key.
Also, the sources aren't the same, the binary is downloaded from a mirror / CDN while the links I posted are from the main FTP server.
edit: grammar corrections
Thanks, I was so focused on finding the files that I forgot.
For those who like me are wary of running unverified binaries:
- checksums: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/late...
- signatures: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/late...
- signing key: https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/lat...
edit: reformatting
2nd edit: added https
Yes, network protocols like IPv6 have a glacial deployment speed. Because all the network equipment have to support it.
But it isn't so for transport protocols like SCTP. Only the endpoints using it need to support it. So a transport protocol that provides a real benefit could be deployed relatively quickly.
and we need something to improve things now
I disagree. Nothing is needed now, HTTP/1 is not broken and it works well enough.
There should be time enough to come up with a clean design. Even if it requires designing a new transport protocol.
Rolling out a new transport protocol like SCTP takes a lot less time than rolling out a new network protocol like IPv6. Transport protocols only runs on the endpoints, not on the routers in the network.
Except for firewalls and NAT'ing home routers, but if HTTP/1 over SCTP would result in a faster better browsing experience the problem would solve itself.
Why worse? Wouldn't multiple HTTP/1.1 requests sharing a persistent TCP-connection also only have one initial slow start phase?
Maybe the SCTP multiplexing / parallelization of the requests and thus the initial headers affect this negatively as more headers would be transferred during the one initial slow start.
If the delay caused by slow start is a big problem one could add header compression to HTTP/1.x and run it over SCTP.
I understand that a transport protocol designed especially for and embedded in HTTP/2 will be more optimal than a generic one like SCTP. But my argument is that a multiplexing transport protocol like SCTP could be good enough. And usable for more than HTTP/2. And the focus could be on simplifying HTTP instead.
It has the benefit of giving us separate protocols for the transport and application layers. And of already existing, though it isn't widely deployed yet.
But it would allow multiple HTTP requests to be multiplexed over a single connection.
SCTP is also using some form of slow start congestion control, but since it would multiplex the HTTP requests over a single connection there would only be one initial slow start for all the requests.
I'm not willing trade away the human readability of HTTP/1 for a a performance gain that I really don't need.
What about tools for reading corrupt binary HTTP/2 frames?
In my opinion HTTP/2 is too complex.
I think the better route is to investigate how HTTP/1.1 could be layered atop multiplexing transport protocols like SCTP.
It might take 10 years to reach wide deployment, but HTTP/1.1 over TCP is working just fine anyways.
On my desktop, Debian unstable with XFCE.
Good riddance!
I never understood why people can't write well designed modular code without writing the test first.
Tests should never dictate the design of an application.
ClojureScript won't have the startup time of the JVM and is probably better suited for command line scripting.
My self hosted instance of Subsonic.
Kinnarps Plus 8