리눅스(페도라) 데스크탑에 리눅스(안드로이드) 폰만 쓰는데도...
망할 윈도우즈에 발목잡힐 수 있네요.. LoL
0.001::10.0.png 0.001::15.0.png ... 이런 식으로 되어 있는 그림들 수 백 개를 쾌적한(?) 터치 환경에서 살펴보기 위하야, 일단 디렉토리를 통째로 ZIP으로 압축해서 FTP로 전송하는 것까진 늘 그랬듯 아무 문제가 없었는데, 폰에서 이놈의 ZIP 압축을 도무지 풀 수가 없더군요 >_< (1년동안 안드로이드폰을 쓰면서 처음 겪는 황당 시츄에이션;; )
그래 한참동안 '진정한 의미에서의 삽질'을 하는데, 윈도우즈 쓰는 친구들의 무심하면서도 충격적인(?!) 지적...
"윈도우즈에선 파일이름에 그딴 글자(:: <-- 요런 거) 못 써~"
오마갓 맙소사!
"혹 그럼 언더바('_')는 되냐?" - "그건 될 껄!" - "땡쓰;; -_-;; " ... (문제 해결!)
왠만해선 : ; ! ? , $ # 같은, 리눅스에선 되고 윈도우즈에선 안되는 특수 문자들이 파일 이름에 들어갈 일은 없겠지만, 그래도 혹시라도 같은 문제로 삽질하시는 분들 있을까봐 여기다 기록해(?) 둡니다;; >_<
(참고 - 안드로이드 기기 쓰는 분들은 잘 아시겠지만,
안드로이드는 시스템 및 바이너리 패키지 설치를 위한 파티션은 ext4, 그리고 사용자 컨텐츠 내지 데이터 패키지를 위한 파티션은 - 보통 마이크로 SD 카드에 실려서 - vfat인가로 되어 있습니다. 아무튼 그 이질적인 파티션 덕분에(?) 아무 컴터에나 폰을 붙여서 파일 시스템에 접근할 수 있는 거니깐 뭐라 하기도 그렇고 원... _-_ )
..
팁 게시판은 없는 것 같네요..
저도 팁 하나입니다.
커널에서 dump_stack()호출하면 커널 내부 콜스택을 로그로 찍어줍니다.
의외로 유용한데 잘 안쓰시는 것 같기도 해서 혹시나 올려봅니다.
A rose is a rose is a rose..
강의 게시판이 있죠. :)
강의 게시판이 있죠. :)
피할 수 있을때 즐겨라! http://melotopia.net/b
MS가 컴퓨팅 환경을 많이 더럽혀놓았죠. 파일 이름
MS가 컴퓨팅 환경을 많이 더럽혀놓았죠.
파일 이름 8글자 제한, 웹, J스크립트, 액티브X, cp949, 헝가리 표기법 등
어떻게 생각해보면... MS 한 기업만 없어지면 모든 것이 제자리로 돌아올 듯합니다.
과거처럼 유닉스, 리눅스가 주름잡는 시대가 도래하겠죠.
어쩌다...PC에 DOS가 침투해서...이 지경까지 오게 되었는지...
PC에 유닉스가 침투했었으면 호환성 문제로 피곤할 일도 없었을텐데...
크롬북이라도 성공해서 그후 리눅스가 PC 시장 구석구석에 뿌리내렸으면 좋겠네요.
유닉스도 파일이름 8글자 제한이 있던 시절이
유닉스도 파일이름 8글자 제한이 있던 시절이 있습니다.
strncpy의 구현에서 빈자리를 끝까지 0으로 채우는게 바로 그 흔적입니다.
마이크로소프트가 이상한 짓 많이 했지만, 8글자 제한은 마이크로소프트가 모델로 삼았던 70년대 버전 유닉스에서 온거니까 그거 욕하려면 유닉스에 침을 뱉는거라는 것은 알고 하세요.
파일이름 8글자 제한은 CD롬 포맷과 90년대
파일이름 8글자 제한은 CD롬 포맷과 90년대 2000년대까지 영향을 끼쳤습니다.
70년대면 유닉스 탄생한 때인데... 너무 거슬러 올라가면...
에니악도 욕먹어야 되고... 컴퓨터 탄생에도 침을 뱉는 행위가 되겠군요.
유닉스가 에니악을 모델로 만들었다면 그래야겠죠.
유닉스가 에니악을 모델로 만들었다면 그래야겠죠. 그런데 전혀 관계가 없으니까 그런 주장은 억지에 불과합니다.
마이크로소프트는 초창기에 유닉스를 자기네 서버로 쓰고 있었고 그걸 모형으로 삼아서 유닉스의 디자인 결정을 베껴온거라는 사실을 무시하고 싶으면 그렇게 해도 상관은 없어요. 그냥 역사를 모르고 억지쓰는 수준에 머무르는 것 뿐이죠.
90년대 유닉스, 리눅스는 파일 이름을 8글자로
90년대 유닉스, 리눅스는 파일 이름을 8글자로 제한하지 않았습니다.
당연한 이야기에 들어오는 태글,
kldp 에서 MS 기반 개발자, 업계 관계자들의 눈치를 보며 글쓰는 것도 짜증납니다.
웹환경, 컴퓨팅 환경이 우리나라만 특수한 상황인거죠?
다음 국어사전
궤변: 상대편을 이론으로 이기기 위하여 상대편의 사고(思考)를 혼란시키거나 감정을 격앙시켜 거짓을 참인 것처럼 꾸며 대는 논법.
마이크로소프트의 8글자 제한이 90년대에 생긴줄 아는
마이크로소프트의 8글자 제한이 90년대에 생긴줄 아는 분이군요.
컴퓨터 역사를 조금 더 공부하시는게 좋겠어요.
90년대에 생겼다는 것이 아니라... 90년대에도
90년대에 생겼다는 것이 아니라...
90년대에도 유행하고 있으니까 하는 얘기잖아요.
아.. 궤변들 짜증나..진짜.
디자인 결정이 70년대에 있었다는 것을 공부하지
디자인 결정이 70년대에 있었다는 것을 공부하지 않았으니까 짜증내는거 이해합니다.
아는줄 알고 있었는데 실제로 전혀 모르면 짜증나죠.
직장인이면 애플II같은 것 썼을법한 고참들에게 옛날얘기 좀 해달라고 해보세요.
왜 그런 디자인 결정이 났는지 이해하는데 도움이 될겁니다.
학생이면 교사나 교수를 찾아가서 왜 과거에 그런 제한이 생겼는지 이유를 들려달라고 해보세요. 32비트 환경이 PC로 언제 도입되었고 그때 쓸만한 유닉스가 뭐가 있었는지도 배우고 오면 더 잘 이해가 될겁니다.
이 보세요... 궤변도 적당히 하게요. 그래서...
이 보세요... 궤변도 적당히 하게요.
그래서... 90년대에도 8글자 제한이 유행했다는 말인가요?
그런 걸 가지고 궤변이라고 하는 겁니다.
모르면서 아는척 우기는걸 억지라고 하는겁니다.
모르면서 아는척 우기는걸 억지라고 하는겁니다.
에혀... 할 말이 없네. 그래서 90년대 유닉스도
에혀... 할 말이 없네.
그래서 90년대 유닉스도 8글자로 제한하던가요?
제가 80년대부터 컴퓨터 만졌던
제가 80년대부터 컴퓨터 만졌던 사람이고요...
운영체제 설계는 당시 하드웨어 수준을 감안해서 하는 것이 당연한거죠.
그걸 가지고 초기 설계가 잘못됐다고 말할 수는 없죠.
후에 하드웨어 수준이 올라가면 운영체제도 그에 따라서 개선되는 것이 맞는거고요.
줄 몇 줄 쓰는 것도 지치네요.
맞는 말입니다. 80년대부터 써온분이면 아시겠지만,
맞는 말입니다.
80년대부터 써온분이면 아시겠지만, 그런 개선 방향이 원래는 OS/2로 나갔었죠. 그뒤에 어떤일이 왜 어떻게 벌어졌는지는 잘 아실거라고 믿습니다. 왜 성능상으로 OS/2가 DOS를 몰아내지 못했는지도 아실거고, 당시 판매되던 386용 유닉스가 OS/2에 비해 성능상 그리고 가격상으로 얼마나 문제가 많았는지도 아실겁니다.
우리나라가 독립이 될 것 같으니까... 최후의
우리나라가 독립이 될 것 같으니까... 최후의 발악이라도 하시는가.. ㅎ
적당히 하셔야지.
90년대 컴퓨터 하드웨어가 8글자로 제한할 만큼의 수준은 아니었죠.
메모리 제한도 그렇고요.
http://en.wikipedia.org/wiki/
http://en.wikipedia.org/wiki/8.3_filename
An 8.3 filename[1] (also called a short filename or SFN) is a filename convention used by old versions of DOS, versions of Microsoft Windows prior to Windows 95, and Windows NT 3.51. It is also used in modern Microsoft operating systems as an alternate filename to the long filename for compatibility with legacy programs. The filename convention is limited by the FAT file system. Similar 8.3 file naming schemes have also existed on earlier CP/M, Atari, and some Data General and Digital Equipment Corporation minicomputer operating systems.
이 당연한 얘기하는데... 이렇게 태클들어오면...누가 kldp 에 글을 쓰려할까요.
...
윈도우 95 98이 80년대에 나왔나요?
8.3을 못버려서 program files 가 progra~1으로 표시되던때입니다.
진짜 답답하게들 사시네요....
xp 부터 컴퓨터쓰셨나...
......
위에 글 태클 아닙니다 ㅎㄷㄷㄷ
글이 길어서 마땅히 달데가 안보이네요.
긴 파일
긴 파일 이름
http://ko.wikipedia.org/wiki/%EC%9C%88%EB%8F%84_95#.EA.B8.B4_.ED.8C.8C.EC.9D.BC_.EC.9D.B4.EB.A6.84
VFAT 파일 시스템을 통해 윈도 95에서 새로 지원하기 시작한 긴 파일 이름 기능을 사용하려면 32비트 파일 접근이 필요했다. 윈도 응용 프로그램은 물론 윈도에서 실행되는 도스용 응용 프로그램에서 긴 파일 이름이 지원되었다. 긴 파일 이름을 사용하려면 더 긴 경로 이름의 버퍼와 새로운 시스템 호출을 사용해야 했기에 약간의 조작이 필요했다. MS-DOS와 경쟁 관계에 있던 도스 호환 운영체제들은 긴 파일 이름을 사용하기 위해 업그레이드가 필요했다. 또한, 긴 파일 이름을 지원하지 않는 종전 버전의 도스용 유틸리티 프로그램을 사용해 파일을 다룰 경우 긴 파일 이름이 없어지는 문제가 있었다. 윈도 3.1x에서 업그레이드하는 경우, 설치되어 있는 도스 유틸리티들 가운데 호환되지 않는 프로그램을 자동으로 찾아 사용되지 않도록 하였다. 긴 파일 이름을 지원하지 않는 오래된 유틸리티(MS-DOS 6.22에 포함된, 조각을 모을 때 쓰는 defrag 등)를 꼭 써야 될 때에는 윈도 95 설치 CD에 함께 제공되는 LFNBACK 프로그램을 가지고 따로 긴 파일 이름을 백업하고 복구해야만 했다.
운영체제 역사를 보면 유닉스가 시조라 할 수
운영체제 역사를 보면 유닉스가 시조라 할 수 있죠.
유닉스 이전에 운영체제라고 일컬을 만한 것이 뭐가 있었을까요.
http://en.wikipedia.org/wiki/Operating_system#History
: ; ! ? , $ # 문자를 정의한 장본인이
: ; ! ? , $ # 문자를 정의한 장본인이 유닉스 입니다 ㅎㅎㅎ
한국 리눅스 문서 프로젝트(KLDP)에서는 MS에
한국 리눅스 문서 프로젝트(KLDP)에서는 MS에 대한 비판들도 못해요?
눈치보면서 글써야 되요? 글 쓸때마다 확실한 근거자료 제시해가면서 글써야 되나요?
MS 기반 개발자들아, 옹호자들아... 당신네들이 일제 강점기 시절 무슨 일본 순사라도 되는줄 아시는 모양인데...
그러는 거 아닙니다.
전산이 정치인줄 아는 초보들이 있는데 좀더 배우면
전산이 정치인줄 아는 초보들이 있는데 좀더 배우면 그게 아니란걸 알게됩니다.
마이크로소프트 욕하면 틀린 말이라도 무조건 자기편 들어줄거라고 생각한다면 큰 착각입니다.
파일 이름 8글자 제한, 웹, J스크립트, 액티브X,
파일 이름 8글자 제한, 웹, J스크립트, 액티브X, cp949, 헝가리 표기법 등
이라고 써놓은 글 보고...
그것이 모두 MS가 먼저 시작했다고 보는 것도 큰 착각이죠.
궤변을 하여 상대방 화나게 하는 것도 당신이고...
그렇게 하여 결론을 유리한 쪽으로 내려고 하는 것도 문제죠.
8글자 제한, J스크립트, cp949 도 역사적 배경이 있는 거고...
제가 그것도 모르고 글을 썼을 거라 생각하시는지..
그러다 토론 격렬해지고 다 밝혀지면... 창피해서 꼬리 내리고 숨으면 끝나는 게임을 원하는 건지.
마조히즘을 원하는 건지. 참.
"MS가 컴퓨팅 환경을 많이 더럽혀놓았죠. 파일
"MS가 컴퓨팅 환경을 많이 더럽혀놓았죠.
파일 이름 8글자 제한, 웹, J스크립트, 액티브X, cp949, 헝가리 표기법 등"
자가기 무슨 말을 했는지 금방 잊어버리는 것도 무슨 병이라고 하더군요. 밝혀진건 8글자 제한이 마이크로소프트가 만들어낸 죄악이 아니라는 것이니까 그동안 "창피해서 꼬리 내리고 숨으면 끝나는 게임을" 원해서 숨어있었나 보군요.
저는 벌써 8글자 제한에 대해 충분히
저는 벌써 8글자 제한에 대해 충분히 써놓았고...
같은 얘기 계속 반복하고 싶지는 않네요.
제금 제가 버로우 타는 거는 같은 얘기 계속 반복하게 하여 피곤해서 그런거지...
창피해서 숨는게 아니에요. 에혀 내 팔자야.
웹, J스크립트, cp949에 대해 태클 안 걸은 것이 참 고맙네요.
네 그러세요. 정신 승리 인정해드립니다. 무식이
네 그러세요.
정신 승리 인정해드립니다.
무식이 탄로나니까 억지쓰다가 그래도 역사적 진실에 상대가 안되니까 정치적으로 선동하려고 들던거에 비하면 장족의 발전이십니다.
역사적
역사적 진실
http://en.wikipedia.org/wiki/Comparison_of_file_systems
거기보면 긴 파일이름을 지원하는 파일시스템은 MS-DOS 이전부터 있었습니다.
http://en.wikipedia.org/wiki/Berkeley_Fast_File_System
FFS Kirk McKusick 1983 4.2BSD
HFS Apple Computer 1985 Mac OS
FFS 255 bytes
HFS 31 bytes
1983년 보여요????
거봐요... 궤변이라는 것이 또 이렇게 밝혀졌잖아요.
이제 저는 논쟁을 마치고 편안하게 버로우나 타겠습니다.
http://en.wikipedia.org/wiki/
http://en.wikipedia.org/wiki/MS-DOS
MS-DOS가 1981 나왔다고 하는군요. 에혀...
위 댓글 써놓은 사람인데요..
아무튼 오래 전부터 긴 파일 이름이 있었고...
8글자 제한은 MS-DOS, 윈95 덕분에 90년대.. 2000년대 초까지 영향을 끼치게 됩니다.
90년대 유닉스, 유닉스 호환 운영체제들은 긴 파일이름 쓰고 있었고요.
그걸 이야기 하는 겁니다.
아무튼 편안하게 버로우 타겠습니다.
ms-dos 는 그 이전에 있던 cp/m의 불법
ms-dos 는 그 이전에 있던 cp/m의 불법 해적판 이었습니다만...
CP/M과 유닉스 때문에 8글자 제한이... 90년대
CP/M과 유닉스 때문에 8글자 제한이... 90년대 후반, 2000년대 초까지 있었다고 합시다.
그러게 왜 모르면서 나와서 자꾸 잘난척하다가 망신을
그러게 왜 모르면서 나와서 자꾸 잘난척하다가 망신을 당해요 ㅋㅋㅋ
윈95는 256자에 드라이브 명까지 집어넣어서 260자까지 사용하게 해줬는데 이런거 좀 써보고서 잘난척을 해야죠. 차라리 OS/2가지고 잘난척 했으면 그래도 뭐 좀 써봤나보다 해줄텐데, 이건 뭐...
윈95,98이 DOS 위에서 돌아가잖아요. 에혀...
윈95,98이 DOS 위에서 돌아가잖아요. 에혀...
거참 무식을 이렇게까지 자랑하고 싶어하는 어린 학생은
거참 무식을 이렇게까지 자랑하고 싶어하는 어린 학생은 처음 봤네요.
그 시절에 프로그램 짜서 된다는 것을 경험으로 알고 있는 사람에게 이렇게까지 들이대다니.
대단하세요. 미래가 촉망되는군요.
다른 운영체제들은 80년대 긴 파일로
다른 운영체제들은 80년대 긴 파일로 갈아타내요...
http://en.wikipedia.org/wiki/Filename
http://en.wikipedia.org/wiki/Comparison_of_file_systems
그냥...
CP/M과 유닉스 때문에 8글자 제한이... 90년대 후반, 2000년대 초까지 있었다고 합시다.
그냥 하겠다는대로 버로우해요. 자꾸 무식한걸 자랑하지
그냥 하겠다는대로 버로우해요.
자꾸 무식한걸 자랑하지 말고.
보는 내가 다 안타까와요.
유닉스도 80년대에 긴 파일로 갈아타네요.
유닉스도 80년대에 긴 파일로 갈아타네요.
논쟁을 하려거든 좀 재밌게 합시다. 이건 뭐 애덜
논쟁을 하려거든 좀 재밌게 합시다.
이건 뭐 애덜 쌈보는것같아 지겹네요.
미안해요. 논쟁이 아니라 사실의 확인의 문제인데
미안해요.
논쟁이 아니라 사실의 확인의 문제인데 일지도 못하면서 자꾸 틀린 말하는 사람이 있네요.
"파일 이름 8글자(제한)"을 MS가 최초로
"파일 이름 8글자(제한)"을 MS가 최초로 시작했다.
"웹"을 MS가 최초로 시작했다.
"J스크립트"를 MS가 최초로 시작했다.
"액티브X"를 MS가 최초로 시작했다.
"cp949"을 MS가 최초로 시작했다.
"헝가리 표기법"을 MS가 최초로 시작했다.
이렇게 이해하시는 분이 있네요...
익명1: 파일 이름 8글자 제한은 MS 때문에 장기간 지속되었다.
vs
익명2: 파일 이름 8글자 제한은 유닉스로부터 온거다. MS 때문이 아니다.
그러니까 제 말뜻은 논쟁 하지 말라는게 아니라..
그러니까 제 말뜻은 논쟁 하지 말라는게 아니라.. 말끝마다 KLDP에서는 원래 이래 저래 그러는데....
참.. KLDP초창기 맴버들이 이런 글 볼때면 참...
원래부터 그런건 없습니다. 이쪽 사람들이 원래 치고받고하길 좋아하지만, 이제는 나이 먹을만큼 먹어서 그냥 이런 글 봐도 그러려니 하죠.
90년도 20줄 이던 사람이 벌써 20년가까이나 흘러버렸으니...;;
그러니까 논쟁이 아니라니까요. 이미 벌어진 역사적
그러니까 논쟁이 아니라니까요.
이미 벌어진 역사적 사실을 모르는 뉴비가 역사적 사실은 그게 아니라 이렇다고 얘기해주니까 그걸 못받아들이고 광분하는거죠. 논쟁은 서로 관점에 따라 맞을 수도 있는 것을 말하는거지 일방적으로 한쪽이 계속 틀리는건 논쟁이 아니잖아요.
잘 보세요. 역사적 사실 하나 적어주면 자꾸 DOS이후에 벌어진 일들을 가지고 와서는 DOS가 나올때 이미 그걸 예견하고 8086에 돌아가는 운영체제에 집어넣었어야 한다고 우기는 어린이가 있잖아요. 심지어 윈95가 긴 파일 이름 지원한다고 엄청나게 선전했고 그걸 사용했던 사람이 버젓이 있는데 그게 아니라고 떼쓰는 어린이가 있다구요.
아무리 봐도 이 사람이 과대해석하고 있는 것
아무리 봐도 이 사람이 과대해석하고 있는 것 같은데..
legacy의 책임을 MS탓으로 돌리는 저 댓글은, legacy의 원조가 DOS라거나, 긴파일 이름을 "DOS가 나올 때 예견하고 넣었어야 한다"고까지 주장하고 있지는 않다. 그저 MS 탓만 하고 있을 뿐. 이후 이어진 댓글들에서 원 저자는 legacy가 지속된 것이 MS의 탓이라고 좀 더 구체화된 주장을 펼치고 있다. 이 주장의 타당성 여부(legacy가 지속된 것이 MS의 탓이냐, 또 legacy가 지속된 것이 꼭 나쁘기만 한 것이냐 등)을 떠나, 주장 자체로는 성립가능하다. 논쟁이 가능하다.
반면 이 사람은 상대방이 하지 않은 주장을 예측하여 반론하는 허수아비 공격의 오류를 지속하고 있다. 상대방을 뉴비, 정신승리 운운으로 깎아내리며 상대적으로 올드비(?)임을 내세울 뿐, legacy의 원조가 MS/DOS가 아니라는 점 한가지에만 집착하고 있기에 논쟁이 더이상 지속될 수 없다.
논쟁이 아니라는게 이해가 안되는 모양이군요. 역사적
논쟁이 아니라는게 이해가 안되는 모양이군요. 역사적 사실은 이미 벌어졌기때문에 정확히 아느냐 아니냐의 문제이지, 관점에 따라 주장하는 문제가 아니라구요. 논쟁이 지속 안되는게 아니라 처음부터 성립하지 않아요. 무슨 독립운동 운운에 KLDP에서는 MS눈치보지 말아야한다고 논점(이란게 존재했었다면)을 광탈할 정도로 횡설수설하는 것을 주장이 성립한다고 본다면 그게 심각한 오류인거죠.
역사관 http://ko.wikipedia.org/w
역사관
http://ko.wikipedia.org/wiki/%EC%97%AD%EC%82%AC%EA%B4%80
역사관은 간단하게 정의하면 '역사의 발전 법칙에 대한 체계적인 견해' 로, 사관이라고도 하며 다양한 역사관이 존재한다. 역사관은 역사가의 역사에 대한 이해, 해석원리, 가치관, 관념등을 포함하는 개념이다. 역사관은 시대에 따라, 사람에 따라 달라질 수 있다. 왜냐하면 사회상과 사람의 가치관에 따라 역사관은 얼마든지 달라질 수 있기 때문이다. 역사관은 역사연구에 의해 확인되고, 발전하게 된다.
지금 역사적 사실이 역사관에 따라 달라진다고 떼쓰는게
지금 역사적 사실이 역사관에 따라 달라진다고 떼쓰는게 주장이라고 우기는건가요? 어처구니가 없군요. 하긴, 역사적 사실을 가르쳐주니까 궤변이라고 떼쓰는거가 벌써 객관적 사실과 주관적 주장을 구분하지 못하는 수준인걸 인증한건데 여기서 놀라는게 더 이상하네요.
역사적 사실을 모르는데 무슨 역사적 해석을 하고 주장을 한다는건지 역사가 전공이라면 설명좀 부탁합니다.
역사에 전혀 무지한 상대이니까 역사를 깡그리 무시하고 기술부분만 얘기합시다. DOS가 대상으로 삼아 개발한 기계는 16비트 8086에 160KB 단면 플로피 두개가 달린 기계라는건 아나요? 중간에 시간적으로 DOS보다 더 뒤에 나온 BSD FFS링크 가져왔을때, BSD가 32비트 VAX에서 당시로서는 거대한 하드디스크 달고 돌아가던 32비트 운영체제인건 알아요? 그렇게 엄청나게 차이가 나는 기계에서 돌아가는 운영체제의 디자인 결정이 (역사적 선후를 다 무시하고) 단순히 파일 이름 길이만 비교해보면 다 알거 같죠? 엄청난 초절고수 하나 나셨네요.
일요일이라고 괜히 무식한 트롤에게 먹이줬다가 엄청 우스운꼴을 당하네요. 거참.
정신승리의 표본~ ㅎㅎ 애초에 원 글 자체가 막
정신승리의 표본~ ㅎㅎ
애초에 원 글 자체가 막 내던진 글이라, legacy를 MS가 만들었다는 주장을 하진 않았지만 또 그렇게 읽을 수도 있는 글이었다. 따라서 이 분처럼 MS가 그걸 만든 게 아니라고 지적하는 것 자체는 충분히 있을 수 있는 일이었다.
다만 이후 상대가 뭘 주장하려는지 세심하게 살피려는 노력을 기울이지 않고, 자기 경력을 내세워 상대를 뭘 모르는 정치꾼 정도로 간단히 깔아뭉개려다보니 발을 뺄 타이밍을 놓친 것이지 ㅎㅎ
걍 처음부터 "MS가 모든 것의 원흉인 것처럼 쓰셨지만 꼭 그런 건 아닙니다"정도의 유연한 태도로 나갔다면 자존심 상하지 않고 좋은 모양새로 마무리할 수 있었을텐데..
긴 파일이름은 8bit Apple DOS 3.3에서도
긴 파일이름은 8bit Apple DOS 3.3에서도 지원하던 건데요.
단순히 머신의 성능차이 가지고 이야기하긴 좀..
제가 봐도 그렇네요. 계속 역사를 제대로 모르니
제가 봐도 그렇네요.
계속 역사를 제대로 모르니 제대로 알고 말하라는 투로 상대를 깎아내리지만, 본인은 정작 그 사람이 무얼 말하는지 요점을 모르는 것처럼 보입니다.
MS 탓을 하는 이유가 다른 OS 들은 일찍부터 긴 파일이름을 지원하도록 바꿨는데, 대중에게 널리 퍼졌던 DOS는 파일 길이 제한을 오랫동안 유지해서 좋지 않은 영향을 끼쳤다는 이야기인 것 같은데요...
윗 분 말씀처럼 그 파일길이제한의 원조가 DOS 가 아니라는 사실에만 집착하고 있네요.
논쟁이 계속 될 수가 없네요.
그런데 이런 사람들 종종 있는 것 같습니다.
zip 압축파일 푸는 프로그램의 버그로
zip 압축파일 푸는 프로그램의 버그로 생각되는군요.
zip파일을 무슨 프로그램으로 압축을 푸는데 안되셨다는 것인지요?
오마이... LoL;;
이거 원...
제딴에는 '팁 꺼리'도 안된다고 생각해서 대충 올린 글인데, 둘 이상의 익명님들 덕분에(설마 혹시 동일인..?!) 흥행대박이네요.. 감사(?)합니다;; >_<
아, 글구 바로 위에 익명님께::
-- 이 경우는 압축 풀어주는 프로그램의 문제라기보다 "압축 파일 속에 들어있는, FAT에서 허용 안되는 이름을 갖는 파일들" 문제라고 할 수 있죠. 물론 unzip 유틸리티가 그 상황을 친절하게 설명해 주지 않고 그냥 "에러났3!"이라는 메시지만 달랑 던져준 것도 문제라면 문제겠지만..
유저에서 난감한 경험을 하게 했으니 버그에
유저에서 난감한 경험을 하게 했으니 버그에 한표입니다.
적어도 허용안되는 값이 있으니 못푼다라고 알려주거나
혹은 허용안되는 값을 "_" 혹은 "-"로 치환해서 푸는 옵션을 제공하고 이를 간단하게라도 알려주면 더욱 좋겠죠.
일부 웹브라우져 혹은 php프로그램에서 공백이나 허용안되는 파일이름 값을 "_" 등으로 치환하는 것처럼.
이와는 반대의 경험이 있는데... 리눅스에서 만든
이와는 반대의 경험이 있는데...
리눅스에서 만든 파일이름이 우연찮게 : 가 포함되었는데...
윈도우에서는 지울수가 없었습니다.
가만히 생각해보니... 파일시스템을 설계한건 MS
가만히 생각해보니...
파일시스템을 설계한건 MS 이므로...
운영체제가 무엇이었건... MS의 파일시스템을 사용한다면
따라주어야 하는게 도리?인듯하네요.
씨디 립하다보면 이것 때문에 무지 짜증나죠.
씨디 립하다보면 이것 때문에 무지 짜증나죠.
거꾸로 요즘 가요 mp3들은 파일이름에 왜 ' 대신 `을 쓰는지 모르겠어요. 리눅스 유저 입장에서 진짜 짜증납니다.