Закапывать ли Линукс?
Оригинал поста доступен здесь: http://tonsky.livejournal.com/292267.html
Немного флейма по теме - тут: https://www.facebook.com/oleg.i.tsarev/posts/10203858357569182
Здесь будут только цитаты оригинального поста и мои ответы.
Итак, закапывать ли Линукс*nix или нет? Попробуем разобраться.
>Вместо файловой системы, очевидно, нужна база данных. По сути, файловая система это и так БД, только не реляционная, без транзакций...
Современные (уже лет 15 как) файловые системы суть иерархические БД с транзакциями.
>Также как гонять unbounded потоки байт по TCP малой полезности идея (в 100% случаев нужны сообщения, а не поток)
Абсолютно голословное утверждение. Сообщения с проверкой доставки совершенно бесполезны при вещании потокового видео, в интерактивных играх, при передаче низкоприоритетной телеметрии и т.п. До тех пор, пока каналы передачи данных не будут гарантировать доставку данных за определенный промежуток времени, будут востребованы потоковые протоколы, позволяющие терять определенный процент данных в обмен на плавное ухудшение качества сервиса. Например, показывать вместо 48 кадров в секунду 24 лучше чем вообще прерывать трансляцию видео.
>хранить большие бинарные блобы произвольного содержания редко кому нужно.
Утверждать что большие бинарные блобы произвольного содержания никому не нужны может только тот, кто шизофренически игнорирует реальность. Реалии таковы, что средний пользователь хранит именно мультимедийные данные большого и очень большого размера. Фотографии, видео, различные документы, как с текстовым, так и с произвольным содержимым.
>...с неудобным программным API и непрозрачная внутрь файлов (sed/awk чтобы поменять значение поля в конфиге? буээ).
>Любое приложение почти всегда работает со структурированными данными, так зачем мучать котенка и каждого разработчика заставлять придумывать сериализатор и парсер конфигов и документов, когда это можно сделать на уровне системы.
Следующая проблема, вытекающая из необходимости хранения мультимедийных данных - невозможность построения обобщенного API для доступа к их содержимому. Чтобы иметь возможность править что-либо внутри файла через предоставляемое файловой системой API, для каждого формата потребуется писать свой сериализатор и десериализатор. По факту это означает перенос существенной части кода из пространства приложения в пространство файловой подсистемы. И если плагины для работы с XML/JSON/BSON/CSV написать довольно просто, то чтобы полноценно работать со сложными документами типа Photoshop, фото или видео, придется реализовать весь функционал этих приложений внутри ФС. Это чревато ошибками и большими проблемами с безопасностью.
Очевидно также, что такие сложные вычисления с потреблением огромного количества памяти невозможно проводить в контексте ядра, а значит, это будет пользовательский процесс. В свою очередь это потребует большого количества переключений контекста исполнения из ядра и обратно. Что очень, очень медленно.
Ну допустим, мы реализовали подобную систему. Теперь главное: какой смысл в возможности доступа к свойствам хранимого документа из любого приложения, если для каждого типа документа, очевидно, будет свое API со своими специфическими вызовами, востребованное одним-единственным приложением?
>Очевидно, современная ОС должна быть network-aware. Начиная от более толкового сетевого протокола (SCTP? ∅mq?), ориентированного на сообщения
Еще раз. Сообщения мало кому нужны при передаче большого количества данных. Все эти докачки с произвольного места в протоколах FTP, HTTP и других придуманы именно для того, чтобы при потере связности на 90% передачи не повторять заново отправку сообщения в N гигабайт, а докачать только необходимое. Не говоря уже о протоколах распределенного обмена небольшими частями сообщения, например, торрентах.
>а не на поток байт (поверх которого все равно все придумывают сообщения)
Кто - все? Вообще, откуда эта категоричность? Всем якобы нужны сообщения, всем нужна гарантия доставки и т.п.
>продолжая более соответствующими современной обстановке буферами (16Kb default TCP write buffer? SRSLY?)
Да, SRSLY. Если сделать буфер большим, а еще лучше - нелимитируемым, это кончится тем, что сделать DDoS сервису не сможет только ленивый.
>и минимальными возможностями роутинга (message broker вполне хорошо бы смотрелся в качестве системного компонента, и востребованность ∅mq это подтверждает), заканчивая cluster awareness.
Роутинг в качестве системного компонента каждого сервера заставит хранить огромную карту маршрутов. Это ресурсоемко и крайне небезопасно.
>Было бы круто, если бы я мог системными средствами видеть, где, кто и сколько машин вокруг, как-то разумно распределять по ним запросы, следить за их доступностью, броадкастить и общаться между ними.
Вообще говоря, любой, кто читал учебник по стеку TCP/IP умеет посредством использования системного API видеть, сколько машин вокруг, следить за их доступностью, броадкастить их и общаться между ними.
>Далее, модель процессов. Она построена вокруг предполагаемой интерактивности: stdin, stdout, string arguments, return value, это всё для работы в sh придумано.
Ну, кроме этого есть и процессы, лишенные управляющего терминала, man setsid.
>То что каждый процесс может максимум что вернуть 1 целое число проходит по категории тяжелого детства и деревянных игрушек. Может показаться что это круто и как раз и принесло UNIX модели бешеную популярность, но на деле это заставляет каждый процесс городить парсер на входе и сериализатор на выходе.
Ничто не мешает использовать другие методы межпроцессного взаимодействия. Если автор не в курсе, могу напомнить о существовании каналов, доступа к разделяемой памяти, отображении файла в память, работе через inet/unix socket, системных очередях сообщений, семафорах и многом другом.
>Программа принимает на вход путь до файла. Зачем? Почему не содержимое файла?
Видимо, автор не знает о существовании pipes. Это печально.
>Если я хочу состыковать ее с другой программой, мне придется научить их разговаривать через файл. Спрашивать на stdout вопрос, а на stdin ждать ответа (привет, ssh)?
По сути своей, это ничем не отличается от работы с так любимой автором 0mq. Там те же самые вызовы read/write/poll.
>Это низ composability, ниже некуда. Ориентированность на использование в sh рождает целую кучу бредовых паттернов (как вернуть из процесса строку, например?), о которых в обычных PL никогда не слышали.
Куда конкретно требуется вернуть строку? В зависимости от конкретных условий есть множество вариантов. Суть *nix в том, что нет одного единственно правильного метода взаимодействия, всегда можно выбрать наиболее оптимальное решение.
>Есть целая индустрия command-line arg parsers, считаете это хороший знак? Понятно, что программа на Java не передаст программе на Perl в качестве return value свой объект, но вот json может, и это будет куда лучше хрен-пойми-как-tab-space-and-comma-delimited вывода какой-нибудь утилиты типа ls, который еще и на stdout уйдет. Как это могло бы работать: TermKit и мой пост про смерть терминала.
Так и сейчас программа на java может передать json программе на Perl. Не совсем понятна суть претензии.
>Можно еще больше расфантазироваться, предложить делать каждый запускаемый процесс network addressable и приделать к нему mailbox (место, куда кто угодно может положить сообщение, а процесс прочитать).
Нельзя давать возможность писать кому угодно куда угодно. Рано или поздно это кончится DDoS или утечкой критически важных данных. Чтобы все это работало, необходимо разработать службы авторизации и аутентификации, а к ним - систему мандатного доступа. Кроме того, необходимы ACL, отсекающие доступ без каких-либо сложных проверок (например - только по маске сети).
>Модель украдена у Эрленга, но так ведь не зря - только Эрленгу пока и удается делать массивные кластерные приложения разумным количеством усилий.
Опять голословное утверждение. Ну вот почтовый сервис на 1.5 петабайта данных с несколькими сотнями нод в кластере - это массивное кластерное приложение или нет? Исходя из своей практики, межпроцессное взаимодействие - самая простая часть задачи. Гораздо затратнее написать быстрый и качественный парзер того же MIME.
>Интеграция чего угодно с чем угодно внезапно становится тривиальной вещью.
Интеграция чего угодно с чем угодно и сейчас тривиальна, см про средства IPC.
>Логично, если бы в ОС была встроенная time series database в которую логировалось бы всё происходящее внутри этой же системы и можно было бы прямо зайдя на http://host:17801/ посмотреть на графики.
Сейчас любой может зайти по ssh на хост и посмотреть все необходимые метрики. Ну да, при этом надо сделать запрос не вид "GET /... HTTP/X.X", а "ps -axw" или "sockstat -4", но суть от этого не меняется никак.
>С интерактивностью у меня вообще давние счеты. Мне кажется правильным строго забанить ходить по ssh на сервера, потому что куча бед и усилий у людей тратится на то, чтобы сделать себе удобный dev environment на удаленном сервере. Чувак, ты что там забыл, сервером надо управлять с пульта, а не сидеть на нём, настраивая тему в vim-е. Запускать процессы, инспектировать ФС (SELECT) и редактировать конфиги (UPDATE по БД), мониторить метрики можно по сети. Заметьте, что все перечисленные вверху средства network friendly. Плюсом будет огромное количество сэкономленных усилий, когда станет понятно, что sh-like интерактивность большинству программ не очень-то и нужна.
Ну так и пульт должен как-то ходить на сервер и делать все те вещи что делаются через ssh. Канал связи должен быть защищенным. В итоге получится тот же ssh, но с другими именами команд. Мне, если честно, непонятно, какой смысл менять одно на другое.
>Тут еще пора сказать, что надо прикрывать многопользовательность, она никому не нужна в век облаков. У серверов все равно как правило в /home один юзер, да и тот с правами sudo.
Типичный подход программиста, свято верящего что в системе работает только одно его приложение. На практике же для обеспечения минимально приемлемого уровня безопасности необходимо разграничение полномочий, и будет ли это MAC на основе имени процесса или запуск от определенного пользователя - не столь уж важно. Сейчас используется комбинированный подход: основная настройка прав доступа осуществляется запуском от указанного пользователя, а тонкая настройка ведется посредством мандатного регулирования.
> Меня давно нервировал тот факт, что для того чтобы запустить 1 java-процесс который собственно и является продакшн-приложением нужно поставить линукс с 20K файлов и 5K каких-то других левых процессов.
Админа наймите, наконец.
Теперь выводы.
1. Перед тем, как советовать закапывать технологию, следует ее изучить. Как мы видим из основных претензий, автор не в курсе о существовании фундаментальных систем и сервисов мира *nix.
2. Автор никогда не занимался вопросами безопасности приложений и не в курсе, какие угрозы бывают и как происходит защита от них.
Немного флейма по теме - тут: https://www.facebook.com/oleg.i.tsarev/posts/10203858357569182
Здесь будут только цитаты оригинального поста и мои ответы.
Итак, закапывать ли Линукс*nix или нет? Попробуем разобраться.
>Вместо файловой системы, очевидно, нужна база данных. По сути, файловая система это и так БД, только не реляционная, без транзакций...
Современные (уже лет 15 как) файловые системы суть иерархические БД с транзакциями.
>Также как гонять unbounded потоки байт по TCP малой полезности идея (в 100% случаев нужны сообщения, а не поток)
Абсолютно голословное утверждение. Сообщения с проверкой доставки совершенно бесполезны при вещании потокового видео, в интерактивных играх, при передаче низкоприоритетной телеметрии и т.п. До тех пор, пока каналы передачи данных не будут гарантировать доставку данных за определенный промежуток времени, будут востребованы потоковые протоколы, позволяющие терять определенный процент данных в обмен на плавное ухудшение качества сервиса. Например, показывать вместо 48 кадров в секунду 24 лучше чем вообще прерывать трансляцию видео.
>хранить большие бинарные блобы произвольного содержания редко кому нужно.
Утверждать что большие бинарные блобы произвольного содержания никому не нужны может только тот, кто шизофренически игнорирует реальность. Реалии таковы, что средний пользователь хранит именно мультимедийные данные большого и очень большого размера. Фотографии, видео, различные документы, как с текстовым, так и с произвольным содержимым.
>...с неудобным программным API и непрозрачная внутрь файлов (sed/awk чтобы поменять значение поля в конфиге? буээ).
>Любое приложение почти всегда работает со структурированными данными, так зачем мучать котенка и каждого разработчика заставлять придумывать сериализатор и парсер конфигов и документов, когда это можно сделать на уровне системы.
Следующая проблема, вытекающая из необходимости хранения мультимедийных данных - невозможность построения обобщенного API для доступа к их содержимому. Чтобы иметь возможность править что-либо внутри файла через предоставляемое файловой системой API, для каждого формата потребуется писать свой сериализатор и десериализатор. По факту это означает перенос существенной части кода из пространства приложения в пространство файловой подсистемы. И если плагины для работы с XML/JSON/BSON/CSV написать довольно просто, то чтобы полноценно работать со сложными документами типа Photoshop, фото или видео, придется реализовать весь функционал этих приложений внутри ФС. Это чревато ошибками и большими проблемами с безопасностью.
Очевидно также, что такие сложные вычисления с потреблением огромного количества памяти невозможно проводить в контексте ядра, а значит, это будет пользовательский процесс. В свою очередь это потребует большого количества переключений контекста исполнения из ядра и обратно. Что очень, очень медленно.
Ну допустим, мы реализовали подобную систему. Теперь главное: какой смысл в возможности доступа к свойствам хранимого документа из любого приложения, если для каждого типа документа, очевидно, будет свое API со своими специфическими вызовами, востребованное одним-единственным приложением?
>Очевидно, современная ОС должна быть network-aware. Начиная от более толкового сетевого протокола (SCTP? ∅mq?), ориентированного на сообщения
Еще раз. Сообщения мало кому нужны при передаче большого количества данных. Все эти докачки с произвольного места в протоколах FTP, HTTP и других придуманы именно для того, чтобы при потере связности на 90% передачи не повторять заново отправку сообщения в N гигабайт, а докачать только необходимое. Не говоря уже о протоколах распределенного обмена небольшими частями сообщения, например, торрентах.
>а не на поток байт (поверх которого все равно все придумывают сообщения)
Кто - все? Вообще, откуда эта категоричность? Всем якобы нужны сообщения, всем нужна гарантия доставки и т.п.
>продолжая более соответствующими современной обстановке буферами (16Kb default TCP write buffer? SRSLY?)
Да, SRSLY. Если сделать буфер большим, а еще лучше - нелимитируемым, это кончится тем, что сделать DDoS сервису не сможет только ленивый.
>и минимальными возможностями роутинга (message broker вполне хорошо бы смотрелся в качестве системного компонента, и востребованность ∅mq это подтверждает), заканчивая cluster awareness.
Роутинг в качестве системного компонента каждого сервера заставит хранить огромную карту маршрутов. Это ресурсоемко и крайне небезопасно.
>Было бы круто, если бы я мог системными средствами видеть, где, кто и сколько машин вокруг, как-то разумно распределять по ним запросы, следить за их доступностью, броадкастить и общаться между ними.
Вообще говоря, любой, кто читал учебник по стеку TCP/IP умеет посредством использования системного API видеть, сколько машин вокруг, следить за их доступностью, броадкастить их и общаться между ними.
>Далее, модель процессов. Она построена вокруг предполагаемой интерактивности: stdin, stdout, string arguments, return value, это всё для работы в sh придумано.
Ну, кроме этого есть и процессы, лишенные управляющего терминала, man setsid.
>То что каждый процесс может максимум что вернуть 1 целое число проходит по категории тяжелого детства и деревянных игрушек. Может показаться что это круто и как раз и принесло UNIX модели бешеную популярность, но на деле это заставляет каждый процесс городить парсер на входе и сериализатор на выходе.
Ничто не мешает использовать другие методы межпроцессного взаимодействия. Если автор не в курсе, могу напомнить о существовании каналов, доступа к разделяемой памяти, отображении файла в память, работе через inet/unix socket, системных очередях сообщений, семафорах и многом другом.
>Программа принимает на вход путь до файла. Зачем? Почему не содержимое файла?
Видимо, автор не знает о существовании pipes. Это печально.
>Если я хочу состыковать ее с другой программой, мне придется научить их разговаривать через файл. Спрашивать на stdout вопрос, а на stdin ждать ответа (привет, ssh)?
По сути своей, это ничем не отличается от работы с так любимой автором 0mq. Там те же самые вызовы read/write/poll.
>Это низ composability, ниже некуда. Ориентированность на использование в sh рождает целую кучу бредовых паттернов (как вернуть из процесса строку, например?), о которых в обычных PL никогда не слышали.
Куда конкретно требуется вернуть строку? В зависимости от конкретных условий есть множество вариантов. Суть *nix в том, что нет одного единственно правильного метода взаимодействия, всегда можно выбрать наиболее оптимальное решение.
>Есть целая индустрия command-line arg parsers, считаете это хороший знак? Понятно, что программа на Java не передаст программе на Perl в качестве return value свой объект, но вот json может, и это будет куда лучше хрен-пойми-как-tab-space-and-comma-delimited вывода какой-нибудь утилиты типа ls, который еще и на stdout уйдет. Как это могло бы работать: TermKit и мой пост про смерть терминала.
Так и сейчас программа на java может передать json программе на Perl. Не совсем понятна суть претензии.
>Можно еще больше расфантазироваться, предложить делать каждый запускаемый процесс network addressable и приделать к нему mailbox (место, куда кто угодно может положить сообщение, а процесс прочитать).
Нельзя давать возможность писать кому угодно куда угодно. Рано или поздно это кончится DDoS или утечкой критически важных данных. Чтобы все это работало, необходимо разработать службы авторизации и аутентификации, а к ним - систему мандатного доступа. Кроме того, необходимы ACL, отсекающие доступ без каких-либо сложных проверок (например - только по маске сети).
>Модель украдена у Эрленга, но так ведь не зря - только Эрленгу пока и удается делать массивные кластерные приложения разумным количеством усилий.
Опять голословное утверждение. Ну вот почтовый сервис на 1.5 петабайта данных с несколькими сотнями нод в кластере - это массивное кластерное приложение или нет? Исходя из своей практики, межпроцессное взаимодействие - самая простая часть задачи. Гораздо затратнее написать быстрый и качественный парзер того же MIME.
>Интеграция чего угодно с чем угодно внезапно становится тривиальной вещью.
Интеграция чего угодно с чем угодно и сейчас тривиальна, см про средства IPC.
>Логично, если бы в ОС была встроенная time series database в которую логировалось бы всё происходящее внутри этой же системы и можно было бы прямо зайдя на http://host:17801/ посмотреть на графики.
Сейчас любой может зайти по ssh на хост и посмотреть все необходимые метрики. Ну да, при этом надо сделать запрос не вид "GET /... HTTP/X.X", а "ps -axw" или "sockstat -4", но суть от этого не меняется никак.
>С интерактивностью у меня вообще давние счеты. Мне кажется правильным строго забанить ходить по ssh на сервера, потому что куча бед и усилий у людей тратится на то, чтобы сделать себе удобный dev environment на удаленном сервере. Чувак, ты что там забыл, сервером надо управлять с пульта, а не сидеть на нём, настраивая тему в vim-е. Запускать процессы, инспектировать ФС (SELECT) и редактировать конфиги (UPDATE по БД), мониторить метрики можно по сети. Заметьте, что все перечисленные вверху средства network friendly. Плюсом будет огромное количество сэкономленных усилий, когда станет понятно, что sh-like интерактивность большинству программ не очень-то и нужна.
Ну так и пульт должен как-то ходить на сервер и делать все те вещи что делаются через ssh. Канал связи должен быть защищенным. В итоге получится тот же ssh, но с другими именами команд. Мне, если честно, непонятно, какой смысл менять одно на другое.
>Тут еще пора сказать, что надо прикрывать многопользовательность, она никому не нужна в век облаков. У серверов все равно как правило в /home один юзер, да и тот с правами sudo.
Типичный подход программиста, свято верящего что в системе работает только одно его приложение. На практике же для обеспечения минимально приемлемого уровня безопасности необходимо разграничение полномочий, и будет ли это MAC на основе имени процесса или запуск от определенного пользователя - не столь уж важно. Сейчас используется комбинированный подход: основная настройка прав доступа осуществляется запуском от указанного пользователя, а тонкая настройка ведется посредством мандатного регулирования.
> Меня давно нервировал тот факт, что для того чтобы запустить 1 java-процесс который собственно и является продакшн-приложением нужно поставить линукс с 20K файлов и 5K каких-то других левых процессов.
Админа наймите, наконец.
Теперь выводы.
1. Перед тем, как советовать закапывать технологию, следует ее изучить. Как мы видим из основных претензий, автор не в курсе о существовании фундаментальных систем и сервисов мира *nix.
2. Автор никогда не занимался вопросами безопасности приложений и не в курсе, какие угрозы бывают и как происходит защита от них.