Привет, Хабр! В предыдущей статье был разобран первичный анализ работы приложения, какие инструменты стоит использовать для сбора информации и как с этими инструментами работать. Напомню, что речь шла о двух утилитах: poor man's profile (pt‑pmp), которая позволяет комплексно оценивать работу приложения, отображая off-cpu и on-cpuчасти; и perf, которая обладает высокой точностью и мощной функциональностью в целом. Оба этих инструмента применяются для анализа производительности, так как их комбинация позволяет целиком и со всех сторон осмотреть «пациента».

Однако есть один пункт, который не был раскрыт в прошлой части: использование этих инструментов на настоящих продуктах. Синтетический пример на базе open‑source‑проекта — это хорошо, но будет не лишним показать, какие реальные проблемы были найдены, исправлены и какой прирост производительности удалось в итоге получить. В этой статье мы поговорим о практическом применении pt-pmp и perf, с помощью которых удалось обнаружить места для оптимизации работы программы. Меня по‑прежнему зовут Александр Слепнев, устраивайтесь поудобнее, начинаем!

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

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

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

Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 15 тыс. разработчиков и 222 компании вносят более 12 тыс. изменений между релизами или 7 / 8 правок каждый час? Чем пользуются создатель кернела Линус Торвальдс, мейнтейнер стабильной ветки Грег Кроа-Хартман (GKH) и другие товарищи, чтобы успешно координировать работу проекта и обеспечивать своевременный выход каждой новой версии?

Этим чудо-инструментом является текстовый клиент электронной почты: Mutt у GKH и Alpine у Линуса Торвальдса. Третий по рангу разработчик ядра Эндрю Мортон, также вовсю использует электронку для управления mm веткой.

With the wide variety of more “modern” development tools such as github, gerrit, and other methods of software development, why is the Linux kernel team still stuck in the 1990’s with ancient requirements of plain text email in order to get patches accepted? This talk will discuss just how the kernel development process works, why we rely on these “ancient” tools, and how they still work so much better than anything else.^[1]

Привет, Хабр!

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

Сразу скажу, что буду говорить обо всём, что известно на данный момент. Понятно, что с этим разбирался далеко не один я: огромное спасибо обывателям ntc party форума за проделанный ресёрч.

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

UPD 10.08.2024 Многие жалуются на недоступность ютуба в целом: не грузит домашнюю страницу. Переживать не стоит, оно обрабатывается всё тем же ТСПУ по всё той же стратегии, обходы должны работать.

Berkeley Packet Filters (BPF) — это технология ядра Linux, которая не сходит с первых полос англоязычных технических изданий вот уже несколько лет подряд. Конференции забиты докладами про использование и разработку BPF. David Miller, мантейнер сетевой подсистемы Linux, называет свой доклад на Linux Plumbers 2018 «This talk is not about XDP» (XDP – это один из вариантов использования BPF). Brendan Gregg читает доклады под названием Linux BPF Superpowers. Toke Høiland-Jørgensen смеется, что ядро это теперь microkernel. Thomas Graf рекламирует идею о том, что BPF — это javascript для ядра.

На Хабре до сих пор нет систематического описания BPF, и поэтому я в серии статей постараюсь рассказать про историю технологии, описать архитектуру и средства разработки, очертить области применения и практики использования BPF. В этой, нулевой, статье цикла рассказывается история и архитектура классического BPF, а также раскрываются тайны принципов работы tcpdump, seccomp, strace, и многое другое.

Разработка BPF контролируется сетевым сообществом Linux, основные существующие применения BPF связаны с сетями и поэтому, с позволения @eucariot, я назвал серию "BPF для самых маленьких", в честь великой серии "Сети для самых маленьких".

• Don't communicate by sharing memory, share memory by communicating.
• Concurrency is not parallelism.
• Channels orchestrate; mutexes serialize.
• The bigger the interface, the weaker the abstraction.
• interface{} says nothing.
• Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
• A little copying is better than a little dependency.
• Cgo is not Go.
• Clear is better than clever.
• Reflection is never clear.
• Errors are values.

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

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

Рисовал я все это в PowerPoint.

Форматы Ehternet фреймов.

1) Ethernet II

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

А тут хвастаемся подарками

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

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

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

Я Александр Парфенов, бэкенд-разработчик в Тинькофф Инвестициях и автор InvestAPI SDK для языка Go. Расскажу о том, как автоматизировать торговые стратегии при помощи Tinkoff INVEST API и языка Go.

Точное определение времени и его синхронизация чрезвычайно важна в мире высокочастотной торговли.

Конечно же, синхронизация времени важна в общей инфраструктуре компании, думаю многие из вас встречались хотя бы раз с проблемами, вызванными некорректным временем на сервере, выполняющим ту или иную роль. Например, возможно некорректное формирование бэкапов, задержка в обработке запросов, некорректная интерпретация валидности сертификатов, ошибки аутентификации и авторизации и т. д. Тут на помощь придет NTP (Network Time Protocol) протокол, который широко распространен повсеместно, а далеко не только в HFT отрасли. Наилучшая точность синхронизации времени с помощью NTP будет порядка 1мс и то, в случае если NTP сервер находится в локальной сети с вашим сервером, а также оптимально настроен, например, дает опрашивать себя достаточно часто. Для среднего случая, когда NTP сервер будет использоваться из интернета, вы сможете добиться 10-100 мс точности, а если сетевой путь до источника времени будет совсем не идеален (зачастую колокация биржи может предоставлять только IPSec туннель в качестве доступа до вашей биржевой инфраструктуры), то и сотен миллисекунд.

Решение же торгового алгоритма об отправке заявки на биржу может и не опираться на абсолютное время.

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

print("hello world")

$ python3 hello.py
hello world

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

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

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.