Gude, mittlerweile nutze ich u.a. seit 2 Jahren Beruflich die Visual Studio IDE für die Entwicklung von Windows Forms Applications, womit ich auch sehr zufrieden bin! Nun habe ich erste Schritte in Richtung WPF gewagt. Es ist mir klar das signifikante Unterschiede zu WF bestehen. Mich beschäftigt jedoch die Frage, wohin sich die Zukunft entwickelt? Auf dem Stellenmarkt lässt sich zugleich eine Nachfrage für Programmierer auf WPF Ebene feststellen. Dennoch bin ich mir nicht ganz sicher wie es in der Industrie aussieht. Wo geht eurer Meinung nach der Trend hin? Gruß 6Fy
Niemand verwendet Windows Forms, kommerziell komplett unbrauchbar.
hexaFy schrieb: > Wo geht eurer Meinung nach der Trend hin Weder - Noch. Beide Systeme sind für richtige Software unbrauchbar. Es mangelt an Plattformübertragbarkeit, an Flexibilität (wer würde WinWord oder Eagle mit den Feameworks aufbauen) und nicht mal für einfache Anwendungen wie Versicherungstarifberechnung sind sie zu gebrauchen, denn wer will schon beim Hinzufügen eines Feldes an mehreren Stellen Code hinzufügen müssen, Felder müss(t)en generisch abgehandelt werden.
das sind einander nachfolgende technologien.. winforms -> WPF -> UWP stand jetzt ist WPF das maß der dinge, weil UWP nur auf Windows 10 funktioniert. Das wird dann in Zukunft mehr und mehr interessant werden..
Günther schrieb: > Niemand verwendet Windows Forms, kommerziell komplett unbrauchbar. wir vertreiben Kommerzielle Produkte mit Windows Forms. So unbrauchbar ist es also nicht. WPF finde sehr unhandlich und es braucht auch mehr Resourcen. Windows Forms wird wohl WPF überleben. Eventuell bringen sie ja für .net core etwas neues raus. (Da fehlt ja die komplette GUI noch, vermutlich sind sie auch mit WPF nicht so zu frieden).
MaWin schrieb: > denn wer will schon > beim Hinzufügen eines Feldes an mehreren Stellen Code hinzufügen müssen, > Felder müss(t)en generisch abgehandelt werden. auch MaWin rede doch lieber über ding die du kannst. Hast doch schon oft bewiesen das du noch .net nicht wirklich viel Ahnung hast. Windows Forms erlaubt die komplette GUI zu Laufzeit zu erzeugen, da kann man beliebige Felder hinzufügen oder entfernen.
Hi, für .NET oder Powershell ist WPF schon etwas schöner zu programmieren und anzuwenden als die Forms. Allerdings habe ich keine Erfahrung mit wirklich großen GUIs. Ich komme auch ursprünglich aus der Web-Programmierung, da ist mir der Umgang mit XAML für die Oberflächengestaltung nicht ganz so fern. Gruß
Wenn man was neues anfängt, dann WPF oder UWP nehmen. Sieht schicker aus und ist einfacher zu handhaben wenn man es erstmal verstanden hat.
Für mich - steinigt mich dafür - ist aktuell eindeutig Qt das Maß der Dinge. Selbst für native Windows-Anwendungen tu ich mir Visual Studio nicht mehr freiwillig an. Verglichen mit QtCreator (oder selbst mit Eclipse) ist VS m.M.n. ziemlich steinzeitlich. Konzeptionell hatte Windows irgendwie schon immer Schwächen mit seiner GUI, egal ob damals nackt WinAPI oder MFC oder WinForms. Allesamt fühlten sie sich unfertig an.
Mein erster Job waren DOS-Oberflächen für Grossrechner-Programme. Dann kam die Dbase-Blockgrafik auf Textbildschirmen. Danach üble Tricksereien auf Win3.1 . Mit Delphi wurde es etwas besser. Smalltalk war leider ein Rohrkrepierer. Mit der Qt ging es dann so richtig gut. Nur bin ich dann in eine ganz üble Sache rein gerutscht - Webbrowser als Oberfläche für Anwendungsprogramme. Du musst sowieso andauernd was neues lernen. Am besten in das einarbeiten, was dir liegt. Wenn du Spass dran hast, wirst du so gut, dass du immer einen Job findest.
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.
Qt ist in der Tat mächtig. Das nutze ich ebenfalls auf der Arbeit. Nur ist es Heute relativ egal ob du im Qt Framework auf C/C++ Basis oder im .NET Framework auf C# - WinForms oder WPF arbeitest (unter bestimmten Anforderungen). Wenn du auf Hardware mit Treiber-Schnittstellen zurückgreifst, wird das SDK zu 99% mit Bibliotheken für alle gängigen Programmiersprachen mitgeliefert. In den letzten Zwei Jahren wurden meinerseits zwei bis drei Projekte via C# - WinForms welche überwiegend Hardware steuern (selbstgebaute, vom Kunden oder von Drittanbietern). Es ist auch kein Geheimnis das man hier bei bestimmten Timing-Anforderungen mit diesem Framework an gewisse Grenzen stößt (ja, es gibt auch hier Mittel und Auswege). Hierbei ist jedoch Qt von Vorteil. Aufgrund eines Projektes welches hohe Timing-Anforderungen mit sich brachte, wurde dies per C/C++ im Qt Framework realisiert. Gruß 6fY
Im aktuellen Projekt wird hier WPF eingesetzt, ich vermute nicht, dass das so schnell von der Bildfläche verschwinden wird.
Rolf M. schrieb: > Rentner schrieb: >> 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. Wenn ich mir Google Docs oder Kibana anschaue, kann man mit den Buzzwords aber schon ziemlich ausgereifte GUIs entwickeln. Und die Technik bleibt ja nicht am heutigen Tage stehen. HTML5 enthält schon einige Formularelemente wie <button>, <menu>, <canvas> und <command> -- um nur einige zu nennen -- deren Hintergrund eindeutig die Entwicklung von GUIs unter HTML ist. Auch QML/Qt Quick weisen in die Richtung, daß GUIs künftig eher deklarativ in einer Markup-Sprache erstellt werden. Gleichzeitig gibt es in aktuellen ECMAScript- Versionen die Bestrebung, die klassische Prototypen-basierte Objektorientierung der Sprache um klassische OO-Konzepte wie Klassen und Vererbung zu erweitern. Ohnehin ist es ja längst anerkannter Stand der Technik, GUI-Anwendungen multilayered etwa nach dem MVC-Pattern zu entwickeln und die eigentliche GUI (View) vom Datenmodell (Model) und der Funktionalität (Controller) zu trennen. Ob ein GUI-Element dann mit 'new QPushButton("blabla", this);' erstellt und dann über Signale wie clicked(), oder mit '<button>' erzeugt und mit ECMAScript-Events wie onClick() mit dem Applikationscode verknüpft werden, ist doch vor allem eine syntaktische Marginalie. Stand heute tendiere ich jedenfalls schon seit mehreren Jahren dazu, nur noch in Ausnahmefällen -- etwa wenn große Datenmengen in near-realtime visualisiert werden müssen -- auf klassische GUIs zu setzen. Webbrowser haben einfach eindeutige Vorteile: sie sind überall vorhanden und müssen nicht, wie klassische GUI-Applikationen, eigens auf die Zielrechner der Benutzer deployt werden. Webserver-Anwendungen kann man ohne größeren Aufwand zentral konfigurieren und pflegen, wiederum ohne die klassichen Deploymentprozesse. HTML-GUIs können außerdem häufig sehr viel besser mit unterschiedlichen Ausgabemedien und -Formaten umgehen, ohne daß sich der Entwickler mit verschiedenen Layout-Managern herumschlagen muß. Und die Plattformunabhängigkeit hinsichtlich der Endgeräte ist prima: anstatt für jede Zielplattform ein eigenes Binary zu erzeugen und bei der Entwicklung entsprechende Workarounds zur Berücksichtigung der jeweiligen Umgebung zu beachten, können ordentliche HTML-GUIs mit allen üblichen Plattformen benutzt und bedient werden, egal ob mit Windows, MacOS, Linux oder *BSD, egal ob von einem Desktop, Laptop, Netbook, Tablet oder Mobiltelefon auf die Applikation zugegriffen wird. Und zuletzt vereinfacht das Konzept eine zentralisierte Datenhaltung und das Backup. Ja, im Moment ist die Entwicklung von Webbrowser-GUIs in vielen Fällen noch ein wenig hakelig, aufwändig, und arbeitsintensiv, und zweifellos dürfte es durchaus weniger von all dem sein. Aber wenn ich mir so den Gesamtaufwand betrachte und überlege, wieviel Zeit und Aufwand ich auf der anderen Seite dann bei der Entwicklung plattformunabhängiger Anwendungen, bei Deployment, Konfiguration, Wartung und Pflege einspare, lohnt sich dieser etwas höhere Entwicklungsaufwand schon jetzt, IMHO. Das ist auch der Trend, den ich bei Kunden beobachte: immer mehr interne Anwendungen werden in die Webportale transferiert, immer häufiger wird webbasierten Anwendungen der Vorzug vor klassischen GUI-Anwendungen gegeben. Ansonsten bin ich zuletzt über das C++-Webframework "Wt" gestolpert, das es ermöglichen soll, Webanwendungen nach ähnlichen Patterns wie klassische GUIs zu entwickeln. Habe ich mir noch nicht genauer angeschaut, sah auf den ersten Blick aber interessant genug aus, um das mal zu tun.
Karl Käfer schrieb: > Und die > Plattformunabhängigkeit hinsichtlich der Endgeräte ist prima: anstatt > für jede > Zielplattform ein eigenes Binary zu erzeugen und bei der Entwicklung > entsprechende Workarounds zur Berücksichtigung der jeweiligen Umgebung > zu > beachten, Aber der aufwand dafür ist doch sehr hoch. man muss alte Browser und neue Browser unterstützen. HTML ändert sich ständig, es fallen auch dinge weg. man ist damit immer gezwungen seine Anwendung unter jeder neuen Browserversion zu testen. Eine normale Anwendung braucht da weniger Wartung. Als Anwender finde ich Browser-Apps einfach zu langsam. Ich verwende auch noch ein Mailclient und arbeite da nicht im Browser. Es nervt einfach wenn man Mails mal schnell durchscrollt und der Inhalt erst nach einigen 100ms erscheint.
Peter II schrieb: > Aber der aufwand dafür ist doch sehr hoch. man muss alte Browser und > neue Browser unterstützen. HTML ändert sich ständig, es fallen auch > dinge weg. man ist damit immer gezwungen seine Anwendung unter jeder > neuen Browserversion zu testen. Entschuldige, aber das ist Unfug. Die Unterschiede zwischen den Browsern sind nicht zuletzt dank automatischer Updates etc. nicht mehr sonderlich groß, und für den Rest sorgen ordentliche Frameworks wie jQuery, Angular und Co. Die Behauptung, HTML ändere sich ständig, ist falsch -- tatsächlich muß man nicht jede Neuerung sofort mitmachen, und die Betriebssysteme sowie Browser ändern sich wesentlich schneller und häufiger als die einschlägigen HTML-Standards. Das sieht nur im Moment so aus, weil gerade HTML5 in der Einführung ist -- aber HTML4-Seiten laufen immer noch völlig problemlos und werden das für die nächsten Jahre wohl auch weiterhin tun. Zwischen HTML4 und und HTML5 liegen 16 Jahre -- wie viele Windows-Versionen mit jeweils geänderter Technik, Optik und Haptik hat denn alleine Microsoft in dieser Zeit herausgebracht? Genau. > Eine normale Anwendung braucht da weniger Wartung. Eine plattformunabhängige Anwendung, die auch auf mehreren Plattformen benutzt wird, ist mindestens genauso wartungsintensiv. Das merkst Du nur nicht, weil Du nur in Deiner kleinen Windows-Desktop-Welt unterwegs bist. Aber wer neben Windows auch noch Android, MacOS, iOS und Linux und zudem verschiedenste Bildschirmauflösungen unterstützen muß, kommt hinsichtlich des Wartungsaufwandes nativer Anwendungen und Apps schnell auf riesige Aufwände. Daß der Entwicklungsaufwand bei Websoftware nicht zuletzt auch wegen der bekannten Schwächen von ECMAScript derzeit noch etwas höher ist, steht außer Frage. Die Aufwände für Pflege, Wartung, Deployment und Betrieb hängen zwar immer auch von Faktoren wie der Anzahl der Nutzer ab, liegen jedoch regelmäßig unter jenen für eine Desktop-Software -- zumindest im Enterprise-Umfeld. > Als Anwender finde ich Browser-Apps einfach zu langsam. Ich verwende > auch noch ein Mailclient und arbeite da nicht im Browser. Es nervt > einfach wenn man Mails mal schnell durchscrollt und der Inhalt erst nach > einigen 100ms erscheint. Das kommt darauf an, wie schnell die Netzwerkverbindung und der Server sind -- und ob die Mails nur on-demand oder im Hintergrund geladen werden. Im letzteren Fall scrollt die Veranstaltung genauso schnell wie in Deinem Mailclient.
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). z.b. wollen sie jetzt den JavaScript Dialog entfernen. Wenn man ihn eingesetzt hat geht dann nichts mehr.
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 :-)
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.
ich behaupte mal: die sprache muss zur anforderung passen. was nutzen mir html5 und javascript wenn ich eine massendruckanwendung schreiben muss? was nutzt mir c# et al wenn es kein XSL-FO framework gibt? zu guter letzt behaupte ich zusätzlich, dass jeder die sprache schätzt die er gut kennt und kann - und ich bezweifle das es viele leute gibt, die schon komplexe anwendungen in java und c# und c++ und pascal geschrieben haben, und tatsächlich fundiert vergleichende aussagen über die brauchbarkeit dieser sprachen machen können. "Was ist die Zukunft? WPF oder WinForms?" - ehrlicherweise: keine ahnung. ich entwickle unter java. geile sprache ;-)
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.
Karl Käfer schrieb: > zentral konfigurieren und pflegen, wiederum ohne die klassichen > Deploymentprozesse. Das ist ja das schlimme. 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. 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.
c.m. schrieb: > was nutzen mir html5 und javascript wenn ich eine massendruckanwendung > schreiben muss Richtig, gar nichts, für Massendruckanwendungen gibt es eh kein vernünftiges (WYSIWYG) Werkzeug, WinWord und FOP sind untauglich.
MaWin schrieb: > c.m. schrieb: >> was nutzen mir html5 und javascript wenn ich eine massendruckanwendung >> schreiben muss > > Richtig, gar nichts, für Massendruckanwendungen gibt es eh kein > vernünftiges (WYSIWYG) Werkzeug, WinWord und FOP sind untauglich. wie kommst du auf winword? apache FOP benutzen wir als zentrales dokumentengenerierungsframework. da es keine WYSIWYG editoren gibt schreibe ich grade einen XSLT designer, der es den report-"entwicklern" einfacher machen soll (mit templates, pdf-vorschau, direkter datenbankanbindung und versionierter speicherung. bonbons halt). WYSIWYG brauchen wir ehrlich gesagt auch nicht - das zusammeneditieren von ein wenig XML ist zumutbar, und wird auch ohne murren angenommen - vor allem weil die leute oracle reports kennen, und wissen wie scheisse DAS ist.
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.
Sheeva P. schrieb: > 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: 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. Beim Browser kann man leider nicht sagen, die Webseite bitte mit Firefox 45 ausführen. 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. 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.
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: > 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? 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? Ich habe keine Werbung für irgendetwas gemacht. ich habe nur gesagt das ich finde das Webanwendungen mehr Wartung brauchen als Nativ-Anwendungen. Nicht mehr und nicht weniger. Und genau das hast du bestätig - Anwendungen brauchen Wartung. 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. Dich stört wenn mehre Frameworkts auf der Platte installiert sind, aber empfiehlst mehre Broswer? Nur Blöd das es für alten Browser keine Sicherheitsupdates gibt, für alte Frameworks eine Zeitlang schon.
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.
:
Bearbeitet durch User
Webserver schön und gut. Aber was passiert wenn ich eine Schnittstelle zu einem Stand-Alone Gerät per Webserver einrichte ? Ist die denn genauso sicher wie meine GUI, sei es in Qt oder .NET?
hexaFy schrieb: > Aber was passiert wenn ich eine Schnittstelle > zu einem Stand-Alone Gerät per Webserver einrichte ? wie ist das zu verstehen?
Der erste und 2. Hauptsazu für Zukunftsforscher: 1. kommt es anders als 2. man es denkt!
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Sheeva P. schrieb: > 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! du hast es immer noch nicht verstanden. Die alten APIs bei C++ und .net bleiben erhalten. Alten Anwendungen laufen einfach weiter, das ist der große unterschied. Auch wenn jede Wochen ein neue C++ Standard erscheint, hat das keine Auswirkung auf alte Programme. > Zwischen den letzten Major-Versionen des HTML-Standards lagen 16 Jahre! das ich nicht lache. Web besteht doch etwas mehr als nur Html. CSS und Javascript ändern sich fast monatlich. https://en.wikipedia.org/wiki/ECMAScript > 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. in nachhinein kann man das immer behaupten. Wenn es aber für eine gewissen Funktionalität nur eine proprietären Lösung gibt hat man wohl kaum eine Wahl. Und niemand kann 10 oder 15 Jahre in die Zukunft sehen und wissen was kommen wird. Vor 10 Jahren haben viele auf Flash auch für Applikationen gesetzt, das ist jetzt auch tot. > 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. Alle Frameworks von 2.0 bis 4.0 in 64 und 32 bit brauchen nur 1.2GB. Könnte sogar weniger sein, wenn man ich nicht SDK sondern nur die Runtime installiert.
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. Sven B. schrieb: > 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. Das beschreibt die Situation recht gut. 95%, wenn nicht sogar mehr, der Softwareinstallationen kann ein Paketmanager bequem handlen. Trotzdem gibt es manchmal Situationen wo ein Installer schon sinnvoll ist. Das Gros der in Repositorys gehosteten SW dürften OSS-Projekte sein. Da kann natürlich jeder Interessierte sich den Upstream nehmen, eventuell darin herumpatchen und ein Paket für seine Lieblingsdistro maintainen. Bei proprietärer SW geht das allerdings weniger leicht. Natürlich kann ein Binary auch per Paketmanager verteilt werden ohne dass die Sourcen offengelegt werden müssen. Allerdings kann keine Firma sich den Aufwand leisten und Pakete für sämtliche gängigen Distros in sämtlichen Versionen maintainen. Da macht ein Windows-Style-Installer schon Sinn. Beispiel wären hier viele kommerzielle Spiele, die mittlerweile auch immer mehr für Linux erhältlich sind. Der Publisher gog-games gibt sich z.B. große Mühe native Linux-Versionen bereitzustellen. Unter anderem gibts da mittlerweile einen nativen Build von Kerbal Space Program oder vielen AD&D-Klassikern. Die werden z.B. per install.sh verteilt. Ich sehe aber keine Möglichkeit wie der Publisher das besser handlen könnte.
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 ...
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. Der Kernel ist zum Glück etwas stabiler was die ABI angeht. Wenn eine X-GUI vorhanden ist, dann wird es wirklich komplizierter.
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. ;-)
Sheeva P. schrieb: > 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. nur das sich dann das verhalten ändert https://developer.mozilla.org/en-US/docs/Web/API/Window/alert > Starting with Chrome 46.0 this method is blocked inside an <iframe> > unless its sandbox attribute has the value allow-modal.
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.
Nach dem ganzen Gezanke hab ich den Überblick verloren. Was ist denn nun Sheeva's Aussage? Dass Paketmanager das Beste seit geschnitten Brot sind und alles andere große Kacke? Ich würd da mal einen weniger radikalen Standpunkt wählen: Paketmanager sind etwas sehr sehr Feines und ich würd nicht mehr ohne leben wollen. Jedoch gibt es - wie immer - sinnvolle Ausnahmen. Manchmal kommt ein Konzept eben an seine Grenzen, dann ist es gut und richtig sich anderweitig zu behelfen.
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
Michael B. schrieb: > 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 Du scheinst tiefgreifende Probleme zu haben. Diesen Text hast du Ende 2016 verbrochen, hab ich grad nur zufällig gesehen weil irgendwer diesen alten Waagen-Thread hochgekramt hat: Michael B. schrieb: > pegel schrieb: >> Was ist so besonders an der Übertragung zu diesen OS? > > Daß absolut kein Mensch das Exotensystem hat, Marktanteil 1,3% > http://www.pcwelt.de/news/Aktuelle_Marktanteile_OS__Browser_und_Suchmaschinen-Net_Applications-9014661.html > dafür baut Niemand Waagen, die sich schon mit Windows-Ankopplung > kaum verkaufen. Was ist denn der Grund für deinen Kreuzzug? Bist du sexuell nicht ausgelastet?
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.
:
Bearbeitet durch User
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: > 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)
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. ;-)
Hört auf zu streiten, wo es nichts zu streiten gibt. Unter Linux hat man die Wahl, welches vorgehen man wählt, und man wählt halt ein vorgehen. Unter Windows gibt es eigentlich nur ein Vorgehen, das ist halt so. Das eine System hat da Vorteile, das andere dort, man nimmt halt das, was man braucht, oder besser findet, oder man muss es selbst machen. Ich kann mit Linux Sachen machen, welche mit Windows nicht möglich sind, und umgedreht gilt das selbe, und mit einem anderen OS sind wieder ganz andere Sachen möglich, welche mit Linux und Windows nicht gehen. Und nun wieder zurück zum Thema bitte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.