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

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

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

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

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

This article is based on the experience of developing the memsafe library, which, using the Clang plugin, adds safe memory management and invalidation control of reference data types to C++ during source code compilation.

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

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

Но данная статья не о библиотеке, а об особенностях разработки анализатора программы на С++ в виде плагина для Clang.

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

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

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

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

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

The most common types of software bugs are memory management bugs. And very often they lead to the most tragic consequences. There are many types of memory bugs, but the only ones that matter now are memory leaks due to circular references, when two or more objects directly or indirectly refer to each other, causing the RAM available to the application to gradually decrease because it cannot be freed.

Memory leaks due to circular references are the most difficult to analyze, while all other types have been successfully solved for a long time. All other memory bugs can be solved at the programming language level (for example, with garbage collectors, borrow checking or library templates), but the problem of memory leaks due to circular references remains unsolved to this day.

But it seems to me that there is a very simple way to solve the problem of memory leaks due to circular references in a program, which can be implemented in almost any typed programming language, of course, if you do not use the all-permissive keyword unsafe for Rust or std::reinterpret_cast in the case of C++.

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

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

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

There have been many discussions about which programming language is better in terms of security and correctness of source code (by "correctness and security" we mean the absence of various errors in the program that manifest themselves at the stage of its execution and lead to the issuance of an incorrect result or unexpected behavior). And some programming languages, such as SPARK or OCaml, were even specially developed to facilitate the proof of program correctness.

Is it possible to write programs without errors at all?

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

А возможно ли вообще писать программы без ошибок?

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

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

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

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

Статья в продолжение темы безопасной разработки на С++ с примером работающего кода. Кратко предыдущие тезисы:

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

А раз текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов, то выходит, что:

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

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

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

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

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

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

Таким образом, возникают, казалось бы, взаимоисключающие и не разрешимые противоречия:

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

Но ключевым моментом в предыдущем абзаце является фраза "казалось бы".

Еще одна статья в продолжение темы анализа сходных текстов на С/С++ с помощью Clang. Предыдущие публикации:

• ​Как создать собственное расширение компилятора C++
• Анализ AST и рефакторинг кода в Clang

Это не перевод довольно подробной публикации Emitting Diagnostics in Clang от Peter Goldsborough про различные нюансы диагностических инструментов у Clang, а преимущественно адаптация старого кода под текущую версию компилятора.

И основная идея, которая меня заинтересовала в исходной публикации, это использование инструмента FixIt из набора диагностики clang для внесения исправлений в исходные файлы.

В продолжение темы кастомизации компилятора С++ публикую перевод еще одной интересной статьи от Eli Bendersky AST matchers and Clang refactoring tools.

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

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

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

Это перевод статьи, которая, к сожалению, у меня не доступна без слова из трех букв. А так как тема довольно интересная, то я решил совместить полезное с полезным и не только самому покопаться с примерами из публикации, но и сделать её перевод на Хабре. Вдруг еще кому данный материал будет интересен?

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

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

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

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

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

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

Ведь как нельзя лучше про это сказал Генри Форд, что "разочарование от низкого качества длится дольше, чем радость от низкой цены".

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

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

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

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

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

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

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

Но обо всем по порядку под катом (с картинками)

Недавно прочитал новость, что Mail.ru отменила бесплатные вечные 100 ГБ для первых пользователей «Облако Mail.ru»

В конце октября 2024 года компания Mail (принадлежит VK) предупредила клиентов, что отменяет бесплатные вечные 100 ГБ для первых пользователей «Облако Mail.ru» спустя 11 лет старта проекта.

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

Но это предыстория, а сама история вот:

Уже давно обратил внимание, что при отправке любого письма на Mail.ru показывается плашка "Письмо отправлено. Вы можете отменить отправку ..." со счетчиком оставшихся секунд до отмены, но я никогда на это не реагировал, всегда нажимая крестик для закрытия окна.

Но однажды, к своему сожалению, решил ради интереса посмотреть, что же будет, если нажать на кнопку "отменить отправку".

И как оказалось ничего хорошего!

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

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

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

Recently, there has been a lot of talk about the success of artificial intelligence (AI), although this usually means another achievement in the field of generative neural networks.

And few people, speaking about AI, try to explain what they themselves understand by the term “artificial intelligence.” After all, it’s one thing to write about “AI problems,” and quite another to endow an ordinary computer algorithm with at least the rudiments of intelligence.

After all, the etymology of the established phrase “artificial intelligence” is not unambiguous and can take on different meanings depending on what meaning the author is trying to put into it.