Это вопрос 2012 года. Если вы читаете это в 2019 году или позже, то ответ действительно таков: нет. В 2019 году нет веских причин для поддержки 32-разрядных операционных систем для настольных ПК.
Исходный вопрос ниже:
Серверное программное обеспечение было 64-битным только некоторое время (начиная с Server 2008 R2 для Windows, еще раньше для Exchange и Sharepoint), и даже Ubuntu отталкивает вас от 32-битных версий для своих серверных ОС.
Но есть ли какая-нибудь веская, поддающаяся количественной оценке причина поддерживать 32-разрядную операционную систему для настольных ПК? Мы готовим наши образы Windows 8 для (к сожалению?) Немногих, которые станут первыми пользователями.
Большинство наших настольных компьютеров имеют 4 ГБ или меньше оперативной памяти, но мне бы хотелось, чтобы мне больше не приходилось беспокоиться о поддержке 32-разрядной операционной системы.
По какой причине я должен?
32-разрядная версия может быть немного быстрее в определенных случаях использования - меньшие адреса означают значительно более компактный код, что означает большую эффективность кеширования. В тестах, которые я видел, эта эффективность, как правило, затмевается большей вычислительной эффективностью 64-битных систем в средах с тяжелыми вычислениями. Но на самом деле 32-разрядная версия иногда выигрывает в некоторых тестах. YMMV. Возраст вашего программного обеспечения имеет значение, так как новые сборки используют 64-битные возможности, которых нет в старых.
Более компактный код означает меньше места на диске. Просто скачайте ISO-образы вашей любимой ОС в 64- и 32-битной версиях, чтобы увидеть разницу. Это нетривиально. Это тоже довольно много Больше после распаковки двоичных файлов. Как указывает OrangeDog: Большая часть этого потребления пространства происходит из-за того, что 64-битные ОС поставляют 32-битные библиотеки в дополнение к 64-битным.
Вы по-прежнему получаете лучшую совместимость с устаревшими компонентами и программным обеспечением с 32-разрядной версией. Это особенно заметно в системах, которые динамически компилируются на главном компьютере, но одновременно используют сторонние двоичные библиотеки. Платформа Microsoft .NET - отличный пример этого: хотя программы теоретически не зависят от архитектуры, каждый раз, когда вы связываете нативный двоичный файл, вы привязываете его к той или иной арке. Многие разработчики даже не знают, что это происходит, и поставляют производственные компоненты, которые не смогут работать в 64-битных системах, без некоторых настроек, чтобы явно указать .NET для работы в 32-битном режиме. Большинство людей не знают, как это сделать.
Как указал Даниэль Б: Разработка Windows .NET на 64-битных машинах оставляет вас открытым для разочаровывающая непоследовательность где при определенных обстоятельствах исключения маскируются ОС.
Устаревшее оборудование. Вы не можете запустить 32-битный драйвер на 64-битном ядре.
Ничто из этого не останавливает большинство людей. Тем не менее, вы должны решить, как эти факторы влияют на вашу среду.
Единственная причина, по которой я могу придумать 32-битную операционную систему для настольных ПК, - это если вы используете старые 16-битные (например, DOS) программы и у вас нет версии Windows, которая поддерживает Windows Virtual PC.
(И даже тогда я бы установил 64-битную ОС и использовал что-то вроде DOSbox).
Изменить: на самом деле есть еще одна причина: оборудование, которое не справляется с адресным пространством более 4 ГБ. Например. FireWire пытается выполнить DMA. Или любое (старое) оборудование без 64-битных драйверов.
Все, что будет работать под управлением Windows 8, уже поддерживает 64-разрядную версию, если только у вас нет нетбуков Intel Atom первого поколения (а я в этом очень сомневаюсь). Это единственное, о чем я могу думать.
AMD выпустила свой первый 64-битный Opteron в 2003 году; и с тех пор практически все процессоры, которые они производили, были 64-битными.
Год спустя Intel выпустила свой первый 64-битный Xeon (Nocona) в 2004 году и расширила почти до всей линейки продуктов к 2006 году. Помимо вышеупомянутых ранних чипов Atom, каждый процессор Intel сегодня 64-битный.
В Википедии есть подробный список процессоров, если вас интересует древняя история.
Совместимость со старым программным / аппаратным обеспечением.
Если бы все работало под x64, я бы не стал заморачиваться с 32-битной.
Адреса памяти на 64-битной машине, естественно, занимают 64 бита. Те же адреса занимают 32 бита на 32-битной машине. В некоторых довольно исключительных обстоятельствах это «увеличение» необходимого количества бит может быть разницей между хорошей производительностью и низкой производительностью на машине с ограниченным объемом памяти.
Кроме того, поскольку вы, вероятно, будете запускать 32-битное программное обеспечение на машине, на которой в любом случае может работать 64-битное программное обеспечение, а поддержка 32-битной версии достаточно хорошо работает на 64-битных машинах, различия на аппаратной стороне не меняют правила игры. Иногда вы найдете устаревшее устройство, у которого нет 64-битного аппаратного драйвера, но сейчас это очень редко, поскольку 64-битные операционные системы доступны уже более десяти лет.
Следует учитывать, что многие старые 32-разрядные приложения старше во многих отношениях, помимо своей разрядности. На стороне ОС Windows 32-битное приложение может запутаться, если оно ищет файлы в «Program Files», которые теперь находятся в «Program Files (x86)». Некоторым элементам реестра также может потребоваться ручное вмешательство. Опять же, это скорее функция слегка неправильно написанных приложений, которым теперь нужна ваша помощь, чтобы «найти» вещи, которые «просто работали бы», если бы машина оказалась 32-битной.
Многие люди не знают, что 64-битные программы и библиотеки занимают больше памяти, чем 32-битные эквиваленты.
Например, при использовании виртуальных машин с низким объемом памяти рекомендуется использовать 32-разрядные операционные системы, чтобы максимально увеличить доступность памяти внутри этой виртуальной машины.
Говоря об Ubuntu, мы уже несколько недель запускаем 64-битную версию 12.04 LTS под LTSP.
Единственная проблема, с которой мы столкнулись для первых бета-тестеров, заключается в том, что используемые нами LTSP-терминалы (Dell GX2xx) требуют 32-битного ядра, и поэтому мы должны скомпилировать второе ядро LTSP и поддерживать вдвое больше пакетов для двух архитектур. .
LTSP - ВЕСЬМА крайний случай, я думаю, что 64-битная версия вполне готова к работе, если только ваше конкретное тестирование не покажет дефект.
Хотя я лично рекомендовал бы перейти на 64-разрядную версию как можно скорее и просто перекусить раньше, чем позже, это не повлияет на вашу команду ИТ-поддержки. Если пропускная способность группы поддержки уже увеличена до максимума (т. Е. Уже не укомплектована кадрами), то я бы подумал об ожидании.
Итак, это один из ответов, который касается человеческих ресурсов, а не только программного обеспечения / совместимости.
Разумеется, развертывание должно быть тщательно спланировано (желательно постепенно, а не сразу). Будут «обнаружены» проблемы, на решение которых у каждого пользователя уйдут часы. После того, как будут выявлены наиболее распространенные проблемы, практические инструкции помогут быстрее решить как запросы в службу поддержки, так и самообслуживание.
В основном (например) я думаю обо всех 32- и 64-разрядных проблемах совместимости между ОС, конкретным программным пакетом и связанным плагины, например, наличие как 32-разрядных, так и 64-разрядных браузеров (и / или нескольких браузеров) в одной 64-разрядной ОС, ярлыки для «запускать от имени администратора» и «запускать от имени обычного пользователя», имея опции для 32 и 64-битный плагин для этих браузеров (а иногда может быть ограничен только 32-битными плагинами, которые работают только в одной версии браузера) - все это нарушает работу приложений и рабочих процессов, построенных на этих плагинах. (Под «плагинами» я подразумеваю все, что угодно, от Java до флэш-памяти до встроенных программ для чтения PDF-файлов и программного обеспечения для веб-конференций - либо встроенного в компанию, либо широко доступного, коммерческого и бесплатного.) Вы можете попытаться проверить все эти проблемы, но это трудно предсказать, будет ли пользователь по неосторожности установить плагин B перед плагином A, что приведет к другому результату, чем другой пользователь, который устанавливает плагин A перед плагином B (в основном всегда трудно предсказать, какой ущерб нанесут пользователи, когда их действия изменят состояние система.)
Единственная причина сохранить 32-битные версии ... чего угодно ... - это поддержка "устаревших" приложений и систем. Если вы можете запускать все на 64-битных ОС, считайте, что вам повезло, и двигайтесь дальше. Вы могли бы походить на некоторых бедных SA, которые находятся в корпоративной среде для нетехнической фирмы, где план по переходу с пользовательской базы с XP на Windows 7 начинается в третьем квартале 2014 года.
<плачет>
Во всяком случае, я не знаю о сдвиг+Del, и я бы, вероятно, просто оставил их проигнорированными в каком-то уголке среды, на случай, если случится невыразимое, и вы окажетесь в нужде Windows XP для чего-то. Определенно перестаньте беспокоиться об их обслуживании, обновлении, тестировании или чем-то еще, но держите их при себе, если они когда-нибудь понадобятся. На днях случилось так, что клиент хотел, чтобы я поддержал Windows 2000 PoS, что я мог, потому что я не сдул все свои Server 2000 изображения, когда Server 2003 вышло (и мне тоже очень хотелось).
Как бы вы ни молились и не надеялись, что время никогда не придет, всегда приятно иметь эти вещи под рукой «на всякий случай», а затраты на их содержание настолько незначительны, что я считаю глупым не делать этого.
Имея значительные проблемы из-за проблем с устаревшим программным обеспечением, я могу сказать только, чтобы убедиться все вы запускаете, может работать в 64-битной ОС. Если это так, то у вас нет причин не выполнять миграцию, если лицензирование не имеет значения.
В моем случае я смог перенастроить системы так, чтобы все 32-битные приложения могли работать на одной машине, а все остальные рабочие станции были 64-битными. В конце концов я даже перенес эту 32-битную машину на виртуальную машину на Virtualbox, работающую на хосте Debian, в основном потому, что там была емкость, и я хотел уменьшить количество ящиков.
Все вышеперечисленное и несколько виртуальные машины не может запускать x64-битный код, если ЦП не поддерживает виртуализацию (например, функция VT-x).
Однако несколько более дешевых 64-битных процессоров без VT-x и т. Д. Привлекательны для «самодельных» кластеров.
Из википедия:
Intel не добавляла поддержку сегментации в свою реализацию x86-64 (Intel 64), что сделало 64-битную программную виртуализацию невозможной на процессорах Intel, но поддержка Intel VT-x делает возможной 64-битную аппаратную виртуализацию на платформе Intel.