У меня есть приличный опыт работы с различными дистрибутивами Linux, с 1998 года я использовал большинство основных, Redhat, Debian, Slack, SUSE, Gentoo и т. Д. Лично я предпочитаю Slack или Arch, а в некоторых случаях Debian из-за минимальная база и лучшее понимание вещей в вашей системе без необходимости полагаться на вспомогательные программы.
Теперь во всем опытном сообществе, среди людей, которые предпочитают такие вещи, как Gentoo, Slackware, Arch или даже BSD или LFS, некоторые другие дистрибутивы, такие как Ubuntu, Fedora, RHEL, SUSE и, в некоторой степени, Debian имеют репутацию полагаться на дистрибутивы. определенные инструменты или методы конфигурации, что затрудняет понимание системы, лежащей в основе.
Лично я уверен, что помню несколько случаев предупреждений не редактировать файлы конфигурации вручную или о том, что это было очень сложно сделать.
Действительно, есть поговорка, что если вы изучите Ubuntu, то вы изучите Ubuntu, а если вы изучите Slackware, вы изучите Linux. Для целей аргумента это также может быть применено к RHEL, SUSE и т. Д.
Недавно я разговаривал с фанатом Ubuntu, который оспорил это. Он сказал, что все файлы конфигурации есть, и их можно понять и отредактировать вручную, как в Slack или Arch, за исключением того, что у вас также есть дополнительный вспомогательный материал, если вы этого хотите.
Итак, мне интересно, насколько оправдано мнение о том, что если вы изучаете Ubuntu или RHEL, или что-то еще, вы узнаете эту конкретную систему, а не Linux, и что сложно управлять всем вручную, если у вас есть понимание? Есть ли правда в этом?
Ваш вопрос на самом деле не похож на вопрос. Но я укушу, потому что я такой наглый.
Я не могу разговаривать с Debian и производными дистрибутивами, потому что я никогда не использовал их в каких-либо целях, кроме как экспериментировать. Никогда не интересовался ими.
Дистрибутивы, производные от RedHat и RedHat, долгое время были моим основным «любимым Linux». Мне не нравится, когда на компьютерах в производственных ролях есть ненужное программное обеспечение. Это означает, что я сокращаю коробки CentOS (и все RedHat и производные дистрибутивы) до минимума RPM. Это также означает редактирование файлов конфигурации «вручную» и удаление инструментов, предназначенных для управления файлами конфигурации для меня.
Мне нравятся «приспособления» RedHat для определения параметров сетевых интерфейсов, статических маршрутов и конфигурации iptables, поэтому я обычно оставляю все это на месте. Для машины, которая будет функционировать как брандмауэр, веб-сервер, DHCP-сервер или другое "безголовое" действие, я убираю все RPM, связанные с X (используя --nodeps, если необходимо, для принудительного удаления), и любые RPM, которые не являются необходимыми и не связаны с ролью машины. Я всегда могу добавить их снова, если они мне понадобятся.
Я вижу здесь одну из моих виртуальных машин CentOS 5.2, которая показывает 113 об / мин на «rpm -qa | wc -l». ОС занимает примерно 600 МБ. Он, конечно, не «тонкий и аккуратный» по сравнению со старыми дистрибутивами, но он легкий для CentOS.
(Дерево зависимостей RPM становилось все безумнее и безумнее в дистрибутивах, производных от RedHat, за эти годы. На самом деле сейчас я не могу вспомнить одну из глупых зависимостей, но они сводили меня с ума, поскольку номера версий из дистрибутивов, производных от RedHat.)
Здесь есть два уровня понимания. Понимание Linux и понимание того, как что-то делает дистрибутив, - это две вещи. Чтобы быть хорошим администратором Linux, вы должны хорошо понимать, как работает Linux, но вам также необходимо хорошо понимать, как работает ваш дистрибутив.
Это ничем не отличается от того, как сетевой администратор должен понимать, как настраивать свое оборудование и управлять им, а также должен понимать сетевые уровни, их назначение и протоколы.
В конце концов, Linux - это такой же инструмент, как математика. Когда вы поймете концепцию и ее применение, в использовании калькулятора нет ничего плохого.
Я смотрю на это просто - системному администратору, настраивающему сервер, или пользователю, запускающему рабочую станцию, требуются вещи, которые работают из коробки с минимальными усилиями. Вот почему окна так популярны, несмотря на бесчисленное множество проблем.
Таким образом, все необходимое для производственных вычислений легко доступно в RHEL, просто установив из исходников. и вы можете быть уверены, что каждый устанавливаемый вами пакет прошел тестирование и готов к работе. Все это после простой установки, не требующей удовлетворения миллиардов зависимостей и компиляции всего из исходников.
Да, такая система может показаться раздутой людям, привыкшим к подходу LFS, но с современной вычислительной мощностью дополнительный модуль в ядре, занимающий 0,00001 процента, не является проблемой.
Мой ранний опыт работы с Linux включал много компиляции и даже больше установок CPAN, вплоть до того момента, когда я столкнулся с Debian - каждый пакет perl был доступен через apt, и они автоматически обновлялись всякий раз, когда мне требовалось обновление. Итак, как человек, которому нужно обслуживать несколько сотен серверов, я категорически против компилирования всего, начиная с исходного кода и заканчивая сборкой и настройкой всех возможных пакетов. Я бы предпочел полагаться на команды QA крупных дистрибутивов.
Если разобраться, все, что находится за пределами ядра, - это удобство.
Возьмем, к примеру, сетевые интерфейсы. Redhat предоставляет system-config-network-gui и system-config-network-tui, которые представляют собой сценарии, которые записывают файлы конфигурации в / etc / sysconfig / network и / etc / sysconfig / network-scripts.
Но на самом деле это файлы конфигурации, которые содержат скрипты, такие как ifup и ifdown, которые вызываются скриптами во время загрузки. Сами команды ifup являются оболочками для команды ifconfig.
Сама по себе удобная программа, позволяющая манипулировать значениями в ядре.
Можно было бы привести аргумент, что если вы не пишете свою собственную программу на C для прямого использования предоставляемых ядром API, вы не изучаете «Linux».
Ни одно из этих преимуществ над ядром не является обязательным - RedHat также предоставляет команду ip, которая делает то же самое, что и команда ifconfig. И, вероятно, есть сценарии и оболочки GUI, которые вместо этого создают это удобство.
Так что все зависит от того, где вы хотите провести черту. Независимо от того, что вы изучаете, вы будете изучать то, что не повсеместно применимо везде, даже в Linux.
Но удобство - это не плохо. Стандартизация - это не плохо. Это причина, по которой многие поставщики инструментов предпочитают (или поддерживают, в зависимости от поставщика) определенные разновидности дистрибутивов семейства RedHat: потому что таким образом они знают, что когда у клиента возникает проблема, они могут воспроизвести среду, в которой он использует свои лаборатории, чтобы они могли видеть, что происходит. Им не нужно беспокоиться ни о какой из шести миллионов тонко конфликтующих «оптимизаций», которые сделают любую машину Gentoo более или менее уникальной.