Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 2, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21 |
|
<< Предыдущая тема | Следующая тема >> |
| [moved] ОС 21-го века | ||
| Переход на страницу 1 2 3 ... 7 [8] 9 10 11 12 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Archon |
| ||
  ID пользователя #18 Зарегистрирован: Суббота 10.07.2004 12:53Местонахождение: Россия, г. Курган Сообщений: 21 | den1, ваши комментарии, конечно, весьма интересны. Но. Мне все таки кажется что мы говорим о реальных перспективах совремнных ОС и об их перерождении в ОС XXI века, а не о фантастических иллюзиях вроде качественного машинного распознавания произнесенных русских (или каких либо еще) слов. Насколько мне известно, на сегодняшний момент существует только один язык (не являющийся языком программирования), который при наличии необходимых программ способен понимать компьютер, это широко известный в узких кругах Loglan. Вроде бы проводились подобные попытки насчет эсперанто (все таки он гораздо проще и логичнее русского, ну или например английского, однако в формальности Логлану явно уступает), но они не закончились успехом. Сможет ли кто либо в ближайшие лет 10 сделать подобную программу для естественного языка - сомневаюсь. Насчет ориентированности на человека - согласен, такая терминология несколько более адекватна данной ситуации. Соответственно, принимая во внимание абзац 1, можно предположить что системы, ориентированные не на визуальное, а на аудиальное восприятие, в ближайшее время никак появиться не могут. Или вы американских футуристических фильмов насмотрелись? (приятный женский голос: You have mail, do you want to read it now?)  Управление командами мозга - это все конечно хорошо и удобно, но абсолютно противоестественно и требует весьма долгого обучения. Захочет ли человек пару месяцев учиться, чтобы научиться читать почту без стилуса / мыши / чего-там-еще-ученые-напридумают?.. Поставь себе ОС, немного, половины хватит. | ||
