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

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]malykh@lj
2009-09-10 01:02 (ссылка)
Файлов не было в PalmOS (вместо них упрощенные структуры БД), что, в целом, да, приводило к похожим проблемам. Приходилось использовать конверторы. Сперва на PC, а потом с развитием карт памяти и интернета (источников файлов) стали появляться костыли для динамической обработки файлов на самом устройстве. Ну а потом PalmOS умерла. ;-)

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

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


[info]dibr@lj
2009-09-10 06:05 (ссылка)
Да, файлы нужны для обмена (и бэкапа) - какой бы объектной не была внутренняя модель мира, по проводочкам бегают и на диск пишутся только сериализованные данные. Значит, нужна возможность развернуть документ (пучок объектов) "в строчку", и потом обратно воссоздать пучок объектов по строчке. Это действительно чисто техническая задача, проблема только в совместимости.

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

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

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

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


[info]malykh@lj
2009-09-10 07:03 (ссылка)
Монотонность структур данных тяжело обеспечить на практике.

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

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

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


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

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


[info]malykh@lj
2009-09-10 02:56 (ссылка)
А кто говорит о прибивании? Одно другому не мешает.
На обмен можно и файлы. А внутри другие структуры.

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


[info]dibr@lj
2009-09-10 06:14 (ссылка)
Устройства - фигня: вон, жесткий диск тоже устройство, а файлы начинаются несколько в другом месте. Тот же фотоаппарат теоретически может иметь в пузе фантом, и создавать не "файлы типа жипег", а сложные "объекты типа фотка" - это даже логично, ибо уже сейчас фотка - не просто image data, а ещё и куча полей exif, бывает что и разных внутренних форматов.

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

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

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


[info]rain251@lj
2009-09-10 02:51 (ссылка)
ну да, ну да. пока упасть-отжаться ему удалось с чем там? с блокнотом или калькулятором? в 10кб весом при самом страшном раскладе. пусть-ка попадает с гиговым приложением в котором висит 6гб данных. пусть попробует прозрачно посохранять снапшоты при таком раскладе.
тот же корел в свое время сохранял проект столько, что мы успевали сходить в кафешку на соседней улице и пообедать.
инкрементальное сохранение есть и сейчас в многих программах. та же пижама при сейве лепит мгновенно поверх файла кусочек. правда при больших проектах файло разрастается настолько, что иногда пижама сама перестает понимать его структуру и тогда приходит северная лисица.
в реальном времени - ворд. практически каждый символ сохраняет при наборе. и чуть отстает при долгих операциях. правда вот пользоваться этим с каждой новой версией умеет все хуже и хуже. иногда темповый файл есть, нормальный, а поднять его ворд не может..

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

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


[info]malykh@lj
2009-09-10 03:00 (ссылка)
Виртуальная память и mmap сейчас в разных ОС работают и не жужжат. ;-) Причем шизофренично работают (одно пытается кидать память на диск, а другое позволяет работать с диском как с памятью).
Проблема возникает тогда, когда опять возникают разные адресные пространства. Мол это память, а это винчестер. А пространство-то одно, а где оно сейчас: на винчестере или в памяти - это должна быть забота ОС.

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


[info]rain251@lj
2009-09-10 03:41 (ссылка)
это-то понятно. но дело в том виртуальная память это ничто иное, как убогая симуляция дорогой оперативной. т.е. - костыль. и совершенно неважно какое там адресное пространство до тех пор, пока программа ложится при записи в своп из-за скорости диска/интерфейса к нему.

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


[info]dibr@lj
2009-09-10 06:30 (ссылка)
"Хорошо быть богатым и здоровым".
Теоретически это костыль. Практически - это эффективное и красивое решение: у программ бывают редкоиспользуемые куски памяти, программа может насосать данных и "заснуть" на полчаса в ожидании пользователя, и хранить всё это вдорогой оперативке - неэффективно. Эффективно отдать эту оперативку тем, кому она нужна сейчас.
То есть, решение с виртуальной памятью позволяет на том же железе эффективно запускать более ресурсоёмкие задачи, чем без виртуалки. Конечно, при какой-то нагрузке всё загнётся от свопа - но никто и не говорил что виртуалка - панацея.

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

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


