I don’t know why people keep arguing this idea.
The short answer is this isn’t how it was conceived, and tearing out the parts that are OS specific leaves you with very little of Rockstor - you’d basically be looking at a Web UID wrapper for BTRFS and Docker.
Regardless, Rockstor is provided as source, it can be installed on any Linux flavour you like, It just won’t work the way you expect it to.
This is because some of the underlying requirements are different per OS, as I began outlining above.
Yes, systemd is pretty ubiquitous these days, and can be used via sysv commands with the Systemd sysv extensions, however this is one of many things that differ between distributions.
However, it should be noted that there is some drift amongst systemd unit names across different distributions.
Try restarting Apache or Samba in both Debian and CentOS.
My stated differences in my previous response are not a comprehensive list, there are many other differences between distributions
Rockstor would need to be altered at minimum to understand how Arch maintains packages. At the moment it is built under the premise that the underlying OS uses ‘yum’ for package management. This is being extended to allow for zypper, but honestly, how many package management systems must the devs be responsible for here?
Lets assume the devs acquiesce to building for Arch.
While they’re at it, they can also build for my preferred OS - Debian. You know, because time isn’t finite.
I’m sure somebody will want Rockstor built for for Alpine, Gentoo, Slack, some BSD variants.
Now the developers need to maintain routines for package installation via:
Now, lets say this is done the way I’d do it, by storing the package maangement commands in a database keyed to the distro name, meaning you can easily add and alter them (better portability).
You still need to account for package name drift amongst different distributions (CentOS - httpd vs Debian Apache2).
Beyond that, different distros have different ways of managing configurations for third party services.
CentOS avoids altering any configs modified by user. Some distros allow for elements of the config to remain untouched in comment tagged areas.
Debian instead opts for providing <config>.d directories defined as wildcard includes in the service config directory.
These things all need to be accounted for for the OS in question.
I’ve mentioned this on other threads in the past, but remember that Rockstor is not supposed to be an application, it’s an appliance.
This is the same logic behind why FreeNAS is FreeBSD based and not installable on Arch, Debian, CentOS, OpenBSD, etc (ostensibly, most BSD things are cross compilable with Linux).
Also the same logic that OpenMediaVault is based on Debian, and not installable on other distributions.
It’s also worth noting that Arch isn’t exactly
If you want Arch support, it’s probably something that you’ll need to bring to the table yourself.
I’m not saying that the Devs won’t choose to support Arch in the future, I’m saying they shouldn’t.
Not because there’s anything wrong with Arch. They also shouldn’t choose to support Debian in the future.
The reason for this is simple - Rockstor is to be installed as an OS, and run as an Appliance. It’s not supposed to be installed onto an OS and run as an application.
Also worth noting is that Arch hasn’t even been in the top 10 distros on Distrowatch any time recently, and has been declining.
Ostensibly, this means that users are less likely to be familiar with it and less likely have the inclination to learn it.
Personally speaking, had Rockstor been provided as OpenSUSE (Or Arch!) when I initially looked into it, I probably would have avoided it (Sorry Rockstor dudes!), purely because I’m familiar with BSD, Debian and CentOS already, figuring out the nuances of another OS and a new NAS framework at the same time would have been too much of a hassle.
Rockstor doesn’t have a very large development team. There’s very few of the developers that are actually active in developing Rockstor.
I’m sure the Rockstor team would love to make Rockstor as Linux distribution agnostic as possible. However, that’s currently not possible. There would need to be a huge influx in developers as well as funding for that to be possible.
From my understanding, Rockstor started out with the intent of being an appliance without being tied to specific hardware. Heck, the first I’d heard of Rockstor was at an InfoSec conference about 5 years ago and 45Drives was demoing one of their appliances powered by Rockstor. The 45Drives guys had chosen Rockstor as one of their options because it allowed them to not have to stick to specific hardware and be able to quickly push out new appliances.
@vesper1978 hit the nail on the head here. The choices realistically are:
Drop features that are OS dependant (service management, package management, others)
Increase development load (higher lead times or more staff, possibly both)
Build for a predictable system (Single distribution, or small set of)
Beyond that, given your only example in the statement:
I don’t see how being distro agnostic resolves this. This is an issue within the Plex application, running in a container. The problem will be present no matter which distro you start the container on.
Also, I have had this issue, I rolled back my plex container’s data share to a previous snapshot and did the sync again - no issues.
No paradox here, feel free to have a secondary boot drive. You can still have the btrfs-tools goodies for R&R, you’ll only lose the pretty interface - which is not particularly useful for R&R anyway.
It’s funny, but Rockstor actually removes a lot of configuration options. tiered subvolumes, path configuration, etc are all locked down from the UI, and many features will cause issues in the UI if you try to do them yourself.