Andrew S. Tanenbaum опубликовал (http://www.cs.vu.nl/~ast/reliable-os/)
документ резюмирующий основные доводы сторон в споре о достоинствах и недостатках микроядерной и монолитной архитектуры ядра операционной системы.
Спор возник после того как Таненбаум опубликовал статью
"Can We Make Operating Systems Reliable and Secure? (http://www.computer.org/portal/site/computer/menuitem.5d61c1...)", в которой утверждал, что потери производительности при использовании микроядра компенсируются простотой реализации и более высокой надежностью и безопасностью ядра.
По этому поводу возникла дискуссия, в в которой не замедлил высказать свое мнение Linux Torvalds (http://www.realworldtech.com/forums/index.cfm?action=detail&...) и основываясь на собственном опыте, попытался опровергнуть идеализированное представление о микроядерной архитектуре.URL: http://www.cs.vu.nl/~ast/reliable-os/
Новость: http://www.opennet.me/opennews/art.shtml?num=7520
Mach рулит, кто нибудь юзает GNU/Hurd?
А если внимательно почитать статью, то обнаруживается ссылка http://www.lightreading.com/document.asp?site=lightreading&d..., в которой рассказывается, что Cisco для своего нового очень мощного роутера решила использовать новую ветвь IOS, базирующуюся на модифицированном ядре QNX. Я так думаю, что авторитет Cisco желающих пооспаривать найдется немного - люди там умеют делать качественные и быстрые вещи.
Вобщем, микроядро рулит.
Куда, оно рулит???Оно рулит там где надо рулить, - кофеварки, кипятильники, СВЧ-печки, сisco-роутеры,
авиационные и баллистческие ракеты, мобильник Васи Пупкина. \m/
Некоторое время я использовал QNX на десктопе. Впечатления остались самые благоприятные.
Что же вас в нем не устраивает?
Firewall, BIND, Games, дрова для NVidia и OpenGL, OpenOffice, Локализация,
Почтовые проги, Браузер, Java, SMP, Гигофлопов в 4 раза меньше чем на линухеК каждому слову подставить +карявые, или +нет
> SMPAFAIU как раз с SMP в QNX6 все вполне даже на уровне. в качестве браузера есть FF и Mozilla. Java есть нативная. по поводу "гигофлопов" не понял.
а по поводу games совершенно по боку, что QNX что Linux - оба в полной ж... :)
ps: у QNX6 а тем более QNX4 хватает своих проблем, но они лежат несколько в другой плоскости :)
// wbr
GFLOPS - G = 10^9 * FLoat Opetations Per Second.
Каким образом скорость работы с плав запятой зависит от ОС ?!
Вы сами то поняли, что написали ?
А сам-то понял что сказал...? Типа операционная система ни причем, так покурить зашла...И то что один и тот же алгоритм, с помощь тех же компиляторов работующих на этой OS
почему-то по разному работает... И вместо того чтоб синус запихнуть в FPU, она его
через ряд Маклорена, или другой быстрее сходящийся...
Из моего опыта написания RT программ использующих тригонометрию = использовать FPU себе дороже и очень часто вычисление через ряды с конечной точностью быстрее чем через FPU.
Так что очень даже прав компилятор :) + не надо тратиться на сохранение FPU state.
>а по поводу games совершенно по боку, что QNX что Linux -
>оба в полной ж... :)
нуну, где на куниксе седега? где кучка портированных третьими фирмами тайтлов?
не рассказывайте о cisco ничего. Может люди там и умные... но за все остальное
>авторитет Cisco желающих пооспаривать найдется немного - люди там умеют делать
>качественные и быстрые вещи.
Быстрые - да.Качество вы говорите?Эксплойты IOS уже продемонстрировали и не раз.Циски не ломают вовсе не из-за их суперского качества а всего лишь потому что мало кто в этом разбирается и мало кто дал себе труд разобраться - экзотичная ОС и все такое, вот и хакеров на нее мало.А так - кошаки неплохи в плане пиара и уникальности но если взглянуть вглубь - они те еще халтурщики.И если их IOS детально копнуть - она наверное дырявая ничуть не меньше чем какой-нибудь мак ос или любой иной *никс при прочих равных (без гуя и с эквивалентным набором фич) )))
http://www.lightreading.com/document.asp?site=lightreading&d...
Правильная ссылка
Микроядро рулит по-любому, это факт. Но довести его до ума куда сложнее (по опыту).
В QNX довели же.
Думаю, что и в Миникс 3 оно нормальное. Я ставил себе миникс 3.1.1 - работает на первый взгляд очень быстро, хотя расширенного теститрования я не проводил. К сожалению, там не работала ни одна из моих сетевых карт, так что в сети работу не тестил.
"на первый взгляд быстро". что за тупизм?! похоже для таких и строчит AST свои статьи.
Он наверно измерял, время загрузки и отклик терминала на нажатие кнопок =)
А может даже и #echo 'main() {printf("Hello World\n");}' | gcc -x c - && ./a.out
Не о том речь. Если к, примеру, поставить задачу выкинуть из ядра Linux в userspace все драйверы, а оставить лишь микроядро для обмена сообщением (утрирую для кратости), то довести такую систему до работоспособного состояния будет куда сложнее, чем перестроить тот же Linux на каком-нибудь другом принципе, сохраняющем монолитную архитектуру.PS: и не надо вспоминать про L4Linux, она организована совсем по-другому!
> выкинуть из ядра Linux в userspace все драйверы,
> а оставить лишь микроядро для обмена сообщениемЧем будет отличатся OS в которой так будет?
Только тем, что, например скажем, появится 1000 ALSA или 200 OSS,
или к каждой материнке будуь свой UserLayer - заставить звуковую плату
не только делать преобразования Фурье, но и проверять то, что ей подсунули,
контрольные суммы, размеры файлов, правадоступа на запись/чтение. и.т.п,
Или скажем, драйвера USB которые будут сканировать содержимое флэшки, тип FS,
а может даже и понимать эту FS. Как здорово, купил флэшку, притащил домой, вставил,
а у неё своя FS, и дополнительно устанавливать ничего не надо, как говорится сколько флэшек
столько и драйверов.
Как я смотрю, вы малость не понимаете суть вопроса. Думаю, что чтение умных книжек вам бы очень помогло. Объясняю на пальцах: драйвер в кольце 3 - это драйвер, который не может навредить системе. Вы можете забыть про синие или черные экраны смерти. В итоге получается офигенная стабильность, так как код самого ядра маленький, тоесть может быть вылизан и полностью выверен. Недостаток - повышенные накладные расходы, так как происходит двойное переключение контекста между кольцами ноль и три.
> Как я смотрю, вы малость не понимаете суть вопроса. Думаю, что чтение умных книжек вам бы очень помогло. Объясняю на пальцах: драйвер в кольце 3 - это драйвер, который не может навредить системе. Вы можете забыть про синие или черные экраны смерти. В итоге получается офигенная стабильность, так как код самого ядра маленький, тоесть может быть вылизан и полностью выверен. Недостаток - повышенные накладные расходы, так как происходит двойное переключение контекста между кольцами ноль и три.hint: в QNX4/6 процессы, напрямую работающие с аппаратными ресурсами, не крутятся в кольце 3 :) в терминах x86.
// wbr
> Oбъясняю на пальцах: драйвер в кольце 3 - это драйвер, который не может навредить системе.Что помешает кривому драйверу в кольце 3 расписать под орех любую область памяти используя dma ? Что помешает ему устроить irq флуд и затормозить систему до безобразия ?
Безопасность драйверов в кольце 3 - сказки.
>> Oбъясняю на пальцах: драйвер в кольце 3 - это драйвер, который не может навредить системе.
>
>Что помешает кривому драйверу в кольце 3 расписать под орех любую область
>памяти используя dma ? Что помешает ему устроить irq флуд и
>затормозить систему до безобразия ?
>Безопасность драйверов в кольце 3 - сказки.А что помешает ему сделать это же в кольце ноль? Уж точно ничего.
В кольце три драйвер выступает как обычное приложение, запрашивающее ресурсы у ядра. И если ядро решит, что эти ресурсы ему давать не надо, то нагадить будет очень непросто. Естественно, что абсолютной защиты не бывает. Но драйвер в кольце 3 гораздо безопаснее драйвера в кольце 0.
> А что помешает ему сделать это же в кольце ноль? Уж точно ничего.
"А если нет разницы, зачем тратить больше ?" (c)> В кольце три драйвер выступает как обычное приложение, запрашивающее ресурсы у ядра. И если ядро решит, что эти ресурсы ему давать не надо, то нагадить будет очень непросто.
Доступ к портам/памяти управляемого устройства он имеет ? Если да то этого достаточно, по крайней мере в системах без IOMMU.> Естественно, что абсолютной защиты не бывает. Но драйвер в кольце 3 гораздо безопаснее драйвера в кольце 0.
Не настолько чтобы это стоило мороки и потерь производительности.
Модульная система всегда более трудоемка при проектировании и разработке. Но зато более гибка при дальнейшем использовании.
Я и не сомневаюсь, просто это превратится в IBM, Sun, HP, Apple, Dell, Gataway ...
у кого больше денег, тот и будет заказывать музыку (разработку) и не кому не
показывать ноты.Что вообще-то противоречит OpenSource.
Так что, я думаю, ядро с подсистемами (Сеть, Перефирия, FS, и.т.п)
должно быть не обязательно единым, но модульным.
Кто например мешает Вам написать свои usb_core.ko или generic.ko, scsi_mod.ko
Тем что они работают в пространстве ядра. Система по сути дела не модульная.
товарисчМодульность - это свойство системы, которая была разделена на связные и слабо зацепленные между собой модули.
Линух офигенно разделен на такие модули. Модули reiserfs и ehci-hcd слабо звцепленные ;)
Так что линух - модульный, как бы тебе от этого не было плохо
"попытался опровергнуть идеализированное представление о микроядерной архитектуре". не попытался, а опроверг. причем давно. про Cisco тоже смешно. можно подумать highend цыски используют софт для чего-то кроме cli и rip/ospf/bgp, с коими прекрасно справится _любая_ ос.
snmp забыли :)А вообще с ссылкой на cisco у профессора нехорошо вышло. Получается он либо не знает их архитектуры и упомянул их просто для красного словца, либо сознательно пытается ввести читателей в заблуждение. В любом случае некрасиво :(
>snmp забыли :)
>
>А вообще с ссылкой на cisco у профессора нехорошо вышло. Получается он
>либо не знает их архитектуры и упомянул их просто для красного
>словца, либо сознательно пытается ввести читателей в заблуждение. В любом случае
>некрасиво :(Cisco needed to make the software change someday, even if it's painful, analysts say. Because it's not modular, IOS is a step behind JunOS and other software -- something IOS XR is intended to correct (see Cisco's HFR Gets Mod).
Moreover, Cisco keeps adding to IOS piecemeal, as if it were the world's largest ball of twine. "Imagine five years from now, if they hadn't built this new software and they tried to keep IOS going. That thing would be a beast," Kamman says.
IOS XR helps Cisco catch up in areas such as hot upgrades of software and separation of control, data, and management planes. The software is based on a kernel licensed from QNX Software Systems, but tailored for the job. "We have made some pretty substantial modifications to [the QNX code] that are Cisco proprietary," Volpi says.
In terms of features, it appears IOS-XR will start incomplete, possibly reflecting the difficulty of rebuilding an entire router's worth of software.
Как мы видим, речь идет о новой ОС для Cisco - IOS XR
Так что нехорошо вышло не у профессора, а у вас.
>Как мы видим, речь идет о новой ОС для Cisco - IOS
>XR
>Так что нехорошо вышло не у профессора, а у вас.Дело вот в этой фразе: "QNX is widely used in real commercial systems. Cisco's top-of-the-line router uses it, for example, and I can assure you, Cisco cares a **LOT** about performance."
Безусловно "Cisco cares a **LOT** about performance", но в топовых роутерах Cisco (и не только Cisco) центральный процессор (где и будет работать QNX) как правило не участвует в маршрутизации пакетов, эту грязную работу делают VIP-модули (интерфесные модули со своим процессором и фирмварью). Центральный же процессор поддерживает протоколы маршрутизации (вышеупомянутые rip/bgp/ospf), строит и раздает VIP'ам таблицы форвардинга, а также используется для управления (telnet/rsh/snmp). Для этих задач особое быстродействие не нужно и как справедливо заметил предыдущий оратор ЛЮБАЯ ОС с этим справится.
Некрасиво в этой истории то, что неосведомленный человек пойдет по ссылке, увидит там огромадные значения пропускной способности и подумает 'О какой крутой QNX. Такими гигабитами жонглирует !!! Дайте два !'
А QNX вовсе и не причем...
>16 bugs per 1,000 lines of сode,
>75 bugs per 1,000 lines of code
>Linux kernel like 15,000 bugs;
>Windows XP has at least double that.В принципе всё время было два способа:
1. Ядро - в котором ни хрена, ни чего нет,
и все вставляется и конфигурится руками.
А когда не будет вставлятся руками, так как не все хотят знать bash и С, это превратится в см. ниже или в вариант кипятильников Mac+MacOS - свой кипятильник + свой чай.
2. И толстое жирное ядрище, как в дистрибутивах, как говорится полный p'n'p.
>В принципе всё время было два способа:
>
> 1. Ядро - в котором ни хрена, ни чего нет,
>и все вставляется и конфигурится руками.
>А когда не будет вставлятся руками, так как не все хотят знать
>bash и С, это превратится в см. ниже или в вариант
>кипятильников Mac+MacOS - свой кипятильник + свой чай.
> 2. И толстое жирное ядрище, как в дистрибутивах, как говорится полный
>p'n'p.Говорю же, читайте книжки. Какое отношение имеет ядро к PnP? Всей подсистеме PnP вовсе не обязательно сидеть в кольце 0. Она прекрасно может работать как отдельный процесс в кольце 3.
P'n'P - это переводится до словно "Штекер и игра" образно Включай и работай.Те между включай и работай нет
#mount -t iso9660 /dev/hda /mnt/cdrom
mount: unknown filesystem type 'iso9660'
#mkdir /usr/src
#cd /usr/src
#wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.16....
#tar -xvjf linux-2.6.16.16.tar.bz2
#cd linux-2.6.16.16
#make menuconfig
... манипуляции...
#make && make modules_install && make install && init 6
....
#mount -t iso9660 /dev/hda /mnt/cdrom
# ls /mnt/cdrom
quake2-3.20-glibc-i386-unknown-linux2.0.tar.gz
tar -xvzf /mnt/cdrom/quake2-3.20-glibc-i386-unknown-linux2.0
cd quake2-3.20-glibc-i386-unknown-linux2.0
eject && sleep 10 && eject -t
mkdir baseq2
mount -t iso9660 /dev/hda ./baseq
./quake2
какая нам разница, на каком ядре будут глючить Х драйверы и пр. проги...
+1 !!
unsigned int fresco(+1)
такая, что при микроядре кнопка резет больше не нужна.к тому же в идеале, дрова будут работать с ядром по одному протоколу (api), который не будет меняться как у линукса. соответственно будут появляться бинарные драйвера (хоть это и абсолютное зло).
Вот, блин! Большинство здесь пишущих до конца не понимают сути.
Пример:
Есть одна сетевая железяка, которая переодически зависает. Производитель уважаемый, прошивки новые выпускает, но где гарантия, что с новыми прошивками не придут новые глюки? Будь то микроядро, то сценарий мог бы быть таким: ядро крутится и смотрит за порядком, сервер TCP делает своё дело, остальные своё, ну произошло переполнение буфера, допустим, в TCP сервере, ну и ничего страшного, потому что всего-навсего вызовется исключение, на которое отреагирует ядро и перезапустит сервер TCP. Всем хорошо и админу и пользователю, а вы говорите, что разницы нет.p.s.
http://www.morphos.org/
успешное микроядро, правда на x86 не работает ;-)
> ну произошло переполнение буфера, допустим, в TCP сервере, ну и ничего страшного, потому что всего-навсего вызовется исключение, на которое отреагирует ядро и перезапустит сервер TCP.
Спасибо, улыбнули. Для DoS не хватает только одного шага - эксплоита, который будет приводить к переполнению каждый раз как только "сервер TCP" станет доступен после очередного перезапуска.
DoS - это не проблема, можно обнаружить и грамотно отреагировать. Я говорю про ошибки разработчиков. В любом, даже проверенном и очень стабильном, коде есть ошибки, точнее не только ошибки, а непрогнозируемые свойства. Коллективная разработка прой приводит к совершенно непредсказуемым и неожиданным ошибкам. Кто работал в коллективе тот поймёт ;-), когда с добавлние одного функционала отваливается другой или когда в новом релизе продукта не не работает то, что всегда работало или работает, но немного иначе. Хорошо, если отловили перед выпуском, а то бывает, что отлавливабт заказчики :-). Менеджер проекта бесится и требует наказать тестировщиков, а те говорят, что экономили время и не могли тестировать заведомо исправны функции.
http://3d.morphos-team.net/
Думаю массовый переход к микроядрам спровоцирует производителей процев к оптимизции и изменении механизма шлюзов перехода между кольцами, ИМХО в v386 много чего можно улучшить.
сам много думал о том, что как-то все не совсем верно, что мааааленький недочет в проверке параметров сискола - и уже громкая дырка "в пенгвина стреляли!"....
И принципы микроядра приходили в голову, но тут же натыкались на факт того, что это мысли о микроядре, которое так не любит Торвальдс. Не склонен я не доверять Торвальдсу, но так бы хотелось избавить линух от глупых проблем.Перенос некоторого числа драйверов поближе (совсем и не совсем) ;) к юзерлевелу реально повысил бы стабильность линуха.
да вот проблема: всего полштыка лопаты в поисках методов перехода к микролинуху - и уже ужасный скрип о камни. Камни тормозов такого ядра и немерянные затраты человекоресурсов: многие годы переписи существующего ядра, которые просто остановят развитие линуха.
Мне кажеццо, это неподъемная цена.
Хотя и пряник не так уж плох - на порядки большая устойчивость...
>Перенос некоторого числа драйверов поближе (совсем и не совсем) ;) к юзерлевелу реально повысил >бы стабильность линуха.
Во-во, все проприетарные: NVidia, ATI, RAID-ы, момеды, Wi-Fi. И не надо кричать погонщикам за FPS-ами, для игровых станций пусть видеодрайвера будут в ядре, а для десктопов пусть будут в юзерспейсе.
>>Перенос некоторого числа драйверов поближе (совсем и не совсем) ;) к юзерлевелу реально повысил >бы стабильность линуха.
>Во-во, все проприетарные: NVidia, ATI, RAID-ы, момеды, Wi-Fi. И не надо кричать
>погонщикам за FPS-ами, для игровых станций пусть видеодрайвера будут в ядре,
>а для десктопов пусть будут в юзерспейсе.что-то в этом есть.
Т.е. если появится еще одна свобода: линух обычный и микроядерный - мир опенсорса лишь выиграет.
Лишняя свобода выбора вряд-ли помешает в данном случае.
Микроядерного линукса не будет :(
Но есть Миникс 3, и он очень неплохо развивается. Тут много людей вылили на микроядерные системы ушаты помоев, непонимая при этом, о чем идет речь. Почему бы не попробовать систему в действии, прежде чем критиковать. А сделать ето очень просто - иден на http://www.minix3.org/download/index.html, качаем и тестим. Потом высказываем конструктивную критику. Обгадить что-то гораздо легче, чем разбираться, я понимаю. Но может все-таки попоробуем разобраться?
MINIX3 -- игрушка. Да, академичеки он не плох (но косяки есть -- одна minixfs че го стоит), но никаой поддержки оборудования. Не стоит забывать, что он задуман и реализован только как игрушка, наглядное пособие к книге Танненбаума.
>MINIX3 -- игрушка. Да, академичеки он не плох (но косяки есть --
>одна minixfs че го стоит), но никаой поддержки оборудования. Не стоит
>забывать, что он задуман и реализован только как игрушка, наглядное пособие
>к книге Танненбаума.Нет.
minix3.org:
MINIX 3 adds the new goal of being usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability
Думаю, что имидж Миникс как "несерьезной" ОС для обучения сейчас будет ей сильно вредить, так как многие люди, не разобравшись в обстановке, будут продолжать считать ее таковой. Да, сделать там еще очень много надо, но, как мне кажется, новая миникс в будующем из гадкого утенка превратится в очень даже вкусного лебедя :)
Микроядерная архитектура кроме всего прочего идеологически очень подходит к NUMA. Все прозрачно: передать сообщение локальному процессу или процессу по ту сторону океана. Сила в масштабируемости. Остальное, имхо, просто вкусности.
>Микроядерная архитектура кроме всего прочего идеологически очень подходит к NUMA. Все прозрачно:
>передать сообщение локальному процессу или процессу по ту сторону океана. Сила
>в масштабируемости. Остальное, имхо, просто вкусности.это да. но как ламерствуют вендузятнеги "TCP/IP между X сервером и клиентом на одном компе можно было бы заменить и чем-нить побыстрее".
Примерно такого же смысла фраза.ну да ладно. у таких вендузятнегов нет мозгов. Но X11 обладает отличной оптимизацией в случае запуска клиента и сервера на одном компе.
А вот микроядру неоткуда взять такую оптимизацию в случае обычной 1 процессорной системы (ну или SMP на борту одной матери).Так что... вкусности тока показательные. Кусать их - больно.
>Так что... вкусности тока показательные. Кусать их - больно.ну, те которые кусать не больно - несомненно вкусности 8) я как раз их имел ввиду.
Можно я вставлю свои пять копеек.Дело в том что микроядерные системы изначально задумывались как высоконадежные, высокопроизводительные, реального времени системы в тех областях деятельности человека, где выход из строя одного из программных компонент очень губительно скажется на жизнедеятельности человека или приведет к материальным потерям, которые в сотни-десятки тысячи раз выше стоимости разработкы микроядерной аохитектуры и накладных расходов связанных с этим.
>Можно я вставлю свои пять копеек.Дело в том что микроядерные системы изначально
>задумывались как высоконадежные, высокопроизводительные, реального времени системы в тех областях деятельности
>человека, где выход из строя одного из программных компонент очень губительно
>скажется на жизнедеятельности человека или приведет к материальным потерям, которые в
>сотни-десятки тысячи раз выше стоимости разработкы микроядерной аохитектуры и накладных расходов
>связанных с этим.Вы будете смеяться, как говорят в Одессе, но системы т.н. "жесткого" реального времени обычно строятся как раз в виде монолитного образа в памяти, где уже предварительно, на стадии загрузки этого образа или даже при компиляции распределены все необходимые ресурсы. Динамическое выделение в рабочем режиме напрочь отсутствует. И как правило, в таких системах используется кооперативная многозадачность, нежели вытесняющая. Правда, бывает и смешанная.
Такой вид систем очень узкоспециализирован. Существует всего-лишь ряд областейв которых применяются такие системы. Некоторые из них: системы медицинской
диагностики, средства спутниковой и аивационной навигации, средства
организации непрерывных технологичесих процессов и производства продукции. Про
военных ничего конкретного не скажу, но по некоторым непроверенным "слухам" -
навигационные системы, а так же управление полетами определенного класса
средств ПВО организовывается на отечественной системе РВДОС, а так же QNX.
Разработка драйверов, а так же прикладного программного обеспечения для такихсистем очень дорогостоящее занятие, это связанно с тем что, так как к классу
таких систем предъявляются очень высокие требования по отклику от неё в
конечное определенное время. Всвязи с этим усложняется отладка и написание
оной.
На десктопах такая система врядли прижевется. Да и врядли опенсорс ссобществонайдет в себе силы пойти на такой беспрецендентный шаг как использование
микроядра. Такого рода системами смогут пользоваться лишь профессионалы, те
которым нужно быстродействие и надежность в поле их профессиональной
деятельности.
Тут идет подмена понятий. Десктоп - системе восе не обязательно иметь такие строгие критерии по надежности только из-за того, что она микроядерная.>Да и врядли опенсорс ссобщество найдет в себе силы пойти на такой беспрецендентный шаг как использование микроядра.
Уже нашло. www.minix3.org
Посмотрите minix3 и прочитайте книгу Таненбаума(желательно обе) посвещенную OS.
У каждой идеологии пострения ОС есть свои премщества и недостатки, так что этот спор будет вечен.
Имея большой опыт работы с QNX, могу смело заявить, что лучше операционной системы в плане архитектуры, простоты построения многозадачных систем, написания драйверов я не видел. У нее только два существенных недостатка, из-за которых пришлось от нее отказаться: закрытые исходные коды и высокая цена в конечном продукте. Первый недостаток QSSL мотивирует тем, что они _отвечают_ за качество кода и открытие исходников повлечет за собой желание каждого добавить что-то свое, что может внести ухудшение качества системы.Сторонникам ломания копьев: нет идеальной ОС, каждая система предназначена для решения конкретных задач: паровозы из потомков UNIX - таскать составы информационных потоков, болиды QNX - управлять ядерными реакторами, самолеты Integrity - летать на самолетах, радиоуправляемые модели Linux - "Just for fun".
>Имея большой опыт работы с QNX, могу смело заявить, что лучше операционной
>системы в плане архитектуры, простоты построения многозадачных систем, написания драйверов я
>не видел.большой опыт работы только в QNX, а говоришь, что она лучшая из всех.... нелогично как-то...
>У нее только два существенных недостатка, из-за которых пришлось
>от нее отказаться: закрытые исходные коды и высокая цена в конечном
>продукте. Первый недостаток QSSL мотивирует тем, что они _отвечают_ за качество
>кода и открытие исходников повлечет за собой желание каждого добавить что-то
>свое, что может внести ухудшение качества системы.где ты такую мазу кривую вчитал? у них на сайте?
смотри логику: если сырцы открываються -> другие резко _хотят_ (и не более) туда портировать весь мир -> эти все посылаюццо НАФИК, потому как кто-то там за что-то там "отвечает". Пускай отвечают, а людди себе сделали бы форк и дополняли чем хотели бы.Вывод: маза про закрытые сырцы - ацтой.
Кроме того: как они могут отвечать за "качество кода", если кода никто кроме них в глаза не видел? ;) Может за качество ядра они и могут ответить, но не за качество кода. Они как раз для того, чтоб не отвечать за его качество - закрывают сырцы.
>Сторонникам ломания копьев: нет идеальной ОС, каждая система предназначена для решения конкретных
>задач: паровозы из потомков UNIX - таскать составы информационных потоков, болиды
>QNX - управлять ядерными реакторами, самолеты Integrity - летать на самолетах,
>радиоуправляемые модели Linux - "Just for fun".а для чего:
- паравозы QNX?
- самолеты Linux?
- радиоуправляемые прошивки Lego NXT?
>>Имея большой опыт работы с QNX, могу смело заявить, что лучше операционной
>>системы в плане архитектуры, простоты построения многозадачных систем, написания драйверов я
>>не видел.
>
>большой опыт работы только в QNX, а говоришь, что она лучшая из
>всех.... нелогично как-то...
слово только явно лишнее ;)
из тех, что трогал руками: CP/M, MSDOS 3,5,6, Novell DOS, Windows 3.1, 3.11, 95, 98, NT, 2000, XP, QNX 4.2..4.25 6.0..6.3, Linux 2.2, 2.4, FreeBSD 5.2..6.1
Еще десяткок, по которым читал обзоры и документацию.>>У нее только два существенных недостатка, из-за которых пришлось
>>от нее отказаться: закрытые исходные коды и высокая цена в конечном
>>продукте. Первый недостаток QSSL мотивирует тем, что они _отвечают_ за качество
>>кода и открытие исходников повлечет за собой желание каждого добавить что-то
>>свое, что может внести ухудшение качества системы.
>
>где ты такую мазу кривую вчитал? у них на сайте?
>смотри логику: если сырцы открываються -> другие резко _хотят_ (и не более) туда портировать весь мир -> эти все посылаюццо НАФИК, потому как кто-то там за что-то там "отвечает". Пускай отвечают, а людди себе сделали бы форк и дополняли чем хотели бы.От людей, которые непосредственно общались с представителями QSSL
>
>Вывод: маза про закрытые сырцы - ацтой.
>
>Кроме того: как они могут отвечать за "качество кода", если кода никто
>кроме них в глаза не видел? ;) Может за качество
>ядра они и могут ответить, но не за качество кода. Они
>как раз для того, чтоб не отвечать за его качество -
>закрывают сырцы.
>
Их система - это товар, на который они дают _гарантию_ работоспособности. Если система работает, мне, как разработчику, исходники не нужны, как не нужны исходники BIOS, firmare винчестеров, главное, чтобы _железка_ работала. Не стоит забывать про интеллектуальную собственность, вложенную в эти исходники. Как разработчику, мне исходники нужны только для прохождения сертификации, и иногда, в случае неработоспособности чего-либо, решении проблем, чаще в своем коде.
>>Кроме того: как они могут отвечать за "качество кода", если кода никто
>>кроме них в глаза не видел? ;) Может за качество
>>ядра они и могут ответить, но не за качество кода. Они
>>как раз для того, чтоб не отвечать за его качество -
>>закрывают сырцы.
>>
>Их система - это товар, на который они дают _гарантию_ работоспособности. Если
>система работает, мне, как разработчику, исходники не нужны,отлично. Зачем тогда говорить о том, чего нет: что они отвечают за "качество кода"?
Код у них может быть практически нечитабельным и непрозрачным для понимания, но все-же ядро будет отлично работать.
Следовательно: качеством кода они отвечают только перед собой же, но не заказчиками.>как не нужны
>исходники BIOS, firmare винчестеров, главное, чтобы _железка_ работала. Не стоит забывать
>про интеллектуальную собственность, вложенную в эти исходники.наздоровье. просто про качество исходников лучше не нужно. Никто их не видел, кроме их самих.
убейте себя о стену.
перед этим внимательно прочтя http://www.qnx.com/products/source_kits/index.html
>убейте себя о стену.
>перед этим внимательно прочтя http://www.qnx.com/products/source_kits/index.htmlпасиба. я пешком постою
все это гуд, тока дорого. хотя, смотря какая задача стоит.
Но что-то пока не вставало ниче подобного %)
Добавлю:
Тем, кто верит в легенды о малой производительности микроядерных систем: имея намного лучшие средства межпроцессного взаимодействия, им не нужны костыли в виде сокетов, разделяемой памяти, сложностей синхронизации и т.п. проблем, из-за которых все потенциальное быстродействие монолитного ядра теряется на сложных протоколах взаимодействия между процессами. Конкретный пример: сравните архитектуру и быстродействие X-Window в *BSD и Photon в QNX.Еще пример:
- машина с несколькими сетевыми адаптерами, работающая как аршрутизатор/firewall;
- сетевые потоки, полностью забивающие процессор и шину;
Результат для *BSD: из-за обработки сетевых пакетов на уровне обработки прерываний все остальные процессы отдыхают, система управления маршрутизатором практически не доступна.
Результат для QNX (аналогично и для других микроядерных систем): повышаю приоритет просесса управления выше сетевого менеджера и все работает.Architecture, Architecture, Architecture...
Так X-Window сидит не в ядре, и не может пользоваться всеми этими "средства межпроцессного взаимодействия". X-Window в *BSD и Photon в QNX сравнивать нельзя, потому что X-Window принципиально работает с интерфейсом через сеть, позволяя создавать много терминалов и одни сервер.Давай сравним производительность Photon и svgalib.
Пример некорректен опять - BSD не создавалась как ОС реального времени.
Возьми монолитный Linux реального времени - http://www.realtimelinuxfoundation.org и все будет нормально.
>Так X-Window сидит не в ядре, и не может пользоваться всеми этими
>"средства межпроцессного взаимодействия". X-Window в *BSD и Photon в QNX сравнивать
>нельзя, потому что X-Window принципиально работает с интерфейсом через сеть, позволяя
>создавать много терминалов и одни сервер.
Photon не сидит в ядре, позволяет работать через сеть, как нативную QNX, так и через TCP/IP, даже через null-модем на скорости в 9600. Позволяет делать такие вещи, которым X'ам и не снились. Все это благодаря архитектуре QNX. X'ы работают через сокеты, т.к. другого средства просто не было, а сейчас это все никто переделывать не будет. Рельсы проложены, паравоз разогнан.>
>Давай сравним производительность Photon и svgalib.
>
Думаю, будут близки, основное время затрачивается на работу видеодрайвера а не разборку сетевых пакетов с запросами клиентов.>Пример некорректен опять - BSD не создавалась как ОС реального времени.
>Возьми монолитный Linux реального времени - http://www.realtimelinuxfoundation.org и все будет нормально.Я нигде не говорил про реальное время, это совершенно другая тема. Речь об архитектуре систем и возможностям IPC. В Linux есть механизмы блокированной передачи сообщений меж процессами? DOS тогда тоже система реального времени, если ее грамотно под это заточить.
> Photon не сидит в ядре, позволяет работать через сеть, как нативную QNX, так и
> через TCP/IP, даже через null-модем на скорости в 9600. Позволяет делать такие
> вещи, которым X'ам и не снились.Если на нульмодеме он только 9600 может поднять и это вещи, которые "иксам и не снились", то ваш моск был отторгнут организмом и требует ампутации.
> Все это благодаря архитектуре QNX.
лишний раз свалилсо под столА если серьезно - линки в студию, плз. Почетаем, чего там иксы не могут. Мало ли...
>> Photon не сидит в ядре, позволяет работать через сеть, как нативную QNX, так и
>> через TCP/IP, даже через null-модем на скорости в 9600. Позволяет делать такие
>> вещи, которым X'ам и не снились.
>
>Если на нульмодеме он только 9600 может поднять и это вещи, которые
>"иксам и не снились", то ваш моск был отторгнут организмом и
>требует ампутации.
9600 было достаточно, чтобы подключится с одной машины на другую в Photon сессии.>
>> Все это благодаря архитектуре QNX.
>лишний раз свалилсо под стол
поднимайся ;) Photon заточен на передачу сообщений: от пользовательского приложения Photon - серверу, далее конкретному видеодрайверу или через сеть другому Photon - серверу; и в обратную сторону - от драйвера ввода до пользовательского приложения. Накладные расходы минимальны, максимальная гибкость и масштабируемость.
>
>А если серьезно - линки в студию, плз. Почетаем, чего там иксы
>не могут. Мало ли...
Для начала:
http://www.qnx.com/products/graphics/photon.html
очень похоже, что в X'ах все есть ;)От себя: в X'ах нет jumpgate - возможности переслать _приложение_ на другую машину. Простейший пример, когда я коллеге отсылаю целиком текстовый редактор, в котором он вводит нужные данные и отправляет его мне обратно. Пример от QSSL: инженер с экрана общего отображения на предприятии забирает приложение на свой notebook и идет с ним по цеху. Естественно, приложение продолжает выполняться на той же машине, весь вывод его идет на другую. Все благодаря механизму передачи сообщений между процессами (прозрачно через сеть), которого в монолитных ядрах нет.
>>Если на нульмодеме он только 9600 может поднять и это вещи, которые
>>"иксам и не снились", то ваш моск был отторгнут организмом и
>>требует ампутации.
>9600 было достаточно, чтобы подключится с одной машины на другую в Photon
>сессии.чтобы подключиться - нужно намного меньше чем 9600
чтобы смотреть фильм - о 10/100Mbit/s придеццо крепко задуматься.т.е. цыфра 9600 НИКАК не характеризует photon.
иксы с тем же успехом будут работать на таком нульмодеме.
>>> Все это благодаря архитектуре QNX.
>>лишний раз свалилсо под стол
>поднимайся ;) Photon заточен на передачу сообщений: от пользовательского приложения Photon -
>серверу, далее конкретному видеодрайверу или через сеть другому Photon - серверу;
>и в обратную сторону - от драйвера ввода до пользовательского приложения.
>Накладные расходы минимальны, максимальная гибкость и масштабируемость.ну не странно ли... слово "photon" заменяешь на "иксы" и смысл сохраняеццо....
Даже БЕЗ QNX. удивительно?
>>А если серьезно - линки в студию, плз. Почетаем, чего там иксы
>>не могут. Мало ли...
>Для начала:
>http://www.qnx.com/products/graphics/photon.html
>очень похоже, что в X'ах все есть ;)
>
>От себя: в X'ах нет jumpgate - возможности переслать _приложение_ на другую
>машину. Простейший пример, когда я коллеге отсылаю целиком текстовый редактор, в
>котором он вводит нужные данные и отправляет его мне обратно.+1
да, такого нет в иксах. Но особенности QNXа к этому всему - примерно как правда к "Get the facts".>Пример
>от QSSL: инженер с экрана общего отображения на предприятии забирает приложение
>на свой notebook и идет с ним по цеху. Естественно, приложение
>продолжает выполняться на той же машине, весь вывод его идет на
>другую. Все благодаря механизму передачи сообщений между процессами (прозрачно через сеть),
>которого в монолитных ядрах нет.ну лана. обежаццо, что реклама нас ная%ывает - несерьезно.
ессьно, ядро к перенаправлению вывода графики никаким боком.
То что передача графики идет через мессаги ядра - особенности этого ядра и подсистемы графики.
Но блин! То, что фичи перепрыгивания нет в иксах - никоим образом не ограничивает возможность такой фичи микроядрами! ну это же бред! Эта фича НЕ зависит от того как модули ядра/процессы взаимодействуют между собой.Вы слабовато разбираетесь в вопросе.
>ну лана. обежаццо, что реклама нас ная%ывает - несерьезно.
>ессьно, ядро к перенаправлению вывода графики никаким боком.
>То что передача графики идет через мессаги ядра - особенности этого ядра
>и подсистемы графики.
>Но блин! То, что фичи перепрыгивания нет в иксах - никоим образом
>не ограничивает возможность такой фичи микроядрами! ну это же бред! Эта
>фича НЕ зависит от того как модули ядра/процессы взаимодействуют между собой.
Весь Photon постоен на фичах QNX, не было бы IPC через передачу сообщений, его бы не было.
XFree86 был когда-то портирован под QNX и неплохо там жил. Photon - это просто пример качественного использования возможностей системы.
Изначально речь шла о том, что в монолитных ядрах UNIX-like систем нет подобных механизмов IPC, что является их большим недостатком.>
>
>Вы слабовато разбираетесь в вопросе.
;) "Вопрос понял, отвечаю на вопрос"
>Весь Photon постоен на фичах QNX, не было бы IPC через передачу
>сообщений, его бы не было.
>XFree86 был когда-то портирован под QNX и неплохо там жил. Photon -
>это просто пример качественного использования возможностей системы.вооооооот....... ;)
правильное определение. А не "такое невозможно на монолитных ядрах".>Изначально речь шла о том, что в монолитных ядрах UNIX-like систем нет
>подобных механизмов IPC, что является их большим недостатком.ХА. Опять откровения. Да :) в монилите нет _ТАКИХ_ IPC.
Так дело в том, что и с другими IPC они ПОЗВОЛЯЮТ реализовать пример с переводом
вывода изображения.
То, что этого нет в иксах - имеет отношение лишь к сравнению набору фич Photona и иксов.
Но блин НИКАК не особенностей ядер! ;)Короче, обычный прием мягкоствольных - придумать хрень и сказать, что она возможна только на венде, потому что нигде ее больше нет.
Ну, типичный "Get the fUckts"
>Еще пример:
> - машина с несколькими сетевыми адаптерами, работающая как аршрутизатор/firewall;
> - сетевые потоки, полностью забивающие процессор и шину;
>Результат для *BSD: из-за обработки сетевых пакетов на уровне обработки прерываний все
>остальные процессы отдыхают, система управления маршрутизатором практически не доступна.
>Результат для QNX (аналогично и для других микроядерных систем): повышаю приоритет просесса
>управления выше сетевого менеджера и все работает.
>
>Architecture, Architecture, Architecture...фантазии, фантазии, фантазии...
Очевидно, пример нужно понимать так:
- есть комп/роутер, загруженный по самое немогу.
Значит, мы говорим примерно о 300-500 целероне с пятеркой соток, находящимся в досе.
Очевидно, что это общажная сетка, где железо собиралось с миру по крохе и ставили чего было возможно - bsd/linux. Иначе бы:
- в мало-мальской фирме это был бы обычное железо, но в пару гиг частотой. И никакой траффик из этих "нескольких адаптеров" не отправят в дос этого монстра (для роутинга - это реальный монстр). И проблемы нет.
- в крупно-мальской :) конторе, где роутинг это не два сегмента для кваки, - уже не будет обычных компов на критически важных каналах - разговор об осях смещаеться в сторону IOS (а реально - в сторону железа). Менее критические точки роутинга - см. пункт 1Итого: общага, сеть. Кое-как, оно роутит, пускай и плохо управляеццо. Зачем сверх (кое-как все-таки будет можно) управляемость настроенным (траффик то валит!) общажным (!!) роутером? Т.е. более-менее всего хватает.
И тут приходите Вы со словами "я вам все поправлю".
Первое что должны сделать студенты - скинуццо на QNX... ну, надеюсь, уже смешно ;)В вашем примере не учтена цена Вашего решения. Очевидно, что за лицензию на QNX можно прикупить 2 гига частоты и забыть о перегрузке шины/проца ;)
>>Еще пример:
>> - машина с несколькими сетевыми адаптерами, работающая как аршрутизатор/firewall;
>> - сетевые потоки, полностью забивающие процессор и шину;
>>Результат для *BSD: из-за обработки сетевых пакетов на уровне обработки прерываний все
>>остальные процессы отдыхают, система управления маршрутизатором практически не доступна.
>>Результат для QNX (аналогично и для других микроядерных систем): повышаю приоритет просесса
>>управления выше сетевого менеджера и все работает.
>>
>>Architecture, Architecture, Architecture...
>
>фантазии, фантазии, фантазии...
Это была цитата ролика о QNX ;)Слова товарищей из IBM, Cisco и других контор.>
>Очевидно, пример нужно понимать так:
>- есть комп/роутер, загруженный по самое немогу.
>Значит, мы говорим примерно о 300-500 целероне с пятеркой соток, находящимся в
>досе.
Говорим о системе, процессор/шины которой загружены на 100%. Любую вычислительную систему можно загрузить полностью, вопрос в ее устойчивости и реактивности. Это самый простой пример, близкий и понятный читателям opennet.>Очевидно, что это общажная сетка, где железо собиралось с миру по крохе
>и ставили чего было возможно - bsd/linux. Иначе бы:
> - в мало-мальской фирме это был бы обычное железо, но в
>пару гиг частотой. И никакой траффик из этих "нескольких адаптеров" не
>отправят в дос этого монстра (для роутинга - это реальный монстр).
>И проблемы нет.
> - в крупно-мальской :) конторе, где роутинг это не два сегмента
>для кваки, - уже не будет обычных компов на критически важных
>каналах - разговор об осях смещаеться в сторону IOS (а реально
>- в сторону железа). Менее критические точки роутинга - см. пункт
>1
>
>Итого: общага, сеть. Кое-как, оно роутит, пускай и плохо управляеццо. Зачем сверх
>(кое-как все-таки будет можно) управляемость настроенным (траффик то валит!) общажным (!!)
>роутером? Т.е. более-менее всего хватает.
>
>И тут приходите Вы со словами "я вам все поправлю".
>Первое что должны сделать студенты - скинуццо на QNX... ну, надеюсь,
>уже смешно ;)
>
>В вашем примере не учтена цена Вашего решения. Очевидно, что за лицензию
>на QNX можно прикупить 2 гига частоты и забыть о перегрузке
>шины/проца ;)
Фантазии ... Чувствуется рука админа: поднять частоту, вбухать деньги и все в порядке ;)
Конкретная задача для разработчика:
- система управления объектом на базе i386;
- возможны потоки данных, на 100% забивающие системную шину;
- реакция системы на внешний запрос управления при любой нагрузке - не более 500 мс;
- цена железа - до $250 в 3" формфакторе;
- ОС: POSIX - совместимая, с открытым исходным кодом, поддержкой TCP/IP стека, встраиваемая, без оплаты лицензий, не GNU - лицензия, не Linux ;)Какая ОС подходит под эти требования?
>Фантазии ... Чувствуется рука админа: поднять частоту, вбухать деньгигде лицензии на QNX дают нахаляву?
>и все в порядке ;)
>Конкретная задача для разработчика:
>- система управления объектом на базе i386;
>- возможны потоки данных, на 100% забивающие системную шину;
>- реакция системы на внешний запрос управления при любой нагрузке - не
>более 500 мс;
>- цена железа - до $250 в 3" формфакторе;
>- ОС: POSIX - совместимая, с открытым исходным кодом, поддержкой TCP/IP стека,
>встраиваемая, без оплаты лицензий, не GNU - лицензия, не Linux ;)все ладно. а чем GPL не понравильсо? Что это за требования такие? ;)
интересные конечно требования... не Линукс улыбает :)
А если правильно запатченый и удовлетворяет всем требованиям выше? все равно только бы не линукс? ну а почему тогда кто другой не скажет "только не <чтовынамтапредлагаете>" ?вам или ехать или куда?
>Какая ОС подходит под эти требования?скажите QNX и я уйду в монастырь. в какой пока не знаю, но уйду :)
minix3? да, название лицензии не GPL %) по этому путнку проходит.
Но вряд-ли ее ядро сможет все то, что Я к нему предьявлю. Уже поэтому оно не подходит.
HURD - ыыыы.... а оно грузиццо без медперсонала ? %)
>>Фантазии ... Чувствуется рука админа: поднять частоту, вбухать деньги
>
>где лицензии на QNX дают нахаляву?
когда-то была бесплатной QNX6 NC - некоммерческий вариант, подходит для общаги, не подходит для промышленного производтсва.
>
>
>>и все в порядке ;)
>>Конкретная задача для разработчика:
>>- система управления объектом на базе i386;
>>- возможны потоки данных, на 100% забивающие системную шину;
>>- реакция системы на внешний запрос управления при любой нагрузке - не
>>более 500 мс;
>>- цена железа - до $250 в 3" формфакторе;
>>- ОС: POSIX - совместимая, с открытым исходным кодом, поддержкой TCP/IP стека,
>>встраиваемая, без оплаты лицензий, не GNU - лицензия, не Linux ;)
>
>все ладно. а чем GPL не понравильсо? Что это за требования такие?
>;)
GPL подразумевает, что любой Вася Пупкин может попросить открыть исходные коды наших продуктов, в которые вложены конкретные деньги и конкретная интеллектуальная собсвенность.
С BSD и им подобным такой проблемы нет.
>
>интересные конечно требования... не Линукс улыбает :)
>А если правильно запатченый и удовлетворяет всем требованиям выше? все равно только бы не линукс? ну а почему тогда кто другой не скажет "только не <чтовынамтапредлагаете>" ?
>
>вам или ехать или куда?
Ехать, без GPL
>
>
>>Какая ОС подходит под эти требования?
>
>скажите QNX и я уйду в монастырь. в какой пока не знаю,
>но уйду :)
>minix3? да, название лицензии не GPL %) по этому путнку проходит.
>Но вряд-ли ее ядро сможет все то, что Я к нему предьявлю.
>Уже поэтому оно не подходит.
>HURD - ыыыы.... а оно грузиццо без медперсонала ? %)
На самом деле в мире больше полусотни RTOS, несколько с открытыми исходниками, идеальной все равно нет :)
>GPL подразумевает, что любой Вася Пупкин может попросить открыть исходные коды наших >продуктов, в которые вложены конкретные деньги и конкретная интеллектуальная собсвенность.не любой, а только тот, кто пупил у вас ваш продукт.
а это я считаю нормально...
>>GPL подразумевает, что любой Вася Пупкин может попросить открыть исходные коды наших >продуктов, в которые вложены конкретные деньги и конкретная интеллектуальная собсвенность.
>
>не любой, а только тот, кто пупил у вас ваш продукт.
>а это я считаю нормально...эээ-нет...
если для разработки железного роутера было взято ядро линух и переколбашено под себя - то сырцы этого переделанноог ядра должны красоваться в downloads на сайте этой железки.
Все. В этом GPL. Взял по GPL - отдай передланоне тоже под GPL.кому и где ты его продал - никого не интересует. Но если распространяешь переделку в бинарях (а в роутере будет бинарь), то, автоматом, должен выдавать ЛЮБОМУ запросившему - сырцы конечного продукта.
>>где лицензии на QNX дают нахаляву?
>когда-то была бесплатной QNX6 NC - некоммерческий вариант, подходит для общаги, не
>подходит для промышленного производтсва.
че-то было порезано?
ну начинается: количество лицензий, лимиты, expiration time....21 век на дворе
>>все ладно. а чем GPL не понравильсо? Что это за требования такие?
>>;)
>GPL подразумевает, что любой Вася Пупкин может попросить открыть исходные коды наших
>продуктов, в которые вложены конкретные деньги и конкретная интеллектуальная собсвенность.
>С BSD и им подобным такой проблемы нет.я угадал. BSD вы прете и легально юзаете в своих денежных продуктах. А GPL такого свинства не позволяет. Вот вы на нее и гоните.
Так вот. для того чтобы использовать GPL-based продукт, не нужно страдать по поводу того, что его нельзя спереть. Цель - использовать, а не перепродавать.>>вам или ехать или куда?
>Ехать, без GPLвсе-таки, вам шашечки хочется... причем качественных и нахаляву, с возможностью присвоить и выдать за свое.
GPL придумывался ИМЕННО чтоб этого не происходило.>На самом деле в мире больше полусотни RTOS, несколько с открытыми исходниками,
>идеальной все равно нет :)под ваши требования - найдется, пускай и не идеальная ;)
>>>где лицензии на QNX дают нахаляву?
>>когда-то была бесплатной QNX6 NC - некоммерческий вариант, подходит для общаги, не
>>подходит для промышленного производтсва.
>че-то было порезано?
система разработки, возможность собирать не i386 платформы, использование только для целей образования и изучения, в комерческие продукты ни-ни.>
>>>все ладно. а чем GPL не понравильсо? Что это за требования такие?
>>>;)
>>GPL подразумевает, что любой Вася Пупкин может попросить открыть исходные коды наших
>>продуктов, в которые вложены конкретные деньги и конкретная интеллектуальная собсвенность.
>>С BSD и им подобным такой проблемы нет.
>
>я угадал. BSD вы прете и легально юзаете в своих денежных продуктах.
Честно качаем с сайта ;)>А GPL такого свинства не позволяет. Вот вы на нее
>и гоните.
Это не свинство, много открытого кода испольуется в закрытых продуктах, посмотри, например, about в Adobe Reader. GPL - путь анархистов: открыть все! BSD - коллег по цеху: у меня есть хорошая вещь, пользуйся.>Так вот. для того чтобы использовать GPL-based продукт, не нужно страдать по
>поводу того, что его нельзя спереть. Цель - использовать, а не
>перепродавать.
У нас цель - продавать свой продукт, GPL этому мешает.
>
>>>вам или ехать или куда?
>>Ехать, без GPL
>
>все-таки, вам шашечки хочется... причем качественных и нахаляву, с возможностью присвоить и
>выдать за свое.
>GPL придумывался ИМЕННО чтоб этого не происходило.
За свое выдавать смысла нет, проблема в требовании открыть исходники Васе Пупкину.>
>>На самом деле в мире больше полусотни RTOS, несколько с открытыми исходниками,
>>идеальной все равно нет :)
>
>под ваши требования - найдется, пускай и не идеальная ;)
Если бы знать ее имя ;)
>>А GPL такого свинства не позволяет. Вот вы на нее и гоните.
>Это не свинство, много открытого кода испольуется в закрытых продуктах, посмотри, например,
>about в Adobe Reader. GPL - путь анархистов: открыть все!кому от этого плохо? вас заставляют открывать ВАШ СОБСТВЕННЫЙ код под GPL?
никогда.
Но если взяли общее - то и вернуть неплохо бы. Не логично ли?> BSD - коллег по цеху: у меня есть хорошая вещь, пользуйся.
ну да. тебе "пользуйся", а ты его за деньги продаешь. Ну, это проблемы BSD.GPL: у меня есть хорошая вещь, пользуйся.
Так вам "пользоваццо" или "продавать как свое" ????
>>Так вот. для того чтобы использовать GPL-based продукт, не нужно страдать по
>>поводу того, что его нельзя спереть. Цель - использовать, а не
>>перепродавать.
>У нас цель - продавать свой продукт, GPL этому мешает.ложь. Написал свой продукт - продавай солько влезет и никакая GPL тебе слова не скажет.
А если взял общий и хочешь выдать за свой с заменой имени и картинки при старте... ну так кто ты после этого?>>GPL придумывался ИМЕННО чтоб этого не происходило.
>За свое выдавать смысла нет, проблема в требовании открыть исходники Васе Пупкину.
тебе открыли исходники и ты заюзал готовый продукт.
а чем Вася пупкин хуже чем вы? GPL именно это и спрашивает. Более того, она утверждает,
что ничем.Фича в том, что никто не призывает и не заставляет "делиться нажитым", как при комунизме.
Есть у тебя свое - да ради бога. Радуйся и живи счасливо.
Но не нужно расстраиваться, что тебе напоминают, что ты взял НЕ свое.Вы практически обижаетесь на замки в дверях, которые вам помешают зайти и унести с концами чужое добро. Это граничит с необходимостью стационарного обследования...
ну и какой псих - покажите мне его,будет проектировать систему без запаса производительности на критичных участках работы? Или Вы ТОЧНО!!!(подпишитесь под этим, деньгами в первую очередь) гарантируете что в во всех возможных режимах перегрузок эта система будет адекватно реагировать?
Я это видел, своими собственными глазами. Самое первое впечатление от QNX4.2: 486DX66 держала 40000 прерываний/с, ISA была загружена полностью потоками данных с датчиков, Photon и сеть работали.
Грамотно спроектированная система реального времени _всегда_ будет правильно решать задачу реального времени, и реагировать на заданные воздействия, т.к. это система _реального_времени_. При детерменированности реакции системы на воздействие запас производительности становится не нужным.Данная тема уже вышла за рамки начальной статьи, _реальное_ время - это совершенно другая область, где гарантии даются математически, а не деньгами.
>Я это видел, своими собственными глазами. Самое первое впечатление от QNX4.2:уна удовлетворяет Вашим же требованиям по бесплатности и открытым исходникам?
где слить мона? ;)
>486DX66
>держала 40000 прерываний/с, ISA была загружена полностью потоками данных с датчиков,
>Photon и сеть работали.
>Грамотно спроектированная система реального времени _всегда_ будет правильно решать задачу реального времени,
>и реагировать на заданные воздействия, т.к. это система _реального_времени_.хорошее - это когда хорошо.
ессьно, если система realtime, то и ее действия будут RT.Но, описано было, что иксы и сетка etc. работыли, когда шина была загружена "полностью".
для этого не нужен RT. нужна возможность раздачи приоритетов процессам (проги, дрова... тд). Почему вы решили, что только QNX так умеет? Пару соотв. патчей на линух и вы удивитесь, как переоценили QNX в плане управляемости (про RT - разговор отдельный).
>При детерменированности
>реакции системы на воздействие запас производительности становится не нужным.не ненужным. Запас не помешал бы только в ОЧЕНЬ редких случаях и здесь представлен не он.
А если к системе повышаются требования: пропускной способности отдельно сети, отдельно шины и т.д. И все вместе они НИКАК не могут просто даже математически быть выполнены в должном объеме на данной системе - то детерменированность стреляет сигаредку напокурить.Просто в данном примере производительность ISA шины была неважна или с запасом превышала нужную скорость передачи с датчика, что даже ваши иксы и работа в сети не опускали эту скорость ниже требуемой.
Итого, чтобы обеспечить бестормозную работу иксов, когда через десяток сетевух льюццо 100мбит, нужно всего-то: вынести подсистему роутинга в отдельный thread и сделать его приоритет меньше, чем любой пользовательский процесс. Я не знаю сделано ли подобное в каком-либо патче к линуху, но четкая определенность цели делает задачу абсолютно реальной.
А скорость реакции системы - это гарантированно выделяемые частоты на ту или иную задачу.
Никаким боком это не касаеться того, что у вас при загрузке шины все работало.>Данная тема уже вышла за рамки начальной статьи, _реальное_ время - это
>совершенно другая область, где гарантии даются математически, а не деньгами.Ессьно вышла. Редкая холиварная тема не выходит за рамки новости ее породившую ;)
А говорить о том, что наука ("гарантии даются математически") преволирует над деньгами - глупо. Они прочно связаны и друг без друга никуда. И _любая_ система просчитавыется в финансовом плане не менее точно, чем в научном.
>>Я это видел, своими собственными глазами. Самое первое впечатление от QNX4.2:
>
>уна удовлетворяет Вашим же требованиям по бесплатности и открытым исходникам?
>где слить мона? ;)
>
Это было году в 97-м, небесплатна, с закрытыми исходниками, через несколько лет пришлось с нее уходить.>
>Просто в данном примере производительность ISA шины была неважна или с запасом
>превышала нужную скорость передачи с датчика, что даже ваши иксы и
>работа в сети не опускали эту скорость ниже требуемой.
>
процессор был загружен на 100% обработкой данных с датчиков>Итого, чтобы обеспечить бестормозную работу иксов, когда через десяток сетевух льюццо 100мбит,
>нужно всего-то: вынести подсистему роутинга в отдельный thread и сделать его
>приоритет меньше, чем любой пользовательский процесс. Я не знаю сделано ли
>подобное в каком-либо патче к линуху, но четкая определенность цели делает
>задачу абсолютно реальной.
Именно об этом я и говорил, что микроядерная архитектура изначально позволяет это сделать без дополнительных патчей и танцев с бубнами.>А говорить о том, что наука ("гарантии даются математически") преволирует над деньгами
>- глупо. Они прочно связаны и друг без друга никуда. И
Мы говорили о работе системы, а не о том, сколько она стоит. Монолитная FreeBSD дешевле микроядерной QNX, монолитная Solaris дороже микроядерной MINIX.>_любая_ система просчитавыется в финансовом плане не менее точно, чем в
>научном.
О том и речь, что на данный момент - либо за деньги, либо плохо, либо с GNU лицензией, что еще хуже в финансовом плане.
> Это было году в 97-м, небесплатна, с закрытыми исходниками,
ну вот. а вы про бесплатность и сырцы...> через несколько лет пришлось с нее уходить.
>>Просто в данном примере производительность ISA шины была неважна или с запасом
>>превышала нужную скорость передачи с датчика, что даже ваши иксы и
>>работа в сети не опускали эту скорость ниже требуемой.
>>
>процессор был загружен на 100% обработкой данных с датчиковесли он был на 100% загружен обработкой датчиков, то вашими иксами он был загружен на 0%
;) ил больше? у вас процессор дает >100% своей текущей (не номинальной, а текущей) производительности? ну, не смешно при разговоре о точных науках...
>>Итого, чтобы обеспечить бестормозную работу иксов, когда через десяток сетевух льюццо 100мбит,
>>нужно всего-то: вынести подсистему роутинга в отдельный thread и сделать его
>>приоритет меньше, чем любой пользовательский процесс. Я не знаю сделано ли
>>подобное в каком-либо патче к линуху, но четкая определенность цели делает
>>задачу абсолютно реальной.
>Именно об этом я и говорил, что микроядерная архитектура изначально позволяет это
>сделать без дополнительных патчей и танцев с бубнами.увы, вы неправы. не микроядерная архитектура это позволяет сделать без патчей, а конкретно QNX. Просто в нем этот функционал был добавлен уже. А то, что он микроядерный - ну, повезло ему так.
>>А говорить о том, что наука ("гарантии даются математически") преволирует над деньгами
>>- глупо. Они прочно связаны и друг без друга никуда. И
>Мы говорили о работе системы, а не о том, сколько она стоит.отлично. я беру парочку кластеров IBM и буду успевать роутить любые 5 (угу, всего пять %) сетевух, снимать МНОГО датчиков, рисовать гору иксов.... и т.д. на простом непатченом линухе.
Рассуждая о технологиях нельзя в наше время ложить на финансовую сторону. Хоть немного, но нужно и об этом помнить. Иначе получеццо, что роутить инет лучше через бортовой компутер марсохода. там операционка "очень для этого подходит" %) даже если она трижды для этого подходит - то нужно задуматься сколько десятилетий такой роутер будет себя окупать, прежде чем даже задуматься над реализацией с марсоходом.
> Монолитная FreeBSD дешевле микроядерной QNX,Если тут о стоимости продажи - то QNX просто продают дороже ;)
> монолитная Solaris дороже микроядерной MINIX.
а эти оба создания вообще раздаюццо бесплатно. Цены у них равны.Но если же говорить о стоимости разработки каждого из этих продуктов с нуля - то minix просто не найдет где сесть. А остальные будут наравне соревноваться в цене.
>>_любая_ система просчитавыется в финансовом плане не менее точно, чем в
>>научном.
>О том и речь, что на данный момент - либо за деньги, либо плохо,бред. Линух: бесплатно (ну или копейки за носитель) и настолько хорошо, что на нем строиться N миллиардный бизнес в всем мире. От хостинга - до вычислений за деньги.
Его юзают потому что он работает достаточно для этого хорошо, а не потому что дорог или дешев.
>либо с GNU лицензией, что еще хуже в финансовом плане.ну про это вообще отдельный разговор. Вы либо девелопер, привыкший тырить BSD-licensed код в свои закрытые продукты и не могущий так же свободно обходиться с GPL, либо посланнег мягких, вещающие, что GPL рушит рынок продажи воздуха.
КАК GPL может быть хуже в финансовом плане, если за использование GPL продуктов НЕ нужно платить?
Да, есть еще куда дальше мечтать - получать деньги за то, что снизошел юзать GPL-licensed. Но это родом оттуда же, откуда и проц с производительностью 105% от своей собственной ;)
>>процессор был загружен на 100% обработкой данных с датчиков
>
>если он был на 100% загружен обработкой датчиков, то вашими иксами он
>был загружен на 0%
>;) ил больше? у вас процессор дает >100% своей текущей (не номинальной, а текущей) производительности? ну, не смешно при разговоре о точных науках...
точная наука: обработка датчиков делалась на 10-м приоритете, сеть жила на 23-м, где-то между ними Photon. События сети и Photon'а были более приоритетными и вытесняли обработку данных.>
>
>>>Итого, чтобы обеспечить бестормозную работу иксов, когда через десяток сетевух льюццо 100мбит,
>>>нужно всего-то: вынести подсистему роутинга в отдельный thread и сделать его
>>>приоритет меньше, чем любой пользовательский процесс. Я не знаю сделано ли
>>>подобное в каком-либо патче к линуху, но четкая определенность цели делает
>>>задачу абсолютно реальной.
>>Именно об этом я и говорил, что микроядерная архитектура изначально позволяет это
>>сделать без дополнительных патчей и танцев с бубнами.
>
>увы, вы неправы. не микроядерная архитектура это позволяет сделать без патчей, а
>конкретно QNX. Просто в нем этот функционал был добавлен уже. А
>то, что он микроядерный - ну, повезло ему так.
QNX _изначально_ строилась как микроядерная реального времени. "Удачи не существует".
Ее _архитектура_ была заточена под это. Что никак не может принять Торвальдс, это то, что он использовал древнюю архитектуру ядра, изначально мотивируя ее простотой. Доводы о производительности он строил на основе своего студенческого опыта с MINIX, если бы он видел QNX, Linux был бы совсем другим ;)>Рассуждая о технологиях нельзя в наше время ложить на финансовую сторону. Хоть
>немного, но нужно и об этом помнить. Иначе получеццо, что роутить
>инет лучше через бортовой компутер марсохода. там операционка "очень для этого
>подходит" %) даже если она трижды для этого подходит - то
>нужно задуматься сколько десятилетий такой роутер будет себя окупать, прежде чем
>даже задуматься над реализацией с марсоходом.
Об этом и речь, на QNX дешевле разрабатывать, т.к. быстрее и проще, но дороже конечная система из-за лицензионных поборов.>
>КАК GPL может быть хуже в финансовом плане, если за использование GPL
>продуктов НЕ нужно платить?
>Да, есть еще куда дальше мечтать - получать деньги за то, что
>снизошел юзать GPL-licensed. Но это родом оттуда же, откуда и проц
>с производительностью 105% от своей собственной ;)
Простой пример: гениальный инженер Иванов изобрел алгоритм управления плавильной печью, который позволяет экономить много $$$, встроил его в систему управления. Приходит Вася Пупкин из конкурирующей конторы, мотивируя GPL, требует открыть исходники. Контора инженера Иванова теряет $$$, т.к. конкуренты будут продавать то же решение за меньшие деньги, т.к. их затраты на разработку многократно сократились, благодаря использованию готового кода Иванова.Конечно, существует вероятность того, что никто не узнает, что в плавильной печи используется код под GPL ;)
>>увы, вы неправы. не микроядерная архитектура это позволяет сделать без патчей, а
>>конкретно QNX. Просто в нем этот функционал был добавлен уже. А
>>то, что он микроядерный - ну, повезло ему так.
>QNX _изначально_ строилась как микроядерная реального времени. "Удачи не существует".
>Ее _архитектура_ была заточена под это. Что никак не может принять Торвальдс,
>это то, что он использовал древнюю архитектуру ядра, изначально мотивируя ее
>простотой. Доводы о производительности он строил на основе своего студенческого опыта
>с MINIX, если бы он видел QNX, Linux был бы совсем
>другим ;)"если бы" не существует" ;)
так вот. повторю еще раз. Наличие возможности в QNX изменить приоритет драйвера и сделать его МЕНЬШЕ приоритета обычной проги - фича НЕ связанная с RT. Просто фича. И она есть в QNX.
Это же можно легко (теоретически определить. потому как возгласы "ну сделай" идут в лес) сделать и в ядре, процессы которого живут в одном адресном пространстве. Для того чтоб сетка была менее приоритетной, чем мультик на экране не нужно быть RT.
Быть RT - это гарантировать конкретное количество герц под конкретную задачу. Все.
>Об этом и речь, на QNX дешевле разрабатывать, т.к. быстрее и проще,
>но дороже конечная система из-за лицензионных поборов.QNX - POSIX-compatible
Linux - тоже (количество отклонений некритично)
Вопрос: какая разница под какую POSIX систему разрабатывать если разницы нет?
Ответ: никакой. Это мифы древней греции>Простой пример: гениальный инженер Иванов изобрел алгоритм управления плавильной печью, который позволяет
>экономить много $$$, встроил его в систему управления. Приходит Вася Пупкин
>из конкурирующей конторы, мотивируя GPL, требует открыть исходники. Контора инженера Иванова
>теряет $$$, т.к. конкуренты будут продавать то же решение за меньшие
>деньги, т.к. их затраты на разработку многократно сократились, благодаря использованию готового
>кода Иванова.Т.е. плакаццо, что твое ноу-хау уедет по GPL влюди - это нормально, но при этом так же
запросто юзать GPL'd систему управления.Товарисч. Все просто как дерево. И за это бореццо мокросовт. Лицензионная чистота.
Вот моя наработка. При исплользовании моей же наработки. И т.д. до драйвера мыши.
Все. %би потом этим моск кому угодно и слово никто не скажет.
Но вы хотите и рыбку съесть и на й%х сесть.Чтоб не претерпевать колосальных убытков от раскрытия ноу-хау - пущай этот грамотей Иванов, напишет с нуля систему управления и затратит на этом н-ную сумму чтоб сэкономить еще большую.
Ничто никуда не деваеццо и не появляеццо из неоткуда.
Хочешь денег - СДЕЛАЙ что-нибудь и для этого придеццо вложить начальный капитал.Конечно же всем хочеться первого, и не хочеться второго ;)
Денег и ниче не делать и не тратить.
Идите, товарисч халявщик в лес. Там все закрыто и в готовом виде. Без сырцов. ;)>Конечно, существует вероятность того, что никто не узнает, что в плавильной печи
>используется код под GPL ;)именно на таком свинстве зарабатывают небольшие конторы, продавая общее как свое.
Просто сволочи
>Простой пример: гениальный инженер Иванов изобрел алгоритм управления плавильной печью, который позволяет
>экономить много $$$, встроил его в систему управления. Приходит Вася Пупкин
>из конкурирующей конторы, мотивируя GPL, требует открыть исходники. Контора инженера Иванова
>теряет $$$, т.к. конкуренты будут продавать то же решение за меньшие
>деньги, т.к. их затраты на разработку многократно сократились, благодаря использованию готового
>кода Иванова.Это глупый пример. Никто не заставит инженера Иванова открывать то, что он сделал сам (алгоритм управления печью).
Он должен показать только исходники модифицированного им линукса (как пример), который является не более чем прослойкой между его "гениальным алгоритмом" и железом.
Так что проблемы нет!
>Конечно, существует вероятность того, что никто не узнает, что в плавильной печи
>используется код под GPL ;)
а это откровенное свинство
>Это глупый пример. Никто не заставит инженера Иванова открывать то, что он
>сделал сам (алгоритм управления печью).
>Он должен показать только исходники модифицированного им линукса (как пример), который является
>не более чем прослойкой между его "гениальным алгоритмом" и железом.
>Так что проблемы нет!ну, вообще-то пример был, как я понимаю, именно о нечто едином: система правления.
Именно патчи к ней и являюццо интелектуальной собственностью Иванова.Так что проблема есть и она в жадности этого инженера ;))
В любом случае: если не хочет отдавать ноу-хау под GPL,
или не хочет оплатить создание системы управлния с нуля, чтоб не было претензий к его коду.
>>Конечно, существует вероятность того, что никто не узнает, что в плавильной печи
>>используется код под GPL ;)
>а это откровенное свинствоРЕСПЕКТ!
>ну, вообще-то пример был, как я понимаю, именно о нечто едином: система
>правления.
>Именно патчи к ней и являюццо интелектуальной собственностью Иванова.дык в любом случае ОС -- это не система управления.
это инструмент, который позволяет разрабатывать конечную программу (алгоритм управления)
с большим комфортом и в меньшие сроки.Патчи не помогут линуксу управлять печкой.
Они могут сделать так, что он будет по другому реагировать на какие то события.
Будут другие приоритеты прерываний.И если человек продает конечное решение на базе такого модифицированного линукса (но со своей управляющей программой/демоном), то он не должен выкладывать управляющую программу.
Он должен показать модификации кода, который под GPL, что для конторы которая не занимается продажец ОСей не является критичным (так как самого "интересного" то и не видно)>Так что проблема есть и она в жадности этого инженера ;))
>В любом случае: если не хочет отдавать ноу-хау под GPL,
>или не хочет оплатить создание системы управлния с нуля, чтоб не было
>претензий к его коду.скорее в невежестве... и ИМХО не инженера а маркетоида.
потому, что люди которые что-то делают а не по форумам п№%дят, информаций и своими нароботками умеют делиться (ИМХО опять же)
>дык в любом случае ОС -- это не система управления.в примере этого товарисча про ОС никто и слова не сказал.
Была НЕКАЯ система управления. Пущай в ней хоть кластер пингвинов был. Она принималась как ОДИН GPL'd продукт.>скорее в невежестве...
ну как сказать... вот мы вот умные, а так же как и его жаба начала бы давить и о GPL чуток, ну и ессьно, про оплату разработки своего аналога.> и ИМХО не инженера а маркетоида.
бралсо некий абстрактный объект, решающий все. детали не интересовали.>потому, что люди которые что-то делают а не по форумам п№%дят, информаций
>и своими нароботками умеют делиться (ИМХО опять же)ну, пиз%еж в форуме еще не повод считать человека жлобом и рас%издяем ;)
эй! горячие парни!
давайте не отклоняться от темы.тема звучит так - микроядро отличается от монолитного ядра примерно так-же как передача данных через вызов подпрограммы от передачи данных через сокет.
еще пример - UDP против TCP.
то есть общая пропускная способность может нисколько не страдать и даже выигрывать (за счет надежности доставки или QoS), но латентность, безусловно совсем другая (особенно в момент установления соединения).Ну и вот объясните мне - что из вышеперечисленного, кроме лишнего переключения контекста действительно _существенно_ повлияет на общую производительность системы?
Да, и не забудьте учесть, что в современном железе и так латентность ухудшается (в том числе многоядерностью с отдельными кешами), а особенно дорожают кеш-промахи (да, полоса пропускания памяти и шины постоянно и неуклонно расширяется, но так же постоянно и неуклонно растет латентность)..
Если железо кого не волнует, то можно вспомнить упрощение отладки драйверов.
>Ну и вот объясните мне - что из вышеперечисленного, кроме лишнего переключения
>контекста действительно _существенно_ повлияет на общую производительность системы?ухудшают производительность только две вещи:
- "лишние" переключения контекста
- усложненная структура общения между этим контекстами
>Да, и не забудьте учесть, что в современном железе и так латентность
>ухудшается (в том числе многоядерностью с отдельными кешами), а особенно дорожают
>кеш-промахи (да, полоса пропускания памяти и шины постоянно и неуклонно расширяется,
>но так же постоянно и неуклонно растет латентность)..
>Если железо кого не волнует, то можно вспомнить упрощение отладки драйверов.Да, некритичность ошибок дров в микроядре - это его главный плюс, несомненно.
Но и с другой стороны - за все нужно платить. Сложность реализации такого ядра - немалого стоит, хотя идея столь высокой надежности и очень привлекательна...
>>Ну и вот объясните мне - что из вышеперечисленного, кроме лишнего переключения
>>контекста действительно _существенно_ повлияет на общую производительность системы?
>
>ухудшают производительность только две вещи:
>- "лишние" переключения контекста
>- усложненная структура общения между этим контекстами
>вы понимаете разницу между влияет на производительность и _существенно_ влияет?
это я к тому, что в реальной жизни никто не работает с файлом, например (сокетом, etc), прямо через системные вызовы, а обычно через какую-нить кеширующую структуру с буферами, и количество системных вызовов резко сокращается.
Хотя, конечно есть проблема криворукости программеров, но современное железо, похоже, скоро и так заставит руки ровнять..>
>>Да, и не забудьте учесть, что в современном железе и так латентность
>>ухудшается (в том числе многоядерностью с отдельными кешами), а особенно дорожают
>>кеш-промахи (да, полоса пропускания памяти и шины постоянно и неуклонно расширяется,
>>но так же постоянно и неуклонно растет латентность)..
>>Если железо кого не волнует, то можно вспомнить упрощение отладки драйверов.
>
>Да, некритичность ошибок дров в микроядре - это его главный плюс, несомненно.
>
>Но и с другой стороны - за все нужно платить. Сложность реализации
>такого ядра - немалого стоит, хотя идея столь высокой надежности и
>очень привлекательна...простая и прозрачная архитектура сложна в реализации?
Вы, извините, в какой области работаете? ато я в практической инженерной деятельности (от пайки/доводки железяк уровня спектрума и драйверов для FreeBSD и собственных мониторов для дос, до флешевых игрушек) ни разу не встречал подтверждающих примеров..
>>Ну и вот объясните мне - что из вышеперечисленного, кроме лишнего переключения
>>контекста действительно _существенно_ повлияет на общую производительность системы?
>
>ухудшают производительность только две вещи:
>- "лишние" переключения контекста
>- усложненная структура общения между этим контекстами
>
>вы понимаете разницу между влияет на производительность и _существенно_ влияет?а какая разница между "пиво" и "много пива" ? %)
>это я к тому, что в реальной жизни никто не работает с
>файлом, например (сокетом, etc), прямо через системные вызовы, а обычно через
>какую-нить кеширующую структуру с буферами, и количество системных вызовов резко сокращается.поставьте себе strace (не помню уже аналога под бздю) и посмотри на любой попавшийся под руку процесс. Будете удивлены: системные вызовы юзаются ОФИГЕННО часто. Про кеширование - думает уже ядро.
Только вот сам факт сискола для микроядра - уже намного (ну не знаю насколько... и у вас это больной вопрос ;) больше работы чем для монолита...>Хотя, конечно есть проблема криворукости программеров, но современное железо, похоже, скоро и
>так заставит руки ровнять..странная у вас логика... пока-что наблюдаеццо обратная тенденция.
Железо становитсья мощьнее - про качество кода программеры забывают...>>>Да, и не забудьте учесть, что в современном железе и так латентность
>>>ухудшается (в том числе многоядерностью с отдельными кешами), а особенно дорожают
>>>кеш-промахи (да, полоса пропускания памяти и шины постоянно и неуклонно расширяется,
>>>но так же постоянно и неуклонно растет латентность)..
>>>Если железо кого не волнует, то можно вспомнить упрощение отладки драйверов.
>>
>>Да, некритичность ошибок дров в микроядре - это его главный плюс, несомненно.
>>
>>Но и с другой стороны - за все нужно платить. Сложность реализации
>>такого ядра - немалого стоит, хотя идея столь высокой надежности и
>>очень привлекательна...
>
>простая и прозрачная архитектура сложна в реализации?у вас есть положительный опыт написания микроядер?
>Вы, извините, в какой области работаете?админ с богатым опытом программирования
>ато я в практической инженерной деятельности
>(от пайки/доводки железяк уровня спектрума и драйверов для FreeBSD и собственных
>мониторов для дос, до флешевых игрушек) ни разу не встречал подтверждающих
>примеров..ну... чтоб встретить пример легкой/тяжелой реализации микроядра - нужно как минимум попробовать, либо послушать людей, съевшЫх некое жЫвотное на этом.
Лично я сам не пробовал фдра писать, увы. Но наслышан мнением Торвальдса о переводе линуха на микроядерные рельсы. (Речь не идет о написании микроядра с нуля). Так вот он считает, что это достаточно большой труд, и, к сожалению, не очень оправданный с точки зрения потерь производительности в дальнейшем.
Ну, с потерей производительности я с ним не совсем согласен. Есть области применения, где любые потери ее - ерудна по сравнению с полученной надежностью.
В принципе, на пальцах :), микроядро сделать их линуха - раз плюнуть. Известна теория и как все должно работать. Но вот у меня большые сомнения касательно реализации этого "раз плюнуть"...
>>>Ну и вот объясните мне - что из вышеперечисленного, кроме лишнего переключения
>>>контекста действительно _существенно_ повлияет на общую производительность системы?
>>
>>ухудшают производительность только две вещи:
>>- "лишние" переключения контекста
>>- усложненная структура общения между этим контекстами
>>
>>вы понимаете разницу между влияет на производительность и _существенно_ влияет?
>
>а какая разница между "пиво" и "много пива" ? %)
>
разница в том что есть понятие "лучше чем дороже" - хорошие итальянские туфли стоят в разы дороже китайских, но служат значительно дольше, точнее раньше устаревают морально чем разваливаются (с китайцами часто наоборот).>
>>это я к тому, что в реальной жизни никто не работает с
>>файлом, например (сокетом, etc), прямо через системные вызовы, а обычно через
>>какую-нить кеширующую структуру с буферами, и количество системных вызовов резко сокращается.
>
>поставьте себе strace (не помню уже аналога под бздю) и посмотри на
>любой попавшийся под руку процесс. Будете удивлены: системные вызовы юзаются ОФИГЕННО
>часто. Про кеширование - думает уже ядро.
>Только вот сам факт сискола для микроядра - уже намного (ну не
>знаю насколько... и у вас это больной вопрос ;) больше работы
>чем для монолита...
>
>>Хотя, конечно есть проблема криворукости программеров, но современное железо, похоже, скоро и
>>так заставит руки ровнять..
>
>странная у вас логика... пока-что наблюдаеццо обратная тенденция.
>Железо становитсья мощьнее - про качество кода программеры забывают...ничего странного - сейчас _все_без_исключения_ переводится с простой (или не очень) параллельной шины на всевозможные варианты последовательных (не считая того, что растет число слоев между приложением и железом), а там - хоть с железной поддержкой хоть без - вызов намного дороже, и что характерно, последние итерации новой аппаратуры _все_без_исключения_ по крайней мере в первых реализациях хуже по латентности чем предыдущие :(
(например DDR vs DDR2)хотя предельная (пиковая) пропускная способность таки действительно растет, почти в соответствии с законом мура.
>
>>>>Да, и не забудьте учесть, что в современном железе и так латентность
>>>>ухудшается (в том числе многоядерностью с отдельными кешами), а особенно дорожают
>>>>кеш-промахи (да, полоса пропускания памяти и шины постоянно и неуклонно расширяется,
>>>>но так же постоянно и неуклонно растет латентность)..
>>>>Если железо кого не волнует, то можно вспомнить упрощение отладки драйверов.
>>>
>>>Да, некритичность ошибок дров в микроядре - это его главный плюс, несомненно.
>>>
>>>Но и с другой стороны - за все нужно платить. Сложность реализации
>>>такого ядра - немалого стоит, хотя идея столь высокой надежности и
>>>очень привлекательна...
>>
>>простая и прозрачная архитектура сложна в реализации?
>
>у вас есть положительный опыт написания микроядер?
>
движок игрушки есть нечто близкое по сложности/функциональности к микроядру, и только подход с жесточайшей формализацией простой архитектуры позволяет создать его с нуля с небольшими затратами ресурсов - то есть конкурировать с китайцами и индийцами.>
>>Вы, извините, в какой области работаете?
>
>админ с богатым опытом программирования
>
>>ато я в практической инженерной деятельности
>>(от пайки/доводки железяк уровня спектрума и драйверов для FreeBSD и собственных
>>мониторов для дос, до флешевых игрушек) ни разу не встречал подтверждающих
>>примеров..
>
>ну... чтоб встретить пример легкой/тяжелой реализации микроядра - нужно как минимум попробовать,
>либо послушать людей, съевшЫх некое жЫвотное на этом.
>Лично я сам не пробовал фдра писать, увы. Но наслышан мнением Торвальдса
>о переводе линуха на микроядерные рельсы. (Речь не идет о
>написании микроядра с нуля). Так вот он считает, что это достаточно
>большой труд, и, к сожалению, не очень оправданный с точки зрения
>потерь производительности в дальнейшем.
>Ну, с потерей производительности я с ним не совсем согласен. Есть области
>применения, где любые потери ее - ерудна по сравнению с полученной
>надежностью.
>В принципе, на пальцах :), микроядро сделать их линуха - раз плюнуть.
>Известна теория и как все должно работать. Но вот у меня
>большые сомнения касательно реализации этого "раз плюнуть"...перепахивать готовый код это конечно далеко не "раз плюнуть", а вот сделать с нуля, для нескольких вариантов широко распространенного железа (да хотя-бы даже для запуска под виртуализатором железа) - вполне реально даже для одного человека.
>разница в том что есть понятие "лучше чем дороже" - хорошие итальянские
>туфли стоят в разы дороже китайских, но служат значительно дольше, точнее
>раньше устаревают морально чем разваливаются (с китайцами часто наоборот).да, но пока что в мире не существует хороших итальянских ядер ;)
линух/бзд/венда - монолиты
hurd/QNX/minix - далеки от функционала линуха (будем спорить, что в нем больше всего функционала из существующих ядер?)так что... либо надежно, либо гибко....
и надежно и гибко - это как раз мог бы быть микро-линух такой себе...
>ничего странного - сейчас _все_без_исключения_ переводится с простой (или не очень) параллельной
>шиныпрограммисты, лабающие венду в Индии - понятия не имеют о шинах.
Давайте ближе к софту и ядрам. Для перехода на другое ядро я лично не буду сидеть с паяльником и править пропускную своей мамки.>на всевозможные варианты последовательных (не считая того, что растет число
>слоев между приложением и железом), а там - хоть с железной
>поддержкой хоть без - вызов намного дороже, и что характерно, последние
>итерации новой аппаратуры _все_без_исключения_ по крайней мере в первых реализациях хуже
>по латентности чем предыдущие :(
>(например DDR vs DDR2)
>хотя предельная (пиковая) пропускная способность таки действительно растет, почти в соответствии с
>законом мура.плз, см. предыдущий пост. Проргаммеры [юзерлевела] сейчас не очень то озабочены железом.
Оно их просто расслабляет своей скоростью. Вот и вся теория.
А задержки DDR2 - ну никоим местом не касаются обсуждения микроядра/монолита...>>у вас есть положительный опыт написания микроядер?
>>
>движок игрушки есть нечто близкое по сложности/функциональности к микроядруну, как Вы понимаете, ЛОЛ. Смеялсо. Давайте Вы скачаете линух с kernel.org, посмотрите в него чу-чуть - и поймете, что Вы тут несете...
>, и только подход
>с жесточайшей формализацией простой архитектуры позволяет создать его с нуля с
>небольшими затратами ресурсов - то есть конкурировать с китайцами и индийцами.гениально. А проектировать эту вашу архитектуру ядра кто будет, чтоб оно таким дешевым потом получилось??
>перепахивать готовый код это конечно далеко не "раз плюнуть", а вот сделать
>с нуля, для нескольких вариантов широко распространенного железа (да хотя-бы даже
>для запуска под виртуализатором железа) - вполне реально даже для одного
>человека.ОК!! давайте пробывать. Я буду писать микроядро из исходников линуха, а вы - с нуля, из головы :)
Спорю на N зелени, что дисковод у меня первого заработает ;)))) да и будет ли второго?...
Про остальные M+1 драйверов вспоминать?
>>разница в том что есть понятие "лучше чем дороже" - хорошие итальянские
>>туфли стоят в разы дороже китайских, но служат значительно дольше, точнее
>>раньше устаревают морально чем разваливаются (с китайцами часто наоборот).
>
>да, но пока что в мире не существует хороших итальянских ядер ;)
>
>линух/бзд/венда - монолиты
>hurd/QNX/minix - далеки от функционала линуха (будем спорить, что в нем больше
>всего функционала из существующих ядер?)С какой это стати винда монолит?
Начиная с NT там микроядро.
-- Dmitry
>>линух/бзд/венда - монолиты
>>hurd/QNX/minix - далеки от функционала линуха (будем спорить, что в нем больше
>>всего функционала из существующих ядер?)
>
>С какой это стати винда монолит?
>Начиная с NT там микроядро.да вы шо?? %)
а че ж она тогда так зОмечательно ходит в синий экран при мало-мальски кривом драйвере подмышки??заблуждаетесь товарисч ;))
>-- Dmitry
>>>линух/бзд/венда - монолиты
>>>hurd/QNX/minix - далеки от функционала линуха (будем спорить, что в нем больше
>>>всего функционала из существующих ядер?)
>>
>>С какой это стати винда монолит?
>>Начиная с NT там микроядро.
>
>да вы шо?? %)
>а че ж она тогда так зОмечательно ходит в синий экран при
>мало-мальски кривом драйвере подмышки??
>
>заблуждаетесь товарисч ;))Не вводите своими домыслами других людей в заблуждение, а почитайте документацию.
Вот например: http://www.microsoft.com/technet/archive/ntwrkstn/reskit/arc...
Цитата:
Working very closely with the HAL is the Microkernel, the heart of Windows NT.А почему она BSOD показывает при кривом драйвере это у MS надо спросить, так вот реализовали микроядро. Вероятно пошли в угоду эффективности в ущерб надежности.
-- Dmitry
>Не вводите своими домыслами других людей в заблуждение, а почитайте документацию.
>Вот например: http://www.microsoft.com/technet/archive/ntwrkstn/reskit/arc...
>Цитата:
>Working very closely with the HAL is the Microkernel, the heart of
>Windows NT.MS-English словарь четали? Что у них мультиплатформенность - это значит работает на любой венде...
Ни на какие мысли на наталкивает??
Все просто - вы повелись на этот кривой треп. Тут "Microkernel" у них - это просто маленький (по размеру) загрузчик драйверов. Но грузит то он все в 0 кольцо, и в свое адрессное пространство ;) ни о каких подсистема/процесс речь даже не идет.
Обычный монолит, просто загрузчик у них - это т.н. "Microkernel" %)Ну большой ведь небось дятька, раз до клавы достаешь, а веришь мягкотелым.... ;)
Вот то что они щас девелопят в поте лица - нечто именуюмое "singularity" - вот это как раз и есть микроядро. Так глянь КАК они его рахсваливают на его сайте - закачаешься как файло по сетке! Опять за тем же QNX велосипед переизобрели - и давай орать... з;%?"ебали....
>А почему она BSOD показывает при кривом драйвере это у MS надо
>спросить, так вот реализовали микроядро.нет, если микроядро - то оно УЖЕ не упадет все сразу, если какая-то часть повреждена.
В этом его суть. Если этого - нет, думаю, не стоит объяснять далее..>Вероятно пошли в угоду эффективности в ущерб надежности.
это моск бигги гейа ушел в угоду надежности %)
>>Не вводите своими домыслами других людей в заблуждение, а почитайте документацию.
>>Вот например: http://www.microsoft.com/technet/archive/ntwrkstn/reskit/arc...
>>Цитата:
>>Working very closely with the HAL is the Microkernel, the heart of
>>Windows NT.
>
>MS-English словарь четали? Что у них мультиплатформенность - это значит работает на
>любой венде...Не понял смысл это фразы. Но Windows NT прекрасно работала и на Alpha платформах и экспериментальная на PowerPC. А WindowsCE (в которой ядро от NT) работает на 4 типах процессоров (ARM, MIPS, SH3, x86).
>Ни на какие мысли на наталкивает??
>Все просто - вы повелись на этот кривой треп. Тут "Microkernel" у
>них - это просто маленький (по размеру) загрузчик драйверов. Но грузит
>то он все в 0 кольцо, и в свое адрессное пространство
>;) ни о каких подсистема/процесс речь даже не идет.
>Обычный монолит, просто загрузчик у них - это т.н. "Microkernel"
> %)
Это именно микрокернел. Или вы не знаете что это такое? Ну я объясню.The minimum set of services required in a microkernel seems to be address space management, thread management, inter-process communication, and timer management.
(это классическое определение)Так вот - в Windows NT микрокернел -
The Microkernel is a component of the core operating system that provides basic operating system functions, like thread dispatching, interrupt handling, and multiprocessor synchronization.Просто микрокернел МОЖЕТ грузить часть драйверов в кернел спейс, а может и не грузить.
The kernel alone may not contain enough services to start up the machine Thus, either additional code for startup, such as key device drivers, must be placed in the kernel, or means must be provided to load an appropriate set of service programs during the boot process. For this reason, most microkernels do place some "external" code in the kernel itself, notably key device drivers.
Ну MS погналось за скоростью и включило большую часть в кернел спейс :)
Ее можно понять в общем.Надо сказать что WinNT летала в космос и ее писала вообще не MS :)
"Фирма Майкрософт пригласила на работу группу разработчиков из формы DEC (Digital Equipment Corporation) во главе с Дэйвом Катлером с целью создания Windows NT, используя опыт DEC разработок многозадачных операционных систем VAX/VMS и RSX-11."
>
>Ну большой ведь небось дятька, раз до клавы достаешь, а веришь мягкотелым....
>;)
>
>Вот то что они щас девелопят в поте лица - нечто именуюмое
>"singularity" - вот это как раз и есть микроядро. Так глянь
>КАК они его рахсваливают на его сайте - закачаешься как файло
>по сетке! Опять за тем же QNX велосипед переизобрели - и
>давай орать... з;%?"ебали....QNX не умел микротреды делать. Сингуларити умеет. Сравнение некорректно.
>
>>А почему она BSOD показывает при кривом драйвере это у MS надо
>>спросить, так вот реализовали микроядро.
>
>нет, если микроядро - то оно УЖЕ не упадет все сразу, если
>какая-то часть повреждена.
>В этом его суть. Если этого - нет, думаю, не стоит объяснять
>далее..>
>>Вероятно пошли в угоду эффективности в ущерб надежности.
>
>это моск бигги гейа ушел в угоду надежности %)Причем здесь билли, винду пишут такие же программеры и админы какие ходят на ЛОР.
А билли ее всего лишь продает :)-- Dmitry
>Не понял смысл это фразы.Смысл просто: не понимать все написанное мягкими буквально.
>Это именно микрокернел. Или вы не знаете что это такое? Ну я
>объясню.
>
>The minimum set of services required in a microkernel seems to be
>address space management, thread management, inter-process communication, and timer management.
>(это классическое определение)>Так вот - в Windows NT микрокернел -
>The Microkernel is a component of the core operating system that provides
>basic operating system functions, like thread dispatching, interrupt handling, and multiprocessor
>synchronization.
>
>Просто микрокернел МОЖЕТ грузить часть драйверов в кернел спейс, а может и
>не грузить.агу :)
Тока вот мягкое "микроядро" НЕ может никуда кроме 0 кольца в свои 4 гига грузить дрова ;)
Разницу между "может не грузить" и "не может грузить" чуете?? ;)))
Короче, ладно, под определения микроядра их загрузчик "Microkernel" подпадает. Но ему от этого не легче, когда некто загруженный выносит систему к ху%;:?йам %)
>The kernel alone may not contain enough services to start up the
>machine Thus, either additional code for startup, such as key device
>drivers, must be placed in the kernel, or means must be
>provided to load an appropriate set of service programs during the
>boot process. For this reason, most microkernels do place some "external"
>code in the kernel itself, notably key device drivers.чудно. Т.е. если я из линуха вывалю все что только возможно в модули - то у меня останеццо микроядро %) Но линух - это монолит, хотя дровей клавы в нем тогда не будет.
Так как же это микроядро больше, чем монолит?? ;)да, и ксати, рядом с вашим определением НЕТ венды...
думаю ее бы туда фпесалибы, если бы она туда вписывалась :)
(а вот сингулярити - есть)
http://en.wikipedia.org/wiki/Microkernel#Examples
>Ну MS погналось за скоростью и включило большую часть в кернел спейс
>:)
>Ее можно понять в общем.конечно. нае;%?:;№?%ть пользователей и назваццо осью с микроядром...
>Надо сказать что WinNT летала в космос и ее писала вообще не
>MS :)...и плавала на каком-то омереканском танкере в поход... но недалеко как-то получилось... метров 500, а назад - на буксире %)
>"Фирма Майкрософт пригласила на работу группу разработчиков из формы DEC (Digital Equipment
>Corporation) во главе с Дэйвом Катлером с целью создания Windows NT,
>используя опыт DEC разработок многозадачных операционных систем VAX/VMS и RSX-11."мс купила контору, которая писала UNIX-like ядро, так шо.... кто там кого и куда попросил - еще вопрос....
>QNX не умел микротреды делать. Сингуларити умеет. Сравнение некорректно.добавили фичу и теперь сравнивать некорректно?? проснись
Короче, я понял причину нашего разногласия. Это наличие дрйверов, загружаемых микроядром и реализующим ФС, дрова, сетку...
Вобщем, понятие микроядра часто поденяют этим ядром вместе с загруженными дровами, да еще и в отдельных процессах и на разные кольца защиты проца... Это все есть в ядре QNX'а
Вот и происходит путаница.Но, как бы там ни было, никто кроме мягкотелых, не видит в венде nt микроядра ;)
А это о многом говорит.
ИМХО в мире Линукса сейчас микроядро стало бы тем раздражителем, который бы спровоцировал разработчиков на очень существенную ревизию кода.Товарищи, гляньте на kernel.org - там ядро 2.6.16.20 последнее. Стабильность работы кода можно достичь увеличением времени тестирования (только не бейте, но в этом случае про поддержку всяких современных НВидиа и АТИ можно забыть) и сокращением числа разработчиков (до фига народа считают себя "шипка умными и низаминимыми"). Чего только не включают в ядро Линукса - и всякие Блютузы, и инфракрасники. Народ, какое отношение к распределению системных ресурсов имеет Блютуз? Зато косяков с написанием драйверов - уйма. Жесткие ограничения по функционалу и размеру ядра будут способствовать тому, что всякие приблуды будут вытеснены из кольца 0, и потому никакие кривые дрова не будут рушить всю систему. Есть те, кто использует ресурсы (драйвера, прикладные проги), а есть те, кто их раздает (ядро). ИМХО уже пора строить раздельный санузел - отдельно туалет и отдельно ванну, поскольку они служат разным целям.
>ИМХО в мире Линукса сейчас микроядро стало бы тем раздражителем, который бы
>спровоцировал разработчиков на очень существенную ревизию кода.
>
>Товарищи, гляньте на kernel.org - там ядро 2.6.16.20 последнее. Стабильность работы кода
>можно достичь увеличением времени тестирования (только не бейте, но в этом
>случае про поддержку всяких современных НВидиа и АТИ можно забыть) и
>сокращением числа разработчиков (до фига народа считают себя "шипка умными и
>низаминимыми"). Чего только не включают в ядро Линукса - и всякие
>Блютузы, и инфракрасники. Народ, какое отношение к распределению системных ресурсов имеет
>Блютуз? Зато косяков с написанием драйверов - уйма. Жесткие ограничения по
>функционалу и размеру ядра будут способствовать тому, что всякие приблуды будут
>вытеснены из кольца 0, и потому никакие кривые дрова не будут
>рушить всю систему. Есть те, кто использует ресурсы (драйвера, прикладные проги),
>а есть те, кто их раздает (ядро). ИМХО уже пора строить
>раздельный санузел - отдельно туалет и отдельно ванну, поскольку они служат
>разным целям.да, такие настроения уже начинают селиццо в горячих понгвиньячих головах.
И я поддерживаю, что такая веточка пингвина была бы весьма привлекательна для определенного рода задач. И потеря произовидельности не везде важна, кое-где ;) важна и надежность...