32 비트 Microsoft Windows 데스크탑 OS를 유지해야하는 좋은 이유

이 질문은 2012 년의 것입니다. 2019 년 이후에이 내용을 읽으면 실제로 대답은 다음과 같습니다. 아니요. 2019 년에 32 비트 데스크톱 운영 체제를 유지 관리 할 이유는 없습니다.

아래의 원래 질문 :

서버 소프트웨어는 한동안 만 64 비트였으며 (Windows의 경우 Server 2008 R2 이후, Exchange 및 Sharepoint의 경우 훨씬 빠름) 심지어 우분투에서도 서버 OS의 32 비트 버전에서 멀어지고 있습니다.

그러나 32 비트 데스크톱 운영 체제를 유지해야하는 적절한 양적 이유가 있습니까? 우리는 얼리 어답터가 될 소수의 Windows 8 이미지를 준비하고 있습니다.

대부분의 데스크톱 컴퓨터에는 4GB 이하의 RAM이 있지만 더 이상 32 비트 맛 운영 체제를 지원하지 않아도됩니다.

내가 왜 그래야합니까?

• 32 비트는 특정 사용 사례에서 약간 더 빠를 수 있습니다. 주소가 작을수록 코드가 훨씬 작아 져 캐시 효율성이 높아집니다. 내가 본 벤치 마크에서, 컴퓨팅 효율이 높은 컴퓨팅 환경에서 64 비트의 더 큰 계산 효율성으로 인해 효율성이 저하되는 경향이 있습니다. 그러나 실제로 32 비트는 일부 벤치 마크에서 승리합니다. YMMV. 최신 빌드는 이전 빌드와 달리 64 비트를 활용하므로 소프트웨어의 시대가 중요합니다.

• 코드가 작을수록 디스크 공간이 줄어 듭니다. 64 비트 및 32 비트 버전으로 선호하는 OS의 ISO를 다운로드하여 차이점을 확인하십시오. 사소한 것이 아닙니다. 바이너리를 압축 해제하면 훨씬 더 많습니다 . OrangeDog이 지적한 바와 같이 :이 공간 소비의 대부분은 64 비트 OS가 64 비트 라이브러리와 함께 32 비트 라이브러리를 제공한다는 사실에서 비롯됩니다.

• 32 비트의 레거시 구성 요소 및 소프트웨어와의 호환성이 여전히 향상됩니다. 이것은 호스트 시스템에서 동적으로 컴파일되지만 동시에 타사 바이너리 라이브러리를 가져 오는 시스템에서 볼 수 있습니다. Microsoft의 .NET 프레임 워크는 이에 대한 좋은 예입니다. 프로그램은 이론적으로 아키텍처와 무관하지만 기본 바이너리에 연결할 때마다 하나의 아치 또는 다른 아치에 연결됩니다. 많은 개발자들은 이러한 일이 일어나고 있음을 알지 못하고 .NET에 32 비트 모드로 실행하도록 명시 적으로 조정하지 않고도 64 비트 시스템에서 실행되지 않는 프로덕션 구성 요소를 제공합니다. 대부분의 사람들은 이것을하는 방법을 모른다.

• Daniel B가 지적한 바와 같이 : 64 비트 컴퓨터에서 Windows .NET을 개발하면 특정 상황에서 예외가 OS에 의해 가려지는 실망스러운 불일치 가 생길 수 있습니다.

• 레거시 하드웨어. 64 비트 커널에서는 32 비트 드라이버를 실행할 수 없습니다.

이 중 어느 것도 대부분의 사람들에게 쇼 스토퍼가 아닙니다. 그러나 이러한 요소가 환경에 미치는 영향을 결정해야합니다.

32 비트 데스크톱 운영 체제를 유지할 수있는 유일한 이유는 이전 16 비트 (예 : DOS) 프로그램을 사용하고 Windows Virtual PC를 지원하는 Windows 버전이없는 경우입니다.

(그리고 심지어 64 비트 OS를 설치하고 DOSbox와 같은 것을 사용합니다).

편집 : 실제로 또 다른 이유가 있습니다 : 4GB 이상의 주소 공간에 대처하지 못하는 하드웨어. 예를 들어 FireWire는 DMA를 시도합니다. 또는 64 비트 드라이버가없는 (구식) 하드웨어.

