Lev Walkin (lionet) wrote,
Lev Walkin
lionet

Category:

Про "новые основания операционок"

Что-то бред какой-то, что с той, что с другой стороны. Как автор имплементации POSIX API для встроенной операционки ASA/PIX в Cisco Inc, прокомментирую.

> >Вместо файловой системы, очевидно, нужна база данных. По сути, файловая система это и так БД, только не реляционная, без транзакций...
>
> Современные (уже лет 15 как) файловые системы суть иерархические БД с транзакциями.

Ну-ну. Написать в файл, чтобы случайно не наткнуться на truncated файл — это эпопея с mkstemps(3) + rename(2). Чтобы гарантировать то, что fsync(2) сбросил буфера, и они дошли до пластин или флэша — это вообще по стандарту POSIX невозможно, да и кроме того на практике есть множество особенностей, от попытки качественного овладения которыми шаблон прикладного программиста не может не разорвать.

Если же требуется изменить два файла, или не изменить ни одного — это вообще просто пляска с бубном. Предложите алгоритм. А? То-то. На уровне базы все эти вопросы тривиально решаются обрамлением серии операций в транзакцию, а файлуха, которую пытаются выдать в качестве иерархической БД с транзакциями — да идите все в пень!

> >Также как гонять unbounded потоки байт по TCP малой полезности идея (в 100% случаев нужны сообщения, а не поток)
>
> Абсолютно голословное утверждение. Сообщения с проверкой доставки совершенно бесполезны при вещании потокового видео, в интерактивных играх, при передаче низкоприоритетной телеметрии и т.п. До тех пор, пока каналы передачи данных не будут гарантировать доставку данных за определенный промежуток времени, будут востребованы потоковые протоколы, позволяющие терять определенный процент данных в обмен на плавное ухудшение качества сервиса. Например, показывать вместо 48 кадров в секунду 24 лучше чем вообще прерывать трансляцию видео.

Комментатор сознательно решает не замечать логику аргумента.

Вещание потокового видео — серия относительно коротких файлов (в районе мегабайта на файл). Интерактивная игра — серия сообщений, либо HTTP (где один фетч — это по сути один мессадж), либо тот же WebSocket — где обмен сообщениями идёт через message-oriented транспорт, или тупо наверчивают фрейминг а-ля "тут пишем 4 байта длины, потом JSON". Это всё каждый факин раз изобретается заново.

Передача низкоприоритетной телеметрии, это, в лучшем случае, UDP, в среднем — line separated TCP (тот же фрейминг, но не length-prefixed, а \n-separated), а в худшем — SNMP, который суть что? Правильно, TLV.

SMTP — это message oriented транспорт. Один заголовок SMTP-exchange (типа EHLO) или боди целиком — это отдельные сообщения. Сейчас парсинг их осуществляется иногда поиском завершителя строки \n, иногда — поиском пустой строки (\n\n), иногда — поиском точки на пустой строке. В одном и том же факин протоколе! Нет уж, дайте нам нативный message oriented transport, дальше уж мы сами накрутим поверх этого логику, надоело парсить в телах \n-ы.

> >хранить большие бинарные блобы произвольного содержания редко кому нужно.
>
> Утверждать что большие бинарные блобы произвольного содержания никому не нужны может только тот, кто шизофренически игнорирует реальность. Реалии таковы, что средний пользователь хранит именно мультимедийные данные большого и очень большого размера. Фотографии, видео, различные документы, как с текстовым, так и с произвольным содержимым.

Заметим, tonsky не утверждал, что блобы произвольного содержания никому не нужны, какого хера это комментировать? Внимательно читаем выделенное жирным. Я с этим утверждением тоже не особо согласен, но зачем же комментировать голоса в собственной голове?

> >...с неудобным программным API и непрозрачная внутрь файлов (sed/awk чтобы поменять значение поля в конфиге? буээ).
>
> >Любое приложение почти всегда работает со структурированными данными, так зачем мучать котенка и каждого разработчика заставлять придумывать сериализатор и парсер конфигов и документов, когда это можно сделать на уровне системы.
>
> Следующая проблема, вытекающая из необходимости хранения мультимедийных данных - невозможность построения обобщенного API для доступа к их содержимому. Чтобы иметь возможность править что-либо внутри файла через предоставляемое файловой системой API, для каждого формата потребуется писать свой сериализатор и десериализатор. По факту это означает перенос существенной части кода из пространства приложения в пространство файловой подсистемы. И если плагины для работы с XML/JSON/BSON/CSV написать довольно просто, то чтобы полноценно работать со сложными документами типа Photoshop, фото или видео, придется реализовать весь функционал этих приложений внутри ФС. Это чревато ошибками и большими проблемами с безопасностью.

Тут я согласен с комментатором. Более того, такие системы были, тот же DEC VMS filesystem, в итоге разработчиков стошнило и они отложили это фпень.

> Очевидно также, что такие сложные вычисления с потреблением огромного количества памяти невозможно проводить в контексте ядра, а значит, это будет пользовательский процесс. В свою очередь это потребует большого количества переключений контекста исполнения из ядра и обратно. Что очень, очень медленно.

Не очевидно. Почему-то считается, что когда фантазируем про операционку, надо тащить за собой весь груз юниксового багажа, типа контекстов исполнения, etc. Во-первых, почему бы и не притащить это в ядро. Там какого только говна уже нет, типа "иерархических баз данных с транзакциями", и это можно впихнуть. Во-вторых, есть концепции ядерных архитектур типа L4 с их драматически более оптимальным способом переключать контекст. В-третьих, при выполнения множества ядрового кода в линуксах "переключения контекстов" (или того, что под этим подразумевается) и так не делается, ибо там делается гораздо более дешёвый mode switch.

> Ну допустим, мы реализовали подобную систему. Теперь главное: какой смысл в возможности доступа к свойствам хранимого документа из любого приложения, если для каждого типа документа, очевидно, будет свое API со своими специфическими вызовами, востребованное одним-единственным приложением?

Не надо этого, достаточно стандартных, встроенных в ОС/стандартную библиотеку/POSIX/whatnot фрейминга. Поверх этого можно любую проприетарщину городить уже.

Однако, исторический провал DEC VAX Files-11 говорит, что лучше таки площе, ибо концептуально проще.

> >Очевидно, современная ОС должна быть network-aware. Начиная от более толкового сетевого протокола (SCTP? ∅mq?), ориентированного на сообщения
>
> Еще раз. Сообщения мало кому нужны при передаче большого количества данных. Все эти докачки с произвольного места в протоколах FTP, HTTP и других придуманы именно для того, чтобы при потере связности на 90% передачи не повторять заново отправку сообщения в N гигабайт, а докачать только необходимое. Не говоря уже о протоколах распределенного обмена небольшими частями сообщения, например, торрентах.

Ещё раз. FTP имеет внутренний фрейминг (line-separated messages), HTTP имеет внутренний гипербредовый текстово-бинарный message framing, который одновременно и \n-separated, и "\n[␣\t]+"-unseparated, и length-separated, и connection-delimited. Да ёжкин же кот!

Именно этот фрейминг лучше отдать на уровень OS API.

> >а не на поток байт (поверх которого все равно все придумывают сообщения)
>
> Кто - все? Вообще, откуда эта категоричность? Всем якобы нужны сообщения, всем нужна гарантия доставки и т.п.

Да все, все. tonsky прав. Действительно, сложно сказать, кто не придумывает!

> >продолжая более соответствующими современной обстановке буферами (16Kb default TCP write buffer? SRSLY?)
>
> Да, SRSLY. Если сделать буфер большим, а еще лучше - нелимитируемым, это кончится тем, что сделать DDoS сервису не сможет только ленивый.

Игнорамусы оба, откуда 16kb взялось-то? Давно уже минимум на порядок больше, часто на два. Никита, ты RFC 793 прочитал только, и ни документом больше? Андрей, ты просто защищаешь предполагаемый статус кво по инерции, из принципа, очевидно не отдавая себе отчёта, что на самом деле там всё гораздо иначе. Чума!

Всё нормально с буферами у TCP, на практике сейчас в них ничего почти никогда не упирается. В протоколы error recovery — упирается. Но не в буфера или их недостаточный размер.

> >и минимальными возможностями роутинга (message broker вполне хорошо бы смотрелся в качестве системного компонента, и востребованность ∅mq это подтверждает), заканчивая cluster awareness.
>
> Роутинг в качестве системного компонента каждого сервера заставит хранить огромную карту маршрутов. Это ресурсоемко и крайне небезопасно.

