Важливі причини зберегти 32-бітні ОС Microsoft Windows

Це запитання починається з 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 Framework є чудовим прикладом цього: хоча програми теоретично не залежать від архітектури, у будь-який час, коли ви посилаєтесь на рідний бінарний файл, ви прив’язуєтесь до однієї або іншої арки. Багато розробників навіть не знають, що це відбувається, і компоненти для виробництва кораблів, які не зможуть працювати в 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-розрядний додаток може заплутатися, якщо він шукає файли в "Файлах програми", які зараз знаходяться в "Програмні файли (x86)". Окремі елементи реєстру також можуть потребувати ручної уваги. Знову ж таки, це більше функція злегка написаних програм, які тепер потребують вашої допомоги, щоб "знайти" речі, які "працювали", якби машина була 32-бітної.

Багато людей не знають, що 64-бітні програми та бібліотеки займають більше пам'яті, ніж 32-бітні еквіваленти.

Наприклад, при використанні віртуальних машин з низькою пам’яттю доцільно використовувати 32-бітні операційні системи, щоб максимально забезпечити доступність пам’яті всередині VM.

Говорячи про Ubuntu, ми працюємо 64-бітні 12,04 LTS під LTSP вже кілька тижнів.

Єдиний клопот, який ми зіткнулися з початковими бета-тестерами, полягає в тому, що для терміналів LTSP, які ми використовуємо (Dell GX2xx), потрібно 32-бітове ядро, і тому нам доведеться скласти 2-е ядро ​​LTSP і підтримувати вдвічі більше пакетів для двох архітектур. .

LTSP - це ТІЛЬКИ крайній випадок, я думаю, що 64-розрядна досить готова до роботи, якщо тільки ваше тестування не виявить дефект.

Хоча я особисто рекомендую якнайшвидше перейти на 64-бітну та просто кусати кулю раніше, ніж пізніше, це не вплине на вашу команду ІТ-підтримки. Якщо пропускна здатність групи підтримки вже розтягнута до максимуму (тобто вже не має достатнього числа), я б насправді подумав чекати.

Отже, це одна відповідь, що стосується людських ресурсів, а не лише програмного забезпечення / сумісності.

Зрозуміло, слід, звичайно, ретельно планувати (бажано поступово, а не відразу) Будуть "виявлені" проблеми, на вирішення яких потребуватимуть години на основі кожного користувача. Як тільки виявляться більш поширені проблеми, "практичні запитання" можуть керувати швидшими рішеннями як для викликів підтримки, так і для самообслуговування.

Здебільшого, (наприклад), я думаю про всі проблеми сумісності між 32 та 64 бітами (в) між ОС, конкретним програмним пакетом та пов'язаними плагінами, наприклад встановлення 32-бітних та 64-розрядних браузерів (та / або декількох браузерів) на одній 64-розрядної ОС, ярлики для 'запустити як адміністратор' та 'запустити як звичайний користувач', маючи параметри як для 32 і 64-розрядний плагін для цих браузерів (або іноді може бути обмежений лише 32-бітовими плагінами, які працюють лише в одній версії браузера) - все, що порушує програми та робочі процеси, побудовані поверх цих плагінів. (Під "плагінами" я маю на увазі все, що завгодно, від Java, щоб перейти до вбудованих читачів PDF у програмне забезпечення для веб-конференцій - або вбудованого у власність, або у широкому доступі, як комерційного, так і безкоштовного.) Ви можете спробувати протестувати на всі ці проблеми, але це важко передбачити, чи користувач ненавмисно встановить плагін B перед плагіном A, що спричиняє інший результат, ніж інший користувач, який встановлює плагін A перед плагіном B (в основному це '

Єдина причина зберігати 32-бітні версії ... нічого ... навколо - це підтримка "застарілих" додатків та систем. Якщо ви можете запустити все на 64-бітних ОС, порахуйте себе щасливчиком і рухайтеся далі. Ви можете бути схожими на бідних офіційних осіб, які перебувають у корпоративному середовищі для нетехнологічної фірми, де план переходу з бази користувачів з XP на Windows 7 починається в третьому кварталі 2014 року.

< крики >

У всякому разі, я не знаю про Shift+ Del, і я, мабуть, просто залишу їх ігнорувати в якомусь куточку навколишнього середовища, на випадок, коли трапиться невимовне, і ви виявите, що вам потрібно Windows XPщось. Безумовно, перестаньте заважати підтримувати, оновлювати, тестувати чи випробовувати інше на них, але тримайте їх, якщо вони коли-небудь знадобляться. Днями клієнт хотів, щоб я підтримав якийсь Windows 2000PoS, що я міг, тому що я не здував усі свої Server 2000зображення, коли Server 2003вийшов (і мені теж дуже хотілося).

Стільки, скільки ви молитесь і сподіваєтесь, що час ніколи не настане, завжди приємно мати такі речі "на всякий випадок", а витрати на її утримання є такими незначними, я думаю, що це нерозумно.

У мене виникли значні проблеми через старі проблеми із програмним забезпеченням, я можу сказати лише для того, щоб переконатися, що все, що ви працюєте, може працювати на 64-бітній ОС. Якщо це так, то у вас немає причин не мігрувати, припускаючи, що ліцензування не є фактором.

У моєму випадку мені вдалося переконфігурувати системи так, що всі 32-бітні додатки змогли запускатися на одній машині, дозволяючи всім іншим робочим станціям бути 64 бітними. Врешті-решт я навіть переніс цю 32-бітну машину у VM на Virtualbox, що працює на хості Debian, головним чином тому, що ємність там була, і я хотів зменшити кількість коробки.

Всі перераховані вище та кілька віртуальних машин не можуть запустити x64-бітний код, якщо ЦП не підтримує віртуалізацію (наприклад, функцію VT-x).

Однак кілька дешевих 64-бітних процесорів, у яких не вистачає VT-x тощо, привабливі для "домашніх" кластерів.

З Вікіпедії :

Intel не додала підтримку сегментації для своєї реалізації x86-64 (Intel 64), що робить віртуалізацію лише 64-бітним програмним забезпеченням на процесорах Intel, але підтримка Intel VT-x робить можливою 64-бітну апаратну віртуалізацію на платформі Intel