niftich

AVIF support Firefox issue [1]; Chromium issue [2].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1443863 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=960620

It's a bit of both.

Early versions of Firefox shipped with a prominent stylesheet chooser in the status bar, that allowed alternate stylesheets on the page to be selected. Of course, hardly any website offered alternate stylesheets. So this later got moved to a menu and forgotten. According to this MDN page [1], IE8 has this feature too, which is wild to me, because that's right around the time most people accepted this feature as irrelevant.

Several browsers offer a way for the user to set a custom stylesheet that will be applied to every page. These options are almost always buried in some forgotten corner of an accessibility menu, if a UI is provided at all. The utility of this feature is passable when used to, say, enlarge text, or apply basic formatting to well-identifiable elements like h1, a, or table, and very useful for pseudoclasses. But because page layouts (i.e. the specific nesting of container elements, and the styles that affect them) between any two random websites can differ so widely, it's only capable of crude attempts to alter layout.

https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative...

This essay, and really, most of the content on A List Apart, have been instrumental in championing accessibility, progressive enhancement, and separation of content from visual flourish, so that the web didn't become a pixel-pushing medium.

While their shoulders are giant, their message was often ignored, because many designers -- often instructed by their customers -- continued to think in terms of layout inseparable from their visual design.

Web users also valued consistent layouts, but it turns out, not enough websites actually cared! Marketing pressures for visuals and refreshes would frequently be at odds with the UI's UX. This is perhaps excusable for websites whose sole reason for being was to be a digital billboard, but this would be a point-of-contention for news sites, e-Commerce, social networks, and productivity sites too.

We know this is what happened, because when the Web 2.0 "age of mashups" came, most websites were caught by surprise. The coolness factor and emerging business cases finally pressured them to make available snippets of their content that can be surfaced independent of presentation -- but as a twist, instead of sending composed documents, they largely turned to shipping around context-free snippets of data. With content having been separated and spliced into pages using JS, the tight combination of HTML+CSS became a layout engine.

The oft-linked Eran Hammer blog post isn't too relevant here, even if its critiques of OAuth2 are valid from the perspective of OAuth1. Really, they're fundamentally different protocols with different goals, and after all that drift in the working group, not changing the name and pretending it's an increment of version was bad form.

Nonetheless, OAuth2 just defines the roles of the players in a situation where an application wants to act on behalf of the user, and defines a few useful interactions between them.

OIDC then layers on top of OAuth2, by defining custom payloads that communicate authentication requests and responses. It does so by relying heavily on the JOSE specs. The end result of all this layering is a protocol that's conceptually similar to SAML, despite looking and feeling rather different. Meanwhile, all the truly hard stuff, like Discovery and Federation, are additional specs alongside. They see much less use.

There's sometimes bad implementations, and there's sometimes authorization flows that aren't actually OAuth2 but merely "OAuth2-inspired". In these, and in transmitted payloads, gratuitous differences from vendor to vendor are irksome.

The same stuff happens in SAML-land too. There are products big and small, IdPs and SPs, that don't actually comply with the protocol. Sometimes the product is fine in theory, but it's misused or misconfigured. Sometimes the IdP product is big enough that they have little incentive to improve, and sometimes the SP is desirable enough that you're being pressured by your employer to integrate with them regardless of any protocol shenanigans.

Two months after Feb 2008 article, in April 2008, Facebook released [1] Facebook Chat, and gradually captured the 'chat with people you know in real life' usecase.

In April 2008, we're three months before the launch of the iOS appstore, more than a year before iOS push notifications, and more than two years before Android push notifications -- and three years before iMessage. For instant messaging, most people are still using 'legacy' networks like AIM, MSN/WLM, Yahoo Messenger; tech early adopters may be using Google Talk inside Gmail, which stopped being invite-only just a year prior. People with phones are using SMS, and smartphones are not too common.

With Chat, Facebook became much more than a place to post text or pictures on one's page: it became one of the largest Instant Messaging networks overnight.

They stayed relevant during the rise of mobile apps as other players faltered, then years later, they turned to acquisitions to buy a few networks that presented a competitive threat.

[1] https://news.ycombinator.com/item?id=13465483

Southern Nevada actually gets most of its electricity from power plants within the state: mainly from natural gas power plants owned by NV Energy adjacent to Vegas. Here's a recent Power Content Label for Southern Nevada [1]. Not much of the electricity consumed in Southern Nevada is purchased from out-of-state. Most of the natgas used in Southern Nevada's power generation comes from western Wyoming.

[1] https://www.nvenergy.com/publish/content/dam/nvenergy/bill_i...

I live on the east coast, but I have friends in Vegas, so when I visit, I avoid the Strip and touristy areas unless I want to specifically go out.

As a kid, I remember our family visiting Vegas multiple times as tourists; going back as an adult has felt very different. It was a fascinating transition to experience, not unlike when you stop flying window seats and start flying aisle seats instead.

In my teenage years, I lived in an east coast city with a boardwalk and beach, lots of hotels and condos and tourist shops. I hardly ever went to the beach -- it could get crowded, and parking and not getting your car wet and sandy would get complicated, so I often forgot that it's an option. All of that works a lot better if you're staying at the beach.

I suppose Vegas residents may feel similar about the Strip or Fremont Street during an average day, when they're trying to get stuff done. But if you're looking for ways to spend an afternoon or night out around town, there's plenty of variety, from shows to shopping, paid attractions, pedestrian spaces, museums, diverse restaurants, bars, nightclubs: much more so than metros of a comparable size: Charlotte, Sacramento, Cincinnati, Kansas City, Columbus, Cleveland. Its weakest areas arguably sports, and smaller "local" venues for bands on tour.

A richly detailed article that delves into the French TGV speed record, the extra modifications they applied to what was already a high-speed system, and the lesser-known physical phenomena that set a performance envelope for this mode of traction.

Then, in a switch of tone and pacing, admits that profitability potential is likely most important of them all.

This is why networks -- rather than just individual lines -- are critically important. High-speed rail works best when it connects robust local transportation networks that already exist: between cities that they themselves have robust temporal and spatial transport coverage. It works best when faraway cities can be brought within commuting range, or further leisure destinations within daytrip range. Similarly, it works best when it extends the catchment area of an airport, rather than a service positioned to compete against point-to-point flights.

But major infrastructure projects often suffer from messy political and public relations approaches that play up the project's impressiveness and prestige in isolation, while neglecting to emphasize or champion synergistic improvements to other parts of the network. Frequent and punctual "normal-speed" rail isn't as politically energizing, and local transit networks that serve the specific transport needs of a town are hardly exciting to regional audience, but without it, high-speed rail is just an expensive showpiece that doesn't serve a genuinely identifiable transport need. This is a risk with the California HSR as much as it is with ambitious efforts to bring western Europe's successful high-speed services further into the EU's east.

Middle- to upper-middle-class suburbs will still exist, they'll just be a municipality a few miles over, where all the houses and roads are 25 years newer, and the long tail of opex costs hasn't quite hit as bad yet. It will, eventually.

If a suburb can attract some retail or office space or manufacturing, they can be like Irvine or Tysons or Bloomington -- the suburbs that have made it. Those that cannot will accumulate the same problems with fiscal sustainability that inner cities once did.

The ZIP Code 97003 took effect on 2014-07-01, when the ZIP Code 97006 was split [2].

ZIP Codes are not geographical entities and don't correspond to geographical extent; rather, they are a hybrid between a discrete number of finite delivery-points and an abstract way of capturing a postal delivery route. They are often abused as geographical entities, which the Census Bureau has tried to rectify with ZCTAs [1], but it's unclear whether most informal use of ZIP Codes is haphazard, or actually conforms to ZCTAs.

However, ZIP Codes directly map to one preferred place name designated by the USPS, and zero or more acceptable alternative place names. These are usually inspired by, but don't necessarily correspond to municipalities and political units that the lots in question belong under.

For both 97003 and 97006, the USPS recommended place name is "BEAVERTON", and other acceptable names are "ALOHA" and "HILLSBORO".

Beaverton's city limits are complicated [3][4]. The city has a map of annexations as well [5]. Cedar Hill was once supposed to be annexed. A court case about the proposed annexation of the Nike HQ resulted in these plans being put on hold [6].

[1] https://www.census.gov/geo/reference/zctas.html [2] https://about.usps.com/news/state-releases/or/2014/or_2014_0... [3] https://www.beavertonoregon.gov/DocumentCenter/View/9005/Cit... [4] https://www.beavertonoregon.gov/DocumentCenter/View/5554/Bea... [5] https://www.beavertonoregon.gov/DocumentCenter/View/843/Anne... [6] https://www.oregonlive.com/oregonianextra/2006/06/appellate_...

Lots [1][2]. These have seen most deployment in closed networks (e.g. subways, or remote mining railways [3]), but experiments on "normal" interconnected networks are ongoing.

[1] https://en.wikipedia.org/wiki/Automatic_train_operation [2] https://en.wikipedia.org/wiki/List_of_automated_train_system... [3] https://www.railwaygazette.com/australasia/rio-tinto-complet...

The crater and the resulting aquifer disruption is a contributing factor to why several nearby cities import their water from far away. Another is that the cities of Norfolk, Portsmouth, and Newport News acquired water rights to nearby creeks long ago, back when nearby jurisdictions were rural counties, so by the time other areas experienced growth, all of their surface water rights were already owned by the oldest cities [1].

Caught in a wave of post-war growth, white flight, threatened by annexation, and discontent with having to buy local water from their neighbors, counties in this part of Virginia started becoming cities. In Virginia, cities are independent from counties -- the federal government therefore considers Virginia cities to be county-equivalent -- and cities are protected from annexation by adjacent cities.

Counties turned into cities, then merged with an adjacent friendly city to avoid annexation by a rival city; Princess Anne County merged into the City of Virginia Beach; Norfolk County merged with the City of South Norfolk and renamed itself to Chesapeake; Nansemond County changed into a city, then a year and half later merged into the City of Suffolk; the county surrounding the City of Hampton merged back into it; and the City of Newport News eventually merged by mutual agreement with the City of Warwick, even though 6 years prior Warwick changed from a county to a city to avoid that exact fate.

After experiencing major growth, Virginia Beach wanted to have a better negotiating position with Norfolk over water supply. It build a long interbasin transfer [1][2] to withdraw water from Lake Gaston on the Roanoke River, adjacent to the North Carolina border. Chesapeake joined as a minority partner. The resulting water is delivered into to Norfolk's system, who filters and treats it, and distributes it to Norfolk, Virginia Beach, the most urbanized areas of Chesapeake, and most military bases in the area.

[1] http://www.virginiaplaces.org/watersheds/lakegaston.html [2] https://www.vbgov.com/government/departments/public-utilitie...

More on this:

szolga = servant

+ l = verb-forming suffix [1]

+ tat = causative suffix [2]

+ ás = gerund-forming suffix, makes a verbal noun from a verb [3]

+ ai = marker for plural possession [4]

+ ért = causal-final suffix, denotes the reason for the action [5]

These suffixes are morphemes you can (with some simple rules) just add to words to achieve the corresponding change in meaning. In CS terms, they're functions that take the input word and make a new one. Each one of the above, used somewhere else:

winter -> to spend the winter: tél + l -> telel

to read -> to make them read: olvas + tat -> olvastat

to read -> the reading: olvas + ás -> olvasás

house -> his houses: ház + ai -> házai

house -> because of, affecting the house: ház + ért -> házért

[1] https://en.wiktionary.org/wiki/-l#Hungarian [2] https://en.wiktionary.org/wiki/-tat#Hungarian [3] https://en.wiktionary.org/wiki/-%C3%A1s#Hungarian [4] https://en.wiktionary.org/wiki/-ai#Hungarian [5] https://en.wiktionary.org/wiki/-%C3%A9rt

