Windows CE по сравнению со встроенным [закрытым] Linux
Просто добавьте следующие ответы:
Если вы не переопределяете Equals, то по умолчанию используется сравнение ссылок объектов. То же самое относится к hashcode - приведение по умолчанию обычно основано на адресе памяти ссылки. Поскольку вы переопределили Equals, это означает, что правильное поведение заключается в сравнении того, что вы внедрили в Equals, а не в ссылках, поэтому вы должны сделать то же самое для hashcode.
Клиенты вашего класса ожидают, что хэш-код будет иметь схожую логику с методом equals, например, методы linq, которые используют IEqualityComparer, сначала сравнивают хэш-коды и только если они равны, они будут сравнивать Equals ( ), который может быть более дорогим для запуска, если бы мы не реализовали hashcode, у равного объекта, вероятно, будут разные хэш-коды (потому что они имеют другой адрес памяти) и будут ошибочно определены как не равные (Equals () даже не попадут ).
Кроме того, кроме проблемы, что вы не сможете найти свой объект, если вы использовали его в словаре (потому что он был вставлен одним хэш-кодом, и когда вы его ищете, хэш-код по умолчанию будет вероятно, будет отличаться, и снова Equals () даже не будет вызван, как объясняет Марк Гравелл в своем ответе, вы также вводите нарушение концепции словаря или хешета, которая не должна допускать идентичные ключи - вы уже заявили, что эти объекты по существу то же самое, когда вы переопределяете Equa поэтому вы не хотите, чтобы оба они были разными ключами в структуре данных, которые предполагают наличие уникального ключа. Но поскольку у них есть другой хэш-код, «тот же» ключ будет вставлен как другой.
6 ответов
Я работал в течение нескольких лет в компании, которая обеспечила и CE и Linux для всех их аппаратных средств, таким образом, я довольно знаком с обеими сторонами этого уравнения.
- Инструменты: инструменты Windows CE, конечно, лучше, чем обеспеченные Linux, хотя инструменты Linux являются, конечно, улучшением.
- Производительность: Windows CE в реальном времени. Linux не. Ядро Linux не разработано для детерминизма вообще. Существуют расширения, которые можно добавить для получения вида - реального времени, но CE бьет его.
- Стоимость: Это - область большого недоразумения. Мой общий опыт состоит в том, что CE является более низкой ценой из поля ($1 тысяча для Platform Builder и всего 3$ для каждого устройства для поставлющегося времени выполнения. "Что?" Вы спрашиваете? "Linux является бесплатным". Ну, не действительно так, особенно на встроенной арене. Да, существуют бесплатные распространения как Debian. Но существует много частей, в которых Вы, возможно, нуждались бы, которые не находятся в той бесплатной категории. Платформы UI как QT, Среды выполнения Java и кодеки медиа так же, как запуск. Кроме того, большинство дистрибутивов Linux с коммерчески поддержанной системой поддержки (например, MontaVista) совсем не свободно.
- Исходная Доступность: сторонники Linux хотели бы говорить, что CE является плохим выбором из-за отсутствия исходного кода. Все, что я могу сказать, - то, что более чем за десятилетие работы с CE, половина которого потраченный на выполнение пользовательского ядра и драйвера работает на пользовательские платы, у меня только когда-либо была потребность в источнике, который не поставлялся с CE (они поставляют подавляющее большинство его), однажды. Мне нравится иметь источник также, но Microsoft оказывает поддержку, таким образом, в редком случае Вы могли бы думать, что Вам нужен тот источник, можно заставить их решать проблему (одно время, нам был нужен источник, Microsoft обеспечила фиксацию, и бесплатно - который является их моделью под CE.
это означает, что CE побеждает каждый раз? Нет. Я не предложил бы это вообще. Если бы Вы - магазин Linux, и Вы имеете большой опыт Linux и кодируете активы, Вы были бы глупы выбежать и пойти CE. Однако при входе в него с нуля, CE обычно имеет более низкий TCO. Разработчики с опытом Win32/C# являются более распространенными и следовательно менее дорогими. Вы также добираетесь намного больше "в поле" с CE, чем большинство других дистрибутивов, имея в виду более быстрое время выхода на рынок, если у Вас уже уже нет этих вещей сделанными внутренний.
Я работал в проектах, которые включили настройку программного обеспечения платы OEM, и я не скажу, что Linux является более дешевым. При покупке платы также необходимо купить SDK. Все еще необходимо заплатить даже за версию Linux. Некоторые производители предлагают и Windows CE и решения Linux для их плат и нет разницы в цене. Для Windows CE Вам также нужны Platform Builder и плата за лицензии, но легче обойтись без помощи поддержки.
Другая важная проблема - то, при создании Пользовательского интерфейса или бездисплейного устройства. Для устройств, которые требуют, жидкокристаллический экран и человеческое взаимодействие намного легче пойти с Windows CE. С другой стороны, при создании бездисплейного устройства Linux может быть более надежной опцией - особенно, если сетевые протоколы включены. Я полагаю, что реализации Linux более надежны и легче настроить.
частично специализированной ОС
намного легче достигнуть, если ОС является открытым исходным кодом (и у Вас есть экспертные знания).
Я буду говорить за сторону Linux, по крайней мере, для категории программного обеспечения, я знаком с (который является оборудованием сбора данных РФ). Или промышленные приложения по сравнению с пользовательскими приложениями.
Windows CE (и его связанные инструменты) IMH довольно недавний E) сильно смещается к созданию "Windows Experience" на маленьком экране. Режим ввода данных пользователем подчеркивает мышеподобные действия. Входы в систему, выбор приложения, и т.д. вся попытка быть максимально подобным стандартному Windows.
, Если пользователь управляет погрузчиком или заполняет корзину выбора или движущийся материал от одного места до другого, существует проблема.
И это - движущаяся цель - особенно на стороне.NET. Компактное время выполнения.NET является и важными библиотеками с серьезными физическими недостатками (как сети, обработка данных и UI) являются неполными, и версии слишком часто удерживают от использования предыдущую версию.. CE, кажется, пасынок в семье Windows (возможно, потому что нет большого количества активной конкуренции, продающей аппаратным интеграторам.)
А хорошая стабильная консоль Linux строк-и-столбцов является довольно удобным контекстом для многих (по моему опыту, большинство) приложения высокого использования на привлекательном экране.
Не много пользы для игр на Вашем сотовом телефоне или Zune, все же.
ПРИМЕЧАНИЕ:
я думаю, что ctacke, вероятно, говорит точно за аппаратную сторону интегратора. Я больше выровненный плееров далее вниз канал - интеграторы программного обеспечения и пользователи.
Я разработал сетевые драйверы, которые работают как в RT Linux (точнее, в вытесняющем ядре Linux с исправлением RT), так и в Windows CE. По моему опыту, Windows CE была более стабильной с точки зрения отклика в реальном времени. Время кадра также показало, что у Windows CE было меньше джиттера.
В RT Linux у нас были самые разные проблемы. Например, когда пользователь перемещал мышь; наши кадры задерживались. Угадайте что, некоторые варианты x-windows отключают прерывания. Вы также можете чувствовать себя безопаснее только на экране консоли. Если у вас включены буферы кадров VGA, вы снова обречены. У нас снова была только одна проблема с Windows CE с точки зрения джиттера. Проблема возникла, когда USB-контроллер был установлен в неправильный режим в BIOS и Windows CE использовала много времени для опроса.
Если честно, Windows CE имела больше поддержки. В Linux вы сами по себе. Вы должны прочитать все возможные списки рассылки, чтобы понять, с какими проблемами вы можете столкнуться.
Выбор часто делается в основном на восприятии и культуре, а не на конкретных данных. И сделать выбор на основе конкретных данных сложно, если учесть сложность современной ОС, все проблемы, связанные с ее переносом на специализированное оборудование, и неизвестные будущие требования. Даже с точки зрения приложения все меняется в течение жизни проекта. Требования приходят и уходят. Вы обнаруживаете, что делаете то, о чем никогда не думали, особенно если это возможно. Вездесущие USB и сетевые порты открывают множество возможностей - например, добавление поддержки сотового модема или поддержки принтера. Флэш-память делает обновление программного обеспечения на месте стандартным режимом работы. И, в конце концов, у каждого решения есть свои сильные и слабые стороны - не существует волшебной пули, которая была бы лучшей во всех случаях.
При рассмотрении разработки встраиваемого Linux я часто использую аналогию с айсбергом; входя в проект, вы видите часть над водой. Это элементы, с которыми взаимодействует ваше приложение, драйверы, которые вам нужно настроить, часть, которую вы понимаете. Остальные 90% находятся под водой, и в этом заключается большая изменчивость. Проблемы с качеством драйверов или невозможность найти драйвер для чего-то, что вы, возможно, захотите поддерживать в будущем, могут легко затормозить известные части проекта. Очень мало людей, которые имеют большой опыт работы с решениями WinCE и Linux, отсюда и тенденция выбирать то, что удобно (или то, с чем удобно руководителям), или то, с чем мы имеем опыт. Ниже приведены мысли по ряду аспектов, которые следует учитывать:
РАЗРАБОТКА СИСТЕМНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Вопросы в этой области включают поддержку ЦП, качество драйверов, обновления программного обеспечения на местах, поддержка файловых систем, доступность драйверов и т. д. Одно из изменений, произошедших за последние два года, заключается в том, что поставщики процессоров теперь переносят Linux на свои новые чипы в качестве первой ОС. Раньше перенос ОС обычно производился компаниями-разработчиками программного обеспечения Linux, такими как MontaVista, или усилиями сообщества. В результате ядро Linux теперь поддерживает большинство основных встроенных процессоров с несколькими дополнительными исправлениями. Это кардинально отличается от ситуации 5 лет назад. Поскольку многие люди используют один и тот же исходный код, проблемы решаются и часто возвращаются обратно в основной источник. В WinCE поддержка BSP / драйверов, как правило, является скорее эталонной реализацией, а затем OEM / пользователи принимают ее, исправляют любые проблемы, и именно там исправления, как правило, остаются.
С системной точки зрения, очень важно учитывать гибкость для будущих потребностей. То, что это не является требованием сейчас, не означает, что оно не будет требованием в будущем. Получить поддержку драйверов для периферийного устройства может быть почти невозможно или потребуются слишком большие усилия, чтобы сделать это практичным.
Большинство людей очень мало думают о системе сборки или никогда не выходят далеко за рамки мысли о том, что «если есть хороший gui, обернутый вокруг инструмента, это должно быть легко ". OpenEmbedded - очень популярный способ создания встраиваемых продуктов Linux, который недавно был одобрен в качестве технологической базы продукта Linux 6 компании MontaVista и, как правило, считается «трудным в использовании» новыми пользователями. Хотя инструменты сборки WinCE на первый взгляд выглядят проще (10% над водой), у вас все еще есть проблема, что происходит, когда мне нужно что-то настроить, реализовывать сложные функции, такие как обновления программного обеспечения и т. д. Для создания производственной системы с функциями производственного уровня вам по-прежнему нужен кто-то в вашей команде, который разбирается в ОС и может работать на уровне детализации как операционной системы, так и системы сборки. При использовании WinCE или Embedded Linux это обычно означает, что компаниям необходимо либо иметь опытных разработчиков, либо нанимать экспертов для выполнения отдельных частей разработки системного программного обеспечения. Разработка системного программного обеспечения - это не то же самое, что разработка приложений, и, как правило, это не то, чем вы хотите заниматься без опыта, если у вас нет много времени. Компании довольно часто нанимают экспертов для первых двух проектов, а затем выполняют последующие проекты собственными силами. Еще одна особенность, которую следует учитывать, - это поддержка параллельной сборки. Четырехъядерные рабочие станции становятся стандартом, Разве большая проблема в том, что полную сборку можно сделать за 1,2 часа вместо 8? Насколько гибкой является система сборки для извлечения и сборки исходного кода из различных источников, таких как различные системы контроля версий и т. Д.
Встроенные процессоры становятся все более сложными. Просто иметь работающий процессор уже недостаточно. Если вы рассматриваете семейство процессоров OMAP3 от TI, то вы должны задать следующие вопросы: существуют ли библиотеки для движка 3D-ускорения, и могу ли я получить их, не вкладывая миллионы единиц в год? Есть ли поддержка моста DSP? Какова стоимость всего этого? В недавнем проекте, в котором я принимал участие, базовый WinCE BSP для Atmel AT91SAM9260 стоил 7000 долларов. С точки зрения времени разработчика, это немного, но вы также должны учитывать текущие расходы на обслуживание, обновление до новых версий операционной системы и т. д.
РАЗРАБОТКА ПРИЛОЖЕНИЙ
И Embedded Linux, и WinCE поддерживают ряд прикладных библиотек и языков программирования. C и C ++ хорошо поддерживаются. Большинство бизнес-приложений в мире WinCE переходят на C #. В Linux есть Mono, который обеспечивает обширную поддержку технологий .NET и очень хорошо работает во встроенных системах Linux. Для Embedded Linux доступно множество сред разработки Java. Одна из областей, где вы действительно сталкиваетесь с различиями, - это графические библиотеки. Как правило, графические API-интерфейсы Microsoft не очень хорошо поддерживаются в Linux, поэтому, если у вас есть большая команда разработчиков, состоящая из убежденных программистов графического интерфейса Windows, то, возможно, WinCE имеет смысл. Однако существует множество вариантов наборов инструментов графического интерфейса, которые работают как на ПК с Windows, так и на устройствах со встроенной Linux. Некоторые примеры включают GTK +, Qt, wxWidgets и т. Д. Gimp - это пример приложения GTK +, которое работает в Windows, плюс есть много других. Это привязки C # к GTK + и Qt. Еще одна особенность, которая, кажется, набирает обороты в пространстве WinCE, - это Windows Communication Foundation (WCF). Но опять же, есть проекты по переносу WCF в Mono, в зависимости от того, какие части вам нужны. Встроенная поддержка Linux для языков сценариев, таких как Python, очень хороша, а Python очень хорошо работает на процессорах ARM с тактовой частотой 200 МГц.
Часто бытует мнение, что WinCE работает в реальном времени, а Linux - нет. Поддержка реального времени Linux приличная в стандартных ядрах с опцией PREEMPT, а поддержка реального времени превосходна с добавлением относительно небольшого патча реального времени. В Linux вы можете легко добиться отсчета времени менее миллисекунды. Это то, что изменилось за последние пару лет с объединением функций реального времени со стандартным ядром.
ПОТОК РАЗРАБОТКИ
В производственной среде большинство передовых встроенных приложений разрабатываются и отлаживаются на ПК, а не целевое оборудование. Даже в тех случаях, когда удаленная отладка в целевой системе работает хорошо, отладка приложения на рабочей станции работает лучше. Так что тот факт, что одно решение имеет хорошую отладку на цели, а другое нет, на самом деле не имеет значения. Для систем, ориентированных на данные, обычно используются режимы моделирования, в которых приложение может быть протестировано без подключения к реальным устройствам ввода-вывода. Как для приложений Linux, так и для WinCE, программирование приложений для встраиваемого устройства аналогично программированию для ПК. Встроенный Linux делает еще один шаг вперед. Поскольку технология встроенного Linux аналогична технологии настольного компьютера и серверного Linux, почти все, что разработано для настольного компьютера / сервера (включая системное программное обеспечение), доступно для встраивания бесплатно. Это означает очень полную поддержку драйверов (см. Примеры USB-модема и принтера выше), надежную поддержку файловой системы, управление памятью и т. Д. Широта возможностей для Linux поразительна, но некоторые могут посчитать это отрицательным моментом и предпочли бы более интегрированное решение, такое как Windows CE, где все находится в одном месте. Присутствует потеря гибкости, но в некоторых случаях компромисс того стоит. Пример количества пакетов, которые могут быть созданы для систем Embedded Linux с использованием Openembedded, см. В
ТЕНДЕНЦИИ GUI
Важно учитывать тенденции для встроенных устройств с небольшими дисплеями, управляемых сотовыми телефонами (iPhone, Palm Pre и т. Д.). Стандартные виджеты графического интерфейса пользователя, которые распространены в настольных системах (диалоговые окна, флажки, раскрывающиеся списки и т. Д.), Не подходят для современных встроенных систем. Таким образом, будет важно рассмотреть возможность поддержки 3D-эффектов и библиотек виджетов, предназначенных для использования на устройствах с сенсорным экраном. Библиотека Clutter является примером такого типа поддержки.
УДАЛЕННАЯ ПОДДЕРЖКА
Возвращаясь к вопросу об инструментах отладки, большинство людей останавливаются на сценарии, когда устройство устанавливается рядом с рабочей станцией в лаборатории. Но как насчет случаев, когда вам нужно устранить неполадки устройства, которое проходит бета-тестирование на другом конце света? Вот где отладчик командной строки, такой как Gdb, является преимуществом, а не недостатком. А как подключиться к устройству, если у вас нет поддержки сотовых модемов в Новой Зеландии, или эффективный механизм соединения, такой как ssh, для доступа к оболочке и передачи файлов?
РЕЗЮМЕ
Выбор любой передовой технологии - непростая задача, и ее довольно сложно выполнить даже с опытом. Поэтому важно задавать правильные вопросы и смотреть на решение с разных сторон. Надеюсь, эта статья поможет в этом.