На выходных чисто ради освежения памяти решил накодить обедающих философов. Вроде задачка из учебника (про дедлоки, если кто не помнит), миллион раз обсужденная в литературе, блогах и т.п., должно быть приключение на 20 минут, да? Читаешь описание задачи, описание проблем и решения — вроде все просто и понятно.

Однако после непосредственно программирования вскрывается, что и условие, мягко говоря, не очень точное/полное, да и описания решений умалчивают о куче нюансов и/или имеют неясности. Я очень долго вникал в решение от Дейкстры, и еще дольше — в статью Чанди-Мисры с универсальным решением. И не могу сказать, что я на 100% понял, как они должны работать, и как стыкуются с изначальными неясностями в условии. Я более чем уверен, что налажал с их реализацией. По Чанди-Мисре смотрел готовый код и там все в итоге сводилось к переизобретению упорядоченных ресурсов. И в итоге лучшим оказалось одно из простейших решений.

А еще примитивы java добавили веселья: семафор, которому можно бесконечно увеличивать количество разрешений — ну, такое.

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

Код можно посмотреть тут.

Кого не разбудил шторм недельной давности — Mozilla убрала из документации Firefox пункт про то, что она не продает никому ваши данные. В целом принцип “если вы что-то получаете бесплатно, то продукт — это вы” выполнен, вроде ничего удивительного (ну а так же “ты либо умираешь героем, либо живешь достаточно долго, чтобы стать злодеем”). Напоминает ситуацию с телегой, которая обещала всегда быть без рекламы, хотя продажа данных — немного другое.

В целом, от Mozilla и до этого доносились не очень хорошие новости — сокращения сотрудников, уменьшение поддержки раста и нового движка, сомнительные зарплаты топов при плохих показателях и т.п.

Почему то, что случилось, не очень хорошо — вам и так уже каждый утюг проорал. Но есть и попытка чуть более объективно взглянуть положение вещей: в статье пытаются выстроить “линию защиты” для Mozilla, где вывод примерно сводится к тому, что чисто теоретически, это юристы лютуют, пиарщики обосрались, но есть шанс, что не все так уж и плохо.

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

Интересно, как отреагируют дистрибутивы Linux, во многих из которых ФФ — браузер по умолчанию.

SWE-bench — это бенчмарк на основе ~2300 реальных тикетов и связанных пулл-реквестов из 12 GitHub репозиториев на питоне. Его часто используют для того, чтобы заявить, что скоро нейронки заменят прогеров: например, недавний Claude 3.7 показал в нем аж 70% (в то время как у текущих рекордсменов — 49%). Бенчмарк изначально задумывался как способ проверки решения “реальных” проблем в реальных проектах.

Вообще, вопросы к репрезентативности должны возникнуть уже на стадии более подробного описания/аннотации (только питон, 12 реп и т.д.), но для своего времени (полтора года назад всего) бенчмарк был хорош — лучшая модель в нем набирала меньше 2%. А вот год спустя появилась статья с качественным анализом бенчмарка.

Результаты получились довольно яркие:

• в 33% случаев решение можно было довольно тривиально вывести из условия (например, решение было предоставленно в комментарии к тикету);
• в 31% решений были хреновые тесты (и “решение” хоть и проходило тесты, но было неполным/некорректным);
• 94% тикетов были созданы до даты отсечки знаний LLM (т.е. датасет нейронки потенциально мог включать в себя PR, закрывающий тикет);
• для всех задач были тесты -_-

Соответственно, если улучшить тесты/условия, то и проценты в бенчмарках будут на порядок ниже. Вот такие маркетинговые пироги :)

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

Захотелось потешить свое эго и вывести красиво список своих PR.

Попробовал несколько готовых страничек, но они все были унылы в той или иной степени (я конечно все понимаю, но смотреть сгенерированный сториз — ну, такое).

В итоге сделал свою. Причем включил максимальный уровень лени и сделал это чистым promt-инженерингом: все написал ChatGPT за 7 коротких промптов, я ни строчки в коде не тронул.

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

В продолжение поста про кроссплатформенность bash: даже если вы проверили скрипт каким-нибудь shellcheck на совместимость с POSIX, это не значит, что он будет работать на всех POSIX-совместимых платформах. Это даже не значит, что работать на всех современных POSIX-совместимых платформах, потому что есть какая-нибудь z/OS для мейнфреймов, которая вышла 1,5 года назад, и которую кто-то даже использует.

