Die Arbeit des Maintainers erfordert Fleiss, weil Ordnung halten immer Handarbeit ist und kontinuierlich erfolgen muss. Und genau das macht es Anwendern so angenehm, dieser Fleiss führt zu schlanken und leicht wartbaren Systemen. Irgend jemand muss die Arbeit machen und sie dem Entwickler aufzuhalsen, weil der einmal mit dem Maintainer nicht zufrieden war, ist nicht die Lösung sondern eine altes Windowsproblem (DLL-Hell?). Eine Paketverwaltung sorgt dafür, das dynamische Libraries den Hauptspeicher und Festspeicher entlasten und Sicherheitslücken gobal behoben werden.
Flatpak kann vieles vereinfachen im Gebiet der Sicherheit und Anwendungsdistribution, aber Maintainerarbeit auf Entwickler zu verlagern lässt die Arbeit nicht verschwinden. Anwendungsentwickler sind denkbar schlecht im kontinuierlichen Pflegen von Libraries, dann haben wir Sicherheitslücken. Und je mehr Flatpaks man installiert um so mehr Speicher geht verloren, weil die zwangsläufig häufig die gleichen Libraries mitliefern müssen. Ich habe als Entwickler gar keine Lust mich mit den Fixes JSONCPP zu beschäftigen, so lange die API-Stabil bleibt ist alles gut! Weder bin ich Admin, Datenbankadministrator noch Servicemitarbeiter - es gibt dafür mit gutem Grund eigene Berufe und Aufgabenbereiche (Devops sehe ich daher auch nicht als Lösung...).
Auch die Paketverwaltung hat ihre Problem, ist ein Paket mal nicht vorhanden wird das bequeme Leben sehr anstrengend - selbst wenn alle Abhängigkeiten erfüllt sind, kann man eigentlich nur Programmieren den einfachen Dreisatz zumuten (configre && make && make install). Das wirkt auf Windowsanwender dann erstmal anstrengend, gerade auf die Sorte "ich lade mir die Nvidia-Binärtreiber selbst herunter" - welche die Paketverwaltung also nicht verstanden haben.
Und am Ende eine Warnung: Wer meint wild Flatpaks auf die Anwender loszulassen, erlebt sind zweites Windows (Viren) oder schlimmer - sein zweites Android (nix gepatched, alles offen wie eine Scheunentor). Paketverwaltungen sind eine Whitelist und die funktionieren ganz gut, man vertraut sowieso grundsätzlich der Distribution.
http://www.stickycomics.com/wp-content/uploads/update_for_your_computer.jpg Linux ist bequem, ich verwende es weil Updates überwiegend angenehm sind.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Aug 2017 um 13:48.
Dem kann ich mich anschließen. Für Entwickler bleibt unter Verwendung des Paketmanagements nur der Mehraufwand, in allen zu unterstützenden Distributionen unter den kompatiblen Versionen der Wunschbibliothek, diejenige mit dem kleinsten Featureset herauszusuchen und auf Eignung für das eigene Projekt zu prüfen. Ist diese geeignet, so sollte auch damit entwickelt werden. Ist sie es nicht, könnten Flatpaks für einzelne Distributionen eine Lösung sein, aber wie wir alle wissen siegt am Ende die Faulheit / Gewinnmaximierung und oben genannter Mehraufwand wird gar nicht erst in Erwägung gezogen...
Die DLL-Hölle unter Windows gibt es, seit es unter Windows DLL gibt. Aber offensichtlich muss ja unbedingt überall Windows kopiert werden. Ich will kein vermeintlich besseres Windows. Ich nutze Linux, weil ich Linux will und eben nicht Windows.
Wenn immer mehr nur noch Windows kopiert wird, kann ich gleich bei dem Gefrickel aus Redmond bleiben, bzw. dorthin wieder zurückkehren. Ich bin froh, dass Linux eben nicht wie Windows ist, sondern sein eigenes Konzept verfolgt.
Nochmal, deine Argumentation hinkt schon bei der Definition von DLL-Hölle. Die DLL-Hölle ergibt sich aus dem überschreiben von DLLs mit anderen gleichnamigen Libraries, die aber eine andere Schnittstellen-Spezifikation haben. Das führt zu nicht funktionierenden Anwendungen, Abstürzen etc. Bitte nochmal informieren, was die DLL-Hölle wirklich ist. Was du als solche bezeichnest hat eben nichts mit der DLL-Hölle zu tun.
Ich habe 20 Jahre lang Windows (von Win95 bis Win7) genutzt und es wäre nicht das erste mal, dass sich, von Programmen parallel installierte, verschiedenen Versionen von DLLs beißen und Ärger machen. Das ist ebenso ein Teil der DLL-Hölle, wie das von dir beschriebene Problem.
http://kmkeen.com/maintainers-matter/index.html
Die Arbeit des Maintainers erfordert Fleiss, weil Ordnung halten immer Handarbeit ist und kontinuierlich erfolgen muss. Und genau das macht es Anwendern so angenehm, dieser Fleiss führt zu schlanken und leicht wartbaren Systemen. Irgend jemand muss die Arbeit machen und sie dem Entwickler aufzuhalsen, weil der einmal mit dem Maintainer nicht zufrieden war, ist nicht die Lösung sondern eine altes Windowsproblem (DLL-Hell?). Eine Paketverwaltung sorgt dafür, das dynamische Libraries den Hauptspeicher und Festspeicher entlasten und Sicherheitslücken gobal behoben werden.
Flatpak kann vieles vereinfachen im Gebiet der Sicherheit und Anwendungsdistribution, aber Maintainerarbeit auf Entwickler zu verlagern lässt die Arbeit nicht verschwinden. Anwendungsentwickler sind denkbar schlecht im kontinuierlichen Pflegen von Libraries, dann haben wir Sicherheitslücken. Und je mehr Flatpaks man installiert um so mehr Speicher geht verloren, weil die zwangsläufig häufig die gleichen Libraries mitliefern müssen. Ich habe als Entwickler gar keine Lust mich mit den Fixes JSONCPP zu beschäftigen, so lange die API-Stabil bleibt ist alles gut! Weder bin ich Admin, Datenbankadministrator noch Servicemitarbeiter - es gibt dafür mit gutem Grund eigene Berufe und Aufgabenbereiche (Devops sehe ich daher auch nicht als Lösung...).
Auch die Paketverwaltung hat ihre Problem, ist ein Paket mal nicht vorhanden wird das bequeme Leben sehr anstrengend - selbst wenn alle Abhängigkeiten erfüllt sind, kann man eigentlich nur Programmieren den einfachen Dreisatz zumuten (configre && make && make install). Das wirkt auf Windowsanwender dann erstmal anstrengend, gerade auf die Sorte "ich lade mir die Nvidia-Binärtreiber selbst herunter" - welche die Paketverwaltung also nicht verstanden haben.
Und am Ende eine Warnung:
Wer meint wild Flatpaks auf die Anwender loszulassen, erlebt sind zweites Windows (Viren) oder schlimmer - sein zweites Android (nix gepatched, alles offen wie eine Scheunentor). Paketverwaltungen sind eine Whitelist und die funktionieren ganz gut, man vertraut sowieso grundsätzlich der Distribution.
http://www.stickycomics.com/wp-content/uploads/update_for_your_computer.jpg
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Aug 2017 um 13:48.Linux ist bequem, ich verwende es weil Updates überwiegend angenehm sind.
Dem kann ich mich anschließen.
Für Entwickler bleibt unter Verwendung des Paketmanagements nur der Mehraufwand, in allen zu unterstützenden Distributionen unter den kompatiblen Versionen der Wunschbibliothek, diejenige mit dem kleinsten Featureset herauszusuchen und auf Eignung für das eigene Projekt zu prüfen. Ist diese geeignet, so sollte auch damit entwickelt werden. Ist sie es nicht, könnten Flatpaks für einzelne Distributionen eine Lösung sein, aber wie wir alle wissen siegt am Ende die Faulheit / Gewinnmaximierung und oben genannter Mehraufwand wird gar nicht erst in Erwägung gezogen...
who knows
> altes Windowsproblem (DLL-Hell?)...
Die DLL-Hell Problem existiert auf Windows schon seit mindestens 15 Jahren nicht mehr. So what's the point?
Die DLL-Hölle unter Windows gibt es, seit es unter Windows DLL gibt. Aber offensichtlich muss ja unbedingt überall Windows kopiert werden. Ich will kein vermeintlich besseres Windows. Ich nutze Linux, weil ich Linux will und eben nicht Windows.
Wenn immer mehr nur noch Windows kopiert wird, kann ich gleich bei dem Gefrickel aus Redmond bleiben, bzw. dorthin wieder zurückkehren. Ich bin froh, dass Linux eben nicht wie Windows ist, sondern sein eigenes Konzept verfolgt.
Nochmal, deine Argumentation hinkt schon bei der Definition von DLL-Hölle. Die DLL-Hölle ergibt sich aus dem überschreiben von DLLs mit anderen gleichnamigen Libraries, die aber eine andere Schnittstellen-Spezifikation haben. Das führt zu nicht funktionierenden Anwendungen, Abstürzen etc. Bitte nochmal informieren, was die DLL-Hölle wirklich ist. Was du als solche bezeichnest hat eben nichts mit der DLL-Hölle zu tun.
Ich habe 20 Jahre lang Windows (von Win95 bis Win7) genutzt und es wäre nicht das erste mal, dass sich, von Programmen parallel installierte, verschiedenen Versionen von DLLs beißen und Ärger machen. Das ist ebenso ein Teil der DLL-Hölle, wie das von dir beschriebene Problem.