| Наверх | | ||
| den1 |
| ||
 ID пользователя #363 Зарегистрирован: Вторник 05.07.2005 16:47Местонахождение: Россия. Москва. Сообщений: 151 | Спасибо. Хорошо . Archon написал(а) ... Вот именно. Мое мнение, что сейчас необходимо лишь немного поменять точку зрения. Если мы серьезно собираемся конструировать перспективную ОС, то в начале нужно сказать, что мы от нее хотим. Уже потом решать конкретные технические вопросы. Не думаю, что все уж так пасмурно. Например, существует несколько схем распознавания голосовых комманд. Одни попроще, но надежнее, другие соответственно... Для управления, естественно, может быть использован достаточно ограниченный набор комманд. Для такого интерфейса правило не умножения сущностей не менее критично. Мне все таки кажется что мы говорим о реальных перспективах совремнных ОС и об их перерождении в ОС XXI века, а не о фантастических иллюзиях вроде качественного машинного распознавания произнесенных русских (или каких либо еще) слов. Или Вы считаете, что задействовать голосовое управление нам можно пробовать только после того, как свой, как правило, не лучший вариант уже предложат корпорации? Пусть теперь они ориентируются на нас, а не мы на них. Например, интересная история получилась с РОС-Линукс. Если сейчас задействовать векторные возможности отрисовки Qt, организовать видеовывод не через fb и, возможно, переписать интерфейс Opie, что вобщем теоретически возможно и является, по сути, техническими вопросами, то мы из простой экспериментальной системы получим лаконичную единообразную минималистскую высокоскоростную систему, отвечающую самым современным требованиям. Лучшую, вообще говоря, чем грядущая "окна" от m$. Не знаю, но может быть и по этой причине на моей конференции часто гости из Редмонда . Получается, что одна из самых богатых корпораций, имея огромный штат сотрудников, не может дать в итоге людям удобную систему без ошибок и вынуждена анализировать любительскую систему. Но я же не считал, даже в начале, что это нереально сделать одному человеку. Кстати, вот лишний факт, того, где корпорации берут идеи... требуя потом оплаты, выдавая эти идеи за свои... вот цена проприетарного кода. Нда... Не хотел я это приводить, но наверное нужно. Заходы частые с разных смежных адресов одного диапазона, сложно представить, что кто-то так шутит..., вот один из примеров: WHOIS results for х.х.х.х Generated by Location: United States [City: Redmond, Washington] NOTE: More information appears to be available at х. Using 1 day old cached answer (or, you can get fresh results). Hiding E-mail address. OrgName: Microsoft Corp OrgID: MSх Address: One Microsoft Way City: Redmond StateProv: WA PostalCode: 98052 Country: US NetRange: х.х.х.х - х.х.х.х CIDR: х.х.х.х/х NetName: MICROSOFT-x NetHandle: NET-х-х-х-х-х Parent: NET-х-х-х-х-х NetType: Direct Assignment NameServer: NS1.MSxx.xxx NameServer: NS5.MSxx.xxx NameServer: NS2.MSxx.xxx NameServer: NS3.MSxx.xxx NameServer: NS4.MSxx.xxx Comment: RegDate: 2001-02-14 Updated: 2004-12-09 TechHandle: x TechName: Microsoft Corporation TechPhone: +1-425-882-8080 TechEmail: ***@microsoft.com OrgAbuseHandle: x OrgAbuseName: Hotmail x OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: *****@hotmail.com OrgAbuseHandle: MSNx-x OrgAbuseName: MSN x OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: *****@msn.com OrgAbuseHandle: x-x OrgAbuseName: x OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: *****@microsoft.com OrgNOCHandle: x-x OrgNOCName: Microsoft Corporation OrgNOCPhone: +1-425-882-8080 OrgNOCEmail: ***@microsoft.com OrgTechHandle: MSx-x OrgTechName: MSx-x OrgTechPhone: +1-425-882-8080 OrgTechEmail: ******@microsoft.com Вместе же мы можем гораздо больше, чем я один, например, и чем все m$ вместе взятые. Если мы так не считаем, то и нечего браться за конструирование ОС. Не обижайтесь , но с вами или без вас я еще улыбнусь в ответ всем этим m$, когда они будет убеждать людей купить хм..., например, очередную улучшенную клавиатуру с улучшенным драйвером... и попрошу мою систему сказать им все, что она думает по этому поводу. Но это если время будет...  .Archon написал(а) ... Насколько мне известно, на сегодняшний момент существует только один язык (не являющийся языком программирования), который при наличии необходимых программ способен понимать компьютер, это широко известный в узких кругах Loglan. Интересная информация. Не знал. Спасибо. Исхожу здесь из того, что метод есть выбор реализации идеи. Если кто-то, когда-то придумал такой подход, он может быть повторен, улучшен, или реорганизован. Archon написал(а) ... Вроде бы проводились подобные попытки насчет эсперанто (все таки он гораздо проще и логичнее русского, ну или например английского, однако в формальности Логлану явно уступает), но они не закончились успехом. Сможет ли кто либо в ближайшие лет 10 сделать подобную программу для естественного языка - сомневаюсь. Естественный не обязателен. Задача действительно сложная, насколько я знаю. Может быть, например, специализированный небольшой язык управления. Мы ведь говорим пока о всего лишь одном из блоков - модуле - объекте, стыкуемом/реализующем часть интерфейса - алгоритм управления. Archon написал(а) ... Соответственно, принимая во внимание абзац 1, можно предположить что системы, ориентированные не на визуальное, а на аудиальное восприятие, в ближайшее время никак появиться не могут. Или вы американских футуристических фильмов насмотрелись? (приятный женский голос: You have mail, do you want to read it now?) Нет. У меня телевизора-то нет... . Я просто представляю, как бы мне удобнее было взаимодействовать с альтернативной информационной вспомогательной сущностью... , которая рядом со мной . Я же не виноват, что мудрецы из корпораций, так и не создали удобной системы и пичкают нас бесконечной документацией на предмет того, что они там мудрят год из года, чтобы я тратил время своей жизни на обучение этому, да еще и доплачивал им. Нет уж. Пусть они сами роются в своих самостройных архаичных, пропитанных коммерцией, хаотических нагромождениях..., а с меня довольно... Хватит... Archon написал(а) ... Управление командами мозга - это все конечно хорошо и удобно, но абсолютно противоестественно и требует весьма долгого обучения. Захочет ли человек пару месяцев учиться, чтобы научиться читать почту без стилуса / мыши / чего-там-еще-ученые-напридумают?.. Я уже писал про это, повторюсь все же (телевизер в гостях видел)... да и не так это все долго и, как раз, менее противоестественно, чем стучать по клавишам... надо, кхм... мыслить просто не так как нас пытаются приучить:den1 [url написал(а) ... http://www.linux.org.ru/jump-message.jsp?msgid=926062[/url]] Я предлагаю к эволюционированию тех же GUI относиться спокойно (да и не только к этому ). Само понятие GUI вполне может быть преобразовано с течением времени к BUI , например, (Brain User Interface) и так далее. Неплохая передача была по Discovery недавно: комментарии и показ работы специалистов (не наших, к сожалению естественно, (что характерно для современного _нашего_ состояния... нда...)). Управление имитатором военного самолета при помощи анализа активности мозга. Женьщина, лет 50, научный сотрудник... говорит, вот, научицца очень просто, легче, чем машиной управлять..., просто привыкаешь... потом на автомате..., сидит себе спокойно, пару проводочков к голове приклеено ... кабина вправо-влево наклоняется... Другой, курсор по экрану во всю возюкает... Третья дифченка... лет 20... в компьютерной игре "со снежной горки съезжает..., примерно как tux racing...На создание приложения может уходить слишком много времени... столько, что за время создания может появиться следующее поколение программ... | ||
| Наверх |
| ||
| stager |
| ||
| ID пользователя #281 Зарегистрирован: Четверг 21.04.2005 10:56Местонахождение: Tomsk, Russia Сообщений: 5 | ссылка по теме: http://users.net1plus.com/scottm/HomeComputer.jpg Segmentation fault. Core dumped. Kernel panic. System halted. Power down. Аминь. | ||
| Наверх |
| ||
| stager |
| ||
| ID пользователя #281 Зарегистрирован: Четверг 21.04.2005 10:56Местонахождение: Tomsk, Russia Сообщений: 5 | устройства ввода/вывода технологически вполне можно уже выпускать очки с наушниками и микрофоном. и отображать на них, поверх реального изображения другую информацию. (например нарисовать на рабочем столе папку с приказами об увольнении админов и программеров или тумбочку в углу с такимиже папками. тогда пользователь _не забудет_ куда компьютер положил предпоследнередактируемый документ. или кассету с мп3 шаинского или утёсова. это будет пространственное запоминание.как же лучше управлять "курсором" в случае когда "рабочий стол" будет нарисован на реальном рабочем столе? помоему самое естественное -- руками. на руки одевать перчатки с датчиками положения в пространстве. и пожалуйста, рисуйте ваши документы. или набирайте на "нарисованной" клавиатуре. при этом не надо отвлекаться на мышку. мышки на этом рабочем столе никогда не будет. (и тогда совет директоров ксерокса скажет: "мы же говорили, что устройство позиционирования мышь ни на что не годна!") компьютер такая коробка, которая стоит под телефизором. нормальный пользователь не интересуется внутренностями радиоприёмника. его интересует, как включить нужную станцию с минимумом затрат. кстати, смерть радио уже предсказывают начиная с изобретения телевизора. а вот ведь вполне можно использовать радиоканалы для широковещательной передачи контента (как это сейчас реализуется при помощи спутников) сам компьютер вполне естественно будет общаться с руками и очками посредством WiSuperPuperMAX. и таким образом можно будет управлять хоть холодильником, хоть стиральной машинкой. запустить на игровой приставке для дитяти квейк13, а жене на телевизоре "рабыня изаура возвращается-3". устройства не видно, но функция его -- управление потоками информации -- выполняется. рабочий стол вот что мне например не хватает от рабочего стола практически любого wm, так это "поднять" иконки над текущим окном. ведь намного удобнее (да и логичнее помоему) редактируя таблицу екселювскую поднять папку "из под" таблицы, открыть нужный документ. в этом отношении чтото такое проскальзывает в windowmaker'е (который как известно пытается копировать самый продвинутый двумерный gui -- nextstep), но всё равно не то. папки, которые, как известно, придумали в микрософте в большого похмелья русские програмисты, на папки не похожи вообще. папки они не такие. или вот взять например электронную почту. как должны выглядеть электронная почта? такой стилизованные почтовый ящик, который подпрыгивает из под текущего заполнения рабочего стола раскладыванием пасьянса "косынка", а в нём лежит реальное такое письмо с маркой и надписаное от руки открываешь, а в нём фотокарточка и магнитофонная кассета ну то есть на самом деле всплывать должен будет не ящик почтовый (хотя некоторые на ящик точно согласятся), а наладонник, точно такойже как и лежит реально в кармане/на тумбочке/на холодильнике. а в нём ты и читаешь почту. так что же главное для пользователя? правильный ответ -- информация. люди работают с информацией, а не с компьютером, повторюсь ещё раз. Segmentation fault. Core dumped. Kernel panic. System halted. Power down. Аминь. | ||
| Наверх |
| ||
| captain cobalt |
| ||
 ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Roman I Khimov написал(а) ... Каждая промежуточная компиляция вообще говоря может приводить к потере информации, полезной для оптимизации. Поэтому такой способ заведомо не превзойдёт (и наверное не достигнет) качества "прямой" компиляции.Мне кажется, что поддержка одного только IL - плюс .NET. Да, с точки зрения абсолютной гибкости - это минус, однако, реально надо учитывать не только это. Единый IL позволяет оптимизировать трансляторы этого IL на машину до посинения и этим преимуществом смогут воспользоваться все языки платформы. Это можно сравнить с потерей качества звука при сжатии с потерями. CD -> mp3 и например CD -> WMA -> mp3 Roman I Khimov написал(а) ... Переоценивать тоже не следует. Единый IL упрощает расширение платформы в сторону новых языков, что, кстати, прекрасно способствует прогрессу в этой области - под .NET есть уже и Boo, и Nemerle, и вот Zonnon тот же. Единый IL изначально делает всю платформу переносимой на разные аппаратные архитектуры - а этого недооценивать нельзя, иначе получится, что вот тут мы имеем этот язык, а вот тут его нет. Обычно софт после короткой инсталяции в течение длительного времени работает на одной платформе. Зачем на заданной фиксированной платформе навороты? Особенно если возможности платформы ограничены? Кроме того, в планы Microsoft вряд ли входит "раскрутка" "не её" платформ. Поэтому следует осторожно относиться к заявлениям переносимости. Roman I Khimov написал(а) ... Bluebottle - самостоятельная система.Вообще же, практически все, что ты говоришь о Bluebottle, перекладывается на .NET без каких-либо потерь. dotNET - требует некоторой нижележащей операционной системы. В настоящее время в качестве таковых используется W*s и L*x. В этих системах процессы монопольно захватывают страницы памяти. В dotNET используется сборка мусора. Это приводит к перерасходу памяти - если у одного процесса много мусора, то другой процесс всё равно не сможет воспользоваться этой памятью. В Bluebottle один сборщик мусора на всю систему (и в целом очень близкая модель исполнения), поэтому она представляется гораздо более подходящей платформой для dotNET. Реализацией dotNET для разных платформ занимаются разные группы разработчиков. Вложенные усилия весьма велики, а результат удручает. Видимо dotNET сильно зависит от нижележащей платформы. И его отцы основатели будут прикладывать максимум усилий, чтобы зависимость от их платформы была как можно сильней. Bluebottle пока не переносят куда попало, но можно посмотреть куда перенесли старый добрый Oberon. http:/www.oberon.ethz.ch/genealsys.html Могу заверить, что усилия необходимые на один такой перенос гораздо меньше, чем усилия затрачиваемые сейчас на перенос dotNET. Roman I Khimov написал(а) ... Всё позволяет описать.А конкретно? Может быть здесь как раз имеет место такая ситуация, когда технология пришлась впору? Тот самый XML? Что он не позволяет описать в .NET? Но в ряде случаев накладные расходы могут оказаться избыточными. Roman I Khimov написал(а) ... Всё очень просто. Вот этот момент меня сейчас интересует больше всего. Получается, что в Bluebottle нет потоков? Как активные объекты заменяют потоки? Активный объект - это объект, имеющий собственный поток управления. Roman I Khimov написал(а) ... Это я сейчас в более подходящем месте напишу. На каких уровнях, как выполняется синхронизация? Roman I Khimov написал(а) ... Документ один - PieterMuller.pdf ~710K. Можно ткнуть носом в документ с ответами, только не шибко большой bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
  ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | captain cobalt написал(а) ... Каждая промежуточная компиляция вообще говоря может приводить к потере информации, полезной для оптимизации. Поэтому такой способ заведомо не превзойдёт (и наверное не достигнет) качества "прямой" компиляции. А где у нас есть сейчас прямая компиляция в серьезных компиляторах? Разве у них у всех нет промежуточного процессоро-независимого представления? captain cobalt написал(а) ... Переоценивать тоже не следует. Обычно софт после короткой инсталяции в течение длительного времени работает на одной платформе. Зачем на заданной фиксированной платформе навороты? О каких наворотах идет речь? О трансляции IL - машина? Есть Ahead-of-time компиляция - вуаля! captain cobalt написал(а) ... Особенно если возможности платформы ограничены? Чем? captain cobalt написал(а) ... Кроме того, в планы Microsoft вряд ли входит "раскрутка" "не её" платформ. Поэтому следует осторожно относиться к заявлениям переносимости. А мне на Microsoft в этом смысле наплевать. Есть Mono, есть открытые спецификации на CLS, IL... captain cobalt написал(а) ... В Bluebottle один сборщик мусора на всю систему (и в целом очень близкая модель исполнения), поэтому она представляется гораздо более подходящей платформой для dotNET. Согласная я, сейчас это выглядит очень некрасиво, каждый процесс создает "свой .NET". Однако ж, я речь веду к тому, что имеет смысл создание ОС, в которой .NET будет основной средой исполнения и такого маразма уже не будет. И такая система будет не хуже Bluebottle, а лучше. Греби и улыбайся! | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Roman I Khimov написал(а) ... Забавно, но многие компиляторы Оберонов - это "несерьёзные" тупые компиляторы, которые прямо из систаксиса делают машинный код. Практика покзывает, что качество получаемого ими кода незначительно уступает оптимизирующим компиляторам других языков (для грамотно написанного кода). Это "фича" языка - не надо ненужных наворотов, чтобы затем героически преодолевать их ограничения. А где у нас есть сейчас прямая компиляция в серьезных компиляторах? Разве у них у всех нет промежуточного процессоро-независимого представления? Да, промежуточное представление в компиляторах обычно присутствует. Оно используется для оптимизации кода. Для этого необходимо сохранять информацию о структуре программы - где у неё циклы, где подпрограммы, и т. п. Для этих целей "последовательность инструкций виртуальной машины" подходит плохо, так как требует восстановления этой информации (которая присутствовала в тексте программы). Roman I Khimov написал(а) ... А ещё есть "компиляция из исходников" - вуаля и никаких наворотов. О каких наворотах идет речь? О трансляции IL - машина? Есть Ahead-of-time компиляция - вуаля! Я не против компиляции из промежуточного представления. И разработчики Bluebottle не против. Существуют различные способы кодогенерации. Каждый имеет преимущества и недостатки. Утверждать, что кодогенерация из одного промежуточного представления "решит все проблемы человечества" - абсурдно. Roman I Khimov написал(а) ... Здесь имеются возможности аппаратной платформы, которые могут быть ограничены мегагерцами и мегабайтами. captain cobalt написал(а) ... Особенно если возможности платформы ограничены? Чем? Некоторые исследователи считают, что мощные процессоры - must die, а рулят распределённые системы из большого числа слабых машин, установка на каждую из них что-нибудь тяжёлого сожрёт ресурсы всей сети. Также существуют сторонники у "тонких клиентов" и "бездисковых станций". Roman I Khimov написал(а) ... Ещё раз. Кодогенерация - это незначительная часть проблемы.А мне на Microsoft в этом смысле наплевать. Есть Mono, есть открытые спецификации на CLS, IL... Почему .NET не написан на .NET (как Оберон написан на Обероне), что позволило бы переносить платформу .NET на другие платформы чуть ли не простой перекомпиляцией. Почему реализацией для различных платформ занимаются совершенно различные группы разработчиков, причём каждый раз начиная полностью с нуля? Почему несмотря на потраченные усилия и время совместимость полученного результата совершенно удручает. Рассмотрим аппаратную платформу IA32. На ей может работать W*s и L*x. Если бы проблема была только в кодогенерации, можно было бы использовать один кодогенератор для всех ОС (аппаратная платформа одна). Значит проблемы в другом месте - в непереносимости .NET Roman I Khimov написал(а) ... А обоснование? я речь веду к тому, что имеет смысл создание ОС, в которой .NET будет основной средой исполнения и такого маразма уже не будет. И такая система будет не хуже Bluebottle, а лучше. А почему не взять Bluebottle в качестве основы для такой системы, в которой есть почти всё необходимое? А почему .NET, а не Java? В настоящее время Java входит в тройку наиболее промышленно развитых платформ (вместе с языками C и C++). Bluebottle может одновременно поддерживать Java (уже поддерживает), .NET (потенциально) и всё что появится в будущем и будет обладать надлежащими свойствами. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Dron |
