Ответ на »сообщение 2460« (panda)
___________________________
Одно дело "встроенность" оконных менеджеров (или даже DE) в современных дистрибутивах Linux (есть полная свобода выбора - GNOME, KDE, IceWM, Xfce, и множество других - вы можете удалить тот, который вам предустановлен и бесшовно встроить любой другой, а поверх него навесить еще и compiz или beryl). И совсем другое дело - встроенный GUI Windows.
Файловая система - дело иное, хотя современные системы в этом тоже всеядны.
Ни одна приличная ОС не пустит пользователя напрямую к диску - только через ФС.
Но и с помощью ФС при современных объемах носителей пользователь быстро создает такую свалку, в которой сам разобраться не в состоянии.
СЭД - следующий уровень обеспечения управляемости информации. Он накладывает дополнительные ограничения на деятельность пользователя и как все подобные механизмы работает только если не может быть отключен (во всяком случае без административных прав). Немногочисленные удачные внедрения СЭД, которые я встречал, работают именно так - пользователь вообще не видит файловой системы, ему доступны только документы.

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

Ответ на »сообщение 2486« (Руслан Богатырев)
___________________________
Иван, видимо, имел в виду этап построения самой ОС, а не средств которыми будет пользоваться разработчики Роса. Что касается экспериментов (работ) над Norebo, то прежде обсуждать отдельные средства языка хотелось бы иметь о нем общее представление. Будет ли для этого достаточно сообщения на evroprog.ru?

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

Все-таки непонятно, зачем пестовать три языка, то есть, три разных синтаксиса для одного и того же. Не лучше ли объединить их в один язык? Хочешь программировать последовательность действий - используешь одни конструкции языка. Хочешь делать универсальные абстрактные функции - используешь другие конструкции языка. А хочешь быстро склеить работоспособный макет программы из готовых частей - используешь третьи конструкции языка. Чтобы их было проще изучать, можно в учебнике разделить конструкции единого языка по парадигме программирования. Не будет необходимости изучать три разных синтаксиса, три разных набора ограничений, три разных модели безопасности типов, три разных модуля системы быстрой разработки и т.д.

Подобная прямолинейность (если не сказать наивность) и привела к рождению на свет Алгол-68, PL/I, C++. Не стоит наступать на грабли тех "алхимиков", которые столько лет безуспешно искали "философский камень".

Вкратце изложил свой взгляд в заметке: "RB27. Пути восхождения к новой ОС" -- http://rbogatyrev.livejournal.com/2007/08/31/

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

Ответ на »сообщение 2478« (anonymous.ru)
___________________________

по поводу перемещения ОС (или правильней Операционного Окружения)

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

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

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

В дополнение к Norebo устойчивую языковую группу могут образовать язык функционального программирования (пока здесь главный кандидат Haskell), а также сценарный (скриптовый) язык (здесь основной кандидат Python).

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

В отношении скриптовых языков (СП), которые, на мой взгляд, проистекают из Лиспа (хотя, это спорно), некоторые вопросы и свою позицию попробовал изложить в статье 6-летней давности: "Природа и эволюция сценарных языков", http://www.osp.ru/pcworld/2001/11/162500/
Полная версия (в PDF) -- http://www.europrog.ru/rb/rb0111.pdf

В контексте проекта новой ОС эта статья дает определенную пищу для размышлений.


Все-таки непонятно, зачем пестовать три языка, то есть, три разных синтаксиса для одного и того же. Не лучше ли объединить их в один язык? Хочешь программировать последовательность действий - используешь одни конструкции языка. Хочешь делать универсальные абстрактные функции - используешь другие конструкции языка. А хочешь быстро склеить работоспособный макет программы из готовых частей - используешь третьи конструкции языка. Чтобы их было проще изучать, можно в учебнике разделить конструкции единого языка по парадигме программирования. Не будет необходимости изучать три разных синтаксиса, три разных набора ограничений, три разных модели безопасности типов, три разных модуля системы быстрой разработки и т.д.

