Переводы — Возьми этот GUI и выкинь.
Во многих случаях интерфейс командной строки делает жизнь проще, чем какой-нибудь симпатичный GUI. Ниже рассказывается, почему это так.
Несколько недель назад я публиковал несколько советов по VMware с рассуждениями, что компания, лидирующая на рынке виртуализации может купить SUSE Linux у Novell. (В контексте: "не делайте этого"). После этого, я получил много комментариев и писем, в основном, в ответ на мою критику утилиты YaST, которая служит центральной консолью управления SUSE.
Многие сказали: "если тебе не нравится YaST, то не используй его" - что, технически, верно, но, в действительности, не отражает проблемы, с которыми можно столкнуться, используя YaST вместо традиционного управления при помощи shell.
[ Пол Венеция разбирается в сетях. Посмотрите его Networking Deep Dive Report (англ.). | Смотрите InfoWorld's 10 tips for boosting network performance (англ.). ]
К тому же, YaST это одно из главных отличий SUSE от других дистрибутивов Linux. Если я не собираюсь запускать YaST, то почему мне не использовать CentOS или RHEL или какой-нибудь другой дистрибутив Linux? И вообще, чем отличаются дистрибутивы друг от друга в серверной части? Инструментами управления, инструментами обновления ПО, путями и выбором пакетов по-умолчанию. И вообще, всё это - просто Linux.
Даже если я уберу YaST, я вижу, что почти все инструменты управления сетевым оборудованием и серверами через GUI приносят больше проблем, чем пользы (кроме Windows, где, фактически, нету выбора, но даже там я выберу CLI для многих задач).
Этот выбор не является техно-чудачеством, это основано на реальном ежедневном администрировании серверов и сетей.
Вспомните четыре самых крупных производителя роутеров и свитчей за примерно 15 последних лет: Cisco, 3Com, Nortel и Cabletron. Из них только Cisco постоянно разрабатывала интерфейс управления, основанный на командной строке, в то время как остальные предпочитали текстовые меню для настройки оборудования. Некоторые также включали убогий CLI-шелл, но все они, такие простые в использовании, были вытеснены сравнительно запутанных CLI Cisco. Из этих четырёх компаний только Cisco процветал, когда остальные полностью провалились или были задавлены.
Также, в 1996, были основаны две компании, работающие с сетями: Extreme Networks и Juniper Networks. Обе они выбрали основным способом администрирования CLI, и обе ещё с нами и чувствуют себя замечательно.
Конечно, много факторов показывают этот эволюционный триумф, но наиболее значительным является то, что большинство проектировщиков и администраторов high-end сетей не могут обойтись интерфейсом в виде меню на сетевом оборудовании. Это просто усложняет многие вещи, которые можно делать проще. И так для многих "не новичков" вроде меня.
Позвольте мне привести пример. У меня недавно была задача создать сложную сеть, используя средства безопасности Cisco ASA. Используя CLI, я настроил всё, что мне требуется в одном ASA5520: IP адреса, маршруты, настройку туннелирования OSPF, параметры VPN-канала, набор правил QoS, списки доступа, правила для удалённых и локальных администраторов, строки SNMP, логи, новую версию прошивки - всё работает.
Затем можно скопировать все текстовые конфигурационные файлы и, при помощи sed, заменить все IP-адреса и параметры сети и получить (за минуту или две) полную конфигурацию для другого ASA5520s. Всё, что требуется - залогиниться на него, скопировать нужную прошивку и конфиги, затем перезагрузиться. Как ни смотри, это крайне просто и эффективно, что является одной из сторон простоты CLI и текстовых конфигурационных файлов.
Но затем я перешёл на Cisco SA520. В то время, как ASA5520s -полномасштабное решение ASA, SA520 позиционируется как решение безопасности для небольшого бизнеса. Это делалось для одного сайта, которому не требовалась мощь ASA5520 и, по спецификациям, SA520 предоставлял все требуемые возможности
В SA520 нету CLI или, вообще, обычной консоли . У него только Web UI.
В то время, как я мог настроить это устройство за минуту или две, как я это делал с его старшими братьями, мне пришлось пробираться через Web UI, чтобы сделать практически такую же конфигурацию, как у других ASA, с отличиями для этого сайта. Этот процесс занял больше времени, чем я тратил для настройки всех других ASA. Номинально, вам кажется, что настройка через Web UI будет легче, чем через CLI, но, в данном конкретном случае, это не так.
Честно говоря, SA520 разработан для малого бизнеса и предназначен для использования теми, кто не знает, что делать с настоящим CLI Cisco IOS. К тому же, Cisco производит PIX 501, который был выпущен для того же рынка, где работает PIXOS с полнофункциональным CLI. Однако, в SA520 Web UI - единственный доступный способ конфигурации. Полное сокрытие CLI делает устройство более сложным в использовании во многих случаях.
Вот другой пример: допустим, что требуется поменять внешние IP-адреса на файерволе крупной компании так быстро, как это возможно, чтобы сократить время простоя. Есть несколько способов это сделать. Самый дорогой - купить другой файервол, настроить его с новыми адресами, трансляциями, правилами и, почему бы и нет, просто включить его, выключив старый.
Если у файервола нету CLI, это может быть единственным вариантом, так, как всё что вы можете - быстро кликать от страницы к странице веб-интерфейса, пробираться через текстовые меню или запускать толстый графический клиент, чтобы сделать все нужные изменения "на лету". В зависимости от размера задачи, это может занять очень много времени.
Однако, если есть мощный CLI, вам требуется просто открыть текстовый редактор, сделать дамп необходимой части конфигов, заменить IP адреса, сделать нужные изменения в настройках маршрутизации, и затем, когда придёт время применять изменения, просто вставить конфигурационные файлы в файервол. Всё будет сделано за несколько секунд.
Эти примеры основаны на сетевом оборудовании, но та же самая концепция подходит практически ко всему. Если вы хотите внести значительные однообразные изменения на несколько Linux серверов, не проще ли залогиниться на них и один-за одним заполнить через GUI или текстовое меню поля, или написать простенький скрипт, который заполняет несколько новых конфигов и перезапускает требуемые демоны?
И речь идёт не только о затрате усилий - также учитывайте точность. Если вы запускаете скрипт, то можете быть уверенным, что выполненные изменения будут идентичными на каждой машине. Если же вы делаете всё вручную, то уверенности быть не может.
Как я говорил ранее, в Windows я широко использую графические инструменты - там есть CLI аналоги многих действий, выполняемых через GUI, но они не универсальны. Однако, столкнувшись с крупными изменениями в правах на больших файловых системах, я использовал fileacl 10 раз из 10.
Мораль этой личной истории такова: графические интерфейсы замечательные и необходимы во многих случаях. Но они должны быть тогда, когда уже есть нормальный CLI, только дополняя его. В других случаях, это позволяет делать простые вещи просто, а сложные - значительно более сложно.
Оригинал (английский): Take this GUI and shove it
Перевод:
Shtsh, 
settler
Несколько недель назад я публиковал несколько советов по VMware с рассуждениями, что компания, лидирующая на рынке виртуализации может купить SUSE Linux у Novell. (В контексте: "не делайте этого"). После этого, я получил много комментариев и писем, в основном, в ответ на мою критику утилиты YaST, которая служит центральной консолью управления SUSE.
Многие сказали: "если тебе не нравится YaST, то не используй его" - что, технически, верно, но, в действительности, не отражает проблемы, с которыми можно столкнуться, используя YaST вместо традиционного управления при помощи shell.
[ Пол Венеция разбирается в сетях. Посмотрите его Networking Deep Dive Report (англ.). | Смотрите InfoWorld's 10 tips for boosting network performance (англ.). ]
К тому же, YaST это одно из главных отличий SUSE от других дистрибутивов Linux. Если я не собираюсь запускать YaST, то почему мне не использовать CentOS или RHEL или какой-нибудь другой дистрибутив Linux? И вообще, чем отличаются дистрибутивы друг от друга в серверной части? Инструментами управления, инструментами обновления ПО, путями и выбором пакетов по-умолчанию. И вообще, всё это - просто Linux.
Даже если я уберу YaST, я вижу, что почти все инструменты управления сетевым оборудованием и серверами через GUI приносят больше проблем, чем пользы (кроме Windows, где, фактически, нету выбора, но даже там я выберу CLI для многих задач).
Этот выбор не является техно-чудачеством, это основано на реальном ежедневном администрировании серверов и сетей.
Вспомните четыре самых крупных производителя роутеров и свитчей за примерно 15 последних лет: Cisco, 3Com, Nortel и Cabletron. Из них только Cisco постоянно разрабатывала интерфейс управления, основанный на командной строке, в то время как остальные предпочитали текстовые меню для настройки оборудования. Некоторые также включали убогий CLI-шелл, но все они, такие простые в использовании, были вытеснены сравнительно запутанных CLI Cisco. Из этих четырёх компаний только Cisco процветал, когда остальные полностью провалились или были задавлены.
Также, в 1996, были основаны две компании, работающие с сетями: Extreme Networks и Juniper Networks. Обе они выбрали основным способом администрирования CLI, и обе ещё с нами и чувствуют себя замечательно.
Конечно, много факторов показывают этот эволюционный триумф, но наиболее значительным является то, что большинство проектировщиков и администраторов high-end сетей не могут обойтись интерфейсом в виде меню на сетевом оборудовании. Это просто усложняет многие вещи, которые можно делать проще. И так для многих "не новичков" вроде меня.
Позвольте мне привести пример. У меня недавно была задача создать сложную сеть, используя средства безопасности Cisco ASA. Используя CLI, я настроил всё, что мне требуется в одном ASA5520: IP адреса, маршруты, настройку туннелирования OSPF, параметры VPN-канала, набор правил QoS, списки доступа, правила для удалённых и локальных администраторов, строки SNMP, логи, новую версию прошивки - всё работает.
Затем можно скопировать все текстовые конфигурационные файлы и, при помощи sed, заменить все IP-адреса и параметры сети и получить (за минуту или две) полную конфигурацию для другого ASA5520s. Всё, что требуется - залогиниться на него, скопировать нужную прошивку и конфиги, затем перезагрузиться. Как ни смотри, это крайне просто и эффективно, что является одной из сторон простоты CLI и текстовых конфигурационных файлов.
Но затем я перешёл на Cisco SA520. В то время, как ASA5520s -полномасштабное решение ASA, SA520 позиционируется как решение безопасности для небольшого бизнеса. Это делалось для одного сайта, которому не требовалась мощь ASA5520 и, по спецификациям, SA520 предоставлял все требуемые возможности
В SA520 нету CLI или, вообще, обычной консоли . У него только Web UI.
В то время, как я мог настроить это устройство за минуту или две, как я это делал с его старшими братьями, мне пришлось пробираться через Web UI, чтобы сделать практически такую же конфигурацию, как у других ASA, с отличиями для этого сайта. Этот процесс занял больше времени, чем я тратил для настройки всех других ASA. Номинально, вам кажется, что настройка через Web UI будет легче, чем через CLI, но, в данном конкретном случае, это не так.
Честно говоря, SA520 разработан для малого бизнеса и предназначен для использования теми, кто не знает, что делать с настоящим CLI Cisco IOS. К тому же, Cisco производит PIX 501, который был выпущен для того же рынка, где работает PIXOS с полнофункциональным CLI. Однако, в SA520 Web UI - единственный доступный способ конфигурации. Полное сокрытие CLI делает устройство более сложным в использовании во многих случаях.
Вот другой пример: допустим, что требуется поменять внешние IP-адреса на файерволе крупной компании так быстро, как это возможно, чтобы сократить время простоя. Есть несколько способов это сделать. Самый дорогой - купить другой файервол, настроить его с новыми адресами, трансляциями, правилами и, почему бы и нет, просто включить его, выключив старый.
Если у файервола нету CLI, это может быть единственным вариантом, так, как всё что вы можете - быстро кликать от страницы к странице веб-интерфейса, пробираться через текстовые меню или запускать толстый графический клиент, чтобы сделать все нужные изменения "на лету". В зависимости от размера задачи, это может занять очень много времени.
Однако, если есть мощный CLI, вам требуется просто открыть текстовый редактор, сделать дамп необходимой части конфигов, заменить IP адреса, сделать нужные изменения в настройках маршрутизации, и затем, когда придёт время применять изменения, просто вставить конфигурационные файлы в файервол. Всё будет сделано за несколько секунд.
Эти примеры основаны на сетевом оборудовании, но та же самая концепция подходит практически ко всему. Если вы хотите внести значительные однообразные изменения на несколько Linux серверов, не проще ли залогиниться на них и один-за одним заполнить через GUI или текстовое меню поля, или написать простенький скрипт, который заполняет несколько новых конфигов и перезапускает требуемые демоны?
И речь идёт не только о затрате усилий - также учитывайте точность. Если вы запускаете скрипт, то можете быть уверенным, что выполненные изменения будут идентичными на каждой машине. Если же вы делаете всё вручную, то уверенности быть не может.
Как я говорил ранее, в Windows я широко использую графические инструменты - там есть CLI аналоги многих действий, выполняемых через GUI, но они не универсальны. Однако, столкнувшись с крупными изменениями в правах на больших файловых системах, я использовал fileacl 10 раз из 10.
Мораль этой личной истории такова: графические интерфейсы замечательные и необходимы во многих случаях. Но они должны быть тогда, когда уже есть нормальный CLI, только дополняя его. В других случаях, это позволяет делать простые вещи просто, а сложные - значительно более сложно.
Оригинал (английский): Take this GUI and shove it
Перевод:
Shtsh, settler
