Приложение находится в файле, файл — в файловой системе. При запуске приложение развертывается в памяти, загружает данные из других файлов ... Всем до боли привычная и знакомая картина. Лучше уже быть не может, так ли?
ИМХО лучше быть может.
Если рассмотреть ОС как единую среду выполнения некоторых модулей совмещенную с объектной системой управления БД — то ни файлы ни приложения не нужны.
Приложение это набор экземпляров классов. Каждый раз при запуске приложения экземпляры приходится инстанциировать, каждый раз при завершении работы — уничтожать экземпляры.
В ОС основанной на ОБД можно сделать по другому. При создании экземпляра класса он существует всегда пока его не собрал сборщик мусора. Не зависимо от того, включен комп или выключен, используется ли этот экземпляр в данное время пользователем или нет — экземпляр существует. Вопрос в каком виде? Он может быть вытеснен в хранилище объектов на HD или быть загружен в RAM — по аналогии со swap fail современных ОС. Важное отличие в том, что экземпляры не уничтожаются при перегрузки ОС. Все приложения всегда находятся в запущеном состоянии. Если пользователь не использует текстовый процессор — то процессор находится в hibernate сотоянии. Так же нет понятия открыть-закрыть текстовый документ. Все текстовые документы этого процессора всегда загружены в виртуальное адресное пространство этого текстового процессора. Те которые не используются вытеснены на HD, те которые пользователь редактирует в данный момент находятся в RAM. Мало того — граница между приложениями стерта. Есть не приложения а компоненты. И эти компоненты используются совместно. Компонент "текстовый файл" совместно с компонентом "текстовый процессор" позволяет редактировать собственное содержание но как в OLE контейнере находится в ячейке электронной таблицы — которая тоже некоторый экземпляр хранимый в этой ОС-ООСУБД...
Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?
С уважением, Дмитрий.
Re: Файловые системы, файлы, приложения - устаревшие концепц
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, shuklin, Вы писали:
S>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?
M>1. Производительность M>2. Updates, patches и новые версии M>3. Перенос данных, многопользовательская работа M>4. Разработка
J2EE EJB соответствует этой модели. Заморочки с производительностью только у Stateful Bean's.
Re[2]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, Mystic, Вы писали:
S>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?
Все решаемо:
M>1. Производительность
Будет такая же или выше по сравнению с текущей ОС. Пример. Запустить Эксель и Ворд. Переключаться между окнами (при условии что оба выгружены в swapfile). Это и будет скорость старта приложения — оно будет подниматься из ОБД так же как поднимается сейчас из swapfile.
M>2. Updates, patches и новые версии
В ОБД для этого применяют версионнинг объектов.
M>3. Перенос данных, многопользовательская работа
Еще лучше чем сейчас. качественная реализация СУБД поддерживает многопользовательскую работу. В режиме клиент-сервер можно будет шарить не только данные но и приложения. Какая перспектива для MS по сдаче в аренду компилятора C# крутящегося на TeamServer )))
M>4. Разработка
Аналогично современным методам разработки на C# но без заботы о старте-шатдоуне приложений. Экземпляр будучи создан не умирает пока не будет собран сборщиком мусора не зависимо от состояния ОС. В некотором смысле даже проще.
Re[3]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, shuklin, Вы писали:
S>Здравствуйте, Mystic, Вы писали:
S>>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?
S>Все решаемо:
M>>1. Производительность S>Будет такая же или выше по сравнению с текущей ОС. Пример. Запустить Эксель и Ворд. Переключаться между окнами (при условии что оба выгружены в swapfile). Это и будет скорость старта приложения — оно будет подниматься из ОБД так же как поднимается сейчас из swapfile.
Нет. Объектная персистентность — дорогое удовольствие. Чтобы поднять объект из хранилища, нужно заново его инстанцировать (сконструировать) из класса, считать сохранённое состояние (поля) из долговременного хранилища (с диска и/или из БД) и присвоить эти сохранённые (старые) значения, восстановив тем самым прежнее состояние объекта. Но это чертовски медленно по сравнению с бинарным hibernate в существующих реализациях операционных систем.
M>>2. Updates, patches и новые версии S>В ОБД для этого применяют версионнинг объектов.
M>>3. Перенос данных, многопользовательская работа S>Еще лучше чем сейчас. качественная реализация СУБД поддерживает многопользовательскую работу. В режиме клиент-сервер можно будет шарить не только данные но и приложения. Какая перспектива для MS по сдаче в аренду компилятора C# крутящегося на TeamServer )))
Это уже есть и работает. Технология JINI.
M>>4. Разработка S>Аналогично современным методам разработки на C# но без заботы о старте-шатдоуне приложений. Экземпляр будучи создан не умирает пока не будет собран сборщиком мусора не зависимо от состояния ОС. В некотором смысле даже проще.
Уже есть и работает под управлением распределённого GC.
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
M>>>1. Производительность S>>Будет такая же или выше по сравнению с текущей ОС. Пример. Запустить Эксель и Ворд. Переключаться между окнами (при условии что оба выгружены в swapfile). Это и будет скорость старта приложения — оно будет подниматься из ОБД так же как поднимается сейчас из swapfile.
ZEN>Нет. Объектная персистентность — дорогое удовольствие. Чтобы поднять объект из хранилища, нужно заново его инстанцировать (сконструировать) из класса, считать сохранённое состояние (поля) из долговременного хранилища (с диска и/или из БД) и присвоить эти сохранённые (старые) значения, восстановив тем самым прежнее состояние объекта. Но это чертовски медленно по сравнению с бинарным hibernate в существующих реализациях операционных систем.
А кто мешает сделать восстановление объектов в ОБД бинарной?
Надо всего лишь встроить ОБД в ядро ОС а не пользоваться промежуточными слоями в виде RDB & ORM.
M>>>3. Перенос данных, многопользовательская работа ZEN>Это уже есть и работает. Технология JINI. M>>>4. Разработка ZEN>Уже есть и работает под управлением распределённого GC.
именно. уже есть и работает. осталась интеграция в ядро ОС.
Re: Файловые системы, файлы, приложения - устаревшие концепц
Здравствуйте, shuklin, Вы писали:
S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?
Некоторые характеристики предполагаемой "ОС будущего" роднят ее с созданной еще в 80-х ОС Оберон, например:
1) система состоит из компонентов, а не изолированных приложений;
2) динамическая загрузка по требованию;
3) сборка мусора;
4) постоянные (persistent) объекты;
5) свободное внедрение объектов в документы.
Есть и различия.
Вы исходите из того, что "приложение это набор экземпляров классов".
Поэтому у Вас нет файлов, а есть объектная база данных.
ОС Оберон строится из модулей (которые, конечно, могут определять классы), поэтому файлы там есть.
"Оберонщики" обосновывают необходимость модулей как отдельного строительного элемента системы, не совпадающего с классом. Например, Шиперски в своей статье "Import is Not Inheritance. Why We Need Both: Modules and Classes": http://www.oberon2005.ru/paper/p_modcla.pdf
Большое значение в Обероне придается безопасности типов, в т.ч. межмодульной, основанной на понятии раздельной (не независимой) компиляции. Изобретены интересные механизмы, позволяющие сохранять одновременно целостность и гибкость системы. Например, в статье Crelier "Separate Compilation and Module Extension": http://www.oberon2005.ru/paper/eth10650.pdf
Я вижу единственную серьезную проблему у такой системы: т.к. она основана не на процессах (отдельных приложениях), то модули и объекты могут "сбиться" в один связный граф, что может затруднить выгрузку модуля.
В принципе, это решаемая проблема.
За основу решения можно взять хотя сборки, как в .NET.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[2]: Файловые системы, файлы, приложения - устаревшие конц
AVC>Поэтому, возможно, предшествующий опыт может быть интересен. AVC>Дизайн ОС Оберон подробно описан в книге "Project Oberon": AVC>http://www.oberon2005.ru/book/ponw2005e.pdf
Огромное спасибо за ссылку. Обязательно воспользуюсь в разработке собственной .NET ООСУБД
AVC>Есть и различия. AVC>Вы исходите из того, что "приложение это набор экземпляров классов". AVC>Поэтому у Вас нет файлов, а есть объектная база данных.
Да. в ОБД нет понятия файлов и RAM. по new выделяется объект. А где он расположен физически, на HD или в RAM — дело СУБД-ОС а не программиста. Пока на объект есть ссылки — он существует. Если он не используется в данное время — то объект занимает место на HD. Если используется — его копия загужается в RAM пока место в RAM не потребуется другому более свежему объекту. Полная аналогия с swapfile.
AVC>ОС Оберон строится из модулей (которые, конечно, могут определять классы), поэтому файлы там есть. AVC>"Оберонщики" обосновывают необходимость модулей как отдельного строительного элемента системы, не совпадающего с классом. Например, Шиперски в своей статье "Import is Not Inheritance. Why We Need Both: Modules and Classes": AVC>http://www.oberon2005.ru/paper/p_modcla.pdf
С этим согласен. namespaces, assemblies нужны. Но они тоже могут быть объектами ОБД а вовсе не файлами. По аналогии с тем же .NET сборка может быть System.Reflection.Assmbly а вовсе не файлом. И иметь методы Emit для генерации кода прямо внутрь объекта.
AVC>Большое значение в Обероне придается безопасности типов, в т.ч. межмодульной, основанной на понятии раздельной (не независимой) компиляции. Изобретены интересные механизмы, позволяющие сохранять одновременно целостность и гибкость системы. Например, в статье Crelier "Separate Compilation and Module Extension": AVC>http://www.oberon2005.ru/paper/eth10650.pdf
AVC>Я вижу единственную серьезную проблему у такой системы: т.к. она основана не на процессах (отдельных приложениях), то модули и объекты могут "сбиться" в один связный граф, что может затруднить выгрузку модуля. AVC>В принципе, это решаемая проблема. AVC>За основу решения можно взять хотя сборки, как в .NET.
Да. сложностей с просто выгрузкой не будет, так как не будет понятия файла и выгружать просто нечего и некуда. А объекты они и так в связаном графе и друг друга блокируют, но не от выгрузки а от удаления сборщиком мусора.
А вот что очень сложно — так это поддержка версионности объектов при необходимости updates но и это решаемо. В промышленных ОБД для этого применяют метаниформацию, по аналогии с сборщиками мусора Java/.NET которые по живому исправляют содержимое регистров процессора — в ОБД по живому исправляют лайоут экземпляров на основании изменившихся методанных классов. Сложно но реализуемо.
Я в своей ОБД сделал по другому. У меня любой экземпляр может иметь переменное число аттрибутов изначально. Тоесть добавить/удалить field в классе это не задача версионирования а просто штатная операция ОБД. При этом разные экземпляры одного и того же класса могут иметь различный набор аттрибутов.
Re[3]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, Ryf, Вы писали:
Ryf>идея нравится, но как приятно иногда начать работу после того как комп перезагружен , так сказать с чистого листа
Так или иначе но потихоньку это просто обязано становиться прошлым.
Приложения должны конструироваться чтобы все время работать как чистый лист.
Управляемые среды это как раз большой шаг в эту сторону.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re: Файловые системы, файлы, приложения - устаревшие концепц
Здравствуйте, shuklin, Вы писали:
S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?
Мне кажется, что подводный камень это то, что работать в некоторых вопросах станет труднее.
Я уже тут веду как раз обсуждения на тему этого с разработчиком другой ООБД.
Мне кажется, что нельзя отказываться от понятия хранилище. Т.е. нельзя бесповоротно стирать грань между персистивными и транзиентными объектами.
Почему? Потому что эта грань несет кроме сложностей еще и пользу. Как то — контроль производительности (все-же простите меня но доступ в ОЗУ всегда будет существенно быстрее чем в более медленное, но более емкое хранилище), возможность контроллировать доступ — делать объекты публичными или работать локально, возможность иметь бесплатную систему откатов изменений, возможность контролировать транзакции и т.п.
Ну а в вашей реализации подводные камни это:
1. Сложность задачи — не справиться гораздо проще, чем кажется по дороге
2. Технические возможности — вы все таки не можете писать свою ОС и тягаться в производительности со своп файлом трудно
3. Как результат производительность
4. Сложные схемы работы для программиста — они не захотят разбираться или многим это будет неудобно
Вот так я думаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
Mystic wrote: > ZEN>J2EE EJB соответствует этой модели. Заморочки с производительностью > только у Stateful Bean's. > В J2EE EJB нет такого понятия как файл?
Нет. В чистой J2EE даже синглтонов нет
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: Файловые системы, файлы, приложения - устаревшие концепц
Забыл сказать. На мой взгляд, ключевая необходимость в хранилище еще и в том, что хранилище должно позволять вам легко находить нужные объекты среди миллиардов других. Иначе вы будете иметь массу проблем в сколько-нибудь сложных системах.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[3]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, shuklin, Вы писали:
S>namespaces, assemblies нужны. Но они тоже могут быть объектами ОБД а вовсе не файлами. По аналогии с тем же .NET сборка может быть System.Reflection.Assmbly а вовсе не файлом. И иметь методы Emit для генерации кода прямо внутрь объекта.
Наверное, да.
По крайней мере, пока не вижу причин, делающих это невозможным.
AVC>>Я вижу единственную серьезную проблему у такой системы: т.к. она основана не на процессах (отдельных приложениях), то модули и объекты могут "сбиться" в один связный граф, что может затруднить выгрузку модуля. AVC>>В принципе, это решаемая проблема. AVC>>За основу решения можно взять хотя сборки, как в .NET.
S>Да. сложностей с просто выгрузкой не будет, так как не будет понятия файла и выгружать просто нечего и некуда. А объекты они и так в связаном графе и друг друга блокируют, но не от выгрузки а от удаления сборщиком мусора.
В Обероне проблем с уничтожением ненужных объектов ( =сборкой мусора ) тоже нет.
А вот с выгрузкой модулей — есть.
Дело в том, что модуль (кроме прочего) — хранилище кода. Объект ссылается на хранимые в модуле методы, что, IMHO, и создает проблему.
Получается, что на модуль существуют как явные ссылки (через отношение импорта), так и неявные (через объекты).
Пока что я не придумал лучшего варианта, чем использовать механизм сборок.
Не снабжать же каждый объект своей копией кода.
S>А вот что очень сложно — так это поддержка версионности объектов при необходимости updates но и это решаемо. В промышленных ОБД для этого применяют метаниформацию, по аналогии с сборщиками мусора Java/.NET которые по живому исправляют содержимое регистров процессора — в ОБД по живому исправляют лайоут экземпляров на основании изменившихся методанных классов. Сложно но реализуемо.
Интересно, хотя и правда сложно.
S>Я в своей ОБД сделал по другому. У меня любой экземпляр может иметь переменное число аттрибутов изначально. Тоесть добавить/удалить field в классе это не задача версионирования а просто штатная операция ОБД. При этом разные экземпляры одного и того же класса могут иметь различный набор аттрибутов.
А методов?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, Mystic, Вы писали:
iZEN>>J2EE EJB соответствует этой модели. Заморочки с производительностью только у Stateful Bean's. M>В J2EE EJB нет такого понятия как файл?
Нет. Система выполнения EJB и непосредственно Bean's имеют понятие только об источнике данных, неважно каком. Конкретный источник данных (файл, байтовый поток, БД и т.д.) определяются в дескрипторе развёртывания. EJB работает только с интерфейсом доступа к источнику, не зная его физической реализации.
Re: Файловые системы, файлы, приложения - устаревшие концепц
Здравствуйте, shuklin, Вы писали:
S>ИМХО лучше быть может.
Всё это здорово. Тольно аппаратное и программное обеспечение целиком состоят из устаревших концепций. Идеи, которые ты предлагаешь, витали и 10 лет назад. Но движение вперёд происходит не за счёт движения к лучшему, а за счёт движения от неприемлимого.
Re[2]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, Kemsky, Вы писали:
K>Всё это здорово. Тольно аппаратное и программное обеспечение целиком состоят из устаревших концепций. Идеи, которые ты предлагаешь, витали и 10 лет назад. Но движение вперёд происходит не за счёт движения к лучшему, а за счёт движения от неприемлимого.
В целом это правда. Но если что-то в наших руках — написать лучше ПО и оно будет востребовано, то почему не писать? А то бы мы так с ДОС и сидели бы и говорили бы, а что, меня все устраивает и редактор отличный и вот хочешь — на BBS позвоню, спишу что угодно... Так что на практике это не совсем так. Конечно, когда неприемлимо, то прогресс идет пошустрее...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[3]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, Max.Subpixel, Вы писали:
MS>В целом это правда. Но если что-то в наших руках — написать лучше ПО и оно будет востребовано, то почему не писать?
Вот вот, писать стараются так, чтоб было востребовано. И желательно, как можно быстрее.
MS>А то бы мы так с ДОС и сидели бы и говорили бы, а что, меня все устраивает и редактор отличный и вот хочешь — на BBS позвоню, спишу что угодно... Так что на практике это не совсем так. Конечно, когда неприемлимо, то прогресс идет пошустрее...
Знаете такой текстовый редактор vi? Тех, кто им пользуется, невозможно убедить перейти на что-то другое. И Windows нужен был не тем, кто сидел в ДОС, а тем, для кого это было неприемлимо.
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, Kemsky, Вы писали:
K>Знаете такой текстовый редактор vi? Тех, кто им пользуется, невозможно убедить перейти на что-то другое.
+1
vi!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
, так сказать с чистого листа
