I think the messaging is clear this time: Steam Deck is the defacto and flagship SteamOS device that represents the platform, and it has a strong established mindshare already, while other options are now available as well. It had a headstart of three years that gave it plenty of time to shine, and the handheld form-factor still stands out as something the competition (Windows) treats as an afterthought at best with poor UX.

The Steam Machines effort tried to position Alienware Alpha as its focus but the press coverage including all of the other options at the same time confused people. Steam Machines also had awful timing and pricing, with the Alienware being outdated hardware whose Windows version had already been out for a year for the same price or lower by the time the SteamOS version released, and the SteamOS version offering absolutely no advantage in pricing, power, features, or UX for most gamers. All of those factors are different this time. Plus game compatibility was much worse than it is now.

Most of the “Is open source software safe?” section of this post seems to advocate for what’s conventionally called Security Through Obscurity, which is widely considered very ineffective at preventing exploitation and at best a minor hurdle.

There are a lot of differences between Android and iOS in terms of security, attack surface, and exploitation, but attributing that to open vs closed-source completely misunderstands the entire subject. For just two of the countless reasons: Many of the worst vulnerabilities that affect Android devices are in closed-source proprietary Qualcomm firmware. A platform being open in the sense of allowing users to install any application they want to (like Windows and Android to a limited extent) or closed off to prevent installation of unapproved software (iOS, PlayStation, Toyota cars, TiVo, etc.) is completely separate from whether that platform is open-source or not. GPLv3 has license terms that try to tie the two concepts but I chose examples that don’t use it at all. Also, iOS has public kernel source code.

Although by a different organization in a different continent, enshittification was also selected as word of the year for 2023 by the American Dialect Society.

I’ve been using single-disk btrfs for my rootfs on every system for almost a decade. Great for snapshots while still being an in-tree driver. I also like being able to use subvolumes to treat / and /home (maybe others) similar to separate filesystems without actually being different partitions.

I had used it for my NAS array too, with btrfs raid1 (on top of luks), but migrated that over to ZFS a couple years ago because I wanted to get more usable storage space for the same money. btrfs raid5 is widely reported to be flawed and seemed to be in purgatory of never being fixed, so I moved to raidz1 instead.

One thing I miss is heterogenous arrays: with btrfs I can gradually upgrade my storage one disk at a time (without rewriting the filesystem) and it uses all of my space. For example, two 12TB drives, two 8TB drives, and one 4TB drive adds up to 44TB and raid1 cuts that in half to 22TB effective space. ZFS doesn’t do that. Before I could migrate to ZFS I had to commit to buying a bunch of new drives (5x12TB not counting the backup array) so that every drive is the same size and I felt confident it would be enough space to last me a long time since growing it after the fact is a burden.