Was ist die Zukunft? WPF oder WinForms?

Rentner schrieb:
> Mein erster Job waren DOS-Oberflächen für Grossrechner-Programme.

DOS auf einem Großrechner? Mit Singletasking und 640 kB RAM?

> Nur bin ich dann in eine ganz üble Sache rein gerutscht - Webbrowser als
> Oberfläche für Anwendungsprogramme.

Ja. Schade, dass sich nie ein richtiges UI auf Webbasis durchgesetzt 
hat, statt das mit html und viel Javascript und nem Dutzen anderer 
Buzzwords irgendwie so halblebig nachzufrickeln.

hexaFy schrieb:
> Was ist die Zukunft? WPF oder WinForms?

Qt

Peter II schrieb:
> Karl Käfer schrieb:
>> Entschuldige, aber das ist Unfug. Die Unterschiede zwischen den Browsern
>> sind nicht zuletzt dank automatischer Updates etc. nicht mehr sonderlich
>> groß,
>
> genau das ist doch das Problem. Nach dem Update kann etwas nicht mehr
> funktionieren was vorher funktioniert hat (aber eventuell fehlerhaft
> war).

Aber das hast Du bei den nativen Fatclients doch ganz genauso. Es ist 
doch einigermaßen erstaunlich, daß ich einen so erfahrenen 
.NET-Entwickler auf die geradezu endlosen Listen von Typen und 
Member-Funktionen hinweisen muß, die Microsoft allein in den 
Minor-Versionen 4.5 und 4.6 des .NET-Frameworks als obsolet erklärt hat:

https://docs.microsoft.com/en-us/dotnet/framework/whats-new/obsolete-types
https://docs.microsoft.com/en-us/dotnet/framework/whats-new/obsolete-members

> z.b. wollen sie jetzt den JavaScript Dialog entfernen. Wenn man ihn
> eingesetzt hat geht dann nichts mehr.

Welchen "JavaScript Dialog" meinst Du denn? Wenn Du die Funktionen 
alert(), prompt() und confirm() meinst, dann laß' uns doch bitte ernst 
bleiben. Denn abgesehen davon, daß kein halbwegs bei Verstand 
befindlicher Entwickler so etwas in einer modernen WebApplikation 
einsetzen würde -- dazu sind diese Dinger viel zu häßlich und 
unflexibel, und jedes moderne Framework bietet wesentlich bessere 
Möglichkeiten für so etwas -- wüßte ich bitte auch mal gerne, wer 
diese Funktionen entfernen will und wann das denn ungefähr stattfinden 
soll, daß Du das als so schrecklichen Nachteil anführst?

Normalerweise würden solche Features natürlich erst im nächsten Standard 
(HTML6 -- nach den 16 Jahren zwischen HTML4 und 5 in ca. 13 Jahren?) als 
deprecated markiert und dann im Folgestandard (HTML7 dann in ca 29 
Jahren) endgültig aus dem Standard und danach dann irgendwann auch aus 
den Browsern entfernt. Bis das passiert, haben GUI-Hersteller wie 
Microsoft schon das .NET-Framework, dessen Nachfolger und dann wiederum 
den Nachfolger dieses Nachfolgers begraben und unser GUI-Entwickler 
durfte die View-Layer seiner Software schon dreimal komplett neu 
schreiben und testen. ;-)

De facto sind HTML und JavaScript wesentlich stabiler als die mir 
bekannten  GUI-Frameworks, und die Browserentwickler und -Hersteller 
achten sehr genau auf die Abwärtskompatibilität. Es will ja keiner daran 
schuld sein, daß der eigene Browser morgen die Hälfte des Internets 
nicht mehr darstellen kann, und so beherrscht mein aktueller Firefox 
sogar noch das <listing>-Tag, das schon in HTML 3.2 von 1997 als 
deprecated markiert war... Insofern bin ich guter Dinge, daß meine 
zwanzig Jahre alten CGIs auch dann noch unverändert und problemlos mit 
aktuellen Browsern laufen werden, wenn alert() und ihre 
Schwesterfunktionen längst aus dem Standard entfernt worden sind.

Jochen schrieb:
> Ich hab lange Zeit auch viele Tools als Webanwendung entwickelt. Zum
> einen, weil halt die Browser einfach gigantisch viel hergeben, wenn es
> um Visualisierung geht. Zum anderen, weil es einfach praktisch ist,
> überall auf die Anwendung zugreifen zu können.
>
> Ich fühle mich mittlerweile allerdings regelrecht überfahren vom "Web".
> Es macht mir reichlich Mühe, überhaupt noch durchzusteigen. PHP - mein
> Favorit von damals - explodiert in alle Richtungen inklusive aller Vor-
> und Nachteile. Auf einfache Anwendungen wird erstmal node.js geschmissen
> und so weiter.
>
> Da fühle ich mich beim Entwicklen in und um Qt ja fast wie im bequemen
> kleinen Wohnzimmer zu Hause :-)

PHP war immer schon eher für Anfänger, die keinen besonderen Wert auf 
eine saubere Programmiersprache gelegt haben und schnell zu Ergebnissen 
kommen wollten, ohne sich mit Feinheiten wie der Webserverkonfiguration 
und solch exotischen Dingen wie Execute-Rechten auseinandersetzen zu 
müssen. Sorry, aber so sehen viele in PHP implementierte Anwendungen ja 
leider auch aus. (Deine natürlich nicht! :-)

Node.js hat den Vorteil, daß der Webentwickler nurmehr eine Sprache für 
die Server- und die Clientseite beherrschen muß. Kluge Idee, das.

Python und Flask oder Django, Ruby on Rails und viele andere 
Möglichkeiten existieren ebenfalls, wenn man es etwas traditioneller 
haben mag. ;-)

Aber im Wesentlichen sehe ich den Implementierungsaufwand von modernen, 
dynamischen Webseiten eher auf der Clientseite; die Serverseite ist 
dabei häufig nur noch eine Schnittstelle zum Datenspeicher. Schicke 
Diagramme zeichnet man nicht mehr serverseitig, wie man das früher 
gemacht hat. Stattdessen fordert der Client per AJAX/XMLHttpRequest die 
Daten als JSON oder XML an, der Server zieht sie aus der 
Persistenzschicht und übergibt sie an den Client, und der zeichnet dann 
ein hübsches animiertes Diagramm in einen SVG-Canvas -- und als 
besonderer Clou wird das rechenaufwändige Rendern der Grafik dabei auch 
noch auf dem Client erledigt und der Server durch dieses "Poor Man's 
Distributed Computing" entlastet. ;-)

Insofern wird die Sache auf der Serverseite oft einfacher als früher, 
und die Komplexität stattdessen eher auf die Clientseite verlagert. Da 
ist es sicher sinnvoll, sich in ein modernes ECMAScript-Framework 
einzuarbeiten, aber das ist nicht jedermanns Sache. Insofern spricht 
überhaupt gar nichts gegen Qt, das ist ein äußerst modernes und 
ausgesprochen leistungsfähiges GUI-Framework, das auch ich oft und gerne 
benutze, wo es sinnvoll ist.

Aber im Beruf sind heute eben zunehmend andere Dinge wichtig, die sich 
mit Webanwendungen oft viel besser realisieren lassen als mit 
klassischen GUIs. In mindestens zwei Fällen haben wir bereits Pitches 
gegen Wettbewerber gewonnen, weil die ihre fetten GUI-Clients angeboten 
haben und wir unsere Webapplikation -- und da ich sowohl Web- als auch 
GUI-Software deploye und bereibe und deswegen die Aufwände für beide 
Fälle kenne, kann ich diesen Trend nur allzu gut verstehen und bin 
überzeugt, daß er anhält.

MaWin schrieb:
> Um Webanwendungen komplett auf dem lokalen Rechner laufen zu lassen (man
> erinnere sich an Microsoft HTA) ohne benötigte Serveranbindung, ist ein
> gigantischer Installations- Aufstand nötig, insbesondere wenn man
> mehrere Anwendungen gleichzeitig installieren muss.

Das mag für Dich einen "gigantischen Installations- Aufstand" bedeuten, 
weil Du ein Betriebssystem benutzt, das keinen vernünftigen Paketmanager 
hat. Für mich, dessen Betriebssysteme über Paketmanager verfügen, ist 
das alles nur ein paar Mausklicks (oder in meinem Fall: einen 
Shellbefehl) und eine Paßworteingabe weit entfernt -- keine Spur von 
einem Aufstand, schon gleich gar nicht von einem "gigantischen". ;-)

> Ein einfaches Installationsprogramm im Sinne von Microsoft MSI welches
> die Anwendung komplett einrichtet so dass auf die (html/hta) Datei
> geklickt wrrden kann, fehlt seit über 10 Jahren.

Ob ich nun eine Webapplikation oder eine klassische GUI-Anwendung in so 
einen MSI-Installer einpacke, ist kein Unterschied. Abgesehen davon 
würde ich sowas heutzutage aber eher mit Docker machen.

Die UNIX-Welt will auch keine "einfachen" Installationsprogramme im 
Sinne von Microsoft MSI, denn ein modernes Paketmanagement kann 
wesentlich mehr als nur eine Anwendung installieren und löschen. Wozu 
solche "einfachen" Installationsprogramme führen, davon können viele 
Windows-Anwender ja ein recht trauriges Liedlein singen: Dateileichen, 
verwaiste Einträge in der Registry, ein zunehmend langsamer und 
instabiler werdendes System und die gute alte DLL-Hell sind nämlich die 
Spätfolgen der von Dir so hochgelobten "Einfachheit". Darauf kann ich 
prima verzichten. ;-)

Sheeva P. schrieb:
> Die UNIX-Welt will auch keine "einfachen" Installationsprogramme im
> Sinne von Microsoft MSI, denn ein modernes Paketmanagement kann
> wesentlich mehr als nur eine Anwendung installieren und löschen.

Mjah, das ist nicht ganz die Wahrheit. Wenn das einfach machbar wäre, 
hätten das viele gern, Entwickler wie Anwender. Es geht auch -- es ist 
dann nur genauso nervig wie unter Windows, die ganzen benötigten 
Bibliotheken korrekt zusammenzupacken. Im gängigen Fall geht das unter 
Linux halt einfacher.

c.m. schrieb:
> ich behaupte mal: die sprache muss zur anforderung passen.

Natürlich.

> was nutzen mir html5 und javascript wenn ich eine massendruckanwendung
> schreiben muss?

Man kann mit Webanwendungen natürlich auch dynamisch PDFs erzeugen -- 
aber für simple Sachen reichen HTML und CSS dazu sogar völlig aus. Das 
im Anhang befindliche PDF wurde mit der ebenfalls angehängten 
Webapplikation erzeugt.

Sven B. schrieb:
> Sheeva P. schrieb:
>> Die UNIX-Welt will auch keine "einfachen" Installationsprogramme im
>> Sinne von Microsoft MSI, denn ein modernes Paketmanagement kann
>> wesentlich mehr als nur eine Anwendung installieren und löschen.
>
> Mjah, das ist nicht ganz die Wahrheit. Wenn das einfach machbar wäre,
> hätten das viele gern, Entwickler wie Anwender. Es geht auch -- es ist
> dann nur genauso nervig wie unter Windows, die ganzen benötigten
> Bibliotheken korrekt zusammenzupacken. Im gängigen Fall geht das unter
> Linux halt einfacher.

Entschuldige, aber wer die Vorzüge eines Paketmanagers kennt, will 
dieses Installer-Zeugs nicht haben. Die mir bekannten Anwender, die so 
etwas haben wollen, suchen einfach nur einen Ersatz für Windows, bei dem 
alles besser aber dann doch irgendwie genauso funktionieren soll wie 
dort. Und die mir bekannten Entwickler, die so etwas haben wollen, 
wünschen sich das in der Regel deswegen, weil sie sich die 
Qualitätssicherung der Distributoren oder das Aufsetzen eines eigenen 
User Repository sparen wollen...

Peter II schrieb:
> eine Anwendung ist aber für .net 4.5 geschrieben, dann spielt es
> überhaupt keine rolle wenn in 4.6 ein Feature entfernt wird. Weil die
> Anwendung mit den "alten" Framework arbeitet.

Also muß ein User im Zweifelsfall mehrere Versionen dieses (mit 4,5 GB 
für die Version 4.5 nicht eben winzigen) Frameworks installiert und die 
dann eventuell sogar im RAM geladen haben? Mal abgesehen von dem 
verschwendeten Diskspace und Arbeitsspeicher: wenn die alle regelmäßig 
aktualisiert und gepatcht werden müssen, sorgt das bei größeren 
Unternehmen auch noch für signifikante Belastungen teurer 
Netzwerkbandbreite.

Da wundert es mich dann auch nicht mehr, daß der Windows-Schleppi in der 
Firma letztes Mal gut eine Stunde gebraucht hat, um 31.000 Updates aus 
unserem WSUS zu installieren. Und da wundert es mich auch nicht mehr, 
daß unsere Kunden Webapplikationen bevorzugen, wenn sie die Wahl haben.

> Beim Browser kann man leider nicht sagen, die Webseite bitte mit Firefox
> 45 ausführen.

Natürlich kann man das, wenn es um interne Applikationen geht -- das war 
im Windows-Umfeld jahrelang Usus, auf einen bestimmten Browser in einer 
ganz bestimmten Version festgelegt zu sein, auch wenn das meistens ein 
Ergebnis schlecht programmierter und/oder gepflegter ASP-Webanwendungen 
war. Warum sollte bei anderen Webanwendungen nicht möglich sein, was im 
MS-Umfeld so viele Jahre lang absolut üblich war?

> Es ist auch egal, ob die Funktionen langsam entfernt werden (deprecated
> usw. ) denn sie werden entfernt und man kann nichts dagegen tun außer
> die Anwendung daran anpassen. Das meinte ich mit Wartung.

Überraschung: Software muß man warten. Und natürlich könnte man etwas 
tun: man könnte für den Zugriff auf die internen Webapplikationen einen 
anderen Browser benutzen, oder eine spezielle Browserversion, genau wie 
damals bei den ASP-Seiten. Und daß mein Browser heute noch HTML-Tags 
unterstützt, die schon vor zwanzig Jahren obsolete waren, sollte Dir 
einen Hinweis darauf geben, wie unsinnig Deine Horrorszenarien sind. ;-)

> Ein Fatclient mit .net 4.5 läuft auch in 10 Jahren noch mit .net 4.5
> genauso. Heute kann man einen alten linksys Switch nicht mehr mit einen
> aktuellen Browser konfigurieren weil die Webseite einfach nicht
> funktioniert.

Tja, da solltest Du wohl mal mit Linksys schimpfen. Daß Leute schlechte 
Programme schreiben und die nicht vernünftig warten, ist aber kein 
Problem,  das auf Webapplikationen beschränkt wäre. Um bei Deinem 
Lieblingshersteller und Deinem Lieblingsframework zu bleiben: alleine in 
diesem Jahr hat MS bereits mindestens fünf (5!) Updates herausgegeben, 
die andere Software kaputtgemacht hat: Quicken Premiere 2017, Microsofts 
Skype 4 Business, den Befehl Stop-Computer von Microsofts hauseigener 
Powershell, die Microsoft Windows Group Policies sowie das Microsoft 
Dynamics CRM.

