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

А вот необходимость строгого (математически строгого) определения понятия "документ" вытекает.

В принципе тут можно отталкиваться от стандарта ГОСТ ИСО 15489-1:2007 "Управление документами. Общие требования" -- http://www.directum-journal.ru/files/1859439.pdf

Не претендуя на строгость и точность определения, скажу, что документом можно считать то, что:
1. хранится на материальном носителе
2. содержит информацию в понятной (наглядной) для человека форме (органы чувств: зрение, слух), при наличии соответствующего оборудования вполне допустимы и дополнительные формы представления (органы чувств: осязание, обоняние, вкус).
3. отчуждаемо от автора
4. имеет однозначную идентификацию в отношении времени создания/отчуждения, авторства и источника публикации.
5. содержит указание на источник хранения оригинала с возможностью проверки достоверности (как информации, так и авторства -- электронная подпись).

Документ в бытовом понятии документом с моей точки зрения не является. Это просто текст или иллюстрация (даже если помимо текстовой информации там содержатся другие виды представления).

Мне кажется, тут есть научная задача: создание теории документов и теории документооборота.
Без этого трудно представить себе хорошее ТЗ на механизмы реализации.

Это интересная задача -- учесть наличие функционала обеспечения документооборота в прикладном уровне для ОС, рассчитанной на офисное применение. Мы, правда, вторгаемся в область docflow/workflow, но область весьма знакомая. Подразумевает ввод и регистрацию документов, согласование, поиск, маршрутизацию, создание отчетов, ведение архива, ролевое управление и регулирование правами доступа в системе.

Хорошо, давайте зайдем не со стороны внутренних механизмов ОС.
И даже не со стороны устройства прикладных программ.
В конце концов нас интересуют только функциональные возможности программно-аппаратного комплекса, а не его устройство.
Поскольку первой цервыми клиентами должны быть учебные учреждения и госуреждения, посмотрим необходимый им базовый функционал.
Прежде всего такие системы будут выступать, как системы документооборота.
Во вторых это будут системы учета.
Из этих задач не вытекает, например, необходимости понятия файла.
А вот необходимость строгого (математически строгого) определения понятия "документ" вытекает.
Тот же текст другим шрифтом, это тот же документ или другой?
Разработчики XML разделили структуру, форму и содержание документа, но и XML определен в основном "разговорным" способом.
Мне кажется, тут есть научная задача: создание теории документов и теории документооборота.
Без этого трудно представить себе хорошее ТЗ на механизмы реализации.

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

Приведите пример хотя бы одного проекта Open Source, который делится ВСЕМИ промежуточными результатами.

Есть конструктивное предложение. Можно ли общими усилиями сформулировать перечень (номенклатуру) материалов и примерную глубину их освещения, которые очень нужны общественности в ходе ведения проекта? Очевидно, что подготовка материалов (осмысление и написание) требует времени. Хотелось бы понять, как распоряжаться временем так, чтобы дело не пострадало и общественность была удовлетворена. Как там в "Напарнике" из "Операции Ы": "Огласите весь список, пожалуйста"...

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

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

Что интересно, одно другому не противоречит. В свое время показывал интересующим, как использовать Template Language для генерации исходного текста на любом языке (и не только программирования). Он далеко не идеал, но дает практическую схему решения задачи генерации каркасов и последующей конкретизации их. Причем не обязательно в диалоговом режиме. Ибо сам Template Language -- это язык.

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

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

Руслан, складывается такое впечатление по поводу вашей активности:
группа местных "оберонщиков", не удовлетворившись функционалом BlueBottle, решила создать собственную операционную систему на Oberon'е.

Ложное впечатление.

Причем удовлетворять свои любопытство и амбиции решили за счет государства. 

Еще одно ложное впечатление. Мы не просим денег у государства. Фазу НИОКР можно сделать без денег. Идея создать ОС, которая может быть востребована государством (государственная ОС), -- это путь от экспериментальной ОС (которой мы хотим заниматься и уже занимаемся) к массовому потребителю. Путь не единственный, но возможный. Поэтому не надо к нам прилеплять ярлыки. Если мы и будем претендовать на гранты, то на общих основаниях, в рамках проводимых работ. Решат, что нужно выделить гранты, -- хорошо. Решат, что не нужно, -- обойдемся.

1. В техсовете одни оберонщики.

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

2. Авторитарность управления (сразу было жестко сказано что делать будут на Обероне и по своим хитрым алгоритмам).

Авторитарность управления -- это условие выживания крупных, долгосрочных проектов. Странно, что это надо еще объяснять. Делать будем совсем необязательно на Оберонах. На Оберонах будем вести фазу НИОКР (кстати, не только на Оберонах).

3. Привлечение к пиар-акции людей с сомнительной репутацией (Алкснис, Гудков, Хинштейн).

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

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

4. Нежелание делиться промежуточными результатами, догадками, эвристиками, то есть подмена Open Document на Open Research, которая ничем не отличается по существу от Open Source.

Обращался по этому поводу к Сергею Перовскому (»сообщение 1722«), но в ответ услышал красноречивое молчание. Обращаюсь теперь и к Вам -- приведите хотя бы один пример подобного проекта открытого НИОКР, который решает задачу создания сложного системного ПО с передачей его массовому пользователю в исходных текстах на условиях public domain. Именно НИОКР, открытости с первого дня проекта (и даже раньше). Приведите пример хотя бы одного проекта Open Source, который делится ВСЕМИ промежуточными результатами. С интересом посмотрю на подобный опыт и приму его на вооружение.

Чем отличается Open Research Programming от Open Project Documentation, признал сам автор второго подхода. Чем отличается Open Project Documentation от Open Source -- детально изложено. Либо нет желания читать и разбираться, либо что-то другое. По-новому перечислять отличия не буду. Достаточно будет посмотреть на Ваши контрпримеры проектов, подобных нашему. Тогда будет что предметно обсуждать.

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

Может быть я неправ, но с трудом верю в то, что команда "Перспетивная ОС", или ГИРС (как-то мы обсуждали имя команды) может справиться с созданием прикладного ПО и с ОС одновременно.

О какой команде и каком численном ее составе мы говорим? Я уже приводил примерные прикидки того, когда произойдет выход на проектирование и на начало разработки ОС (не прикладного уровня!). Убежден, что даже через полгода мы будем иметь несколько иную ситуацию по команде (имеется в виду кадровый состав), в сторону увеличения нашего потенциала. Первый год -- это не только начало НИОКР, но и год создания команды.

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

А если она именно в этих фичах будет Windows превосходить? В том числе и по "обертке", по качеству эстетического восприятия?


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

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

2. ГИРС оценить возможность реализации означенной функциональности за те сроки, которые по прогнозам будут допустимы. Надо иметь ввиду, что развитие событий под флагом "Свобода от Билла!" не будет откладываться в интересах получения результатов работы ГИРС. Если ОС не будет подана к столу, то можно сильно промазать. Не будет спать и Microsoft. Он в курсе тех же событий и еще у него фора в виде массы технологий, финансов и много чего еще. И рынок в части интересов перспективной ОС пока в его руках.

Было бы большой наивностью вступать в открытый бой с Microsoft. Мы пойдем иначе -- у нас будет экспериментальная ОС, сделанная не совсем традиционным образом, с претензией на интересные технологические разработки. При этом мы не ограничимся (как Bluebottle) демонстрацией перспектив и уходом в узкую нишу на коммерческую почву.

3. Критически осмыслить затею (извините, пока по-другому не могу сказать) по одновременному созданию прикладных программ типа Office и самой ОС. "Не промахнись, Асунта!" Во что я точно не верю, так это в авантюры. Обозначенная компактность прикладных программ и свобода, связанная с отсутствием необходимости обеспечения обратной совместимости, на деле могут оказаться иллюзиями.

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

4. Т.к. по п3 еще нет данных и по моим оценкам их не будет очень долго, определить, какие форматы файлов должны поддерживаться (не уверен, что такие требования выходят прямо на ОС, поэтому могу ошибиться). И иметь ввиду, что придется в целях выживания работать с существующими прикладными пакетами, вплоть до MS Office. Надо выбрать путь минимальных затрат и вырвать инициативу из рук монополий.

Подобную задачу (определиться с функционалом и форматами) можно решить за несколько месяцев. Вопрос приоритетов.

Тут преимущество будет иметь не столько тот, у кого в загашнике сверхновые технологии, а тот, кто лучше сконцентрирует свои силы в нужном направлении. Если бы я был директор, то наряду с командой Руслана Богатырева, снярядил бы еще команду с Линуксом.

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

>Но ОС должна быть проста для использования.
Сразу возникает вопрос "зачем"? Мы не собираемся конкурировать по простоте
Я тут вижу зародыш просчета! Пока обсуждать не буду. Просто мне было бы интересно послушать мнение по этому вопросу у разных людей на этом форуме. Кстати говоря, Линукс в этом проигрывает Windows-у.

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

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

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

Согласен, что безопасность - на первом месте. Но что за безопасность может обеспечить ГИРС?

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

Надежность.
Вы хорошо знаете, что обеспечить надежность 90% и 95% - усилия и затраты отличаются на порядки. Не могу привести в цифрах, но по интуитивным оценкам надежность Windows XP - очень хорошая. Будет на первых порах достаточно иметь и такую.

