niftich

A few days ago, I was just thinking of the phrase 'This place is not a place of honor' and the foreboding aesthetic of the field of spikes warning nuclear waste buried below. I first saw this document many years ago, yet it stuck with me enough to have my mind wander to it on occasion.

Every time this is posted, many comments on this topic echo comments made in the past. This is reassuring, because many people throughout the years will independently arrive at some of the same critiques, as diverse as those critiques may be. There's concerns about the longevity of the artifacts intended to communicate the message, there's concerns about whether the symbolism will be understood to signify danger, and there's concerns about whether the message of danger will be heeded. There's also the argument that drawing overt attention to the site is more risky than concealing its location, and that avoiding the circulation of information about it is wiser than publicizing it and risk it becoming a legend that some may someday seek.

While it's difficult to design a message that transcends time, culture, and biology, and conveys the authority of the writers and the gravity of the warning, violence against intruders conveys the danger to those who value their existence. It won't necessarily protect against malevolence of someone seeking to unearth a weapon, or the arrogance of individuals willing to compel or force others to put themselves in danger in their stead, but the properties of nuclear waste in particular may enable a design that proves fatal to anyone who may enter the protected chamber, such that once they're through, they can never leave. Technology and telecommunications could still be used to extract material from the site, but only the most dedicated adversaries would be able to proceed.

Thinking on this, the obscurity argument is compelling. It relies on the vastness of the planet to approximate random chance, and force dedicated adversaries to devote time and resources in spacetime (in an analogue to cryptography and keyspace), while clearly marking a location aids those are intrigued by it and lets them skip to planning on how to exploit it. In times when a trustworthy defense force may protect the site from adversaries, the public location is hard to exploit, but in times when no such force exists, the obscurity forces an adversary to expend more work than if the location were known.

The notion that new construction being 'high-end' won't improve the market on the low-end is erroneous in markets where the spread of rent budgets of people forms smooth, continuous gradient. But the Bay Area is not such a market -- nor are places where significant cash infusions such as very high pay at the high-end or subsidies like military housing allowances to people of middle incomes will distort the field upwards. Then there's Prop 13, which disincentivizes the sale of legacy homes, removing many residents and homes in the middle of the income/rent spread from the liquidity of the market.

Developers want to build units that are 'high-end' because it's the best way to recoup their costs. Urban construction is expensive and many projects are made possible by a combination of loans, private equity funding, and government subsidies. The increase of supply in high-end apartments creates competitive pressure on older units, places with less amenities, places with dated design, and places in inferior locations. Since housing sorting resembles an auction, people with the highest rent budgets have the most options. Landlords of less ideal places will see some tenants filter out and replaced. Eventually, the replacements stop coming, because all people of higher rent budgets have already moved to more desirable places. Instead of letting apartments sit empty, the landlord might lower the rent while still staying within the profitability threshold.

This doesn't work every time. If people of high rent budgets never stop coming, they never have to lower prices: there's an undersupply on the high-end too. This is clearly the case in the Bay and other desirable areas of California.

The field does suffer a bit from version control, dependency management, language compilers, and build and packaging tools all being single-purpose tools that are layered, where one can't introspect others beyond the public API, and manual effort or simplistic not-always-true assumptions have to be used to bridge information from one to the other.

It's tempting to imagine an integrated system where making changes to a piece of source code automatically commits every change, every commit will attempt to compile and build, every successful build auto-packages into a new artifact with a new build version. The language and the build system would ensure that all builds are reproducible. Because of this, all builds can be addressed by identity (content hash) too, not just a name and a build number within some namespace.

When any dependency of the current project has newer builds, one could choose to pull up an interactive diff experience to step through the code of newer versions. This would aid in selecting a different version on which to depend, if desired. If a different version of a dependency is picked up, a new build gets triggered too, and a successful build gets a new build version.

The strong linkage between source code revision and build version, the deterministic builds, and content-based artifact addressing work together to ease the traceability of changes and the reusability of artifacts, and sidesteps concerns about the hosting and namespacing of source code and build artifacts interfering with the project's "single source of truth", because any copy of an artifact, known by any name, irrelevant of its location, will share the same hash.

