Work & Beer Balance

Мне сегодня пришло письмо что тридпати провайдера metabase, среди клиентов которого Framework, ломанули через 0day уязвимость.
Доставерно известно что выкачать успели

- Full name
- Email address
- Login IPs
- Billing and shipping address information
- Country
- Address
- City
- State
- Zip code
- Phone number
- Company

Хирово

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

Не приятно, но че с этим делать не придумал еше

анекдот. Решил я значит посмотреть на этот антигравити в целом и последний gemini flash 4.6 hight.
Есть определнные люди которые говорят что он ничего для не сложных задач так что я решил дать ему шанс.

Дал самую простую задачку - включать определнную анимацию по условию - в отдельном ворктрии и отдельном бранче.
Через 5 минут внезапно у меня намерктво стал зависать намертво godot, жрет 130% cpu при этом. в основном worktree.
При этом гит чистый, откат не помогает

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

Gemini решил что он умнее всех и сделал ХАРДЛИНК на такую же директорию из основного worktree в свой так что godot рекурсивно обходя директории зацикливался XD

Был ли у вас такой опыт: вайбкодишь какой-то пет проект, все работает но код сплошные монолиты и файлы на 3000+ строк.

Решаешь это все отрефакторить, раскладывает все по слоям, single responsibility, дедупаешь код, т.е. базовый минимум читаемого кода добавляешь

Итого - сжёг недельный лист за день, код красивый, минус 4000 строк кода, +190 новых файлов.

НО перф упал так что заметно невооружённым глазом!

И так каждый раз.

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

Запустил тесты vitest через bazel. вот это все - кушает джава

keychron выпустили что-то типа трекбола но с колесом вокруг него и... не могу понять мне это надо или фигня какая-то

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

C:\Dev Files\DUNE3\olddata\3ddata\Units\AT_mongoose_high.TXT
I:\Dev\Dune3\Art\Vehicle\Textures & XAF's\Atreides\AT_minotaurus_Low.txt
I:\Dev\Dune3\Art\Vehicle\Textures & XAF's\Harkonnen\hk_assault_High.txt

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

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

(док прикрепил)

О, выложили тест батарейки framework pro
https://youtu.be/bLYUD4IMvQI?is=N7WZp5FD6kE3hukw

Теперь о веселом - вчера прям жестко заcтрял на юнитах которые поливают противника огнем или газом.

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

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

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

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

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

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

Давайте спросим себя, какие навыки отличают человека который полагается на удачу при разработке с помощью LLM (то чего мы не хотим в рабочем проекте) от человека который контролирует процесс?

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

Я думаю что у меня есть некоторые идеи на этот счет:

Ключевой становится способность понять что предлагает LLM. У вас бывало что вы полезли не в свой домен и в какой-то момент лмм отвечает вам "тарабарщиной" и просит выбрать один из двух вариантов?

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

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

Как это проверить?

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

Криминализация приватности и безопастности идет полным ходом.

За удаление данных на телефоне теперь судят как за уничтожение потенциальных улик.
А GrapheneOS уже де-факто вне закона - ее обладатель автоматически считается минимум наркодиллером, и даже покупка Google Pixel сразу привлечет внимание полиции к покупателю в таких странах как Испания или Франция.

А помните в 2009 году, когда в Великобритании человека наказали 13 месяцами заключения за отказ дать ключи от зашифрованных PGP контейнеров, не доказав, что внутри них вообще было что-либо преступное?

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

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

Если вы вдруг не в курсе - пакет законов под зонтиком Chat Control 2.0 которй уже пару лет пытаются пропихнуть (под сусом "защиты детей по педафилов" конечно же) изнчально преполагал end-to-end шифрвоание привелигерованной технологией для военных и политиков (это придумавших), а для остальных такой трафик должен быть распознан и забанен как нелегальный.

Паралельно с этим есть еще один проект "Lawful and Effective Access to Data for Law Enforcement" суть которого в том что каждый софт с шифрованием обязан иметь бэкдор для "хороших ребят"

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

Вся разработка ведется в открытом репозитории на github Akiyamka/EmperorReborn, а декодер звука был доабвлен в PR 111

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

Уже ночью я залогинился в вебверсию клоды чтобы посмотреть на стату как мне антропик выдал "награду" - $100 кредитами на фейбл. Я уже знал на что я их потрачу - задача со всеми логами и моими комментариями была отдана фейблу и через 7 минут загадка файла созданного 25 лет назад была разгадана

...функция по адресу 0x472520, которая переводит запись BAG в дескриптор звука. Она подтвердила, что Compressed (бит 3) сам по себе выбирает format type 1 (флаг Unk ни на что не влияет — вопрос из finding #7 закрыт). Но главное — она копирует в дескриптор 16 «хвостовых» байт 64-байтовой записи таблицы, которые мы считали паддингом. Первый из этих u32 (смещение +48) — размер блока: 512 у всех сжатых записей, 1024 у одиннадцати (47-UA*).

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

Соннсет пытался математикой выкорелировать какие-то закономерности на сравнении референса с файлом но успеха не было.

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

Через несколько часов соннет начал сдаваться (md файл с поменетсками о том что было испровбовано и что нйадено уже первалил за пол тыщи строк) и выдавать мне после каждого действия выбор:

1. Признать что мы не можем распаковать этот фомрат и отложить на потом или найти замену (рекомендую)
2. Продолжать попытки не смотря ни на что

Уговорить его что-то вообще делать становилось все сложнее : )

Честно: это уже далеко не "один шаг" — трассировка до конца может занять ещё много часов без гарантии результата, а объём кода (виртуальные вызовы, сложные структуры) заметно больше, чем в decode-функции, которую я уже разобрал.

Исследование сети в целом и гитхаба в частности показало - я не первый кто тут споткнулся:

- Vladan Bato автор AUD2WAV.exe распаковать их не смог. В реадми он оставил такую заметку

The common one is standard IMA-ADPCM (shift 3, i.e. `DIVISOR=8`) and his tools handle it. The other, used for 8-bit sounds like death screams, is "Westwood's proprietary compression and I don't know how it works"

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

The format of 0x0C WAVE files (CMP) in Dialog.bag is still a mystery to me"* — `0x0C` = 12 = `Compressed | Is16Bit`, i.e. exactly this codec. It exports these entries as an unplayable `.CMP` file rather than a real WAV

- Уже соременная попытка от IceReaper [ebfd-re](github.com/IceReaper/ebfd-re) увенчалась частичным успехом

Audio: Mostly working, but compressed files have a continuous noise.

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

Итого за 25 лет так никто и не смог доконца распаковать эти файлы

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

Все звуки игры хронятся в .bag файлах - довольно примитивном архиве который был быстро вскрыт.

Хранит он разную солянку - моно, стерео звуки, wav, mp3 и тп.

Среди всего этого понятного разнообразия есть файлы (674 штуки) которые по названиям очевидно содержат голосовые линии юнитов (voice line feedback)

И вот их распаковать никак не получаеься никаким из известных кодеков.