Well to the point! Thanks James for your reply on behalf of mine.
There’s two areas I’d like to elaborate on.
For the first major reason to understand, you must escape your bubble first:
People tend to only think about their individual situation (e.g. in terms of physical accessibility), the hardware they own, their knowledge, their preferences and sometimes even their ideology.
openHABian is for people that cannot or don’t want to mess with Linux. That’s the majority of users.
Interactively modifying a specific Pi model to boot off some specific non-default device is hard to impossible for beginners but to the Linux experienced it is no challenge.
Then again, Linux guru or not, building a self-configuring system that automagically, NON-interactively and reliably does this for all sorts of servers, firmwares and USB devices is just not feasible.
Once we offer an option even when the assumptions and limits are documented that they should or must not, people will nonetheless start using it, start complaining when it does not work and post hoping for help thus wasting ressources, some even expect to get support. So we as maintainers have to - and we do - put lots of our spare time into validating to ensure it works for everyone, in as many use cases and under as many conditions as possible.
Apply this to the SSD use case to see that’s a very time consuming task we cannot provide for the huge range of software and parameters that are affected when you want to move your root filesystem somewhere else than the default.
The second major reason is a technical one:
What openHABian offers today, i.e. the combo of ZRAM and SD mirroring, provides results superior to what you obtain from moving to an SSD, it’s cheaper and requires less efforts.
Here’s some more stuff that SSD apologists usually don’t think of:
An SSD only gets you a longer MTBF (if at all because it also intros potential for new problems e.g. with space, cooling and power limitations). ZRAM gets you about the same MTBF improvement.
Then again MTTR is the more impacting part of the calculation and any hardware/driver/OS setup modification such as the SSD move will also inevitably worsen your MTTR a lot.
Here’s why: If you don’t have a spare SSD, you must order it the day your system dies → downtime at least some days (and you won’t know if a cold spare works when you need it if you haven’t been using it actively).
When there have been changes in the image or to the OS during operations compared to the one you installed with last time (and there always are many), the reinstalled system is not guaranteed to continue working flawlessly with your old SSD let alone any other model.
Chances are you don’t even get the replacement to work let alone in half an hour unless you keep thoroughly and constantly testing, verifying and updating your setup procedure every time any of the firmware/software components and settings you rely on changes. That’s what outsourcing companies do, they spend A LOT of resources on staying up to date and they wouldn’t be spending money on that if it wasn’t essential to their business.
The openHABian implementation is not “over-managing” but matches this approach.
Your one-shot model is a real no-go in the professional world.
Restoring the zip file might not work for example after the OH version has changed (image will always install the latest, some older OH versions are even not available any more, let alone non-default binding jars). And don’t forget all the remaining tools and modifications of your system beyond pure OH. Several OS packages will have changed meanwhile so will those keep working?
The backup system implementation in openHABian will not properly work any more. The current documentation is hardly applicable to modified setups which will confuse people right in the worst moment when they are in need (of a restore).
And so on, I could continue that list with stuff I’ve seen fail in reality while your “I can get that back up running in an hour” is just another incarnation of the “hope principle”.
The openHABian implementation is experience and sense of responsibility shrink-wrapped put to use.