Inferno Часть 0: пространства имён

http://debu.gs/entries/inferno-part-0-namespaces
  • Перевод
FAQ: Что такое OS Inferno и зачем она нужна?

Я обещал, но ещё не написал пост о том, как установить и запустить Inferno, и делать невероятные вещи; я раздул его до серии статей, из которых это первая, вводная часть. Я собираюсь немного рассказать о пространствах имён (namespaces). Это критическая часть ОС, и одна из тех вещей, которые сильно отличают Plan 9 и Inferno от того, что сейчас работает на вашем компе.

Inferno малоизвестна, и я не намерен её евангелизировать. Я хочу помочь сократить разрыв между предысторией и практикой, чтобы объяснить как использовать Inferno, и почему она работает так, как работает.

Мне придётся немного отклониться в сторону. Я собираюсь поговорить об эволюции пространств имён, не совсем в хронологическом порядке, скорее в порядке развития возможностей, и потом показать как использовать возможности Inferno.

Содержание



DOS


Помните DOS? У вас были A: и B:, ваши дисководы. Был C:, ваш винчестер, и т.д. У вас была иерархия каталогов на каждом из этих дисков. (Опустим лишние детали.) Вы можете думать об этом как о плоском, верхнеуровневом, одно-буквенном, привязанном к железу пространстве имён. Один диск — одна буква.

Unix, Linux


В Unix, однако, был каталог верхнего уровня, "/". Туда монтировался корневой диск, а все остальные диски монтировались в подкаталоги корневого каталога, в подкаталоги подкаталогов — где бы вы хотели видеть этот диск. Вам не требовалось знать что на каком разделе или диске, если только вы не занимались настройкой системы или на одном из разделов не заканчивалось свободное место. Вы можете думать об этом как об иерархическом пространстве имён, общем для всей ОС.

Это намного более гибкий и мощный подход. Программам и пользователям не требуется знать что на каком диске.

Позднее, в Unix появились файловые системы нового типа: синтетические. Например, /proc. В Linux так же есть /sys, и не редко /dev тоже синтетическая файловая система. Нет физического диска, на котором бы хранились файлы этих файловых систем, но, тем не менее, программам об этом ничего знать не нужно. Файлы видны в пространстве имён так же, как любые другие файлы, и программы не требуется изменять чтобы они смогли читать или писать файлы в этих файловых системах.

В некотором смысле между ними находятся файловые системы, которые хоть и хранят файлы на диске как обычно, но знать это наверняка или доказать пользователь не может. Например, NFS представляет собой удалённый сервис содержащий иерархию файлов и каталогов.

Дальше есть FUSE, предоставляющая файловые системы в пространстве пользователя. Используя FUSE для взаимодействия с локальным ядром ОС, и реализовав то, для чего вы собирались писать драйвер, вы можете создать сервис любой синтетической файловой системы — без необходимости писать реальный драйвер для ядра ОС. (Я замалчиваю BSD; туда похоже попало меньше фич из Plan 9, хотя в DragonFly разработали несколько интересных идей.)

С другой стороны, поскольку пространство имён общее для всей системы, вам требуется быть root чтобы изменять его. Представьте себе случайного пользователя, который что-то там подмонтировал поверх /sbin, угробив этим даже команду umount. Пользовательские монтирования это мелкое исключение, в каком-то смысле костыль, который принципиально ничего не меняет: вы можете монтировать файловую систему FUSE в любой _свой_ каталог. (Кстати, в Linux есть драйвер для 9P2000, протокола используемого Plan 9 и Inferno.)

Ранее, файловая система могла быть подключена только в одном месте. «Bind mounts» в Linux дают немного больше гибкости — если файловая система (или её часть) уже доступна где-то в пространстве имён, её можно подключить в другое место через mount --bind. Это относительно недавнее добавление, и до ядра 2.6.26 нельзя было подключить одну и ту же файловую систему в одно место в режиме read-write и при этом в другое в режиме read-only.

Plan 9, Inferno


Plan 9 и Inferno взяли несколько больших кусков исторической семантики Unix и выкинули их в окно, выкинули некоторые из ключевых допущений ОС, допущений, которые во многом были подразумевающимися и неявными. Я сейчас говорю про Inferno, но практически всё это так же относится к (и впервые появилось в) Plan 9. Когда я говорю «в Inferno» можете спокойно добавлять в скобках «и в Plan 9». Эти допущения не указаны в каком-то определённом порядке, я их просто для удобства пронумеровал.

