You are viewing lionet

Tired of ads? Upgrade to paid account and never see ads again!
«Уважаемые коллеги!
  Ульяновский государственный технический университет приглашает Вас принять участие в Международной научно-практической конференции «Патриотизм: история, современность, образ будущего», 14 – 16 апреля 2015 г., г. Ульяновск.
К участию в конференции приглашаются студенты, научные сотрудники, аспиранты, докторанты, ведущие специалисты и крупные исследователи, ученые высших учебных заведений и научных учреждений.
  По результатам работы конференции будет издан сборник научных трудов. Публикация осуществляется за счет организатора.»


«Крупные исследователи»... цирк с конями!..

Так начинается письмо из родного политеха, в котором недавно со скандалом назначили нового и.о. ректора (ютьюб-кульмине́ц этого процесса доступен здесь: http://ulpressa.ru/2015/01/13/aleksandr-pinkov-o-svoem-novom-naznachenii-obrazovanii-i-planah-na-vuz/ (на другое видео кульминцá, которое с курицей, ссылку в приличном обществе ставить неприлично)).

Письмо я получил 27 марта (вчера, реально), а материалы нужно сдать к 31 марта, то есть, меньше недели на подготовку. Темы такие:

Секция I. «Героизм советского народа в годы Великой Отечественной войны как один из главных источников Победы».
Секция II. «Война и мир в современных философских и политических интерпретациях».
Секция III. «Героические образы российской истории. Патриотическое воспитание: проблемы методологии и социальной практики. История малой Родины в системе патриотического воспитания».
Секция IV.«Советский интернационализм как фактор победы в Великой Отечественной войне».
Секция V.«Эффективность государственной экономики в годы Великой Отечественной войны».
Секция VI.«Духовно-нравственные и религиозные основания в осмыслении исторического прошлого и настоящего».
Секция VII. «Патриотизм в зеркале спортивных достижений».
Секция VIII. «Патриотизм на перекрестье современных информационных войн в СМИ и Интернете»


Сборник научных трудов будет включен в Российский индекс научного цитирования (РИНЦ).

Конференция, разумеется, международная. В программном комитете представитель Англии (sic!): «Котов-Дарти Сергей Фануэльевич – доктор экономических наук, доктор юридических наук, профессор, ректор-президент Академии образования Великобритании». Про эту «британскую академию», и про Сергея Котова-Дарти можно подробнее почитать здесь: http://inter-academy.ru/kotov_about.html

Я не могу считать это приглашение ничем, кроме проявления непрофессионализма (неделю на подготовку и отсылку материалов на конференцию!), дремучей, бессмысленной, недалёкой конъюнктурщины, и подлизывания вертикали власти. Подобное отношение к системе высшего образования, когда вуз заставляют проводить совершенно дикие «конференции», а преподавателей на полном серьёзе изображать международность этого балагана, это отчётливый маркер возвращения в поздний советский союз, причём отнюдь не в позитивном понимании этого периода.

Я спросил организаторов, что так мало времени на подготовку? Ответа пока не услышал.

Прошу считать этот пост материалом к VIII секции данной международной конференции.
Что-то я не понимаю эти вот страдания по поводу того, что покрытие кода не 100%. Ну допустим ваша тулза показывает 100%. Что это значит, можно конюшни больше не чистить? А вот и нет:

int f(int a, int b) {
  int arr[2] = { 0, 0 };
  int i = 1;

  if(a == 1) i--;

  if(b == 1) i--;

  return arr[i];
}

И что это вам дало? Покрытие по строчкам 100%, а всё падает.

По опыту, у 84% программистов какой-то blind spot, не позволяющий ощутить масштаб проблемы.

Чувствую себя капитаном, пиша этот пост. Но он нужен.
Наверняка ничего от этого не изменится, но хочу зафиксировать свою позицию по этому вопросу. Опасной информации не бывает. Бывают опасные действия. Чтобы информация не превращалась в опасные действия, надо воспитывать и давать людям (детям, в частности) как можно боле полную картину мира. Надо не сжигать книги, а порождать новые книги, новые знания. Моя позиция — за отмену ограничений на информацию.

Государство и общество предполагает, что существуют какие-то деструктивные действия (или прекурсоры деструктивных действий), которые-таки надо запрещать. Например, разжигание межнациональной розни. Это уже на границе между информацией как созданием картины мира и действием, которое может напрямую деструктивно влиять на общество. Кто-то вышел на площадь, проорал что-то, и на следующий день кто-то другой убил еврея, украинца или татарина. У государства всегда был механизм борьбы с этим явлением. Называется, «суд над виноватым». Не над информацией, а именно над тем, кто совершает предусмотренное преступление. То есть, вывешена страничка «бей кавказцев» — пусть прокуратура займётся, найдёт человека, организующего межнациональную рознь, вынесет решение, которое человека наказывает и предписывает страницу закрыть. Вывешена детская порнография — то же самое.

Социальная динамика противоправной деятельности

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

Экономическая перспектива

Задачей государства можно считать (цинично так) повышение благосостояния граждан. А раз так, то можно смотреть на все эти списки, законы, запреты, как силовой эквивалент экономической стимуляции населения. Борьба с наркотиками потенциально высвобождает занятое в процессе их потребления население для общественно полезного труда. Борьба с межнациональной рознью предотвращает материальный ущерб от деструктивных действий. И так далее. В связи с этим становится возможным измерять эффективность запретов в деньгах. В США известна средняя «стоимость человека»: жизнь человека примерно эквивалентна $129 тысячам в год, то есть $5–6 миллионам. Иначе говоря, один подростковый суицид примерно эквивалентен для государства и общества пяти миллионам долларов недополученной прибыли. В России несколько пониже, наверняка. Так вот, если предположить, что от одной странички на гитхабе, вероятно, скончалось ноль целых и ноль десятых подростков, а десятки тысяч человек программистов сегодня затратили день на создание VPN-туннелей в небо (примерно $4mln, я сделал оценку), ценность вчерашнего решения по запрету страницы на гитхабе получается отрицательная. Иначе говоря, этим запретом мы нанесли государству экономический ущерб больший, чем самоубившийся подросток. Который бы где-то в ином месте нашёл, как удавиться. Например, взялся бы за ум и прочёл бы Анну Каренину. И так каждый раз: каждая блокировка гитхаба или подобного ресурса — и несколько миллионов долларов уходит в песок. Ей-богу, лучше бы в горячую линию поддержки суицидников вложили, а не в эти блокировки.

Глобальная перспектива

Россия не может бесконечно вариться в своём киселе в отношении информации, которая гуляет в интернете. Потому что то, что запрещено в России, может быть совершенно не запрещено где-то ещё. Например, в России запрещён Майн Кампф, а в США — нет. Космонавт Алексей Леонов, углядев Майн Кампф в личной библиотеке американского астронавта Дэвида Скотта, был немилосердно удивлён этим. Но затем понял, что к чему и выражал мнение, что образованный человек должен уметь обращаться с любой литературой, а не только с разрешённой. Так вот, пока в России запрещают какой-то детский сад типа официальной рекламы австралийского Метро, она всегда будет выглядеть так же прогрессивно, как Иран, который назначает смертную казнь за выражение недовольства на фейсбуке. Встаёт задача гармонизировать представление о том, что такое действительно запрещённая информация, а что — локальная конъюнктурщина прямиком из семнадцатого века. Можно было бы в рамках ООН обсудить и договориться о каких-то общих вещах, которые могут являться универсально запрещёнными везде. Я думаю, таких будет не очень много: на ум пока приходит только детская порнография.

Правоприменение в России

У меня не вызывает сомнения, что причинами создания механизмов предотвращения противоправных действий через фильтрацию роскомнадзорскими списками, являются:
* Получение политических очков структурой ЛБИ и, возможно, финансовой поддержки государством;
* Создание механизма быстрого автоматического покрытия цензурой политически неугодных материалов.
Последнее может пригодиться при росте недовольства населения — и вот там будет уже не до решения суда. Это будет чистая антиконституционная цензура, а потом иди доказывай, что интернетный запрет на твой невинный манифест был неправомерен. То есть, сам предложенный и внедрённый механизм совершенно не защищён от злоупотреблений властью: чрезвычайно слабые (никакие?) механизмы контроля над тем, что попадает в списки, и совершенное отсутствие оперативной возможности этот контроль осуществить. Я считаю, что это самое неправильное в том, как фильтрация сейчас организована.

В целом я призываю к отмене фильтрации роскомнадзором или существенному, глубокому изменению того, как осуществляется контроль над этими списками.

Keyless SSL™ (shameless plug)

CloudFlare анонсировал, что теперь можно не раздавать сертификаты точкам, которые терминируют SSL трафик.

[1] http://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudflare-without-having-to-turn-over-your-private-ssl-keys/
[2] https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

И это на самом деле здорово. Только они так говорят, как будто это инжениринговый прорыв нереальный.

В начале двухтысячных у нас в Netli (продались Akamai) появилось желание терминировать SSL, причём, чтобы наши датацентры, стоящие в Китае, Бразилии, России и ещё чёрт-те где, не имели бы приватного SSL-сертификата. Потому что несекьюрно и может утечь. Среди наших клиентов были такие компании, как Dell (dell.com), HP (hp.com), и сертификаты этих сайтов было бы очень грустно утратить в процессе обработки их на этих разнесённых датацентрах.

В районе 2003-2004 я имплементировал этот процесс в виде расширения OpenSSL (добавил туда fibers, чтобы можно было асинхронизировать запросы; изначально в OpenSSL этот процесс синхронен), и набора софта "keyserver", при котором бы ключи хранились на центральных машинах в штатах, а на краевых машинах, в левых датацентрах, терминация SSL приводила бы к асинхронному запросу на генерацию pre-master ключа. На централизованных keyservers ключи на диске хранились в зашифрованном блобе, а ключ от блоба хранился в HSM (от nCipher) в центральном сервере, и передавался кейсерверам только временно.

Процесс мы не запатентовали, потому что наши предыдущие патенты, связанные с простыми инженерными шнягами, шли туговато. Например, моя глупая аппликация US20060098645 так и не прошла.

С тех пор эта же технология безключевого SSL светилась несколько раз в разных патентных аппликациях:

http://www.google.com/patents/US20070074282 (Certeon)
http://www.google.com/patents/US20130156189 (Akamai) — это выглядит ровно как описание моей работы — ну да не мудрено, потому что Akamai купил Netli целиком вместе с её кодом и клиентами, использовавшими безключевую терминацию SSL.

Но эти апликации не прошли. А вот более поздняя апликация от CloudFlare — прошла, и превратилась в патент:

https://www.google.com/patents/US8782774 (CloudFlare)

Вывод? Молодцы, я рад за них ;) Только патент у них non-enforceable, потому что есть prior art, закреплённый в патентах от Certeon и Akamai.

