Исходное сообщение
"Доступны OpenIndiana 2020.04 и OmniOS CE r151034, продолжающ..." Отправлено andy, 10-Май-20 10:18
> Не совсем понял, почему ТВОЕ утверждение о том, что промышленная ОС это "маркетоидный буллшит" Потому, что есть операционная система. И выбирают ее исходя из потребностей. И мне всегда было любопытно, почему коммерческий *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... Это из того, что вспомнилось по опыту. > Для начала, может объяснишь - а каким образом эти вещи вообще соотносятся? Причем тут дешевизна > разработки и моё в ней участие? Эти вещи соотносятся непосредственно. Если у Вас есть релевантный опыт в работе над ядром или дистрибутивом "наколенной" ос, Вы бы сами могли оценить усилие и масштабы работы, после чего не писать про "разрабатывать дешевле и быстрее". > Причем тут дешевизна разработки и моё в ней участие? При том, что Ваше оценочное суждение, непонятно на чем основанное (не на собственном опыте уж точно), может не являться верным, допускаете? > Так ведь мнение собирается из твоих же действий. Так это и в обратную сторону работает, понимаете, админ "промышленной" ос?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Не совсем понял, почему ТВОЕ утверждение о том, что промышленная ОС это "маркетоидный буллшит" > Потому, что есть операционная система. И выбирают ее исходя из потребностей. И > мне всегда было любопытно, почему коммерческий *nix - это "промышленная ОС", > а RHEL или Debian - "наколенное поделие". И почему у базы > данных Oracle заявленна поддержка промышленных(tm) и "наколенных" ос? И когда Оракл > собезъянил CentOS, стал ли их дистрибутив linux "промышленной" ос, сделанной из > "наколенной" и в какой момент времени? Думать головой надо, а не > пересказывать маркетоидную херню. >> Естественно, вместо кучи воды и бестолковых вбросов можно было с этого и начать > Ты правда не в курсе, или просто прикидываешься? > 1. Эпичный баг в libc соляры, по 256 файловых дескрипторов на процесс, > который, souuuqqaaa, 18 лет исправляли и умудрились это сделать не с > первого раза. > https://stackoverflow.com/questions/312091/file-handlers-limit-crossing-256 > 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/preparecustom-24696.html#scrolltoc > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/installation_guide/s1-kickstart2-options > Это из того, что вспомнилось по опыту. >> Для начала, может объяснишь - а каким образом эти вещи вообще соотносятся? Причем тут дешевизна > разработки и моё в ней участие? > Эти вещи соотносятся непосредственно. Если у Вас есть релевантный опыт в работе > над ядром или дистрибутивом "наколенной" ос, Вы бы сами могли оценить > усилие и масштабы работы, после чего не писать про "разрабатывать дешевле > и быстрее". >> Причем тут дешевизна разработки и моё в ней участие? > При том, что Ваше оценочное суждение, непонятно на чем основанное (не на > собственном опыте уж точно), может не являться верным, допускаете? >> Так ведь мнение собирается из твоих же действий. > Так это и в обратную сторону работает, понимаете, админ "промышленной" ос?
	Введите код, изображенный на картинке: