[qoute]Я говорю не столько об определении документа как объекта рассуждений, сколько об определении документа, как математического объекта, прежде всего с точки зрения допустимых операций и типов результата этих операций.[/qoute]
Боюсь, понятие документа слишком широко для математической теории. Придумать то можно, но смысла в ней будет не больше чем в "теории объектов", "теории сущностей" или "теории всего на свете". Чем шире понятие, тем менее содержательна теория для него.
Если хочется полезной теории, надо как-то ограничить смысл слова "документ".
Заметьте, хорошие теории были построены не для баз данных вообще, а для реляционных баз данных, функциональных баз данных и т. п.

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

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

Ответ на »сообщение 1819« (Димыч)
___________________________
Например, есть у меня папка на компьютере с фотографиями.
Папка - еще один устаревший атрибут времен дискет.
На современном винте с 200-300 Гигабайт, расфасовывать файлы по папкам все равно что хоронить их на кладбище. Ни черта не найдешь потом, да и бессмысленно. Древовидная структура каталогов хороша когда их можно окинуть взглядом (размер дискеток) А что делать с деревом с десятки тысяч глубоко вложенных друг в друга папок ? Лазить по ним вручную ? Конечно нет. Все равно придется пользоваться поиском.
Так зачем же заморачиваться с папками в первую очередь ?
Так что единственный выход для всех больших хранилищ - это база данных файлов с тегами и индексами по ним, а также по массе другой служебной метаинформации (дата, размер, тип, описание итд)
И вот тогда можно создавать виртуальные папки (запросы, или view) типа "Папка фотографий с озера Балхаш 2006 год." Или скажем "Я и Колян." Причем некоторые фотки окажутся в обоих папках (если ты с Коляном на озеро ездил конечно :)) )

В свете этого коментарии типа "Разархивируйте ваше приложение в папку Applications" выглядят до смешного старомодно.

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

Ответ на »сообщение 1802« (колобок)
___________________________

Ответ на »сообщение 1800« (Сергей Перовский)
___________________________
Документ является скорее обобщением понятия файла, чем частным случаем.
Против такого обобщения возражений нет, кроме названия (слишком узкое и неуниверсальное понятие). Но, по-моему этого недостаточно. Еще нужен механизм синхронизации данных в сети компьютеров при сохранении возможности автономной работы. Вот если запретить компьютеру загружаться без подключения к сети - задача, возможно, и будет решаться. Но это рассуждения колобка.
Механизм синхронизации довольно сложный, но создать его можно.
Составной документ может ссылаться на другие документы. Документы эти могут быть расположены локально или глобально, тут есть аналогия с областью видимости переменных. Если мы хотим придать документу статус локального, то придется создать копии всех общих и библиотечных вложенных документов. Такой механизм давно есть в Worde. Картинки могут быть встроены в документ или фигурировать в виде ссылок. Web породил подобные механизмы с локальными и глобальными ссылками. Навести на все это теоретическую строгость и скрыть от пользователя копирование фрагментов и документов между компьютерами и сетями вполне возможно.



По поводу файла и документа.
Под файлом понимается "поименованная область на диске" (из Фигурнова по моему). Т.е. первая (и главная) характеристика файла - имя. А если сделать имя необязательной характеристикой?

Например, есть у меня папка на компьютере с фотографиями. Имена файлов мне ни о чем не говорят (PICT0224.jpg, говорит мне меньше, чем открытое фото моей семьи на озере).

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

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

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

Правда есть одно но - передавать данные в другие [файловые] системы можно будет только с потерей характеристик. Но ведь совсем не обязательно делать всю информацию в файловой системе в новой ОС такой. Можно часть папок (которые, кстати, могут обладать своими характеристиками) обязать работать по предложенной схеме, а часть по старой схеме. Или предусмотреть процедуру автоматического создания файлового имени и, возможно, файла новой структуры. В случае криптографии при передаче файла в старую файловую систему можно подпись выносить в отдельный файл.

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

