Линукс 0

Опубликовал: Igor

Невозможно точно сказать, какова доля интернет-серверов, работающих под управлением Линукс1, но по косвенным данным (например по доле традиционных для Линукс HTTP-серверов2) можно предположить, что это как минимум две трети. В любом случае доля эта очень существенна, поэтому обойти тему этой статьи сложно, если мы говорим о том, как работает интернет.

Тема операционных систем и особенно их противостояния так велика и многообразна, что никакая статья ее не охватит. Поэтому не стоит и дергаться, надо сосредоточиться на чем-то одном, и желательно важном.

Начнем пожалуй с того, почему так получилось – в смысле почему существенна доля интернет-серверов, работающих под управлением линуксовых операционок.

Конечно же какую-то играет роль то, что они бесплатны. Но роль эта не так уж существенна. Провайдеры хостинга на виртуальных серверах предлагают Windows с довольно низкой помесячной оплатой. К примеру, у Rackspace гигабайтный сервер с Линукс стоит 43 доллара в месяц, а с Windows – 58. Плюс-минус такое же соотношение цен и у других тарифов, и у других хостинг-провайдеров. То есть хостинг все равно стоит денег, и в цене хостинга цена аренды Windows не так велика, чтобы играть заметную роль при выборе3.

Более существенной причиной являтеся историческая: Интернет изначально работал на юниксах. Тут не надо ничего доказывать, достаточно посмотреть где в какую сторону наклонены слэши: в юниксах и строке браузера – прямые слэши, в командной строке DOS/Windows – обратные.

Но одной исторической преемственности недостаточно, должно быть что-то еще.

Я абсолютно убежден, что такой причиной является Unix shell. Все самые существенные преимущества так или иначе сводятся к нему, даже если вы им не пользуетесь напрямую. Все те фичи, которые доступны на Линукс-серверах (как и на других юниксовых операционках – FreeBSD, Solaris и пр. – линуксовые более распространены, но это уже другая тема), но недоступны на Windows-серверах, были бы невозможны без юникс-шелла4.

Итак, что же собственно такое этот юникс-шелл?

Во-первых, конечно, это интерфейс. Человеко-машинный в смысле. То есть с его помощью можно запускать программы, получать данные и вообще делать все что угодно. Единственное, чего в нем нет, это WYSIWYG-функциональности. Другими словами, в нем несколько неудобно рисовать, и полноценной графики в нем нет. Видео смотреть можно, но видно плохо :)

Для этого есть оконные графические интерфейсы, шелл нужен несколько для другого.

Тут есть проблема: функциональность шелла сложно описать в двух словах. Если сказать, что это командная строка – это правда, но чем тогда это отличается от командного интерпретатора Windows (cmd.exe)? Если сказать, что это интерфейс для получения информации – это тоже правда, но чем тогда это отличается от браузера?

Вся суть шелла в том, что это то место, где встречаются и взаимодействуют ввод, вывод и командный интерфейс. Только не надо думать, что это суперфича, изобретенная великими мыслителями прошлого. Это просто естественное положение вещей. Другое дело, что оконно-графический интерфейс ее лишен в силу самой его парадигмы: он предназначен для более, разумеется, качественного вывода информации – но вывода “прямо в глаз”. А ваш глаз – не командный интерпретатор. Информация вам в глаз-то попала, но все, что вы теперь с ней можете сделать – это запомнить ее. То есть конечно можете выделить мышкой, покликать куда-то, сохранить, но во-первых это уже следующие действия, а во-вторых, это вы можете. А компьютер уже не может. Вы становитесь в этом случае прокладкой между выводом одной программы и вводом другой, что вынуждает вас во многих случаях совершать лишние действия, которые были бы совершенно не нужны, если бы вы использовали для этой же задачи шелл.