Чуваки говорят каждый сам с собой здесь, и сложно сказать, что имелось ввиду в обоих случаях.

> >Было бы круто, если бы я мог системными средствами видеть, где, кто и сколько машин вокруг, как-то разумно распределять по ним запросы, следить за их доступностью, броадкастить и общаться между ними.
>
> Вообще говоря, любой, кто читал учебник по стеку TCP/IP умеет посредством использования системного API видеть, сколько машин вокруг, следить за их доступностью, броадкастить их и общаться между ними.

В какой-то степени это так. Broadcast datagrams или даже RAW sockets с одного конца, rpc(3) — с другого. Только речь о том, что это некомфортно низкий уровень. Иначе ZeroConf бы не существовал, например. И даже он слишком низкий. Какой именно уровень нужен: одним, например, API-коллом зарегистрировать себя, свои капабилити, и коллбек, а с другой тачки тоже одним же коллом послать в любую тачку в локальной сети, которая имеет такой-то капабилити, JSON, и получить ответ.

Нет такого. Очень много программить надо, и, если оно даже сверху rpc(3), оно реализовано "на отцепись" и неэффективно для больших нагрузок.

> >Далее, модель процессов. Она построена вокруг предполагаемой интерактивности: stdin, stdout, string arguments, return value, это всё для работы в sh придумано.
>
> Ну, кроме этого есть и процессы, лишенные управляющего терминала, man setsid.

Опять, подозреваю, каждый о своём тут. Сложно комментировать.

> >То что каждый процесс может максимум что вернуть 1 целое число проходит по категории тяжелого детства и деревянных игрушек. Может показаться что это круто и как раз и принесло UNIX модели бешеную популярность, но на деле это заставляет каждый процесс городить парсер на входе и сериализатор на выходе.
>
> Ничто не мешает использовать другие методы межпроцессного взаимодействия. Если автор не в курсе, могу напомнить о существовании каналов, доступа к разделяемой памяти, отображении файла в память, работе через inet/unix socket, системных очередях сообщений, семафорах и многом другом.

Да, именно так, есть некоторое количество средств.

С другой стороны, как только уходим от файлов и пайпов, shell перестаёт быть помощником, и мы получаем закрытую систему, которую не проинтроспектируешь mmap или семафор из шелла?..

> >Программа принимает на вход путь до файла. Зачем? Почему не содержимое файла?
>
> Видимо, автор не знает о существовании pipes. Это печально.

Опять каждый о своём. Речь о application programming paradigm, где ты в argv[], скажем, получаешь структурированный блоб, например, а не char * до файла.

Впрочем, чтобы такое было удобным, надо достаточно развесистый API делать (иногда аргумент это просто аргумент, то есть, строка), и в итоге будет всё сосать. Как сейчас ОК.

> >Если я хочу состыковать ее с другой программой, мне придется научить их разговаривать через файл. Спрашивать на stdout вопрос, а на stdin ждать ответа (привет, ssh)?
>
> По сути своей, это ничем не отличается от работы с так любимой автором 0mq. Там те же самые вызовы read/write/poll.

Очень даже отличается, ибо 1) message oriented, 2) асинхронные запросы можно посылать.

> >Это низ composability, ниже некуда. Ориентированность на использование в sh рождает целую кучу бредовых паттернов (как вернуть из процесса строку, например?), о которых в обычных PL никогда не слышали.
>
> Куда конкретно требуется вернуть строку? В зависимости от конкретных условий есть множество вариантов. Суть *nix в том, что нет одного единственно правильного метода взаимодействия, всегда можно выбрать наиболее оптимальное решение.

Мне тоже нравится unix programming model, она показала свою жизнеспособность.

> >Есть целая индустрия command-line arg parsers, считаете это хороший знак? Понятно, что программа на Java не передаст программе на Perl в качестве return value свой объект, но вот json может, и это будет куда лучше хрен-пойми-как-tab-space-and-comma-delimited вывода какой-нибудь утилиты типа ls, который еще и на stdout уйдет. Как это могло бы работать: TermKit и мой пост про смерть терминала.
>
> Так и сейчас программа на java может передать json программе на Perl. Не совсем понятна суть претензии.

