Основная мысль была что вопрос "меньшей надежности" в убунте и "старости софта" в дебиан имеет нюанс: вряд ли кто то в здравом уме будет гнаться за свежестью софта как главным критерием. При этом в данном топике уже разговор пошел именно в этом не правильном русле. По этому надо понимать, что стоит "под капотом" в этом споре.
Из опыта: я всегда за Debian. Некоторые проекты были на CentOS, но т.к. она перестала существовать в качестве продуктовой версии. (ведь SentOS Stream так и позиционируется вендором как тестовый полигон)
В прочем выбор между Debian и Ubuntu определяется тем:
1. Я уже пользовался debian прежде чем появилась Ubuntu (в т.ч. и на десктопе)
2. Был личный опыт когда приходилось решать проблему Ubuntu (правда в качестве десктопа было)
Полагаю что обилие вариантов с Ubuntu (на тех хостингах где за нее топят) это скорее про маркетинг+ личные предпочтения владельцев хостинга. Сборку можно подготовить на любом дистре... так что дело вкуса про сборки.
Debain на сервере ни когда не заставлял делать какие то лишние движения. Хотя нюанс: сейчас использую скрипт который на голую ОС ставит все что мне нужно
В любом Linux ПО устанавливается согласно пожеланию администратора. Что значит "лишнего ПО меньше"? :) Если я поставлю себе ВСЕ пакеты из штатных реп (в дебиан) у меня будет дохрена лишнегго, если я поставлю минимум на убунту... и как тут будет работать сравнение?
Пакетная база у Debian самая большая. (если конечно в последнее время ни чего не изменилось)
Для начала не забываем, что речь идет о серверах. Сомневаюсь что есть различие. Тут вообще все дистры будут плюс минус одинаково. На десктопе..... фиг знает: плюс минус. Тут скорее вопрос от того какой GUI будет выбран. Ну, а далее (на любом дистре) включаем голову, берем доку (если нужна) , пакетный менеджер и делаем либо суперлегкую либо супертормозную систему :)
Вообще говоря определяется это в первую очередь логикой. Debian и Ubuntu различаются своим подходом к релизам. Если упрощено: убунта выпускается релизы по графику, а дебиан выпускает релиз только тогда когда пофикшены все найденные баги (ну или практически все :) )
Отсюда собственно и такое мнение, отсюда же, как следствие, что пакеты более устаревшие. По сути по "стабильности" убунта сопоставима с Debian ветки Testing . Я долгое время использовал тестинг на десктопе - вполне себе стабильно.
Ну, а далее, естественно, уже надо конкретно смотреть какой баг не успели закрыть до релиза, ну и грамотно подходить к выбору релиза и моменту перехода на следующий. На сервере скорее будет LTS версия.
В то же время "устаревшие пакеты Debian" точно так же "так себе аргумент". Это скорее важно для десктопа. Да и то, под вопросом. На своем опыте, долго сидел на тестовой ветке, сейчас уже несколько лет на стабильной. Вообще не вижу ни каких проблем от "устаревших версий". Есть некоторые пакеты (порядка пяти), в которых мне условно "важно" иметь свежую версию - всегда есть возможность поставить свежую. На серваках такая необходимости реже возникает.
Так же надо понимать в данном плане "новые версии" это не про безопасность, а про функционал и на серверах редко есть объективная необходимость "быть на острие версий"
Короче, если это опенсорс решение, то почти наверняка это Linux (скорее всего, CentOS/Alma)
Если это коммерческое решение, то скорее всего VMware ESXi. Windows Server - маловероятно
centOS ? Ее же больше нет. А стрим ставить на прод.... не верю
Т.е. не хватает знаний сделать правильный кастом, но хватает знаний сделать все, что нужно полностью с нуля.... ну ну.. :)
Не знаю чего вам там забанили, но репозиторий на githab "мастхев" в таких проектах. (Уже если каким то чудом вы реально там забанены - есть и аналоги). Это важно и для распространения, и для разработки особенно публичных решений.
Скрипт очень сырой. Он не дожидается загрузки картинок как следствие не гарантирует их подхватывание. В прочем сомнительный функционал сгребать все картинки со страницы. протестировать удалось только убрав из фильтра некоторые условия.
Зачем вы включили в него стили (те что отвечают за дизайн точно не стоит втаскивать внутрь скрипта), и саму верстку - не легче ли создавать скриптом ее, что б не было необходимости потом искать в DOM и навешивать обработчики. Крутящийся прогресс при каждой смене картинки - сомнительное решение. Зачем оно ведь картинки в данном случае уже загружены. Опять же: достаточно стандартное решение, что на старнице отображаются маленькие превью, а при открытии уже их полноразмерные варианты..... ну и в общем по мелочи не хватает некоторого функционала, который популярен в подобных скриптах.
И не только на странице. Есть у меня проект, там фоном идет обмен с несколькими внешними сервисами. Все три обмена готовые сторонние решения (и не дешевые). Но глядя на их реализацию (опять же вопрос алгоритмов) хочется кого то прибить...... Там такое ощущение, что люди сделали решение для каталога (вот как раз как выше говорили "до 1000 товаров" и с парой заказов в месяц) и им все ок.... И вот эти процессы идущие фоном на серваке - способны этот сервак загасить полностью
