Linux 응용 프로그램이 종종 작성된 언어를 요약에 넣는 이유는 무엇입니까?

응용 프로그램을 보여줄 때 Windows와 Mac은 대부분 기능에 대해 이야기합니다. 반면에 Linux 응용 프로그램에는 기능이 아니라 언어를 작성하는 데 사용한 언어 (및 해당 라이브러리)에 대한 자세한 내용이 있습니다. 왜 그런 겁니까?

GTK +와 QT의 차이점을 데스크탑 통합 요구 사항으로 인해 차이를 알고 있지만 C 대 C ++ 대 Python 대 어셈블리 대 등을 알고 있다는 것을 이해할 수 있습니까? 정말?

예를 들면 : foo는 C / GTK +로 작성된 간단한 blah blah입니다.

필자는 전통적인 Linux 사용자 (실제로 시스템을 직접 설치 한 괴짜 땜장이)가 그러한 정보 (어떤 기술이이 도구의 배후에 있는가?) 나는 또한 예를 들어, 내가 싫어하는 기술을 사용하기 때문에 패키지를 설치하고 사용하지 않는 괴짜들 중 하나입니다. 어떤 사람들은 이런 종류의 행동을 물론 종교라고 부릅니다. 바보 아닌가요?

어쨌든 나는 두 가지 이유를 생각할 수 있습니다.

• 패키지 사용자는 Linux 사용자보다 괴짜 (그렇지 않은 경우)이므로 그러한 정보를 추가하는 것이 좋습니다.

• 나는이 패키저들이 그러한 정보를 그들의 패키지 설명에 넣을 때, 어떤 형태의 판촉으로 그것을하고 있다고 생각합니다. 그것은 때때로 작동합니다 (꽤 많은 시간을 일했습니다).

이것은 물론 추측입니다.

제 생각은 그것이 소프트웨어 자유 의 두 번째 자유와 관련이 있다는 것입니다 .

프로그램의 작동 방식을 연구하고 원하는 방식으로 변경할 수있는 자유 (자유 1). 이를 위해서는 소스 코드에 액세스해야합니다.

언어 (또는 기타 기술 기능)를 홍보하면 사람들의 선택 능력을 지원하고 해당 언어에 능숙한 사람들의 프로젝트 참여를 장려합니다.

이것은 부분적으로 역사적인 것일 수 있습니다. 그리 멀지 않은 과거에도 개별 시스템 관리자는 시스템에서 실행 된 모든 것을 구축하고 설치하는 것이 일반적이었습니다.

언어와 라이브러리 도구를 구현하는 데 사용하고 있었는지에 대한 참고 프로세스가 될 것입니다 것을 얼마나 많은 일에 대한 관리자에 대한 힌트를주고 자신의 시스템을.

유비쿼터스 시대와 패키지 관리 도구에 이르기까지이 시대는 약간의 구식이지만 유닉스 문화는 작동하는 것처럼 보이지 않는 것을 버리지 않는다는 의미에서 보수적이므로 습관이 죽기까지 시간이 걸릴 것입니다.

jasonwryans의 답변 확장 :

작성된 언어의 이름을 지정하면 해당 언어를받는 사람이 패치를 제공하거나 통찰력을 얻거나 프로그램을 확장하는 것이 얼마나 어려운지 추정 할 수 있습니다.

물론 이것은 프로그래머라면 말이됩니다.

요약을 어디에서 보았습니까? 저장소 또는 .deb 또는 .rpm과 같은 패키지?

소스에서 빌드하는 경우 다른 항목 (컴파일러, 라이브러리, 빌드 도구)을 설치해야하는지 여부를 식별하는 데 도움이 될 수 있습니다.

유닉스, 그리고 현재 LInux와 BSD는 항상 소프트웨어 기반을 골절하고 있으며, 과거에는 훨씬 더 다양한 하드웨어 기반이 존재했습니다. 일부 소프트웨어는 시스템의 통역사에서 실행되었거나 소스 코드를 컴파일 할 수 있음을 아는 것이 중요했습니다. Common Lisp 인터프리터, Tcl 인터프리터 또는 기타 인터프리터가없는 경우 소스를 다운로드하지 않아도되고 소스를 실행할 수 없다는 것을 알게됩니다.

어떤 언어로 된 언어인지 설명하면 많은 시간을 낭비하지 못했습니다.

“이것이 무엇입니까?”라는 프롬프트가 표시되면 개발자는 그 특성을 설명하는 경향이 있으며, 그 특성은 기능이 아니라 소스 코드와 관련이 있습니다. 누군가는 설명이 패키지에 들어가기 전에 사용자 중심의 설명을 다시 작성하기를 희망하지만, 언어가 확장 성과 스크립팅과 관련이 있거나 공헌자를 유치 할 수있는 기회와 같이 여전히 관련이 있다고 언급 할 수 있습니다.

