> Не совсем понял, почему ТВОЕ утверждение о том, что промышленная ОС это "маркетоидный буллшит"

Потому, что есть операционная система. И выбирают ее исходя из потребностей. И мне всегда было любопытно, почему коммерческий *nix - это "промышленная ОС", а RHEL или Debian - "наколенное поделие". И почему у базы данных Oracle заявленна поддержка промышленных(tm) и "наколенных" ос? И когда Оракл собезъянил CentOS, стал ли их дистрибутив linux "промышленной" ос, сделанной из "наколенной" и в какой момент времени? Думать головой надо, а не пересказывать маркетоидную херню.

> Естественно, вместо кучи воды и бестолковых вбросов можно было с этого и начать

Ты правда не в курсе, или просто прикидываешься?

1. Эпичный баг в libc соляры, по 256 файловых дескрипторов на процесс, который, souuuqqaaa, 18 лет исправляли и умудрились это сделать не с первого раза.
https://stackoverflow.com/questions/312091/file-handlers-lim...
technopark02.blogspot.com/2007/05/sun-solaris-solution-to-32-bit-stdios.html
Из-за этого про работающий Apache с логгированием каждого virtualhost'а в отдельный лог можно было забыть. Либо все в общий, либо иди к ...

2. Отсутствие bridge'а в сетевом стеке, до появления crossbow (OpenSolaris, Solaris 11).
3. Отсутствие tap интерфейсов без патчей, иначе про работу OpenVPN можно забыть
https://community.openvpn.net/openvpn/ticket/10#no1

4. Абсолютно ублдочный пакетный менеджер без разрешения зависимостей. ips был в OpenSolaris/Solaris 11, до этого момента - pkg*. Не в силах вынести такое убожество, кое-какое сообщество создало OpenCSW (ранее Blastwave), что бы хоть как-то по-человечески управлять пакетами, и не зависть от того, что вендор вывалил на дисках, плюс, дополнительно решало гадюшник из путей с исполняемыми файлами, которые могли лежать не только в /bin,/sbin,/usr/bin,/usr/sbin, а так же в /usr/ccs/bin или /usr/gnu/bin, или /usr/xpg4/bin, либо в /usr/dt/bin. И да, бинарники по этим путям были _разные_ (с разными возможностями), так как создатели "промышленной" ос пытались покрыть все стандарты posix сразу и усидеть одной задницей на всех стульях.
https://docs.oracle.com/cd/E86824_01/html/E54776/posix.2-5.html

Следствие - собрать собственный пакет можно, но не в среде для воспроизводимой сборки - никаких mock (как в RH/CentOS), или hasher (как в Альте) не было и в помине. Ребята из OpenCSW сделали GAR, что бы решить проблему. Оценить масштабы действа можно по ссылке https://www.youtube.com/watch?v=JWKCbPJSaxw
Что бы было понятно, сообщество "наколенно" решило проблему, на которую разработчикам "промышленной" ос было покласть.

5. Виртуализация в "промышленной" ОС Solaris Zones появилась практически одновременно с "наколеночным" поделием OpenVZ. В 2010 году проще и приятнее было работать с OpenVZ, нежели с zones (да, я субъективен)

6. Создание загрузочных флешек с Солярой прекрасно описано -  https://yvoinov.blogspot.com/2008/11/solaris-10-1008-usb.html . Годом ранее такая же процедура в "наколеночной" oc - https://www.debian.org/releases/etch/i386/ch04s04.html.en

7. Возможности jumpstart и kickstart. Примерно тоже самое как и с пакетным менеджером. Jumpstart появился давно и остался на примитивном уровне:
https://docs.oracle.com/cd/E26505_01/html/E28039/preparecust...
https://access.redhat.com/documentation/en-us/red_hat_enterp...

Это из того, что вспомнилось по опыту.

> Для начала, может объяснишь - а каким образом эти вещи вообще соотносятся? Причем тут дешевизна > разработки и моё в ней участие?

Эти вещи соотносятся непосредственно. Если у Вас есть релевантный опыт в работе над ядром или дистрибутивом "наколенной" ос, Вы бы сами могли оценить усилие и масштабы работы, после чего не писать про "разрабатывать дешевле и быстрее".

> Причем тут дешевизна разработки и моё в ней участие?

При том, что Ваше оценочное суждение, непонятно на чем основанное (не на собственном опыте уж точно), может не являться верным, допускаете?

> Так ведь мнение собирается из твоих же действий.

Так это и в обратную сторону работает, понимаете, админ "промышленной" ос?