Какие именно ключевые слова?

Да первые попавшиеся, имеющиеся на странице по ссылке (т.е. на странице http://dibr.nnov.ru/issue/on-18-01-00.htm). Я взял фразу "Публикация на прошлой неделе полуоформленного описания операционной системы моей мечты вызвала крайне бурную реакцию" - яндекс, бинг и яху её нашли, гугл - не нашёл.

Да, ссылка малоинформативна, используется чисто для привязки даты, когда dz начал говорить о Фантоме.

А идея Фантома хорошая, но в полноценную реализацию особо не верится, зная... хм... личные качества DZ. ;-)

Посмотрим - я тут предсказывать вообще не берусь, вдруг получится :-) Он же, надеюсь, не в одиночку и не "в рукопашную" это пишет.

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

Я сам не очень внимательно вчитывался, поэтому точно сам не скажу. Задачи восстановить задачи по состоянию "ровно в момент падения" не ставится, ибо это и невозможно (без непрерывного сброса всех-всех изменений на диск), стоит задача "восстановиться по состоянию на какое-то небольшое время назад". Для этого состояния сбрасывются - часто (непрерывно?), впараллель работе, но так чтобы не мешать собственно работе (не грузить шину/процессор более чем на N%). Соответственно, на диске всегда есть "удовлетворительно свежее" состояние системы и приложений.

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

Из прочитанного могу выделить это:
http://www.pcmag.ru/club/group/12/blog/164/
http://dz.ru/solutions/phantom/

Второе - это faq по фантому, местами их немного заносит, ну да ладно. Вот ключевой момент из faq:

--- цитата
Q: Но компьютер нужно иногда выключать. Значит, система будет остановлена. А значит — будут остановлены и все программы, нет?
A: Скажем иначе — «приостановлены». Для программ остановка системы выглядит как задержка в работе. Примерно как нажатие кнопки «пауза» на DVD. После запуска системы все программы просто «поедут дальше».
Q: Такое уже есть в Windows, называется Hibernate.
A: Не всё так просто. Hibernate требует от вас специального завершения работы системы — если его не выполнить, то всё пропало. То есть — Windows не может гарантировать программам «вечную жизнь», а значит — программы под Windows приходится писать по-старому. Фантом же способен пережить даже ситуацию, когда компьютер обесточен совершенно внезапно. После перезапуска системы она всё равно восстановится в том виде, который имела за несколько секунд до спонтанного выключения.
Q: Это должно требовать огромных ресурсов? Ведь система вынуждена постоянно «фотографировать» себя?
A: Основное know how Фантома состоит именно в умении дёшево создавать мгновенные снимки состояния системы, не останавливая её и не внося серьёзных возмущений в работу. Тонкость в том, что «фотографирование» должно запечатлеть всю систему на один момент времени — без исключений. До сих пор считалось, что это требует паузы в работе всех программ. Мы нашли способ распределить во времени создание такой «фотографии», при этом оставив её синхронной с точки зрения «внутренностей» системы.
--- конец цитаты

Главная фишка - это именно восстановление и якобы они это делают как-то хитро и достаточно эффективно и при этом четко на заданный момент. Вот тут собственно у меня сильные сомнения. Возьмем телефон - работает скайп, он например еще записывает разговор (доп. нагрузка), вдруг началась синхронизация - как без временных блокировок это сделать, чтобы не было задержек? Вобщем конкретики про это их ноу хау нет. Все остальное весьма прикольно, но является побочным эффектом их модели и это можно реализовать иначе и проще, например - любое ядро + .net сверху и весь софт на .net. Думаю и другие managed среды (java например), а не только .net имеют возможность сериализации и десериализации объектов.

Кстати почему нельзя их замечательную возможность дампа состояния не прикрутить к java или .net?

Я еще совершенно не понял насчет языков программирования - у них какие-то они свои (где-то упоминался како-то странный), типы и объекты вроде в своем формате - это полный привет если это так, но может я не прав.

