Причины выбрать клон RHEL вместо Debian (мини-опрос)

Ой, сюда же анонимы не смогут писать…

Модераторы, может в General переместить?

Добавь вариант «слышал что rhel пользуются крупные фирмы а они плохого не выберут».

В прошлом бздун и дебиянщик (домашний юзер).

Отказ от BSD понятен, а по поводу демьяна надо говорить, конечно, но это было давно, так что может там сейчас стало хорошо, не знаю.

Когда-то хорошенько подумав, понял, что наверное самый правильный Линукс — Федора, поэтому стал осваивать (не помню уже, что за версия была первая, но тогда ещё был гном2 везде).

Где-то 4 года назад решил попробовать Шляпу 8. Дело пошло, так на ней и сижу, только перелез на AlmaLinux 8, санкции случились. Вот такой осознанный выбор.

Нехватает варианта «мне за это платят». Вот приходишь в организацию, условия устраивают. Тебе на собесе сразу говорят у нас %distrname% это корп стандарт. И вот ситуация и выбор есть как будто, но не дистра

Сейчас пользуюсь ubuntu, но

rpm --rebuild

Интресно что скажешь, когда распробуешь mock 😊

3 и 4 — это и правда так. Сравни качество статей на https://wiki.debian.org/ и статей на https://access.redhat.com/search/knowledgebase , ну и срок поддержки больше в 2 раза — 10 лет у RHEL против 5 у Debian.

Что maxcom попросил, то и установил :-)

Считаю Дебиан (и Убунту, соответственно) дистрибутивом с устаревшей инфраструктурой и процессами из говна и палок. Работать все будет и там, и там, но мне неприятно таким пользоваться. Т.е. чисто вкусовщина.

Кали ставить надо, ну

дистрибутивом с устаревшей инфраструктурой

Речь про инфраструктуру, используемую разработчиками/мейнтейнерами?

Да, это весомые аргументы. Хотя и качество документации и срок поддержки у дебиана потихоньку растёт.

А selinux кто-нибудь настраивает? Или из коробки используете?

Я пользую notamock, рекомендую.

А selinux кто-нибудь настраивает?

Ага, это просто, надо добавить в параметры ядра selinux=0 и перезагрузить компьютер 😁

Ничтяк! Думаю вот как-нибудь росу покурить нормально, но её же надо наверное использовать как есть, а я привык ставить минималку и наращивать потихоньку без лишнего. Ещё тут у кого-то не получилось на systemd-boot её переключать, а мне понравилась эта штука.

Ну есть серверный образ, там по минимуму. Notamock он будет и в других системах работать, он на python. Я по работе его настроил и собираю из Роса для rhel пакеты.

Самая главная причина не выбирать дебиан - dpkg сотоварищи.

Клоны RH я выбираю сознательно из-за того что мои клиенты хотят Cpanel, т.е. в моем случае это вопрос поддержки софтом.

выбирающие бесплатные клоны RHEL

экономят на спичках? скупой платит дважды? почему сразу федору не воткнули? зачем эти поделия?

У RedHat лучше документация

Разве она не для подписчиков доступна?

Проф деформация, изначально был повсеместно debian, потом начал работать в ынтерпрайзе, обвешался редхатовскими сертификатами и понеслось, теперь просто по инерции.

Полистал форум росы, ты там прям активный разработчик, респект!

У fedora срок поддержки один год. Зачем такое на сервере?

4 (сейчас в основном alma 9) и 2 (selinux, который уже работает, а не можно сделать самому). Ну и частично 1, конечно, но это не принципиально.

Но в первую очередь rhel технологически лучше:

• В нём нет половинчатых решений, как это было во времена deb 9/10, когда они переходили на systemd, но сервисы оставляли работающими на скриптах, из-за чего мне приходилось самому заменять скрипты на нормальные unit-файлы, иначе дубликаты сервисов появлялись, в случае некорректного завершения сервисов.

• Пакетник и управление зависимостями пакетов лучше. Ты можешь взять пакет из федоры (например свежий cmake) и пересобрать его под rhel в 2 команды вообще не включая мозг. Да и пакетировать своё в rpm удобнее, чем в deb.

• Есть бэкпорты всего и вся. Нужен свежий питон? - пожалуйста, нужен свежий компилятор плюсов? - не вопрос. Свежая нода - держи.
  И всё это с большим сроком поддержки.

А из минусов только то, что в дебиане больше пакетов в штатной репе. Но пока для меня это не является хоть сколько-нибудь значимым фактором. Если будет, то можно и дебиан в этом конкретном случае взять.

] Я использую специфический функционал (какой?), которого нет в Debian.

и что же такого есть в rhel чего нет в debian?

Я пользую notamock, рекомендую.

Я из описания не очень понял, чем оно лучше mock --no-clean --no-cleanup-after ...?

Не, теперь только убунту и salix. Не хочу сложностей.

Я тоже не совсем понял, ведь у мока есть кэши и бутсрапы, а для того, что ты написал, в notamock тоже надо указывать настройку.

Потом неясно удобнее ли контейнер чрута, в который можно просто зайти ФМом и полазить.

Ещё интресно, если я хочу распаковать srpm, пошаманить, а потом результат назад запаковать, умеет он так или нет?

Чем хорош саликс?

Использую предпочтительно debian (если сам сервер готовлю), но иногда попадается alma/rocky, в принципе что то, что это - linux, просто со своими приколами которые надо держать в голове.

Касательно RHEL откровенно бесит навязывание NetworkManager и firewalld которые первым делом из системы удаляются (если нет задачи «оставить как есть», конечно)

Ну ниже уже ответили, в chroot можно зайти и посмотреть, быстрее разворачивается чем контейнер, прогу контейнера можно не ставить и не настраивать. Еще notamock поддерживает массовую сборку.

