CNBC:

Google will pay $7.35 per share in cash for the acquisition, Fitbit said. Fitbit’s all time high share price was $51.90 on Aug. 5, 2015, a couple months after its stock market debut at $30.40. The deal is expected to close in 2020, according to the announcement.

Apple is showing that wearables are a huge market moving forward, and no one else is doing them right. I don’t see Fitbit helping Google here.

Daisuke Wakabayashi:

The hardware business is very hard. Even if you “make it” and avoid burNing all your cash, the best you can hope for is to be gobbled up by a giant. Nest (Google), Ring (Amazon), Eero (Amazon), Beats (Apple) and, now, Fitbit (Google).

Off the top of my head the only hardware startup of this era that’s seemingly standing on its own is Tesla. And I’m not sure how long that’s going to last.

Ben Bajarin:

Fitbit 2019 revenue estimates are $1.45B so Google buying for $2.1B is not even 2x revenue.

When negotiating an acquisition 3x revenue is usually the baseline. This is telling about the state of Fitbit.

I don’t know anyone who’s bought a Fitbit device recently. I know runners and cyclists with Garmin watches, but I don’t know anyone still wearing a Fitbit.

Click here to go see the bonus panel!

Hovertext:
This comic dedicated to Noah Smith.

thedemoscene:

Rendering the full scene description for the island from Moana ( 70 GB of data on disk for a single frame).

Part 1

Part 2

Part 3

Part 4

Part 5

This is a fantastic exploration of how to optimize really resource-intensive software. The memory footprint of the parsed data is completely insane.

When we last met UDOO, the team was building a powerful Raspberry Pi-based DIY board with a bunch of impressive features, including more ports and a better processor. Now the team behind the first units has released the UDOO BOLT, a DIY board that can run “AAA games” thanks to a built-in AMD Ryzen Embedded V1202B 3.2 GHz SoC processor and a Radeon Vega 3 graphics card. The system is also Arduino compatible so you can connect it to your robotics and other electronics projects.

The BOLT, when outfitted with a chunk of RAM, is, according to the creators, “almost twice as powerful as a MacBook Pro 13-inch equipped with an Intel i5, and three times more powerful than a Mac Mini.” Because it is nearly a fully fledged computer, you can stick it into a case and treat it like a mini-workstation with a USB keyboard and mouse and HDMI out to a monitor. The BOLT can drive four monitors at once, two via 4K HDMI and two via USB-C. It runs Linux or Windows.

The team plans to ship in December 2018. The starter kit costs $298 on Kickstarter and includes a power supply and 4GB of RAM. The 8GB unit with SATA and Wireless costs $409.

Is a DIY board with a massive processor and graphics card a bit of overkill? Absolutely. However, because the system is designed for experimentation and on-the-fly design, you can easily repurpose a board like this for a kiosk, store display or workstation. Because it is so portable, you could slap a few of these on school desks and give the kids powerful computers that run nearly everything you can throw at them. Plus, it’s pretty cool to be able to play VR games on a machine the size of a peanut butter and jelly sandwich.

UDOO has been adding onto the traditional Raspberry Pi/Arduino stack for so long that they’ve become experts at making basic boards much more powerful. Given their earlier models could run drones and control multi-legged robots all while running Android, this new product should be a real treat.

I spent some time yesterday building out a UEFI server that didn’t have on-board hardware RAID for its system drives. In these situations, I always use Linux’s md RAID1 for the root filesystem (and/or /boot). This worked well for BIOS booting since BIOS just transfers control blindly to the MBR of whatever disk it sees (modulo finding a “bootable partition” flag, etc, etc). This means that BIOS doesn’t really care what’s on the drive, it’ll hand over control to the GRUB code in the MBR.

With UEFI, the boot firmware is actually examining the GPT partition table, looking for the partition marked with the “EFI System Partition” (ESP) UUID. Then it looks for a FAT32 filesystem there, and does more things like looking at NVRAM boot entries, or just running BOOT/EFI/BOOTX64.EFI from the FAT32. Under Linux, this .EFI code is either GRUB itself, or Shim which loads GRUB.

So, if I want RAID1 for my root filesystem, that’s fine (GRUB will read md, LVM, etc), but how do I handle /boot/efi (the UEFI ESP)? In everything I found answering this question, the answer was “oh, just manually make an ESP on each drive in your RAID and copy the files around, add a separate NVRAM entry (with efibootmgr) for each drive, and you’re fine!” I did not like this one bit since it meant things could get out of sync between the copies, etc.

The current implementation of Linux’s md RAID puts metadata at the front of a partition. This solves more problems than it creates, but it means the RAID isn’t “invisible” to something that doesn’t know about the metadata. In fact, mdadm warns about this pretty loudly:

# mdadm --create /dev/md0 --level 1 --raid-disks 2 /dev/sda1 /dev/sdb1
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90

Reading from the mdadm man page:

   -e, --metadata=
...
          1, 1.0, 1.1, 1.2 default
                 Use  the new version-1 format superblock.  This has fewer
                 restrictions.  It can easily be moved between hosts  with
                 different  endian-ness,  and  a recovery operation can be
                 checkpointed and restarted.  The  different  sub-versions
                 store  the  superblock  at  different  locations  on  the
                 device, either at the end (for 1.0), at  the  start  (for
                 1.1)  or  4K from the start (for 1.2).  "1" is equivalent
                 to "1.2" (the commonly preferred 1.x format).   "default"
                 is equivalent to "1.2".