There will still be usability problems with such a system too. There would be no way to strip data out. A shelve, replay, and cherry-pick frontend would be necessary to allow the doctoring of input before it's committed permanently -- but in such a system, only permanently committed code can be built. The workflow to prepare a project for public consumption would be to author and test all the changes in a 'scratch' project that doesn't auto-disseminate its build artifacts elsewhere, and cherry-pick the changes into a public project. Public projects could only have public dependencies.

Configuration files, data files, and pieces making up a larger environment may need a different approach. Nonetheless, a lot of these problems take the same shape: some input should deterministically produce some output, and a running system may choose to alter its own state by interfacing with a stateful outside world (e.g. load or write files, communicate through a network). The sensible places of drawing a boundary between the inside world and outside world will differ for every use-case.

I don't know if I'd look at it with that lens. Clearly, knowledge and analyses of this topic are resident in academia and have been long present at various levels of industry, but other factors like performance and power consumption have received generous affordances by hardware designers, and makers of system software and application software had to step in where the hardware provided little help for leak-proof sharing. In retrospect, the market may have rewarded hardware makers' direction of pursuit -- until now, but the survivors of those past pursuits remain.

Leak-proof sharing of resources may be a more marketable pursuit now, with cloud providers hosting code from mutually untrusted parties, and consumers running delivered applications and untrusted Javascript on the same machine, but I'd rather see the conversation about this topic improve across the board, independent from commercial forces.

Discussion also at https://news.ycombinator.com/item?id=19669380

This post lifts out the key parts of the paper [1] and is a good summary. I think the paper is an accessible read as well.

Not too much discussion two weeks ago when the paper was posted on HN [2], so I will raise a point I've made before [3][4][5] and is consistent with the recommendations of the paper (and another post in this thread [6]): this is an opportunity to improve the terminology, mental models, and formalisms of observable state, and its implications for information hiding, privilege separation, and computer system design.

This conversation needs not only to occur among (e.g.) computer chip designers and cryptography experts, but also among higher-stack users of that technology, so that the information leakage aspects and trade-offs can be analyzed together with other performance indicators of the system.

It seems as if the haphazard, ad hoc way that chipmakers and system architects dealt with this issue have contributed to an environment where Spectre could occur: and such timing attacks were never a secret, but resistance to them in various levels of mainstream computing appears to have been fitted in a patchwork of hasty fixes and well-meaning but informal caution. The conversation around this topic could use an upgrade, and the paper's authors agree.

[1] https://ts.data61.csiro.au/publications/csiroabstracts/Ge_YC... [2] https://news.ycombinator.com/item?id=19547293 [3] https://news.ycombinator.com/item?id=17308014 [4] https://news.ycombinator.com/item?id=16165942 [5] https://news.ycombinator.com/item?id=19644997 [6] https://news.ycombinator.com/item?id=19670296

It's no accident that one can see a similar result in timing attacks and information leakage from computer systems (e.g. Spectre and prior art), because in both cases, statistical inferences are being made from observable state.

Though this is an accessible paper that explores communication networks in detail, I'd still like to see more of these analyses conducted from a more abstract, information-theory perspective, and for these results to be broadly applied in various concrete settings.

I wonder if these sorts of fundamental underpinnings don't interface nearly as much with the daily mainstream line-of-business work that much of IT has evolved towards as they do in some other fields of applied science and design.

The Verge also did an interview with the designers [1]; I prefer The Verge interview to the Creative Boom announcement [2] that's the article link at the time of writing, because the interview adds detail behind the design process and reads much less like a marketing announcement.

Truly the most amusing thing about the new typefaces are the alternate forms of certain iconic letters. The alternate forms are more classically resemble the legendary Akzidenz-Grotesk, in the tradition of paring back the few flourishes that Helvetica did have.

