linuxfreak wrote:... the stubbornness seems to come from your side.
...
RHEL is supported because paying customers do want enterprise distributions that come with support contracts most of the time. ... So that's apples and oranges, when you compare the market share of CentOS to other "community" or "desktop" linux derivates.
come on! -- just look at some
real world numbers instead of arguing in a quite speculative manner:
if you study this kind of statistics/trends, it should look more than obvious, that those days, where RHEL/CentOS undoubtedly represented a significant option, are more or less bygone history! RHEL plays a nearly negligible role at the present day.
but even, if it isn't a very popular choice anymore, i don't see any necessity to ignore or discriminate against this particular choice. if linux software is written with care, it simply should run on any kind of distribution with minimal adaptation efforts.
my
nvidia-docker based solution (
https://gitlab.com/mash-graz/resolve) is a radical different approach/workaround to solve this challenge.
it's somehow a hybrid solution, where you really use an unmodified CentOS resolve installation resp. runtime environment within an arbitrary linux host ambient. in this case, all of the CentOS specific dependencies and library versions are handled within the container in a perfectly reproducible and consistent manner. this makes it much easier, to reduce incompatibilities, trace actual bug reports and reduces the amount of necessary external installation requirements. the surrounding container hosting environment just provides the necessary general infrastructure in very compatible way. it should be better seen in analogy to running CentOS on various kinds of actual hardware.
especially resolves demand of CUDA access doesn't make it easy to realize this kind of environment isolation in practice, but the developers of nvidia-docker already prepared a fantastic solution, to work around all this nividia related dependencies and driver version incompatibilities in very satisfaying and mature manner. in the meanwhile it has become the de facto standard solution for CUDA acceleration in cloud related tasks (e.g. machine learning jobs running on kubernetes clusters...).
all the necessary tools to realize this kind of solution are already available for nearly any kind of linux distribution and well maintained by nvidias development team. o.k. -- it's a little more tricky on alpine and clear linux, but on the more common choices, its acceptable easy to install nvidia-docker, although not utterly trivial.
nevertheless i still have my doubts, if it's really an acceptable solution to the given problem or if daniels approach, to simply repack .deb packages, isn't a more satisfaying solution for the affected actual debian/ubuntu/mint users?
in fact, it would be very easy for me, to add this kind of debian repacking into the actual CI solution, just the same as it's now generating the docker images automatically. i often use this kind of private debian packaging and deployment via
aptly based private repositories hosted on GitLab pages in my inhouse work as well. it's a really nice and user friendly solution, to provide all the necessary update requirements in very comfortable and debian-like manner, but in this particular case, i don't think, it would be adequate.
i simply do not see any reliable way, to test and avoid all the possible incompatibilities in a sufficient manner in the given case. simple repacking of complex binary applications should be IMHO only seen as the last resort, if no other passable alternative is available. it can not substitute proper adaption and CI handled compilation/generation of perfect fitting packages for the most relevant target platforms/distributions. that's why i have precautionary chosen this other approach in this particular case, which undoubtedly also has it's drawbacks and uncomfortable/frightening complexity, but it seems to provide at least a little bit more control and robustness concerning all the mentioned well know obstacles and show stoppers.