흥미롭네. 내 시대 이전 일이라 CP/M 프로그램을 패치로 설정했다는 건 들어본 적이 없었음
맞음, 실제로 그런 방식이 있었고 패치 코드는 Z80/8080 기계어여야 했음
이 기능으로 내 WordStar에 더 빠른 키보드·화면 출력 루틴을 직접 작성했음
맞음, 실제로 있었고, 원래 CP/M 프로그램이던 일부 프로그램은 DOS용 WordStar 7.0까지도 오래 이어졌음
WordStar 7 문서에는 DOS의 debug.exe로 프로그램 동작을 바꾸는 데 쓸 패치 위치가 포함돼 있었던 것으로 기억함
지금도 어느 정도는 남아 있음. suckless가 만드는 것들은 보통 config.h를 바꾸고 다시 컴파일해서 설정함 https://suckless.org/
덧붙이면, 이 페이지의 다른 하위 스레드에서 이미 언급된 걸 뒤늦게 봤음
그 방식이 필요했던 건 RAM과 디스크 공간이 극도로 제한적이었고, 거의 모든 컴퓨터에 어셈블러가 딸려 있었기 때문임
많은 CP/M 프로그램은 32K RAM과 느린 130K 플로피, 심하면 카세트테이프에서도 돌아가야 했음. 64K RAM과 360K 디스크가 있으면 꽤 특별한 축이었음
당시에는 오늘날과 달리 프로그램을 시장 상단이 아니라 하단에 맞춰 최적화했음. 더 많은 시스템에서 돌아가야 더 많이 팔 수 있었고, 고객에게 하드웨어를 업그레이드하라고 떠넘기지 않았음
외부 설정 파일이나 그 설정 파일을 만드는 프로그램을 둘 공간 자체가 없었고, 명령줄 인자 처리조차 귀한 바이트를 잡아먹었음
요즘은 MacBook Neo의 RAM이 8,000,000,000바이트밖에 안 된다고 불평하지만, 1978년에는 2,048바이트짜리 기본 IDE도 만들 수 있었음
Raymond의 블로그는 좋아하지만, 1973년에 마이크로컴퓨터에서 CP/M이 흔했다는 건 이상함
1973년의 마이크로컴퓨터는 Intel Intellec 같은 개발 시스템 수준의 시제품에 가까웠고, 운영체제도 없었음. Kildall이 CP/M 개발을 1973년에 시작한 건 맞지만, 그때는 PDP-10 메인프레임의 시뮬레이터에서만 돌아갔음
1979년이면 몰라도 1973년은 너무 이름
Wikipedia에는 CP/M이 1974년에 만들어졌다고 되어 있으니, 여기의 시간표는 확실히 어긋나 있음
1979년과 1973년의 차이가 지금의 2020년과 현재 사이 차이와 같다는 점이 재밌음
그러고 보면 2020년에는 ChatGPT가 없었다고 생각하게 됨
초기 개발자가 거의 고민하지 않고 내린 결정이 수십 년 동안 남는 좋은 예임
잠깐 다뤘던 S&P500 제품의 핵심 테이블 하나는 앞으로도 영원히 attornies라는 이름일 것임. 초기에 아무도 오타를 잡지 못했기 때문임
TMPorary 결정만큼 영구적인 것도 없음
프로그램들이 TMP를 고른 건 MS-DOS의 파일 확장자가 최대 3글자였고, 임시 파일 이름에 .TMP 확장자를 쓰던 관행 때문일 가능성이 큼
Unix 프로그램들이 http_proxy를 볼지 HTTP_PROXY를 볼지 일관되지 않았던 것과 비슷함
요즘은 많은 프로그램이 둘 다 보지만, 확인 순서는 같지 않을 수 있음
CP/M 언급이 헷갈림. 글쓴이는 나중에 중요해질 거라고 해놓고, 결국 CP/M이나 8080 CPU와는 관련이 없었다고 설명하는 것처럼 보임
동의함. 이 이야기는 CP/M도, 8080/8086으로 빠지는 곁가지도 별 관련이 없음
핵심은 Microsoft가 직접 쓰면서도 표준화할 생각을 안 했다는 것뿐임
CP/M이 설정에 환경 변수를 썼다면, TMP와 TEMP 중 무엇을 쓸지 이미 표준이 생겼고 DOS가 그걸 따랐을 것임
다만 진짜 걸림돌은 CP/M에는 디렉터리가 없었고, DOS 1.0에도 없었다는 점임
어느 문장을 말하는 건지 인용해 줄 수 있음?
1995년쯤 Telstra, 즉 Australia Telecom에서 조직 전체에 데스크톱이 약 5만 대 있었음
어느 날 모두의 네트워크 홈 디렉터리에 null이라는 작은 파일이 생겼고, 아마도 Unix 사용자가 .bat 파일을 작성해 본 듯했음
이미 존재하는 표준을 왜 따라야 하냐는 얘기임. “왜 표준화해야 하냐”고 묻고 싶었지만, 북미 사람들을 헷갈리게 할 수도 있겠다고 생각했음
아마 처음에는 /dev/null을 시도했다가 실패해서 그냥 null로 바꾼 것 같음
그렇지 않다면 Unix 프로그래머가 그랬다는 게 말이 안 됨. 오히려 DOS 프로그래머가 NUL을 null로 잘못 썼을 가능성이 큼
버리려고 했던 텍스트가 뭐였는지 궁금함
어떤 Logitech 드라이버 설치 프로그램도 비슷한 일을 했음
하드디스크에서 NULL이라는 파일을 찾았고, 당연히 .BAT 파일 안에는 > NULL 같은 구문이 있었음
솔직히 많은 프로그램에서 홈 디렉터리에 닷파일을 흩뿌리는 방식보다 CP/M식 패치 설정이 더 나았을 것 같음
사람들이 XDG Base Directory Specification만 지키면 설정 파일 난립은 문제가 되지 않음
Firefox 같은 버티던 프로젝트까지 포함해 점점 더 많은 프로젝트가 채택하고 있음
약간 특이한 suckless 쪽 철학 중 하나가, 프로젝트를 대체로 소스 코드를 바꾸고 다시 컴파일해서 설정한다는 것임
현대 오픈소스식으로 보면 비슷한 접근이라고 할 수 있음. 다만 전반적인 금욕주의 때문에 프로젝트들이 취향을 좀 탈 것 같음
원래는 전부 .config 안에 있어야 함
문제는 많은 앱 개발자들이 자기 앱만은 특별해서 별도 디렉터리를 가질 자격이 있다고 생각한다는 것임
중앙의 바이너리 레지스트리 여기저기에 흩어진 설정보다는, grep하고 텍스트 편집기로 관리할 수 있는 닷파일이 낫다고 봄
어쩌면 그냥 익숙해서 그럴 수도 있음
이런 건 표준화됐으면 좋겠음. 어떻게든 .config 폴더를 강제할 수 있는 배포판이 있다면 나에게는 승자임
다만 이미 타이밍을 놓친 것 같기도 함
이렇게 혼란스러운 줄은 몰랐음
교훈은 아마 항상 같은 경로를 가리키게 하라, 아니면 큰일 난다는 것임
Microsoft의 이런 짜증나는 것들을 수십 년 동안 짚어 왔음
예전에는 거기서 모든 걸 안다는 듯한 “시니어 개발자”가 늘 답을 갖고 있었음. “temp는 temporary고 tmp는 troubleshoot my pc, 디버그 로그용이야. 그래서 내가 시니어고 넌 아니지” 같은 식이었음
내가 더 시니어가 되고 보니 의문을 제기한 게 맞았고, 이제는 원래 Microsoft 개발자들과 이야기해 보면 실수였지만 하위 호환성 때문에 유지했다고 설명함
그런데 그 변명이 왜 유효한지 묻게 됨. 하위 호환성을 이유로 삼으면서도 New Outlook처럼 핵심 호환성과 실제 업무 흐름을 자주 깨는 변경은 그대로 밀어붙이기 때문임. 그러면 “나는 나쁜 개발자가 아니니 새 사람들에게 물어보라”고 빠짐
새 사람들에게는 물어볼 수도 없고, 그들은 LeetCode 선발 장벽 뒤에 숨어 있음. 그래서 이런 실제 문제가 고쳐지지 않고 New Outlook 같은 게 나오는 것도 이상하지 않음. 예전의 그 시니어 개발자가 이제 거기서 일하고 있고, 진짜 개발자들은 은퇴했음
사용자 홈의 Documents 폴더를 임의 프로그램이 부적절하게 쓰거나 OneDrive가 실수로 강제로 지워 버리는 문제에 대해 Microsoft에서 그럴듯한 답을 받아도, 6개월 안에 Microsoft가 무작위 변경을 밀어 넣어 동작을 안 좋은 방향으로 바꾸면서 그 핵심 논리를 무너뜨림
Notepad도 비슷함. 개발자 인터뷰에서는 위험이 0이어야 하므로 아주 단순한 프로그램이어야 한다고 말했는데, 나중에는 Microsoft 계정 로그인과 Copilot이 붙었음
LeetCode식 개발자 태도와 Microsoft 문화가 업계 전체를 망친다고 봄. 차분한 토론이 안 되고, “넌 Microsoft에서 일하지 않으니 네 주장은 무효”로 흘러감
Google Chrome이 관리자 권한을 우회하려고 AppData에 설치되던 일은 강하게 기억에 남음. 그 기능의 본래 의도가 제3자가 관리자 권한 없이 설치하려는 데 쓰라는 건 분명 아니었음
하지만 당시 Chrome이 좋았고, 잠긴 기업 컴퓨터 수백만 대에 제3자 예외 프로그램을 배포하는 혼란을 처리해야 했으니, 개발자들은 이제 그걸 의도된 기능으로 다시 포장하고 있음
Hacker News 의견들
흥미롭네. 내 시대 이전 일이라 CP/M 프로그램을 패치로 설정했다는 건 들어본 적이 없었음
이 기능으로 내 WordStar에 더 빠른 키보드·화면 출력 루틴을 직접 작성했음
WordStar 7 문서에는 DOS의
debug.exe로 프로그램 동작을 바꾸는 데 쓸 패치 위치가 포함돼 있었던 것으로 기억함config.h를 바꾸고 다시 컴파일해서 설정함https://suckless.org/
덧붙이면, 이 페이지의 다른 하위 스레드에서 이미 언급된 걸 뒤늦게 봤음
많은 CP/M 프로그램은 32K RAM과 느린 130K 플로피, 심하면 카세트테이프에서도 돌아가야 했음. 64K RAM과 360K 디스크가 있으면 꽤 특별한 축이었음
당시에는 오늘날과 달리 프로그램을 시장 상단이 아니라 하단에 맞춰 최적화했음. 더 많은 시스템에서 돌아가야 더 많이 팔 수 있었고, 고객에게 하드웨어를 업그레이드하라고 떠넘기지 않았음
외부 설정 파일이나 그 설정 파일을 만드는 프로그램을 둘 공간 자체가 없었고, 명령줄 인자 처리조차 귀한 바이트를 잡아먹었음
요즘은 MacBook Neo의 RAM이 8,000,000,000바이트밖에 안 된다고 불평하지만, 1978년에는 2,048바이트짜리 기본 IDE도 만들 수 있었음
Raymond의 블로그는 좋아하지만, 1973년에 마이크로컴퓨터에서 CP/M이 흔했다는 건 이상함
1973년의 마이크로컴퓨터는 Intel Intellec 같은 개발 시스템 수준의 시제품에 가까웠고, 운영체제도 없었음. Kildall이 CP/M 개발을 1973년에 시작한 건 맞지만, 그때는 PDP-10 메인프레임의 시뮬레이터에서만 돌아갔음
1979년이면 몰라도 1973년은 너무 이름
그러고 보면 2020년에는 ChatGPT가 없었다고 생각하게 됨
초기 개발자가 거의 고민하지 않고 내린 결정이 수십 년 동안 남는 좋은 예임
attornies라는 이름일 것임. 초기에 아무도 오타를 잡지 못했기 때문임프로그램들이
TMP를 고른 건 MS-DOS의 파일 확장자가 최대 3글자였고, 임시 파일 이름에.TMP확장자를 쓰던 관행 때문일 가능성이 큼Unix 프로그램들이
http_proxy를 볼지HTTP_PROXY를 볼지 일관되지 않았던 것과 비슷함요즘은 많은 프로그램이 둘 다 보지만, 확인 순서는 같지 않을 수 있음
CP/M 언급이 헷갈림. 글쓴이는 나중에 중요해질 거라고 해놓고, 결국 CP/M이나 8080 CPU와는 관련이 없었다고 설명하는 것처럼 보임
핵심은 Microsoft가 직접 쓰면서도 표준화할 생각을 안 했다는 것뿐임
TMP와TEMP중 무엇을 쓸지 이미 표준이 생겼고 DOS가 그걸 따랐을 것임다만 진짜 걸림돌은 CP/M에는 디렉터리가 없었고, DOS 1.0에도 없었다는 점임
1995년쯤 Telstra, 즉 Australia Telecom에서 조직 전체에 데스크톱이 약 5만 대 있었음
어느 날 모두의 네트워크 홈 디렉터리에
null이라는 작은 파일이 생겼고, 아마도 Unix 사용자가.bat파일을 작성해 본 듯했음이미 존재하는 표준을 왜 따라야 하냐는 얘기임. “왜 표준화해야 하냐”고 묻고 싶었지만, 북미 사람들을 헷갈리게 할 수도 있겠다고 생각했음
/dev/null을 시도했다가 실패해서 그냥null로 바꾼 것 같음그렇지 않다면 Unix 프로그래머가 그랬다는 게 말이 안 됨. 오히려 DOS 프로그래머가
NUL을null로 잘못 썼을 가능성이 큼하드디스크에서
NULL이라는 파일을 찾았고, 당연히.BAT파일 안에는> NULL같은 구문이 있었음솔직히 많은 프로그램에서 홈 디렉터리에 닷파일을 흩뿌리는 방식보다 CP/M식 패치 설정이 더 나았을 것 같음
Firefox 같은 버티던 프로젝트까지 포함해 점점 더 많은 프로젝트가 채택하고 있음
현대 오픈소스식으로 보면 비슷한 접근이라고 할 수 있음. 다만 전반적인 금욕주의 때문에 프로젝트들이 취향을 좀 탈 것 같음
.config안에 있어야 함문제는 많은 앱 개발자들이 자기 앱만은 특별해서 별도 디렉터리를 가질 자격이 있다고 생각한다는 것임
grep하고 텍스트 편집기로 관리할 수 있는 닷파일이 낫다고 봄어쩌면 그냥 익숙해서 그럴 수도 있음
.config폴더를 강제할 수 있는 배포판이 있다면 나에게는 승자임다만 이미 타이밍을 놓친 것 같기도 함
이렇게 혼란스러운 줄은 몰랐음
교훈은 아마 항상 같은 경로를 가리키게 하라, 아니면 큰일 난다는 것임
Microsoft의 이런 짜증나는 것들을 수십 년 동안 짚어 왔음
예전에는 거기서 모든 걸 안다는 듯한 “시니어 개발자”가 늘 답을 갖고 있었음. “
temp는 temporary고tmp는 troubleshoot my pc, 디버그 로그용이야. 그래서 내가 시니어고 넌 아니지” 같은 식이었음내가 더 시니어가 되고 보니 의문을 제기한 게 맞았고, 이제는 원래 Microsoft 개발자들과 이야기해 보면 실수였지만 하위 호환성 때문에 유지했다고 설명함
그런데 그 변명이 왜 유효한지 묻게 됨. 하위 호환성을 이유로 삼으면서도 New Outlook처럼 핵심 호환성과 실제 업무 흐름을 자주 깨는 변경은 그대로 밀어붙이기 때문임. 그러면 “나는 나쁜 개발자가 아니니 새 사람들에게 물어보라”고 빠짐
새 사람들에게는 물어볼 수도 없고, 그들은 LeetCode 선발 장벽 뒤에 숨어 있음. 그래서 이런 실제 문제가 고쳐지지 않고 New Outlook 같은 게 나오는 것도 이상하지 않음. 예전의 그 시니어 개발자가 이제 거기서 일하고 있고, 진짜 개발자들은 은퇴했음
사용자 홈의 Documents 폴더를 임의 프로그램이 부적절하게 쓰거나 OneDrive가 실수로 강제로 지워 버리는 문제에 대해 Microsoft에서 그럴듯한 답을 받아도, 6개월 안에 Microsoft가 무작위 변경을 밀어 넣어 동작을 안 좋은 방향으로 바꾸면서 그 핵심 논리를 무너뜨림
Notepad도 비슷함. 개발자 인터뷰에서는 위험이 0이어야 하므로 아주 단순한 프로그램이어야 한다고 말했는데, 나중에는 Microsoft 계정 로그인과 Copilot이 붙었음
LeetCode식 개발자 태도와 Microsoft 문화가 업계 전체를 망친다고 봄. 차분한 토론이 안 되고, “넌 Microsoft에서 일하지 않으니 네 주장은 무효”로 흘러감
Google Chrome이 관리자 권한을 우회하려고
AppData에 설치되던 일은 강하게 기억에 남음. 그 기능의 본래 의도가 제3자가 관리자 권한 없이 설치하려는 데 쓰라는 건 분명 아니었음하지만 당시 Chrome이 좋았고, 잠긴 기업 컴퓨터 수백만 대에 제3자 예외 프로그램을 배포하는 혼란을 처리해야 했으니, 개발자들은 이제 그걸 의도된 기능으로 다시 포장하고 있음