Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 99
Неплохо! The BlackBerry PlayBook price is expected to be in the $300 – $500 range.
Помню их дискетку с QNX. Единственное что страшновато, так это рынок BlackBerry пока был на 80-90% только в США. Ну и совершенно новая платформа.
Помню их дискетку с QNX. Единственное что страшновато, так это рынок BlackBerry пока был на 80-90% только в США. Ну и совершенно новая платформа.
все как обычно упрется в детали
— магазин приложений
— комьюнити как разработчиков так и пользователей
— отзывчивость интерфейса
— время работы
а для меня еще и цена в европе. если они не пожлобятся на и выпустят его с нормальной ценой звезды могу и сойтись…
— магазин приложений
— комьюнити как разработчиков так и пользователей
— отзывчивость интерфейса
— время работы
а для меня еще и цена в европе. если они не пожлобятся на и выпустят его с нормальной ценой звезды могу и сойтись…
Магазины приложений (для преведущей ос) уже есть, как официальный (недавно стартовавший), так и куча неофициальных.
Комьюнити судя по всему находится в США (большая часть разработок делают для них).
Отзывчивость интерфейса — тут я не знаю.
Время работы — это конек BB, 5 дней смартфон с инетом, почтой и разговорами (нечастыми) держится. По слухам qnx выбрали в основном и по этому. И самое интересное — новую ось будут переносить на смартфоны и более того делают ее полность совместимой с преведущей.
Комьюнити судя по всему находится в США (большая часть разработок делают для них).
Отзывчивость интерфейса — тут я не знаю.
Время работы — это конек BB, 5 дней смартфон с инетом, почтой и разговорами (нечастыми) держится. По слухам qnx выбрали в основном и по этому. И самое интересное — новую ось будут переносить на смартфоны и более того делают ее полность совместимой с преведущей.
>Время работы — это конек BB, 5 дней смартфон с инетом, почтой и разговорами (нечастыми) держится.
Ну, не знаю, как насчёт 5 дней, но дня 3 держит точно. При том, что 2 почтовых ящика, 20-30 емейлов ежедневно, GTalk, Facebook, ежедневно башорг «и компания», немного Хабра, плюс блютус включён постоянно (часто за рулём, гарнитуру использую).
Ну, не знаю, как насчёт 5 дней, но дня 3 держит точно. При том, что 2 почтовых ящика, 20-30 емейлов ежедневно, GTalk, Facebook, ежедневно башорг «и компания», немного Хабра, плюс блютус включён постоянно (часто за рулём, гарнитуру использую).
Ну и если цену удержат в этом диапазоне, то перспективы Galaxy Tab становятся ещё туманнее.
Пока RIM доделает и выкатит продукт, Samsung успеет продать не одну сотню тысяч операторский Galaxy Tab в США.
Вот только купив QNX они тут же сильно усложнили доступ к исходным кодам.
Исходным кодам чего? Ядра? А зачем они вам?
Ядра. Вот вы бы доверили оси управлять ядерным реактором без полного аудита сырцов? Ну и хотя бы просто на посмотреть, на прикрутить какую-нибудь функциональность.
Я не страдаю паранойей, доверил бы при одном условии, что мне дадут чексумму ядра соседней электростанции.
А внутренности ядра не нужны, это все равно ничего не даст, так как приложения запускаются в защищенном адресном пространстве, все общения с ядром сводятся к использованию API.
Да и зачем разработчику апликейшинов для таблетки сырцы ядра?
А внутренности ядра не нужны, это все равно ничего не даст, так как приложения запускаются в защищенном адресном пространстве, все общения с ядром сводятся к использованию API.
Да и зачем разработчику апликейшинов для таблетки сырцы ядра?
> А внутренности ядра не нужны, это все равно ничего не даст, так как
> приложения запускаются в защищенном адресном пространстве, все
> общения с ядром сводятся к использованию API.
На сегодня чуть ли не главная вещь, для которой нужны исходники, это уверенность в том, что если в следующем году фирма-производитель разориться или будет куплена, а у Вас на руках миллионный проект на основе продукта этой фирмы, то Вы не останетесь ни с чем, на руках будут хотя бы исходники. И в крайнем случае Вы сможете нанять девелоперов и устаранить какой-нибудь вскрывшийся баг.
Я бывал в таких ситуациях, когда продукт работал и вдруг перестал, исходников нет, правда там была логическая закладка, но не суть, компании нет, исходников нет, разработчиков нет, исходников нет, продукт стоит 100 долларов, оборудование/люди на него завязанное — порядка 100 тыс.
> приложения запускаются в защищенном адресном пространстве, все
> общения с ядром сводятся к использованию API.
На сегодня чуть ли не главная вещь, для которой нужны исходники, это уверенность в том, что если в следующем году фирма-производитель разориться или будет куплена, а у Вас на руках миллионный проект на основе продукта этой фирмы, то Вы не останетесь ни с чем, на руках будут хотя бы исходники. И в крайнем случае Вы сможете нанять девелоперов и устаранить какой-нибудь вскрывшийся баг.
Я бывал в таких ситуациях, когда продукт работал и вдруг перестал, исходников нет, правда там была логическая закладка, но не суть, компании нет, исходников нет, разработчиков нет, исходников нет, продукт стоит 100 долларов, оборудование/люди на него завязанное — порядка 100 тыс.
Простому смертному исходники и не предоставят :) Сертификацией ОС ведь занимаются специальные службы.
А для «прикрутить какую-нибудь функциональность» исходники ядра совсем не нужны, достаточно API.
А для «прикрутить какую-нибудь функциональность» исходники ядра совсем не нужны, достаточно API.
Кхе… лажу говорите. QNX вбухала и вбухивает массу денег на аудит своего кода и сертификацию. Не знаю, у кого ещё есть столько сертификатов по безопасности. Почитайте их историю — весьма интересная. С самого начала они ориентировались на рынок безопасных систем. То что сырце не опен-сорс, не значет, что их не проверили.
А в чем проблема? Они открыты: www.linux.org.ru/news/opensource/2138112/page2
Остается только надеяться, что у них будет достойный вариант App Store.
Что больше всего воодушевляет лично меня — так это тот факт, что обещается поддержка нативного кода на C/C++. Плюсуя сюда факт существования Qt для QNX, получаем потенциальную возможность использовать Qt для разработки под PlayBook.
Что не может не радовать.
Что не может не радовать.
Хех, если оно действительно будет стоить в районе $300-500, то я к тебе обращусь ;) Модель без всяких 3G и прочих наворотов взял бы вместо читалки, которые неадекватно дороги.
Я думаю Qt (как QUI библиотека) будет смотреться там несколько инородно. Всё же там свои виджеты UI, своя идеология и т. д.
Qt может использовать родные для системы стили оформления
Да, будущее за системами реального времени. Вначале они переползут из встроенных устройств на планшеты и смартфоны, а потом и на десктоп.
соовершенно не понимаю, зачем они нужны на десктопе. RTOS предназначены чуть-чуть не для тех задач
Размечтались… Хотите наблюдать тормоза на десктопе? Плюс я не думаю, что в планшете она реально демонстрирует свою realtime сущность, просто она легковесная и очень живучая, вот и всё. RT на планшете не нужен.
Просто RT OS более жёстко распределяет свои ресурсы. Это сложнее реализовать, но если это уже реализованно, грех этим не пользоваться.
Тем более, когда реализация всего этого не снимает преимуществ десктопной ОС — та же QNX поддерживает вытесняющую многозадачность и индивидуальные адресные пространства.
Жестко да, но далеко не в соответствии с нуждами десктопных пользователей. Вспоминается комикс про линукс, в который добавили поддержку 4096cpu, но флеш так и тормозит при разворачивании в fullscreen.
Ну, пока что мы наблюдаем другой процесс, внедрение подсистем реального времени в ОС общего назначения. А на ширпотребе РВ нужно, пожалуй, только для звука.
Есть сведения от любителей linux-RT ядро ставить, что это на повседневные нужды не очень то положительно влияет.
Я немножко не про то. По сути для десктопа и серверов РВ нужно для подсистемы звука, чтобы не заикался, в остальных местах ядро пользовательским задачам не нужно, ну может еще мягкое РВ для видео.
Вот стандартное ядро и совершенствуется в этом направлении.
А само по себе жесткое РВ спецефическая и достаточно редко необходимая вещь.
Вот стандартное ядро и совершенствуется в этом направлении.
А само по себе жесткое РВ спецефическая и достаточно редко необходимая вещь.
Причём тут звук и РВ? Windows — ни разу не RealTime и что, где там звук заикается?
Для это приоритеты есть. Плюс сколько=либо прямые руки программиста. Реальное время нужно только там, где требуется гарантированное (причём не обязательно маленькое) время реакции на ВНЕШНЕЕ воздействие, либо генерация воздействия с жёсткими временными интервалами. И упирается всё не я ядро, а в идеологию системы — реальное время предполагает специфичный дизайн драйверов устройств и многих подсистем ОС. Достаточно одного кривого драйвера и реального времени, как ни бывало.
Звук и видео тут совершенно ни причём — там всё достигается планированием задач, приоритетами и буферами.
Для это приоритеты есть. Плюс сколько=либо прямые руки программиста. Реальное время нужно только там, где требуется гарантированное (причём не обязательно маленькое) время реакции на ВНЕШНЕЕ воздействие, либо генерация воздействия с жёсткими временными интервалами. И упирается всё не я ядро, а в идеологию системы — реальное время предполагает специфичный дизайн драйверов устройств и многих подсистем ОС. Достаточно одного кривого драйвера и реального времени, как ни бывало.
Звук и видео тут совершенно ни причём — там всё достигается планированием задач, приоритетами и буферами.
Описанное Вами Внешнее воздействие — это одна из задач, где требуется РВ. Ваше определение неполное, РВ нужно там, где нужно выделять гарантированное время какой-либо задаче.
Иногда это внешнее воздействие, иногда это процесс.
Звук, это пример процесса, где выделение ресурсов критично, потому, что ухо чуствительно к задержкам и если не успеем выделить ресурсов процессу воспроизведения звука, звук «заикнется».
Приоритетами это не решить полностью, можно только уменьшить к-во заиканий.
Звук — типичная задача РВ. Не выделили гарантированно ресурсов — сбой.
Иногда это внешнее воздействие, иногда это процесс.
Звук, это пример процесса, где выделение ресурсов критично, потому, что ухо чуствительно к задержкам и если не успеем выделить ресурсов процессу воспроизведения звука, звук «заикнется».
Приоритетами это не решить полностью, можно только уменьшить к-во заиканий.
Звук — типичная задача РВ. Не выделили гарантированно ресурсов — сбой.
ЭЭэээ… Не нужно путать хрен с морковкой — гарантированное время достигается приоритетами и структурой приложения. Это не реальное время. Реальное время — это именно гарантия времени реакции. Т.е. гарантия того, что если Вы назначили приоритеты для своей задачи( или задач), то никакой процесс ОС не сможет вам помешать.
Ещё раз — причём тут звук? Что мешает мне назначить высокий (максимальный) приоритет на обработку звука? Звук отлично буферизируется — реализовывать обработку потоковой информации через реальное время — это малость микроскопом гвозди забивать.
Ещё раз — причём тут звук? Что мешает мне назначить высокий (максимальный) приоритет на обработку звука? Звук отлично буферизируется — реализовывать обработку потоковой информации через реальное время — это малость микроскопом гвозди забивать.
> гарантированное время достигается приоритетами и структурой приложения
Именно, что в ОС общего назначения не достигается приоритетами. Кое-что мешает. Приоритеты, это просто очередь на выполнение так или иначе организованная. И еще там много условий.
Для обработки некоторых задач и в Win и в Lin есть подсистемы
Гарантировать время реакции может только бог. ОС может только гарантированно выделить задаче ресурсы (в основном время). Не уложится обработчик задачи (ответственность программиста) в выделенное время, все — сбой. Главная ответственность РВОС — гарантированно выделить это время.
Но вообще, не все так просто с гарантиями. В общем случае ОСРВ предоставляет программисту сервисы, которые позволяют организовать обработку задач в РВ. Гарантии ОСРВ не обработка задач, а гарантированное выделение ресурсов.
Для большинства же юзерских или серверных задач РВ не нужно и даже вредно.
Но, есть задачи, где РВ нужно, для этого в ОС общенго назначения есть подсистемы с элементами РВ. Линукс кстати долго вычесывал код, который мешал работе РВ подсистемы. Еще и сейчас, наверное вычесывает.
Именно, что в ОС общего назначения не достигается приоритетами. Кое-что мешает. Приоритеты, это просто очередь на выполнение так или иначе организованная. И еще там много условий.
Для обработки некоторых задач и в Win и в Lin есть подсистемы
Гарантировать время реакции может только бог. ОС может только гарантированно выделить задаче ресурсы (в основном время). Не уложится обработчик задачи (ответственность программиста) в выделенное время, все — сбой. Главная ответственность РВОС — гарантированно выделить это время.
Но вообще, не все так просто с гарантиями. В общем случае ОСРВ предоставляет программисту сервисы, которые позволяют организовать обработку задач в РВ. Гарантии ОСРВ не обработка задач, а гарантированное выделение ресурсов.
Для большинства же юзерских или серверных задач РВ не нужно и даже вредно.
Но, есть задачи, где РВ нужно, для этого в ОС общенго назначения есть подсистемы с элементами РВ. Линукс кстати долго вычесывал код, который мешал работе РВ подсистемы. Еще и сейчас, наверное вычесывает.
> Звук отлично буферизируется
Буфера помогают, но не решают. Если Вы имеете в виду, то, что можно в буфера карты напихать звука, то это только снижает временные требования к РВ, но не убирает их совсем.
Буфера помогают, но не решают. Если Вы имеете в виду, то, что можно в буфера карты напихать звука, то это только снижает временные требования к РВ, но не убирает их совсем.
Для десктопа нужно чтобы звук просто не заикался, а задержки не так важны, а для звукозаписи как раз нужно бороться с задержками любыми способами.
Так звук когда при воспроизведении заикается? Имеется в виду конечно случай, когда ресурсов компьютера хватает для обработки звука. Это значит, что ОС не смогла вовремя выделить ресурсы для обработки звука. Это и есть типичный пример, когда ОС не справилась с выделением ресурсов для обеспечения работы задачи, которая требует РВ. Звук является такой задачей, т.к. слушать заикающийся звук невозможно.
Это заикание совершенно то же самое, что и например ОС потеряет сигнал от датчика из-за того, что не сможет обеспечить своевременное выделение ресурсов там, где нужно РВ.
Это заикание совершенно то же самое, что и например ОС потеряет сигнал от датчика из-за того, что не сможет обеспечить своевременное выделение ресурсов там, где нужно РВ.
Ну пока не сообщили ни одну информацию, чем она лучше Android (тем, что заметно конечному пользователю) :D.
Ну, как минимум — более широким спектром средств для разработки и возможностью писать нативные приложения.
Учитывая открытость для Android может быть сколько угодно средства разработки (просто это приведёт к лишней фрагментации, хотя, например, есть инструменты для разработки на Ruby и JS). А писать нативные приложения (компилируемые в машинный ARM-код, а не в байт-код) можно уже очень давно в Android (например, так Firefox написан).
Ну, Вы ведь понимаете разницу между «вот вам исходники андроида, ковыряйте и пишите нативные приложения, а потом каким-то макаром интегрируйте в общий визуальный стиль» и «вот вам готовая среда для разработки — валяйте!»?
Так у Android готовая среда разработки для нативных приложений developer.android.com/sdk/ndk/index.html и уже довольно давно.
Думал будет нечто интересное, но интервью оказалась не о чем. Можно сколь угодно долго описывать насколько QNX клевая RTOS, но какой профит от этой ОС на десктопном уровне, и в особенности на устройствах, которые ориентированы на потребление контента (мультимедиа + веб)? С чем бы не справился Linux? Очевидно, прежде чем выкатить качественный конечный продукт, нужно решить уйму проблем и микроядерная ли внутри ОС — не имеет особо значения. Тот же, прости меня Господи, iPad до выхода 4.2 там и не имеет многозадачности, но продукт оказался более, чем успешен.
PlayBook безусловно интересный девайс, но мне совершенно непонятно, почему такие жесткие ограничения на существование нативных приложений? Плюс, насколько я понимаю, сам девайс еще не полностью готов, так как на выставке демонстрировался под стеклом. Да и в проморолике RIM показано что угодно и где угодно, но не на PlayBook :)
PlayBook безусловно интересный девайс, но мне совершенно непонятно, почему такие жесткие ограничения на существование нативных приложений? Плюс, насколько я понимаю, сам девайс еще не полностью готов, так как на выставке демонстрировался под стеклом. Да и в проморолике RIM показано что угодно и где угодно, но не на PlayBook :)
Сразу оговорюсь что QNX я не занимался вот уже 6 лет, но тогда 6 лет назад вывод графики в QNX раза 4-5 был скоростнее, чем в тогдашних любых линуксов. В те же лет 6 шесть назад наше НПО тесно работало с MIT в области тогда еще наработок устройст типа вот этих тэчскрин-планшетов, но у нас это были проектные наработки для переносных управляющих экранов в промышленном производстве и я помню, как мы тогда исследовали каждую систему, скурпулезно, выясняли их потенциал итд, в итоге мы выбрали как раз нейтрину для этих устройств. И не ошиблись. Я вас могу заверить на 1 ГГц этот планшетник будет литать у вас покруче чем убунту например на 2 Ггц. Это совершенно точно. Ядра просто и близко не валяются.
А лет 10 назад, я вот так как вы задавался вопросом, ну а где это чудовище может стоять? ну есть же BSD, Linux, пока не увидел кластер из 1000 машин на Газпроме. Так тогда qnx стоил где-то под штуку баксов за версию, если мне не изменяет память. Я не знаю с чем там справляется Линукс, у самого домашний Линукс есть, но то что я его бы не поставил на нефтеперерабатывающие заводы, или на такой планшет вот, там где крайне важна скорость, надежность и отказоустойчивость — это я уверен на 100%.
А лет 10 назад, я вот так как вы задавался вопросом, ну а где это чудовище может стоять? ну есть же BSD, Linux, пока не увидел кластер из 1000 машин на Газпроме. Так тогда qnx стоил где-то под штуку баксов за версию, если мне не изменяет память. Я не знаю с чем там справляется Линукс, у самого домашний Линукс есть, но то что я его бы не поставил на нефтеперерабатывающие заводы, или на такой планшет вот, там где крайне важна скорость, надежность и отказоустойчивость — это я уверен на 100%.
>> но тогда 6 лет назад вывод графики в QNX раза 4-5 был скоростнее, чем в тогдашних любых линуксов
Надеюсь, речь идет не о QNX4? :)
PS. Сравнивать планшет с НПЗ это конечно сильно ))
Надеюсь, речь идет не о QNX4? :)
PS. Сравнивать планшет с НПЗ это конечно сильно ))
Ну вы сравнили RTOS и настольный дистрибутив Linux. На наших Wimax SoC раньше крутилась RTOS VxWorks, теперь же, ради удешевления заменили на eCos (embedded Linux), и производительность лишь возросла ;)
Планшет — это не нефтеперерабатывающий завод, и там совершенно не важна ультремодная многозадачность и микроядерность ядра ОС. Плюс вы говорите об ускоренном выводе графики (опять же, 2D, 3D или просто во фреймбуфер)? А теперь представьте какой оверхед добавит Adobe Air, и куда в итоге денется данное преимущество планшета? ;) Я не говорю, что QNX плох, я говорю, что не пойму его преимуществ на данном продукте.
Планшет — это не нефтеперерабатывающий завод, и там совершенно не важна ультремодная многозадачность и микроядерность ядра ОС. Плюс вы говорите об ускоренном выводе графики (опять же, 2D, 3D или просто во фреймбуфер)? А теперь представьте какой оверхед добавит Adobe Air, и куда в итоге денется данное преимущество планшета? ;) Я не говорю, что QNX плох, я говорю, что не пойму его преимуществ на данном продукте.
Послушайте, я не буду с вами спорость про то, у вас с VxWorks якобы возросла производительность, но то что у вас никакая производительность не возрастет от перехода с QNX на RT Linux, это не раз обсуждалось на множественных конференциях, на которых мне удалось побывать. Если мы говорим про QNX сейчас.
Очевидно, что планшет не нефтеперерабатывающий завод, и тем более не атомная электростанция, он еще много чего не, с чем я не сравнивал. Я понятия не имею какой оверхед добавит adobe air, поскольку я не вкурсе как именно adobe его реализует на qnx. Вот как Java реализовали для QNX я помню, и могу рассказать, что компания sun как разработчик просто обосралось, поскольку даже не имела понятия как реализовывать java для нейтрины, но спас положение ibm. Да так, что мир увидел проект eclipse.
Еще раз ставить Linux на планшет — это утопия, поскольку планшет а)может иметь расширеный диапозон температур, т.е. теоретически можете вынести из холодной среды в теплую итд, Linux однозначно будет вываливатся б)ставить однозначно более надежную и скоростную среду, на такой проц однозначно лучше чем другую менее надежную. Это мое мнение.
Очевидно, что планшет не нефтеперерабатывающий завод, и тем более не атомная электростанция, он еще много чего не, с чем я не сравнивал. Я понятия не имею какой оверхед добавит adobe air, поскольку я не вкурсе как именно adobe его реализует на qnx. Вот как Java реализовали для QNX я помню, и могу рассказать, что компания sun как разработчик просто обосралось, поскольку даже не имела понятия как реализовывать java для нейтрины, но спас положение ibm. Да так, что мир увидел проект eclipse.
Еще раз ставить Linux на планшет — это утопия, поскольку планшет а)может иметь расширеный диапозон температур, т.е. теоретически можете вынести из холодной среды в теплую итд, Linux однозначно будет вываливатся б)ставить однозначно более надежную и скоростную среду, на такой проц однозначно лучше чем другую менее надежную. Это мое мнение.
Вы говорите правильные вещи, но уводите разговор совершенно в другое русло :)
Миллионые продажи смартфонов на Android и их производители в корне не согласны с этим утверждением ;) Я уж не говорю про iOS, который внутри xnu, гораздо более совершенен, чем Linux. Если бы от RTOS на смартфонах/планшетах был какой-либо заметный толк, она бы там давно уже обносновалась, и цена — отнюдь не ключевая роль.
А по поводу eCos vs vxWorks, просто последний для наших задач подходил куда лучше. Я уж не говорю о том, с какими глючными драйверами от WindRiver пришлось столкнутся.
Еще раз ставить Linux на планшет — это утопия, поскольку планшет а)может иметь расширеный диапозон температур, т.е. теоретически можете вынести из холодной среды в теплую итд, Linux однозначно будет вываливатся б)ставить однозначно более надежную и скоростную среду, на такой проц однозначно лучше чем другую менее надежную. Это мое мнение.
Миллионые продажи смартфонов на Android и их производители в корне не согласны с этим утверждением ;) Я уж не говорю про iOS, который внутри xnu, гораздо более совершенен, чем Linux. Если бы от RTOS на смартфонах/планшетах был какой-либо заметный толк, она бы там давно уже обносновалась, и цена — отнюдь не ключевая роль.
А по поводу eCos vs vxWorks, просто последний для наших задач подходил куда лучше. Я уж не говорю о том, с какими глючными драйверами от WindRiver пришлось столкнутся.
Как один из миллионных продаж на android я не буду здесь скрывать своего разочарования а)тормозами системы на 1Ггц, б)разочарование от энергопотребления системы, о чем свидетельствует и разряд за 1 день и повышенное тепловыделение в)стабильные зависы примерно 1 раз в 1-1.5 месяца. Это вот практика использования этого самого андроида, те у кого есть смартфоны на андроиде, легко могут подтвердить мои слова, ведь так? Кстати, спросить хочу
а)у вас есть android?
б)вы работали с qnx хоть раз и сколько?
а)у вас есть android?
б)вы работали с qnx хоть раз и сколько?
У меня есть Android (HTC Desire). Я работал с QNX на десктопе любопытства ради. То, что вы описали — проблема производителей, а отнюдь не системы и тем более не ядра ОС. Вчера установил на свой Desire MIUI ROM, и вы не представляете, но на Android также возможна полноценная и гладкая кинетическая прокрутка, плавность интерфейса.
О времени работы — это целиком и полностью вина:
— Производителей железа: так как жрет миливатты Qualcomm'вский baseband ни жрет никто :)
— Многозадачности с десятками фоновых процессов, пуш-месседжей и разнообразных нотификейшинов.
О времени работы — это целиком и полностью вина:
— Производителей железа: так как жрет миливатты Qualcomm'вский baseband ни жрет никто :)
— Многозадачности с десятками фоновых процессов, пуш-месседжей и разнообразных нотификейшинов.
Умеляют люди, которые говорят, что Линукс (да наверное и любая ОС) будет от перепада температур падать… ;)
ЗЫЖ интересно, как корректно можно ответить на такой комментарий :)
ЗЫЖ интересно, как корректно можно ответить на такой комментарий :)
Умиляют люди, не тестировавшие линукс при -10. С каких пор Линукс стал реентерабельным? )) давно не наслаждались отваленым звуком во флэше? Что происходит значительно чаще, чем например заваленый и не поднятый видео. Только не надо мне сейчас андроид приводить в пример, там аппаратура эту надежность обеспечивает.
Не обижайтесь, но вы бред говорите. Линуксу всеравно при какой температуре работать. Если у вас аккум сдохнет при -10, что QNX поможет? Если механика примерзнет, QNX ее отогреет? Допуски по температуре даются на железо, а не на ОСь.
Совершенно верно, отказ какой-либо части в QNX не так критично как это в Linux, и не влияет на общую работоспособность системы, это обусловлено многими вещами, но главное — это архитектура.
Это все замечательно, но в потребительском устройстве не так важна надежность, как функциональность и сопутствующая инфраструктура. Вы пытаетесь доказать нужность QNX в секторе потребительского HW, но при этом приводите аргументы, которые важны для промышленного hw.
Ну и откажет у тебя какая нить часть оси, и что будем пялится в экран с красивой переливающейся ошибкой вместо голого kernel panic'а? Без полноценно работающих подсистем работать всё равно не возможно.
Ну если тебя парит это, то «пялься». Че ты мне предъявляешь? Аргументируй что реентирабельная и отказоустойчивая система хуже менее надежной.
Я лишь говорю, что при аппаратных сбоях она точно также становится бесполезной. Единственное отличие в том, что монолитная ось упадет в панику, а микроядерная ещё что-то сделать сможет. Но для конечного юзера и так и сяк устройство теряет работоспособность целиком.
Ну это смотря что откажет. Если 3D-акселератор — это одно. Если же сетевой модуль — то я бы предпочёл, чтобы девайс остался работоспособным (пусть и без сети), а не свалился с кернел паником.
Как показывает практика, Линукс вполне себе переваривает отказ сетевого модуля и не падает в панику.
Зато он быстрее работает, чем микроядерные оси, у которых имеется оверхед на переключения контекста.
Вообще микроядра скорее от сбоев в драйверах спасают, которые в пространстве пользователя висят, но часто ли вы видели kernel panic в гуглофонах, серверах, десктопах?
Зато он быстрее работает, чем микроядерные оси, у которых имеется оверхед на переключения контекста.
Вообще микроядра скорее от сбоев в драйверах спасают, которые в пространстве пользователя висят, но часто ли вы видели kernel panic в гуглофонах, серверах, десктопах?
>Зато он быстрее работает, чем микроядерные оси, у которых имеется оверхед на переключения контекста.
Это в теории.
Где-то в комментах кто-то упоминал о том, как летал QNX на десктопе по сравнению с Линуксом, поэтому у меня некоторые сомнения по поводу Вашего утверждения.
Да, я также видел комментарий о том, что у кого-то при замене VxWorks на Линукс всё стало работать быстрее — но извините, RTOS RTOSу рознь, и экстраполировать тормоза отдельно взятой VxWorks на все RTOS в целом было бы неправильно, как мне кажется. Особенно с учётом того, что я с этой самой VxWorks в своё время ковырялся :)
Это в теории.
Где-то в комментах кто-то упоминал о том, как летал QNX на десктопе по сравнению с Линуксом, поэтому у меня некоторые сомнения по поводу Вашего утверждения.
Да, я также видел комментарий о том, что у кого-то при замене VxWorks на Линукс всё стало работать быстрее — но извините, RTOS RTOSу рознь, и экстраполировать тормоза отдельно взятой VxWorks на все RTOS в целом было бы неправильно, как мне кажется. Особенно с учётом того, что я с этой самой VxWorks в своё время ковырялся :)
>Где-то в комментах кто-то упоминал о том, как летал QNX на десктопе по сравнению с Линуксом, поэтому у меня некоторые сомнения по поводу Вашего утверждения.
Ну так это проблема X11, проблема всяких там Питонов, тяжелых тулкитов и т.д. Уверяю вас, QNX с Adobe AIR на борту тоже не будет летать там где летала QNX с Photon'ом. Более того, я осмелюсь утверждать, что если на QNX запустить X11, то они будут работать медленнее, чем в Linux'е
Ну так это проблема X11, проблема всяких там Питонов, тяжелых тулкитов и т.д. Уверяю вас, QNX с Adobe AIR на борту тоже не будет летать там где летала QNX с Photon'ом. Более того, я осмелюсь утверждать, что если на QNX запустить X11, то они будут работать медленнее, чем в Linux'е
>Уверяю вас, QNX с Adobe AIR на борту тоже не будет летать там где летала QNX с Photon'ом.
Вот только сравнивать QNX+AIR мы будем не с QNX+Photon, а с Linux+Davlik, и «кто кого сборет», я пока прогнозировать не берусь.
К тому же основной гуй, я так понимаю, в плейбуке будет не на AIR, а нативный, а на AIR только сами приложения.
Вот только сравнивать QNX+AIR мы будем не с QNX+Photon, а с Linux+Davlik, и «кто кого сборет», я пока прогнозировать не берусь.
К тому же основной гуй, я так понимаю, в плейбуке будет не на AIR, а нативный, а на AIR только сами приложения.
Ну и отлично, когда потеряешь кроме данных еще и время и бабло, или ты тоже не сможешь представить такой ситуации? То тогда может и поймешь о чем я.
Если ломается дисковая подсистема, то данные и так и так теряются. Затраты времени на полный ребут немногим больше, чем на ребут части драйверов.
Танненбаум таки проиграл в споре с Линусом. Вот где нынче Minix3 и где нынче Linux? Да и вообще мне больше нравится идея Singularity, заключающаяся в полном отказе от аппаратных колец защиты и за счет того, что всё будет просчитано и проверено на этапе компиляции.
Танненбаум таки проиграл в споре с Линусом. Вот где нынче Minix3 и где нынче Linux? Да и вообще мне больше нравится идея Singularity, заключающаяся в полном отказе от аппаратных колец защиты и за счет того, что всё будет просчитано и проверено на этапе компиляции.
Пошла жара. ) Так я не понял, это Minix был основан на Linux или наоборот? Или может Minix не задумывался как изначально только для обучающих целях? На каком рынке Minix хоть должен был вытеснить? На учебном? Так он и вытеснил его, вводный курс по операционным системах вот уже 20 лет не менялся — изучают архитектуру ОС на примере minix.
Где нынче minix — ты спрашиваешь? А я спрошу лучше, а где нынче Linux нет и почему там Linux нет, может быть тогда какой-то конструктив появится от тебя.
Где нынче minix — ты спрашиваешь? А я спрошу лучше, а где нынче Linux нет и почему там Linux нет, может быть тогда какой-то конструктив появится от тебя.
извините, а что, именно линукс сильно чувствителен к температурам?
при низких и высоких температурах могут частично отказывать составные части компонент и устройств, линукс крайне плохо работает в подобных ситуациях.
Что именно в Линуксе будет крайне плохо работать? Вы сейчас пытаетесь плюсы микроядерности сюда впихнуть, но они неуместны. Да, микроядерная архитектура помогает быстро систему восстанавливать, в определенных условиях. Но это не отказ устройства. Если у вас был неудачный опыт работы с линукс на таких системах, это скорее всего проблема, либо драйверов, либо конкретной реализации.
Вы что думаете, в qnx нет плохих реализаций драйверов, которые не виснут? Просто при зависании в qnx они не останавливают систему, как зачастую происходит в linux, это не только заслуга микроадра, но и общее качество представленной для инженера системной изолированности.
ОК, давайте посмотрим на проблему с этой стороны:
— Планшет на Linux (Android/WebOS/MeeGo etc.) с большим количеством софта.
— Планшет на QNX с небольшим количеством софта, да и еще на прослойке Adobe Air.
И пользователи этих планшетов при температуре -20 оказались на улице. При этом планшет на Linux перезагрузился, а на QNX продолжает работать.
Так вот, с потребительской точки зрения, что важнее, работа в экстремальных ситуациях и истинная многозадачность в реальном времени, или сопутствующая инфраструктура и количество софта и игр? Сомневаюсь, что для большинства потребителей первый фактор будет сколь угодно значительным. Технологичность и абсолютно отказоустойчивость девайса абсолютно меркнут, если потребительские качества устройства не на высоте.
Пока что RIM показа технологичность и лишь небольшое превью потребительских качеств будущей ОС. Посмотрим, что из этого выйдет.
— Планшет на Linux (Android/WebOS/MeeGo etc.) с большим количеством софта.
— Планшет на QNX с небольшим количеством софта, да и еще на прослойке Adobe Air.
И пользователи этих планшетов при температуре -20 оказались на улице. При этом планшет на Linux перезагрузился, а на QNX продолжает работать.
Так вот, с потребительской точки зрения, что важнее, работа в экстремальных ситуациях и истинная многозадачность в реальном времени, или сопутствующая инфраструктура и количество софта и игр? Сомневаюсь, что для большинства потребителей первый фактор будет сколь угодно значительным. Технологичность и абсолютно отказоустойчивость девайса абсолютно меркнут, если потребительские качества устройства не на высоте.
Пока что RIM показа технологичность и лишь небольшое превью потребительских качеств будущей ОС. Посмотрим, что из этого выйдет.
Я честно говоря не знаю что вам ответить, вы задали каку-то задачку неберучку, которую я не до конца понял. Но вот если будут оба устройства за одинаковую цену например, я бы советовал брать тот что с БОЛЕЕ НАДЕЖНОЙ системой внутри
>При этом планшет на Linux перезагрузился, а на QNX продолжает работать.
Повторюсь. Если например из за холода отказал 3D ускоритель, то какой смысл продолжать работу, даже если ось из строя не вышла?
Повторюсь. Если например из за холода отказал 3D ускоритель, то какой смысл продолжать работу, даже если ось из строя не вышла?
> там где крайне важна скорость, надежность и отказоустойчивость — это я уверен на 100%.
ИМХО, в критичных областях, по надежности ОС должна отвечать высоким но не слишком требованиям. Надежность же опасной системы в целом должна достигаться совсем другими путями. Как бы так выразится, наверно архитектурно-аппаратными. Т.е. если у нас есть котел, который может взорваться, и контроллер на компе с ОС, который этим котлом управляет, то надежность системы д приемлемой не поднимешь, повышая вероятность отказа скажем с 0.0001 до 0.00001. Нужно вводить дублирование/троирование ну и другие архитектурные решения.
ИМХО, в критичных областях, по надежности ОС должна отвечать высоким но не слишком требованиям. Надежность же опасной системы в целом должна достигаться совсем другими путями. Как бы так выразится, наверно архитектурно-аппаратными. Т.е. если у нас есть котел, который может взорваться, и контроллер на компе с ОС, который этим котлом управляет, то надежность системы д приемлемой не поднимешь, повышая вероятность отказа скажем с 0.0001 до 0.00001. Нужно вводить дублирование/троирование ну и другие архитектурные решения.
мертворожденный проект.
С QNX игрался еще в универе (ибо специальность была системы реального времени). Она поразила меня совершенно нереальным набором API для межпроцессного взаимодействия, шедулинга процессов и потоков и т.п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интервью с основателем QNX Software Systems, посвящённое выходу BlackBerry Tablet OS