Also, kurz gesagt: Du betätigst Dich hier als der große Werbeträger 
eines Herstellers, der alleine dieses Jahr schon fünfmal Updates 
herausgegeben hat, die Software beschädigt hat, davon waren viermal die 
eigenen Produkte ebendieses Herstellers betroffen. Dabei warnst Du unter 
Verweis auf genau solche Probleme vor einer Technik, bei der von derlei 
Problemen bislang überhaupt nichts bekannt geworden ist. Mal ehrlich: 
findest Du das nicht langsam selbst ein bisschen lächerlich?

Sheeva P. schrieb:
> Entschuldige, aber wer die Vorzüge eines Paketmanagers kennt, will
> dieses Installer-Zeugs nicht haben. Die mir bekannten Anwender, die so
> etwas haben wollen, suchen einfach nur einen Ersatz für Windows, bei dem
> alles besser aber dann doch irgendwie genauso funktionieren soll wie
> dort. Und die mir bekannten Entwickler, die so etwas haben wollen,
> wünschen sich das in der Regel deswegen, weil sie sich die
> Qualitätssicherung der Distributoren oder das Aufsetzen eines eigenen
> User Repository sparen wollen...

Ne, stimmt halt nicht. Für GNU Grep ist das alles gut und richtig, aber 
wenn man eine komplexere Anwendung hat, ist jede Woche ein Benutzer im 
Bugtracker, der sich über einen Bug beschwert der in der von Ubuntu 
14.04 geshippten Version vorhanden aber eigentlich seit zwei Jahren 
behoben ist. Und es gibt im Rahmen von Paketmanagern keine sinnvolle 
Antwort auf diese Situation. Ich kann als Entwickler auch kein User 
Repository bereitstellen, das ist einfach massiv zu viel Arbeit (das 
müsste ich quasi für jede Version jeder Distro machen, das gibt bestimmt 
25 Repos um nur die gängisten Fälle abzudecken). Das ist einfach 
komplett unrealistisch. Macht ja auch niemand.

Paketmanager sind gute Tools für Software die sich langsam entwickelt 
und die man eher so als Werkzeug gelegentlich benutzt und nicht den 
ganzen Tag. Der Dateimanager, Chat-Client, Media Player, wget, bash, 
Terminalemulator, so Zeug. Da ist es mir egal, ob die Version ein Jahr 
alt ist. Für Anwendungen wie z.B. Blender, Krita, KDevelop hingegen ist 
ein Paketmanager effektiv ziemlich furchtbar.

Und no offense, aber die Qualitätssicherung der Distributoren ist meist 
eher auf einem ziemlichen Meta-Niveau ... die qualitätssichern 
vielleicht, dass da die richtige Lizenz dransteht, aber tatsächlich mal 
testen ob die Anwendung überhaupt startet die da gepackaged wurde wird 
auch gern mal ausgelassen. Soll jetzt kein Vorwurf sein, ist auch extrem 
viel Arbeit und sehr schwer, aber passiert halt auch nicht.

hexaFy schrieb:
> Webserver schön und gut. Aber was passiert wenn ich eine Schnittstelle
> zu einem Stand-Alone Gerät per Webserver einrichte ?

Wer sprach von Webserver? Eine Anwendung kannst du auch ohne Webserver 
im Browser laufen lassen.

Ob du nun deinen Browser oder deine Qt-Anwendung mit deinem Arduino 
sprechen lässt, ist aus Sicht der Sicherheit egal. Mit beiden kannst du 
beliebige Protokolle fahren, aber mit einer Webanwendung sparst du dir 
u.U. die Installation auf dem Computer (kann der Arduino gleich mit 
ausliefern).

Sven B. schrieb:
> Ne, stimmt halt nicht. Für GNU Grep ist das alles gut und richtig, aber
> wenn man eine komplexere Anwendung hat, ist jede Woche ein Benutzer im
> Bugtracker, der sich über einen Bug beschwert der in der von Ubuntu
> 14.04 geshippten Version vorhanden aber eigentlich seit zwei Jahren
> behoben ist. Und es gibt im Rahmen von Paketmanagern keine sinnvolle
> Antwort auf diese Situation.

Es fällt mir nicht leicht, jemanden ernstzunehmen, der eine drei Jahre 
alte Distribution benutzt und sich dann über veraltete Software oder gar 
den Paketmanager beschwert -- aber ich versuche mein Bestes. ;-)

Selbstverständlich gibt es diese sinnvolle Antwort. Zunächst die 
natürlich naheliegendste, mit dem Paketmanager ein Upgrade auf eine 
aktuelle Version der Distribution zu machen, und dadurch natürlich auch 
vollautomatisch an aktuellere Versionen der gewünschten Software zu 
kommen.

Darüber hinaus ist es natürlich so, daß Backports existieren und man sie 
aktivieren und installieren kann. Scheinbar ist Dir Apt-Pinning 
unbekannt, denn das ist eine weitere sinnvolle Antwort für Dein Problem 
und haargenau für solche Fälle gedacht und gemacht.

Außerdem steht Dir jederzeit die Möglichkeit offen, Deine eigenen Pakete 
zu erzeugen und über ein eigenes Repository in den Paketmanager 
einzubinden.

Und dann ist da ja noch die Möglichkeit des klassischen Dreisprungs: die 
gewünschte Softwareversion aus dem Quelltext mit "./configure && make && 
make install" zu bauen und sauber nach /usr/local/, oder aber ins eigene 
Homedirectory zu installieren, think "--prefix".

Und als wäre das immer noch nicht genug, könnte man derlei Applikationen 
natürlich auch in einem Docker- oder LXC-Container laufen lassen.

> Ich kann als Entwickler auch kein User
> Repository bereitstellen, das ist einfach massiv zu viel Arbeit (das
> müsste ich quasi für jede Version jeder Distro machen, das gibt bestimmt
> 25 Repos um nur die gängisten Fälle abzudecken). Das ist einfach
> komplett unrealistisch. Macht ja auch niemand.

Für "macht ja auch niemand" finde ich diese Liste hier [1] ziemlich lang 
-- und das ist nur ein kleiner Ausschnitt. Auf Launchpad.net findest Du 
etwas mehr als 40.000 Softwareprojekte. Für viele davon gibt es PPAs, 
die vom Projekt selbst oder von interessierten Dritten betrieben werden.

Auch für die von Dir explizit genannten Programme Blender, Krita und 
KDevelp gibt es dort die aktuellsten Versionen als fertig kompilierte 
Binärpakete in PPAs. Diese PPAs müßtest Du nur in die Paketquellen 
Deines Paketmanages einbinden und könntest die aktuellsten Versionen der 
Software dann ganz einfach über Deinen Paketmanager installieren.

Ein PPA zu erstellen und zu betreiben, ist auch nicht viel Arbeit, schon 
gar nicht im Vergleich zu der Arbeit, eine halbwegs komplexe Software zu 
entwickeln und zu pflegen. Die Übersetzung der meisten Software wird ja 
heute ohnehin über Make oä. automatisiert, und für die Entwickler ist es 
gar kein Problem, ihre Makefiles so zu erweitern, daß beim "make 
release" gleich auch fertige Pakete für die großen Distributionen 
erzeugt werden.

[1] https://www.ubuntuupdates.org/ppas

> Paketmanager sind gute Tools für Software die sich langsam entwickelt
> und die man eher so als Werkzeug gelegentlich benutzt und nicht den
> ganzen Tag. Der Dateimanager, Chat-Client, Media Player, wget, bash,
> Terminalemulator, so Zeug. Da ist es mir egal, ob die Version ein Jahr
> alt ist. Für Anwendungen wie z.B. Blender, Krita, KDevelop hingegen ist
> ein Paketmanager effektiv ziemlich furchtbar.

Tja, wenn man eine über drei Jahre alte Distribution einsetzt, ist die 
darin enthaltene veraltete Software Dein selbst gewähltes Schicksal, für 
das ganz alleine Du selbst verantwortlich bist. Wenn Du Deine Software 
nicht updatest, hilft Dir ein Installer rein gar nichts -- oder Du 
läufst in die aus dem Windows-Umfeld bekannten Probleme mit verwaisten 
Date(i)en, DLL-Hell und so weiter.

Im Grunde genommen ist Dein wahres Problem aber nicht der Paketmanager, 
sondern die darin enthaltenen Softwareversionen. Es ist aber kein großer 
Unterschied, ob man Software als Paket für einen Paketmanager oder als 
ausführbaren Installer zusammenbastelt. Infolgedessen ist Dein 
"Argument" auch an dieser Stelle unsinnig: wenn es keinen Installer für 
die von Dir gewünschte Softwareversion gibt, stehst Du wieder vor 
haargenau denselben Problemen, vor dem Du auch stehst, wenn es keine 
fertigen Binärpakete für Deinen Paketmanager gibt... Die Frage ist also 
nicht "Paketmanager oder Installerpackage", sondern "hat es jemand 
gepackt".

Schau, wenn es einen echten Bedarf für Installer unter Linux gäbe, dann 
würde es längst welche geben und sie würden auch benutzt. Daß weder das 
Eine, noch das Andere der Fall ist, dürfte sogar für Dich ein ziemlich 
deutlicher Hinweis darauf sein, wer in dieser Diskussion der 
Geisterfahrer ist und nochmal über seinen Standpunkt nachdenken könnte. 
;-)

Sheeva P. schrieb:
> Schau, wenn es einen echten Bedarf für Installer unter Linux gäbe, dann
> würde es längst welche geben und sie würden auch benutzt. Daß weder das
> Eine, noch das Andere der Fall ist,

Man sieht sie hin und wieder. Letztes Beispiel das ich erlebt habe vor 
ein paar Wochen war als ich mal die Software Repetier-Host antesten 
wollte, die kommt mit einem kruden Installer-Script das erst eine 
Litanei von Paketen per apt zieht, dann noch irgendwelchen Kram von 
sonstwo runterlädt, kurz noch den Compiler anwirft und dann alles 
zusammen irgendwohin kopiert.

Gruselig. Keiner will das eigentlich aber manche Hersteller zwingens 
einem trotzdem auf. Ich hab auch noch keine Ahnung wie ich den Mist 
jetzt wieder rückstandsfrei entfernen soll.

Der saubere weg für Debian-basierte Systeme wäre ein Repository 
aufzusetzen das man mit apt-add-repository einbinden kann, viele größere 
OSS Projekte bieten das an um ihre bleeding edge developer Versionen 
oder die letzte stable Version für alle (auch ältere) 'buntu/Debians 
bereitzustellen.

Und wenn man als Softwarehersteller noch darauf achtet daß es auf einem 
aktuellen Debian Stable sauber gebaut werden kann (und nicht die 
neuesten bleeding edge libs voraussetzt) dann wird es auf praktisch 
jeder anderen Distri ebenfalls gebaut werden können und oftmals werden 
die binaries sogar ohne Neuübersetzung überall laufen. Und fast jeder 
andere Paketmanager dürfte Tools haben um .deb in sein eigenes Format 
umzupacken.

Peter II schrieb:
> ich habe doch ein Beispiel genannt, wo ein webclient noch dem Update
> nicht mehr läuft. Kann es sein das du nur das liest was du lesen willst?

Wenn ich die Aussagen auf der Linksys-Seite richtig verstehe, scheint es 
da Probleme mit dem Caching und mit der Beschränkung auf einen ganz 
bestimmten Browser -- nämlich Microsofts Internet Explorer -- zu geben. 
Wenn die Leute von Linksys in ihrer Konfigurationssoftware aber 
proprietären Müll benutzen ist das keine auf den Web-Standards 
basierende Webapplikation mehr, sondern proprietärer Mist.

Wenn ich von Webapplikationen rede, meine ich damit natürlich Software, 
die sich an die einschlägigen Standards hält. Nach dieser Definition ist 
diese Linksys-Software natürlich keine Webapplikation, sondern ein 
proprietäres Konglomerat technischen Mittelmaßes, das zufällig mit zwei 
ganz bestimmten Versionen eines ganz bestimmten Webbrowsers bedient 
werden kann.

Im Übrigen bezieht sich Dein Beispiel auf eine neun Jahre alte Software, 
während ich Dich alleine für das aktuelle Jahr schon auf geschlagene 
vier Beispiele verwiesen habe, bei denen klassische GUI-Applikationen 
durch Updates beschädigt worden sind. Offensichtlich treten solche 
Probleme bei GUI-Anwendungen wesentlich häufiger auf als bei 
Webapplikationen. Es ist offensichtlich, daß GUI-Anwendungen höhere 
Wartungsaufwände benötigen als Webapplikationen, egal wie Du es drehst 
und wendest.

> Ich habe keine Werbung für irgendetwas gemacht. ich habe nur gesagt das
> ich finde das Webanwendungen mehr Wartung brauchen als
> Nativ-Anwendungen.

Und genau dieses "mehr" ist falsch. Ja, Webanwendungen brauchen Wartung, 
wie jede andere Software auch, und ja, ihre initiale Entwicklung ist 
heute noch geringfügig aufwändiger. Aber wenn man einmal eine 
standardkonforme Webanwendung entwickelt hat, braucht sie üblicherweise 
weniger Wartung, und zwar aus zwei Gründen: erstens, weil die 
Webstandards sich viel langsamer weiterentwickeln als GUI-Frameworks und 
Betriebssysteme, und zweitens, weil eine Webapplikation genau einmal an 
einer zentralen Stelle installiert ist und dort zentral gepflegt und 
gewartet werden kann, während GUI-Software auf vielen tausenden Rechnern 
installiert und gepflegt werden muß.

> Und genau das hast du bestätig - Anwendungen brauchen Wartung.

Ja. Aber klassische GUI-Anwendungen brauchen wesentlich mehr Wartung als 
Webanwendungen, weil die GUI-Frameworks und Betriebssysteme sich 
deutlich schneller weiter entwickeln als die Webstandards und -Browser 
und weil die Pflege von GUI-Anwendungen nicht zentral an einer Stelle 
stattfinden kann, sondern auf tausenden Rechnern gemacht werden muß.

> Ob es dabei um .net geht oder
> nicht ist sogar egal. Es ist kein unterschied zu einer C++ Anwendung.
> Dort ändert sich auch nicht so schnell eine API wie im Browser.

Dort ändert sich die API sogar schneller und öfter als im Browser, das 
ist doch gerade der Punkt. Allein in den letzten sechs Jahren kamen je 
drei neue Versionen des C++-Standards und des .NET-Frameworks heraus. 
Zwischen den letzten Major-Versionen des HTML-Standards lagen 16 Jahre!

> Dich stört wenn mehre Frameworkts auf der Platte installiert sind, aber
> empfiehlst mehre Broswer?

Solange ein Browser nur mit popeligen 100 MB und jede Version des 
.NET-Framework mit 4500 MB zu Buche schlägt: ja, eindeutig.

> Nur Blöd das es für alten Browser keine Sicherheitsupdates gibt, für
> alte Frameworks eine Zeitlang schon.

Und wenn es für das alte Framework keine Sicherheitsupdates mehr gibt, 
stehst Du vor einer noch viel schlimmeren Situation wie bei dem Browser. 
Denn für den Browser gibt es Alternativen, für das Framework nicht. Und 
während es für den Browser selbstverständlich ist, auch mit einer 
älteren standardkonformen Webapplikation zu funktionieren, kannst Du bei 
Deinem Framework nicht einfach eine aktuelle Version nehmen. Sondern Du 
bist auf Gedeih und Verderb entweder auf die alte Version angewiesen -- 
oder darauf, daß Dein Softwarehersteller seine Software dann auf die 
aktuelle Version portiert und Dir zur Verfügung stellt.

