sudo rm -rf /*

Из-за того, что утилиты для работы с сетевым стэком в Linux (ifconfig, arp, netstat, route, brctl, etc ...) были написаны во времена, когда динозавры ходили по планете, и со времен мезозоя все привыкли к определенного вида форматированию вывода этих команд, а разработка ядра, вот так сюрприз, не стояла на месте, сообщество столкнулось с проблемой: старые утилиты не могут без поломки совместимости внешних скриптов корректно отдавать вывод по новому функционалу, который был добавлен в ядро.

Как решение проблемы был написан модный стильный молодежный iproute2, который замыкает на себя работу с сетевой подсистемой Linux, и, как следствие, предоставляет единый интерфейс работы. Остальные команды были признаны устаревшими. Сделано это было 10+ лет назад, однако, люди до сих пор используют связку ifconfig + route + arp + netstat + brctl как голландский штурвал управления сетевой подсистемой.

Простой пример.
В старых версиях ядра, для решения простой задачи добавления второго ip адреса на существующий интерфейс (eg eth0) приходилось создавать новый, зависимый от основного, виртуальный интерфейс (eth0:0) и вешать на него нужный адрес. В выводе ifconfig интерфейсы eth0 и eth0:0 шли друг за другом, и этот бред был сделан просто потому что ifconfig не умеет отрисовывать два адреса на одном интерфейсе. Ядро уже лет 10 позволяет назначить больше одного адреса на интерфейс, а ifconfig все эти 10 лет не научился с этим работать. Потому что обратная совместимость сломается.

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

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

https://baturin.org/docs/iproute2/

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

This is an example of using dd to asynchronously write 30% of memory to disk which would happen to be affected by the change in vm.dirty_ratio:
root # MEMTOTAL_MBYTES=`free -m | grep Mem: | awk '{print $2}'`
root # sysctl vm.dirty_ratio=40
root # dd if=/dev/zero of=zerofile ibs=1048576 count=$((MEMTOTAL_MBYTES*30/100))
2507145216 bytes (2.5 GB) copied, 8.00153 s, 313 MB/s
root # sysctl vm.dirty_ratio=20
dd if=/dev/zero of=zerofile ibs=1048576 count=$((MEMTOTAL_MBYTES*30/100))
2507145216 bytes (2.5 GB) copied, 10.1593 s, 247 MB/s
Note that the parameter affects the time it takes for the command to complete and the apparent write speed of the device. With dirty_ratio=40, more of the data is cached and written to disk in the background by the kernel. It is very important to note that the speed of I/O is identical in both cases. To demonstrate, this is the result when dd synchronizes the data before exiting:
root # sysctl vm.dirty_ratio=40
root # dd if=/dev/zero of=zerofile ibs=1048576 count=$((MEMTOTAL_MBYTES*30/100)) conv=fdatasync
2507145216 bytes (2.5 GB) copied, 21.0663 s, 119 MB/s
root # sysctl vm.dirty_ratio=20
root # dd if=/dev/zero of=zerofile ibs=1048576 count=$((MEMTOTAL_MBYTES*30/100)) conv=fdatasync
2507145216 bytes (2.5 GB) copied, 21.7286 s, 115 MB/s
Note that dirty_ratio had almost no impact here and is within the natural variability of a command. Hence, dirty_ratio does not directly impact I/O performance but it may affect the apparent performance of a workload that writes data asynchronously without synchronizing

Занимательная история сегодня произошла в мире IT журналистики. Я вообще не планировал про это писать, но всякие разные околоайтишные журналисты, блогеры и прочие мамкины копипастеры начали год с кликбейтных заголовков, что Microsoft опять обосрались, а число 220101001 is way to long, и в моей ленте про Y2K22 не написала разве что только сутулая собака.

Синопсис такой: весь мир сегодня узнал что Microsoft для версионирования внутри своих компонентов использует формат int32. Это такое довольно длинное число (2 147 483 647), которого казалось бы должно хватить всем. Проблема в том, что если вы кодируете год двумя символами, то вы рано или поздно придете к Y2K bug, и не важно в каком месте вы эти две цифры положите.

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

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

2147483647 - это предел в int32
220101001 - это число из заголовков (Reddit, ещё, etc ...)

Вообще первоисточник воть, и здесь автор банально объебался на один ноль в заголовке, а дальше все как один пошли тиражировать число, которое на порядок меньше int32, выдавая его превышение предела максимального значения. Красиво.

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

Всем привет, я вам кек принес, но это вам в счет Нового Года.

Вот баг https://bugs.python.org/issue3971, и ему 13 лет уже. Создали его в 2008, 10 лет молчали, потом так же молча закрыли. Welcome to the world of opensource community support, baby!

В этой истории прекрасно вообще всё. Единственный вопрос, который не дает мне покоя - это такой прикол или реально кто-то столнулся с описанной в первом комменте ситуацией?