1 세대 Intel Atom 넷북이없는 한 Windows 8을 실행하는 모든 제품은 이미 64 비트를 지원합니다. 그것은 내가 생각할 수있는 유일한 것입니다.

AMD는 2003 년에 최초의 64 비트 지원 Opteron을 출시했습니다. 그 이후로 거의 모든 프로세서는 64 비트를 지원했습니다.

인텔은 1 년 후 2004 년 첫 64 비트 Xeon (Nocona)을 출시하고 2006 년까지 전체 제품 라인으로 확장했습니다. 앞서 언급 한 초기 Atom 칩 외에도 오늘날 모든 인텔 프로세서는 64 비트입니다.

Wikipedia에는 고대 역사에 관심이있는 경우 세분화 된 프로세서 목록이 있습니다 .

고대 소프트웨어 / 하드웨어와의 호환성

모든 것이 x64에서 작동한다면 32 비트로 귀찮게하지 않을 것입니다.

64 비트 시스템의 메모리 주소는 자연스럽게 64 비트를 사용합니다. 동일한 주소는 32 비트 시스템에서 32 비트를 사용합니다. 매우 예외적 인 상황에서 필요한 비트 수의 "증가"는 메모리 제한 시스템에서 성능과 성능의 차이가 될 수 있습니다.

그 외에도 64 비트 소프트웨어를 실행할 수있는 컴퓨터에서 32 비트 소프트웨어를 실행하고 64 비트 컴퓨터에서 32 비트 지원이 합리적으로 잘 작동하므로 하드웨어 측면의 차이점은 게임 변경이 아닙니다. 간혹 64 비트 하드웨어 드라이버가없는 레거시 장치를 찾을 수 있지만 10 년 이상 64 비트 운영 체제를 사용할 수 있기 때문에 매우 드물게 나타납니다.

한 가지 고려해야 할 점은 많은 오래된 32 비트 응용 프로그램이 비트 단위를 넘어 여러 가지 방식으로 오래되었다는 것입니다. Windows OS 측에서는 32 비트 앱이 이제 "프로그램 파일 (x86)"에있는 "프로그램 파일"에서 파일을 찾는 경우 혼란 스러울 수 있습니다. 특정 레지스트리 항목도 마찬가지로 수동주의가 필요합니다. 다시 말하지만 이것은 약간 잘못 작성된 응용 프로그램의 기능입니다. 이제 기계가 32 비트 인 경우 "방금 작동 한"항목을 "찾기"위해 도움이 필요합니다.

많은 사람들은 64 비트 프로그램과 라이브러리가 32 비트에 해당하는 것보다 더 많은 메모리를 차지한다는 것을 모릅니다.

예를 들어, 메모리가 적은 가상 시스템을 사용하는 경우 32 비트 운영 체제를 사용하여 해당 VM 내에서 메모리 가용성을 최대화하는 것이 좋습니다.

우분투에 대해, 우리는 현재 몇 주 동안 LTSP 하에서 64 비트 12.04 LTS를 운영하고 있습니다.

초기 베타 테스터에 대한 유일한 번거 로움은 우리가 사용하는 LTSP 터미널 (Dell GX2xx)에 32 비트 커널이 필요하므로 두 번째 LTSP 커널을 컴파일하고 두 아키텍처에 대해 두 배 많은 패키지를 유지해야한다는 것입니다 .

LTSP가 가장 중요한 경우라고 생각합니다. 특정 테스트에서 결함이 표시되지 않는 한 64 비트가 준비가되었습니다.

개인적으로 가능한 빨리 64 비트로 옮기고 나중에 총알을 빨리 물리 치는 것이 좋지만 IT 지원 팀에는 영향을 미치지 않습니다. 지원 팀의 대역폭이 이미 최대치까지 확장 된 경우 (즉, 이미 직원이 부족한 경우) 실제로 대기하는 것이 좋습니다.

따라서 이것은 소프트웨어 비 호환성뿐만 아니라 인적 자원과 관련된 하나의 대답입니다.

롤아웃은 물론 신중하게 계획해야합니다 (한 번에 전체적으로 수행하는 것이 아니라 점진적으로 수행하는 것이 좋습니다). "발견 된"문제는 사용자별로 해결하는 데 몇 시간이 걸릴 것입니다. 보다 일반적인 문제가 확인되면 "사용 방법"을 통해 지원 서비스와 셀프 서비스 모두에 대한 빠른 해결 방법을 안내 할 수 있습니다.

