Yep. Google, at least, started this transition during Trump1.

The company has long had engineering sites in various other countries, but until Trump1, the primary focus was always on cities where Google thought the global talent would want to live. Low cost was clearly not the driving factor in the selection of London, Zurich, Munich, Tokyo and Sydney, to name a few of the ones I visited. US sites were similarly not located in low-rent areas. The workforce was definitely global, because Google wanted to hire the smartest people and while the US does have its share of brilliant minds, the US has only 4% of the world's population, so most teams -- even in the US -- ended up being minority American.

During COVID, Trump leveraged the health crisis to essentially halt H-1B approvals and renewals. This caused significant problems for Google. My own team lost a few people because they couldn't get their visas renewed and had to go back home. Some chose to move to other Google sites overseas where Google could get them a work visa, others simply went back to their home countries. One trans woman on my team was in a particularly tough spot because her home country (India) refused to renew her passport because it didn't recognize her new gender. She couldn't get her visa renewed, couldn't go home to India, and also couldn't move to any other country with an expired passport. Luckily, she had a lot of nVidia and Google stock she'd been saving up to buy a house, and by cashing that out had enough free cash to get an EB-5 "investor" visa. It's good to be rich, of course.

Anyway, Google saw what was going on and, anticipating future troubles of the sort, refocused its overseas office plans on building up teams and infrastructure, especially in India which provided so much of Google's engineering talent anyway, with the intention of shifting whole projects and workstreams there. The company had long required a significant percentage of all staffing growth to be in the US (and especially in the bay area), but that policy was scrapped and replaced by its opposite: A certain percentage of all new roles must be based overseas.

It's still the case that the center-of-mass of Google is in the bay area, but the company is actively working to change that, to build up overseas capacity, and not just groups of junior engineers under a manager whose role is to pass them detailed requirements for implementation, but instead full teams with highly-skilled and experienced senior engineers and managers able to take full ownership of major product areas and move them forward.

Trump's latest moves will just accelerate this transition. The result will eventually be a hollowing out of the company's US capacity, and therefore a reduction in the need to hire American engineers. Lucky for me, I'm leaving Google for a startup and anyway am not far from retirement. Between this stuff and AI being poised to replace junior engineering staff it's a good time to be getting out.

Also, I think it will soon be time to start shifting investments out of the US.

I currently work hybrid. It reduces my effective pay by around 10%, which is a hell of a cut. It gains me nothing, since all meetings - even when we're all in the same room - are via teams, because company policy.

I see no added value from visiting the office.

Wine runs in user space. I don't see how Wine could ever run drivers, such as peripheral drivers required by things like the iPhone sync functionality of iTunes or kernel-level anti-cheat required by major online games supporting pickup matches with strangers.

People who use software that requires Windows are "forced" to buy Windows along with a new PC. An OEM Windows 10 license that came with a PC is locked to that PC. A new PC purchased to replace a PC that cannot be upgraded to Windows 11 will come with a new Windows license.

Start with stage0 (whose binary seed is about 1 KiB) and GNU Mes. Use mescc to build tinycc, then GCC 2.95, then GCC 4.7, then fairly modern GCC, and then use mrustc to build some version of Rust. The time-consuming part is that each version of the Rust toolchain uses fairly new features in the Rust language, so yes, you'll probably have to build the world a couple dozen times starting with the most recent version supported by mrustc.

Cppcheck doesn't flag anything in Waffle Iron's example.

It also doesn't find anything wrong with:

std::vector<int> vec = {1, 2, 3, 4, 5};
auto it = vec.begin();
vec.push_back(6);
std::cout << *it << std::endl;

Which is another common example of how you can write memory errors without using C++ pointers.

Sure, so C++ is safe as long as it's used in a way that makes it incredibly painful. Sounds good. Let's just require all C++ code everywhere to be written that way. Rust usage will skyrocket overnight.

He unintentionally used Signal? How drunk was he?

For a really rigorous definition of "fair", it's impossible to have fair democracy at all. Arrow's Theorem demonstrates this to a large degree, although many have argued that some of his fairness axioms are excessive. More recent research has concluded that fairness is the wrong standard, because there's no way for an electorate's "will" to really be fairly represented by any electoral system, not in all cases. Some systems can do better most of the time (and "winner take all" is particularly bad), but all systems fail in some cases.

What we need to aim for instead of fairness is "legitimacy", which is more about building broad acceptance of the system than about fixing the system itself, though it's easier to build acceptance for better-designed systems.

Having the country's top politicians continually claiming the system is unfair and rigged is, of course, the worst possible thing to do if you want to build support for the legitimacy of the system.