Именно. Проблема формулируется так: давайте уже наконец сделаем универсальный формат данных и во все языки вставим поддержку оного.

Придумали.

Восхитились.

Заиспользовали.

Протошнило, стало легче. В итоге, от XML сейчас рожки да ножки. А теперь JSON на коне. Всё это время flat array of bytes продолжал рулить и бибикать, поддерживая любой очередной конъюнктурный форматный бред.

Кстати, в JSON нельзя передать просто тупо набор байтов, у него нет этого в модели данных. Приходится или конвертировать в base64, или эскейпить, а потом out of band передавать информацию о том, как оно там лежит, другим программистам. В MessagePack нельзя передать строку, только последовательность байтов.

> >Можно еще больше расфантазироваться, предложить делать каждый запускаемый процесс network addressable и приделать к нему mailbox (место, куда кто угодно может положить сообщение, а процесс прочитать).
>
> Нельзя давать возможность писать кому угодно куда угодно. Рано или поздно это кончится DDoS или утечкой критически важных данных. Чтобы все это работало, необходимо разработать службы авторизации и аутентификации, а к ним - систему мандатного доступа. Кроме того, необходимы ACL, отсекающие доступ без каких-либо сложных проверок (например - только по маске сети).

Да, это так. Но никто не запрещает это всё разработать, вопрос о первой линии удобства пользования системой, а не о том, какие там свитчи надо выставить один раз в stdlib, чтобы это всё завелось для большинства стандартных сценариев.

> >Модель украдена у Эрленга, но так ведь не зря — только Эрленгу пока и удается делать массивные кластерные приложения разумным количеством усилий.
>
> Опять голословное утверждение. Ну вот почтовый сервис на 1.5 петабайта данных с несколькими сотнями нод в кластере - это массивное кластерное приложение или нет? Исходя из своей практики, межпроцессное взаимодействие - самая простая часть задачи. Гораздо затратнее написать быстрый и качественный парзер того же MIME.

Как ни странно, message-oriented транспорт и соответствующий стандартный структурированный формат данных помог бы с этой задачей. Нахрена парсить MIME? Потому что тупо его писали слой за слоем поверх text-oriented протоколов, в которых концепции messages не было. tonsky как раз за то, чтобы эту концепцию первазивно внедрить, и перестать хернёй маяться, наконец. HTTP 2.0 добавляет её поверх HTTP 1.x, кстати.

> >Интеграция чего угодно с чем угодно внезапно становится тривиальной вещью.
>
> Интеграция чего угодно с чем угодно и сейчас тривиальна, см про средства IPC.

О да, конечно.

> >Логично, если бы в ОС была встроенная time series database в которую логировалось бы всё происходящее внутри этой же системы и можно было бы прямо зайдя на http://host:17801/ посмотреть на графики.
>
> Сейчас любой может зайти по ssh на хост и посмотреть все необходимые метрики. Ну да, при этом надо сделать запрос не вид "GET /... HTTP/X.X", а "ps -axw" или "sockstat -4", но суть от этого не меняется никак.

Это уже application/userland level, это неинтересно.

> >С интерактивностью у меня вообще давние счеты. Мне кажется правильным строго забанить ходить по ssh на сервера, потому что куча бед и усилий у людей тратится на то, чтобы сделать себе удобный dev environment на удаленном сервере. Чувак, ты что там забыл, сервером надо управлять с пульта, а не сидеть на нём, настраивая тему в vim-е. Запускать процессы, инспектировать ФС (SELECT) и редактировать конфиги (UPDATE по БД), мониторить метрики можно по сети. Заметьте, что все перечисленные вверху средства network friendly. Плюсом будет огромное количество сэкономленных усилий, когда станет понятно, что sh-like интерактивность большинству программ не очень-то и нужна.
>
> Ну так и пульт должен как-то ходить на сервер и делать все те вещи что делаются через ssh. Канал связи должен быть защищенным. В итоге получится тот же ssh, но с другими именами команд. Мне, если честно, непонятно, какой смысл менять одно на другое.

Мне тоже непонятно, ssh ok. Плюс керберос или LDAP.

<бессмысленный обмен репликами поскипан>
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 87 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →