Mobile basebands already get the local time and UTC offset when connecting to a tower, there's no need to power up the GPS antenna and receiver separately.
Although Google did come up with the original specification their influence over the IETF specifications is not overarching nor absolute; gQUIC is substantially different from IETF QUIC which has caused Google themselves to have implementation and interop issues in their deployments. OS vendors, CDNs, academic researchers, and individuals have all contributed to the resulting specifications that have emerged in a standards body that is by far the most open as the requisite to participate is a functioning email address. All matters and decision making are publicly available for observation and scrutiny.
There is no requirement for people to implement this protocol and it won't be appropriate to every use case that exists today. TCP, UDP, HTTP/1.1, and HTTP/2 are not going away - all continue to undergo standardisation, research, and new implementations.
(Disclosure: I'm not a Google employee, but I have participated in the QUIC and httpbis working groups)
There are multiple implementations and their interoperability is tested [1], with some implementations already having bindings to higher level languages (aioquic) or into existing servers (nginx).
ntpd is now looked after by the Network Time Foundation, but more importantly many distributions use other implementations of the protocol like chronyd.
iPhone 7 onwards[1], Qualcomm Snapdragon 610 onwards[2], and Intel Skylake and later CPUs[3] can all encode and decode H.265 in hardware to varying profile levels.
QUIC is already getting those optimisations as the existing large deployments are incentivised to do so, as one example Kazuho Oku from Fastly made changes to their TLS implementation that showed improvements to AEAD and header encryption[1]. I suspect we will see improvements to QUIC's performance at a pace faster than the optimisations to TLS were made to make ubiquitous use of it trivial.
This is incredibly useful, thanks! Whist it has some region information and endpoints, boto's lacking other useful information - availability zone count, hosted zones IDs for services like S3, etc. This data publicly lives in a variety of tables across their documentation, and is painful to scrape.
To extend what I'm trying to say is that customers shouldn't have to do this and that updating of this data (which ideally should be in a machine readable format, much like ip-ranges.json) is just another step. I would like to hope that AWS already has playbooks for taking a region out of closed-beta and making it GA. If the listing of af-south-1 is already present on other sections of documentation this may already be the case.
Every time a new AWS region is made public, it continues to highlight the disparity in services availability across the regions, as well as making information about services available. Many regions are "discovered" because the ip-regions.json file is updated long before the press release, but it will be some weeks to months before key information needed to spin up infrastructure appears in documentation, for example things like the ELB hosted zone identifier, which at time of writing is not documented.
My non-European partner gives money to their parents despite being fairly middle-class and fiscally stable. You're right, it's cultural - theirs expects grown children to contribute to the parents after spending their childhood paying for them. It's an investment into the family unit as a whole, as the family will support you beyond what the state welfare could provide. Had a car accident and need some money? The family can help. Want help with a deposit for a place? The family will contribute.
I think you're overlooking the quality measure of the proprietary garbage as it evolves over time. Slack, in comparison to say Lync, or Skype has made huge moves towards better usability. But for a company like Slack determined to maintain market share, to control the user experience for all its users (whether they want to be users or not) is repeating the same mistakes, not necessarily the corporations signing contracts and writing cheques.
Slack is not the end solution. It's a step in the direction to being less terrible in the realm of corporate communication, and will be replaced by something else that does better in the future. For now it'll hold on whilst it still can.
I disagree - in a lot of corporate environments, it once snuck in as shadow IT to work around the then incumbent, infosec certified approved solution of less usable.
Slack has become the new corporate mandated unusable messaging application.
Adam Langley's Roughtime protocol[1] largely solves some (but not all types) of time malfeasance, and a variant of it is already an IETF draft specification[2]. There is also NTS, which is secure NTP and provides some protections, but not nearly as many.
He is a dual national now, which only complicates any attempt, Australia's connection with Five-eyes and other military and political arrangements aside.