?

Log in

No account? Create an account

Previous Entry | Next Entry

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

<бессмысленный обмен репликами поскипан>

Comments

( 87 comments — Leave a comment )
Page 1 of 2
<<[1] [2] >>
archaicos
Jun. 5th, 2014 05:33 am (UTC)
Что-то плохо читается, т.к. не ясно кто говорит что, вроде как аж трое аффтаров?
lionet
Jun. 5th, 2014 05:49 am (UTC)
Никита красный, Андрей серозелёный, я — остальной.

Edited at 2014-06-05 06:22 am (UTC)
(no subject) - archaicos - Jun. 5th, 2014 07:32 am (UTC) - Expand
vitus_wagner
Jun. 5th, 2014 05:38 am (UTC)
Всё нормально с буферами у TCP?

До чего ж задрало, что, когда ты копируешь по scp фотку с телефона на сервер, оно мгновенно улетает до якобы 100% а потом несколько минут ждет в состоянии 100%. С 16Кб буферами лучше было бы.
lionet
Jun. 5th, 2014 06:13 am (UTC)
Ты говоришь о противоположной проблеме — слишком больших буферах. Я отвечал именно в контексте недостаточного размера буферов.

Твоя же проблема несколько облегчается через sftp (32k по дефолту, но можно -B 1634). Пойдёт для краевых случаев. Можешь себе LD_PRELOAD-либу соорудить, которая оверрайдит socket(2) и ставит setsockopt(SO_SNDBUF) в нужное число.
(no subject) - vitus_wagner - Jun. 5th, 2014 08:08 am (UTC) - Expand
(no subject) - cdesz - Jun. 5th, 2014 08:26 am (UTC) - Expand
(no subject) - _slw - Jun. 5th, 2014 08:37 am (UTC) - Expand
(no subject) - cdesz - Jun. 5th, 2014 09:49 am (UTC) - Expand
(no subject) - vitus_wagner - Jun. 5th, 2014 01:38 pm (UTC) - Expand
blackyblack
Jun. 5th, 2014 05:41 am (UTC)
Вот это вот всё - это реально нужно тащить на уровень ОС? Может оставим это всё на откуп application level да и дело с концом.
lionet
Jun. 5th, 2014 06:14 am (UTC)
> Может оставим это всё на откуп application level

Не возражаю :)
(no subject) - blackyblack - Jun. 5th, 2014 06:27 am (UTC) - Expand
(no subject) - nponeccop - Jun. 5th, 2014 06:44 am (UTC) - Expand
nponeccop
Jun. 5th, 2014 06:39 am (UTC)
Исходные аргументы валидные, а обоснования со всех трёх сторон - бред. Я ничего не понял.

Мое понимание:

1) POSIX API (FS, сокеты) низкоуровневый и нинужен. Попытки улучшить делают и много: в линуксе это fs journaling во всех ипостасях, в винде - Volume Shadow Copy, USN Journal и сделанная на их основе Transactional NTFS. Про то, что есть несоответствие возможностей между низкоуровневым протоколом (SCSI packets) и API, я писал.

2) TCP низкоуровневый и нинужен. Много претензий: фрейминг, порядок, мультиплексирование, шифрование, обработка ошибок.

3) Нормальные ASN и http://en.wikipedia.org/wiki/COM_Structured_Storage нужны. Впрочем, при прошлых попытках всех стошнило. В результате чего МС перешел на XML в зипе, а например ССШ придумали свой формат сертификатов вместо традиционного.

4) На секьюрити все кладут. Учитывая масштабы, хорошо бы сначала добиться того, чтобы все уважали FHS и аналоги. А MAC - это дело далекого будущего. Всё есть, но никто не пользуется, аналогично тому, что под виндой сидели под админом.

5) Context switches это ерунда, есть более важные проблемы. Например, отсутствие сборщика мусора. Я считаю сборку мусора злом, но пока безопасной памяти без сборки не придумали, перенос сборки на системный уровень по идее сократит накладные расходы.