Очевидно, что у POSIX есть несколько версий стандартов, причем последняя — аж от 2024 года! Изменения не очень впечатляющие — всякие API для C11, флаги к командам, которые и так уже были, удаление устаревших API и т.п. Т.е. это скорее фиксация текущих распространенных практик, чем изобретение чего-то принципиально нового.

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

Но не все так просто. Есть и более адекватные причины ограничивать размер пароля:

• DoS (тратим много лишнего CPU на хэширование пароля из миллиона символов и/или ваш сервер не может обработать запрос больше мегабайта).
• Атака на переполнение буфера (в ваш массив на 256 байт, которого хватит всем, запихнули 257 символов).
• У алгоритма хэширования могут быть ограничения. Знали ли вы, что у bcrypt есть ограничение на длину и что это реальная проблема даже в современных реализациях?

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

Но чаще всего ограничение сверху это чья-то ошибка, потому что обычно это не 50-100 символов, которые могут быть адекватными, а 16-20. Больше дебильных правил можно найти тут.

P.S. Если спросить ChatGPT про то, зачем ограничивать длину пароля, никакого намека на ограничения алгоритма он вам не даст.

В топ-3 статей Хабра за январь — статья, написанная ChatGPT. Где-то наверху рейтинга за ту же неделю — статья-жалоба, как все стало плохо. Примерно через 2 часа, как я пролистал первую, выходит еще одна — Хабр мертв, где анализируется еще одна статья из недельного топа, написанная нейронкой.

В прочем, ничего нового. Подобные статьи о том, как все стало плохо, выходят регулярно. Мертвый интернет все-таки, что вы хотели.

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

Если с какого-то HackerNews я достаточно регулярно публикую что-то в #утюг, то с Хабра в 2021 году репостнул штуки 3, в 2022 пара статей пришлась в тему/подкинули идею, в 2023 была топ-статья про ICMP-туннель, а в 2024 — вообще ничего.

Кажется, пора бы уже на научные статьи переходить, пробовал года полтора назад поиграться с фильтрами на arXiv, но слишком много результатов, которые непонятно как фильтровать, да и хочется все-таки более практически применимого материала. Так и и не понял, где смотреть хорошие статьи :(

После эксперимента с OpenRewrite планировал посмотреть что-то более надежное, а именно Txl. В целом, я остался доволен экспериментом.

Чтобы получить общее впечатление, я не изобретал велосипед и тупо выполнял задания из Txl Challenge. Примечательно, что там предлагается общаться по почте с одним из “Оракулов”, чтобы получить помощь (делать я этого, конечно, не стал).

Язык не очень сложный — все основы можно почерпнуть из презентации. Однако документация в целом не супер — это набор PDF. Искру добавляет неироничное использование шрифта Comic Sans.

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

Киллер-фича по сравнению с OpenRewrite, на мой взгляд, — это валидация выхода: вместо просто “текста” на выходе получается тоже АСД. Т.е. замена либо применится и это будет корректный код, либо будет пропущена. Увы, за это приходится расплачиваться тем, что надо иметь хорошую грамматику для целевого языка и задабривать компилятор: например, if -> if преобразовать просто, а if -> switch уже тяжело, потому что типы другие.

На 3 задании долго тупил как раз из-за непоняток, как правильно преобразовывать типы, и в итоге пришлось подсмотреть готовые решения на GitHub. Еще у меня почему-то не работал [list X], да и в целом любые преобразования кроме 1 к 1 давались тяжело. При этом преобразования 1 к 1 выглядят чуть ли не как куски кода из оригинала (“возьми такое и замени на сякое”).

У технологии, на мой взгляд, 2 основных минуса. Во-первых, откуда-то надо добыть грамматику. Для какой-нибудь Java это легко, для чего-то типа Kotlin — до свидания. Во-вторых, как я понял, нет никакого способа предоставить контекст. С какими-нибудь функциями расширения Kotlin — удачи понять, откуда метод и что там сейчас в качестве this. Т.е. совсем произвольный код не очень понятно как преобразовывать с учетом того, что могут быть подключены библиотеки.

При всем при этом группа ученых смогла написать скрипт для перевода Java на C#. Правда только с версии 1.1 и это заняло 8 месяцев.

Еще отмечу, что первая версия Txl появилась аж в 1985 году. В целом, мне кажется, что фундамент вполне хороший и если бы инструмент немного набрал бы популярности в нужное время, то описанные проблемы могли бы быть решены.