Tags:

Originally posted by che_shr_cat at Как я прошёл 50 онлайн-курсов
Всё началось осенью 2011 с ai-class (ныне Udacity) — вводного курса про искусственный интеллект, про который я узнал из анонса в рассылке от IEEE Spectrum. Сразу было ясно, что это то что нужно и чего очень не хватало. Как, видимо, и остальным 160.000 человек. Когда параллельно запустились ещё несколько курсов, включая ml-class (ныне курс по машинному обучению на Coursera) и db-class, стало ещё интереснее. А когда по окончании всего этого было анонсировано ещё с десяток новых курсов, стало совсем замечательно.

С тех пор (осень 2011 — лето 2014) я прошёл более 50 курсов. Прошёл — это в смысле успешно окончил, с сертификатом (где их выдавали) или без него (где не выдавали, но финальные тесты я выполнил хорошо). Ещё с десяток курсов я брал, но забросил по разным причинам — скучно, плохой материал или организация, не то, что я ожидал, или просто не было времени.

Можно считать, что я создал себе персонализированную магистерскую программу, сконцентрировавшись на биологии, computer science и экономике с финансами и отобрав лучшие курсы из разных университетов мира.

Здесь я хочу поделиться опытом, который, возможно, поможет кому-то достичь его собственных целей. Расскажу, что помогает на этом пути и не помогает, и как, по возможности, более эффективно этот путь пройти, если есть такая цель (если цели нет, то это совсем другой вопрос, и мои мысли вам скорее всего помогут не сильно, но тем не менее я всё равно призываю взять и попробовать пройти один-другой-третий курс — аппетит приходит во время еды, здесь надо лишь распробовать).
moreCollapse )

