Приветствую!Я хочу поделиться с вами очередной своей разработкой, которая позволяет сделать надежную, крепкую мебель и при этом без необходимости иметь инструмент, пылить в доме/квартире и собрать её буквально за один день.Эта статья для аудитории Хабра, которая любит DIYи получает удовольствие от процесса создания вещей своими руками. Осторожно, в статье много изображений и фотографий.

Началось все с

Попросила меня супруга сделать небольшой открытый стеллаж на кухню чтобы всё было недалеко и при этом у всего было своё место. Подумал я, что делать просто ящик прямоугольной формы не хочу это не красиво и будет выглядеть как коробка Рядом с местом предполагаемой установки стоит буфет Хемнэс от ИКЕА. Посмотрел я на него и мне понравился стиль его боковых стенок по углам брусок, а в середине филёнка.
Да, это не стеллаж, но на этой фотографии лучше видно то, о чем я пишу:

Ну думаю надо делать по такой технологии,однако почти сразу понял, что данная сборка возможна только если фрезеровать ножки и вклеивать в паз филенку.У меня есть фрезер и место где это можно сделать, но работать с нимя жуть как не люблю, а люблю работать с SolidWorks и разрабатывать что-либо для печати на 3D-принтере. Поэтому было принято решение разработать детали, с помощью которых можно собрать аналогичную конструкцию, но без фрезеровки, сверления, запилов и прочей грязной работы. Наша цель максимально снизить необходимость в обработкедерева на территории дома.

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

Разработка

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

Витоге с чем нам придется работать:

• Толщина которая нас интересует 18 мм
• Доступные ширины 200 / 250 / 300 / 400 / 500 / 600 мм
• Длина от 600 до 3000 мм
• Брусок на ножки взят такой, как у Хемнэс 40х40 мм

Задача и вводные данные ясны, оттягивать не стоит, нужно делать.

За типовой размер взятыХ-мм на филенку и Х+50 мм на полку. Сделано это неспроста. Допустим мы используем филенку размером 200 мм, соответственно общая ширина боковой стенки будет равна 280 мм. Делать полку 300 мм не получится, так как она будет шире самой стенки и будет выпирать. Во вторых, красивее, когда полка чуть утоплена внутрь, а не заподлицо с боковой стенкой это создает эффект объема и убирает эффект ящика. Соответственно среди типовых размеров в продаже у нас есть щиты размером 250 мм. Вот его мы и будем использовать для разработки общей конструкции деталей.

Если же мы хотим стеллаж глубиной 380 мм, то мы берем щит 300 мм на филенку и 400 мм на полки, НО! в этом случае нам просто нужно при покупке распилить щит вдоль, отрезав 50 мм, а потом поперек на длину равную длине полки.

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


Деталь panel_rack_bracingкрепится к каждой полке и нужна для придания конструкции жесткости, а также связывания нижней части. Без нее ножки не разъедутся, но конструкция не получится крепкой.
Детали в крупном виде под спойлером.Подписывать каждую не буду, они легко находится на схеме выше.

Как это работает

Сейчас я опишу технологию сборки на примере небольшой конструкции.
Допустим мы хотим получить столик-стеллаж глубиной 300 мм, высотой 1000 мм и длиной 1200 мм. В стеллаже должно быть 6 полок.

Покупаем в строительном магазине (Леруа / Максидом / OBI / ):

• брусок на ножки 40х40х2000мм в кол-ве 4 штуки
• щит на столешницу 12х300х1200 мм (стандартный размер)
• щит на филенку 18х200х800 мм в кол-ве 3 штуки
• щит на полки 18х250х2000 мм

Набираем это всё, идем на распиловку ипросим распилить каждый брусок наножкипо 980 мм, а щит для полок на 6 штук по 330 мм.



Там же берем саморезы с пресс-шайбой (клопы) размером 4,2х13 и саморезы с потайной головкой 4,0х30. Вторых нужно будет равным количеству нижних полок умноженное на 2. А вот первых нужно будет намного больше. Считать лучше из общего количества пластиковых деталей умноженного на 2,5.

Распечатываем на 3D-принтере:

• 40x40_top 8 шт
• 40x40_btm_right_shelf 2 шт.
• 40x40_btm_left_shelf 2 шт.
• 40x40_btm_2sides_shelf 4 шт.
• panel_rack_bracing 6 шт.
• rack_holder 12 шт.

На бруски надеваем верхний элемент, прикручиваем к бруску. Затем нижний (в соответствии со схемой), а в середину филенку. Всё плотно прижимаем и скручиваем. Получается такая конструкция стенки:





Далее к середине нижних полок прикручиваем держательpanel_rack_bracing



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

Вот что у нас получилось и как оно выглядит в интерьере

Дополнительныевозможности

Первый плюсплюс данной конструкции мы рассмотрели выше нам ничего не нужно пилить / сверлить / фрезеровать. При определенных длинах полок даже нет необходимости в распиловке в магазине.

Второй же плюс в том, чтоданная системапозволяет собирать стеллажи любой длины. Ранее мы собрали стеллаж длиной 1,2 м, однако мы легко можем собрать такой же стеллаж но длиной 2, 3 и даже 5 и более метров (при условии соединения столешницы на штапики). При этом жесткость конструкции будет аналогичной.

И наконец третий плюс сборка стеллажа в высоту и возможность делать комбинированные сборки, когда одна секция ниже другой. Сейчас я собираю конструкцию в спальню дочери, где одна секция будет глубиной 380 мм (филенка 300 мм, полки 350 мм), а вторая 280 мм. При этом глубокая секция высотой 2,7 м (обязательно крепить к стене или потолку), а низкая 1,6 м.

Большая секция в процессе сборки:







Внимательный читатель наверное уже заметил, что здесь появилась новая, 7/8/9-я детали. Эти деталидержат филенку в середине её длины, центрируют относительно ножки и притягивают к ней. Они немного отличаются от нижних стартовых отсутствием поддерживающей полочки.


Собственно думаю на этом статью можно закончить и поделиться с вами моделями.
Полный набор файлов для печати выложены на Thingiverse

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

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

Технический прогресс не стоит на месте, появляются новые компьютерные архитектуры, компиляторы становятся умнее и генерируют более быстрый машинный код. Современные задачи требуют все более креативного и эффективного решения. В данной статье пойдет речь, на мой взгляд, про один из самых прогрессивных тулчейнов LLVM и компиляторы на его основе Clang и Clang++, для языков программирования С и C++ соответственно. Хоть GCC конкурент Clang, может агрессивнее оптимизировать циклы и рекурсию, Clang дает на выходе более корректный машинный код, и чаще всего не ломает поведение приложений. Плюс оптимизация программ не заканчивается только оптимизацией циклов, поэтому Clang местами дает лучшую производительность. В GCC же за счет переоптимизации вероятность получить unpredictable behavior значительно выше. По этой причине на многих ресурсах не рекомендуют использовать -O3 и LTO(Link Time Optimization) оптимизации для сборки программ. Плюс в случае агрессивной оптимизации, размер исполняемых файлов может сильно увеличиться и программы на практике будут работать даже медленнее. Поэтому мы остановились на Clang не просто так и опции компиляции -O3 и LTO работают в нем более корректно. Плюс современные компиляторы более зрелые, и сейчас уже нет тех детских болячек переоптимизации и LTO.

Что меня побудило написать эту статью? В первую очередь это несколько фактов:

1. Впервые прочел про сборку ядра Linux с LTO оптимизацией и Clang из новостей, где упоминалась компания Google. Она использует Clang и LTO оптимизацию для сборки ядра Linux и получения лучшей производительности. Компания Google для меня является синонимом инноваций, лучших программистов в мире и поэтому для меня ее опыт является самым авторитетным. Плюс она привнесла очень много в развитие open source, и ее наработками пользуются тысячи компаний во всем мире.
2. Хоть компания Google начала использовать Clang и LTO оптимизацию раньше, только с выходом ядра Linux 5.12.6 и 5.12.7 было закрыто большое количество багов, и сборка ядра c LTO оптимизаций стала доступна многим. До этого при сборке ядра с LTO оптимизацией многие драйвера давали сбой.
3. Мною уже протестирована работа ядра с LTO на Ryzen 9 3900x + AMD Radeon 5700 XT. Плюс уже давно использую LLVM 12 и Clang для сборки системных программ. Инструментарий LLVM12 и Clang стали основными в моей системе по причине лучшей поддержки моего процессора и нужные мне программы работают быстрее при сборке с помощью Clang. Для программистов Clang дает лучший контроль ошибок, оптимизации и unpredictable behavior. -fdebug-macro, -fsanitize=address, -fsanitize=memory, -fsanitize=undefined, -fsanitize=thread, -fsanitize=cfi, -fstack-protector, -fstack-protector-strong, -fstack-protector-all, -Rpass=inline, -Rpass=unroll, -Rpass=loop-vectorize, -Rpass-missed=loop-vectorize, -Rpass-analysis=loop-vectorize и т.д.
4. Данная возможность толком нигде не была описана в связи с п.2 и есть подводные моменты, которые будут рассмотрены в данной статье.

В этой статье будет описана сборка ядра Linux 5.12.10 c LLVM 12 + Clang и LTO оптимизацией. Но так как статья получилась бы короткой, то так же бонусом будет рассмотрен вопрос как сделать утилиты LLVM 12 и Clang сборочным инструментарием по умолчанию, и какие программы и библиотеки имеет смысл собрать вручную, чтобы получить лучший отклик и производительность от системы. GCC имеет более лояльную лицензию на использование, и поэтому он установлен во многих дистрибутивах по умолчанию.

Так как в новом ядре фиксится немалое количество багов для работы с моим оборудованием(Ryzen 9 3900x + AMD Radeon 5700 XT) будет рассмотрен вопрос автоматизации сборки и установки нового ядра, чтобы это сильно не отвлекало и занимало минимум времени. Думаю многим это будет полезно. Будет рассмотрен принцип работы моего сборочного скрипта. Все действия будут проводиться в Arch Linux. Если статья будет хорошо оценена, то она станет вводной частью в серию статей про оптимизацию Linux, где будут рассмотрены внутренние механизмы ОС, и как оптимизировать их работу, будут рассмотрены вредные советы и ошибки оптимизации, и будет дан ответ на вопрос оптимизации системы Что для русского хорошо, то для немца смерть!.

Хоть тема оптимизации описывалась многократно, не мало где дают вредные советы, и некоторые механизмы ОС описаны с ошибками. Чаще всего это происходит из-за сложностей перевода или минимальной документации в интернете к компонентам ядра Linux. Где-то информация вовсе устарела. Плюс некоторые вещи понимают программисты, но не понимают системные администраторы, и наоборот. Изначально после установки Linux работает относительно медленно, но благодаря оптимизации и гибкой настройке, можно добиться более высокой производительности и значительно улучшить отклик системы. Arch Linux у меня используется как основная система, и отклик системы, производительность лучше, чем в Windows 10.

Внимание, автор статьи не несет ответственность за причиненный вред в следствии использования данной статьи! Все действия вы выполняете на свой страх и риск! Все действия должны выполнять только профессионалы!

Немного теории

LTO или Link Time Optimization это оптимизация на этапе линковки(компоновки). Чтобы понять, что такое LTO рассмотрим как работают компиляторы. В большинстве компиляторов используется двух этапная модель: этап компиляции и этап линковки.

На этапе компиляции:

Парсятся исходные тексты программ, строится AST Абстрактное Синтаксическое Дерево.

• Оптимизируется Абстрактное Синтаксическое Дерево. Оптимизируются циклы, удаляется мертвый код, результат которого нигде не используется. Раскрываются выражения, например 2+5 можно заменить на 7, чтобы при работе приложения не вычислять его значение каждый раз и тем самым сделать его быстрее и т.д.
• Оптимизированное дерево может быть преобразовано в машинный псевдокод понятный компилятору. Псевдокод используется для дополнительной оптимизации, упрощает разработку универсального компилятора для разных архитектур процессора, например для x86-64 и ARMv7\. Так же как ASM листинг, этот псевдокод еще используется, чтобы понять, как компилятор генерирует машинный код, и служит для понимания работы компилятора, поиска ошибок, например, ошибок оптимизации и unpredictable behavior. Стоит заметить этот этап не является обязательным и в некоторых компиляторах отсутствует.
• Происходит векторизация. Векторизация ,Automatic Vectorization, SIMD
• Генерируется объектный файл. Объектный файл содержит в себе машинный код для компьютера, и специальные служебные структуры, в которых все еще есть неизвестные адреса функций и данных, поэтому этот файл все еще не может быть запущен на исполнение. Чтобы разрешить неизвестные адреса, был добавлен этап линковки.

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

На этапе линковки:

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

Понимая это мы можем понять, что LTO оптимизация это дополнительная оптимизация исполняемых файлов, которая не может быть произведена на этапе компиляции и происходит на этапе линковки.

В Clang используется два вида LTO Оптимизации: Full LTO и Thin LTO. Full LTO это классическая реализация LTO оптимизации, которая обрабатывает конечный исполняемый файл за раз целиком и использует много оперативной памяти. Отсюда эта оптимизация занимает много времени, но дает на выходе самый быстрый код. Thin LTO это развитие LTO оптимизации, в которой нет оптимизации всего файла целиком, а вместо этого вместе с объектными файлами записывают дополнительные метаданные, и LTO оптимизатор работает с этими данными, что дает более высокую скорость получения оптимизированного исполняемого файла (скорость сравнима с линковкой файла без LTO оптимизации) и код сравнимый или чуть уступающий в производительности Full LTO. Но самое главное Full LTO может значительно увеличить размер файла, и код наоборот может из-за этого работать медленнее. Thin LTO лишен этого недостатка и в некоторых приложениях на практике мы можем получить лучшую производительность! Поэтому наш выбор будет сборка ядра Linux с Thin LTO.

Дополнительная информация:

• blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html>
• clang.llvm.org/docs/ThinLTO.html>

Установка LLVM 12 и Clang

Поставить llvm и clang можно выполнив в консоли под root команду:

pacman -Syu base-devel llvm clang lld vim

Это самый простой вариант установки, но лично предпочитают новые версии ПО и git версия закрыла часть багов компилятора и даже стабильнее релиза. Так как за время написания статьи многое поменялось, вышел официальный пакет llvm 12, то чтобы понять ход мыслей, рекомендуется к прочтению прошлая версия по установке.

Cборка LLVM 12 из Arch User Repository

Для сборки нам понадобиться git и нам надо будет собрать программу yay.

Поставим необходимые зависимости, для этого нам будут нужны права root: pacman -Syu base-devel git go vim

Если вы хотите собрать llvm 12 с помощью clang 11, то надо поставить еще их: pacman -S llvm clang

Отредактируем конфигурационный файл сборщика пакетов makepkg в Arch Linux и увеличим количество потоков для сборки программ. Это ускорит скорость сборки. Под root выполним: vim /etc/makepkg.conf

Найдем строки MAKEFLAGS и NINJAFLAGS. Нажмем латинскую букву A. Нам после -j надо указать количество потоков для сборки. Рекомендуется ставить ваше количество ядер или потоков процессора, если ядер 4, то ставим 4 или 8\. У меня это 20, 12 ядер 24 потока, 4 остаются запасными для других задач. Или используем автоматическое определение $(nproc).

В итоге получим:

MAKEFLAGS="-j20"NINJAFLAGS="-j20"

или

MAKEFLAGS="-j$(nproc)"NINJAFLAGS="-j$(nproc)"

Нажмем ESC, дальше SHIFT + :(буква Ж). Внизу появится : строка для ввода команд, вводим wq. w write, записать изменения в файл. q quit, выйти из vim. q! выход из vim без сохранения файла. Кому сложно разобраться с vim, в Linux есть замечательная программа, называется она vimtutor. Если у вас настроена правильно локаль, то vimtutor будет на русском, запустить его можно командой vimtutor. Стоит заметить, вопреки распространенному мнению, обучение у вас не займет много времени. Обычно новичков пугают мифом: vi и vim люди изучают очень долго, и осилить их могут только единицы. На самом деле это не так и там нет ничего сложного.

Под обычным пользователем клонируем репозиторий yay, собираем и устанавливаем:
git clone https://aur.archlinux.org/yay.git && cd yay && makepkg -cfi

Импортирует открытый gpg ключ, он необходим для проверки подписи llvm12-git:
gpg --keyserver pgp.mit.edu --recv-keys 33ED753E14757D79FA17E57DC4C1F715B2B66B95

Поставим LLVM 12 и библиотеки совместимости с 11 версией. Стоит заметить, мой пакет LLVM 12 уже содержит все необходимые утилиты, включая Clang и LLD и их не надо ставить отдельно. Под обычным пользователем выполним команду: yay -Syu llvm12-git. Если llvm 12 есть в официальном репозитории, то llvm11-libs-bin не нужно ставить. Команда yay задаст вам несколько вопросов, нажмите Enter в ответ на все. Сборщик LLVM задаст 3 вопроса:

• Build with clang and llvm toolchain? Собрать с помощью llvm и clang? Отвечаем Y или Enter если да, и N если нет. Рекомендую собирать LLVM с помощью Clang.
• Skip build tests? Пропустить сборку тестов? Отвечаем Y или Enter. Так как во время сборки, не все тесты проходят проверку, то сборка будет прекращена. Поэтому мы пропускаем сборку тестов, и на самом деле сборка будет идти даже быстрее.
• Skip build documentation? Пропустить сборку документации? Отвечаем Y или Enter если да, и N если нет. Если вам не нужна документация, то можно пропустить, это ускорит сборку. Лучше читать документацию на официальном сайте, это удобнее.
• Skip build OCaml and Go bindings? Пропустить сборку OCaml и Go биндингов? Отвечаем Y или Enter если да, и N если нет. Для большинства ответ Y и их сборку можно смело пропустить в угоду скорости сборки. Для тех кому они нужны, а это очень маленькое количество людей могут ответить N.

Сборка может занять от 20 минут до пары часов. Ждете и в конце отвечаете Y на вопрос: хотите ли вы поставить собранные пакеты?

После установка LLVM надо собрать libclc12-git yay -S libclc12-git. libclc необходим для компиляции opencl и для сборки mesa.

Делаем LLVM и Clang сборочным тулчейном по умолчанию в Arch Linux

Большинство программ в Arch Linux собираются с помощью команды makepkg: man makepkg и PKGBUILD файлов. Поэтому в первую очередь внесем изменения в конфигурационный файл /etc/makepkg.conf. Выполним под root в консоли команду: vim /etc/makepkg.conf. Перейдем к строке CHOST="x86_64-pc-linux-gnu" поставим курсор на следующей пустой строке и нажмем латинскую букву A, и вставим после строки:

export CC=clangexport CXX=clang++export LD=ld.lldexport CC_LD=lldexport CXX_LD=lldexport AR=llvm-arexport NM=llvm-nmexport STRIP=llvm-stripexport OBJCOPY=llvm-objcopyexport OBJDUMP=llvm-objdumpexport READELF=llvm-readelfexport RANLIB=llvm-ranlibexport HOSTCC=clangexport HOSTCXX=clang++export HOSTAR=llvm-arexport HOSTLD=ld.lld

Дальше заменим строки CPPFLAGS, CXXFLAGS, LDFLAGS на содержимое ниже:

CFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"CXXFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"

Если вкратце мы используем -O2 оптимизацию для всех программ, -fstack-protector-strong используем улучшенную защиту стека, что снижает вероятность потенциально опасных ошибок при работе со стеком в программах, она же включена у меня в ядре. Плюс на моем процессоре при сборке с Clang с -fstack-protector-strong код при работе с целыми числами работает чуть быстрее, при работе с числами с плавающей запятой есть небольшой оверхед. В GCC наоборот есть более заметный оверхед и производительность снижается. -march=native есть смысл заменить на ваш, у меня это -march=znver2 gcc.gnu.org/onlinedocs/gcc/x86-Options.html.

Изменим количество потоков в MAKEFLAGS и NINJAFLAGS для сборки программ. Это помогает ускорить сборку программ. После -j надо указать количество потоков для сборки. Рекомендуется ставить ваше количество ядер или потоков процессора, если ядер 4, то ставим 4 или 8\. У меня это 20, 12 ядер, 24 потока, 4 остаются запасными для других задач. Или используем автоматическое определение $(nproc).

В итоге получим:

MAKEFLAGS="-j20"
NINJAFLAGS="-j20"

или

MAKEFLAGS="-j$(nproc)"
NINJAFLAGS="-j$(nproc)"

Из DEBUG_CFLAGS и DEBUG_CXXFLAGS надо удалить -fvar-tracking-assignments. LLVM не поддерживает данный параметр.

Файл должен будет принять примерно такой вид:

CARCH="x86_64"CHOST="x86_64-pc-linux-gnu"CARCH="x86_64"CHOST="x86_64-pc-linux-gnu"#-- Compiler and Linker Flagsexport CC=clangexport CXX=clang++export LD=ld.lldexport CC_LD=lldexport CXX_LD=lldexport AR=llvm-arexport NM=llvm-nmexport STRIP=llvm-stripexport OBJCOPY=llvm-objcopyexport OBJDUMP=llvm-objdumpexport READELF=llvm-readelfexport RANLIB=llvm-ranlibexport HOSTCC=clangexport HOSTCXX=clang++export HOSTAR=llvm-arexport HOSTLD=ld.lldCPPFLAGS="-D_FORTIFY_SOURCE=2"CFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"CXXFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"RUSTFLAGS="-C opt-level=2"#-- Make Flags: change this for DistCC/SMP systemsMAKEFLAGS="-j20"NINJAFLAGS="-j20"#-- Debugging flagsDEBUG_CFLAGS="-g"DEBUG_CXXFLAGS="-g"#DEBUG_CFLAGS="-g -fvar-tracking-assignments"#DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"#DEBUG_RUSTFLAGS="-C debuginfo=2"

Нажмем ESC, дальше SHIFT + :(буква Ж). Внизу появится: строка для ввода команд, вводим wq. w write, записать изменения в файл. q quit, выйти из vim. q! выход из vim без сохранения файла. Кому сложно разобраться с vim, в Linux есть замечательная программа, называется она vimtutor. Если у вас настроена правильно локаль, то vimtutor будет на русском, запустить его можно командой `vimtutor`. Стоит заметить, вопреки распространенному мнению, обучение у вас не займет много времени. Обычно новичков пугают мифом: vi и vim люди изучают очень долго, и осилить их могут только единицы. На самом деле это не так и там нет ничего сложного.

Следующим этапом можно добавить настройки в файл .bashrc текущего пользователя. Не root, сборка программ под root очень плохая идея! Это относительно вредный совет и с помощью clang будут собираться все программы! Поэтому делайте это только если хорошо понимаете зачем это вам. Это можно сделать командой:

cat << 'EOF' >> "${HOME}/.bashrc"export CARCH="x86_64"export CHOST="x86_64-pc-linux-gnu"export CC=clangexport CXX=clang++export LD=ld.lldexport CC_LD=lldexport CXX_LD=lldexport AR=llvm-arexport NM=llvm-nmexport STRIP=llvm-stripexport OBJCOPY=llvm-objcopyexport OBJDUMP=llvm-objdumpexport READELF=llvm-readelfexport RANLIB=llvm-ranlibexport HOSTCC=clangexport HOSTCXX=clang++export HOSTAR=llvm-arexport HOSTLD=ld.lldexport CPPFLAGS="-D_FORTIFY_SOURCE=2"export CFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"export CXXFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"export RUSTFLAGS="-C opt-level=2"export MAKEFLAGS="-j20"export NINJAFLAGS="-j20"export DEBUG_CFLAGS="-g"export DEBUG_CXXFLAGS="-g"EOF

