Устали от ограничений и долгой настройки серверов? High-speed VDS поможет в работе!

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

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

✅  Управление репозиториями кода для Git
✅  Система отслеживания задач
✅  Удобная Wiki для документации
✅  Мощный CI/CD пайплайн
✅  И многое другое для продуктивной работы всей команды!

🎁 Подготовили приятный бонус для тебя: +10% к пополнению баланса

​​Блеск и нищета FreeBSD

Разработчики FreeBSD опубликовали отчёт о развитии за четвёртый квартал 2024 года, в котором упомянут проект bsd-user-4-linux, развивающий инструментарий для запуска в Linux приложений, собранных для FreeBSD.

Целью проекта заявлена возможность собирать пакеты для FreeBSD в Linux, используя родной сборочный инструментарий FreeBSD.

Для запуска исполняемых файлов FreeBSD задействован форк эмулятора QEMU. В данном режиме QEMU выполняет трансляцию системных вызовов и обработку сигналов.

Для запуска приложений требуется развёртывание в локальном каталоге библиотек и настроек из базовой системы FreeBSD. Проект можно рассматривать как обратный аналог Linuxulator.

На текущем этапе разработки работает запуск основных системных утилит (sh, bash, find, grep, git, clang и т.п.), поддерживается динамическое связывание и разделяемые библиотеки, доступны сетевые функции.

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

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

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

Далее бездарно проспали наследство Sun в виде ZFS, которая могла бы стать киллер-фичей и снова сделать систему конкурентной. Но увы, в настоящий момент развитием этой файловой системы занимается OpenZFS, которая разрабатывает ее в первую очередь в интересах Linux.

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

Этим активно пользуются многие, от Apple до Juniper и слышать от адептов FreeBSD отсылки к этим системам смешно. Так как никто не знает, что именно там взяли от BSD и как изменили. Плюс самому сообществу и системе от этого ни холодно, ни жарко. Взамен они не получили ничего.

​​Культура работы с сертификатами

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

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

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

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

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

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

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

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

🔹 Введение в криптографию. Общие вопросы, проблемы и решения

Что нужно знать в нашем случае? Что единственно допустимым хранилищем ключевой пары является токен, ну это если официально. Если проявить некоторую смекалку, то при должном знании и умении из токенов Рутокен (кроме Рутокен ЭЦП 2.0/3.0) ключевая пара извлекается и может быть записан на флешку или в реестр.

Физически ключевая пара – это два файла бинарного или текстового формата, в последнем случае используется Base64 кодирование бинарного файла.

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

Если вы после этого смените его хранилище, скажем с токена на флешку, то сертификат надо будет переустановить.

Хранилища ключевой пары зовутся контейнерами и в том же Крипто-Про доступны в отдельном разделе. А раздел Сертификаты отражает установленные в системное хранилище сертификаты, т.е. те, которые непосредственно доступны для работы.

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

Что касается удаления контейнера, то для этого нужно постараться отдельно: отформатировать токен, удалить файлы с флешки или раздел реестра. Но это надо сделать отдельно и осознанно. Штатные инструменты работы с сертификатами или Крипто-Про (равно как и другие криптопровайдеры) таким не занимаются.

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

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

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

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

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

Что не так сделал Вася?

🔹 Вася интерактивно отладил нужные команды в оболочке bash с правами root.

🔹 Вася записал команды в скрипт.

🔹 Вася проверил скрипт – все работает!

🔹 Вася настроил запуск скрипта в cron.

🤬 У Васи ничего не работает!

🤫 Что не так сделал Вася?

​​Режимы запуска bash

Для того, чтобы правильно ответить на вопрос «что не так сделал Вася» следует понимать контекст выполнения команд bash в каждом конкретном случае.

1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.

При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации /etc/profile и один из файлов: ~/.bash_profile, ~/.bash_login или ~/.profile который будет найден первым при поиске в указанном порядке.