6) Средства IPC ужасны своей низкоуровневостью. Даже MPI, о ручном закате солнца я не говорю.

7) Стандартнизация централизованного репортинга и конфигурации не помешала бы. SNMP это смешно, но движение в сторону DMTF CIM/WBEM есть. В идеале - что-то вроде стандартных Theforeman smart-proxies и паппета.

8) Шелл как способ configuration management ужасен. См. пункт 7 - standard-based centralized configuration management позволит отказаться от администрирования посредством интерактивного шелла. Сам шелл и ссш как способ получить удаленный шелл останутся, разве что можно протокол передизайнить на использование стандартных фрейминга, мультиплексирования и т п.

b00ter
Jun. 5th, 2014 07:12 am (UTC)
Непонятно, что в итоге.
Ну да, мессажинга на уровне ОС не хватает, есть такое.
Ну да, в прикладном аспекте разброд и шатание, и каждый суслик - агроном.
И что со всем этим делать? Ну акромя того, что надо мигрировать в сторону Erlang on Xen и подобного.
dk379
Jun. 5th, 2014 07:33 am (UTC)
Сейчас вы plan9 придумаете.
lionet
Jun. 5th, 2014 07:40 am (UTC)
Я менеджер, я нихочу ничего решать, я хочу теслу и айпад!
(no subject) - vitus_wagner - Jun. 5th, 2014 08:10 am (UTC) - Expand
(no subject) - tim_caper - Jun. 5th, 2014 09:24 am (UTC) - Expand
sleepy_drago
Jun. 5th, 2014 08:09 am (UTC)
хоть я не знаю всех троих =) мне в режиме угадай мелодию видно что тов. tonsky нужен нормальный интернет вещей, а не 5 разных админов в 3х разных облаках (1 из яблочников, 1 из амазона, 2 индуса из мс и еще ктото по кофеваркам/холодильникам) ... Предлагать ему сопрягать закрытые системы (плейстейшн - телефон - телевизор - планшет - ноутбук) с помощью посикс апи ... ну вы представьте себе.

если в процессе больше не понадобятся сервисы парсящие аж один mime протокол я лично даже не замечу =)
blackyblack
Jun. 5th, 2014 08:14 am (UTC)
Дак для того, чтобы закрытые системы сопрягать, достаточно какого-нибудь json'а, а не линукс курочить. А ещё лучше не json, а in-band протокол.
permea_kra
Jun. 5th, 2014 08:14 am (UTC)
ИМХО, реляционную транзакционную СУБД давно пора воткнуть таки в ОС. Понятное дело, не в ядро. Транзакционная ФС тоже не помешала бы, но там свои заморочки и простыми средствами этого, похоже, не сделать. Сделать message-ориентированные пайпы/сокеты/message queue на уровне шелла. Типизация в шелле тоже не помешала бы, но грамотно её можно сделать только в языке типа хаскеля или более сильном, а это очень не все осилят. Консольные утилиты для хождения по древовидным данным есть, хоть и на переусложненном xml и json, адаптировать их можно. Очень не помешал бы более внятно расширяемый шелл - сейчас там все на IPC, а это все-таки, медленно, было бы неплохо что-то на с использованием dll - но это фантастически сложно грамотно сделать, не потеряв в security.

За попытку устранить многоюзерскость надо бить по шапке, безусловно. Как и ограничить возможность ходить куда надо.

Это я как advanced user говорю.

Edited at 2014-06-05 08:15 am (UTC)
lionet
Jun. 5th, 2014 08:21 am (UTC)
> ИМХО, реляционную транзакционную СУБД давно пора воткнуть таки в ОС.