Чем плодить несколько языков программирования, целесообразнее расширять инструментарий разработки: хочешь - рисуешь схемки, которые автоматически преобразуются в код, хочешь - набрасываешь код с помощью построителя, хочешь - последовательность твоих действий автоматически запишется в код, и т.д. См. http://forum.oberoncore.ru/viewtopic.php?f=7&t=389&p=8291#p8291

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

Имелось в виду, видимо, другое - не паразитирование на массовом браузере (что само по себе приятно), а возможность переноса части функциональности ОС в веб-сервис.

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

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

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

Но о делах придется говорить все же словами :)

1. На каком алгоритмическом языке будет разрабарываться РОСа?

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

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

2. Как привлечь к разработке программистов (агитация не поможет!)?

Не торопитесь. Проект стартовал полтора месяца назад. Никаких специальных шагов для рекрутинга не предпринималось (оно и понятно, сейчас мы готовим в основном бумаги для развертывания-раскатки процесса и вырабатываем подходы к работе). При этом он уже насчитывает два десятка специалистов из России, Беларуси, Украины, Узбекистана, Израиля. Для сравнения -- в Singularity team примерно 35 человек.

3. Какой опыт можно извлечь из разработки  LINUX?

Положительный и отрицательный. Некоторые детали можно найти в след. моих публикациях:
1. Linux: истоки новой философии программирования (2001) -- http://www.europrog.ru/rb/rb0101.pdf
2. "Открытость программирования" и пред.заметки -- http://rbogatyrev.livejournal.com/2007/07/12/

4. Как максимально использовать возможности Интернет?
5. Как создать коллектив программистов на базе виртуальной машины
    в Интернет?

Это важные вопросы. Предполагается их решать с учетом опыта организации глобального аутсорсинга (промышленный подход) и хаотической дистанционной работы отдельных индивидуалов в рамках Open Source. По первому в качестве введения можно посмотреть мою работу: "От офшорного программирования к глобальному производству" -- http://www.osp.ru/os/2001/07-08/180316/

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

Один из участников нашего проекта, Евгений Прохоров (Geniepro) приводил тут как-то ссылку на работу Спольски "Огонь и движение" См. »сообщение 2458«

Спольски конечно не открыл Америку, рассказывая об эффективности использования рабочего времени в корпоративной среде. Несмотря на пользу привычной для корпоративного рынка концентрации сотрудников в офисе (где можно получить быстро консультации у коллег и вариться в единой среде работы), в итоге продуктивны в день всего 2-3 часа. Остальное уходит впустую (на вторичные вещи). Это издержки синхронности. Распределенная работа позволяет добиться асинхронности. Если участник занят в проекте частично, в свободное от работы время (я не говорю сейчас о финансовой стороне дела, которая может быть сюда подтянута со временем при условии грамотного продвижения), то он вполне может уделять проекту время, сопоставимое с упомянутым эффективным временем (напр., 1-1,5 часа в день). Только в корпоративной среде он работает "на дядю", а здесь -- "на себя". В этом существенная разница мотивации. Осталось только создать условия, при которых участник осознает, в чем состоит работа на себя, зачем она ему нужна и выгодна ли при таком раскладе.

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

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

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


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


Имелось в виду, видимо, другое - не паразитирование на массовом браузере (что само по себе приятно), а возможность переноса части функциональности ОС в веб-сервис.

Ответ на »сообщение 2476« (Ка джа)
___________________________

Такая мысль - нужна школа программирования в рамках Open Research Programming.

Это планируется делать в рамках Европейского центра программирования (www.europrog.org).

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

Относительно первого пункта есть рабочее название. Само его описание нужно дать в месте предназначенном для размещения материалов по РОСа. OberonCore.ru, например.

Большая просьба ко всем -- не искажать название ОС и проекта. Он пишется так: "Роса" (Rosa). Это не аббревиатура!

Что касается места размещения информации по новой ОС, то по всей видимости это будет сделано в рамках Европейского центра программирования (www.europrog.ru). OberonCore концентрирует в себе информацию по линии Оберонов (это одна из составляющих проекта) и является базой для организации сообщества (community). Это разъяснялось в »сообщение 2188«.