Это направление более или менее неизбежно. По крайней мере я не вижу ни одного конкурента ему — ни у нас, ни у Microsoft, ни у кого бы то ни было в мире. А уж выиграет при этом «Фантом» или другая ОС того же класса — это, к сожалению, вопрос зависящий больше от финансирования, чем от идеи.
- Хорошо, про то, какие преимущества «Фантом» даст встроенным решениям, вы уже сказали. С серверами ситуация сложнее?
- На самом деле, нет, не сложнее. Вторая область, где мы можем показать преимущества «Фантома» в ближайшее время — это как раз серверы. То есть какие-то веб-системы, причём распределённые. Современные программирование уже не предполагает обособленных программ. Почти всё, что сейчас делается — это вещи, которые так или иначе ввязываются в существующую инфраструктуру. Достаточно зайти на любой проект, чтобы увидеть кнопочки «Твиттер», «Фейсбук», «Живой журнал» и т.п. Это простой пример того, что обособленно жить уже нельзя — всем требуется среда, которая легко поддерживает не просто компонентное программирование, а уходящее во врешний мир.
Мы считаем, что здесь у нас есть хорошие шансы, особенно — в разработке не очень масштабных систем. Условно — систем, которые делаются на коленке тремя программистами. То есть небольшие разработки, которые, как правило, сегодня делаются на PHP плюс MySQL. Здесь мы можем предложить PHP без MySQL. PHP и MySQL популярны, потому что их легко изучить. Если выкинуть MySQL, изучать будет ещё вдвое легче. В этом месте у нас есть шансы, хотя есть и конкуренты. Существуют среды, которые реализуют сходную с «Фантомом» персистентную функциональность не в рамках ОС, а в рамках отдельного приложения.
- Можно ли «Фантом» применять для распределённых вычислений и виртуализации?
- Можно, конечно, загнать под него монитор виртуальных машин, но я не вижу больших причин этого делать. Я не вижу особых проблем в мире виртуализации — там всё хорошо, и нам помогать нечему. Хотя к нам приходил как-то человек, который рассматривал «Фантом» как некоторое средство виртуализации, и в некотором смысле мы и будем им являться, потому что среда Linux в «Фантоме» отчасти имеет характер виртуальной персистентной среды.
Та среда Linux, которую мы собираемся сделать — она будет отличаться от обычного Linux тем, что запущенные в ней программы не будут «видеть» перезагрузки операционной системы. Это попытка сделать очень совместимую на уровне исходного кода среду, но при этом с плюсами «Фантома».
Однако когда я говорил про среду разработки в рамках нескольких компьютеров, я имел в виду несколько другое. Мы хотели бы в рамках «Фантома» реализовать достаточно прозрачный механизм дистанционного доступа к объектам на другой машине и миграцию объектов.
Я приведу пример, который в «Фантоме» можно будет реализовать не скоро, но идеологически он достижим. Вы садитесь за компьютер и начинаете работать с некой программой — не важно какой — к примеру, рисуете в CAD-е какой-нибудь проект. Он реализован как множество объектов, которые описывают проектируемую вами систему, вы видите в окне представление этой системы и работаете с ним. Поработав, вы собираетесь поехать на дачу. Вы берёте окно (подчёркиваю — окно!), кладёте его в письмо и отправляете себе на дачный компьютер. Когда вы приезжаете туда, вынимаете из письма окно, и начинаете с ним работать. Но при этом окно у вас здесь, а объекты — там.
К тому же компьютер вполне в состоянии обнаружить, что ситуация изменилась, и те лежащие дома объекты на самом деле используются с дачи. Среда в состоянии передать их вам. По мере того, как вы будете с ними работать, они будут переползать на машину, с которой вы работаете. Если вы долго проработаете, они соберутся там. Уехали в Швейцарию к другу? Они приедут за вами по мере необходимости.
Это, кстати, ответ на вопрос о том, не выйдет ли завтра так, что стоящий на рабочем столе компьютер не будет ничего содержать, а всё станет жить в сети. Может быть. Но к этому мы тоже в известной степени готовы. К тому же, какая бы сеть хорошая ни была, всё же близко находящееся эффективнее, и эта схема миграции кажется мне осмысленной и актуальной.
Даже если что-то живёт в сети, давайте мигрируем к вам то, чем вы реально сейчас пользуетесь. Поработаете с этим, дальше оно прозрачно уедет обратно. Не обязательно заставлять программу бегать непосредственно на дальний компьютер за каждым обращением к объекту. Если вы с ним работаете, можно принести его, поработать и вернуть обратно. Это достаточно эффективно — и с точки зрения нагрузки на каналы, и с точки зрения реактивности работы программ.
- Наш разговор плавно перешел к настольным применениям, но я бы сперва хотел поговорить о портативных устройствах. Сейчас активно обсуждается, как должна быть сделана многозадачность на устройствах с ограниченным количеством памяти и энергии. К примеру, в iOS 4 используется хитрая схема, позволяющая программам сперва замораживаться, затем закрываться, когда памяти не хватит. Если бы использовалось ядро «Фантома», это можно было бы сделать легче и очевиднее?
- Дело в том, что то, что вы сейчас описали, совершенно штатная ситуация для «Фантома» — там для этого не нужно предпринимать никаких специальных усилий. В отличие от Unix и Windows, в которых существует выраженные отдельные состояния запущенной и незапущенной программы, в «Фантоме» эти состояния размыты и неотличимы друг от друга с точки зрения внешнего наблюдателя. Программы переходят из более активного состояния в менее активное просто по факту того, работают они или нет. Если программа реально не работает, то подсистема виртуальной памяти «Фантома» по мере необходимости в оперативной памяти постепенно вытеснит её в дисковое состояние. Для этого не нужно ничего делать — всё происходит само собой.
То есть то, что сейчас делают разработчики мобильных ОС, у нас есть и так. Кстати, одна из причин, по которой я так уверен в правильности концепции «Фантома», — в том, что очень много частных задач здесь решается в силу естественных свойств системы. Это меня очень мотивирует. Это критерий правильности проектирования базовой идеи «Фантома».
"Фантом" — это же, собственно, программы, которые постоянно и живы и мертвы. Они лежат на диске, но как только они попытаются поработать, то непосредственная попытка обращения к программе приведёт её в оперативную память. Она может поработать частью, и именно эта часть загрузится и поработает. Как только памяти станет мало для программ, и какие-то программы станут пассивными, они вытеснятся из оперативной памяти непосредственно стандартным механизмом планирования ресурсов компьютера.
Единственное, что в случае мобильного устройства таки нужно делать — это, собственно, принимать решение о том, работает программа или нет. С этим ничего не поделаешь — это либо какое-то волюнтаристское решение операционки о том, что какая-то программа слишком много «ест», и давайте её приостановим (но это именно приостановка, а не выгрузка — выгрузка случится сама), либо это решение самой программы о том, что она находится в стеснённой ситуации и лишнего потреблять не должна.
- Переходя к десктопному использованию, представим, что «Фантом» сможет его добиться, и немножко помечтаем. У дизайнеров интерфейсов есть несколько давних мечтаний — что хорошо бы было сделать, но тяжело, и не понятно, кто бы мог это сделать.
- Если вы знаете этих дизайнеров, гоните их ко мне — с удовольствием с ними поговорю. К сожалению, на сегодня видел очень мало людей, у которых есть хоть сколько-нибудь сформулированные мечтания. Общеизвестный Раскин — это наиболее цельный пример. Хоть его представления и находятся на очень глобально-абстрактном уровне.
- Давайте я перечислю наиболее известные примеры, а вы скажете, может ли в этих случаях «Фантом» чем-нибудь помочь. Первое — это избавление от иерархической файловой системы.
- О да! Спасибо вам за этот вопрос. Это же просто мучение, ужас и кошмар. Да, конечно, может, очень хотим и обязательно сделаем. Но здесь есть некоторые проблемы. Во-первых — совместимость с предыдущим поколением пользователей, для которых мы, конечно, стандартное дерево оставим.
Но при этом смотрите, что происходит в «Фантоме»: здесь нет файлов, зато есть объекты. Объекты отличаются от файлов прежде всего тем, что для них можно определить методы — то есть давать им возможность сказать системе, что с ними ещё можно сделать. К примеру, их можно искать по другим критериям; например, их можно по-другому классифицировать, и не одним способом классифицировать.
Даже если брать совершенно прямолинейный уровень: как родным для «Фантома» способом сделать приложение? Приложение — это некоторый класс, реализующий некоторую функциональность. И объекты этого класса являются документами с точки зрения пользователя. Уже сам этот факт означает, что вы можете одним движением найти все документы такого типа.