Aber wie dem auch sei: es gibt Gründe, warum unsere Kunden 
Webapplikationen bevorzugen, wenn sie eine Wahl haben. Ich verstehe 
diese Gründe. Ob Du sie verstehst, ist Deine Sache. ;-)

Sheeva P. schrieb:
> Es fällt mir nicht leicht, jemanden ernstzunehmen, der eine drei Jahre
> alte Distribution benutzt und sich dann über veraltete Software oder gar
> den Paketmanager beschwert -- aber ich versuche mein Bestes. ;-)
Diese Leute gibt es aber zu Hauf, zum Beispiel bei Unternehmen, die eben 
alte Distro-Versionen einsetzen. Die "Betroffenen" können da oft auch 
gar nichts dafür.

> ein Upgrade auf eine
> aktuelle Version der Distribution zu machen
Das geht aber oft nicht. Zum Beispiel im Computerpool deiner Uni. Oder 
an deinem Arbeitsplatz.

> Darüber hinaus ist es natürlich so, daß Backports existieren und man sie
> aktivieren und installieren kann.
Gibt es einen Backport von z.B. KDevelop 5.1 für Ubuntu 14.04? Sehe ich 
nirgends. Ist auch sehr aufwendig zu machen. Nicht einmal die 
Patch-Version 4.7.3 gibt es anscheinend -- nur 4.7.0. Übrigens: auch das 
aktuelle Ubuntu hat nicht die aktuelle Version davon (nur als Backport).
Auf meinem über fünf Jahre alten Windows 7 hingegen kann ich für fast 
alle Software einen Installer runterladen und der tut halt und ich hab 
die Version von gestern. Das ist eine Tatsache, der man einfach mal in's 
Auge sehen muss.

> Außerdem steht Dir jederzeit die Möglichkeit offen, Deine eigenen Pakete
> zu erzeugen und über ein eigenes Repository in den Paketmanager
> einzubinden.
Die Möglichkeit ja, aber wie oben beschrieben ist der Zeitaufwand 
komplett unrealistisch. Soll ich jetzt als Maintainer PPAs für Ubuntu 
14.04, 14.10, 15.04, 15.10, 16.04, 16.10 und 17.04 packen und testen 
und dann mit Fedora 19, 20, 21, 22, 23 weitermachen und mich dann den 
fünf gängigen Versionen von SuSE und Debian zuwenden?

> die
> gewünschte Softwareversion aus dem Quelltext
Joa, theoretisch ja, in der Praxis ist das halt auf deinem 3 Jahre alten 
Ubuntu 2 Tage Arbeit weil du erstmal einen Compiler bauen musst der den 
Code überhaupt übersetzen kann und dann 17 Abhängigkeiten die zu alt 
sind. Das macht halt niemand, und aus gutem Grund.

> Und als wäre das immer noch nicht genug, könnte man derlei Applikationen
> natürlich auch in einem Docker- oder LXC-Container laufen lassen.
Ne, sorry, das VM-Argument lasse ich einfach gar nicht gelten. Dann kann 
ich auch gleich Windows in einer VM installieren oder den 
Windows-Installer mit wine ausführen. ;)

> Für "macht ja auch niemand" finde ich diese Liste hier [1] ziemlich lang
> -- und das ist nur ein kleiner Ausschnitt.
Für die Länge der Liste ist die Versorgung der Benutzerbasis alter 
Systeme mit aktueller Software aber, verglichen mit dem Windows-Zustand, 
trotzdem ziemlich schlecht. :/

> und für die Entwickler ist es
> gar kein Problem, ihre Makefiles so zu erweitern, daß beim "make
> release" gleich auch fertige Pakete für die großen Distributionen
> erzeugt werden.
Doch, wegen der wirren Distributions- und Versionsvielfalt und den 
Abhängigkeiten, siehe oben.

> Es ist aber kein großer
> Unterschied, ob man Software als Paket für einen Paketmanager oder als
> ausführbaren Installer zusammenbastelt.
Doch, ist es. Ich hab beides schon gemacht und es ist ein immenser 
Unterschied. Der Unterschied ist, dass bei dem Installer die Versionen 
der Abhängigkeiten fixiert sind, weil die mit enthalten sind. Deshalb 
habe ich da nicht wirre Probleme mit "X braucht ruby < 2.3 aber Y 
braucht ruby > 2.4". Über ein Jahr oder zwei geht das meist noch 
irgendwie hinzubiegen, aber über fünf Jahre passiert das früher oder 
später. Umgekehrt muss ich bei der Installer-Variante sehr sehr viel 
mehr darüber nachdenken, was ich auf dem Basissystem als vorhanden 
voraussetzen kann, während das beim Paket als klar angenommen werden 
kann.

> Schau, wenn es einen echten Bedarf für Installer unter Linux gäbe, dann
> würde es längst welche geben und sie würden auch benutzt.
Tatsächlich haben z.B. die drei von mir genannten Anwendungen sowas 
(AppImage) und das wird auch sehr viel benutzt. Auf jeden Fall wird es 
ungefähr zwanzigmal so oft heruntergeladen wie der Quellcode ...

Viele Grüße,
Sven

Bernd K. schrieb:
> Der saubere weg für Debian-basierte Systeme wäre ein Repository
> aufzusetzen das man mit apt-add-repository einbinden kann, viele größere
> OSS Projekte bieten das an um ihre bleeding edge developer Versionen
> oder die letzte stable Version für alle (auch ältere) 'buntu/Debians
> bereitzustellen.
>
> Und wenn man als Softwarehersteller noch darauf achtet daß es auf einem
> aktuellen Debian Stable sauber gebaut werden kann (und nicht die
> neuesten bleeding edge libs voraussetzt) dann wird es auf praktisch
> jeder anderen Distri ebenfalls gebaut werden können und oftmals werden
> die binaries sogar ohne Neuübersetzung überall laufen. Und fast jeder
> andere Paketmanager dürfte Tools haben um .deb in sein eigenes Format
> umzupacken.

Ich glaube das Problem mit dem Packaging ist hier völlig missverstanden. 
Es geht nicht darum, in welches Archivformat du dein Binary packst. Es 
geht darum, gegen welche ABI das kompiliert ist.

Unter Windows gibt es ganz wenig ABI, auf die man sich verlassen kann, 
deshalb packen die Leute einfach alle Bibliotheken mit in ihren 
Installer. Das ist nicht besonders elegant, aber es tut halt. Dazu gibt 
es nur ungefähr 3 gängige Versionen dieser ABI (wenn überhaupt) sodass 
das dann alles auch zuverlässig läuft.

Unter Linux gibt es auf der typischen Distribution einen Paketmanager, 
der ganz viele Pakete in ganz spezieller Version installiert hat. Das 
ist ganz viel ABI, auf die man sich verlassen kann. Deshalb kann man ein 
Paket bauen, das nur das betroffene Programm enthält und sonst nichts. 
Der Nachteil ist, dass das dann nur auf dieser Distro mit genau dieser 
Version der abhängigen Pakete läuft. Dazu ändert sich selbst die ABI der 
glibc ständig, sodass man seinen Krempel effektiv auf irgendwas bauen 
muss, was mindestens fünf Jahre alt ist, wenn man erreichen möchte dass 
das entstehende Binary halbwegs universell verwendbar ist.

Und das, gegeben die wirre Anzahl möglicher Versionen von möglichen 
Distros, ist ein Problem, und ein großer Nachteil gegenüber dem Zustand 
unter Windows. Um Missverständnisse zu vermeiden -- ich finde 
Paketmanager super. 95% der Software-Installations-Aufgaben werden durch 
die hervorragend abgedeckt. Es reicht nur nicht als einziger 
Mechanismus zur Software-Installation, zumindest nicht auf Distros die 
nicht Arch sind und einfach immer alles direkt aktualisieren.

Ansager schrieb:
> Beispiel wären hier viele kommerzielle Spiele, die mittlerweile auch
> immer mehr für Linux erhältlich sind.
Stimmt, gutes Beispiel. Alles was es an Spielen für Linux auf Steam 
gibt, das sind wohl an die 1000 Anwendungen heutzutage, fällt auch in 
die Kategorie.

Sven B. schrieb:
> Diese Leute gibt es aber zu Hauf, zum Beispiel bei Unternehmen, die eben
> alte Distro-Versionen einsetzen. Die "Betroffenen" können da oft auch
> gar nichts dafür.

Langsam wird es immer abenteuerlicher, denn die Betroffenen würden in so 
einem Fall auch keine Software mit einem Installer einspielen können, 
weil sie nicht die nötigen Rechte dazu haben.

> Das geht aber oft nicht. Zum Beispiel im Computerpool deiner Uni. Oder
> an deinem Arbeitsplatz.

Auch da würdest Du mit einem Installer keine Software installieren 
können, weil Dir die Berechtigungen fehlen -- unter Windows übrigens 
ganz genauso, wenn Deine Systemverwalter keine Schnarchnasen sind.

> Gibt es einen Backport von z.B. KDevelop 5.1 für Ubuntu 14.04?

Nicht, daß ich wüßte. Möglicherweise bin ich nicht der Einzige, dem es 
gelinde gesagt ein wenig merkwürdig erscheint, die aktuellsten Werkzeuge 
auf einer uralten Plattform benutzen zu wollen... ;-)

>> Außerdem steht Dir jederzeit die Möglichkeit offen, Deine eigenen Pakete
>> zu erzeugen und über ein eigenes Repository in den Paketmanager
>> einzubinden.
> Die Möglichkeit ja, aber wie oben beschrieben ist der Zeitaufwand
> komplett unrealistisch. Soll ich jetzt als Maintainer PPAs für Ubuntu
> 14.04, 14.10, 15.04, 15.10, 16.04, 16.10 und 17.04 packen _und testen_
> und dann mit Fedora 19, 20, 21, 22, 23 weitermachen und mich dann den
> fünf gängigen Versionen von SuSE und Debian zuwenden?

Wenn Du KDevelop unbedingt auf Deinem Ubuntu 14.04 benutzen willst, dann 
kannst Du Dir die entsprechenden Pakete auf einem Ubuntu 14.04 bauen und 
Deine Pakete auf dem Zielsystem in einem lokalen Repository zur 
Verfügung stellen. Warum Du plötzlich auch noch andere Ubuntu-Versionen, 
sogar ganz andere Distributionen unterstützen willst, erschließt sich 
mir nicht.

> Joa, theoretisch ja, in der Praxis ist das halt auf deinem 3 Jahre alten
> Ubuntu 2 Tage Arbeit weil du erstmal einen Compiler bauen musst der den
> Code überhaupt übersetzen kann und dann 17 Abhängigkeiten die zu alt
> sind. Das macht halt niemand, und aus gutem Grund.

Tja, das ist eben schlimmstenfalls der Preis für Deine ganz besonderen 
Anforderungen.

>> Und als wäre das immer noch nicht genug, könnte man derlei Applikationen
>> natürlich auch in einem Docker- oder LXC-Container laufen lassen.
> Ne, sorry, das VM-Argument lasse ich einfach gar nicht gelten. Dann kann
> ich auch gleich Windows in einer VM installieren oder den
> Windows-Installer mit wine ausführen. ;)

Das kannst Du natürlich auch machen, wenn Du magst. Abgesehen davon sei 
ausdrücklich darauf hingewiesen, daß Container eben keine VMs sind, 
sondern lediglich isolierte Hostprozesse.

>> Für "macht ja auch niemand" finde ich diese Liste hier [1] ziemlich lang
>> -- und das ist nur ein kleiner Ausschnitt.
> Für die Länge der Liste ist die Versorgung der Benutzerbasis alter
> Systeme mit aktueller Software aber, verglichen mit dem Windows-Zustand,
> trotzdem ziemlich schlecht. :/

Der Windows-Zustand ist aber keine Folge davon, daß es dort Installer 
gibt.  Diese Aussage ist letztlich nur eine Variante von "für Windows 
gibt es viel mehr Software" -- und die Antwort ist: ja, dann benutz' das 
doch!

Wenn es für eine bestimmte Software kein Paket für eine bestimmte 
Version einer bestimmten Distribution gibt, dann ist das exakt 
vergleichbar mit dem Zustand, daß es keinen Windows-Installer für eine 
bestimmte Windows-Version gibt. Also geht es nicht um Paketmanagement, 
sondern um Paketierung.

>> und für die Entwickler ist es
>> gar kein Problem, ihre Makefiles so zu erweitern, daß beim "make
>> release" gleich auch fertige Pakete für die großen Distributionen
>> erzeugt werden.
> Doch, wegen der wirren Distributions- und Versionsvielfalt und den
> Abhängigkeiten, siehe oben.

Erst ging es darum, daß Du eine ganz bestimmte Version einer Software 
auf einer ganz bestimmten Version einer ganz bestimmten Distribution 
benutzen wolltest. Jetzt willst Du auf einmal alle Versionen aller 
Distributionen mit der Software beschicken? Das erschließt sich mir 
nicht.

Ansonsten beweist die Vielzahl an verfügbaren PPAs, daß genau das geht 
und auch von vielen Softwareprojekten genutzt wird -- und darüber hinaus 
ergibt sich daraus auch keine Notwendigkeit für Installer, die das 
Paketmanagement umgehen und so höchstwahrscheinlich zerstören würden.

> Deshalb habe ich da nicht wirre Probleme

Das wünsche ich Dir sehr. ;-)

>> Schau, wenn es einen echten Bedarf für Installer unter Linux gäbe, dann
>> würde es längst welche geben und sie würden auch benutzt.
> Tatsächlich haben z.B. die drei von mir genannten Anwendungen sowas
> (AppImage) und das wird auch sehr viel benutzt. Auf jeden Fall wird es
> ungefähr zwanzigmal so oft heruntergeladen wie der Quellcode ...

AppImages sind etwas vollkommen anderes als Installer. Sie sind am 
Ehesten vergleichbar mit den Apple Disk Images oder Windows 
PortableApps: Abbilder einer Applikation, die OHNE Installation direkt 
gestartet werden können. Das OHNE Installation ist dabei das wichtige 
Merkmal, das so paketierte Self-Contained-Images von Software 
unterschiedet, die für Installer oder Paketmanager paketiert ist.

Aber auch da geht es im Wesentlichen nicht um die Technik, sondern um 
die Pakierung an sich: denn wenn dort kein AppImage, kein Disk Image und 
keine PortableApp für diese betreffende Software in der betreffenden 
Version zur Verfügung gestellt wird, dann stehst Du wieder am Anfang.

Zuletzt verstehe ich nach diesen Aussagen noch sehr viel weniger, wo 
jetzt Dein Problem mit dem Konzept des Paketmanagements liegt. Denn wenn 
Dir die AppImages genau die Möglichkeit eröffnen, deren Fehlen Du hier 
beklagst, dann hast Du doch faktisch genau das, was Du willst, auch wenn 
das eine grundsätzlich andere Technik benutzt und obendrein, noch viel 
wichtiger, störungsfrei und problemlos mit dem Paketmanagement 
koexistiert.

