>не вижу проблемы - это a. нода должна принимать входящих юзеров, как я понимаю - это b.

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

с другой стороны, роутеры и дешёвое железо - это тот самый сегмент, как мне кажется. p2p сеть не должна требовать больших ресурсов на один узел.

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

можете объяснить на пальцах в чём конкретно проблема? хеш, автор, дата, сабж, тело - это всё части сообщения, что мешает кроме хеша выдать ещё и дату? возможно я человек новый, но проблемы я не вижу. select id, date from msgs where date >= requested_date и выдать это в вывод.

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

>А вообще - вы фетчер, вам и карты в руки. Хоть метод биссектрисы применяйте :) Вы же сами выбираете, что фетчить, никто вам не указ.

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

>это обсуждали буквально вчера. и какой там формат, и какой способ БД может быть. к сожалению, обсуждали мимоходом и в im.1406, а не в dev. надо будет, наверное, это обсуждение перенести.

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

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

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

из-за того, что вы в это упёрлись возникают другие проблемы: надо мигрировать, выдаются все сообщения с начала времён, хоть их никто и не просил. а всё что надо чтобы этого избежать - ёбаная дата в utc+0. вместе со списком сообщений, либо уметь на входе распознать откуда запрашивают. например /m/ii.dev.14/1401767669, а реализация уже сама по базе сверится. /m/ii.dev.14/0 - сообщения с начала времён.

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

>эту работу могут делать компьютеры

ну сделайте

>да. я сегодня ещё буду объяснять, почему сложилоь так, а не иначе. только найду человека, который бы меня об этом спрашивал. :) в общем случае http://51t.ru/list.txt

ну объясните уже наконец один раз, напишите на какой-нибудь страничке в интернете. я новый человек в сети, откуда я его должен взять? скачать все сообщения в сети, потом grep | sort | uniq? а не скачивая все сообщения никак? ну пиздец.

в склайт это select id from echos и отдать поинту то, что есть у меня, такой же запрос можно сделать ко всем аплинкам, а они к своим аплинкам. получится p2p сеть в которой серией запросов можно собрать весть список эх и иногда обновлять. новые эхи будут постепенно расползаться по нодам.

> когда памяти всего 32 мегабайта, 5 мегбайт для ноды - это очень много, там не отлько нода, там ещё другой софт должен работать.

поэтому и предложен был вариант либо "поток zlib + поток заголовков" либо "поток zlib в sqlite, с нужными заголовками"

> можете объяснить на пальцах в чём конкретно проблема? хеш, автор, дата, сабж, тело - это всё части сообщения, что мешает кроме хеша выдать ещё и дату? возможно я человек новый, но проблемы я не вижу. select id, date from msgs where date >= requested_date и выдать это в вывод.

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

это - срандарт. вот чтобы и сохранять весь софт, включая бюльку на баше на две строки, совместимой со стандартом, чтобы всё всегда со всем работало, и чтобы по стандарту было легко писать - он и сделан таким. всё остально убрано. принцип "по эхам" нас устраивает. а трагедии даже в получени 5000 сообщений я не вижу, никаких особых сложностей там нет.

> /m/ii.dev.14/1401767669

это было в версии 0.2. если хотите, сделайте hg checkout на нужную ревизию, и пользуйтесь. по нашим принципам, архив эхи XX - это архив, где всегда есть полная копия сообщений из этой эхи.

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

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


> ну объясните уже наконец один раз, напишите на какой-нибудь страничке в интернете

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


> в склайт это select id from echos и отдать поинту то, что есть у меня, такой же запрос можно сделать ко всем аплинкам, а они к своим аплинкам. получится p2p сеть в которой серией запросов можно собрать весть список эх и иногда обновлять. новые эхи будут постепенно расползаться по нодам.

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

>поэтому и предложен был вариант либо "поток zlib + поток заголовков" либо "поток zlib в sqlite, с нужными заголовками"

это не так важно, попробую объяснить. если курл читает чанками и сразу ложит в файл, то не важно злиб там или не злиб. но чтобы только запустить интерпретатор питона понадобится 3-5 секунд, а он ещё что-то делать должен. скорее всего он выест 100% 400-х мегагерцового мипса который стоит на этом роутере, залезет в своп да юсб-диске со своим сраным сборщиком мусора. тащить надо всю сеть by design. это значит, что если трафик в сети будет значительным, то роутер будет работать 24/7 постоянно копируя всю сеть. значит скорее всего он ничего другого делать не будет.

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

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

вы вообще понимаете сложность сети? я имею ввиду вычислительную сложность. вы понимаете, что в таком случае сложность будет расти квадратично количеству участников, да? все отправляют сообщения всем, каждый должен получить копию каждого сообщения. для десяти участников это 100 попугаев, для 30 участников это 900 попугаев.

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

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

