/usr/bin

systemctl list-unit-files --type=service --state=enabled

apt-get update
sudo !!

diff <(sort a.txt) <(sort b.txt)sort a.txt) <(sort b.txt)

{ echo "starting job"; date; run_job; } >run.log 2>&1echo "starting job"; date; run_job; } >run.log 2>&1

cut -d',' -f1,4 users.csv | tr ',' '\t' | column -t

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

Есть много опенсорсных разработок, которые подходят для установки на VPS. Среди них универсальные решения вроде b1gMail, который работает на любом дистрибутиве и может интегрироваться с Postfix. Или emailwiz — баш-скрипт для полной автоматизации установки серверов Postfix/Dovecot/SpamAssassin/OpenDKIM на Debian. Есть и готовые контейнеры с конфигами, как docker-mailserver, там уже всё настроено.

Хочешь быстро поднять несколько лёгких Linux-виртуалок из Windows, да так, чтобы процесс можно было легко повторить? Я, как любитель и самоучка, недавно решил с этим разобраться и всё получилось.

Я делал это на Windows через WSL, куда установил лёгкий Alpine-minirootfs, а после Ansible с помощью которого автоматически создал в Oracle VirtualBox 3 виртуальные машины на базе Alpine-standard. Никаких облаков, только локальный контроль и минимум зависимостей. Для чего всё это? Сейчас всё чаще говорят о минималистичных системах, об оптимизации железа под конкретные задачи, о работе на граничных устройствах, вот и захотелось попробовать всё своими руками.

Бывало, открываешь десяток терминалов, чтобы мониторить систему: в одном htop, в другом делаешь tail логов, в третьем запускаешь отладку. Через пару минут такой работы голова идет кругом от мельтешащих окон. Для того, чтобы как‑то разобраться с этим, помогут терминальные мультиплексоры, старый добрый GNU Screen и его более крутой товарищ tmux.

2 декабря 2025 года состоялся выпуск стабильного релиза FreeBSD 15.0 с большим количеством доработок и улучшений. Установочные сборки решения доступны для архитектур amd64, aarch64, armv7, powerpc64, powerpc64le и riscv64. Дополнительно представлены сборки FreeBSD 15.0 для систем виртуализации (QCOW2, VHD, VMDK, raw) и облачных окружений Amazon EC2, Google Compute Engine и Vagrant.

Версия FreeBSD 14.0 вышла в ноябре 2023 года Релиз FreeBSD 13.0 состоялся в апреле 2021 года. Согласно пояснению команды разработчиков, ветка FreeBSD 14.x стала последней с поддержкой 32-разрядных платформ. В версии FreeBSD 15.x будет доступна поддержка только 64-разрядных систем. При этом до конца жизненного цикла ветки FreeBSD 16.х сохранится возможность сборки 32-разрядных приложений и использования режима COMPAT_FREEBSD32 для запуска 32-разрядных исполняемых файлов в 64-разрядном окружении.

Один сервер — это точка отказа. Рано или поздно он не выдержит. Как только появляется второй, третий, десятый сервер, возникает вопрос: кто будет раздавать им работу? Эту роль и берет на себя балансировщик нагрузки.

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