it-swarm.com.de

Warum erstellen Entwickler keine Installationsassistenten unter Linux?

Ich bin mir sicher, dass es nicht um Faulheit oder ähnliches geht, aber ich verstehe nicht, warum Entwickler von Apps, die hauptsächlich auf Verbraucher ausgerichtet sind, keinen Installationsassistenten erstellen, in dem Sie das nächste Mal fertig sind. Dieselben Apps haben normalerweise Installationsprogramme für Windows und Mac OS. Warum also nicht Linux?

Gibt es einen technischen Grund für diesen Trend oder handelt es sich nur um Konventionen?

BEARBEITEN (23-09-2014): Diese Frage wurde nicht gestellt, um einen Flammenkrieg zwischen Windows und Linux zu starten. Ich habe alle drei Hauptbetriebssysteme verwendet und außer Linux haben die beiden anderen (Windows und Mac OS) Installationsprogramme. Ich habe Oracle noch nicht installiert, aber was auch immer ich für die Installation benötigt habe, ich habe nie ein GUI-Installationsprogramm für Linux gesehen.

Ja, ich weiß, dass Linux Paketmanager hat, sodass die Entwickler die Installationsprogramme nicht "benötigen". Es gibt jedoch immer noch eine große Menge an Software, die entweder in den Standardpaketmanagern veraltet oder einfach nicht verfügbar ist. Da Linux als Alternative zu Windows für Gelegenheitsbenutzer verkauft wird (Ubuntu ist in dieser Domäne sehr bemüht), wäre es viel sinnvoller, den Benutzern nur das zu geben, mit dem sie vertraut sind.

Nehmen Sie zum Beispiel das Einrichten eines LAMP-Stapels. Das sind alles Open-Source-Software in den Standard-Repositorys, aber können Sie alles auf einmal ohne Skript einrichten? Schauen Sie sich nun den WAMP-Server in Windows an. Sie führen einfach ein Installationsprogramm aus und es installiert mehrere Software so, dass sie gut miteinander funktionieren. Dann werden gute Standardeinstellungen und ähnliches festgelegt. Installer können das, Paketmanager nicht. Ja, Sie können ein Skript dafür online finden, aber wo? Und welches?

Installer sind keine veraltete Technologie aus der Vergangenheit. Sie sind immer noch nützlich und 95% der Benutzer sind bereits mit ihnen vertraut.

34
Arsalan Ahmad

Entwickler müssen lediglich ein Paket für eine Distribution bereitstellen. Jede Distribution hat dann eine Möglichkeit, dieses Paket zu installieren. Dieser Weg kann in einem Terminal sein (apt-get) oder über eine grafische Oberfläche, z. Ubuntu Software Center.

Das Schöne ist, dass Entwickler sich nur darum kümmern müssen, ein richtiges Paket zu erstellen. Die Distributoren kümmern sich um den Rest, und jede Paketinstallation hat den gleichen Prozess.

63

Weil sie es nicht müssen. Linux-Distributionen verfügen normalerweise über funktionierende Paketverwaltungssysteme, im Gegensatz zu Windows, bei denen jede einzelne Anwendung die Installation und Aktualisierung immer und immer wieder neu implementieren muss.

42
Jörg W Mittag

Die meisten Closed-Source-Software für Linux , die nicht kostenlos ist (== --- ==), werden mit Installationsassistenten geliefert . Dies gilt auch für einige Closed-Source-Software, die kostenlos erhältlich ist, zumindest bis die meisten großen Distributionen sie aufgreifen. Für Open Source-Software sind Paketmanager eine eindeutig überlegene Lösung.

Was ist also mit den frühen Phasen, bevor Open Source-Software von den großen Distributionen aufgegriffen wird? Warum erstellen Entwickler in dieser Phase keine Installationsassistenten?

Erstens interessieren sich viele Open-Source-Entwickler nicht für die Verteilung. Sie schreiben Software für sich selbst und stellen sie dort zur Verfügung, falls sie für andere nützlich ist, aber sie sehen die Verpackung für die Verteilung als das Problem eines anderen an. Wenn es genug gefällt, übernimmt jemand die Aufgabe, es in seine Lieblingsdistribution aufzunehmen.