Ульяновск форева!

Originally posted by miumau at Ульяновск форева!
Пост для тех, кто в Ульяновске (или кого этот город как-то касается): мы тут делаем серию чехлов для айфонов, про Москву и Питер. И решили сделать парочку про Ульяновск - просто потому, что мы уже совсем скоро туда едем (и теперь вдруг невероятно много про него интересного узнали :-))
Только мы никак понять не можем, сколько их нужно делать.

Если бы вы такой хотели, отпишитесь в комментариях! И напишите, какой у вас айфон!

Originally posted by kids at Новые европейские школы
1416
В Европе тоже строят новые школы. Я уже показывал лучшие российские примеры, теперь покажу шведскую школу "свободного воспитания". Особенность этой системы заключается в том, что дети занимаются не отдельными предметами, а решением конкретных учебных ситуаций, где требуются знания самого разного рода. Соответственно, делятся воспитанники не на классы, а на группы, исходя из их личностных особенностей, склонностей и объема базовых навыков. Не представляю, как это работает, но выглядит классно.

УДИВИТЕЛЬНЫЕ ФОТОГРАФИИCollapse )

miumau на ULCAMP'2014!

Яна Франк (http://www.miu-mau.org) приедет на ULCAMP'2014!

Originally posted by miumau at Ulcamp 2014
Дорогие друзья!
Я в конце июля приеду в Ульяновск, вот на эту очень пляжную ит-конференцию: Ulcamp 2014.
Я там буду рассказывать про организацию всего и вся. :-) Ну и вообще - общаться. Приезжайте, кому близко и интересно. И не забудьте зарегистрироваться, а то места кончаются.

Tags:

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

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