[info]rain251@lj
2009-09-10 06:42 (ссылка)
ну так в том то и дело, что эти костыли идут с тех пор, когда 32 мб памяти стоили больше 200 баксов.
эффективно иметь столько оперативки, сколько ее надо текущей программе. при нынешних ценах и их тенденции - это вполне реально.

>у программ бывают редкоиспользуемые куски памяти
у криворуких индийских программистов еще не то бывает :)))

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

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


[info]dibr@lj
2009-09-10 06:58 (ссылка)
> эффективно иметь столько оперативки, сколько ее надо текущей программе. при нынешних ценах и их тенденции - это вполне реально.

Это не "эффективно", это "быстро".

>> у программ бывают редкоиспользуемые куски памяти
> у криворуких индийских программистов еще не то бывает :)))

Да ладно. Ты всегда постоянно используешь всю запрошенную память? Ситуации "загрузили, использовали раз, второй раз понадобится через полчаса, но не выбрасывать же загруженное" не бывает?

> оно не позволяет "эффективно запускать более ресурсоёмкие задачи" - оно позволяет просто запускать. но использование тормозного свопа сводит на нет все преимущества. это не работа.

Это *работа*. А когда задача, вместо того чтобы за полчаса отработать на системе ценой $500 требует(!) систему за $2000, и работает на ней аж в три раза быстрей - это фигня какая-то. Особенно если именно эта задача эта запускается раз в месяц, а остальное время ничего тяжелее медиаплеера на системе не запускается.

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

То есть, если памяти реально не хватает для быстрой работы - надо покупать, кто ж спорит. Но добавление к физической памяти - виртуальной, помогает сэкономить от десятков до сотен процентов цены при не очень сильном падении скорости. Кроме того, у меня может внезапно появиться "одноразовая" задача, которая захочет МНОГО памяти. С виртуалкой она потрещит диском несколько часов и отработает. Без виртуалки - погонит меня в магазин, а оно мне надо, для одноразовой задачи-то?...

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


[info]malykh@lj
2009-09-10 07:08 (ссылка)
По поводу виртуальной памяти вспоминается как много лет назад на мегакомпьютере 386SX с 2МБ памяти ну очень хотелось поиграться в Doom2. А он, зараза, требовал 4МБ.
Пришлось немного с бубном попрыгать, попытаться запустить его под Windows 3.1 с виртуалкой. И запустился. И работал. Некоторые сложные уровни, конечно, вызывали жуткий свопинг. А некоторые, попроще, вполне бегали. С тех пор эти простые уровни просто наизусть помню, только в них и играл тогда. ;-)

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


[info]rain251@lj
2009-09-10 09:09 (ссылка)
ну да все понятно, то что своп используется везде как раз и говорит за жизнеспособность этого решения.
мы начали с того что строится принципиально новая система, которая будет свопить ВСЮ память ПОСТОЯННО.

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


[info]dibr@lj
2009-09-10 09:23 (ссылка)
Не свопить (это не свопинг, это другое), и не всю (только изменяемую) :-) И "постоянно" - не значит "очень плохо": можно (и нужно) ввести ограничение вида "потреблять на снапшоты не более N% ресурсов" - тогда шуршать оно будет, но сильно мешать работе уже не должно.

Хотя непрерывный(!) шорох винта (а так оно и будет, поскольку в системе всегда что-нибудь да меняется) - не для слабонервных...

Кстати, "своппингу" это тоже поможет: объекты, не помеченные как "несохранённые", можно при необходимости выкидывать из памяти молча :-) То есть, это и сейчас делается (вытесненная на диск страница дискардится не сразу, а когда понадобится память), тут просто добавится принудительное массовое вытеснение страниц на диск :-)

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


[info]rain251@lj
2009-09-10 09:30 (ссылка)
опять пошло по кругу :)) в том виде как сейчас с приложением которое считает х=х+1 такой "свопинг" будет работать. с чем-то более тяжелым придется свопить именно всю память или довольно большой ее кусок. для пользователя в общем нет разницы что свопить 2 гига или 4. и то и то одинаково медленно в терминах уборщица ткнула шваброй в пилот а я не сохранялся. в таком виде оно и сейчас есть - и во многих программах, да и макрос повесить на ктрл+с несложно..
да и винты при такой нагрузке будут лететь стаями. в общем пока вижу идею как бредовую и малоприменимую... проще уж поставить копию оперативы+автономное питание и свапить туда. дорого, но зато быстро и надежно.

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