Die Open-Source-Entwickler, die sich um die Verteilung kümmern, arbeiten immer noch besser im Paketmanagersystem, da sich dort ihre Kunden befinden. Linux-Benutzer durchsuchen das Web normalerweise nicht nach Software. Sie suchen zuerst ihren Paketmanager. Andernfalls durchsuchen sie die von der Community gepflegten Repositories wie Ubuntus PPAs oder Arch's AUR. Wenn Sie sich nicht an diesen Orten befinden, wird Ihre Software höchstwahrscheinlich nicht bemerkt, und wenn sie bemerkt wird, ist es weniger wahrscheinlich, dass sie vertrauenswürdig ist.

Der Verzicht auf diese bestehenden Vertriebskanäle ist so etwas wie die Entscheidung, dass Superbowl-Anzeigen zu teuer sind. Sie werden also Ihre eigene Fußballmeisterschaft veranstalten und stattdessen dort Werbung schalten. Es kann weniger kostspielig sein, aber es ist auch weniger effektiv.

Was das Anpassen der Konfiguration betrifft, gilt dies für Software wie einen Webserver, die traditionell einfacher mit einer Konfigurationsdatei zu handhaben ist, wodurch die Konfiguration einfacher freigegeben, gesichert und wiederhergestellt werden kann.

Für Client-Software wie einen Webbrowser ist es viel besser, einen Konfigurationsassistenten zu erstellen, der angezeigt wird, wenn ein neuer Benutzer die Software zum ersten Mal ausführt , als dies zu tun zur Installationszeit. Der Hauptgrund dafür ist, dass Linux ein Mehrbenutzer-Betriebssystem ist. Sie möchten es also trotzdem pro Benutzer anpassen. Dies macht es auch einfacher, den Konfigurationsassistenten später aus irgendeinem Grund erneut auszuführen, ohne das Installationsprogramm beibehalten zu müssen, um die gesamte Software neu zu installieren. Diese Art von Assistenten ist in Linux-Software ziemlich verbreitet.

22
Karl Bielefeldt

Linux-Distributionen (auch als BSD-Unices) verfügen über eine benutzerfreundliche Oberfläche für die Programminstallation über sogenannte Paketmanager (oder die Portverwaltung im BSD-Fall): pacman für Arch, dpkg für Debian/Ubuntu , und so weiter.

Diese Paketmanager bieten eine Möglichkeit, Programme mithilfe einheitlicher Konfigurationsdateien zu installieren. Sobald das benötigte Programm gemäß dem Paketmanager Ihrer Distribution gepackt ist, können Sie den Installationsbefehl einfach über das ausgewählte Paket ausführen (mit gelegentlichen benutzerspezifischen Anpassungen, wenn auch häufig gar keiner), und der Manager erledigt den Rest.

Paketmanager sind in der Regel benutzerfreundlicher als die programmspezifischen Installationsprozesse von Windows, nur weil Programme einheitlich für die Installation gepackt werden. In der Regel können Sie auch die Paketmanager-Datenbank nach dem gesuchten Programm abfragen und dessen Abhängigkeiten anzeigen.
Sie unterstützen auch die zentrale Aktualisierung der Pakete.

14
Nadir Sampaoli

Ich habe mir und anderen oft diese Frage gestellt, und ich möchte einen Punkt ansprechen, den ich oft angesprochen sehe, bevor ich erfahre, warum Linux weniger Installationsprogramme sieht:

Linux-Distributionen bieten Paketmanager.

