Собрав по кусочкам информацию от вас. Я пришёл выводу..
В данном случае systemd пытался задействовать механизм "The Discoverable Partitions Specification", для автоматического определения разделов.
И вот почему:
The OS can discover and mount the necessary file systems with a non-existing or incomplete /etc/fstab file and without the root= kernel command line option.
Итог: /etc/fstab нет или не полный, опция ядра root= не указана, разделы по спецификации вы явно не настраивали. Но systemd как всегда крайний.
То, что вы описали, никак не имеет отношения к systemd.
Это больше похоже на особенности работы UEFI, возможно даже особенности отдельных производителей железа. Например у меня одна мат.плата MSI при некоторых похожих условиях, самостоятельно удаляет запись загрузчика Linux и
устанавливает дефолтным загрузчиком Windows.
Есть механизм и директива WatchdogSec=, единственное, что требуется от сервиса уметь периодически слать sd_notify со значением WATCHDOG=1. При этом sd_notify можно использовать из поставки либо прямо слать дейтаграммы на AF_UNIX сокет из переменной окружения $NOTIFY_SOCKET. Для скриптов есть консольная утилита systemd-notify.
SOCKS5 по определению не может быть безопасным, он не для этого проектировался.
А парольная авторизация системных пользователей, через незащищённый SOCKS5 это даже не дыра в безопасности, это парадная дверь к серверу.
Если вы знаете способ аутентифицироваться в прокси в приложении Telegram по ключу, очень прошу поделиться.
Это и не нужно, SOCKS не безопасен. Все ваши подключения можно легко отследить и как минимум заблокировать, когда начнут душить незащищённые прокси, только дело времени. Всё, что нужно это использовать локальный SSH как безопасный туннель во внешний мир.
Чем не угодила авторизация по ключу вместо пароля?
Возможно вам также потребуется поделиться доступом к прокси с кем то из недоверенного круга.
К счастью это не проблема. Но это не тема вашей статьи. Которая уж точно не покрывает безопасные кейсы, особенно если судить о рекомендацией использовать код из подозрительного источника запущенный от root'а.
теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service. Уже или галстук, или трусы…
Это проблема вашего дистрибутива, а не systemd. А в прогрессивных дистрибутивах такой проблемы нет, они уже давно целиком перешли на systemd без костылей.
А просто здесь автор теста не ставил целью использовать map по своему назначению, использовал для простого обхода массива. Не окрепший студент насмотрится страшилок и потом всю жизнь будет избегать map.
Замечание верное и это конечно нужно иметь ввиду.
Но в контексте бенчмарка someFn не чужая тестовая функция, которая принимает ровно 1 аргумент. В общем такие бенчмарки больше вредны, чем полезны.
Собрав по кусочкам информацию от вас. Я пришёл выводу..
В данном случае systemd пытался задействовать механизм "The Discoverable Partitions Specification", для автоматического определения разделов.
И вот почему:
Итог: /etc/fstab нет или не полный, опция ядра root= не указана, разделы по спецификации вы явно не настраивали. Но systemd как всегда крайний.
То, что вы описали, никак не имеет отношения к systemd.
Это больше похоже на особенности работы UEFI, возможно даже особенности отдельных производителей железа. Например у меня одна мат.плата MSI при некоторых похожих условиях, самостоятельно удаляет запись загрузчика Linux и
устанавливает дефолтным загрузчиком Windows.
Есть механизм и директива WatchdogSec=, единственное, что требуется от сервиса уметь периодически слать sd_notify со значением WATCHDOG=1. При этом sd_notify можно использовать из поставки либо прямо слать дейтаграммы на AF_UNIX сокет из переменной окружения $NOTIFY_SOCKET. Для скриптов есть консольная утилита systemd-notify.
Уточните, пожалуйста, какие баги раздражают.
И был ли открыт по ним issue до вас или вами?
Для этой задачи вообще никакие пакеты из NPM не нужны и велосипеды тоже.
Все что нужно уже есть из коробки, даже с примерами.
https://nodejs.org/api/readline.html#readline_example_read_file_stream_line_by_line
Но для построчного чтения не нужен велосипед. Ведь уже есть Readline
sudo: yum: command not foundсомневаюсь, что справится
SOCKS5 по определению не может быть безопасным, он не для этого проектировался.
А парольная авторизация системных пользователей, через незащищённый SOCKS5 это даже не дыра в безопасности, это парадная дверь к серверу.
Это и не нужно, SOCKS не безопасен. Все ваши подключения можно легко отследить и как минимум заблокировать, когда начнут душить незащищённые прокси, только дело времени. Всё, что нужно это использовать локальный SSH как безопасный туннель во внешний мир.
Чем не угодила авторизация по ключу вместо пароля?
К счастью это не проблема. Но это не тема вашей статьи. Которая уж точно не покрывает безопасные кейсы, особенно если судить о рекомендацией использовать код из подозрительного источника запущенный от root'а.
Зачем еще какие либо SOCKS серверы, если SSH уже с SOCKSом на борту.
Есть же systemd-swap в репах. С настройками под все возможные варианты.
Имя доступ к клавиатуре, заполучить какой либо файл не слишком сложная задача.
Вы забыли, что keepass тоже нужно разблокировать паролем с той же самой клавиатуры.
Это проблема вашего дистрибутива, а не systemd. А в прогрессивных дистрибутивах такой проблемы нет, они уже давно целиком перешли на systemd без костылей.
А просто здесь автор теста не ставил целью использовать map по своему назначению, использовал для простого обхода массива. Не окрепший студент насмотрится страшилок и потом всю жизнь будет избегать map.
Замечание верное и это конечно нужно иметь ввиду.
Но в контексте бенчмарка someFn не чужая тестовая функция, которая принимает ровно 1 аргумент. В общем такие бенчмарки больше вредны, чем полезны.
И совершенно бесполезное создание бесполезной функции:
Можно упростить, до
К тому же агрегатные функции не равнозначны простому циклу без проверок из-за того, что они пропускают дырки.