PS. Идея не совсем моя, навеяна книгой Д.Раскина http://www.books.ru/shop/books/25835

Ответ на »сообщение 1802« (колобок)
___________________________

Ответ на »сообщение 1800« (Сергей Перовский)
___________________________
Документ является скорее обобщением понятия файла, чем частным случаем.
Против такого обобщения возражений нет, кроме названия (слишком узкое и неуниверсальное понятие). Но, по-моему этого недостаточно. Еще нужен механизм синхронизации данных в сети компьютеров при сохранении возможности автономной работы. Вот если запретить компьютеру загружаться без подключения к сети - задача, возможно, и будет решаться. Но это рассуждения колобка.
Механизм синхронизации довольно сложный, но создать его можно.
Составной документ может ссылаться на другие документы. Документы эти могут быть расположены локально или глобально, тут есть аналогия с областью видимости переменных. Если мы хотим придать документу статус локального, то придется создать копии всех общих и библиотечных вложенных документов. Такой механизм давно есть в Worde. Картинки могут быть встроены в документ или фигурировать в виде ссылок. Web породил подобные механизмы с локальными и глобальными ссылками. Навести на все это теоретическую строгость и скрыть от пользователя копирование фрагментов и документов между компьютерами и сетями вполне возможно.

Адаптивность. Адаптивность рассматривается как средство динамической оптимизации режима работы и взаимодействия всех компонентов ОС, а также демпфирования внешних возмущений, ведения политики обработки нештатных ситуаций (управляемая деградация) при изменении параметров операционного окружения. В некоторых моментах близка к идеям автономного компьютинга (в понимании IBM).
Насколько я понимаю, предполагается использовать для этого аппарат нейронных сетей. Идея кажется логичной, если не принимать в расчет рост числа процессоров и задач. Задача диспетчеризации, как частный случай задачи расписания, резко меняет свою сложность с ростом размерности. В машиностроении ставят бригадира на 6 станков - больше человеческий мозг распределять эффективно не в состоянии. Вызывает сомнение, что модель нейронной сети в принципе способна распределять заметно большее число ресурсов. Мы строили системы, способные эффективно распределять сотни ресурсов, но для машиностроительных и сходных с ними производств, где длительность операции заранее известна. В задачах распределения вычислительных ресурсов длительность распределяемых операций заранее не известна. Как подходить к такой задаче, я не представляю.
Хотелось бы представить математическую постановку задачи адаптации ОС.

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

Я было тоже хотел предложить такой вариант (РОСА), но, боюсь, он уже занят, кажется...

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

Что ж, написано неплохо. Заметил, что моя критика была не зря :).
Желаю успеха!
Мне бы хотелось пожелать участникам проекта большей открытости, чтобы любой человек мог поучаствовать в написании драйвера или портирования какой-нибудь программы (и не надо для этого людей мариновать 2 месяца).

Спасибо всем, кто высказал добрые слова в адрес проекта. Они нам очень пригодятся. Разворачивать такую махину с нуля, да еще под улюлюканье, охи и вздохи, непросто. К конструктивным словам и полезным идеям будем обязательно прислушиваться и прислушиваемся. Что до открытости, то ее будет с избытком. Еще успеет вам всем надоесть. :)

Ответ на »сообщение 1805« (имя)
___________________________

Идей на самом деле нет. Есть пиар, проработанная процедура приема новых членов и много названий разных ОС.

Если не ошибаюсь, Ивану Бунину принадлежат крылатые слова: "Я не золотой червонец, чтобы всем нравиться".

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

Походу это бедут ОС с GUI, защищенным режимом, многопоточностью и kernel на С++?

То, что kernel не будет на С++ - это однозначно. И даже не потому, что Линус Торвальдс советует убрать С++ подальше от низкоуровневых вещей.
Просто С++ не вписывается в идеологию систем, близких к духу ОС Оберон...