commit -m "better"

Исследование: просмотр мемов во время рабочего дня улучшает производительность Теперь ты знаешь, чем заняться на работе

ё

В 2024 стыдно не уметь программировать! Если вам хочется быстро вкатиться в IT, разобраться в тонкостях ядра Linux, научиться писать красивый код на Rust/Python/Go/C++, постигнуть все тайны менеджмента, и вообще, почувствовать себя в IT, как рыба в воде, то заходите в https://t.ly/3RQBu, будет интересно!

Вышла новая gcrypt - https://www.opennet.ru/opennews/art.shtml?num=61405 И я как раз хотел было написать по этому поводу, что "больше всего на всете я люблю, когда проекты копипастят друг у друга код", потому что:

ld.lld: error: duplicate symbol: gf_mul
>>> defined at f_impl64.c
>>>            libcrypto-lib-f_impl64.o:(gf_mul) in archive libcrypto.a
>>> defined at mceliece6688128f.c
>>>            mceliece6688128f.o:(.text+0x0) in archive libgcrypt.a

Но потом не поленился провести фактчекинг, и, должен сказать, что вот, просто так совпало. Код про что-то такое похожее, но совершенно разный. В случае сборки в .so вероятность пересечения не очень велика, потому что всякие внутренние символы можно скрыть из интерфейса .so, а вот со статической линковкой такое ловится довольно часто.

Ну, допустим, #meme про изучение #rust. (thanks @bapho_bush)

Так и работаем

Neofetch developer archives all his repositories: "Have taken up farming" Article, Comments

#runit, будни #bootstrap, #herobora. У используемого и нежно любимого мной runit есть одна неприятная особенность (врочем, как и у остальных init-ов, унаследованных от daemontools). Он хочет безусловно портить струткуру директорий, в которых лежат сервисы. Простыми словами - он создает директорию ./supervisor, рядом с каждым файликом run каждого сервиса. Там он хранит состояние управляемого сервиса, и прочую лабудень. Контрольки сервисов (./run файлы) у меня лежат в /etc, которая есть ссылка на какую-то папку в content addressable store. Из этого следует простой вывод - runit у меня "портил" (и продолжает портить) папки (и данные) в cas, чего допускать, конечно, нельзя. Я обкатывал несколько разных решений этой проблемы, которые, так или иначе, сводились к "теневой" копии сервисов из /etc "куда-то", где можно писать. Например, регулярным копированием /etc/services куда-то в /var/run/, или, вот, с помощью rw overlay unionfs куда-то в tmpfs. Короче, совершенно всратые решения, ошметки которых я даже не хочу показывать. В общем, после нескольких лет попыток придумать что-то не столь всратое, я плюнул, и переписал runsvdir - это часть runit, которая отвечает именно за управление деревом процессов. Эдакий сплав (она же херобора) из обычного runit для pid1, и моей запчасти, с таким же интерфейсом, ее так же зовут скрипты инициализации runit, но с нужной мне семантикой. Та-да-да-дам! https://github.com/stal-ix/ix/blob/main/pkgs/bin/ix/runsvdir/run.py Да, на python, потому что для прототипирования python подходит очень хорошо, и я уже смирился с тем, что он у меня есть в базовой системе (при этом я упаковал в один бинарь со всеми зависимостями, поэтому он не мозолит глаза своей россыпью файлов по всей fs). Когда его семантика устаканится, перепишу на go, или даже на rust (не хочет кто-то взяться? там строк 50-100 идиоматичного rust-о кода должно быть). Что я могу сказать? * Мне кажется, это самый компактный супервизор процессов, который я когда-либо видел/делал, при этом, с приличным набором фич. Он умеет пасти структуру директорий, такую же, как у runit, но ничего не пишет на диск. Сервисы могут добавляться и убираться "на лету". * Удивительно, но я вот написал этот скриптец, ребутнул машину, ожидая debug и recovery окирпиченного хоста, но ничего такого не случилось - все завелось сразу, с полпинка, потому что поверхность у runsvdir - очень простая и компактная. * В принципе, теперь я могу там запилить недостающие фичи из runit, типа динамически создаваемых юнитов. Захочу ли - пока не знаю.