Warum geben Linux-Anwendungen in der Zusammenfassung häufig die Sprache an, in der sie geschrieben wurden?

19

Bei der Präsentation von Anwendungen sprechen Windows und Mac hauptsächlich über Funktionen. Auf der anderen Seite enthalten Linux-Anwendungen mehr Details zu der Sprache, in der sie geschrieben wurden (und den zugehörigen Bibliotheken), als Features. Warum das?

Ich könnte verstehen, dass der Unterschied zwischen GTK + und QT nur aufgrund der Desktop-Integrationsanforderungen einen Unterschied ausmacht, aber C vs C ++ vs Python vs Assembly vs usw.? "Ja wirklich?"

Zum Beispiel: foo ist ein einfaches bla bla, geschrieben in C / GTK +.

Jordan Parmer
quelle
2
Ich möchte erwähnen, dass viele Windows-Apps nicht Open Source sind ... Oft sind sie mit den Abhängigkeiten gepackt, die sie benötigen, auch wenn sie Open Source sind. Ein Beispiel ist Pidgin. Sie müssen gtk unter Windows nicht separat herunterladen, damit pidgin funktioniert. Es kann vorkommen, dass das Einbeziehen der Sprache in Windows geschieht, wenn externe Abhängigkeiten erforderlich sind, obwohl mir derzeit keine Beispiele einfallen, da es am schwierigsten zu sein scheint, keine externen Abhängigkeiten zu erfordern.
Xenoterracide

Antworten:

21

Ich denke, der traditionelle Linux-Benutzer (ein geeky Bastler, der das System selbst installiert hat) kümmert sich um solche Informationen (welche Technologie steckt hinter diesem Tool?). Ich gehöre auch zu den Geeky, die zum Beispiel davon absehen würden, ein Paket zu installieren und zu verwenden, nur weil es eine Technologie verwendet, die ich nicht mag. Manche nennen diese Art von Verhalten natürlich Religion. Blöd, nicht wahr?

Trotzdem kann ich mir zwei Gründe vorstellen:

  • Die Packager sind ebenso geeky (wenn nicht sogar mehr) als diese Linux-Benutzer, daher fanden sie es eine gute Idee, solche Informationen hinzuzufügen.

  • Ich denke, wenn diese Paketanbieter solche Informationen in ihre Paketbeschreibungen aufnehmen, tun sie dies wahrscheinlich als eine Form der Werbung. Es funktioniert manchmal (es hat ziemlich oft bei mir funktioniert).

Dies ist natürlich nur eine Vermutung.

Tshepang
quelle
Ja, ich denke, Sie haben hier einen guten Punkt. Die * nix-Kultur ist in der Tat eine Kultur.
Jordan Parmer
1
Es spart auch Zeit, wenn Sie sich fragen: "Hey, in welcher Sprache ist Chromium geschrieben?".
Greenoldman
@macias: Der Geek in mir lässt mich auf die Abhängigkeiten des Pakets schauen, wo dieser Geek am häufigsten die Sprache herausfindet. Tatsächlich ist dieser Geek so religiös, dass er sich ärgert, wenn er eine Website besucht, dass er nicht schnell überprüfen kann, in welcher Sprache das unbekannte Tool geschrieben ist <Lieblingssprache einfügen>, zeigt das Vorurteil des Geeks.
Tshepang
4
Ein praktisches Beispiel für eine Technologie, die ein Problem darstellen könnte, ist das Mono / .NET, da Microsoft in diesem Bereich viele Patente hat und eine lange Tradition darin besteht, "unfreundlich" zu sein. Daher ist es nicht verwunderlich, dass einige Leute dies möchten kenne diese Art von Dingen, um zukünftige Probleme zu vermeiden.
Johan
1
Aus Sicht des Systemadministrators bestimmt das, was für ein Projekt geschrieben wird, oft, welche Abhängigkeiten verfügbar sein müssen.
JM Becker
12

Meiner Meinung nach bezieht es sich auf die zweite der vier Software-Freiheiten :