Первое допущение, которое было проще всего сломать, и, пожалуй, самое очевидное в ретроспективе — то, что файлы и каталоги в пространстве имён представляют объекты на диске.

Второе допущение — что есть связь один-к-одному между файловыми системами и точками монтирования. Т.е. что данная файловая система подключена только в одном месте, и что в это место подключена только эта одна файловая система. Избавиться от этого допущения означает, что файловая система и место куда она подключена независимы друг от друга, и что любое количество файловых систем могут быть подключены в одно и то же место.

Третье допущение — что есть связь один-к-одному между работающей системой и пространством имён. Если изменения пространства имён будут видны только изменившему пространство имён процессу и его потомкам, не будет необходимости защищать пользователей от изменений пространства имён сделанными другими пользователями, и уйдёт ограничение кто что и куда может монтировать. Пользователю достаточно иметь права на чтение файловой системы чтобы её подмонтировать.

Выкидывание этих допущений насчёт пространства имён позволило получить гораздо более мощную систему, причём разница эта может быть не видна так уж явно с первого взгляда, но на самом деле является такой же большой, как разница между пространством имён DOS и Unix.

Эти три допущения были нарушены в разной степени в Unix-подобных ОС, и с разной степенью успешности. Первое допущение было успешно нарушено в Unix. У вас есть /proc, к примеру, почти во всех Unix. FUSE позволила пользователям монтировать файловые системы, даже скрывать их (не идеально, конечно) от других пользователей, что дало подобие личного пространства имён, почти нарушив третье допущение. Bind mounts дали возможность одной части пространства имён появиться в где-то в другой части, приблизившись к нарушению второго допущения, но требуя root. Union mounts так же пробрались в Unix, вроде бы. Но, за исключением первого допущения, все эти решения не полны. Что если мы начнём с самого начала, не таща за собой багаж Unix?

Поскольку пространство имён теперь у каждого процесса своё (точнее говоря, любой процесс может, но не обязан fork-нуть пространство имён), кто угодно может монтировать что угодно куда угодно, или подключать (bind) что угодно куда угодно, без создания каких либо проблем безопасности. Поскольку точка монтирования может содержать любое количество подмонтированных систем, причём все будут одновременно доступны, появляется возможность накладывать одни файловые системы на другие. Поскольку любая файловая система может быть «настоящей» или «синтетической» пока она использует соответствующий протокол (9P2000 в случае Inferno), что угодно может быть файловой системой и любая программа которая работает с файлами может это использовать.

Многие вещи, которые являются либо хаками, либо кривыми решениями, вдруг исчезают, поскольку в них больше нет необходимости. Очевидно, что многое из того, что делегировалось root, больше не нужно, как и sudo. chroot больше не нужен. Символические ссылки не нужны. Громадное количество встроенных в ядро ОС драйверов не нужны. NSF и /etc/exports не нужны (скатертью дорога). mount -o loop не нужен. mount --bind не нужен. FUSE не нужна. Даже $PATH больше не нужен, и вместе с ним необходимость быть root для установки софта.

… Ну и?


Одна из вещей, которая раздражает меня в документации для Inferno (и Plan 9) — что есть научные статьи, man страницы, исходный код, но почти нет учебников или документов в стиле «howto». Возможно я испорчен Linux-ом, который идёт с HOWTO как готовить кофе. Начать — непростая задача, особенно если ты не знаешь достаточно о системе чтобы использовать систему для изучения самой себя. Ты пытаешься, но там незнакомый шелл который запускает незнакомые команды, и man-страницы написанные как справочник, не особо помогают.

Так что я могу оценить документ, пытающийся ответить на вопрос «Ну и? Я слышал заманчивые обещания и раньше. Как я могу это использовать?» и я собираюсь объединить всё это несколькими конкретными примерами, поясняя что происходит.

Наконец, что-то что вы можете набрать


Помните все эти вещи, которые больше не нужны? Каждая из них была заменена чем-то лучшим, а некоторые из них несколькими вещами, каждая из которых лучше. Я собираюсь (для простоты) игнорировать аутентификацию в этих примерах, но скажу, что у вас есть выбор методов аутентификации и шифрования в Inferno.

