Comments 20
Статья хорошая и полезная, но технически она описывает то, что происходит уже после запуска процесса. А запуск процессов это fork exec который не менее интересен.
А запуск процессов это fork exec
Точнее clone, остальное уже userland.
Немного несогласен с некоторыми философскими вопросами в начале.
Намного безопаснее сохранить код, работающий в привилегированной памяти(kernel space), настолько маленьким, насколько это вообще возможно. Это ускорит разработку ядра, сделает его быстрее и уменьшит количество ошибок и уязвимостей.
Я думаю важен не столько размер, сколько активный функционал.
Тот же process scheduler да, должен быть маленьким.
А драйвера могут быть достаточно большими, поскольку они не дергаются каждый слайс времени.
Вот дос - минималистичная система, но работу с девайсами каждому приходилось писать самому.
Если говорить про ембеддед разработку под конкретные устройства, там требования к ОС могут быть другими.
В общем в статье много полезных моментов, но мне кажется не там сделан акцент.
ОС это базовая система для запуска софта, а дальше уже идет вопрос насколько эта ОС удобная или неудобная для написания прикладного софта и для пользователей в целом.
p.s. а ваш скрипт вполне правильный. можно максимум printf на echo заменить и тест упростить, типа
while LC_CTYPE=C IFS= read -d '' -rn1 a; do [ ${#a} -eq 0 ] && echo -ne '\0' || echo -nE "$a"; done </usr/bin/file >test.fil
Спасибо за статью, пишите про "кишочки" еще и не становитесь рекрутером - собеседование это совсем не ковбойский поединок. :)
Как вы интересно огородами начали подходить к теме.) Спасибо, начинаю очередную итерацию изучения линуксовых систем.
Чёрт, целая статья, и ни слова про LD_LIBRARY_PATH.
А причём тут Гейтс и Цук?
Когда я был еще молод и "умен", я поменял IP адрес ДНС сервера в файле /etc/resolv.conf
Надо было читать маны(шутка с долей сарказма).
На сегодя:
Domain name resolution
dns: the glibc resolver which reads /etc/resolv.conf, see resolv.conf(5)
resolv.conf — Gentoo Wiki
OpenRC(openresolv), systemd-resolved
К сожалению, я не нашел более быстрого и простого способа копирования бинарных файлов в bash. Надеюсь гуру bash просветят меня и читателей хабра, как сделать это не криворуко, как в моем примере
На гурость не претендую, но dd if=<src file> of=<dest file> bs=4096 сработал в моём тесте.
В целом, спасибо за отличную статью. Я раньше думал, что управлением библиотеками занимается непосредственно ядро, а редкие проблемы с поломанной загрузкой решал перекомпиляцией
хехе
Шутки шутками, а некоторые спрашивают базовую теорию на собеседованиях и абсолютно все учили её в профильных ВУЗах.
Но знакомый мне ответил, что это все конечно увлекательно, но только ему это нафиг не нужно, так как он успешно работает без "вот этих вот знаний" на крупных проектах уже второй десяток лет.
Как человек, который периодически собеседует людей тянущих вроде как на гордое звание «девопса», регулярно обнаруживает, что когда я начинаю собеседовать людей на подобные темы, у них делаются большие, круглые глаза. Они-то думают, что девопс — это про рисование yaml для кубернетесов и прочих гитлабов. А знать, что там внизу — это для смердов, видимо. :)
Выше в комментах упомянули Таненбаума и я это безусловно всячески одобряю. Но не вижу плохого, если напишете на эту тему что-то своим языком. Иногда надо почитать разных авторов, чтобы понять, как оно работает. :) И да, тут в коммента так же упоминают про разные вещи вроде LD_PRELOAD или LD_LIBRARY, можете написать вторую часть этой статьи. :)
Добавлю 5 копеек для следующих читающих ))
Если ld (ld-linux-x86-64.so) использовать вручную (для запуска приложений), то можно немного конфигурировать запуск (audit, lib path) (может быть полезно для "поиграться").
И также с ее помощью можно посмотреть список зависимостей/dll.
Что для вас Linux? Или как устроен запуск процессов