> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Это дело хорошее :)

> В данный момент реализовано всё, кромен фэх и нет вебморды
А нужна ли веб-морда в эталонной реализации ноды?

> Обсуждать готов, а вот писать пока не очень.
Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.
Так мы вообще никак не переусложним стандарт.

>> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Difrex> Это дело хорошее :)

Нужное как минимум =)

>> В данный момент реализовано всё, кромен фэх и нет вебморды
Difrex> А нужна ли веб-морда в эталонной реализации ноды?

В реализации ноды, может, и не нужна. А клиент хочу с вебмордой сделать. Это потребует меньше кода и усилий для создания удобоваримого интерфейса. А от морды клиента до морды узла один шаг =)

>> Обсуждать готов, а вот писать пока не очень.
Difrex> Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

Обязательно, но пока занят всякой фигнёй =(

>> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Difrex> Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.

Да. Всё верно =)

Difrex> Так мы вообще никак не переусложним стандарт.

При случае отпишу туда конь цепцию, которая сложилась в голове на эту тему.

В текущем обновлении для сабжа появилась одна очень интересная фича

Если вы не смотрели коммиты в репозитории, то для вас это будет небольшим сюрпризом

Что делать:

1. Обновите клиент
2. Зайдите в новостную эху (желательно ii://habra.rss )
3. Возьмите любое сообщение и прокрутите в конец
4. Нажмите на волшебную кнопочку

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Привет!

Это первое сообщение от G2I - бота слежения за задачами в репозитории на Github.
Сейчас я наблюдаю за проектом https://github.com/idec-net/netmail.

Новые события будут публиковаться в этой теме.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-13 08:43:24 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472330230

> Мне кажется, что идеологически правильно дать возможность пользователю тянуть свою личку с любой ноды

Именно. Но при этом надо не давать ноде читать нетмейл поинтов чужих нод. Чтобы пересылать можно было, а читать - нет. Поэтому какое-то подобие шифрования желательно

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-13 09:44:30 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472350243

Напишу бота `github<->idec`, чтобы транслировать стрим, а то не все подключились в обсуждение.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:56:50 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472035614

Я за то, чтобы по умолчанию работало без шифрования. Если так хочется шифровать личку, то можно использовать gpg в теле сообщения.
Нода уже может шифровать все у себя внутри.

Я как-то предлагал шифрование на основе публичных ключей нод, но меня не особо поддержали.

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

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:58:16 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472036264

Я за то, чтобы по умолчанию работало без шифрования. Если так хочется
шифровать личку, то можно использовать gpg в теле сообщения.
Нода уже может шифровать все у себя внутри.

Я как-то предлагал шифрование на основе публичных ключей нод, но меня не
особо поддержали.

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


+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:11:45 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472017154

По факту это самая сложная штука для проработки

Ведь нам надо сделать так, чтобы

1. Нетмейл-сообщения ходили между станциями
2. Станция не могла прочитать нетмейл чужих станций
2.1 Но при этом могла отдавать их даунлинкам

Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Client protocol draft" https://github.com/idec-net/netmail/pull/1.
Оставлен 2019-03-12 12:22:16 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/1#issuecomment-471977969

Как в текущем виде?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-16 13:47:14 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-473531586

> Напишу бота github<->idec, чтобы транслировать стрим, а то не все подключились в обсуждение.
Написал. Постит комменты с гитхаба в этот тред: https://dynamic.lessmore.pw/thread/3a6a0226-a22f-475a-82d1-81311e552b3a

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Хм. Не вижу никакой новой кнопки.
Смотри скрин в файлоэхе pictures

+++ картошки хватит на всех

Difrex> Хм. Не вижу никакой новой кнопки.
Difrex> Смотри скрин в файлоэхе pictures

Всё правильно, эта кнопочка на то и волшебная, что отображается не у всех =)

Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

>Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе
Ага, KDE Connect :).

А эта штука может работать вне кед?

>>Скинул в той же фэхе pictures, как оно сейчас выглядит на моём девайсе

Difrex> Ага, KDE Connect :)
Difrex> А эта штука может работать вне кед?

Конечно может. Я вот уже долгое время работаю в XFCE и этой штукой доволен.

А на нетбуке тоже KDE Connect работает, и там AwesomeWM

Всего лишь индикатор в трее висит и никому не мешает. Огромное количество полезных прибамбасов. Доволен и всем советую. Это действительно одна из тех уникальных и удобнейших вещей, за которую стоит похвалить кедерастов.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01>> Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.

Difrex> Сделаю страничку для роботов :)
Difrex> Еще есть в планах доливать раз в неделю данные в read-only индекс и прямо вставлять iframe из кибаны, чтобы все интерактивно было.

Спасибо, что сделал. Хорошая штука.

А я вот недавно начал пробовать Zabbix - для мониторинга числовых данных и доступности серверов очень даже красивенько и удобно показывает статистику. И, главное, выдаёт предупреждения, если что-то пошло не так.

