Размещать конфиги в /lib/systemd/system/*.service, т.е. там, где их не стоит размещать — неправильно. Кастомные конфиги живут в /etc.

Править сервис-файлы в [/usr]/lib/systemd/system — очень плохая идея, т.к. это vendor-файл, который перезапишется при обновлении.

Для оверрайда используется /etc/systemd/system, куда можно поместить свой вариант сервис-файла. Но и это не совсем правильно, т.к. требует дублирования всего файла (можно решить инклюдом, но это костыльно).

Самый правильный подход для указанной в статье задачи — использовать drop-in'ы:

coreos.com/os/docs/latest/using-systemd-drop-in-units.html

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

Моя статья на эту тему, конечно, была давно, но актуальности не потеряла:

habrahabr.ru/post/98742

Так а чем вам NFLOG+ulogd2 не угодил?

В Линуксах вызов calloc может привести к маппингу всего выделяемого адресного пространства на заранее зануленную страницу (одну) с последующим COW при модификации выделенных страниц.

Нет, по крайней мере в Линуксе это не так. Попробуйте сравнить по скорости calloc и malloc+memset.

А меня вот AC/DC очень даже успокаивает.

Да пребудет с вами обоими буква «е».

Нет, речь не о Nat64:

mirrors.bieringer.de/Linux+IPv6-HOWTO/nat-netfilter6..html

atoomnet.net/howto-ipv6-nat-in-centos-6/

> В IPv6 нету технологии NAT которая есть в IPv4. Смело спорьте с тем кто скажет обратное.

Ну давайте поспорим:

git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/netfilter

Посмотрите файлики, в названии которых есть nat и masquerade. Я понимаю, что аналога RFC 2663 нет, но если есть рабочая реализация в ядре, то нельзя говорить, что её нет.

А если так:

https://medium.com/@shazow/ssh-how-does-it-even-9e43586e4ffc

?

Забыл указать, что данные нужно реплицировать на две ноды. Пока всё живёт на гластере, но это медленновато, особенно, когда нужно 200-300 тысяч файлов выбрать и удалить.

У нас 11 ТБ мелких файлов по 2–4 МБ, которые нужно ротейтить каждый день, причём выборку очень желательно делать не тупым перебором, а SQL-запросами, например. Что посоветуете?

А какой тип нагрузки у вас? И тип хранимых данных?

Хотелось бы бенчмарков GridFS. Как раз думаем, использовать ли её в продакшне.

А почему не gvpe?

software.schmorp.de/pkg/gvpe.html

К тому же, tmux можно запускать при интерактивных сессиях автоматически. Вот пример из моего .zshrc:

mosh_test=$(pstree -s $PPID | egrep -o 'mosh-server')
if [[ "$mosh_test" == "mosh-server" ]]
then
        STARTED_TMUX=1; export STARTED_TMUX
        ((tmux has-session -t remote && tmux attach-session -t remote) || (tmux new-session -s remote) ) && exit 0
        echo "tmux failed to start"
fi

kdbus нужен в первую очередь, если я правильно понимаю, для Linux Automotive Initiative, и это уже не поттерингиада, а реальное внедрение.

RSS-клиент в ownCloud.

> Не все разделяют его радикальные идеи по модернизации ядра.

К счастью, от него тут мало что зависит, а Линус пока ещё в своём уме. Да и вообще, что конкретно имеется в виду?