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

Но гит в этом прекрасно меня заменяет.

Прикольно! Впрочем, я ж для себя делаю, обойдусь без реверансов 😊

То, что ты описал я обычно делаю rpmbuild’ом из родной системы

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

Сейчас уже длинная баш-портяка, которую запускаю перед бекапом, что позволяет делать его быстро и занимать минимум места. Сегодня делал — Clonezilla управился за полторы минуты, а клон занял 2,4 гига (вся система и важнейшие файлы по работе).

Ради упрощения такой стратегии бекапов и решил когда-то освоить mock. Впрочем, я ни разу не собирал ничего прямо в системе, может оно и сложнее в чем-то, хз.

Правильно отключать selinux в федора-лайк дистрах надо так, как я написал. Твой вариант давно устарел даже для RHEL. SELINUX=disabled остановит работу, но оно будет загружаться и в журнале будет выдано предупреждение об устарелости этого метода.

ОМГ, на слаке ещё кто-то сидит… Хотя я сам её использовал в своё время - года 3-4, наверное. Классная система, но много приходилось руками собирать.

Как я понимаю, у них много документации доступно без подписки.

Пример: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/tuning-the-network-performance_monitoring-and-managing-system-status-and-performance

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

Причин нет

Сейчас не сижу, но хочу вернуться

Пользуюсь только RHEL и Debian

RHEL только на брендовые серваки (железо) и/или под проприетарный софт требующий определенную вендор/версию ОС (RHEL там всегда присутствует)

Во всех остальных случаях Debian

Debian лучше чем RHEL

у меня пара каталогов на это сделано а b, файлы в них ложу, меняю только в b и делаю:

diff -ruN a/ b/ >foo.patch

срок поддержки один год

не гони - там роллинг есть

Ты rawhide что ли предлагаешь на сервер ставить? Или про какой ещё ты роллинг?

...почему вы это делаете?

Я? Делаю?

А если серьёзно...
Лично я сижу на Альте. Оч. долгое время (really very long time) сидел на Red Hat (не путать с RHEL), и вот тогда я подсел на rpm.

А вот с RHEL «любви» не произошло из-за «заточенности» RHEL на корпоративный сектор.

Полагаю, что именно этот фактор и привлекает к RHEL.

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

А что с последним не так? Он определённо удобнее для простых случаев, чем ручное копание в nftables или iptables. Типа разрешить такие то порты везде, а такие то только на доверенных сетках, всё остальное запретить…

Мне проще обычный iptables/nftables настроить чем вспоминать синтаксис и логику firewalld, плюс он создает абсолютно ужасающую нечитаемую портянку в iptables-save

1.
5. На сервер не ставится GUI и пакеты приходится ставить через консоль. И какой же dnf (а до не го yum) удобный, с нормально форматированным выводом. И какой же apt в этом плане говно. Начиная от вывода (результат работы как есть сблёвываем в консоль) и кончая консистентностью команд. Пока ставишь удаляешь пакеты ещё ничего, но когда задача хоть немного усложняется. Например получить пакет, чтобы покопаться что там у него внутри. Или найти какому пакету принадлежит этот файл. В dnf всё под одной крышей. В apt - сначала нагугли какой утилитой это делается, потом доустанови её... meh.

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

Что значит настраиваю или использую? Использую штатные политики, дополняют их своими. Но что-то нетривиальное очень редко делать приходится.

iptables-save

Моё имхо: iptables-save всегда была нечитаемой портянкой. Наверное за это так и понравился nftables. Соответственно, для сложных конфигураций firewalld проще снести, но 95% серверов требуют только открыть пару портов и всё. Чего там читать?

Нечитаемая портянка там будет только если ты её сам перед этим организовал. Кстати я не знаю зачем нужна эта команда когда есть iptables -S без лишних обёрток.

но 95% серверов требуют только открыть пару портов и всё. Чего там читать?

--append INPUT -p tcp --dport 123 --jump ACCEPT
--append INPUT -p tcp --dport 345 --jump ACCEPT
--append INPUT --jump DROP

Ну и чего тут сложного или нечитаемого? Намного лучше смотрится чем флуд из firewalld.

Ну и чего тут сложного или нечитаемого?

Я имел ввиду не это. А именно то, как iptables сохраняет фаервол для загрузки. До nftables я предпочитал скрипт иметь, потому что в таком виде оно более понятно.

P.S. А в firewalld будет так:

firewall-cmd --permanent --zone=public --add-port=123/tcp
firewall-cmd --permanent --zone=public --add-port=345/tcp
firewall-cmd --reload

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload

rawhide

а чем это хуже того же sid?

Под шапку иногда бывают пакеты, которые на других системах собраны на коленке и работают через известный универсальный интерфейс. Например ceph. Хотя она в любом случае через жопу работает. Других кейсов хз

Скорее всего rawhide ломается чаще. Rawhide скорее ближе к experimental.
Но я ни rawhide, ни sid активно не использовал, так что это лишь предположение.

Но в любом случае, есть отважные парни, которые sid на серверах используют?

есть отважные парни, которые sid на серверах используют?

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

Но в любом случае, есть отважные парни, которые sid на серверах используют?

Таких, кто использует sid на десктопе - знаю. Таких, кто использует sid на серверах - не знаю.