Btw, sqlite очень похожа на правду. И везде есть, по сути.
(no subject) - thesz - Jun. 5th, 2014 10:34 am (UTC) - Expand
(no subject) - lionet - Jun. 5th, 2014 10:51 am (UTC) - Expand
(no subject) - thesz - Jun. 5th, 2014 11:50 am (UTC) - Expand
(no subject) - wizzard0 - Dec. 4th, 2014 10:26 am (UTC) - Expand
(no subject) - aptakhin - Jun. 6th, 2014 07:55 am (UTC) - Expand
(no subject) - dottedmag - Jun. 5th, 2014 01:01 pm (UTC) - Expand
(no subject) - permea_kra - Jun. 5th, 2014 01:23 pm (UTC) - Expand
(no subject) - dottedmag - Jun. 5th, 2014 02:07 pm (UTC) - Expand
(no subject) - permea_kra - Jun. 5th, 2014 02:12 pm (UTC) - Expand
(no subject) - ftrvx - Jun. 5th, 2014 02:16 pm (UTC) - Expand
(no subject) - permea_kra - Jun. 5th, 2014 02:28 pm (UTC) - Expand
(no subject) - archaicos - Jun. 5th, 2014 02:43 pm (UTC) - Expand
(no subject) - permea_kra - Jun. 5th, 2014 04:45 pm (UTC) - Expand
(no subject) - archaicos - Jun. 5th, 2014 04:48 pm (UTC) - Expand
(no subject) - permea_kra - Jun. 5th, 2014 04:53 pm (UTC) - Expand
(no subject) - archaicos - Jun. 5th, 2014 04:56 pm (UTC) - Expand
(no subject) - permea_kra - Jun. 5th, 2014 05:00 pm (UTC) - Expand
(no subject) - archaicos - Jun. 5th, 2014 05:03 pm (UTC) - Expand
tzirechnoy
Jun. 5th, 2014 09:19 am (UTC)
Приятно, конечно, услышать обсуждение этой темы от вменяемого человека (тебя). Но всё-таки: http://lurkmore.so/images/e/e1/Arguing.retarded.jpg
jakobz
Jun. 5th, 2014 09:23 am (UTC)
Типа Сталин такой выходит из могилы, объявляет один формат сериализации единственно верным, остальные существующие объявляет несоответствующими идеям марксизма-ленинизма, а за изобретение новых - отправляет в ГУЛАГ :)

jakobz
Jun. 5th, 2014 09:27 am (UTC)
Ну и вообще ребята хотят "всё в одном", что неверно. Веб-серверу вон надо драйвер сетевухи, библиотеку с TCP/IP стеком, 2 гига плоской памяти и всё. А крутится он по факту - на карусели с лампочками, тиграми, вторым этажом, и лавками для родителей.

Короче надо наоборот разлеплять это всё. И если стандартизировать ту же сериализацию или пайпы - то уж точно заниматься этим вне контекста ОС.
(no subject) - tzirechnoy - Jun. 5th, 2014 10:59 am (UTC) - Expand
maxim
Jun. 5th, 2014 09:32 am (UTC)
Чо-то непонятно. Каждый хуйовый коментарий на заявление Тонского прокомментирован.
А кто виноват, и что делать не написано :-)
lionet
Jun. 5th, 2014 09:43 am (UTC)
Надо неустанно продолжать создавать максимальную ценность для пользователей, даже если приходится закрывать глаза на некоторое количество костылей в реализации или в низлежащей платформе.
(no subject) - maxim - Jun. 5th, 2014 09:46 am (UTC) - Expand
(no subject) - dottedmag - Jun. 5th, 2014 01:06 pm (UTC) - Expand
(no subject) - tonsky - Jun. 6th, 2014 10:52 am (UTC) - Expand
(no subject) - dottedmag - Jun. 6th, 2014 11:19 am (UTC) - Expand
sermp
Jun. 5th, 2014 10:15 am (UTC)
Внесу свои пять копеек.
>>Опять каждый о своём. Речь о application programming paradigm, где ты в argv[], скажем, получаешь структурированный блоб, например, а не char * до файла.

