Ответ на »сообщение 1899« (Гарин)
___________________________
>>> Пока моя программа на диске даже на языке самого высочайшего уровня будет выглядеть, как файл - я буду пользоваться именно этим понятием.
Так и я про это.
Пользователю вообще не нужно знать про диски. Сколько и каких дисков, как разбиты и т.д. Соответственно "физический" путь к информации теряет смысл. Все, что пользователю требуется, это придать документу определенный статус: должен ли документ открываться при отсутствии доступа к интернету и при отсутствии доступа к локальной сети. Уровень важности документа должен сообщить системе, сколько резервных копий необходимо поддерживать, но где именно они будут находится пользователя не волнует. Мы ведь не требуем от пользователя указывать, на каком ядре процессора выполнять приложение, так почему он должен думать о физическом размещении информации на дисках. По сути это уже не файлы, а скорее BLOB поля распределенной базы данных.

Ответ на »сообщение 1837« (Антон Григорьев)
___________________________

А может, тогда ну его на фиг, этот POSIX? Чтобы нельзя было перетащить под новую ОС всю эту гадость. От С и С++ в новых разработках надо избавляться, как от кошмара, чтобы эти языки не продолжали уродовать мозги программистов.

Ну почему же? Там есть и хорошие вещи. Например компиляторы Ады (GNAT), Хаскелла (GHC) и многие другие, основанные на GCC...
Если запускать программы на Си в отдельных пользовательских процессах, то они будут изолированы от ошибок друг друга...
И вапще на Си можно создавать элегантные и вполне безопасные программы... (Но можно и не создавать, да...:о( )

Ответ на »сообщение 1893« (Гарин)
___________________________

Кстати, на сайте http://oberoncore.ru изображена белка.
Это имеет отношение к Оберон-технологии или к городу Орел?

Белка имеет прямое отношение к ядрам... :)

>>>Я не о том, каким термином будет это называть пользователь.
>>>Бытовое понятие силы имеет мало общего с физическим термином "сила".
>>>Нисколько не мешает строгой формализации термина в физике.
Так я же не против :). Формализуйте это, если хотите. Я про то, что к реальной работе пользователя Ваша формализация не будет иметь никакого отношения. То, что принято называть документами в современном документообороте и информационной технологии, будет по-прежнему называться документами, а то, что не принято (фильмы, презентации, музыка и т.д.) будет называться соответственно и независимо от Вашей формализации этого понятия.
А по поводу "файловой системы" я уже сказал. Чтобы отменить это понятие, надо отменить саму файловую систему. Пока моя программа на диске даже на языке самого высочайшего уровня будет выглядеть, как файл - я буду пользоваться именно этим понятием. Потому что называть исполнительный файл EXE "файлом" - это ничуть не хуже, чем называть его "документом" или "программой". Именно потому, что файл - это тоже очень широкое понятие, шире некуда: любой набор информации, который имеет собственное имя, хранится на техническом носителе или передается между устройствами ввода-вывода и выступает в качестве самостоятельной единицы в операциях перемещения, копирования или удаления данных.

Ответ на »сообщение 1890« (Гарин)
___________________________
>>>Потому что понятие "документ" уже стало слишком широким.
Я не о том, каким термином будет это называть пользователь.
Бытовое понятие силы имеет мало общего с физическим термином "сила".
Нисколько не мешает строгой формализации термина в физике.
Те термины, понятия и требования, которые сформировались при попытках построения автоматизированных систем документооборота, кажутся мне очень подходящими для того, что должно прийти на смену понятию файла и файловой системы.
Разделение понятий структуры, вида и содержания документа очень созвучно соответствующей триаде  Model/View/Controller.
Обязательность авторства упроздняет множество коллизий, прежде всего связанных с безопасностью.
Все попытки автоматизации документооборота ненадежны в том числе и потому, что осуществляются поверх ненадежной файловой системы. Всем хорошо знакомы попытки навешивания защиты задним числом вместо встраивания в базовые механизмы.
Разница между файловой системой и системой документооборота такая же, как между ассемблером и языком высокого уровня. Можно делать промежуточную трансляцию в ассемблер, но сейчас уже никто этого не делает.

К вопросу о разных уровнях абстракции.
Проблема действительно есть. То, что удобно для "простого пользователя" и то, что удобно для "квалифицированного пользователя" - это разные вещи.
Мне, как специалисту, все равно "документами" называть информационные сущности или файлами. Я и так знаю, что на диске нет ничего, кроме файлов (даже папки - это, по сути, тоже файлы, только специального назначения). "Простому пользователю", далекому от компьютерной науки, например, экономисту-юристу, наоборот - понятие документа ближе и роднее.
Другой пример. Я не люблю "умные" инсталляторы именно потому, что привык контролировать все, что происходит в моей системе. Терпеть не могу программы, которые пишут куда-то какие-то файлы, а я не вижу что именно и куда именно записано. Поэтому мне очень нравится Блэкбокс - развернул архив в ту папку, в которую мне надо и готово. И я точно знаю что и куда развернуто. А все эти "офисы-мописы" дергают диск туда сюда, а потом даже не знаешь, что и куда они "напихали". А с точки зрения "пользователя-гуманитария"? Наверно, все наоборот. Чем меньше он знает о файлах - тем крепче у него сон. Правда у него иногда не добьешся признания, куда он дел свои документы :))). Но это, слава Богу, не очень часто случается.
Думаю, что даже в новой ОС должны быть разные уровни абстракции:
1) Абстракции низкого уровня - файлы-папки-тома;
2) Абстракции высокого уровня - документы-библиотеки-архивы;

Руководство по миграции на Linux для региональных администраций - от IBM.

http://www.ibm.com/developerworks/ru/library/linux_migr/contents.html

Ответ на »сообщение 1890« (Гарин)
___________________________

>>>"документ" нужно, наоборот, предельно сузить.
Трудно сузить то, что уже так расширилось :)).....

Согласен с каждым словом. Трудно увидеть выгоды от формализации понятия "документ", одни неудобства :) Разве что на режимных предприятиях :)

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

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

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

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

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

Кстати, на сайте http://oberoncore.ru изображена белка.
Это имеет отношение к Оберон-технологии или к городу Орел?
Тогда можно и так: "Белка на цветке Розы, умывающаяся утренней Росой".