> In fairness I would say that I've spent just as much or more time fixing rolling release issues on Arch/Manjaro.

That doesn't even matter much to me. Obviously, less time spent is better, but what really matters is the timing.

When I have to spend time upgrading my linux box, I have set time aside. I decide that I have a bit of time, and if it turns out to be a bigger job than expected, I can decide to abort and continue some other time.

On Windows the upgrade is always inconvenient, because you have no way of controlling it. Microsoft decides when the best time for you to upgrade is, and once it starts you have no means of punting on it.

Although the telemetry is certainly a problem too.

> That doesn't even matter much to me. Obviously, less time spent is better, but what really matters is the timing.

That too. When I update MacPorts, it can, sometimes, take ages. I don't care - I just continue working.

> Obviously, less time spent is better, but what really matters is the timing... On Windows the upgrade is always inconvenient, because you have no way of controlling it.

True, very good point in favor of user control. Linux has the added benefit of teaching the discipline and foresight to understand that "Hey... maybe I shouldn't run sudo pacman -Syu and reboot until I have some time set aside". Though in recent years I've found Arch to be way more stable with very few updates causing major problems.

> Though in recent years I've found Arch to be way more stable with very few updates causing major problems.

Can confirm. I've had the same Arch install for nearly 6 years now. I've borked it only once in that time, and that one was my fault for not reading the news first. Fixed it in < 5 minutes.

And I've made considerable changes in that time, including moving the entire installation from one hard disk to another.

So after a very long hiatus I have decided to try installing linux on a raspberry pi - and wow, the results were amazing. Using my decade-old knowledge of using fstab I added some drives to /etc/fstab and rebooted. Oooops. Raspbian would fail boot with a message "root account locked, couldn't open console".

Fantastic - so if any of the fstab entries are missing, the entire system effectively bricks itself. The only way to fix it was to remove the SD card, put it in another machine, and manually remove the offending entries from the fstab file. Fantastic. I Don't think I have ever managed to get windows to self-brick itself with something so simple.

I think you are being unfairly downvoted. On of the major downsides to Linux is that while you can, and often have to, tinker to make it work you can break it on many levels. Sometimes it's even hard to know if it is working properly, until you realize it doesn't. Many developers uses virtualization just for those reasons alone. It might even be a major upside to using WSL, if they do it well.

Our tools are either too powerful or too weak. To each their own. I can cope with a tool that is too powerful, but I can't cope with a tool that is too weak.

I don't think that is the general problem. More so inconstancy. It's almost harder to quit vi then to delete your boot record. I am not sure many tools are even that powerful. Which often means you have to use many different ones, making it even more confusing. Linux lacks abstraction and makes you do things manually as root, it isn't very robust.

I've had a windows update brick my laptop. It failed to complete an update, would roll back, reboot, then try again. Nothing I did fixed it. I spent almost a week with it in a boot loop, trying various fixes and such before giving up and reformatting. Put linux on it and added it to my pile of linux laptops.

You probably haven't tried changing windows partition and messing with Windows bootloader's registry file...

With great power comes great responsibility, I guess. I agree it would have been nice for Linux to come with a few more sanity checks by default, like maybe a warning flag for rm -rf /* and dd commands...

Standard rm (coreutils) has included rootfs protections since at least 2012:

    --no-preserve-root
        do not treat '/' specially
    --preserve-root
        do not remove '/' (default)

https://manpages.debian.org/stretch/coreutils/rm.1.en.html

Mind that if your rm comes from elsewhere (say, Busybox), it may not have that protection.

Very careful use of rm as root is an excellent habit to cultivate.

As are backups.

What about it? I don't think that does anything for "/*"

Interesting, I didn't know that and I stand corrected.

I'm just more offended that the default behaviour on an extremely popular distro is failed boot = brick. You don't even get a basic command prompt to fix something, the default behavior is to lock everything down and forbid access, making it impossible to repair the machine from itself. Windows will reboot a few times and then automatically start in safe mode when this happens, you don't need to extract the drive to manually edit some text files before the system can boot again.

> I'm just more offended that the default behaviour on an extremely popular distro is failed boot = brick

If you can't properly start the OS, that's correct behavior. You don't want the OS to start writing things to /var when it can't mount the filesystem that should be mounted to /var.

In any case, the fix with an RPi is easy - pop out the microSD, mount it on the other computer and fix whatever is broken (which should be in the logs). If the RPi is the only computer, put a microSD with a plain install of the OS, mount the other microSD through an USB dongle and fix it the same way you'd do with a laptop.

FWIW, you're using the word "brick" incorrectly. Bricking is when the only fix is to throw the device away and buy a new one, which clearly is not the case here.

Distinguish Hard Brick and Soft Brick.

I don't think I am. I've been fixing hardware for years and any device that doesn't switch on is "bricked" - its utility has dropped down to zero, it has turned into a literal brick. Just because you can revive it through some arcane procedure doesn't make it any less bricked to the end user.

Flashing a new OS onto the SD card is not "some arcane procedure" for the RPi's target audience.

you're getting downvoted, but as a 19-year Linux fanboi, I actually agree with you. If the system has booted at least once, then it knows how to successfully boot. i.e. it knows of a string of modules, kernel, initrd image, etc that worked. As you upgrade, the OS should have a courtesy feature where it doesn't simply delete these files (unless you do the equivalent of issue a "-rf" force command). For instance, we currently have (kernel, initrd, filesystem, and modules that exist on our fs). All we would need to make it (nearly) brick-proof is to add one more thing: fallback-rd that has all the previous shit that worked last time. This would save so many users' asses at hardly any cost since storage is so cheap these days.

Use a gui if you don't know your way around the shell. I'm pretty sure Debian provides one.

I wanted to setup a headless Samba server - so after the reboot I didn't even have any way of knowing why the system wouldn't appear on the network anymore. I had to find the right HDMI adapter to see if the system even attempts to start as it was completely dead by all other indications.

And no, I'm sorry but I hate the argument of "you should have known better" - the system first and foremost shouldn't have defaults set up in such a way that not only the SSH server doesn't come up in case of an issue during boot, but the local console is entirely disabled for any access. That's a crazy default.

Check your video card chipset and call support :P