Надежность не будет самоцелью. Она не будет и получаться автоматом. Тем не менее, мы будем уделять ей внимание. Тот уверень надежности, который сейчас могут обеспечивать конкретные Оберон-реализации, лично меня для данного проекта не устраивает.

Ответ на »сообщение 1757« (Руслан Богатырев)
___________________________
Я бы уточнил: Windows и базового прикладного ПО, важным элементом которого является Microsoft Office.
Может быть я неправ, но с трудом верю в то, что команда "Перспетивная ОС", или ГИРС (как-то мы обсуждали имя команды) может справиться с созданием прикладного ПО и с ОС одновременно. Вам, конечно, виднее, только могу гарантировать на 100%, что пользователя вообще не будет интересовать, кто разработал ОС. Необходимость выдержать конкуренцию с Windows чисто по внешним показателям (с фичами, которыми пользуются те самые 80% пользователей) - это объективно. Новая ОС очень легко может быть отвергнута, невзирая на все ее перпективы, если она будет заметно уступать Windows.

Поэтому (с учетом всех вышестоящих постов) вижу актуальными следующие мероприятия:
1. Сделать ревизию функциональности Windows в ракурсе потребительских свойств, выходящих на массового пользователя и выделить список, образующий необходимую функциональность в будущей ОС. При этом надо отдавать себе отчет в том, что решать, хороша ли ОС, будет не команда высококвалифицированных спецов, а простой пользователь. Он и решит судьбу ОС.
2. ГИРС оценить возможность реализации означенной функциональности за те сроки, которые по прогнозам будут допустимы. Надо иметь ввиду, что развитие событий под флагом "Свобода от Билла!" не будет откладываться в интересах получения результатов работы ГИРС. Если ОС не будет подана к столу, то можно сильно промазать. Не будет спать и Microsoft. Он в курсе тех же событий и еще у него фора в виде массы технологий, финансов и много чего еще. И рынок в части интересов перспективной ОС пока в его руках.
3. Критически осмыслить затею (извините, пока по-другому не могу сказать) по одновременному созданию прикладных программ типа Office и самой ОС. "Не промахнись, Асунта!" Во что я точно не верю, так это в авантюры. Обозначенная компактность прикладных программ и свобода, связанная с отсутствием необходимости обеспечения обратной совместимости, на деле могут оказаться иллюзиями. 
4. Т.к. по п3 еще нет данных и по моим оценкам их не будет очень долго, определить, какие форматы файлов должны поддерживаться (не уверен, что такие требования выходят прямо на ОС, поэтому могу ошибиться). И иметь ввиду, что придется в целях выживания работать с существующими прикладными пакетами, вплоть до MS Office. Надо выбрать путь минимальных затрат и вырвать инициативу из рук монополий. Тут преимущество будет иметь не столько тот, у кого в загашнике сверхновые технологии, а тот, кто лучше сконцентрирует свои силы в нужном направлении. Если бы я был директор, то наряду с командой Руслана Богатырева, снярядил бы еще команду с Линуксом.

Но ОС должна быть проста для использования.
Сразу возникает вопрос "зачем"? Мы не собираемся конкурировать по простоте
Я тут вижу зародыш просчета! Пока обсуждать не буду. Просто мне было бы интересно послушать мнение по этому вопросу у разных людей на этом форуме. Кстати говоря, Линукс в этом проигрывает Windows-у.

С позволения команды, предложил бы зафиксировать эти по-существу 4 цели НИОКР, как присущие перспетивной ОС качества.
Это далеко не полный перечень, но некие контуры дает. При этом конутры внутренние (полуфабриката), тогда как в направлении требований здесь мы затрагиваем внешние. А они совсем не обязательно должны коррелировать. Как сделан функционал -- для потребителя по большому счету неважно.

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

Что касается безопасности.
Мне кажется у безопасности есть несколько важных аспектов. Я тут не спец, но думаю, что есть уровень безопасности, который безусловно должен быть реализован в ОС. Ну хотя бы защита ядра.
С точки зрения пользователя безопасность - это защита от проникновения. Только тут нет 100% гарантий защиты. Поэтому когда ГИРС берется обеспечить защиту - у меня возникает желание задать кучу вопросов и понять, что она может обеспечить. Команда же не изменит протоколов, используемых в сетях! Когда ОС начнет жить, когда у хакеров появится необходимость преодолеть барьеры защиты (а хакеры бывают и такие, что у них средств будет поболее, чем у разработчиков ОС), вот тогда можно будет что-нибудь конкретное понять. Согласен, что безопасность - на первом месте. Но что за безопасность может обеспечить ГИРС?