Ironically some of the alternate forms also make it resemble Arial, Monotype's famous metric-identical Helvetica clone, despite Monotype's long insistence that Arial is less grotesk and more humanist. But I also found the not-sure-if-serious dissing of Arial to be mostly signalling and snobbery. Other alternate forms seem a bit odd, as if someone was playing 'design your own sans-serif typeface' and filled out the missing cells of a big row-column table for completion, like here's a geometric 't', and a humanist 'l'.

But all that aside, the new typefaces look nice and are redrawn with purpose. The micro variant actually makes Helvetica usable at small sizes for the first time. It's a well-crafted family in the honor of a classic.

[1] https://www.theverge.com/2019/4/9/18302057/helvetica-now-new... [2] https://www.creativeboom.com/resources/monotype-launches-the...

Sleeper trains are doing fine in Central and Eastern Europe, despite having to contend with some long running times. Sweden is trying to revive them through Denmark, which hasn't hosted night trains since 2014 [1].

There's two viable, existing routes for trains between the Central Sweden and Northern Germany. One's through the Fehmarn Belt rail ferry, and another is the long way through Jutland. Both ways take a long time compared to the distance covered. Stockholm is already ~5 hours by fast train from Copenhagen -- this segment of the journey stays the same. It's after that things get complicated and slow. Operational issues remain with changing voltages and train protection systems (ETCS Level 2 will be built out in a few years), or with the ferry.

A Fehmarn Belt fixed link would be a boon for such a service, like the article says. But it remains to be seen whether that will be built.

[1] https://back-on-track.eu/night-trains-to-europe-new-opportun...

Solar on the WEIM market [1][2], which (given more and more utilities joining) is more and more of the actual interconnected infrastructure within the WECC [3] -- including plants down south in CA, AZ, NV, NM.

The scenario to envision is that there will be times when solar is cheap enough to buy on the market that a hydro-heavy utility can ''reduce'' hydro generation during the day, and timeshift that same generation into later hours when solar drops off to sell it for profit.

A solar- or natgas-heavy, hydro-poor utility (e.g. San Diego Gas & Electric [5], NV Energy [6][7]) can't do the same, they have to invest in storage, buy power from elsewhere (where the exact source is abstracted away), or spin up more natgas at peak times. The latter two are the most popular solutions now, but regulations in California are now forcing [4] the first issue in CA.

[1] https://www.powermag.com/how-does-the-western-energy-imbalan... [2] https://www.westerneim.com/ [3] https://www.wecc.org/ [4] https://news.ycombinator.com/item?id=16560856 [5] https://sites.uci.edu/energyobserver/2018/12/28/comparison-o... [6] https://www.nvenergy.com/about-nvenergy/our-company/power-su... [7] https://www.eia.gov/state/?sid=NV

Idaho Power is one of the three big power companies that covers a portion of Idaho -- they serve the southwest, Avista is in the northwest, and PacifiCorp is in spots in the southeast [1].

Idaho Power has been, for several years, planning to pull out as a partner from the 3 coal power plants it has an ownership share in: North Valmy in NV, Jim Bridger in WY, and Boardman in OR [2]. Jim Bridger will have soon been due for an expensive upgrade because of environmental regulations, Boardman has seen consistent pressure from Oregon activists and regulators to bring the shutdown date closer, and North Valmy has seen less and less use because the other owner has succeeded meeting most of the Northern Nevada demand with a robust mix of natgas and solar, but also has fresh interconnects with Southern Nevada and Idaho.

In 2018, Idaho Power also joined [3] the Western Energy Imbalance Market, which streamlines realtime energy trading in the WECC interconnect. As time goes on and coal plants are retired, coal's share will decline in the energy mix, and there will be an increasing amount of quasi-'baseload' solar available to buy in the energy market. And for the times in the day when the solar generation drops off and natgas plants would often be the next sellers, Idaho Power has plenty of its own hydro it can deploy to compensate. But note that despite their well-situated position with renewables, their target for 100% renewables is still 2045 -- relatively far off.