> это не так важно, попробую объяснить. если курл читает чанками и сразу ложит в файл, то не важно злиб там или не злиб. но чтобы только запустить интерпретатор питона понадобится 3-5 секунд, а он ещё что-то делать должен. скорее всего он выест 100% 400-х мегагерцового мипса который стоит на этом роутере, залезет в своп да юсб-диске со своим сраным сборщиком мусора. тащить надо всю сеть by design. это значит, что если трафик в сети будет значительным, то роутер будет работать 24/7 постоянно копируя всю сеть. значит скорее всего он ничего другого делать не будет.

zlib - для сжатия. для минимального места на диске.

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

откровенно говоря, если вам не нужны пойнты, то всё, что вам нужно, работает вот так, хоть на busybox:

for e in `cat subscribe.list`
do
wget http://51t.ru/e/$e -O echo/$e

for m in `cat echo/$e`
do
wget http://51t.ru/m/$m -O msg/$m
done

done

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

скажите, вы фидо вообще видели? если да, то к чему эти вопросы - все основные принципы такие же.


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

реализация ii меняться не будет, она уже доказала свою практичность, прежде всего - нам. возможно, будут другие, основанные на ii вещи, но самой ii это никогда не коснётся, она всегда будет такой же примитивной.

>zlib - для сжатия. для минимального места на диске.

zip не творит чудеса. место на диске всё равно ограничено.

>откровенно говоря, если вам не нужны пойнты, то всё, что вам нужно, работает вот так, хоть на busybox:

если мне не нужны поинты, значит я поинт

>скажите, вы фидо вообще видели? если да, то к чему эти вопросы - все основные принципы такие же.

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

>реализация ii меняться не будет, она уже доказала свою практичность, прежде всего - нам. возможно, будут другие, основанные на ii вещи, но самой ii это никогда не коснётся, она всегда будет такой же примитивной.

желаю удачи.

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

вообще не понятно, к чему это.

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

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

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

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

>если вы тянете эху, она должна быть у вас целиком.

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

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

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

вы всё таки не торопитесь, подумайте. не будете менять ii, да и хуй с ним, сделаете iii.

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

оно взято из целесообразности.

> в фидо эхи пуржились, я вообще не обязан был никому эти эхи доставлять.

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

> всем было насрать, что в эхах видны только новые сообщения.

это не так. радость сидеть после подписки перед пустым голдедом, и ждать неделю получения faq - сомнительна

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

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

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

> вы всё таки не торопитесь, подумайте. не будете менять ii, да и хуй с ним, сделаете iii.

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

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

Постфиксы. Смотря с какой стороны читать.

А расскажите как правильно пушить.

Т.е. структура поста мне понятна. А вот куда пушить - не очень. Например:

>где СТРОКА - это просто текстовый файл, кодированный base64
Т.е. передается файл, или просто в пост запрос оборачивается все?

>Файл текста отдавать, как есть
Куда?

Приминительно к этой ноде.

имеешь ввиду /u/push или /u/point? /u/push (нодовые сообщения) на этой ноде нет

/u/point:

передаётся POST-запрос вида:

pauth=authstr&tmsg=BASE64BASE64BASE64BASE64

в принципе, можно в исходниках сервера посмотреть shell-скрипты для постинга через wget, там всё понятно.


>> Файл текста отдавать, как есть
> Куда?

это касалось плоской спецификации. :) она увеличилась, а фрагмент остался. /m и /e. это надо вообще убрать :)

>имеешь ввиду /u/push или /u/point?
/u/point

>передаётся POST-запрос вида:
>pauth=authstr&tmsg=BASE64BASE64BASE64BASE64

Т.е., я правильно понимаю, что в итоге урл будет примерно таким?

http://example.com/u/point?pauth=authstr&tmsg=BASE64BASE64BASE64BASE64

нет.

гет запрос - таким:

http://example.com/u/point/authstr/BASE64BASE64BASE64BASE64

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

пост-запрос - соответственно заполняются поля pauth и tmsg. тут можно использовать и urlsafe, и обычную base64

кстати, если пропустил - вот нода для любых экспериментов с любыми эхами:

http://iibbs.bl.ee

насоздавай себе эх по вкусу, и тесть

>кстати, если пропустил
Пропустил.
Спасибо, буду с ней играться =)

Как только увидел существующие клиенты для ii, сразу зачесалось написать свой. И вот: https://github.com/6vasia/ncii
Умеет пока немного - ридонли, без локального кэша.
В ближайших планах: локальный кэш, отправка сообщений.

Зависимости: perl5, libwww-perl (LWP::UserAgent сотоварищи), Curses::UI, YAML.
Выглядит так: http://itmag.es/4CoXh

слов нет описать, насколько это вестчь! :)

Попробовал - очень хороший клиент, не забрасывай :)

Поместил на страницу скачивания

Я правильно понимаю что размер бандла сейчас ограничивается длинной URL? Если да, то какая длинна урлика максимальная?

http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request
Я ограничился пачками по 100, это чуть больше 2kB.

нахрена? к тому времени, когда это будет применимо, уже будут пост-запросы :)

> нахрена? к тому времени, когда это будет применимо, уже будут пост-запросы :)

Попробуй выдернуть im.1406 одним куском, например.