First we toss a FAT32 on the RAID (mkfs.fat -F32 /dev/md0), and looking at the results, the first 4K is entirely zeros, and file doesn’t see a filesystem:

# dd if=/dev/sda1 bs=1K count=5 status=none | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  fc 4e 2b a9 01 00 00 00  00 00 00 00 00 00 00 00  |.N+.............|
...
# file -s /dev/sda1
/dev/sda1: Linux Software RAID version 1.2 ...

So, instead, we’ll use --metadata 1.0 to put the RAID metadata at the end:

# mdadm --create /dev/md0 --level 1 --raid-disks 2 --metadata 1.0 /dev/sda1 /dev/sdb1
...
# mkfs.fat -F32 /dev/md0
# dd if=/dev/sda1 bs=1 skip=80 count=16 status=none | xxd
00000000: 2020 4641 5433 3220 2020 0e1f be77 7cac    FAT32   ...w|.
# file -s /dev/sda1
/dev/sda1: ... FAT (32 bit)

Now we have a visible FAT32 filesystem on the ESP. UEFI should be able to boot whatever disk hasn’t failed, and grub-install will write to the RAID mounted at /boot/efi.

However, we’re left with a new problem: on (at least) Debian and Ubuntu, grub-install attempts to run efibootmgr to record which disk UEFI should boot from. This fails, though, since it expects a single disk, not a RAID set. In fact, it returns nothing, and tries to run efibootmgr with an empty -d argument:

Installing for x86_64-efi platform.
efibootmgr: option requires an argument -- 'd'
...
grub-install: error: efibootmgr failed to register the boot entry: Operation not permitted.
Failed: grub-install --target=x86_64-efi  
WARNING: Bootloader is not properly installed, system may not be bootable

Luckily my UEFI boots without NVRAM entries, and I can disable the NVRAM writing via the “Update NVRAM variables to automatically boot into Debian?” debconf prompt when running: dpkg-reconfigure -p low grub-efi-amd64

So, now my system will boot with both or either drive present, and updates from Linux to /boot/efi are visible on all RAID members at boot-time. HOWEVER there is one nasty risk with this setup: if UEFI writes anything to one of the drives (which this firmware did when it wrote out a “boot variable cache” file), it may lead to corrupted results once Linux mounts the RAID (since the member drives won’t have identical block-level copies of the FAT32 any more).

To deal with this “external write” situation, I see some solutions:

• Make the partition read-only when not under Linux. (I don’t think this is a thing.)
• Create higher-level knowledge of the root-filesystem RAID configuration is needed to keep a collection of filesystems manually synchronized instead of doing block-level RAID. (Seems like a lot of work and would need redesign of /boot/efi into something like /boot/efi/booted, /boot/efi/spare1, /boot/efi/spare2, etc)
• Prefer one RAID member’s copy of /boot/efi and rebuild the RAID at every boot. If there were no external writes, there’s no issue. (Though what’s really the right way to pick the copy to prefer?)

Since mdadm has the “--update=resync” assembly option, I can actually do the latter option. This required updating /etc/mdadm/mdadm.conf to add <ignore> on the RAID’s ARRAY line to keep it from auto-starting:

ARRAY <ignore> metadata=1.0 UUID=123...

(Since it’s ignored, I’ve chosen /dev/md100 for the manual assembly below.) Then I added the noauto option to the /boot/efi entry in /etc/fstab:

/dev/md100 /boot/efi vfat noauto,defaults 0 0

And finally I added a systemd oneshot service that assembles the RAID with resync and mounts it:

[Unit]
Description=Resync /boot/efi RAID
DefaultDependencies=no
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/sbin/mdadm -A /dev/md100 --uuid=123... --update=resync
ExecStart=/bin/mount /boot/efi
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target

(And don’t forget to run “update-initramfs -u” so the initramfs has an updated copy of /dev/mdadm/mdadm.conf.)

If mdadm.conf supported an “update=” option for ARRAY lines, this would have been trivial. Looking at the source, though, that kind of change doesn’t look easy. I can dream!

And if I wanted to keep a “pristine” version of /boot/efi that UEFI couldn’t update I could rearrange things more dramatically to keep the primary RAID member as a loopback device on a file in the root filesystem (e.g. /boot/efi.img). This would make all external changes in the real ESPs disappear after resync. Something like:

# truncate --size 512M /boot/efi.img
# losetup -f --show /boot/efi.img
/dev/loop0
# mdadm --create /dev/md100 --level 1 --raid-disks 3 --metadata 1.0 /dev/loop0 /dev/sda1 /dev/sdb1

And at boot just rebuild it from /dev/loop0, though I’m not sure how to “prefer” that partition…

© 2018, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Christina Farr, reporting for CNBC:

Apple is launching a group of health clinics called AC Wellness for its employees and their families this spring, according to several sources familiar with the company’s plans.

The company quietly published a website, acwellness.com, with more details about its initiative and a careers page listing jobs including primary care doctor, exercise coach and care navigator, as well as a phlebotomist to administer lab tests on-site.

Seems like a great perk, but would you really want to have your primary care physician tied to your employment? What happens if you love your doctor but leave Apple?