[1] (PDF) https://oemr.idaho.gov/wp-content/uploads/3.6.18-Energy-Land... [2] http://www.spokesman.com/stories/2017/sep/16/power-company-m... [3] https://www.idahopower.com/news/idaho-power-customers-will-b...

Peak electrification in the US was in the 1930s and began falling in the 40s, but the Class I railroad route miles were almost 2.5x that of today. Electrification generally came about to reduce the impacts of steam traction (e.g. in cities and tunnels), to gain more power on grades, or to reduce the opex on high-traffic routes vs. steam.

In the decades after WW2, diesel-electric propulsion boomed, viable again after wartime shortages were over, simpler to maintain than steam, and more flexible than electric. This was well before double-stack trains got started in the 80s, but now that double-stack is widespread in the US, overhead electrification does present another operational hurdle.

Very accessible paper. They took the seL4 kernel, implemented a series of mitigations against timing leaks, and showed that their performance impact is tolerable and less than one might think.

While some of these mitigations have seen common use, their chief innovation is the on-demand cloning of (the majority of) global kernel data and state, which reduces resource sharing and allows the other partition and padded-flush mitigations to work better.

While they acknowledge that doing the same in a larger and differently-designed kernel would be a big undertaking, they also note that the hardware's uneven support and seeming lack of a formal mental model about this topic is unfortunate. Both software and hardware work would benefit from a focused approach in this area.

PostgreSQL 'TIMESTAMP', for nonextreme values, is the same idea as java.time.Instant -- an absolute point on the timeline stored internally as a number from some epoch -- but whose default textual interface accepts and emits java.time.LocalDateTime values that correspond, but aren't tagged with the UTC zone.

When you insert into a 'TIMESTAMP', it's as if it did input LocalDateTime(x).atZone(UTC).toInstant(), and saved that; and when you read it, it's as if it does storedInstant.atZone(UTC).toLocalDateTime().

A 'TIMESTAMPTZ' is stored the same way, but on string output is converted to the session timezone, and an underspecified input is enriched with the session timezone.

When you insert into a 'TIMESTAMPTZ' it'd take the input OffsetDateTime or ZonedDateTime, or enrich the input with the session zone until one were obtained, call .toInstant(), and save it. On read, it'd do storedInstant.atZone(sessionZone) to obtain a ZonedDateTime, and its default output format only includes the offset.

LocalDateTime is useful for calendaring, and as an intermediate step when joining a LocalDate and a LocalTime and working towards a Zoned or Instant.

Oracle has 'DATE', 'TIMESTAMP', 'TIMESTAMP WITH TIME ZONE', and 'TIMESTAMP WITH LOCAL TIME ZONE'.

Out of these, 'TIMESTAMP' and 'TIMESTAMP WITH TIME ZONE' do exactly what you'd expect without needing a big tutorial.

'DATE' is a 'TIMESTAMP' that can't store fractional seconds.

And 'TIMESTAMP WITH LOCAL TIMEZONE' is an unmitigated footgun that you'll probably misuse.

I feel that storing unix epoch seconds in a >=4-byte fixed length numeric or arbitrary precision numeric column is a reasonable choice if:

1) the record naturally has the semantics of a timestamp that is chiefly used for comparisons between values (e.g. to sort, min, max, subtract to get an approximate interval) and whose conversions to human-meaningful calendrical datetime are not needed or only need to be approximate (given unix timestamps' lack of leap seconds),

AND 2) you've thought about overflow (of both unix time and your column), signed-ness, sentinel and special values, and NULL handling,

AND 3) you're not enthused by the ANSI SQL definitions of TIMESTAMP types or think you, your RDBMS, your database driver, your programming language, your datetime library, or the code's next maintainer might screw something up.

If only the first factor isn't true, use an RFC 3339 UTC timestamp in a string column instead. If only the second factor isn't true, use one of the SQL TIMESTAMP types instead, so you can pick up a better-defined suite of behaviors.