Kurz gesagt hast Du also genau das, dessen Fehlen Du beklagst... 
sicherlich liegt es nur an mir, daß mir das dann doch etwas wirr 
erscheint. ;-)

Sheeva P. schrieb:
> Langsam wird es immer abenteuerlicher, denn die Betroffenen würden in so
> einem Fall auch keine Software mit einem Installer einspielen können,
> weil sie nicht die nötigen Rechte dazu haben.
Na doch, wenn man das lokal installieren oder einfach ausführen kann. 
Wie in meinem zweiten Post gesagt: das ist alles völlig irrelevant. Die 
Frage ist ob du gegen die ABI von "Ubuntu 15.04 mit diesen 270 Paketen 
in diesen Versionen" baust, oder gegen irgendwas wohldefiniertes was du 
im Zweifel mit einpacken kannst.

>> Gibt es einen Backport von z.B. KDevelop 5.1 für Ubuntu 14.04?
>
> Nicht, daß ich wüßte. Möglicherweise bin ich nicht der Einzige, dem es
> gelinde gesagt ein wenig merkwürdig erscheint, die aktuellsten Werkzeuge
> auf einer uralten Plattform benutzen zu wollen... ;-)
Benutzer die das wollen gibt es jedenfalls genug. Ich persönlich will es 
nicht, aber ich werde sehr oft danach gefragt und der Grund ist 
irgendwie meist nachvollziehbar.

> Wenn Du KDevelop unbedingt auf Deinem Ubuntu 14.04 benutzen willst, dann
> kannst Du Dir die entsprechenden Pakete auf einem Ubuntu 14.04 bauen und
> Deine Pakete auf dem Zielsystem in einem lokalen Repository zur
> Verfügung stellen. Warum Du plötzlich auch noch andere Ubuntu-Versionen,
> sogar ganz andere Distributionen unterstützen willst, erschließt sich
> mir nicht.
Weil ich als Distributor meiner Software das machen will. Weil es 2 
Tage Aufwand ist, und das kann ich meinen Benutzern nicht zumuten. Die 
wollen das nicht, die können das nicht, die haben nicht die Zeit dafür.

> Wenn es für eine bestimmte Software kein Paket für eine bestimmte
> Version einer bestimmten Distribution gibt, dann ist das exakt
> vergleichbar mit dem Zustand, daß es keinen Windows-Installer für eine
> bestimmte Windows-Version gibt. Also geht es nicht um Paketmanagement,
> sondern um Paketierung.
Nein, das ist schlicht falsch, und ich versteh nicht wie man so 
unpragmatisch sein kann das nicht einzusehen. Es gibt etwa 3 gängige 
Windows-Versionen, auf denen meist der gleiche Installer funktioniert. 
Es gibt ohne Übertreibung ca. 200 gängige Linux-Versionen, die _im 
gleichen Zeitraum_ entstanden sind, und für jede brauche ich ein 
anderes Paket. Weil die alle unterschiedliche ABIs haben.

> Erst ging es darum, daß Du eine ganz bestimmte Version einer Software
> auf einer ganz bestimmten Version einer ganz bestimmten Distribution
> benutzen wolltest. Jetzt willst Du auf einmal alle Versionen aller
> Distributionen mit der Software beschicken? Das erschließt sich mir
> nicht.
Sorry, wenn das unklar war: ich betrachte das Problem aus der 
Perspektive des Entwicklers, der seine Software für Menschen benutzbar 
machen will. Als Benutzer bin ich da im Moment weniger betroffen.


> AppImages sind etwas vollkommen anderes als Installer.
Ja, wirkt vielleicht so, aber es ist vom Problem was gelöst werden muss 
um sowas zu bauen 100% genau dasselbe. Wenn du ein AppImage hast, kannst 
du das einfach nach /opt entpacken und hast einen Installer, wenn du 
einen Baum Bibliotheken in /opt hast kannst du das in ein AppImage bauen 
und es tut. Das Problem ist, diesen Satz zusammengehöriger Bibliotheken 
zu haben, die am besten gegen eine 5 Jahre alte ABI der glibc gebaut 
sind. Und das ist einfach kein Problem, was unter Linux im Moment 
einfach lösbar ist. Unter Windows übrigens auch nicht, deshalb ist da 
immer alles so ein Schmerz sobald man 3 Bibliotheken in seiner 
C++-Anwendung verwenden will.

> Kurz gesagt hast Du also genau das, dessen Fehlen Du beklagst...
> sicherlich liegt es nur an mir, daß mir das dann doch etwas wirr
> erscheint. ;-)
Ja, sowas wie AppImage oder ein tar-Archiv mit allen Bibliotheken drin 
löst das Prblem schon mehr oder weniger. Es ist nur im Moment super 
schwer zu bauen und hat, sagen wir mal, Akzeptanzprobleme, weil überall 
argumentiert wird Paketmanager seien für alle Fälle der Weisheit letzter 
Schluss und ein anderes Distributionsprinzip für Software sei irgendwie 
böse und unnötig ...

Peter II schrieb:
> Sven B. schrieb:
>> Es gibt ohne Übertreibung ca. 200 gängige Linux-Versionen, die _im
>> gleichen Zeitraum_ entstanden sind, und für jede brauche ich ein
>> anderes Paket. Weil die alle unterschiedliche ABIs haben.
>
> so extrem ist es zum glück nicht. Auch Linux lässt sich auf eine
> Handvoll reduzieren wenn man sein Programm statisch gegen alle
> relevanten Libs linkt. Dann kommt man mit einer 32 und 64 Version für
> Intel schon recht weit.
Joa, wenn du das hinkriegst. Wird aber leicht sehr kompliziert wenn du 
z.B. Plugins hast, die gegen dieselbe Bibliothek linken und sowas. Die 
meisten Dinge haben zudem die static libs nicht im Paketmanagement, 
musst du dir also selber bauen.

> Der Kernel ist zum Glück etwas stabiler was die ABI angeht. Wenn eine
> X-GUI vorhanden ist, dann wird es wirklich komplizierter.
Hm, ist das so? OpenGL habe ich als kompliziert wahrgenommen, vor allem 
wegen diesem Murks dass nvidia seine eigene libgl hat. Für X11 würde ich 
einfach alle X-Bibliotheken mit-shippen: die reden dann mit dem Server 
X11R6, das ist seit vielen vielen Jahren stabil.

Peter II schrieb:
> du hast es immer noch nicht verstanden.

Ich habe zumindest verstanden, daß Du wie leider viele handelsübliche 
Anwendungsentwickler ausschließlich die Entwicklungsaufwände siehst und 
dabei die Operatingaufwände komplett ignorierst. Für Unternehmen ist es 
aber völlig gleichgültig, ob die Kosten nun in der Entwicklung oder im 
Betrieb anfallen. Entscheidend ist nur, in welcher Höhe sie anfallen.

In unserem Kundenumfeld kommen dabei zunehmend mehr Fachleute darauf, 
daß die Gesamtkosten (TCO) für Webapplikationen häufig niedriger sind 
als bei klassischen GUI-Applikationen, ob es Dir gefällt oder nicht. Die 
stimmen dabei einfach mit den Füßen ab und entscheiden sich, sofern sie 
die Wahl haben, dann eben für die Webapplikation. Und es interessiert 
sie herzlich wenig, ob Du das für klug, sinnvoll, oder vernünftig zu 
halten geruhst.

>> Zwischen den letzten Major-Versionen des HTML-Standards lagen 16 Jahre!
> das ich nicht lache.

Das sei Dir von Herzen gegönnt!

> Web besteht doch etwas mehr als nur Html. CSS und Javascript ändern sich
> fast monatlich.
>
> https://en.wikipedia.org/wiki/ECMAScript

Wenn Du den Artikel nicht nur verlinkt, sondern auch gelesen hättest, 
dann wüßtest Du auch, daß da lediglich neue Funktionen hinzukommen, 
während die alten natürlich erhalten bleiben. Deswegen läuft Software, 
die gegen alte ECMAScript-Standards entwickelt wurde, auch mit Browsern, 
die zusätzlich zu den alten auch die neueren Standards unterstützen. 
Unter Fachleuten wird so etwas als "Abwärtskompatibilität" bezeichnet.

> Und niemand kann 10 oder 15 Jahre in die Zukunft sehen und wissen was
> kommen wird.

Richtig, aber auch darin unterscheiden sich Webapps nicht von GUI-Apps.

> Vor 10 Jahren haben viele auf Flash auch für Applikationen gesetzt, das
> ist jetzt auch tot.

Es war eben immer schon gefährlich, seine Entwicklung an proprietäre 
Technologien zu binden. Vor dreißig Jahren haben viele auf 16-Bit 
gesetzt, vor zwanzig Jahren haben viele auf DOS-basierte Windows-Systeme 
gesetzt, und heute ist beides genauso tot. Und daß es keine 
Kompatibilitätsprobleme für diejenigen gegeben hat, die seinerzeit auf 
WinXP gesetzt haben, wird hoffentlich auch niemand behaupten, der ernst 
genommen werden will. Du siehst: genauso wie Flash werden auch im 
Desktop-Bereich immer wieder alte Zöpfe abgeschnitten, was Probleme mit 
den GUI-Apps provoziert, die auf und für diese Desktops entwickelt 
worden sind. Daß Du diesen Punkt beharrlich ignorierst, läßt ihn nicht 
verschwinden.

>> Solange ein Browser nur mit popeligen 100 MB und jede Version des
>> .NET-Framework mit 4500 MB zu Buche schlägt: ja, eindeutig.
>
> jetzt bleibe mal realistisch.

Ja, bin ich. Die Versionen 4.5, 4.6 und 4.7 schlagen jeweils mit 4,5 GB 
Diskspace zu Buche, nicht nur realistisch, sondern sogar ganz real.

> Alle Frameworks von 2.0 bis 4.0 in 64 und 32 bit brauchen nur 1.2GB.

Also wenn ich nur die Versionen 2.0, 4.0, 4.5, 4.6 und 4.7 brauche, weil 
die von mir benutzten Anwendungen darauf angewiesen sind, dann belegen 
alleine diese Frameworks insgesamt 15,9 GB meiner Festplatte? Abgesehen 
davon bringe ich in 15,9 GB Festplattenplatz ganze 159 Webbrowser mit 
jeweils ungefähr 100 MB unter... Ok, Disks sind billig, aber vielleicht 
sollte trotzdem mal jemand Microsoft darauf hinweisen, daß die meisten 
Anwender ihre Festplatten nicht kaufen, damit genug Platz für Microsofts 
Frameworks vorhanden ist...

Und im Unternehmensumfeld -- da sind wir wieder beim Operating -- müssen 
jene 15,9 GB über das Unternehmensnetzwerk auf -- nehmen wir einen 
kleinen Laden -- auf 1000 Rechner verteilt werden. Damit wäre das 
Gigabit-Ethernet des Servers ganze 37 Stunden lang vollständig saturiert 
-- Server mit 10, 25, 40 oder 100 GbE sind in solchen kleinen 
Unternehmen ja (leider) noch ziemlich selten anzutreffen. Vielleicht 
sollte jemand mal Microsoft darauf hinweisen, daß die meisten 
Unternehmen ihre Netzwerkinfrastruktur nicht nur zur Verteilung von 
Microsofts Frameworks betreiben. ;-)

> Könnte sogar weniger sein, wenn man ich nicht SDK sondern nur die
> Runtime installiert.

Vielleicht möchtest Du das ja mal recherchieren und uns berichten? Als 
Gegenleistung rechne ich dann aus, wie viele Browserinstallationen ich 
darin unterbringen kann. ;-)

Ansager schrieb:
> Was ist denn nun Sheeva's Aussage? Dass Paketmanager das Beste seit
> geschnitten Brot sind und alles andere große Kacke?

Nein, daß Linux das Beste seit geschnitten Brot ist, weil man sich damit 
mit 2% Marktanteil zu den Elitären zählen darf, die keine der Probleme 
haben, die die anderen 98% plagen. Wer nicht arbeitet, macht eben keine 
Fehler.

http://www.zdnet.de/88285356/betriebssysteme-windows-10-steigert-marktanteil-auf-244-prozent/?inf_by=585c4b042ad0a19e179ec8a0

Ansager schrieb:
> Sheeva P. schrieb:
>> Schau, wenn es einen echten Bedarf für Installer unter Linux gäbe, dann
>> würde es längst welche geben und sie würden auch benutzt.
>
> Es gibt Bedarf in manchen Situationen, und da werden sie auch genutzt.

Es gibt Hersteller, die das Paketmanagement nicht verstanden haben, das 
stimmt. Solange so ein Installer dabei seine Software standardkonform in 
/opt/hersteller/produkt/, /etc/opt/hersteller/produkt/ etc. installiert, 
hat auch niemand ein Problem damit -- nichtmal ich.

Zur Klarstellung: mit "Installer" meine ich hier etwas, das die zu einer 
Applikation gehörenden Programme, Bibliotheken, Ressourcen-, Konfig- und 
andere Dateien über die verwalteten Systemverzeichnisse verteilt, also 
im Wesentlichen das macht, was in einem sauber verwalteten System einzig 
und alleine dem Paketmanager vorbehalten ist. Ich rede nicht über 
Skripte und Programme, welche ihre Software in die dafür vorgesehenen 
Standardpfade installiert und die Systempfade ansonsten nicht anpackt.

> Bei proprietärer SW geht das allerdings weniger leicht.

Warum denn das?

> Natürlich kann ein Binary auch per Paketmanager verteilt werden ohne
> dass die Sourcen offengelegt werden müssen.

Genau.

> Allerdings kann keine Firma sich den Aufwand leisten und Pakete für
> sämtliche gängigen Distros in sämtlichen Versionen maintainen.

Komisch, daß das ziemlich viele Firmen genau so machen. Große 
Unternehmen wie Google (Google Earth, Google Chrome, etc.), aber auch 
winzige Firmen wie der Hersteller des Webbrowsers Vivaldi.

Darüber hinaus ist es natürlich unrichtig, daß ein Hersteller "sämtliche 
Distros in sämtlichen Versionen" unterstützen müßte. Man kann problemlos 
jeweils ein RPM- und ein DEB-Paket anbieten, die dann in allen auf dem 
jeweiligen Paketmanager basierenden Distributionen und Versionen genutzt 
werden können -- so macht das zum Beispiel Vivaldi.

> Da macht ein Windows-Style-Installer schon Sinn.

Nein, immer noch nicht. Denn dann müßte unser Maintainer ja einen 
eigenen für jede Windows-Version anbieten...

Ansonsten gibt es immer auch die Möglichkeit, Applikationen 
self-contained zu packen und sie am Paketmanager vorbei zu benutzen, wie 
das Apple Disk Images, Windows PortableApps, oder unter Linux eben 
Snappy, Zero Install oder das hier bereits erwähnte AppImage machen. Die 
koexistieren völlig problemlos mit dem Paketmanager, kein Problem. Für 
Software, die ein User ohne Privilegien installieren und nutzen kann, 
ist das durchaus sinnvoll, aber eben nicht das, was ich unter 
"Installer" verstehe.