[info]dibr@lj
2009-09-10 09:44 (ссылка)
По порядку :-)

Шуршать винтом будет непрерывно в любом случае, даже если в системе просто мигает двоеточие в часах. Это проблема, причём для пользователя скорее всего вполне серьёзная. Для системы - не очень серьёзная, потому что можно ограничить затрачиваемые на это ресурсы. Сильно ли изменится ресурс HDD - неочевидно: пластины крутятся в любом случае, головка пластин штатно не касается...

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

А решение вида "дёшево и сердито" давно существует - это UPS. Подпереть систему на время принудительного гибернейта, после чего обессиленно упасть. Правда, последние два раза мой ippon почему-то "не смог" удержать компьютер - свет мигнул, упс пискнул, комп перегрузился. Батарейку что-ли проверить, может она уже превратилась в собственный массогабаритный макет...

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


[info]rain251@lj
2009-09-10 09:53 (ссылка)
я уже сам нить потерял чего обсуждаем :)) ну да ладно))
ресурс хдд меняется сильно - на своем опыте. раньше в бедной редакции компы дизайнеров жили в постоянном свопе. и там винты летели НАМНОГО чаще, чем такие же в рядом стоящих компах без таковой нагрузки. а с учетом что ресурс нынешних винтов не тот что был раньше, увы.. (да, раньше и деревья выше и трава зеленее и винты долгожительнее были ))

о, иппона мать. не проверяй - меняй сразу. у них батареи больше 1.5-2 лет не живут, даже если ни разу не использовались. у меня этих иппонов штук 30. сначала перестает держать при падении, через некоторое время просто не включится.
чудно что 12/7 аккум для них в компмагазине стоит 1200, а точно такой же в пожарных и прочих сигнализациях - 400 руб ))

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


[info]dibr@lj
2009-09-10 10:08 (ссылка)
У меня есть пять штук 12/4, купленных когда-то для других целей. Привяжу проводочками снаружи, заодно менять проще будет :-)

А вообще, я пожалуй задумаюсь. При таком сроке службы, и при сегодняшних ценах на литий - может, переделать УПС на литий? Или автомобильный аккум под стол поставить...

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


[info]rain251@lj
2009-09-10 10:14 (ссылка)
под литий наверное затруднительно будет, там же схема простая - заряд идет постоянно, слишком много городить придется.. про автомобильный на форуме иппона были топики вроде кто-то прикручивал. надо охлаждение прикручивать - их конструктив не рассчитан на такое время работы - инвертер сдохнет..
не вижу смысла ни в том ни в том. раз в 2 года 400 рублей можно потратить, хотя бы для цивильного внешнего вида. а литий через 2 года тоже вполне может потерять большую часть емкости..
12/4 маловато будет. иппоны и так не шибко эффективные на новом аккуме 7а/ч комп с лсд монитором держат 5-8 минут. а с 4а/ч хорошо бы гибернейтнуться успело..

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


[info]dibr@lj
2009-09-10 10:26 (ссылка)
Надо замерить, какое напряжение будет на аккуме в стационарном состоянии. Литий чрезвычайно капризен, скорее всего вопрос с литием отпадёт сам собой. Но практика показывает, что литий, при правильном использовании, живёт весьма долго, так что "эту мысль я буду думать".

А 12/4 у меня пять штук, и они уже спаяны/склеены воедино, так что поставлю снаружи, "дизайн" комнаты сильно не испортится...

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


[info]ilya_314@lj
2009-09-10 07:33 (ссылка)
>эффективно иметь столько оперативки, сколько ее надо текущей программе. при нынешних ценах и их тенденции - это вполне реально.

Оперативки во многих задачах не хватает, поэтому и пишут алгоритмы исходя из реалий. Три простых примера:

*) photoshop работает с растром - можно посчитать сколько надо памяти на 50 * 10 mpix 32 bit картинок - всего-то 2 gb, а как бы было удобно работать

*) сшивка панорам - например сшиваем панораму из 100 картинок - как бы удобно и панораму и исходники с промежуточными данными держать в памяти, а ведь делают гигапиксельные панорамы