| ||
  ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Вообще все эти заморочки с оптимизацией связаны скорее с несовершенством и с раздробленностью самой архитектуры... Правда есть еще высокоуровневая оптимизация (типа подстановки констант и разворота циклов). Ее то никто никогда не отменял. А низкоуровневая оптимизация в принципе зло. (не всмысле что вредна, а всмысле что надуманная проблема, требующая значительного неоправданного приложения сил и средств...) Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | captain cobalt написал(а) ... Да, промежуточное представление в компиляторах обычно присутствует. Оно используется для оптимизации кода. Для этого необходимо сохранять информацию о структуре программы - где у неё циклы, где подпрограммы, и т. п. Для этих целей "последовательность инструкций виртуальной машины" подходит плохо, так как требует восстановления этой информации (которая присутствовала в тексте программы). Мимо. Есть два (ну, конечно, значительно укрупненных) этапа оптимизации - один выполняется в IL, а второй уже при трансляции IL в машинный код. У первого есть все и оптимизировать бинарник поставщик просто обязан до посинения, а второму информация с первого этапа - ехало-болело. Но, что интересно, информацию ведь действительно можно восстановить и что-то учесть, эта схема работает просто прекрасно. captain cobalt написал(а) ... Roman I Khimov написал(а) ... О каких наворотах идет речь? О трансляции IL - машина? Есть Ahead-of-time компиляция - вуаля! А ещё есть "компиляция из исходников" - вуаля и никаких наворотов. И что быстрее? captain cobalt написал(а) ... Утверждать, что кодогенерация из одного промежуточного представления "решит все проблемы человечества" - абсурдно. Я не говорю, что это решает все проблемы, но конкретно вот эта реализация кодогенерации более чем разумна и покрывает все что надо на сегодняшний день. А ведь .NET - это не только кодогенерация, это еще многое другое... captain cobalt написал(а) ... Здесь имеются возможности аппаратной платформы, которые могут быть ограничены мегагерцами и мегабайтами. Некоторые исследователи считают, что мощные процессоры - must die, а рулят распределённые системы из большого числа слабых машин, установка на каждую из них что-нибудь тяжёлого сожрёт ресурсы всей сети. Также существуют сторонники у "тонких клиентов" и "бездисковых станций". Я не думаю, что в этом смысле с .NET есть какие-либо проблемы, в конце концов, глубочайшее проникновение Java в embedded уже говорит за то, что JIT и сборка мусора на сегодняшнем железе не являются тормозами, а ведь в рукаве .NET есть все та же AOT компиляция. Ну и насчет построения распределенных систем тоже принципиальных проблем для .NET я не вижу. captain cobalt написал(а) ... Почему .NET не написан на .NET (как Оберон написан на Обероне), что позволило бы переносить платформу .NET на другие платформы чуть ли не простой перекомпиляцией. Вопрос не ко мне. Реализация на C, вообще говоря, меня вполне устраивает. Системному программированию - C, прикладному - .NET. Why not? captain cobalt написал(а) ... Почему реализацией для различных платформ занимаются совершенно различные группы разработчиков, причём каждый раз начиная полностью с нуля? Не поняла? Mono работает на массе платформ. captain cobalt написал(а) ... Почему несмотря на потраченные усилия и время совместимость полученного результата совершенно удручает. Не проверял точно, сказать не могу, однако ж, Mono заявляет о совместимости с реализацией MS .NET. captain cobalt написал(а) ... Рассмотрим аппаратную платформу IA32. На ей может работать W*s и L*x. Если бы проблема была только в кодогенерации, можно было бы использовать один кодогенератор для всех ОС (аппаратная платформа одна). Значит проблемы в другом месте - в непереносимости .NET Mono работает на GNU/Linux, работает на Windows, на FreeBSD вроде бы тоже, на Mac OS работает нормально - где непереносимость? Непереносимость на дух не принимается.  captain cobalt написал(а) ... А почему не взять Bluebottle в качестве основы для такой системы, в которой есть почти всё необходимое? А что поддерживает Bluebottle аппаратно? Ответ - ни-чер-та. Я согласен с тем, что это красивый концепт, я может быть даже соглашусь, что это лучшая в техническом смысле на сегодня ОС, поскольку она цельная и действительно во многом новая, но надо двигаться дальше. .NET и свободное ядро Linux - оп-ля! А еще если дополнить технологией ЕПД? Ага, вот тебе и 3OS сегодня, ищу, блин, спонсора... captain cobalt написал(а) ... А почему .NET, а не Java? Моноязычность? Увольте. Одного этого более чем достаточно. Dron написал(а) ... Вообще все эти заморочки с оптимизацией связаны скорее с несовершенством и с раздробленностью самой архитектуры... Я бы все-таки сказал "с развитием и изменениями", впрочем совершенства от этого не прибавляется . Тут, кстати, звучало мнение, что разворот циклов для P4 больше вреден, чем полезен - он сам со всем неплохо разбирается, вот и учти это при компиляции в бинарник... А из IL всегда можно быстро и качественно оттранслировать, при этом полностью используя все возможности конкретного процессора - это большая разница. Из исходников компилировать серьезные вещи долго, из IL с ними можно работать здесь и сейчас, при этом результаты компиляции можно сохранять, а можно запускать AOT со всеми "тяжелыми" оптимизациями, которые выдадут отличный, быстрый код. Греби и улыбайся! | ||
