Дмитрий Радищев ([info]dibr) wrote,

Фантом раз, фантом два...

     Я всё о Фантоме. Который "от dz".

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

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

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

  • Post a new comment

    Error

    Your IP address will be recorded 

  • 66 comments

[info]malykh

September 10 2009, 04:02:21 UTC 2 years ago

Файлов не было в PalmOS (вместо них упрощенные структуры БД), что, в целом, да, приводило к похожим проблемам. Приходилось использовать конверторы. Сперва на PC, а потом с развитием карт памяти и интернета (источников файлов) стали появляться костыли для динамической обработки файлов на самом устройстве. Ну а потом PalmOS умерла. ;-)

Хотя лично мне файлы не нужны. Единое адресно-объектное пространство гораздо интереснее. А файлы можно рассматривать не более, чем бинарный кусок сериализованных объектных данных. Но там есть и другая проблема. Если мы вдруг начнем меняться данными, то сразу возникнет проблема совместимости этих самых объектных данных. Потому все равно придется делать некоторую объектную модель, облегченную и стабильную между версиями и писать функции импорта и экспорта в нее и внутренней рабочей объектной модели. Будет тот же разбор, создание файлов, только попроще, поскольку вопрос сериализации объектов на себя возьмет ОС. Но и это уже неплохо. ;-)

[info]dibr

September 10 2009, 09:05:26 UTC 2 years ago

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

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

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

Ну, и конечно в каком-то случае (при серьезных изменениях) можно и сломать совместимость. Микрософт так не раз делал, и ничего - как был гигантом, так и остался :-)

[info]malykh

September 10 2009, 10:03:05 UTC 2 years ago

Монотонность структур данных тяжело обеспечить на практике.

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

Так что без своеобразного импорта/экспорта ОО-структур не обойтись, но в этом ничего страшного нет.

[info]avryabov

September 10 2009, 05:35:39 UTC 2 years ago

Файлы - это не только хранение информации.
Это, что гораздо более важно - интерфейс обмена данными между программами и устройствами.
Типа: цифровой фотоаппарат сделал снимок и положил его в файл, чтобы другое устройство (компьютер через флеш-ридер) смог его забрать и обработать. Тогда когда это потребуется и для этого будут ресурсы.
Попытка прибыть самый старый способ обмена информацией - ИМХО дурацкая.

[info]malykh

September 10 2009, 05:56:38 UTC 2 years ago

А кто говорит о прибивании? Одно другому не мешает.
На обмен можно и файлы. А внутри другие структуры.

[info]dibr

September 10 2009, 09:14:21 UTC 2 years ago

Устройства - фигня: вон, жесткий диск тоже устройство, а файлы начинаются несколько в другом месте. Тот же фотоаппарат теоретически может иметь в пузе фантом, и создавать не "файлы типа жипег", а сложные "объекты типа фотка" - это даже логично, ибо уже сейчас фотка - не просто image data, а ещё и куча полей exif, бывает что и разных внутренних форматов.

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

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

[info]rain251

September 10 2009, 05:51:31 UTC 2 years ago

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

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

[info]malykh

September 10 2009, 06:00:46 UTC 2 years ago

Виртуальная память и mmap сейчас в разных ОС работают и не жужжат. ;-) Причем шизофренично работают (одно пытается кидать память на диск, а другое позволяет работать с диском как с памятью).
Проблема возникает тогда, когда опять возникают разные адресные пространства. Мол это память, а это винчестер. А пространство-то одно, а где оно сейчас: на винчестере или в памяти - это должна быть забота ОС.

[info]rain251

September 10 2009, 06:41:40 UTC 2 years ago

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

[info]dibr

2 years ago

[info]rain251

2 years ago

[info]dibr

2 years ago

[info]malykh

2 years ago

[info]rain251

2 years ago

[info]dibr

2 years ago

[info]rain251

2 years ago

[info]dibr

2 years ago

[info]rain251

2 years ago

[info]dibr

2 years ago

[info]rain251

2 years ago

[info]dibr

2 years ago

[info]ilya_314

2 years ago

[info]dibr

September 10 2009, 09:26:42 UTC 2 years ago

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

[info]rain251

2 years ago

[info]malykh

2 years ago

[info]dibr

September 10 2009, 09:21:54 UTC 2 years ago

> ну да, ну да. пока упасть-отжаться ему удалось с чем там? с блокнотом или калькулятором?

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

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

Интересно, надо будет попробовать :-) То есть, ворд удовлетворительно устойчив к падениям - это я помню, но таких вот тестов (падение при наборе текста в большом документе) я не проводил. Хорошо, если есть и работает.

> правда при больших проектах файло разрастается настолько, что иногда пижама сама перестает понимать его структуру

[вздыхая] ...и главная проблема систем вида "мы поднимемся в точности в том же состоянии, в которым были до падения" в том, что если программа зависла, то после прибивания она поднимется заново. В том же самом состоянии - т.е. зависшем.
То есть, чтобы фантомовская идея "файлы не нужны" действительно работала, нужна либо железная уверенность, что никто никогда не зависнет, либо специальный механизм "расклинивания" зависших программ без потери данных.

