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

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

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

Я всё тщательно проверил и убедился, что мой сайт отлично (или хотя бы вполне неплохо) работает даже без JavaScript. Но, когда JavaScript недоступен, иногда бывает немного тяжеловато скрывать вещи, скрывать которые необходимо. Всего 7 строк кода (или даже однострочника, для самых душных) достаточно, чтобы скрывать на странице элементы, требующие JavaScript. Поэтому вам не придётся краснеть перед пользователи, которые без JavaScript заметили бы, как хромает функциональность вашего сайта.

Небольшой контекст: я сейчас разрабатываю небольшую кнопочку «Share», которую можно вставлять в посты и с лёгкостью делиться ими, если мне захочется. Взгляните, как она сейчас выглядит без JavaScript:  

В течение последнего полугода команда Discord по обслуживанию медиа-инфраструктуры модернизировала конвейер обработки изображений, добавив поддержку анимированных форматов WebP и AVIF. Теперь на платформе можно делиться анимированными картинками WebP и AVIF как в виде прикреплённых файлов, так и в виде вставок. При этом все эмодзи выдаются в виде анимированных WebP — и бесшовно отображаются на любой платформе Discord. Эти изменения были реализованы для того, чтобы повысить качество анимации и воспроизведения роликов на всех платформах. При этом одновременно резко уменьшается размер файлов, и поэтому их загрузка ускоряется!

То и дело, прожигая время за чтением reddit, я натыкаюсь на очередной пост, в котором упоминается метод S3 FIFO и говорится, что он лучше LRU (вытеснение реже всего используемых значений) — потому, что даёт более низкий процент промахов кэша. Видные компании, в частности, RedPandas, Rising Wave и Cloudflare уже внедрили S3 FIFO у себя на различных мощностях, что только подогрело мой интерес к нему. Кэши — чертовски интересная тема, а по работе мне приходится сильно полагаться на работу с кэшами при обслуживании нескольких сервисов. Так что я был уверен, что рано или поздно мне потребуется протестировать S3 FIFO или, как минимум, удостовериться, что я понимаю ключевые идеи, заложенные в этой технологии.

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

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

В этом посте будет разобрано, как написать приложение на Rust с применением самого минимального API, возможности которого искусственно ограничены (например, не применяется динамическое выделение памяти). Предполагается, что читатель немного знаком с языком Rust.

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

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

Какие настройки git config сейчас следует устанавливать по умолчанию? Ниже рассмотрены избранные настройки, менять которые не стесняются даже разработчики самого Git.

Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.  

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

В этом посте я разберу некоторые (пожалуй, малопонятные) настройки Git, которые сам активировал во всех моих проектах. Я подробно расскажу о них, поясню, как они действуют, и почему их, пожалуй, стоит выставить по умолчанию.

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

На протяжении более двух лет я много времени уделял разработке моего собственного эмулятора Game Boy, GameRoy. Я немало успел сделать. В эмуляторе был готов графический пользовательский интерфейс (с отладчиком и дизассемблером), сама программа прошла многочисленные тесты и могла сравниться с некоторыми наиболее точными эмуляторами. Я даже портировал её на Android!

Прошло много лет с тех пор, как я написал donut.c, и всё это время я не раз задумывался, можно ли как-то упростить этот проект. Например, может быть, нашёлся бы способ очертить пончик лучами, дописав для этого немного кода. В октябре 2023 года я написал твит о совершенно внезапном просветлении, позволившем мне найти новый подход к этой проблеме — без привлечения памяти, без каких-либо синусов, косинусов, без квадратных корней, деления, строго говоря, даже без умножения. Всё нужное можно отобразить с помощью одних только сдвигов и сложений. Вот обновлённая версия на C.

Эта программа представляет собой свободную от зависимостей реализацию GPT-2. Она загружает матрицу весов и файл BPE из оригинальных файлов TensorFlow, токенизирует вывод при помощи простого энкодера, работающего по принципу частотного кодирования, реализует базовый пакет для линейной алгебры, в котором заключены математические операции над матрицами, определяет архитектуру трансформера, выполняет инференс трансформера, а затем очищает вывод от токенов при помощи BPE-декодера. Всё это — примерно в 3000 байт на C.

Код достаточно эффективно оптимизирован — настолько, что малый GPT-2 на любой современной машине выдаёт отклик всего за несколько секунд. Чтобы этого добиться, я реализовал KV-кэширование и применил эффективный алгоритм перемножения матриц, а также добавил опциональный OMP-параллелизм.

Взяв это за основу, можно создать некий аналог Chat GPT — при условии, что вас не слишком волнует качество вывода (объективно говоря, вывод получается просто ужасный… но решение работает). Здесь есть некоторые глюки (особенно с обработкой символов в кодировке UTF-8), а для эксплуатации модели размером XL с широким контекстным окном может потребоваться ~100 ГБ оперативной памяти. Но, если вы просто набираете текст в кодировке ASCII при помощи малого GPT2, то такая модель должна нормально работать примерно везде.

Я выложил весь код на GitHub, поэтому можете свободно брать его там и экспериментировать с ним.

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

От переводчика.

Под катом я помещаю для вас перевод статьи знаменитого и влиятельного инженера из Кремниевой Долины Дэвида Крошо (David Crawshaw), сооснователя и технического директора (CTO) компании Tailscale. Ранее Дэвид более 9 лет работал программистом-исследователем в компании Google и в настоящее время является одним из самых авторитетных практикующих специалистов по языку Go. В частности, именно Дэвид адаптировал Go для платформ iOS и Android. В статье Дэвид делится своими наблюдениями о том, какую работу программист может и должен поручать большим языковым моделям, какие подводные камни есть в этом искусстве, и как оно может развиваться в ближайшие годы. Далее — от автора.

