Siemargl

После публикации статьи прошло уже более двух лет, модели 1400 серии на сегодняшний день убраны из продажи. Пришло время для изменений и новшеств, эту задачу CheckPoint постарался реализовать в 1500 серии. В статье мы рассмотрим модели для защиты небольших офисов или филиалов компании, будут представлены технические характеристики, особенности поставки (лицензирование, схемы управления и администрирования), коснемся новых технологий и опций.

Модельный ряд

В качестве новых SMB моделей представлены: 1530, 1550, 1570, 1570R. Ознакомиться с продуктами возможно на странице портала CheckPoint. Логически мы разделим их на три группы: офисный шлюз безопасности с поддержкой WIFI (1530, 1550), офисный шлюз безопасности с поддержкой WIFI + 4G/LTE (1570, 1550), шлюз безопасности для промышленности (1570R).

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

Хотя это только четвёртая публикация в этой серии, это уже третья, в которой я рассказываю о способах избежать использования GC. Не обманитесь: я не пытаюсь отпугнуть программистов от сборщика мусора в языке D. Как раз наоборот. Понимание того, когда и как обходиться без GC, необходимо для эффективного его использования.

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

D, как и многие активно используемые сегодня языки, поставляется со сборщиком мусора (Garbage Collector, GC). Многие виды ПО можно разрабатывать, вообще не задумываясь о GC, в полной мере пользуясь его преимуществами. Однако у GC есть свои изъяны, и в некоторых сценариях сборка мусора нежелательна. Для таких случаев язык позволяет временно отключить сборщик мусора или даже совсем обойтись без него.

Чтобы извлечь максимум пользы от сборщика мусора и свести его недостатки к минимуму, необходимо хорошо понимать, как работает GC в языке D. Хорошей точкой старта будет страничка «Garbage Collection» на dlang.org, которая подводит обоснование под GC в языке D и даёт несколько советов о том, как с ним работать. Это — первая из серии статей, которая призвана более подробно осветить тему.

В первой из серии статей о GC я представил сборщик мусора в языке D и возможности языка, которые его используют. Два ключевых момента, которые я пытался донести:

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

   
   

2. Простые стратегии выделения памяти в стиле C и C++ позволяют уменьшить нагрузку на GC. Не выделяйте память внутри циклов — вместо этого как можно больше ресурсов выделяйте заранее или используйте стек. Сведите к минимуму общее число выделений памяти через GC. Эти стратегии работают благодаря пункту № 1. Разработчик может диктовать, когда допустимо запустить сборку мусора, грамотно используя выделение памяти из кучи, управляемой GC.

   
   

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

Когда сборщик мусора отключён через GC.disable или запрещён к использованию атрибутом функции @nogc, память всё ещё надо откуда-то выделять. И даже если вы используете GC на всю катушку, всё равно желательно минимизировать объём и количество выделений памяти через GC. Это означает выделение памяти или на стеке, или в обычной куче. Эта статья будет посвящена первому. Выделение памяти в куче будет предметом следующей статьи.

И снова здравствуй. Какое-то время назад я писал о другом малоизвестном инструменте для любителей высокой производительности — System.IO.Pipelines. По своей сути, рассматриваемый System.Threading.Channels (в дальнейшем «каналы») построен по похожим принципам, что и Пайплайны, решает ту же задачу — Производитель-Потребитель. Однако имеет в разы более простое апи, которое изящно вольется в любого рода enterprise-код. При этом использует асинхронность без аллокаций и без stack-dive даже в асинхронном случае! (Не всегда, но часто).

Крис Хоббс (Chris Hobbs) в своей фундаментальной работе «Embedded Software Development for Safety-Critical Systems» [1] приводит распространенное среди программистов мнение о том, что накладывать ограничения на языки программирования, это как заказывать Пикассо создание картины, при этом запрещать ему использовать желтый цвет. Тем не менее, сложно представить себе предприятие, которое серьезно занимается разработкой программного обеспечения для систем ответственного назначения, у которого в писанных или неписанных стандартах не было бы указаний о том, какой язык программирования применять и, мало того, как его применять.

Данная статья посвящена подходу, который определен в стандарте IEC 61508 и который состоит в применении для разработки ответственного программного обеспечения безопасных подмножеств языков программирования С и С++.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи "Using GitHub Actions with C++ and CMake" о сборке проекта на C++ с использованием GitHub Actions и CMake автора Кристиана Адама.

Использование GitHub Actions с C++ и CMake

В этом посте я хочу показать файл конфигурации GitHub Actions для проекта C++, использующего CMake.

GitHub Actions это предоставляемая GitHub инфраструктура CI/CD. Сейчас GitHub Actions предлагает следующие виртуальные машины (runners):

Каждая виртуальная машина имеет одинаковые доступные аппаратные ресурсы:

• 2х ядерное CPU
• 7 Гб оперативной памяти
• 14 Гб на диске SSD

Каждое задание рабочего процесса может выполняться до 6 часов.

Представьте себе, вам необходимо доработать некую очень полезную программу без SDK, но по счастливому стечению обстоятельств рядом завалялся PDB файл.

(Беременным и детям не читать!)

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

Раннее было принято решение построить систему автоматизации на базе одноплатного микрокомпьютера Orange pi plus 2e и микроконтроллера Arduino Nano. Для этих плат нашлось применения для другого подобного проекта, но это уже другая история. Но в последствии, после обсуждений всех преимуществ и недостатков остановились на PLC CPU 1214C DC/DC/DC с каталожным номером 6ES7 214-1AG40-0XB0 у которого на борту можно сконфигурировать до четырех импульсных выводов управления и модуль дискретных выходов SM 1222 DQ16 x 24VDC с каталожным номером 6ES7 222-1BH32-0XB0. Шаговые двигатели были выбраны из серии KRS56, управляемые драйверами TB6560 V2.

Мы уже писали о сборке мусора для JavaScript, о DOM, и о том, как всё это реализовано и оптимизировано в JS-движке V8. Правда, Chromium — это не только JavaScript. Большая часть браузера и движок рендеринга Blink, куда встроен V8, написаны на C++. JavaScript можно использовать для работы с DOM, а на экран изменения выводятся с использованием конвейера рендеринга.

Так как граф C++-объектов, имеющих отношение к DOM, тесно связан с JavaScript-объектами, команда разработчиков Chromium пару лет назад начала использовать для управления памятью, в которой хранятся эти объекты, сборщик мусора, названный Oilpan. Oilpan — это сборщик мусора, написанный на C++ и предназначенный для управления C++-памятью, которая может быть подключена к V8. Управление памятью осуществляется с использованием технологии кросс-компонентной сборки мусора. В рамках этой технологии граф связанных C++/JavaScript-объектов рассматривается как единая куча.



Этот материал является первой публикацией, посвящённой Oilpan. Здесь будет сделан обзор основных принципов, лежащих в основе данного сборщика мусора, а также — C++-API Oilpan. Мы рассмотрим некоторые возможности, поддерживаемые Oilpan, расскажем о том, как устроена работа различных подсистемам сборщика мусора. Тут же мы разберём процесс конкурентного освобождения памяти, занятой объектами.

Самое интересное здесь то, что система Oilpan является частью Blink, но сейчас осуществляется её перевод в V8, где она будет представлена в форме библиотеки для сборки мусора. Цель этого всего заключается в том, чтобы облегчить доступ к C++-механизмам сборки мусора всем тем, кто встраивает в свои платформы движок V8. Кроме того, то, что Oilpan станет библиотекой, позволит пользоваться этой системой абсолютно всем заинтересованным в ней C++-программистам.

Месяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)

Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:

1. С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
2. Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
3. Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
4. Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)

Начну со статистики по мартовскому релизу LLVM 10.0:
В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.

А вот распределение по числу инструкций:

Есть много существующих инструментов для парсинга файлов по заданной грамматике. Например, ANTLR или Yacc. Они используют конечные автоматы и генерируют большие файлы с исходным кодом для парсинга. Действительно ли это так сложно? Попробуем сделать сами.