Кроме того, /etc/profile считывает файлы /etc/profile.d/*.sh и /etc/bash.bashrc, а : ~/.bash_profile содержит указание на исполнение файла ~/.bashrc.

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

2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).

В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из ~/.bash_profile и общие из /etc/bash.bashrc.

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

3️⃣ Третий режим – неинтерактивный. Он используется при запуске bash -с или bash имя_скрипта, а также при вызове команд и скриптов системными процессами, тем же cron.

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

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

Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо ./my_script.sh используйте bash my_script.sh.

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

​​День рождения Arch Linux

Сегодня, 12 марта Arch Linux исполняется, кто бы мог подумать, 23 года. А ведь казалось это было только вчера.

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

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

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

Самый известный и дружелюбный – это Manjaro – своего рода Ubuntu в мире Arch, где новичка буквально проведут за руку, а чтобы вы случайно ничего не сломали апгрейдами у Manjaro есть свой репозиторий, в который пакеты попадают после дополнительной проверки.

Да, это уже не экстремально свежий софт, зато надежно, стабильно и предсказуемо (насколько это вообще применимо к миру Arch).

✅ Manjaro Linux - самый простой способ окунуться в мир Arch

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

✅ EndeavourOS - и снится нам не рокот космодрома

А может быть чего-то необычного? И этого хватает, тот же Garuda – яркий, стильный с буйством красок и возможностей, вплоть до игровых. Но в тоже время это Arch со всеми своими особенностями и хотя он менее суров чем EndeavourOS, но под капот заглядывать все равно придется.

✅ Garuda KDE Dr460nized - яркий и стильный и это тоже Arch

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

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

​​Настраиваем политику паролей в Linux

Во многих дистрибутивах Linux (а более подробно мы будем говорить о Debian / Ubuntu) политика паролей по умолчанию не установлена, и никто не помешает нам установить слабый пароль, даже «123».

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

apt install libpam-pwquality

После чего откроем файл /etc/security/pwquality.conf, который отвечает за политику паролей. Опции будут перечислены в порядке их перечисления в файле со значениями по умолчанию:

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

difok = 1 

Минимальная длина пароля

minlen = 8 

При составлении пароля учитываются классы символов, их четыре: прописные буквы, строчные буквы, цифры и специальные символы.

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

Следующие опции позволяют начислять дополнительные кредиты за каждый класс символов:

dcredit = 0 – цифры
ucredit  = 0 – прописные буквы
lcredit = 0 – строчные буквы
ocredit = 0 – специальные символы

Таким образом, если мы установим dcredit = 1, то пароль pass123 получит 10 кредитов, что будет эквивалентно его длине в 10 символов.
Если же мы установим количество кредитов меньше нуля, то это будет требованием минимального количества символов данного класса, например, ocredit = -2 – не менее двух специальных символов в пароле.

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

minclass = 0

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

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

maxrepeat = 0

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

maxclassrepeat = 0

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

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

Учетная запись пользователя в Linux имеет специальное поле GECOS, которое может содержать его реальное имя, телефон, адрес почты и т.д. Мы можем проверить пароль на наличие в нем общедоступной информации:

gecoscheck = 0

При установке значения в единицу при нахождении в пароле данных GECOS он не будет пропущен.
Также мы можем осуществлять проверку по словарям cracklib (ставятся по зависимостям):

dictcheck = 1

Следующая проверка исключает использование имени пользователя в пароле:

usercheck = 1

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

usersubstr = 0

Если установить его равным трем, то сочетание ivanov:ivan123 будет запрещено, равно как vano456, а iva123 будет пропущен.

Следующая опция устанавливает количество попыток ввода пароля:

retry = 3

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

enforce_for_root

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

Mikrotik и несколько провайдеров. Балансировка каналов

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

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

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

https://interface31.ru/tech_it/2023/04/mikrotik-i-neskol-ko-provayderov-balansirovka-kanalov.html

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

👆 А начинающего автора следует поддержать подпиской, потому что на текущем этапе это для него лучшая мотивация. Лучше донатов, правда!

Ммммм, как же мне нравятся холивары между сектой свидетелей докера и сектой свидетелей пакетов...

Сам я в холиварах давно стараюсь не участвовать, поэтому отпишусь здесь, у себя.

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

Возьмем, к примеру, маленькую галеру на пяток бэкендеров и пару фронтов. Есть пара-тройка активных проектов, десяток на поддержке, пара в перспективе. Вот скажите, что в таких реалиях админу проще? Пилить ансибл под каждый проект для сборки и деплоя на дев/прод — или использовать единожды написанные шаблонный пайплайн Гитлаба, шаблонные докерфайлы и шаблонный же композфайл, точечно инжектируя нужные изменения? Десяток несложных проектов могут крутиться (и крутятся) в дев-окружении на одной виртуалке о четырех головах ядрах, у каждого свои зависимости могут быть — попробуйте их развернуть на одном хосте, чтоб они друг другу не мешали, и обновление работало без вашего участия месяцами и ничего не ломало? Я верю, у вас получится — но давайте при этом сравним трудозатраты?

При этом я совершенно точно не стану пихать в докер, например, Nextcloud для домашнего пользования, особенно, если задумаю ставить его на маломощное железо типа Raspberry Pi. Тут это явно будет лишним: Клауд обновляется не так уж и часто, да плюс к этому пихать его в контейнер — не самая лучшая затея, с учетом его архитектуры... Уж кто-кто, а он точно при установке на хост конфигурируется куда проще и понятней.

Совершенно точно не потащу в докер Samba (написал — и понял, что хочу попробовать, вот такой я странный). Офисная файлопомойка обновляется крайне редко, правильно настроенная работает годами, ломающие изменения редки, конфиги для знающего человека простые. Плюс, как правило, под нее выделяется отдельная виртуалка, не отягощенная более никаким функционалом. (А DC ставят на голой самбе только конченные извращенцы типа меня в прошлом, граблей хватает, особенно если домен изначально был виндовый)

Люди еще возражают против почтовиков в докере, но у меня есть собственноручно развернутый в бою mailcow-dockerized на пару десятков пользователей, работает без нареканий второй год. Хотя могу и iRedMail накатить, и голые postfix+dovecot.

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

А накосячить можно при любом подходе. Никто от этого не застрахован.

А про секты было только в прошлую пятницу.

🔥Хотите упростить сбор логов, метрик и трейсов в своей инфраструктуре? Grafana Alloy — мощный инструмент, который унифицирует доставку данных и интегрируется с Prometheus, Loki, Tempo и другими сервисами.

⚡️17 марта в 20.00 мск приглашаем на открытый вебинар "Grafana Alloy - универсальный инструмент доставки логов, метрик и трейсов", на котором узнаем:
- Как Grafana Alloy решает проблемы передачи данных в сложных системах?- Чем он отличается от Fluentd, Vector и других агентов?
- Как настроить отказоустойчивость и балансировку нагрузки?
- Лучшие практики маршрутизации, фильтрации и трансформации данных.Регистрируйтесь и внедряйте Grafana Alloy в своих проектах!

👉Регистрация: https://otus.pw/ljG6/?erid=2W5zFFyDLYp 

Занятие приурочено к старту курса "Observability: мониторинг, логирование, трейсинг", на котором вы научитесь строить эффективные системы мониторинга, работать с Prometheus, Grafana, ELK и другими инструментами, визуализировать метрики.

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Установка облачного файлового сервиса Seafile на Ubuntu Server

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

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

Это может быть связано как с объемом хранимых данных, так и с требованиями безопасности или конфиденциальности.

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

https://interface31.ru/tech_it/2023/09/ustanovka-oblachnogo-faylovogo-servisa-seafile-na-ubuntu-server.html

​​И снова про RouterOS 7

В комментариях в очередной раз задавали вопрос: а что не так с RouterOS 7? Почему мы не планируем писать по ней статей и вообще не советуем к применению.

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

Во-вторых – RouterOS 7 продолжает развиваться и изменения часто вносятся очень серьезные. Если взять две наши статьи про ROS 7 которые касаются OpenVPN и WireGuard, то на сегодня они порядком устарели. Поэтому подобные материалы придется переписывать постоянно, либо всегда помнить, что инструкция может быть не актуальной.

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

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

Теперь что касается старых устройств. Про все, что не на платформе ARM можно сразу смело забыть. hAP, hEX, 2011 и т.д. – это не для ROS 7, поставить вы, конечно можете, но ничего хорошего из этого не получится, новая ОС существенно требовательнее к ресурсам. Нет, работать за редким исключением, вроде hAP lite, будет, но нагрузка на устройство существенно вырастет.

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

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

Как быть? В большинстве случаев следует оставаться на старой и стабильной ROS 6, которая вдоль и поперек изучена и не преподносит сюрпризов.

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

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

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

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

Канал о захватывающем мире IT-инфраструктуры, где опытные сисадмины и DevOps-инженеры делятся уникальными кейсами и решениями технических задач. 🔧

Собрана подборка самых важных постов для вас:

• Топ-3 самых популярных характеристик ПК в Steam

• История VPN: от военных технологий до повседневного использования

• Доклад от Сбера - Будущее 2035

• Как устроен даркнет

• Криптовалюта: цифровая революция денег

• Сравнение двух разных технологий ИИ 2024 и 2025 (видео)

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

Mikrotik и несколько провайдеров. Резервирование каналов

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

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

https://interface31.ru/tech_it/2023/03/mikrotik-i-neskol-ko-provayderov-rezervirovanie-kanalov.html

​​Субботнее, о жизни. Вкалывают роботы, но почему несчастлив человек?

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

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

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

Меньше смен – меньше заработная плата, которая там и так невелика. А небольшие по площади магазины уже давно перешли на схему «один сотрудник и несколько касс самообслуживания».

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

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

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

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

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

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

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

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

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

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

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

К чему все это? А к тому, что если твою профессию можно заменить роботом, то ее очень скоро заменять роботом. И он будет вместо тебя вкалывать, только вот счастья тебе это не принесет.

​​Мы пахали, я и трактор…

Чарльз Ганьон (Charles Gagnon), мэйнтейнер проекта Dash to Panel, объявил, о поиске нового сопровождающего, которому он мог бы передать управление. Панель создана в 2016 году на основе проекта Dash to Dock и насчитывает более 4 млн загрузок. Чарльз участвует в разработке с 2018 года и в своё время сменил на посту мэйнтейнера Джейсона ДеРоуза (Jason DeRose), основателя проекта.

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

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

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

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

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

Но если мы зайдем на страницу проекта на GitHub и посмотрим список контрибьюторов, то обнаружим, что основной вклад в проект внес именно Чарльз Ганьон – 823 коммита, на втором месте автор проекта Джейсон ДеРоуз – 227 коммитов. На третьем месте Philipp Unger со 155 коммитами.

Остальные участники внесли от 20 коммитов и менее, т.е. фактически не проявили заметного участия. Если взять тройку лидеров, то Чарльз Ганьон внес 68% коммитов за все время существования проекта.

Но если мы посмотрим на графики активности, то увидим, что Джейсон ДеРоуз после 2018 года практически отошел от дел, а все это время, в течении шести с лишним лет проект тянул Чарльз Ганьон.

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

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

Донаты? Ну вы, наверное, уже поняли, как оно работает. Если ведущий разработчик был вынужден достаточно навязчивым образом привлечь внимание к этой проблеме.

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

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

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

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

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

Зато «сообщество» в очередной раз показало «кто здесь власть».