Системное программирование *

Добрый день, всем читающим данную статью. Недавно эксперементируя с eBPF для разработки нового функционала своей EDR для linux-серверов, я столкнулся с огромной проблемой: на просторах интернета есть огромный пласт статей по теории работы с eBPF, однако кратких практических статей как работать с BPF мной найдено не было.

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

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

Со временем стало очевидно: проблема не в модели, а в том, как мы ее онбордим в проект. Один и тот же Claude в одном репозитории ведет себя как сильный мидл, а в другом как растерянный стажер. Разница почти всегда в том, что написано (или не написано) в CLAUDE.md и его аналогах для агентов.

Я перепробовал кучу подходов: от огромных "библий" с правилами до минималистичных заметок и автогенерации. Что-то работало, что-то категорически нет. В итоге вырисовались простые, но хорошо проверенные на практике принципы того, каким должен быть CLAUDE.md, чтобы не было мучительно больно ни вам, ни агенту.

В теории я бы хотел сделать ОС на современном C++ — с умными указателями, лямбдами и прочими красивостями. А на практике пока что научился выводить текст прямо в видеопамять. Но это же и есть самый честный low-level — когда ты по-настоящему чувствуешь, как железо оживает от твоего кода.

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

Здравствуйте, меня зовут Анна Мелехова. Я старший архитектор в отделе развития архитектуры KasperskyOS. В статье я хочу поделиться практическим опытом системной разработки, которой я занималась сначала в проекте по виртуализации, а теперь в «Лаборатории Касперского», где мы делаем микроядерную операционную систему с повышенными требованиями к безопасности – KasperskyOS. Когда вы работаете в такой среде, быстро понимаете: харденинг – это не красивые галочки в чек-листе, а набор очень конкретных, очень практических решений, которые должны и защищать, и минимально снижать производительность. О них я и расскажу, а в конце дам личный топ самых полезных харденингов, которые бустят security и не снижают performance.

Есть старая инженерная мудрость:

Если у вас не хватает проводов — значит, вы недостаточно творчески подходите к вопросу.

У нас была ровно такая ситуация.

Работая на одном проекте системы «умного города» мы, уйдя в стандарт «одна плата с разными конфигами для всего» решили делать на ней свой BMS. Зачем да почему? Нужно было универсальное решение, которое должно работать и с литиевыми, и со свинцовыми батареями, и с ещё парой экзотических химий, встречающихся в природе примерно так же часто, как радужные единороги. Нужно было надёжно определять тип батареи, считывать её состояние, пригодность к использованию, дату производства и всё‑всё‑всё подобное, блокировать несовместимые варианты и вообще предотвращать самое главное — человеческую ошибку. Но как это часто бывает в компаниях где в R&D священный хаос — никто и не задумывался чтобы сесть и обсудить «А как мы вообще это делать будем». В производство ушла тысяча плат.

В любой другой ситуации мы бы пошли по наименьшему пути сопротивления: i2c на коннекторе рядом и EEPROM на аккуме. Но не тут было.

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

Видимо по этой причине, одним мрачным осенним днем мне захотелось создать графическое приложение на современном C++ под.. классический Mac из 90х.

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

Если вы планируете подобное событие (или проводите личный доклад по теме open source, который можно послушать бесплатно) в начале следующего года, присылайте посмотреть ссылки для потенциального включения в новую подборку.

Всем привет! Наша группа занимается RISC-V Linux и загрузчиками в компании «Синтакор». Однажды перед нами возникла задача — реализовать поддержку аппаратных триггеров в ядре Linux и OpenSBI. Она стала началом исследования, в ходе которого я изучил смысл аппаратных триггеров с точки зрения отладчика, их устройство и использование для вотчпойнтов и брейкпойнтов, а также принял участие в совершенствовании поддержки аппаратных триггеров в RISC-V Linux и OpenSBI. 

Этими знаниями я хотел бы поделиться в статье. Покажу на примерах, как устроены брейкпойнты и вотчпойнты в отладчиках, сравню их программную и аппаратную реализации, покопаюсь в деталях их работы в ядре Linux. Начну с легкого способа сломать GDB, а к каким выводам он приведет, вы узнаете далее под катом.

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

А значит снова пришло время карать и патчить!

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