| Наверх |
| ||
| Wanderer |
| ||
 ID пользователя #2 Зарегистрирован: Вторник 29.06.2004 20:13Местонахождение: Беларусь, Гомель Сообщений: 76 | Roman I Khimov написал(а) ... Я не говорю, что это решает все проблемы, но конкретно вот эта реализация кодогенерации более чем разумна и покрывает все что надо на сегодняшний день. А ведь .NET - это не только кодогенерация, это еще многое другое... Что конкретно? Кролики - это не только ценный мех, это понятно. .NET - какие преимущества? Roman I Khimov написал(а) ... Вопрос не ко мне. Реализация на C, вообще говоря, меня вполне устраивает. Системному программированию - C, прикладному - .NET. Why not? Why yes? Roman I Khimov написал(а) ... Не поняла? Mono работает на массе платформ. Только он на этой массе платформ никому не нужен. .NET по своей сути не подразумевает переносимость, потому что Microsoft это не выгодно. Да, есть Mono, написанная, заметь, абсолютно посторонними людьми, и никто тебе ничего не гарантирует. Это продукт, сделанный гиками для гиков. Romain I Khimov написал(а) ... Не проверял точно, сказать не могу, однако ж, Mono заявляет о совместимости с реализацией MS .NET. Это называется Сизифов труд. Они не связаны с Microsoft. Нахрена нужна такая платформа, свободные реализации которой компания-"изобретатель" будет стараться затормозить при первом удобном случае? Я тебя уверяю, что они пока активно не ставят палки в колеса Mono только потому, что анти-монопольный комитет будет сильно такими действиями недоволен. Roman I Khimov написал(а) ... многом новая, но надо двигаться дальше. .NET и свободное ядро Linux - оп-ля! А еще если дополнить технологией ЕПД? Ага, вот тебе и 3OS сегодня, ищу, блин, спонсора... Звучит откровенно как навязчивая идея... Мифический ЕПД, старое как мир и штопанное-перештопанное ядро Linux, .NET со своей отдельно болтающейся открытой реализацией - романтика. "Самое лучшее - только для вас." Roman I Khimov написал(а) ... Моноязычность? Увольте. Одного этого более чем достаточно. А тебе нужно много языков? Зачем? Объясни мне, почему лично ты не можешь обойтись одним языком. Доказывая идиоту, что он идиот, ты сам становишься идиотом. | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 ... 7 [8] 9 10 11 12 | |
Powered by e107 Forum System