Ну, я не зна-а-аю... я ж не dz :-)

Можно, например, "консервировать" срезы системы используя что-то вроде copy-on-write - у нас *в памяти* хранится (и потихоньку сливается на диск) мгновенное (замороженное) состояние системы+приложений, а если приложение пишет в ещё-не-слитую память, то содержимое копируется (приложению об этом знать не обязательно), и дальнейшая работа идёт в новой области. Как только все изменения слиты - всё ненужное (скопированное) дискардится, и делается новая "заморозка" состояния: опять изменённые участки памяти сливаются на диск, а попытка записи в ещё не слитый участок вызывает CoW. В результате и приложения не блокируются (происходит CoW и продолжается работа), и на диске будет гарантированно синхронный, хотя и не совсем свежий, дамп.

Но это первое что пришло в голову. Оно заведомо неэффективно (нужно много памяти, сама процедура CoW не особо быстрая), но "решение есть". Значит, есть и какое-то более оптимальное решение...

> Возьмем телефон - работает скайп, он например еще записывает разговор (доп. нагрузка)

А при чём тут "доп. нагрузка"? Компьютер либо успевает, либо не успевает. Оверхед от "фотографирования" обязан быть, чудес не бывает.

> вдруг началась синхронизация - как без временных блокировок это сделать, чтобы не было задержек?

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

> Кстати почему нельзя их замечательную возможность дампа состояния не прикрутить к java или .net?

Ну, я опять не зна-а-аю... :-)
Если их дамп делается примерно так, как описал я - то при прикручивании этого к java/.net придётся как-то предусмотреть обеспечение синхронности памяти и "файлов" - файлы-то на диске апдейтятся независимо. В их системе нет файлов, а значит нет и проблемы. С файлами - придётся её решать. С другой стороны - неразрешимой она не выглядит, разве что несколько более ресурсоёмкой...

Я уже не тебе адресую вопросы, поэтому ничего, что ты не dz :)

COW это нормальное решение и вероятно в большинстве случаев много доп. памяти и не потребуется. Но для этого не нужна новая ОС!

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

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

> COW это нормальное решение и вероятно в большинстве случаев много доп. памяти и не потребуется. Но для этого не нужна новая ОС!

Нынаю. Навскидку я уже сказал - могут быть заморочки с файлами. Решаемые, конечно - мы просто будем считать файл ещё одним объектом, и точно так же делать CoW - но если делать это не внутри ОС, то между приложением (или VM, в которой гоняется приложение) и FS отрастёт неудобная и потенциально глючная прослойка...

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

Я не вижу принципиальных отличий WinXP с запущенным скайпом и впараллель ему, скажем, медиаплеером, и фантомом с запущенным скайпом и фоновым процессом "слива состояния". Почему медиаплеер параллельно скайпу вопросов не вызывает, а слив состояния (идущий равномерно, без блокировок - откуда взяться блокировкам, если запись в неслитую память вызывает CoW) - вопросы вызывает?
Отдельный вопрос - при чём тут вообще риалтайм. WinXP - не RT OS, скайп - не программа управления ядерным реактором, даже если разговор "икнёт" от недостатка ресурсов, никто не умрёт, лишь бы "в среднем" это происходило достаточно редко. Тем более, он и в XP имеет все шансы "икнуть", могу легко спровоцировать ситуацию.

> Сомневаюсь, что подобный механизм нельзя прикрутить к уже работающей среде, проблема файлов вполне решаемая - транзакции для файлов уже давно умеют делать или пусть делают по своему - все файлы это такие-же объекты как и объекты программы.

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