Die klassischen Windows-Installer nämlich verteilen ihre Dateien wild 
über die Systemverzeichnisse -- und genau das ist dann ein Problem, weil 
es mit dem Paketmanager kollidieren kann. Wenn der nämlich eine Datei 
desselben Namens installiert und der Installer sie überschreibt oder 
umgekehrt, dann haben wir genau dieselbe DLL-Hell wie die armen 
Windows-Nutzer, und da bin ich ganz froh, ohne diese Geißel auszukommen.

Sven B. schrieb:
> Sheeva P. schrieb:
>> Wenn es für eine bestimmte Software kein Paket für eine bestimmte
>> Version einer bestimmten Distribution gibt, dann ist das exakt
>> vergleichbar mit dem Zustand, daß es keinen Windows-Installer für eine
>> bestimmte Windows-Version gibt. Also geht es nicht um Paketmanagement,
>> sondern um Paketierung.
> Nein, das ist schlicht falsch, und ich versteh nicht wie man so
> unpragmatisch sein kann das nicht einzusehen. Es gibt etwa 3 gängige
> Windows-Versionen, auf denen meist der gleiche Installer funktioniert.
> Es gibt ohne Übertreibung ca. 200 gängige Linux-Versionen, die _im
> gleichen Zeitraum_ entstanden sind, und für jede brauche ich ein
> anderes Paket. Weil die alle unterschiedliche ABIs haben.

Als gängige Linux-Versionen würde ich einerseits die RPM- und 
andererseits die DEB-basierten Varianten betrachten, alles andere ist 
"ferner liefen". Ein self-contained Paket, das für Debian gebaut ist, 
läuft problemlos mit allen Debian-Derivaten wie Ubuntu und Mint, ein 
entsprechendes RPM läuft ebenso problemlos auf RedHat, CentOS, Fedora 
und SuSE Linux. Demzufolge gibt es auf vivaldi.com genau zwei Packages 
für Linux -- ein RPM und ein DEB -- sowie je ein Paket für WinXP, eines 
für Win7-10, und ein DMG für MacOS. Das sieht für mich nicht nach 
übermäßigem Aufwand aus -- schon gar nicht, wenn man das einmal im 
Build-Prozeß automatisiert hat.

Das Linux Kernel ABI ist darüber hinaus ziemlich stabil. Es hindert Dich 
nichts daran, darauf aufbauend die Binaries für Deine übrigen ABI mit in 
ein Paket, AppImage, 0install oä. zu packen. Natürlich ist das 
aufwändig, aber alle anderen Lösungen sind noch aufwändiger.

>> AppImages sind etwas vollkommen anderes als Installer.
> Ja, wirkt vielleicht so, aber es ist vom Problem was gelöst werden muss
> um sowas zu bauen 100% genau dasselbe. Wenn du ein AppImage hast, kannst
> du das einfach nach /opt entpacken und hast einen Installer, wenn du
> einen Baum Bibliotheken in /opt hast kannst du das in ein AppImage bauen
> und es tut.

Sorry, aber das meine ich nicht -- und mit sowas habe ich auch keinerlei 
Probleme, wenn es ordentlich gemacht ist, also nicht mit dem 
Paketmanager des Betriebssystems kollidiert.

> Das Problem ist, diesen Satz zusammengehöriger Bibliotheken
> zu haben, die am besten gegen eine 5 Jahre alte ABI der glibc gebaut
> sind. Und das ist einfach kein Problem, was unter Linux im Moment
> einfach lösbar ist.

Naja, pack' die passende glibc halt mit in das Paket.

> Unter Windows übrigens auch nicht, deshalb ist da
> immer alles so ein Schmerz sobald man 3 Bibliotheken in seiner
> C++-Anwendung verwenden will.

Der Punkt ist: es gibt keine komfortable Lösung für das Problem und kann 
auch keine geben, solange Software und ihre ABIs immer weiter entwickelt 
werden. Die Lösungen, die es dafür gäbe, sind allesamt mehr oder weniger 
unerfreulich. Auch die Installer lösen das grundsätzliche Problem nicht, 
sondern verursachen dann nur wieder neue Probleme an anderer Stelle.

> Ja, sowas wie AppImage oder ein tar-Archiv mit allen Bibliotheken drin
> löst das Prblem schon mehr oder weniger. Es ist nur im Moment super
> schwer zu bauen und hat, sagen wir mal, Akzeptanzprobleme, weil überall
> argumentiert wird Paketmanager seien für alle Fälle der Weisheit letzter
> Schluss und ein anderes Distributionsprinzip für Software sei irgendwie
> böse und unnötig ...

Böse und unnötig sind nur Werkzeuge, die das Paketmanagement stören. Auf 
meinen Systemen gibt es etliche Software, die einfach nur als Zip-Archiv 
oder als Tarball ausgeliefert werden, von Apache Spark über Apache Storm 
bis hin zu Elasticsearch. Die kommen dann in ihr passendes Verzeichnis 
in opt, und fertig ist die Laube.

Andere Software nutze ich in Docker-Containern, ebenfalls kein Problem 
für mich: denn die Docker-Images und -Container interferieren und 
interagieren ebenfalls an keiner Stelle mit dem Paketmanagement. Auch 
damit habe ich nicht das geringste Problem.

Ein Problem habe ich nur mit Installern, die wild Dateien in mein System 
und die vom Paketmanager verwalteten Systemverzeichnisse installieren. 
Es kann nämlich nicht die Idee sein, ein Paketierungskonzept zu 
beschädigen, das seit Jahrzehnten in mindestens 95% aller Fälle prima 
funktioniert.

Abradolf L. schrieb:
> Sheeva P. schrieb:
>> Und im Unternehmensumfeld -- da sind wir wieder beim Operating -- müssen
>> jene 15,9 GB über das Unternehmensnetzwerk auf -- nehmen wir einen
>> kleinen Laden -- auf 1000 Rechner verteilt werden. Damit wäre das
>> Gigabit-Ethernet des Servers ganze 37 Stunden lang vollständig saturiert
>> -- Server mit 10, 25, 40 oder 100 GbE sind in solchen kleinen
>> Unternehmen ja (leider) noch ziemlich selten anzutreffen. Vielleicht
>> sollte jemand mal Microsoft darauf hinweisen, daß die meisten
>> Unternehmen ihre Netzwerkinfrastruktur nicht nur zur Verteilung von
>> Microsofts Frameworks betreiben. ;-)
>
> Das ist weltfremder Unsinn.

Ja, natürlich. Es ist genauso weltfremder Unsinn wie die Behauptung, daß 
Webapplikationen ständig durch Änderungen in den Webstandard kaputt 
gingen und deswegen mehr Wartung erfordern würden als GUI-Applikationen. 
;-)

Ansager schrieb:
> Was ist denn der Grund für deinen Kreuzzug?

Fakten sind Kreuzzug ?

> Bist du sexuell nicht ausgelastet?

Computerkrams macht dich geil ?

Armer Willi.

Michael B. schrieb:
> Ansager schrieb:
>> Was ist denn nun Sheeva's Aussage? Dass Paketmanager das Beste seit
>> geschnitten Brot sind und alles andere große Kacke?

Nein. Meine Aussage ist, daß es ganz große Kacke ist, Dinge am 
Paketmanager vorbei in Systemverzeichnisse zu installieren, wenn das 
System über einen Paketmanager verfügt.

> Nein, daß Linux das Beste seit geschnitten Brot ist, weil man sich damit
> mit 2% Marktanteil zu den Elitären zählen darf, die keine der Probleme
> haben, die die anderen 98% plagen.

Ach, Laberkopp... von 1,5% im Juli 2015 auf 2,5% im August 2017, das ist 
doch wirklich nicht schlecht für ein Betriebssystem, das im Gegensatz zu 
den Wettbewerbern kein Multimilliardendollar-Marketing hat.

Abgesehen davon habe ich letztens irgendwo gelesen, daß auf Webservern 
in über 80% der Fälle ein Linux läuft, sogar in Microsofts Azure-Cloud 
sollen zwei Drittel der Systeme unter Linux laufen. Auch das ist nicht 
so schlecht für ein OpenSource-System ohne Marketingbudget.

Naja, und Daten von NetShare zu benutzen, die ihre Daten nur auf 
Webseiten sammeln, die dafür bezahlen... Bei der Wikipedia lag der 
Anteil von Linux jedenfalls schon im Juli 2015 bei über 3%. Ist immer 
noch nicht überragend, aber vor dem erwähnten Hintergrund finde ich das 
ziemlich gut.

Sheeva P. schrieb:
> Als gängige Linux-Versionen würde ich einerseits die RPM- und
> andererseits die DEB-basierten Varianten betrachten, alles andere ist
> "ferner liefen". Ein self-contained Paket
An der Stelle ist m.E. das Konzept eines Pakets schon ad absurdum 
geführt. Das kannst du genauso gut in ein .tar.gz packen und einfach 
nach /opt extrahieren. Pakete machen nur Sinn, wenn sie Abhängigkeiten 
und Versionierung haben. Alle Abhängigkeiten in ein .deb packen, was 
dann den ganzen Kram nach /opt installiert -- warum? Das bringt 
niemandem irgendwas.

> Sorry, aber das meine ich nicht -- und mit sowas habe ich auch keinerlei
> Probleme, wenn es ordentlich gemacht ist, also nicht mit dem
> Paketmanager des Betriebssystems kollidiert.
Ok -- darauf können wir uns glaube ich leicht einigen, Kram verteilen 
über den System-Verzeichnisbaum per Shellskript ist Murks. Das muss dann 
schon in /opt sein. Realistisch gesehen funktioniert die andere Variante 
tendentiell sowieso nicht.

> Naja, pack' die passende glibc halt mit in das Paket.
Das kannst du nicht machen, das geht nicht. Auf dem System läuft 
irgendein Kernel und es muss die dazu passende, auf dem System 
vorhandene glibc verwendet werden. Alles andere ist kompletter Murks.

> Der Punkt ist: es gibt keine komfortable Lösung für das Problem und kann
> auch keine geben, solange Software und ihre ABIs immer weiter entwickelt
> werden. Die Lösungen, die es dafür gäbe, sind allesamt mehr oder weniger
> unerfreulich. Auch die Installer lösen das grundsätzliche Problem nicht,
> sondern verursachen dann nur wieder neue Probleme an anderer Stelle.
Mjah, ein bisschen ordentliches Tooling um so Installer zu bauen wäre 
schon ganz nett. Und da ist das Linux-Ökosystem dem Windows um Jahre 
hinterher, obwohl es schon unter Windows total furchtbar ist.

Sven B. schrieb:
> An der Stelle ist m.E. das Konzept eines Pakets schon ad absurdum
> geführt. Das kannst du genauso gut in ein .tar.gz packen und einfach
> nach /opt extrahieren. Pakete machen nur Sinn, wenn sie Abhängigkeiten
> und Versionierung haben. Alle Abhängigkeiten in ein .deb packen, was
> dann den ganzen Kram nach /opt installiert -- warum? Das bringt
> niemandem irgendwas.

Nö, die Auflösung von Abhängigkeiten ist ja nur eine der vielen 
Aufgaben, um die sich so ein Paketmanager kümmert. Denn ein Paketmanager 
merkt sich nämlich, welche Dateien zu welchem Paket gehören und 
verhindert Konflikte, führt Pre- und Post-Installations- und 
Deinstallationsskripte aus, kümmert sich um den Download und die 
Installation von Updates... und schon alleine deswegen wäre ein sauberes 
Paket auch in diesem Fall besser als ein blödes Shellskript. Denn sonst 
beschweren sich die Nutzer wieder darüber, daß sie ihre Software manuell 
pflegen müssen, von der DLL- in die SO-Hell gekommen sind, und daß das 
alles ja kein Deut besser sei als unter Windows... ;-)

> Mjah, ein bisschen ordentliches Tooling um so Installer zu bauen wäre
> schon ganz nett. Und da ist das Linux-Ökosystem dem Windows um Jahre
> hinterher, obwohl es schon unter Windows total furchtbar ist.

Da ist Linux Windows kein bisschen hinterher, sondern weit voraus. Indem 
es einen Mechanismus wie das Paketmanagement gibt, sind die hier 
genannten 95% aller Fälle -- und ich würde vermuten, daß es deutlich 
mehr sind -- bereits vollumfänglich und ausgesprochen komfortabel 
gelöst. Für alles andere gibt es ebenfalls bereits fertige Mechanismen 
wie die erwähnten ZeroInstall (das ist sogar schon in den 
Ubuntu-Repositories verfügbar), AppImage, Flatpack, Autopackage und 
Snappy.

Was willst Du denn noch, warum machst Du es nicht einfach und 
entwickelst etwas? Immerhin lebt OpenSource bekanntlich vom Mitmachen. 
Wenn Dir etwas fehlt, dann schreib was und biete es der Community an, 
oder beteilige Dich an einem Projekt wie ZeroInstall oder AppImage. 
Anhand der Nutzung können wir ja dann sehen, wie groß der Bedarf dafür 
ist. Ich vermute aber, daß er bei Weitem nicht so groß ist, wie einige 
hier zu glauben scheinen -- denn 0install, Autopackage, AppImage und 
Flatpack gibt es jetzt auch schon seit deutlich über zehn Jahren, und 
die Verbreitung ist sehr überschaubar. Aber wenn Du unbedingt sowas 
haben willst, dann tu' Dir bitte bloß keinen Zwang an und überzeug' mich 
durch Taten. ;-)

Sheeva P. schrieb:
> Nö, die Auflösung von Abhängigkeiten ist ja nur eine der vielen
> Aufgaben, um die sich so ein Paketmanager kümmert. Denn ein Paketmanager
> merkt sich nämlich, welche Dateien zu welchem Paket gehören und
> verhindert Konflikte, führt Pre- und Post-Installations- und
> Deinstallationsskripte aus, kümmert sich um den Download und die
> Installation von Updates... und schon alleine deswegen wäre ein sauberes
> Paket auch in diesem Fall besser als ein blödes Shellskript. Denn sonst
> beschweren sich die Nutzer wieder darüber, daß sie ihre Software manuell
> pflegen müssen, von der DLL- in die SO-Hell gekommen sind, und daß das
> alles ja kein Deut besser sei als unter Windows... ;-)
Ja, das ist aber alles trivial wenn das Programm samt aller 
Abhängigkeiten in /opt/foobar installiert ist. Dann löscht man halt den 
Ordner oder ersetzt ihn. Das rechtfertigt keinen Paketmanager mit 500k 
SLOC oder ein ultra-kompliziertes Paketformat wie rpm-

>> Mjah, ein bisschen ordentliches Tooling um so Installer zu bauen wäre
>> schon ganz nett. Und da ist das Linux-Ökosystem dem Windows um Jahre
>> hinterher, obwohl es schon unter Windows total furchtbar ist.
>
> Da ist Linux Windows kein bisschen hinterher, sondern weit voraus. Indem
> es einen Mechanismus wie das Paketmanagement gibt, sind die hier
> genannten 95% aller Fälle -- und ich würde vermuten, daß es deutlich
> mehr sind -- bereits vollumfänglich und ausgesprochen komfortabel
> gelöst.
Darauf hatten wir uns doch schon geeinigt. Aber es ging doch in dem 
Diskussionspunkt jetzt explizit um die restlichen 5%.

