Google acquired ITA in 2010. Cape Air switched their entire flight reservation/departure control system to ITA/Google in 2012. Google discontinued the system in 2013.
The reason Google continued to offer API access after the acquisition was because a 5 year stipulation was in the contract to get it approved by the Department of Justice. Of course once the 5 years were up that was it. ITA had also built a reservation system for Air Canada. Air Canada never used it, but Cape Air switched in 2012. In 2013, Google discontinued it.
The whole acquisition was a huge failure on the part the DoJ Antitrust Division.
They are not conspiring. It just makes a lot of sense to keep operating under-staffed (your labor costs are now a fraction of what they were) as long as the revenue keeps rolling in, using "labor shortage" as an excuse to customers for why quality has gone down, and to employees for why they need to work overtime. A lot of it is also PPP loan fraud - PPP loan forgiveness terms let you weasel out of actually re-hiring staff as long as you make and document some effort at trying to hire (https://quickbooks.intuit.com/r/coronavirus/rules-for-rehiri... I assume the rules are similar for second draw). Also, why would you hire someone at what you believe is an "unreasonably" high wage right now, given that you believe that wages will go back down in the near future? If I was running a small business in the US with employees right now, I would be doing the same, no conspiracy necessary.
> Farther north in Ontario, the heating season is way longer than the cooling one, so it does kind of make sense to optimize for heat retention. The other side is that having a roof which warms itself in winter is better for reducing snow accumulation.
So much wrong here. Asphalt shingles neither "retain heat" nor "warm themselves." You really do not want either property in a roof covering in a climate where it snows because that will cause the formation of ice dams. If you have snow on your roof, it obviously covers the black shingles - now you have a white roof anyway. If it is winter and you do not have snow on your roof, it is still not worth it - solar irradiance at 50° latitude (approximately Timmins, Ontario) is going to be about a factor of 7 less in January than in June. You are much better off with a white roof in northern Canada to reduce peak heat stress in the summer, which will continue to get worse and worse due to greenhouse gasses.
Yes, plus while every Canadian home has heating, not all homes have air conditioning. Optimizing the roof for the summer makes a lot of sense.
We had a steep roof in the Okanagan which rose about 20ft to the peak. That extra room was problematic in winter for heating but a life saver in the hot, sunny summer. The loft was unbearable during the summer.
A neighbor with a low roof would run a sprinkler on his roof all summer long, that's how bad the heat would get.
Interesting, that's a good point about the height of the sun in the sky!
My previous house already had a light colored metal roof, and my current one is shingles that are not due to be replaced for another ten years or so, but these are good things to think on.
Have you heard of unique local addresses? Most of the LAN "problems" you describe are solved by using ULAs. Yes, even name resolution - the hosts file becomes useful again. PCP (the 2013 replacement for NAT-PMP) supports IPv6 port opening; UPnP has supported it since IGDv2 (2015). Any ISP that does not do IPv6 prefix delegation ("your ISP only gives you a single v6 address"), might as well stop claiming IPv6 support.
I am not sure why you think multihoming is a bad thing. That is one of the major things that in my experience makes IPv6 LAN configuration a lot more useful and robust than IPv4 with private addressing. It sounds like you misunderstood some basic IPv6 assumptions - configuring an IPv6 LAN is not that much more difficult than an IPv4 one. I would never go back to IPv4 for my LAN.
There was also Gary Sabot's work on Paralation Lisp (really interesting approach to declaratively specifying data locality), and later Guy Blelloch's NESL (the first programming language to really deal with nested parallelism) for the CM-2.