Скриншот в фэхе pictures прилагается

Хочется найти ему какое-то более крутое применение, потому что инструмент мощный, но придумать пока не могу :)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Новый комментарий от пользователя Difrex
к задаче "Client protocol draft" https://github.com/idec-net/netmail/pull/1.
Оставлен 2019-03-16 19:28:35 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/1#issuecomment-473577352

Ну, что, мержим?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Сегодня буду обновлять основной хост динамика с Debian oldstable до stable.
Возможно все приляжет до завтра. Бэкапы льются на DO, так что все восстановимо будет, если что.
Так же буду переводить сеть между виртуалками с OpenVPN на Wireguard.

G2I> Ведь нам надо сделать так, чтобы
G2I> 1. Нетмейл-сообщения ходили между станциями

Это просто.

G2I> 2. Станция не могла прочитать нетмейл чужих станций

Почему? Если нужно шифрование, то оно должно быть на стороне клиента, а не на стороне ноды.

G2I> 2.1 Но при этом могла отдавать их даунлинкам

Это совсем просто.

G2I> Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?

Я не умею пользоваться гитхабом, так что напишу свои мысли тут.

1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
3. Шифрование не является частью протокола.

То есть выглядеть оно должно примерно так:

Поинт забирает почту: GET /x/m/<authstr>[/слайс].

Поинт отправляет почту: POST /x/m/ (параметры pauth и tmsg).

Нода забирает почту с аплинка: GET /x/n/<password>.

Этого уже достаточно для рабочей лички, в принципе.

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

За основу формата сообщений предлагаю взять существующий формат:

ii/ok[/reply/<msgid>]
<адрес получателя>
<время>
<имя отправителя>
<адрес отправителя>
<имя получателя>
<тема>

<тело сообщения>

И для отправки тоже:

<адрес получателя>
<имя получателя>
<тема>

[@repto:<msgid>]
<тело сообщения>

В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?

ЗЫЖ Я за любую движуху, но без излишнего усложнения протокола.

Посмотри пожалуйста https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api

если согласен, то давай межить этот ПР.

> В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?
Так я для того, чтобы и тут и там обсуждать можно было бота написал.

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


+++ At work. idec.el/0.1

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

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

AL> 1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
AL> 2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
AL> 3. Шифрование не является частью протокола.

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

Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

Это и правда упрощает реализацию, хотя и теряется гибкость.

Почему-то всегда думалось, что мы примем путь настоящей децентрализации (как в обычных эхах), чтобы пути хождения сообщений были заранее не регламентированы и можно было бы строить гораздо более нетривиальные схемы

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

Не надо каждому с каждым. Просто весь нетмейл ходит по всем узлам. То есть это такой подвид эхомейла, которым ноды обмениваются по паролю, а клиенты получают только свою часть от этой эхи.

Но это всего лишь мои мысли.

AL>>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01>> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

AL> Не надо каждому с каждым. Просто весь нетмейл ходит по всем узлам. То есть это такой подвид эхомейла, которым ноды обмениваются по паролю, а клиенты получают только свою часть от этой эхи.

Предположим, у нас есть 3 станции по такой схеме:

node1 ---- node2 ---- node3

node1 не соединена напрямую с node3
Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:

1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM

2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

На счёт протокола получения лички клиентом возражений нет? Мержим?

+++ картошки хватит на всех

vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM


vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

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

Можно обменяться ключами нод. Ну, шифровать ими личку с армором, тогда всё остаётся в plain text, но усложняет стандарт.
С другой стороны gpg есть ваще везде.

+++ картошки хватит на всех

Ура, у меня заработали уведомления о новой почте!

+++ картошки хватит на всех

vit01> Предположим, у нас есть 3 станции по такой схеме:
vit01> ====
vit01> node1 ---- node2 ---- node3
vit01> ====
vit01> node1 не соединена напрямую с node3
vit01> Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:
vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM
vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов
vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

Для этого есть PGP, например. Если уж параноишь в сети друзей, то делай это правильно. Шифрование на уровне стандарта это бессмысленное переусложнение. IDEC должен всего лишь носить почту, а остальное - не его забота.

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

Второй вариант неприемлемый, потому что или гарантировано усложняет топологию сети или делает нетмейл бесполезным.

Ёлы, всё уже сто лет как придумано. Передавать сообщения в скомпрометированных сетях можно безопасно уже очень-очень много лет, а народ всё ещё пихает шифрование куда ни поподя, усложняя стандарты.

Difrex> На счёт протокола получения лички клиентом возражений нет? Мержим?

У меня вообще возражений нет. Только соображения. Что ни примите, я или сделаю это у себя или забью.

Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?

Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?

Никаких соображений. Всё замечательно. Так я это себе и представлял =)

Я тут немного выпадаю из сети. Не теряйте. Рано или поздно я отвечу =)

AL> Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?
AL> Никаких соображений. Всё замечательно. Так я это себе и представлял =)
Ок. Я мержу тогда.

+++ At work. idec.el/0.1

