Postgres 17.0 уже вышла, и она замечательная, но реальность такова: большинство пользователей Postgres не выполняют апгрейд сразу же. Многие, вероятно, сейчас даже не на 16.4, и даже не на 16, они пользуются Postgres 15 или ещё более старой версией. Ситуация с Postgres не такая же, как с новыми Call of Duty, когда каждый хочет скачать обновление сразу же после его выхода.

Почему же люди так неохотно идут на апгрейд?

На то есть множество причин, но всё сводится к двум основным: качество работы Postgres и неудобство апгрейдов.

Привет, меня зовут Дэниел, мне пятнадцать лет, я имею опыт программирования, в свободное время занимаюсь поиском багов. В посте я расскажу безумную историю о том, как обнаружил один баг, затронувший больше половины компаний из списка Fortune 500.

Поприветствуйте Zendesk

Возможно, вы уже сталкивались с Zendesk. Это инструмент службы поддержки, используемый одними из самых богатых компаний мира. Он прост в настройке: достаточно указать ссылку на электронную почту технической поддержки компании (вида support@company.com), и Zendesk сразу начнёт обрабатывать входящие письма и создавать тикеты. Вы можете работать с этими тикетами самостоятельно или передавать их команде службы поддержки. Компания Zendesk стоит несколько миллиардов долларов, ей доверяют такие крупные игроки, как Cloudflare.

Лично мне всегда казалось удивительным, что такие огромные компании, стоящие миллиарды долларов, используют сторонние инструменты наподобие Zendesk, а не создают собственные инструменты для работы с тикетами.

Ваше самое слабое звено

Как гласит поговорка, «где тонко, там и рвётся». Так как Zendesk считается базовым инструментом обработки тикетов, компании часто настраивают его, особо не задумываясь. Чаще всего я встречал такую систему: все электронные письма с support@company.com перенаправляются в Zendesk.

Почему это опасно? Многие компании используют свой домен company.com для единого входа (Single Sign-On, SSO), позволяющего сотрудникам быстро выполнять вход во внутренние инструменты. Связывая Zendesk с тем же доменом, компании неосознанно создают потенциальную брешь в защите. Zendesk обрабатывает все письма домена, для которого он был сконфигурирован, поэтому если ваша система SSO не валидирует надлежащим образом адреса электронной почты, то любой, получивший доступ к вашему Zendesk, потенциально может воспользоваться этим для доступа к вашим внутренним системам (подробнее я расскажу об этом ниже).

Мессенджер Revolt

После блокировки Discord в РФ люди начали искать варианты решения проблемы. Легально это можно сделать двумя способами:

1. Перейти на альтернативный мессенджер с централизованным управлением от сторонней компании (TeamSpeak, Skype и др.). Правда, некоторые аналоги Discord уже упали под нагрузкой и вынуждены ограничить доступ пользователям из РФ, как Guilded.
2. Поднять собственный сервер.

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

В итоге остаётся только свой сервер. Желательно в локальной сети или хотя бы на виртуальном хостинге.

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

Алгоритмы — важнейшая часть программы: замена «горячего» алгоритма O(n) менее сложным, например, O(log n), обеспечивает практически произвольное увеличение производительности. Однако существенно влияет на производительность и структурированность данных: программы выполняются на физических машинах с физическими свойствами, например, разными задержками чтения/записи данных в кэши, на диски или в ОЗУ. После оптимизации алгоритмов стоит изучить эти свойства, чтобы достичь наибольшей производительности. Оптимизированный формат данных учитывает используемые алгоритмы и паттерны доступа при выборе того, как сохранять структуру данных на физическом носителе. Благодаря этому можно увеличить скорость алгоритмов в несколько раз. В этом посте мы покажем пример, в котором нам удалось достичь четырёхкратного повышения скорости чтения простым изменением формата данных в соответствии с паттерном доступа.

Сравнение хранилищ данных AoS и SoA

Современное оборудование, и, в частности CPU, спроектировано так, чтобы обрабатывать данные определённым образом. Расположение данных в памяти влияет на то, насколько эффективно программа сможет использовать кэш CPU, как часто она сталкивается с промахами кэша и насколько оптимально она сможет задействовать векторные команды (SIMD). Даже при использовании оптимальных алгоритмов выбор неподходящего формата данных может приводить к частым перезагрузкам кэша, простаивающим конвейерам и чрезвычайно большому объёму передач содержимого памяти; всё это снижает производительность.

Спойлер: ДА.

Элитный инструмент для хакинга; от вас скрывают, что он уже у вас есть

Прежде чем писать эксплойт, нам нужен баг. А если багов нет, то приходится быть изобретательными — тут нам на помощь приходит внесение неисправностей. Внесение неисправностей (fault injection) может принимать множество различных форм, в том числе быть управляемым ПО повреждением данных, глитчингом питания, тактовым глитчингом, электромагнитными импульсами, лазером и так далее.

