Цифровой журнал «Компьютерра» № 24

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

- Наш разговор плавно перешел к настольным применениям, но я бы сперва хотел поговорить о портативных устройствах. Сейчас активно обсуждается, как должна быть сделана многозадачность на устройствах с ограниченным количеством памяти и энергии. К примеру, в iOS 4 используется хитрая схема, позволяющая программам сперва замораживаться, затем закрываться, когда памяти не хватит. Если бы использовалось ядро «Фантома», это можно было бы сделать легче и очевиднее?

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

То есть то, что сейчас делают разработчики мобильных ОС, у нас есть и так. Кстати, одна из причин, по которой я так уверен в правильности концепции «Фантома», — в том, что очень много частных задач здесь решается в силу естественных свойств системы. Это меня очень мотивирует. Это критерий правильности проектирования базовой идеи «Фантома».

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

Единственное, что в случае мобильного устройства таки нужно делать — это, собственно, принимать решение о том, работает программа или нет. С этим ничего не поделаешь — это либо какое-то волюнтаристское решение операционки о том, что какая-то программа слишком много «ест», и давайте её приостановим (но это именно приостановка, а не выгрузка — выгрузка случится сама), либо это решение самой программы о том, что она находится в стеснённой ситуации и лишнего потреблять не должна.

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

- Если вы знаете этих дизайнеров, гоните их ко мне — с удовольствием с ними поговорю. К сожалению, на сегодня видел очень мало людей, у которых есть хоть сколько-нибудь сформулированные мечтания. Общеизвестный Раскин — это наиболее цельный пример. Хоть его представления и находятся на очень глобально-абстрактном уровне.

- Давайте я перечислю наиболее известные примеры, а вы скажете, может ли в этих случаях «Фантом» чем-нибудь помочь. Первое — это избавление от иерархической файловой системы.

- О да! Спасибо вам за этот вопрос. Это же просто мучение, ужас и кошмар. Да, конечно, может, очень хотим и обязательно сделаем. Но здесь есть некоторые проблемы. Во-первых — совместимость с предыдущим поколением пользователей, для которых мы, конечно, стандартное дерево оставим.