Linux에서 일부 명명 규칙이 왜 그렇게 일관성이 없습니까? [폐쇄]

Linux에서 일부 명명 규칙이 왜 그렇게 일관성이 없습니까? [폐쇄]

Linux에서 로깅, 변경 로그, 추가 정보 파일 및 구성 파일의 공통 풀 이름 지정은 매우 일관성이 없는 것 같습니다. 이것은 항상 궁금합니다. 왜 *nix 개발자들은 오래 전에 범용 파일 이름 패턴을 사용하기로 결정하지 않았습니까? 파일(예를 들어 구성)의 이름이 어떻게 지정되는지 정확히 기억해야 한다는 것이 불필요하게 짜증나는 일이라는 것을 알았습니다.

예를 들어 구성 명명 규칙은 다음과 같습니다. this, this.cnf, this.conf, this.config또는 둘 다 모두 밑줄 this_config영역에 속하지 않으며 때로는 Windows this.cfg스타일에 속하기도 합니다. 위의 다양성을 고려할 때 가장 널리 사용되는 구성 이름 지정 방법은 무엇입니까? 로그, 변경 로그, 추가 정보 파일 등에 대해서도 마찬가지입니다.

대부분의 스크립트와 바이너리는 잘 배치되어 있고 일관된 패턴을 가지고 있는 것으로 보입니다. 그렇다면 구성이 어려운 이유는 무엇일까요? 개발 군중을 명명 규칙 진영으로 나누는 일이 당시 진행되고 있었습니까? 아니면 Linux의 개방성과 자유 정신 접근 방식으로 인해 이와 같은 "레벨 3" 일관성을 추구할 가치가 없었습니까?

답변1

위의 다양성을 고려할 때 가장 널리 사용되는 구성 이름 지정 방법은 무엇입니까?

당신이 그들을 부르고 싶은 것은 무엇이든. 파일 확장자는 관리자에게 파일이 무엇인지 알려주는 것 외에는 중요하지 않습니다. 인간은 이것을 알 수도 있고 *.cfg*.conf다 프로필일 수도 있습니다.

저는 *.cnf이것을 MySQL에서만 보았습니다. 일회성 차이이므로 MySQL/MariaDB 개발자에게 문의해야 합니다.

개발 군중을 명명 규칙 진영으로 나누는 일이 당시 진행되고 있었습니까? 아니면 Linux의 개방성과 자유 정신 접근 방식으로 인해 이와 같은 "레벨 3" 일관성을 추구할 가치가 없었습니까?

이것은 아마도 대부분의 사람들이 중요하다고 생각하는 것이 아닐 것입니다. 이제 대부분의 사람들은 ( , , , / 등) *.conf을 선택 하지만 파일 경로에 몇 개의 문자만 포함될 수 있는 경우에는 이 방법을 선호할 수 있습니다. 이름이 변경되지 않은 것과 같은 이유로 변경되지 않았을 수도 있으며 관심 있는 대부분의 사람들은 문제의 파일이 무엇을 하는지 이미 알고 있습니다.nginxudevapachersyslogsyslog-ng*.cfg/etc/fstab

답변2

그날 무슨 일이라도 있었나요?그 구분개발자들이 모여든다...캠프...?

시간순서를 거꾸로 보면 될 것 같습니다. "과거에는" "유닉스 개발 집단"이 AT&T 벨 연구소에 있었습니다. (플럭스 커패시터에 충분한 전력을 공급한다면 "유닉스 개발 집단"이 단지 두 사람에 불과했던 시절로 돌아갈 수 있을 것입니다. 제가 아는 바로는 두 사람이 사무실을 공유했을 것입니다.) UC Berkeley(및 기타 , 잘 알려지지 않은 대학)이 이를 수정하기 시작했고 IBM, Sun 및 Oracle과 같은 회사가 이에 동참했습니다(Xenix, AIX 및 Solaris와 같은 제품 만들기). 모든 회사(예: Sybase)는 포함되지 않습니다. ) 방금 Unix용 애플리케이션을 작성했습니다. (바라보다POSIX란 정확히 무엇입니까? Unix/POSIX에 대한 더 많은 배경/역사. )

이러한 개발자는 (1) 경쟁 조직에서 일하기 때문에 서로가 무엇을 하고 있는지 모르고, (2) 자신의 방식이 더 낫다고 생각하고 사용자에게 통합된 경험을 제공하는 데 관심이 없으며, (3) 의도적으로 선택합니다. 시장 분할 목적을 달성하기 위해 임의로 호환성을 갖지 않는 것입니다. (어떤 사람들은 IBM이 고객을 Unix에서 벗어나 자신의 독점 운영 체제로 돌아가게 하기 위해 전략적으로 Unix 시장을 정글로 만들었다고 주장합니다.) 이것은 Linux 유산의 일부일 뿐입니다.

그렇다면 왜 이 문제가 "수정"되지 않았습니까? 글쎄요, 당신이 말했듯이 "고장나지 않았다면 고치지 마세요." 제품(예: mySQL) 내의 하위 호환성은 제품 간의 수평 호환성보다 더 가치 있다고 간주될 수 있습니다.

관련 정보