> Попробуй выдернуть im.1406 одним куском, например.

так официальный клиент эту часть тоже разбивает, по 40 сообщений. я так понял, человеку нужно на 724 эхи подписаться.

Common lisp клиент продолжает развиваться. Хотя и в день по чайной ложке.

https://github.com/spline1986/ii-dc

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

>нахрена?

Что нахрена?

>будут пост-запросы

Это что за зверь?

> Что нахрена?

нахрена столько эх?

> Это что за зверь?

дикий совсэм... зато соврэмэнный... все в 1998 годе так дэлали, слюшай

>нахрена столько эх?

Как длинна бандла к количеству эх относится? Вот хочу я тянуть im.1406. И хочу тянуть кусками побольше =)

>дикий совсэм... зато соврэмэнный... все в 1998 годе так дэлали, слюшай

Какой ты, Рома, загадочный =)

> Как длинна бандла к количеству эх относится? Вот хочу я тянуть im.1406. И хочу тянуть кусками побольше =)

официальный клиент тянет по 40 собщений за раз. ты что, хочешь быть святее Ромы Римского?

> Какой ты, Рома, загадочный =)

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

длинные реквесты и серверу могут проблемы создавать. а для клиента принципиальной разницы, 40 их или 100, на самом деле нет, на практике. да и 20 не особо изменят картину. просто, если плохая связь, то удобнее выкачивать мелкими бандлами, чтобы обрывы не сильно вредили. 20-40 - это оптимальное число.

Понятненько. Ну пока мне лень переписывать функцию формирования запроса. С анализатором длины и всё такое.

я тебе могу без анализатора сказать, сколько будет длина. с / - 21 символ на сообщение.

а вообще, у меня уже сформировались требования к клиентам, на проблемные места. кто не будет соблюдать - того Виктор в список не включит :) потому что там есть заметные проблемы.

Обновление клиента!
- Локальный кэш
- Немного изменились хоткеи

> Обновление клиента!
Ах да, конфиг теперь можно держать в текущей директории, но кэш всё равно будет в
~/.config/ncii/

> Обновление клиента!

Долгожданный фулскрин! Вход по ENTER, выход по C-q, переход по сообщениям -
LEFT & RIGHT.
@img: http://itmag.es/2gqTJ

Плюс бонусом счетчик непочитанных.

ура! вступаю в фанклуб этого клиента (ему надо крутое название! там был godled, а тут golbaba или goldbaby или dedushko :) шучу)

А поведение

Вот такого
    форматирования
Имею в виду 4 знака равно

это где-то в стандарте на сообщения прописано, или это просто парсер 51t?
У себя можно городить, что угодно, например, [code][/code]?

это прототип, который должен доказать своё поведение на практике

это всё должно быть применимо как на веб-клиентах, так и на txt-клиентах (см., например, game.rogue.14)

>это прототип, который должен доказать своё поведение на практике
На самом деле ==== - не очень удобно парсить. Точнее, вообще жутко. Или я просто на регекспах зациклился.

это выглядит понятно и в plain-text, и в html. кроме этого, это и там и там выглядит одинаково.

в текущей реализации не используется regexp. кроме того, таких вставок может быть много, и они все должны выглядеть одинаково. есть проблема с foundation, которая сбрасывает стили, поэтому на этом сайте ставятся огромные отступы :( но суть именно в том, чтобы всё было наглядно для всех видов клиентов.

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

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

Т
  р

в <pre>?

это файл splitfilter.py, хоть в клиенте, хоть в сервере

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

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

ps. есть некоторые вещи, которые кажутся лишними. но это особенность foundation. я не понимаю css и подобное, если кто-то скажет, как исправить разночтение нескольких <pre>, тогда от этого можно будет отказаться

Реализовал у себя

:)

>если кто-то скажет, как исправить разночтение нескольких <pre>
В смысле разночтение? Или ты имеешь в виду, чтобы мог быть просто преформатированный текст и код с подсветкой?
Если так, то можно сделать для кода <pre code=bash> например

> В смысле разночтение?

в смысле, параметры межстрочных интевалов, и ещё очень много других, внутри <p>, сбрасываются при завершении <pre>

поэтому при

<p>
...
<pre>
....
</pre>
...
<pre>
...
</pre>
</p>

отступы и прочее у разных pre будут разными. поэтому сейчас </p> закрывается, и открывается новая. особенности foundation,

> Как только увидел существующие клиенты для ii, сразу зачесалось написать свой.

А подскажи как его запустить. Пишет мне он

./ncii 
Can't locate Curses.pm in @INC (you may need to install the Curses module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at ./ncii line 7.
BEGIN failed--compilation aborted at ./ncii line 7.

Перл есть, yaml установил.
Curses::UI - вроде нету. Не пойму как энто установить. Нагулил "perl -MCPAN -e 'install Curses::UI'", но видимо это что-то не то, ибо выводит кучу ошибок.

Памагай

Какая ОС?
Ну и попробуй просто cpan -i Curses::UI