Активируем Ubuntu On Windows в свежей Windows 10 Build 14316

Надо сразу отметить, что стеснительные Microsoft форсируют новомодную пепяку именно под названием Bash, хотя на самом деле это весь user-mode *nix софт (в ближайшем будущем точно).

Пишем под *nix

Для устранения некоторых недостатков сервера, собранного из бытовых комплектующих, недавно разработал устройство, которым хочу поделиться. Его подробное описание, со схемой и исходными кодами, находится в первой части.
В этой части статьи будет рассмотрено как взаимодействовать с последовательным портом из пространства ядра (kernel space) и как организовать работу с несколькими подсистемами устройства через RS232 в Linux.
Устройство включает в себя следующие подсистемы:
watchdog демоном;



// returns name of property with sequential number nProperty, or error
errno_t listproperties( int fd, int nProperty, char *buf, int buflen );
errno_t getproperty( int fd, const char *pName, char *buf, int buflen );
errno_t setproperty( int fd, const char *pName, const char *pValue );


В последнее время много разговоров идет о том, что для C++ нужен свой пакетный менеджер подобный pip, npm, maven, cargo и т.д. Все конкуренты имеют простой и стандартизированный механизм подключения нестандартной библиотеки. В C++ же все действуют как умеют: кто-то прописывает в README список пакетов для Ubuntu, CentOS и других дистрибутивов, кто-то использует git submodule и скрипты для их сборки, кто-то использует CMake ExternalProject, кто-то копирует все исходники в один гигантский репозиторий, кто-то делает образ Docker или Vagrant.
Чтобы решить проблему был даже создан стартап — biicode, но он обанкротился и его будущее неизвестно. Взамен появился conan, дополняя зоопарк конкурентов — nuget, cget, hunter, cpm, qpm, cppget, pacm и даже gradle for c++.
Меня не устраивал ни один из перечисленных способов. Я было начал писать пакеты для Conan, но столкнулся с большим числом хаков, неразвитым API, отсутвием гайдлайнов и, как следствие, низкой вероятностью переиспользования чужих пакетов. И тут вспомнилось, что когда-то мне очень понравились идеи пакетного менеджера в NixOS. И подумал — а зачем плодить пакетный менеджер специально для C++, если те же задачи решает обычный пакетный менеджер? Нужно только чтобы он был достаточно гибким и простым в части описания пакета. И Nix идеально подошел на эту роль.


Если вы следили за новостями о последних разработках в области инструментов анализа C/C++ кода, то, должно быть, слышали про инструмент PVS-Studio. Я узнал о нем благодаря статьям, которые разработчики публикуют на своем сайте и в которых они рассказывают о проверках проектов с открытым кодом. К настоящему времени уже проверено внушительное число проектов, включая ядро Linux, Qt, Unreal и т.д., и каждый раз им удается находить интересные ошибки, подолгу живущие в коде, никем не обнаруженные. Опечатки, неаккуратное копирование, неопределенное поведение, бессмысленный код, синтаксические ошибки, которые чудесным образом пропускаются компилятором…

В век «онлайна», печатная фотография стала больше походить на диковинку, как это было раньше с фотографией цифровой. В последнее время, различного рода фотобудки, стали набирать популярность, как интересный способ развлечь гостей и получить памятный сувенир в виде фотографии. Я фотограф, который увлекается программированием, и при этом сочетании, было бы странно не попробовать сделать себе фотобудку. 
pip, npm и gem не подходили в силу языка самой утилиты — bash. Тогда стало понятно, что нужно распространять свое приложение в том числе и через системные пакетные менеджеры. Для Mac — в силу отсутствия встроенного — таких пакетных менеджеров несколько. И у каждого из них есть свои особенности и недостатки. И в первой части я хочу более подробно остановиться на Homebrew, и как создавать пакеты для него..tar.gz, .deb и .rpm. О чем я расскажу во второй части.