*) База данных - объемы могут быть в десятки раз больше оперативки

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

>но использование тормозного свопа сводит на нет все преимущества

В большом количестве задач лучше не задумываться о памяти, когда объем задачи в разы меньше RAM. Тут уже нужен своп который на конкурентной основе обслуживает задачи. До какой-то поры он отлично справляется, но может наступить момент, когда придется мирится с тормозами или закрывать задачи.

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


[info]dibr@lj
2009-09-10 06:26 (ссылка)
Сейчас память и винчестер разделяют, что на винчестере файлы (персистентные объекты, которые можно вынести наружу), а в памяти - фигня какая-то для внутреннего употребления.
Я согласен с тем, что с одном пространством ("всё - память") жить проще. Но существование выделенного вида "объектов типа плоский файл", для которых гарантируется сохранность при выключении питания (т.е. они находятся именно на диске) всё-таки очень желательно. Правда, разделять пространство HDD на "тут у нас файлы, а тут - как бы память" действительно необязательно - "файлы" могут с точки зрения адресного пространства "лежать в памяти", просто гарантированно физически находится на HDD.

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


[info]rain251@lj
2009-09-10 06:45 (ссылка)
ну общем-то когда-то нечто похожее сделали с видеопамятью, когда просто кусок оперативки отражался в видебуфер. а программе не было разницы куда писать просто в память или в видеопамять. правда современные видяхи все-таки стараются иметь на борту свою память более быструю..

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


[info]malykh@lj
2009-09-10 06:57 (ссылка)
Вооооот. Мысль в правильном направлении.
Нужны приоритеты сохранности для объектов. Вижу навскидку как минимум три уровня.
1. Данные которые вообще терять нельзя. Параноидально кидаются на диск. В идеале в ста тысячах копий, если место есть. ;-)
2. Данные, которые желательно не терять, но если что, то можно восстановить, но это ресурсоемкая операция. Например, какие-то кэш-подобные структуры, аналог временных файлов и т.п.
3. Рабочие и проходные данные. То, чем в основном оперирует программа при работе.

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


[info]dibr@lj
2009-09-10 06:21 (ссылка)
> ну да, ну да. пока упасть-отжаться ему удалось с чем там? с блокнотом или калькулятором?

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

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

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

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

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

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

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

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

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


[info]rain251@lj
2009-09-10 06:32 (ссылка)
ворд обычно падает на рюшечках. или на внедренных объектах или на проверке орфографии и т.п.
сам текстовый набор в нем вполне пригоден к любому использованию.

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

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

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

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


[info]dibr@lj
2009-09-15 13:13 (ссылка)
> хуже другое, что файлы это не только текущее отражение памяти. джипег, распакованный в памяти, занимает в среднем в 7-10 раз больше. нафига оно такое хранить? а видео потоковое?

Делать discardable объекты: пусть джипег хранится as is, но для удобства и скорости создаётся объект "распакованный джипег". Который система (не приложение!) имеет право выбросить, никого не спросивши (а приложение при попытке обращения получит эксепшн, и при необходимости воссоздаст заново).

Я так думаю :-)

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


[info]malykh@lj
2009-09-10 02:57 (ссылка)
А по поводу второго. При нормальных механизмах транзакций проблем для прикладного программиста нет.

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


[info]malykh@lj
2009-09-10 03:11 (ссылка)
Там, кстати, сразу и версионность напрашивается для полного счастья. ;-)
Мечты-мечты.

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


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

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

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


[info]ilya_314@lj
2009-09-10 07:14 (ссылка)
Отступление по поводу версий.

История и бэкап с версиями сейчас можно сделать с помощью Windows Home Server. Это такой offline вариант. Там можно настроить бэкап выбранных компонент файловой системы (хоть все) по расписанию. Предлагают делать каждую ночь. Фишка в том, что они хэшируют фрагменты файловой системы на уровне секторов, т.е. если будут совпадающие файлы на одном диске или даже на нескольких машинах в сети, то они не будут дублироваться. Соответственно инкрементальный бэкап идет шустрее и уже не требует много места. Потом ты можешь зайти и посмотреть копии своих файлов и посмотреть на историю, скопировать оттуда то что надо или стартовать со специального диска который из WHS вынет снапшот твоей системы и просто перепишет его поверх твоей.

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


