Ромеро> а можно сделать так, чтобы в окне сообщений q давала ответ на сообщение, а в списке эх - выходила из клиента? я себе в старом именно так сделал, пришлось в коде разбираться

Можно, но придётся немного подпатчить код.

>> блеклист
Peter> Возможно, нужно уметь блеклистить по нику. :) Но пока это не нужно.

Твита достаточно =)

>> У тебя пережиток прошлого, а у нас вполне себе средство визуально идентифицировать отправителя. Ты всё время меряешь idec своими мерками, которые подходят ГК11 и тебе, но не подходят idec. Отсюда куча каши в голове на эту тему. Лучше или разобраться или таки совсем забить на idec.
Ромеро> ничё не понял. это я придумал эту адресацию, вообще-то :) а теперь ты мне объясняешь, зачем я её придумал? :) если честно, я не понял вообще ничего

Это как вопрос с ii. Ты придумал, а мы приспособили. Имея карту сети (правда пока вас там нет, но это временно), можно легко понять по адресу от кого и каким путём пришло сообщение.

vit01> Сабж. Ваши действия?

Как там развиваются события? Уже пора переходить на self-hosted? =)

>>>>  Awesome WM
AL>> А вот тут моё мнение диаметрально противоположное, если честно. Использовать лучше то, к чему привык. Конечно, любопытство в своё время заставило меня попробовать так называемые тайловые оконные менеджеры, да так на них и остался по сей день, но Awesome достаточно сложен в настройке, если именно осмысленно писать ему конфиг и аплеты, и его изучение требует времени и сил.
vit01> Ничего ведь не мешает просто попробовать. Да, конечно, для настройки авесома надо мануалов покурить, поизучать чужие примеры. Но зато интеграция WM с языками программирования вырабатывает творческий подход к своему десктопу.

Это основная причина, по которой я отказался и от Fvwm и от stumpwm. Я в итоге слишком много времени тратил на кастомизацию, вместо того, чтобы пользоваться машиной =)

Anotheroneuser> * Потом, когда ещё не было Спектрумов, пробовали составлять игры самостоятельно, но недоставало знания алгоритмизации (их и теперь недостаёт, но мне удалось найти литературу [1]. В конце задам вопрос по ней)

Ссылки не стоит, но авторов и названия же можно =)

Anotheroneuser> * Потом начались Спектрумы 48К, игры на кассетах, которые мы покупали ещё на старые российские рубли. Там уже, конечно, всё было по-взрослому: графика и прочее. Вот, текстовых игр для Спектрума я что-то не припоминаю..

Были, конечно. И их было много. На https://www.worldofspectrum.org/ их насчитывается 2217 штук. Для меня года с 1996-го это стал практически основной жанр игр, в которые я играл тогда.

Anotheroneuser> Припоминаю, как сосед, который учился в школе с уклоном по информатике, писал в клетчатой тетради программы для ЭВМ. На каком языке он их писал, уже не помню. Кажется, Бейсик. Некоторые вещи мне удавалось выучить попутно. Потом удивлял друзей, оказавшись в классе информатики, где учились уклоняющиеся в неё старшеклассники и оставляли машины (Электроника какая-то там) включенными с результатом на экранах. Мне удавалось изменять код и запускать его снова. Получалась хрень, но это впечатляло непосвящённых ))

Я так и не позанимался на компьютерах в школе. Да и были там корветы до самого моего 10 класса. Как раз когда я перешёл в 10 класс, поставили третьи пентиумы и там уже был паскаль.

Anotheroneuser> Вообще, тот код писать было весело.

Это да =)

Когда хотят утешить, то говорят, когда для вас закрывается одна дверь, открывается другая. Так и вышло для Кена Томпсона (Ken Thompson) и Дениса Ритчи (Dennis Ritchie), когда они создавали операционную систему UNIX - одну из самых вдохновляющих и влиятельных программ за всю историю компьютерной техники.


Что было до UNIX: Эпоха Динозавров

Для Томпсона и Ритчи дверь закрылась в марте 1969 года, когда их работодатель, American Telephone & Telegraph Co. (AT&T), вышел из совместного с Массачусетским Институтом Технологий (MIT) и General Electric проекта по созданию интерактивных систем с разделением времени под названием Multics. Метод разделения времени (time-sharing), позволяющий нескольким людям использовать один компьютер одновременно, был изобретен всего десять лет назад и использовался в системе Compatible Timesharing System (CTSS).

Совместимая система с разделением времени, Compatible Timesharing System (CTSS), была одной из первых операционных систем такого типа. Разработанная в Вычислительном центре MIT командой, возглавляемой Fernando J. Corbató, система была продемонстрирована в 1961 на компьютере IBM 709. Усовершенствованная система CTSS запускалась на машине IBM 7094 и позволяла обслуживать до 30 пользователей одновременно через модемы.

Есть сохранившееся видео тех времён, где Fernando J. Corbató доступно объясняет принцип работы системы с разделением времени: https://youtu.be/Q07PhW5sCEk

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

Компания AT&T более пяти лет инвестировала миллионы долларов в проект Multics, закупая мэйнфрэймы GE-645 и координируя усилия многих ведущих исследователей в Bell Telephone Laboratories (Bell Labs), в том числе Ken Thompson, Dennis Ritchie, Joseph F. Ossanna, Stuart Feldman, M. Douglas McIlroy, и Robert Morris. Но новая операционная система была слишком амбициозна, и оттого её разработка серьёзно отставала от графика. В конце концов, корпоративные слизняки из AT&T решили ударить по тапкам и выйти из проекта.

После этого менеджеры Bell Labs сильно охладели к проекту разработки Multics. Такой поворот событий не мог не огорчать многих исследователей. Хотя операционная система Multics не достигла многих своих целей, она, по воспоминаниям Ритчи, предоставляла "удобный интерактивный сервис для вычисления, хорошую среду разработки, и систему, вокруг которой могло бы образоваться сообщество". Но беда пришла, и её совсем не ждали.

Справедливости ради, нужно отметить, что Multics ещё долгое время служила верой и правдой в разных академических и оборонных учреждениях. Некоторые машины с Multics составили части ARPAnet - то, что мы сейчас знаем как Internet, а тогда серьёзная сеть суровых американских вояк на случай ядерной войны. MIT's Multics был одним из первых сайтов в той сети.

Огорчённые этим событием, исследователи вернулись к использованию старой пакетной системы. В этот неблагоприятный момент, когда руководство было категорически против новых идей, казалось безрассудным продолжать разработку компьютерных операционных систем. Но это именно то, что Томпсон, Ритчи, и многие из их коллег по Bell Labs, отважились сделать. Теперь, 40 лет спустя, нам стоит поблагодарить этих исследователей за то, что они проигнорировали своих шефов и продолжили своё любимое дело, подарившее миру UNIX - одну из величайших компьютерных операционных систем всех времён и народов.

Томпсон, Ритчи, и Rudd Canaday из Bell Labs, начали делать наброски дизайна для файловой системы. Томпсон написал основы новой операционной системы для мэйнфрейма GE-645, установленного в лаборатории. Но конец проекта Multics означал и конец GE-645. Томпсон понял, что дальнейшее программирование под GE-645 это путь в никуда.


С чего начался UNIX...

После кончины Multics в 1969 году, Томпсон потратил часть своего времени на создание компьютерной игры под названием Космические путешествия, которая моделировала все крупные тела в Солнечной системе. Игроку требовалось провести космический корабль вокруг них, пытаясь приземлиться на планеты.

