Я вот думаю такую систему: сейчас провайдеры ставят независимые магнитные порталы, и то, что есть у одних, не оформлено у других, хотя и есть у кого–то на хабе.

Узлы Prism Tower (так я собираюсь назвать софт портала), стоящие у провайдеров или у энтузиастов, синхронизируют друг у друга афиши и магнитные ссылки. Далее, специальный бот, запущенный внутри всё той же Inferno, сидит на локальных хабах, на которые его натравили админы узла, качает списки файлов юзеров и обновляет статус мёртвости/живости афиш. Если какая–то афиша, созданная на другом узле, имеет TTH, который в нашей сети никогда раньше не появлялся, на портале эта афиша публикуется как только что появившаяся. То есть, юзер одной сети скачал через глобальные хабы или даже через торренты файл у юзера другой сети, третий юзер в третьей сети когда–то давно оформил этот файл — и, вуаля, оно публикуется на портале. Разумеется, должна быть и возможность смотреть неживые афиши. Кроме афиш можно, допустим, иметь ещё и форумы с блогами, или систему распространения видеороликов, если только это не отключит админ узла.

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

Inferno становится актуальной по мере того, как web становится асинхронным. node.js однопоточный, и нужно городить лапшу из обратных вызовов, чтобы воспользоваться асинхронностью. Inferno использует многочисленные зелёные потоки, которые пишутся в синхронном блокирующем стиле. Код получается чистый, более понятный, без ущерба для виртуальной памяти и производительности. node.js имеет проблемы с Windows, Inferno — нет. node.js имеет глобальный сборщик мусора, который к тому же плохо работает с буферами. В Inferno сборщик мусора тоже есть, но основная часть мусора собирается сразу, при достижении счётчиком нуля ссылок. Как результат, Inferno работает гладко, без больших пауз на сборку мусора. Правда, конкретных сравнений производительности у меня нет. Было бы неплохо иметь в этой статье и Inferno тоже.

Позиционирование Inferno как OS и непозиционирование Inferno как web–сервера с зелёными потоками, возможно, было ошибкой, ставшей причиной непопулярности. Те, чьё внимание притягивалось, отворачивались, а те, кто не отвернулся бы, не притягивались.

Вот возьмём, допустим, всё тот же node.js. Mы не видим у него никакого GUI. Просто REPL и всё. Мы пишем на нём web–сервер типа Cloud9 IDE, юзер видит именно красивую web–часть. У Inferno же эта GUI–часть как бы есть, и она ужасна. Inferno позиционировалась как OS, но это хреновая OS. Acme, который позиционируется аргументами, аналогичными пропаганде Emacs, для меня невыносим. Там можно кликнуть по меню и случайно стереть его. Ненавижу такие приколы с интерфейсом. Браузер Charon — что–то с чем–то. Я ему нашёл применение для I2P, а ещё из него реализацию JavaScript выдрали, хоть чем–то, но полезен. Но так вообще, конечно, тяжеловато угнаться за современными браузерами. Однако, если мы не будем смотреть на GUI, а начнём показывать юзеру только HTTP, сайт будет настолько красив, насколько красив дизайн.

Я оценивал Inferno с разных сторон. У Inferno неважная поддержка баз данных. Чтобы работать с БД, нужно запускать отдельный процесс на основной системе, который через ODBC будет работать с БД и по протоколу 9P (Styx) обслуживать процесс Inferno. Это значит, надо ещё и ODBC настроить. В проекте LimboMachine я ещё видел клиент PostgreSQL, не знаю, насколько законченный.

Впрочем, я думаю, это занятие нужно оставить тем, кому зачем–то понадобится интеграция с существующей базой данных, а для внутренних нужд Prism Tower использовать банально файловую систему. В Inferno, как и в Plan9, VFS воистину virtual, а не как в линуксах, все плюшки только для рута. У каждого процесса может быть своё видение файловой системы, процессы могут влиять на это видение, а в системной оболочке есть специальные команды, позволяющие монтировать, биндить и экспортировать по протоколу 9P(Styx) файловые системы. Я думаю, для начала хватит того, что мы будем создавать пустой файл, монтировать KFS и использовать её для хранения данных в формате ключ–значение. KFS защитит нас от особенностей host OS, что касается исчерпания inode, максимальной длины путей, чувствительности к регистру, скорости создания файла и прочего.

Клиент, подключающийся к хабу, будет экспортировать файловую систему так же ircfs. Наверное, этот ircfs и стоит взять за основу. Web–порталы сейчас обычно слабо связаны с хабами, но с таким подходом можно будет из web отправлять в личку сообщения, обозревать шару юзера, чтобы выбрать файл.