Web Excursions 2021-10-10

Can Nuclear Fusion Put the Brakes on Climate Change?

The M.I.T. team continued to dedicate its time to ARC/SPARC, quilting together fellowships and grants. At one point, to make payroll, technicians went into the basement and loaded trucks with scrap copper to sell. SPARC Underground was set up—a group of interested scientists who met regularly, to discuss plans and work through difficulties. They needed to buy as much H.T.S. as they could, in order to learn more about the material’s characteristics—hammer it, heat it, freeze it, send current through it. “I remember so well the first shipment of H.T.S.,” Mumgaard said. “We waited for months to get this reel of material. It was only five hundred metres. Now, if we’re not talking ten kilometres, we’re not talking anything. These days, you can order this stuff on Alibaba.com. But then—it was such a moment.”

Much of what seems difficult about fusion to a plasma physicist—How will tritium be produced and recycled? How can edge-localized modes be anticipated and countered? Will quantum computing enable the study of electromagnetic waves in a plasma?—is so much Greek to a layperson. In contrast, much of what seems difficult about fusion to a layperson—super-hot plasmas, magnetic bottles, toroidal coils—is bread and butter for a fusion scientist.

There are at least twenty fusion startups now, all benefitting from technological advances in 3-D printing and artificial intelligence. The companies have different risks.

Destiny's Animators Studied Boxing to Keep You From Getting Sick by polygon.com

  • How that game's graceful characters and elegant weapons feel so good to inhabit from the first-person perspective.

  • The secret is all in how the camera —

    • essentially the cone of vision that player sees —

    • moves in relation to the rest of the avatar's body.

  • If the camera remains still as a avatar moves through the world,

    • the game can feel light and floaty.

    • But if you are too agressive with the movement of that camera,

      • people will get motion sick.

  • Helsby turned to the world of boxing, studying in detail how boxer's heads moved when they threw a punch.

    • they have intent.

    • The head leads the action. ...

      • When the boxer is setting up [his punch] he's also setting up with this anticipation to strike. ...

      • Then, as he starts to throw the punch, his head actually starts to lead that action or that hit, leading the arm.

      • And then as the boxer is about to make contact with his target and his arm is about to cross the centerline of his body,

        • the head actually starts to go in the opposite direction.

      • And this is because his body is trying to keep on balance ... and the head returns over the center of the body.

    • That same kind of intentionality, of leading actions with the head,

      • is a big part of all the animations in the game,

      • be it strafing from side to side, throwing a grenade, or simply taking a step forward

  • in the final game, if you look carefully you'll notice that

    • every time your avatar makes the throwing motion the first thing they do is lower their primary weapon.

    • That simple fix meant that instead of 25 animations, his team only had to make one.

  • the first-person animation team settled on a field of view of 77 degrees early in the design process

    • they finally settle on 72 degrees.

    • that wider field of view in the foreground

      • provides room for the avatar's arms and weapons to flash through the player's field of vision, and

      • directly contributes to the immersive quality of the Destiny's animations.