Если хочется принимать на вход блоб, то можно просто читать из stdin и работать с программой так: cat file | my_super_bin
Именно об этом и говорил slonik_v_domene, когда упоминал пайпы.

Edited at 2014-06-05 10:16 am (UTC)
lionet
Jun. 5th, 2014 10:23 am (UTC)
А теперь давай посмотрим, как в my_super_bin принимать данные из файлов и из пайпа. Почему запрограммировать это получается отчётливо разный код? И почему обработать два файла, потом stdin, потом ещё три файла — отдельный геморройчик?
(no subject) - nponeccop - Jun. 5th, 2014 10:35 am (UTC) - Expand
(no subject) - lionet - Jun. 5th, 2014 10:55 am (UTC) - Expand
(no subject) - nponeccop - Jun. 5th, 2014 06:48 pm (UTC) - Expand
(no subject) - ftrvx - Jun. 5th, 2014 02:09 pm (UTC) - Expand
(no subject) - lionet - Jun. 5th, 2014 05:16 pm (UTC) - Expand
(no subject) - ftrvx - Jun. 5th, 2014 08:02 pm (UTC) - Expand
ufm
Jun. 5th, 2014 11:32 am (UTC)
Я думаю, мы просто сейчас наблюдаем очередную смену парадигмы в IT, совмещенный с попыткой "оставить совместимость с легаси кодом" - от этого весь этот разброд, шатание и монстры, типа веб-браузеров, которые, по сути, уже давно выполняют функционал X сервера, только через жопу.
alexander_mikh
Jun. 5th, 2014 12:18 pm (UTC)
"шатание и монстры, типа веб-браузеров, которые, по сути, уже давно выполняют функционал X сервера, только через жопу."
Классный комментарий.
(no subject) - ufm - Jun. 5th, 2014 01:08 pm (UTC) - Expand
(no subject) - alexander_mikh - Jun. 5th, 2014 01:17 pm (UTC) - Expand
qehgt
Jun. 5th, 2014 11:55 am (UTC)
Хм... В MsgPack строки передаются в UTF-8, собственно, это массив байтов и есть. Или жалоба в том, что нельзя отличить передачу строки от передачи массива?
lionet
Jun. 5th, 2014 05:14 pm (UTC)
> Хм... В MsgPack строки передаются в UTF-8

Ага, щаз. Нет строк в MsgPack, только рекомендация "если хотите строку — пихните UTF-8, что-ли. но от блоба со свопом Windows NT это отличаться не будет".

"String objects may contain invalid byte sequence and the behavior of a deserializer depends on the actual implementation"

Также см. https://github.com/msgpack/msgpack/issues/121
_winnie
Jun. 5th, 2014 12:12 pm (UTC)
Два файла надо перезаписывать так же, как двигают гору Фудзи.

Надо записать два файла куда угодно, записать path до них в paths.txt.tmp, а затем сделать атомарный rename файла paths.txt.tmp в paths.txt

Читающее файлы приложение - пусть лезет в paths.txt и достаёт оттуда имена файлов.

Возможно, можно делать rename на директорию, но у меня не получилось (почему-то падает с ошибкой "директория уже существует").

Edited at 2014-06-05 12:26 pm (UTC)
vitus_wagner
Jun. 5th, 2014 01:18 pm (UTC)
Атоммарный ренейм на директорию не получится.

Поэтому когда я развлекался с этим делом, я делал на хардлинках (файлов в директорию(

Это, конечно, тоже не атоммарно, но вероятность того что пользователь увидит неконсистентное состояние, достаточно мала.
(no subject) - _winnie - Jun. 5th, 2014 02:05 pm (UTC) - Expand
(no subject) - lionet - Jun. 5th, 2014 05:12 pm (UTC) - Expand
(no subject) - _winnie - Jun. 5th, 2014 07:32 pm (UTC) - Expand
(no subject) - lionet - Jun. 6th, 2014 05:45 am (UTC) - Expand
Page 1 of 2
<<[1] [2] >>
( 87 comments — Leave a comment )