Иногда я ловлю себя на странном ощущении: будто многие современные инструменты исполняют роль такого мягкого пуха, через который мы перестали чувствовать остроту реального программирования. И тут я не о ностальгии, а скорее о том, что те, кто начинал путь в девяностых или в начале нулевых, делали свою работу в куда более жестком окружении. Без фреймворков, без бесконечных библиотек, без удобных механизмов вроде ленивых генераторов и автоматических сборщиков. Даже если вы сами не пережили ту эпоху, наверняка хотя бы слышали истории, как кто-то руками поднимал сетевой стек или писал собственный шаблонизатор, просто потому что другого варианта не было.

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

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

может ли ИИ заменить программиста?

А действительно? Сколько вокруг этой темы хайпа, нет ни дня чтобы здесь на ресурсе не появилось 100 500 статей на тему нейросетей, LLM, ML и прочего. Пишут много и всякое. Возникло желание проверить лично, насколько решения, предлагаемые ИИ могут быть воплощены в жизнь.

Системы ИИ прочно вошли в нашу жизнь, и да, я тоже ими регулярно пользуюсь. Но мысли программировать с их помощью особо не возникало. Но что если попробовать, поставив при этом задачу из предметной области в которой ты не особо разбираешься? Похожий вопрос ставит и @kiltum, но я хочу попросить автора не ругаться на мою невольную попытку «пообезьянничать». Своей публикацией я лишь хочу подкрепить уже высказанные тезисы, на примере личного опыта. К тому же, старое железо — это всегда интересно, не правда ли? Если так, то добро пожаловать под кат.

Если вы когда-нибудь задумывались о написании своего языка программирования, в особенности функционального, то должны быть в курсе, что лямбда исчисление — это основа всех функциональных языков. Я решил сделать цикл статей, где мы будем реализовывать интересные алгоритмы, используемые в компиляторах, а также различные исчисления. Лямбда‑исчисление — это фундамент, с которого я и предлагаю начать погружение в эту нору.

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

${habrauser}, Привет!

Продолжаю здесь рассказывать о внутренних процессах игрового фреймворка Oriol Engine, разработка которого до сих пор идёт, и мы не собираемся останавливаться. (⌐■_■)

На Хабре я уже писал о решении проблемы кросс-компиляции шейдеров в данном фреймворке — ShaderPack. Ну а сегодняшняя наша тема будет именно о сборке проектов с помощью Oriol Engine и о том, что в этот момент происходит на его стороне.

Дорогие читатели, вы, наверное, не слышали об AerynOS. Это — новый дистрибутив, который его автор — Ikey Doherty — спроектировал прямо с нуля, используя свой богатый опыт с Solus Linux и ClearLinux. Хорошая новость — в том, что всё получилось, и дистрибутив сейчас в стадии твёрдой альфы, плохая — что автор снова отошёл от дел на неопределённое время.

Но, прежде чем взять долгую паузу в разработке, Ikey Doherty написал длинный пост о технической стороне вопроса — какие идеи были заложены в AerynOS и как они воплощались на практике. Несмотря на то, что всё удалось реализовать, как задумывалось, в некоторых вопросах, всё‑таки, выяснилось, что «зашли не в тот подъезд». Но в целом, после прочтения этого поста складывается некоторая картина - как должен выглядеть современный дистрибутив — чем и хочу с вами поделиться.

Некоторые из IT-компаний говорят, что поддерживают open source. На деле это нередко означает использование чужого кода и PR-активность. Мы считаем, что настоящий вклад — это коммиты в ядро. И чтобы делать это системно, мы открыли инженерный центр не в столичном бизнес-парке, а в месте, где фундаментальная наука — часть культурного кода. Рассказываем, почему будущее системного программирования мы строим в новосибирском Академгородке.

${habrauser}, Привет!

При разработке игрового фреймворка Oriol Engine (которая, к слову, до сих пор ведётся) мы столкнулись с проблемой написания шейдеров для Cross-API рендеринга. В RHI-слой данного фреймворка было запланировано добавить поддержку таких графических API, как DX11/DX12, OpenGL и Vulkan.

И вот тут возникает вопрос: как же писать шейдеры на одном языке и обеспечить их поддержку на других графических API?

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

Почему бы не запустить своё ядро прямо на смартфоне? Без Android, без Linux — только Rust, загрузчик и паяльник. В этой статье расскажу о результатах своего эксперимента, как оживить голое ARM-железо, увидеть первые символы в UART и даже вывести что-нибудь на экран.