по postgresql я подобного не нашёл, но для mysql/mariadb есть ли какой-нибудь набор статей "mysql для полных дебилов"? без php, без sql - чисто "как запустить, как подключаться, как создать юзеров" и подобное? хотя бы пример как из консоли этим хозяйством пользоваться - без увязания в дебри конфигов, кроме как "перебиндить базу"?

я вот поставил mariadb-server в openbsd, хотел какую-то фигню для него сделать, которая на 127.0.0.1 висит - так он даже адреса такого, вроде, не видит. и юзеров нет, и паролей нет, и чем дальше погружаешься, тем больше непонятной информации тебя спрашивают.

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

как запустить - я знаю. но, например, в openbsd он даже не видит хоста из php-приложения, и непонятно, что ему нужно.

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

там даже номера какие-то странные у сообщений - 9 символов или около того...

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

а насколько просто использовать из этих стилей меню, кнопки и обрамления окон? если просто взять стиль и начать шлёпать? :)

хочется, чтобы в netsurf эстетично выглядело. :)


> Какие не прорисовываются? И какой конкретно стиль имеешь в виду?

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

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

Проект Uliss:
- тот же ii, только с блоками вместо цифровых эх. с английским интерфейсом. и сервер и клиент будут единой программой, которая сможет работать и так и так

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

Проект Patrokl:
- что-то типа распределённой вики-портала-что-то-подобное. Для коллективного написания и синхронизации. В первую очередь - для самого проекта odii, чтобы вести там документацию по openbsd, debian и проекту 'odii'... возможно, как-то будет заточено под перевод текстов. Тоже есть уже куча наработок - надо собрать воедино во что-то цельное.

Вот, примерно так.

я есть....

кстати, всем, кто хочет людей - подписывайтесь на ii://hc.51 - там есть жизнь :)

25 марта 2014 года общественность взбудоражил выход ii 0.1

смахнуть скупую слезу можно здесь:

https://www.linux.org.ru/news/opensource/10319264

http://www.opennet.ru/opennews/art.shtml?num=39418

тест

я живой. раз 20 пытался сюда написать - да и сейчас еле залогинился. писал на @ii-net.tk, дали отлуп. писал на spline@ - нет ответа. других способов регистрации не нашёл. и только сейчас нашёл свой ключ.

дважды проезжал мимо Иркутска, но так и не смог закинуть сюда сообщение

> Ура, есть люди! Привет :)

Здраствуйте, друзья, кого видел или нет. :)

> Что у тебя хоть нового? Давно не заходил сюда.

я ж говорю - заходил :) но у вас тут закрытый клуб, что даже обладателю дома №2 по проспекту Мира - милиция на входе шлагбаум закрывает :)

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

hg clone http://hg.51t.ru/ii12/

который использует старые url для запроса, но идентификаторы 12-символьные и эхи определяются не ЭХА.ЧИСЛО, а :ЭХА. полагаю, так всё можно и оставить, и подобную схему - научить понимать клиенты (кстати, а где ссылка со всеми актуальными клиентами?), для совместимости.

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

Qt-клиент - это вот это?

https://github.com/vit1-irk/iicli-modular

> У нас куча клиентов, в них стоят проверки (хотя в сишном и qt они точно отсутствуют). Да и не особо это важно: было всегда 20 и не мешало.

просто тут 2 варианта:

1. делать форки всех клиентов - тогда будут одни и те же клиенты, но под разные сети
2. научить клиенты использовать оба стандарта

> Теперь подробнее рассказывай, как ты будешь обеспечивать безболезненную жизнь с миллионом сообщений в эхе :)

я уже писал об этом в bosfor - так же, как в nntp или в fido с rescan - забираем только последние n сообщений. либо количественно, либо отслеживаем новое поле таймштампа "прибыло на станцию" и отслеживаем по нему. в любом случае, клиент должен уметь изменять глубину запроса (нужны ли ему болталки за 10 лет), и после этого сообщения должны загружаться в правильном порядке.

собственно, всё это уже работает в bosfor, вроде и в ii12 это работает (не помню)

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

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

> Это же главная архитектурная проблема ii, если мы помним.

у ii не может быть архитектурных проблем, это была проба пира, набросанная за 20 минут "давайте мы вот так попробуем и покрутим, а потом сделаем, как надо". была бы нужда - были бы и iii, и iiii :), но вроде текущая реализация и достаточно простая, и полностью меня устраивает (есть даже нашмётки для NETMAIL, но это - после)


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

покажите хоть одну ноду с регистрацией, на случай потери ключа

Андрей, а у тебя через веб-интерфейс писать можно?

