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

Т.е. это просто "бумажка"? Инструкция по эксплуатации (для пользователей и для разработчиков)? Нарушил -- твои проблемы?

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

Чем это тогда отличается от сопроводительной документации на ОС?
Что именно "это"?

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

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

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

Система Oberon -- характерный пример вольницы. Там можно написать свой (пользовательский) модуль, в котором любая экспортируемая процедура без параметров автоматически становится командой ОС. Круто!
Положите написанную Вами программу (или скрипт) в /usr/bin (в *nix) или в Windows\System32. Она станет командой ОС?

Ответ на »сообщение 2307« (Мухтар )
___________________________

Таким образом, чтобы определить эту грань, Ваша команда должна утвердить характеристики ОС и ее правила эксплуатации:

Т.е. это просто "бумажка"? Инструкция по эксплуатации (для пользователей и для разработчиков)? Нарушил -- твои проблемы? Чем это тогда отличается от сопроводительной документации на ОС? Как быть с эволюционированием ОС (ее обновлениями)? Очевидно, что любое обновление ОС теоретически означает поставку НОВОГО продукта. В котором может быть иной состав компонентов (номенклатура "товаров" и "услуг"). С иным поведением. С иными правилами эксплуатации.

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

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

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

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

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

>3. Нужно ли ее проводить?
Значит, с точки зрения пользователя есть четкая граница между ОС (которую он не "видит") и прикладной программой. Выражается она в том, что ОС имеет стабильное поведение, не зависящее от наличия прикладных программ. Мне думается, что этот вопрос решается на уровне стандартов, которым должны следовать прикладные программы.

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

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

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

Что, интересно, думают разработчики Росы о пост-обероне, и почему бы не завести соответствующий форум здесь: http://forum.oberoncore.ru/viewforum.php?f=42 ?

Выскажу свою точку зрения. Как уже говорил, для публичного обсуждения технических вопросов по проекту Роса планируется на OberonCore открыть специальные ветки.

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

Что касается регламентации размеров описания, то пожелания понятны. Другое дело, сможем ли вписаться в это "прокрустово ложе". :)

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

Это пожелание тоже понятно. Несколько лет назад, будучи научным редактором "Мира ПК" и тесно контактируя c крупными зарубежными компаниями (по линии EPAM Systems по вопросам перевода промышленной документации) поднимал вопрос о целесообразности унификации компьютерной терминологии. Предлагал организовать рабочую группу из ряда редакторов ведущих ИТ-изданий, представителей ведущих издательств, а также специалистов по локализации в крупных зарубежных компаниях (прежде всего, Microsoft). Увы, инициатива заглохла, а жаль.

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

Графические объекты нужно называть графическими объектами, а не словом view, которое в применении, например, к базам данных означает запрос.

Если речь идет о термине "view" в понимании известной триады MVC (model -- view -- controller), то view -- это не графический объект в этой схеме, а абстракция отображения (визуализации) сущности (объекта). Т.е. это форма внешнего (визуального) представления некоей сущности. Как это лучше сформулировать в виде слова или словосочетания не знаю. Можно подумать, но это лишний раз показывает, что в переводах не все так просто. Есть очень много факторов, которые влияют на формирование терминологии. Увы, редко переводчики хотят тратить свое время на изучение истоков появления тех или иных терминов, а также на согласование варианта перевода с другими терминами в общем контексте. Яркий пример проблем непонимания (незнания): computing, computer science, computing science, informatics. Это разные понятия, которые переводят как "информатика" или как "компьютерная наука" (компьютерные науки), считая синонимами. Сам был грешен, пока не разобрался.

Ответ на »сообщение 2304« (Руслан Богатырев)
___________________________
Операционная система - это набор стандартизированных программ, библиотек, сервисов и норм для осуществления работы прикладного обеспечения. (мое)

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

Таким образом, чтобы определить эту грань, Ваша команда должна утвердить характеристики ОС и ее правила эксплуатации:

а)для пользователей
б)для сторонних разработчиков

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

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


Обратите внимание еще на такой момент. В отношении языков мы ориентируемся на привилегированную тройку (пост-Oberon, Haskell и Python), а также "примкнувшие" к ним непривилегированные Си и Java.



Что, интересно, думают разработчики Росы о пост-обероне, и почему бы не завести соответствующий форум здесь: http://forum.oberoncore.ru/viewforum.php?f=42 ?

Я искренне надеюсь, что описание пост-оберона для широкой публики существенно превысит пресловутые 16 страниц (тем более, на русском языке) и будет комментированным стандартом, включая мотивацию, примеры и ссылки. Что касается возможных объемов, то нормальными для меня выглядят следующие цифры (в случайном порядке):
10 страниц - описание отличий от Компонентного Паскаля
150 страниц - комментированное описание семантики языка
30 страниц - иллюстрированный справочник по синтаксису языка
5 страниц - стандарт создания идентификаторов и оформления текстов программ
100 страниц - описание среды разработки
200 страниц - описание стандартной библиотеки
50 страниц - описание интеграционных возможностей и средств их реализации (важнейший раздел)
20 страниц - описание дисциплины и характерного стиля программирования
50 страниц - руководство по программированию типовых задач (работа с кодировками, с гипертекстом, с файловой системой, с базами данных, проектирование GUI, создание веб-вервиса и т.п.)
10 страниц - описание рекомендуемого технологического процесса разработки и отладки программ
10 страниц - FAQ
10 страниц - тезаурус

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

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

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


Вопросы простые:
1. Где можно провести границу между ОС и остальным программным миром ("не-ОС")?
2. Можно ли вообще ее провести?
3. Нужно ли ее проводить?

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

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

3. А тут я попытаюсь высказать мнение с точки зрения пользователя ОС. Я использую всегда приложения, будь оно в составе ОС, или установленное дополнительно. Практически никогда не болела голова о том, что делается в ядре и служебных сервисах системы. Но зато сталкивался довольно часто с тем, что после установки новой программы ОС ведет себя уже по-другому. И даже удаление программы не всегда спасает. Значит, с точки зрения пользователя есть четкая граница между ОС (которую он не "видит") и прикладной программой. Выражается она в том, что ОС имеет стабильное поведение, не зависящее от наличия прикладных программ. Мне думается, что этот вопрос решается на уровне стандартов, которым должны следовать прикладные программы. Если разработчик ОС сумеет пресекать нарушение этих стандартов, то задача будет иметь практическое решение. Отсюда следует, что ничего похожего на закидывание библиотек в раздел System, или редактирование реестра, не должно допускаться. Боюсь, что такую ОС нельзя сделать. Т.е. вернулись к пукту 2.

Есть достаточно важная цепочка вопросов, напрямую связанных с проектом "Роса". Хотелось бы узнать различные точки зрения.

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

Вопросы простые:
1. Где можно провести границу между ОС и остальным программным миром ("не-ОС")?
2. Можно ли вообще ее провести?
3. Нужно ли ее проводить?

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

А Дельфи под РОСой будет работать? Ну или иной приличный RAD?

Не могли бы Вы перечислить тот RAD-инструментарий, который считаете "приличным", а заодно хотя бы вчерне некоторые критерии "приличности"?

P.S. Если в Росе будет реализован в полноценном виде POSIX и в список "приличного" инструментария попадет такой, который опирается исключительно на POSIX, то вопрос его переноса в новую систему решается сам собой.