Для внесения аппаратных неисправностей обычно требуется специализированное (и дорогостоящее) оборудование. Его цена связана с высокой точностью времени и места внесения неисправностей. Для снижения цен было совершено множество отважных попыток такими проектами, как PicoEMP на основе RP2040 и вплоть до «Laser Fault Injection for The Masses». (Неожиданная популярность RP2040 связана с его низкой ценой и периферией PIO, обеспечивающей ввод-вывод с чёткими таймингами и задержками.)

Какое-то время назад я прочитал об использовании соединённой с индуктором пьезоэлектрической зажигалки для барбекю в качестве низкобюджетного устройства для внесения электромагнитных неисправностей (electro-magnetic fault injection, EMFI). Меня захватила эта идея. Я задался вопросом, а чего можно добиться при помощи такого примитивного устройства? На тот момент мне пришёл в голову лишь эксплойтинг работающей на Arduino программной реализации AES при помощи DFA. И это сработало!

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

Перенесёмся в наше время: пару недель назад уже ожидалось объявление о выпуске Nintendo Switch 2. Предполагается, что системное ПО Switch 2 будет практически таким же, как и на Switch 1, а программные баги для изучения у нас закончились. Поэтому у меня возникла мотивация смахнуть пыл с моих навыков взлома оборудования, и я вернулся к мыслям о низкобюджетном EMFI.

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

Я поспрашивала у людей в Mastodon, какие проблемы у них возникали с цветами в терминале, и получила кучу интересных ответов! Давайте обсудим некоторые из проблем и разные способы их решения.

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

А теперь немного усложним задачу. Будем писать код для людей!

Объясню, что я имею в виду: я говорю о коде, с которым смогут взаимодействовать другие люди. В частности, я имею в виду искусство создания удобных фреймворков, библиотек, API, SDK, DSL, встроенных DSL или даже языков программирования.

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

Ричард Фейнман как-то сказал: «Представьте, насколько сложнее была бы физика, если бы электроны имели чувства». Он говорил это в другом контексте, но мне кажется, это частично описывает и программирование для людей. У человека, интерпретирующего твой код, есть чувства!

Давайте поговорим о том, как упростить ему задачу.

Уязвимости безопасности памяти остаются серьёзной угрозой для защиты ПО. Мы, работники Google, считаем, что путь к крупномасштабному устранению этого класса уязвимостей и к защищённому ПО заключается в Safe Coding — подходе secure-by-design, отдающем приоритет переходу на безопасные по памяти языки.

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

Также мы приведём обновлённую статистику того, как благодаря переходу на безопасные по памяти языки, процент уязвимостей безопасности памяти в Android упал за шесть лет с 76% до 24%.

Акт 1: полдень воскресенья

Я занимался домашними делами, ни о чём плохом не думал, пил водичку и ни в коем случае не имел никаких намерений заниматься подрывной деятельностью против Австралийского Союза.

А потом я получил сообщение в «групповом чате»¹.

Милое сообщение от моего друга с фотографией посадочного талона. В сообщениях от друзей хорошо то, что они не несут за собой никаких катастрофических последствий

Обладателем талона был Тони Абботт, один из множества бывших премьер-министров Австралии.

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

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

Если вы начинали изучение программирования с JavaScript, Rust, C или любого другого высокоуровневого языка, то ассемблерный код может показаться вам непонятным или даже пугающим.

Рассмотрим следующий код:

section .data
  msg db "Hello, World!"

section .text
  global _start

_start:
  mov rax, 1
  mov rdi, 1
  mov rsi, msg
  mov rdx, 13
  syscall

  mov rax, 60
  mov rdi, 0
  syscall

К счастью, по второй строке мы можем понять, что он делает.

Здесь нет ничего привычного нам: мы не видим ни условных операторов, ни циклов, нет никакого способа создавать функции… Да даже у переменных нет имён!

С чего же вообще начать?

Это небольшое введение предназначено для того, чтобы познакомить имеющих опыт в программировании с миром ассемблера. Мы обсудим основы языка и сопоставим их с конструкциями высокоуровневого программирования.

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

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

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

Давайте рассмотрим пример, в котором применено защищённое от ошибок целочисленное деление:

int safeDiv(int a, int b) {
   if (b == 0)
      throw Div0(); // Исключения передаются особым образом
   return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}

Новые языки программирования склонны применять сообщения об ошибках в функциональном стиле и кодировать ошибки в возвращаемый тип. Например, Go кодирует ошибку в возвращаемый тип при помощи кортежа (res, err), а Rust возвращает Result<T, E> — тип-сумму результата и ошибки.

— Скажи триста!
— Триста
— С днём программиста!