I decided to check :-)

According to the Book Censorship Database from the Every Library Institute, both "Of Mice and Men" and "Adventures of Huckleberry Finn" have been challenged, but only "Of Mice and Men" was removed, though "restricted" is more accurate. The Birdville Independent School District in Texas removed the book from general access, allowing access only to the AP English class, and the Indian River County Schools in Florida restricted it to high school students.

No Doctor Suess books were banned, although Suess Enterprises voluntarily ceased publication of six books.

If I had to guess, we let this happen by the USA electing George W. Bush in 2000. His incoming Attorney General settled United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001), with a wrist slap instead of a Windows division breakup.

You probably guessed correctly: equitable relief in the form of an injunction against Disney bringing a trademark lawsuit. I haven't read the complaint, but I'd be surprised if it didn't cite Kellogg and Dastar.

The Supreme Court of the United States has decided a few cases about the interaction between the Lanham Act, which inclues trademark law, and exclusive rights pursuant to the Copyright Clause. Key cases includes Kellogg Co. v. National Biscuit Co., 305 U.S. 111 (1938), and Dastar Corp. v. Twentieth Century Fox Film Corp., 539 U.S. 23 (2003). In both cases, the Court ruled that the Lanham Act cannot be used to extend the effective term of exclusive rights in an invention whose patent has expired or a work whose copyright has expired. Disney's legal counsel ought to be familiar with the latter case, seeing as it involved a company that is now a subsidiary of Disney.

From the article:

The Go project recently arranged for Go itself to be completely reproducible given only the source code, meaning that although a build needs some computer running some operating system and some earlier Go toolchain, none of those choices matters."

[...]

The Multics review is famous for pointing out the possibility of adding a back door to a compiler to insert back doors in critical system programs during compilation [...]. Reading the report inspired Ken Thompson to implement exactly that attack on an early Unix system, probably in early 1975. He later explained the attack in his 1983 Turing Award lecture, published in Communications as "Reflections on Trusting Trust."

David A. Wheeler described a defense against a back door that propagates through the compiler in a 2009 PhD dissertation titled Fully Countering Trusting Trust through Diverse Double-Compiling . Diverse double-compiling (DDC) involves choosing two or more other independently developed compilers A and B for a language, bootstrapping compiler C from source code through each of them (building C with A or B and then building C with itself), and ensuring that the output is byte-identical. This relies on previous effort to make builds reproducible.

However, DDC also relies on having more than one implementation of a particular language. Go and Rust each have only one widely used implementation. This means someone trying to wrangle a supply chain has to do one of three things: trust a particular old version of a compiler not to have a back door, compile every version since the dawn of the language (such as when Rust was prototyped in OCaml), or implement a usable subset of the language in a more widely implemented language. This is why mrustc is so important, as it's a way to skip forward by several years' worth of versions when bootstrapping a Rust compiler.

From the article: "The only problem left is key distribution: The verifier must know who should have signed the code. [...] To the extent that questions of identity can be solved, having authors sign their software can provide even stronger guarantees." It goes on to describe how Debian and Go package repositories include the expected hash value of a package, so that package downloading tools can reject a package that has been replaced.

However, the approach used by Debian to verify developers' identity, that of new developers physically meeting existing trusted developers at key signing parties to exchange OpenPGP public keys, doesn't scale very well. A lot of contributors are disconnected from the strongly connected set of the web of trust because they cannot travel to key signing parties. This can be because of cost, work or child care scheduling, regulatory restrictions related to geopolitics, or regulatory restrictions related to public health (most recently during 2020-2021). These disconnected contributors must forever rely on the bottleneck of "sponsors" (trusted developers who forward packages from the maintainer to the distribution) to get their work into a distribution.

And sponsors are indeed a bottleneck. From the article: "And then you need to be ready to update to a fixed version of that dependency." When a package's upstream maintainer releases an updated version of a package, the package's sponsor in a particular distribution may be too busy with other tasks to handle it the same day. This can mean that there is no available labor to forward the update to the rolling distribution and backport the fix to the version of the package in a stable distribution.

Ish.

I would not trust C++ for safety-critical work as MISRA can only limit features, it can't add support for contracts.

There have been other dialects of C++ - Aspect-Oriented C++ and Feature-Oriented C++ being the two that I monitored closely. You can't really do either by using subsetting, regardless of mechanism.

IMHO, it might be easier to reverse the problem. Instead of having specific subsets for specific tasks, where you drill down to the subset you want, have specific subsets for specific mechanisms where you build up to the feature set you need.