Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2009-09-09 23:19:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Фантом раз, фантом два...
     Я всё о Фантоме. Который "от dz".

     ОС Фантом настолько сурова, что в ней нет файлов. Документ, с которым в данный момент работает пользователь, даже в обычных операционках во время работы не "лежит на диске", а висит в памяти в виде пучка объектов. Система (Фантом), в силу, тсзть, дизайна, гарантирует долговременную сохранность состояния приложения (и, естественно, всей этой грозди объектов) - а раз так, то как бы нет потребности эту гроздь объектов переливать из одной формы (память) в другую форму (последовательность байт), и обратно. Привязали к этой грозди иконку на десктопе - пользователь кликает иконку, у него всплывает документ - красота, и никаких файлов!
     С точки зрения dz, отсутствие файлов, а равно и отсутствие необходимости чего-то куда-то сохранять, есть плюс разработчикам: не надо писать процедуру разборки "внешнего" формата "документа" во внутренний формат "как оно лежит в памяти", не надо писать обратную процедуру - сборки внутреннего представления в поток байтиков. И это как бы верно. Если бы не одно "но" - даже сам dz понимает, что без файлов, собственно, обойтись всё равно не удастся - мир вокруг, увы, слишком завязан на "одномерные потоки данных", и даже при передаче документа между двумя "фантомами" в промежутке может возникнуть какой-нибудь ужас, типа флэшки с FAT'ом, электрописьма с аттачем, или банального веб-сайта с пипкой "download". И тут-то файл и понадобится.
     Но это фигня! Если документ - не более чем "состояние приложения" (т.е. фактически множество объектов, принадлежащих приложению, плюс совсем чуть-чуть служебной информации, а может быть и без неё), то сохранение/загрузку документа можно сделать единообразным образом, и вообще поручить её системе: нужно сохранить документ - просим систему сделать "дамп состояния программы", нужно загрузить - просим "восстановить состояние из дампа". Дамп - обычный файл, который можно передавать куда надо, разработчику приложения думать ни о чём не надо - достаточно дёрнуть ровно одну ниточку в системе, а бонусом - вместе с документом при этом автоматом будет сохраняться всякая приятная мелочёвка типа undo-буфера и запомненных строчек в полях ввода. Недостатки тоже есть, но они решаемы :-)
     Есть только один нюанс. Для того, чтобы сохранять "гроздь объектов" - вовсе не нужен фантом. Никто не мешает приделать такую возможность к любому современному "объектно-озабоченному" языку. Более того - в принципе это приделываемо к любой программе, необязательно "объектно-ориентированной" - просто "объектом" там будет нечто другое. И мы поимеем один из бонусов фантома (заментый, правда, скорее разработчикам чем пользователям), не имея собственно фантома.

     Второй бонус Фантома (заметный пользователю, а не разработчику) - возможность "упасть-отжаться": прозрачное (без остановки приложений) постоянное "автосохранение" мгновенного слепка состояния системы (и приложений). Радость при этом в том, что даже при внезапном пропадании электричества - теряется не "вся работа с момента последнего сохранения", а только последние несколько минут, а то и секунд: после загрузки системы она восстанавливается по состоянию "на момент последнего снапшота". При этом для снятия снапшота, напомню, не требуется остановка приложений.
     Как это реализовано - особо не афишируется. Но, как мне кажется, особо фантазировать не получится. В момент начала снятия снапшота мы выставляем всем "объектам" флажок "не сохранён". Далее - бежим по всем объектам, сохраняя их, и сбрасывая флажки. Если приложение хочет изменить (записать в) какой-то объект, помеченный как "несохранённый" - система автоматически делает copy-on-write - дублирует объект, приложение начинает работать с объектом, а система, когда дело доходит до сохранения именно этого объекта, сохраняет копию (и убивает её - у нас остался оригинал). На самом деле всё чуть сложнее - снапшоты надо делать инкрементально (т.е. к объекту привязать что-то вроде dirty flag, и при его чистоте - не пересохранять объект, а делать ссылку "старая копия вполне годна"), снапшота должно быть два - один "в стабильном состоянии", второй "в процессе сохранения", а "флажки сохранённости" необязательно тупо переворачивать у всех объектов, достаточно в начале цикла сохранения переопределить их интерпретацию на противоположную. Впрочем, это подробности.
     Многие программы сами имеют функцию автосохранения. Полезную - когда документ небольшой, и жутко раздражающую, когда документ разрастается на сотни мегабайт и сохраняется минутами. Раздражающую ровно потому, что на время сохранения программа блокируется - действительно, сложно одновременно сохранять текущее состояние, и вносить в него изменения.
     Однако - опять вспомним фантом. Ничего не мешает делать фантомовское "прозрачное сохранение" в пределах одного отдельно взятого приложения. Механизм тот же - сохранение всего по кругу, CoW для несохранённых объектов при попытке их изменения, инкрементальность сохранения. После этого "автосохранение" в данном приложении начнёт работать волшебным образом: если я сижу и набираю текст (изменения - не более десятков байт в секунду) - автосохранение будет успевать сохранить изменения буквально в реальном времени, и только если я делаю большие изменения - автосохранение будет "отставать" на заметное время. В любом случае меньшее, чем обычное автосохранение всего документа "раз в пять минут", и не блокирующее на это время приложение. А заодно и обычное, не автоматическое, сохранение станет халявой: просто прекратили изменять документ, дождались конца цикла автосохранения, выдали окошко "всё ок" :-)
     Правда, есть нюанс: для достижения такого счастья в обязательном порядке понадобится поддержка со стороны языка программирования (среды выполнения, возможно даже системы). Поскольку, как мне кажется (могу ошибаться), на современных языках подобные извраты с CoW естественным образом не пишутся, а противоестественные методы - угробят идею в зародыше. Но, опять же, это возможно и без создания новой ОС - модернизацией уже существующих.

     Поэтому, я так подозреваю, где-нибудь в windows 8 или windows 9 мы вполне можем обнаружить "бессмертные" приложения или "прозрачное" сохранение. Файлы, надеюсь, останутся на месте: микрософт - не Завалишин, на такие радикальные меры не пойдёт :-)


