Обеспечение работы прикладного ПО
Это третья статья из цикла по разработке ОС на С++. В данной статье я познакомлю читателя, с прерываниями x86 реализуем ее поддержку. Добавим работу с клавиатурой. Познакомимся с такими устройствами как PIC и напишем код для работы и инициализации. Я так же буду делать упор, на абстракцию и высокоуровневый код.
Заходите будет интересно.
Продолжаем публикации из серии «математическое моделирование для самых маленьких». В предыдущих статьях мы показали, как из погони волка за зайцем можно получить формулы для систем наведения противоракетной обороны.
Там очень подробно описано как, зная скорость объекта, можно рассчитать траектории движения различных объектов в пространстве.
https://habr.com/ru/articles/878168/
В этот раз мы займемся исследованием траектории движения космических ракет. Сравним формулу Циолковского с законом Ньютона и рассчитаем отправку груза на орбиту земли одноступенчатой ракетой, и двухступенчатой. И все это – в рамках курсов школьной физики и математики с помощью структурного моделирования.
В предыдущей статье я рассматривал различные способы организации стековых корутин в языке Си. Эти сопрограммы имели чисто учебное значение так как вряд ли кто-то будет создавать генераторы последовательностей при помощи сопрограмм. Сегодня рассмотрим как писать стектовые корутины на С++ и создадим на их основе tcp сервер, обрабатывающий запросы от клиентов на основе опроса событий с использованием API мультиплексированного ввода-вывода epoll. Данная тема, на мой взгляд, является ключевой для понимания того, как функционируют современные серверные приложения, написанные при помощи таких библиотек как Boost Asio.
В текущей статье, реализуем поддержку памяти и аллокатора в ядре, а так же перегрузим new и delete используя новый механизм памяти. На последок напишем контейнер OS::String для работы со строками, интерфейс API будет совпадать с интерфейсом std::string. Что бы в будущем просто сделать using на std контейнеры. Когда получится их завести. Цель создать фундамент для использования C++ идиом (включая умные указатели и STL‑подобные контейнеры) в «голом» окружении ядра без стандартных библиотечных аллокаторов. Решение позволяет тестировать код на хост‑системе (Windows/Linux) и затем без изменений запускать на целевой платформе (QEMU).
Добрый день, всем читающим данную статью. Недавно эксперементируя с eBPF для разработки нового функционала своей EDR для linux-серверов, я столкнулся с огромной проблемой: на просторах интернета есть огромный пласт статей по теории работы с eBPF, однако кратких практических статей как работать с BPF мной найдено не было.
Если быть более точным, то такие статьи есть, однако, они не дают понимания функционала.
В общем, в данной статье хотелось бы написать краткий гайд по работе с eBPF с уклоном в практику.
Когда я впервые начал всерьез работать с кодинг-агентами, казалось, что это магия: просишь поправить модуль, а через пару минут у тебя уже пулл-реквест. Но чем больше я ими пользовался, тем чаще ловил себя на одном и том же: агент то ломает билд, то игнорирует важные договоренности по архитектуре, то переписывает код "как ему удобнее". И каждый раз приходилось руками разгребать последствия "умной" автоматизации.
Со временем стало очевидно: проблема не в модели, а в том, как мы ее онбордим в проект. Один и тот же Claude в одном репозитории ведет себя как сильный мидл, а в другом как растерянный стажер. Разница почти всегда в том, что написано (или не написано) в CLAUDE.md и его аналогах для агентов.
Я перепробовал кучу подходов: от огромных "библий" с правилами до минималистичных заметок и автогенерации. Что-то работало, что-то категорически нет. В итоге вырисовались простые, но хорошо проверенные на практике принципы того, каким должен быть CLAUDE.md, чтобы не было мучительно больно ни вам, ни агенту.
В теории я бы хотел сделать ОС на современном C++ — с умными указателями, лямбдами и прочими красивостями. А на практике пока что научился выводить текст прямо в видеопамять. Но это же и есть самый честный low-level — когда ты по-настоящему чувствуешь, как железо оживает от твоего кода.
Здравствуйте, меня зовут Анна Мелехова. Я старший архитектор в отделе развития архитектуры KasperskyOS. В статье я хочу поделиться практическим опытом системной разработки, которой я занималась сначала в проекте по виртуализации, а теперь в «Лаборатории Касперского», где мы делаем микроядерную операционную систему с повышенными требованиями к безопасности – KasperskyOS. Когда вы работаете в такой среде, быстро понимаете: харденинг – это не красивые галочки в чек-листе, а набор очень конкретных, очень практических решений, которые должны и защищать, и минимально снижать производительность. О них я и расскажу, а в конце дам личный топ самых полезных харденингов, которые бустят security и не снижают performance.
Конец ноября в Питере — крайне мрачное время года, на улице лишь холод, сырость и уныние. Что определенно влияет на психику местных жителей, порождая в головах самые нездоровые желания.
Видимо по этой причине, одним мрачным осенним днем мне захотелось создать графическое приложение на современном C++ под.. классический Mac из 90х.
Предлагаю вашему вниманию подборку ближайших событий по open source. Фокус на открытых, бесплатных тематических мероприятиях различного формата (очных, онлайн и гибридных), в том числе с научным и управленческим уклоном.
Если вы планируете подобное событие (или проводите личный доклад по теме open source, который можно послушать бесплатно) в начале следующего года, присылайте посмотреть ссылки для потенциального включения в новую подборку.
Всем привет! Наша группа занимается RISC-V Linux и загрузчиками в компании «Синтакор». Однажды перед нами возникла задача — реализовать поддержку аппаратных триггеров в ядре Linux и OpenSBI. Она стала началом исследования, в ходе которого я изучил смысл аппаратных триггеров с точки зрения отладчика, их устройство и использование для вотчпойнтов и брейкпойнтов, а также принял участие в совершенствовании поддержки аппаратных триггеров в RISC-V Linux и OpenSBI.
Этими знаниями я хотел бы поделиться в статье. Покажу на примерах, как устроены брейкпойнты и вотчпойнты в отладчиках, сравню их программную и аппаратную реализации, покопаюсь в деталях их работы в ядре Linux. Начну с легкого способа сломать GDB, а к каким выводам он приведет, вы узнаете далее под катом.
На свете есть не так много вещей, способных выбесить программиста. И лишь одна делает это с гарантией: оборзевшая в край машина, возомнившая себя умнее человека.
А значит снова пришло время карать и патчить!
Тон данной публикации задал товарищ @kiltum в своих статьях, начатых с этой. В самом начале был задан вопрос
может ли ИИ заменить программиста?
А действительно? Сколько вокруг этой темы хайпа, нет ни дня чтобы здесь на ресурсе не появилось 100 500 статей на тему нейросетей, LLM, ML и прочего. Пишут много и всякое. Возникло желание проверить лично, насколько решения, предлагаемые ИИ могут быть воплощены в жизнь.
Системы ИИ прочно вошли в нашу жизнь, и да, я тоже ими регулярно пользуюсь. Но мысли программировать с их помощью особо не возникало. Но что если попробовать, поставив при этом задачу из предметной области в которой ты не особо разбираешься? Похожий вопрос ставит и @kiltum, но я хочу попросить автора не ругаться на мою невольную попытку «пообезьянничать». Своей публикацией я лишь хочу подкрепить уже высказанные тезисы, на примере личного опыта. К тому же, старое железо — это всегда интересно, не правда ли? Если так, то добро пожаловать под кат.
Если вы когда-нибудь задумывались о написании своего языка программирования, в особенности функционального, то должны быть в курсе, что лямбда исчисление — это основа всех функциональных языков. Я решил сделать цикл статей, где мы будем реализовывать интересные алгоритмы, используемые в компиляторах, а также различные исчисления. Лямбда‑исчисление — это фундамент, с которого я и предлагаю начать погружение в эту нору.
${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 и даже вывести что-нибудь на экран.