Надежность.
Вы хорошо знаете, что обеспечить надежность 90% и 95% - усилия и затраты отличаются на порядки. Не могу привести в цифрах, но по интуитивным оценкам надежность Windows XP - очень хорошая. Будет на первых порах достаточно иметь и такую. Переход от 95% до 99% пользователь никогда заметит. Поэтому повторюсь - "Не промахнись, Асунта!", занятие дорогое. Другое дело, когда надежность обеспечивается архитектурой. Но не забывайте, что высоконадежная ОС, помещенная в неблагонадежную среду (железо) будет оплевана. Я видел, как врал QNX, производивший запись потока данных в файл на Windows-машине в сети. Данные в файле оказывались с существенными искажениями. А на свой диск все писалось без ошибок.

Руслан, складывается такое впечатление по поводу вашей активности:
группа местных "оберонщиков", не удовлетворившись функционалом BlueBottle, решила создать собственную операционную систему на Oberon'е. Причем удовлетворять свои любопытство и амбиции решили за счет государства.  Для этого была развернута большая шумиха о необходимости государственной ОС.
На такое мнение наводят следующие факты:
1. В техсовете одни оберонщики.
2. Авторитарность управления (сразу было жестко сказано что делать будут на Обероне и по своим хитрым алгоритмам).
3. Привлечение к пиар-акции людей с сомнительной репутацией (Алкснис, Гудков, Хинштейн).
4. Нежелание делиться промежуточными результатами, догадками, эвристиками, то есть подмена Open Document на Open Research, которая ничем не отличается по существу от Open Source.

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

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

Стэн, Вы видели такую прелестную штуку, как SoftVelosity Clarion (http://www.clarion.ru)?
Море возможностей. Функциональности по горло, не захлебнуться бы. Я с этой штукой недавно распрощался, хотя разрабатывал на нём софт с 1996 года. И перешёл на BlackBox.
И вот что скажу - почти вся эта "функциональность" - дутая. Содержание подменяется формой. Вместо работы над задачей предлагается работать над средой, бесконечно тыкать в красивые кнопки.

Не могу в полной мере согласиться. Отслеживаю Clarion с конца 1980-х (с Clarion Professional Developer). Особенно активно после приобретения Брюсом Баррингтоном (автором языка Clarion, идеологом системы и ее хозяином) компании TopSpeed и всей линейки TopSpeed-компиляторов. Там есть интересные технологические находки, до которых в BlackBox еще не дошли. Например, Template Language и вся кухня построения исходников с обеспечением интерактивной настройки процесса генерации.

Да-да, генерация монолитного приложения по шаблонам. С одной стороны, это впечатляет. Описал сущности предметной области в словаре, запустил визатрон, и за 5 минут получил работающий макет приложения.
С другой стороны, такой подход, как оказывается, хорош только для генерации однотипных приложений. Если нужно делать что-то новое, что-то особенное, то сразу же всплывают нюансы, заслоняющие суть. Среда, язык шаблонов, сами шаблоны-компоненты (но это же не настоящие компоненты, это блоки настройки генератора кода), ограничения словаря, ограничения драйверов БД (не зря же они выпустили Dynamic Driver). Развитие приложения тоже затрудняется, так как родная поддержка БД не предусматривает динамического расширения описания таблиц. А что вы хотите - у нас же монолитное приложение, опирающееся на метаданные. Будьте добры - меняйте метаданные и перегенерируйте всё.
Если много клиентов, у всех стоят разные версии, то простое добавление одного поля в таблицу превращается в головную боль, ведь старая программа просто не заработает на новой (расширенной) таблице.
Добираться до точек вставок своего кода тоже особая песня. Не знаю, как в С6 (много было заявлений о переходе на plain text), но в предыдущих версиях это не сильно тривиальная задача :)

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

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

Стэн, Вы видели такую прелестную штуку, как SoftVelosity Clarion (http://www.clarion.ru)?
Море возможностей. Функциональности по горло, не захлебнуться бы. Я с этой штукой недавно распрощался, хотя разрабатывал на нём софт с 1996 года. И перешёл на BlackBox.
И вот что скажу - почти вся эта "функциональность" - дутая. Содержание подменяется формой. Вместо работы над задачей предлагается работать над средой, бесконечно тыкать в красивые кнопки.

Не могу в полной мере согласиться. Отслеживаю Clarion с конца 1980-х (с Clarion Professional Developer). Особенно активно после приобретения Брюсом Баррингтоном (автором языка Clarion, идеологом системы и ее хозяином) компании TopSpeed и всей линейки TopSpeed-компиляторов. Там есть интересные технологические находки, до которых в BlackBox еще не дошли. Например, Template Language и вся кухня построения исходников с обеспечением интерактивной настройки процесса генерации. В свое время занимался вскрытием и детальным описанием нюансов реализации, в частности, формата драйверов БД.

Что касается дутости функционала и аморфности языка Clarion, который своей тушей заслонил все остальное, то есть такое дело. Но замысел системы и отдельные решения достаточно интересны. Даже сейчас.