Анестезиолог Кон Коливас разработал собственную версию планировщика задач для Linux ядра, потому что существующая реализация была адаптирована под серверные задачи, но неудовлетворительно справлялась с пользовательскими задачами.

Алексей Кузнецов, который по воле случая «превратился» в Linux хакера, сменил свою профессию с физика-теоретика на системного программиста.

ИТ-журналист Пётр Семилетов помимо своей основной работы уже десять лет разрабатывает свой текстовый редактор Tea с открытым исходным кодом.

Леся Новасельская, получившая специальность паталогоанатома, участвует в тестировании проекта c открытым исходным кодом.

Подобных примеров множество. Всех этих людей объединяет одно — они реализовали свои интересы в проектах с открытым исходным кодом и участвовали в них и для удовольствия, и для получения опыта. Сложился некий миф о том, что открытый проект – это только для программистов, причем тех, у кого уже есть большой опыт в разработке. Но это не так. Открытый проект — это не только разработка исходного кода, но и тестирование, техническая поддержка, написание документации, маркетинг и т.д. А ещё — отличный шанс приобрести опыт и получить удовольствие от общения с такими же единомышленниками, как вы. Согласно результатам голосования основным препятствием для участия в открытом проекте является отсутствие понимания того, как присоединиться к проекту. Поэтому в статье мы разберёмся как и в качестве кого можно присоединиться к такому проекту.

SystemC это библиотека для C++ позволяющая моделировать всевозможные аппаратные системы на различном уровне абстракции. Поддерживается как традиционное дискретно-событийное моделирование, привычное программистам на Verilog и VHDL, так и аналоговое моделирование в духе SPICE/Verilog AMS. В комплект также входит библиотека и методология для виртуального прототипирования, библиотеки для написания тестовых окружений и верификации с использованием рандомизированных тестов.

В этой я расскажу о синтезируемом подмножестве SystemC, сравнивая его с синтезируемым SystemVerilog. Сам я пользуюсь SystemC уже где-то 3 года, а до этого несколько лет писал на Verilog/SystemVerilog. Попытаюсь охватить предмет с разных сторон: начиная с философских рассуждений о причинах возникновения SystemC, краткого обзора экосистемы и инструментария и заканчивая практическими примерами синтаксиса и семантики.

Подразумевается, что читатели знакомы с Verilog и C++.

Здарова! Короче, последнее время на хабре было много срачей вокруг Go: хороший-плохой, нужен-ненужен, много сравнивали с питоном, много сравнивали с растом, divan0 даже додумался перевести высер «Go vs Haskell» ну и в таком ключе. У меня сложилось ощущение, что из-за хайпа и агрессивного маркетинга языка некоторыми Иванами Данилюками очень мало кто понял, кому и зачем вообще Go может пригодиться, зачем его делали и стоит ли вообще его учить. Я тоже долгое время участвовал в этих срачах, принимая посменно сторону «фанов» языка и сторону оппозиции, но в конце-концов допер, в чем фокус. Сегодня немного потупил у дивана в посте и решил написать вот эту заметочку.

Давайте, пацаны, проходим в пост.

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

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

Я пишу мультипротокольный (но не мультиплатформенный, увы, сейчас только windows) мессенджер, который пока что поддерживает только протокол TOX. Но речь не о мессенджере, а о его интерфейсе, а если точнее, об основной его функции — AlphaBlend. Да, я решил написать свой велосипед GUI. Ну а какой современный GUI без полупрозрачных элементов и плавных закруглений? Поэтому остро встала необходимость смешивать изображения с учетом полупрозрачности, т.е. альфа-смешивание или alpha blending. К счастью, в windows GDI такая функция имеется — AlphaBlend. Работает как надо, делает то что нужно. Но я тот еще строитель велосипедов, и мне стало интересно, смогу ли я написать такую же функцию, но более быструю. Результат моих трудов под катом.

В статье подробно рассказано о самомодифицирующимся коде (СМК), и о том, как его использовать в своих программах. Примеры написаны на C++ с использованием встроенного ассемблера. Ещё я расскажу о том, как выполнять код на стеке, что является существенным козырем при написании и выполнении СМК.

1. Вступление

Ну что ж, поехали. Статья обещает быть длинной, так как мне хочется написать её такой, чтобы у вас не возникло никаких вопросов. На тему СМК уже существует миллион статей, но здесь представлено моё видение проблемы – после сотен часов написания СМК… Я попытаюсь впихнуть все свои труды сюда. Всё, хватайте томатный сок (или что вы там предпочитаете пить), делайте музыку громче и готовьтесь узнать, как избавить своё приложение от начинающих кракеров! Попутно, я расскажу вам о памяти Windows и некоторых других вещах, о которых вы даже и не подозреваете.

Сегодня я расскажу о неожиданных проблемах, которые возникли при подключении матричной клавиатуры к ARM-борде под управлением Linux в приборе Беркут-ETN (ETN — новая аппаратная ревизия Беркут-ET). А конкретно о том, почему драйвер adp5589 не захотел получать прерывания и как мы смогли заставить его это делать.

Кому интересно — добро пожаловать под кат.

Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.

Похрустев немного жестким диском, красивый инсталятор показал мне совершенно некрасивое сообщение об ошибке. Вот такое:


Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

Отвечают на все эти вопросы специалисты первой линии техподдержки Microsoft, советы которых сводятся к «отключите антивирус», «проверьте чексуму образа со студией», «проверьте диск на ошибки». Ничего из этого, конечно, не помогает, о чём им и рассказывают, после чего они пропадают и больше не отвечают. Очень дружелюбная пользовательская поддержка, ничего не скажешь.

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

Нередко у программистов, пишущих драйверы, возникают некоторые трудности с обменом данными в 64-битном формате. Давайте разберём некоторые ситуации.

По сравнению со многими современными языками язык Си зачастую кажется крайне примитивным и небезопасным. И одной из частых претензий к языку является невозможность доступа из кода в его же внутреннее представление. В других языках это традиционно осуществляется механизмами, вроде reflections, и довольно удобно в применении.

Тем не менее, с появлением libclang, можно писать собственные анализаторы и генераторы кода прямо в compile time, устраняя достаточно большое множество проблем на ранних этапах работы. Сочетание инструментов статического анализа общего плана (coverity, clang-scan), инструментов анализа для конкретного проекта, а также дисциплины написания кода позволяет намного улучшить качество и безопасность кода, написанного на Си. Конечно, это не даст гарантий, каких дает haskell или даже rust, но позволяет существенно оптимизировать процесс разработки, особенно в случае, когда переписывать огромный проект на другом языке является нереальной задачей.

В данной статье я хотел бы поделиться опытом создания плагина статического анализа format argument для функций, похожих на printf. В ходе написания плагина, мне пришлось очень много рыться в исходниках и doxygen документации libclang, поэтому я счел полезным сделать некоторый обзор для тех, кто хочет ступить на этот тернистый путь, но пока еще не уверен в целесообразности траты времени на сбор информации. В статье не будет картинок, и даже картинок блюющих единорогов, простите.

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

В этой статье мы намерены подробно изложить работу с ошибками в Rust. Более того, мы попробуем раз за разом погружаться в обработку ошибок с различных сторон, так что под конец у вас будет уверенное практическое представление о том, как все это сходится воедино.

В наивной реализации обработка ошибок в Rust может выглядеть многословной и раздражающей. Мы рассмотрим основные камни преткновения, а также продемонстрируем, как сделать обработку ошибок лаконичной и удобной, пользуясь стандартной библиотекой.

От переводчика: представляю вашему вниманию перевод статьи Майкла Штейла. Я давно хотел подготовить подобный обзор методов использования виртуализации для задач обеспечения совместимости. Я даже опубликовал некоторые заметки на эту тему: в учебнике по симуляции, глава 1, и на Хабре в посте про системные ВМ. Однако мне не удалось раскрыть вопрос так глубоко, как он представлен в этой работе. Поэтому я решил поделиться переводом с читателями.

---

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

Давайте рассмотрим, как это происходило в последние 30 лет, на примерах MS DOS/Windows, Apple Macintosh, Amiga OS и Palm OS.

Доброго времени суток!
Хочу представить вашему вниманию перевод статьи Джонатана Барлетта (Jonathan Bartlett), который является техническим директором в компании New Medio. Статья была опубликована 16 ноября 2004 года на сайте ibm.com и посвящена методам управления памятью. Хотя возраст статьи достаточно высок (по меркам IT), информация в ней является фундаментальной и описывает подходы к распределению памяти, их сильные и слабые стороны. Всё это сопровождается «самопальными» реализациями, для лучшего усвоения материала.

Аннотация от автора
Решения, компромиссы и реализации динамического распределения памяти
Получите представление о методах управления памятью, которые доступны Linux разработчикам. Данные методы не ограничиваются языком C, они также применяются и в других языках программирования. Эта статья даёт подробное описание как происходит управление памятью, на примерах ручного подхода (manually), полуавтоматического (semi-manually) с использованием подсчёта ссылок (referencing count) или пула (pooling) и автоматического при помощи сборщика мусора (garbage collection).

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