Die Freiheit, die Funktionsweise des Programms zu studieren und es so zu ändern, dass es das tut, was Sie möchten (Freiheit 1). Voraussetzung hierfür ist der Zugriff auf den Quellcode.

Die Veröffentlichung der Sprache (oder anderer technischer Merkmale) unterstützt die Auswahlmöglichkeiten der Menschen und fördert die Teilnahme an Projekten durch Personen, die diese Sprachen beherrschen.

jasonwryan
quelle
10

Dies kann teilweise historisch sein. Selbst in nicht allzu ferner Vergangenheit war es üblich, dass einzelne Systemadministratoren alles erstellten und installierten, was auf ihrem System lief.

Hinweise zu den Sprachen und Bibliotheken, mit denen ein Tool implementiert wurde, geben dem Administrator einen Hinweis darauf, wie viel Arbeit dieser Prozess für sein System bedeuten wird.

In einer Zeit allgegenwärtiger und weitreichender Paketverwaltungstools ist dies ein gewisser Anachronismus, aber Unix-Kultur ist konservativ in dem Sinne, dass Dinge, die funktionieren, nicht verworfen werden, sodass es eine Weile dauern wird, bis die Gewohnheit vergeht.

dmckee
quelle
2
Ein anständiges Beispiel, an das ich denke, ist eine Webapp namens Redmine. Es wurde mit Ruby on Rails geschrieben. Weder Ruby noch Rails sind standardmäßig im System enthalten. Java-Apps sind auch so.
Xenoterracide
10

In Erweiterung der Antwort von jasonwryans :

Wenn Sie die Sprache angeben, in der es geschrieben wurde, kann die Person, die es erhält, abschätzen, wie schwierig es sein wird, einen Patch bereitzustellen, einige Einblicke zu erhalten oder das Programm zu erweitern.

Das macht natürlich nur Sinn, wenn Sie Programmierer sind.

Wo hast du die Zusammenfassungen gesehen? In einem Repository oder einem Paket wie .deb oder .rpm?

Wenn Sie es aus dem Quellcode erstellen, können die Informationen hilfreich sein, um festzustellen, ob Sie andere Komponenten (Compiler, Bibliotheken, Build-Tools) installieren müssen.

Benutzer unbekannt
quelle
Durchsuchen Sie einfach die Ubuntu-Repositorys (über das Software Center). Fast alle Zusammenfassungen enthalten die Sprache im ersten Satz. Ich finde es irgendwie komisch, dass die meisten Linux-Entwickler tatsächlich für andere Linux-Entwickler anstatt für Benutzer entwickeln.
Jordan Parmer
@ j0rd4n kein Ubuntu-Benutzer können Sie ein Beispiel für ein Softwarepaket geben? Ich meine, um sie wirklich C in der Beschreibung von Firefox setzen? Ich würde spekulieren, dass 90% der Software unter Linux nicht für Endbenutzer gedacht sind, sondern eine Bibliothek. Außerdem ... haben Sie nicht bemerkt, dass Linux-Entwickler für sich selbst entwickeln? es ist traurig aber wahr ... als perl programmierer schweife ich ab ich habe noch nichts für einen
endbenutzer
Ich benutze Ubuntu, mit Deutsch als Sprache für die Benutzeroberfläche, so dass es nur wenigen von uns helfen wird, einige Beispiele zu nennen, aber ich kann Ihnen versichern: In synaptics, dem Installationstool für neue Software, habe ich einen Test durchgeführt und 5 Pakete ausgewählt - und Ich habe keinen gefunden, der die Sprache erwähnte, in der es geschrieben wurde.
Unbekannter Benutzer
Erweiterung meines Kommentars: Oft ist die Software für Unix geschrieben (wenn Sie Automake-Dateien und ähnliches finden) und nicht unbedingt für Linux produziert, aber aufgrund der Kompatibilität auf verschiedenen Unix-Versionen verfügbar.
Benutzer unbekannt
6

Unix, und jetzt LInux und die BSDs, hatten schon immer eine wirklich zerbrochene Softwarebasis, und in der jüngeren Vergangenheit gab es eine weitaus vielfältigere Hardwarebasis. Es war wichtig zu wissen, dass auf Ihrem System Software für die Interpreter installiert ist oder dass Sie den Quellcode kompilieren können. Wenn Sie keinen Common-Lisp-Interpreter oder Tcl-Interpreter oder einen beliebigen Interpreter haben, wollten Sie sich nicht die Mühe machen, den Quellcode herunterzuladen, nur um herauszufinden, dass Sie ihn nicht ausführen konnten.

Eine Beschreibung der Sprache, in der sich etwas befand, verhinderte viel Zeitverschwendung.

Bruce Ediger
quelle
4

Wenn ein Entwickler gefragt wird, was ist das ?, beschreibt er in der Regel seine Natur, die für ihn eher an den Quellcode gebunden ist, als an seine Funktion. Es ist zu hoffen, dass jemand die Beschreibung umschreibt, um sie benutzerorientierter zu gestalten, bevor sie auf einem Paket landet. Die Erwähnung der Sprache kann jedoch weiterhin relevant sein, beispielsweise für die Erweiterbarkeit und Skriptfähigkeit oder für die Gelegenheit, Mitwirkende zu gewinnen.

Tobu
quelle
Das Ubuntu-Repository enthält eine erstaunliche Menge an Paketbeschreibungen, die in den ersten fünf Wörtern enthalten sind. Ich bin selbst Entwickler, aber ich habe nie gedacht, dass sich meine Benutzer darum kümmern. Ich könnte jedoch verstehen, dass Open Source mehr Bedeutung hat, aber entwickeln wir für Menschen oder andere Entwickler?
Jordan Parmer
1
@ j0rd4n Entwickler sind auch Leute!
Zach
3

Aus meiner Sicht sind solche Informationen unerlässlich, um neue Mitarbeiter zu gewinnen und potenziellen Benutzern eine sofortige Vorstellung davon zu geben, wie viel Arbeit es bedeuten könnte, die Anwendung in ihr System zu integrieren.

  • Ein allgemeiner Aspekt sind die Bibliotheken, die beim Ausführen der Anwendung verwendet werden.

Einige Installationen sind auf einige ausgewählte Toolkits beschränkt, z. B. GTK +, jedoch nicht QT oder umgekehrt. Für einen Administrator, der ein System wartet und seine Komponenten über einen langen Zeitraum regelmäßig aktualisiert, ist dies möglicherweise nur eine praktische und keine religiöse Frage.

  • Ein weiterer Aspekt sind die verwendeten Bibliotheken und Voraussetzungen, die zum Kompilieren der Anwendung erforderlich sind .

Dh für Benutzer einer quellbasierten Linux-Distribution macht es einen großen Unterschied, ob eine Anwendung in C oder in Objective-C geschrieben ist, da ihr Compiler die Sprache in erster Linie unterstützen muss. In anderen Sprachen muss möglicherweise ein großer Stapel von Bibliotheken installiert werden. Die Frage ist dann wiederum, wie viel Arbeit Sie bereit sind, um diese Anwendung zu kompilieren.

  • Ein anderer Aspekt ist die Absicht, Mitwirkende anzuziehen.

Die meisten Entwickler bevorzugen eine kleine Anzahl von Sprachen oder haben einfach keine Erfahrung in anderen Sprachen. Damit eine größere Anzahl von Personen zu einer Bewerbung beitragen kann, teilen einige Projekte ihre Quellen sogar in zwei verschiedene Sprachen auf (wie Wesnoth, Vega Strike, Naev, um nur einige zu nennen). Eine davon für die Kernanwendung (wie C oder C ++), die andere für die einfache Modifikation (wie Python oder Lua). Hier ist ein Link zu einem Kapitel in "Die Architektur von Open Source-Anwendungen", das beschreibt, wie und warum dies in Wesnoth geschehen ist.

  • Schließlich gibt es offensichtlich eine Menge Befangenheit und Vorurteile gegenüber einigen Sprachen.

Ich sage nur, dass ich schrecklich ineffiziente Software gesehen habe, die in einer beliebigen Sprache geschrieben wurde. Wenn Sie mich aus Gründen der Effizienz fragen, ist die Codequalität der Anwendung viel wichtiger als die Sprache, in der sie geschrieben ist.

