Что-то бред какой-то, что с
той, что с
другой стороны. Как автор имплементации 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.
<бессмысленный обмен репликами поскипан>