When I was learning Hungarian grammar in Hungarian grades 1-8, the 'noun case' terminology was not widespread, although more and more academic sources began lifting it from works discussing Indo-European languages. Instead, what's taught is that Hungarian is a thoroughly agglutinative language, and there are different kinds of suffixes which play different roles. If they're present, the types of suffixes always occur in the same order.

The first kind are any word-creation suffixes that change the meaning of the root word, perhaps making it a different part of speech. Such a suffix is called a 'képző'.

The second kind are word-relationship markers that preserve the part of speech but signify a clarifying quality, like belonging to an adjacent noun, or plurality, comparative intensity, or an ordinal pointer -- the sorts of markers you'd use to answer questions like 'whose?', 'which?'. This kind of suffix is called 'jel'.

The third are role-in-sentence markers that signal the function of the word within the sentence. This suffix is called a 'rag'. For verbs, these are endings for grammatical person and mood. For nouns, the most common of these correspond to nominative case, accusative case, and dative case, but then there's one that expresses the notion of being used as an instrument, one that expresses a purpose, two that are used to signify a transformation, and a couple others. And, there are 10 more that show a location relationship; English would prefix such words with one of: at, into, in, out of, towards, by, away from, onto, on, from off of; in Hungarian, the word takes a corresponding suffix instead.

When I was learning English grammar in an American school, a structural examination at a level I was used to from Hungarian was largely absent -- it took until I was learning English as a foreign language, or learning German as a foreign language, that mechanics of English grammar became apparent to me. The dying usage of subjunctive mood and incorrect use of accusative and dative case is a natural simplification, but enabled by the lack of education about the origin of those forms and their meaning.

Was an eastern bypass for long-distance traffic studied?

Compare and contrast with the Swiss cheese model [1].

There's not enough cross-domain awareness and discussion of such quips that approximate useful and widely-applicable mental models.

[1] https://en.wikipedia.org/wiki/Swiss_cheese_model

Cassettes were also the first and last audio storage medium where mainstream consumers could purchase an affordable, ready-made appliance for home listening that could also act as an audio editing system, recording the result onto another cassette. This is what enabled mixtapes.

With formats that came later, CD-recording remained expensive until personal computers were becoming widespread, and while CDs could be ripped or mp3s could be remixed on computers, you needed software that was often commercial and rarely included.

Digital audio then de-emphasized removable storage, re-introducing friction between exchanging music and listening to it on a portable player. Nowadays, most music exchange happens online, but the appeal of exchanging music in person endures even for generations that grew up with the Internet.

Cassettes had excellent usability for sharing: ease of duplication, ease of remixing, more rugged than vinyl, easier to hold than CDs, and maintaining its playback position at rest [1]. Couple that with authentic nostalgia, or yearning for an aesthetic and mood of times past. While the vinyl revival is centered around the deliberate experience of browsing, playback, and large-size album art, like enjoying an artisanal product made by skilled craftsmen, cassette revival celebrates the versatility of the format, its lack of restrictions, the opportunities for creativity, and its physicality on a very human scale.

[1] https://news.ycombinator.com/item?id=20332150

As noted in the article, hydrogen is currently unfortunate, because the most economical way to produce it is through steam reforming of natgas. Germany already has supply issues with natural gas, not just the pressure to reduce greenhouse gas emissions. Electrolysis of water is another method, but requires a lot of electricity. Using it in the short term is highly wasteful, when the source fuels could just be used directly.

Nonetheless, on a longer timescale, hydrogen effectively becomes a roundabout instrument of space-, time- and demand-shifted energy storage, but potentially bulk-conveyable using portions of existing gas pipeline infrastructure. This compares favorably to batteries (which are heavy, solid, contain other commodities, and are non-bulk-conveyable in a comparable way), and other energy storage schemes (which are immobile or lack effective the distribution of work). It's broadly similar to hydrocarbon natgas and syngas, but without the direct release of carbon during actual combustion.