Игра, написанная для GE-645, была неуклюжа и очень дорогостояща - поиграть стоило примерно 75 долларов, потому как процессорное время стоило недёшево. Бродя по лаборатории, Томпсон наткнулся на PDP-7, мини-компьютер, созданный корпорацией Digital Equipment, и купленный его коллегами по Bell Labs.

PDP-7 выгодно отличался прекрасным видеовыводом, так что Томпсон переписал игрушку Космические путешествия для работы на PDP-7.

Это было куда сложнее, чем может показаться на первый взгляд. Так как отцы UNIX презирали всё существующее программное обеспечение, они должны были реализовать арифметику с плавающей точкой и полную спецификацию графических символов для подсистемы отображения и отладки, которые непрерывно отображают содержимое положений игрушечного корабля в углу экрана. Все это было написано на ассемблере, и запускалось на компьютере GECOS, выдавая бумажные ленты для PDP-7.

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

Название Unix связана с шуткой одного из коллег Томпсона: новая операционная система поддерживает только одного пользователя (собственно, Томпсона), и он рассматривал её как выхолощенную версию Multics - потому и нарёк новую операционную систему "Un-multiplexed Information and Computing Service". Это название позже превратилось в Unix.

Всё это непотребство творилось за спиной начальства, которое ничего не подозревало об этих игрищах.

Изначально Томпсон использовал GE-645 для создания и компиляции программного обеспечения, который он затем загружал на PDP-7. Вскоре Томпсон начал разработку файловой системы и пользовательских утилит: копирование, печать, удаление, правка файлов и, естественно, командный интерпретатор. Все программы писались на компьютере GECOS и переносились на PDP-7 на бумажной ленте. Как только Ассемблер на PDP-7 заработал к концу 1969 года, Томпсон был в состоянии писать код операционной системы собственно на самом PDP-7. Это был шаг в правильном направлении. Однако Томпсон и другие исследователи знали, что миникомпьютер PDP-7 уже был устаревшей моделью, как знали они и то, что руководство лаборатории не собиралось больше разрешать исследований по операционным системам.


Подпольная разработка UNIX и первые успехи

Так что Томпсону и Ритчи нужно было проявить изобретательность, которую они блестяще продемонстрировали: в заявке они попросили начальство купить одну из новых мини-ЭВМ DEC, а именно PDP-11. Запрос был сформулирован в очень кучерявых терминах: они написали, что целью является создание инструментов для редактирования и форматирования текста (то, что мы сейчас назвали бы текстовый процессор). Тот факт, что они также должны были написать операционную систему для новой машины, чтобы запускать текстовый редактор, был всего лишь сноской.

Менеджмент клюнул на приманку, и заказ на PDP-11 был размещён в мае 1970 года. Хотя сам компьютер доставлен быстро, носители данных для него привезли лишь через полгода. В этом время, Томпсон, Ритчи и другие продолжали разрабатывать Unix на PDP-7. После установки носителей данных в PDP-11, исследователи перенесли свою навороченную операционную систему на новую машину. Затем они перетащили туда текстовый редактор roff.

Первыми ходовыми испытаниями для Unix стал патентный отдел AT&T, где машинистки стали использовать Unix для набора, редактирования и оформления патентов. И это был успех! Патентное ведомство с удовольствием приняло новую систему, что дало исследователям достаточно авторитета, чтобы убедить руководство приобрести ещё одну машину, обновлённую и более мощную модель PDP-11, позволяющие продолжить их подпольные работы по Unix.

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

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

Каждый файл мог содержать не более 64 килобайт, и его имя могло быть не длиннее шести символов. Эти ограничения, кажущиеся такими неуклюжими сейчас, в то время были более чем адекватными.

Хотя Unix якобы создавался для обработки текстов, единственным доступным редактором в 1971 году был ориентированный на строки ed. Сегодня, ed по-прежнему является текстовым редактором, гарантированно присутствующим на всех системах Unix. Помимо обработки текстов и общесистемных приложений, первая версия Unix включала такие игры, как блэкджек, шахматы и крестики-нолики. Утилиты системного администратора включали сохранение и восстановления образов дисков на магнитную ленту, утилиты чтения и записи на бумажные ленты, а также программы для создания, проверки, монтирования и размонтирования съемных дисков.

Самое замечательное заключалось в том, что система предлагала интерактивную среду, которая позволяла работать в режиме разделения времени (time-sharing). Это позволяло нескольким пользователям использовать одну машину одновременно. Были доступны различные языки программирования, в том числе BASIC, Fortran, ассемблер и язык B. Собственно, язык B является потомком BCPL (Basic Combined Programming Language, базовый комбинированный язык программирования), и в конечном итоге превратился в чрезвычайно популярный язык C, созданный Ритчи во время работы над Unix.


Влияние UNIX

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

Всё было примерно так: в течение многих лет Unix оставались лишь исследовательским проектом Bell Labs, но к 1973 году авторы Unix сочли, что система была достаточно зрелой для того, чтобы выступить с докладом о ней на конференции Ассоциации вычислительной техники (Association for Computing Machinery).

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

Это поставило AT&T в трудное положение. Дело в том, что в 1956 году AT&T пошло на соглашение с правительством США, по которому компании запрещалось продавать продукцию, не связанную напрямую с телефонами и телекоммуникациями, в обмен на её право монополии в междугородных телефонных услугах для всей страны. Так что Unix не мог быть продан в качестве продукта. Вместо этого AT&T выпустила исходные коды Unix под лицензией, позволяющей использовать их любому желающему по цене носителей. Важная деталь: по тому же соглашению, AT&T не могла оказывать поддержку Unix. На протяжении многих лет исследователи Bell Labs с гордостью демонстрировали это на Unix-конференциях слайдом, который гласил: "Без рекламы, без техподдержки, без багфиксов, деньги вперёд."

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

Группа пользователей Usenix выступала в качестве центра по обмену программным обеспечением для Unix в США. Люди могли отправлять магнитные ленты с новым программным обеспечением или исправлениями и получать софт и исправления, которые Usenix получал от других. В Австралии, Университет Нового Южного Уэльса и Сиднейского университета, была создана более надежная версия Unix, Australian Unix Share Accounting Method, которая могла справиться с большим количеством одновременно работающих пользователей и отличалась более высокой производительностью.

К середине 1970-х годов, среда, возникшая вокруг Unix, напоминала движение Open Source, столь распространенное сегодня. Пользователи повсюду с энтузиазмом расширяли и улучшали систему, и многие из этих улучшений отправлялись обратно в Bell Labs для включения в будущие релизы. Однако с увеличением популярности Unix, стервятники из AT&T начали более пристально смотреть за тем, что пользователи делали с их системой.

Человеком, привлёкшим их внимание, был Jogn Lions, учёный, преподававший в Университете Нового Южного Уэльса в Австралии. В 1977 году он опубликовал книгу, ставшую самой известной в то время - A Commentary on the Unix Operating System, содержащую прокомментированный основной исходный код Unix.

Лицензионные условия Unix позволяли обмен исходным кодом, и изначально книга Лайонса продавалась лицензиатам Unix. Но к 1979 году адвокаты AT&T запретили распространение и использование книги в академических кругах. Сообщество Unix, будучи анти-авторитарным, отреагировало на это так, как и ожидалось: копии книги распространялись самиздатом со скоростью лесного пожара. Многие до сих пор держат почти нечитаемые фотокопии оригинальной книги тех лет.