Вот о чем речь:

<VirtualHost *:80>
    ServerName host1.example.com
    ServerAdmin webmaster1@example.com
    ServerUserGroup user1 group1
    DocumentRoot /var/www/host1
</VirtualHost>
<VirtualHost *:80>
    ServerName host2.example.com
    ServerAdmin webmaster2@example.com
    ServerUserGroup user2 group2
    DocumentRoot /var/www/host2
</VirtualHost>

При этом корневые директории виртуальных хостов могут быть доступны только соответсвующим пользователям:

# ls -la /var/www
total 16
drwxr-xr-x   4 root  root   4096 Oct 26 16:10 .
drwxr-xr-x  21 root  root   4096 Oct 26 01:13 ..
drwxr-x---   2 user1 group1 4096 Oct 26 16:10 host1
drwxr-x---   2 user1 group2 4096 Oct 26 16:10 host2

Это не очередные танцы с бубном вогруг многопоточности, запуска процессов от рута и т.п. Основная идея в том, чтобы процесс самостоятельно решил, с какими правами ему необходимо обработать запрос, взял себе эти права, обработал, и снова вернул себе права основного пользователя apache.

Не так давно у меня появилась необходимость загружать конфигурацию приложения при очень ограниченных ресурсах. Не было доступа, практически, ни к каким стандартным функциям C. Очень повезло, что были стандартные функции по работе с памятью malloc()/free().

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

Из этого можно сделать вывод, что надо либо:

1. Писать свой редактор бинарного формата.
2. Использовать текстовый формат.

От переводчика. Представляю вашему вниманию перевод поста Майкла Штейла (Michael Steil) http://www.pagetable.com/?p=308. В нём затрагиваются вопросы сомнительной практики именования сущностей в спецификациях вычислительных архитектур.
Эта заметка очень хорошо отражает ситуацию с именами, возникающую в процессе длительной эволюции документации, и моё собственное недоумение, когда я впервые встретился с этими понятиями.
Комментарии к тексту размещены во всплывающих подсказках.

Имеется в виду выполнение записи по аппаратно защищённому от записи адресу памяти в архитектуре x86. И то, как это делается в операционной системе Linux. И, естественно, в режиме ядра Linux, потому как в пользовательском пространстве, такие трюки запрещены. Бывает, знаете ли, непреодолимое желание записать в защищённую область … когда садишься писать вирус или троян…

Описание проблемы

… а если серьёзно, то проблема записи в защищённые от записи страницы оперативной памяти возникает время от времени при программировании модулей ядра под Linux. Например, при модификации селекторной таблицы системных вызовов sys_call_table для модификации, встраивания, имплементации, подмены, перехвата системного вызова — в разных публикациях это действие называют по разному. Но не только для этих целей… В очень кратком изложении ситуация выглядит так:

• В архитектуре x86 существует защитный механизм, который при попытке записи в защищённые от записи страницы памяти приводит к возбуждению исключения.
• Права доступа к странице (разрешение или запрет записи) описываются битом _PAGE_BIT_RW (1-й) в соответствующей этой странице структуре типа pte_t. Сброс этого бита запрещает запись в страницу.
• Со стороны процессора контролем защитой записи управляет бит X86_CR0_WP (16-й) системного управляющего регистра CR0 — при установленном этом бите попытка записи в защищённую от записи страницу возбуждает исключение этого процессора.

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

Если вам интересно, чем безопасности прошивки могут помочь STM, SGX и PSP — жду вас под катом.

Желая показать бунтарский дух и наплевательство на традиции, ссылки на предыдущие части не даю — сами ищите их там.

В преддверии Java-конференции Joker 2015, которая начнется уже завтра, я публикую большое интервью с Алексеем Шипилёвым, инженером команды Java Performance Team из Oracle, одним из самых крутых и известных во всем мире специалистов по производительности. Ну и конечно, прекрасным спикером.

С Алексеем мы подробно поговорили:

• про грядущие изменения в классе String;
• про то, кто же на самом деле разрабатывает OpenSource;
• про системных разработчиков и их карьеру;
• про обмен технологиями, «научную» и «продуктовую» разработку;
• про сложность низкоуровневых задач;
• про развитие Java-сообщества и бенчмарк-войны;
• про mutable vs immutable;
• про Unsafe;
• про JMH, бенчмарки и узкую специализацию.

Вот видео нашего разговора. Больше часа длиной, можно слушать в дороге.



Ниже под катом — расшифровка нашей беседы для тех, кто видео не очень.