(Читать комментарии) - (Добавить комментарий)


[info]raphaeel@lj
2009-10-18 14:44 (ссылка)
Скорей уж идеи фантома реализуются аппаратной революцией. Когда будет большой-большой и быстрый-быстрый флеш-диск. Которому будет без разницы, в каком режиме работать - в режиме диска или в режиме ОЗУ. Предвижу 10ТБ озу размером с коробок с запоминанием состояния при отключении питания =)

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 15:17 (ссылка)
Ну, это отдельное направление. Хотя по-моему вполне реальное уже сейчас. Правда с небольшим обманом: если приставить к (быстрой но дорогой) оперативке небольшой аккумулятор, контроллер, и эквивалентный объем флэш-памяти (медленной, но дешевой) - это будет выглядеть, как если бы оперативка в самом деле не теряла бы состояние при выключении :-) До 10Тб, впрочем, в любом случае ещё очень и очень далеко.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-10-18 16:09 (ссылка)
Подумал, что наверное не совсем верно исходить из позиции - давайте выкинем файлы и потом будем мучительно решать возникшие проблемы. Стоит посмотреть с другой стороны - что такого плохого в них?

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

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

Например чтение jpeg в документ:

File file("filename.jpg");
IImage image = (IImage)file; // спрашиваем интерфейс IImage
if(image == null)
return this_is_not_image;
BitMap bitmap = image.bitMap();
Document doc = new Document;
doc.resetBitMap(bitmap);

Запись в jpeg:

File file("filename.jpg");
Jpeg jpeg(doc.bitMap());
file.serialize(jpeg);

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 16:30 (ссылка)
А ты на меня подписан что-ли - так быстро реагируешь? Если да - это подписка средствами ЖЖ, или средствами, скажем, яндекс-блогов?

Я в общем-то полностью согласен: от файла отказаться не удастся по ряду причин (начиная с того, что без файлов сможет прожить только сферический фантом в вакууме, при взаимодействии с внешним миром "консервы объектов" так или иначе понадобятся). Ну и да - единообразный метод консервации/расконсервации дерева объектов (с возможностью указать, что из дерева можно выбросить как легковосстановимое) - был бы более полезен, чем отсутствие файлов. Более того, при наличии такого единообразного метода - проблема совместимости между версиями программ решалась бы проще: новая программа читает "из консервов" старые версии объектов, которые очень похожи на новые, только надо заполнить несуществующие поля "дефолтными" значениями, а старая программа - читает только в свои объекты только то, что сама знает, остальное игнорируется...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-10-18 16:40 (ссылка)
На этот пост я трекинг ставил, кроме того еще RSS пл поиску в yandex блогах.