Nicolas Kaiser
quelle
1

Ich denke, vieles hat mit Performance-Werbung zu tun. Eine Anwendung, die in einer kompilierten Sprache (C, C ++, ...) geschrieben ist, wird eine Menge besser abschneiden als eine Anwendung, die in einer Skriptsprache (Perl, Python, ...) geschrieben ist.

Es hängt aber auch mit der Kompatibilität zusammen. Eine in einer Skriptsprache geschriebene Anwendung ist wahrscheinlich auch für Architekturen und Betriebssysteme portabler, ohne dass Änderungen erforderlich sind.

Patrick
quelle
In beiden Fällen haben Sie also ein Pro und ein Contra-Argument - was nicht befriedigend ist. Kompilierter Code, der eine geschlossene Quelle ist, ist auch unter Windows üblich, daher würde das Leistungsargument ein Linux-Programm nicht unterscheiden
Benutzer unbekannt
1
Was? Du hast einfach keinen Sinn ergeben. Pro und Contra ist genau der Grund, warum Sie die Sprache auflisten würden. Wenn man nur Profis hätte, würde jeder es benutzen. Und ich verstehe nicht einmal, was Sie über kompilierten Code und Betriebssysteme sagen wollen.
Patrick
Ich habe Ihre Antwort so verstanden, dass die Leute implizit für die Leistung werben, wenn sie in C / C ++ geschrieben ist, und dass sie implizit für die Portabilität werben, wenn sie nicht in C / C ++ geschrieben ist. Was immer ein Gegenargument ist - entweder gegen die Portabilität oder gegen die Leistung -, beides Gründe, ganz zu schweigen von der Sprache. Warum ist es manchmal so und in anderen Zeiten umgekehrt?
Benutzer unbekannt
0

Auf heutigen Desktop- / Serversystemen mag dies nicht so relevant sein, aber für kleinere Systeme, die von eingebetteten Systemen bis zu SSD-Netbooks und -Tablets reichen, können die von einem Programm verwendeten Sprachen oder Bibliotheken sowohl aufgrund der Größe als auch aufgrund der Größe ein Problem darstellen Überlegungen zur Portabilität.

In Bezug auf die Größe: Durch Hinzufügen eines Interpreters für eine zusätzliche Sprache sowie aller Standardmodule und häufig verwendeten Zusatzmodule können Speicheranforderungen problemlos um Hunderte von Megabyte erweitert werden. Gleiches gilt für Bibliotheksfamilien, insbesondere für diejenigen, die mit wichtigen Desktop-Umgebungen wie Gnome und KDE in Verbindung stehen. Was noch schlimmer ist: Wenn Sie nicht nmit n+1Perl-Programmen arbeiten, erhöht sich der Speicherbedarf möglicherweise nicht so stark, da viel Speicher gemeinsam genutzt werden kann. Wenn Sie jedoch mit , steigt der Speicherbedarfn Perl-Programmen und 0 Python-Programmen aufnPerl-Programme und 1 Python-Programm führen zu einem erheblichen Anstieg der Speichernutzung. Dies wird noch problematischer, wenn jeder Narr, der freie Software schreibt, seine eigene bevorzugte Skript- / Radtool-Sprache hat, in der er programmieren möchte ... Perl, Python, PHP, Ruby, JavaScript, Bourne-Shell, Bash, Csh, ....

Portabilität: Viele interpretierte Sprachen (sowie Bibliotheks-Frameworks) nutzen häufig Funktionen, die auf großen Linux-Desktop- / Serversystemen verfügbar sind, jedoch nicht unbedingt auf kleineren / eingebetteten / MMU-freien Systemen. Die Abhängigkeit vom dynamischen .soLaden von Modulen zur Laufzeit wird deutlich ...

R ..
quelle
Warum nennst du sie Narren? Warum kodieren sie nicht in der Sprache, die sie mögen? Welche Sprache sollten sie stattdessen verwenden?
Tshepang