I've been a user of openSUSE since "openSUSE", nearly. It's my daily driver, today.
I want to say I was playing with Mandrake, Red Hat and a little Gentoo at the time. I started using it regularly around 2010ish - I was working at a Windows shop and had a pretty elaborate home lab with Windows servers and domain controllers so I could do things at home "before trying that on corporate." I remember the deciding factor became "I can use YaST to add this device to my domain controller and login with domain credentials easier than I can add a Windows box to the domain." And I found that was often the theme with many tasks, whether they're unusual like "logging into a Windows host" or mundane. Over the years, the software options available have been pretty incredible. I run Tumbleweed in most places and it's, by far, the smoothest "bleeding edge rolling update" distribution I've worked with. `Snapper` was my first experience with "working rollback."
Because of the fine folks at openSUSE, I went from "knowing nothing about Linux" to "using it as my primary desktop" and I'm mostly a .NET developer. So many development tasks are just easier to do under Linux, whether it's the pesky node or python module that needs gcc/LLVM to compile some dependency and the expansive set of software repositories and available `.rpm`s make it all very straight-forward.
I recently picked up a higher-end AMD GPU and was dismayed to find that ROCm support was limited, mostly, to Ubuntu[0]. I got everything mostly working in Tumbleweed -- interestingly, most of the AI workloads I put it through worked as well in Tumbleweed as they did in Ubuntu following the official documentation but a few of the ROCm utilities didn't run. I ended up reloading with Ubuntu and quickly regretted the situation. Stupidly, I assumed doing a distribution update would be flawless like it typically is with Tumbleweed. After all, the only way to actually update Tumbleweed is via a distribution update, and 2K packages later it very rarely fails to boot. I knew right away that I wouldn't have the safety of being able to pick the previous snapshot but I was surprised that when it failed half-way through it didn't bother to roll anything back; it simply left my machine in a broken state that booted directly to a text console. Having re-loaded this box four times in the prior few days, I decided to go back to what I knew.
About the only complaint I have centers around their default choice of `btrfs` for the filesystem. While I like the CoW functionality (the only particular "advanced" feature that I utilize with `btrfs`), it seems to excel -- mostly -- at teaching me about filesystem recovery. My home lab isn't anywhere near as elaborate as it had been in the past. It seems even on a UPS with proper shutdowns it's ridiculously prone to getting itself into a state where a `btrfs restore` is the only way to recover from a filesystem problem. Every single time I get everything back except for some random cache/tmp/log file but I need to dig up or purchase a volume of equal size to restore it to, meaning I have to keep around an empty drive at least as large as my largest volume. It seems to me "if the filesystem can literally restore everything except for a file or two that has become corrupted" it should offer a "dangerous" option to do so online. To this day I have never had to restore everything from an actual backup, it's always gotten back everything important simply restoring the broken filesystem to a new volume and the filesystem becomes corrupted without explanation -- power didn't fail, the system had a clean shutdown, it just randomly goes "read-only" with a guarantee that the next boot will drop to an emergency console. Unfortunately, CoW helps a lot with the work I do and ends up being worth the grief involved. While I've had fewer failures in the last couple of years and an easier time recovering from those failures, it's often a full day's work to get everything right, again.
[0] Support exists for Leap but the repositories were broken for a solid month while I was setting things up.
True but SUSE (the enterprise version) is pretty clear about the use of btrfs, just use it for the OS (snapshots), the "data" partition should always be XFS.
AFAIK (though not as connected to Red Hat storage team these days), RHEL is pretty much XFS plus logical volume managers. As I understand it, ZFS was just a non-starter because of licensing + Oracle and the feeling was that btrfs just wasn't quite there.
> it seems to excel -- mostly -- at teaching me about filesystem recovery.
100% this.
I worked for SUSE for 4 years and I like the distro, but I unhappily and reluctantly got used to the distro destroying its own root partition a couple of times a year.
In the end I reinstalled on plain old ext4, and then it became rock solid, but you lose snapper and the rollback functionality, and they are handy.
> I want to say I was playing with Mandrake, Red Hat and a little Gentoo at the time.
I don't know when you started playing with all of these and for how long, so it can be absolutely how you said (in the end, it's your own life!) but chances are you mostly used Mandriva, since the Mandrake name disappeared in 2005.
I didn't know snapper supported LVM. That is nice. OpenSUSE's installer probably doesn't support it with its snapper setup though. Default is / btrfs and allowing snapshots if the disk is big enough. (More than 30gb?)
I want to say I was playing with Mandrake, Red Hat and a little Gentoo at the time. I started using it regularly around 2010ish - I was working at a Windows shop and had a pretty elaborate home lab with Windows servers and domain controllers so I could do things at home "before trying that on corporate." I remember the deciding factor became "I can use YaST to add this device to my domain controller and login with domain credentials easier than I can add a Windows box to the domain." And I found that was often the theme with many tasks, whether they're unusual like "logging into a Windows host" or mundane. Over the years, the software options available have been pretty incredible. I run Tumbleweed in most places and it's, by far, the smoothest "bleeding edge rolling update" distribution I've worked with. `Snapper` was my first experience with "working rollback."
Because of the fine folks at openSUSE, I went from "knowing nothing about Linux" to "using it as my primary desktop" and I'm mostly a .NET developer. So many development tasks are just easier to do under Linux, whether it's the pesky node or python module that needs gcc/LLVM to compile some dependency and the expansive set of software repositories and available `.rpm`s make it all very straight-forward.
I recently picked up a higher-end AMD GPU and was dismayed to find that ROCm support was limited, mostly, to Ubuntu[0]. I got everything mostly working in Tumbleweed -- interestingly, most of the AI workloads I put it through worked as well in Tumbleweed as they did in Ubuntu following the official documentation but a few of the ROCm utilities didn't run. I ended up reloading with Ubuntu and quickly regretted the situation. Stupidly, I assumed doing a distribution update would be flawless like it typically is with Tumbleweed. After all, the only way to actually update Tumbleweed is via a distribution update, and 2K packages later it very rarely fails to boot. I knew right away that I wouldn't have the safety of being able to pick the previous snapshot but I was surprised that when it failed half-way through it didn't bother to roll anything back; it simply left my machine in a broken state that booted directly to a text console. Having re-loaded this box four times in the prior few days, I decided to go back to what I knew.
About the only complaint I have centers around their default choice of `btrfs` for the filesystem. While I like the CoW functionality (the only particular "advanced" feature that I utilize with `btrfs`), it seems to excel -- mostly -- at teaching me about filesystem recovery. My home lab isn't anywhere near as elaborate as it had been in the past. It seems even on a UPS with proper shutdowns it's ridiculously prone to getting itself into a state where a `btrfs restore` is the only way to recover from a filesystem problem. Every single time I get everything back except for some random cache/tmp/log file but I need to dig up or purchase a volume of equal size to restore it to, meaning I have to keep around an empty drive at least as large as my largest volume. It seems to me "if the filesystem can literally restore everything except for a file or two that has become corrupted" it should offer a "dangerous" option to do so online. To this day I have never had to restore everything from an actual backup, it's always gotten back everything important simply restoring the broken filesystem to a new volume and the filesystem becomes corrupted without explanation -- power didn't fail, the system had a clean shutdown, it just randomly goes "read-only" with a guarantee that the next boot will drop to an emergency console. Unfortunately, CoW helps a lot with the work I do and ends up being worth the grief involved. While I've had fewer failures in the last couple of years and an easier time recovering from those failures, it's often a full day's work to get everything right, again.
[0] Support exists for Leap but the repositories were broken for a solid month while I was setting things up.