Ich würde jedoch nicht sagen, dass der Paketmanager einer Linux-Distribution aus folgenden Gründen ein Ersatz für ein Installationsprogramm ist:

  • Diese Paketmanager sind im Betrieb nicht standardisiert

    Ein Paketmanager ist ein bisschen so, als würde man seine Binärdatei bereitstellen und den Endbenutzer das Installationsprogramm auswählen lassen. Sie können das Terminal oder ein Tool mit einer erweiterten Benutzeroberfläche auswählen, aber es bietet Ihnen nicht die gleiche Kontrolle über den Prozess wie mit einem "herkömmlichen" Installationsassistenten.

    Ein Beispiel für das, was ich unter Kontrolle verstehe, ist die Dokumentation. Sie können Ihrem Endbenutzer keine Anweisungen wie "Klicken Sie auf Weiter, und Sie sollten sehen" geben. Sie können Befehlszeilenanweisungen für ein bestimmtes Tool geben, verlassen sich dann aber nicht nur darauf, dass der Benutzer über dieses Tool verfügt, sondern verlieren auch die meisten Vorteile eines Installationsassistenten (schließlich bieten die meisten Assistenten eine Front -end für einfache Befehlszeilenanweisungen und das Starten von Skripten).

    Dies hängt auch mit der Ästhetik zusammen. Jetzt sind Sie auf die Verteilung Ihrer Endbenutzer angewiesen, um eine intuitive/geeignete Benutzeroberfläche bereitzustellen. Obwohl Sie sich dieser Tatsache voll bewusst sind, ist es für einen Gelegenheitsbenutzer nicht unangemessen, sich zu beschweren, wenn ein Doppelklick auf Ihre Datei (Installationsprogramm in ihrer Ansicht) einen hässlichen Paketmanager öffnet und überhaupt nichts tut ) oder am schlimmsten öffnet ein Terminalfenster. (Die Erfahrungen, die ich mit Benutzern gemacht habe, und ihre Abneigung gegen die "dos Prompt"/"Black and White Box"/"Sache, die alle ihre Dateien löschen wird, wenn sie es lustig ansehen", könnten wahrscheinlich ein Buch füllen)

  • Paketformate sind nicht plattformübergreifend standardisiert.

    Es gibt Tools zum Konvertieren zwischen Systemen wie rpm und deb, aber es ist nicht sinnvoll zu erwarten, dass Ihr Endbenutzer Ihre Pakete konvertiert, wenn Sie sie in einer Situation verwenden, in der ein Installationsassistent dies tun würde auf einer anderen Plattform bereitgestellt werden (dh Klicks und fertig). Das Bereitstellen aktueller Pakete für ein zusätzliches Paketformat kann recht einfach sein, wenn Sie ein rudimentäres Build-System haben, aber dennoch eine neue Binärdatei hinzufügen, die unterstützt werden muss.

    Dazu gehört auch das Hinzufügen einer neuen Binärdatei, aus der die Benutzer je nach Plattform auswählen müssen (es klingt geringfügig, aber ich bin sicher, dass jemand hier bestätigen kann, dass er x86 vs x64 vorher erklären muss [ja, es gibt Möglichkeiten, die richtige Plattform aus der Plattform abzuleiten Browser, aber dann geraten Sie in noch kompliziertere und schwerer zu unterstützende Verfahren])

  • Paketmanager sind für Open-Source-Software "netter".

    Dies bedeutet nicht, dass Sie Closed-Source-Software nicht mit einem Paketverwaltungssystem teilen können, dies ist definitiv möglich. Wenn Sie jedoch versuchen, quellnahe Software auf Linux-Distributionen freizugeben, stoßen Sie auf eine Wand, was Ihre Optionen betrifft, um Ihre Software in gängige Repositorys zu integrieren. Dinge wie PPAs oder der openSUSE Build Service sind nicht verfügbar, und selbst die Canonical Partners-Repositorys sind standardmäßig nicht aktiviert.

    Das heißt, wenn Sie kein eigenes Repository bereitstellen, können Sie nicht viele der Hauptfunktionen von Paketverwaltungssystemen, einschließlich automatischer Updates, ausführen. Meiner Meinung nach ist dies der wichtigste Vorteil für die meisten Plattformen, die diese Systeme verwenden (zB iOS, Android und Windows Store).

    Und selbst wenn Sie ein Repository bereitstellen (ein weiterer Job mit variabler Trivialität), müssen Sie die Benutzer dennoch dazu bringen, es einzurichten (dies ist eine weitere Unterstützungsebene, ein weiterer Satz nicht standardmäßiger Ansätze und eine weitere Ablenkung vom ursprünglichen Punkt des Installateur)