Хотя если "среду" сделать достаточно широкой - чтобы там были все основные программы - то "нативные" файлы будут нужны редко, и это не будет составлять неудобства. Тем более что импорт-экспорт из "объектов" в "последовательность байт" всё равно будет нужна - по почте отправлять, на диск записать. То есть, "фантом фор виндоуз/линукс", как среда выполнения, вполне возможна, и явно проще в реализации. Разве что она будет иметь один сильный недостаток: грузиться медленно :-) Ибо сначала придётся грузить подлежащую ОС, а фантому достаточно поднять с диска (уже загруженный и настроенный) кусок ядра, а остальное вытянется менеджером виртуальной памяти само, по ходу выполнения :-)

>Отдельный вопрос - при чём тут вообще риалтайм

Я в начале задался вопросом - не получится ли слишком большой плата за слив состояния, ведь есть приложения прерывание которых нежелательно. Изначально не видя решения такого снапшота у меня были сомнения не слишком ли дорого это обойдется, но с COW согласен, проблем вобщем нет особых, поэтому вобщем вопрос снят.

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

По их методе можно так - файл = объект с одним полем - массив байт, интерфейс доступа аналогичен обычным операциям. Интересно как они будут переваривать такие объекты размером больше памяти, очевидно подкачка должна иметь место. Для такого типа объектов мы можем снять снапшот, получим наш файл в обычном понимании.

* * *

В целом все туманно и мне кажется что правильнее было продемонстрировать на существующем managed framework свою концепцию, хотя может этого и недостаточно - мы ведь не знаем как оно работает. Но я подозреваю, что достаточно, просто планы наполеоновские.

С транзакциями убедил - поскольку "слив состояния" тоже по сути транзакционен (мы сначала неторопливо сливаем "новое" состояние, не затирая "текущее" (предыдущее), а потом "завершаем транзакцию" - объявляем свежеслитое состояние "текущим"), то в момент такого переключения можно и файл "закоммитить". Раз оно есть и работает, значит можно это заюзать (кстати, бэкап диска "живой" системы в процессе работы системы - идеологически не отличается от бэкапа памяти живой системы при работе системы, и как я понимаю, принцип там тот же - пока не завершён бэкап, изменения пишутся "немного в другое место", а после записи "коммитятся").

Единственный нюанс - атомарность. Вместо одной транзакции (слив состояния) имеем две - состояние и файл, и теоретиццки кнопку "ресет" могут нажать между коммитами состояний, в результате чего получится рассинхронизация.
Но это тоже решаемо: к моменту окончания слива "нового" состояния мы имеем два "живых" состояния - предыдущее и текущее. Помечаем в EA "файла" то, с каким состоянием он синхронен, зовём коммит, дожидаемся завершения, открываем новую транзакцию для файла и начинаем новый слив состояния. В результате в любой момент времени мы имеем "файл", и синхронное с ним "состояние".

Собственно, да - этого должно быть достаточно. Более того, если слово "объект" заменить на слово "блок памяти" (а все эти CoW - они ведь вполне низкоуровневые), то получается что такого рода "неубиваемость" можно просто прикрутить к винде - пусть она точно так же бэкапит память. Можно для отдельных приложений - мне необязательно "поднимать", скажем, браузер - он и сам поднимется если что, а вот какой-нибудь ворд-эксель-корел-фотошоп - не помешало бы :-)

Надо толкнуть идею микрософту. Пусть в windows 8 реализуют :-)

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

сделать свой яп и vm практически проще, чем заэмбеддить готовое. не факт, что правильней, но - проще.

Что проще - спорить не буду, т.к. этот вопрос требует проработки, на которую я конечно не претендую.

Что я понял для себя - реализовать подобное можно и для существующих систем. Вы выбрали свой способ достижения цели и стратегия видимо еще вызвана коммерческой составляющей. Очень большим минусом будет необходимость переписывания софта. Пример iphone конечно показателен, но масштабы Apple - это заоблачные дали, да и в основе там вроде лежит unix, а не что-то совершенно ни на что не похожее.

Так или иначе, удачи!

Спасибо.

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

Переписывать, строго говоря, не нужно - во всяком случае, мы планируем подхватить весь java (+другие JVM-языки) софт, плюс javascript и php. Это - минимальная задача.