Давно присматривался к языку программирования Zig и наконец решил на нём что-то написать. Выбор пал на TCP/UDP echo сервер: задача не слишком сложная, но с интересными моментами, особенно при переходе на event loop. В статье поделюсь процессом и своими впечатлениями.
В игре CoreWars участники писали программы, которые сами клонировались в памяти и пытались затереть друг друга. Работало это в виртуальной машине с хитроумными инструкциями, которые позволяли создавать очень короткий код. Простейшая само-копирующаяся программа, "самобеглый MOV", выглядела вот так:
MOV 0, 1
Пояснение этой инструкции будет дано чуть ниже. Программа "бежит" по всему сегменту памяти, в котором происходит "битва" и затирает собою все ячейки последовательно. В языке RedCode используемом в игре эта инструкция занимает одну ячейку памяти.
Мне неизвестны реальные процессоры в которых были бы подобные "удобные" инструкции. И вот любопытно - насколько короткой можно сделать (а можно ли?) подобную "самобеглую" программу для какой-нибудь настоящей архитектуры. Ну хотя бы для 8086. Тем более что там сегменты обозримого размера - 64 килобайта.
Не страшно если вы не знаете или плохо помните команды ассемблера, их будет немного и мы снабдим их пояснениями.
На работе разгорелась жаркая дискуссия по поводу того, является ли сегодня программирование профессией, и кто такие вообще — программисты. Коллеги утверждали, что весь этот научный флёр вокруг программирования — полный бред. Не более, чем скилл, умение, ремесленный навык, но не реальная инженерная профессия. По их мнению, программирование не может сравниться с чем‑то более реальным — работой архитектора, строителя, механика и.т.д. И от этих слов, мне… стало чертовски обидно.
Пока вы рождались, ходили в школу, заканчивали учебу и выходили на свою первую работу, на свете существовал совершенно особенный набор компиляторов, о котором крайне мало известно на просторах РФ.
Именно о нем пойдет сегодняшний рассказ.
Почему-то не нашёл с первой попытки здесь на Хабре какого-нибудь демо или инструкции по использованию этой старинной, но милой тулы из стандартной поставки DOS. Давайте быстренько это исправим. Как легко догадаться из названия - DEBUG.EXE предполагается использовать для отладки. Мы же напишем пару коротких ассемблерных программ "с нуля" - это не займет много времени, а притом даст лёгкое ощущение магии!
Экспериментировать можно в DosBox или DosEmu - правда если вы возьмёте версию DEBUG.EXE например из MS-DOS 6.22 то скорее всего обнаружите что она не заработает в эмуляторе. Несложно отыскать в интернете рабочую версию (из Windows XP или FreeDOS например - иногда также под именем DEBUG.COM) - либо установить полноценный ДОС в виртуалку вроде VirtualBox.
Внимание! Эта статья имеет скорее развлекательно-познавательное назначение - её автор вовсе не думает что кому-то (кроме студентов со старыми лабами по "архитектуре микро-ЭВМ") в наше время это понадобится в практических целях. Мне же эта мини-инструкция пригодится как вспомогательная для будущей статьи про "самокопирующуюся программу".
После статьи о баге в CancelIoEx решил рассказать ещё об одном дефекте в системных компонентах Windows — на этот раз в IP Helper (часть Windows API, отвечающая за работу с сетевой статистикой и таблицами соединений).
Этот API, среди прочего, даёт возможность сопоставлять перехваченные на уровне сети пакеты с локальными процессами. Казалось бы, проверенный механизм, который работает «под капотом» множества утилит и сетевых фильтров. Но в ходе тестирования WireSock Secure Connect в режиме split tunneling по процессам мы наткнулись на утечку, способную за считанные минуты выбить лимит хендлов в системе.
Поводом для расследования стало сообщение в нашей группе поддержки WireSock в Telegram: один из пользователей заметил аномально быстрый рост числа открытых дескрипторов процессов. Проблема стабильно воспроизводилась под нагрузкой и исчезала, если использовать фильтрацию по IP-адресам. Это стало первой зацепкой, которая в итоге вывела нас на баг в реализации IP Helper.
Отдельное спасибо пользователю @dno5iq, который обнаружил проблему, выполнил реверсинг GetOwnerModuleFromPidAndInfo и помог подтвердить наличие дефекта в её реализации.
Технический долг — вещь, знакомая многим компаниям и программистам. Обычно он копится годами, чтобы потом, подобно сизифову камню, держать в тонусе всех и вся. Под катом — рассказ Альберта Халимова, одного из членов команды «М.Видео – Эльдорадо», о том, как мы справляемся с подобными недугами.
В этой статье я коротко опишу один приём, который помогает мне писать код быстрее и с меньшим числом ошибок. Я говорю «приём», но по факту это просто практика, которой я начал следовать с опытом, сам того не замечая.
Когда вы работаете над чем-то сложным, формируйте в уме некое подтверждение, что ваш код будет делать именно то, что вам нужно. Звучит вроде просто, но на деле всё оказывается сложнее. Чтобы начать делать это «на лету», не прерывая рабочий поток, потребуется упорная практика. Зато, когда вы освоите эту технику, то удивитесь, насколько чаще ваш код будет полноценно работать с первой или второй попытки. Невероятно впечатляет.
Добиться этого можно по-разному, и я не хочу давать какие-то категоричные рекомендации. Просто приведу несколько примеров тех вещей, о которых я сам рассуждаю «на лету», чтобы вы могли сформировать общее представление.
Команда Rust рада сообщить о новой версии языка — 1.89.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.89.0 вам достаточно выполнить команду:
$ rustup update stable
Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.
Многие разработчики при обсуждении основ Clean Code называют одни и те же принципы — чаще всего упоминаются DRY, KISS и YAGNI. Эти концепции прочно закрепились в профессиональном сообществе и воспринимаются как обязательная часть хорошего кода.
Принцип RUG упоминается значительно реже. Чаще всего о нём узнают с опытом, а многие применяют его интуитивно, даже не подозревая, что для этого подхода существует отдельное название и формулировка.
Сегодня я хочу поговорить о принципе RUG и о том, какие рекомендации он даёт по написанию программного обеспечения.
RUG (Repeat Until Good) — это принцип, который говорит: можно повторять один и тот же код, пока это разумно.
На ранних этапах разработки важнее просто реализовать логику, исходя из текущих требований, чем пытаться сразу создать «идеальную» абстракцию. В этот момент задача — как можно быстрее получить рабочее решение, которое отражает текущие знания о системе. Но со временем, когда одна и та же логика начинает встречаться всё чаще, становится очевидно, что её удобнее и правильнее выделить в отдельную, чётко оформленную абстракцию, чтобы избежать дублирования и упростить дальнейшую поддержку.
Мы используем этот принцип каждый раз, когда пишем код. Ведь практически любую логику можно сделать более абстрактной и масштабируемой — вопрос лишь в том, когда наступает подходящий момент для этого.
Я буду использовать TypeScript, так как этот язык знаком большинству разработчиков. 😁
После того, как я опубликовал предыдущую статью, в которой рассказал о том, какие приёмы применяю, создавая Shell-скрипты, отличающиеся отличным UX, сообщество Hacker News поделилось со мной ценными откликами и предложениями. Я оформил то, что мне удалось узнать, в виде новой статьи, разобрав здесь ещё шесть приёмов, которые позволят всем желающим улучшить свои скрипты.
В этой статье подробно разбирается создание пользовательской файловой системы с помощью FUSE и языка Go. На реальном примере мы пройдём путь от установки окружения до реализации чтения, записи, метаданных и параллельного доступа. В процессе встретятся живые комментарии, личные наблюдения и советы, которые помогут избежать распространённых подводных камней.
Go (Golang) создан для эффективной параллельной и конкурентной работы. Его killer feature — легковесные потоки выполнения, называемые горутины (goroutines), и мощные средства синхронизации. Приглашаю разобраться подробно.
Когда-то в отделе разработки встраиваемого ПО в YADRO мне задали вопрос: «А как с этим взаимодействовать?». Речь шла в первую очередь о I2C для QEMU, а не GPIO. И я некоторое время был одержим идеей «прозрачного» взаимодействия с устройствами внутри QEMU — использовать те же библиотеки и инструменты, как и для реальных устройств, что может быть прекраснее? Не какой-то там скрипт для посылки команды по QMP, а знакомый и целостный gpioset/gpioget из библиотеки libgpiod или поставляемые с ядром инструменты из tools/gpio.
Получилось ли это у меня? Да, но какой ценой…
Я не считаю себя специалистом по Go и лишь изредка обращался к этому языку, но хочу поделиться историей об одном баге на стыке Go и ядра Windows, с которым мне «посчастливилось» столкнуться.
Баг до сих пор остаётся актуальным (issue на GitHub), хотя есть основания надеяться, что он будет исправлен в следующем релизе Go.
Тем не менее, если звёзды сойдутся неудачно и ваша программа на Go внезапно зависнет у клиента в вызове CancelIoEx, а воспроизвести и проанализировать проблему не удастся, то, надеюсь, приведённый ниже материал поможет понять её причины и попробовать обойти проблему.
Обязательно посмотрите shell-скрипт в репозитории — он чудо как хорош. Раскрашивает выходные данные, надёжный как скала… настоящий мастер-класс по созданию shell-скриптов.
Спасибо Гуннару Морлингу за добрые слова!
В январе 2024 года меня, вместе с несколькими дюжинами других гиков, повёрнутых на производительности, что называется, «заснайпили», заинтересовав участием в конкурсе Гуннара One Billion Row Challenge (1BRC).
Гуннара, оценивающего результаты работы конкурсантов (бесплатно), очень быстро буквально завалил непрерывный поток решений. Я рискнул помочь ему автоматизировать оценку работ и написал Shell-скрипт, за что и получил от него вышеприведённый хвалебный отзыв. Он это сказал в выступлении на конференции JavaZone (# 1BRC‑Nerd Sniping the Java Community — Gunnar Morling). Посмотрите это выступление, если хотите узнать о подходах к повышению производительности кода, применённых на конкурсе.
Здесь я расскажу о 6 приёмах, которые я использовал в Shell-скрипте для конкурса. Эти приёмы позволили сделать скрипт надёжным, безопасным и приятным в использовании для Гуннара.
Декомпиляция — это не магия, а очень упрямый, скрупулёзный и грязноватый процесс, где каждый байт может оказаться фатальным. В этой статье я разложу по винтикам, как мыслят современные декомпиляторы: как они восстанавливают структуру кода, зачем строят SSA, почему не верят ни одному call’у на слово, и как Ghidra и RetDec реализуют свои механизмы под капотом. Это не глянцевый обзор, а техразбор, вплоть до IR, реконструкции управляющего графа и попытки угадать типы переменных там, где они уже испарились. Будет сложно, но весело.
В первой статье мы разобрались с базовыми терминами: что такое Embedded Linux, чем он отличается от обычного дистрибутива, из чего состоит, как происходит его загрузка и с помощью каких инструментов всё это можно собрать.
Надеюсь, что те, кого эта тема зацепила, уже обзавелись платой с SoC на борту — без неё часть шагов будет упущена, а удовольствие от результата будет неполным.
Пришло время перейти от теории к практике!
Привет, Хабр!
Сегодня рассмотрим, как реализовать собственный бинарный семафор на основе futex и библиотеки parking_lot_core.
В начале лета меня пригласили на Data Fest 2025 в секцию по менеджменту и научным инициативам в open source. Делюсь расшифровкой доклада, но не своего, а Александра Нозика, директора Центра научного программирования.
