becauseiam

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)

Earthquakes, nuclear explosions, tectonic plate activity, the moon slowly moving away from us amongst other causes.

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).

1: https://interop.seemann.io

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.

1: https://support.apple.com/en-gb/HT207022

2: https://www.qualcomm.com/snapdragon/processors/comparison

3: https://trac.ffmpeg.org/wiki/Hardware/QuickSync

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.

[1] https://mailarchive.ietf.org/arch/msg/quic/OnBhC4gCosmlU3VKo...

It's possible we _could_ - a combination of DNSSEC used to sign records, and TLSA records to provide the linking. In reality, however...

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.

I'll send the feedback through anyhow.

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.

The real question is how the rest of the market will respond to EVC, not necessarily VVC.

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.

Property Lists already do tick some of those boxes.

The ace working group within the IETF has a fairly recent draft[1] standard on this.

[1] https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-pro...

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.

[1] https://roughtime.googlesource.com/roughtime/

[2] https://tools.ietf.org/html/draft-roughtime-aanchal-01

He is a dual national now, which only complicates any attempt, Australia's connection with Five-eyes and other military and political arrangements aside.

Good behaviour really is honoring the resolvers provided in a DHCP answer.

4.2.2.2 is supposedly for Level3 customers only.

There's quite a few things you've missed that are significant and should have been included, maybe one for part two:

* Network ACLs, which describe the ruleset (consider it like a stateless firewall) for subnets and their respective routes. Whilst they are optional, having a default set it straightens out a lot of duplication that may end up in Security Groups (which are more stateful in nature).

* Elastic (public) IPs. NAT instances/gateways require their use, and there is dance to be done around their allocation in account, and attaching to instance interfaces.

* IPv6 components. Egress-only Internet Gateways operate differently to IGWs, as there is no NAT they need a route applied across all subnets both public and private. IPv6 CIDR which allocates the VPCs /56 (and thus each subnet gets a /64, and each instance's interface thus gets a /128 which is bananas, but IPv6 is a second class citizen on AWS). Finally updating the subnets so automatic IPv6 address assignment happens.

* VPC Gateways - these are broken into two types, the older type that support S3/DynamoDB and effectively allow traffic in a public/private subnet to bypass NAT. These enabled can have significant advantages to access and throughput. The newer "PrivateLink" services are different and having pricing costs associated with them.

* DNS and DHCP: It's a rule in the VPC that the delegated resolver lives on ".2" of the VPC's CIDR, and operates in dual-horizon - EC2 hostnames setup accordingly resolved by instances inside the VPC will get the private VPC CIDR address, not any Elastic IP.

Maybe I am biased, but live TV is not going to die completely. News, sport, concerts, lotto results, and other timely things will continue to have demand. IP is a terribly broken and inefficient medium to deliver this to the audience, and the internet as it stands today with what we deliver simply does not have the capacity to survive a "traditional TV switch off". Some broadcasters are testing with deploying onto 5G with various trials, but most appear to be doing an all IP operation, and handing over the controls of deployment from the incumbent transmission networks who charge on site/power and other performance metrics, to telcos who will probably charge both the broadcaster and the end user per packet, as well as introducing more middlemen (CDNs) to further create inefficiencies.

There's a lot to work out before Cringely's "utopian" 5G network to rule them all can actually exist.

Graphviz for simple diagrams that can represented with basic shapes.

PlantUML for sequence diagrams, state machines and the likes.

Powerpoint/Keynote for things that are presentations - and usually I will export one of the above formats as SVG, clean it up a bit, turn into PDF and drop into the slides. As a general rule all my diagrams must be vector based, and no bitmap objects should be embedded.

Confluence with Graphviz and PlantUML plugins for placing diagrams into documentation. This also gives more granular version control. Other diagrams may also end up in source control with the product itself.

Occasionally I have ASCII art embedded in source code, nearly all of this is hand cranked as I've yet to find tools that work for me. Almost always this is formatted to show up in generated documentation.

But most importantly is having consistent design elements - spend time having colour palettes that are consistent, typefaces and type positioning that match, that shapes and layouts are as consistent as possible. Having templates, colour palettes, and snippets help. Finally, understand basic colour theory, typography and layout. Looking at graphic design visual porn (Behance is a good starting point) after knowing the basic rules will hopefully give meaningful inspiration.

The article misses that months before the ARM announcement, AWS announced AMD based instances being available in m5 and r5 classes, and are cheaper than the default Intel offerings. If anything Intel might be afraid is that because the workloads that can be achieved are comparable.

I think the immediate reason why a lot of the older movies are not coming back is partly due to a rights management thing (films are usually negotiated for terms of n months/years, and renewing the contracts is a cost), but also they impact the size of CDN working set. The "long tail" where 90% of traffic is accessing only 10% of the files kept on origin makes for an inefficient proposition for an SVOD service. This is even more of a pressure when you are both the VOD service AND the CDN. I suspect Netflix spends a lot of man hours finding which titles perform in consistent viewership and prioritise those for the reasons above - besides, how many times can a person watch Breakfast at Tiffany's per month?

Ericsson have both their own PKI infrastructure[0], at least for software integrity checking (however that certificate is valid since March this year, and the CRL[1] it refers to is empty), in addition to using other certificate authorities for everything such as the hosting of websites to internal infrastructure[2]. I suspect it wasn't any of the above - rather it is the PKI that is used in running the IPSec networking done between carrier's RANs and other parts of core network[3], which is probably Ericsson's own internal CA.

[0] https://www.ericsson.com/en/about-us/enterprise-security/pki

[1] http://crl.ericsson.net/Ericsson_Software_Deliverable_Integr...

[2] https://crt.sh/?q=%.ericsson.net

[3] https://en.wikipedia.org/wiki/System_Architecture_Evolution

This website appears to be sourcing it from Wikipedia.

DynamoDB is really only good for testing since it uses SQLite underneath.

It's because the rights holders in Japan (of whom many are broadcasters) have broadcasters by the balls and demand it and the Japanese Government goes along with it. In particular it's music labels, but various sporting events also make explicits of it. HD broadcasts in Japan (including free to air terrestrial) are encrypted with B-CAS, something that has been broken a few times over many years now. The 4k/8k transmissions over satellite have a new system called A-CAS that instead of being smart card based, is an ASIC in device that apparently receives keys and firmware out of band from the video mux. Now these kinds of systems have been the status quo in that market for over a decade, any new format coming along will most certainly have to implement _some_ form of conditional access. At least until the value of the content on it makes a minority stake on the balance sheets.