root не нужен для монтирования

Это довольно просто:
bind '#p' /n/prog

Это монтирует файловую систему prog (аналог /proc) в /n/prog. Кстати говоря, вы можете управлять, отлаживать, и делать всё что обычно с запущенными процессами через файловую систему /prog, точно как в Unix. Разница в том, что если вы локально подмонтируете /prog удалённой машины, вы сможете делать все эти вещи с удалёнными процессами без всякой ssh и даже без запущенного отладчика на удалённой машине. Да, вы сможете локально выполнить kill 15 и это убьёт процесс 15 на удалённой машине.

mount -o loop и FUSE не нужны

У меня есть кучка .iso файлов на моём компе. Предположим, они находятся в /n/cds, и я хочу подключить один из них:
; 9660srv /n/cds/dfly-i386-3.0.2_REL.iso /n/dfly
; ls /n/dfly

Сейчас текущий процесс и его потомки могут видеть содержимое этого CD. Ничего особого не требуется; 9660srv(4) знает как читать файловую систему ISO-9660 с одной стороны и поддерживает протокол 9P2000 с другой.

Inferno так же идёт в комплекте с, например, tarfs(4), которая трактует tar-архив как read-only файловую систему.

Драйвера в ядре не нужны

Ну, большинство. Те, которые не просто экспортируют файловую систему, и наконец-то можно будет забыть про ioctl(). Драйвера предоставляемые ядром можно увидеть в файле /dev/drivers, и это довольно краткий список, более краткий, чем вывод lsmod на типичной машине с Ubuntu или даже Arch.

Там, где вам бы потребовался драйвер ядра для поддержки новой файловой системы в большинстве ОС, Inferno не нуждается в modprobe (и таким образом в правах root) и не трогает ядро чтобы добавить новую файловую систему. Вы можете получить поддержку ext2 (read-only) скачав ext2fs, точно так же как ядру не требовалось знать о ISO-9660 в примере выше.

chroot не нужен

Поскольку процесс может создать для себя пространство имён, всё, что может быть опасным показывать не доверенному процессу может быть отмонтировано от пространства имён, и системный вызов pctl(2) может быть использован для запрета процессу монтировать драйвера. Экстремальный пример которые отмонтирует всё (и поэтому не сможет сделать ничего кроме использования встроенной в шелл функциональности):
; load std
; pctl newns
; pctl nodevs
; unmount /
; ls /
sh: ls: './ls' file does not exist

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

Так же вы можете сделать временную песочницу, если хотите, подмонтировав файловую систему в памяти поверх корневого каталога:
; mount -bc {memfs -s} /
; echo Mad with power! > /asdf

И, конечно, /asdf нигде не появится. (Надо заметить, что это касается только создания новых файлов.)

Симлинки не нужны

bind решает эту задачу предоставляя возможность помещать одни каталоги поверх других. Например, мне нравится набор иконок tinytk больше, чем иконки по умолчанию, так что я перекрываю ими иконки по умолчанию перед запуском оконного менеджера:
; bind -bc /icons/tinytk /icons/tk

Вы даже можете поместить один файл поверх другого:
; echo Hello > some-file
; bind some-file /NOTICE
; cat /NOTICE
Hello

Поскольку симлинки не нужны и отсутствуют в Inferno, проблема циклических ссылок в файловой системе почти исчезает.

$PATH, $LDPATH и права root для установки софта не нужны

Я ненавижу возиться с $PATH. Большие куски моего .bashrc посвящены выяснению кто идёт первым, и не добавлением избыточных путей или путей, которые указывают на бинарники для других архитектур. У меня установлен Plan 9 Port, но я не хочу, чтобы версия Plan 9 man конфликтовала с Linux версией, к примеру.

В Inferno, всё, что вы хотите запускать, находится в /dis (/bin в Plan 9). Если вы хотите запускать программы из другого места, вы просто подключаете его перед или после /dis.
; bind -bc $home/dis /dis

Так что если вы хотите что-то установить, но не можете писать в /dis, установите его куда хотите, и подключите его поверх /dis. sudo не требуется. То же самое касается /lib и /module.

NFS не нужен