Я собирал через mock, теперь собираю через notamock.

s/mock/nix/

Справедливости ради, у дебиана есть https://wiki.debian.org/LTS/Extended, но о нем мало кто знает, что намекает.

Не все предпочитают обновляться раз в 10 лет через боль и слезы.

А, это ты, опять трусы через голову предлагаешь одевать 😁

Я читал, что никс или гуикс можно на любую систему ставить, но что-то не вдохновился.

просто если разобрать, пропатчить руками и собрать для тебя — просто, то NixOS, где такие идиотские self-inflicted проблемы отсутствуют, ты сможешь с закрытыми глазами администрировать.

Разобрать-собрать просто, а вот патчить совсем не умею, поэтому тупо редактором вандалю исходники (не более чем изменить константу, я ж не программист). И в спеке не шарю, познаю методом научного тыка. Последняя сборка mscore-3.6 для восьмёрки оказалась тяжким квестом, из-за того, что в федоре давно какие-то макросы юзают для сборки навороченных шрифтов, и пришлось спек от второй (емнип) версии адаптировать на 3.6, сцуко. Хорошо оно за15 минут собирается на моём компе.

Меня в никсе смущает специальный язык, я баш-то никак не выучу нормально для себя (хорошо теперь есть ИИ).

1. EL использовал для сетапов Oracle.

2. Некоторые заказчики хотят безусловный EL под свои задачи.

Я знаю, но там не все пакеты, а лишь часть.

Slackware + зависимости (slapt-get)

А в целом всё православно-канонично — sustemd, wayland, gnome etc?

Наоборот, сплошной косплей винтажного SVr4 - портянки на bash, но короткие и понятные, xfce, ванильное ядро, стабильные версии glibc и gcc.

в chroot можно зайти и посмотреть

Ну в mock тоже можно зайти и посмотреть. Как напрямую в /var/lib/mock/, так и через mock --shell. С этим по-прежнему не понял отличий.

быстрее разворачивается чем контейнер

Ну вот как раз mock --no-clean --no-cleanup-after вообще не разворачивается, а берёт уже развёрнутое. Куда быстрее?

прогу контейнера можно не ставить и не настраивать

С mock мне надо было что-то настраивать только чтобы подключить свою репу или сделать конфиг для непредусмотренного дистрибутива. Что ещё там настраивать? А репы и конфиги и в notamock придётся настраивать, если они нужны.
Я уж молчу о том, что его в репах федоры нет, т.е. в любом случае сперва будут пляски с установкой, вместо dnf install mock, хоть это и не проблема.

Еще notamock поддерживает массовую сборку.

А можно тут по-подробнее. Ему можно скормить пачку srpm’ок и он сам разберёт зависимости и соберёт в нужном порядке? Или там просто аналог for pkg in /path/to/*.src.rpm; do mock ... ${pkg}; done?

Мне массбилды гонять не приходится, так что не знаю.

Насчет mock –no-clean –no-cleanup-after, такое не использую на практике.

Ещё интресно, если я хочу распаковать srpm, пошаманить, а потом результат назад запаковать, умеет он так или нет?

Вообще это явно не целевое использование, т.к. основная задача mock - это «воспроизводимо» собирать правильно сделанную srpm в минимальном чистом окружении.

Понятно, что можно сделать контейнер через mock, поставить туда зависимости, а дальше в mock --shell орудовать rpmbuild’ом, и для каких-то целей это будет даже удобно.
Но предпочтительный вариант всё-таки включать все необходимые шаманства в spec-файл, а пошаманить внутри скорее отладочный вариант.

Понятно, что можно сделать контейнер через mock, поставить туда зависимости,

Не понял про контейнер. Зависимости и так легко штатно ставятся в рутовый-кэш, если есть rpm-ы, хотя лучше репу свою держать для этого дела, так удобнее, кмк. А чтобы после неудачной сборки не сбрасывать окружение, достаточно запускать с ключом -n.

а дальше в mock –shell орудовать rpmbuild’ом, и для каких-то целей это будет даже удобно.

Дык вроде всё нужное доступно из mock, даже не знаю зачем залезать туда через шелл, хотя наверное не дорос ещё 😊

Вообще это явно не целевое использование

Почему? Легко же делается. Я файл-роллером распаковываю srpm в каталог, скажем, source. Ковыряюсь там, а потом

mock --buildsrpm --source /path/to/source --spec /path/to/spec

и вот он — кастомный srpm.

Но предпочтительный вариант всё-таки включать все необходимые шаманства в spec-файл

Это надо уметь патчи писать.

Эээ… маргинальщина.

Я видимо тебя просто не правильно понял.

То, что ты описал я обычно делаю rpmbuild’ом из родной системы, без всякого mock, если нужно патч подкинуть или напрямую в исходниках/сборке что-то поменять.

Можно, конечно, через mock, но для этого не нужны никакие build-зависимости и целевая система, так что излишне.

Не понял про контейнер. Зависимости и так легко штатно ставятся в рутовый-кэш

Ну я это и имел ввиду. mock --installdeps или любой другой предпочтительный способ.

Это надо уметь патчи писать.

Ну непосредственно руками я тоже не умею патчи писать (ну или как минимум не хочу). Но гит в этом прекрасно меня заменяет.
Развернул исходники, сделал git init; git add .; git commit, поменял что хотел, git diff - вот твой патч.
Делать через патч, а не напрямую, менять не обязательно, но при обновлении версии может быть удобно (хотя зависит от того, что за патч).
Ну и так больше контроля за внесёнными изменениями, что иногда тоже полезно.

Лошара ты слакварьный. Надо делать

echo SELINUX=disabled >/etc/sysconfig/selinux