Обратная разработка аппаратного обеспечения бывает очень сложна — но иногда для неё может потребоваться только уютное кресло и Google Translate.

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

Недавно юный предприниматель взбаламутил соцсети, заявив, что приобретённый им в Китае девайс для подключения Ethernet-to-USB сразу был начинён вредоносом, который «ускользал от виртуальных машин», «считывал клавиатурный ввод» и «использовал характерные русскоязычные элементы».

Считайте, что я этого не говорил.

Если я хочу посмотреть видео — разве для этого обязательно покидать vim?

Что ж, прямо в заголовке этого поста я пообещал вам продемонстрировать Bad Apple в vim, пользуясь только поисковыми запросами. Вот Bad Apple в vim, всё, что здесь меняется — только поисковый запрос:

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

Не могу подобрать идеального названия для этого явления, так что буду называть его просто «эффект Makefile». Эффект Makefile не назовёшь однозначно порочным — просто нужно иметь его в виду при проектировании инструментов и систем.

Суть эффекта Makefile сводится к следующему:

В ходе нашего исследования, охватывавшего записи SPF, DKIM и DMARC на 1 миллионе самых популярных веб-сайтов мы с удивлением обнаружили более 1 700 открытых DKIM-ключей длиной менее 1 024 бит каждый. Эта находка нас удивила, поскольку RSA-ключи короче 1 024 бит расцениваются как небезопасные, и их не рекомендуется использовать в DKIM с 2018 года, когда был введён в действие документ RFC 8301.

Просто из любопытства мы решили проверить, а удастся ли нам взломать один из таких ключей. Мы стремились извлечь закрытый ключ из открытого RSA-ключа, так, чтобы можно было подписывать им электронные сообщения, выдавая себя за их подлинного отправителя. Кроме того, нас занимало, пройдут ли DKIM-верификацию электронные письма, подписанные таким скомпрометированным ключом. Мы решили проверить крупнейших провайдеров электронной почты —  в частности, Gmail, Outlook.com и Yahoo Mail — вдруг они просто с порога откажутся проверять цифровые подписи, сгенерированные настолько коротким ключом.

Для нашего эксперимента мы выбрали домен redfin.com, на котором нашли 512-разрядный открытый RSA-ключ по адресу key1._domainkey.redfin.com (сейчас он уже не доступен):

Ответ: да! И вот же он:

Игра запускается, и вы можете перемещаться по миру 64x64x64 при помощи клавиш WASD. Пробелом прыгаем, мышью осматриваемся. Щёлкнув левой кнопкой мыши, можно разрушить блок, а правой — установить землю.

Можно просмотреть QR-код при помощи следующей команды под Linux:

zbarcam -1 --raw -Sbinary> /tmp/m4k &&chmod +x /tmp/m4k  && /tmp/m4k

-1: выйти после того, как код будет просканирован

--raw: не обрабатывать его как текст

--Sbinary: воспользоваться двоичной конфигурацией

Проект выложен на GitHub здесь:TheSunCat/Minecraft4k

Ассемблерные вставки, используемые компиляторами GCC и Clang, опосредуют взаимодействие высокоуровневых и низкоуровневых языков программирования. Это тонкая и коварная штука. Многие попадают в расставленные здесь капканы, зачастую совершенно неожиданно для себя. В сущности, ключевое слово asm можно перевести на C и C++ как unsafe. Почти в любых руководствах по встроенному ассемблеру, в том числе, и на ужасной странице ibilio, которая десятилетиями попадает в самый верх поисковой выдачи, неисправимо фигурируют фундаментальные серьёзные ошибки, а примеры в большинстве своём некорректны. Наиболее опасно, что эти примеры обычно приводят к ожидаемым результатам! Ситуация плачевная. Эта статья — не руководство, а подборка элементарных правил, которые помогут вам избежать самых распространённых ошибок либо отловить их при ревью кода.

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

Возможно, вы слышали о финансовой стратегии ставок по методу Келли. Это система, позволяющая оборачивать себе на пользу известную информацию в азартной игре или связанные с ней предубеждения. Эта стратегия также называется максимально агрессивной или стратегией высокой дисперсии. Дело в том, что если сделать ставку выше, чем позволяет предел Келли, то последствия могут быть катастрофическими.
Недавно мне попалась странная карточная игра, в которой стратегия Келли абсолютно не подразумевала риска, поскольку в игре действует Нулевая дисперсия. В своей знаменитой книге «Математические головоломки» Питер Уинклер называет её «Next Card Bet» («Следующая карточная ставка»). Саму задачу и её решение, по-видимому, сформулировал Томас Кавер. Мне понравилась как сама эта игра в ставки, так и её анализ, поэтому я поделюсь ими с вами здесь.

Почему я это написал, и как читать статью

Недавно получил от друга такое сообщение:

Знаешь, какая статья была бы реально интересна? Если бы в ней было показано, что именно происходит с твоим кодом в результате оптимизаций.

Я сразу же подумал: «Ну конечно, я знаю тысячу статей и видеороликов на эту тему», но вскоре осознал, что практически во всех таких источниках от читателя требуется знать компьютерный жаргон, внутреннее устройство, промежуточные представления, т.д. Вот какая проблема здесь возникает: те, кто пользуется компиляторами (как, например, мой друг), всем этим не заморачиваются. Их не волнует, каково именно промежуточное представление LLVM, или что такое φ-узел, или какой проход и почему называется «ротацией циклов». Нет, их интересуют (в порядке убывания приоритета) ответы на вопросы: (1) что, (2) почему, (3) как.