Здравствуйте!
Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой
ОС. Причём не только русской, но и всего русскоговорящего населения?
Присоеденились бы вы к такому проекту?
Прошу не относить к флейму. Речь идёт о уже существующем проекте.
С уважением,
VICH
Всего в теме 5452 сообщения
Отслеживать это обсуждение 
| № 2372 26-08-2007 14:30 |   |
Ответ на »сообщение 2363« (Руслан Богатырев)
___________________________
Ответ на »сообщение 2362« (Сергей Прохоренко)
___________________________
1. А будет ли позволено надстроить служебную СУБД до уровня полноценной промышленной универсальной СУБД? Бывают ситуации, когда какую-то информацию можно хранить как в форме файлов, так и в форме полей БД.
Доступ приложений к служебной СУБД предусматривается в т.ч. и для своих прикладных целей (а не только для получения системной информации).
По остальным вопросам -- пока за рамками обсуждения.
И очень зря. Самое время обсудить. Напомню вопросы:
3. Будет ли организован статический (буфер обмена, импорт-экспорт данных) и динамический (связи с таблицами СУБД, электронными таблицами, встроенные объекты и т.п.) обмен данными между приложениями (включая аплеты), работающими под разными ОС?
4. Будет ли возможно нескольким приложениям новой ОС одновременно работать с одним документом?
Эти вопросы не на пустом месте появились. Если приложения не будут иметь хороших средств интеграции, то никто не будет использовать ни сами приложения, ни ОС, для которой они написаны.
Вот, например, только что появилась интересная статья: http://citcity.ru/16663/#comments "Интеграция приложений такая, как она есть". Автор вполне обоснованно пишет, что разработчики приложений не заинтересованы в интеграции, и не предоставляют API.
Поэтому, я считаю, что ОС должна брать проблему интеграции приложений на себя. Ключевые средства интеграции должны быть заложены в API ОС. Более того, должно быть невозможно написать неинтегрируемое приложение для новой ОС. Она должна быть как ДНК, к которой могут пристыковываться только нуклеотиды или пептиды определенной структуры. Если приложение не отвечает требованиям интегрируемости, то ОС не должна позволять ему работать.
Поэтому никакое приложение не должно восприниматься как священная корова, структура которой есть прихоть создателя. Структура приложений должна диктоваться разработчиками ОС. Приложения обязаны работать с теми средствами (открытые форматы данных, средства переноса данных и создания связей между документами и т.п.), которые заложены в ОС и попутно обеспечивают интегрируемость приложений. Им не должно быть позволено использовать собственные закрытые аналоги таких средств.
Всё это, конечно, не укладывается в концепцию "ОС в виде небольшого ядра + анархия приложений", которую, разработчики ОС, слава богу, не поддерживают.
| № 2371 26-08-2007 12:11 | |
Некоторые предложения по интерфейсу ОС:
1. Должна создаваться виртуальная папка "открытые документы" - разработчики операционных систем всё никак не могут пристроить на экране ярлыки открытых
документов.
2. Нужно попытаться стереть грани:
(а) между приложениями, запускаемыми в окне браузера и обычными приложениями;
(б) между браузером, менеджером файлов, поисковиком, вьюером картинок, видеоплеером, вьюером презентаций, вьюером pdf-документов и прочих текстовых
документов, вьюером электронных таблиц и диаграмм (то, что получится в результате, может иметь рабочее название "универсальный браузер"). Приложения не
должны иметь собственных окон для отображения документов, а должны выглядеть как инструментальные панели и приборные панели (формы) для манипуляций над
объектами, единообразно отображаемыми "универсальным браузером" ОС. В зависимости от того, какие объекты выделены для манипуляций, отображаются те или иные
инструментальные панели;
(в) между окнами открытых документов, виджетами и формами;
(г) между первичными и вторичными окнами приложений (специализация всплывающих окон должна сохраниться),
(д) между ярлыком для доступа к файлу и обозначением самого' файла в открытой папке.
3. Нужно похоронить такие реликты, как:
(а) "рабочий стол" (свалка, выставленная на всеобщее обозрение) - если пользователю нравится картинка рабочего стола, то её можно пристроить в виртуальную
папку для хранения часто используемых ярлыков приложений и документов;
(б) папка "мои документы" (означает, что общедоступны потрохи программ, хранимые за пределами этой папки).
Anybody home?
| № 2370 26-08-2007 07:48 | |
| № 2369 24-08-2007 19:18 | |
Ответ на »сообщение 2241« (Сергей Прохоренко)
___________________________
Ответ на »сообщение 2239« (Сергей Перовский)
___________________________
Ответ на »сообщение 2232« (Сергей Прохоренко)
___________________________
Я бы предложил классифицировать задачи по следующим четырем критериям (с примерами в скобках):
1. реального времени (автоматическое управление транспортом) - с разбивкой задач по приоритетам или общего назначения (GUI)
2. требующие высокой надежности (управление самолетом) или допускающие отказы (видеоигры)
3. с небольшим потоком данных (телеметрия) или с большим потоком данных (потоковое видео)
4. с минимальными ресурсами (гаджеты - ограничения по объему, массе и стоимости; сети конроллеров в автомобилях и встроенные системы для бытовой техники - ограничения по стоимости), с большими ресурсами (бортовые компьютеры спутников и самолетов - ограничения по массе) или с неограниченными ресурсами (серверы, персоналки)
Для каждого класса задач (сочетания значений четырех критериев) может быть свой подход к организации памяти, свой состав модулей ОС, свой набор допустимых языков программирования.
Очень люблю цитировать эту фразу Азимова: число два не имеет физического смысла :)
1. Необходимая скорость реакции.
2. Требуемая надежность.
3. Максимальные потоки входящей и исходящей информации.
4. Требуемая вычислительная мощность.
5. Ограничения на технические средства (массо-габаритные, стоимостные, по потребляемой мощности и т.д.).
Получится не таблица а пространство, в котором придется выделять области применимости тех или иных решений.
Вы любите fuzzy-логику? А я - булеву алгебру. Правда, последний критерий у меня имеет три значения... Ну, ведь были же ЭВМ с тремя состояниями логических ячеек.
Мне кажется, что грубый здравый смысл будет полезнее, чем микрометр. То есть, понимания на качественном (в философском смысле) уровне достаточно, и ни к чему особо количественные измерения. Только потеря времени. Можно даже еще больше упростить задачу - выделить типичные применения ОС (максимум, десяток) и классифицировать их по этим четырем критериям. Если у каких-то классов критерии совпали, значит их надо объединить в один класс. Надо лишь посмотреть, не упущены ли какие-то классы (может, поперебирать возможные сочетания критериев).
Предлагаю перечень типичных применений ОС:
Суперкомпьютер
Сервер/мэйнфрэйм (мэйнфрэйм явно не для "Росы", просто для полноты картины)
Персональный компьютер
Тонкий клиент
Система реального времени на процессорах общего назначения
Система реального времени на контроллерах
Контроллер низкой производительности (ОС применяется только при необходимости)
| № 2368 24-08-2007 16:07 | |
Ответ на »сообщение 2366« (Lisp Hobbyist)
___________________________
Чтобы назвать транслятор транслятором Оберона достаточно лишь показать его соответствие нормам Виртовского определения, а им будет соответствовать и транслятор без соблюдения норм безопасности (раз уж в предыдущих репликах упоминались законы, то вспомним принцип, что "разрешено все то, что явно не запрещено").
На мой взгляд, в отношении данного принципа и его применимости к описанию языка, Вы заблуждаетесь.
Сначала анекдот:
В США все, что не запрещено законом, разрешено.
В Германии все, что не разрешено законом, запрещено.
В России все запрещено, даже если разрешено законом.
Во Франции все разрешено, даже если запрещено законом.
В Швейцарии все, что не запрещено законом, является обязательным.
А теперь развернутый комментарий.
В юридической литературе и в практике существуют две юридические формулы, на основе которых выделяются два типа правового регулирования.
Первая формула: дозволено все, кроме прямо запрещенного в законе. На этой формуле построен общедозволительный тип правового регулирования. По этому типу в регулируемых правом отношениях устанавливаются строго и четко сформулированные запреты. Как правило, объем этих запретов невелик, а объем дозволений не определен: все, что не запрещено. Например, право допускает для членов общества любые способы умножения материальных благ, кроме прямо запрещенных законом. Данный тип правового регулирования характерен для отношений, регламентируемых отраслью гражданского права.
Вторая формула: запрещено все, кроме прямо разрешенного в законе. Сказанное означает, что участник правовых отношений подобного типа может совершить только действия, которые прямо разрешены законом, а все остальные действия запрещены. Этот тип правового регулирования принято называть разрешительным. Он присущ тем отраслям права, которые связаны, например, с государственным управлением (административное право). Здесь в законе указывается точный, строго ограниченный объем правомочий; все, что выходит за пределы компетенции властвующего субъекта, категорически запрещено.
Моя трактовка описания языка как закона -- это моя личная точка зрения. Не уверен, что ее разделяет проф. Вирт. А поскольку на сей счет (как трактовать описания языков) нет четко прописанных юридических норм, то почему Вы вдруг взялись судить по своим (или даже моим) правилам?
Все это крайне интересно и познавательно, вот только никак не могу взять в толк, какое отношение наша столь обстоятельная дискуссия имеет к проекту новой ОС?
| № 2367 24-08-2007 15:41 | |
Ответ на »сообщение 2366« (Lisp Hobbyist)
___________________________
Да пожалуйста. Открываем Oakwood guidelines, раздел 2, "Language Clarifications".
2.3 Illegal Operations
The following operations are illegal. Their effect is system dependent.
...
4. Indexing an array with an index that is out of range.
Да... Тяжело вздохнув, я все же прокомментирую.
Давайте рассуждать. Спокойно. Без эмоций.
Читаем упомянутый пункт 2.3. Illegal Guidelines.
Первой строчкой идет фраза: The following operations are illegal. Their effect is system dependent.
Т.е. в переводе на русский язык: "Следующие действия неправомерны. Их результат является системнозависимым".
Другими словами, семантика указанных неправомерных действий остается на усмотрение реализации языка (системы программирования).
Вам из приведенного перечня не очевидно, что действия неправомерны:
* Разыменование NIL (пустого указателя)?
* Доступ к массиву по индексу, который выходит за границы диапазона индекса?
Если в описании Вирта ничего по этому поводу не сказано, значит, он это не регламентирует. Т.е. семантика неправильных действий остается на усмотрение конкретных реализаций. В Oakwood Guidelines просто явно сказали то, что и так очевидно.
Хорошо, предположим, что Вирт, с Вашей точки зрения, недоглядел. В каком году вышло описание языка? В 1990 г. В каком году вышли Oakwood Guidelines? В 1995 г. Какой сейчас год на дворе? 2007. Прошло 12 лет. Вирт в этом году выпустил скорректированное описание (для StrongARM-версии): http://www.inf.ethz.ch/personal/wirth/Articles/OberonSAReport.pdf
Что-то там ничего в этом плане не изменилось (или я невнимательно смотрел). Он забыл? Упорствует в своих "ошибках"? Или может быть считает, что очевидные вещи не надо явно прописывать?
Кстати, если Вы так озабочены этой мировой проблемой, позвольте Вам задать вопрос: Вы пробовали обращаться с этим "недоразумением" к Вирту напрямую. Его email не секретный. См. например здесь: http://www.vspu.ac.ru/~chul/wirth/index.htm
Расскажите о результатах обращения. Возможно, он разрешит Ваши сомнения.
| № 2366 24-08-2007 14:38 | |
Ответ на »сообщение 2343« (Руслан Богатырев)
___________________________
>>> Но так уж получилось, что мне довелось найти в этом обосновании немалую дырку (впоследствие оказалось, что еще раньше ее нащупали авторы Oakwood guidelines). Ничего личного, обычные научные разборки.
И что это за "дырка"? Укажите конкретно.
Да пожалуйста. Открываем Oakwood guidelines, раздел 2, "Language Clarifications".
2.3 Illegal Operations
The following operations are illegal. Their effect is system dependent.
...
4. Indexing an array with an index that is out of range.
При этом "The Programming Language Oberon (Revision 1. 10. 90)" вообще не содержит никаких указаний о том, какой должна быть семантика данной конструкции.
Так почтим же вставанием память безвременно скончавшегося мифа о том, что "Оберон --- безопасный язык"! На деле оказывается, что никаких требований о безопасности определение языка не содержит и приходится полагаться исключительно на добрую волю авторов реализаций. Авторам Oakwood guidelines эта добрая воля присуща --- если мы обратимся к разделу 4, в нем мы увидим набор директив компилятора, среди которых есть и проверка индексов, и даже более того, сказано, что "All pragmas should default to provide maximum safety." Наконец, в разделе 5.9 указано, что возникновение ситуаций с неопределенной семантикой должно обнаруживаться и обрабатываться (интересно, как это коррелирует с упомянутой в разделе 4 возможностью отключения соотв. контроля, но это уже другая история).
Но в том-то и дело, что Oakwood guidelines не являются нормативным документом и не обязательны к исполнению! Чтобы назвать транслятор транслятором Оберона достаточно лишь показать его соответствие нормам Виртовского определения, а им будет соответствовать и транслятор без соблюдения норм безопасности (раз уж в предыдущих репликах упоминались законы, то вспомним принцип, что "разрешено все то, что явно не запрещено").
Из всего этого, например, следует такой интересный вывод. Если мы хотим написать программу на Обероне, которая гарантированно не будет иметь неопределенного поведения (гарантированное завершение в случае ошибки индексации неопределенным не является), но при этом можем основываться лишь на базовом Виртовском определении языка, нам придется каждое обращение к элементу массива предварять соответствующим ASSERT'ом. Кстати, я что-то не вижу упоминания этой конструкции в базовом определении... Она там называется по-другому или ее тоже не включили из соображений минимализма?
Резюме. Минимализм описания сносно работает лишь тогда, когда существует одна эталонная реализация языка, которая и служит арбитром (реально, она и есть этим самым описанием, но этот факт предпочитают скромно умалчивать). Чем больше реализаций появляется, тем выше вероятность, что в их поведении возникнут расхождения, влияние которых на процесс разработки программ может быть как незначительным, так и очень существенным. Именно потому, что дизайнеры "мейнстримовских" языков уже наступили на эти грабли, они уделяют столько времени разработке объемистых стандартов, охватывающих каждую мелочь. Впрочем, как показывает вся история человечества, каждый предпочитает наступать на грабли сам. Не буду в этом мешать.
| № 2365 24-08-2007 10:22 | |
| № 2364 24-08-2007 08:40 | |
| № 2363 24-08-2007 08:39 | |
Ответ на »сообщение 2362« (Сергей Прохоренко)
___________________________
1. А будет ли позволено надстроить служебную СУБД до уровня полноценной промышленной универсальной СУБД? Бывают ситуации, когда какую-то информацию можно хранить как в форме файлов, так и в форме полей БД.
Доступ приложений к служебной СУБД предусматривается в т.ч. и для своих прикладных целей (а не только для получения системной информации).
По остальным вопросам -- пока за рамками обсуждения.
Отслеживать это обсуждение
| Дополнительная навигация: |
|