ничего пока не пробовал - только разбираюсь :)

> В моих клиентах проверок на длину msgid (и не только длину) нет. Есть только проверки на эху (если в строке есть точка, то это эха), но могу добавить двойной фильтр, если что.

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

> Если на сервере за время до фетча появились сообщения в количестве больше n, то клиент не сможет их зафетчить.

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

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

я уже где-то показывал, как работает acceptts. у меня на этом принципе полные бандлы срезов для bosfor делались. но бандлы для 10000-1M сообщений генерировать очень долго, поэтому в gk11 бандлов не будет, принцип старый - сначала списки с msgid, потом сами сообщения. и не нужно хранить acceptts для каждого сообщения, нужно хранить для каждой эхи. в любом случае, это всё заботы клиента.

> Но нодам при синхронизации и парсинге нужно работать с полным списком сообщений

не обязательно. я вот смотрю на станцию ii-net и spline, и вижу, что там разное количество сообщений в pipe.2032 :) пути синхронизации неисповедимы, я спокойно на "тыще последних" гоняю

> Можно делать таймстамп последнего обновления эхи и/или преобразовать файл echo/<название> на ноде в формат msgid:ts\nmsgid:ts.

у bosfor был ключ appendts, который вместе с запросом выдаёт и ts синхронизации сервера
ты его сохраняешь, а при следующем синке делаешь запрос /acceptfrom/СОХРАНЁННЫЙTS

но это уже на усмотрение клиента. сервер это добро поддерживать будет (из 1000 способов босфора в gk11 останутся только несколько наиболее простых, а как это будет использовать клиент - это уже его дело). самый простой способ - запрашивать список с n последних (рекомендации по трафику может выдавать и сервер, показывая трафик за последние дни)

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

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

> Но я имел в виду другую вещь. Предположим, элементов в эхе 100 000. Когда серверное ПО пытается распарсить список из 100 000 msgid, оформить это в виде массива, выделить для всех элементов память

до 2 млн волноваться не стоит. а когда будет 2 млн - тогда уже будут возможности для любой инфраструктуры :)

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

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

200000 - это смешной размер

from random import randint, seed

seed(0)

a = ['000000000000'] + [str(randint(100000000000,999999999999)) for _ in xrange(200000)]
print 'generate 200000 a'

b = [str(randint(100000000000,999999999999)) for _ in xrange(200000)] + ['000000000000']
print 'generate 200000 b'

a = set(a)
b = set(b)

print 'convert to set'

print a & b

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

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


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

> Посмотрим что Рома скажет. Технологию то он разрабатывает.

технологию ii я уже давно разработал и 4 раза забыл, поэтому это не ко мне вопросы

в моей сети суть такова, что всё это - на усмотрение клиента, а сервер будет просто сервером

ещё один нюанс:

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

поэтому запрос

http://bb.51t.ru/bb/echo/besedka:obsd:humor/lim/50/fmt/msgid

даёт 50 сообщений, которые просто расположены в тех эхах: http://bb.51t.ru/bb/echo/besedka:obsd:humor/lim/50/fmt/flat (если не указывать эхи - то это будет просто 50 последних сообщений станции)

реализовывать режим "как в ii" я не буду, поскольку и полные коллекции эх не очень нужны, и сервер усложнять смысла нет: да, будет режим, выдающий "msgid:echo", вместо "msgid", но это - опционально. то есть, тут клиент сам будет разбираться - или он будет делать по timestamp, или запрашивать n сообщений в каждой эхе отдельно, или брать просто n сообщений со станции. все сообщения в эхе клиент должен забирать только по запросу пользователя (кому нужны rss-новости за 2014 год?), а в остальном - клиент должен быть умнее. а сервер - тупым, как пробка, и быстрым, как пробка.

ps. что-то та станция постоянно отваливается - сейчас написал ответ, а отправить не смог, "сервер не отвечает"

да, при этом логику клиентов придётся менять - либо действительно использовать msgid:echo, чтобы проверять "есть ли сообщение в эхе", либо брать msgid, но проверять не "есть ли в эхе", а "есть ли в базе"

различия незначительные в серверной части

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

>> различия незначительные в серверной части
> Кстати, ты исходники серверной части откроешь?

босфор я где-то тарболил. ii12 - доступна. gk11 - это нечто среднее между ними. собственно, единственное, что там осталось - это утвердить стандарты url-ов (ну и, поскольку хочется сделать площадку и для ретро-компьютеров - я сделаю flat-версию, которая нормально работает в netsurf, links grapics, lynx и т.д., за основу возьму сайт OpenBSD, но это уже отдельный проект) и удалить лишние реквесты из босфора