Технически можно обойтись без дефолтных значений. Например старый Word будет работать с документом через интерфейс IWord2003, а новый через IWord2007 и т.д. Собственно в COM это уже давно есть, только несколько тяжеловесно. В новых языках типа C# подобное делается очень легко, любой класс может реализовывать произвольный набор интерфейсов.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 17:06 (ссылка)
Насчет интерфейса не очень понял. Приношу я файл (сериализованное дерево объектов) на соседний компьютер, запускаю ворд, и?.. Скажем, новый ворд попросили загрузить файл от старого. Какой интерфейс он дёрнет, как этот интерфейс разберется со "старыми" объектами?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-10-18 18:01 (ссылка)
Я думал немного с другой стороны и это не обдумал. Я просто предстваил как бы это выглядило в программе - мы из файла запрашиваем объект нужного типа и далее с ним работаем. Какие-то функции объекта возвращают другие объекты, которые и образуют этот самый граф.

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

Кстати, а где должен быть весь исполняемый код объектов? Если в файле, то он может непомерно разрастись, представляешь код word в каждом документе! Нужно сериализовать только данные и привязываться в рамках глобального namespace (аналог GUID из COM) (многие проекты кстати приходят к необходимости подобного) к коду объекта, который может существовать в единственном экземпляре отдельно. Это наверное правильно, т.к. не превратит файлы в рассадник вирусов, код будет централизованно контроллироваться. Функции преобразования объектов разных версий тоже где-то находятся снаружи. Можно придумывать какие-то способы упростить миграцию, чтобы программисту было легче, но суть не поменяется, если меняется архитектура, то без копирования представления в старый/новый формат наверное не обойтись. В коммерческом софте часто начинают убивать COM интерфейсы старых версий через некоторое время или начинают блокировать некоторые функции, и это происходит не только от лени разработчиков, а из-за того, что старое слишком идет в разрез с новым.

Вобщем контроль версий всегда был проблемой и волшебного рецепта тут нет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 18:27 (ссылка)
Код объекта, конечно, не в файле - нечего коду делать в "переносной" версии объекта.

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

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

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ilya_314@lj
2009-10-18 18:44 (ссылка)
Согласен с тем, что упрощать эту часть нужно, но это все равно не снимает с разработчика заботу о совместимости.

Вспомни "dll hell" (http://en.wikipedia.org/wiki/DLL_hell). Одна из причин проблемы - казалось, что можно подменить код сохранив версию и все заработает. Оказалось, что в реальном мире все не так, даже если была ошибка, то лучше ее оставить, чтобы все не осыпалось. Каждой версии свой экземпляр кода, собственно это сейчас и сделано в папке WinSxS. Поэтому идея микса может быть несколько утопичной.

(Ответить) (Уровень выше)


[info]raphaeel@lj
2009-10-18 16:45 (ссылка)
А вы не думаете, что вы путаете "отсутствие файлов" как концепцию взаимодействия компьютера и пользователя (где файл конечно-же нужен) и принцип работы самой ОС, с точки зрения программиста?

Я так понимаю, что ОС без файлов вполне может существовать. Мне в голову приходит пресловутая winfs, в которой (если я правильно помню) файлов как таковых не было, а были записи в БД, которые юзер уже воспринимал как файлы.

Мне кажется, что в фантоме речь идет так-раз о последнем. А по поводу железного решения проблемы - новые типы памяти совмещающие современные dram и flash = возможности фантом. И мне почему-то кажется, что железный путь перспективнее и реальнее.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 17:04 (ссылка)
Я не путаю, я смешиваю :-)

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

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

А про новые виды памяти я слышал уже давно. Вот только пока не видел вживую, и не очень верю что в ближайшие годы увижу "на столе". Ибо чтобы оно прорвалось "на стол", нужно чтобы оно было не медленее обычной памяти, и не слишком уж сильно дороже...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]raphaeel@lj
2009-10-18 17:35 (ссылка)
Вот и разобрались ;) Что видно программисту не всегда видно пользователю. А что по поводу памяти, я года три назад и не думал об SSD памяти, которая в разы быстрее чем HDD. А она бац - уже на столах. Так что шансы есть ;)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-10-18 17:44 (ссылка)
Ну, в моей окрестности SSD пока либо медленные, либо жутко дорогие. Либо смешного размера :-) Поэтому попадаются больше не "на столах", а либо в портативных дивайсах (где не важна скорость), либо в каких-то спецприменениях (где не важна цена).

Но шансы есть, да.

(Ответить) (Уровень выше)


(Читать комментарии) -