I frequently wish that datetime libraries and APIs frozen in time and awkward design were given a second pass and redone in the style of Java 8 [1], which is a triumph of clarity after many years of lessons learned. Even putting out a new RFC would help move things along, because I've long felt that RFC 3339 is underspecified [2].

If datetime libraries were more thoroughly patterned after that of Java 8, there would be less need for the 'misconceptions programmers believe about datetimes' posts, and less need for the 'just use UTC' or 'maybe always-UTC isn't the right advice' posts, because the data-types are thoroughly reflective of their intended use, and their misuse is harder than in other APIs.

[1] https://docs.oracle.com/javase/8/docs/api/java/time/package-... [2] https://news.ycombinator.com/item?id=12364805

To build a rail line (or extension) in the US, you must ask the Surface Transportation Board for authority [1]. They also conduct an analysis of environmental impacts.

[1] https://www.stb.gov/stb/public/resources_construct.html

This time was indeed marked by the high popularity and increasing interop between classic IM networks, and the rise new networks. Some choice dates:

- 2005-09: Meebo launches offering web access to AIM, WLM, Yahoo

- 2006-02-07: Google Talk integration inside Gmail goes live

- 2006-03: Nielsen/Netratings survey for active users: AIM 53M, WLM 27M, Yahoo 22M

- 2006-07-12: seamless interop starts between Windows Live Messenger and Yahoo Messenger

- 2006-09-26: Facebook opens up to everyone (not just colleges)

- 2007-02-14: Gmail opens up to everyone (not just invite-only)

- 2008-04-06: Facebook chat goes live

- 2008-04-19: Facebook overtakes Myspace in Alexa ranking

- 2008-07-11: iOS App Store launches, AIM for iOS released

- 2008-08-26: Facebook hits 100 million active users

- 2008-09-23: Android 1.0 launches

More (and sources) in my earlier posts [1][2]. [1] https://news.ycombinator.com/item?id=13465483 [2] https://news.ycombinator.com/item?id=11114518

I get this recurring dream of a retrofuturistic world where intercontinental travel serviced by nuclear-powered ocean liners. For nonproliferation reasons, there's only a handful companies operating them, one for each theatre. It takes ~4 days to get across the Atlantic, so some amenities are inspired by cruise ships, but optimized for less crew. It's an intriguing dream, but in our current world the economic and regulatory barriers around nuclear propulsion for civilian use make it impractical. More on this later.

I believe economic forces and regulations will be the primary drivers of changing modes of transport, so if it makes economic sense to keep operating jet fuel aircraft, that will be an option for those who can afford it and don't have misgivings about it. But for planning and resilience, there's value in envisioning how a world with very limited jet fuel air travel would look like, and whether portions of its role ought to be taken over by other modes of travel, or if societies merely need to adjust to its loss.

Our world's globalized economy greatly depends on the movement of goods and sometimes people, but for goods, the pace of water transport is often good enough, coupled with its much lower cost per amount and time. Much of this transport uses some of the lowest grades of fuel you can get from fossil oil. To change this, the price of these fuels would have to soar or the fuel would need to be banned. Let's suppose this extreme case comes and fuel oil is no longer an option. A rapid migration to nuclear propulsion for merchant fleets is both politically untenable and economically improbable. Solar/battery propulsion doesn't have the energy density, which leaves wind-like propulsion as one of the only contenders, with the others being simply higher grades of hydrocarbons like gasoline and compressed gas. One's carbon-free, slow, and presents a significant change in show ships are built, while the other needs changes only to the engines, fuel lines, and fuel tanks, re-uses existing industrial expertise, and maintains the pace of travel -- but isn't carbon-free. Which one do you think companies would chose?

I think this piece takes too long to arrive at a underwhelming point, seemingly that prime transportation and activity corridors all want to co-locate because of interrelated and natural, rational reasons. This finding isn't obvious but is easily revealed, and though it's worth talking about, there's deeper insights if we continue the examination further.