Nachdem ich das alles gesagt habe, habe ich das ursprüngliche Problem immer noch nicht angesprochen, warum Installer unter Linux trotz dieser Faktoren (unter anderem) weniger verbreitet sind. Die ursprüngliche Frage fragt, ob es technisch ist oder auf Konventionen basiert, und es basiert teilweise auf beiden.

Wenn Sie sich die oben genannten Faktoren ansehen, machen sie die Dinge für ein "Assistenten-ähnliches" Installationsprogramm auch komplexer. Würde Ihr Assistent beispielsweise mehrere zu installierende Paketformate enthalten? Wie gehen Sie mit dem Erscheinungsbild von Distributionen um? Die Liste geht weiter und eine Sache, die Pakete Ihnen bieten, ist, dass nichts davon Ihr Anliegen ist ( ) zum Guten oder zum Schlechten ) solange Sie die richtigen Pakete zur Verfügung stellen. Und je nach Art Ihres Projekts können Sie diese "spezialisierteren" Ressourcen nutzen, z. B. das Einreichen von Apps an das Ubuntu Software Center. Dies alles würde sich auf die technische beziehen.

Aber der Aspekt, den ich persönlich als treibende Kraft empfinde, ist die Konvention. (Ich hoffe, ich habe so tief vergraben, dass die Leute, die diese andere Antwort auf das Vergessen abgelehnt haben, aufgehört haben zu lesen.)

Ich bin der Meinung, dass das Poster einen Punkt hatte, es aber möglicherweise zu unverblümt formuliert und keine objektiven Gründe für diesen Punkt geliefert hat. Wenn Sie die Unterschiede untersuchen, die ich für einen Paketmanager und ein Installationsprogramm angegeben habe, wäre ich nicht überrascht, wenn Sie feststellen würden, dass die meisten davon fast keine Probleme darstellen (vielleicht sogar an Pedantik grenzen). Aber (entschuldigen Sie, was ich hoffe, wird als legitime Verwendung eines Ad-Hominem-Arguments angesehen) wir sind auch Benutzer vor Ort für Programmierer. Ich sehe Linux-Distributionen als hervorragende Windows-Alternative für Gelegenheitsbenutzer (unter anderem natürlich). Es ist nicht ideal imo , keine allgemein definierte Klick-und-Fertig-Prozedur bereitzustellen, die alle diese Benutzer verwenden können.

Gleichzeitig finde ich aber auch, dass viele Dinge unter Linux für diese Gruppe nicht besonders ideal sind. Sicher, einige Distributionen haben GUI-basierte Paketmanager, aber das bedeutet, dass diese Leute sich mit der Verwendung eines separaten Tools befassen müssen, da dies nicht ausschließlich auf die Installation Ihres Programms ausgerichtet ist (vergleiche this und - this bis this ).