> Für alles andere gibt es ebenfalls bereits fertige Mechanismen
> wie die erwähnten ZeroInstall (das ist sogar schon in den
> Ubuntu-Repositories verfügbar), AppImage, Flatpack, Autopackage und
> Snappy.
ZeroInstall, AppImage und Autopackage lösen das Problem nicht. Das sind 
Paketformate, die sind ganz nett, aber wie gesagt: nicht das Problem. 
Das Problem ist die Binaries zusammenzusammeln die in das Paket 
reinsollen, nicht wie das Format des Pakets dann ist, das ist völlig 
wurscht. Tar-Archiv wäre mir gut genug.
Snappy gibt's nur auf Ubuntu, das kannste im Moment vergessen.
Flatpak ist ganz nett, hat aber m.E. ein paar fragliche Entscheidungen 
getroffen bezüglich OpenGL und so ... mal gespannt ob das tatsächlich 
funktioniert mittelfristig. Es hat sicher seine Anwendungen, aber 
"aktuelle Anwendung auf Ubuntu 14.04 ausführen" gehört eher nicht dazu.

> Anhand der Nutzung können wir ja dann sehen, wie groß der Bedarf dafür
> ist.
Ich hab mühevoll ein AppImage für KDevelop assembliert und ich sehe ja 
wie groß der Bedarf ist: er ist groß. Und es wäre schön wenn das weniger 
mühsam wäre.

Diese "schreib doch selber was"-Haltung finde ich ein bisschen 
unangebracht  ... ich weiß dass das Problem existiert, ich hab schon 
viel Zeit investiert um es zu lösen. Du erzählst mir hingegen das 
Problem hat keiner und ich soll mal was tun um zu beweisen dass das 
anders ist ... meh.

Ansager schrieb:
> Sheeva P. schrieb:
>> Was willst Du denn noch, warum machst Du es nicht einfach und
>> entwickelst etwas? Immerhin lebt OpenSource bekanntlich vom Mitmachen.
>> Wenn Dir etwas fehlt, dann schreib was und biete es der Community an
>
> Endlich!!
> Meine Lieblings-Killerphrase in Linux-Diskussionen.
> Wurde auch Zeit!
>
> (Versteh mich nicht falsch, ich bin OSS-Fan und auch mal Contributor,
> aber das "Argument" ist einfach scheiße)

Warum? "Rough consensus and running code" (RFC2031) ist das Mantra der 
IETF und der OSS-Bewegung. Ein Großteil der heutigen OSS wurde 
entwickelt, weil Entwickler einen Bedarf gesehen haben, und wenn ich ihn 
richtig verstanden habe, ist Sven ja ein Entwickler. Da gehe ich davon 
aus, daß er so ähnlich tickt wie ich und eine Lösung entwickelt, wo er 
ein Problem sieht.

Sheeva P. schrieb:
> Da gehe ich davon
> aus, daß er so ähnlich tickt wie ich und eine Lösung entwickelt, wo er
> ein Problem sieht.

Nicht unwesentlicher Teil des Problems ist aber auch, einen "rough 
consensus" zu erreichen, dass es überhaupt ein Problem gibt. Darüber 
diskutieren du und ich ja die ganze Zeit. ;)

Sven B. schrieb:
> Ja, das ist aber alles trivial wenn das Programm samt aller
> Abhängigkeiten in /opt/foobar installiert ist. Dann löscht man halt den
> Ordner oder ersetzt ihn.

Das mag bei einer Applikation funktionieren, aber bei 20 oder 50? Zudem 
muß unser Anwender erst einmal wissen, daß es eine neue Version gibt, 
sie dann manuell herunterladen, in /opt/foobar-<version> entpacken und 
den Symlink /opt/foobar auf das Installationsverzeichnis umbiegen -- und 
Pre- und Post-Install-Skripte, die eine Default-Konfiguration abfragen 
oder die Konfig der Vorgängerversion in eine für die nun aktuelle 
Software konvertieren, die Gruppen und / oder Benutzer anlegen und so 
weiter, die hat der Anwender dann auch noch nicht aufgerufen. Also muß 
er die README lesen und verstehen damit er überhaupt weiß, daß er Pre- 
und Postinstall-Skripte aufrufen muß.

Ansonsten kannst Du diese Schritte natürlich automatisieren und daraus 
ein Installationsskript machen, die es im UNIX-Umfeld seit Jahrzehnten 
gibt. Id Software hat Quake3 und Return to castle Wolfenstein für Linux 
so gemacht, der NVidia-Installer und VirtualBox machen es IMO immer noch 
so. Damit hast Du alles, was Du brauchst: ein ausführbares Skript, das 
die Installation vor- und nachbereitet, Deine Binaries und Ressourcen in 
einem Tarball, ein sauberes Installationsverzeichnis in /opt. Nur die 
Aufgabe, Deine Dateien zusammen zu suchen, die nimmt Dir keine mir 
bekannte Software ab.

> Das rechtfertigt keinen Paketmanager mit 500k
> SLOC oder ein ultra-kompliziertes Paketformat wie rpm-

Welcher Paketmanager hat denn 500 kLOC? Allerdings: ja, RPM-Pakete und 
ihre Packaging-Werkzeuge sind wirklich PITA.

> ZeroInstall, AppImage und Autopackage lösen das Problem nicht. Das sind
> Paketformate, die sind ganz nett, aber wie gesagt: nicht das Problem.
> Das Problem ist die Binaries zusammenzusammeln die in das Paket
> reinsollen,

Aber genau dasselbe Problem hättest Du mit einem Installer doch auch?!

> Tar-Archiv wäre mir gut genug.

Was hindert Dich denn daran, Deine Software in /opt zu installieren und 
in einen Tarball zu packen? Die Slackware-Leute machen das seit 
Ewigkeiten für ihre regulären Pakete: das sind einfache Tarballs, die in 
/ entpackt werden und ein Extraverzeichnis für die Skripte enthalten -- 
und mit Ausnahme der Tatsache, daß Debian-Pakete ar-Archive sind, sind 
auch diese dem ganzen nicht vollkommen unähnlich.

Das löst natürlich auch nicht Dein Problem, die Binaries auszuwählen und 
zusammenzusammeln, die dann in den Tarball sollen. Aber dieses Problem 
hast Du in jedem Fall, egal ob mit Paketen für einen Paketmanager, mit 
Tarballs, 0install-, AppImage-, Flatpack- oder Installerpaketierung.

> Ich hab mühevoll ein AppImage für KDevelop assembliert und ich sehe ja
> wie groß der Bedarf ist: er ist groß. Und es wäre schön wenn das weniger
> mühsam wäre.

Was genau ist denn der mühsame Teil daran?

> Diese "schreib doch selber was"-Haltung finde ich ein bisschen
> unangebracht  ... ich weiß dass das Problem existiert, ich hab schon
> viel Zeit investiert um es zu lösen. Du erzählst mir hingegen das
> Problem hat keiner und ich soll mal was tun um zu beweisen dass das
> anders ist ... meh.

Aber es liegt doch an uns Leuten, die OSS entwickeln, daß das so mühsam 
ist -- und einfach nur zu sagen "es ist mühsam" ist mir dabei auch ein 
bisschen zu dürftig. Zumal ein Windows-artiger Installer das Problem 
doch auch nicht löst, sondern stattdessen Probleme an anderen Stellen 
verursacht.

Sheeva P. schrieb:
>> Ich hab mühevoll ein AppImage für KDevelop assembliert und ich sehe ja
>> wie groß der Bedarf ist: er ist groß. Und es wäre schön wenn das weniger
>> mühsam wäre.
>
> Was genau ist denn der mühsame Teil daran?

Dass du dir ein fünf Jahre altes CentOS nehmen musst, und da irgendwie 
deinen kompletten aktuellen Software-Stack zum Bauen kriegen. Das ist 
unter Umständen nicht so einfach. Wenn du ein neueres Basissystem 
nimmst, hast du mindestens dieses glibc-ABI-Problem. Dieses ganze 
Problem ist unter Windows irgendwie weniger dramatisch, weil das einfach 
eher das ist was die Leute typischerweise machen. Unter Linux hingegen 
hat man ständig irgendwie so Probleme wie mit der ABI-Kompatibilität der 
libgl auf dem System, oder irgendwelcher freetype-Kram oder so ... die 
ABIs dafür sind auf Windows irgendwie stabiler.

Und dafür sowie für das Zusammensammeln der entstehenden Binaries gibt 
es quasi keinerlei Tooling. Das fehlt.

Wie gesagt, ob das ein Installer ist oder ein tar-Archiv ist mir egal. 
Es geht mir nur darum, dass dieser Fall (der Entwickler will oder muss 
seine Anwendung selbst verteilen) nicht wirklich sinnvoll durch 
Paketmanager abgedeckt wird. Und nee, ein rpm und ein deb reicht halt 
nicht, unter Arch tut das zum Beispiel nicht und ist wieder ein riesiges 
Gefrickel. Zwölf Paketformate mit je 300 MB Binaries drin sind keine 
Lösung für diese Aufgabenstellung.

Sven B. schrieb:
> Sheeva P. schrieb:
>> Da gehe ich davon aus, daß er so ähnlich tickt wie ich und eine Lösung
>> entwickelt, wo er ein Problem sieht.
>
> Nicht unwesentlicher Teil des Problems ist aber auch, einen "rough
> consensus" zu erreichen, dass es überhaupt ein Problem gibt. Darüber
> diskutieren du und ich ja die ganze Zeit. ;)

Dann diskutieren wir an einander vorbei: ich diskutiere nur darüber, ob 
man unter Linux so etwas wie die von Windows bekannten Installer haben 
will -- und lehne diese Idee klar ab.

Aber ich sehe, daß es für manche Anwender das Problem gibt, Software 
nutzen zu wollen, die ihr Distributor nicht oder nicht in der 
gewünschten Version in seinen Repositories anbietet. Im Gegensatz zu Dir 
sehe ich aber nicht, wie dieses Problem durch Windows-ähnliche Installer 
gelöst werden sollte, ohne erhebliche Probleme an anderer Stelle zu 
bekommen. Außerdem sehe ich eine Vielzahl von etablierten und besseren 
Möglichkeiten, das Problem zu lösen.

Sheeva P. schrieb:
> Was genau ist denn der mühsame Teil daran?

Frag mal NVidia, was für Ärger die mit ihrem Grafiktreiber haben, um 
ein Binary auf allen Distributionen verwenden zu können. Die hantieren 
da mit antiken glibc-Versionen rum, und bringen zum Glück ihr eigenes 
OpenGL mit.

Entweder, du linkst deine Binaries gegen uralte Bibliotheken (und hoffst 
darauf, dass die neuen ABI-kompatibel sind, was oft nicht gilt), oder du 
hältst drei Dutzend Binaries vor (die müssen auch erst gebaut werden), 
oder du lieferst nur Source aus und baust auf dem Zielsystem zusammen.

Und letzteres scheitert oft genug, insbesondere, wenn deine Software 
nicht auf dem Dreisatz basiert (sondern z.B. FreePascal und libav 
verheiratet) oder nicht mit der neusten Toolchain getestet ist. Im 
Gegensatz zu Windows kannst du nämlich nicht "mal eben einen gcc 3.3 
installieren".

Irgendwann greift dann auch der letzte fähige Entwickler einfach zu den 
Windows-Binaries und wine. Gewisse Software möchte man nämlich einfach 
nur benutzen, ohne sie neuentwickeln zu müssen.

Sheeva P. schrieb:
> Sven B. schrieb:
>> Nicht unwesentlicher Teil des Problems ist aber auch, einen "rough
>> consensus" zu erreichen, dass es überhaupt ein Problem gibt. Darüber
>> diskutieren du und ich ja die ganze Zeit. ;)
>
> Dann diskutieren wir an einander vorbei: ich diskutiere nur darüber, ob
> man unter Linux so etwas wie die von Windows bekannten Installer haben
> will -- und lehne diese Idee klar ab.

Ja, aber hm ... wir sind uns doch einig, dass Installer im Sinne von 
"ich kopiere irgendwelche Binaries und Libs nach /usr/bin und /usr/lib" 
schlecht sind. Das hab ich doch auch schon mindestens zwei Mal gesagt.


> Aber ich sehe, daß es für manche Anwender das Problem gibt, Software
> nutzen zu wollen, die ihr Distributor nicht oder nicht in der
> gewünschten Version in seinen Repositories anbietet. Im Gegensatz zu Dir
> sehe ich aber nicht, wie dieses Problem durch Windows-ähnliche Installer
> gelöst werden sollte, ohne erhebliche Probleme an anderer Stelle zu
> bekommen.

Ist ja ok. Mein Punkt ist nur: Technisch gesehen ist das reale Problem, 
was gelöst werden muss um irgendeine Lösung anzubieten die diesen 
Anwendern hilft, ganz genau das was man unter Windows löst wenn man 
einen Installer baut. Der Rest der Aufgabe ist nur noch, irgednein 
Skript oder Programm zu haben was irgendeinen Verzeichnisbaum irgendwo 
hin entpackt. AppImage, 0install, Shellskript was in /opt installiert 
(wie z.B. bei Mathematica) oder ein tar-Archiv machen da alle ziemlich 
dasselbe mit ziemlich demselben Effekt und es ist relativ wurscht was 
davon sich etalbiert.

Wichtig ist, dass es ein distributionsunabhängiges Format ist (kein 
Debian-Paket) und das richtige drin ist (alle ABI die das Programm 
braucht, von der man sich nicht sicher ist dass sie auf dem Zielsystem 
vorhanden ist).

S. R. schrieb:
> Sheeva P. schrieb:
>> Was genau ist denn der mühsame Teil daran?
>
> Frag mal NVidia, was für Ärger die mit ihrem Grafiktreiber haben, um
> ein Binary auf allen Distributionen verwenden zu können. Die hantieren
> da mit antiken glibc-Versionen rum, und bringen zum Glück ihr eigenes
> OpenGL mit.

... was dann aber z.B. flatpak das Genick bricht, weil die abhängig von 
der Grafikkarte des Anwenders verschiedene libgl-Varianten in ihren 
Containern ausliefern müssen, was kompletter Murks ist.


> Irgendwann greift dann auch der letzte fähige Entwickler einfach zu den
> Windows-Binaries und wine. Gewisse Software möchte man nämlich einfach
> nur benutzen, ohne sie neuentwickeln zu müssen.

aber jo, so sieht's nämlich aus. Und der erste Schritt zur Verbesserung 
dieser Situation ist sich mal einig zu sein, dass es ein Problem gibt ;)

Sven B. schrieb:
> ... was dann aber z.B. flatpak das Genick bricht, weil die abhängig von
> der Grafikkarte des Anwenders verschiedene libgl-Varianten in ihren
> Containern ausliefern müssen, was kompletter Murks ist.

Das ist der Geschichte geschuldet. Die OpenGL-Bibliotheken sind ein Teil 
des Grafiktreibers, das ist unter Windows aber auch nicht anders. 
Allerdings baut man dort auch nicht solche Container. ;-)

Interessant an den Installern finde ich ja die Frage, wie man 
Bibliotheken installieren soll, ohne irgendwelche Systemdateien 
anzufassen. Also, wie Sheeva schrieb, alles nach /opt/firma/programm 
packen und in /usr nichts anfassen. Für Programme ist das kein Problem, 
aber wie kriege ich damit eine systemweite Bibliothek installiert? Und 
wie stelle ich sicher, dass der Paketmanager keine Version in /usr/lib/ 
installiert, die dann stattdessen benutzt wird?

