Ответ на »сообщение 2852« (Beginner)
___________________________

Ответ на »сообщение 2850« (Valery Solovey)
___________________________
Если Вы на основе оставшегося создадите нечто действительно новое, то я соглашусь, что я был неправ.

Извините, упустил, в чем прав-неправ? Графика только для пространственно распределённых задач?

Всё, что проектируется и планируется разве не моделируется?

Ответ на »сообщение 2856« (Сергей Перовский)
___________________________

Ответ на »сообщение 2850« (Valery Solovey)
___________________________
Однако, как видно из списка, большинство вещей предназначены для проектирования или планирования. Я же имел в виду задачи моделирования.
Подобный спор требует очень точного определения терминов.
Что именно Вы понимаете под моделированием?
Моделирование ЧЕГО и ДЛЯ ЧЕГО?
В конце концов любой план и проект тоже модель своего рода.

Да, пожалуй, моё понятие о термине моделирования отличается границами от ваших (что увеличивает проблемы при его реализации). Однако, как меня учили, проектирование и моделирование - разные вещи, что отражено в названии специальности, по которой я обучался:
"Моделирование и компьютерное проектирование ...", а не "Моделирование или компьютерное проектирование ...".

В моделировании на построении чего-то не завершают работу. Далее идёт анализ.
В проектировании построение завершает работу. Результат соответствует ТЗ (в идеале). Чего тут анализировать? Возможно, к моделированию можно отнести создание ТЗ, так как на данном этапе идёт анализ: некоторые вещи отбрасываются, некоторые заменяются, некоторе добавляются. ТЗ и будет моделью, которую далее воплощают (чертежи, листинги, документация).
Если создание ТЗ относится к проектированию (является его составной частью), то моё замечание следует конкретизировать.

P.S. Не могу себе позволить купить лицензию 2007 офиса, следовательно, визио не посмотрю. Однако, есть подозрение, что оно предназначено для проектирования, которое в любом случае не моделирование.

Ответ на »сообщение 2890« (Димыч)
___________________________

возможность отказа от имени файла или автоматическая генерация имени

возможность сопоставления файлу некоторой информации, которая с одной стороны, была бы независимой от содержимого (в смысле расположения не в теле файла), но была сопоставлена строго с одним файлом. Пример - наличие одной или нескольких ЭЦП под файлом, EXIF в JPEG, пользовательские комментарии, поля, определяемые приложением.



По поводу этих двух пунктов. Вещь хорошая фактически она уже реализована в специализированной ОС. Содержимое (там они называются BLOB) отделено от атрибутов файла и имеет некую hash запись (сделана MD5) которая также как и атрибуты хранятся отдельно в одной XML БД. Что это дает, прежде всего то что вы тем самым избавляетесь от кучи копий одного и того же содержимого но под разными именами. В то же время BLOB хранится в двух разных местах.

Ответ на »сообщение 2887« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 2886« (Ка джа)
___________________________
Раз уж мы отказываемся от традиционной адресации дискового пространства, пора подумать о логической буферизации данных. Во-первых, связанные документы, файлы одного приложения должны считываться с диска в один прием как единое целое. Во-вторых, ОС должна делать "предсказания переходов" пользователя или приложения и считывать документы и файлы приложения с диска в оперативную память заранее. Особенно полезно это для интернет-серверов и серверов для сетей тонких клиентов.

Сергей, вы так легко отказываетесь от разных вещей :)

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

Предлагаю вернуться в плоскость обсуждения файловой системы ОС Роса, считая задачу документооборота пользовательским приложением, которого в минимальной конфигурации ОС точно не будет. Это позволить освободиться от термина "документ", сильно перегруженного даже в текущем контексте.

Требования, выдвигаемые (мною) к файловой системе следующие:

• безопасность (наличие механизма разграничения доступа на локальном уровне и на сетевом уровне)
  
• скорость работы
  
• отказоустойчивость (транзакционность или атомарность операций). Как вариант - регулируемый механизм отката/наката изменений после сбоя.
  
• наличие регулируемых механизмов протоколирования
  
• возможность отказа от имени файла или автоматическая генерация имени
  
• кеширование (группировка) операций (например, копирование группы файлов одним блоком, что улучшает использование сети)
  
• возможность сопоставления файлу некоторой информации, которая с одной стороны, была бы независимой от содержимого (в смысле расположения не в теле файла), но была сопоставлена строго с одним файлом. Пример - наличие одной или нескольких ЭЦП под файлом, EXIF в JPEG, пользовательские комментарии, поля, определяемые приложением.
  

Последний пункт хочу раскрыть полнее.
Мне думается разумным отделить тело файла от зависимой информации.
Приходилось писать код, в котором надо было вырезать заголовки или трейлеры файла (пресловутая ЭЦП). Кроме того, это несколько меняет ряд алгоритмов, работающих со всем файлом сразу, но без учета таких вставок(архивирование, хеширование и пр.)

Еще одно предложение по файловой системе - встраивание на уровне системы (конфигурируемой) системы поиска типа Google Desktop или Yandex.Персональный Поиск, использующей приведенные выше свойства ФС.

Вполне допускаю, что ФС будет реализована как СУБД, а сами файлы будут если не записями в БД, то зависимая информация вполне может находится в БД.

Ответ на »сообщение 2887« (Сергей Прохоренко)
___________________________
Во-первых, связанные документы, файлы одного приложения должны считываться с диска в один прием как единое целое.

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

Ответ на »сообщение 2882« (Сергей Прохоренко)
___________________________

