В разработке долгоживущих серверов и embedded программ очень много общего.
Настолько много, что это, кажется, одна и та же задача, только для серверов добавляется аспект большого количества данных / RAM / disk.
В embedded невреден аппаратный вочдог, который работает независимо от mcu, какая-нибудь байда, которая по истечению таймаута ресетит mcu если ей это явно не отменили. типа детонатор "мёртвая рука".
В хаскельном сервере вот вскрылся интересный нюанс — если у нас приключилось что-то внутри stm, то залипнет так, что никакой написанный на хаскелле же внутренний вочдог не поможет — клинит намертво всё, при том, что далеко не все ядра, например загружены. Максимум одно. Это так-то довольно логично, но что с этим делать не очень понятно. Нужно разработать какую-то дисциплину, которой придерживаться, но она влияет на вообще все аспекты.
Кажется, что эрланговый подход, хоть и предположительно тормознее, но более положительно сказывается на живучести в силу нормальной изоляции процессов.
На хаскелле можно его эмулировать, но это надо прямо всю волю в кулак собрать, и писать не как пишется, а как надо (а хрен его знает, как надо).
Насчёт вочдога поможет, конечно, например, сишный/еще какой лаунчер — который будет форкать хаскельный процесс и управлять его рестартом, а так же работать вочдогом. Конечно, хочется не сишную, а на том же хаскелле - пока что придумываю какой-нибудь кунштюк, что бы это сделать.
Некоторые называют такую пускалку "systemd", но я хочу
1) пускать в консолях / tmux-ах и смотреть разноцветные логи, а не journalctl этот ваш
2) не исключаю миграцию (свою) на платформы, где нет systemd
3) так или иначе большой проблемы сделать такую запускалку не вижу, хотя на си будет неизящно.
буду думать, короче
Настолько много, что это, кажется, одна и та же задача, только для серверов добавляется аспект большого количества данных / RAM / disk.
В embedded невреден аппаратный вочдог, который работает независимо от mcu, какая-нибудь байда, которая по истечению таймаута ресетит mcu если ей это явно не отменили. типа детонатор "мёртвая рука".
В хаскельном сервере вот вскрылся интересный нюанс — если у нас приключилось что-то внутри stm, то залипнет так, что никакой написанный на хаскелле же внутренний вочдог не поможет — клинит намертво всё, при том, что далеко не все ядра, например загружены. Максимум одно. Это так-то довольно логично, но что с этим делать не очень понятно. Нужно разработать какую-то дисциплину, которой придерживаться, но она влияет на вообще все аспекты.
Кажется, что эрланговый подход, хоть и предположительно тормознее, но более положительно сказывается на живучести в силу нормальной изоляции процессов.
На хаскелле можно его эмулировать, но это надо прямо всю волю в кулак собрать, и писать не как пишется, а как надо (а хрен его знает, как надо).
Насчёт вочдога поможет, конечно, например, сишный/еще какой лаунчер — который будет форкать хаскельный процесс и управлять его рестартом, а так же работать вочдогом. Конечно, хочется не сишную, а на том же хаскелле - пока что придумываю какой-нибудь кунштюк, что бы это сделать.
Некоторые называют такую пускалку "systemd", но я хочу
1) пускать в консолях / tmux-ах и смотреть разноцветные логи, а не journalctl этот ваш
2) не исключаю миграцию (свою) на платформы, где нет systemd
3) так или иначе большой проблемы сделать такую запускалку не вижу, хотя на си будет неизящно.
буду думать, короче
В начале этого всего я не хотел делать по возможности TCP, думал (где-то с 2018 - 2019), что можно обойтись без него. Потому, что считал, что TCP это большой геморрой, связанный с управлением ЖЦ соединений, особенно в P2P системе. Теперь, по прошествии лет, могу сказать, что на самом деле TCP это большой геморрой, связанный с управлением ЖЦ соединений, особенно в P2P системе.
И конечно, могу сказать, что цикл REPL в трое суток это лучше, чем REPL вида (поставил GPS трекер на автобус - отпустил автобус - автобус пропал с радаров из-за бага - ездишь на машине по тамбовской области и ищешь автобус, что бы посмотреть, что с трекером) — но всё равно напрягает.
В соседних чатах продолжают жаловаться на ущемления со стороны гитхаба, и атаку клоунов ботов на опенсорсные репозитории, где (видимо написанные на js) краулеры AI кладут опенсорсную инфраструктуру, вроде sr.ht
Не то, что бы P2P подход решал этот вопрос полностью, но он точно решил бы его как в моменте, так и в перспективе — т.е если отключить HTTP для получения деревьев, то ботописатели будут вынуждены пользоваться фреймворком, который балансирует нагрузку по пирам.
Кроме того, везде, где возможно спроектировано так, что бы основную нагрузку нёс запрашивающий.
Занятно, что текущая ситуация с AI ботами отличается от поисковиков двумя вещами:
1) поисковики удушили свой собственный поиск по исходникам (т.к. он не в их интересах)
2) криворукость нынешних ботов, которые просто кладут на соблюдение всяких приличий (robots.txt)
Не то, что бы P2P подход решал этот вопрос полностью, но он точно решил бы его как в моменте, так и в перспективе — т.е если отключить HTTP для получения деревьев, то ботописатели будут вынуждены пользоваться фреймворком, который балансирует нагрузку по пирам.
Кроме того, везде, где возможно спроектировано так, что бы основную нагрузку нёс запрашивающий.
Занятно, что текущая ситуация с AI ботами отличается от поисковиков двумя вещами:
1) поисковики удушили свой собственный поиск по исходникам (т.к. он не в их интересах)
2) криворукость нынешних ботов, которые просто кладут на соблюдение всяких приличий (robots.txt)
Удаление из нового сторейджа сделал, работает быстро, потому что удаление это добавление. удивительно, сколько вылазит сразу неочевидного, например "добавили удалили добавили удалили добавили..." - короче это CRDT со счётчиком удалений + несколько оптимизаций в моменте (которые мешают жить потом). Теперь вот думаю, как сделать компакцию этого всего, да так, что бы онлайн работало, да автоматом запускалось, да кукухой не поехать, да файловые дескрипторы бы не вытекли и в корку бы не падало ( mmap-нутые файлы в хаскелле умеют/могут)
А нельзя ли принять какой-то закон, что все российские сайты обязаны быть в домене .ru ? а если не в домене .ru то не имеют права запрещать доступ с иностранных ip. Ну либо закон, обязывающий firefox запускать разные инстансы с разными настройками прокси, но firefox пошлёт, конечно же.
Вообще можно сказать, что компакция в реальном времени/инкрементальная не сделана в разных БД не потому, что они придурки и не осилили, а потому, что это очень непросто и порождает проблемы, которые не хочется решать иммутабельных системах, напротив, от этого всего хотелось как раз уйти. Даже из того, что сходу видно там (с реальным временем) порождаются дичайшие гонки, и решения в стиле "делаем так, а если к концу действия произошло вот это — то откатываем операцию целиком". Чот too much для наколеночной БД. Короче, я пока придумал только половину инкрементальной компакции в реальном времени, а вторую чот никак не могу.
На чём бы можно было помоделировать сторейж, например? TLA+? допустим? т.е допустим сделать некую модель, проверифицировать алгоритмы, а потом из неё сгенерить код. Не сэкономило бы это время, по сравнению со "сделал - частично работает - сидишь отлаживаешь". Т.е есть ли реальные кейсы, как применение подобных инструментов сэкономило время?
Заставляем LLM обучать нас TLA+ -> вместе пишем модель -> генерим код в рамках имеющихся примитивов -> заставляем модель проверять соответствие модели коду -> профит. Кто-то уже пытался?
Говорящая собака подогнала почитать: https://lamport.azurewebsites.net/tla/book.html
Что бы дать отдохнуть мозгам, решил сделать бота для печати анкет для аэроклубов. ознакомился с 152-ФЗ и у меня много вопросов. Ну так-то конечно быстрый вывод после ознакомления — данунегонахуй, особенно бесплатно. Второй вопрос — а что, вот те крупные всем нам известные операторы персональных данных от которых данные утекают прямо в день появления — и потом нам звонят из службы безопасности сбербанка — они какую-то ответстенность за это несут/понесли? Или им можно? Ну и третий вопрос — а не цирк ли безопасности ли это всё и не инструмент ли вытеснения мелких игроков с рынка.
Попробовал typst вместо xelatex. Работает очень быстро, только не работает. При попытке вставить страницу из PDF, или сам PDF в качестве бэкграунда моментально обосрался. Ну и сам синтаксис наводит на мысли. Ну мысль строго одна — не пытайтесь изобретать синтаксис, будет только хуже. Впрочем, какая разница, какой синтаксис, если всё равно что нужно не работает. На гитхабе рекомендуют сконвертировать PDF в SVG или еще куда. Попробую, но уже понятно, что скорее всего будет xelatex.
У кого-нибудь не завалялась хаскельная функция склонения имён? ну типа
Пупкин Василий -> Заявление от Пупкина Василия. аналог petrovich. Буквально все доступные мне LLM облажались написать рабочий код. Придётся или вникать или кто-то уже сделалИтого, petrovich почти переписан на Haskell с утра (с точностью до того, что я перемудрил с типами и не могу сделать интерфейс). Может завтра добью. от LLM пользы почти не было. Это как если микроменеджить совсем джуна. Странно, на других задачах ( SQL с обвязкой) было лучше. Сделал эвристику вывода гендера получше вроде, чем в исходном на Go - там только по отчеству, я сделал с весами по всем частям имени)
Ну короче в первом приближении порт petrovich работает
hbs23://5kQb6z3SJ9jdHEebtWJMPKg8ENguA9xUaUHypAFkBS53
оформлять как-то пока что не до этого, но если вдруг кому надо то вот
hbs23://5kQb6z3SJ9jdHEebtWJMPKg8ENguA9xUaUHypAFkBS53
оформлять как-то пока что не до этого, но если вдруг кому надо то вот
А вот помните, я хотел делать 9P потому, что простой и красивый, но по факту стали делать на fuse, потому что "все используют fuse", "быстрее запилить" и "быстрее будет работать" ?
Что по факту: 1) не работает на задаче 2) не проще (т.к. не работает на нашей задаче хрен знает почему и надо отлаживать выяснять) 3) быстрее не будет, т.к. fuse точно не место в демоне, но при этом оно в демона ходить будет по RPC, т.е что так по сети что сяк по сети (и об этом я сразу не подумал).
Какой-то отсюда надо вынести урок, но урок который я вижу — если нормально то давай, а если говно — то не надо. Проблема в том, что пока не попробуешь - не поймешь.
Надо было брать 9P оно красивое, жаль, что мёртвое. Но простое, можно с нуля написать и поддерживать. Но по факту и hFuse много лет никто не поддерживает — т.е если ориентироваться не на интуицию, а сначала выписать факты в табличку — то может быть сразу бы принял правильное решение. А может нет. Короче, интуиция сначала не подвела, а потом подвела. Нельзя никакие решения принимать интуитивно.
Что по факту: 1) не работает на задаче 2) не проще (т.к. не работает на нашей задаче хрен знает почему и надо отлаживать выяснять) 3) быстрее не будет, т.к. fuse точно не место в демоне, но при этом оно в демона ходить будет по RPC, т.е что так по сети что сяк по сети (и об этом я сразу не подумал).
Какой-то отсюда надо вынести урок, но урок который я вижу — если нормально то давай, а если говно — то не надо. Проблема в том, что пока не попробуешь - не поймешь.
Надо было брать 9P оно красивое, жаль, что мёртвое. Но простое, можно с нуля написать и поддерживать. Но по факту и hFuse много лет никто не поддерживает — т.е если ориентироваться не на интуицию, а сначала выписать факты в табличку — то может быть сразу бы принял правильное решение. А может нет. Короче, интуиция сначала не подвела, а потом подвела. Нельзя никакие решения принимать интуитивно.
Вернул не-IT блог. Собственно снёс-то я его из-за неприятной реакции со стороны определенного сообщества, но если здраво рассудить - то надо бы было просто послать всех любителей перемыть кости за глаза нахрен, как и буду поступать в дальнейшем, ну а тогда это была запоздалая попытка сбить волну. В общем, по заметки по филлипинской поездке и дайвингу вообще здесь - https://t.me/genedrd47r
как понять, что у кандидата большой опыт в области блокчейна : в качестве уточняющего вопроса он пытается выяснить, кого посадят в случае реализации той или иной фичи если что.