Снующие всюду юристы AT&T стали привычным явлением, даже в Bell Labs. Например, между шестым релизом Unix в 1975 году и седьмым в 1979 году, Томпсон собрал множество важных исправлений ошибок. Он хотел исправить их для пользователей Unix, но юристы компании сочли, что это будет являться одной из форм техподдержки и запретили релиз. Тем не менее, эти исправления вскоре стали широко распространены по неофициальным каналам. Например, Lou Katz, основателю и президенту Usenix, позвонили в один прекрасный день и сказали, что если он придёт в определенное место на Mountain Avenue (где находилась Bell Labs) в 2 часа пополудни, он найдёт нечто интересное. Конечно же, Кац обнаружил магнитную ленту с исправлениями, которые быстро попали в руки бесчисленных пользователей.

К концу 1970-х годов, Unix, начавшаяся десять лет назад как бунт против потери комфортной среды программирования (Multics), росла, как сорняк, по всему научному миру и ИТ-индустрии. Unix расцвёл в начале 1980-х и достиг вершины своей популярности в начале 1990-х.

По многим причинам, Unix с тех пор уступил дорогу другим коммерческим и некоммерческим системам. Но его наследие, эта элегантная, хорошо продуманная и комфортная среда разработки программного обеспечения, продолжает жить по сей день. В знак признания достижений, Томпсон и Ритчи получили Japan Prize в начале 2011 года, увеличив коллекцию наград, которая включает National Medal of Technology and Innovation и Turing Award от Association of Computing Machinery.


UNIX жил, UNIX жив, UNIX будет жить.

Unix действительно является одной из наиболее влиятельных операционных систем, когда-либо изобретённых. Прямые потомки Unix в настоящее время исчисляются сотнями. С одной стороны родословной находятся различные коммерческие версии Unix, появившиеся на рынке в 1980-х годах после падения монополии Bell System. С другой стороны - различные Unix-подобные операционные системы, предком которых была версия Unix, разработанная в Университете Калифорнии, Беркли (University of California, Berkeley), в том числе используемая Apple - OS X. Именно Unix-подобные: разработчики Berkeley Software Distribution (BSD) Unix много работали над тем, чтобы удалить весь оригинальный код AT&T, чтобы их и основанное на нём программное обеспечение могло распространяться свободно.

Результаты этих усилий, однако, были поставлены под вопрос, когда филиал AT&T, Unix System Laboratories, подал иск против Berkeley Design Software в 1992 году за права интеллектуальной собственности на данное программное обеспечение. Университет, в свою очередь, подал встречный иск против AT&T. Последовавшая за этим судебная тяжба замедлила развитие свободных Unix-подобных систем, в том числе 386BSD, которая была разработана для Intel 386 - процессора, который использовался во многих компьютерах IBM.

Линус Торвальдс говорил, что если бы эта операционная система была доступна в то время, он вряд ли создал бы Linux. А вышло так, что Unix передал эстафету Linux в двадцать первый век, работая на самых разных устройствах: от беспроводных роутеров, телевизоров, настольных компьютеров и смартфонов Android до кластеров и суперкомпьютеров.

Хотя AT&T быстро уладили правовые споры с Berkeley Design Software и Университетом Калифорнии, юридические тяжбы на тему украденной Linux интеллектуальной собственности Unix продолжаются до сих пор. К 2004 году было подано не менее пяти крупных исков. Не далее как в августе 2011 года, компания TSG Group (ранее известная как SCO Group), проиграла в суде дело о владении авторскими правами Unix.

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


Отдавая дань истории...

Мир компьютерного железа и программного обеспечения движется вперед поразительно быстро. Быстрый темп изменений для ИТ-специалистов, как правило, замечательная вещь. Но он приводит к тому, что мы забываем наше собственное прошлое, в том числе и важные уроки оного. Для решения этой проблемы, Warren Toomey [автор оригинального текста], в 1995 году начал почтовую рассылку по поиску старых поклонников Unix. Эта работа переросла в Сообщество Наследия Unix (Unix Heritage Society). Цель сообщества - не только сохранить историю Unix, но также собрать и сохранить эти старые системы, вернув их к жизни. С помощью многих талантливых участников общества Наследия Unix, Warren Toomey смог восстановить большую часть старого программного обеспечения Unix в рабочем состоянии, в том числе первый компилятор C, созданный Ритчи в 1972 году, и первый релиз Unix, написанный на C в 1973 году.

Долго ускользавшая от нас Чаша Грааля - первое издание Unix. Затем, в 2006 году, Al Kosso из Музея компьютерной истории в Mountain View, штат Калифорния, откопал печатную версию Unix от 1972 года, которая не только описывала внутреннюю работу Unix, но также включала полный ассемблерный код ядра. Это была удивительная находка, примерно как обнаружение первого автомобиля Ford Model T, пылящегося в углу сарая. Но мы не просто хотели полюбоваться на это издалека - мы хотели запустить первую версию Unix снова.

В 2008 году Tim Newsham, независимый программист, и я [Warren Toomey], собрали команду единомышленников-энтузиастов Unix, и решили воскресить эту древнюю систему. Работа была технически трудной и зачастую разочаровывающей, но в итоге мы создали копию первой версии Unix, и заставили её работать на эмуляторе PDP-11/20. Мы разослали сообщения, извещающие о нашем успехе всем, кому, как мы думали, это будет интересно. Томпсон, как всегда кратко, ответил: "Потрясающе". В самом деле, его детище удивительно, и я [Warren Toomey] был рад сделать всё от меня зависящее, чтобы история Unix стала более известной.


Оригинал статьи с фотографиями, видеороликами и прочей дополнительной информацией находится по адресу http://mydebianblog.blogspot.ru/2012/02/unix.html

vit01> Попытался запустить на рабочем сервере своём ii-net.tk и обломался, потому что там проставлен HSTS, и браузер ни в какую не хочет пускать по обычному http, форсируя защищённое соединение.
vit01> Нужна поддержка сертификатов.
vit01> В той же Gitea всё это продумано до мелочей, хз, как с этим bottle себя ведёт.

Зачем это эталонной реализации? Кто-то будет её юзать в боевых условиях?

AL>> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
vit01> Слабая валидация POST данных. Особенно на тех же файловых эхах

Непонятно что именно не так =)

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

Можешь привести пример?

vit01> Мои пожелания:
vit01> 1. Складывать все конфиги, файлы, относящиеся к эхам и файлэхам, в отдельный каталог вроде "data"

На боевой реализации конфиги вообще в БД будут

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

В БД всё.

vit01> К конфигам удобнее добавить готовые примеры, чтобы ещё быстрее ускорить развёртывание станции.

Зачем ускорять развёртывание эталонной реализации. Это же по факту POC.

vit01> 2. Объединить cli-скрипты в единый интерфейс и запускать вроде
vit01> ====
vit01> idec.py run
vit01> idec.py points add Vasya
vit01> idec.py stats -f ... -t ...
vit01> idec.py stats --help
vit01> ====

Нет смысла. Это усложнит чтение исходного кода.

vit01> 3. Туда же, к cli-интерфейсам. Не надо городить велосипедов к парсингу параметров командной строки, ведь есть модуль argparse из стандартной библиотеки. Он же поможет тебе объединить все скрипты в один
vit01> https://docs.python.org/3/library/argparse.html

Про это я пока у Лутца не читал =)

vit01> 4. Текстовая БД не единственный тип БД. Я понимаю, что у нас это классика, но в боевых условиях, на десятках тысяч сообщений это не вариант. Только если в виде PoC

