sudo qlop -C -l | sed -e 's/. >>> //' | sed -e 's%./%%' | sed -e 's/-r[0-9]//g;s/_rc[0-9]//;s/-[0-9.]*//g' | sort -u | sudo xargs qlop -t -C | cut -d' ' -f2 | awk 'BEGIN{s=0}{s+=$1}END{print s}'
76282
76282
Что мне не нравится в Linux?
1. Полностью незащищённое ядро от самого себя. Любая ошибка при работе с памятью в одном модуле может порушить всю систему (а ошибки такого рода всё равно будут существовать, т.к. ядро написано на небезопасном языке, компиляторы которого не могут проверять программу достаточно хорошо). ИМХО нельзя считать такой выбор удачным решением проблемы производительности микроядерных систем — можно было бы и в отдельные сегменты положить код и данные тех модулей, которые мало (или вообще не) взаимодействуют друг с другом. А ведь последнее время чего только не запихнут в ядро.
2. Текстовые интерфейсы (через open/close/read/write/...) для всего. Реализация этой идеи обладает двумя недостатками: она недостаточна хороша по сравнению с другими универсальными интерфейсами (например, из-за производительности) и одновременно не доведена в Linux до завершения. Например, пусть программе нужно считать ARP-таблицу и взять оттуда MAC-адрес для хоста с IP 1.2.3.4. а потом подключиться к хосту с MAC-адресом 00:11:22:33:44:55 и передать ему этот адрес через какой-нибудь протокол. Для этого ей придётся открыть "текстовый файл" в procfs, прочитать его в память, распарсить его, перевести в своё внутреннее представление. Текстовая информация удобна для человека, но неудобна для программ — везде будут происходить двойные преобразования. Почему бы не преобразовывать информацию в текст только в момент вывода её на экран? Но ведь это не единственный вид интерфейса с ядром — есть ещё ioctl, который уж никак не текстовый (например для cmd = TCGETS, CDROMPLAYMSF, ...). А ещё есть всякие bind/connect/stat/..., которые тоже совсем не текстовые. Но ведь идея полностью текстового интерфейса вполне реализуема (например в Plan 9). Точно так же, как и идея полностью нетекстового (объектно-ориентированные ОС).
3. У (non-root) пользователя нет возможности сделать так, чтобы его окружение выглядело так, как ему хочется. Он не может монтировать fs в свои директории, не может менять корень (chroot), не может менять некоторые настройки только для себя (hostname, создавать сетевые интерфейсы, создавать пользователей, менять настройки файрвола, системное время, ...). Всё это может быть полезным для отладки, изоляции и адаптации приложений.
4. Непрерываемые системные вызовы. Если процесс повис во время выполнения системного вызова, то его нельзя убить. kill -9 не работает.
5. Отсутствие возможности (де)сериализации состояния процессов. Реализации есть, но они работают в юзерспейсе и достаточно ограничены.
1. Полностью незащищённое ядро от самого себя. Любая ошибка при работе с памятью в одном модуле может порушить всю систему (а ошибки такого рода всё равно будут существовать, т.к. ядро написано на небезопасном языке, компиляторы которого не могут проверять программу достаточно хорошо). ИМХО нельзя считать такой выбор удачным решением проблемы производительности микроядерных систем — можно было бы и в отдельные сегменты положить код и данные тех модулей, которые мало (или вообще не) взаимодействуют друг с другом. А ведь последнее время чего только не запихнут в ядро.
2. Текстовые интерфейсы (через open/close/read/write/...) для всего. Реализация этой идеи обладает двумя недостатками: она недостаточна хороша по сравнению с другими универсальными интерфейсами (например, из-за производительности) и одновременно не доведена в Linux до завершения. Например, пусть программе нужно считать ARP-таблицу и взять оттуда MAC-адрес для хоста с IP 1.2.3.4. а потом подключиться к хосту с MAC-адресом 00:11:22:33:44:55 и передать ему этот адрес через какой-нибудь протокол. Для этого ей придётся открыть "текстовый файл" в procfs, прочитать его в память, распарсить его, перевести в своё внутреннее представление. Текстовая информация удобна для человека, но неудобна для программ — везде будут происходить двойные преобразования. Почему бы не преобразовывать информацию в текст только в момент вывода её на экран? Но ведь это не единственный вид интерфейса с ядром — есть ещё ioctl, который уж никак не текстовый (например для cmd = TCGETS, CDROMPLAYMSF, ...). А ещё есть всякие bind/connect/stat/..., которые тоже совсем не текстовые. Но ведь идея полностью текстового интерфейса вполне реализуема (например в Plan 9). Точно так же, как и идея полностью нетекстового (объектно-ориентированные ОС).
3. У (non-root) пользователя нет возможности сделать так, чтобы его окружение выглядело так, как ему хочется. Он не может монтировать fs в свои директории, не может менять корень (chroot), не может менять некоторые настройки только для себя (hostname, создавать сетевые интерфейсы, создавать пользователей, менять настройки файрвола, системное время, ...). Всё это может быть полезным для отладки, изоляции и адаптации приложений.
4. Непрерываемые системные вызовы. Если процесс повис во время выполнения системного вызова, то его нельзя убить. kill -9 не работает.
5. Отсутствие возможности (де)сериализации состояния процессов. Реализации есть, но они работают в юзерспейсе и достаточно ограничены.
19 лет
запилил дверной звонок:
2010-07-27T01:53:02.701017+04:00 mu xinetd[6649]: START: ringing pid=6667 from=192.168.1.254
2010-07-27T01:53:03.264085+04:00 mu xinetd[6649]: EXIT: ringing status=0 pid=6667 duration=1(sec)
2010-07-27T01:53:03.412772+04:00 mu xinetd[6649]: START: ringing pid=6669 from=192.168.1.254
2010-07-27T01:53:03.968090+04:00 mu xinetd[6649]: EXIT: ringing status=0 pid=6669 duration=0(sec)
2010-07-27T01:53:04.534915+04:00 mu xinetd[6649]: START: ringing pid=6670 from=192.168.1.254
2010-07-27T01:53:05.098749+04:00 mu xinetd[6649]: EXIT: ringing status=0 pid=6670 duration=1(sec)
2010-07-27T01:53:02.701017+04:00 mu xinetd[6649]: START: ringing pid=6667 from=192.168.1.254
2010-07-27T01:53:03.264085+04:00 mu xinetd[6649]: EXIT: ringing status=0 pid=6667 duration=1(sec)
2010-07-27T01:53:03.412772+04:00 mu xinetd[6649]: START: ringing pid=6669 from=192.168.1.254
2010-07-27T01:53:03.968090+04:00 mu xinetd[6649]: EXIT: ringing status=0 pid=6669 duration=0(sec)
2010-07-27T01:53:04.534915+04:00 mu xinetd[6649]: START: ringing pid=6670 from=192.168.1.254
2010-07-27T01:53:05.098749+04:00 mu xinetd[6649]: EXIT: ringing status=0 pid=6670 duration=1(sec)
alsamixer:
In the midst of the word he was trying to say,
In the midst of his laughter and glee,
He had softly and suddenly vanished away---
For the Snark was a Boojum, you see.
(Lewis Carroll, "The Hunting of the Snark")
The sound device was unplugged.
Press F6 to select another sound card.
In the midst of the word he was trying to say,
In the midst of his laughter and glee,
He had softly and suddenly vanished away---
For the Snark was a Boojum, you see.
(Lewis Carroll, "The Hunting of the Snark")
The sound device was unplugged.
Press F6 to select another sound card.
Как отучить кошку лежать на ноуте? Ей там тепло.