내 관점에서 볼 때 이러한 정보는 새로운 기고자를 유치하고 잠재적 인 사용자에게 응용 프로그램을 시스템에 통합하는 데 얼마나 많은 작업이 필요한지 즉시 알 수 있도록하는 데 필수적입니다.

• 일반적인 측면은 응용 프로그램을 실행할 때 사용되는 라이브러리 입니다.

일부 설치는 GTK +와 같은 일부 선택된 툴킷으로 제한되지만 QT는 아니고 그 반대도 마찬가지입니다. 시스템을 유지 관리하고 장기간 구성 요소를 정기적으로 업데이트하는 관리자의 경우 이는 종교적인 문제가 아니라 실용적 일 수 있습니다.

• 또 다른 측면은 응용 프로그램 을 컴파일 하는 데 필요한 라이브러리 및 전제 조건 입니다.

즉, 소스 기반 Linux 배포판 사용자의 경우 컴파일러가 언어를 먼저 지원해야하기 때문에 응용 프로그램이 C로 작성되었는지 아니면 Objective-C로 작성되는지에 따라 큰 차이가 있습니다. 다른 언어는 거대한 라이브러리 스택을 설치해야 할 수도 있습니다. 문제는 다시이 응용 프로그램을 컴파일하기 위해 얼마나 많은 작업을 수용 할 것인가입니다.

• 다른 측면은 기고자를 유치하려는 의도입니다.

대부분의 개발자는 소수의 언어를 선호하거나 다른 언어에 대한 경험이 부족할 수 있습니다. 더 많은 사람들이 응용 프로그램에 기여할 수 있도록 일부 프로젝트는 소스를 두 가지 언어 (Wesnoth, Vega Strike, Naev 등 몇 가지 언어 로만 구분)로 나누기도합니다. 하나는 C 또는 C ++와 같은 핵심 응용 프로그램 용이고 다른 하나는 Python 또는 Lua와 같이 쉽게 수정하기위한 것입니다. 다음 은 Wesnoth에서이 작업이 수행 된 방법과 이유를 설명하는 "오픈 소스 응용 프로그램 아키텍처"장에 대한 링크 입니다.

• 마지막으로, 일부 언어에 대한 편견과 편견이 분명히 있습니다.

모든 언어로 작성된 비효율적 인 소프트웨어를 보았습니다. 효율성을 위해 응용 프로그램의 코드 품질은 작성된 언어보다 훨씬 중요합니다.

성능 광고와 많은 관련이 있다고 생각합니다. 컴파일 된 언어 (C, C ++, ...)로 작성된 응용 프로그램은 스크립트 언어 (perl, python 등)로 작성된 것보다 훨씬 나은 성능을 발휘합니다.

그러나 그것은 또한 호환성과 관련이 있습니다. 스크립팅 언어로 작성된 응용 프로그램은 거의 또는 전혀 수정하지 않고도 아키텍처 및 OS에서 더 이식성이 뛰어납니다.

오늘날의 데스크탑 / 서버 시스템에서는 그다지 관련성이 없지만 임베디드 시스템에서 SSD 넷북 및 태블릿에 이르는 소규모 시스템의 경우 프로그램에서 사용하는 언어 또는 라이브러리는 크기와 크기 때문에 문제가 될 수 있습니다. 휴대 성 고려 사항.

크기 관련 : 모든 표준 모듈 및 일반적으로 사용되는 애드온 모듈과 함께 추가 언어에 대한 인터프리터를 추가하면 스토리지 요구 사항에 수백 메가 바이트를 쉽게 추가 할 수 있습니다. 라이브러리 제품군, 특히 Gnome 및 KDE와 같은 주요 데스크탑 환경과 관련된 라이브러리 제품군도 마찬가지입니다. 더 나쁜 것은, 실행 예정 n에 n+1펄 프로그램은 메모리를 많이 공유 할 수 있기 때문에, 메모리 사용 요구 사항을 너무 많이 추가 할 수 있지만에서하지 않을 수도 n펄 프로그램과 0 파이썬 프로그램nPerl 프로그램과 1 개의 Python 프로그램으로 인해 메모리 사용량이 크게 증가합니다. 무료 소프트웨어를 작성하는 모든 바보가 자신이 좋아하는 스크립트 / radtool 언어를 프로그래밍 할 때 더 많은 문제가됩니다 : ... Perl, Python, PHP, Ruby, JavaScript, Bourne shell, Bash, Csh ....

이식성 관련 : 많은 해석 언어 (및 라이브러리 프레임 워크)는 큰 Linux 데스크탑 / 서버 시스템에서는 사용할 수 있지만 소규모 / 임베디드 / MMU가없는 시스템에서는 사용할 수없는 기능을 많이 사용합니다. .so런타임시 동적 모듈 로딩에 대한 의존성이 떠 오릅니다.