Хотите обеспечить бесперебойное питание своим устройствам, но при этом не сильно потратиться? Именно такой своей разработкой я и хотел с вами поделиться.

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

А что если сделать такой источник бесперебойного питания, который можно поставить прямо рядом с защищаемым устройством – лёгкое, компактное, недорогое?

В моём предыдущем материале речь шла о сравнении производительности ASP.NET Core-приложений, запускаемых в Windows и в среде Linux + Docker, работающих в службе приложений Azure. Эта тема интересна многим — поэтому я решил написать продолжение.



Я снова провёл испытания, используя подход, отличающийся от прежнего лучшей воспроизводимостью, такой, который даёт более надёжные результаты. Теперь я генерирую веб-нагрузку на серверы с помощью облачных инструментов Azure Cloud Agents, применяя Visual Studio и VSTS. И, более того, в то время как ранее я выполнял тесты с использованием HTTP, теперь тестирование проводилось с применением HTTPS.

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



Сильной стороной errno является тот факт, что этот интерфейс представляет собой простейший механизм, способный возвращать несколько значений из системных вызовов C, в которых нет непосредственной поддержки возврата нескольких значений (особенно — в ранних вариантах C). Использование глобальной переменной для «возврата» второго значения — это практически идеал того, что можно сделать в обычном C, если только не планировать передачу из C-библиотеки указателя на каждый системный вызов и функцию, которые собираются возвращать значение errno (при таком подходе придётся, например, интенсивно пользоваться stdio). Постоянная передача подобного указателя приводит не только к ухудшению внешнего вида кода. Такой подход увеличивает объём кода, и, из-за использования дополнительного параметра, приводит к повышению нагрузки на стек (или на регистры).

Что быстрее — ASP.NET Core-приложение, развёрнутое в Docker-контейнере на Linux, или такая же программа, но запущенная на Windows-сервере, учитывая то, что всё это работает в службе приложений Azure? Какая из этих конфигураций предлагает более высокий уровень производительности, и о каком «уровне производительности» можно говорить?

В давние времена многоархитектурных Unix-окружений разработчики дистрибутивов не могли прийти к единому мнению о том, что должно быть в $PATH. Базовые вещи, вроде /bin и /usr/bin, были везде одинаковыми, но у каждого дистрибутива был собственный набор дополнительных директорий (у Solaris их, например, было много). Кроме того — у разных локальных вычислительных групп было различное видение того, где должны размещаться локальные программы. Например — в /usr/local/bin, в /local/bin, в /opt/<something>/bin, в /<group>/bin и так далее. Всё это усложняло мне жизнь, так как я занимался поддержкой общего набора dot-файлов, используемых во всех Unix-системах, за которые я отвечал, и мне не хотелось бы, чтобы моя переменная $PATH представляла бы собой огромный список, содержащий пути ко всем необходимым директориям каждой из систем. Поэтому мне нужно было убирать всё лишнее из гигантского базового списка директорий, которые могли присутствовать в $PATH, оставляя там лишь те директории, которые существовали в текущей системе. А чтобы ещё сильнее усложнить эту задачу, мне хотелось использовать для этого только команды, встроенные в оболочку, и это — при работе с оболочкой, где test встроенной командой не является.

Для многих радиолюбителей первым собственным трансивером стал «Радио-76». Радиостанция эта была разработана в лаборатории журнала «Радио» Б. Степановым (UW3AX) и Г. Шульгиным (UA3ACM). Конструкция трансивера была простой и хорошо повторяемой.

Актуальность трансивера «Радио-76» повысилась, когда в августе 1978 года для советских радиолюбителей вновь «открыли» для работы диапазон 160 метров. Радиолюбительский позывной для работы на этом диапазоне стало возможным получить уже с 14 лет, причём без сдачи экзамена на приём и передачу азбуки Морзе.

Собрать же юным радиолюбителям свою радиостанцию стало гораздо проще, когда в 1980 году Ульяновский радиоламповый завод начал выпуск радиоконструктора «Электроника-Контур-80». Стоил набор 64 рубля, содержал собранные на производстве основную плату и плату гетеродинов (без моточных компонентов), и из него можно было собрать малосигнальный тракт трансивера «Радио-76».

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

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

Микроскоп

В материале о том, что в наши дни find, как правило, не нуждается в xargs, я отметил, что в конструкции '-exec ... {} +' скобки ('{}') (для имён файлов, генерируемых find) должны находиться в конце команды. В комментарии к той публикации анонимный читатель сказал, что это неприменимо к -exec-версии, которая запускает отдельную команду для каждого имени файла. В результате можно поместить заменяемое имя файла в любом месте команды. Это, как оказалось, относится не только к GNU Find, являясь стандартной возможностью, и я полагаю, что этого даже требует Single Unix Specification (SUS) для find.

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

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

Большинство командных оболочек, включая bash, ksh, dash и ash, выводят приглашение командной строки в той позиции, в которой остался курсор после завершения работы предыдущей команды.



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

Насколько это реально, почему нельзя, а также, — какое слово зашифровано ниже и причём тут стартапы, вы узнаете из этой статьи

Год назад вышла ShellCheck v0.7.1. Главным образом в ней были подчищены и исправлены имеющиеся проверки, но также появились и новые. Лично меня из всех новинок больше всех удивила та, что указывает на проблему, обсуждение которой я еще нигде не встречал:

In demo line 6:
  cat template/header.txt "$f" > archive/$((i++)).txt
                                             ^
  SC2257: Arithmetic modifications in command redirections
          may be discarded. Do them separately. 
#Арифметические изменения при перенаправлениях в command могут быть 
#отброшены. Выполняйте их отдельно

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

После того, как я прочитал очередную статью, где говорится о том, что JS-классы — это всего лишь «синтаксический сахар» для прототипного наследования, я решил написать материал, призванный (в который раз!) прояснить вопрос о том, почему данное утверждение неверно. Тут я, надеюсь, смогу объяснить разницу между JS-классами и прототипным наследованием, и смогу рассказать о том, почему важно понимать эту разницу.

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

Если вы не знакомы с первой частью, советую сначала ознакомиться с ней:
Свой личный SMS-шлюз. Часть 1 – цели, задачи, сборка и тестирование

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

Гарантированный базовый доход, он же ББД (безусловный базовый доход) или UBI (Universal Basic Income) — горячая тема, набирающая популярность не только на Хабре и в гиковских кругах, но и по всему миру среди экономистов, руководителей городов и даже кандидатов в президенты США.

В 2021 тема ББД актуальна как никогда: эмпирические данные в пользу гарантированного базового дохода растут по экспоненте, новые эксперименты запускаются буквально на глазах: в апреле о запуске собственных пилотных программ объявили Лос-Анджелес и Сан-Франциско, следующий вероятный кандидат на очереди — Нью-Йорк. О том, что говорят ББД на практике забытый канадский эксперимент 1970-х, калифорнийский эксперимент 2020-х, политическая программа лидирующего кандидата на выборах мэра Нью-Йорка 2021 года и современная пенсионная система, существующая с 1889 года — в этой статье.

tl;dr: используйте инструкцию ${placeholders?} для выдачи ошибки при пропуске параметра и объединяйте команды оболочки с помощью &&, чтобы упростить и обезопасить их копирование из технической документации.

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

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



Часто это принимает форму грубо замаскированных команд, вроде той, что показана ниже. Её запуск приведёт к выполнению в текущей директории команды rm -rf *, которая всё удалит. Вот эта команда:

$(echo cm0gLXJmICoK | base64 -d)

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

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