Новый комментарий от пользователя Difrex
к задаче "Описание client API" https://github.com/idec-net/netmail/issues/4.
Оставлен 2019-04-03 07:08:09 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/4#issuecomment-479367180

Сделано в рамках #1

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

В books закинул отличную книгу. Сабж. Очень помогает мне разобраться в себе и переосмыслить свои поступки, их причины, на свою жизнь и мир вокруг меня.

Книга представляет собой историю одного бизнесмена, рассказанную от первого лица. Действия в книге не так много, но зато много рассуждений и идей, который вроде бы и лежат на поверхности, но я сам до них не додумался за 33 года жизни.

Рекомендую к прочтению всем. Даже тем, кто уже полностью доволен собой и своей жизнью.

2vit01: в книге нет религиозной составляющей =)

PS: Пока я её не дочитал, но прочтённая четверть уже начала вправлять мне мозги.

Смотрю в стандарт и думаю про сабж.

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

Здравый смысл подсказывает мне, что как минимум ":" стоит запретить, так как это может быть чревато боком.

У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
Что-то больше мне не хочется называться Anotheroneuser-ом :)

Anotheroneuser> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
Anotheroneuser> Что-то больше мне не хочется называться Anotheroneuser-ом :)

Лучше попросить своего сисопа переименовать тебя. Потому что ты здесь это не только ник, но и адрес =)

> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
> Что-то больше мне не хочется называться Anotheroneuser-ом :)

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

> Так что ничего страшного в том, чтоб новый акк сделать -- не вижу.
Спасибо. Сделаю новый: меньше хлопот

Короче, по-новой зарегистрируюсь.

>> У нас тут есть возможность сменить псевдоним? Или просто зарегистрироваться по-новой?
>> Что-то больше мне не хочется называться Anotheroneuser-ом :)
Peter> Могу попробовать просто заменить имя в конфиге. но если честно - я точно не помню, считается ли хеш по имени в тч или нет. Так что ничего страшного в том, чтоб новый акк сделать -- не вижу.

Хеш может быть любым.

> Хеш может быть любым.
Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало. Может быть, ты и прав, но проверить я сейчас не смогу.
В принципе, стоимость поддержки аккаунта нулевая, так что новый аккаунт это не страшно. )

>> Хеш может быть любым.
Peter> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало. Может быть, ты и прав, но проверить я сейчас не смогу.
Peter> В принципе, стоимость поддержки аккаунта нулевая, так что новый аккаунт это не страшно. )

Ну пока нет лички да =)

> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало
gk11.ru уже год, как лежит :(.

>> Я вроде ж там переписывал эту часть, чтоб с gk11 совпадало
> gk11.ru уже год, как лежит :(.

Это да... :(

Но сейчас свою ноду не могу поддерживать (в плане развития кода) в основном из за здоровья. Поэтому пока она в том состоянии, в котором есть.
В будущем, конечно, я бы хотел что то переосмыслить/дописать. Тот же нетмыл сделать, если когда он будет....

На днях обновил nginx, и клиент перестал пускать на станцию мира, хотя в браузерах всё хорошо работало.

Ошибка заключалась в обновлении протоколов SSL у nginx и в невозможности старого https-клиента netcipher (который в составе IDEC Mobile) с ним работать. Итого я прописал в клиенте свежую версию netcipher, и всё заработало

Просьба обновиться

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Прочитал книженцию полностью. Есть там годные и интересные мысли, однако под конец автор вообще всё запорол.

Особенно ту часть с доктором конспирологом-ВИЧ-диссидентом (приводящим совершенно идиотские аргументы), ну и потом многочисленные нападки на "извращуг" со стороны автора и форсирование "традиционных ценностей", от которых уже тошнить начинает.

Мне-то ещё ладно, но люди ведь всерьёз воспринимают. Ещё и поверят, небось.

А, и да, какие-то остаточные кусочки религиозного мировоззрения там всё-таки присутствуют в высказываниях персонажей.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

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

AL> Здравый смысл подсказывает мне, что как минимум ":" стоит запретить, так как это может быть чревато боком.

Уточнил в документации. Там сейчас требования похожие для таковых у файлэх (в текущей реализации). Если что, можно подправить стандарт и указать что-нибудь другое.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01> Прочитал книженцию полностью. Есть там годные и интересные мысли, однако под конец автор вообще всё запорол.
vit01> Особенно ту часть с доктором конспирологом-ВИЧ-диссидентом (приводящим совершенно идиотские аргументы), ну и потом многочисленные нападки на "извращуг" со стороны автора и форсирование "традиционных ценностей", от которых уже тошнить начинает.
vit01> Мне-то ещё ладно, но люди ведь всерьёз воспринимают. Ещё и поверят, небось.
vit01> А, и да, какие-то остаточные кусочки религиозного мировоззрения там всё-таки присутствуют в высказываниях персонажей.

На самом деле это что-то из разряда х/ф. "Yes man" же =)

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