The hope in this effort to encourage progress and deployment of hydrogen-based technologies, infrastructure, and business models, and tolerate some short-term wastefulness to target a more favorable goal in the long term.

For Shibboleth, the XML configs are unwieldy, but both the IdP and SP are solid and eminently configurable, which is helpful when interfacing with someone else's broken software or odd requirements. In running our Shib IdP, I've had far more trouble with hand-rolled SPs (presumably using found libraries) than I've had with poorly managed Shib SPs. SimpleSAMLphp is comparable, if you're not a Java shop.

Commercial IdP-aaS products have their place, but with their spread, some SPs just code and document how to integrate with the two or three most popular IdP-aas products, and if you're using something else, you're left trying every possible binding, signing, and encryption, until you figure out which one works. Competent SP authors and operators can likely say similar things about various IdPs.

Despite the standards, it's nice if knowledgeable, accommodating people are running capable software on both ends of the exchange, and frustrations will probably increase the further you depart from that ideal.

As a SAML IdP operator, you're not wrong -- the typical SAML IdP operator is an insitution or a BigCo's internal SSO, while the typical OIDC/OAuth provider is a tech company that runs a data silo -- but consider that SAML IdPs and SPs frequently have to engage in a dialogue to peform an integration, while OAuth 2.0 providers just kind of exist by fiat, and wait for SPs to show up. OIDC evolved from OAuth 2.0 so the UX expectations remain: the SP's operator expects to have to go through some web-based SP registration process provided by the OIDC IdP.

In SAML, the IdP and SP can exchange metadata, but plenty of fly-by-night SPs can't consume it, and need to be configured by hand. Tons of vendors of claim their SP supports SAML, but their implementation was hacked together in someone's basement and doesn't support SAML medadata, is hardcoded to use NameIDs, can't do key rotation, and the like. Some vendors intentionally "simplify" the terminology and translate well-specified SAML terms like "Assertion Consumer Service" to nicer sounding common words, like "login URL", largely obscuring meaning and making any integration an exercise of repeated trial and error.

Garbage IdP software exists too. The SAML specs are very accommodating and offer lots of options, so even among parties that don't flout the text of the standard, the interoperability matrix can be challenging. It's best if your product supports all the options, because the other guy's handmade product probably won't. Then, with attribute release and usage, some vendors ask for email address and use it as a persistent non-reassinable identifier, and some vendors ask for a persistent non-reassingable identifier and if it looks like an email, they'll probably send mail to it. It's frustrating.

Really, because each standard's deployment base, the incentives are different: the typical SAML SP offers a product it wants to sell to an institution or BigCo and the IdP is trying to be careful with its attribute release, while the typical OAuth provider is the data silo itself, full of user data, and SPs want to integrate with it to surface that data in their own application. OIDC then shipped a bunch of standard claims to carry identity info too, but the nature of the typical deployer has hardly changed.

Top users of California's allocation of Colorado River water are [1]:

~61% Imperial Irrigation District;

~20% Metropolitan Water District of Southern California;

~8% Palo Verde Irrigation District;

~8% Coachella Valley Water District;

Out of these, only the Palo Verde Irrigation District is inside the Colorado River basin. The Metropolitan Water District of Southern California has access to the coastline, so it can mix in desalinated water directly. It currently mixes in local water sources and water delivered from Northern California [2].

The Imperial and Coachella valleys require an interbasin transfer in either case, but despite the presence of canals and pipelines from the lower Colorado River to these sites, supplying them with additional water from the coast would require significantly less infrastructure than pumping said coastal water all the way up to Lake Mead.

[1] https://www.usbr.gov/lc/region/g4000/4200Rpts/DecreeRpt/2018... [2] http://www.mwdh2o.com/AboutYourWater/Sources%20Of%20Supply/P...

Because most of the US does not have this problem. The Colorado River basin does, but it's worth noting that California's allocation is very high relative to the portion of the drainage basin within the state, and most of the state's allocation (>88%) is pumped out of the basin.

Top users of California's allocation of Colorado River water are [1]:

- the Irrigation Districts of the Imperial Valley (~61%) and its northwest extension the Coachella Valley (~8%);

- the Metropolitan Water District of Southern California (~20%) [2];

- the Palo Verde Irrigation District (~8%). The Palo Verde Irrigation District is inside the Colorado River basin.

[1] https://www.usbr.gov/lc/region/g4000/4200Rpts/DecreeRpt/2018... [2] http://www.mwdh2o.com/AboutYourWater/Sources%20Of%20Supply/P...

Arizona produces approximately 1/4 to 1/5 of the leafy greens grown in the US, by weight, depending on the exact commodity [1]. Meanwhile, California produces roughly 3/4 of such products grown in the US. The two states participate in a seasonal rotation, where California's temperate valleys produce most of the summer crop, and in the winter production is shifted to inland desert locales in both Arizona and California.

[1] https://cals.arizona.edu/arec/sites/cals.arizona.edu.arec/fi... [2] https://californiaagnet.com/2017/11/03/a-look-at-year-round-... [3] https://www.ers.usda.gov/webdocs/publications/93033/vgs-362.... [4] https://news.ycombinator.com/item?id=18535425#18536045

It's fair to suppose that in the far-off future, midrise high-density housing (the five-over-ones and texas donuts) built cheaply years ago would become some of the least desirable housing around. Unlike with detached housing, rehabilitating the structure is a package deal, so its quality will likely decline until the entire structure is demolished, likely in conjunction with a redevelopment of its lot.

The likely ossification of such midrises shows why incremental, small-scale increases of density, like allowing threeplexes on small lots, is so useful.

This article in German [1] and this source in Hungarian [2] demonstrate the concept with very clear charts you can likely understand without having to read the labels. The distance-time graphs show that different trains move at different speeds: faster trains have a steeper slope, slower trains have a gentler slope and more spots where they dwell for a few minutes before advancing.

You want your graph symmetric around various point-in-time axes, so that the scheduling is predictable.

On the distance-time graph, if you've upgraded a line and can run faster trains, you can plot the train with an even steeper slope in the graph. But by doing so, you may miss more of the knots where many different lines in the graph come together. These knots in the graph are moments in space and time when several trains are at the same station around the same time: the time to change trains and make connections.

The system works best when major hubs are roughly 1 hour apart, so you begin optimizing for that fact systemwide, instead of small, few-minute travel time reductions on individual lines. It may be the case that small improvements in travel time on one line don't outweigh the reduction in connection opportunities, so small improvements become harder to justify. You'd have to run certain trains much faster (and spend more money on faster tracks) to maintain the same level of connections in the network.

[1] https://www.zukunft-mobilitaet.net/42868/analyse/integraler-... [2] http://www.itf.hu/index.php/alapfogalmak/integralt-uetemes-m...

Although I'm familiar with this concept since the implementation of ITF (integrated clock-face timetables) in Central Europe, I found the second half of this article (as of this revision [1]) hard to read. After finishing it, I felt like I understood less about clock-face scheduling than I did before.

Nonetheless, I know that the key desirable features are (1) to ensure that hub-like nodes have services from all directions arrive and leave at the same time, so that connecting passengers don't need to wait for long, and (2) that a future arrival/departure time at a major node is somewhat predictable without consulting the full timetable.

For trains, it's also a nice feature that trains of opposite directions will meet somewhere predictable, so track improvements like double-tracking can be targeted at places where crossings are likely to occur, which can cost less than double-tracking the entire line.

Integrated clock-face timetables work best when rigid, but it requires the spacetime of transport geography to fit into a regular pattern. But this can mean that some improvements that would result in faster service on portions of the network would put the the network out of sync. Because of this complication, such incremental improvements may not happen.

[1] https://en.wikipedia.org/w/index.php?title=Symmetry_minute&o...

Yes, but the trial-and-error model of Netflix original content production is exactly the same as it is for series produced chiefly to be shown on major US TV channels.