S. R. schrieb:
> Interessant an den Installern finde ich ja die Frage, wie man
> Bibliotheken installieren soll, ohne irgendwelche Systemdateien
> anzufassen. Also, wie Sheeva schrieb, alles nach /opt/firma/programm
> packen und in /usr nichts anfassen. Für Programme ist das kein Problem,
> aber wie kriege ich damit eine systemweite Bibliothek installiert?
Du installierst nach /opt/packagename/usr/lib/ oder so. Wenn jemand die 
Bibliothek verwenden will (z.B. dagegen linken) muss er das eben seinem 
Build-System beibringen, dass es da suchen soll.

> Und
> wie stelle ich sicher, dass der Paketmanager keine Version in /usr/lib/
> installiert, die dann stattdessen benutzt wird?
Mit RPATH, würde ich sagen in dem Fall.

Sven B. schrieb:
> Dass du dir ein fünf Jahre altes CentOS nehmen musst, und da irgendwie
> deinen kompletten aktuellen Software-Stack zum Bauen kriegen. Das ist
> unter Umständen nicht so einfach. Wenn du ein neueres Basissystem
> nimmst, hast du mindestens dieses glibc-ABI-Problem. Dieses ganze
> Problem ist unter Windows irgendwie weniger dramatisch, weil das einfach
> eher das ist was die Leute typischerweise machen. Unter Linux hingegen
> hat man ständig irgendwie so Probleme wie mit der ABI-Kompatibilität der
> libgl auf dem System, oder irgendwelcher freetype-Kram oder so ... die
> ABIs dafür sind auf Windows irgendwie stabiler.

Das stimmt. Der Preis für die Weiterentwicklung von Software ist, daß 
die Software sich weiterentwickelt. Große Überraschung allenthalben! ;-)

Ok, kommen wir nach dieser fundamentalen Erkenntnis zur Sache...

Nun, weil sich OpenSource-Software sehr viel schneller weiterentwickelt 
als kommerzielle Software und darüber hinaus keiner zentralen 
Steuerungsinstanz unterliegt, sondern im Wesentlichen aus einer Vielzahl 
von lose verbundenen Einzelprojekten besteht, ergibt sich, daß man 
irgendeinen Tod sterben muß.

Entweder man orientiert sich am kleinsten gemeinsamen Nenner und 
verzichtet die vielen netten Komfortfunktionen aktueller Bibliotheken -- 
und nein, das macht auch keinen Spaß -- oder man nimmt erhöhte Aufwände 
für das Packaging und die Distribution der Software in Kauf. Oder, wie 
gesagt, man überläßt diese Aufgabe jenen speziellen Anwendern, welche 
die aktuellste Software unbedingt auf uralten Systemen benutzen 
wollen...

> Und dafür sowie für das Zusammensammeln der entstehenden Binaries gibt
> es quasi keinerlei Tooling. Das fehlt.

Ok, dann verhalten wir uns doch einfach mal wie Entwickler und gehen die 
Sache systematisch an. Welche Binaries möchtest Du genau 
zusammensammeln? Was genau ist die Schwierigkeit dabei, und wie genau 
machst Du das bisher? Wie machen das die Maintainer der Distributoren? 
Und von welcher Software reden wir hier überhaupt?

Sheeva P. schrieb:
> Entweder man orientiert sich am kleinsten gemeinsamen Nenner und
> verzichtet die vielen netten Komfortfunktionen aktueller Bibliotheken --
> und nein, das macht auch keinen Spaß -- oder man nimmt erhöhte Aufwände
> für das Packaging und die Distribution der Software in Kauf.

Das Problem besteht in beide Richtungen.

Neue Software auf alter Distribution:

Genau dann notwendig, wenn man auf einen Bugreport nur eine "im 
aktuellen git ist das gefixt, also nimm die aktuelle Software und geh 
weg"-Antwort bekommt und das Repo nicht baut. Denn dann ist per 
Definition jede Distro alt, auch wenn es nur zwei Monate sind.

Nicht jeder benutzt Arch oder hat die Möglichkeit (oder Erlaubnis), mal 
eben schnell ein Release-Upgrade wegen irgendeinem kleinen Bug zu 
machen. Und weil es eben keine Kompatiblität gibt, steht man gerne im 
Regen.

Alte Software auf neuer Distribution:

Das ist besonders nervig. Nicht jeder Entwickler hat sein Leben lang 
Zeit, sich um seine Software zu kümmern, oder das Leben war einfach zu 
kurz. Je spezieller das Programm, desto weniger Portierung findet statt, 
und desto größer ist die Wahrscheinlichkeit, dass der Entwickler einfach 
andere Dinge tut.

Linux-Programme (egal welcher Qualität) gehen nach relativ kurzer Zeit 
kaputt, im Gegensatz zu (einigermaßen sauberer) Windows-Software. Selbst 
Windows 10 (32-Bit) kann noch Win31-Software von 1993 ausführen.

> Oder, wie gesagt, man überläßt diese Aufgabe jenen speziellen Anwendern,
> welche die aktuellste Software unbedingt auf uralten Systemen benutzen
> wollen...

Also man lässt den Endanwender bluten. Das ist Scheiße.

S. R. schrieb:
> Sheeva P. schrieb:
>> Oder, wie gesagt, man überläßt diese Aufgabe jenen speziellen Anwendern,
>> welche die aktuellste Software unbedingt auf uralten Systemen benutzen
>> wollen...
>
> Also man lässt den Endanwender bluten. Das ist Scheiße.

So ist es.

>> Und dafür sowie für das Zusammensammeln der entstehenden Binaries gibt
>> es quasi keinerlei Tooling. Das fehlt.
>
> Ok, dann verhalten wir uns doch einfach mal wie Entwickler und gehen die
> Sache systematisch an. Welche Binaries möchtest Du genau
> zusammensammeln? Was genau ist die Schwierigkeit dabei, und wie genau
> machst Du das bisher? Wie machen das die Maintainer der Distributoren?
> Und von welcher Software reden wir hier überhaupt?

Meh, irgendwie mäßig produktiv das jetzt hier durchzueiern, oder? Die 
Distributionen haben das Problem nicht, das haben wir schon zehnmal 
diskutiert. Auch die Schwierigkeiten hab ich doch schon öfter genannt.
Bei uns macht das im Moment ein riesiges Shellskript, was halt die 
ganzen Build-Befehle ausführt, und dann von Hand Abhängigkeiten in's 
Image-Verzeichnis reinkopier und unnötige Inhalte rauslöscht. Tut so 
halbwegs auf den meisten Systemen dann.
Ich rede meist von KDevelop.

S. R. schrieb:
> Das Problem besteht in beide Richtungen.

Natürlich.

> Linux-Programme (egal welcher Qualität) gehen nach relativ kurzer Zeit
> kaputt,

Jetzt hör' aber mal auf mit dem Quatsch. Ich hab' gerade extra nochmal 
eine alte Kubuntu 9.10-VM gestartet und ein kleines Programm damit 
übersetzt; es läuft aus dem Stand und ohne Änderung auch unter Kubuntu 
16.04 LTS.

Schwierig wird es erst, wenn der Entwickler Libraries benutzt, die 
schnell weiterentwickelt werden. Aber das ist eben, wie gesagt, der 
Preis für die schnelle Weiterentwicklung. Würdest Du lieber darauf 
verzichten?

> Selbst Windows 10 (32-Bit) kann noch Win31-Software von 1993 ausführen.

Microsoft sagt, daß 16-Bit Programme nicht unter den 64-Bit Versionen 
von Windows laufen. Verschiedene Seiten empfehlen dazu die Nutzung einer 
VM -- ein Weg übrigens, der Linux-Usern in ähnlichen Fällen ebenso 
offensteht.

Abgesehen davon erinnere ich mich an das große Wehklagen, daß etliche 
der beliebten WinXP-Programme unter Win7 plötzlich nicht mehr liefen. 
Oder an die Verwünschungen, als viele MacOS/9-Programme nicht mehr unter 
MacOS/X laufen wollten. Und daran, als verschiedene uralte Programme 
unter neuen Windows-Versionen plötzlich nicht mehr drucken wollten. Es 
ist also nicht so, als wären solche Problem bei kommerzieller Software 
völlig unbekannt.

> Also man lässt den Endanwender bluten. Das ist Scheiße.

Ja, das Leben ist ungerecht. Es ist nun einmal, wie es ist: Du kannst 
nicht einen alten Borgward fahren und gleichzeitig Airbag, Servolenkung, 
ABS und einen Spurhalteassistenten haben wollen -- es sei denn, Du baust 
das Zeug selbst ein oder bezahlst jemanden dafür, das zu tun.

Sven B. schrieb:
> Sheeva P. schrieb:
>> Ok, dann verhalten wir uns doch einfach mal wie Entwickler und gehen die
>> Sache systematisch an. Welche Binaries möchtest Du genau
>> zusammensammeln? Was genau ist die Schwierigkeit dabei, und wie genau
>> machst Du das bisher? Wie machen das die Maintainer der Distributoren?
>> Und von welcher Software reden wir hier überhaupt?
>
> Meh, irgendwie mäßig produktiv das jetzt hier durchzueiern, oder?

Wenn ich nicht an einer konstruktiven Lösung interessiert wäre, dann 
hätte ich sicherlich nicht gefragt. ;-)

> Bei uns macht das im Moment ein riesiges Shellskript, was halt die
> ganzen Build-Befehle ausführt, und dann von Hand Abhängigkeiten in's
> Image-Verzeichnis reinkopier und unnötige Inhalte rauslöscht.

Also habt Ihr das Ganze einmal automatisiert, und jetzt muß nur noch das 
Shellskript nach gepflegt werden. Ist schon länger her, daß ich mit 
einem Installer gearbeitet habe, und leider kann ich unsere 
Windows-Entwickler übers Wochenende nicht fragen -- aber ich habe vor 
vielen, vielen Jahren mal einen MSI-Installer erstellt und mußte damals 
auch auswählen, welche Dateien ins Installerpaket aufgenommen und wohin 
sie installiert werden sollten. Mir ist bisher auch nichts bekannt, das 
das automatisch könnte.

> Ich rede meist von KDevelop.

Fein, das hatte ich vermutet. Ja, angesichts der enormen Vielzahl darin 
verwendeter Libraries kann ich mir gut vorstellen, daß das Packen davon 
ziemlich schmerzhaft ist.

Kann man Euer Shellskript vielleicht irgendwo einsehen?

Sheeva P. schrieb:
>> Linux-Programme (egal welcher Qualität) gehen nach relativ kurzer Zeit
>> kaputt,
>
> Jetzt hör' aber mal auf mit dem Quatsch. Ich hab' gerade extra nochmal
> eine alte Kubuntu 9.10-VM gestartet und ein kleines Programm damit
> übersetzt; es läuft aus dem Stand und ohne Änderung auch unter Kubuntu
> 16.04 LTS.

Was für ein Programm hast du denn übersetzt? Irgendwas textbasiertes, 
was ausschließlich die libc (also das POSIX-Interface) benutzt? Dann ist 
logisch, dass es läuft.

Nimm mal irgendwas grafisches, was mehr als nur Xlib benutzt. Oder 
etwas, was geringfügig von den autotools abweicht. Am besten etwas mit 
Abhängigkeiten, KDevelop wurde ja schon genannt. Vielleicht nen 
aktueller Firefox oder Evince?

Oder versuche mal, sowas wie UltraStar Deluxe (aber nicht die Beta) auf 
einer halbwegs modernen Distribution zum Laufen zu kriegen. Protipp: Du 
darfst auch auf einer antiken Distro bauen.

Sheeva P. schrieb:
> Schwierig wird es erst, wenn der Entwickler Libraries benutzt, die
> schnell weiterentwickelt werden.

Wie ungefähr alles, was nicht von POSIX abgedeckt wird. Also so ziemlich 
alles, was über die Grundideen eines 80er Jahre-UNIXes hinausgeht. Ist 
jetzt auch nicht überraschend.

Sheeva P. schrieb:
>> Selbst Windows 10 (32-Bit) kann noch Win31-Software von 1993 ausführen.
>
> Microsoft sagt, daß 16-Bit Programme nicht unter den 64-Bit Versionen
> von Windows laufen.

Deswegen schrieb ich "(32-Bit)" dazu, und Microsoft hat dafür eine 
verdammt gute technische Begründung für die Einschränkung. Für die 64 
Bit-Versionen liegt die Grenze bei Windows 95.

Sheeva P. schrieb:
> Es ist nun einmal, wie es ist: Du kannst nicht einen alten Borgward
> fahren und gleichzeitig Airbag, Servolenkung, ABS und einen
> Spurhalteassistenten haben wollen

Darum geht es doch garnicht. Alte Autos haben keine Airbags, das ist mir 
auch klar.

Aber: Der alte Borgward funktioniert wunderbar auf neuen Straßen. Und 
moderne Autos fahren wunderbar auf Straßen, die so neu sind wie der 
Borgward. Und genau das funktioniert unter Windows in der Regel deutlich 
besser als unter Linux.

> Jetzt hör' aber mal auf mit dem Quatsch. Ich hab' gerade extra nochmal
> eine alte Kubuntu 9.10-VM gestartet und ein kleines Programm damit
> übersetzt; es läuft aus dem Stand und ohne Änderung auch unter Kubuntu
> 16.04 LTS.
a) probier das mal andersrum
b) ein zeitloses Hello World interessiert halt keinen.

Sheeva P. schrieb:
> aber ich habe vor
> vielen, vielen Jahren mal einen MSI-Installer erstellt und mußte damals
> auch auswählen, welche Dateien ins Installerpaket aufgenommen und wohin
> sie installiert werden sollten. Mir ist bisher auch nichts bekannt, das
> das automatisch könnte.
Automatisch geht das auch eigentlich nicht. Aber irgendwie ist das unter 
Linux doch alles fummeliger und labiler, selbst wenn man's von Hand 
auswählt. Irgendwas komisches passiert immer -- dann hat der 
Gentoo-Fritze sich ein binärinkompatibles fontconfig gebaut und alles 
crasht, oder keine Ahnung was.

> Kann man Euer Shellskript vielleicht irgendwo einsehen?
https://cgit.kde.org/kdevelop.git/tree/appimage

S. R. schrieb:
> Was für ein Programm hast du denn übersetzt? Irgendwas textbasiertes,
> was ausschließlich die libc (also das POSIX-Interface) benutzt? Dann ist
> logisch, dass es läuft.

Vorher wurde hier noch behauptet, daß sich das ABI der C-Library so oft 
ändern würde, daß man sich nicht darauf verlassen könne, und Du hast dem 
nicht widersprochen...

> Vielleicht nen aktueller Firefox oder Evince?

Die aktuellste Version von Mozilla Firefox arbeitet wunderbar auf dem 
schon etwas älteren Kubuntu 16.04 LTS -- ich schreibe gerade diese 
Antwort damit. Evince ist in den aktuellen Versionen in den Repositories 
der Distributoren verfügbar. Wo ist denn Dein Problem?

> Oder versuche mal, sowas wie UltraStar Deluxe (aber nicht die Beta) auf
> einer halbwegs modernen Distribution zum Laufen zu kriegen. Protipp: Du
> darfst auch auf einer antiken Distro bauen.