Early road bypasses failed precisely because of the lack of development restrictions: they increased traffic and cheap land value drew businesses seeking to capitalize on it, so now the bypasses of yesteryear are of the urban fabric. The classic way to armor against this is to make the roadway limited access, and then you have development concentrating only at intersection nodes. Or the jurisdictions at play can always place additional restrictions on development.

But underneath all the SimCity we can play with roads and zoning, the transportation geography will always remain constrained to edges and nodes, corridors and chokepoints. It's these chokepoints that truly define the way people will get around, because getting to a point beyond them will require crossing it, and there's only ever a handful of time-effective paths to take between you and it. Bridges and mountain passes are the obvious chokepoints, but in a car-oriented world so are motorway interchanges and meetings of big arterials. Much criticism is levelled at US suburban development where single-family homes are plopped onto winding streets that only discharge to big avenues at subdivision entrances, so everyone has to take the big roads to get anywhere, but most European cities aren't that different: the lesser streets aren't passable at a pace that motorists have come to expect, and rarely does an uninterrupted network of them exist to get into a different part of the city using only small streets. Although the planning forces, commercial forces, and histories are different, they both arrive at the same result, of cars being channeled to a small number of higher-capacity paths, instead of distributed more evenly throughout.

There's cities that have leveraged the grid to great effect to arrive at a less crushing result. Las Vegas is a good example: attractions are located along a narrow corridor with heavy traffic that locals have learned to avoid. The rest of the urban area forms a large grid with dozens of avenues at regular intervals, and amenities and retail are sprinkled among housing. You have many options of traversing the urban area from one side to another.

There's other urbanized areas that have the same basic form, but they're imbalanced by a nearby node that draws traffic and upsets the network. Plano, TX looks really similar, but is a surburb to much larger Dallas. Other times, there's far too little commercial in a sea of residential, like much of South Florida or Inland Empire or Oklahoma City, or the desired directions of travel don't match the grid, like in Orange County, CA. Sometimes the grid is limited by natural obstructions that create chokepoints, significantly impairing the utility of the grid, like in Seattle, Minneapolis, or the connections of Manhattan to elsewhere.

One of the goals of railroads, motorways, subways, etc. is to "warp" and cheat the natural network and create connections among nodes that previously didn't exist, or weren't even nodes. This requires clever and thoughtful design that goes beyond simply putting transit along every avenue, or putting in more lanes.

An Altamont Pass segment ought to have been one of first things built. A faster 'Altamont Corridor Express' would have created a ~1-hour link between Stockton and the Bay, integrating the corridor's economy further beyond its current role as an overlong exurban commute. It would've also provided for an alternate rail routing between Sacramento and the Bay that'd be competitive with the Capitol Corridor.

After the initial push towards a 'Super ACE', Altamont lost in the planning to Pacheco Pass; this increased linearity and reduced distance in the SF-SJ-Fresno axis, but in my opinion it was the wrong move. Fresno's accession to the economic continuum of the Bay is far less likely than that of Stockton or Modesto.

The EU is working on extending the TEN-T road and rail network to Moldova and Ukraine as part of its Eastern Partnerships initiative [1], and they'll connect with existing and new corridors in EU member states. This will benefit Romania's Moldavia region, where there were no TEN-T corridors in the previous update in 2013, but is the region that borders both the Republic of Moldova and Ukraine.

Suceava, where this 1-meter motorway was built, will likely find itself on a corridor between Bucharest and Lviv (UA) and on another from Cluj-Napoca to Iași and Chișinău (MD) and Odessa (UA). This will unlock EU funding bring upgraded roadways and railways to this region.

[1] https://ec.europa.eu/transport/themes/international/european...

He's fed up and so are lots of people rallied behind him, because the problem is that bad. The Romanian road network is deficient and overburdened. Aside from commuters stuck in traffic, there's also lots of trucks. Most roads are undivided and overtaking is allowed. Safety culture among drivers is poor, deaths are high [1]. Sadly, road fatality rates in non-EU countries in the same region are even higher.