Нет смысла в эталонной реализации. Как и вебморда не нужна.

Peter> Сугубо для оживления беседы. :) У меня был примерно такой путь:

Забыл же про свой неказистый путь рассказать =)

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

  -.-
*=(0)

так как компьютер не имел графического видеорежима.

Потом был спектрум. Тоже самопальный и в разных вариантах. Без дисковода с 48 килобайтами памяти, с дисководом с ним же, с 128 килобайтами памяти, потом даже с музыкальным сопроцессором. Там я лет до восьми только в игрушки играл и баловался графическим редактором Art Studio. А лет в восемь задал себе вопрос: как же делаются эти игрушки? Как раз примерно в это время мой друг принёс мне книжку по бейсику для детей. Называлась она, как сейчас помню, "Сказки дядюшки компьютера". Там были нелепые истории и самое ценное - примеры программ на бейсике, визуализирующие эти истории. Меня тогда это сильно впечатлило, но при ближайшем рассмотрении оказалось, что написаны они на диалекте бейсика, отличном от спектрумовского. Сейчас я искренне недоумеваю как мне тогда это удалось, но я смог их ввести в спектрум и адаптировать под имеющийся диалект.

Если кто не помнит или не знает, ввод программ на бейсике в спектруме был достаточно хитёр. Каждый символ занимал в памяти один байт, но ввести можно было только 128 символов. И ещё 127 значений этого байта было отведено под команды бейсика. То есть на экране было написано какое-нибудь слово, например, "CIRCLE", а в памяти эта команда занимала целый байт. В связи с этим команды вводились нажатием одной клавиши или клавиши-модификатора и буквы. Это сильно усложняло мне задачу, ведь на тот момент у меня была только самодельная клавиатура вообще без какой-либо маркировки и догадаться, что надо нажать, например, EXT MODE и букву для ввода команд было тяжело. Но я и с этим справился =)

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

Так я и баловался с бейсиком и в ус не дул. Я слышал, что есть некий ассемблер, но у меня не было ни литературы ни компилятора этого дела. А больше языков я не знал совершенно. Даже не догадывался об их существовании. Открытием для меня стало приложение к журналу "Радиолюбитель" с оригинальным названием "Мой компьютер". Оказалось, что есть такой язык, как паскаль. Читая статьи и пытаясь понять опубликованные в журнале программы, я возомнил его чем-то очень крутым. Строго говоря, оно так и было, ведь прогаммы были ориентированы на Turbo Pascal от Borland, и PC с паскалем на фоне спектрума с бейсиком был очень классным и интересным. Но PC у меня не было. Как и какого-нибуь компилятора паскаля.

Правда однажды я у кого-то стянул компилятор для спектрума, но на 128 килобайтах оперативки что-то дельное на нём было сделать тяжело. Он был тяжёлый и на программу оставалось мало памяти. То есть было просто тесно. Не знаю, скорее всего я с ним просто не разобрался, ведь сопроводительной документации к нему у меня не было. Так что побаловавшись немного, я так и вернулся на бейсик, лелея мечту когда-нибудь осилить ассемблер, потому что все крутые программы на спектруме были написаны именно на ассемблере. Значительно позже мне попался справочник по процессору Z80 (сердцу спектрума), но сама концепция программирования на ассемблере настолько отличается от программирования на бейсике, что ничего это мне не дало.

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

Так я и промаялся с бейиком до 14 лет. А потом в моей жизни появился PC на базе 486 процессора. Рухлядь по тем временам (2001-й год), но после простенького спектрума это было для меня откровением. До того момента я вживую видел PC только у друга и ничего в нём не понимал. Только в дум резаться умел =)

Друзья быстро присоветовали книжку и дали заветные дискетки с турбо паскалем. На книжку мне пришлось копить несколько месяцев, но я всё таки её купил. Как сейчас помню, Немнюгин С. А. "Turbo Pascal Учебник". Кстати, очень хорошая книжка была для старшеклассников. Наисана ясно и примеры хорошие. Так я начал писать программки для доса.

Потом был целый пентиум, разогнанный аж до 166 МГц и Windows. И Delphi с ужасной книжкой "Delphi для чайников". Случилось это где-то уже годам к 16. На страшной и ужасной Delphi я просидел ещё несколько лет и даже диплом писал там же. А потом я открыл для себя GNU/Linux и занялся егё изучением. И программирование несколько забросил, ведь кроме паскаля ничего не знал, а с free pascal быстро наигрался. Так продолжалось достаточно долго и двигаться дальше я начал уже года в 24. Для начала освежил в памяти паскаль, начал играться с python-ом, вспомнил, что хотел попробовать написать игру для Instead. И понеслось до сих пор.

Профессиональная деятельность у меня ушла от программирования далеко в сторону, а для себя я пишу на чём попало. Python3, Common Lisp, Go и, конечно, lua. Ведь инстед стал частью моей жизни.

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

// Надеюсь, это было не слишком скучно читать =)

Anotheroneuser> Я о Моженкове особо ничего не знаю, если честно. ПРосто его видеодневник попался мне в Youtube и показался нормальным. Он там старается аккуратно советовать, так что, может я что-то не так понял: если разбираться, то придётся лезть в вашу профессию, а я не могу по причине полного отсутствия представления о ней )

Я о нём вообще только от тебя услышал. Просто рекомендовать C++ как основной язык сегодня не очен хорошо даже для профессионалов. Рекомендовать же его любителям и вовсе вредительство. Если говорить, например, о профессиональной деятельности, то знание C++ сейчас требуется только для сопровождения старых программ и кучи чужого кода. Новые программы на нём пишут мало. По крайней мере в сфере коммерческого ПО.

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

vit01> Видно, видно

Спасибо. Переехал на новое железо и не был уверен, что фетчер адвокатно отрабатывает.

>>  Это должно научить некоторым базовым вещам
Anotheroneuser> А могу я некоторые базовые вещи освоить просто в теории? Или обязательно надо сразу где-то закреплять их на практике?

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

>>  Awesome WM
Anotheroneuser> На некоторых снимках выглядит обалденно. Только у меня не настолько глубокое знание Linux на данный момент. Уже несколько лет работаю в Mint. Но надо что-то менять — согласен. Попробую..

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

Anotheroneuser> Это позволит сэкономить массу сил. По-крайней мере, сейчас, когда их действительно есть куда девать. Как ты понимаешь, до меня практически не доходят характеристики языков программирования. Я просто не понимаю, что значит «монструозный-компактный» или «простой-сложный».

Да оно тебе особо и не нужно. Просто есть языки с кучей конструкций и концепций, которые нужно знать. Теоретически на них проще писать, ведь на каждый чих у тебя есть в языке что-нибудь. А есть языки с необходимым минимумом. В них тебе многое придётся делать чуть сложнее, но зато там мало всего и писать/читать код будет существенно проще. Это, конечно, моё мнение как любителя, но для себя я вывел такую штуку.

Anotheroneuser> С моей точки зрения на данный момент, язык — некий набор инструментов, с помощью которого мне предстоит оживить сценарий игры. Как это будет в натуре, пока даже не представляю. Ну main3.lua понять могу. И приблизительно представляю себе, что движок будет воспроизводить то, что предусмотрено алгоритмом, который ему напишешь в main3.lua. Наверное, в main3.lua же будут содержаться ссылки на звуковые- видео- фото- и прочие материалы, которые необходимо разместить в каталоге игры (это, кстати, отлично).

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

