Большой список программных решений, которые предлагают бесплатные возможности для разработчиков, администраторов и прочее (FreeTier, бесплатные возможности и т.п.)
https://free-for.dev/#/

Что можно почитать по systemd
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-managing_services_with_systemd-remote
https://people.redhat.com/pladd/systemd_NYRHUG_2016-03.pdf
https://www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf

Разработчики телеграмма завезли новое в голосования.
https://telegram.org/blog/polls-2-0-vmq

logrotate положил грабельку (по-крайней мере, актуально для OEL 6, logrotate-3.7.8-28.el6.x86_64),
которая игнорирует директиву size при запуске утилиты с ключом -f.
Какие директивы ещё игнорируются - не оч понятно.
Имхо, не очень приятное поведение.
https://stackoverflow.com/questions/47888465/logrotate-working-but-ignoring-size

Превращаем RHEL-подобные дистрибутивы в RHEL с подпиской (если она у вас есть :) ) с помощью утилиты Convert2RHEL
https://www.redhat.com/en/blog/convert2rhel-how-update-rhel-systems-place-subscribe-rhel

Вжух и ты хакнут 😎
https://www.opennet.ru/opennews/art.shtml?num=52340

Ситуация, когда у вас есть лог-файлы и они могут внезапно вырасти, до сих пор актуальна и может возникать по разным причинам:
1) Изменение уровня логгирования на DEBUG (моё любимое, сжирает дисковое пространство со скоростью света)
2) Ошибки в логах (при проблемах на инфраструктуре или с приложением тоже может достаточно быстро съесть ваше свободное место).
И неважно, запущено ли ваше приложение в контейнере или вне его, логи вездесущи.
Варианты решения/предотвращения тоже довольно очевидны:
1) Почитать документацию (увы и ах, довольно редко документация изучается в полном объеме и некоторые моменты упускаются), возможно, в ней описан стандартный функционал, который умеет в ротацию и очистку логов
2) Написать logrotate-файл и/или скрипт, который удаляет старые лог-файлы, если это не заложено в функционал программы.
3) Настроить мониторинг (ведь в современном мире без мониторинга никуда)

