Я всё о Фантоме. Который "от dz".
ОС Фантом настолько сурова, что в ней нет файлов. Документ, с которым в данный момент работает пользователь, даже в обычных операционках во время работы не "лежит на диске", а висит в памяти в виде пучка объектов. Система (Фантом), в силу, тсзть, дизайна, гарантирует долговременную сохранность состояния приложения (и, естественно, всей этой грозди объектов) - а раз так, то как бы нет потребности эту гроздь объектов переливать из одной формы (память) в другую форму (последовательность байт), и обратно. Привязали к этой грозди иконку на десктопе - пользователь кликает иконку, у него всплывает документ - красота, и никаких файлов!
С точки зрения dz, отсутствие файлов, а равно и отсутствие необходимости чего-то куда-то сохранять, есть плюс разработчикам: не надо писать процедуру разборки "внешнего" формата "документа" во внутренний формат "как оно лежит в памяти", не надо писать обратную процедуру - сборки внутреннего представления в поток байтиков. И это как бы верно. Если бы не одно "но" - даже сам dz понимает, что без файлов, собственно, обойтись всё равно не удастся - мир вокруг, увы, слишком завязан на "одномерные потоки данных", и даже при передаче документа между двумя "фантомами" в промежутке может возникнуть какой-нибудь ужас, типа флэшки с FAT'ом, электрописьма с аттачем, или банального веб-сайта с пипкой "download". И тут-то файл и понадобится.
Но это фигня! Если документ - не более чем "состояние приложения" (т.е. фактически множество объектов, принадлежащих приложению, плюс совсем чуть-чуть служебной информации, а может быть и без неё), то сохранение/загрузку документа можно сделать единообразным образом, и вообще поручить её системе: нужно сохранить документ - просим систему сделать "дамп состояния программы", нужно загрузить - просим "восстановить состояние из дампа". Дамп - обычный файл, который можно передавать куда надо, разработчику приложения думать ни о чём не надо - достаточно дёрнуть ровно одну ниточку в системе, а бонусом - вместе с документом при этом автоматом будет сохраняться всякая приятная мелочёвка типа undo-буфера и запомненных строчек в полях ввода. Недостатки тоже есть, но они решаемы :-)
Есть только один нюанс. Для того, чтобы сохранять "гроздь объектов" - вовсе не нужен фантом. Никто не мешает приделать такую возможность к любому современному "объектно-озабоченному" языку. Более того - в принципе это приделываемо к любой программе, необязательно "объектно-ориентированной" - просто "объектом" там будет нечто другое. И мы поимеем один из бонусов фантома (заментый, правда, скорее разработчикам чем пользователям), не имея собственно фантома.
Второй бонус Фантома (заметный пользователю, а не разработчику) - возможность "упасть-отжаться": прозрачное (без остановки приложений) постоянное "автосохранение" мгновенного слепка состояния системы (и приложений). Радость при этом в том, что даже при внезапном пропадании электричества - теряется не "вся работа с момента последнего сохранения", а только последние несколько минут, а то и секунд: после загрузки системы она восстанавливается по состоянию "на момент последнего снапшота". При этом для снятия снапшота, напомню, не требуется остановка приложений.
Как это реализовано - особо не афишируется. Но, как мне кажется, особо фантазировать не получится. В момент начала снятия снапшота мы выставляем всем "объектам" флажок "не сохранён". Далее - бежим по всем объектам, сохраняя их, и сбрасывая флажки. Если приложение хочет изменить (записать в) какой-то объект, помеченный как "несохранённый" - система автоматически делает copy-on-write - дублирует объект, приложение начинает работать с объектом, а система, когда дело доходит до сохранения именно этого объекта, сохраняет копию (и убивает её - у нас остался оригинал). На самом деле всё чуть сложнее - снапшоты надо делать инкрементально (т.е. к объекту привязать что-то вроде dirty flag, и при его чистоте - не пересохранять объект, а делать ссылку "старая копия вполне годна"), снапшота должно быть два - один "в стабильном состоянии", второй "в процессе сохранения", а "флажки сохранённости" необязательно тупо переворачивать у всех объектов, достаточно в начале цикла сохранения переопределить их интерпретацию на противоположную. Впрочем, это подробности.
Многие программы сами имеют функцию автосохранения. Полезную - когда документ небольшой, и жутко раздражающую, когда документ разрастается на сотни мегабайт и сохраняется минутами. Раздражающую ровно потому, что на время сохранения программа блокируется - действительно, сложно одновременно сохранять текущее состояние, и вносить в него изменения.
Однако - опять вспомним фантом. Ничего не мешает делать фантомовское "прозрачное сохранение" в пределах одного отдельно взятого приложения. Механизм тот же - сохранение всего по кругу, CoW для несохранённых объектов при попытке их изменения, инкрементальность сохранения. После этого "автосохранение" в данном приложении начнёт работать волшебным образом: если я сижу и набираю текст (изменения - не более десятков байт в секунду) - автосохранение будет успевать сохранить изменения буквально в реальном времени, и только если я делаю большие изменения - автосохранение будет "отставать" на заметное время. В любом случае меньшее, чем обычное автосохранение всего документа "раз в пять минут", и не блокирующее на это время приложение. А заодно и обычное, не автоматическое, сохранение станет халявой: просто прекратили изменять документ, дождались конца цикла автосохранения, выдали окошко "всё ок" :-)
Правда, есть нюанс: для достижения такого счастья в обязательном порядке понадобится поддержка со стороны языка программирования (среды выполнения, возможно даже системы). Поскольку, как мне кажется (могу ошибаться), на современных языках подобные извраты с CoW естественным образом не пишутся, а противоестественные методы - угробят идею в зародыше. Но, опять же, это возможно и без создания новой ОС - модернизацией уже существующих.
Поэтому, я так подозреваю, где-нибудь в windows 8 или windows 9 мы вполне можем обнаружить "бессмертные" приложения или "прозрачное" сохранение. Файлы, надеюсь, останутся на месте: микрософт - не Завалишин, на такие радикальные меры не пойдёт :-)
September 10 2009, 04:02:21 UTC 2 years ago
Хотя лично мне файлы не нужны. Единое адресно-объектное пространство гораздо интереснее. А файлы можно рассматривать не более, чем бинарный кусок сериализованных объектных данных. Но там есть и другая проблема. Если мы вдруг начнем меняться данными, то сразу возникнет проблема совместимости этих самых объектных данных. Потому все равно придется делать некоторую объектную модель, облегченную и стабильную между версиями и писать функции импорта и экспорта в нее и внутренней рабочей объектной модели. Будет тот же разбор, создание файлов, только попроще, поскольку вопрос сериализации объектов на себя возьмет ОС. Но и это уже неплохо. ;-)
September 10 2009, 09:05:26 UTC 2 years ago
Совместимость "межплатформенную" можно (и нужно) взвалить на систему: пусть система единообразным образом сериализует/десериализует все стандартные объекты. Нестандартные всё равно построены из стандартных, поэтому если стандартизован "внешний" формат хранения стандартных объектов, то даже если отличается "внутренний" (в памяти) формат - все объекты должны перенестись корректно. Лишь бы программа была той же версии (но под нужную платформу), т.е. знала что потом с этим делать.
Совместимость между версиями - можно взвалить на разработчика в виде "если нужна совместимость - не изменяй структуру объектов, но только расширяй". Если в новой версии к старым объектам приделаны новые свойства (с сохранением старых, и с "дефолтными значениями" для новых) - старый документ можно будет загрузить в новую программу: при этом старые объекты старыми частями лягут в новые, а отсутствующие части - заполнятся дефолтом. Если делать аккуратно - должно сработать.
Более того, можно рискнуть так же сделать и "совместимость назад" - новый документ при загрузке в старую программу будет грузиться так же, но новые свойства будут "срезаны". Что-то улетит (логично), но это не должно быть смертельным.
Ну, и конечно в каком-то случае (при серьезных изменениях) можно и сломать совместимость. Микрософт так не раз делал, и ничего - как был гигантом, так и остался :-)
September 10 2009, 10:03:05 UTC 2 years ago
Есть и чисто прагматические соображения, что данные на обмен и данные для работы просто по структуре разные, поскольку цели совсем другие. Например, компактное представление на обмен не позволяет организовать эффективную обработку данных внутри программы.
Так что без своеобразного импорта/экспорта ОО-структур не обойтись, но в этом ничего страшного нет.
September 10 2009, 05:35:39 UTC 2 years ago
Это, что гораздо более важно - интерфейс обмена данными между программами и устройствами.
Типа: цифровой фотоаппарат сделал снимок и положил его в файл, чтобы другое устройство (компьютер через флеш-ридер) смог его забрать и обработать. Тогда когда это потребуется и для этого будут ресурсы.
Попытка прибыть самый старый способ обмена информацией - ИМХО дурацкая.
September 10 2009, 05:56:38 UTC 2 years ago
На обмен можно и файлы. А внутри другие структуры.
September 10 2009, 09:14:21 UTC 2 years ago
Файл - интерфейс с внешним миром. Внутри устройства мы можем творить всё что угодно, но как только нам понадобится вынести результат наружу - нужен будет некий компактный и удобный к переноске (без выступающих наружу и самопроизвольно отваливающихся деталей) кусок данных. Сейчас это файл (плоский, без "дополнительных потоков" и "расширенных атрибутов" - ибо не-плоские свойства легко осыпаются при передаче), и перспектив что стандарт изменится - не видно (слишком много где используются именно плоские файлы).
Так что по сути - согласен: пытаться обойтись без файлов вообще - глупость. Но можно минимизировать потребность в файлах самой системы, и "минимизировать вред" от необходимости иногда всё-таки взаимодействовать с этими странными плоскими структурами данных из внешнего мира... :-)
September 10 2009, 05:51:31 UTC 2 years ago
тот же корел в свое время сохранял проект столько, что мы успевали сходить в кафешку на соседней улице и пообедать.
инкрементальное сохранение есть и сейчас в многих программах. та же пижама при сейве лепит мгновенно поверх файла кусочек. правда при больших проектах файло разрастается настолько, что иногда пижама сама перестает понимать его структуру и тогда приходит северная лисица.
в реальном времени - ворд. практически каждый символ сохраняет при наборе. и чуть отстает при долгих операциях. правда вот пользоваться этим с каждой новой версией умеет все хуже и хуже. иногда темповый файл есть, нормальный, а поднять его ворд не может..
в общем пока скорости диска отличаются от скоростей памяти на порядки и десятки порядков - никакого мгновенного снапшота не будет, как не инкрементируй. либо только для легких приложений, где оно не особо и нужно..
September 10 2009, 06:00:46 UTC 2 years ago
Проблема возникает тогда, когда опять возникают разные адресные пространства. Мол это память, а это винчестер. А пространство-то одно, а где оно сейчас: на винчестере или в памяти - это должна быть забота ОС.
September 10 2009, 06:41:40 UTC 2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
September 10 2009, 09:26:42 UTC 2 years ago
Я согласен с тем, что с одном пространством ("всё - память") жить проще. Но существование выделенного вида "объектов типа плоский файл", для которых гарантируется сохранность при выключении питания (т.е. они находятся именно на диске) всё-таки очень желательно. Правда, разделять пространство HDD на "тут у нас файлы, а тут - как бы память" действительно необязательно - "файлы" могут с точки зрения адресного пространства "лежать в памяти", просто гарантированно физически находится на HDD.
2 years ago
2 years ago
September 10 2009, 09:21:54 UTC 2 years ago
Хуже - со считалкой от 1 до "пока не упадёт" (текущая версия фантома быстро падает).
Но это, тсзть, пруф оф концепт, на коленке писаный. Что будет в реальности - надо думать.
> инкрементальное сохранение есть и сейчас в многих программах
> в реальном времени - ворд. практически каждый символ сохраняет при наборе
Интересно, надо будет попробовать :-) То есть, ворд удовлетворительно устойчив к падениям - это я помню, но таких вот тестов (падение при наборе текста в большом документе) я не проводил. Хорошо, если есть и работает.
> правда при больших проектах файло разрастается настолько, что иногда пижама сама перестает понимать его структуру
[вздыхая] ...и главная проблема систем вида "мы поднимемся в точности в том же состоянии, в которым были до падения" в том, что если программа зависла, то после прибивания она поднимется заново. В том же самом состоянии - т.е. зависшем.
То есть, чтобы фантомовская идея "файлы не нужны" действительно работала, нужна либо железная уверенность, что никто никогда не зависнет, либо специальный механизм "расклинивания" зависших программ без потери данных.
Проблема-то близкая...
> в общем пока скорости диска отличаются от скоростей памяти на порядки и десятки порядков - никакого мгновенного снапшота не будет, как не инкрементируй
Так ить пока я луплю текст - снапшот может быть почти мгновенным. А как только я потрогал многомегабайтный кусок данных - да, снапшот создастся с заметной задержкой. Ну так без задержки в таких случаях и быть не может, "это фантастика"... :-)
September 10 2009, 09:32:54 UTC 2 years ago
сам текстовый набор в нем вполне пригоден к любому использованию.
в пижаме уже тогда были попытки бороться с "поднятием в зависании" - с помощью нажатых клавиш при загрузке должна открываться предпоследняя версия быстросейва.
хуже другое, что файлы это не только текущее отражение памяти. джипег, распакованный в памяти, занимает в среднем в 7-10 раз больше. нафига оно такое хранить? а видео потоковое?
ну так с текстом и сейчас уже работает мгновенный бэкап, как в ворде, так и в мелких поделиях - действительно тупо каждую букву сохраняют. при текущих скоростях печати достаточно самого тормозного и старого диска для этого. а вот я работаю с фотошопом с огромной картинкой... это будет уже не работа и тут же появятся твикеры на отключение этой бодяги.
2 years ago
September 10 2009, 05:57:32 UTC 2 years ago
September 10 2009, 06:11:11 UTC 2 years ago
Мечты-мечты.
September 10 2009, 09:37:27 UTC 2 years ago
Хрен знает когда, лет пятнадцать назад если не больше, сидел на СМ-4 с ОС RSX-11 (если не перепутал название). Жесткие диски системы "стиральная машина" и ёмкостью с пачку трёхдюймовых дискет... и на этом - FS с автоматической поддержкой версий файлов! Прозрачной абсолютно: если не знать, так и не заметишь - всегда по умолчанию используется последняя версия, но если сделать определенное телодвижение - получишь любую из (сохранившихся - диски-то маленькие) предыдущих.
Прошло N-дцать лет, объемы дисков выросли на несколько десятичных порядков. Где, %$#, современные FS с автоматической поддержкой версий?! Ужас...
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
September 10 2009, 09:32:47 UTC 2 years ago
September 10 2009, 09:46:42 UTC 2 years ago
Для произвольного объекта? Ну наверное есть какие-нибудь академические языки программирования, где это реализовали just for fun. ;-)
В любом случае транзакции вещь привычная хотя бы работающими с СУБД.
2 years ago
September 10 2009, 06:24:56 UTC 2 years ago
Сериализация состояния объектов с обходом связей как я понимаю есть в managed языках, а вот cow конечно нет. Причем если делать cow на низком страничном уровне (так проще), тогда мы имеем дело уже не с объетами а со страницами памяти в которой не пойми что лежит - получаем такой "умный" hibernate. Кстати таким образом записанные образы полностью привязаны к железу - это по сути ассемблерный код. Если же мы хотим работать на уровне отдельных объетов, то не очень понятно как понять начал ли он изменяться, видимо все операции модификации должны отслеживаться и сопровождаться проверкой. Этот вариант возможен, но предполагает специальную managed среду исполнения, которая все это гарантирует. В таком случае уже можно сериализовать платформенно независимые snapshot-ы - это будет значительно медленнее, но интересно в плане переноса объектов между системами.
September 10 2009, 09:45:07 UTC 2 years ago
А вот проблема "мы зависли, и вот собственно и всё" (приложение взглюкнуло, система сохранила это его состояние) - да, серьёзная. Если рассматривать фантом - непонятно как разрешимая без "грязных хаков", если рассматривать автосохранение - да, нужна возможность "отбивать" от сохраненного куста объектов "лишние". Но возможность сохранять абсолютно всё дерево объектов - тоже не лишняя: при этом документ будет загружаться в полном рабочем контексте, со всеми запомненными полями ввода и undo-буферами, например :-)
Автосохранение на страничном уровне, кстати, может оказаться сильно быстрее: CoW на "тяжёлый" объект и сохранение его целиком при изменении в нём пары байт - не лучший вариант. Но он аппаратнозависим, да. Впрочем, "для продолжения работы" это неважно, а для выноса результатов наружу можно делать и обычную сериализацию.
2 years ago
2 years ago
2 years ago
September 10 2009, 12:36:04 UTC 2 years ago
September 10 2009, 16:14:36 UTC 2 years ago
October 18 2009, 17:44:56 UTC 2 years ago
October 18 2009, 18:17:53 UTC 2 years ago
И, кстати, концепция "файл не нужен" по-моему без костылей и подпорок не обойдётся.
Скажем, мы имеем jpeg, загруженный в "фотошоп". В памяти фотошопа - джипег распакован, для удобства и беспотерьности редактирования. Когда мы завершаем редактирование - мы *сохраняем в файл* запакованный джипег, а распакованную сущность - отбрасываем.
В фантоме же, при отсутствии явного действия "завершить работу с документом", система не будет знать, можно ли выбросить из памяти распакованный джипег (при условии, что его слегка подредактировали), или он ещё понадобится в распакованном виде. В результате в "фотошопе" всё-таки понадобится отдельная операция "сохранить" (по сути почти возвращающая концепцию файлов), либо в системе будут копиться "мёртвые" ресурсы, которые и выбросить нельзя, и использоваться не будут...
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
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]