Dual stack is the most common way of deploying IPv6 in access networks. A recent standard defines IPv6-mostly access networks, providing IPv4 connectivity only for legacy devices while allowing modern devices to run IPv6-only. It is already well supported and allows network operators to gradually phase out IPv4 from the access networks.
Tailscale lets you connect your computers to each other so that you can use them together securely. As technology continues to advance, we’ll be carrying around more and more devices that, for convenience, we’ll call “computers.” Some of them are more limited than others, but today I want to talk about one device in particular: the Steam Deck by Valve.
The Steam Deck is a handheld Linux computer that is used for playing desktop-grade PC games. Its portability allows you to take your Steam library on the go with you anywhere, just like a Nintendo Switch. The Deck is also notable because it runs a variant of Arch Linux called SteamOS. Valve’s philosophy is that the Steam Deck is just a PC. It is open and hackable for anyone to modify to fit their needs. Valve even gives you the drivers to install Windows on the Deck, in case you want to.
Since the Steam Deck is essentially a PC, you can put Tailscale on it so that you can use it with your internal services, such as an NAS, and remotely access your home network when you’re on the go. You might also want to use Taildrop to copy files over to your Deck so you don’t have to mess with authentication and SSH keys just to copy over a Skyrim mod or two.
Tailscale is a low-level networking primitive, and as such it can be difficult to miss the forest for the trees when it comes to figuring out what to do with it. You can do anything with Tailscale that you can do with a normal network, and since you can do a lot of things with a normal network, it’s easy to suffer from decision paralysis because of all the options you have at your fingertips. I want to give you ideas inspired by my own experiences and setbacks that will inspire you to come up with your own uses for Tailscale. My posts are designed to help challenge your assumptions and preconceptions about what a network is supposed to be or do, so that you can really get out there and experiment with things. What could you do with a network if you didn’t have to care about the hard parts of networking?
It’s just a PC
One of the easiest ways to install Tailscale is to blow away SteamOS, install whatever Linux distribution you want, and go from there. This Just Works™️ because Valve lets you replace SteamOS with any other operating system you want, even Windows.
However, this isn’t in the spirit of making the Deck run Tailscale. That is just putting another OS on the Deck and then installing Tailscale on it. This won’t easily give you access to the features SteamOS gives you and is overall not as interesting as getting Tailscale running on SteamOS itself.
Let’s start this by taking a closer look at what the Steam Deck is and what it runs. The Steam Deck is basically a pair of game controllers glued to either side of a small, single-board computer and a screen. This single-board computer is set up to run SteamOS, and SteamOS is based on Arch Linux. Tailscale is already packaged for Arch Linux, so from here it’s tempting to think something like this:
Oh, it’s just spicy Arch Linux. I can pacman -S tailscale once I get to a shell, and from there I can use Tailscale normally, right?
It’s not just a PC
Well, let’s see how that works.
At a high level you need to do the following things:
Create a password for the deck user (the user that the Steam Deck UI and desktop mode use)
Crack open the SteamOS readonly seal
Set up the package manager’s keyring
Install programs with pacman as normal
Then you should be able to install Tailscale using the command pacman -S tailscale — right? In practice, it’s not really that easy. Sure — this will work. Your Steam Deck will become a weirdly shaped ultra-portable PC that just happens to ship with game controllers. However, this will not keep working the moment that the Steam Deck installs an update.
The Steam Deck has an A/B partition setup much like ChromeOS. This means that when you boot the system into partition A, updates are installed to partition B. Then, when partition B boots, updates are installed into partition A. This gives the system the ability to go back to the previous partition if an update doesn’t work. In other words, if Valve makes an update that renders your Steam Deck unbootable, the Deck will shrug it off and go back to the older, known good version. This gives you a user experience similar to what you get with NixOS or FreeBSD with ZFS boot environments enabled without having to use either of those OSes.
However, when we crack open the SteamOS readonly seal, we edit one of the fungible OS partitions directly. If we make changes to the A partition, those changes will not apply to the B partition when an update is installed. So when you reboot into the B partition after an update, your changes appear to be gone. They are still there, however; they’re just inaccessible on the A partition. Those changes will then get wiped out of existence when an update is downloaded to the A partition.
This means that if you go through that process to install Tailscale on the Steam Deck running SteamOS with the native package manager, you basically create a time bomb where the Deck will randomly stop working once an update is applied to the system. This is very much not what we want here. Tailscale has a bit of a reputation for being “magic.” Tailscale is “the secure network that just works,” so it’s probably a very bad idea for you to set up Tailscale in a way that will randomly break in the future. This makes Tailscale not seem magic, which is the absolute opposite of what you want.
Drawing inside the lines
Drawing outside the lines won’t work reliably. Let’s draw inside the lines instead. In the terminal, you can use the mount command to list all the places on the disk that you do have access to write files into. In my own setup, I also passed it through a few grep invocations to filter down the output to what we really care about. (In the past years, there have been more and more pseudo-filesystems added to Linux systems, and they will make it harder to notice the things you care about here.) The end result is that you have these folders we can write to:
$ mount | grep nvme | grep rw
/dev/nvme0n1p6 on /var type ext4 (rw,relatime)
/dev/nvme0n1p8 on /home type ext4 (rw,relatime,x-systemd.growfs)
/dev/nvme0n1p8 on /opt type ext4 (rw,relatime)
/dev/nvme0n1p8 on /root type ext4 (rw,relatime)
/dev/nvme0n1p8 on /srv type ext4 (rw,relatime)
/dev/nvme0n1p8 on /var/cache/pacman type ext4 (rw,relatime)
/dev/nvme0n1p8 on /var/lib/docker type ext4 (rw,relatime)
/dev/nvme0n1p8 on /var/lib/flatpak type ext4 (rw,relatime)
/dev/nvme0n1p8 on /var/lib/systemd/coredump type ext4 (rw,relatime)
/dev/nvme0n1p8 on /var/log type ext4 (rw,relatime)
/dev/nvme0n1p8 on /var/tmp type ext4 (rw,relatime)
Given that we have access to these folders, let’s arbitrarily pick /home. Tailscale ships static binaries that you can use to install Tailscale on systems that aren’t otherwise able to run it. This looks like a good fit here because we don’t have to care about the forest of doom that is ABI incompatibility. You can make a folder in ~/.local/share, then go into it to download Tailscale:
$ mkdir -p ~/.local/tailscale/steamos
$ cd ~/.local/tailscale/steamos
$ wget https://pkgs.tailscale.com/stable/tailscale_1.24.2_amd64.tgz
$ tar xzf tailscale_1.24.2_amd64.tgz
$ cd tailscale_1.24.2_amd64
From here we can run tailscale version to test whether the binary can run at all:
$ ./tailscale version
tailscale commit: 9d6867fb0ab30a33cbdfc8e583f5d39169dbb2e6
other commit: 2d0f7ddc35aa4149e67e27d11ea317669cccdd94
go version: go1.18.1-ts710a0d8610
Hooray! We have the Tailscale CLI working! This means that all we need to worry about is getting the node agent tailscaled running. There are several ways to do this, but I prefer running programs in an environment that is as close to its default environment as possible.
If it were possible, I would love to distribute this as a Flatpak. But it’s not possible: Tailscale uses some low-level kernel networking primitives, and the Flatpak sandbox understandably blocks us from using them. Even if we could use those primitives, Tailscale is a system service on Linux and not a GUI application (even on platforms where Tailscale has a GUI application, there’s still the system service running in the background). Flatpak doesn’t allow you to run system services.
So, you have to get more clever. Let’s step back a moment and think about the OS the Steam Deck is using. SteamOS is a fork of Arch Linux, a Linux distribution that is well known for its use of systemd. Arch makes use of every component of systemd to a degree that other distributions would find ludicrous. Some people have accused systemd of having a lot of “bloat” (read: unnecessary extras), but in cases like this, that “bloat” very much comes in handy, especially since each Steam Deck is going to have the same set of systemd components. This makes writing documentation/engineering logs like this a lot easier. After doing some extensive research and experimentation, I have identified two things we can try to run Tailscale on the Steam Deck.
As an aside, it may be tempting to wonder things like:
Why are there two ways to run a service like this? That seems like wasted
effort on the systemd project. They should just have one way to run services and
you should just use that.
Each of these things was created for different reasons and they all do different
things, even though they might appear to have similar goals. I’m not judging!
I’m just pointing out that in cases like the one we find ourselves in with the
Deck, this becomes very convenient.
Most of the time when you have normal Linux machines, you have a lot of power over what they can do and how they can do it. This is very different than the situation with the Deck, which is closer to a game console than a normal PC. We can’t easily erase the limitations of the default OS image and draw our own path. We have to draw inside the lines. This is what comes with drawing inside the lines.
At a high level, we have two options for running Tailscale through systemd:
Launching the tailscaled process into the background using systemd-run
Creating a system extension image and layering that into SteamOS, then using systemd to manage tailscaled as normal
Let’s go over each of these options in their own little sections on how to use them and what the advantages and drawbacks of these approaches are.
You could also run Tailscale as a portable service, but doing this doesn’t let tailscaled run in kernel networking mode. Portable services have additional constraints similar to Flatpak that make it unviable for use on the Steam Deck. You certainly don’t want to configure everything on your gaming console to use a SOCKS proxy server!
The easiest way to hoist this service into systemd would be to use systemd-run. systemd-run lets you create one-off systemd jobs using systemd’s DBus API. This basically lets you spawn off services, socket-activated services, and timer jobs (think spicy cronjobs) at will. They will keep running after you lock your screen or disconnect from SSH. This lets your one-off jobs have all the advantages of being a systemd service, including memory limits, isolation from the system, detailed logging with the journal, and management of services using control groups.
As an example, we can run systemd-run -S to spawn into a shell session managed by systemd:
(deck@taildeck ~)$ sudo systemd-run -S
[sudo] password for deck:
Running as unit: run-u97.service
Press ^] three times within 1s to disconnect TTY.
We can then use systemctl status in another terminal window to see information about this transient shell session:
(A+)(root@taildeck deck)# systemctl status run-u97.service
● run-u97.service - /bin/bash
Loaded: loaded (/run/systemd/transient/run-u97.service; transient)
Active: active (running) since Tue 2022-05-03 13:28:31 EDT; 50s ago
Main PID: 8274 (bash)
Tasks: 3 (limit: 17718)
├─8290 systemctl status run-u97.service
May 03 13:28:31 taildeck systemd: Starting /bin/bash...
May 03 13:28:31 taildeck systemd: Started /bin/bash.
This is one way to manage tailscaled in systemd. Reading through the manpage and tailscaled.service, you could end up with a systemd-run command that looks like this:
Running this command will make tailscaled start up and then you can log in with this command:
$ sudo /home/deck/.local/share/tailscale/steamos/tailscale_1.24.2_amd64/tailscale up --operator=deck --qr
You can then scan the QR code with your phone and log into your tailnet and do all the computer things you want.
As a systems administrator, you can also use systemd-run to super-daemonize one-off tasks. This is incredibly useful for handling things like package upgrades when you don’t want to risk it randomly dying when your shell session gets interrupted.
Doing this has many advantages when compared to cracking the readonly seal: It installs Tailscale without needing to modify the system image, and the relevant state, cache, and runtime directories for Tailscale are automatically created by systemd into writable folders when tailscaled.service starts. This allows you to update your Steam Deck freely without worrying about updates randomly breaking your VPN.
However, the main drawback to this approach is that Tailscale won’t automatically start on boot. There are ways around this (namely, by either editing systemd/tailscaled.service to point to the tailscaled location in /home/deck/.local/share/tailscale/steamos or by using systemctl cat tailscaled.service after running that above systemd-run command and putting that in /etc/systemd/system), but in general starting Tailscale once like this won’t integrate it into the system.
You can simplify this with a shell alias or changing your shell’s $PATH, but just having the tailscale command in /usr/bin would make life a lot easier.
This setup will work, and in most cases it should do just about everything you need. However, there is a much more ergonomic option: system extensions.
The systemd project has recently introduced the concept of system extension images. These allow you to add arbitrary extra files to a system at runtime, much like you would by installing a package to the system. However, the main difference is that a system extension is overlaid on top of the underlying system partitions, so you don’t need to have write access to the system partition to install packages into it. This is likely the big reason why they spearheaded the migration of everything in Linux-land to be in /usr with compatibility symlinks to accommodate older workflows. For more information about how to use system extension images, see this blog post by Lennard Pottering.
These are super convenient for our use case because they allow us to install Tailscale into the Steam Deck as if we installed it from pacman, but without breaking the readonly seal and leaving a landmine to be triggered the next time a system update is installed. This also allows us to run the tailscale command like any other command on the system, which will make debugging a lot easier.
The static binary tarballs that Tailscale ships are very close to a system extension image already; the main differences are that we need to do the following in a temporary directory:
Put the binaries in usr/bin/tailscale and usr/sbin/tailscaled
Put the systemd unit in usr/lib/systemd/system/tailscaled.service
Add an extension-release file that defines the OS that the extension is compatible with
If you are making your own extension images at home, do not forget to do this step. Without this step, the extension image will not be recognized.
To do this we can run a shell script like the following:
This will make a rather large QR code show up on your Deck. When you scan it and log in with your phone, you will be authenticated to Tailscale and you can use all your tailnet features as normal.
Steam Deck plugin sneak peek
This can be made a lot simpler with the Steam Deck Plugin UI. I have been working on a Steam Deck plugin to automate this setup away from you. It isn’t in a state where I feel comfortable releasing it yet, but here’s a sneak preview of what the plugin looks like:
More details to come as soon as I can get them nailed down.
Fun things you can do
I did a lot of experimenting, and here are some things that I got working that you may find inspiring. The big one was remote-mounting my NAS over Tailscale and playing games stored on my NAS. This was stable enough to let me play more simple games on the Steam Deck in Montreal even though my NAS with the actual game files was in Ottawa. I was able to play it all day without any issues, save slightly higher load times. Other games may not have the same experience, but games released around 2005 and earlier usually fare better in this regard. With the Deck’s WiFi card in a perfectly spherical test environment, loading things over the network will be faster than reading data from a DVD drive, even with the multiple layers of overhead involved.
This will require testing. Some games tolerate higher latency to storage better than others. Games like Dead Space 2 will fare worse than others due to Dead Space 2 constantly streaming in assets from the disk to create the world around you as you move forward.
Generally, the simpler the game, the more likely it will just work.
Games with dedicated servers
In my testing, nearly every game that has a self-hostable dedicated server worked over Tailscale. Here are some of the games that I tested:
The only hiccup came when I was trying to play Assetto Corsa Competizione (a racing simulator) because its dedicated server discovery process relies on broadcast/multicast packets (which Tailscale doesn’t support at time of publication). Everything else was seamless, just as if I were hosting the server over a local network or the public internet. I was able to share servers with node sharing, and my friends were able to join without any issues.
Moonlight game streaming
The Steam Deck has a game streaming service by default; however, it can have issues with double-NAT and other network situations that Tailscale can tolerate without blinking. Moonlight is an open source game streaming protocol that lets you run your games on your gaming tower and send the video stream to another device that can’t run them, such as the Steam Deck. Moonlight is available from the Discover store in the KDE desktop mode available in the Steam button menu.
I was not able to get this working due to the hardware of my gaming machine being incompatible (I use an AMD card instead of an NVIDIA card), but there are reports of it working seamlessly for people with compatible machines.
What games do you like to play with your friends? Have you gotten your Steam Deck in yet? What games would you like to host your own servers for if you didn’t have to worry about securing the servers down, DDoS attacks, and griefers? Reach out to us @Tailscale or join our forums to talk about your experiences.
Bloomberg reported earlier this year that Apple is working on a subscription service model for iPhones: For a monthly fee, customers will be able to lease a phone instead of buying it outright. Last week, Fairphone announced a similar subscription plan for their customers in the Netherlands. We’re big fans of Fairphone (their phones always top our repairability scale, with easy-to-swap batteries...
Google held its I/O conference earlier this month, and for longtime Google watchers, the event felt like a seance. Google CEO Sundar Pichai stepped on stage for his keynote address and channeled the spirits of long-dead Google products. "I'm hearing... something about an Android tablet? And a smartwatch?" he seemed to say.
By my count, "resurrecting the past" accounted for around half of the company's major announcements. In all of these cases, Google would be in a much stronger position if it had committed to a long-term plan and continuously iterated on that plan.
Unfortunately, the company doesn't have that kind of top-down direction. Instead, for most of the resurrected products, Google is trying to catch up to competitors after years of standing still. There's a question we have to ask for every announcement: "Will things be different this time?"
Android tablets are back
How long have Android tablets been dead? Some companies, like Samsung, have never given up on the idea, but Google's last piece of actual tablet hardware was the Pixel C in 2015. Android's tablet UI has been gone for a while. Its development peaked with the initial release of Android 3.0 Honeycomb in 2011, and every subsequent Android release and Google app update watered down the tablet interface until it disappeared. App developers took Google's neglect as a sign that they should stop making Android tablets, too, and the ecosystem fell apart.
After the 2015 Pixel C release, Google quit the tablet market for three years, then launched the Pixel Slate Chrome-OS tablet. It then quit the tablet market for another three years. Now it's back. Will the company's new plans produce another one-year wonder like the Pixel Slate?
Google is bringing tablet interfaces back to its app lineup. [credit:
Some of the biggest tablet news coming from the show was that Google is truly committing to tablet app development again. The company announced it would bring tablet interfaces to over 20 Google apps, and it showed off screenshots for most of them. Tablet versions of Google Play, YouTube, Google Maps, Chrome, and a bunch of other heavy hitters were all on display. Google even got some third parties committed to making Android tablet apps, including Facebook, Zoom, and TikTok. All of these will help make the Android tablet experience something worth investing in.
Google also announced a new tablet, the Pixel Tablet, with a release scheduled for the very distant date of "sometime in 2023." It's a widescreen, large-looking tablet, and regular phone apps will not look good on it. I'm speculating here, but the Pixel Tablet looks cheap. I don't say that as a slight against the product; I mean it seems targeted to compete more with Amazon Fire tablets than iPads.
The product only got a 30 second teaser at Google I/O, but Google showed off what looks like a thicker tablet, which is usually a hallmark of a cheaper device. The lone camera on the back looked like a bargain-basement pinhole camera, and the back might even be plastic. If Google wanted to target the iPad, we probably would have seen a thinner design and a pile of accessories, like a pen and keyboard.
Going after the Fire tablet would make sense. They are the most popular (forked) Android tablets on the market. Considering Google's immature tablet ecosystem, it would be easier to win people over with a cheaper product than charging a premium right out of the gate. This also wouldn't be new, since the Nexus 7 line defined cheap tablets for a few years until Google lost interest.
The Pixel tablet, coming in 2023. [credit:
Google's presentation also lined up perfectly with the rumor that the company's next "smart display" would be a detachable tablet. The last thing the teaser showed was a set of pogo pins, which could be for a smart display dock. Google also highlighted Google Nest camera smart home support, which is currently a smart display feature. Docked smart display mode is something the Fire tablets do today, lending more credence to the idea that Google wants to compete with Amazon's products.
So far, all of this work makes it seem like Google is trying to get back what it threw away shortly after the release of Honeycomb. The company already released a tablet-centric update to Android in March—Android 12L—but that was a lot less ambitious than the Honeycomb release. Android 13 will continue with a bit more tablet work.
The rise of foldables has also changed the market, and these devices need tablet apps to work well. If people with flagship Android phones suddenly have devices that open up into tablets, the market for tablet apps would be a lot stronger. Assuming the foldable future really does happen, more and more devices will demand big-screen app designs even if the standalone Android tablet completely tanks.
Android watches—this plan is actually working!
Wear OS has been dead for a long time. Google allowed the operating system to go three years without a major update, and the major SoC vendor Qualcomm has been strangling the market with very little in the way of competitive SoC support. The result has been an OS at the bottom of the wearables market, with Counterpoint Research data putting it at around a 3 percent market share, good enough for fifth place.
Google has been working on a resurrection of Wear OS, with Samsung in tow as a major partner. As part of this new partnership, Samsung is dumping its Tizen OS and bringing its hardware to Wear OS, starting with the Galaxy Watch 4 launch in August 2021. This partnership has already shown a stunning turnaround. Wear OS is now at 17.3 percent market share—well within striking distance of the No. 1 spot, which is held by the Apple Watch at 21.8 percent. The Wear OS number doesn't even include Fitbit, which Google will eventually fold into the Wear OS ecosystem.
With I/O came the next part of this plan: the Pixel Watch is real. This is Google's first smartwatch hardware despite the company technically making a smartwatch OS for the past eight years. There are two reasons Google went so long without launching smartwatch hardware. First, the company tried to make a first-party smartwatch back in 2016, when the Google Hardware division was initially getting off the ground. According to a report from Business Insider, Google Hardware SVP Rick Osterloh shuttered the project after concerns about its quality emerged. The devices still hit the market as the LG-branded Watch Style and LG Watch Sport.
Second, it has been practically impossible to make a competitive Android smartwatch for a while now. For years, Qualcomm has been the only major SoC vendor willing to sell to OEMs. Rather than produce a chip that attempts to be competitive with the Apple Watch, Qualcomm took advantage of the lack of competition and just repackaged the same basic chip design for years. Qualcomm's "top of the line" offerings for wearables used 2011-era technology—Cortex A7-based, 28 nm SoCs—as late as 2020. Going with Qualcomm meant laughable performance and battery life, but most OEMs had no other choices. If Google cared about making a competitive Pixel Watch, the lack of a viable SoC vendor made the project a nonstarter for years.
What's different this time? The Samsung partnership.
Samsung has its own "Exynos" chip division, and it produces far more competitive SoCs for wearables than Qualcomm can offer. Samsung doesn't sell its wearables chips to third parties, but the Galaxy Watch series has gotten reliable SoC updates directly from Samsung. That's a lot more than you can say for any Qualcomm-based smartwatch lines. Samsung gets a better wearables app selection, and Google gets a viable hardware partner. After Google's partnership with Samsung's Exynos division for the Google Tensor SoC in the Pixel 6, it's widely expected that the Pixel Watch will also feature an Exynos chip.
Which Exynos chip is still a matter of debate. Google officially announced the Pixel Watch at Google I/O, but it neglected to mention any specs—perhaps because the specs aren't worth bragging about. If you were digging through the Samsung parts bin, the SoC you'd want is the Samsung Exynos W920, which is used in the Galaxy Watch 4. This is a 2021 chip with technology to match—two ARM Cortex A55 cores and an ARM Mali-G68 GPU on a 5 nm manufacturing process.
But the latest rumor from 9to5Google's Abner Li is that Google isn't using Samsung's latest chip in the Pixel Watch. Instead, Li claims, Google will use Samsung's 2018 SoC, the Exynos 9110, which has two Cortex-A53 cores and an Arm Mali-T720 MP1 GPU at 10 nm. Incredibly, Samsung's 4-year-old chip is still better than anything Qualcomm produces, but using an old Samsung chip would make the Pixel Watch more of a half-step toward competitiveness than a triumphant arrival at the top of the market.
9to5Google suggests that the Pixel Watch will use an old chip because the hardware has been in development for so long. That's not great news for people who wanted a smartwatch this year, but if Google's wearables are going to work, the company needs a multi-year plan anyway. We need several years of Pixel Watches, hopefully with several years of regularly upgraded Samsung chips, all backed by tons of Google Wear OS apps.
As for the wider ecosystem, Samsung seems to have realized that Tizen is a dead end with app developers and appears to be all-in on Wear OS. Samsung is big enough to single-handedly prop up the ecosystem, even if Google loses interest. The chart above is proof of this since Samsung is currently the only reliable source of decent Wear OS hardware.
Google Wallet -> Android Pay -> Google Pay -> Google Wallet
Google Wallet is back! Google's payment system is deep into the Google failure cycle and is now running on rebrand No. 4 after previously being known as "Google Pay." It's only natural to run out of ideas for your fourth rebrand, so this is the second time Google has used "Google Wallet" as a product name. The first was in 2011, three years before Apple Pay launched, making Google a pioneer in NFC payments.
The company didn't stick to a plan or iterate on its products, though. After its services stagnated and were surpassed by Apple Pay's 2014 launch, Google launched "Android Pay" in 2015, which was all about copying the Apple Pay model. Google Pay arrived in 2018, and now we're back to Google Wallet in 2022.
With Google Wallet, it feels like the company is closing the book on the spectacular implosion of Google Pay in 2021. The existing Google Pay codebase, which could trace its lineage back to Android Pay, was thrown out and replaced by a completely new codebase with a different feature set. The new Google Pay code came from another Google payment product called Google Tez, which the company originally built for India.
Instead of Google accounts, the new Google Pay used a phone number. That's common for many apps in India, but it doesn't work well for more flexible, multi-device apps in the rest of the world. The new Google Pay arrived with a stunning list of regressions: It no longer worked with multiple accounts, it didn't support logging in to multiple devices, and it didn't work on the web. Switching identifiers meant you had to rebuild your payment contact list. Google's switch also didn't happen all at once, so people on the old Google Pay couldn't send money to people on the new Google Pay.
The new Google Pay was an unmitigated disaster. After Google launched the service in March 2021, an employee exodus started in April, beginning with the departure of payments chief Caesar Sengupta. According to a report from Business Insider, Sengupta's pet project was the transition to the new Google Pay, which took two years. An anonymous former employee admitted to Insider that "the product wasn't growing at the rate we wanted it to," and about 40 other "frustrated" employees followed Sengupta out the door.
With Sengupta gone, Google is left to dig through the wreckage. The executive left when the new Google Pay transition was only half done. All of these "new Google Pay" shenanigans only happened in the US, and the rest of the world was still on the old (good) Google Pay app. The next part of Sengupta's plan, a dystopian idea to launch Google bank accounts under the name of "Google Plex," was also canceled. Embarrassingly, this was after the service had been publicly announced, and Google had already started a waitlist.
Google's payment division is at the point where it has to fix all of these problems, and it sounds like Wallet is that fix. It's hard to get into too many details because Wallet isn't out yet, but Google says the service will roll out to 40 countries, including the US, but not India. India will be keeping the new Google Pay, and that carve-out suggests that Google wants to undo all of the feature regressions and SIM card lock-in that service introduced. There's a Wear OS app coming, hinting that multi-device support is back.
Wallet will also introduce some new features, like storing non-payment information such as boarding passes, student IDs, and vaccine cards (and, someday, digital car keys and driver's licenses).
Google Glass déjà vu
It's been 10 years, and Google's new goggles do not seem all that different from Google Glass. (credit: Google)
Google also showed off an augmented reality headset at I/O. It was explicitly not a product, but rather a sneak preview of a prototype the company is working on. Of course, Google started this whole AR goggles idea a decade ago with the launch of Google Glass in 2012. Just like many other Google products, Google Glass was a trailblazing idea with a ton of potential, but after the initial year or two of interest wore off, Google just sort of gave up on the idea as a consumer product. Part of the reason Android is so successful is that divisions from across Google threw their weight behind the OS with excellent, feature rich apps, but Glass never got that treatment. Most Google services did not work on the device, or they worked very poorly.
Why would customers even want to wear Glass in the first place? Google never gave a solid answer to that question. Google Glass was a flat, 2D, mostly text-based interface without any 3D capabilities, and its small list of features, like voice commands and notification awareness, were made completely obsolete by smartwatches. If the product couldn't actually detect the world around users and augment their vision, why would they take the extreme step of strapping a computer to their face?
It's a decade later, and Google's latest AR experiment seems to just be... Google Glass again?
The company's new prototype looked like regular glasses instead of the wild prism design of Google Glass, but the interface appeared to be exactly the same. This new prototype has a single function: translation. It has a microphone that will listen as someone talks to you, and the device will try to translate the speech. Considering that Google Glass could display exactly this interface—and it had a microphone and processor that was good enough for voice transcription—I'm not sure why this feature couldn't have been a part of Glass 10 years ago. It certainly doesn't seem to show 10 years of hardware progress.
What has progressed over 10 years is Google's ability to translate speech. The current Google Translate app has an interpreter mode that works great. These glasses probably just pipe that technology to the lenses, but why bother with the glasses at all?
What Google should have learned from its time with Google Glass is that asking customers to wear something on their faces should be a last resort, and justifying an awkward face computer is a high bar to clear. If people can get similar functionality from any other device, they'll use that instead. Face computers are justifiable if they do something unique with vision, like scanning the world around you and projecting something into the world in 3D. If a product can't do that, it's probably not making up for all its downsides—among them, making the wearer look strange.
Google's translation could just as easily be implemented in a set of headphones—and, in fact, it already has been. Similarly, it could be used on a phone. The idea that a face computer will somehow make translated speech less awkward doesn't really track. A translation app on a phone would probably even work better since it can speak translated text to both parties. Glasses only work for the person wearing the glasses, so unless you just want to listen, the other person needs to be somewhat bilingual. Maybe Google plans to sell these in a two-pack?
Try aiming for the “wait and see” crowd this time
Like most Google products in the Sundar Pichai era, what will really matter for all of these resurrections is if Google continues to care about them for several years. Way too many Google products seem to have a one-year roadmap. The company pins 100 percent of its hopes on a project's initial launch, and the product is canceled if it isn't an overnight success. Google rarely allows products enough runway to adapt to feedback or convince the "wait and see" crowd. The problem is that Google has burned so many of its early adopters over the years that there are not many of them left.
Google needs to listen to feedback, like the calls to scrap almost everything it changed with Google Pay. Thankfully, it seems to be doing this. The company also needs to learn from its many product failures. Unfortunately, its vaporware AR demo suggests it hasn't taken these lessons to heart.
Really, though, those two projects are small potatoes compared to the expanded Android form factors. Actual success here would mean supporting multiple years of Pixel tablets and Pixel watches. Apps for both platforms need to release at launch and should continue to be updated for years afterward. Many people treat new Google products with skepticism, and the company needs to overcome that by committing to developing its devices and services for multiple years.
None of this should be as difficult as Google is making it. Android is a massively popular operating system on phones, and that should make it a no-brainer on tablets and watches. The company just needs to give its products time to grow and mature.
When we launched the Framework Laptop a year ago, we shared a promise for a better kind of Consumer Electronics: one in which you have the power to upgrade, repair, and customize your products to make them last longer and fit your needs better. Today, we’re honored to deliver on that promise with a new generation of the Framework Laptop, bringing a massive performance upgrade with the latest 12th Gen Intel® Core™ processors, available for pre-order now. We spent the last year gathering feedback from early adopters to refine the product as we scale up. We’ve redesigned our lid assembly for significantly improved rigidity and carefully optimized standby battery life, especially for Linux users. Finally, we continue to expand on the Expansion Card portfolio, with a new 2.5 Gigabit Ethernet Expansion Card coming soon.
In addition to launching our new Framework Laptops with these upgrades, we’re living up to our mission by making all of them available individually as modules and combined as Upgrade Kits in the Framework Marketplace. This is perhaps the first time ever that generational upgrades are available in a high-performance thin and light laptop, letting you pick the improvements you want without needing to buy a full new machine.
12th Gen Intel® Core™ processors
Framework Laptops with 12th Gen Intel® Core™ processors are available for pre-order today in all countries we currently ship to: US, Canada, UK, Germany, France, Netherlands, Austria, and Ireland. We’ll be launching in additional countries throughout the year, and you can help us prioritize by registering your interest. We’re using a batch pre-order system, with only a fully-refundable $100/€100/£100 deposit required at the time of pre-order. Mainboards with 12th Gen Intel® Core™ processors, our revamped Top Cover, and the Upgrade Kit that combines the two are available for waitlisting on the Marketplace today. You can register to get notified as soon as they come in stock. The first batch of new laptops as well as the new Marketplace items start shipping this July.
12th Gen Intel® Core™ processors bring major architectural advancements, adding 8 Efficiency Cores on top of 4 or 6 Performance Cores with Hyper-Threading. This means the top version we offer, the i7-1280P, has a mind-boggling 14 CPU cores and 20 threads. All of this results in an enormous increase in performance. In heavily multi-threaded benchmarks like Cinebench R23, we see results that are *double* the last generation i7-1185G7 processor. In addition to the top of the line i7-1280P configuration, we have i5-1240P and i7-1260P options available, all supporting up to 30W sustained performance and 60W boost.
We launched a new product comparison page, letting you compare all of the versions of the Framework Laptop now available. Every model is equally thin and light at <16mm and <1.3kg, and each has our Expansion Card system that lets you choose your ports, a 13.5” 3:2 display optimal for productivity, a great-feeling keyboard with 1.5mm key travel, a 1080p webcam, hardware privacy switches, and more. We offer both ready-to-use Framework Laptops with Windows 11 and our extremely popular Framework Laptop DIY Edition that lets you bring and assemble your own memory, storage, and Operating System, such as your preferred Linux distro. If you need a laptop today (or a volume order of laptops) or want a bargain, we're dropping the price of the first-generation Framework Laptop until we run out of the limited inventory we have left. If you ever need more performance in the future, you can upgrade to the latest modules whenever you’d like!
Optimized for Linux
We continue to focus on solid Linux support, and we’re happy to share that Fedora 36 works fantastically well out of the box, with full hardware functionality including WiFi and fingerprint reader support. Ubuntu 22.04 also works great after applying a couple of workarounds, and we’re working to eliminate that need. We also studied and carefully optimized the standby power draw of the system in Linux. You can check compatibility with popular distros as we continue to test on our Linux page or in the Framework Community.
In redesigning the Framework Laptop’s lid assembly, we switched from an aluminum forming process to a full CNC process on the Top Cover, substantially improving rigidity. While there is more raw material required when starting from a solid block of 6063 aluminum, we’re working with our supplier Hamagawa to reduce environmental impact. We currently use 75% pre-consumer-recycled alloy and are searching for post-consumer sources. The Top Cover (CNC) is built into all configurations of the Framework Laptop launching today, and is available as a module both as part of the Upgrade Kit or individually.
Ethernet Expansion Card
Support for Ethernet has consistently been one of the most popular requests from the Framework Laptop community. We started development on an Expansion Card shortly after launch last year and are now ready to share a preview of the results. Using a Realtek RTL8156 controller, the Ethernet Expansion Card supports 2.5Gbit along with 10/100/1000Mbit Ethernet. This card will be available later this year, and you can register to get notified in the Framework Marketplace.
Reduce Reuse Recycle
We’re incredibly happy to live up to the promise of longevity and upgradeability in the Framework Laptop. We also want to ensure we’re reducing waste and respecting the planet by enabling reuse of modules. If you’re upgrading to a new Mainboard, check out the open source designs we released earlier this year for creative ways to repurpose your original Mainboard. We’re starting to see some incredibleprojects coming out of creators and developers. To further reduce environmental impact, you can also make your Framework Laptop carbon neutral by picking up carbon capture in the Framework Marketplace.
We’re ramping up into production now with our manufacturing partner Compal at a new site in Taoyuan, Taiwan, a short drive from our main fulfillment center, helping reduce the risk of supply chain and logistics challenges. We recommend getting your pre-order in early to hold your place in line and to give us a better read on production capacity needs. We can’t wait to see what you think of these upgrades, and we’re looking forward to remaking Consumer Electronics with you!
Many of today’s laptops are more powerful than yesterday’s desktop PCs (well maybe not yesterday’s, but desktops from more than a few years ago). And while it’s certainly possible to use a laptop as a desktop replacement, hardware hacker Penk went a little further with the Mainboard Terminal.
It’s a compact all-in-one computer with a custom, retro-inspired design. And it’s powered by a laptop motherboard. That doesn’t mean Penk had to rip the guts out of an existing laptop though.
Framework, a company that makes a modular laptop, recently began selling mainboards directly to customers. While you can use one of Framework’s Mainboards to replace a broken motherboard in a Framework Laptop or to upgrade to a more powerful model, you can also use these mainboards as standalone computers… or as the heart of a custom PC like Penk’s Mainboard Terminal.
For a display, Penk made an unusual choice and opted for a 5 inch, 1080 x 1080 pixel LCD which gives the computer a distinctive look, but which may not be the best option for displaying content from websites, apps, games, videos, and just about anything else designed for rectangular displays.
On the bright side, since the system is powered by modern laptop hardware, it should be able to support most modern operating systems – Penk says Ubuntu 22.04 LTS runs perfectly out of the box with only a bit of tweaking required to get the operating system to support the circular display.
The Framework Terminal isn’t for sale, but if you’d like to build you own you can find more details and as well as downloads for the design files at Penk’s GitHub page.
This isn’t Penk’s first retro-inspired computer design. Earlier this year Penk unveiled a Raspberry Pi-powered mini-laptop called the Penkesu Computer featuring a 7.9 inch widescreen display and 48-key ortholinear keyboard. And Penk is also the creator of the Raspberry Pi-powered CutiePi tablet with an 8 inch touchscreen display and a handle.