Я собираюсь игнорировать аутентификацию (флаг -A) и шифрование, так что мы будем экспортировать что-нибудь не важное: снова memfs(4). Первая машина:
; mount -c {memfs -s} /n/mem
; echo something > /n/mem/asdf
; listen -A 'tcp!*!1234' { export /n/mem & }

Вторая машина:
; mount -A 'tcp!thefirstmachine!1234' /n/remotememfs
; cat /n/remotememfs/asdf
something

Поскольку большинство команд файл-серверов могут работать через stdin/stdout вместо подключения к точке монтирования, файловую систему даже не требуется локально монтировать чтобы сделать её доступной по сети:
; styxlisten -A 'tcp!*!1234' {memfs -s}

И на второй машине:
; mount -Ac 'tcp!thefirstmachine!1234' /n/remotememfs

Команды listen(1) и dial(1) это просто удобные обёртки для взаимодействия с файловой системой /net, которая является интерфейсом в сеть для Inferno. Сокеты в Unix обрабатываются библиотекой BSD sockets (с соответствующими системными вызовами) и значительно сложнее в использовании. Вы можете думать о listen и dial как об аналоге netcat. styxlisten это то же самое, только ожидает передавать протокол 9P2000 (называвшийся так же Styx пока его не приняли в Plan 9) вместо потока байт.

Мощные примитивы означают, что вы никогда не пожалеете


Всё это достигается несколькими короткими командами, которые сами по себе являются просто обёртками вокруг системных вызовов Inferno. У вас есть bind(1), mount(1), и unmount(1). Если вам нужна интроспекция вам поможет ns(1).

Представление всех объектов ОС как файловых систем означает, что программы вроде cat, sed и echo могут быть использованы для, к примеру, доступа к сети используя файловую систему ip(3). ftpfs(4) позволяет использовать ls и cp без интерактивного клиента, что упрощает написание скриптов (нет необходимости в перенаправлении через FTP клиент). По сути, вашим скриптам вообще нет нужды знать, что они работают с FTP сервером а не с обычным файлом на диске. zipfs позволяет вам подмонтировать .zip файл. Комбинируя их, вы можете подмонтировать .iso, который внутри .zip, который на FTP сервере, и потом скопировать из него отдельные файлы.

Где-то в будущем


Мы уже находимся в интересной точке. Большая часть населения владеет как минимум ноутбуком и смартфоном, и, из них, большая часть так же владеет домашним компом, имеет компьютер на работе, планшет, и т.д. В период расцвета Unix, был один компьютер и много пользователей. Это кажется очевидным, но мы быстро приближаемся к точке когда общим случаем будет много компьютеров у одного пользователя а не наоборот.

Управление всеми этими ресурсами (диском и CPU, в частности) уже большая проблема. Синхронизация файлов, синхронизация контактов, и т.д. Если у вашего телефона не хватает ресурсов чтобы что-то обработать, вам нужно идти к обычному компу (физически или через ssh). Если вы хотите посмотреть фильм на телефоне, вам необходимо его туда скопировать. Что вы делаете если читали статью на телефоне и решили продолжить чтение на ноутбуке? Посылаете себе email или IM? (Это всё ещё лучше, чем DBUS, но это отступление.)

Я не думаю, что так будет и дальше. В качестве временного решения можно отдать все свои данные Google, Facebook, или любому «облачному» сервису, но такое решение оставляет желать лучшего (и перечисление причин это другое отступление).

Программное решение проблемы управления вычислительными ресурсами и объединения всех этих машин (локальных и удалённых) неизбежно. По крайней мере в данный момент я вижу Inferno лучшим кандидатом на роль платформы, которая сделает всё это возможным. Если это и не полностью объясняет, почему я вдруг влюбился в эту систему, то, по меньшей мере, делает это частично.

Продолжение следует