The difference is, more of this content used to be licensed to Netflix, but shows have been leaving as licensing deals expire and typically end up on Hulu, which is a first-party platform for Disney (ABC, Freeform, FX, A&E) and NBC (Syfy, Bravo, USA), and a third-party platform for WarnerMedia until they finish starting their own.

Streaming services are proliferating as each vertical starts their own, and exclusivity is being leveraged to drive subscriber numbers. Discerning viewers can choose on content or cycle out subscriptions as they consume the material of interest, while casual viewers can choose on a different dimension like price per month, size of back catalog, variety of genres, search and discovery tools, or lack or presence of commercial breaks.

Coins, cash, and disability-accessible faregates solve most dimensions of this problem -- portability, scalability, no vendor lock, security, privacy, and equal access -- but even that isn't universally deployed.

If you want to support distance-based, or otherwise complex fare structures, have both entrance and exit gates demand a fixed payment, and give a one-time-use token, ticket, or rebate code that identifies the origin, which, when inserted at the exit, reduces the price if it's below the default amount. Non-payment at exit gates is a similar issue to being caught with fare evasion by roving inspectors, and has similar societal answers (or lack thereof).

If you want to reduce entrance friction, you can additionally deploy faster payment methods for those who opt in, or reconsider the funding model of transit entirely. Roads are a similar public good, yet rarely are 'usage fees' deployed for roads; instead, the funding model of roads is complex, but fees designed to somewhat correlate with road usage, like fuel taxes, are deployed widely for this purpose. Both transit and roads are extensively subsidized from general government revenues as well.

The effect is that roads are generally used without individual purchasing decisions needing to be expended for every trip, and together with cars' intrinsic point-to-point routing, it vastly reduces friction compared to transit. Rethinking the funding model of transit, in places where the road network is under strain and transit is a viable contender, would be worthwhile.

Good reporting. A few more points:

1. In the famous California power mix charts, 'Other' includes power bought from different utilities where the exact generating method is abstracted away. You can mentally think of the 'Other' as 'Unsure'.

2. Intermountain's conversion to natgas has been long rumored, facing both regulatory pressure, environmental pressure, and infrastructure considerations. Large amounts of natgas is already piped through the Kern River Pipeline in this corridor, going to Nevada and California from the Opal hub in Wyoming. This is where Southern Nevada gets most of its electricity -- through natgas power plants alongside I-15.

3. There is a project called TransWest Express [1], to build a HVDC transmission line from Wyoming to Las Vegas to carry wind power from Wyoming to markets in the Southwest. This will run immediately parallel to the existing Intermountain HVDC line for much of their overlap, and no connection is planned at the Intermountain Power Plant (the latter line's origin) or anywhere else between the two for now. Vegas is presumably the destination for TransWest Express because it's a power exchange hub for many electricity suppliers and consuming utilities, but the overall effect is still a bit silly, because most of the power exchanged at the Vegas hub flows towards Southern California anyway on existing AC lines. One might imagine a different scenario where the Intermountain line gets split in two at Vegas, TransWest express only builds the "missing portion" between Wyoming and Intermountain Power Plant, and then there's an available chain of HVDC lines to ship power between 4 key interchange nodes...

[1] https://news.ycombinator.com/item?id=16452926#16454026

OpenID Connect, aka. 'OIDC', is widely deployed. It's a compatible extension on top of OAuth 2.0, the latter of which was often used to provide third-party apps some delegated access to users' data at some data silo. This all coincided with the proliferation of HTTP-native APIs inspired by the easiest-to-implement tenets of REST. The payload of OIDC and OAuth 2.0 can be carried with in HTTP headers, which is a good fit for these APIs and simplifies implementation.

OIDC is used by some branded 'sign-in' buttons like 'Sign-in with Google' [1], and the new 'Sign in with Apple' feature is a close copy of the OIDC, if not yet directly conformant and compatible [2].

[1] https://developers.google.com/identity/protocols/OpenIDConne... [2] https://openid.net/2019/06/27/open-letter-from-the-openid-fo...