Ich habe gerade wirklich keinen Bock, mir einen Free Pascal Compiler zu 
installieren, aber dem Projekt zufolge soll das gehen: [1].

[1] 
https://github.com/UltraStar-Deluxe/USDX#compiling-on-linuxbsd-using-make

> Deswegen schrieb ich "(32-Bit)" dazu, und Microsoft hat dafür eine
> verdammt gute technische Begründung für die Einschränkung.

Ist das so? Dann haben die Linux-Leute eine mindestens genau so gute 
technische Begründung dafür, daß nicht jede noch so alte oder neue 
Version einer beliebigen Software nicht auf jeder noch so alten oder 
neuen Version jeder beliebigen Distribution läuft: nämlich, daß sich 
OpenSource-Software nun einmal sehr schnell weiterentwickelt.

> Aber: Der alte Borgward funktioniert wunderbar auf neuen Straßen. Und
> moderne Autos fahren wunderbar auf Straßen, die so neu sind wie der
> Borgward.

Das wiederum eher nicht. Auf Straßenqualitäten, für die der Borgward 
einst gebaut wurde, würden sich moderne PKW in kürzester Zeit erst den 
Unterboden und dann die Aufhängung ruinieren.

Sven B. schrieb:
>> Jetzt hör' aber mal auf mit dem Quatsch. Ich hab' gerade extra nochmal
>> eine alte Kubuntu 9.10-VM gestartet und ein kleines Programm damit
>> übersetzt; es läuft aus dem Stand und ohne Änderung auch unter Kubuntu
>> 16.04 LTS.
> a) probier das mal andersrum

Hab' ich gemacht, geht.

> b) ein zeitloses Hello World interessiert halt keinen.

...reicht mir aber als Beleg dafür, daß es um die Binärkompatibilität 
von Linux nicht gar so düster bestellt ist, wie hier schwarzgemalt wird. 
;-)

> Automatisch geht das auch eigentlich nicht. Aber irgendwie ist das unter
> Linux doch alles fummeliger und labiler, selbst wenn man's von Hand
> auswählt. Irgendwas komisches passiert immer -- dann hat der
> Gentoo-Fritze sich ein binärinkompatibles fontconfig gebaut und alles
> crasht, oder keine Ahnung was.

Wenn man Myriaden von Libraries benutzt, ist dieser Schritt bei 
Erstellung eines Windows-Installers genauso fummelig und labil.

>> Kann man Euer Shellskript vielleicht irgendwo einsehen?
> https://cgit.kde.org/kdevelop.git/tree/appimage

Das kann ich jetzt nicht sonderlich schrecklich finden. Tatsächlich 
macht dieses Skript ja auch eine Menge: es klont und übersetzt etwa 
fünfzig KDE-Projekte, zieht die benötigten Libraries aus den erzeugten 
Binaries und kopiert sie in die passenden Zielverzeichnisse, löscht dann 
die vom System mitgelieferten Libraries sowie zum Übersetzen benötigte 
Software wieder und packt das Ergebnis dann als AppImage ein.

Naja, vermutlich würde ich es etwas anders machen, aber für eine so 
große Funktionalität zum Übersetzen und Deployen einer so komplexen 
Software... also da hab' ich in kommerziellen Systemen schon viel 
Übleres gesehen. Und für einen Windows-Installer müßtest Du die meisten 
der Schritte jedenfalls ganz ähnlich gehen -- und sogar viel 
umfangreicher, deswegen, weil Windows die meisten verwendeten Libraries 
gar nicht mitliefert, so daß Du da also auch die entsprechenden 
Libraries runterladen, übersetzen und installieren müßtest. Das hat 
nichts mit der genutzten Paketierungs- oder Deployment-Technik zu tun, 
sondern ist lediglich an der Komplexität der Software und ihren vielen 
genutzten Libraries geschuldet.

Sheeva P. schrieb:
> Vorher wurde hier noch behauptet, daß sich das ABI der C-Library so oft
> ändern würde, daß man sich nicht darauf verlassen könne, und Du hast dem
> nicht widersprochen...

POSIX ist standardisiert, da ist jede Bibliothek API-stabil (wenn sie 
die Funktionalität unterstützt). Das ist ne Nullaussage. Und die glibc 
gehört mit zu den ABI-stabilsten Bibliotheken überhaupt (was aber an 
massiver Kompatiblitätslogik liegt). Ebenfalls ne Nullaussage.

>> Vielleicht nen aktueller Firefox oder Evince?
> Die aktuellste Version von Mozilla Firefox arbeitet wunderbar auf dem
> schon etwas älteren Kubuntu 16.04 LTS -- ich schreibe gerade diese
> Antwort damit.

Ubuntu 16.04 ist ziemlich aktuell, das taugt ebenfalls nicht als 
Beispiel. Wie sieht's mit Ubuntu 9.04 aus, was du vorhin als Beispiel 
rangezogen hast?

> Evince ist in den aktuellen Versionen in den Repositories
> der Distributoren verfügbar. Wo ist denn Dein Problem?

Gilt das auch für dein Ubuntu 9.04?
Gilt das auch für die aktuelle git-Version?
Welche Patches braucht Ubuntu, um das Repository-Paket zu bauen?

Mir ging es hier hauptsächlich um Programme, die in den Repositories 
entweder nicht drin sind oder nur in einer zu alten Version (der Fall 
"der Bug ist im git gefixt").

>> Oder versuche mal, sowas wie UltraStar Deluxe (aber nicht die Beta) auf
>> einer halbwegs modernen Distribution zum Laufen zu kriegen. Protipp: Du
>> darfst auch auf einer antiken Distro bauen.
>
> Ich habe gerade wirklich keinen Bock, mir einen Free Pascal Compiler zu
> installieren, aber dem Projekt zufolge soll das gehen: [1].

Natürlich "soll das gehen", sonst hätte ich dir das ja nicht als 
Beispiel gebracht.

Es scheitert aber daran, dass libavcodec weder API- noch ABI-kompatibel 
ist, ältere Versionen mit neuen Compilern nicht bauen, ältere Versionen 
in den Repositories nicht vorhanden sind, und das Programm nicht gegen 
neuere Versionen baut.

Das ist eine andere Hausnummer als ein POSIX-kompatibles Hello-World 
ohne Abhängigkeiten.

>> Deswegen schrieb ich "(32-Bit)" dazu, und Microsoft hat dafür eine
>> verdammt gute technische Begründung für die Einschränkung.
> Ist das so?

Ja. Im 64 Bit-Modus funktioniert der vm86 nicht mehr, und das ist eine 
/Hardware/-Beschränkung. Solltest du eigentlich wissen...

> Dann haben die Linux-Leute eine mindestens genau so gute
> technische Begründung dafür,

Das, lieber Sheeva, hat damit überhaupt nichts zu tun.

Es gibt genau zwei mir bekannte Programme, welche unter Linux den vm86 
aktiv nutzen: X.Org (für int 10h) und DOSemu. Beide haben Updates 
erhalten, um auf x86_64 funktionsfähig zu bleiben.

>> Aber: Der alte Borgward funktioniert wunderbar auf neuen Straßen. Und
>> moderne Autos fahren wunderbar auf Straßen, die so neu sind wie der
>> Borgward.
>
> Das wiederum eher nicht. Auf Straßenqualitäten, für die der Borgward
> einst gebaut wurde, würden sich moderne PKW in kürzester Zeit erst den
> Unterboden und dann die Aufhängung ruinieren.

Du implizierst, dass ein neues Auto auf einer alten Straße auch wie ein 
neues Auto fahren muss. Das habe ich nicht behauptet. Du kannst nicht 
mehr nutzen, als die Infrastruktur hergibt, aber der kleinste gemeinsame 
Nenner zwischen Infrastruktur und Anwendung sollte funktionieren.

Und das funktioniert bei Linux nunmal deutlich schlechter als bei 
Windows (und selbst bei MacOS). Ob du das nun akzeptieren magst oder 
nicht.

S. R. schrieb:
> Du implizierst, dass ein neues Auto auf einer alten Straße auch wie ein
> neues Auto fahren muss.

Ich stelle fest, daß neue Autos auf alten Straßen schnell kaputt gehen.

> Das habe ich nicht behauptet. Du kannst nicht
> mehr nutzen, als die Infrastruktur hergibt, aber der kleinste gemeinsame
> Nenner zwischen Infrastruktur und Anwendung sollte funktionieren.

Tut er, der Kleinste Gemeinsame Nenner ist POSIX. Alles was darüber 
hinaus geht unterliegt einem mehr oder weniger schnellen Wandel, nicht 
nur in der Linux-Welt. Das ist der Preis für die Weiterentwicklung und 
natürlich auch eine Folge des modernen Paketmanagement -- das zwar für 
viele Zwecke sehr komfortable und für die jeweiligen Versionen der 
einzelnen Distributionen gut auf einander abgestimmte Bibliotheken 
mitbringt, aber die unterliegen dann eben alle dem besagten Wandel durch 
die Weiterentwicklung.

Für viele Funktionen der in einem modernen Linux vorhandenen 
Bibliotheken bringen die kommerziellen Anbieter wenig bis nichts mit, so 
daß Du in dem Umfeld letztlich wieder vor demselben Problem stehst: 
entweder Du benutzt eine komfortable Bibliothek und handelst Dir damit 
den Aufwand ein, sie in Deinen Softwarepaketen für bestimmte, am 
Paketmanager vorbeigehende Fälle mitdeployen zu müssen, oder Du machst 
alles selbst und bist dann auch nicht von den veränderlichen 
Schnittstellen fremder Bibliotheken abhängig. Your code, your choice.

> Und das funktioniert bei Linux nunmal deutlich schlechter als bei
> Windows (und selbst bei MacOS). Ob du das nun akzeptieren magst oder
> nicht.

Nun, wenn das für Dich so unerträglich ist, hast Du verschiedene 
Optionen: Du kannst die Library-Entwickler anhalten, ihre Schnittstellen 
stabiler zu halten oder bei Änderungen jeweils Kompatibilitätslayer 
einzuziehen, oder Du kannst bei Windows oder MacOS/X bleiben, oder Du 
kannst Dich schmollend in eine hübsche Ecke zurückziehen und der Welt 
(nicht mir, wohlgemerkt, da ich weder für diese Situation verantwortlich 
bin, noch etwas daran ändern könnte oder wollte) Dein Leid klagen. Tut 
mir leid, aber sonst fallen mir keine anderen Möglichkeiten ein. Und Dir 
ja anscheinend auch nicht, sonst hättest Du Dich vermutlich etwas 
konstruktiver eingebracht als immer nur die Klage zu wiederholen, daß 
das Gras auf der anderen Seite des Flusses angeblich so viel grüner, 
saftiger und überhaupt sei. ;-)

Wenn ich mir allerdings die Build Instructions und -Tools für KDevelop 
unter Windows anschaue, gewinne ich nicht gerade den Eindruck, daß dort 
alles Friede, Freude, Eierkuchen sei. Immerhin haben die KDE-Entwickler 
dafür sogar ein eigenes Build-System namens Craft entwickelt, das mit 
ca. 18 kLOC Python-Code um mehr als den Faktor 50 größer ist als Svens 
Skript für AppImage und für dessen Nutzung erst einmal eine 
beeindruckende Reihe von Softwarepaketen manuell heruntergeladen und 
installiert werden muß: Python, Microsofts DirectX SDK, die Powershell 
und, (Überraschung!) ein Compiler wie MingW. Und das nur zum Übersetzen, 
von der Paketierung in einen Windows-Installer war dabei noch gar keine 
Rede... ;-)

Zusammenfassend bist du also mit der derzeitigen Situation nicht nur 
zufrieden, sondern auch glücklich und siehst keinerlei Probleme oder 
Verbesserungspotential.

Naja, da kann man dann wohl nichts machen.

S. R. schrieb:
> Zusammenfassend bist du also mit der derzeitigen Situation nicht nur
> zufrieden, sondern auch glücklich und siehst keinerlei Probleme oder
> Verbesserungspotential.

Natürlich sehe ich gewisse Probleme und ein Verbesserungspotential, 
fürchte jedoch, daß die Möglichkeiten für Verbesserungen eng begrenzt 
sind.

Im Wesentlichen laufen diese Möglichkeiten, wie angedeutet, darauf 
hinaus, die Bibliotheksentwickler dazu anzuhalten, ihre APIs zu 
stabilisieren, was sie wiederum früher oder später in die Situation 
bringen würde, keine neue Funktionalität mehr einbauen, oder 
möglicherweise sogar Designfehler nicht mehr zeitnah korrigieren zu 
können.

Auch die Sache mit den Kompatibilitätslayern sehe ich durchaus kritisch, 
denn das würde wertvolle Entwicklerressourcen binden, die ich sehr viel 
lieber in der Weiterentwicklung der Software genutzt sehe.

Ansonsten gäbe es natürlich noch die Möglichkeit, eine zentralen Instanz 
zur Steuerung einzurichten, was allerdings viele mir persönlich bekannte 
OSS-Entwickler eher abschrecken, und obendrein bei jeder Änderung wieder 
haargenau dieselben Probleme provozieren würde.


Andererseits betreffen die gennanten Probleme lediglich zwei Gruppen von 
Leuten: erstens Anwender, die entweder alte, schlecht gepflegte Software 
auf neuen Systemen oder die neue Software auf alten, schlecht gepflegten 
System einsetzen wollen. Und zweitens Entwickler, die die Wünsche dieser 
Anwender erfüllen wollen und dadurch hohe Packaging-Aufwände haben.

Für diese beiden Gruppen gibt es Lösungen, die hier schon genannt 
wurden:

1.) Parallel zum Paketmanager benutzbare Techniken wie AppImage et al.
2.) Virtuelle Maschinen.
3.) Container wie LXC oder Docker.
4.) Software selbst zu übersetzen.

Es gibt also Lösungen. Ja, sie bedeuten einen Aufwand, wahlweise für die 
Entwickler, oder für die Anwender, oder sogar für beide. Das ändert aber 
nichts an ihrer Existenz, sondern nur an ihrem Komfort.


Außerdem bieten die Paketmanager für 95% der Anwender und 
Anwendungsfälle -- ich würde sogar vermuten, für erheblich mehr, aber 
sei's drum -- eine komfortable, einfach zu bedienende und 
leistungsfähige Lösung. In vielen Gesprächen wird das Paketmanagement 
als einer der wichtigsten, oft sogar als der wichtigste Punkte genannt, 
der Linux so komfortabel und angenehm macht. Deswegen darf dessen 
Funktion nicht gestört oder behindert werden.

Wenn Du also einen besseren Lösungsvorschlag als die oben Genannten 
hast, der dem Paketmanagement nicht in die Quere kommt, können wir gern 
darüber reden. Ich fürchte nur, durch das Beklagen und Aufbauschen 
relativ selten auftretender Probleme kaum zu einer Lösung für solche 
Fälle führt. Sofern Du konstruktive, praktikable Vorschläge hast: gerne, 
immer her damit. Ich bin gerne der Erste, der Deinen konstruktiven 
Vorschlag unterstützt. ;-)

> Naja, da kann man dann wohl nichts machen.

Nein, vermutlich nicht. Ich bin einfach ein sturer Bock. ;-)