лицензия будет та же - Public Domain

как только соберусь сделать - так сразу и сделаю :) надо только все наработки откопать, собрать в кучу, и выпилить из них Буратину :)

14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)

ii12 сделана на текстовых файлах

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

> Оно будет сильно загружать процессор и ЖД.

жаль, pentium 150 умер. я бы запустил на нём ноду :)

текущая реализация как раз неоптимальна, и точно загружает процессор и ЖД. первая версия ii (которая была сразу после ii на json) была сильно оптимальная, но не была совместима с фетчерами :)

ii пусть остаётся. но лучше и её перевести на формат ii12, чтобы оно было совместимо полностью

>> 14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)
> Но это же ооочень долго =) и просто недопустимо. 2-3 секунды - максимум для комфортной работы.

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

а для синка "все со всеми" - и 15 секунд нормальное время. он будет отрабатывать раз в сутки, если будет необходимость. если нет - раз в неделю. всё остальное время - оперирование более короткими списками

есть ли хде самый полный список эх? а то в веб-интерфейсе - не все ;(

Андрей, переименуй меня, пожалуйста, с 51t на Рома или Рома Яковлев или Roman Yakovlev

btw, а карбонки в голдеде будут? :)

>> есть ли хде самый полный список эх? а то в веб-интерфейсе - не все ;(
>Только у сисопов. Я вон себе давно уже BSOD поставил на http://ii-net.tk/ii/echo/ =)
>Могу припомнить из своих более-менее новых только архивную ii://hc.51, lenta.rss.15.* до 6 и ii://clop_r.34 (только не читай её, там куча бреда).

в первой нет новых сообщений, во второй - rss (rss-эхи не интересуют), третью не рекомендуют читать :)

какие есть ещё живые эхи (но не rss), которые есть на всех станциях?

и ещё со стандартами не понятно - босфор 8 значный, гк11 - видимо, будет 12-значной (а мож оставлю 8-знаки, не знаю ещё - как-то мы так по стандартам взаимодействия ничего не решили), ii - 20значная... начать сейчас что-то гейтовать - потом опять всё переделывать...

>Мы просто уберём проверки на длину, и всё будет работать.

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


>Только вот интересно, что именно гейтовать? А то, смотрю, у тебя на том сайте домен истёк.

куда истёк? http://bb.51t.ru
эхи :besedka, :obsd, :humor - все вроде живые

>> в гейте?
>Не только в гейте, а вообще на ноде. На длину msgid.
>Либо можно сделать их нестрогими (от 8 до 20, к примеру)

у меня тоже была такая идея. вот и надо всё тщательно взвесить - к каким проблемам это приведёт, какие палки в колёса влезут, и так далее... понять, является ли это лучшим вариантом. первый недостаток, который я вижу - bosfor не умеет ничего, кроме 8 символов, и если скормить ему 20 - подавится :) но босфор может фетчить ii - но дубли опять же будут (нужна политика по дублям: являются лисообщения AAAAAAAA и AAAAAAAAAAAAAAAAAAAA идентичными. если да - то зачем нужна 20-знаковость. если нет - то как фиксить дубли?). в общем, тут надо детально разбирать проблему

>> куда истёк? http://bb.51t.ru
>Был же более короткий hc25.ru, он и истёк.

hc25 - это хоккейный. он был объявлен "устаревшим" ещё в начале года.

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

в passthru заведи, мож кому из даунлинков понадобится :)

три новых песни - на http://osole.51t.ru

>> первый недостаток, который я вижу - bosfor не умеет ничего, кроме 8 символов, и если скормить ему 20 - подавится :)
>А вот это уже реальная проблема. Тогда предлагаю всем нам убрать фильтры, чтобы по-честному, а длину msgid оставить на собственное усмотрение.

bosfor будет жить до релиза ноды ГК11. после чего будет прибит. а нода ГК11 рождается сейчас, чтобы там всё было по уму... и чтобы всё было по уму - надо тщательно продумать, где будут проблемы.

собственно, у меня осталось только 3 финалиста: 8-значная нумерация, 12-значная нумерация и произвольная 8-20 символов. из них и выбираю.

>> в passthru заведи, мож кому из даунлинков понадобится :)
>У меня из даунлинков только Rush_Pon, а ему эта эха уж точно не нужна =) Difrex же сейчас в отпуске, без сети отдыхает.

появятся. эх с живыми людьми и так мало :)

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

>> три новых песни - на http://osole.51t.ru
>Хорошо песни делают =) Аж 3 сразу

юбилей, 20 лет. песен будет ещё больше, как я понимаю. сколько именно - не знаю :)