Я автоматизировал FTPS через LFTP, потому что c этой задачей не справился Python с его великим разнообразием пакетов в "Сырном Магазине". Читайте историю из компании с примерами кода и погружением в детали проблемы.
Вопрос о том, можно ли загрузить линукс на микроконтроллерах Espressif я
впервые услышал в 2015, в период бума esp8266. Тогда мой ответ на него
был: "нет, не это ядро и не на этом железе". Но прошло 8 лет и ответ
изменился на "да, и у меня есть рабочий пример". Дальше рассказ о том,
как это произошло.
Некоторое время назад я писал об идее проекта под названием «Сивелькирия». Данный проект представляет собой гибрид среды выполнения и операционной системы. Сегодня, когда прототипы нескольких ключевых систем завершены и покрыты тестами, подтверждающими, что модули в такой среде способны выполняться и обмениваться вызовами, я хотел бы подробнее рассказать об архитектуре решения.
Как правило, при покупке материнской платы для микрокомпьютера типа Raspberry или Jetson в документации есть распиновка. Распиновка показывает как связаны физические пины платы с пинами процессора. Однако, мало в какой документации найдётся описание связи между виртуальными пинами системы и физическими пинами платы. Постараемся в этом разобраться на примере микрокомпьютера Jetson Nano от Nvidia.
Как обычно пишут сервер, если не особо заботиться производительности? Программа запускается, затем начинает принимать входящие соединения от клиентов и для каждого клиента запускает новый поток, который занимается обслуживанием этого клиента. Если вы используете какой-нибудь, прости господи, Spring или Flask или там Poco, то он что-такое внутри себя и делает - разве что потоки можно переиспользовать, то есть брать из некого пула. Это всё довольно удобно, но не слишком эффективно. Скорее всего, ваши потоки, обслуживающие клиентов, живут недолго и большую часть времени ожидают либо получения данных от клиента, либо отправки их клиенту - то есть ждут возвращения системных вызовов. Создание потока ОС - довольно дорогая операция, как и переключение контекста между потоками ОС. Если вы хотите уметь обслуживать много клиентов эффективно, надо придумать что-то другое. Например, коллбеки. Но это довольно неудобно.
С годами подходы к обработке конкурентности в ядре Linux сильно изменились. К 2023 году в арсенале разработчиков ядра появились, в частности, автозавершения, хорошо оптимизированные мьютексы, а также россыпь неблокирующих алгоритмов. Но были времена, когда управление конкурентностью сводилось к использованию обычных семафоров. Дискуссия о внесении небольшого изменения в API семафоров лишний раз свидетельствует, как сильно они изменились за долгую историю ядра.
Команда Rust рада сообщить о новой версии языка — 1.69.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.69.0 вам достаточно выполнить команду:
rustup update stableЕсли у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать beta (rustup default beta) или nightly (rustup default nightly) канал. Пожалуйста, сообщайте обо всех встреченных вами ошибках.
В марте прошлого года многие зарубежные вендоры заявили о приостановке поставок и технической поддержки для российских предприятий. Для нашей компании данное событие не стало неожиданным. Последние два десятилетия усилия предприятия были направлены на освоение и воспроизводство обширного пласта технологий разработки и развития ОС без участия иностранного капитала и специалистов.
Рассматривать этот опыт можно с разных сторон. В статье рассмотрим процесс становления технологической независимости на примере отдельно взятой подсистемы ОС «Нейтрино». Ожидается большое число ссылок на первоисточники и обилие сведений.
Команда Rust с радостью сообщает о выпуске новой версии языка Rust 1.69.0. Rust - это язык программирования, позволяющий всем создавать надежное и эффективное программное обеспечение.
Cargo теперь предлагает автоматически исправлять некоторые предупреждения.
Rust 1.69.0 добавил команду cargo fix, чтобы автоматически исправлять некоторые простые предупреждения компилятора. Кроме того, была добавлена поддержка автоматического исправления некоторых простых предупреждений Clippy. Чтобы привлечь больше внимания к этим возможностям, Cargo теперь будет предлагать запустить cargo fix или cargo clippy --fix при обнаружении автоматически исправляемых предупреждений:
Процесс запуска компьютера всегда был интересен пользователям. Именно здесь начинается магия, которое продолжается, пока устройство включено. В этой статье рассматривается общая картина процесса загрузки, включая различные этапы, ключевые компоненты, задачи, с которыми сталкивается система во время загрузки. Несмотря на то, что основное наше внимание будет сосредоточено на x86 архитектуре, остальные архитектуры будут иметь много общего в их процессе запуска. Приступим!
Многие расширения (модули) Python поставляются в виде платформонезависимого байт-кода и могут быть использованы в системах с любой архитектурой. Однако, в некоторых случаях расширения поставляются в виде Py-исходников лишь частично. Например, часть внутренних функций может быть реализована на Си и для обеспечения работоспособности всего расширения потребуется их предкомпиляция для каждой требуемой архитектуры. В контексте ОС «Нейтрино» перечень последних достаточно широк.
В статье рассмотрим общий подход к портированию Python-расширений в нашу ОС. Для примера возьмем NumPy, чей жизненный путь проходит следующие стадии: нативный Pyhton код →трансляция в Си (Cython) → компиляция → запаковка результатов с wrapper-ами для Python.
В своей прошлой статье я не был полностью честен. Перед тем, как получить рабочее устройство, я много раз проверял как мой код работает, перезаписывая его на многоразовую флеш AT28С64. И с самого начала знал что отлаживаться придется на железе, а потому встал вопрос программатора параллельных EEPROM.
Некогда крайне востребованные, а ныне необходимые только для редких специфических задач, эти программаторы стоят неприлично дорого (на этот раз серьезно). Есть бюджетные варианты, например собрать такой программатор на основе ардуины (но не весело) или быстро изобрести решение самому (но лень писать софт).
Однако, у отца оказался программатор Omega. На самом деле это не совсем программатор, это базовый блок на основе которого, теоретически, можно собрать множество разных устройств используя разные адаптеры, но один из адаптеров (имеющихся в наличии) — это универсальный программатор Orange. Все это разработки cnc‑lab.com, там же можно найти описание этого железа http://cnc‑lab.com/omega.htm . Но есть одна небольшая загвоздка: у меня современные компьютеры с Windows 10 и Windows 11, а этот программатор использует LPT. И нужно было как‑то из этой ситуации выходить.
Эта статья о том, как можно заставить работать на новом компьтере старый софт и старое железо, рассчитанные на связь через LPT, при этом не прибегая к изменению ни оригинальных исполняемых файлов, ни схемотехники устройства.
С помощью этого учебного материала мы научимся писать кросс-платформенный код на Си, используя системные функции популярных ОС (Windows, Linux/Android, macOS и FreeBSD): управление файлами и файловый I/O, консольный I/O, пайпы (неименованные), запуск новых процессов. Мы напишем свои небольшие вспомогательные функции поверх низкоуровневого системного АПИ (API), для того чтобы наш основной код, используя эти функции, мог работать на любой ОС без изменений. Этот учебный материал — начального уровня. Я делю сложные вещи на части, чтобы примеры кода здесь не были слишком заумными для тех, кто только что начал программировать на Си. Мы обсудим различия между системными АПИ и разберёмся, как создать кросс-платформенный программный интерфейс, который скрывает все эти различия от пользователя этого интерфейса.
Одной из важных задач операционной системы является управление различными устройствами ввода/вывода, включая: мышь, клавиатуру, тачпад, дисковые накопители, адаптеры дисплея, USB-устройства, экран с поточечной адресацией, светодиоды, аналого-цифровой преобразователь, переключатель включения/выключения, сетевые подключения, аудио-входы/выходы, принтеры и т. д.
Система ввода/вывода должна принимать запрос приложения на ввод/вывод и посылать его физическому устройству, затем принимать ответ от устройства и посылать его приложению. Устройства ввода/вывода можно разделить на две категории: блочные и символьные устройства.
При написании предыдущей статьи я наткнулся на странный эффект с производительностью TCP-сокетов. При попытке отправить пачку запросов через сокет оказалось, что выгоднее заново устанавливать TCP-соединение после каждого запроса, а не переиспользовать его. Исследованию причин этого эффекта (а заодно и поиску способов от него избавиться) и посвящена эта статья.
NULL. Shit happens, как говорится…
Язык программирования Rust был разработан компанией Mozilla и впервые представлен в 2010 году. Он считается одним из самых безопасных и производительных языков программирования на сегодняшний день. В данной статье мы рассмотрим основные преимущества Rust, и почему он становится все более популярным в системном программировании.
Начнем с простого вопроса:
Что означает QEMU/KVM или QEMU-KVM?
Можно ответить - это QEMU + KVM или qemu-system, запущенный с kvm в качестве ускорителя. Но в какой-то степени это еще и анахронизм, так как с появлением KVM его разработчики для интеграции с QEMU поддерживали отдельный форк qemu-kvm, но начиная с QEMU версии 1.3 (декабрь 2012) все основные изменения из qemu-kvm были перенесены в главную ветку QEMU, а qemu-kvm объявлен устаревшим.
В разных дистрибутивах до сих пор еще можно встретить исполняемый файл qemu-kvm или просто kvm, но это лишь обертки над qemu-system:
exec qemu-system-x86_64 -enable-kvm "$@"
или симлинки:
/usr/bin/kvm -> qemu-system-x86_64
А в самом qemu существует проверка:
Можно разрабатывать на Java, а можно разрабатывать Java. Есть люди, чей код исполняет виртуальная машина — а есть люди, чей код и есть виртуальная машина.
Вроде бы те и другие существуют в одной Java-экосистеме, но задачи совершенно разные. Поэтому редкое место, где они пересекаются и могут что-то поведать друг другу — Java-конференции. Мы проводим их регулярно (уже в апреле будет JPoint). И на предыдущей нашей конференции Иван Углянский dbg_nsk поделился с Java-разработчиками тем, как всё выглядит с его стороны.
Чем он вообще занимается? Почему JVM-инженеры всё так медленно делают? На каком языке стоит писать рантайм, а на каком компилятор? Как «папка бога» в Windows привела к неожиданным последствиям? Может ли «обычный джавист» стать JVM-инженером?
Поскольку все эти вопросы из доклада звучат интересно, мы решили для Хабра сделать его текстовую версию (а для тех, кому удобнее видео, прикладываем ссылку на ютуб). Далее повествование идёт от лица Ивана.