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

Тем времени в контексте Organic books, как сколько появится сертификация "Органическое правительство" или "Органический совет директоров" или "Органическая служба доставки" и тд.

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

#thoughts #ai

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

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

Цифровая архивация - это довольно специфическая тема про данные которые с дата инженерией и data science пересекается только в части обучения LLM'ок и пока из всех известных мне проектов наиболее продвинутыми технологически являются те которые в этом помогают - это Common Crawl и ряд пиратских библиотек.

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

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

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

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

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

Вот примерно об этом я думаю в контексте цифровой архивации. Заодно наблюдаю как в США сейчас ренессанс цифровой архивации на фоне спасения гос-сайтов уничтоженных Администрацией Трампа и их воссозданием как общественных проектов активистами.

#digitalpreservation #webarchives #thoughts

Открытое письмо более 30 тысяч подписантов с призывом к запрету любых исследований по созданию сверхразума (superintelligence).

Дословно звучит как:
Мы призываем к запрету на развитие сверхразума, который не должен быть снят до тех пор, пока не будет
1. широкий научный консенсус, что это будет сделано безопасно и контролируемо, и
2. сильная общественная поддержка.

Среди подписантов Стив Возняк (экс-основатель Apple), Ричард Бренсон, многочисленные основатели компаний, в том числе AI стартапов, а также многочисленные политики, исследователи, представители искусств и медиа и религиозные деятели. Включая принца Гарри и его жену Меган и еще много-много других знаменитостей.

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

#readings #thoughts #ai

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

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

#python #thoughts #memories

О сжатии данных

Вначале немного общего контекста.
Один из трендов разработки ПО, игр, сайтов, мобильных приложений последних десятилетий был и остаётся рост размера самих программ и связанных с ними цифровых артефактов. Это же относится и к данным, данных становится больше, хранить их в как-есть оказывается накладно и для передачи, и для стоимости хранения, и для обработки. Собственно одна из причин появления новых алгоритмов сжатия вроде Zstandard, Brotli и др. от бигтехов в том что внутренний и глобальный запрос на повышение эффективности хранения и передачи данных есть и он давно уже перерос специализированные и академические области применения и новые алгоритмы приходят теперь не из задач связанных с академическими проектами, вроде появления алгоритма LZO, а именно из практической массовой потребности.

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

Самые очевидные правила:
1. Во всём что касается хранения структурированных данных когда нужны эталонные данные то применение одного из способов сжатия: Zstandard, Xz, GZip. Zstandard как наиболее сбалансированный по скорость/уровень сжатия, Xz для долгосрочного хранения, а Gzip для работы с инструментами которые могут не поддерживать остальные способы сжатия
2. В случаях когда нет необходимости хранить оригинальные данные - сохранять их в Parquet со сжатием в Zstd. В такой конфигурации данные остаются пригодными для машинной обработки и существенно меньшего объёма

А теперь не самое известное об алгоритмах компрессии:
1. Есть много алгоритмов сжатия гораздо лучше сжимающих данные ценой длительной работы и множество ресурсов. Тем кто интересуется будет интересно почитать о Hutter Prize конкурса по сжатию данных человеческих знаний (Википедии) где можно найти множество программ дающих качественно лучшее сжатие чем общеизвестные инструменты
2. Многие популярные архиваторы дают плохое сжатие, как в угоду скорости, так и просто из-за слабой технической реализации. Есть такие экзотические инструменты как precomp которые пережимают файлы повторно находя в двоичном потоке сигнатуры сжатых потоков, расжимая их и сжимая снова улучшенными алгоритмами. Важное ограничение в том что это всё ещё не production ready инструмент и в том что сжатый файл обяззательно надо расжимать перед использованием.
3. Но есть файлы которые можно пересжимать без потери их реюзабельности. Много лет назад я делал утилиту filerepack которая пересжимала файлы в zip контейнерах. Например, у вас накопились файлы MS Office в docx, pptx, xlsx и других форматах и есть желание их уменьшить. filerepack последовательно пересжимал все файлы внутри контейнера и сам контейнер, но делал это с потерями применительно к файлам изображений. Для презентаций и документов в 99% случаев это было приемлемо, а также в ZIP контейнерах хранятся файлы из LibreOffice (OpenDocument), файлы EPUB и многие другие. Те же приложения для Android и Apple IOS.
4. Один из способов работы с архивами - это их монтирование в операционную систему. Это позволяет некоторым приложениям не работающим со сжатыми данными, тем не менее это делать. Пример, утилита mount-zip и более универсальный инструмент Archivemount

А также существует множество других подходов, инструментов и трюков. Чем больше дискового пространства ты используешь, тем больше думаешь о том как на нем экономить;)

#texts #thoughts #data #compression

Про разговоры про мошенников которые звонят пользователям, в американских интернетах подсмотрел как делает сервис Robinhood. Они просто... никогда не звонят пользователям. Вообще никогда.

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

А ведь просто. Не надо. Звонить. Никогда

P.S. А если какой-то сервис ещё и звонит роботом, то сразу в черный список.

#privacy #thoughts

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

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

Это же к вопросу о доступе к данным/коду и тд. К примеру, выбирая между Copilot'ом и Cursor'ом для приватного кода. Дефакто Github и так имеет доступ ко всему моему приватному коду, использование Copilot'а не создает тех же рисков которые присутствуют в ИИ продуктах и сервисах за пределами Github'а.

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

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

#thoughts #ai

Я довольно давно натыкаюсь на тексты о том как же censored достал всех декларативный подход в разработке, управлению инфраструктурой, управление кодом. Есть даже уже сформировавшиеся термины такие как declarative data platforms, declarative prompts, declarative API, declarative configuration и так далее.

Что такое декларативное программирование? Это когда конфигурация ПО, правила, архитектурные блоки, часть программной логики и так далее вынесены в настройки внутри файлов в форматах YAML / TOML или их аналоги.

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

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

Лично я отношусь к YAML формату и его деривативам индиффирентно, но могу сказать что есть случаи когда декларативное программирование реально труднозаменимо.

Многие специализированные программные продукты до сих пор используют сложные бинарные форматы для переноса и сохранения файлов. Это могут быть и собственные бинарные форматы и использование ZIP контейнеров с некоторым числом разных вложенных файлов (MS Word, Xmind, Pages и десятки других).

Одна из регулярно возникающих у меня задач в том что создать диаграммы предметной области - блоков кода репозитория, структуры документа, архитектуры приложения и многое другое. И вот оказывается что ИИ агенты неплохо умеют генерировать схематичное описание в текстовых форматах вроде Mermaid, D2 или PlanUML, но как-только доходит до майндмапов то остается только генерация в формате FreeMind, а какой-нибудь Xmind остается не удел поскольку его нативный формат - это тот самый ZIP контейнер со сложным содержанием.

Чтобы ИИ агент сумел такой xmind файл сгенерировал надо приложить немало усилий. Гораздо проще сгенерировать файл Markdown который в тот же Xmind импортировать. Тогда можно получить майндмап сразу же и достаточно приближенный к ожиданиям.

Почему так? Потому что язык разметки markdown зачастую используется так же как и другие декларативные языки разметки - для передачи информации о структуре данных.

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

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

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

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

#thoughts #ai

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

Сама утилита эта работа как обертка вокруг множества приложений в операционной системе: pngquant, jpegoptim, 7z, zip и тд, но вот одна беда что она устарела и её надо было переписать.

Так что я её использовал как второй полигон для проверки кодирования с помощью ИИ (первый был с библиотекой iterabledata).

Итого:
- утилита filesrepack полностью переписана и теперь умеет две команды: repack - сжимать одиночные файлы, bulk - сжимать файлы внутри папки, рекурсивно
- добавлена поддержка множества новых форматов файлов: tiff, parquet, avi, avf, svg, gif, rtb, pages, numbers, key и других
- 90% кода написано с помощью ИИ агента Cursor'а (2-я версия Cursor, режим автовыбора моделей)
- существенные ошибки были лишь пару раз, достаточно легко они исправлялись
- у ИИ агента очень неплохое понимание контекста и того для чего сделано приложение и очень хорошие ответы на вопросы вроде "проанализируй приложение и предложи какие опции были бы полезны для его пользователей" или "предложи форматы файлов которые можно было бы оптимизировать и которые пока не поддерживаются"
- наибольшая польза, по прежнему, в автоматическом написании документации что очень удобно для всякого рода утилит и программных библиотек где не надо скриншотов и сложных сценариев.
- для такого простого практического применения ИИ агенты, действительно, прекрасно подходят и ускоряют работы многократно, а также помогают закрыть дыры в документировании, тестировании и тд.
- по ощущениям можно уже применять ИИ агенты и для промышленного применения в сложных системах, но, конечно, с существенно большей осторожностью и дополнительными мерами по верификации кода
- все в совокупности, конечно, огромный прогресс за последний год. Ранее когда я пытался применять ИИ агенты, было ощущение что галлюцинаций существенно больше чем результата.
- в любом случае джуниорам я категорически не рекомендую начинать изучение программирования через ИИ ассистенты. Что бы понимать насколько созданный код хорош и адекватен нужно уметь создавать его самостоятельно иначе можно наделать серьёзных ошибок

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

#opensource #tools #ai #coding #thoughts