Это описание очень поверхностно. «Всё является файловой системой» это только одна из великих идей, на которых построена Inferno.
Метки:
Поделиться публикацией
Похожие публикации
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 32
  • +5
    Если кому интересно, в блоге автора этой статьи есть ещё большая статья по инферновскому шеллу: debu.gs/entries/inferno-part-1-shell (я её переводить не планирую).
    • 0
      Простите, но ваша ссылка на FAQ ведет не на FAQ, а на каталог статей.
      • 0
        Разве ссылка на FAQ? По-моему ссылка на вопросе «Что такое Инферно». А каталог статей — это ответ. ;-)
        • –2
          Каталог статей — не ответ на этот вопрос.
          • +4
            Ну, какой есть. Другого ответа пока нет. Вот как напишет кто-нить внятный и короткий ответ в пару абзацев — буду ссылаться на него.
      • 0
        Если честно, то за вычетом функционала «скрытия» (для замены chroot), всё остальное как-то не особо водушевляет.

        Особенно я не понял, как это так лихо разобрались с nfs.
        • +3
          В ядро инферно встроен сетевой протокол для доступа к файлам (тот самый 9P2000 a.k.a. Styx), это одна из ключевых составляющих инферно. Он используется для доступа и к локальным и к удалённым файлам. Соответственно, никаких дополнительных протоколов или утилит для расшаривания файлов по сети, вроде NFS, не требуется.
          • +1
            И он настолько хорош, что может заменить собой NFS? Не в теории «а мы тоже можем через сеть ходить за файлами», а в реальной боевой нагрузке? Как этот протокол себя ведёт при массовом конкурентном доступе от приложений в сетях 10G (и выше?) Как разруливаются файловые блокировки при перезагрузке сервера?

            Если эта штука реально крута — рассказывайте, потому что NFS и CIFS всех утомили, но лучше пока файловых протоколов не известно.
            • +1
              Насколько мне известно, под высокими нагрузками 9P ведёт себя точно так же, как и под низкими.

              Файловые блокировки не разруливаются никак по причине их отсутствия. Никакого flock(2) в инферно нет. При необходимости они легко реализуются множеством способов, и разруливание при перезагрузке будет зависеть от деталей реализации.

              Что касается использования 9P в качестве замены NFS/CIFS для поднятия банальной файлопомойки, то здесь есть одна проблема. Основной (он же вроде бы единственный, если я ничего не путаю) недостаток 9P это высокая latency. Исправить сей недостаток достаточно проблематично, т.к. по хорошему это вовсе не недостаток, а особенность протокола.

              Дело в том, что 9P всё-таки в первую очередь заточен для доступа к любым файлам, что в частности подразумевает файлы синтетические, файлы устройств в /dev, etc. Поэтому операция, к примеру, чтения файла выглядит так:
              1. клиент вызывает read(2) и блокируется в ожидании возврата из системного вызова
              2. ОС клиента отправляет пакет по протоколу 9P на сервер, откуда подмонтирован читаемый файл
              3. ОС сервера получает пакет 9P и передаёт его файл-серверу (это может быть и драйвер физической файловой системы и любое приложение файл-сервер)
              4. Файл-сервер анализирует полученный запрос на чтение файла и принимает решение — вернуть ошибку или данные
              5. ОС сервера отправляет пакет 9P с ответом
              6. ОС клиента получает пакет 9P с ответом
              7. клиент выходит из системного вызова read(2) получив данные либо ошибку переданные файл-сервером
              Суть описанного процесса в том, что пока клиент не получит ответ на первую операцию read(2), он не может послать следующую. А чтобы получить ответ нужно как минимум потратить 2*RTT времени, не зависимо от того, считывается 1 байт или 1 мегабайт. И реализовать какое либо кеширование и опережающее чтение в этих условиях проблематично. Более того, с синтетическими файлами любое кеширование и опрежающее чтение может привести к совершенно непредсказуемым результатам.

              Насколько я знаю, предпринималось как минимум две различные попытки решить эту проблему, но насколько они были удачны в плане сравнения производительности с CIFS я не помню.

              Лично я не вижу никакой проблемы в том, чтобы продолжать использовать CIFS для файлопомоек, и использовать 9P2000 для всего остального, где нет необходимости в выжимании максимальной скорости при передаче гигабайт данных. К примеру, одна из очень приятных особенностей 9P2000 заключается в том, что сам факт завершения системного вызова write без ошибки гарантирует что файл-сервер получил отправленные данные (в отличие от традиционных ОС, где завершение write не говорит вообще ни о чём — данные могут быть в исходящем буфере ОС отправляющей стороны или во входящем ОС принимающей стороны, а приложение куда они отправлялись может их так и не увидеть).
              • 0
                Были небольшие и кстати простые(как и многое в inferno/plan9) проекты направленные на попытку решения проблемы latency в styx/9p2000 – введением дополнительных команд tstream/rstream — например Extending 9P to include HTTP-like streams (было на 5th International Workshop on Plan 9). Подозреваю что проблема просто напросто в том чтобы стандартизировать данное расширение 9p и внедрить во все проекты где styx/9p уже в пользовании.

                Так что latency на самом деле не такая уж и большая проблема.
                • +1
                  Если оно не умеет параллельного IO, то его можо уносить, NFS оно никаким образом не заменит.

                  Поясняю: мы открываем файл и запускаем 30 параллельных процессов, делающих IO с этим файлом. Если это не возможно, то практической пользы от протокола — не много больше, чем от sshfs — пользовательский уровень покрывает, системный — нет.
                  • +1
                    Хм. А с чего Вы решили, что это не будет работать в инферно? Все эти параллельные запросы придут на файл-сервер, во всех запросах по определению будет смещение в файле для текущей операции чтения/записи, и никаких проблем не возникнет.
                    • 0
                      То есть random io от многопоточного приложения будет обрабатываться нормально? Тогда я хочу увидеть это в жизни.

                      Просто для информации: сетевой оверхед от scst (iscsi target) неощутим до 20k IOPS, для NFS я ещё серьёзных тестов не делал, но там примерно такие же показатели.

                      Речь про IO внутри открытого файла, разумеется.
          • 0
            С другой стороны, поскольку пространство имён общее для всей системы, вам требуется быть root чтобы изменять его.
            Мне хватит и pam_namespace. Ну и fuse для монтирования всего без рута.

            9p2000 это, конечно, круто, но обычные файловые системы в *nix заметно быстрее для типичных задач.
            • 0
              Inferno и plan9 очень клевые ОС. Когда впервые узнал про plan9 был поражен его красотой и простотой. Был некий русскоязычный сайт с хорошей документацией, постараюсь найти ссылку. Там описывалось очень много всего интересного. Например (про план):
              — отлаживать можно не просто на удаленной машине, а машине с другой архитектурой. Стандартными средствами. Просто импортировав к себе /proc.
              — ps и top- просто скрипты, читающие /proc
              — rio — оконная система в plan9 — требует для работы файлы устройств клавиатуры, мыши и экрана (и еще чего то, не помню). Своим клиентам (gui приложениям) она предоставляет их же. В результате можно запускать рекурсивно, и для этого ничего не требуется.
              — tcp/ip — тоже фс, можно сделать какой нибудь cat сайта и разобрать полученное shell скриптом.

              А еще идеи plan9 развили еще дальше — см. lsub.org
              Там и элементы gui тоже фс. Или как вам включение света в комнате через. Echo on > /rooms/234/light/top?
              Советую сходить посмотреть демки.
              Буду не с мобилки — напишу еще.

              P.s. жаль что обе ос не особо распространены. Думаю что inferno был бы отличной мобильной ос.
              • 0
                jfyi, в обычном линуксе ps тоже парсит только proc.
                • 0
                  Ну да, разницы почти никакой. Разве что… реализация инферновского ps содержит 61 строчку в одном файле, а линухового 5793 строк в 8-ми файлах.
                  • 0
                    А 18 листов опций (в man'е) для ps обрабатываются 61 строкой? Или сравним таки c ps в busybox'е, которая широтой опций не отличается?
                    • 0
                      Да не вопрос: в ps busybox-а 799 строчек.

                      Что касается 18-ти листов опций, то это проблемы индейцев. Им ещё в 1983 пытались объяснить, что так делать не надо.
                      • 0
                        Я рад, что они не послушались. Потому что сейчас coreutils в линуксе позволяют решать довольно обширный класс задач быстрее, чем на любом языке программирования.
                      • +1
                        powerman прозрачно намекает что 18-ть листов опций это черезчур, а вот в решении практических задач всегда найдется что-то невнятное что потребует необходимость еще одной новой опции для ps — a вот тут внимательно посмотрите на выбор - взять исходник ps длинной 61 строк и за пару минут получить нужный результат под ваш проект или взять 5+K строчек кода ps и пытаться их подрихтовать под нужное за дни или недели при этом посылая ментальные лучи разработчикам coreutils.

                        Ps в inferno возможно избитый пример, но как раз подобный подход относится ко всем утилитам, модулям, кодам в inferno os в целом.
                      • 0
                        Я посмотрел на эту 61 строчку — я не очень их «b» понимаю, но, кажется, эта штука не способна даже ps -faux нарисовать, не говоря уже про всё остальное.

                        А если мне процессы нужно вывести, то это можно и проще:

                        for a in /proc/[1-9]*;do echo `cat $a/cmdline`;done
                        • 0
                          Ну, давайте сравним:
                          $ ps faux
                          USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME 
                              COMMAND
                          powerman 12472  0.0  0.0   7352  1100 ?        S    22:04   0:00 
                              sshd: powerman@pts/5
                          powerman 12491  1.2  0.0   5500  2156 pts/5    Ss   22:04   0:00 
                               \_ -bash
                          powerman 12546  0.0  0.0   4392  1044 pts/5    R+   22:04   0:00 
                                   \_ ps faux
                          
                          $ emu-g
                          ; ps
                                 1        1   powerman    0:00.0    release   143K Sh
                                20        1   powerman    0:00.0       recv   147K Mntgen
                                21        1   powerman    0:00.0        alt    13K Nametree
                                22        1   powerman    0:00.0    release    77K Styx
                                65       64   powerman    0:00.0        alt    34K Cs
                                66        1   powerman    0:00.0      ready   142K Ps
                          

                          • USER — выводится
                          • PID — выводится
                          • %CPU, START, TIME — выводится только TIME, да и тот работает только в native инферно, а в hosted там всегда 0 если я не ошибаюсь. В любом случае, к функциональности самой команды ps это имеет слабое отношение.
                          • VSZ, RSS — выводится, просто в инферно нет разделения на VSZ и RSS
                          • %MEM — а оно нужно? учитывая, сколько килобайт памяти используют все инферновские приложения? мегабайтами память в инферно могут жрать только ваши собственные приложения, и это не сложно увидеть без всяких процентов
                          • TTY — в инферно такого понятия нет
                          • STAT — выводится
                          • COMMAND — выводится; что до псевдографики, то вместо неё выводится ID группы процессов (вторая колонка), он же PID главного процесса в группе

                          Как по мне, функциональности инферновского ps более чем достаточно.
                          • 0
                            'f' рисует кто кого породил. Когда разбираешься в зоопарке сложной системы, очень помогает.

                            Вторая важная опция — T — показывает треды.
                            Ещё одно важное — это -s, позволяет разбираться кто там что где забыл на сервере запущенным.

                            То есть аргументировать «да нафига все эти опции сдались», можно, но это будет в категории «мне хватает для игрушек, а что вы там для работы юзаете, меня это не касается».

                            «Свои» приложения часто бывают тоже в большом количестве и видеть быстро, что приложение съело не те ресурсы, что ему положено, весьма удобно.
                            • 0
                              Кто кого породил видно по ID группы. Если нужно нарисовать псевдографикой — ну значит либо сами напишете, либо Вам инферно не подходит по причине отсутствия псевдографики в выводе ps. :D

                              В инферно нет разделения на процессы и нити, так что то, что вы видите в выводе ps — это и есть нити.

                              -s — в моём Gentoo не работает. Это что вообще и для чего?

                              Аргументировать «нафига» это, конечно, не вариант. Но помимо «нафига», есть ещё такое понятие как «misuse». При разработке Инферно была решена сложнейшая задача: реализовать всю необходимую функциональность сохранив простоту — как архитектуры, так и реализации. Инферно даёт Вам всё необходимое для того, чтобы писать абсолютно полноценные и функциональные приложения очень просто. Безусловно, если проигнорировать эту возможность, и начать писать под инферно традиционный переусложнённый раздутый софт — через некоторое время Вам действительно понадобятся 18 листов опций для ps, чтобы хоть как-то управлять созданной Вами сложностью. Но вины инферно в этом не будет.
                              • +1
                                Не понимаю патетики высказывания. Примеры крупных product-исталляций есть?
                                • 0
                                  Э… в чём Вы там патетику углядели?

                                  Некоторые примеры использования инферно можно увидеть здесь: inferno.execbit.ru/wiki.wsgi/Реальное%20применение%20Inferno У нас в проекте инферно крутится на некотором кол-ве сервисов на 4-х серверах, под весьма высокими нагрузками. В maillist-е и на IRC народ упоминал ещё довольно много проектов на инферно, но продакшн это или просто эксперименты я не знаю.

                                  Безусловно, это мизер. Пока про инферно мало кто знает — никто не рискнёт внедрять её в продакшн. А пока её не внедрят в продакшн в значительном кол-ве мест — про неё никто не узнает. Проблема курицы и яйца. Обычно решается поднятием маркетингового хайпа вокруг системы, но в случае инферно её разработчики предпочитают тихо сидеть и работать с системой, а не заниматься её раскруткой.

                                  Даже я и то почти пять лет внедрял её крайне осторожно и точечно в нашу систему, т.к. не был уверен не вылезут ли где-нить проблемы с производительностью или надёжностью, активно тестируя чуть ли не каждую фичу перед использованием. И только недавно принял решение, что все тесты пройдены успешно, работает она отлично, и можно приступать к массовой замене текущих Perl+libev сервисов на инферно.
                                  • 0
                                    Ну, я бы хотел посмотреть на неё в условиях боевой нагрузки (условно — больше гигабита входящего трафика).

                                    Для этого, видимо, надо начать с поддержки приличного серверного оборудования. ixgb/ixgbe портирован? aacraid/mpt2sas?
                                    • 0
                                      Я не понимаю, для каких задач Вы хотите её использовать? Как замену линуховому файрволу/роутеру на шлюзе? Возможно native инферно и может что-то в этом духе, не знаю, я этот вопрос не изучал и с native инферно не работал, но я сомневаюсь, что это является подходящим use case для инферно.

                                      Как я уже упоминал, я просто пишу под инферно софт, фактически использую инферно как альтернативу для Perl или Java. Подумайте, насколько осмысленно звучат Ваши вопросы в отношении, например, JavaVM… Написать приложение на Java или Inferno которое будет как-то осмысленно обрабатывать гигабит входящего трафика, возможно, и получится. Смотря как обрабатывать и на каком железе. Но при чём тут портирование ixgb/ixgbe/aacraid/mpt2sas?
                                      • 0
                                        Ну, например, в качестве головы для раздачи дисков виртуальных машин. Примерные ожидания — поддержка кластеризации, способность обработать ~100k прерываний в секунду от оборудования, раздать (file/block io) 1-3 Гбит/с.

                                        Это даже не совсем highload, но не «рутер».

                                        ЗЫ Может я неправильно понимаю, inferno — это ОС или нет? прерывания, кольца защиты, виртуальная память, переключение процессов, скедулинг, свопинг, стек блочных устройств, сетевой стек… Что там ещё от казуальной ОС ожидают?
                                        • 0
                                          Прерывания — точно не скажу. Наверное, на уровне native ОС они есть, иначе она бы не работала. Но в user-space никаких прерываний нет.

                                          Колец защиты и виртуальной памяти нет. Вся память плоская и доступна всем процессам (защита памяти обеспечивается сильной типизацией, я об этом уже писал).

                                          Переключение процессов есть. Скедулинг — это что? Планировщик процессов (scheduler)? Есть.

                                          Свопа нет.

                                          Стек блочных устройств — поскольку устройство это просто файл в /dev, то стекирование этих устройств реализуется обычными файл-серверами в user space. Есть ли готовый файл-сервер, например, для реализации software RAID — я не знаю, никогда не интересовался.

                                          Сетевой стек есть, хотя используется он скорее всего только в native Inferno, а hosted использует стек основной OS.

                                          В общем, да, Инферно это ОС. И нет, это не альтернатива линуху на сервере или винде на десктопе. Да, Инферно работает и на встроенных устройствах и на суперкомпах вроде Blue Gene. Вероятно это означает, что, да, её можно запустить и на обычном сервере. Только вот смысла в этом скорее всего нет, т.к. для решения задач стоящих перед обычными серверами гораздо лучше приспособлены традиционные ОС, и возможностей инферно не хватит для решения этих задач. На обычных серверах/десктопах инферно имеет смысл запускать в hosted режиме как обычную VM (вроде JavaVM, а не VMware VM :)) или сервис.
                                          • 0
                                            ок, оно ближе к понятию платформы, чем ОС, я понял. Только просьба тогда с юниксом не сравнивать, ибо классы решаемых задач разные.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.