Список системных библиотек и программ которые стоит собирать вручную

Внимание, сборка всех программ и все консольные команды надо выполнять под обычным пользователем, перед установкой у вас попросит пароль root. Сборка всех библиотек и программ из списка не занимает много времени. Все кроме Mesa у меня собирается в районе 1 минуты. Список дан в той в последовательности в которой рекомендуется сборка! К примеру от zlib-ng и zstd зависит Mesa, а от Mesa зависит xorg-server.

Самое первое, что надо сделать в Arch Linux это заменить zlib на zlib-ng. Это дает хороший выигрыш производительности в приложениях, которые зависят от zlib. Больше всего это заметно на веб браузерах и веб серверах, которые используют gzip сжатие для передачи данных. На высоко нагруженных серверах это дает очень значительную прибавку к производительности. Сборка довольно быстрая. Поставить можно командой(под обычным пользователем): yay -Syu zlib-ng. На вопрос хотите ли вы удалить zlib отвечайте Y. Не бойтесь библиотеки полностью взаимозаменяемы, и ничего не сломается!

Дальше у нас идет zstd это вторая по популярности библиотека используемая в ядре и в программах для сжатия данных. Поэтому имеет смысл собрать так же ее. Чтобы собрать, вам нужно скопировать содержимое zstd, создать директорию, например zstd, а в ней создать файл PKGBUILD и в него вставить содержимое по ссылке. Дальше в консоли перейти в директорию содержащую PKGBUILD, выполнить команду makepkg -cfi .

libjpeg-turbo Библиотека для работы c jpeg файлами. Ее очень часто используют браузеры и программы рабочего стола. libjpeg-turbo собранный с clang дает у меня лучшую производительность. Действия такие же, как в zstd. Создать директорию, и вставить в файл PKGBUILD содержимое по ссылке libjpeg-turbo. Дальше в консоли перейдите в директорию содержащую PKGBUILD, выполнить команду makepkg -cfi.

libpng Библиотека для работы с PNG файлами. По сборке и установке все то же самое. libpng. Для сборки вам понадобится патч: 72fa126446460347a504f3d9b90f24aed1365595.patch, его надо положить в одну директорию с файлом PKGBUILD. Для сборки надо внести изменения в PKGBUILD, заменить source и sha256sums на строки ниже, и добавить функцию prepare.

source=("https://downloads.sourceforge.net/sourceforge/$pkgname/$pkgname-$pkgver.tar.xz"  "72fa126446460347a504f3d9b90f24aed1365595.patch")sha256sums=('505e70834d35383537b6491e7ae8641f1a4bed1876dbfe361201fc80868d88ca'  '84298548e43976265f414c53dfda1b035882f2bdcacb96ed1bc0a795e430e6a8')prepare() {  cd $pkgname-$pkgver  patch --forward --strip=1 --input="${srcdir:?}/72fa126446460347a504f3d9b90f24aed1365595.patch"}

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

Для сборки вам надо отредактировать файл mesa.conf и установить необходимые вам драйвера dri, gallium, vulkan для сборки. У меня сборка только под новые видеокарты AMD. Подглядеть можно тут: Mesa OpenGL, mesa-git package, Mesa Documentation. При выходе новой версии Mesa не забудьте сменить 21.1.2 на новую версию. А после смены версии обновите контрольные суммы файлов, выполнив в директории с PKGBUILD команду updpkgsums.

xorg-server X сервер с которым взаимодействуют почти все среды рабочего стола. Сборка дает заметное улучшение отклика рабочего стола. Сборка такая же через mapkepkg -cfi. Скачать необходимые файлы для сборки можно тут: xorg-server Сборочный пакет немного кривой и собирает пакет без оптимизаций. Поэтому его надо пропатчить. Для это после строки arch-meson ${pkgbase}-$pkgver build \ надо добавить строки:

  -D debug=false \  -D optimization=2 \  -D b_ndebug=true \  -D b_lto=true \  -D b_lto_mode=thin \  -D b_pie=true \

Полный список критических важных программ влияющих на производительность системы вы можете посмотреть в поем github репозитории arch-packages. Список был создан с помощью системного профилировщика perf. Все сборочные файлы оптимизированы для сборки с помощью llvm и сборка полностью автоматизирована. На моем ryzen 9 3900x сборка всего занимает около 20 минут. Единственный пакет который невозможно собрать с помощью clang и llvm это glibc. Его надо собирать вручную, и с оптимизацией -march= под ваш процессор, это самая часто вызываемая библиотека. Сборку glibc могут проводить только профессионалы, понимающие, что они делают. Не правильная сборка может сломать систему!

Для того, что бы воспользоваться автоматизированной сборкой надо выполнить(под обычным пользователем):
git clone https://github.com/h0tc0d3/arch-packages.git && cd arch-packages && chmod +x build.sh

Дальше нам надо установить все gpg сертификаты и зависимости необходимые для сборки, выполним ./build.sh --install-keys, а затем ./build.sh --install-deps

Для сборки программ достаточно просто запустить скрипт: ./build.sh --install, скрипт вам будет задавать вопросы, какие программы хотите собрать и поставить. На вопрос: хотите ли вы отправить все ваши деньги и пароли автору статьи? хотите ли вы заменить программы?(например, zlib-ng и zlib конфликтуют. Удалить zlib? [y/N] ) ответьте Y . Если вам нужна принудительная пересборка всех программ, то надо выполнить ./build.sh --install --force. По умолчанию, если пакет был уже собран и найден с нужной версией, то он не собирается, а просто устанавливается.

Для сборки mesa надо отредактировать файл mesa/mesa.conf и установить необходимые вам драйвера dri, gallium, vulkan для сборки.

С помощью команды ./build.sh --check можно проверить различия версий в моем репозитории и в официальном, помогает быстро адаптировать сборочные файлы и собрать актуальные версии программ. Слева версия в моем репозитории, справа от стрелки в официальном. Мой репозиторий может служить удобной тренировочной точкой на пути к созданию своего дистрибутива, создания LFS и развитию навыка пересборки ПО не ломая систему.

[+] zstd 1.5.0-1[+] libpng 1.6.37-3[+] libjpeg-turbo 2.1.0-1[+] mesa 21.1.2-1[+] pixman 0.40.0-1[-] glib2 2.68.3-1 -> 2.68.2-1[+] gtk2 2.24.33-2[+] gtk3 1:3.24.29-2[+] gtk4 1:4.2.1-2[+] qt5-base 5.15.2+kde+r196-1[+] icu 69.1-1[+] freetype2 2.10.4-1[+] pango 1:1.48.5-1[+] fontconfig 2:2.13.93-4[+] harfbuzz 2.8.1-1[+] cairo 1.17.4-5[+] wayland-protocols 1.21-1[+] egl-wayland 1.1.7-1[+] xorg-server 1.20.11-1[+] xorgproto 2021.4-1[+] xorg-xauth 1.1-2[+] xorg-util-macros 1.19.3-1[+] xorg-xkbcomp 1.4.5-1[+] xorg-setxkbmap 1.3.2-2[+] kwin 5.22.0-1[+] plasma-workspace 5.22.0-2[+] glibc 2.33-5

Сборка Ядра с помощью LLVM и Clang с LTO оптимизацией

Внимание! Сборку ядра необходимо выполнять под обычным пользователем. Перед установкой ядра у вас попросит sudo пароль. Не рекомендуется использовать патчи ядра linux-ck, linux-zen, MuQSS и т.д. Мною были протестированы все, при кажущемся увеличении производительности системы, происходят кратковременные лаги и снижается стабильность системы, некоторые подсистемы ядра работают не стабильно! С выходом ядра 5.11 стандартный планировщик работает не хуже и значительно стабильнее! Единственный патч который мною применяется это патч для применения оптимизации под процессор github.com/graysky2/kernel_gcc_patch Выбрать ваш процессор можно в меню конфигуратора ядра Processor type and features-->Processor family.

Сборка ядра с помощью LLVM описана в официальной документации Linux Kernel Build with LLVM. Но там есть несколько подводных моментов, которые не описаны. Первый подводный момент заключается в OBJDUMP=llvm-objdump, тут идет переопределение objdump, но так как параметры objdump в llvm имеет другой синтаксис, то при сборке будет пропущена часть тестов для проверки корректности сборки, и будет warning ругающийся на objdump. Правильно будет оставить родной objdump OBJDUMP=objdump

Неправильно:

make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \  READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ \  HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump

Правильно:

make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \  READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ \  HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=objdump

Второй подводный момент заключается в том, что если мы не добавим LLVM_IAS=1 в строку make, то нам не будет доступна LTO оптимизация в конфигураторе ядра!

Поэтому полная строка для сборки с LTO будет:

export BUILD_FLAGS="LLVM=1 LLVM_IAS=1 CC=clang CXX=clang++ LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=objdump"make ${BUILD_FLAGS} -j$(nproc)

Полный список команд для сборки ядра. /tmp
надо заменить на вашу директорию куда будут распакованы исходные файлы ядра, а mykernel
надо заменить на ваш постфикс для имени ядра.

export BUILD_FLAGS="LLVM=1 LLVM_IAS=1 CC=clang CXX=clang++ LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=objdump"tar -xf linux-5.12.10.tar.xz -C /tmpcd /tmp/linux-5.12.10zcat /proc/config.gz > .config # Берем конфигурацию запущенного ядра из /proc/config.gz и используем ее для сборкиecho "-mykernel" > .scmversionmake ${BUILD_FLAGS} oldconfigmake ${BUILD_FLAGS} -j$(nproc) nconfig

C помощью oldconfig конфигурация адаптируется под новое ядро и запускается конфигуратор nconfig. Подробнее о конфигураторах ядра можно прочесть в официальной документации [Kernel configurator](http://personeltest.ru/aways/www.kernel.org/doc/html/latest/kbuild/kconfig.html).

В конфигураторе переходим в General architecture-dependent option --> Link Time Optimization (LTO) и выбираем Clang ThinLTO (EXPERIMENTAL). Для дополнительной защиты стека в General architecture-dependent options ставим \* напротив Stack Protector buffer overflow detection и Strong Stack Protector. Жмем F9 и сохраняем новый конфигурационный файл. Далее идет список команд для сборки и установки нового ядра.

make ${BUILD_FLAGS} -j$(nproc)make ${BUILD_FLAGS} -j$(nproc) modulessudo make ${BUILD_FLAGS} -j$(nproc) modules_installsudo cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-mykernel

Следующий подводный момент заключается в DKMS, после установки ядра собранного с помощью Clang, DKMS пытается собрать модули ядра с помощью GCC. По этой причине сборка и установка DKMS модулей в новое ядро завершается ошибкой. Решение проблемы заключается в передаче DKMS компилятора Clang таким образом:

sudo ${BUILD_FLAGS} dkms install ${dkms_module} -k 5.12.10-mykernel

Автоматизация сборки ядра Linux

Для автоматизации сборки ядра мы будем использовать мой bash скрипт github.com/h0tc0d3/kbuild. Клонируем репозиторий и перейдем в рабочую директорию: git clone https://github.com/h0tc0d3/kbuild.git && cd kbuild && chmod +x kbuild.sh

Отредактируем файл build.sh или поместим содержимое ниже в файл ${HOME}/.kbuild. Рекомендуется второй способ vim "${HOME}/.kbuild" т.к. при обновлении скрипта наши настройки сохранятся. Если использовалось клонирование репозитория git, то в директории со скриптом можно выполнить команду git pull, чтобы обновить скрипт. Ниже даны параметры по умолчанию, они формируют поведение скрипта по умолчанию, если соответствующий параметр не был передан. Эти параметры в дальнейшем можно будет переопределить с помощью параметров командной строки для скрипта. Так же можно добавить команду в ваш .bashrc. Для этого в директории со скриптом kbuild.sh надо выполнить echo "alias kbuild='${PWD}/kbuild.sh" >> "${HOME}/.bashrc", ${PWD} автоматом заменит на текущую директорию. Или из любой другой директории можно указать полный пусть к скрипту echo "alias kbuild='полный-путь/kbuild.sh'" >> "${HOME}/.bashrc" После редактирования .bashrc необходимо перезапустить терминал! Теперь можно будет запускать скрипт командой kbuild --help .

KERNEL_VERSION='5.12.10'         # Версия Linux для сборки. Любая версия с официального сайта kernel.org, включая rc версии.KERNEL_POSTFIX='noname'         # Постфикс для названия ядра. Ядро будет иметь имя версия-постфикс, 5.12.10-noname, нужно для разделения в системе ядер с одной версией.KERNEL_CONFIG='/proc/config.gz' # Конфигурационный файл ядра. Поддерживает любые текстовые файлы и с жатые с расширением gz.KERNEL_CONFIGURATOR='nconfig'   # Конфигуратор ядра nconfig, menuconfig, xconfig.# Рекомендую использовать nconfig, он лучше menuconfig.# Можно писать полную строку, например MENUCONFIG_COLOR=blackbg menuconfig# Дополнительную информацию можно найти в документации к ядру https://www.kernel.org/doc/html/latest/kbuild/kconfig.htmlMKINITCPIO=1 # Запускать "mkinitcpio -p конфигурационный_файл" После сборки? 0 - Нет, 1 - Да.MKINITCPIO_CONFIG="${KERNEL_POSTFIX}" # Имя конфигурационного файла mkinitcpio, по умолчанию равно постфиксу.CONFIGURATOR=0      # Запускать конфигуратор ядра? 0 - Нет, 1 - Да. Если вам не нужно конфигурировать ядро, то можно поставить 0.LLVM=0              # Использовать LLVM Для сборки? 1 - Да, 0 - Нет(Будет использован GCC или другой системный компилятор по умолчанию)THREADS=8           # Количество поток для сборки. Ускоряет сборку. Для автоматического определения надо заменить на $(nproc)BUILD_DIR='/tmp'    # Директория в которой будет проходить сборки ядра. У меня 32gb оперативной памяти и сборка происходит в tmpfs.DOWNLOAD_DIR=${PWD} # Директория для сохранения архивных файлов с исходниками ядра. ${PWD} - в папке из которой запущен скрипт сборки.DIST_CLEAN=0    # Если директория с исходниками существует выполнять make disclean перед сборкой? 0 - Нет, 1 - ДаCLEAN_SOURCE=0  # Выполнять make clean после сборки ядра? 0 - Нет, 1 - ДаREMOVE_SOURCE=1 # Удалять директорию с исходными файлами ядра после сборки? 0 - Нет, 1 - Да.SYSTEM_MAP=0    # Копировать System.map в /boot После сборки? 0 - Нет, 1 - Да.PATCH_SOURCE=1                          # Применять патчи ядра? 0 - Нет, 1 - Да.PATCHES=("${HOME}/confstore/gcc.patch") # Список патчей ядра. Нельзя поменять с помощью параметров скрипта.DKMS_INSTALL=1                                        # Выполнять DKMS Install? 0 - Нет, 1 - Да.DKMS_UNINSTALL=1                                      # Выполнять DKMS Uninstall? 0 - Нет, 1 - Да.DKMS_MODULES=('openrazer-driver/3.0.1' 'digimend/10') # Список DKMS модулей, который нужно собрать и установить. Нельзя поменять с помощью параметров скрипта.

Внимание! Сборку ядра необходимо выполнять под обычным пользователем. Перед установкой ядра у вас попросит sudo пароль. Не рекомендуется использовать патчи ядра linux-ck, linux-zen, MuQSS и т.д. Мною были протестированы все, при кажущемся увеличении производительности системы, происходят кратковременные лаги и снижается стабильность системы, некоторые подсистемы ядра работают не стабильно. С выходом ядра 5.11 стандартный планировщик работает не хуже и значительно стабильнее! Единственный патч который мною применяется это патч для применения оптимизации под процессор github.com/graysky2/kernel_gcc_patch. Нас интересует файл more-uarches-for-kernel-5.8+.patch. Путь к нему имеет смысл указать в PATCHES. Выбрать ваш процессор можно в меню конфигуратора ядра Processor type and features-->Processor family.

Принцип работы скрипта:

1) set -euo pipefail скрипт переходит в строгий режим, в случае ошибок скрипт завершается с ошибкой. Является хорошим тоном, при написании bash скриптов. Скрипт проверяет запущен ли он под рут, если запущен под рут, то выдает ошибку и завершается. Загружается настройки пользователя из файла ${HOME}/.kbuild

2) Скрипт проверяет существование директории linux-версия в директории BUILD_DIR. Если существует, то исходники распакованы. Перед сборкой может выполняться команда make distclean, поведение задается переменной DIST_CLEAN. Если этой директории не существует, то проверяется существование файла linux-версия.tar.gz

или linux-версия.tar.xz. Если файл найден, то он распаковывается в BUILD_DIR. Иначе файл скачивается с kernel.org в директорию DOWNLOAD_DIR.

3) Скрипт применяет патчи ядра и устанавливает постфикс для версии ядра(записывает его в файл .scmversion ).

4) Скрипт копирует настройки ядра из файла KERNEL_CONFIG в .config и выполняет make oldcofig для адаптации настроек под новое ядро и запускает конфигуратор ядра.

5) Скрипт собирает ядро и модули.

6) Скрипт удаляет модули DKMS из ядра которое сейчас запущено, если это необходимо. Это необходимо, чтобы в списке dkms status не отображались мертвые ядра. Удаляет директорию `/lib/modules/версия-постфикс` если она существует. Она существует в том случае, если мы собираем одну и туже версию несколько раз. Это дополнительная защита от unpredictable behavior .

7) Скрипт устанавливает модули ядра, копирует ядро в /boot/vmlinuz-постфикс.

8) Скрипт собирает DKMS модули и устанавливает их. Копирует System.map в /boot/System-постфикс.map, если это необходимо.

9) Обновляет загрузочный img файл для ядра. Выполняет mkinitcpio -p конфиг.

10) Выполняет make clean если необходимо. Удаляет директорию linux-версия в директории BUILD_DIR, если это необходимо.

Собрать ядро с llvm можно командой ./kbuild.sh -v 5.12.10 --llvm --start или kbuild -v 5.12.10 --llvm --start, если был установлен alias. -v 5.12.10 указывает версию ядра для сборки, --llvm указывает собирать ядро с помощью llvm и clang. --start указывает, что надо запускать конфигуратор ядра. Получить справку по параметрам скрипта можно выполнив команду kbuild --help.



Как можно понять из статьи сборка ядра с LLVM и Clang относительно простая. И самое главное можно автоматизировать сборку и установку ядра, и в дальнейшем не тратить много времени на сборку новых ядер.

Всем кто дочитал до конца, спасибо! Комментарии и замечания приветствуются!

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

Тестирование на небольших программах командной строки постепенно устаревает, поэтому для переноса мы выбрали ничто иное, как Quake 3. Стоит ли говорить, что буквально через пару дней мы уже были первыми, кто играл в Rust-версию этого популярного шутера.

Подготовка: исходники Quake 3

Посмотрев оригинальный код Quake 3 и различные форки, мы остановились на ioquake3. Это форк коммьюнити, который до сих пор обслуживается и строится на современных платформах.

Для начала мы убедились, что сможем воссоздать проект как есть:

$ make release

Сборка ioquake3 создает несколько библиотек и исполняемых файлов:

$ tree --prune -I missionpack -P "*.so|*x86_64". build     debug-linux-x86_64         baseq3            cgamex86_64.so          # клиент             qagamex86_64.so         # игровой сервер            uix86_64.so             # ui         ioq3ded.x86_64              # исполняемый файл выделенного сервера         ioquake3.x86_64             # основной исполняемый файл         renderer_opengl1_x86_64.so  # модуль рендеринга opengl1         renderer_opengl2_x86_64.so  # модуль рендеринга opengl2

Клиентскую, серверную и UI библиотеки можно собрать в виде Quake VM либо как нативные общие библиотеки x86. Мы предпочли второй вариант. Переносить VM на Rust и использовать версии QVM было бы существенно проще, но задачей было протестировать C2Rust максимально тщательно.

Сосредоточились мы на UI, игровом сервере, клиенте, модуле рендеринга OpenGL1 и основном исполняемом файле. Можно было также перевести модуль OpenGL2, но мы решили его не трогать, так как он активно использует файлы шейдеров .glsl, которые система сборки включает в исходники Си в виде строковых литералов. Конечно, можно было добавить поддержку скрипта кастомной сборки для встраивания кода GLSL в строки Rust после транспиляции, но нас остановило отсутствие надежного автоматического способа транспилировать эти автогенерируемые временные файлы.

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

Транспиляция

Чтобы сохранить используемую в Quake 3 структуру каталогов и не прибегать к изменению ее исходного кода, нужно было создать в точности такие же двоичные файлы, что и в нативной сборке, то есть четыре общие библиотеки и один двоичный файл. Поскольку C2Rust использует для сборки файлов Cargo, каждому исполняемому файлу требуется собственный контейнер Rust с соответствующим файлом Cargo.toml. Чтобы C2Rust на выходе создал для каждого исполняемого файла контейнер, ему нужно предоставить список двоичных файлов вместе с соответствующими им объектными или исходными файлами, а также вызов компоновщика, определяющего прочие детали, такие как зависимости.

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

В большинстве инструментов, создающих такую базу данных, подобное ограничение присутствует преднамеренно, например cmake с CMAKE_EXPORT_COMPILE_COMMANDS, bear и compiledb. Насколько нам известно, единственным инструментом, включающим команды компоновки, является build-logger из CodeChecker, который мы не задействовали только потому, что узнали о нем после написания собственных оберток (приводятся ниже). Это означало невозможность использовать файл compile_commands.json, создаваемый любым типовым инструментом для транспиляции мультибинарной программы Си.

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

$ make release

Мы добавили обертки для перехвата процесса сборки:

$ make release CC=/path/to/C2Rust/scripts/cc-wrappers/cc

Обертки создают каталог с файлами JSON, по одному файлу за вызов. Второй скрипт агрегирует все эти файлы в новый compile_commands.json, который содержит уже и команды компиляции, и команды сборки. Мы расширили C2Rust для считывания компонующих команд из базы данных и создания отдельного контейнера для каждого связанного двоичного файла. Кроме того, теперь C2Rust считывает зависимости каждого исполняемого файла и автоматически добавляет их в файл build.rs его контейнера.

В качестве облегчения процесса все исполняемые файлы можно собрать за раз, если они будут находиться в одном рабочем пространстве. C2Rust производит высокоуровневый файл рабочего пространства Cargo.toml, позволяя собирать проект одной командой cargo build в каталоге quake3-rs:

$ tree -L 1. Cargo.lock Cargo.toml cgamex86_64 ioquake3 qagamex86_64 renderer_opengl1_x86_64 rust-toolchain uix86_64$ cargo build --release

Исправление недочетов

При первой попытке собрать переносимый код возникла пара проблем с исходниками Quake 3, которые C2Rust не мог корректно обработать или не обрабатывал совсем.

Указатели на массивы

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

int array[1024];int *p;// ...if (p >= &array[1024]) {   // error...}

Стандарт Си (загляните, например, в C11, Section 6.5.6) допускает указатели на элемент, выходящий за границу массива. Проблема же в том, что Rust это запрещает даже при получении только адреса элемента. Примеры этого шаблона мы нашли в функции AAS_TraceClientBBox.

Компилятор Rust также отметил похожий, но уже действительно ошибочный пример в G_TryPushingEntity, где условие представлено как >, а не >=. После этого условия выходящий за границы указатель разыменовывался, что являлось реальной ошибкой безопасности памяти.

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

Члены динамических массивов

На первый проверочный запуск игры Rust отреагировал паникой:

thread 'main' panicked at 'index out of bounds: the len is 4 but the index is 4', quake3-client/src/cm_polylib.rs:973:17

Заглянув в cm_polylib.c, мы заметили разыменовывание поля p в следующей структуре:

typedef struct{intnumpoints;vec3_tp[4];// переменный размер} winding_t;

Поле p здесь это более ранняя несовместимая с C99 версия члена массива переменной длины, которая до сих пор принимается gcc. C2Rust распознает членов динамических массивов с синтаксисом С99 (vec3_t p[]) и реализует простую эвристику для попутного обнаружения более ранних версий этого шаблона (массивов с размером 0 и 1 в конце структур; в исходниках ioquake3 мы нашли несколько таких).

Панику удалось устранить, изменив вышеприведенную структуру на синтаксис C99:

typedef struct{intnumpoints;vec3_tp[];// переменный размер} winding_t;

Реализация автоматического исправления этого шаблона для общих случаев (массивы с размером не 0 или 1) оказалась бы слишком сложной, поскольку пришлось бы различать членов стандартных массивов от членов массивов с произвольными размерами. Вместо этого мы рекомендуем корректировать исходный код Си вручную как сделали сами в случае с ioquake3.

Связанные операнды во встроенном ассемблере

Еще одним источником сбоев был встроенный в Си код ассемблера из системного заголовка /usr/include/bits/select.h:

# define __FD_ZERO(fdsp)                                            \  do {                                                              \    int __d0, __d1;                                                 \    __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS               \                          : "=c" (__d0), "=D" (__d1)                \                          : "a" (0), "0" (sizeof (fd_set)           \                                          / sizeof (__fd_mask)),    \                            "1" (&__FDS_BITS (fdsp)[0])             \                          : "memory");                              \  } while (0)

Он определяет внутреннюю версию макроса __FD_ZERO. Это определение вызывает редкий граничный случай встроенного ассемблерного кода gcc: связанные входные/выходные операнды разного размера.

Выходной операнд =D (_d1) привязывает регистр edi к переменной _d1 в качестве 32-битного значения, в то время как 1 (&__FDS_BITS (fdsp)[0]) привязывает тот же регистр к адресу fdsp->fds_bits в качестве 64-битного указателя. gcc и clang исправляют это несоответствие, взамен используя 64-битный регистр rdi и затем усекая его значение перед присваиванием к _d1. Rust же по умолчанию использует семантику LLVM, которая оставляет этот случай неопределенным. В отладочных сборках (не релизных, которые работали корректно) оба операнда присваивались регистру edi, обуславливая преждевременное усечение указателя до 32 бит еще до достижения встроенного кода ассемблера, что и вызывало сбои.

Поскольку rustc передает встроенный ассемблерный код Rust в LLVM с минимальными изменениями, мы решили исправить этот частный случай в C2Rust. Для этого мы реализовали новый контейнер c2rust-asm-casts, корректирующий проблему через систему типов Rust с помощью типажа (trait) и вспомогательных функций, которые автоматически расширяют и усекают значения связанных операндов до внутреннего размера, достаточного для хранения обоих операндов.

Вышеприведенный код корректно транспилируется в следующее:

let mut __d0: c_int = 0;let mut __d1: c_int = 0;// Ссылка на выходное значение первого операндаlet fresh5 = &mut __d0;// Внутреннее хранилище для первого связанного операндаlet fresh6;// Ссылка на выходное значение второго операндаlet fresh7 = &mut __d1;// Внутреннее хранилище для второго операндаlet fresh8;// Входное значение первого операндаlet fresh9 = (::std::mem::size_of::<fd_set>() as c_ulong).wrapping_div(::std::mem::size_of::<__fd_mask>() as c_ulong);// Входное значение второго операндаlet fresh10 = &mut *fdset.__fds_bits.as_mut_ptr().offset(0) as *mut __fd_mask;asm!("cld; rep; stosq"     : "={cx}" (fresh6), "={di}" (fresh8)     : "{ax}" (0),       // Приведение входных операндов к внутреннему типу хранилища       // с дополнительным нулевым или знаковым расширением       "0" (AsmCast::cast_in(fresh5, fresh9)),       "1" (AsmCast::cast_in(fresh7, fresh10))     : "memory"     : "volatile");// Приведение операндов к внешнему типу (с выведением типов) и усечениеAsmCast::cast_out(fresh5, fresh9, fresh6);AsmCast::cast_out(fresh7, fresh10, fresh8);

Обратите внимание, что код выше не требует типов для любых входных или выходных значений инструкций ассемблера, полагаясь на вывод типов Rust (главным образом типов fresh6 и fresh8).

Выравнивание глобальных переменных

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

static unsigned char ssemask[16] __attribute__((aligned(16))) ={"\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\x00\x00\x00\x00"};

На данный момент Rust поддерживает атрибут выравнивания для типов структур, но не глобальных переменных, то есть элементов static. Мы продолжаем искать универсальный способ решения этой проблемы в Rust или C2Rust, но для ioquake3 пока что решили ее вручную с помощью небольшого патча. Этот патч заменяет Rust-эквивалент ssemask на:

#[repr(C, align(16))]struct SseMask([u8; 16]);static mut ssemask: SseMask = SseMask([    255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 0, 0, 0, 0,]);

Запуск quake3-rs

Выполнение cargo build --release генерирует двоичные файлы, но все они генерируются в target/release с использованием структуры каталогов, не распознаваемой бинарником ioquake3. Мы написали скрипт, который создает символические ссылки на текущую директорию, чтобы дублировать верную структуру каталогов (включая ссылки на файлы .pk3, содержащие ресурсы игры):

$ /path/to/make_quake3_rs_links.sh /path/to/quake3-rs/target/release /path/to/paks

Путь /path/to/paks должен указывать на каталог, содержащий файлы .pk3.

Ну а теперь пора запускать игру! При запуске нужно передать команду +set vm_game 0 и пр., чтобы загрузить эти модули как общие библиотеки Rust, а не ассемблерный код QVM, а также команду cl_renderer, чтобы использовать OpenGL1.

$ ./ioquake3 +set sv_pure 0 +set vm_game 0 +set vm_cgame 0 +set vm_ui 0 +set cl_renderer "opengl1"

Иии



Перед нами рабочая Rust-версия Quake3!



Вот видео, в котором мы транспилируем игру, загружаем ее и недолго тестируем игровой процесс:


Транспилированный исходный код лежит в ветке transpiled нашего репозитория. Там также есть ветка refactored, содержащая те же файлы, но уже с примененными командами рефакторинга.

Инструкции по транспиляции

Если вы захотите повторить аналогичный процесс переноса и запуска Quake 3, то имейте в виду, что вам понадобятся либо оригинальные ресурсы игры, либо скачанные из интернета демоверсии таких ресурсов. Помимо этого, потребуется установить C2Rust (минимальная необходимая ночная версия Rust на момент написания это nightly-2019-12-05, но мы рекомендуем заглянуть в репозиторий C2Rust или на сайт crates.io на предмет наличия последней):

$ cargo +nightly-2019-12-05 install c2rust

а также копии репозиториев C2Rust и ioquake3:

$ git clone git@github.com:immunant/c2rust.git$ git clone git@github.com:immunant/ioq3.git

В качестве альтернативы установке c2rust вышеприведенной командой вы можете собрать C2Rust вручную с помощью cargo build --release. В обоих случаях вам все равно потребуется репозиторий C2Rust, так как там находятся скрипты оберток компилятора, необходимые для транспиляции ioquake3.

Мы предоставляем скрипт, который автоматически транспилирует код Си и применяет патч ssemask. Чтобы его использовать, выполните из верхнего уровня репозитория ioq3следующую команду:

$ ./transpile.sh </path/to/C2Rust repository> </path/to/c2rust binary>

Эта команда должна создать подкаталог quake3-rs, содержащий код Rust, где можно будет последовательно выполнять cargo build --release и остальные ранее описанные шаги.

Звонит как-то вендор и говорит, что в возврате бракованного железа не их жёсткий диск.


Это местный вендор. Для прода мы покупаем серверное железо у крупных поставщиков, часто возим его в разные страны из одного центра. Но для тестовых новых конфигураций обращаемся к локальным поставщикам, берём железо на тесты или разовые проекты. Один из жёстких дисков оказался бракованным, и мы вернули его назад поставщику по гарантии. Причём знатно ругаясь, что связались с маленькой компанией, что задержало нам график тестов.

Гарантийный отдел ковыряется с диском, а потом звонят:

А зачем вы подменили диск?

Мы такие:

В смысле подменили?

Мы вам продавали другой. А тут корпус тот, а внутри другой. Какие-то следы от отвёртки.

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

У нас было ещё несколько странных ситуаций, и сейчас я о них расскажу.

Форекс-трейдер

VDS часто покупаются для торговли на биржах. Ну, на нормальных биржах: я имею в виду тех, где важно географическое расположение сервера для минимизации задержек. Но есть и биржи уровня Форекса. Вернее их даже биржами назвать нельзя. Это на сленге трейдеров кухня. Напомню, что многие из них попали в список компаний с признаками нелегальной деятельности, который завёл ЦБ. У меня есть глубокое личное убеждение, основанное на здравом смысле и математике, что система работает как качели для вытаскивания денег из не самых разбирающихся в вопросе клиентов. Возможно, это не так, но свою точку зрения я могу аргументировать и обосновать при необходимости. Но в истории важно другое. Звонит мой знакомый, который взял у нас сервер в Швейцарии. И вот он начинает в открытую меня и всех наших сотрудников обвинять в том, что мы залезаем к нему на сервер в процессе торгов и вмешиваемся в его форекс-сделки.

По его словам, он придумал великую стратегию, а убыточные сделки берутся рынком, плюсовые же вовремя не берутся, игнорируются. И в этом виноваты мы. Точнее, сначала он обратился с задачей, что его не устраивает производительность сервера. С его слов, она радикально падала в момент выхода новостей. В 16:30, когда выходит мировая статистика. В этот момент времени все трейдеры, кто работает с помощью автоматических торговых систем, начинают многократно усиливать свою активность. Если, грубо говоря, внутри дня он делает десять сделок, то в эти 16:30 и одну минуту он может сделать сто сделок. Естественно, это создаёт пик нагрузки, причём не локально, а на принимающем сервере. Но трейдер этого не понимает, он думает, что у нас сервер именно в 16:30, когда ему надо выставить заявку или закрыть заявку, тормозит. А это совпадает с самым нужным временем. И не верится, что это просто совпадение.

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

Здесь главная проблема работа со знакомым. Если бы это был просто клиент, то мы бы провели диагностику и не получали оскорблений.

Игровые серверы школьников

Школьники довольно часто размещают у нас игровые серверы. Это, скажем так, сложные клиенты, потому что они выбирают третий по цене тарифный план. Первый это промо за 30 рублей в месяц (по цене IP), второй урезанная версия стандартных конфигураций за 130 рублей и третий уже полноценный сервер от 300 рублей в месяц.

Итак, дети открывают сервер, начинают играть. Через некоторое время их с завидным постоянством начинают дидосить. Не каждого, условно примерно каждый десятый сервер. После начала дидоса наша система их блокирует. Ещё через пять минут ребёнок с большим гонором и богатым трёхэтажным матом начинает писать в нашу поддержку о том, какие мы тут все плохие люди. Обрезали ему, значит, игру, у него там нет дохода из-за этого, мы там попали на миллионы из-за него теперь. Он нас побить приедет.

Поддержка вежливо объясняет суть проблемы и предлагает подключить защиту от DDOS-атак за 400 рублей (причём первый месяц бесплатно). По нашей практике, потом можно будет играть совершенно спокойно. На что клиент начинает нас обвинять в том, что это мы специально дидосим его, чтобы он нам заплатил ещё. Далее закономерно встаёт вопрос о возврате средств, и обычно мы средства возвращаем и с лёгкостью расстаёмся с таким клиентом.

Один из тикетов был похож на подобный, но с нюансом. Блокировки не было, дидоса не было, трёхэтажного мата тоже не было. Просто клиент запросил возврат средств с сервера, который был оплачен на несколько месяцев. А тут надо сказать, что у нас есть ссылка для оплаты, которую можно выставить наружу, и любой человек может оплатить хостинг для какого-то клиента. Это удобно, потому что бухгалтерии не обязательно логиниться в админпанель. Школьники использовали эту ссылку для краудфандинга, скинулись на сервак и начали играть.

Клиент пишет заявку на возврат средств, мы отправляем её в платёжный шлюз. И вдруг владелец удаляет сервер, начинаются тот самый мат и дикие крики про то, что вернуть надо на его счёт, а не на счета плательщиков. То есть условно у них было порядка сорока оплат по 100 рублей, и все их платёжный шлюз собирался распихать обратно по тем самым карточкам, с которых они платили. Но главному герою нужен был возврат на один свой счёт. В общем, в ходе диалога с поддержкой он уже прямо признался, что хотел получить чужие деньги. Через пару месяцев эта же история повторилась с минимальными вариациями с другим школьником.

Самый короткий детектив

Бывает, наши серверы берутся для обхода блокировок. Люди разворачивают VPN и просто ходят через наш сервер в большой интернет, если на работе он заблокирован. Ну или просто берут сервер в другой юрисдикции типа Швейцарии и ходят через него. Почему это важно, есть вот тут про маски-шоу.

И вот пишет клиент, что наш сервер не отвечает.

Мы просим трассировку. Клиент делает, присылает. Мы сообщаем, что RDP блокирует его отель, и желаем приятного отпуска в Таиланде. Клиент немного в панике, но мы поясняем, что его Wi-Fi-точка названа именно по отелю. И даём ссылку на то, как это обойти. В тот раз помогло.

Регистрации под ботами

Очень странная ситуация была с тестовыми периодами на наших 32-ядерных машинах. Кто-то научился брать американские номера, парсить голос, русский текст и цифры. Как только криптовалюты совершали очередной прыжок, начинались авторегистрации, а дальше серверы использовались (судя по характеру нагрузки) для майнинга криптовалют. Не знаю, что это было, но майнить биткоин на VDS без видеокарты идея откровенно так себе. Процессор уходит в потолок, три дня они пытаются что-то там сделать, потом период заканчивается. Мы обновили капчи, но на следующей волне скачка курса биткоина снова начались авторегистрации. Я откровенно не понимаю, какой в этом смысл, ведь аренда американского номера стоит дороже, чем возможный профит с майнинга на процессоре три дня. Сейчас эти волны мы наконец-то победили.

Блокировки по IP

Мы выдаём один статический IP клиенту при аренде сервера. Это не карусель динамических адресов, не замены раз в месяц, а конкретный IP, привязанный к клиенту. Сначала мы проверяем его чистоту и отсутствие во всяких чёрных списках, а потом даём клиенту.

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

Ещё накручивают отзывы и просмотры на Амазоне. Потом в поддержке: Ребята, это мой не первый аккаунт, можете, пожалуйста, сменить мне IP-адрес, потому что меня забанило?

Бывает так, что админ настраивает клиенту работу на сервере, но забывает уточнить вопрос про лицензии. Звонит генеральный директор, у которого 25 сотрудников, и они все сидят на удалённом рабочем столе, у нас размещали соответственно. Весь замес в том, что системный администратор, который это настраивал, был на аутсорсе. Он настроил кучу виртуальных рабочих мест. Человек платил около 35 тысяч. У него там размещалось 25 сотрудников, и 120 дней человек вообще не знал никакой проблемы с подключением к удалённому рабочему столу. А цимес в том, что Майкрософт даёт триалку на размещение этого удалённого сервера рабочих столов 120 дней ровно. Человек четыре месяца, получается, пользуется, и тут внезапно посреди пятого месяца обнаруживает, что у него ни один сотрудник не может зайти. Диктует нам ошибку, мы всё прекрасно понимаем, что у него там происходит. И предлагаем ему два варианта:

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

В общем, ребят, я не буду платить тройную цену от сервака.

Неудивительно, потому что лицензия стоит 91 тысячу рублей, а у него сервак стоит 36 тысяч.

Ребята, надо, короче, решать. Давайте так: мне по-любому нужно это бесплатно. Что если мы оформим договор на другое лицо, и таким образом у меня будет ещё 120 дней? А что если вы измените человека, у меня сейчас есть знакомый, он зарегистрируется?

А вы точно понимаете, что сейчас у официального партнёра MS спрашиваете, как их же обмануть?

Да! Ребята, какие ещё варианты есть?

Неожиданный уход коллеги

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

И вот одна из ситуаций. Сотрудник взял и не пришёл на работу. Работал-работал и потом пропал. Выходного интервью нет. Начали разбираться, что же случилось, может быть, обиделся на что-то. Никаких внутренних предпосылок. Уже потом начали общаться с ним удалённо, он прислал ссылку на статью на Хабре про профессиональное выгорание.

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

Никаких выводов и действий. Просто, возможно, он счастлив где-то ещё.

Дебош

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

В итоге уголовку он не получил, полицейские оказались добрыми. Оставили всего до утра к КПЗ и отпустили домой к жене и детям. Как бы конец истории, но непонятно, что делать дальше, потому что в беседе он пояснил, что нет гарантии того, что ровно такое же не повторится. Например, в офисе. Или в серверной. Или на переговорах с клиентом или ЦОДом.

Долго думали, что делать. Увольнять вроде неправильно. По работе претензий нет, всё хорошо.
Но вроде, если человек облажался в соцсетях и кого-то оскорбил, в крупных компаниях увольняют. Тут похожая ситуация. Непонятно. В общем, в итоге перевели на полную удалёнку ещё до того, как это стало мейнстримом.

Уничтоженный сервер 1С

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

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

Письмо приходит, в нём просьба поменять основную почту доступа.

Мы соответственно меняем почту.

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

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

Общие выводы и чем закончилась история с жёстким диском

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

Реакция мира на новый коронавирус в 2020 году и идущая с разным успехом в разных странах прививочная кампания от него него в 2021, обнажили и обострили множество слабых мест экономики и социальных проблем. Фактически, многие аспекты социального (коллективного) бытия сейчас переживают стресс-тест, подобного которому не было с начавшейся в 1929 году Великой депрессии.

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

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



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

Вакцины и антибиотики: история

Антибиотики намного моложе вакцин: пенициллину нет и ста лет (1928) а свой ресурс они уже практически выработали, и побочные эффекты их применения стремительно приближаются к пользу.

Вакцинам более 200 лет (1798) и со временем они становятся только эффективнее и безопаснее. Технология Спутника по сравнению со старыми вакцинами, использовавшими ослабленные формы вирусов небо и земля.

Growing recognition for Russias Sputnik V COVID-19 vaccine

Вакцина по своей сути очень простой инструмент. У неё одна задача: правильный пас иммунитету, чтобы тот его отбил нужными антителами. И одно условие (стандартное): не навредить. По простоте это пинг-понг: подал мячик отбил мячик. Иммунитет и так играет в это буквально с рождения. То есть, никакого насилия и перелома природы через колено тут тоже нет. Антителом больше, антителом меньше. Однозначные критерии успеха (конкретные антитела и их количество) и неудачи (недостаточность эффекта, побочные эффекты) и позволяют однозначную оценку результата. Иными словами, от вакцины от ковида не так много и требуется: 1) защита от заражения, 2) предотвращение передачи, 3) защита от заболевания, 4) защита от тяжёлого течения болезни, 5) защита от смертельного исхода, 6) продолжительность защиты, 7) не навредить. И по каждому пункту всё довольно однозначно. Спутник-V выполняет их все.

По данным ученых, эффективность вакцины составила 91,6%, для добровольцев старше 65 лет 91,8%. Вакцина также на 100% защищает от тяжелого течения коронавируса, сообщили в фонде. Уровень антител к коронавирусу у сделавших прививку в 1,3-1,5 раза выше, чем у переболевших коронавирусом, отметили исследователи.

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

Но главная военная тайна в том, что и другие успешные вакцины (Pfizer, Moderna) делают то же самое и на том же уровне, не лучше и не хуже, потому что коридор делает свою работу у вакцин в принципе довольно узкий.



Поэтому безупречный результат в данном случае это как сделать копию ключа: ключ должен открывать замок и не приносить проблем. Если новый ключ подошёл к замку и не создаёт проблем работа выполнена безупречно. Если вакцина создаёт антитела и не создаёт проблем работа выполнена безупречно. Но для таких задач безупречное исполнение и есть норма. Для вакцин это норма.

Вакцины избавили мир от самых страшных заболеваний, которые до этого меняли цивилизации а, возможно, и стирали, если про оспу в Южной Америке в XVI веке правда. Очень похоже на правду, всё укладывается в историческую логику и соответствует археологическим находкам просто это будет очень страшная правда, ведь речь о стёртой на 100% цивилизации, многолюдных городах и огромных империях по всему континенту от инков до майя, о которых мы не знаем почти ничего, потому что единственный вирус оспы всего за несколько лет мог убить десятки миллионов человек, под 100% стерев целые народы, а джунгли быстро скрыли все следы их цивилизаций.

Вакцина победила оспу

Восьмого мая 1980 г. Тридцать третья сессия Всемирной ассамблеи здравоохранения официально объявила: Мир и все народы земли одержали победу над оспой.

Это заявление ознаменовало победу над болезнью, от которой человечество страдало по меньшей мере 3 000 лет и которая только в XX веке унесла жизни 300 миллионов человек.

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

Вакцина работает с иммунитетом человека, тогда как антибиотики его подменяют (и разрушают).

Наша собственная система врождённого иммунитета, по сути, сама отбирает бактерии, которые она плохо ловит.


До двух лет на восстановление здоровой кишечной микрофлоры после одного курса антибиотиков.

При том, что вакцина со всех сторон безупречная. Эффективность более 90% оставляет ~8% вероятность лёгкой формы заболевания и это весь технический зазор. Защита от тяжёлого течения болезни и смертельного исхода 100%, защиты от тяжёлого течения и смертельного исхода.

Вакцина по своей сути вещь очень простая. У неё одна задача: правильный пас иммунитету, чтобы тот его отбил нужными антителами. И одно условие (стандартное): не навредить. По простоте это пинг-понг: подал мячик отбил мячик. При том, что иммунитет к этому полностью (обычно) готов: выработка приобретённого иммунного ответа это есть основная работа иммунитета с рождения. То есть, тут нет никакого насилия и перелома природы через колено это пинг-понг с заинтересованным партнёром, который и так целыми днями играет со стенкой. Антителом больше, антителом меньше. С той лишь разницей, что иммунитет сам по себе имеет дело с тем, с чем повседневно сталкивается. А вакцина позволяет стратегически подправить игру вероятностей в свою пользу, принеся максимум пользы в один ход.

Одна задача из одного цикла требует предельно простого инструмента, в котором нечему ломаться и неоткуда взяться скрытым рискам. Все риски вакцины на поверхности: угроза нежелательной реакции организма или недостаточность желательной. Поскольку вакцина, по своей сути, рассчитана на однократную транзакцию: шлёпнул штампик получил оттиск, то и возможные негативные реакции в таком случае вероятнее всего простые, типа аллергической реакции. Чтобы одним уколом запустить непредвиденную цепную реакцию, добиться многоступенчатых последствий надо очень сильно постараться. В отличие от вирусов и микробов, содержимое вакцины заведомо не подразумевает возможности репликации, поэтому перерасти внутри организма в какую-то новую угрозу, навредить больше, чем на объём впрыснутого за укол, вакцина не может. Конечно, и укола достаточно, чтобы убить или покалечить, но для этого есть испытания пропустить негативную реакцию первого-второго порядка очень сложно. А в отложенные последствия спустя долгое время и длинную цепочку химических реакций в организме по умолчанию я не верю. В вакцинах обычно нет ничего, что даже теоретически могло бы сказаться далеко отложенными последствиями с одного (!) укола. Может ли такое быть? Возможно. Но это тот случай, когда надо доказывать существование риска (отложенных последствий), а не отсутствие. По умолчанию обычных испытаний, которые, обычно, и так растягиваются на месяцы и годы (ковид рекорд и исключение) более, чем достаточно. Если есть основания подозревать долгосрочные последствия их надо проверять, но это если есть основания.

Вакцины vs антибиотики

Если прислушаться к голосу коллетивного бессознательного, то сложится впечатление, что антибиотики просто кажутся людям понятнее: есть микроорганизм вредоносная живность, есть антибиотик средство против неё.

А вакцины, наоборот, кажутся сложными, непонятными, и от них люди словно ждут, что они будут действовать как мутаген из Черепашек-ниндзя. Отсутствие мутантов, созданных вакцинациями, люди принимают за подтверждение худших опасений: всё настолько плохо, что власти скрывают. А непонимание, что вакцина, в принципе, такое, и чего конкретно они боятся, ведёт к распространению позиции мы не знаем долгосрочных эффектов, подождём. Подождать, соответственно, подразумевается период предполагаемой возможности наступления побочных эффектов как правило, что-то исчисляемое в годах. Это абсурд.

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

Опасаться этого тоже логично. Но для этого и есть три фазы испытаний. Самые осторожные могут подождать, пока пройдёт пара недель вакцинации, будет вакцинирован 1% от популяции, например. Для России это миллион человек это в 50 раз больше количества участников третьей фазы испытаний Спутника (20 тысяч человек), и, с точки зрения репрезентативной выборки репрезентативнее некуда. При условии, что первыми обычно вакцинируются группы риска это и самые высокие группы риска побочных эффектов. А рассчитывать, что что-то, что не проявилось среди миллиона человек, проявится у двух, бессмысленно: на таких объёмах любая информация превращается в какофонию, ведь никто не ведёт учёта результатов, как во время результатов. Даже миллион человек это очень много, чтобы считать из неупорядоченных сигналов такой массы людей в ноосферу что-то осмысленное, только если среди них не начнётся массовый мор. Но если массовый мор не начался то разумных оснований откладывать вакцинацию больше не остаётся.

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

Пока люди продолжают заболевать и умирать от ковида при наличии действующей доступной вакцины это уже смерти не только эпидемии сопутствующих заболеваний (диабета итд), не только разрушенного состояния медицины, но и отсутствия в обществе солидарности. Можно говорить о том, что эпидемия раздута, случаев заболеваний не так много, смертность не так высока но с точки зрения личного выбора, гражданской позиции это ничего не меняет. 30 тысяч смертей от ковида в месяц, сто тысяч или миллион речь идёт о сейчас уже необязательных, предотвратимых смертях. По официальным данным, общее число смертей людей с коронавирусом в январе превысило 37 тыс. против 44 тыс. в декабре 2020 года. С начала 2020 года умерло около 200 тыс. человек с коронавирусом. Показатели избыточной смертности в России за год по февраль 2021 года показывают, что это число может быть почти в два раза больше. Впрочем, 37 тысяч в месяц это больше годовой смертности в ДТП. Помню, когда годовые показатели смертности в ДТП 1015 лет назад на самом деле были за 30 тысяч в год это казалось жутким количеством, и на дорогах постоянно напрягала перспектива пополнить эту статистику. 37 тысяч в месяц явно не вызывают такого эффекта возможно, потому что они умирают в больницах? Возможно, смерти в больнице не ощущаются такими же чудовищно внезапными, как на дороге.

Nobody panicswhenthings go according toplan. Eveniftheplanis horrifying!If, tomorrow, I tell the press that, like, a gang banger will get shot, or a truckload of soldiers will be blown up, nobody panics, because it's all part of the plan.

Впрочем, не с точки зрения людей, которые за 2 недели до этого умирать не планировали.

Что важно: эпидемия саму себя не остановит. С начала первых локдаунов в России прошёл уже полный год. Никакие сезонные ожидания на коронавирус не повлияли. В отсутствие вакцины его ничего не могло остановить хотя, безусловно, меры дистанцирования замедлили. В присутствие вакцины, но невакцинированном населении распространение коронавируса тоже ничего не остановит. Возможно, кажется, что само создание вакцины и доступность возможности вакцинироваться меняет ситуацию. По крайней мере, это чувствуется в воздухе: люди ведут себя если не так, словно всё закончилось, то словно всё закончится в ближайшие недели.

Но только не с точки зрения коронавируса. Лёгкость на душе от появления вакцин и приближающегося лета не является фактором, влияющим на развитие эпидемии. Смена сезонов не является таким фактором в 2020 надежды, что коронавирус хотя бы возьмёт отпуск под июньским солнцем не оправдались. 5 млн вакцинированных из 110 млн взрослого населения не остановят коронавирус. Если к ним прибавить переболевших, которых, по официальным данным, в январе насчитывалось менее 4 млн (и удвоить, чтобы учесть переболевших бессимптомно) получится 13 миллионов человек. При этом модель распространения коронавируса показала себя довольно устойчивой. На его распространения не влияют практически никакие другие факторы, кроме двух: количества и плотности нахождения невакцинированных и непереболевших людей поблизости друг от друга и ношения масок и очков для защиты себя и окружающих. По сути, это один и тот же фактор, потому что маски и очки, по сути, служат таким же барьером, как и дистанцирование. Маски, очки и дистанция замедляют распространение коронавируса, массовые сборища ускоряют распространение коронавируса, но оно продолжается в любом случае и больше на его распространение ничего, похоже, не влияет. Вакцинация способна повлиять но именно вакцинация, а не возможность вакцинации или новости о вакцинации.

Скажем, в США к началу июня привито уже более половины взрослого населения и менее, чем через месяц американцы планируют отмечать 4 июля всей страной. Это прекрасные новости для Америки и повод серьёзно задуматься для России.

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

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

Если кто-то пропустил, то с 24 по 28 мая мы реализовали проект под кодовым названием Рояль, азот и котик. И настало время рассказать о том, как мы всё организовали, с грязными подробностями, скандалами, интригами и расследованиями.

Сразу скажем, что это был, пожалуй, самый смелый и необычный проект для нашей компании.

Итак, наливайте в кружку кофе, смузи или ягер, и устраивайтесь поудобнее: впереди много гик-порно, мужиков с перфораторами и сварочными аппаратами, красивых девушек и, собственно, самого рояля Красный октябрь, который, как и полагается музыкальному инструменту Made in USSR, пережил падение и даже не расстроился (в прямом и переносном смысле). Чего не скажешь о капиталистическом ноутбуке

Всё началось с идеи. Ты никогда не знаешь, когда на тебя упадет рояль фраза, которая не один раз обыгрывалась в литературе и кинематографе и описывает гипотетическую ситуацию, когда происходит какое-то нелепое событие, которое, скажем так, вносит коррективы в планы главного героя.

Ок, а куда мы будем ронять этот рояль?

Очевидно, что ронять мы его будем на компьютер или ноутбук, так как речь идет о ситуации, когда под угрозой оказываются данные, хозяин которых не позаботился о цифровой копии в облаке. Чертежи, секретные материалы или резервная копия базы данных 1С: Бухгалтерии потеря этих данных уже обыгрывалась, и не один раз, как в фильмах, так и в страшных снах системных администраторов. Поэтому хотелось найти что-то свежее. И тогда мы схватились за идею, что это будет NFT-гифка с котиком, ценность которой стремительно растет.

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

Итак, история придумана, основные инструменты подобраны, осталось дело за малым, весь этот план реализовать

Окей, гугл, как подвесить рояль к потолку?

Да, по этому запросу результатов катастрофически мало, поэтому придется делать всё самим.

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


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

А что с помещением?

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

В голову приходили только строительные ангары, промышленные склады или заброшенные цеха. Вокруг мы построили бы декорации квартиры девушки и сносно вписались бы в легенду. Три location-менеджера, услышав наш бюджет и вышеописанные требования, глубокомысленно молчали. А когда слышали про наш план, что именно мы собираемся там уронить, вежливо заканчивали разговор и желали нам успехов в поисках.

И тут мы вспомнили о нашем друге, Алексее Горове, владельце студии Faraloft, в которой мы снимали уже несколько видео-проектов, и, не особо рассчитывая, позвонили ему. Хабр? Рояль? Жидкий азот? Разбить ноутбук? Ахаха, я в деле! ответил Алексей, и мы в очередной раз поверили в великую силу Хабра.

Оказалось, что он фанат Хабра, у него своя мини-ферма, где майнится крипта, и вообще он не против, чтобы в его легендарной студии произошла еще одна не менее легендарная история. А у него этих историй, поверьте, хватает.

Студия интересна тем, что она находится в бывшем гараже Госплана, спроектированном архитектором Мельниковым.


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

Ок, а что с роялем?

Найти в Москве поддержанный рояль было не сложно. Но когда речь заходила о том, чтобы он был в рабочем состоянии (нам нужно было, чтобы центральная октава была рабочей), тут все владельцы были не очень уверены в своих показаниях.

Наконец, нашелся один в Подмосковье (Электросталь), вполне вписывался в бюджет.

• А он у вас в рабочем состоянии? спрашивали мы.
• Да, две недели назад настраивали, говорила Валентина Ивановна, его владелица. Будьте с ним аккуратнее, пожалуйста!
• Ну что вы, Валентина Ивановна! Будем сдувать с него пылинки! отвечали мы, стараясь сохранить благородные интонации в голосе.

К нам в студию он прибыл тщательно упакованный от царапин:


Как только мы его распаковали и перевезли в студию, поняли, что рояль отлично вписывается в интерьер:


Фабрика Красный октябрь (бывшая фортепианная фабрика Беккер) выпускала отличные музыкальные инструменты.

Немного из истории фабрики: В 1947 году на фабрике было создано конструкторское бюро, и в 1950-е о достоинствах инструментов Красный Октябрь заговорили в Европе. Сенсацией стало завоевание ленинградским роялем Гран-при на Всемирной промышленной выставке в Брюсселе в 1958 году, ведь прославленные Блютнер, Бехштейн и Стейнвей его и за конкурента не считали.

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


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

Ок, а как мы его подвесим к потолку?

Первый набросок схемы крепления рояля к потолку выглядел так:

За кадром остались пенные напитки RuVDS, без которых никак нельзя было разобраться.

Три года назад мы с командой Хабра участвовали в регате AFR, и оттуда взялась идея стянуть все тросы, удерживающие рояль, в одну консоль, которую на яхтах называют пианино (подробнее о той легендарной регате читайте тут.



Первый эскиз пианино выглядел так:


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




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

Алексей Горов (владелец студии Faraloft) монтирует строительные леса, без которых до балки было не добраться.


Простите, Валентина Ивановна, мы постарались не царапать ваш рояль

Тросы крепились за специальный поддерживающий каркас из нержавеющего профиля, прикрученного ко дну рояля:


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


С такелажем и консолью не всё получилось сразу. Пришлось поменять болты с 8-миллиметровых на 10-миллиметровые, потому что при тестах их кое-где начало гнуть. А на соединениях тросов пришлось добавить П-образные хомуты, потому что двойные плоские стяжки не справлялись.

Первое тестовое поднятие рояля:


Да, в кадре пусто, потому что многие из нас смотрели фильм Корабль-призрак и на всякий случай отошли подальше. Никто не захотел быть героем сиквела Рояль-призрак.

Чтобы снизить возможный ущерб от отлетающих тросов (в студии большие стеклянные окна), мы закрепили на концах малярные валики:


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

А что, если на рояле можно будет поиграть?

Идея дать пользователям возможность поиграть на рояле вызвала у всей команды проекта восторг.

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

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

Параллельно мы начали думать о том, как организовать игру на рояле, и собрали на коленке прототип устройства на базе Arduino Nano и Raspberry Pi. В первом варианте у нас зажигались нужные лампочки адресной светодиодной ленты.


В конечном варианте мы добавили плату расширения с реле и два ряда соленоидов на фанерке:


Устройство собрано и готово ко встрече с роялем:


В финальном варианте это выглядело так:


Хотя сперва и была идея распечатать корпус на 3D-принтере, мы не стали прятать внутренности. Во-первых, чтобы оставить видимыми светодиоды, по которым нам будет понятно, работают ли основные узлы устройства или нет. А во-вторых, это же проект для Хабра, гик-порно и немного киберпанка:

Кадр из заставки сериала Мир дикого запада.

На сайте мы разместили клавиатуру, на которой нарисовали и цифры с нотами, что жирно намекало на то, что мы что-то там зашифровали:


Очевидно, что желающих проиграть свою мелодию будет много (за весь проект на рояле было проиграно около 2100 мелодий), поэтому мы реализовали механизм очереди через Telegram-бота. Участник проигрывал мелодию, она записывалась и передавалась ботом через API на Raspberry Pi. Пользователю сразу же после этого приходило первое оповещение с прогнозом времени воспроизведения, а затем, примерно за 20 секунд до того, как будет проигрываться запись, приглашение посмотреть этот момент вживую через трансляцию на сайте:


Участник переходил по ссылке и слушал, как его мелодия проигрывается в какой-то далекой московской квартире:


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

А что там с азотом?

Собственно, зачем вообще нужен был азот? Ну, во-первых, это красиво. А во-вторых, современные HDD делаются довольно прочными и вполне себе могут пережить такую незначительную неприятность, как падение рояля. Поэтому мы решили подойти к вопросу уничтожения NFT c котиком основательно и добавить в сюжет жидкий азот. Чтобы наверняка.

Для того, чтобы жидкий азот никуда не разлился, мы купили обычный душевой поддон и заварили у него сливное отверстие:


Резиновая пробка или герметик под действием азота могли бы довольно быстро разрушиться, поэтому Только сварка! Только хардкор!

Жидкий азот приехал к нам в обычной газели внутри которой размещался такой вот агрегат:


Да, судя по всему, одного из участников Дом 2 заморозили, чтобы реанимировать в 2035-м году и придать шоу новое дыхание:


Процесс переливки в жидкого азота в сосуд Дьюара:


В назначенный час мы, как и обещали, залили ноутбук жидким азотом:


Стоп-кадр за несколько миллисекунд до встречи с роялем. Видно, что от резкого охлаждения вспучилась панель ноутбука и клавиатура покрылась инеем:


А вот что стало с ноутбуком после заморозки и встречи с 500-килограммовым роялем:


Диск мы впоследствии вытащили, он действительно был целым, но данные на нем уже не читались, видимо, резкое переохлаждение всё же нарушило целостность печатной платы или микросхем. Ну штош, не самый дешевый способ избавиться от данных. Зато весьма зрелищный!

Итоги проекта и немного статистики:

• 7635 уникальных посетителей заглянуло на сайт проекта.
• 10 литров жидкого азота было вылито на ноутбук перед падением рояля.
• 45 метров троса понадобилось для поднятия и удержания рояля.
• 4 человека прошло квест до конца.
• 2340 раз рояль проиграл мелодии участников проекта.
• 113 раз рояль сыграл мелодию Чижик пыжик где ты был?

Хронология постов по проекту:

1. Спаси котика из-под рояля
2. Котики в NFT: революция в цифровом мире или хайповая пирамида?
3. Рояль над котиком, день первый
4. Хроники котика: брутфорс рояля, крыса-кун и деанон Оксаны
5. Финал квеста и победители: особенности криогравитационного воздействия на портативные ЭВМ
6. Hack the hackers: полное руководство по прохождению квеста
7. Как организовать трансляцию на 5 суток (почти) без разрывов?
8. Рояль, азот и котик: как это было <=== Вы сейчас здесь

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

А может быть, вы популярный хостинг? Хотите привлечь пользователей, используя около-тематический трафик создаете онлайн сервис который смог бы заменить целые серверные утилиты nslookup, dig, curl?! Звучит неплохо, но всё ли так хорошо с безопасностью пользователей?

Об интересных и неочевидных уязвимостях онлайн-сервисов поговорим под катом.

Важное отступление

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

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

Поиск уязвимостей проходил в рамках программы BugBounty. Все сайты, указанные во всех частях статьи, раскрыты с письменного согласия владельцев.

Ой! Прекратите! Чем опасен XSS в 2021??! Да и вообще, XSS не опасен. Не смешите читателей!

Кажется, верное утверждение. С внедрением CORS, X-XSS-Protection современные браузеры научились неплохо фильтровать XSS, вот только не все так гладко.

Любая XSS уязвимость, несет в себе идею возможности кражи Cookie данных для авторизации или переброски пользователя на фишинговый сайт например, для имитации окна ввода пароля. Эта статья как раз про то, что XSS всё ещё опасен, даже в Google Chrome.

Проверяем DNS записи или опасности утилиты Dig и NSLOOKUP в онлайн сервисах

Рассматриваемую здесь уязвимость можно расценивать как Stored XSS. Хоть хранимой она, в зависимости от архитектуры построения сервиса может не являться, вот только конечному пользователю будет совершенно непонятно откуда на странице взялся скрипт.

Если кто не знает, серверная утилита Dig (NSLOOKUP работает похожим образом) позволяет получить DNS записи любого домена. В интернете же, можно найти множество онлайн сервисов, которые используют эту утилиту у себя на бэкенде, а своим пользователям показывают результат её работы.

DNS записей существует несколько: A, MX, CNAME, SOA, TXT и другие. Мне стало интересно проверить возможности TXT записи что если здесь написать скрипт? Для проверки атаки нужен собственный домен.



Оказалось, помимо всевозможных символов DKIM и SPF подписей, в TXT запись можно написать обычный скрипт или полноценный html, с небольшими нюансами. Можно было бы подумать, что мой NS провайдер не экранирует спецсимволы, но нет так делать можно у всех.

Оказалось, помимо всевозможных символов DKIM и SPF подписей, в TXT запись можно написать обычный скрипт или полноценный html, с небольшими нюансами. Можно было бы подумать, что мой NS провайдер не экранирует спецсимволы, но нет так делать можно у всех.

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

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

На видео выше видим простую реализацию эксплуатации XSS уязвимости крупного хостинг-провайдера. Здесь пришлось немного изощренно подойти к вопросу реализации и вместо тега script, навесить код на событие onerror тегаimg.

Ребята из ukraine.com.ua закрыли уязвимость через 10 минут, после моего обращения в техподдержку. Быстрее, на моем опыте, пока не делал никто. Адекватная и профессиональная команда на всех этапах переговоров.

А что другие, спросите Вы? Например, ребята из Xtool тоже быстро исправили проблему и разрешили рассказать об этом в статье. Проблема здесь была в блоке DNS INFO:


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

Тем не менее, стоит отметить, что XSS уязвимости через TXT записи домена были (и могут быть) подвергнуты проекты масштабом на любой вкус от 200 тысяч до нескольких миллионов посетителей в месяц (по данным Similarweb), по всему миру.

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

Странные HTTP заголовки в ответе сервера

Продолжим тестировать онлайн-сервисы что если передать скрипт в HTTP заголовке? Сколько сервисов будут экранировать заголовки сервера, выводимые на свой фронтенд из curl -I [host]? Давайте попробуем, назовем заголовок X-Test .


Многие SEO-анализаторы, помимо технической информации о сайте, выводят, в том числе и заголовки ответа сервера. Это проблема не только мелких анализаторов. Здесь, как и в уязвимости из прошлого раздела, не очевидной уязвимости со скриптом в HTTP заголовке были подвержены проекты разных масштабов.

Идея эксплуатации HTTP заголовка ответа сервера не лежит на поверхности, именно поэтому разработчики могли упустить попытки подобной XSS атаки. Так произошло и с SEO анализатором сайтов Seolik, владельцы которого любезно разрешили опубликовать этот кейс. Разработчики проявили серьезное отношение к безопасности и в режиме адекватного диалога очень быстро исправили уязвимость.

Можно справедливо заметить, что для безопасности исполнения скриптов стоит использовать Content Security Policy . Некоторые онлайн-инструменты использовали этот прием и отключали inline скрипты. Однако, это не сильно осложняло задачу эксплуатации уязвимости, ведь большинство сервисов пользуются внешними средствами аналитики трафика.


Перед началом использования счетчиков, на странице необходимо инициализировать их, например так script nonce="analytics". Чтобы этот код заработал, онлайн-сервис добавил в CSP: default-src 'nonce-analytics'.

Но безопаснее не стало ведь мы по прежнему можем передать через XSS over Response Header такую же конструкцию скрипта. Браузер будет считать чужой скрипт местным.

Пишем скрипт в HTML теги

Согласитесь, писать скрипт в тег заголовка страницы неочевидное решение для попытки эксплуатации XSS. Но оно работает. Исследовав небольшую часть онлайн-сервисов, становится понятно, что не все экранируют содержимое HTML тегов: title, h1, description и других.

Разработчики популярного сервиса поисковой аналитики Topvisor тоже упустили нашу маленькую шалость и вывели содержимое тега title на страницу отчета анализа сайта.

Здесь, очень полезная функция ТопВизора Поделиться результатом анализа играет нам на руку ведь мы получаем прямую ссылку на эксплуатацию XSS уязвимости через вывод содержимого HTML тегов. Также стоит отдать должное отношению к безопасности разработчики связались в тот же день и сразу закрыли уязвимость.

Ситуация повторяется в популярном онлайн-сервисе для SEO-аудита PR-CY. Здесь также, в инструменте проверки Open Graph разметки, не экранировались значения полученные с исследуемого ресурса. Для удобства пользователей генерировалась прямая ссылка на результат что конечно на руку атакующему.

Администраторы PR-CY исправили баг в течении часа после обращения в поддержку, за что им спасибо. А еще через некоторое время предложили провести дополнительный аудит других проектов.

Неожиданные уязвимости популярных онлайн-инструментов

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

Нет. Писать текст не придётся. Здесь не будет NFT котиков и рояля на тросах, но будет небольшая головоломка. Предлагаю читателям как можно скорее найти и раскрыть все варианты одной XSS уязвимости онлайн-сервиса от W3C который называется "Unicorn".


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

Решением можно считать найденные, как минимум, 3 разных способа эксплуатации XSS уязвимости Юникорна (должны быть разные варианты скрипта и разные теги страницы). Варианты точно не очевидные, но очень простые и из статьи легко понять направление поиска. Минимально, в валидаторе должен сработать alert с любым текстом из вашего скрипта.

Пока вы решаете головоломку, я подготовлю вторую часть статьи с объявлением лучших решателей и подробным описанием уязвимостей популярного продукта W3C Unicorn и еще нескольких онлайн-сервисов, аудитория которого превышает несколько миллионов посетителей в месяц (по данным SimilarWeb).

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

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

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

Хорошие новости

Современный Rust оказывается весьма схож с JavaScript. Переменные объявляются через let, функции выглядят очень похоже, типы уже не чужды, так как мы привыкли к TypeScript, присутствуют async/await, да и в общем формируется весьма знакомое ощущение.

Плохие новости

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

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

Управлению памятью быть!

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

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

Когда речь заходит об управлении памятью, то Rust как бы говорит: Ничего не знаю реальные шеф-повара сами за собой убирают. И на то есть хорошая причина, потому что сборщик мусора несет в себе собственный набор неочевидных проблем, которые могут навредить в самый неожиданный момент. Хотя в то же время, обогащенный опытом других языков, Rust признает, что заставлять программиста управлять памятью столь же разумно, сколь поручить Дугласу Адамсу написать Звездолет Титаник.

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

Как розу ты ни назови, а запах ее столь же сладок

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


Корабль длиной 55 метров, замаскированный в Тихом океане под вид маленького острова для избежания обнаружения во время Второй мировой войны. Сработало

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

На землях Вестероса (смею я сказать ВестеRust?) есть крохотные, небольшие, а также крупные феоды. Загвоздка в том, что все они оккупированы Ланнистерами. Внутренне феоды занимаются своими собственными делами, а когда им требуются товары извне, то они берут на себя долг, чтобы эти товары получить. В последствии долг необходимо возвращать Богам Вестероса. Rust подобен королеве драконов этого мира он узрит свысока все нюансы и проследит, чтобы все долги перед Богами были уплачены.

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

Может ли возникнуть кризис?

Посмотрим, как это работает.



Здесь у нас две области: внешняя main и внутренняя, будем звать ее inner scope, для демонстрации. В этом случае владение работает так:

1. main владеет a и b
2. a хочет поработать в inner scope, поэтому main передает a во владение inner scope
3. inner scope делает свои дела с a и завершается
4. Скрытый код Rust отбрасывает a
5. main делает свои дела с b и тоже завершается
6. Rust отбрасывает b

Обратите внимание, что долг, обусловленный владением, возвращается системе, а не области, из которой возник. Владение a не возвращается в область main. Так, подождите звучит очень опасно.

Что, если у нас будет такой код?



Здесь область main хочет снова использовать a, но мы сказали, что Rust уже ее отбросил по завершении inner scope.

Не даст ли программа сбой и не сгорит ли, когда достигнет этой точки выполнения?



Да, так и будет. Но, как спартанцы ответили отцу Александра, королю Филиппу II Македонскому: если она этой точки достигнет.

Абсолютный бюрократ

Компилятор Rust является гордым послушником традиции Легизма, настолько верным, что Хан Фей-цзы с восторгом бы объявил вне закона все остальные языки. Ничто не происходит в землях Rust, пока компилятор не скрепит это действие печатью Утверждаю. Он будет тщательно проверять каждую мелочь, оценивая, насколько безопасен запуск программы, и только при удовлетворении всех требований выдаст-таки исполняемый файл.



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

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

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

Rust RPG

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

Помните пример с dbg!()? Это макрос, представляющий грубый эквивалент console.log из JS. Давайте создадим собственную типизированную переменную и выведем ее в консоль.



Мы создали struct, которая, по сути, является типом. Затем мы создали объект этого типа. В завершении мы запросили вывод созданного объекта.



Ну дела. Наш игрок до такой степени нуб, что даже не может предоставить отладочную информацию. Правда! Просто удивительно

Ключевой момент здесь в том, что ваши рукотворные переменные все начинают в пешках без всякого снаряжения. А вот где вступает в игру и само снаряжение (на языке Rust называемое типажи (Trait)).

Нажмем F.



На этот раз работает. Единственное отличие в появившейся сверху строке. Здесь мы снаряжаем Noob типажом Debug. Теперь наш игрок готов к выходу в консоль какое достижение!

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

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

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

Типаж Copy означает, что вы берете раздел памяти и memcpy его в другое место, работая непосредственно с байтами. Хорошо, значит String не имеет типажа Copy, нужно ли нам просто сообщить компилятору, чтобы он его присвоил? К сожалению, нет. В целях безопасного использования Copy является слишком низкоуровневой для применения к String.

Конечно же, Rust бы не был полезен, если бы история на этом завершалась. Есть более явный типаж, который проделывает практически то же самое Clone. String обладает типажом Clone, значит нам просто нужно использовать его вместо Copy.

В качестве примера немного подправим код:



Здесь компилятор видит, что нам нужно использовать a внутри inner scope, но теперь он также видит, что мы научились все делать правильно, задействовав вместо фактической a ее клона. Итак, получается следующее:

1. a принадлежит main
2. Создается a.clone и одалживается в inner scope
3. inner scope делает свои дела и завершается
4. Rust отбрасывает a.clone
5. main без проблем использует a, потому что a всегда оставалась в ее владении

Красота. Естественно, это не единственный способ решить конкретно данную проблему, но он четко вписывается в наше небольшое исследование принципа владения и типажей.

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

Конец?

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

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

Привет, Хабр! Серная кислота почти вдвое тяжелее воды, и её водные растворы, в том числе аккумуляторный электролит, склонны к расслоению: тяжёлая кислота вытесняет лёгкую воду вверх и опускается вниз. Как это влияет на работу аккумуляторной батареи, и насколько эффективно перемешивает электролит тряска при движении транспортного средства? Проведём эксперимент с видео и показаниями приборов.

Перед началом опыта, вспомним известные факты о расслоении электролита:

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

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

Следовательно, повышенная концентрация электролита в нижней части банок и глубине намазок пластин АКБ аккумуляторной батареи ведёт к тому, что для преодоления термодинамической ЭДС требуется более высокое напряжение на клеммах. При недостаточном напряжении заряд участка активной массы (АМ) с повышенной концентрацией кислоты не произойдёт никогда. Также препятствует заряду и недостаток воды в данном участке АМ.

И заряд, и разряд активных масс ведут к расслоению электролита, так как выделяющаяся при заряде кислота стремится вниз, а образующаяся при разряде вода вверх. Таким образом, если не предпринять специальных мер, при любой глубине циклирования или просто саморазряде АКБ расслоение электролита прогрессирует.

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

Чем более прогрессирует расслоение электролита, тем большая доля активных масс при штатном зарядном напряжении не заряжается, то есть, остаётся в виде сульфата свинца, склонного переходить в труднорастворимую форму. Это явление называется сульфатацией. Не следует путать с двойной сульфатацией п. 1 нормальной токообразующей реакцией. Сульфаты имеют меньшую плотность, чем заряженные АМ губчатый свинец отрицательных пластин и оксид свинца положительных, потому сульфатированные намазки увеличиваются в объеме, что ведёт к разрушению конструкции аккумулятора и коротким замыканиям. П. 5 этому препятствует, но при отсутствии периодического выравнивающего заряда АКБ с расслоением и сульфатацией теряет ёмкость, токоотдачу и концентрацию кислоты в верхних слоях электролита.

Электролит с низкой концентрацией кислоты замерзает при более высокой (менее минусовой) температуре, потому расслоение электролита ведёт к выходу аккумулятора из строя в зимнее время.


По просторам Всемирной Паутины с давних времён гуляет множество мифов о губительности кипячения, заряда с перенапряжением и выделением водорода и кислорода, пузырьки которых перемешивают электролит, для автомобильных АКБ. Многие руководствуются этими мифами при заряде АКБ и выборе для этого зарядных устройств ЗУ.

Отчасти поэтому, во многих моделях ЗУ производители ограничивают напряжение на уровне, не допускающем кипения электролита, в других моделях предоставляют пользователю выбор максимальных напряжений заряда путём ступенчатого переключения или плавной регулировки, даже если ЗУ представляет собой не просто источник питания со стабилизацией тока и напряжения (СС/CV), а имеет алгоритмы автоматического управления напряжением и током согласно табличным значениям профиля или на основании измерения характеристик АКБ.

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

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


Подопытным будет аккумулятор АКОМ +EFB 6СТ-60VL. Со времени предыдущего стационарного обслуживания он использовался на автомобиле 4 месяца. График работы владельца автомобиля сутки через трое, каждая поездка занимала 20 минут. Стартер и сигнализация за трое суток простоя в каждом таком цикле расходовали примерно 3 ампер*часа.

Начнём с измерения параметров текущего состояния. И как всегда, в первую очередь вымоем корпус и зачистим клеммы.


Напряжение разомкнутой цепи НРЦ, оно же ЭДС без нагрузки, по показаниям трёх приборов 12.48, 12.50, 12.52 В.


Плотность электролита по банкам колеблется от 1.22 до 1.23. В крайних банках плотность ниже, в средних выше. Это тенденция, обычная для свинцовых батарей.


Итак, наблюдаем расхождение: НРЦ соответствует уровню заряженности выше 80%, плотность электролита при котором должна быть 1.24, а по плотности уровень заряженности получается 75%, НРЦ должно быть 12.4 В. Причиной такого несоответствия как раз является расслоение электролита за 4 месяца эксплуатации под капотом. Повышенная концентрация кислоты в нижней части банок создаёт завышенное НРЦ. АКБ в таком состоянии необходим стационарный заряд.


Напряжение под нагрузочной вилкой не падает ниже 10 вольт, аккумулятор способен крутить стартер. Но если почитать инструкцию от производителя, то там чётко и ясно написано: если плотность ниже 1.25, аккумулятор требуется зарядить до плотности 1.28. Также в инструкции сказано,что можно оценить степень заряда по напряжению, и рекомендуется производить стационарный заряд при НРЦ ниже 12.5, но если имеется доступ к электролиту, то лучше проверить его плотность.


Приступаем к заряду зарядным устройством BL1204 на программе 2.


Заряд длился 9 часов. Плотность по банкам составила от 1.23 до 1.24.


По графику напряжения на клеммах, видно, что ЗУ производит основной заряд с подачами и паузами разной продолжительности, а затем три этапа непрерывного дозаряда, после чего последовали тест АКБ и буферный режим 13.65 В. Однако для кальциевой АКБ до 14.8 вольт происходит лишь основной заряд, потому продолжим заряд на программе 4.


Время заряда составило 1 час 16 минут плюс 20 часов в режиме буферного хранения. Плотность поднялась ещё на одну сотую и составила от 1.24 до 1.25. Сделаем ещё один проход на 4-й программе.


Время заряда снова 1 час 16 минут. Плотность поднялась всего на 0.005. Перезапустим программу 4 в третий раз.


Третий проход длился те же 1 час 16 минут. Плотность снова поднялась на 0.005. Отключаем ЗУ от АКБ. После отстоя продолжительностью 18 часов 20 минут НРЦ 13.20 В. При плотности 1.25 это говорит об очень сильном расслоении электролита. Запустим программу 4 ещё раз.


Заряд длился на этот раз около 50 минут. Плотность электролита не поднялась. Попробуем воспользоваться другим ЗУ.


Возьмём Бережок-V, установим 15.9 В то же максимальное напряжение, что у BL1204.


Ток изменяется от -0.2 до 4.5 ампер. Отрицательное значение тока не ошибка токовых клещей, а разрядные импульсы в асимметричном (реверсивном) заряде.


Заряд длился 4 часа, за которые ЗУ сделало две длительные паузы, и затем перешло в режим хранения не поддержание буферного напряжения, как BL1204, а периодический подзаряд.
В пиках напряжение достигает тех же 15.9.


Плотность в 5 банках составила 1.26 или чуть выше, и в одной 1.255. Оставим АКБ на ночь дозаряжаться в режиме хранения.


По прошествии 15 часов, импульсы тока доходят до 5 А, снижаясь менее чем за секунду до 1 А.
Для отбора проб электролита из глубины банок воспользуемся удлинённой пипеткой, гибкий наконечник которой может пройти сбоку от пластин. Короткой пипеткой произведём отбор, как обычно, из верхнего слоя.


Плотность верхнего слоя составила 1.26, нижнего почти 1.31. Это весьма значительное расслоение, обуславливающее высокое напряжение разомкнутой цепи при недозаряженных и сульфатирующихся нижних частях пластин. Ни одно из применённых ЗУ при заряде нашего аккумулятора до 15.9В с расслоением не справилось.


Устранят ли поездки такое расслоение? Для непосредственной проверки установим АКБ под капот, для чего пришлось удлинить провод массы.


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


Приборная панель Gamma GF-618 позволяет регистрировать данные поездок, что тоже очень пригодится в нашем эксперименте.


Пробег за трое суток в городском режиме составил 143.7 километра. Большое количество разгонов и торможений должно способствовать перемешиванию электролита.


Израсходовано 12.8 литров бензина.


После таких поездок плотность на глубине составила 1.29.


Плотность сверху 1.27. Предписываемого инструкцией значения 1.28 так и не достигли. Расслоение до сих пор присутствует. Покатаемся ещё трое суток, на этот раз, не только по городу, но и по трассе.


Итого за 6 суток автомобиль двигался восемь с половиной часов.


Общий пробег за это время 377.8 км.


Бензина затрачено 28.8 литра.


Плотность электролита наверху и внизу, наконец, уравнялась, и составила чуть ниже 1.27.


Итак, чтобы устранить расслоение в Ca/Ca EFB аккумуляторе после нескольких перезапусков стационарного заряда до 15.9 вольт, понадобилось почти 378 километров пробега и 29 литров бензина при напряжении бортсети 14.8 В. Сделаем выводы:

Q: Перемешивается ли электролит в современном кальциевом аккумуляторе с высокой плотностью сепараторов и упаковки пластин при движении транспортного средства?

Да, действительно перемешивается.

Q: Насколько такое перемешивание эффективно?

Мягко говоря, не очень.При более низком напряжении бортовой сети и более коротких поездках расслоение электролита продолжило бы прогрессировать

Q: Остались ли после всех стараний в испытуемом аккумуляторе недозаряд и сульфатация?

Да, остались. Чтобы считать данную АКБ заряженной, мы должны получить плотность верхних слоёв не менее 1.28.

Q: Проявляют ли EFB аккумуляторы, вместе со склонностью к расслоению электролита, заявленную стойкость к длительному недозаряду (PSoC, partial state of charge, состояние частичной заряженности) и циклированию с глубокими разрядами?

Да, как показывают другие наши исследования, которые продлжаются, уже выложено несколько видео, и готовятся следующие видео и статьи.

Q: Тем не менее, будут ли ёмкость, токоотдача и устойчивость к замерзанию электролита деградировать если не предпринимать периодических регламентных процедур по полному стационарному заряду?

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

---

Теперь давайте всё-таки продолжим заряд данной аккумуляторной батареи. На этот раз начнёт Бережок-V, при том же напряжении окончания заряда 15.9 В.


Заряд продолжался около 4 часов, плюс 4 часа в хранении.


Плотность поднялась с чуть ниже 1.27 до 1.275. Передаём эстафетную палочку BL1204.


Заряд длился около часа, и далее 14 часов в режиме хранения.


Плотность осталась 1.275.


Установим на Бережке-V ограничение напряжения 16.7 вольт и запустим заряд.


По прошествии 4 часов ЗУ автоматически перешло в режим хранения. Плотность и над пластинами, и на глубине чуть выше 1.28. Электролит перемешан, расслоение устранено.


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


Спустя сутки, имеем следующие показания тестера:
Здоровье 100%, внутреннее сопротивление 4.81 мОм, ток холодной прокрутки 574 из 560 А по стандарту EN. НРЦ 12.80 В соответствует плотности 1.28. Расслоения нет, АКБ в полном порядке, можно ставить под капот.

Статья составлена в сотрудничестве с аккумуляторщиком Виктором VECTOR, осуществившим описанные опыты.

Сегодня, в третьей части серии материалов, посвящённых разработке серверов на Go, мы займёмся реализацией нашего REST-сервера с использованием Gin одного из самых популярных веб-фреймворков для Go. Вот код, который мы будем тут обсуждать.

Выбор веб-фреймворка

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

Я выбрал именно Gin из-за того, что это один из самых популярных проектов такого рода (если судить по количеству GitHub-звёзд). Этот фреймворк кажется минималистичным, возникает такое ощущение, что с ним будет легко работать. Состояние документации к нему оставляет желать лучшего, но сам фреймворк настолько понятен, что мне, несмотря на это, было достаточно легко в нём разобраться и начать им пользоваться.

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

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

Маршрутизация и Gin

Наша функция main настраивает новый маршрутизатор Gin и регистрирует маршруты:

router := gin.Default()server := NewTaskServer()router.POST("/task/", server.createTaskHandler)router.GET("/task/", server.getAllTasksHandler)router.DELETE("/task/", server.deleteAllTasksHandler)router.GET("/task/:id", server.getTaskHandler)router.DELETE("/task/:id", server.deleteTaskHandler)router.GET("/tag/:tag", server.tagHandler)router.GET("/due/:year/:month/:day", server.dueHandler)

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

Вышеприведённый код регистрации маршрутов должен показаться вам знакомым. А именно, он немного похож на тот код, который использовался в gorilla-версии нашего сервера. Но в нём есть и некоторые отличия:

1. Вместо указания HTTP-метода в виде дополнительного (Go) вызова метода в маршруте, метод закодирован в имени функции, используемой для регистрации маршрута. Например тут используется конструкция вида router.POST, а не что-то вроде router.HandleFunc(...).Methods(POST).
2. Gorilla поддерживает обработку запросов с использованием регулярных выражений. А Gin нет. К этому ограничению мы ещё вернёмся.

Обработчики запросов

Посмотрим на код обработчиков запросов, используемых при применении Gin. Начнём с самых простых, в частности с getAllTasksHandler:

func (ts *taskServer) getAllTasksHandler(c *gin.Context) {allTasks := ts.store.GetAllTasks()c.JSON(http.StatusOK, allTasks)}

Тут стоит обратить внимание на несколько интересных моментов:

1. У обработчиков, используемых в Gin, нет стандартных сигнатур HTTP-обработчиков Go. Они просто принимают объект gin.Context, который может быть использован для анализа запроса и для формирования ответа. Но в Gin есть механизмы для взаимодействия со стандартными обработчиками вспомогательные функции gin.WrapF и gin.WrapH.
2. В отличие от ранней версии нашего сервера, тут нет нужды вручную писать в журнал сведения о запросах, так как стандартный механизм логирования Gin, представленный ПО промежуточного уровня, сам решает эту задачу (и делается это с использованием всяческих полезных мелочей, вроде оформления вывода разными цветами и включения в журнал сведений о времени обработки запросов).
3. Нам, кроме того, больше не нужно самостоятельно реализовывать вспомогательную функцию renderJSON, так как в Gin есть собственный механизм Context.JSON, который позволяет формировать JSON-ответы.

Теперь давайте изучим немного более сложный обработчик запросов, поддерживающий параметры:

func (ts *taskServer) getTaskHandler(c *gin.Context) {id, err := strconv.Atoi(c.Params.ByName("id"))if err != nil {c.String(http.StatusBadRequest, err.Error())return}task, err := ts.store.GetTask(id)if err != nil {c.String(http.StatusNotFound, err.Error())return}c.JSON(http.StatusOK, task)}

Тут особенно интересно выглядит обработка параметров. Gin позволяет обращаться к параметрам маршрута (к тому, что начинается с двоеточия, вроде :id) через Context.Params.

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

Привязка данных запросов

И последний обработчик запросов, который мы рассмотрим, это createTaskHandler. Он обрабатывает запросы, которые включают в себя особые данные, поэтому с ним интересно будет познакомиться поближе:

func (ts *taskServer) createTaskHandler(c *gin.Context) {type RequestTask struct {Text string  `json:"text"`Tags []string `json:"tags"`Due time.Time `json:"due"`}var rt RequestTaskif err := c.ShouldBindJSON(&rt); err != nil {c.String(http.StatusBadRequest, err.Error())}id := ts.store.CreateTask(rt.Text, rt.Tags, rt.Due)c.JSON(http.StatusOK, gin.H{"Id": id})}

В Gin имеется серьёзная инфраструктура для организации привязки запросов к структурам данных Go, содержащих данные из запросов. Тут под привязкой понимается обработка содержимого запросов (которое может быть представлено данными в различных форматах, например JSON и YAML), проверка полученных данных и запись соответствующих значений в структуры Go. Здесь мы пользуемся весьма примитивной формой привязки данных для RequestTask, где проверка данных не используется. Но, полагаю, нам стоит знать не только о базовых, но и о более продвинутых возможностях Gin.

Можно заметить, что Gin-версия createTaskHandler существенно короче более ранних версий аналогичного обработчика, так как за разбор JSON-данных запроса отвечает ShouldBindJSON.

Ещё внимание обратить стоит на то, что теперь нам не нужно пользоваться одноразовой структурой для ID ответа. Вместо этого мы используем gin.H псевдоним для map[string]interface{}; это очень просто, но, всё же, позволяет весьма эффективно конструировать ответы, используя совсем небольшие объёмы кода.

Дополнительные возможности Gin

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

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

Ограничения фреймворков

Обратная сторона удобства работы с веб-фреймворками это их ограничения и непривычные стилистические особенности кода, который пишут с их использованием. Мы уже столкнулись с подобным ограничением в нашем простом примере. Речь идёт об отсутствии поддержки регулярных выражений в системе маршрутизации Gin. А это значит, что обработка любого необычного маршрута, его разбор и проверка, потребуют писать больше кода.

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

Представьте себе, что мы обнаружили ограничение в gorilla/mux, которое мешает развитию нашего приложения. Мы в такой ситуации вполне можем заменить этот маршрутизатор на другой, подходящий. Конечно, придётся потратить некоторое время на переход, но изменениям подвергнется только конфигурация маршрутизатора.

А теперь давайте представим, что у нас имеется большое веб-приложение, написанное с применением Gin. Мы неожиданно выясняем, что ограничение, связанное с регулярными выражениями, несовместимо с проектом (вряд ли так случится на самом деле, но, всё равно, это хороший пример). Но мы не можем просто взять и быстро заменить Gin на другой фреймворк, так как на Gin основано всё наше приложение. Перевод проекта на другой фреймворк потребует очень много времени и сил.

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

Каким фреймворком вы воспользовались бы при разработке сервера на Go?

Завтра, 18 июня в 15:00 в наших соцсетях выступит Лейла Исмаилова, специалист машинного обучения в геологии и со-ведущая подкаста о геологах Про вулканы и людей

Лейла окончила геологический факультет МГУ им. М.В. Ломоносова. Поступила в аспирантуру Баварского Геологического Института в Германии. Во время обучения в аспирантуре опубликовала статьи в престижных научных журналах (Nature и Science Publishing group) и работала в разных лабораториях в Германии, Франции и США. С подробным списком публикаций можно ознакомиться по ссылке.

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

План выступления

Задавайте вопросы в комментариях и Лейла ответит на них во время прямого эфира.

• Наука в геологии
• Как стать ученым в России
• Наука в России и наука зарубежом
• Машинное обучение в нефтянке

До встречи в эфире!

Начну с того, что очень часто, рядом со мной аккумулируется разного рода железо (в простонародье хлам), а так как я по своей природе Плюшкин, в том плане, что я очень редко выкидываю технику, а если и случается предварительно вытаскиваю оттуда всё, что может хоть как-то пригодиться. И что бы ничего не выкидывать, периодически приходится находить применение всему этому железу, об этом сегодня и будет идти речь.

Итак мы имеем: ПК 11 летней давности в состоянии трэш.
Если подробнее: у блока питания вздуты все конденсаторы на выходе, у жёсткого диска взорванный полимерный конденсатор на входе питания, видеокарта тоже не стартует. По моим догадкам, по 12в линии явно пошло сильно больше 12в. При этом материнка с процессором остались живы. Чудо!

Порывшись в закоулках нахожу 4 плашки ddr2 пару на 1гб и пару на 2гб.

По характеристикам

Процессор: Celeron E3400
Материнская плата: P5K PRO
Оперативная память: 6 Gb ddr2
Жёсткий диск: 400 Gb IDE
Видеокарта: GeForce 8400 GS
Блок питания: FSP 350W

---

Ну вот всё что нужно есть, приступаем к оживлению трупа!

Начал с БП. Конденсаторов на большую ёмкость у меня нет (2000-3000мкФ) и пришлось городить этажами, получился вот такой лес:



На плате жёсткого диска, припаял конденсатор (старый просто испарился, одни следы только были), так же заодно покрыл припоем контактные площадки, чтобы не коррозировали, и даже не надеялся что он заработает, однако ожил:



С видеокартой немного сложнее, питание gpu звонится с малым сопротивлением в обе стороны, явно что то не то. При прозвоне нашёл два подозрительных силовых транзистора, перепаял на те, что были в закромах, заработало это только с помощью черной магии, других объяснений нет!Хотя сильно в нагрузке не тестировал:



Обновляю bios, накатываю win 10 и подключаю подготовленные под это дело диски (восстановленные). Я осознал насколько он тормоз в плане быстродействия, так что все планы по установке чего либо в него, я убрал (по крайне мере до того момента как найду, хотя бы четырёхъядерный процессор).



Тут больше ничего не оставалась как сделать из него NAS (сетевое хранилище) с возможностью подключения по RDP, к тому же в материнке была рабочая родная гигабитная сетевая карта (кто много возился со старым железом, знает что рабочая сетевуха в материнке это джекпот).
Далее я в прямую сделал доступ к локальным дискам по SMB включая C и разрешил подключение по RDP:

Майнинг

Сразу понятно что речь идёт о новой одноимённой монете.
Так как я не дата центр, будем экспериментировать с пулом.
Еще к этому NAS я подключил заплоченные диски, по-другому никак, характеристики вы сами видели.

На главном компьютере запускаю программу добычи, и тут столкнулся с тем, что сетевые диски она не видит, пришлось прописать полный путь до каждого диска:



После 24ч теста всё хорошо, ничего не взорвалось. Синхронизация кошелька ест 90% процессора и идёт со скоростью ленивца, который должен преодолеть 50 км ХД.

По итогу, у нас 6 портовый NAS, ещё и с 400Гб памяти на борту. Ради интереса глянул сколько стоит подобные готовые решения и удивился 700$ и это минимум.

Что можно сделать дальше?

Можно отрыть 4 ядерный процессор, подоткнуть usb 3.0 контроллер, настроить мультимедийный DLNA сервер и это только то, что мне пришло на ум.

На момент написания текста статьи, 1Тб приносит 10 рупий рублей в день.

Ни одна деталь не была куплена, всё собиралось из того, что есть.

Финал

Мне нравится спасать компьютерное железо, это экологично и экономично, к тому же, никогда не знаешь, когда может пригодиться тот или иной компьютер. И вышел реально неплохой NAS, если отойдёт в мир иной напишу в комментариях.

Галактика Андромеды в различных спектральных диапазонах: радио, инфракрасном, видимом, ультрафиолетовом и рентгеновском

Два года назад в космосе завершилась работа российского спутника Спектр-Р основы астрофизического проекта РадиоАстрон. Сейчас ему на смену пришел космический телескоп Спектр-РГ, а в разработке находятся еще две обсерватории Спектр-УФ и Миллиметрон. Давайте посмотрим зачем Роскосмос и Российская академия наук создают эти телескопы, и как движется их реализация.

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

Что такие могоспектральная астрономия?

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


Наука открыла людям возможность смотреть вокруг себя и в других диапазонах. В зависимости от длины волны электромагнитные колебания мы называем по разному. Длинные волны от километров до сантиметров это радио. Например FM радиоволна имеет длину около 3 метров, сотовая связь 16 см, микроволновки 12 см, а экспериментальная сеть 5G в Сколково 6 см.

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


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

Электромагнитные волны создаются в процессах связанных с выделением и передачей энергии, а из далекого космоса к Земле долетает только то, что было выброшено какими-то масштабными событиями: взрывами сверхновых, аккреционными дисками черных дыр, воздействием космической радиации на газ и пыль И каждое событие соответствует своей спектральной подписи. Излучение звезды зависит от её температуры и состава, например, Солнце имеет пик яркости в диапазоне видимого света, а в гамма-диапазоне почти черное. Молодые звезды синие, старые красные. Далёкие квазары светят практически во всём спектре.

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

Центр галактики Млечный путь в различных диапазонах рентгеновского света и радиоизлучения

Излучение, которое достигает Земли, далеко не всегда прямо совпадает с тем, которое покинуло источник. Разница зависит от скорости источника относительно приемника, расстояния и свойств среды между ними. И только учет всего комплекса факторов позволяет извлекать огромный объем данных о близком и далёком космосе: изучать строение, движение и эволюцию звезд, находить экзопланеты и черные дыры, наблюдать процессы в ядрах галактик, измерять расстояние в галактических и галактических масштабах, изучать свойства межгалактического и межзвездного пространства, заглядывать в прошлое галактик на миллиарды лет В конечном счёте, лучше понимать Вселенную, в которой мы живём. Поэтому нам и нужны многоспектральные глаза. (Крайне рекомендую книгу на эту тему Многоканальная астрономия).

Зачем запускать телескопы в космос?

В межзвездном пространстве электромагнитные волны переживают воздействия от гравитационных волн, межзвездной плазмы, газа и пыли, но самое серьезное препятствие на пути к Земле это наша атмосфера. Её плотность сопоставима с десятью метрами воды, поэтому нам не страшна космическая радиация, но астрономам интересна именно она. Даже если в небольшой телескоп взглянуть на звёзды с Земли, то можно увидеть рассеивающий эффект воздуха, а для некоторых электромагнитных волн (жесткий УФ, рентген, гамма) воздух вообще непрозрачен.


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

Пролёт спутников Starlink в поле зрения одного из телескопов обсерватории CTIO

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

Спектры

Ученые Советского Союза в 80-е годы прошлого века запланировали масштабную астрофизическую программу Спектр, которая предполагала запуск целой серии тяжелых космических телескопов. Наблюдение планировалось в радио, миллиметровом, инфракрасном, ультрафиолетовом, рентген и гамма диапазонах. Соответственно телескопы получили литеры: Р, М, ИК, УФ, РГ. К сожалению, в приоритетах советской космонавтики 80-х гг была гонка с Америкой: станции Мир, Энергия-Буран, безумное количество спутников-шпионов СССР запускал по две ракеты в неделю, но не для науки. Лишь пара телескопов была запущена в 80-х: Астрон, и Гранат, но Спектры оставались только в мечтах наших астрономов.

Потом Советский Союз распался, пришли лихие девяностые, в которые каждый лихачил как мог. Например специалисты Астрофизического центра Физического института имени Лебедева собрали прототип телескопа КРТ-10 в Пущино, и приступили к наземным испытаниям.


Технически это был РТ-10, поскольку К значит космический, а наземный прототип в космос не летел. Но работа была вознаграждена. Астрофизикам, физикам и инженерам удалось-таки создать и запустить в 2011 году первый из Спектров Р, т.е. радио.

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


На мой взгляд, главная уникальность РадиоАстрона была в том, что он в принципе полетел несмотря на обстоятельства, в которых создавался в 90-е и 2000-е. Наиболее важную роль в этом достижении сыграл Николай Кардашев, который в 50-х годах был соавтором работы теоретически обосновавшей создание гигантских радиотелескопов-интерферометров, а в последние десятилетия своей жизни весь свой авторитет вложил в запуск РадиоАстрона. Разработанная с участием Кардашева технология РСДБ значительно расширила возможности радиотелескопов за счет их объединения в решетки-интерферометры. Теперь много антенн могли работать как одна большая.


Причем их можно объединять не только напрямую, но и удаленно, т.е. создавать радиотелескопы-интерферометры диаметром 12 тысяч километров. Это не опечатка, всё правильно: радиотелескоп размером 12 тыс км. РСДБ позволяет объединять антенны размещенные по всей Земле, а значит пределом выступает только её диаметр.

Космический РадиоАстрон позволил увеличить размер радиоинтерферометра до 340 тыс км, и Кардашев стал свидетелем его успешной работы. Позже, та же технология, примененная уже европейскими и американскими учеными дала фотографию тени черной дыры.


Другие Спектры тоже двигались вперед, например 1,7-метровое зеркало для ультрафиолетового телескопа уже изготовлено на Лыткаринском заводе оптического стекла, а его гигантская труба, размером с автобус, не первый год ждет своего часа на НПО им. С.А. Лавочкина. Правда были проблемы с финансированием и санкционной электроникой, но, вроде бы, их смогли решить.


Рентгеновский Спектр-РГ, после многочисленных задержек и проблем полетел-таки в 2019 г. и сейчас радует мировую науку. Это тоже телескоп с тяжелой судьбой, которая требует отдельного рассказа. Сложности в его создании привели в выпадению Г из его научной программы, т.е. он наблюдает только в рентгене, а для гамма-диапазона не предназначен, но название решили не менять, чтобы не получился второй Спектр-Р.

В отличие от РадиоАстрона рентгеновский телескоп наблюдает не отдельные источники излучения, а ведет картографирование всего видимого небосвода.


Спектр-РГ это тоже международный проект, но если у РадиоАстрона иностранное участие заключалось в наземной поддержке, то в рентгене наблюдает два телескопа: российский и германский. За каждые полгода работы Спектра-РГ составляется полная карта небосвода, и чем дольше ведутся наблюдения, тем большего проникновения добьются телескопы и больше источников рентгеновского излучения будет картографировано.


Про Спектр-РГ мы обязательно поговорим отдельно. Нам же осталось упомянуть о самом сложном, и самом долгом Спектре Миллиметроне. Его разработкой сегодня заняты создатели РадиАстрона, которым помогает накопленный в прежнем проекте опыт.

Рендер Миллиметрона на фоне снимка инфракрасного телескопа Herschel. Снимки Миллиметрона должны выглядеть примерно так.

Миллиметровый диапазон не менее важен для изучения космоса, в нем светятся облака межзвездной пыли, и другие холодные объекты. Удобство миллиметрового диапазона ещё и в том, что в телескоп может наблюдать как самостоятельно, так и применяя технологию РСДБ. Пока наблюдения в миллиметровом диапазоне ведутся с Земли из высокогорных районов, например в Чилийских Андах расположен массив миллиметровых телескопов ALMA.


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

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

Сон

Сон это самый важный фактор среди тех, что влияют на мою продуктивность. Если бы мне пришлось выбирать между хорошим ночным отдыхом и другими пунктами моего списка я выбрал бы сон. У меня есть жёсткое правило не пить кофе после 16:00. Если я делаю себе кофе в 15:45, а потом забываю о нём до 16:05, я убираю его в холодильник и оставляю на следующий день. Незначительный рост эффективности вечерней работы не стоит серьёзного ухудшения моей продуктивности на следующий день.

В те дни, когда я перевозбуждён, мне обычно помогает успокоиться приём 0,3-0,9 мг мелатонина. Я, кроме того, считаю, что спать лучше в прохладной комнате. Мне кажется, что оптимальным вариантом является температура в 16-18C.

Кофе

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

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

Качество воздуха

Можно очень сильно улучшить продуктивность, понизив уровень CO₂ в воздухе рабочей комнаты. Под очень сильным улучшением я понимаю что-то в районе 20% или больше. Было одно исследование, где изучали воздействие уровня CO₂ на когнитивную деятельность людей. Одна группа работала в помещении с уровнем CO₂ в 1000 ppm, вторая с уровнем CO₂ в 600 ppm. Для справки на открытом воздухе уровень CO₂ составляет 400 ppm. Люди, работавшие в комнате с более высокой концентрацией CO₂, набрали в когнитивных тестах примерно на 20% меньше баллов, чем люди, которые дышали воздухом с более низким содержанием CO₂.

Я, пока не обзавёлся монитором качества воздуха, считал, что уровень CO₂ в моей рабочей комнате достаточно низок, так как я часто проветривал эту комнату. А оказалось, что уровень CO₂ в моей комнате составляет примерно 1200 ppm, что даже выше, чем в неблагополучной комнате вышеописанного исследования! Для того чтобы это исправить, я почти всегда, когда работаю, держу окно приоткрытым. Это позволяет поддерживать уровень CO₂ в моей комнате примерно на отметке в 450 ppm.

Физические упражнения

Я не очень спортивный человек. Правда. Каждый раз, когда я устраиваю тренировку, не занимавшись несколько дней, я думаю: Замечательные ощущения. Почему я не занимаюсь этим чаще?.

Честно говоря, хорошие упражнения, которые заставляют двигаться и поднимают частоту сердечных сокращений, способны творить чудеса. В идеале речь идёт о работе с тяжестями, но подойдут и другие упражнения. Я обнаружил, что игра в Beat Saber в течение часа бодрит меня так же, как пробежка. А ещё мне попалась статья, где речь идёт о том, что отсутствие физических нагрузок опаснее для здоровья, чем курение, диабет и заболевания сердца. В общем, у меня нет причин не заниматься спортом, и я сочувствую вам, если вы, как и я, занимаетесь спортом нерегулярно.

Работа в одиночестве

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

Удаление игр

Игра Valorant это мой наркотик. Она практически идеально мне подходит. По опыту я знаю, что могу провести изрядную часть дня, стреляя по врагам. Поэтому я сам для себя построил забор Шеллинга и напрочь удалил соответствующий раздел диска. Кто-то другой, вероятно, сможет лучше себя контролировать, не прибегая к столь радикальным мерам. А вот у меня однажды вышло так, что я очень надолго заигрался, потеряв массу ценнейшего времени. Поэтому лично я предпочитаю всеми силами избегать компьютерных игр.

Блокировка сайтов

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

Составление плана работ на день

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

Музыка

Я полагаю, что идеальный музыкальный жанр, который позволяет мне длительное время не терять сосредоточения, это Deep House. Вот один из моих любимых миксов (живое выступление на воздушном шаре!). Ещё я пользуюсь наушниками с шумоподавлением. Без них я просто не могу сосредоточиться. Даже если я работаю в тихой комнате, мне очень нравится невероятная тишина, которую обеспечивают такие наушники.

Питание

Я стараюсь не употреблять сахар и обработанные продукты, правда, делаю я это, в основном, ради здоровья, а не ради продуктивности. Я не обнаружил прямой взаимосвязи между моей едой и продуктивностью.

Выбор правильной задачи

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

Как вы относитесь к состоянию потока?

Сравнительно недавно Raspberry Pi Foundation выпустила плату Raspberry Pi Pico, основанную на микроконтроллере (Micro Controller Unit, MCU) RP2040. Эта плата привлекла большое внимание членов сообщества разработчиков различных электронных устройств. Появилось довольно много проектов, в которых используются программируемые модули ввода-вывода (Programmable I/O, PIO) Raspberry Pi Pico. Например, это проект PicoDVI, в котором конечные автоматы PIO используются для вывода DVI-сигнала.



Но с появлением Raspberry Pi Pico связано не только радостное возбуждение разработчиков электроники. Это событие заставило сообщество задаться важным вопросом о том, окажет ли появление платы какое-то ощутимое влияние на тех, кто пользуется STM32, SAM и другими микроконтроллерами, основанными на Cortex-M. Станет ли микроконтроллер RP2040 жизнеспособным выбором для некоторых из проектов, в которых используются похожие MCU? Учитывая то, что в состав RP2040 входит двухъядерный процессор ARM Cortex-M0+, кажется справедливой идея использования этого микроконтроллера там же, где применяются 32-битные MCU от ведущих производителей компонентов такого рода, в частности, от STMicroelectronics.

Сможет ли небольшой проект Raspberry Pi Foundation показать инженерам STM как надо делать микроконтроллеры, или создателям платы на RP2040 стоит пересмотреть некоторые из своих гипотез? Сложно ли будет портировать на RP2040 низкоуровневый код, рассчитанный на STM32?

Сложно ли перенести STM32-проект на RP2040?

Короче говоря, когда я обратила внимание на RP2040, мне подумалось, что будет интересно попытаться портировать на новый микроконтроллер мой C++-фреймворк для STM32. Правда, эта идея меня заинтересовала не из-за двухъядерного ARM Cortex-M0+. У меня есть двухъядерные микроконтроллеры STM32H7 (M4 и M7), которые, за счёт более совершенных характеристик, легко обойдут RP2040. Сильнее всего меня заинтриговали программируемые модули ввода-вывода RP2040, возникало такое ощущение, что они достойны того, чтобы познакомиться с ними поближе.


Плата Raspberry Pi Pico, основанная на RP2040 подключена к одноплатному компьютеру Raspberry Pi, играющему роль SWD-адаптера (оригинал)

Основываясь на опыте работы с STM32 я поняла, что смогу быстро портировать некоторые файлы, создав в репозитории проекта ветку RP, рассчитанную на другую архитектуру, и принявшись за дело. Ведь и в основном проекте, и в новой ветке код будет рассчитан на Cortex-M. Обычно работа с новым ARM-микроконтроллером заключается в том, чтобы найти даташит, справочное руководство и CMSIS-файлы для соответствующего устройства. А потом существующий низкоуровневый код можно легко адаптировать под новый подход к именованию периферийных устройств и под новую схему регистров, учитывая то, что фундаментальные компоненты нового и старого микроконтроллеров (SysTick, NVIC и так далее) ничем не отличаются.

Может, я поступила слишком опрометчиво, но я заказала плату Raspberry Pi Pico, даже не поинтересовавшись тем, есть ли для неё CMSIS-файлы, и даже не взглянув в справочное руководство по ней. Позже я, к своему удивлению, выяснила, что пока нет даже и речи о наличии CMSIS-файлов для Raspberry Pi Pico, или хотя бы о возможности взаимодействия RP2040 с другими устройствами из экосистемы Cortex-M. Но при этом SVD-файл для MCU RP2040 имеется в Pico SDK, а на основе этого файла можно создать заголовочный файл для устройства. Благодаря проекту cmsis-pi-pico в моём распоряжении, в итоге, оказалось рабочее решение.

Решение моей задачи можно было бы и упростить

Для того чтобы низкоуровневый программный проект завёлся бы на целевом MCU, при работе с STM32 нужно решить несколько задач. В них входит подготовка загрузочного кода, который выполняет некоторые простые настройки рабочей среды и таблицы векторов прерываний, содержащей адреса функций обработчиков прерываний.


Последовательность загрузки RP2040 (даташит RP2040, рисунок 15) (оригинал)

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

Первая сложность, которую нужно было преодолеть для того чтобы научиться работать с RP2040, заключалась в понимании особенностей цепочечного процесса загрузки микроконтроллера. Тут всё очень похоже на то, как в прошлом, на обычных компьютерах, была организована загрузка с дискет, или то, как устроена загрузка с HDD/SSD. А именно внешняя QSPI Flash ROM рассматривается MCU лишь как устройство, которое, возможно, содержит загрузочные данные. Загрузчик первой фазы загрузки интегрирован в MCU и располагается в ROM по адресу 0x0000 0000. Он обращается к интерфейсу QSPI и пытается загрузить из него 256 байт данных. Потом будет проверен CRC32-хеш этих данных. Если проверка пройдёт успешно, они будут признаны загрузчиком второй фазы загрузки.

Загрузчик второй фазы может решать множество задач, при этом некоторые задачи он должен решать в обязательном порядке. Этот процесс, реализованный в RP2040, если сравнить его с аналогичным процессом в некоторых знаменитых клонах STM32, тоже имеющих SPI ROM (вроде отличных клонов компании GigaDevice), не так понятен, не так хорошо документирован, не так прозрачен, как мог бы быть. В нём много такого, в чём можно запутаться.

Говорят, что хорошие художники копируют

У меня ушло достаточно много времени на то, чтобы понять, как подход к управлению тактированием периферийных устройств, принятый в STM32, соотносится с системной архитектурой RP2040. Я внимательно читала даташит RP2040 и всех вокруг спрашивала об этом. Как оказалось, RP2040-версия системы управления тактированием периферии называется RESETS. Эта система является полной противоположностью той, что применяется в STM32. А именно, нужно установить условие сброса периферийного блока в 0 для того чтобы включить его тактирование. Так, чтобы включить тактирование GPIO, нужно переключить бит 8 в RESETS_RESET (PADS_BANK0).


Функциональная схема GPIO-пина RP2040 (оригинал)

Когда я это поняла, я посмотрела раздел документации по GPIO-периферии (раздел 2.19). И кое-что тут же бросилось мне в глаза. А именно, то, что я там увидела, совершенно не похоже на то, как устроена практически вся GPIO-периферия, с которой я когда-либо сталкивалась. В частности, речь идёт о периферии STM32, AVR и SAM.

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

А теперь, когда я через всё это прошла, полагаю, можно будет просто переписать мой код, после чего он заработает на RP2040?

Причуды загрузки

Как уже было сказано, загрузчик второй фазы загрузки должен быть расположен в начале образа прошивки. Я считала, что это должен быть какой-то достаточно стандартный код, поэтому просто взяла готовый ASM-код, который выдал официальный Pico SDK, и использовала его при сборке примера Blinky. Добавив этот код к RP2040-порту моего проекта Nodate, я смогла без проблем собрать Blinky.

Запись результирующего ELF-бинарника в RP2040 стала ещё одним приключением. Дело в том, что на плате Raspberry Pi Pico нет встроенного SWD-адаптера, чего-то в духе ST-Link. А микроконтроллеру на двухъядерном Cortex-M нужен могоканальный SWD-адаптер. Единственным подобным устройством, которое было у меня под рукой, оказался адаптер, интегрированный в плату Nucleo-STM32H7. Поэтому я решила использовать кастомный форк OpenOCD, созданный Raspberry Pi Foundation. Его я запустила на Raspberry Pi.

После столь основательной подготовки мне удалось успешно прошить RP2040, но ничего не заработало. Беглая проверка вызвала у меня такое ощущение, что в ходе загрузки мне не удалось выйти за пределы исходного загрузчика и добраться до прошивки, находящейся в SPI ROM. Сейчас мне сложно дать ответ о причинах происходящего. Это могла быть проблема с ASM-кодом второй фазы загрузки, это могла быть ошибка в экспериментальных CMSIS-файлах RP2040, которые создавала не я. Это могло быть и что-то совершенно иное.

Продолжение следует?

Raspberry Pi Pico (оригинал)

После того, как я потратила много часов на то, чтобы завести RP2040 с использованием CMSIS-файлов и файлов загрузчика второй фазы загрузки, мне кажется, что можно немного отстраниться от ситуации и переоценить происходящее. А именно, с того момента, когда начинала формироваться моя точка зрения на Raspberry Pi Pico, в запросе по поводу CMSIS-файлов появились сведения о том, что официальные CMSIS-файлы, возможно, появятся в Pico SDK 1.2.0. Это довольно-таки приятно.

Полагаю, любому, кто хочет поближе познакомиться с RP2040, пользуясь инструментами, ставшими индустриальным стандартом, имеет смысл дождаться этого релиза Pico SDK. А после того, как в моём распоряжении окажутся официальные CMSIS-файлы, я, вероятно, начну с переделывания примера Nodate Blinky, а потом попробую поработать с PIO. Перспектива создавать собственные интерфейсы кажется мне весьма привлекательной. И хотя возможности Raspberry Pi Pico не так мощны, как возможности CPLD или FPGA, они, всё равно, способны лечь в основу интереснейших проектов.

Возникает такое ощущение, что авторы даташита для RP2040 (он, скорее, похож на смесь справочного руководства и даташита) иногда забывают о том, что в нём должно быть описание микроконтроллера, а не чего-то другого. В эти моменты он превращается в учебное руководство по Pico SDK. Хотя материалы этого даташита и способны принести пользу тем, кто стремится освоить Pico SDK, тем, кто хочет написать что-то своё, пользы от него, однозначно, меньше, чем от более привычного даташита.

Полагаю, тех, кто захочет написать для Raspberry Pi Pico что-то своё, не особенно порадуют такие особенности платы, как запутанная работа с GPIO-периферией, сложный процесс загрузки, необходимость в загрузчике второй фазы загрузки, непрозрачность внешней ROM. В общем тому, кому интересна плата Raspberry Pi Pico, пока приходится ориентироваться на официальный SDK.

Конечно, я не исключаю возможности того, что если некто как следует привыкнет к особенностям платы, то всё в ней будет казаться ему довольно-таки логичным и удобным. Или, возможно, решение проблем, подобных тем, с которыми столкнулась я, это лишь вопрос времени, вопрос встраивания поддержки RP2040 в стандартные наборы инструментов. В конце концов, каждый новый микроконтроллер перед его эффективным использованием приходится некоторое время изучать.

Пользовались ли вы Raspberry Pi Pico?

Мне на удивление часто приходится говорить о том, почему мне всё ещё нравится язык C, и о том, почему я плохо отношусь к C++. Поэтому я решил, что мне стоит об этом написать, а не снова и снова повторять одно и то же.



Как это обычно бывает у C-программистов, язык C не был ни моим первым языком, ни языком, после которого я уже не изучал ничего другого. Но мне всё ещё нравится этот язык, и когда мне нужно писать программы я выбираю именно его. Правда, в то же время, я стараюсь быть в курсе того, что происходит в мире современных (и не очень) языков программирования. Я слежу за тенденциями в этой сфере и пишу собственный хобби-проект, связанный с мультимедийными технологиями, на Rust. Почему же я до сих пор не поменял C на что-то более современное? И при чём тут C++?

Почему C это не самый лучший язык программирования?

Сразу скажу то, что, пожалуй, и так все знают: нет такого понятия, как самый лучший язык программирования. С каждым языком связан набор задач, для решения которых он подходит лучше всего. Например, хотя и можно заниматься трассировкой лучей в Excel, применяя VBA, лучше будет делать это с использованием более подходящего языка. Поэтому полезно знать об ограничениях языков программирования чтобы не жаловаться на то, что веб-серверы не пишут на Fortran, и на то, что почти нигде Perl или C++ не используется в роли внутренних скриптовых языков. C может считаться не очень хорошим языком по причинам, которые я перечислю ниже (это помимо того, что язык этот просто очень старый и того, что его нельзя назвать активно развивающимся языком, но это дело вкуса).

В синтаксисе C имеются неоднозначные конструкции (например, символ * может играть роль обычного оператора умножения, может применяться в виде унарного оператора разыменования, или может использоваться при объявлении указателей; а радости работы с typedef достойны отдельной статьи).

Этот язык не является безопасным. Например в C-программах довольно часто встречаются ошибки, связанные с обращением к элементам массивов, которые находятся за пределами границ массивов. В языке нет проверок на ошибки такого рода, производимых во время выполнения программы. А вот, например, в Borland Pascal, не говоря уже о более современных языках, такие проверки есть (это плюс, даже если подобные возможности можно, пользуясь параметрами компиляции, отключить ради повышения производительности). А использование в языке указателей ещё сильнее усложняет задачу программиста по поддержанию кода в хорошем состоянии. И, кроме того, C имеет и некоторые другие неприятные особенности, вроде возможности вызова функции без объявления прототипа, в результате чего функции легко можно передать аргумент неправильного типа.

У C довольно-таки скромная стандартная библиотека. В некоторых других языках программирования могут даже иметься стандартные веб-серверы (или, как минимум, всё, что нужно для создания таких серверов), а в стандартной библиотеке C нет даже описаний контейнеров.

Почему я, несмотря на все недостатки C, пользуясь именно этим языком?

Причина, по которой мне всё ещё нравится C, заключается в том, что это простой язык. Простой в смысле того, что он легко позволяет мне описывать имеющиеся у меня идеи, и в смысле того, что я знаю о том, чего можно от него ожидать.

Например, если нужно получить значение элемента массива, имея два смещения, одно из которых может быть отрицательным числом, то при программировании на C можно воспользоваться такой конструкцией: arr[off1 + off2]. А при использовании Rust это уже будет arr[((off1 as isize) + off2) as usize]. C-циклы часто короче, чем идиоматичные механизмы Rust, использование которых предусматривает комбинирование итераторов (конечно, обычными циклами можно пользоваться и в Rust, но это не приветствуется линтером, который всегда рекомендует заменять их итераторами). И, аналогично, мощными инструментами являются memset() и memmove().

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

Если описать это всё, прибегнув к аналогии с автомобилями, то окажется, что C похож на спортивную машину с механической коробкой передач, позволяющую выжать из двигателя всё, что только возможно. Но водитель легко может повредить и коробку передач, и даже двигатель, если перемудрит со сцеплением. Да и с дороги можно вылететь, если слишком сильно надавить на педаль газа. Но при этом, в сравнении с машинами, имеющими автоматическую трансмиссию, на колёса поступает больше мощности двигателя. Водитель лучше понимает то, чего можно ждать от автомобиля. На ручной машине можно делать такие вещи, которых не сделаешь на автомате (из-за того, что водителю, чтобы сделать что-то необычное, придётся бороться с автоматизированными системами управления автомобилем).

При чём тут C++?

Если говорить о C++, то хочу сразу сказать, что я не отношусь к тем, кто ненавидит этот язык. Если вы этим языком пользуетесь и он вам нравится я ничего против этого не имею. Я не могу отрицать того, что C++, в сравнении с C, даёт нам два следующих преимущества. Во-первых это улучшение структуры программ (это поддержка пространств имён и классов; в Simula, в конце концов, есть хоть что-то хорошее). Во-вторых это концепция RAII (если описать это в двух словах, то речь идёт о наличии конструкторов для инициализации объектов при их создании и о наличии деструкторов для очистки ресурсов после уничтожения объектов; а если глубже разработать эту идею, то можно прийти к понятию времени жизни объекта из Rust). Но, в то же время, у C++ есть несколько особенностей, из-за которых мне этот язык очень и очень не нравится.

Это, прежде всего склонность языка постоянно вбирать в себя что-то новое. Если в каком-то другом языке появится какая-нибудь возможность, которая станет популярной, она окажется и в C++. В результате стандарт C++ пересматривают каждые пару лет, и при этом всякий раз в него добавляют новые возможности. Это привело к тому, что C++ представляет собой монструозный язык, которого никто не знает на 100%, язык, в котором одни возможности часто дублируют другие. И, кроме того, тут нет стандартного способа указания того, возможности из какой редакции C++ планируется использовать в коде. В Rust это поддерживается на уровне единицы компиляции. В IIRC C++ для той же цели предлагалась концепция эпох, но эта затея не удалась. И вот одно интересное наблюдение. Время от времени мне попадаются новости о том, что кто-то в одиночку (и за приемлемое время) написал рабочий компилятор C. Но я ни разу не встречал похожих новостей о компиляторе C++.

Вторая особенность C++, из-за которой мне не нравится этот язык, заключается в том, что это, на самом деле, не просто смесь нескольких языков. Это, кроме того, мета-язык, иначе говоря язык, в котором используются шаблоны. Я понимаю для чего это создано, согласен с тем, что это лучше, чем препроцессор C для типонезависимого кода. Но, на самом деле, это приводит к появлению некрасивого громоздкого кода. Это означает переход от идеи заголовочный файл содержит объявления, а компилируемый код функционал к идее заголовочный файл содержит весь код, используемый в проекте, в состав которого входит этот файл. Мне не нравится, когда код долго компилируется, а этот подход ведёт к увеличению времени компиляции проектов.

И, наконец, я мог бы вообще не обращать внимания на C++, если бы этот язык не был бы связан с C и не оказывал бы на C плохое влияние. Я не говорю о ситуации, когда, говоря о C и C++, их объединяют, упоминая как C/C++, и считая, что тот, кто знает C, знает и C++. Я имею в виду связь между языками, которая оказывает влияние и на стандарты, и на компиляторы. С одной стороны C++ основан на C, что придало C++, так сказать, хорошее начальное ускорение. А с другой стороны сейчас C++, вероятно, лучше смотрелся бы без большей части своего C-наследия. Конечно, от него пытаются избавиться, называя соответствующие конструкции устаревшими, но C-фундамент C++ никуда пока не делся. Да и будет ли популярным, скажем, некий С++24, вышедший в виде самостоятельного языка, основанного на C++21 и лишённого большей части устаревших механизмов? Не думаю.

Воздействие компиляторов C++ на C

Вышеописанная связь C и C++ приводит к тому, что к C относятся как к C++, лишённому некоторых возможностей. Печально известным примером такого восприятия C является C-компилятор Microsoft, разработчики которого не позаботились о поддержке возможностей C99 до выхода версии компилятора 2015 года (и даже тогда разработчики придерживались стратегии bug-for-bug compatibility, когда в новой реализации чего-либо воспроизводят старые известные ошибки; делалось это для того, чтобы пользователи компилятора не были бы шокированы, внезапно обнаружив, что вариадические макросы вдруг там заработали). Но тот же подход можно видеть и в стандартах, и в других компиляторах. Эти проблемы связаны друг с другом.

Принципиальная проблема тут заключается в том, что и стандарт C, и стандарт C++ создаются с учётом сведений, получаемых от разработчиков компиляторов, а это, в основном, C++-разработчики (и иногда возникает такое ощущение, что они ничего не знают о настоящем программировании, и полагают, что всё должно укладываться в их точку зрения, но это тема для отдельного разговора). Я не слежу за процессом работы над стандартом, но я почти уверен, что самые неприятные аспекты C99 и более поздних версий стандарта стали результатом воздействия разработчиков компиляторов. Причём, их видение ситуации влияет не только на C++, где в этом видении есть какой-то смысл, но воздействует и на C ради упрощения компиляторов.

Я, конечно, говорю, о неопределённом поведении, и о том, как оно рассматривается компиляторами. Эта тема стала популярным пугалом (код полагается на способ представления чисел с дополнением до двух; в результате в нём имеется неопределённое поведение и компилятор может выбросить оптимизировать целый блок кода!).

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

• Поведение, определяемое архитектурой системы (то есть то, что зависит от архитектуры процессора). Сюда, в основном, входят особенности выполнения арифметических операций. Например, если я знаю, что целевая машина использует для представления чисел дополнение до двух (нет, это не CDC 6600), то почему компилятор (который, как представляется, тоже знает об особенностях целевой архитектуры) должен считать, что система будет вести себя иначе? Ведь тогда он сможет лучше выполнять некоторые теоретически возможные оптимизации. То же применимо к операциям побитового сдвига. Если я знаю о том, что в архитектуре x86 старшие биты, выходящие за пределы числа, отбрасываются, а на ARM отрицательный сдвиг влево это сдвиг вправо, почему я не могу воспользоваться этими знаниями, разрабатывая программу для конкретной архитектуры? В конце концов, то, что на разных платформах целые числа имеют разные размеры в байтах, считается вполне приемлемым. Компилятор, обнаружив нечто, рассчитанное на конкретную платформу, может просто выдать предупреждение о том, что код нельзя будет перенести на другую платформу, и позволить мне писать код так, как я его писал.
• Неочевидные приёмы работы с указателями и каламбуры типизации. Такое ощущение, что плохое отношение к подобным вещам возникло лишь ради потенциальной возможности оптимизации кода компиляторами. Я согласен с тем, что использование memcpy() на перекрывающихся областях памяти может, в зависимости от реализации (в современных x86-реализациях копирование начинается с конца области) и от относительного расположения адресов, работать неправильно. Разумно будет воздержаться от подобного. А вот другие ограничения того же плана кажутся мне менее оправданными. Например запрещение одновременной работы с одной и той же областью памяти с использованием двух указателей разных типов. Я не могу представить себе проблему, возникновение которой может предотвратить наличие подобного ограничения (это не может быть проблема, связанная с выравниванием). Возможно, сделано это для того чтобы не мешать компилятору оптимизировать код. Кульминацией всего этого является невозможность преобразования, например, целых чисел в числа с плавающей запятой с использованием объединений. Об этом уже рассуждал Линус Торвальдс, поэтому я повторяться не буду. С моей точки зрения это делается либо для улучшения возможностей компиляторов по оптимизации кода, либо из-за того, что этого требует C++ для обеспечения работы системы отслеживания типов данных (чтобы нельзя было поместить экземпляр некоего класса в объединение, а потом извлечь его как экземпляр совсем другого класса; это тоже может как-то повлиять на оптимизации).
• Поведение кода, определяемое реализацией (то есть поведение, которое не в точности отражает то, что предписано стандартом). Мой любимый пример подобной ситуации это вызов функции: в зависимости от соглашения о вызове функций и от реализации компилятора аргументы функций могут вычисляться в совершенно произвольном порядке. Поэтому результат вызова foo(*ptr++, *ptr++, *ptr++) неопределён и на подобную конструкцию не стоит полагаться даже в том случае, если программисту известна целевая архитектура, на которой будет выполняться код. Если аргументы передаются в регистрах (как в архитектуре AMD64) компилятор может вычислить значение для любого регистра, который покажется ему подходящим.
• Полностью неопределённое поведение кода. Это тоже такой случай, когда сложно спорить со стандартом. Пожалуй, самый заметный пример такого поведения кода связан с нарушением правила, в соответствии с которым значение переменной в одном выражении можно менять лишь один раз. Вот как это выглядит в одном знаменитом примере: i++ + i++. А вот пример, который выглядит ещё страшнее: *ptr++ = *ptr++ + *ptr++е.

C++ это язык более высокого уровня, чем C. В то время, как в C++ имеется большинство возможностей C, использовать эти возможности не рекомендуется. Например, вместо прямого преобразования типов надо применять reinterpret_cast<>, а вместо указателей надо применять ссылки. От С++-программистов не ждут того, что они будут понимать низкоуровневый код так же хорошо, как C-программисты (это, конечно, лишь средняя температура по больнице, в реальности всё зависит от конкретного программиста). И всё же, из-за того, что существует очень много C++-программистов, и из-за того, что C и C++ часто воспринимают как C/C++, C-компиляторы часто расширяют в расчёте на поддержку ими C++ и переписывают на C++ для того чтобы упростить реализацию сложных конструкций. Это произошло с GCC, и того, кто начнёт отлаживать с помощью GDB С++-код, находящийся в .c-файлах, ждёт много интересного. Грустно то, что для того чтобы скомпилировать код C-компилятора нужен C++-компилятор, но, чему нельзя не радоваться, всё ещё существуют чистые C-компиляторы, вроде LCC, PCC и TCC.

Итоги

В итоге хочу сказать, что люблю язык C за то, что он занимает промежуточную позицию среди других языков программирования. Он позволяет без труда делать всякие низкоуровневые вещи, вроде манипуляций с содержимым памяти, но при этом даёт нам приятные возможности, характерные для языков высокого уровня (хотя и не мешает программисту делать то, что ему нужно). А моя стойкая неприязнь к C++ основана на архитектурных решениях, принятых в ходе развития этого языка (хотя тут скорее можно говорить не о чётко спланированном развитии языка, а о том, что нечто появляется в языке по воле случая). Не нравится мне и то, что C++ влияет на стандарт C и на компиляторы для C, что немного ухудшает тот язык, который я люблю.

Но, по крайней мере, нельзя заменить C90 на какой-нибудь C90 Special Edition и сделать вид, что C90 никогда не существовало.

Как вы относитесь к языку C?

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

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

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

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

Фиктивная наука
На данный момент практикуется ряд приемов, которые угрожают подрывом легитимности научных исследований в целом. К ним относятся выдумывание авторов, а также указание соавторства никак не связанных с исследованием ученых и даже более гнусные приемы вроде заваливания журналов материалами из низкосортного бреда, сгенерированного ИИ.

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

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

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

Camille Nos

Часть этой проблемы смоделирована намеренно. К примеру, Camille Nos никак не связано с ИИ, но все равно заслуживает упоминания. Созданное в марте 2020 года, Nos уже выступило соавтором более, чем 180 работ в таких разносторонних областях, как астрофизика, компьютерная наука и биология.

Я использовал оно, потому что Nos не является реальным человеком. На деле это псевдо-личность, созданная французским движением в защиту науки RogueESR. В качестве первого имени было взято французское гендерно-нейтральное Camille, а в качестве фамилии слияние греческого слова , означающего разум/познание, и французского слова nous, означающего мы.

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

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

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


Усилия сообщества должны быть стандартизированы, но пока для этого нет системы

Указание авторов там, где они не участвовали

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

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

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

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


Когда речь идет о написании научных работ, то путь мысли старого-доброго человеческого ума пока еще превосходит налучший ИИ

Алгоритмы плохие писатели

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

Аналогичным образом в 2005 году трое студентов, изучавших компьютерные науки, решили приколоться над научным сообществом, разработав программу SCIgen. Она генерирует абсолютно бессмысленные работы с графами, иллюстрациями и цитатами, приправленные множеством заумных слов из компьютерной науки. Одна из таких статей даже была принята к участию в конференции. Более того, в 2013 году различными издателями было отозвано 120 работ, когда вскрылось, что написала их SCIgen. За 2015 год сайт программы все еще зарегистрировал около 600 000 посещений.

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

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

Конечно, это не все, и на горизонте маячит еще один вопрос: Как долго написанием научных работ будут заниматься только люди? Может ли случиться так, что через 10 или 20 лет ИИ-алгоритмы станут способны автоматически анализировать обширные объемы литературы и делать собственные заключения в новой работе, соответствующей высшим научным стандартам? Как тогда мы будем отдавать должное этим алгоритмам или их создателям?

Хотя сегодня мы пока имеем дело с намного более простыми вопросами: Как выявить работы, написанные относительно несложными алгоритмами, и не несущие никакой смысловой нагрузки? Что с ними в итоге делать? Помимо добровольных усилий и принуждения лже-авторов отзывать свои работы, научное сообщество имеет поистине мало ответов на эти вопросы.


Большинство журналов остро нуждаются в обновлении систем безопасности для отслеживания фиктивных работ

Противодействие фальшивой науке

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

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

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

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

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

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

Именно поэтому в данном случае для отслеживания бумажных фабрик и определения идентичности всех их авторов необходим коллективный подход.

Помимо науки: все больше фейковых новостей

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

К примеру, в различных консервативных СМИ было очевидно, что авторами обзорных статей являются фейковые журналисты. Их фотографии генерировались ИИ-алгоритмами, а аккаунты LinkedIn и Twitter были абсолютно вымышленными, и до сих пор неизвестно, кто на самом деле стоял за этими статьями.

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

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

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

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

Хочется верить, что к тому времени мы уже достигнем согласия на тему того, как противостоять фейковому контенту и фейковым исследованиям.

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



Изображения обычно имеют большие размеры. Даже очень большие. В большинстве случаев CSS- и JavaScript-ресурсы, необходимые для обеспечения работоспособности страниц это мелочь в сравнении с тем объёмом данных, который нужно передать по сети для загрузки изображений, используемых на страницах. Медленные изображения могут повредить показателям Core Web Vitals сайта, могут оказать воздействие на SEO и потребовать дополнительных затрат на трафик. Изображения это обычно тот самый ресурс сайта, который оказывает решающее воздействие на показатель Largest Contentful Paint (LCP) и на задержки загрузки сайта. Они способны увеличить показатель Cumulative Layout Shift (CLS). Если вы не знакомы с этими показателями производительности сайтов почитайте о них в Definitive Guide to Measuring Web Performance.

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

1. Формат изображений

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

Есть одно хорошее общее правило, касающееся выбора форматов для изображений. Заключается оно в том, что для фотографий рекомендуется использовать формат JPG, а для рисунков, схем и прочего подобного формат PNG. Вот пример.


Изображения ленивца

Слева мы можем видеть фото нашего товарища-ленивца Сэма. Эта картинка в формате JPG занимает всего лишь 32,7 Кб. А если то же самое изображение преобразовать в формат PNG размер графического файла увеличится более чем вдвое до 90,6 Кб!

Справа находится рисунок со всё тем же Сэмом. Этот рисунок лучше всего хранить в формате PNG. Так он занимает всего 5,5 Кб. А если преобразовать его в JPG, то его размер подскочит до 11,3 Кб.

Обратите внимание: всё то, что фотографиями не является, обычно занимает меньше места, чем фотографии. Не забывайте об этом, проектируя свои веб-страницы.

Существует, конечно, ещё много графических форматов! Если у вас имеется некое векторное изображение (состоящее из всяческих линий и геометрических фигур), то вам лучше всего подойдёт формат SVG. Более новые браузеры поддерживают и более современные графические форматы вроде AVIF и WebP. Их использование для хранения подходящих изображений позволяет добиться ещё более серьёзного уменьшения размеров графических файлов.

2. Отзывчивые изображения и их пиксельные размеры

Не все посетители сайта будут просматривать его в одних и тех же условиях. У кого-то имеется огромный монитор шириной в 1600 пикселей. А кто-то смотрит сайт на планшете с шириной экрана в 900 пикселей, или на телефоне с экраном шириной в 600 пикселей. Если на сайте применяется изображение шириной в 1200 пикселей это будет означать, что при просмотре такого сайта на устройствах с небольшими экранами сетевые и другие ресурсы будут тратиться впустую, так как размер таких изображений при выводе на экран, всё равно, будет уменьшен.


Просмотр сайта на устройствах с разными экранами

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

<img src="picture-1200.jpg"srcset="picture-600.jpg  600w,picture-900.jpg  900w,picture-1200.jpg 1200w"sizes="(max-width: 900px) 100vw, 1200px"alt="my awesome picture" height="900" width="1200" />

В данном случае ширина базового изображения составляет 1200 пикселей. Оно, кроме того, является изображением, записанным в атрибут src тега и используемым по умолчанию. В srcset описаны 3 варианта изображения шириной в 600, 900 и 1200 пикселей. В sizes используются медиа-запросы CSS, позволяющие дать браузеру подсказку, касающуюся видимой области, доступной для вывода изображения. Если ширина окна меньше 900 пикселей место, где будет выведено изображение, займёт всю его ширину 100vw. В противном случае место для вывода изображения никогда не окажется шире 1200 пикселей.

Большинство инструментов для работы с изображениями, вроде Photoshop, Gimp и Paint.NET, умеют экспортировать изображения в различных размерах. Стандартные системные графические программы тоже, в определённых пределах, способны решать подобные задачи. А если надо автоматизировать обработку очень большого количества изображений возможно, есть смысл взглянуть на соответствующие инструменты командной строки вроде ImageMagick.

Скрытие изображений при просмотре сайта на мобильных устройствах

При работе над некоторыми страницами может быть принято решение, в соответствии с которым изображения, имеющиеся на этих страницах, не будут выводиться при просмотре их на мобильных устройствах. Дело может быть в том, что эти изображения просто слишком велики. При этом установка для изображения стиля display:none особой пользы не принесёт из-за того, что браузер, всё равно, будет тратить время и трафик на загрузку изображения. Вместо этого можно воспользоваться атрибутом sizes, сообщив с его помощью браузеру о том, в каких условиях изображение выводиться не будет.

<img src="picture-1200.jpg"srcset="picture-600.jpg  600w,picture-900.jpg  900w,picture-1200.jpg 1200w"sizes="(max-width: 600px) 0, 600px"alt="my awesome picture" height="900" width="1200" />

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

3. Качество изображений

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


Исходное PNG-изображение с прозрачными участками имеет размер 57 Кб. Такое же изображение, но сжатое, имеет размер 15 Кб.

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

4. Встраивание изображений в веб-страницы

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

Код изображений встраивают в код страниц, преобразуя данные изображений в base64-строки и помещая то, что получится, в атрибут src тега . Выглядеть это может так, как показано на следующем рисунке.


Изображение, встроенное в страницу

Может, выглядит это и странновато, но тут перед нами так называемый Data URL. Такие URL пользуются полной поддержкой всех браузеров. В атрибуте src сказано, что соответствующие данные надо воспринимать как PNG-изображение в кодировке base64. После описания изображения идёт набор символов, представляющих содержимое этого изображения. В данном случае это маленькая красная точка.

Google часто использует встроенные в страницу изображения при выводе результатов поиска. Это одна из причин того, что поиск Google кажется таким быстрым.

Вот материал, в котором проанализированы подходы к повышению производительности веб-ресурсов, используемые Google. Возможно, вы найдёте тут что-то такое, что вам пригодится.

А вот удобный веб-инструмент для преобразования изображений в формат base64.

5. Ленивая загрузка изображений

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

Вместо того, чтобы заставлять браузер сразу загружать все изображения, можно посоветовать ему немного полениться. Ленивая загрузка изображений это такой подход к работе с изображениями, когда браузеру предлагают загружать изображения только тогда, когда они могут понадобиться пользователю. Применение ленивой загрузки изображений способно оказать огромное положительное влияние на показатель Largest Contentful Paint (LCP), так как благодаря этому браузер, при загрузке страницы, может уделить основное внимание только самым важным изображениям.

В спецификации HTML есть атрибут loading, которым можно воспользоваться для организации ленивой загрузки изображений, но он пока имеет статус экспериментального. А Safari ещё даже его не поддерживает. В результате о его широком использовании говорить пока нельзя. Но, к счастью, ленивую загрузку изображений можно организовать средствами JavaScript.

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

var lazyEls = [].slice.call(document.querySelectorAll("[data-src]"));var lazyObserver = new IntersectionObserver(function(entries) {entries.forEach(function(entry) {if (entry.isIntersecting) {var el = entry.target;var src = el.getAttribute("data-src");if (src) { el.setAttribute("src", src); }lazyObserver.unobserve(el);}});});lazyEls.forEach(function(el) {lazyObserver.observe(el);});

Тут, для определения того момента, когда надо загружать изображение, используется объект IntersectionObserver. Когда наступает нужный момент содержимое атрибута data-src копируется в атрибут src и изображение загружается. Тот же подход можно применить к атрибуту srcset и воспользоваться им при работе с любым количеством изображений.

Пользуются этим, переименовывая атрибут src в data-src.

<img data-src="picture-1200.jpg"loading="lazy" class="lazy" />

В этом фрагменте HTML-разметки используется и экспериментальный атрибут loading, и обычный атрибут, который можно использовать с некоей JavaScript-функцией или с какой-нибудь библиотекой.

Настройка размеров области, которую займёт изображение

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

Избежать сдвига макета страницы можно, указав атрибуты height и width тега <img>.

<img data-src="picture-1200.jpg"loading="lazy" class="lazy"width="1200" height="900" />

Обратите на то, что значения атрибутов height и width это не 1200px и 900px. Это просто 1200 и 900. И работают они немного не так, как можно было бы ожидать. Размер соответствующего изображения не обязательно будет составлять 1200x900 пикселей. Этот размер будет зависеть от CSS и от размеров макета страницы. Но браузер, благодаря этим атрибутам, получит сведения о соотношении сторон изображения. В результате, узнав ширину изображения, браузер сможет правильно настроить его высоту.

То есть, например, если макет страницы имеет в ширину всего 800px, то браузер, не загружая изображение, будет знать о том, что ему надо зарезервировать 600px вертикального пространства для вывода изображения с правильным соотношением сторон.

Итоги

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

Как вы оптимизируете изображения, используемые в ваших веб-проектах?

Приветствую всех читателей Habr! В своей сегодняшней статье, хочу рассказать вам о своем новом DIY беспроводном устройстве датчике качества воздуха. Помимо оценки качества воздуха, датчик может оценивать уровень освещенности в помещении, температуру, влажность и атмосферное давление, на основе данных атмосферного давления, устройство может предсказывать прогноз погоды. Это полностью открытый проект.

Внутреннее устройство

Датчик работает на микроконтроллерах nRF52, были разработаны 4 версии плат датчика под радиомодули nRF52 разных производителей. Одна основная и еще три расширенные версии (пояснения будут чуть ниже по тексту).

Используемые в проекте модели радиомодулей:

• основной MINEW MS88SF3 (nRF52833, nRF52840)
• дополнительные: MINEW MS50SFA1 (nRF52810, nRF52811), MINEW MS50SFA2 (nRF52832), EBYTE E73-2G4M08S1C (nRF52840) и EBYTE E73-2G4M08S1E (nRF52833)

Используемые в проекте сенсоры:

• сенсор качества воздуха в помещении для измерения ЛОС SGP40
• сенсор давления, температуры и влажности BME280
• сенсор освещенности MAX44009

Позднее, из-за проблем с производством электронных компонентов и невероятном росте цен на многие компоненты, в проект были добавлены сенсоры BMP280 и SHTC3 которые по функционалу способны заменить сенсор BME280. По этой причине, были сделаны три дополнительные модификации плат, так же добавлена поддержка дополнительных радиомодулей, добавлена защита от переполюсовки, доработан дизайн плат.

Устройство может выводить данные на экране и передавать данные в системы Умного Дома, так же может работать в режиме без сети.

Для вывода информации использовался e-ink дисплей со сверхнизким потреблением и диагональю 2.13 дюймов компании WaveShare.



Характеристики дисплея:

• Разрешение: 250x122
• Диапазон рабочих температур: 0 50 C
• Потребление в рабочем режиме: 3мА
• Потребление в режиме глубокого сна: 1мкА
• Минимальное время обновления экрана: 0.3 сек.

В ближайшее время в проект будет добавлена поддержка дисплея DES e-Ink 2.13 c рабочим температурным режимом -20C~60C (что такое DES).
..upd Пока статья писалась сделал драйвер, дисплей протестирован, в морозильнике работает :), из минусов разрешение 212х104, но зато морозов не боится, в общем рабочий вариант.


Основная версия PCB датчика:

Дополнительные версии:



Основным сенсором в данном проекте является сенсор качества воздуха в помещении SGP40. Можно сказать что это новинка на рынке от компании Sensorion c весьма неплохими характеристиками.


Сенсор измеряет общую концентрации летучих органических веществ (TVOC). В сравнении с предыдущим датчиком этой компании SGP30 потребление было значительно снижено, 48 мА при измерении у SGP30 и 2.6мА у SGP40. Правда предыдущий датчик мог отдавать уже готовые значения VOC и эквивалента СО2, в то время как новинка отдает сырые данные которые в дальнейшем надо обрабатывать на стороне МК при помощи поставляемой с датчиком библиотеки с алгоритмом расчета качества воздуха. Даташит на датчик SGP40.


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

Схема устройства:

Передача датчиком данных с сенсоров в системы Умного Дома реализована на открытом проекте MySENSORS.

Функционал датчика

Устройство, при подаче питания, осуществляет попытку поиска сети, если сеть не найдена, то устройство переходит в основной режим работы без работы в сети (не шлет данные), но периодически делает короткие запросы на поиск сети(~раз в 2 часа). Интервал опроса сенсора SGP40 3 секунды, чтение остальных сенсоров, отправка данных, основное обновление экрана раз в 1 минуту. Обновление экрана и отправка данных(если сеть доступна) происходит при изменении данных уровня качества воздуха (TVOC) на 10 единиц, температуры на 0.5C, влажности на 5%, давления на 1 единицу, при изменении уровня освещенности на 10 люкс, при изменении прогноза по погоде. Интервал опроса батарейки задается пользователем в интервале от 1 часа до 24 часов, по умолчанию опрос один раз в 6 часов.
Так же есть дополнительная подпрограмма для обновления экрана и отправка данных при резком повышении уровня TVOC на 30 единиц, интервал проверки раз в 6 секунд.

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

Доступный функционал кнопки меню:

1. Инверсия экрана
2. Отправка презентации
3. Вход в режим конфигурации внешними командами по радио
4. Поиск сети
5. Сброс устройства

Так же, помимо кнопки меню, датчик может настраиваться внешними командами из интерфейса УД. Для этого необходимо активировать нужный пункт меню конфигурация датчика нажатием кнопки меню. После активации режима конфигурации, датчик перейдет в режим прослушивания на 20 секунд. В этот интервал необходимо отправить команду. Внешними командами можно настроить интервал проверки батарейки, изменить вывод информации на экран в инверсии, выбор режима работы: LP (чтение сенсора SGP40 раз в 3 секунды) или ULP (чтение сенсора SGP40 раз в 5 секунд).

Датчик умеет анализировать данные атмосферного давления и рассчитывать по ним прогноз погоды, выводить на экран данные о прогнозе погоды и отправлять эти значения в УД. Описание алгоритма расчета прогноза погоды (NXP Application Note 3914 | John B. Young)

На экране рядом с каждым типом данных выводится индикация направления изменения значений.



Для компиляции нужной версии ПО необходимо сконфигурировать файл aConfig.h.

//#define MY_DEBUG#define LANG_RU // If this is not used the English localization will be displayed.#ifndef LANG_RU#define LANG_EN#endif#define SN "eON Air Quality Sensor"#define SV "0.99"#define MY_RADIO_NRF5_ESB#define MY_NRF5_ESB_PA_LEVEL (0x8UL)//#define MY_PASSIVE_NODE//#define MY_NODE_ID 151//#define MY_NRF5_ESB_MODE (NRF5_1MBPS)#define MY_NRF5_ESB_MODE (NRF5_250KBPS)#define ESPECIALLY#define SEND_RESET_REASON#define MY_RESET_REASON_TEXT

