GoboLinux의 아이디어가 주류 리눅스 커뮤니티에서 받아들여지지 않은 것이 아쉬움. 리눅스 파일시스템 구조는 완전히 혼란스러움.
GoboLinux는 전통적인 경로를 GoboLinux에 해당하는 경로로 매핑하여 유닉스 유산과의 호환성을 투명하게 유지함. /bin은 /System/Index/bin으로 링크되어 있고, /usr/bin, /usr/sbin 등 모든 "바이너리" 디렉토리가 같은 장소를 가리킴. 이는 일부 표준적인 배포판보다 더 호환성이 높다는 것을 의미함.
파일시스템이 정말 필요하다면 라이브러리의 중복 복사본을 제거할 수 있음. 파일 수준의 중복성은 그 수준에서 해결되어야 함.
이 프로젝트는 우리의 인지 부하를 크게 줄일 수 있는 잠재력을 가짐. 이미 20년간 진행된 프로젝트임을 알게 됨.
디렉토리 이름의 첫 글자를 대문자로 쓰는 것은 좋지 않음. 경로를 탐색할 때 추가 작업이 되며, 특히 명령줄 사용 시 매번 Shift 키를 눌러야 하므로 번거로움.
GoboLinux 팀은 사람이 이해하기 쉬운 파일시스템 레이아웃을 "지능적으로" 만들어냄. 오래된 UNIX 관습은 더 이상 저장 공간 부족이나 1GB 이상의 파일 크기 문제로 인한 8.3 형식의 제한이 없기 때문에 고루함.
필요한 패키지가 없을 경우 GoboLinux 레시피를 만들어야 함. 레시피 생성 언어는 이해하기 쉽지만, 종종 하나의 패키지가 수십 개의 라이브러리에 의존하고, 이들의 버전을 맞추고, 다운로드 URL을 찾아 레시피를 만드는 데 많은 시간을 소비함.
macOS는 GoboLinux와 유사한 방식을 사용하며, CLI에서 macOS를 사용하기 쉬움. 예를 들어, 펜 드라이브는 /Volumes에, 프로그램의 설정 파일은 ~/Library에 위치함.
GoboLinux가 snap/flatpak이나 nixOS와 같은 배포판보다 더 나은 점이나 이점에 대해 더 지식이 많은 사람이 설명해줄 수 있음. 지식이 부족한 상태에서 보았을 때, 이 방식이 가장 단순해 보임.
웹사이트 랜딩 페이지가 JavaScript를 요구하는 이유에 대한 의문. 여기에는 스크립팅 언어의 동적 기능이 필요하지 않으며, 접근성과 SEO에 영향을 줌.
이 프로젝트는 마이크로소프트의 오래된 WinFS 아이디어를 떠올리게 함. 공유 객체 의존성이 문제가 될 수 있지만, GoboLinux가 이를 어떻게 처리하는지 자세히 살펴보지 않음. 모든 공유 리소스가 특정 위치에 있거나 모든 것이 정적으로 컴파일되었을 수도 있음. 파일 시스템의 혼란에는 이유가 있으며, 오픈 소스 세계에서는 이러한 위험을 감수할 수 있음.
Hacker News 의견
/bin은/System/Index/bin으로 링크되어 있고,/usr/bin,/usr/sbin등 모든 "바이너리" 디렉토리가 같은 장소를 가리킴. 이는 일부 표준적인 배포판보다 더 호환성이 높다는 것을 의미함./Volumes에, 프로그램의 설정 파일은~/Library에 위치함.