Предсказывать что-либо — дело неблагодарное, последние лет пять преподали нам отличный урок. Однако, если вы встретите программиста конца 80-х — начала 90-х, то он наверняка расскажет вам, сколько раз за 30 лет умирала страшно невостребованная профессия программиста. Её убивали декларативные языки, платформы разработки, low-code, no-code, теперь очередь AI. А программисты знай себе живут, раскаляют рынок зарплат, придумывают новые языки программирования и пишут тот самый искусственный интеллект, который и должен уничтожить программирование как деятельность. Потому что знают — здесь, как с врачами скорой помощи: что бы в мире ни случилось, без разработчиков ничего не обойдётся. Или… нет? В общем, давайте посмотрим в будущее. Мы под это дело даже КДПВ нагенерили (надеемся, вы не генерируете код, который выглядит, как этот кот).

Начнём, конечно, с главного. Ну как с главного — с самого заметного и обсуждаемого. Как известно, пустая бочка громче всех звенит.

В детстве у нас с сестрой была гора VHS-кассет, которые мы бесконечно пересматривали. Современная видеоколлекция моих детей сильно от них отличается. Она полностью цифровая и разбросана по разным сервисам. Я хотел поделиться с ними магией осязаемости носителя из моего детства.

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

Это заставило меня задуматься: почему бы не объединить новое и старое? Я хотел, чтобы у сына была более активная роль в выборе того, что он хочет посмотреть, несмотря на цифровой формат.

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

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

Недавно я завершил процесс устранения бага в веб-браузере Chromium. Это был мой первый опыт контрибьютинга в проект Chromium, да и вообще в какой-либо опенсорсный проект такого масштаба, он сильно отличался от любой моей прошлой работы над open source.

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

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

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

▍ Если ты (или твоя команда) постоянно стреляешь себе в ногу, то почини ружьё

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

Когда я занимался разработкой для iOS, то использовал CoreData и подписывался на изменения нескольких view. Обратный вызов подписки поступал в тот же поток, из которого было запущено изменение. Иногда это был основной поток, а иногда — фоновый. В разработке для iOS важно то, что вносить изменения в UI можно только в основном потоке, иначе приложение вылетит. Поэтому подписка могла работать нормально, но потом ломалась, когда кто-то запускал изменение из фонового потока или вы позже добавляли обновление UI.

Все без раздумий воспринимали это как что-то само собой разумеющееся, и об этом часто говорили в ревью для новичков в команде. Время от времени кто-нибудь ошибался, и мы добавляли DispatchQueue.main.async, когда видели отчёт о сбое.

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

Серверный узел с восемью GPU-ускорителями AMD Instinct MI325X (2,3 ТБ видеопамяти, 8×750 Вт)

Современные дата-центры уже не такие, как прежде. Раньше на типичный сервер поставили бы 144-ядерный CPU, много RAM и десяток HDD/SSD. Но теперь приоритеты меняются, в первую очередь из-за высокого спроса на машинное обучение (ML) и приложения LLM. Хотя аппетит к памяти только вырос, но процессоры нужны другие.

И крупным корпорациям, и маленьким компаниям нужно железо для обсчёта ИИ-приложений. Это GPU-ускорители, NPU (Neural Processing Unit) и TPU (Tensor Processing Unit), AI-чипы нового поколения. Нужны серверы с GPU. Открываются даже специализированные GPU-облака на растущем спросе.

Этим летом я занимался созданием нового приложения для машины, продажи которой закончились в 1980 году, и которая не была рассчитана на поддержку графики, сети и даже букв в нижнем регистре. Её продавала компания, обанкротившаяся десяток лет назад. Приложение было специально разработано под единственного пользователя — моего отца, которому в позапрошлую пятницу исполнилось семьдесят лет. Представляю вашему вниманию MTS-70:

Программа MTS-70 была разработана для Radio Shack TRS-80 Model 1 (примерно 1979 год). У неё есть шесть уникальных и очень забавных функций, неинтересных никому, кроме меня и (в идеале) моего отца (инициалы которого, разумеется, MTS):

1. Чат с Dadbot — инстансом gpt-3.5 с fine-tuning на основе текстовых переписок между мной и отцом на протяжении пятнадцати лет.
2. Воспроизведение «Happy birthday» (через 500-бодный кассетный вывод данных; этот хак был необходим из-за отсутствия нативной поддержки звука в TRS-80).
3. Морской прогноз на сегодня, в том числе прогнозы прилива и течений.
4. Поиск ближайших концертов и мероприятий в Ист-Энде Лонг-Айленда (где живёт мой старик).
5. Текстовая адвенчурная игра на основе LLM о выживании летом в Ист-Энде, дополненная забавными семейными байками.
6. Игра в го (на доске 9×9 против достаточно сильного локального игрового движка).

Одновременная многопоточность (Simultaneous multithreading, SMT) — это функция, позволяющая процессору одновременно обрабатывать команды из двух разных потоков. Но задавались ли вы когда-нибудь вопросом, как это работает? Как процессор отслеживает два потока и распределяет ресурсы между ними?

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

Примечание: основная часть изложенного в статье относится к реализации SMT компании Intel, также называемой гипертредингом (hyper-threading). Она основана на научной статье компании, опубликованной в 2002 году.