>> for true long-term support, with support meaning=capability of debugging issues in-house for all the core stack they release
> Your definition of support doesn't match that used by enterprises like Spotify,
My sentence was exactly saying that: if you truly want your problem fixed, and the problems include debugging the kernel, RHEL is the way to go. There are companies that offer professional Debian support, but not at the same level as RH, sadly.
> > If the package you're having problems with is an old release that is not maintained anymore upstream
> Wouldn't Debian suffer the same problem here, e.g. if some piece of software's maintainer gets hit by a bus?
I also said that. Debian suffers from the same problem, though if the package is part of the debian "base" system in a stable release, it will be fixed, no matter what. Note that base packages with release critical bugs do not enter stable releases: either the bug is fixed or the package is dropped before hitting the stable release. Once is released, it will be supported. Most of the maintainers for the packages in the base system are also developers.
This is also one of the main reasons Debian releases are "costly" in terms of manpower, and that's why usually releases slip off by months due to release-critical bugs that stop the release process.
I personally don't follow stable releases, as I'm a developer. I often move between testing and unstable, which are basically rolling releases with different degrees of stability. But the work of the maintainers and the base system is vastly underrated, and unfortunately criticized for being a slow process.
> Your definition of support doesn't match that used by enterprises like Spotify,
My sentence was exactly saying that: if you truly want your problem fixed, and the problems include debugging the kernel, RHEL is the way to go. There are companies that offer professional Debian support, but not at the same level as RH, sadly.
> > If the package you're having problems with is an old release that is not maintained anymore upstream
> Wouldn't Debian suffer the same problem here, e.g. if some piece of software's maintainer gets hit by a bus?
I also said that. Debian suffers from the same problem, though if the package is part of the debian "base" system in a stable release, it will be fixed, no matter what. Note that base packages with release critical bugs do not enter stable releases: either the bug is fixed or the package is dropped before hitting the stable release. Once is released, it will be supported. Most of the maintainers for the packages in the base system are also developers.
This is also one of the main reasons Debian releases are "costly" in terms of manpower, and that's why usually releases slip off by months due to release-critical bugs that stop the release process.
I personally don't follow stable releases, as I'm a developer. I often move between testing and unstable, which are basically rolling releases with different degrees of stability. But the work of the maintainers and the base system is vastly underrated, and unfortunately criticized for being a slow process.