Проблема-то близкая...

> в общем пока скорости диска отличаются от скоростей памяти на порядки и десятки порядков - никакого мгновенного снапшота не будет, как не инкрементируй

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

[info]rain251

September 10 2009, 09:32:54 UTC 2 years ago

ворд обычно падает на рюшечках. или на внедренных объектах или на проверке орфографии и т.п.
сам текстовый набор в нем вполне пригоден к любому использованию.

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

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

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

[info]dibr

2 years ago

[info]malykh

September 10 2009, 05:57:32 UTC 2 years ago

А по поводу второго. При нормальных механизмах транзакций проблем для прикладного программиста нет.

[info]malykh

September 10 2009, 06:11:11 UTC 2 years ago

Там, кстати, сразу и версионность напрашивается для полного счастья. ;-)
Мечты-мечты.

[info]dibr

September 10 2009, 09:37:27 UTC 2 years ago

Не трави душу. Мечты, понимаешь.
Хрен знает когда, лет пятнадцать назад если не больше, сидел на СМ-4 с ОС RSX-11 (если не перепутал название). Жесткие диски системы "стиральная машина" и ёмкостью с пачку трёхдюймовых дискет... и на этом - FS с автоматической поддержкой версий файлов! Прозрачной абсолютно: если не знать, так и не заметишь - всегда по умолчанию используется последняя версия, но если сделать определенное телодвижение - получишь любую из (сохранившихся - диски-то маленькие) предыдущих.

Прошло N-дцать лет, объемы дисков выросли на несколько десятичных порядков. Где, %$#, современные FS с автоматической поддержкой версий?! Ужас...

[info]ilya_314

2 years ago

[info]dibr

2 years ago

[info]dibr

2 years ago

[info]ilya_314

2 years ago

[info]dibr

2 years ago

[info]ilya_314

2 years ago

[info]dz

2 years ago

[info]balamutang

2 years ago

[info]dibr

2 years ago

[info]balamutang

2 years ago

[info]dibr

September 10 2009, 09:32:47 UTC 2 years ago

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

[info]malykh

September 10 2009, 09:46:42 UTC 2 years ago

Для объектов, конечно.
Для произвольного объекта? Ну наверное есть какие-нибудь академические языки программирования, где это реализовали just for fun. ;-)
В любом случае транзакции вещь привычная хотя бы работающими с СУБД.

[info]ilya_314

September 10 2009, 06:24:56 UTC 2 years ago

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

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

[info]dibr

September 10 2009, 09:45:07 UTC 2 years ago

Если мы клонируем объект-хранилище перед началом работы - мы нарушим идейный принцип "никаких файлов" :-) Правда, есть нюанс: некоторым людям нравится иметь пункт меню "revert to saved", а он подразумевает физическое сохранение изначальной версии объекта. А при "сохранении" (точнее, "приведении в транспортабельную форму" - в фантоме сохранять не надо) - лишние объекты можно и срезать.

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

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

[info]ilya_314

2 years ago

[info]dz

2 years ago

[info]dibr

2 years ago

[info]platon_4exov

September 10 2009, 12:36:04 UTC 2 years ago

http://community.livejournal.com/bestcheapers/ в нашем сообществе делимся идеями, как заработать и экономить, присоединяйся!

[info]dz

September 10 2009, 16:14:36 UTC 2 years ago

не так всё просто с прозрачным сохранением состояния приложения. хотя сделать это в обычной ОС - можно. факт.

[info]raphaeel

October 18 2009, 17:44:56 UTC 2 years ago

Скорей уж идеи фантома реализуются аппаратной революцией. Когда будет большой-большой и быстрый-быстрый флеш-диск. Которому будет без разницы, в каком режиме работать - в режиме диска или в режиме ОЗУ. Предвижу 10ТБ озу размером с коробок с запоминанием состояния при отключении питания =)

[info]dibr

October 18 2009, 18:17:53 UTC 2 years ago

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

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

[info]ilya_314

2 years ago

[info]dibr

2 years ago

[info]ilya_314

2 years ago

[info]dibr

2 years ago

[info]ilya_314

2 years ago

[info]dibr

2 years ago

[info]ilya_314

2 years ago

[info]raphaeel

2 years ago

[info]dibr

2 years ago

[info]raphaeel

2 years ago

[info]dibr

2 years ago

Anonymous

September 8 2011, 05:24:02 UTC 8 months ago

восстание декабрстов

[url=http://therkalo.pl.ua]галстена жирное молоко
[/url]

Anonymous

September 26 2011, 07:35:02 UTC 7 months ago

прокладка локальных сетей обзоры прокладка локальных

[url=http://mokin.if.ua]Sonny Ericsson
[/url]
Create an Account
Forgot your login or password?
Facebook Twitter More login options
English • Español • Deutsch • Русский…