[info]dibr@lj
2009-09-10 07:25 (ссылка)
> История и бэкап с версиями сейчас можно сделать с помощью Windows Home Server.

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

> Предлагают делать каждую ночь.

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

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


[info]dibr@lj
2009-09-10 07:34 (ссылка)
> "Система версий" и "автоматический бэкап" - совершенно разные версии,

"Разные системы". конечно. Как "страховочный пояс" и "страхование жизни" :-)

И ещё. Версионность - свойство FS. WHS - отдельная железяка. Прикрути её к ноутбуку, с которым я сижу в поезде и что-то пишу?...

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


[info]ilya_314@lj
2009-09-10 07:51 (ссылка)
Все понимаю. Это по сути просто инкрементальный бэкап по расписанию. Плюс его в том, что они умеют распознавать дублирующиеся секторы и при бэкапе нескольких машин или одинаковых файлов существенно могут сэкономить время.

А вообще версионность можно сделать в ntfs через shadow copy (через него же работает transactions, объединяя группы изменений в snapshot). Но только вопрос в том, кто будет активировать точку с версией. Если эту фишку добавить в процедуру сохранения документа (стандартный диалог например) и все будет замечательно.

http://en.wikipedia.org/wiki/Shadow_Copy

утилита для просмотра истории
http://www.shadowexplorer.com/documentation/manual.html

В vista есть вроде специальная закладка previous versions.

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


[info]dibr@lj
2009-09-10 07:57 (ссылка)
А "стандартной процедуры сохранения"-то и нету :-) Вот я нажал ctrl/s в ворде или F2 в фаре - к чему цепляться будем? ;-) А если приложение решит само озаботиться версиями - то оно может и без поддержки ОС это сделать. "Предыдущую версию" почти все программы сохранять умеют, добавить настройку "хранить N версий" - и всё готово. Но приложение должно этим озаботиться, а если нет?

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

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


[info]ilya_314@lj
2009-09-10 08:58 (ссылка)
>С другой стороны - наверное можно перехватить API "открыть файл", и пытаться создавать версии в этот момент. Но глючно это по-моему...

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

***

Еще кстати есть толком неразрешимая проблема с файлами - хранение дополнительных метаданных. Это может быть: тэги к музыке, тэги к видео (их кстати нет!), к картинкам всякие дополнительные данные типа EXIF, просто ключевые слова и пр. Если это и прикрутить ко всем файлам в виде расширенных атрибутов (NTFS например), то при передаче за пределы NTFS атрибуты потеряются. Если копировать не системной функцией CopyFile, то тоже потеряются, если делать преобразование формата (например bmp -> jpeg какой-нибудь обычной утилитой то расширенные атрибуты тоже потеряются). Вобщем нельзя так сделать чтобы все везде работало и получается что иногда проще рядом положить файл с описанием и его ручками таскать следом.

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

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


[info]dz@lj
2009-09-10 13:19 (ссылка)
кстати, именно из RSX я в фантом хочу притащить тему версионности классов (кода).

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


[info]balamutang@lj
2009-10-15 14:45 (ссылка)
>Прошло N-дцать лет, объемы дисков выросли на несколько десятичных порядков. Где, %$#, современные FS с автоматической поддержкой версий?! Ужас...

такая фича в windows серверных и в некоторых версиях висты при включении теневых копий например есть.
http://www.winline.ru/articles/2742.php

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


[info]dibr@lj
2009-10-15 16:27 (ссылка)
Если я правильно понял, то это даёт возможность восстановления состояния файла не вида "ой, $%#, я все сломал, хочу предыдущую версию", а "хммм, по-моему у нас проблемы. Когда у нас было последнее создание точки восстановления, пять дней назад?"...

В RSX-11 "старая версия" сохранялась при _каждом_ сохранении файла. Грубо говоря, пару раз внёс изменения/сохранил, убедился что "всё сломалось", откатился "на три сохранения назад", работаешь дальше. Тут - из статьи неочевидно что можно откатиться ближе чем на последнюю "точку восстановления", и что точки восстановления могут делаться настолько часто, что можно откатываться на малое время назад.

Хотя, возможно я невнимательно читал :-)

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


