Hacker News Reader

Comment by SilverRed | Hacker News Reader

I think that Fedora SilverBlue would have been the perfect OS for these kinds of consumer products. Arch is great and probably very rarely breaks but if it does, there is very few ways to recover the situation other than instructing users to reinstall the OS.

With something like fedora silverblue, if an update fails, The system can reboot in to the previous OS image without issue. It also ensures that there is a known state for the OS without having to deal with the fact that users may have changed things which breaks an update.

View on HN

> Arch is great and probably very rarely breaks but if it does, there is very few ways to recover the situation other than instructing users to reinstall the OS.

What are you talking about? Whenever things break in Arch, I fix them in my own install, either by downgrading a package that may be causing problems, or worst case with a USB stick which can enable me to chroot in the system again. Never had to reinstall anything from scratch.

On top of that, Valve will use its own repositories and you can be sure that for a SINGLE device, they will test things and make sure they don't break when they roll things out. That's a non-issue from the get go.

The problem is you can not tell users to just go fix it themselves. This is a device that should not _ever_ require fixing. It is not ok to ever tell a casual user to open up a terminal and correct the system state.

An immutable OS gives a huge safety layer by allowing all mistakes to be rolled back automatically.

You can't have an Open device with an immutable OS. And Valve is marketing this as an open device.

This is not a Switch.

Immutable OS does not mean it is not customizable. Your own customization just go in to "layers" which are applied on top of the OS. Means that if something stuffs up, you turn off your own layers and see if the problem goes away.

> Arch is great and probably very rarely breaks but if it does, there is very few ways to recover the situation other than instructing users to reinstall the OS.

Is there any citation to support this? I’ve run arch for 11 years, never once on that same computer did I have to reinstall the OS. On the rest that have been running it for 2y and 5y they’ve never had that issue, nor instruction.

I have the same experience with Arch. If anything has ever been borked a quick search and at worst Ctrl-Alt-F3 to get to a different TTY and running some commands has fixed whatever it was. I've never needed recovery or a separate boot device. Meanwhile, I've had a few fiascos with Ubuntu dist upgrades.

>at worst Ctrl-Alt-F3 to get to a different TTY and running some commands has fixed whatever it was.

For the average user of a hand held gaming console you may as well tell them to pop the back off and replace the chips on the PCB.

At most you could tell them to hold a button combo to factory reset but ideally you would want some way to roll back the whole OS state to the previous working version. Silverblue allows this to happen in a fairly elegant way by making the OS an image file and mounting it as read only so a roll back is simply mounting an older image.

Say valve pushes out a bad update that messes up the package manager list or puts it in a bad state, there is no recovery method. I guess one thing they could do is have some button combo you hold while booting which copies a fresh OS copy from a protected partition.

I'm sure you could imagine countless ways that a update could possibly break things.

Yes, me! Just a few weeks ago my Thinkpad ran out of battery mid upgrade (`pacman -Syu`) and got corrupted so bad it caused a kernel panic right after the LUKS prompt. Only took an hour to boot into the live USB, chroot into the disk installation (`arch-chroot`, but don't forget to mount `/boot` afterwards!!!), and reinstall the entire OS with `pacman -Qqn | pacman --overwrite "*" -S -` followed by `pacman -Syyu` (to update bootloader, just in case).

Reinstalled the OS and didn't even have to restore a single dotfile.

Edit: You may have to update your live USB packages first so run `mount -o remount,size=4G /run/archiso/cowspace && pacman -Syu` (cowspace is a ramdisk so make sure you've got the memory)

Edit2: I really hoped "and didn't even have to restore a single dotfile" was enough of a clue that this was tongue-in-cheek. I migrated to Arch a few months ago after two decades of Windows so as far as OS reinstalls go, this was like Microsoft sending me a giant settlement check with triple damages.

You corrupted your kernel. Arch had nothing to do with that, and regardless of the os if you corrupt the kernel you need to reinstall.

Wow. How’s that a reasonable answer? The OS did a very bad job at upgrading something that should be upgraded in an atomic fashion and blew up on both that and a failsafe boot to previous kernel. Neither should happen.

Unplug a windows machine, or any os, while its updating and see what happens. Y

Please point me to where I said windows does a good job, because I must’ve missed writing that.

Android and ios will survive this. Android uses an A/B partition scheme and will switch back to a working partition if the upgrade failed.

How do you corrupt your kernel? What leads to that?

Fedora silverblue can recover from this state. The kernel is just a file inside the OS image. If the latest OS image is corrupted due to a power failure, it will just boot the previous image which is still working.

I use to have arch break a lot because I only updated every couple of months, fixed it every time by looking at the forums.

I don't seem to have those problems any more though.

The use case is very different here thought. For a handheld game console, it really has to work forever (or as long as the hardware lasts) without a single issue or ever requiring users to fix anything. The competitors here are nintendo consoles, and the playstation.

It's not acceptable to say "oh its ok you can just open the terminal to fix and I haven't had an issue in 2 years". It has to be essentially perfect or able to recover itself from any kind of software fault without much user intervention.

>The competitors here are nintendo consoles, and the playstation.

Nope, the competition is GPD and other UMPCs. Valve is quite clear about the fact that this is a PC, not a game console. It's a portable gaming PC, but not a console. It's a general purpose computer. I expect a lot of people to install Windows on it, too.

Isn't SilverBlue just Redhat's NixOS clone?

It's more of a "clone" of the update mechanism in recent versions of Android. By "clone" I mean it was cloned the other way around.

SilverBlue is not a clone of any existing system. It's a brand new setup which treats the OS as read only layered images. A little bit like docker. The key feature is that you can roll back a failed update by simply mounting an older image. You can also allow the user to customize things by adding on extra layers and if anything ever goes wrong, you just boot without the users layers to restore a stock system.

For consumer level hardware this is essential to make sure it never ends up "bricked". The average user can not and will not reinstall an OS manually so if the OS gets in a bad state, the whole device is ewaste now.

Not quite. Silverblue is based around flatpak's (containers) and composing your OS from a set of containers.

NixOs is based on Nix, which doesn't use containers but links binaries against specific versions of dynamic libraries to resolve dependency issues and allow for reliable installations.

No, it's based on ostree for system distribution (which Colin had been developing since 2011), and using flatpak for applications. This had been a goal of the Red Hat desktop team for a while (see also: Stateless Linux from the 90s), but it took a long time for the community to realize the benefits. Other approaches here are the ChromeOS image style updates, CoreOS's image style updates, systemd's btrfs based OS distribution, and quite a few more throughout history. It's a good idea.

Collabora's SingularityOS they built for Valve for the original SteamOS was going to use ostree, but for various reasons (poor ones), they didn't ship that.

Reply on news.ycombinator.com