The EU is a critical source of funding for major infrastructure projects, especially for newer members who also have access to convergence funds. Road projects are expensive not only because of costs in design, land acquisition, and construction materials, but because they require large amounts of labor over several years. While it's often the same multinational consortia who bid on and win such construction projects, these firms aren't set up to do everything by themselves, and partner with local subcontractors for much of the work. The way work gets subcontracted makes this process vulnerable to corruption and graft. But sometimes it's the big consortia that get themselves into a problematic situation: just read up on Bechtel and Viaduct at Suplacu de Barcău.

EU transport and convergence funds might be a big help, but they do come with a few strings attached: they have to be used for projects that can be justified though a regional or EU-wide lens. On top of the slow pace of progress on the matter, Moldavia has an unfortunate geographic situation that puts it far away from the most important transit corridors -- the TEN-T corridors -- that EU desires to prioritize. In Romania's case, this means that connections towards Hungary and Bulgaria have so far made more progress than connections towards Ukraine and Moldova.

[1] https://www.euronews.com/2018/12/07/which-countries-in-europ...

[1] Canada blamed for India's 'peaceful' bomb [Radio broadcast]. (1974, May 20). In As It Happens. Ottawa, Ontario: Canadian Broadcasting Corporation. Retrieved March 14, 2019, from https://www.cbc.ca/archives/entry/1974-canada-blamed-for-ind...

[2] Perkovich, G. (2001). India's nuclear bomb: The impact on global proliferation. Berkeley, CA: University of California Press. <https://books.google.com/books?id=UDA9dUryS8EC>

[3] Ramana, M V (2012). The Power of Promise: Examining Nuclear Energy in India. Penguin Books Limited. <https://books.google.com/books?id=5m8Atq0ncrwC>

India has an intricate history with nuclear technology. Both the Soviet Union and the US courted India in the 1950s, but in the end it was Canada who donated a design for the first Indian reactor that came online in the 1960s. The US assisted with building another. Indian testing of nuclear weapons in the 1970s drew a sharp rebuke from several countries and the US and Canada withdrew their assistance. This also resulted in the creation of the Nuclear Suppliers Group, an export control regime to prevent nuclear proliferation. Cut off from exporters of nuclear technology, they slowly continued with domestic designs and new research. But their tremendous size and influence made them an attractive partner in geopolitical power plays.

In 1988 the Soviet Union and India announced they would build two new reactors, and the US fiercely protested at the time. The Soviet Union fell apart, and the Russians didn't resume the project for another 10 years, but construction eventually began in 2002. In 2006 the US and India reached an agreement to cooperate and the US lobbied for an exemption for India from the Nuclear Suppliers Group, which was granted. It quickly became obvious that everyone wanted a slice of the Indian nuclear energy market.

Disregarding climate change for a moment, it's clear that the energy demand in India is increasing, and despite a rapid rise in the deployment of renewables, utility-scale generation is still 75% coal. This contributes greatly to pollution. Local coal lower quality than elsewhere, requiring more per unit of power. Nuclear will be an important complement to renewables as the energy mix slowly migrates off of coal. Unlike the US, which is awash in cheap natural gas that's readily stored and piped where needed, helping to even out the mismatch between solar generation and demand, India has very little natural gas, so it can't afford to pursue a strategy that deemphasizes nuclear energy.

Sourcehut's design seems inspired by terminals and line-oriented interfaces more so than early 2000's boxy HTML, so some choices are head-scratchers.

