Обеспечение работы прикладного ПО
Недавно друг попросил помочь с настройкой VPN. Казалось бы, обычная задача. Но когда я посмотрел, что у него уже развернуто, удивился.
Для управления четырьмя vpn-клиентами использовался полноценный многопользовательский веб-сервис на PHP с MySQL, который требовал отдельного сервера.
История о том, как я перебрал популярные панели управления WireGuard и написал свою.
Представим, что у нас есть массив целых чисел. Какой будет самый медленный способ их просуммировать? Будет ли это складывание слева направо, в случайном порядке или как-то иначе? Чтобы ответить на этот вопрос, мы воспользуемся слабыми местами системы управления памятью и с нуля разработаем такой паттерн обращения к данным, по которому сложение будет происходить максимально долго.
Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.
В прошлой статье я рассуждал про развитие системного аналитика, карьерный путь внутри профессии и то, как меняется роль аналитика в современных командах и проектах. И в какой-то момент я заметил, что практически любой разговор про развитие специалистов рано или поздно начинает приходить к теме T-Shaped. В этом материале мне хотелось бы немного порассуждать о том, почему термин T-Shaped вообще появился, где он действительно помогает, где начинает вредить и почему, как мне кажется, главная проблема этой концепции сегодня находится вовсе не в ней самой, а в том, как именно ее начали трактовать.
Для кого-то T-Shaped — это специалист, который понимает систему шире своей основной области и умеет эффективно взаимодействовать со смежными ролями. Для кого-то — тот, кто должен «уметь всё понемногу». А иногда под этим термином вообще начинают подразумевать сотрудника, который фактически совмещает несколько ролей одновременно. Короче говоря, с T-Shaped все далеко не так однозначно.
Выбор языка программирования (ЯП) отражает стиль мышления разработчика. Однако если какой-то язык называют «популярным», это вовсе не значит, что он самый перспективный и единственно достойный глубокого изучения. Просто в данный момент он чаще на слуху по разным причинам. Это может быть следствием лёгкости освоения, востребованности в какой-то быстро растущей и специфической отрасли, ошибкой интерпретации статистических данных или просто хайпом. В этой статье вместе с разработчиками и исследователями компании «Криптонит» мы проследим динамику рейтингов ЯП, разберёмся, что скрывается за всплесками интереса к разным языкам, какие из них действительно востребованы и почему.
Для понимания общей картины рассмотрим подробнее, что говорят о популярности ЯП в источниках с разной методологией и оценим динамику.
Вашему вниманию предлагается вторая часть статьи “Разработка драйвера сетевого адаптера для Linux”. Первая часть была опубликована очень давно, по некоторым обстоятельствам не было возможности продолжить работу над статьей. Но в итоге вторая часть готова, надеюсь материал будет полезен тем, кто интересуется темой разработки для Linux.
Добрый день!
В прошлой статье мы подготовили кастомную плату на Zynq-7000 для загрузки Linux: Buildroot, U-Boot SPL, device tree и минимальная rootfs уже работают. Но PL-часть при этом оставалась почти пустой.
На первых этапах bring-up это нормально: bitstream обычно шьют через JTAG или кладут в BOOT.BIN, чтобы FPGA конфигурировалась ещё до старта Linux. Но для реального проекта такой подход быстро становится неудобным: иногда нужно менять PL-логику уже после загрузки системы.
В этой статье разберём, как загрузить bitstream в Zynq-7000 из Linux через FPGA Manager, какие параметры ядра для этого нужны, и как завернуть загрузку в небольшую C++ утилиту.
В прошлой статье я рассказывал про свой пет-проект qrrot. Тогда это была in memory база данных на Go с TCP-интерфейсом и встроенным ИИ-ассистентом. Идея казалась забавной, но на практике оказалась бесполезной вещью, поэтому я просто продолжил ее ковырять и пробовать сделать из нее что то интересное и быстрое. В процессе ковыряния в своем проекте я полностью перевернул его суть и идею, и вышло это.
В C++ часть ошибок выглядит слишком безобидно, чтобы сразу насторожиться: std::move в return, emplace_back «для скорости», перемещение из const, move‑конструктор без noexcept. Код компилируется, тесты могут проходить, а потом внезапно появляются лишние копирования, просадки производительности и странное поведение объектов.
Разберём пять типичных ловушек move‑семантики на небольших задачах и посмотрим, где именно ожидания разработчика расходятся с тем, что реально делает язык.
Привет, Хабр! На связи снова команда виртуализации платформы Astra Cloud. Решили рассказать, как мы укрощали тяжелую графику — от первых экспериментов до полноценного релиза.
Запрос от заказчиков звучал железобетонно: «Хотим тяжелую графику в виртуализации, как на рабочей станции, но чтобы управлялось централизованно». Мы ответили: «Сделаем». Как будто были другие варианты, ха!
Каждый раз, когда вы пишете .await, происходит не магия, а вполне конкретный механизм: Future, Waker и опрос состояния. Чтобы увидеть это своими глазами, я написал собственный async-рантайм на Rust с нуля - с executor, reactor на epoll и рабочим TCP-эхо-сервером. По пути разобрался, как именно tokio будит ваши задачи, и нашёл баг, который тихо висел у меня в проде. Внутри - весь код целиком и объяснение без отсылок к чёрным ящикам.
Современная вычислительная платформа — это не просто процессор, память и набор периферийных устройств. За видимой для пользователя работой операционной системы скрывается сложный слой взаимодействия между аппаратной частью, прошивкой и программным обеспечением. Именно в этом слое решаются вопросы обнаружения устройств, управления питанием, обработки аппаратных событий, перехода между состояниями сна и пробуждения, а также множества низкоуровневых сценариев, о которых прикладные программы обычно даже не подозревают.
Одним из ключевых механизмов такого взаимодействия является ACPI (Advanced Configuration and Power Interface). Эта спецификация определяет, каким образом прошивка платформы описывает аппаратную конфигурацию системы, а операционная система получает возможность управлять устройствами, питанием и событиями платформы без необходимости знать все детали конкретной реализации материнской платы или SoC.
Сколько существует ПО, столько админы и программисты спорят о свободном и несвободном ПО. Тема эта древняя и, казалось бы, все участвующие в споре стороны давно определились с лагерем, за который они “топят».
И так бы все и продолжалось, если бы в 2022 году картинка радикально не поменялась. Такие привычные и понятные продукты ушли из России, оставив многих перед необходимостью искать альтернативы. На встречах с заказчиками я начал снова все чаще слышать старые вопросы: «А объясните мне, что такого плохого в OpenSource?» и «Почему вы мне рекомендуете платное, если есть прекрасная бесплатная альтернатива?». Если на этом месте сразу захотелось прекратить читать и нажать на крестик, я дам быстрые ответы: между Open Source и проприетарным ПО гораздо больше общего, чем принято считать, а выбор по принципу «платное ПО или нет» – абсолютно неверная стратегия.
Если вы еще читаете, то давайте разбираться.
Привет, Хабр.
Сегодня я постараюсь максимально понятным языком объяснить Hazard pointers, с схемой и примерами.
В этой статье речь пойдёт не просто об очередном алгоритме, а о том, как можно обойти классический бинарный поиск. Казалось бы, что может быть эффективнее старого доброго деления массива пополам для нахождения значения в отсортированных данных? Однако можно пойти дальше. В этой статье будет рассказываться о самодельном алгоритме «SIMD Quad» - квадратичном поиске.
Идея возникла из необходимости быстро искать 16-битные целые числа в массивах размером до 4096 элементов — именно такие структуры лежат в основе популярного формата Roaring Bitmap. Вместо того чтобы на каждом шаге сравнивать искомый элемент только с одной серединой интервала, авторский алгоритм использует две ключевые аппаратные особенности современных процессоров. Во-первых, это SIMD-инструкции, позволяющие за раз сравнить до 16 элементов. Во-вторых, это распараллеливание работы с памятью, которое даёт возможность безболезненно делить массив не на две, а сразу на четыре части. Так родился гибрид, который сначала выполняет учетверённый поиск по блокам, а затем находит нужный элемент с помощью векторных инструкций. Давайте разберёмся, как это работает и почему такой подход действительно позволяет превзойти бинарный поиск.
Миллион асинхронных задач на Rust спокойно живёт в нескольких сотнях мегабайт. Сто тысяч корутин на Python нередко упираются в память раньше. Дело не в том, что “Rust быстрый, а Python медленный” - дело в том, ГДЕ физически лежит состояние приостановленной задачи.
Разбираю, во что превращается ваш async fn после компиляции: стейт-машина на стеке против объекта в куче. Сравниваю модели Rust (Tokio), Python (asyncio), C# и JavaScript - кто аллоцирует на каждый await, а кто нет, и почему это видно на счётчике RAM при 100k задач.
Внутри: что генерирует компилятор, куда уезжает состояние между await, stackful против stackless, и что с этим делать сегодня.
В этой статье я расскажу, на какие подводные камни я споткнулся при разработке своего пет‑проекта — мониторинга сайтов на Golang, аналог UptimeRobot.
Начнем издалека... Я хотел разработать пет‑проект, но не банальный todolist, а что‑то свежее, интересное в плане архитектуры и реализации. Шерстя по просторам интернета, я наткнулся на UptimeRobot — сервис для мониторинга сайтов. Азарт и любопытство взяли верх и я начал продумывать, как буду разрабатывать «свой» UptimeRobot. Думал — делов на пару недель от силы. Ведь принцип прост: дергать URL по таймеру и проверять код ответа и всё. Но на практике все оказалось намного сложнее, чем я изначально представлял...
redb экосистема
В предыдущей статье я анонсировал redb.Route.Llm как 24-й транспорт redb.Route — мы делали LLM ещё одним endpoint'ом наравне с Kafka, RabbitMQ и HTTP, чтобы выкинуть отдельную «AI-инфраструктуру», стоящую рядом с интеграционной. Заодно я повесил в конец статьи «честный skip-list» — список того, что в 3.1.0 ещё не доделано: streaming, ToolCacheStore, KnowledgeStore, BatchStore, EvalRunStore, sliding-window память, sandbox-инструменты.
Из этого skip-list'а делано больше, чем я планировал. Но не это главное. Главное — что в процессе доделывания обнаружилась настоящая ценность всей затеи: LLM-транспорт оказался не очередным чат-фреймворком, а недостающим звеном в ESB, после которого «бизнес-агент в проде» перестаёт быть отдельным проектом. Эта статья — про то, как чат-демо превращается в enterprise-агентскую платформу, не переписываясь и не превращаясь в «AI-монолит сбоку».
Всё, что ниже — реальный код из репозитория, не псевдокод. Ссылки на демо-маршруты в конце.
Привет, Хабр! Меня зовут Владислав, я разрабатываю компиляторы в YADRO. В этой статье я расскажу вам про алиасинг памяти в C++: как он развивался, к чему пришел сейчас и что комитет по стандартизации языка думает делать с алиасингом в будущем. По пути я немного затрону алиасинг в других языках, рассмотрю связанные случаи undefined behavior, а также пропозалы C++, которые, как ожидалось, проблемы с алиасингом решат.
Привет! Хотел бы рассказать о своем MVP проекта hw-mlir-lab, где я использую MLIR для lowering операции умножения матриц (matmul) на systolic array, который я симулирую в Verilator.
Если вы пользовались моим LxBox или десктопным лаунчером, то могли натыкаться на оранжевый баннер: «с этим узлом, скорее всего, не соединится». Так клиент честно сознаётся, что наткнулся на узел с транспортом XHTTP, а ядро sing-box, на котором всё крутится, его не умеет. В этот момент лаунчер тихо даунгрейдит конфиг до HTTPUpgrade.
А еще сразу как я выпустил приложение пришли запросы с AWG/AWG2 и такие: сделай! а я сюда
В какой-то момент я устал ждать и собрал свой форк ядра — sing-box-lx. Сегодня расскажу, зачем он понадобился, что внутри, и почему главное в нём — не сами фичи, а то, как он сделан.