Потребление датчика в режиме сна составляет в среднем 33мкА (смотрите даташит на SGP40), в режиме считывания сенсоров и обновления экрана 4мА(среднее), в режиме передачи данных 8мА(среднее), время передачи одного сообщения 10мc (идеальные условия).
Датчик работает от батарейки CR2477 (950мА), среднее расчетное время работы устройства 1 год(зависит от конфигурации прошивки, установленных сенсорах на устройстве, больше сенсоров больше данных нужно будет отправлять, а передача по воздуху это основной потребитель), данных о реальном сроке работы пока нет, устройство пока работает 2 месяца.



Модели разработанного корпуса датчика я печатал на FDM 3D принтере, что бы добиться более или менее приличного вида, корпус после печати шлифовался и полировался. На задней крышке корпуса можно установить магниты.



GitHub проекта github.com/smartboxchannel/

В файле readme находится инструкция по установке и настройке среды для редактирования и компиляции ПО для датчика.

OPEN SOURCE HARDWARE CERTIFICATION
OSHWA UID: RU000004


В завершении, уже как обычно, сделаю небольшой фото анонс проектов с которыми в скором времени поделюсь и о которых расскажу (Датчики влажности почвы Zigbee, Уличный датчик температуры и влажности Zigbee Long Range, Датчик качества воздуха bme680 c e-ink3.7).


Если вам интересно все, что связано с DIY, вы являетесь DIY разработчиком или хотите только начать, вы заинтересованы в использовании DIY девайсов, а так же хотите узнавать первыми о моих проектах, то приглашаю всех в телеграм чат DIYDEV.

Если вы как и я, хотите понять что такое Zigbee, попытаться сделать свои первые DIY Zigbee устройства, то приглашаю вас в чат для разработчиков zigbee девайсов/прошивок ZIGDEV

Всем, кто хочет делать устройства, начать строить автоматизацию своего дома, я предлагаю познакомиться с простым в освоении протоколом Mysensors телеграм-чат MySensors

А тех кто смотрит в будущее IOT приглашаю в телеграм-чат Open Thread (Matter, Project CHIP). (что такое Thread?, что такое Matter?)

Спасибо за внимание, всем добра!

Они отличаются тем, что у гибридных (Ca+, Ca/Sb) свинцовый сплав положительных решёток легирован сурьмой, а отрицательных кальцием, тогда как у кальциевых (Ca/Ca) те и другие кальцием. В результате, выделение газов происходит при разных напряжениях заряда, и токи окончания заряда при этих напряжениях тоже разные.

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


Обманывают ли нас производители, или мы не всегда учитываем влияния конструкции на электрохимические процессы? Проведём серию испытаний пары аккумуляторных батарей (АКБ), изображённых на фото.

В сегодняшнем эксперименте участвует батарея 6СТ-64L Тюмень PREMIUM СаСа 64 А*ч. Кальциевая технология освоена Тюменским аккумуляторным заводом (с лосем на логотипе) в 2019 году.


Аккумулятор полностью разряжен, плотность электролита 1.07 граммов на кубический сантиметр. Ареометр утонул ниже шкалы. (Выводим тюменского лося на чистую воду, шутка для тех, кто знает: электролит полностью разряженного свинцово-кислотного аккумулятора вода, потому что вся кислота в намазках, в виде сульфатов свинца).


Тестер показывает уровень заряженности (state of charge, SoC) 0%, внутреннее сопротивление 9.77 мОм, ток холодной прокрутки (ТХП) 283 из 620 А по стандарту EN, напряжение разомкнутой цепи (НРЦ, оно же электродвижущая сила ЭДС без нагрузки) 11.53 В, и предписывает зарядить аккумулятор.


Заряжать будем зарядным устройством (ЗУ) Кулон-720. Настроим следующие параметры заряда: предзаряд до 12 В 2 А, основной заряд 14.7 В 6.4 А 24 часа, хранение 13.2 В 0.5 А.


Дозаряд у Кулона-912 реализован качелями, так принято называть управление двухпороговым компаратором или компаратором с гистерезисом по напряжению. Когда напряжение на клеммах достигает верхней планки, ЗУ отключает зарядный ток. Когда поляризация релаксирует, напряжение на клеммах снижается, и при касании нижней планки ЗУ возобновляет подачу тока. Продолжаются эти циклы до превышения максимального времени. Установим пороги 15.6 и 14.7 В, ток 3.2 А, продолжительность 16 часов.


Прерывистый дозаряд качелями или моргалкой служит затем, чтобы минимизировать потерю воды на электролиз, и при этом по возможности полнее зарядить АКБ и перемешать электролит. Исторически этот способ сложился применительно к зарядным устройствам (источникам питания), у которых было невозможно оперативно регулировать зарядный ток, и вместо снижения силы тока, его прерывали по таймеру с помощью реле указателей поворота, либо по напряжению с помощью компаратора. Чтобы компаратор не возобновлял заряд моментально после его отключения, а делал паузу, понадобился гистерезис.

Некоторые энтузиасты считают электролиз воды при заряде аккумулятора вообще недопустимым, и устанавливают низкий верхний порог качелей. Дозаряд с такими настройками затягивается надолго, и часто не устраняет расслоения электролита и сульфатации глубинных слоёв намазок. Поверхность пластин при этом может выглядеть идеально: коричневая у положительных и серебристая у отрицательных, но при изгибе материала активных масс (АМ) он хрустит, выдавая присутствие сульфатов в глубине. Разумеется, для проверки пластин на хруст АКБ следует вскрыть и разобрать, потому эти факты не общеизвестные.

---

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

---

Другие энтузиасты пошли дальше и стали регулировать интегральный ток с помощью широтно-импульсной модуляции (ШИМ, PWM) более высокой частоты, чем доли герца единицы герц, реализовав подачи зарядного тока одной и той же амплитуды пачками импульсов ШИМ. В любом случае, для эффективного заряда свинцово-кислотного аккумулятора, необходимо обеспечить присутствие воды в зоне реакции, т.е. перемешивать электролит, так как при заряде АМ затрачивается вода и выделяется кислота, и потенциал заряжаемого участка АМ должен быть достаточным для преодоления термодинамической ЭДС и осуществления реакции Гладстона-Трайба.


Пошёл предзаряд.


Вскоре ЗУ перешло к этапу основного заряда.


За три с половиной часа залито 22.4 А*ч, напряжение на клеммах 13.3 В. Оставим ЗУ работать на ночь.


На следующий день время заряда составило 19 часов 42 минуты, аккумулятору сообщено 75.3 А*ч. Напряжение дозаряда доходит до установленных 15.6, ток при этом напряжении снизился до 1.2 А.


Алгоритм ЗУ не просто включает и отключает ток, а продолжает заряд некоторое время при максимальном напряжении, отключает, после падения включает сначала заряд постоянным напряжением по нижней уставке, затем по верхней, с ограничением тока не выше установленного.


Плотность электролита уже чуть выше 1.25.


С момента начала заряда прошло 23 часа, залито 77.4 А*ч. Ток при 15.6 В снизился до 1 А.
АКБ продолжает заряжаться, плотность электролита поднялась чуть выше 1.26.


Заряд продолжался 26 с четвертью часов, батарее передано 79.2 А*ч. Ток при 15.6 В не снижается.


Плотность 1.27.


29 с половиной часов от начала заряда, залито 80.9 А*ч. Ток при 15.6 В снизился до 0.9 А. Оставим ещё на ночь.


На утро аккумулятору сообщено 82.6 ампер*часа, ЗУ в режиме хранения. С начала заряда прошло 45 с половиной часов.


Плотность во всех банках 1.28. Нам удалось зарядить эту АКБ после глубокого разряда за один подход.

---

Однако возникают сомнения в том, что эта АКБ полностью кальциевая. При заряде она повела себя как гибридная. Ca/Ca аккумулятору 16 часов дозаряда, а именно такое максимальное значение можно установить на Кулоне-720, и его мы как раз установили, бывает недостаточно. Приходится перезапускать заряд.

---

Разряжать будем электронной нагрузкой ZKE EBD-A20H, по ГОСТ током 5% номинальной ёмкости 3.2 А до касания под нагрузкой 10.5 В.


Прибор подключается к ПК по USB и позволяет строить графики напряжения и тока. После начала разряда стабилизированным током напряжение растёт вследствие зависимости сопротивления электролита от концентрации кислоты, затем вскоре начинает плавно снижаться по мере разряда аккумулятора.


Через 8 часов разряда напряжение на клеммах 12.22 В. Слито 26.78 А*ч, 332.45 Вт*ч.


Через 20 с половиной часов разряд продолжается, на клеммах 11.07 В, АКБ отдала 66.86 А*ч, что уже превышает паспортную ёмкость. Как видно из графика, в конце разряда напряжение снижается быстрее, модуль первой производной выше.


На последней минуте график резко пошёл вниз.


Разряд завершён, напряжение после снятия нагрузки начало расти. Время разряда составило 20 часов 44 минуты, отданная ёмкость 67.39 А*ч.


Через 3 минуты после снятия нагрузки напряжение на клеммах выросло до 11.42 В. Подождём ещё час.


Прошёл час с момента завершения разряда, НРЦ 11.63 В.


Плотность электролита ниже 1.10. Ставим на заряд.


Заряд продолжается 26 часов 19 минут, залито 79.2 А*ч. Ток при 15.6 В 1 А.


Плотность уже 1.27. Аккумулятор заряжается очень легко при дозаряде качелями с максимальным напряжением 15.6. Так обычно ведут себя гибридные Ca/Sb, а не кальциевые Ca/Ca аккумуляторы.

Смотрим интенсивность газовыделения в качелях до 15.6. Это также признак гибридной АКБ. В силу более низкого напряжения начала газовыделения, расход воды при эксплуатации у этой АКБ выше, чем у других современных Ca/Ca. Это следует обязательно помнить, не забывать проверять уровень электролита, и своевременно доливать дистиллированную воду.


А так кипит при дозаряде с перенапряжениям вторая участница тестов оригинальная запасная часть LADA 6СТ-62VL производства жигулёвского завода АКОМ, типичная полностью кальциевая Ca/Ca батарея. Для такого газовыделения понадобилось 16.2 вольта при постоянном токе 2% ёмкости, то есть, 1.2 ампера, безо всякого прерывания качелями.


Тесты АКБ Лада объёмны и заслуживают как минимум отдельной статьи, потому здесь приведём только их конечные результаты, нужные для сравнения двух испытуемых образцов.



Показания тестера у Тюмени: здоровье 100%, ТХП 687 из 620 А по EN, внутреннее сопротивление 4.02 мОм, НРЦ 12.96 В. У Лады: EN 722 из 600 A, 3.82 мОм.


Просадка под нагрузочной вилкой 200 А до 10.64 В.


Для сравнения, Лада проседает до 10.90.


Масса тюменского аккумулятора 16.4 кг.


Сведём данные тестирования двух аккумуляторных батарей в одну таблицу:
Фактическая удельная ёмкость на килограмм массы батареи у АКБ Лада на 11.57% выше, чем у Тюмень Премиум, удельный ток холодной прокрутки на 13.69%. Оба этих параметра зависят не от кальция и сурьмы в свинцовом сплаве, а от собственно массы активных масс и их рабочей площади, а также конструкции решёток и тоководов. Получается, действующих активных масс у тюменского аккумулятора меньше, а несуще-токоведущих конструкций больше. Это признаки классической докальциевой технологии, по которой часто производились гибридные Ca/Sb батареи.

Итак, по итогам испытаний двух АКБ типичной современной Ca/Ca Лада производства АКОМ (завод, использующей технологию Exide), и тюменской Premium с маркировкой Ca/Ca и лосем на логотипе, можно сделать следующие выводы:

1. Оба аккумулятора проявили прекрасные характеристики: ёмкость по ГОСТ и пусковой ток по цифровому тестеру и нагрузочной вилке выше паспортных, однако Лада показывает заметно лучшие параметры, чем Тюмень Premium.
2. Жигулёвская АКБ АКОМ при заряде ведёт себя как полагается Ca/Ca, тогда как тюменская заряжается как гибридная: рано начинается газовыделение, электролит перемешивается без затруднений, выравнивающий заряд проходит легко и быстро.
3. Тюменская Премиум изготовлена по более старой технологии, чем жигулёвская Лада. Именно поэтому, несмотря на современный кальциевый сплав и отрицательных, и положительных решёток, тюменская АКБ имеет меньшую плотность упаковки пластин и проявляет свойства, характерные для гибридной, а не Ca/Ca АКБ.

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

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

В традиционных батареях, даже если изготовить все решётки по технологии Ca/Ca, внутренняя конструкция более массивная и просторная, заряжать и перемешивать электролит легче и быстрее, но и воды выкипает больше. Это одна из причин, приведших разработчиков свинцовых аккумуляторов к модерновым конструкциям. Экономия свинца, с соответствующим экологическим аспектом, и при этом повышение долговечности, стойкости к вибрации, предотвращение оплывания активных масс и короткого замыкания, другие цели, которые также преследуют модерновые конструкции АКБ.

Следует ли трактовать результаты опытов так, что тюменский аккумуляторный завод лось вводит покупателей в заблуждение, и АКБ Тюмень Премиум плохая АКБ? Категорически нет. Для автомобилей с низким бортовым напряжением Тюмень Премиум прекрасный выбор.

Тюмень Премиум хорошая АКБ, достойно проявившая себя на испытаниях. Она не гибридная, а действительно кальциевая, в плане современного материала решёток пластин. Но конструкция батареи не модерновая плотно упакованная, а традиционная, вследствие чего, при изготовлении затрачивается больше свинца, и газовыделение наступает при меньшем напряжении. И именно поэтому АКБ маркирована не VL, как Лада, что означает очень низкий расход воды, а L низкий расход. Всё честно.

Это необходимо учитывать при эксплуатации: тюменская Ca/Ca под капотом автомобиля теряет воду не как типичная Ca/Ca, а как гибридная Ca+. Нужно своевременно проверять уровень электролита и доливать дистиллированную воду, и пробки для этого завод-изготовитель предусмотрел.

Напоследок сравним Тюмень Премиум с антикварной аккумуляторной батареей 6СТ-60ЭМ из статьи про капсулу времени:
Почти три десятилетия прожиты недаром, и сегодняшний технологический уровень Тюменского аккумуляторного завода позволяет производить батареи с удельной эффективностью по ёмкости на треть, а по пусковому току на две трети более высокой, чем старые сурьмянистые батареи. Потому слова классическая и модерновая применительно к конструкции АКБ не следует понимать превратно. Современные аккумуляторы разных отечественных производителей и марок показывают достойные характеристики и имеют свои области для успешного применения.

Статья написана в сотрудничестве с автором экспериментов и видео Аккумуляторщиком Виктором VECTOR.