The lack of visible bounding boxes or ("old-style") underlining around the core navigation links draws inspiration both tab-oriented keyboard navigation and very modern, ~201x UI design, but lifts only their outward look without incorporating strengths from each: it neither has strong indicators of a series of menu items that can be stepped through (like a right-facing triangle to the left of the menu item's text), nor does it evoke the Metro-style UI, where UX-meaningful text is king on a sparse field. Underlining each link in the top bar would immediately communicate that many of the words are clickable but not all; as would the use of background shading and color to set the static top bar apart from the rest of the page content. Or even just a 1px bottom border.

Similarly, visual suggestion of tabs for 'summary', 'tree', etc, is not very convincing in a browser. Desaturated borders around the inactive tabs would clearly communicate that there's a tabbed interface here. Bolding of the text of the active tab would reinforce that further.

EDIT: When I think about minimalism on the web, I'm inspired by the box model and by occasionally-visible borders, which help translate the tree structure of the page into a coherent interface. Borders have gone out of fashion in mainstream design, and so has the use of text decoration for links, so it's harder now to distinguish between interactive and static elements in an interface. Sourcehut's 'spartan' take on this misses an opportunity to clarify a distinction that's been lost in other schools of design.

Coal-based generation in Nevada (from coal mined elsewhere) does exist, but the remaining plants are in the I-80 corridor, linked to Southern California only through a circuitous routing that's not commonly used -- that energy goes to Reno and Idaho instead.

Outside-of-California coal plants that significantly and regularly contribute to Southern California's energy mix are Navajo (in Page, AZ) and Intermountain (in Delta, UT). These are Los Angeles Department of Water and Power (LADWP)'s share and get mixed in through them. There's even a dedicated HDVC line [1][2] between Intermountain and Victorville.

The coal for Navajo is mined in Kayenta, AZ, and the plant's effects are multifaceted. It came about as a compromise when dams affecting the Grand Canyon were cancelled, and the mine and plant create jobs and lease payments for the Navajo Nation, but it also pollutes land and is used to power cities far away.

The coal for Intermountain is mined in Utah, Colorado, or Wyoming, depending on market forces.

LADWP has set goals to switch off of coal in the coming years, including considering converting Intermountain to natgas. Navajo's prospects are not good -- they're under regulatory and economic pressure, and conversion to natgas is not viable due to the lack of pipelines to the area.

[1] https://en.wikipedia.org/wiki/Path_27 [2] https://www.openstreetmap.org/relation/3392214

San Bernardino County is home to the Ivanpah Solar Power Facility [1], which is a mirror-focused solar thermal power plant. It generates a lot of glare and is controversial for its impact on animals. It also took several years to ramp up to its promised output.

Solar panels don't have problem with glare, but the landscape of the county has large viewsheds of sloping treeless desert, so any facility will have a large visual impact. It also disturbs the ground and replaces the desert scrub with actual bare ground, which is more susceptible to dust, and dust is a problem that plant operators try to combat [2], but have long accepted as an inconvenient reality of siting in the desert.

[1] https://en.wikipedia.org/wiki/Ivanpah_Solar_Power_Facility [2] https://ieeexplore.ieee.org/document/7274289

I don't agree with that quote being used to define software rot, and I don't think the examples illustrate rot either. I'm just fundamentally opposed to the terminology of the rotting metaphor when it's applied to projects that receive active upkeep, even if the project drifts further from its original scope and vision. For that, we need a name for that that alludes to scope creep and refactoring, but one that isn't suggestive of decomposition at the mercy of the environment of things immobile and abandoned.

I've always understood software rot to refer only to cases where the dependencies, including libraries and platform APIs, are changed so that an already-delivered copy of the software can no longer function, and the maintainers have since abandoned it, or can't do a quick fix to get it working again.

A recent example is the removal of support for NPAPI plugins in Firefox [1] in 2017. Firefox is in the role of the 'platform API' here, and this change of theirs broke any extension that didn't update. And, the replacement API differs in features, so the effort of updating an extension approaches that of a rewrite.

Another example is the game 'Star Wars Episode I: Racer', the podracing game from 1999. Newer versions of Windows and DirectX have changed things so that the game's original executable doesn't run [2].

Even open source isn't a remedy. Random projects one can find on a source repo, last updated x years ago, are code that are susceptible to this. Sometimes they're shipped without dependency management, pinned to old versions that themselves no longer work, or track the latest when they should be pinned instead. If more work is required to get it running than just the instructions provided by the author (assuming those were sufficient at some point), then it has suffered software rot.

[1] https://support.mozilla.org/en-US/kb/npapi-plugins [2] https://www.play-old-pc-games.com/2013/12/02/star-wars-episo...