Anotheroneuser> Но читать код... пока не понимаю. Изучаю пособие. Слава Богу, кстати, что не придётся пока учить С++ )) Наверное, на это уйдут годы

Ну с инстедом всё просто на самом деле. Есть в РИЛ-сообществе мнение, что инсед сложный, но на самом деле это не так. Инстед против FireURQ, ИМХО, примерно как go против python. То есть писать на питоне, может, ипроще новичку, но go проще устроен с точки зрения синтаксиса и структуры языка. Инстед это простой инструмент, но не с самым низким порогом вхождения. Но это так. Растекаюсь мыслью по байтам =)

Я как-то объяснял жене как писать игры на инстеде. Вот комната, вот ещё комната. Их можно связать переходами. Вот объект, вот ещё объект. Можно сказать движку, что их можно брать или что между ними возможно взаимодействие.

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

jmaks> Какие есть у кого предложения, что можно еще вкорячить на железку?
ii-ноду же ну =)

Difrex>> Да, попробуй этот мануал http://docs.slackware.com/howtos:general_admin:kvm_libvirt
jmaks> Низкий поклон тебе, добрый человек, поисковые системы постоянно чудят со
jmaks> мной и на полезные и понятные маны в одном месте не выдают никаких ответов
jmaks> на запросы.
jmaks> Читаю и просвещаюсь. Вообще у слаки вроде такая богатая история, а с поиском
jmaks> манов в сети -- постоянно проблемы.
Вобще, это официальный сайт слаки. Как бы не такая уж и проблема =)

PS Но гугл действительно выдаёт муру по слаке часто. Просто потому что он так устроен.

Peter> Сугубо для оживления беседы. :) У меня был примерно такой путь:

Довольно увлекательный, надо сказать, путь =)

Peter> 15) Написал INSTEAD. Понравился Lua, появился инстерес к высокоуровневым языкам. Так что теперь с удовольствием применяю то, что попадется под руку.

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

Peter> 16) Работы менялись, но C остался =)

И это не просто так. До сих пор считаю его очень крутым инженерным языком. Конечно, писать прикладной софт на нём нынче не очень удобно, КМК, но системные вещи сам Пат велел =)

Меня видно?

>>> Переходи сразу к lua
Anotheroneuser>> Привлекательная мысль, благодарю. И очень сэкономит время.
vit01> То, что для "настоящего" обучения программированию советуют C++, на самом деле не лишено смысла. Это должно научить некоторым базовым вещам, да и строгая типизация дисциплинирует.

ИМХО, а я не настоящий сварщик, делать первые шаги с C++ имеет смысл только если под рукой есть гуру, который всегда придёт на помощь. Причём именно гуру, а не преподаватель.

vit01> На мой взгляд, самое важное в обучении программированию - это иметь возможность сразу "потрогать" результат своего труда. А если твоя краткосрочная цель есть написание игрушек на Инстеде, то Lua - это точное попадание. Так у тебя будет мотивация улучшать свои навыки, и, натренировавшись, можно будет углубляться, переходить от простого к сложному. К тем же плюсам, например.

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

>> сделаете замечания
Difrex> filter() - это встроенная функция python.
Difrex> Т.е. делая так
Difrex> ====
Difrex> from api import filter
Difrex> ====
Difrex> Ты ее переопределяешь.

Спасибо. Переделаю.

>>  Не знаю почему тебе советовали начинать с С++
Anotheroneuser> Программу обучения составляю спешно, ориентируясь на мнение таких людей, как ты, Андрей, Пётр — специалистов.
Anotheroneuser> Начинать с С++ рекомендует В.Моженков в своём видеожурнале https://www.youtube.com/playlist?list=PLY7PmJJFH5nS_QOUktkW_eJikn41A819x
Anotheroneuser> Он говорит, что начинать изучение программирования с какого-нибудь вспомогательного (возможно, я не точно воспроизвожу его слова) языка приведёт к тому, что впоследствии придётся осваивать основной язык как бы заново. Может быть, меня попросту переклинило в анализе этой теории применительно к изучению Lua по отношению к C++... А, может, Моженков говорил это не для всех, а лишь для тех, кто планирует капитально связать свою жизнь с программированием и заниматься им профессионально? У меня-то нет такой цели.

Если честно, по ссылке я не сходил, но сильно не согласен с В. Моженковым по той простой причине, что в современном мире именно C++ требуется разве что для поддержки legacy-кода. Для системщиков он так и остался слишком монструзным, хотя кто-то что-то и пишет на нём, а для прикладного ПО появились более классные языки. Причём если говорить именно о прикладном ПО, то опускаться до низкого уровня нынче нет никакого смысла, так как большинство потребностей программиста, особенно если он пишет для себя, с лихвой покроют те же python или go.

>>  Переходи сразу к lua
Anotheroneuser> Привлекательная мысль, благодарю. И очень сэкономит время.

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

// Может, я предвзят, но С++ не самый удачный язык в принципе. Не самый и плохой, но уж учиться программировать с него это как-то слишком.

Теперь idec-txt поддерживает слайсы. Вроде как, теперь он вполне себе POC клиентской части полноценный.

Много чего доделал и доработал в сабже. Также написал простенький idec-txt под шумок. И переписал скрипт отсылки файлов в фэхи.

Всё это лежит вот тут:

* https://gitlab.com/spline1986/idec - эталонная нода;
* https://gitlab.com/spline1986/idec-txt - скрипт для отпрафки файлов в фэхи;
* https://gitlab.com/spline1986/idec-utils - тут я собираюсь возродить свои скрипты для idec, но пока тут только скрипт для отправки файлов.

Если есть желание и время, буду признателен, если потестируете или сделаете замечания по README хотя бы =)

PS: Да. Докстринги я до сих пор не прописал. Это на очереди.

jmaks> Каким образом можно заинсталлить vb на систему x86_64. Кто делал, что делал,
jmaks> как делал?

Я сейчас глупость скажу, но можно попробовать поставить мультилиб и собрать под 32 бита или подыскать версию vbox работающую на старом ядре.

ps Я так понимаю, попытка запустить ядро из current-ветки результатов не дала?

>>  Посоветуешь что-нибудь толковое по алгоритмизации. Я искал, но попадалось либо очень сложное, либо малоизвестное. А ты, наверняка, знаешь что-нибудь толковое.
Anotheroneuser> После «алгоритмизации» знак вопроса, конечно же))) Прошу прощения — спешил и спотыкался )

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

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

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

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

Лично я бы начал как раз с чего попроще. То есть с lua, так как он проще C++ и является целью. В books.tech (спрашивайте у оператора вашего уза =) лежит Иерусалимски на русском языке. Очень хороший учебник.

// Книжку могу скинуть более дургим способом, но для этого лучше написать мне на почту spline at rooker dot ru.

Anotheroneuser> Парни, набросал тут себе небольшую программу по освоению языков. Но, конечно, сомневаюсь в том, правильна ли последовательность и т.д. Можно вас попросить — посмотреть, исправить и рекомендовать мне что-нибудь? Там не очень много.

А где посмотреть то?

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

>>Думаю, что IDE всё-таки придётся ставить.
>Попробовал android studio, так она виснет и вылетает через 5 минут работы. Ещё и терминал, в котором запущена, в сегфолт загоняет.

У нас таки будет андроид-клиент?

Оффтопик: у меня, скорее всего, остались последние дни сессии. В iing чего договорились то? Оставляем 20 знаков в msgid и обязательную точку в имене эхи, но без обязательного числа в конце (ii.talk)?

>> Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)
Difrex> Ок, по стилю :)
Difrex> Общие рекомендации:
Difrex> * Код должен быть по PEP8.

Уже переделал этот момент.

Difrex> * Хорошо бы иметь краткий докстринг в каждой функции -- это полезно, для того, чтобы
Difrex> сразу понимать, что эта функция делает, для показа доков в Емаксе и для автогенерации
Difrex> документации на код в том же Sphynx. У меня, например, настроена CI так, что ПР, где
Difrex> нет докстрингов, не принимаются.

Это у меня в TODO было давно =)

Difrex> * Никогда не импортировать * из модулей.

Да. Я уже усвоил это. Если импортировать только нужное, то получается гораздо нагляднее и безопаснее.

Difrex> * Не переопределять имена функций в переменные. Что я имею в виду:
Difrex> В файле points.py(а возможно и в других, не копал еще сильно) есть функция `hsh()',
Difrex> которая генерирует authstring. Так вот в нескольких других местах ты создаешь строковые
Difrex> переменные с таким же именем. Это может привести к неочевидным последствиям.

Этот момент я ещё не проработал, но ошибка весьма очевидна, если подумать. Спасибо =)

Difrex> * Использование python-black по желанию -- это бескомпромиссный форматировщик кода.
Difrex> Работает четко и круто.

Пока я просто прогнал все файлы через pep8 и исправил все замечания. Ну и форматирование исправил с оператора форматирование на метод форматирования. Правда пока не тестировал чего я там наделал, зато исправил пару критичных багов попутно =)

Difrex> Как облегчить себе жизнь и ваще не париться по поводу стиля:
Difrex> Ставишь из своих репов autopep8, flake8, python-black, pip.
Difrex> Настраиваешь Емакс: https://paste.lessmore.pw/hojecuqece.lisp
Difrex> Теперь всю работу по форматированию кода, а так же комплиту, прыжкам в методы, и.т.д будет делать
Difrex> за тебя GNU Emacs :)

Как раз собирался гуглить как это сделать. GNU Emacs это сила =)

Спасибо за полезные советы и рекомендации. Давно пора было мне упорядочить свой стиль и перестать разводить бардак в коде.

Difrex> Сделал ПР.

Кстати, так как я учусь только, то лучше мне просто указывать на недочёты и ошибки, чтобы я сам разбирался и делал всё. Особенно что касается стиля, так как хороший стиль чужими патчами не выработаешь =)

Peter> P.S. Кто еще заценил эту штуку? :)

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

Да. Маскот крайне классный ещё. Согласен.

Difrex> И еще. Генерация authstring в points.txt отстой.
Difrex> Т.к. зная имя пользователя, мы всегда можем получить его строку авторизации.
Difrex> Сделал ПР.

А вот это по существу уже совсем. Спасибо.

AL>> Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)
Difrex> Сделал ПР.
Difrex> Замечания:
Difrex> * Не импортируй звездочки из модулей
Difrex> * Форматирование строк через % устарело
Difrex> * PEP8

Спасибо. Разберусь что к чему и смержусь/пофикшу.

Пора уже действительно писать как для людей, а не как для себя =)

Давненько уже я начал работу над сабжем, но некоторые события жизни и длинный отпуск существенно замедлили события. Сегодня я, вроде как, закончил вчерне всё. Доступно это добро тут https://gitlab.com/spline1986/idec

Очень бы хотелось услышать замечания и рекомендации от многоуважаемого All =)

Difrex(mobile)> Переделал на хэшики - все работает =)

Можешь накидать примерчик? Интересно а то.

Я опять проморгал движухху на freenom. Они теперь не пускают по github'овскому аккаунту. Так что перенастраивайте фетчеры на сабж на адрес http://idec.spline-online.tk/ я вернул старый домен себе.

Difrex(mobile)> А ты не мог бы подсказать как мне сделать такую штуку, как список из ассоциативных массивов.
Difrex(mobile)> Делаю сейчас так:
Difrex(mobile)> ====
Difrex(mobile)> (setq new-messages-list (-concat 'new-messages-list '((content . message-content) (id . msg))))
Difrex(mobile)> ====
Difrex(mobile)> Потом пытаюсь пройтись по этому списку:
Difrex(mobile)> ====
Difrex(mobile)> (dolist (msg new-messages-list)
Difrex(mobile)> (message (assoc 'id msg)))
Difrex(mobile)> ====
Difrex(mobile)> Но не работает. Ругается так: Wrong type argument: listp

Вот я не помню как в emacs lisp работают property lists. Я делал простой список списков со структурой ((msgid body) (msgid body)) и обкодил список, обращаясь к элементам посредством (first...) и (second...). Решение кривое, но рабочее и с учётом статичности структуры данных, в целом, приемлемое.

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

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

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

Difrex> В общем начал я пилить клиента под емакс. Пока удалось сделать только получение списка эх. Но думаю потом дело пойдет быстрее.
Difrex> Если кто готов присоедениться - велком https://gitea.difrex.ru/Difrex/idec.el

О! Крутота. Я неоднократно начинал, но забрасывал. А я go осваиваю потихоньку =)

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

У вебчатов были удобные клиенты и распределённость? Или работа в оффлайне?

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

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

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

Зачем простой распределённый способ общения или зачем оффлайновые сети?

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

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

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

Ну и это. Фидо никуда не делось и продолжает существовать. Так что утверждение ложное. Вот социальные сети мертвы. Там нет общения. Только мемы и лайки.

Difrex> Привет.
Difrex> Вот я пишу программку, хочу опакетить ее. Делаю в конце
Difrex> (provide 'my-prog)
Difrex> В емаксе добавляю каталог в load-path, делаю require. Вопрос: как достучатьс до функций из пакета?

Не очень понял что значит "достучаться". Если вызывать их из других программ, то они сразу доступны по имени. Если имеется в виду интерактивный вызов, то надо использовать специальную форму (interactive &optional ARG-DESCRIPTOR). Подробнее можно прочитать во встроенной справке "C-h f interactive RET".

;;; Йу-ху! С каждым днём имаксеров становится всё больше =)

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

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

Difrex> Чтобы считать из файла структура и поля у нее должны быть экспортированы https://blog.golang.org/gobs-of-data

Да. Дело оказалось именно в этом. Спасибо за помощь.

Сабж. Я всего лишь с гитхаба съезжал и уснул. Все репозитории доступны на http://git.spline-online.tk/. Пока так, а потом посмотрим.

> отправка из старого доброго и уже родного клиента

Попробуй новый клиент. Он классно заточен под idec (умеет слайсы и максимально эффективно ими пользуется в плане соотношения трафик/количество запросов), имеет черновики на случай, если ты пишешь длинное сообщение и отвлекаешься, это полезная штука. И вообще кучу всего, включая исправления багов.

> Нет, я ее не помещаю в репозиторий. Это все таки не игра. Но думаю будет работать.

Поднял бы у себя instead-js. Там делов то на пару минут.

>> В ii/idec адрес формируется так: имя узла,номер поинта. Например, tavern,1.
Ромеро> это пережиток прошлого. ещё до ii была несколько другая сеть, нераспределённая, где были визуализированы улицы и домики, причём у девочек были нечётные номера дома, а у мальчиков - чётные. в дом можно было зайти, там были хранилища. поэтому адреса и улицы остались по наследству. :) кроме того, в ii имена были неуникальны, могло быть хоть пять Вась, или 20 человек с именем All [кстати, это имя надо запретить для регистрации]. В ГК11 - имена уникальны, поэтому достаточно только указания бухты, где юзер кинул свои кости :) вместо домиков - уютные гавани, Владивосток всё-таки :)

У тебя пережиток прошлого, а у нас вполне себе средство визуально идентифицировать отправителя. Ты всё время меряешь idec своими мерками, которые подходят ГК11 и тебе, но не подходят idec. Отсюда куча каши в голове на эту тему. Лучше или разобраться или таки совсем забить на idec.

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

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

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

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

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

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

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

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

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

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

Difrex(mobile)> А какая версия го?

1.9

Difrex(mobile)> Вечером попробую у себя воспроизвести.

Буду признателен.

Difrex(mobile)> ЗЫ: приехал в Москву. Отвык я уже от метро.

А я ни разу на метро не ездил. В Екатеринбурге, когда ездил на курсы по MS SQL Server, на нём можно было доехать от вокзала до гостинницы и обратно, но я предпочёл лишний ачсок пешком прогуляться.

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> Ну и ошибку лучше обрабатывать все же.

Это тестовый пример. В ошибку попадает EOF, так что заведомо всё нормально. Вот поему слайс пустой я не пойму.

Difrex> Тут ссылку нужно передать
Difrex> _ = encoder.Decode(&d)

Да. Я там нагуглил потом. Но один фиг пустой слайс на выходе.

Difrex> Потом маршаль его и пиши в файл json. После считывания анмаршал делай.

json у меня как крайний вариант.

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

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

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

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

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

Есть затея сохранять слайс из структур в файл:

package main

import (
    "encoding/gob"
    "os"
    "fmt"
)

type count struct {
    echo string
    count int
}

func main() {
    d := []count{{"bash.rss", 100}, {"pipe.2032", 200}}
    fmt.Println(d)
    f, _ := os.Create("slice")
    encoder := gob.NewEncoder(f)
    encoder.Encode(d)
    f.Close()
}

Файл вполне себе создаётся.

А вот считать из этого файла у меня не выходит:

package main

import (
    "os"
    "encoding/gob"
    "fmt"
)

type count struct {
    echo string
    count int
}

func main() {
    d := []count{}
    f, _ := os.Open("slice")
    encoder := gob.NewDecoder(f)
    _ = encoder.Decode(d)
    fmt.Println(d)
    f.Close()
}

В итоге в d после декодирования вижу пустой слайс. Что я делаю не так?

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

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

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

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

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

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>]
<тело сообщения>

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

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

vit01> Андрей попросил видео сабжа в действии. Вот оно:
vit01> https://alicorn.tk/dashie/index.php/s/4PZLyfKTDDVSH5U
vit01> Ничего интересного здесь нет (тем более, плохонькая камера мобильника не может запечатлеть эту игру света), но просто как факт.

Не взирая на то, что камера не сняла (ну почти не сняла) то, что было на стенах, мне видео понравилось =)

> Есть div, у него задана ширина в процентах от вьюпорта, внутри длинная-длинная ссылка. Ссылка переносится, но только один раз, а потом растягивает этот div за пределы экрана. Как это можно забороть? Есть опыт?

Таки разобрался.

word-break: break-all;

И всё отображается как мне надо.

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

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

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

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

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

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

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

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

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

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

Есть div, у него задана ширина в процентах от вьюпорта, внутри длинная-длинная ссылка. Ссылка переносится, но только один раз, а потом растягивает этот div за пределы экрана. Как это можно забороть? Есть опыт?

AL>> А ещё бы полноценный git-клиент под андроид. А то в маршрутке приходится книги читать, а мог бы тратить это время на написание игрушки на инстеде. Писать есть чем вполне сносно, а вот потом пушить изменения нечем.
vit01> Порекомендую клиент MGit или его предшественника (по форку) SGit. И коммитить, и пушить, и всё остальное необходимое умеет.
vit01> https://f-droid.org/repository/browse/?fdfilter=MGit&fdid=com.manichord.mgit

Спасибо. Попробую.

vit01> Кстати, а чем тебя Termux'овский гит не устроил? Это ведь тоже вполне рабочий вариант (даже более идеологически правильный). Пробовал и остался доволен.

Как-то не очень удобно получается с ним работать без hacker's keyboard, а от последней я отказался.

Difrex> Я думаю, что нужно начинать с этим что-то делать.

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

Закладываю три вещи в это дело:

1. Реализация на python, чтобы любой желающий мог ознакомиться и внести изменения.
2. По возможности максимальная модульность реализации.
3. Настолько лаконичный и простой код, насколько я смогу.

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

Difrex> Для этого я создал репозиторий с документом в котором предлагаю общими усилиями
Difrex> разработать стандарт обмена личными сообщениями, а так же реализовать PoC сервера(ноды)
Difrex> и клиента.
Difrex> Вот этот репозиторий: https://github.com/idec-net/netmail

Хорошее дело.

Difrex> Давайте обсуждать и дописывать.

Обсуждать готов, а вот писать пока не очень.

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

AL>> Коммитнул в сабж
Anotheroneuser> Это значит, где-то опубликовал?

В внёс изменения в исходники документации по idec.

Anotheroneuser> А где?

На гитхабе.

Anotheroneuser> Я бы тоже хотел свой адрес оставить

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

Коммитнул в сабж изменение своего мыла. Старое более недоступно.

btimofeev>>> Для андроид обнаружил программку Orgzly
btimofeev> Там есть еще Dropbox, но только в версии из Google Play (или если сам из исходников соберешь). Я, кстати, ей побольше попользовался и оказалось, что она поддерживает сильно ограниченный набор возможностей org-mode. И непонятно собирается ли автор этот набор расширять.

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

vit01>> Другое дело, что следовать расписаниям и всяким спискам в целом - это неудобно и часто бессмысленно, потому что планы постоянно перекраиваются, а хотелки меняются.
btimofeev> А для меня нормально работает: память у меня не очень хорошая, так что постоянно приходится записывать todo'шки.

У меня фиг спланируешь что. Так что простые тудушки покрывают рабочий процесс.

>> Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов.
Peter> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.

Вообще, я примерно так и думаю.

Например:

image:<filename>:<base64>
audio:<filename>:<base64>

А желание не пропустить информацию, ИМХО, противоречит самой цели секты.

Peter> Идея была все-таки вот в чем.
Peter> С сообщением могут идти данные. Формат данных и что в них, мы не стандартизируем. Это просто данные, связанные с сообщением.
Peter> Поэтому детализация на таком уровне, по моему, принесет только вред. Тогда лучше остаться на том, что есть.
Peter> Просто есть дополнительная инфа. Что именно в этой информации определяет клиентское ПО. Там могут быть картинки, звук.
Peter> Ну как в современных мессенжерах. :)

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

Peter> А выбирать пропускать данные или нет нода может только руководствуясь лимитами на размер. Скажем, размер данных не больше 1Мб.

Ну тут да. Можно подумать как и что пропускать. Можно метаданные передавать ещё к каждому блобу.

>>>> Клиент видит тэг, запрашивает все аттачи по этому тегу
>>> Вот это не нравится. А если я не хочу все аттачи тянуть?
>> Тогда просто игнорируешь тег и всё.
Difrex> Не, мне кажется, что нужно что-то сделать для того, чтобы можно было по одному аттачу качать.

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

>> Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/.
Difrex> Вот это еще не особо нравится.
Difrex> Со стороны клиента мне это видится так:
Difrex> ====
Difrex> +--------------+
Difrex> | |
Difrex> | IDEC Client |
Difrex> +------>| |<------+
Difrex> | +--------------+ |
Difrex> | |
Difrex> xdata tag message
Difrex> | data
Difrex> | |
Difrex> | v
Difrex> +-+-------------+ +-----------------+
Difrex> | /u/m/gkC... | | /x/d/gkC... |
Difrex> | | | |
Difrex> +---------------+ +-----------------+
Difrex> ====
Difrex> Т.е. клиент видя соотвествующий тег лезет в /x/d/gkCo68TG1nrIXrgMklUN, получает от туда список аттачей, а затем делает еще
Difrex> один запрос /x/d/gkCo68TG1nrIXrgMklUN/attachName для получения аттача. На ровном месте мы получили 3 запроса.

Зачем третий запрос? Клиент видит тэг, запрашивает все аттачи по этому тегу. Ему приходят они. В верхней квоте ни слова про третий запрос нет. И на схеме у тебя его нет.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

vit01> Если вы видите это сообщение, значит ii-net.tk успешно переехал на новый сервер к немцам
vit01> Мне пришлось сильно задолбаться, чтобы проапгрейдить MySQL до версии 5.7 и php до 7.2
vit01> А ещё чтобы сменить lighttpd на nginx

Вот где собака зарыта! Фетчер забирал сообщения с Мира по http. Мы месяц жили с поломанным линком.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

А что случилось с сабжевой эхой? Уже почти месяц нет новостей. Могу натравить своего робота, если у тебя какие-либо проблемы с ним.

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

vit01> Услышав "PDF", я порадовался и подумал, что "для него уж точно кучу всего написали, проще некуда, найду что-нибудь". Но не тут-то было!

Вот меня как раз может ожидать работа с pdf, но из питона. И там может оказаться тоже весьма весело. По крайней мере беглое гугление показало, что граблей с PDF до сих пор много где есть, что на мой взгляд очень странно.

vit01> Где же, наконец, простое и рабочее решение для автозаполнения PDF-форм?

vit01> Вот оно: https://sourceforge.net/projects/pdfformfiller2/?source=directory
vit01> Использует библиотеку iTextPdf 5 версии, написано на Java.

Спасибо за наводку. Вполне допускаю отдавать данные сторонней штуке.

Difrex> $сабж
Difrex> Вот этот вот http://idec.spline-online.ml/x/file/nodegraph.svg не актуален.
Актуализацией надо заниматься. У нас нет актуального нодлиста, так что пока что не могу построить актуальный граф.

Скиньте актуальные сегменты нодлиста тогда.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

В очередном треде tabs vs. spaces было обнаружено прекрасное:

butlerpcnet * 5 years ago

YES! Another strong win for us Tab people! Thank you :) another disadvantage of space-indented code is what I call the "asshole" principle. If I were using spaces to indent? I could be an asshole and indent with 1 space per level! Any normal person thah opens the file would have to make sure his/her IDE or text editor is configured correctly to convert the spaces, and convert back (like you said with committing). It's just a mess.

butlerpcnet * 3 months ago

Comming back to reverse my opinion! I'm now a 4-spaces indenter!! Python 3 standard is 4 spaces, and PHP PSR-2 standard is also 4 spaces. Go away tabs!!

Я там коммитнул в сабж. У меня опять проэтосамован почтовый ящик а то.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

Anotheroneuser> На самом деле, интересная штука -- это ваше программирование. Но я никак не могу себя заинтересовать им более, чем инструментом для создания игр.. Наверное, не дано.

Программирование ради программирования это какая-то ментальная мастурбация. Нужно просто решать свои задачи. Если удаётся их решать без программирования, то жить легче значит %)

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

> И на python'е плюс kivy.

Вроде, там какие-то проблемы с третьим питоном, но для себя именно такой вариант на будущее рассматриваю. Пайтон, киви и бульдозер =)

Не хочу C++. Правда яву я хочу ещё меньше =)

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

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

AL>> Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
AL>> Ладно. Буду в музыкальные эхи анонсить.
vit01> Увеличил до 80 мб лимит. Пока место на диске позволяет.
vit01> Но файлы по-хорошему анонсировать всё равно надо. Во-первых, не все следят за файлэхами. Во-вторых, чтобы не скачивать котов в мешке, ведь иногда описания может быть недостаточно.

Ну вообще, bitjam podcast он и есть bitjam podcast =)

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL>> Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
vit01> Сначала удалил файл зиповник, а потом только увидел, что "без расширения". Скачал обратно :)
vit01> Ты предупреждай, когда большие файлы кидаешь. У меня на фетчере лимит то 30 мегабайт, то 35 на файл.
vit01> Поэтому, чтобы *все* твои файлы "доходили до адресата", мне приходится править конфиг, увеличивая лимит, потом вручную дёрнуть фетчер и править конфиг обратно.

Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)

Ладно. Буду в музыкальные эхи анонсить.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
vit01> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.

Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.

mirage>> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
vit01> Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
vit01> iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
vit01> Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.

Да все эти варианты мы уже рассматривали и обсуждали. Начиная с лета 2014 и заканчивая обсуждением расширенной u/e. Пройденный этап, откинутые варианты. Нет смысла к ним возвращаться. К тому же до сих пор не было озвучено предполагаемых преимуществ перед текущим вариантом.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

mirage> Сабж.

В данный момент это iing, но в планах переход на новый софт, который у меня подвис в процессе и будет релизнут, видимо, уже только в следующем году. Он готов, но ещё не доделан вебинтерфейс. На этот раз на golang =)

+++ Caesium/0.4 RC1

mirage> Этот x/c нужен же для u/e?

Нет.

mirage> Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
mirage> Получается не оптимально. Ведь в разных эхах разное количество апдейтов.

Да, но зато никакой дополнительной нагрузки на ноду.

mirage> А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

mirage> Решаемая задача: скачать обновление индекса.
mirage> Предложеное решение: запросить все что после конкретного ID.
mirage> Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
mirage> Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
mirage> Получается, если надо качать все обновление индекса за раз, то один запрос.

Можешь предложить красивое решение?

Вот, например, я подписан на несколько эх. Тогда я просто отправляю запрос x/c/bash.rss/pipe.2032/idec.talks и потом делаю u/e/bash.rss/pipe.2032/idec.talks/-50:50. Передавать что-то типа x/e/bash.rss/<id1>/pipe.2032/<id2>/idec.talks/<id3>?

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

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

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

Peter>>> Фехи не поддерживаются этой нодой (syscall) :)
mirage>> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
mirage> Кажется я доменом ошибся. В одной доке .tk в другой .ml
mirage> В итоге в клиенте одно, в браузере другое :)

Да. tk я проморгал =(

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.

Ещё проще так, как есть. Потому что оно уже есть и оно простое.

Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

mirage> Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.

Сколько угодно =)

mirage> Допустим это 100 idшников.
mirage> Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
mirage> 1. Придет меньше 100 id - запоминаем последний, конец.
mirage> 2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.

Этот вариант мы тоже рассматривали. Но пока думали как это сделать так, чтобы не плодить сущностей и не сломать совместимость с ii (ты до сих пор можешь взять ii-client-03 и пользоваться им), соорудили эту штуку на том, что было. Получилось просто и без излишеств.

AL>> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
mirage> Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.

Я понимаю, что предложение, но не понимаю в чём будет выигрыш? Можно и аутбаунды сделать а-ля FTN, но пользы нет.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.

Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

mirage> Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.

Как ты это видишь в текущем варианте? Как из ID получить что-то типа -10:10?

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.

Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?

mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.

Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.

+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.

AL>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.

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

А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.

+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.