В этом месте меня обычно спрашивают, с подковыркой: “ну и для какой такой задачи?”. Объясню, с примерами, ниже. Но прежде надо обязательно объяснить еще одну штуку. Эта штука называется piping, и она является одним из самых могучих инструментов в арсенале шелла.

Она позволяет перенаправлять вывод одной программы на вход другой. При этом можно отделять сами данные от сообщений и перенаправлять их в разные места.

Что это дает? Прежде всего это дает возможность работать с удаленными серверами так же, как и с вашим локальным компьютером. Например: вам нужен график того, как изменяется нагрузка на сервер в течение дня. Для какого-то отчета, скажем, так что вы хотите вставить его в электронную таблицу. Большинство даже действующих серверных администраторов не осознают, что это очень просто (дает о себе знать трудное детство, знакомство с компьютерами происходило при помощи оконных интерфейсов). Конструкция ниже берет данные из лога удаленного веб-сервера за определенный день, делит данные по часам, суммирует количество запросов в каждом часе и выводит результат в файл CSV на локальном компьютере, который вы можете открыть в электронной таблице и построить график:

ssh your.webserver.com grep '24/Nov' /var/log/apache2/access_log | awk '{print $4}' | cut -d':' -f2 | sort | uniq -c > report.csv

Строго говоря, это не будет правильным CSV, потому что поля разделены пробелом и не заключены в кавычки. Если есть желание, можно удлинить “трубопровод” и сэкономить время на импорте неправильного формата:

ssh your.webserver.com grep '24/Nov' /var/log/apache2/access_log | awk '{print $4}' | cut -d':' -f2 | sort | uniq -c | while read line ; do echo $line | sed 's/^/"/g;s/ /","/g;s/$/"/g' > report.csv ; done

Команда ssh в этих примерах обеспечивает защищенное соединение с шеллом удаленного сервера (это сокращение от secure shell). Она сама по себе обладает некоторыми дополнительными возможностями типа организации туннелей, например, что позволяет работать с удаленными сервисами так, как будто они локальные. Вы (ваш шелл) для удаленного сервиса при этом – локальный клиент. В частности это позволяет пользоваться географически ограниченными сервисами типа видеосервисов, которые смотрят, с какого адреса IP вы подключились. Данные ведь не обязательно должны быть текстовыми, как в вышеприведенном примере, это может быть и видео, вы можете вывести поток в файл и получить его через HTTP и так далее – возможности неограниченны.

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

Ну и если по теме – выбор операционки ведь осуществляют, в большинстве случаев, профессионалы: хостеры, ИТ-отделы, сисадмины или кто там еще. Мне поэтому удивительно, что Windows может занимать целую треть от общего числа. Я бы больше пары процентов не дал.

Не подумайте, что я какой-то противник Windows. Просто каждому свое. Unix всегда был сетевой системой: есть терминал, есть ядро, где каждая из этих сущностей находятся – неважно, при условии, что между ними есть какая-то сеть. Windows же – это персональная система. Сеть к ней прикручивали уже потом, да и как ни прикручивай, запуск окошек на удаленных машинах – это мазохизм.

1 Под Линуксом тут понимается то, что и должно пониматься: ядро Linux.

2 Apache не обязательно означает юниксовую ОС, что сбивает статистику, но все-таки IIS гораздо более распространен под Windows, чем Apache, поэтому погрешность такой оценки не очень велика.

3 Для облаков это уже не так верно: облака отличаются, грубо, тем, что вместо одного большого сервера вы имеете много маленьких. В случае с Windows вам придется платить эти 13-15 долларов в месяц с каждого, что уже создает заметную разницу. Но на обсуждаемый вопрос это не сильно влияет, потому что облака появились относительно недавно.

4 Строго говоря, некоторые вещи, о которых ниже идет речь, – это заслуга стандарта POSIX, но я свалю все в кучу для простоты: в конце концов шелл – стандартный интерфейс ко всему этому.

Комментарии

Выскажитесь:

Коммент