Mac OS X 10.4.6부터는, 디스크가 GPT로 분할되어 있다면, 터미널 도구인 diskutil을 사용해서 볼륨 크기를 조절할 수 있게 되었다고 한다.
$ diskutil resizeVolume
Disk Utility Tool
Usage: diskutil resizeVolume [Mount Point|Disk Identifier|Device Node] size
<part1Format part1Name part1Size> <part2Format part2Name part2Size> ...
Non-destructively resize a disk. You may increase or decrease its size.
When decreasing size, you may optionally supply a list of new partitions to create.
Ownership of the affected disk is required.
Valid partition sizes are in the format of <number><size>.
Valid sizes are B(ytes), K(ilobytes), M(egabytes), G(igabytes), T(erabytes)
Example: 10G (10 gigabytes), 4.23T (4.23 terabytes), 5M (5 megabytes)
resizeVolume is only supported on GPT media with a Journaled HFS+ filesystem.
A size of "limits" will print the range of valid values for the current filesystem.
Example: diskutil resizeVolume disk1s3 10G
JHFS+ HDX1 5G MS-DOS HDX2 5G
Valid filesystems: "Case-sensitive HFS+" "Journaled HFS+" "Case-sensitive Journaled HFS+"
"HFS+" "HFS" "MS-DOS FAT32" "MS-DOS FAT16" "MS-DOS" "MS-DOS FAT12" "UFS" "Linux" "Swap"
여기서 GPT로 분할된 디스크란, Apple 문서에 의하면, Intel 기반 맥들의 내장 하드 드라이브에 새로 채용되어 사용되는 GUID Partition Table(GTP)을 의미하며, 외장 USB 혹은 FireWire 디스크에서 Intel 기반 맥들을 시동하려면 GPT 디스크 파티션으로 설정되어 있어야 한다고…
참고로, 이전 PowerPC 기반 Mac들에서는 Apple Partition Map(APM)이 사용되었다.
굳이 당장 하드 디스크를 쪼갤 필용성도 못 느끼고 Intel 기반 Mac도 없으면서, 약간의 부러움과 반가움을 동시에 느끼는 이유는 바로,
Intel 기반 Mac들이 소개되면서, 그 동안 금단의 구역으로만 여겨졌던 장벽들이 하나 둘씩 무너지고, 더불어 사용자 만족도도 높아지리라 기대되기 때문이다.
또 한 명의 Mac 열망 고백성사… 😛 + 😥
얼마전, Windows XP Pro를 Intel Mac들에 설치하는 방법이 공개된 데 이어,
오늘은 몇몇 해커들에 의해 Intel CPU용 Mac OS X를 Dell PC에 설치 시동하는데 성공했다는 소식이 알려졌다.
그야말로, 봄을 맞아 태생적으로 허락된 그들만의 갇혀 있던 영역을 넘어서 다른 세계로의 봄나들이가 시작된 형국이다.
물론, 아직 그들의 봄나들이는 제각기 약간의 제약들이 따르긴 하지만, 시간이 지나서 이 약간의 제약들마저도 걷어진다고 가정하면, 결국 진정한 OS들 간의 활동 영역 간 점유 전쟁을 알리는 선전포고는 이미 시작되었는지도 모를 일이다. 😮
누구의 승리로 돌아가든, 제3의 사용자 입장에선 그냥 지켜만 봐도 즐겁고 이로운 결말이 되겠지.
여기서 굳이 나의 응원군을 말할 필요는 없겠군. 🙂
개인적으로 한국 사용자들을 위한 Dashboard Widget을 개발하면서 몸소 느끼고 체험했던 몇 가지 사실들을 적어놓고자 한다.
사실 하나.
대부분의 한국 웹 사이트들은 그 구조가 아직 XHTML 형태로의 전환을 이루지 못하고 있다. 따라서, widget에서 원하는 정보를 XMLHttpRequest Object를 사용해서 가져오는데 상당한 벽에 부딪히게 된다.
이것은, 필요한 정보를 XML 데이터 형태로 직접 접근할 수 없게 됨으로써, 클라이언트 쪽에서는 입맛에 맞는 Document Object Model(DOM)로의 접근과 수정이 차단되어 버린다.
결국, 차선책으로 XMLHttpRequest Object의 responseText 속성을 가지고서 원하는 정보에 접근할 수밖에 없게 되는 샘.
이쯤 와서, 그나마 막강한 힘을 발휘하게 되는 것이 바로 JavaScript의 RegExp Object이다.
물론, DOM 형태로의 유연한 접근과 수정이 불가능하고, 어쩌면 거치지 않았어도 될 불필요한 과정이겠지만, 어쨌든 원하는 정보를 그야말로 긁어올 수는 있다. 하지만, 여전히 아쉬운 것은 마찬가지.
사실 둘.
웹 표준 준수의 문제.
한국 대부분의 사이트는 표준 준수에 따른 이점들을 제대로 인식하고 있지 못하는 듯하다.
이것이 widget 개발과 무슨 상관이 있느냐고?
엉성한 구조로 된 웹 페이지로의 접근은 어떠한 user agent들에도 불리한 영향을 끼치기 마련이다.
사실 셋.
웹 정보 접근 용이성의 문제.
가끔은, 심한 경우 웹 사이트의 특정 정보가 Windows에서만 적용되는 ActiveX control 혹은 JScript (Windows Script Technologies) 등의 기술만 사용해서 전달되어 보이는 경우가 있다. 이렇게 되면 다른 플랫폼을 통한 정보 접근은 완전히 막히게 된다. 다른 길로 돌아가는 접근 방도가 전혀 없을 때에는, 다른 곳으로 눈을 돌릴 수밖에.
짧지만, 이렇게 해서 지금까지 적어놓은 내용을 한 문장으로 정리를 한다면, 불행하게도 “한국 사용자들을 겨냥한 widget을 개발하려면, 웹 표준의 파괴로 인해 생긴, 높은 장벽들로 둘러쌓여 진 정보에도 무사히 접근할 수 있는 여러 꼼수들에 단련이 되어 있어야 한다.“가 되겠군.
끝으로, 그나마 잘 갖추어진 한국의 인터넷 하드웨어 기반 환경에 걸맞은 잘 짜인 웹 사이트가 많이 늘어나길 기대하며…
새로 태어난 바깥 날씨 widget 덕분에 미남이의 Widget들 모음이라는 이름의 연결고리가 추가되었다.
이로써, 별 쓸모도 없는 뒷북 날씨 정보만 흘리던 Apple의 날씨 widget과는 완전하게 결별할 수 있게 되기를 바란다.
그래도, 다른 widget들 중에서 가장 빼어난 겉모습을 자랑했던 점을 생각하면, 약간 시원섭섭한 생각이 들지도 모르겠군.
당분간은 둘 다 양 옆에 앉혀놓고 서로 다른 주장의 말다툼을 지켜볼 예정. 😛