В этой статье я покажу, как можно сделать такой парсер методом рекурсивного спуска. Для сравнения я буду говорить об ANTLR, другие парсеры не рассматриваются. Под катом много примеров кода, без этого сложно объяснить, почему сделано так, а не иначе.

Будем делать парсер для грамматик в ANTLR-like виде. Вот в таком:

C:
    | A1? A2* A3
    | B1? B2+ B3
;

Делать будем на языке PHP. А если получится нормально, перепишем на C++.

Опубликован второй бета-выпуск операционной системы Haiku R1. Изначально проект был создан как реакция на закрытие ОС BeOS и развивался под именем OpenBeOS, но был переименован в 2004 году из-за претензий, связанных с использованием в названии торговой марки BeOS. Для оценки работы нового выпуска подготовлено несколько загрузочных Live-образов (x86, x86-64). Исходные тексты большей части ОС Haiku распространяются под свободной лицензией MIT, исключение составляют некоторые библиотеки, медиа-кодеки и компоненты, заимствованные из других проектов.

ОС Haiku ориентирована на персональные компьютеры, использует собственное ядро, построенное на основе модульной архитектуры, оптимизированное для высокой отзывчивости на действия пользователя и эффективного выполнения многопоточных приложений. Для разработчиков представлен объектно-ориентированный API. Система напрямую базируется на технологиях BeOS 5 и нацелена на бинарную совместимость с приложениями для данной ОС. Минимальное требование к оборудованию: CPU Pentium II и 256 МБ ОЗУ (рекомендовано Intel Core i3 и 2 ГБ ОЗУ).

Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?

Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".

Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.

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

Привет, Хабр!

Сегодня хотим поделиться со всеми, кому интересна облачная тема, переводом whitepaper от Oracle на тему перехода на облачную инфраструктуру. За перевод благодарим нашего коллегу и постоянного хаброавтора obieesupport.

РДТЕХ — один из старейших партнеров Oracle в России (первое партнерское соглашение между компаниями было подписано в 1993 году). Сегодня наша компания имеет высший партнерский статус Oracle Platinum Partner, а Учебный центр РДТЕХ — один из главных центров авторизованного обучения Oracle в России (думаем, кто-то из числа наших читателей посещал курсы в нашем Учебном центре или даже учится в нем сейчас дистанционно).

Еще наши коллеги создали легендарный глоссарий терминов Oracle, которым пользуются многие представители «базоданческого сообщества» (спойлер: в одном из последующих постов мы расскажем подробнее о глоссарии).

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

Долгое время Rust позиционировался исключительно как язык для системного программирования. Попытки использовать Rust для высокоуровневых прикладных задач зачастую вызывали усмешку у значительной части сообщества: зачем использовать инструмент в том качестве, на которое он не рассчитан? Какая польза от возни с типами и анализатором заимствований (borrow checker), если есть Python и Java со сборкой мусора? Но другая часть сообщества всегда видела потенциал Rust именно как языка прикладного, и даже находила его удобным в использовании для быстрого прототипирования — во многом благодаря его особенностям, а не вопреки им.

Идея о том, что можно писать веб приложение без JavaScript интересна многим, а особенно тем кто начинал свой путь в программирование с серверного языка. Внедрение Web Assembly может (наконец-то) позволить это полноценно реализовать. Писать всю логику приложения на одном языке — звучит довольно заманчиво. Тем более, если этот код компилируется в бинарник, а не в промежуточный язык.

Эту технологию хотелось бы увидеть в не типичных веб-приложениях. Например, как это — писать что-то более интерактивное на Web Assembly (Blazor). Предлагаю попробовать создать простую текстовую интерактивную игру. В игре есть возможность создать свой вопрос и отвечать на вопросы других игроков, набирая очки за правильные ответы. Всё на одной странице и с помощью Blazor.



Результат:

Github
Demo

Привет, Хабр! Я рад сообщить, что Blazor WebAssembly теперь официально выпущена и доступна для всех. Это полнофункциональный и поддерживаемый выпуск Blazor WebAssembly, готовый к использованию в продакшене. Фулл-стак веб-разработка с .NET! Подробности под катом.