Где именно закапывать Линукс, или вперед, в светлое будущее
Меня периодически клинит при столкновении с Линуксом, насколько архаичная это технология. Так же как я не умею восхищаться кодом, я не понимаю рассказов о том, как Линукс удобен для разработчика. Есть понятие devops. Типа, уважаемые программисты, а не офигели ли вы познакомиться ли вам с тем чем живут ваши братья-админы. Гуд, но у этого термина можно отыскать еще одно значение, а именно какие хорошо зарекомендовавшие себя практики программисты могут привнести в серверное администрирование. Можно очень много интересного придумать, если задавать один простой вопрос: я вот так в моем языке программирования могу делать, почему я с сервером не могу сделать то же самое?
Давайте немного пофантазируем, как могла бы выглядеть современная операционная система.
Исходный Линукс это такая большая интегрированная среда для разработки C-приложений. IDE for C. Если вы пишите на C, то весь Линукс, сама операционная система, это для вас такой рантайм, управление зависимостями, биндинги для C ко всему, тулинг. Понятно почему так получилось, но остальным это даром не нужно, а ведь создает кучу геморроя просто потому что есть и надо как-то считаться.
Итак, вперед, в будущее. Вместо файловой системы, очевидно, нужна база данных. По сути, файловая система это и так БД, только не реляционная, без транзакций, с неудобным программным API и непрозрачная внутрь файлов (sed/awk чтобы поменять значение поля в конфиге? буээ). Также как гонять unbounded потоки байт по TCP малой полезности идея (в 100% случаев нужны сообщения, а не поток), хранить большие бинарные блобы произвольного содержания редко кому нужно. Любое приложение почти всегда работает со структурированными данными, так зачем мучать котенка и каждого разработчика заставлять придумывать сериализатор и парсер конфигов и документов, когда это можно сделать на уровне системы. См. живой пример здесь. Как побочный эффект, целая пачка линуксовых утилит и их сумасшедшие command-line arguments умрут сведутся к набору SQL выражений (ps → select from processes..., ls → select from files..., и т.д.).
Очевидно, современная ОС должна быть network-aware. Начиная от более толкового сетевого протокола (SCTP? ∅mq?), ориентированного на сообщения, а не на поток байт (поверх которого все равно все придумывают сообщения), продолжая более соответствующими современной обстановке буферами (16Kb default TCP write buffer? SRSLY?) и минимальными возможностями роутинга (message broker вполне хорошо бы смотрелся в качестве системного компонента, и востребованность ∅mq это подтверждает), заканчивая cluster awareness. Было бы круто, если бы я мог системными средствами видеть, где, кто и сколько машин вокруг, как-то разумно распределять по ним запросы, следить за их доступностью, броадкастить и общаться между ними. Хорошую работу в этом направлении делают CoreOS и Serf.
Далее, модель процессов. Она построена вокруг предполагаемой интерактивности: stdin, stdout, string arguments, return value, это всё для работы в sh придумано. То что каждый процесс может максимум что вернуть 1 целое число проходит по категории тяжелого детства и деревянных игрушек. Может показаться что это круто и как раз и принесло UNIX модели бешеную популярность, но на деле это заставляет каждый процесс городить парсер на входе и сериализатор на выходе. Реализация интерактивности идет внутрь приложения, хотя она должна быть снаружи, вокруг не интерактивного, а extremely programmable, composable ядра. Программа принимает на вход путь до файла. Зачем? Почему не содержимое файла? Если я хочу состыковать ее с другой программой, мне придется научить их разговаривать через файл. Спрашивать на stdout вопрос, а на stdin ждать ответа (привет, ssh)? Это низ composability, ниже некуда. Ориентированность на использование в sh рождает целую кучу бредовых паттернов (как вернуть из процесса строку, например?), о которых в обычных PL никогда не слышали. Есть целая индустрия command-line arg parsers, считаете это хороший знак? Понятно, что программа на Java не передаст программе на Perl в качестве return value свой объект, но вот json может, и это будет куда лучше хрен-пойми-как-tab-space-and-comma-delimited вывода какой-нибудь утилиты типа ls, который еще и на stdout уйдет. Как это могло бы работать: TermKit и мой пост про смерть терминала.
Можно еще больше расфантазироваться, предложить делать каждый запускаемый процесс network addressable и приделать к нему mailbox (место, куда кто угодно может положить сообщение, а процесс прочитать). Модель украдена у Эрленга, но так ведь не зря - только Эрленгу пока и удается делать массивные кластерные приложения разумным количеством усилий. Почему, собственно, это не легитимизовать на уровне ОС? Интеграция чего угодно с чем угодно внезапно становится тривиальной вещью. Главная тут штука в том, что появляется штатный механизм как пообщаться с процессом, своего рода default API (на самом деле API transport). Сейчас, например, я поднимаю Java-программу и мне не очень понятно как с ней пообщаться. Нужно либо коннектиться к чему-то (message broker), либо поднимать целое HTTP API, что во многих случаях overkill. Подробнее см. Erlang On Xen.
Вообще, раз уж мы придумали себе process manager, неплохо оснастить его чуть более богатым чем spawn набором фич. Базовые возможности supervisord, мониторинг liveness, таймеры, реакция на события, оповещения, торчащий наружу API (самое главное).
Еще одна тривиальная, но жутко полезная вещь - metrics dashboard. Логично, если бы в ОС была встроенная time series database в которую логировалось бы всё происходящее внутри этой же системы и можно было бы прямо зайдя на http://host:17801/ посмотреть на графики. Тут важно чтобы это была не какая-то особенная система сбора метрик, а чтобы она была стандартная системная, включена по умолчанию и покрывала все базовые случаи (CPU, Memory, Limits). См., например, Amazon CloudWatch или Couchbase Dashboard, очень удобно.
С интерактивностью у меня вообще давние счеты. Мне кажется правильным строго забанить ходить по ssh на сервера, потому что куча бед и усилий у людей тратится на то, чтобы сделать себе удобный dev environment на удаленном сервере. Чувак, ты что там забыл, сервером надо управлять с пульта, а не сидеть на нём, настраивая тему в vim-е. Запускать процессы, инспектировать ФС (SELECT) и редактировать конфиги (UPDATE по БД), мониторить метрики можно по сети. Заметьте, что все перечисленные вверху средства network friendly. Плюсом будет огромное количество сэкономленных усилий, когда станет понятно, что sh-like интерактивность большинству программ не очень-то и нужна.
Я сначала хотел написать здесь, что поверх нужен красивый командный интерфейс, типа ansible, но на самом деле, если всё как следует прокачать, может получиться, что он сведется к тривиальности и работать будет хорошо даже и без него.
Тут еще пора сказать, что надо прикрывать многопользовательность, она никому не нужна в век облаков. У серверов все равно как правило в /home один юзер, да и тот с правами sudo. Раньше был смысл экономить (поставили один Линукс и весь институт на нем сидит), а сейчас есть новые средства, виртуализация, и самое простое и адекватное решение это одна задача - одна машина (или больше :).
Итак, что же мы тут насочиняли?
Во-первых, это, конечно, очень грубый концепт. Многие детали могут уточняться.
Во-вторых, мне очень нравится, как многие вещи тут объединяются и работают вместе. Скажем, пространство для process inbox может выделяться в той же самой БД, или local fs access ничем не отличается от remote fs access потому что SQL, или network-addressable processes сильно упрощаются при наличии process manager.
В-третьих, совершенно справедливо можно заметить, что это скорее обычные devops-практики, чем что-то кардинально новое. Многое из этого можно достичь сегодня в user-level. Верно, но. Главное достоинство концепта (если он когда-либо реализуется) в том, что это будет у каждого, по умолчанию и об этом не надо будет задумываться. Сейчас можно повторить, скажем, сбор метрик, но это надо уметь. А много ли ума надо, чтобы, скажем, записать строку в файл? Нисколько, это просто есть и работает. Так же и тут, если оно просто будет, всегда и by default, и просто будет работать, это кардинальнейшим образом упростит создание приложений. Современных, работающих в кластере, принимающих нетривиальные согласованные решения.
В-четвертых, очень приятно убирать лишнее. В этой концепции девелоперские машины, конечно, остаются сложными и интерактивными швейцарскими ножами, но от продакшна требуется быть минимальным - несколько core services да возможность запустить процесс, всё. Меня давно нервировал тот факт, что для того чтобы запустить 1 java-процесс который собственно и является продакшн-приложением нужно поставить линукс с 20K файлов и 5K каких-то других левых процессов.
В-пятых, я ни в коем случае не претендую на полноту. Очень интересно услышать, как по вашему мнению выглядела бы операционная система, если бы ее дизайнили сегодня?