주로, 예를 들어 OS, 특정 소프트웨어 패키지 및 관련 플러그인 사이의 모든 32 및 64 비트 (in) 호환성 문제를 생각하고 있습니다.단일 64 비트 OS에 32 비트 및 64 비트 브라우저 (및 / 또는 여러 브라우저)를 모두 설치 한 경우, '관리자로 실행'대 '일반 사용자로 실행'에 대한 바로 가기, 32 해당 브라우저를위한 64 비트 플러그인 (또는 한 버전의 브라우저에서만 작동하는 32 비트 플러그인으로 제한 될 수도 있음)-플러그인 위에 구축 된 애플리케이션과 워크 플로를 모두 중단합니다. ( "플러그인"이란 Java에서 플래시, 임베디드 PDF 리더, 웹 회의 소프트웨어, 사내 또는 무료로 제공되는 웹 회의 소프트웨어에 이르기까지 모든 것을 의미합니다.) 이러한 모든 문제를 테스트 할 수는 있지만 사용자가 플러그인 A보다 플러그인 B를 실수로 설치하는지 예측하기 어렵 기 때문에 플러그인 B보다 플러그인 A를 설치 한 다른 사용자와는 다른 결과가 발생합니다.

32 비트 버전의 모든 것을 유지해야하는 유일한 이유는 "레거시"응용 프로그램 및 시스템을 지원하는 것입니다. 64 비트 OS에서 모든 것을 실행할 수 있다면 운이 좋으면서 계속 진행하십시오. XP에서 Windows 7로 사용자 기반에서 마이그레이션 계획이 2014 년 3 분기에 시작되는 비 기술 기업의 회사 환경에있는 일부 빈약 한 SA와 비슷할 수 있습니다.

< 울다 >

어쨌든, 나는 Shift+ Del에 대해 모른다. 아마도 말할 수없는 일이 발생하고 Windows XP무언가를 필요로 하는 경우를 대비하여 환경 구석에서 무시할 수 있습니다 . 유지 관리, 업데이트, 테스트 또는 그 밖의 것을 유지하기 위해 귀찮게하지 말고 필요할 때 주위에 두십시오. 다른 날 클라이언트가 내가 Windows 2000PoS 를 지원하기를 원했던 것은 일어났다. 나는 나왔을 Server 2000때 모든 이미지를 날려 버리지 않았기 때문이다 Server 2003.

당신이기도하고 시간이 다가 오지 않기를 희망하는 한, "만약의 경우"에 대해 그런 것들을 갖는 것이 항상 좋으며, 그것을 유지하는 데 드는 비용이 너무 작기 때문에 어리석지 않다고 생각합니다.

레거시 소프트웨어 문제로 인해 상당한 문제가 있었기 때문에 실행하는 모든 것을 64 비트 OS에서 실행할 수 있는지 확인해야 합니다. 그렇다면 라이센스가 중요하지 않다고 가정하면 마이그레이션하지 않을 이유가 없습니다.

필자의 경우 모든 32 비트 전용 응용 프로그램이 한 컴퓨터에서 실행될 수 있도록 시스템을 재구성하여 다른 모든 워크 스테이션을 64 비트로 만들 수있었습니다. 결국 32 비트 머신을 데비안 호스트에서 실행되는 Virtualbox의 VM으로 마이그레이션했습니다. 주로 용량이 있었고 박스 수를 줄이고 싶었습니다.

CPU가 가상화를 지원하지 않는 경우 위의 모든 가상 머신 과 x64 비트 코드를 실행할 수 없습니다 (예 : VT-x 기능).

그러나 VT-x 등이없는 저렴한 64 비트 CPU는 '집에서 만든'클러스터에 적합합니다.

에서 위키 피 디아 :

인텔은 x86-64 구현 (인텔 64)에 세분화 지원을 추가하지 않아 인텔 CPU에서 64 비트 소프트웨어 전용 가상화를 불가능하게 만들었지 만 인텔 VT-x 지원으로 인텔 플랫폼에서 64 비트 하드웨어 지원 가상화가 가능해졌습니다.