Чтобы подтвердить подлинность контента и права правообладателя.
Замечательно. Давайте рассмотрим на конкретном примере. Вот купил я диск с лицензионной игрой (пусть будет NFS Carbon). Кто будет проверять через ЭЦП, что этот диск выпустила именно Electronic Arts? Я или компания? И мне, и компании хватает формальной регистрации серийного номера игры на сайте.
Зачем здесь ЭЦП? Я серьезно спрашиваю. Мне по работе приходится сталкиваться с различными аспектами применения ЭЦП (как со стороны разработчика, так и со стороны пользователя). Но зачем ЭЦП именно здесь - я не понимаю.

Ответ на »сообщение 2886« (Ка джа)
___________________________
Раз уж мы отказываемся от традиционной адресации дискового пространства, пора подумать о логической буферизации данных. Во-первых, связанные документы, файлы одного приложения должны считываться с диска в один прием как единое целое. Во-вторых, ОС должна делать "предсказания переходов" пользователя или приложения и считывать документы и файлы приложения с диска в оперативную память заранее. Особенно полезно это для интернет-серверов и серверов для сетей тонких клиентов.

Ответ на »сообщение 2858« (Руслан Богатырев)
___________________________
мысли пляшут... но некогда формулировать..
...Насколько я помню, разделение на код и данные - весьма условно, - соответственно на программы и файлы тоже...
В общем случае код взаимодействует с данными и где-то, либо в коде, либо в описании структуры данных (прикрепленной неотрывно к этим данным) есть знания о том, каким образом произойдет взаимодействие кода и данных.
А у нас ситуация в которой программа (набор функционала, кода) может развиваться, появляться новые версии с большим или даже другим функционалом.
Исходя из этого логично сделать описание структуры таковым, что данные будут способны выбрать программу которая сможет их обрабатывать, но ни списком возможных программ, который устареет через месяц, а чем?.. - может нужен протокол предоставления коннектной информации программы в сторону к данным и от данных в сторону программы, с правилами установления соответствия и выбора режима возможной обработки данных...
То есть вопрос в распределении знаний между кодом и данными. И уж коли код отдельно, данные отдельно - то можно предусмотреть универсального посредника, который должен будет иметь совместимость вниз, а код и данные не обязаны будут иметь полную совместимость...
...Собственно еще мысль - файловую систему можно строить "от данных" и их свойст, а можно от кода и его свойств. Или придумать другой, не файловый способ коннекта кода и данных..

Извиняюсь за сумбур ))

Ответ на »сообщение 2877« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2869« (Сергей Прохоренко)
___________________________

Полностью самопоясняющий универсальный документ так распухнет от тегов, что не поместится ни на один носитель, а ОС будет часами пережевывать и интерпретировать теги. Нет, во всем нужно чувство меры.

Так я и клоню в сторону чувства меры. Оставлять голым формат (с минимальным тегированием типа допущенных к его обработке приложений) -- это крайность. Даже если допустить, что внутри документа находится подробнейшая схема его интерпретации (для будущих поколений и инопланетян), никто не заставляет ее обрабатывать каждый раз, здесь и сейчас. Достаточно ее просто пропустить мимо ушей. Она нужна только тогда, когда нет в доступе алгоритма обработки документа, который ВСЕГДА представлен в том или ином формате (его версии).

Количество типов данных не очень велико. Зачем все эти теги повторять в каждом документе? А пересылка всего этого "добра" по сети, чтение/запись на диски... Не проще ли добавить несколько шаблонов в среду времени исполнения? Т.е. своего рода драйверы документов.

Ответ на »сообщение 2875« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2868« (Сергей Прохоренко)
___________________________

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

Боюсь, Вам редко доводилось работать со справочно-правовыми системами. Там постоянный логический разрыв связей -- типичная проблема. Вступление в действие поправок к законам (например), формирующих (линейную) цепочку редакций, регламентирует логический разрыв связей. Поправки вступают в силу фрагментарно (пункт такой-то части такой-то -- тогда-то) и происходит это при наступлении конкретного фактора -- текущей даты.

Автор действительно подписывается под содержанием со словесным изложением ссылок. Но если по этому словесному изложению ссылки нельзя однозначно идентифицировать (и получить) импортируемый документ в данном окружении (кто будет вести репозитарии документов, куда всегда можно было бы сделать запрос на получение недостающего документа?), то ЭЦП грош цена.


Ну, раз по сто я обращался к Гаранту и Консультанту+. Я же не зря написал в форуме, что версии различаются в том числе статусом. Например: действующий, недействующий и т.п. Для правовых документов можно добавить атрибуты, указывающие на сроки действия. Можно добавить "будущие" версии, которые вступят в силу только с определенного момента.

Что касается ведения репозитория документов, то это вопрос бизнеса соответствующих компаний, а не проблема разработчиков ОС.

Ответ на »сообщение 2874« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2869« (Сергей Прохоренко)
___________________________

3. Изучали ли Вы форматы ODF и Office Open XML?

Разве я похож на мазохиста?

Это центральные универсальные форматы представления документов, имеющие международные стандарты (ISO и ECMA соответственно). С учетом мировой тенденции вымывания из учреждений и компаний форматов DOC и RTF корпорации MIcrosoft (в т.ч. директивным образом) в ближайшие 5-7 лет это будут основные форматы в мире. Нравится нам это или нет. PDF будет также иметь огромный вес и уже заявлен на международную ISO-стандартизацию. См. http://www.linux-watch.com/news/NS7542722606.html


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