С Docker ситуация выглядит немножко поинтереснее. Если контейнера сожрали все дисковое пространство, а сервис или докер перезапускать нельзя (по разным причинам), то можно аккуратно снести логи,
например вот так:
find /var/lib/docker/containers/ -type f -name "*.log" -delete
Дешево и сердито. Если нужно снести конретные логи, то можно воспользоваться вариантом ниже:
# сортируем логи по возрастанию, получаем соответствие лога контейнеру
du -chs /var/lib/docker/containers/*/*json.log | sort -h
# грохаем логи
echo "" > $(docker inspect --format='{{.LogPath}}' container_id)

Чтобы сделать все красиво, можно задать глобальные параметры логгирования в JSON-файл Docker-демона, и/или
задать эти параметры для конкретного контейнера/указать параметры в docker-compose.
https://docs.docker.com/config/containers/logging/json-file/

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

Кто-нибудь читал статью, как вам?)
Имхо, какая-то не оч репрезентативная выборка, о чем явно и сказали в комментариях.
В России большое количество компаний, который занимаются ИТ и вносят большой вклад, как на территории СНГ, так и за границей. А список из 15 компаний какой-то куцый.
https://habr.com/ru/company/habr_career/blog/488220/

Вжух
https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/

Из интересных наблюдений.
Нужно запускать задачу раз в полтора часа через Gitlab.
Gitlab поддерживает Cron Syntax, а чтобы все исполнялось минута в минуту, надо подкрутить Sidekiq (https://docs.gitlab.com/ee/user/project/pipelines/schedules.html#advanced-configuration).
И, внезапно, выясняется, что синтаксис крона не позволяет запускать в одном выражении задачу каждые полтора часа. Каждый час, минуту - все ок, вот целый час с половиной (два с половиной и так далее) - нельзя.
В результате нужно создавать 2 выражения для крона. Например, если задачу планируется выполнять с 8 до 20 каждые полтора часа, то это будет выглядеть вот так:

0 8,11,14,17,20 * * *
30 9,12,15,18 * * *

можно подставить выражения вот сюда https://crontab.guru/ и увидеть время выполнения задач.

Очень бодрый наброс без конкретных аргументов. Основные претензии - ZFS, ifconfig,route vs ip.
https://habr.com/ru/post/490408/

Немного интересностей из последнего кейса.
Есть набор автотестов, который потреблял определенное количество трафика во время прогона до 74 версии Google Chrome (то что именно до этой версии - выяснилось уже позднее), с 75 версии Google Chrome и выше количество трафика на том же наборе увеличилось в 4-8 раз. Все это прекрасно видно по графикам мониторинга.
Немного об инфраструктуре, где крутятся автотесты. Имеются несколько машин, где развернут продукт Aerokube Selenoid (Docker-контейнер, который отвечает за запуск и остановку браузеров для автотестов. Браузеры запускаются тоже в Docker), а также терминальный сервер, откуда запускаются автотесты.
Сначала была проверена конфигурация Selenoid - в ней не было изменений, потом конфигурация ОС - тоже самое, затем начали запускать браузеры разных версий и проверять с какими параметрами они запускались. Нашли отличающийся параметр --disable-web-resources (Disables the backend service for web resources).
Не помогло. Начали дампить трафик - увидели небольшое число TCP Retransmission (https://networkguru.ru/tcp-retransmission-wireshark-chto-eto/), но это плюс-минус нормальная ситуация в сети, при небольшом количестве подобных пакетов. Следующие шаги заключались в проверке флагов в chrome://flags, проверке issue для selenium, в общем, поиск ошибок в используемых компонентах. Ничего похожего так и не нашли. Затем решили дампить трафик по-умному, сняв дамп на одном автотесте с версией Google Chrome, где объём трафика нормальный, а затем на версии, где большой объём трафика, после этого попакетно сравнить дампы. И это сработало. При анализе было обнаружено, что на новой версии Google Chrome часто происходят POST-запросы вида:

POST /wd/hub/session/66f73310d3d71f244a90287d2e823b91b92e436757429a63823aff59b955c485/execute/sync HTTP/1.1
User-Agent: selenium/3.141.59 (java windows)
Content-Type: application/json; charset=utf-8
Content-Length: 48867
Host: 10.84.181.9:4444
Connection: Keep-Alive
Accept-Encoding: gzip
 
{
"script": здесь тело скрипта на сотни символов
}

Как выяснилось, URL /session/{session id}/execute/sync - это команда Execute Script в WebDriver (https://chromium.googlesource.com/chromium/src.git/+/master/docs/chromedriver_status.md), которая несколько сотен раз (это только в одном автотесте) отправляла JS-файлы на сайт, а в старой версии такого не было. Статус этой команды - «Почти доделано» (даже есть баг, который говорит о проблемах с производительностью и о том, что эта фича будет работать, даже если у вас нет необходимости в её использовании - https://bugs.chromium.org/p/chromedriver/issues/detail?id=2938). И эта команда стала частью стандарта W3C (World Wide Web Consortium), поддержка которого как раз была реализована в Google Chrome 75. Как можно поправить всё быстро - отключить поддержку w3c в браузере (https://stackoverflow.com/questions/56452798/how-to-turn-off-w3c-in-chromedriver-to-address-the-error-unknown-command-cannot), медленно - внимательно изучить новый стандарт и провести корректировки в коде автотестов.

GitHub - теперь и на мобильном 😎

https://github.com/mobile?utm_source=announcement&utm_medium=email&utm_campaign=mobileGA

Пам-пам)

https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/

У слерма появилась возможность записаться на теоретический курс по куберу по вечерам бесплатно
https://slurm.io/evening/

Вжух, и в виндовом проводнике появится интеграция с WSL
https://blogs.windows.com/windowsexperience/2020/04/08/announcing-windows-10-insider-preview-build-19603/

GitHub продолжает радовать)
https://github.blog/2020-04-14-github-is-now-free-for-teams/