Progress Report: September 2021 - Asahi Linux by asahilinux.org

  • The goal of the Asahi Linux project is to upstream everything into the Linux kernel, so all our drivers are eventually headed for upstream review.

  • USB-C PD driver (tps6598x, merged):

    • M1 machines use Texas Instruments USB-C controller chips,

    • which handle things like USB-PD negotiation and alternate modes.

    • Linux already has a basic driver for the TPS6598X versions,

      • but the chips in M1 machines are special Apple variants (CD3217/CD3218) which are slightly different.

  • I²C driver (i2c-pasemiin review):

    • The M1 borrows its I²C hardware from… none other than the PA Semi PWRficient PA6T-1682M, used in the AmigaOne X1000 [Note: AmigaOne X1000 is a PowerPC-based personal computer intended as a high-end platform for AmigaOS 4.]

    • Turns out there is some clear PA Semi legacy in these chips

    • Linux already has a driver for this hardware,

      • but on the PowerPC chips it is a PCI device,

      • while on the M1 it is a platform device.

  • ASC mailbox driver (apple-mailbox, in review):

    • Apple SoCs have tons of different side cores to handle auxiliary tasks, and

    • these cores need to communicate with the main CPU.

    • These are known as “ASC"s, and

      • they all share the same low-level “mailbox” hardware.

  • IOMMU 4K patches (in review):

    • The M1 is peculiar in that, although it supports OSes that use either 16K or 4K pages, it really is designed for 16K systems.

    • Its DART IOMMU hardware only supports 16K pages.

    • These chips have 4K support chiefly to make Rosetta work on macOS,

      • but macOS itself always runs with 16K pages – only Rosetta apps end up in 4K mode.

    • Linux can’t really mix page sizes like that and likely never will be able to, so we’re left with a conundrum:

      • running a 16K kernel makes compatibility

        • with older userspace difficult (chiefly Android and x86 emulation),

        • plus distros don’t usually ship 16K kernels;

      • while running a 4K kernel runs into a major mismatch with the DART.

    • This initially seemed like a problem too intractable to solve,

      • but Sven took on the challenge and now has a patch series

        • that makes Linux’s IOMMU support layer play nicely with hardware

          • that has an IOMMU page size larger than the kernel page size!

    • It’s not perfect,

      • as it can’t support a select few corner case drivers

        • (that do things that are fundamentally impossible to support in this situation),

      • but it works well and will support everything we need to make 4K kernels viable.

  • Device Power Management (apple-pmgr-pwrstate, in review):

    • A fundamental part of any modern power-efficient SoC is the ability to turn parts of itself on and off, to various extents, to save power.

    • On many SoCs this is handled as discrete hardware

      • that can do things like control power to different blocks, turn clocks on and off, etc,

      • requiring complex sequences of operations.

    • Apple SoCs instead have a much higher level interface

      • that automates most of the hard work.

  • CPU frequency scaling (apple-cluster-clk, final cleanup before RFC):

    • Continuing the power management theme, Linux needs a driver for CPU core frequency scaling.

      • At boot, the 4 “Icestorm” efficiency cores are at max performance,

      • but the 4 “Firestorm” performance cores are at the lowest performance state.

    • Similar to device PM, the M1 has a very high level interface for this,

      • but with a twist: in higher CPU performance states, it is also desirable to adjust the memory controller configuration

      • to increase system performance.

  • NVMe + SART (apple-ans-nvme/apple-sart, in development/functional):

    • The NVMe hardware in the M1 is quite peculiar:

    • it breaks the spec in multiple ways, requiring patches to the core NVMe support in Linux, and

    • it also is exposed as a platform device instead of PCIe.

    • In addition, it is managed by an ASC, the “ANS”, which needs to be brought up before NVMe can work, and

    • that also relies on a companion “SART” driver, which is like a minimal IOMMU.

  • On typical SoCs, drivers have intimate knowledge of the underlying hardware, and they hard-code its precise layout

    • This is effectively a requirement for most SoCs,

      • because hardware tends to vary quite a bit from generation to generation,

      • so drivers always require changes to support newer hardware.

  • Apple is unique in putting emphasis in keeping hardware interfaces compatible across SoC generations –

    • the UART hardware in the M1 dates back to the original iPhone

    • This means we are in a unique position to be able to try writing drivers

      • that will not only work for the M1,

      • but may work –unchanged– on future chips as well.

    • This is a very exciting opportunity in the ARM64 world.

    • [Note: Shac Ron (@stuntpants) [kernel ee at aapl], in a reply to asahi team’s tweet that M1 “has I2C hardware (required for USB, Thunderbolt and the speakers) dating back to P.A. Semi in the 2000s”, said: “We spent a lot of time convincing the silicon teams that maintaining a stable register interface is important and shouldn’t be changed unless you have a very good reason.” ]

  • This does require thinking differently about things.

    • Instead of hard-coding the precise layout of the hardware in the driver,

    • we rely on the Device Tree to provide that information:

      • the parts that are “parameters” that change from device to device,

      • without fundamentally changing how they work.

    • For example, on other SoCs, the device power management driver would drive a single device, and

      • provide power management for all on-board devices as a hard-coded list.

      • Our PMGR driver instead is actually instantiated for every device that has to be managed, and

        • controls a single register;

        • the device tree then can be used to represent the dependency relationships between these power domains dynamically.

  • With these drivers, M1 Macs are actually usable as desktop Linux machines

    • While there is no GPU acceleration yet,

    • the M1’s CPUs are so powerful that a software-rendered desktop is actually faster on them

      • than on e.g. Rockchip ARM64 machines with hardware acceleration.

Gmail password first character is case insensitive on mobile device - Gmail Community

Fish Nm [Original Poster]:

When using Mobile device (Both Android and IOS) browser (Chrome , Safari), the gmail password first character becomes case insensitive.


  • I'm not sure, but I THINK we had information that due to auto-cap on mobile devices that

  • the case of the FIRST character in a password was ignored.

  • Passwords are totally case sensitive on other platforms (like a computer).


  • I tried signing into an account whose password starts with an upper case first letter using Chrome on my Android phone.

    • It would not accept the password with a lower case first letter.

  • I was able to add the account to the Gmail app using the lower case first letter.

    • Looks like the app is clever enough to try changing the case of the first letter if the first attempt fails.

Gmail password first character is case insensitive on mobile device | Hacker News


  • This is a well-understood feature. Facebook does the same thing. Quote:

  • Facebook actually accepts three forms of your password:

    • Your original password.

    • Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word.

    • Your original password with the case reversed, for those with a caps lock key on.

  • They may have changed it, but it was certainly working in 2017


iirc, on mac capslock works like (caps OR shift) and on windows its (caps XOR shift), that is, on mac, with capslock on its always cap, but on windows its just a toggle.


Is this implemented by Facebook holding 3 hashes of your password?