Natürlich können Sie die GUI verwenden, um einen Großteil der Aufgaben eines durchschnittlichen Gelegenheitsbenutzers zu erledigen, insbesondere bei bestimmten Distributionen (ironischerweise werden die Dinge, die diese Distributionen tun, in der Open-Source-Community nicht immer akzeptiert [sehen Sie sich Beschwerden über Ubuntu an und es ist "ummauert" Garten "]) Aber ich denke nicht, dass es leugnbar ist, dass Linux-Konventionen jemanden bevorzugen, der mit einer CLI vertraut ist oder zumindest keine Todesangst hat, dass das Aussehen bedeutet, dass er etwas schrecklich Falsches getan hat.

Ich sage nicht, dass dies das ist, was sie anstreben, aber ich sehe wirklich, dass diese Konventionen dies tun. Und Paketverwaltungssysteme unter Linux scheinen dem zu folgen. Schließlich sind die meisten ihrer "Nachteile" fast nicht vorhanden, wenn Ihr Endbenutzer mit den zugrunde liegenden Konzepten besser vertraut ist.

Installer auf den meisten anderen Plattformen sind davon nicht wirklich betroffen und wurden so konzipiert, dass sie einen Kommentar zu der Frage "99,99% der Benutzer können blind auf" Weiter "klicken. Das Problem bei der Paketverwaltung besteht darin, diese Benutzer dazu zu bringen eine "Weiter" -Button, die sie wissen lässt, was diese "Weiter" -Button ist (ich habe gesehen, dass Benutzer von Werkzeugen gestolpert werden, die besagten, dass sie mit einem anderen Text die Eingabetaste drücken), und sie wissen lässt, wenn sie diese "Küste" beim Klicken gedrückt haben die Stufe "Weiter".

13
Selali Adobor

Zu groß ist beides. Das Linux-Distributionsmodell ist näher am AppStore/Play Store als das herkömmliche Windows/Mac OS X - und selbst diese Plattformen bewegen sich von dem, was ich gehört habe, dorthin.

Die Konvention ist, dass es einfacher ist. Die meisten Argumente für den AppStore/Play Store gelten auch für Linux:

  • Automatische Updates. Das separate Aktualisieren von 20 Programmen unter Windows ist störend und ineffizient. Der Benutzer muss beim Booten auf Java/Flash/Adobe/... klicken.
  • Einzelnes, vertrauenswürdiges Repository. Überprüfen Sie, ob Sie über eine sichere Verbindung herunterladen? Oder Sie haben noch kein Reader-Update von get.Adobe.com.hackers.example.com/setup.exe heruntergeladen? Selbst wenn Sie die meisten Benutzer, insbesondere keine Hauptbenutzer, nicht. Stattdessen gehen Sie zu einem Softwarecenter oder einem ähnlichen Programm unter Linux und erhalten eine vertrauenswürdige Kopie.

Darüber hinaus gibt es folgende Vorteile, die möglicherweise nicht für den AppStore/Play Store gelten:

  • Nicht jedes Linux hat eine GUI - denken Sie an einen http-Server -, aber die meisten Distributionen unterstützen eine solche Konfiguration. OK. Nicht jeder braucht einen, aber früher oder später wird jemand ihn aus irgendeinem Grund verwenden wollen.
  • Die ABIs von Bibliotheken in verschiedenen Distributionen können unterschiedlich sein. Wenn Sie nicht auf Details mit einem Installationsprogramm eingehen, liegt die Verantwortung für das Programm, das an Ihnen arbeitet, anstatt dafür, dass Personen ein Paket im Repository verwalten.
  • Verbunden mit dem vorherigen - Sie müssen Abhängigkeiten irgendwie verwalten. Das Bündeln wird aus einem bestimmten Grund als unangemessen angesehen. In diesem Fall müssen Sie sicherstellen, dass Sie die Bibliothek ohne Fehler auf die Version aktualisiert haben. Beispielsweise haben Sie openssl 1.0.1f nicht in Ihr Bundle aufgenommen. Die Praxis zeigt, dass Menschen veraltete Bibliotheken mit bekannten Sicherheitslücken enthalten.
9

Normalerweise benötigt die Installation keine Interaktion mit einem Benutzer (die meisten apt-get Pakete zum Beispiel) oder können per Skript ausgeführt werden. Dies macht es sehr einfach zu automatisieren, um eine Software auf vielen Maschinen bereitzustellen. Anstatt Dinge über den Assistenten zu erledigen, tun Sie dieselben Dinge über Skripte oder Konfigurationsdateien.

Angesichts der Tatsache, dass in der Linux-Welt das Terminal an erster Stelle steht und die grafische Benutzeroberfläche optional ist, wird deutlich, warum ihnen tatsächliche Installationsassistenten fehlen.

Windows hingegen ist sehr benutzerorientiert. Die meisten MSI-Dateien können problemlos unbeaufsichtigt bereitgestellt werden, genauso wie die Windows-Installation unbeaufsichtigt sein kann (wie einfach/schwierig es ist, WAIK zum Laufen zu bringen, ist ein anderes Thema). Dies bedeutet auch, dass eine Reihe von Anwendungen für Windows nicht auf MSI basieren und nicht skriptfähig sind. Unter Unternehmensanwendungen sind beispielsweise Adobe-Produkte dafür bekannt, dass sie nur schwer per Skript zu installieren sind.

6