[info]balamutang@lj
2009-10-15 16:53 (ссылка)
ну по сути то да - копии (хотя тут больше подходит слово снимки) делаются по расписанию, но сам процесс создания теневых копий занимает достаточно мало ресурсов.
есть практика на файловом сервере запускать этот процесс 3 раза в день и все это абсолютно прозрачно для пользователей.
По идее на выделенном разделе с документами/исходниками можно увеличить частоту хоть до одного раза в пять минут и в принципе этого будет достаточно для отката.

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


[info]dibr@lj
2009-09-10 06:32 (ссылка)
Эээ... транзакций - где? В FS - не помогут. В памяти (для объектов) - пожалуй, да, вопрос только - а где они есть, чтобы не для "базы данных", а прямо вот для произвольного объекта?

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


[info]malykh@lj
2009-09-10 06:46 (ссылка)
Для объектов, конечно.
Для произвольного объекта? Ну наверное есть какие-нибудь академические языки программирования, где это реализовали just for fun. ;-)
В любом случае транзакции вещь привычная хотя бы работающими с СУБД.

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


[info]alpha_cygnus@lj
2009-09-23 10:06 (ссылка)
Куда-то в эту сторону STM, а в качестве академического языка - пресловутый Haskell.

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


[info]ilya_314@lj
2009-09-10 03:24 (ссылка)
Для хранения документа все равно нужно делать некий объект хранилище - например объект предоставляющий структуру папок с другими объектами, и помещать туда объекты осмысленно. Если документ это объект, то когда он начнет использоваться в программе, то видимо надо его клонировать и работать с копией, чтобы не повредить оригинал, а когда захотим сбросить состояние, то надо, чтобы объект не был перегружен лишней информацией которой он может обрастать в процессе использования, грубо говоря он не должен за собой потащить ворох внешних ссылок и лишних объектов. Чистота объекта еще гарантирует надежность, если мы сериализуем внутреннее состояние сложного объекта, то есть вероятность записать состояние которое приведет к ошибке в дальнейшем - программы пока безошибочно писать не научились.

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

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


[info]dibr@lj
2009-09-10 06:45 (ссылка)
Если мы клонируем объект-хранилище перед началом работы - мы нарушим идейный принцип "никаких файлов" :-) Правда, есть нюанс: некоторым людям нравится иметь пункт меню "revert to saved", а он подразумевает физическое сохранение изначальной версии объекта. А при "сохранении" (точнее, "приведении в транспортабельную форму" - в фантоме сохранять не надо) - лишние объекты можно и срезать.

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

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

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


[info]ilya_314@lj
2009-09-10 07:20 (ссылка)
>Если мы клонируем объект-хранилище перед началом работы - мы нарушим идейный принцип "никаких файлов"

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

>Но возможность сохранять абсолютно всё дерево объектов - тоже не лишняя

Полностью согласен - сериализовать я все-же предлагаю объекты, просто надо отрезать излишки.

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

Согласен.

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

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


[info]dz@lj
2009-09-10 13:20 (ссылка)
"Если мы клонируем объект-хранилище перед началом работы - мы нарушим идейный принцип "никаких файлов" :-)"

Почему??

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


[info]dibr@lj
2009-09-10 14:02 (ссылка)
Эээ... ладно, убедил, фигню сказал :-)

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

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

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


[info]platon_4exov@lj
2009-09-10 09:36 (ссылка)
http://community.livejournal.com/bestcheapers/ в нашем сообществе делимся идеями, как заработать и экономить, присоединяйся!

(Ответить)


[info]dz@lj
2009-09-10 13:14 (ссылка)
не так всё просто с прозрачным сохранением состояния приложения. хотя сделать это в обычной ОС - можно. факт.

(Ответить)


[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 пока либо медленные, либо жутко дорогие. Либо смешного размера :-) Поэтому попадаются больше не "на столах", а либо в портативных дивайсах (где не важна скорость), либо в каких-то спецприменениях (где не важна цена).

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

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

восстание декабрстов
(Анонимно)
2011-09-08 02:24 (ссылка)
[url=http://therkalo.pl.ua]галстена жирное молоко
[/url]

(Ответить)

прокладка локальных сетей обзоры прокладка локальных
(Анонимно)
2011-09-26 04:35 (ссылка)
[url=http://mokin.if.ua]Sonny Ericsson
[/url]

(Ответить)