I don't recall having problems with Dell server-related packages on Debian, even if their own crapware (OpenManage Essentials and then Enterprise, legitimately one of the worst pieces of software I've ever had the displeasure of using) for managing iDRACs and firmware came as a CentOS-based appliance.
It's still a frighteningly low number of distros considering we used to have an abundance of distros to hop around on for desktop use. Distrowatch.com for example, but for all those distros, when it comes to servers we narrow ourselves down to less than a handful.
Support you how and with what? What does your storage vendor have to do with your server's distros? Even the distro running on the server itself doesn't matter, really, because it's not like Dell/HP are writing distro-specific userspace drivers.
Operating systems have a hardware compatibility list (HCL). If your product is not on the HCL for the operating system vendor and you have a problem--at least one somehow plausibly related to the interaction between your product and the server--neither vendor is obligated to support you. (They may well try but there's no guarantee.)
I don't care if DistroWatch shows bunch of random newbie friendly distro in the upper ranking, they're not corporate supported.
Debian doesn't do clean 2 years LTS release cycle nor has 10 years extended support.
I have seen Gentoo used as a base to deploy binary packages veted by the org in the past. Gentoo provides tooling to do that and it worked fine.
Oracle also still sell a distribution.
ArchLinux, something I would never use professionally but enjoy on my machine. Packages are mostly vanilla and are updated quickly.
The last software company I worked for used CentOS.
Debian patches a lot for completely bonker reasons. They do it to support architectures nobody uses. They do it to remove part of packages for purely ideological motives. They do it to split packages into multiple parts making work harder for upstream when bugs are found. They do it to integrate with their own subpar tools. Sometimes they introduce major bugs along the way like the infamous OpenSSL one.
I understand people liking the fact that Debian is community maintained but the security track record is simply not there.
>On May 13th, 2008 the Debian project announced that Luciano Bello found an interesting vulnerability in the OpenSSL package they were distributing. The bug in question was caused by the removal of the following line of code from md_rand.c
> MD_Update(&m,buf,j); > [ .. ] > MD_Update(&m,buf,j); /* purify complains */ >These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL. You can see one such report to the OpenSSL team here. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only “random” value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.
The most security focused uh? the distro where a maintainer modifies code he doesn't understand because valgrind complains about it? In one of the most important packages of a linux distribution? No. Anyone who has had memories of this event would treat anything stamped with debian's name as nuclear waste.
Debian has had many conflicts with upstream projects for their relentlessly idiotic patching. Firefox once prohibited Debian from using the FF trademarked name and debian in turn renamed firefox "Iceweasel" in their distribution to continue shipping their tainted version.
I'd trust any of these : RHEL/Fedora, openSUSE, Gentoo and Arch over debian any day.
To be fair, the maintenir had asked about the change on the project mailing list and was given the go ahead.
I too don’t like the general attitude of Debian towards patching but it’s an issue of the whole project. There is no need to single out someone.