Von sbsjsjsjs am Fr, 29. September 2017 um 20:52 #
Die meisten Devs stellen auch kompilierte Pakete zur Verfügung. Sie erstellen auch Makefiles.
Meine Frage hast du nicht beantwortet, was soviel heißt, dass du wie jeder andere Kompilierer, nichts anpasst. Dann kannst du auch das vorkompilierte Paket nehmen und dir die Mühe sparen.
Veränderungen am Build Prozess (Optimierung, Abhängigkeit, Prozessor Architektur) ist ohnehin nicht sinnvoll wenn man nicht aktiv am Projekt mitarbeitet.
Von Alter Sack am Fr, 29. September 2017 um 21:36 #
Halt mal bitte den Ball flach, okay? Ich muss mich nicht rechtfertigen, was ich mit mit freiem Code mache, solange es der Lizenz entspricht. Ich muss auch keine Unterstellungen beantworten. Ich habe freie Software immer so begriffen, dass ich mit dem Code alles machen darf, was die Lizenz erlaubt. Ich werde auf das, was ich unter "brauchbares System" verstehe, auch nicht weiter eingehen.
Veränderungen am Build Prozess (Optimierung, Abhängigkeit, Prozessor Architektur) ist ohnehin nicht sinnvoll wenn man nicht aktiv am Projekt mitarbeitet.
Okay, mal ein unverfängliches Beispiel: Ich dürfte deiner Meinung nach also nicht xu4 , ein freies Remake von Ultima IV, für ARM kompilieren, weil ich nicht aktiv am Projekt mitarbeite?
Von Verfluchtnochmal am Sa, 30. September 2017 um 00:21 #
Ja was denn - Benenne deine Probleme oder halte das Maul!
du bist doch nur genauso ein Versager wie die paar schreihälse die sich dauernd über systemd beschweren dabei so klingen wollen als wären sie die Mehrheit und ausser "alles anders, zu dumm und zu faul" keine Argumente vorbringen ausser dass der Schwager vom Halbbruder auch sagt
Läuft @home als systemwide systemd-unit seit die Maschine 2011 aufgesetzt wurde 24 Stunden am Tag ohne Zucker
Da waren von Fedora 15 bis 25 auch 10 Dist-Upgrades dabei
Läuft auf der workstation im Büro genauso lange, streng genommen ein paar Jahre länger aber dazwischen Neuinstallation, seit dem wandert das software raid samt OS auf neue Hardware mit
Von Gitstompah am Sa, 30. September 2017 um 09:24 #
Meine Frage hast du nicht beantwortet, was soviel heißt, dass du wie jeder andere Kompilierer, nichts anpasst. Dann kannst du auch das vorkompilierte Paket nehmen und dir die Mühe sparen.
Richtig, könntest du, wenn es den vorkompiliertes Paket gäbe. Der "Kompilierer" oder Dev stellt aber nicht unbedingt für jedes Paketmanagementsystem und/oder Architektur ein Paket bereit. Die Distributoren sind teilweise auch etwas langsam, wenn es neuere Versionen gibt, wenn sie den das Paket überhaupt updaten.
Veränderungen am Build Prozess (Optimierung, Abhängigkeit, Prozessor Architektur) ist ohnehin nicht sinnvoll wenn man nicht aktiv am Projekt mitarbeitet.
Es ist schon erstaunlich wie viel Halbwissen hier herrscht und wie wehement solche Leute ihre Meinung verteidigen.
Bei Firefox führte der Switch auf 64 Bit lange für kaputte Binaries, weil der obere Bit Bereich der longs? zum Speichern der Meta Informationen verwendet wurde.
Bei PCL führt Änderungen am Struct Alignment regelmäßig zu korruptem Speicher, weil intern selbst optimiert wird.
Einstellungen wie -O3, das Hinzuschalten von AVX oder OpenMP optimiert hin und wieder zu aggressiv, so dass die Programme aufgrund von z. B. Thread Racing langsamer laufen als mit (nur) O2.
So viel zum Thema Unsinn den du selbst verbreitetst.
Von Alter Sack am Fr, 29. September 2017 um 20:59 #
Gewagte Theorie...
Die lese ich eigentlich nur bei dir. Deine Schlussfolgerungen sind haltlos. Mal schauen, ob du mir folgen kannst: Andersherum wird nämlich ein Schuh daraus. Ein Maintainer, der sich exakt den individuellen Befindlichkeiten eines Nutzers anpasst, ist – ganz genau – ein schlechter Maintainer. Es verhält sich also genau andersherum, als von dir postuliert. Deine weiteren Folgerungen sind somit auch zu vernachlässigen. Alles klar soweit?
Gut. Entwickler A entwickelt die Anwendung foo und nimmt dort nach reiflicher Überlegung die Funktionalität bar auf. Der Maintainer B der Distro X baut das Paket nun standardmäßig mit der Funktionalität bar, ebenfalls nach reiflicher Überlegung. User Y hat aber nun einen anderen Use-Case für foo, kann aber mit der Funktionalität bar leben. User Z hingegen hat einen ähnlichen Use-Case wie Y, mag aber nach reiflicher Überlegung die Funktionalität bar nicht haben. Weil es sich nun um freie und quelloffene Software handelt, baut Z sein eigenes Paket, was auch ganz einfach ist, da A eigens dafür vorgesehen hat, foo wahlweise ohne bar zu kompilieren. Z lädt sein Paket foo-without-bar ins User-Repo seiner Distro hoch. Y freut sich darüber und bedankt sich bei Z. Beide sind froh, dass A die Funktionalität von bar fakultativ aufgenommen hat. Was ist mit A? Der freut sich auch, dass ihm Z ein paar Nörgler vom Hals hält. Alles klar soweit?
Von Gitstompah am Sa, 30. September 2017 um 09:33 #
Die sind nicht unfähig, aber es ist einfach nur dämlich jede Anwendung "distributionsbahängig" zu bauen.
IMHO haben sich die distributionsabhängigen Repositories komplett überholt. Da wird viel zuviel Aufwand dafür verbraten. Bevor ich mir den Abhängigkeitswahn antue, baue ich manche Anwendung lieber komplett selbst aus dem Source.
>IMHO haben sich die distributionsabhängigen Repositories komplett überholt. Da wird viel zuviel Aufwand dafür verbraten. Dies. In Zeiten mit 100 Nutzeranwendungen war das vielleicht mal praktikabel.
Von immoreofaKDEusermyself am Mo, 2. Oktober 2017 um 19:19 #
"Das würde bedeuten, das a.die Maintainer in den Distris unfähig sind" ------------------------------Auszug Ende-------------
Schau doch mal, wie wenig Distributionen wirklich in der Lage sind, KDE oder etwas anderes hinreichend Funktionales mit der entsprechend benötigten Komplexität funktionierend abzuliefern. Selbst bei den meisten großen Distributionen hapert es an allen Ecken und Enden. Wenn ihr mal wieder jemanden über KDE-Bugs jammern hört, sollte man wirklich erstmal prüfen ob das nicht mal wieder ein Fehler der Distributoren war. KDE ist hier nur ein Beispiel, weil man Aufgrund der recht homogenen Nutzfläche garantiert auf das ein oder andere faux pas stößt. Es gibt natürlich noch andere Stellen, wo sich die Überforderung der Distributoren bemerkbar macht.
Das es viele Maintainer gibt, die irgendwelche simplen Serverdistributionen paketieren und zuverlässig mit Updates können bestreitet hier sicherlich niemand, aber das ist nunmal leider nicht der Maßstab für Desktopnutzer.
Anders bekommt man heutzutage schwer ein brauchbares System.
So? Was genau willst du denn besser können als der Dev selbst?
Was hat denn deiner Meinung nach Kompilieren mit Entwickeln zu tun?
Die meisten Devs stellen auch kompilierte Pakete zur Verfügung. Sie erstellen auch Makefiles.
Meine Frage hast du nicht beantwortet, was soviel heißt, dass du wie jeder andere Kompilierer, nichts anpasst. Dann kannst du auch das vorkompilierte Paket nehmen und dir die Mühe sparen.
Veränderungen am Build Prozess (Optimierung, Abhängigkeit, Prozessor Architektur) ist ohnehin nicht sinnvoll wenn man nicht aktiv am Projekt mitarbeitet.
Halt mal bitte den Ball flach, okay? Ich muss mich nicht rechtfertigen, was ich mit mit freiem Code mache, solange es der Lizenz entspricht. Ich muss auch keine Unterstellungen beantworten. Ich habe freie Software immer so begriffen, dass ich mit dem Code alles machen darf, was die Lizenz erlaubt. Ich werde auf das, was ich unter "brauchbares System" verstehe, auch nicht weiter eingehen.
Okay, mal ein unverfängliches Beispiel: Ich dürfte deiner Meinung nach also nicht xu4 , ein freies Remake von Ultima IV, für ARM kompilieren, weil ich nicht aktiv am Projekt mitarbeite?
Ja was denn - Benenne deine Probleme oder halte das Maul!
du bist doch nur genauso ein Versager wie die paar schreihälse die sich dauernd über systemd beschweren dabei so klingen wollen als wären sie die Mehrheit und ausser "alles anders, zu dumm und zu faul" keine Argumente vorbringen ausser dass der Schwager vom Halbbruder auch sagt
Läuft @home als systemwide systemd-unit seit die Maschine 2011 aufgesetzt wurde 24 Stunden am Tag ohne Zucker
Da waren von Fedora 15 bis 25 auch 10 Dist-Upgrades dabei
Läuft auf der workstation im Büro genauso lange, streng genommen ein paar Jahre länger aber dazwischen Neuinstallation, seit dem wandert das software raid samt OS auf neue Hardware mit
Ach, der Beleidigungsbot mal wieder.
Ja ja,
wer schreit, hat Recht.
Ach der Märchenerzähler mal wieder.
Richtig, könntest du, wenn es den vorkompiliertes Paket gäbe. Der "Kompilierer" oder Dev stellt aber nicht unbedingt für jedes Paketmanagementsystem und/oder Architektur ein Paket bereit. Die Distributoren sind teilweise auch etwas langsam, wenn es neuere Versionen gibt, wenn sie den das Paket überhaupt updaten.
Unsinniger geht es nicht mehr, oder?
> Unsinniger geht es nicht mehr, oder?
Es ist schon erstaunlich wie viel Halbwissen hier herrscht und wie wehement solche Leute ihre Meinung verteidigen.
Bei Firefox führte der Switch auf 64 Bit lange für kaputte Binaries, weil der obere Bit Bereich der longs? zum Speichern der Meta Informationen verwendet wurde.
Bei PCL führt Änderungen am Struct Alignment regelmäßig zu korruptem Speicher, weil intern selbst optimiert wird.
Einstellungen wie -O3, das Hinzuschalten von AVX oder OpenMP optimiert hin und wieder zu aggressiv, so dass die Programme aufgrund von z. B. Thread Racing langsamer laufen als mit (nur) O2.
So viel zum Thema Unsinn den du selbst verbreitetst.
"Anders bekommt man heutzutage schwer ein brauchbares System."
-------------------------------------------------Zitatende---------------
Gewagte Theorie...
Das würde bedeuten, das
a.die Maintainer in den Distris unfähig sind
und b. das die User like me schlauer als die Maintainer sind.
Ich denke, da trollt nur jemand rum.
Mal schauen, ob du mir folgen kannst: Andersherum wird nämlich ein Schuh daraus. Ein Maintainer, der sich exakt den individuellen Befindlichkeiten eines Nutzers anpasst, ist – ganz genau – ein schlechter Maintainer. Es verhält sich also genau andersherum, als von dir postuliert. Deine weiteren Folgerungen sind somit auch zu vernachlässigen. Alles klar soweit?
Gut. Entwickler A entwickelt die Anwendung foo und nimmt dort nach reiflicher Überlegung die Funktionalität bar auf. Der Maintainer B der Distro X baut das Paket nun standardmäßig mit der Funktionalität bar, ebenfalls nach reiflicher Überlegung. User Y hat aber nun einen anderen Use-Case für foo, kann aber mit der Funktionalität bar leben. User Z hingegen hat einen ähnlichen Use-Case wie Y, mag aber nach reiflicher Überlegung die Funktionalität bar nicht haben. Weil es sich nun um freie und quelloffene Software handelt, baut Z sein eigenes Paket, was auch ganz einfach ist, da A eigens dafür vorgesehen hat, foo wahlweise ohne bar zu kompilieren. Z lädt sein Paket foo-without-bar ins User-Repo seiner Distro hoch. Y freut sich darüber und bedankt sich bei Z. Beide sind froh, dass A die Funktionalität von bar fakultativ aufgenommen hat. Was ist mit A? Der freut sich auch, dass ihm Z ein paar Nörgler vom Hals hält. Alles klar soweit?
BlaBlaBla
Dein BlaBlaBla ist zu vernachlässigen
Die sind nicht unfähig, aber es ist einfach nur dämlich jede Anwendung "distributionsbahängig" zu bauen.
IMHO haben sich die distributionsabhängigen Repositories komplett überholt. Da wird viel zuviel Aufwand dafür verbraten. Bevor ich mir den Abhängigkeitswahn antue, baue ich manche Anwendung lieber komplett selbst aus dem Source.
>IMHO haben sich die distributionsabhängigen Repositories komplett überholt. Da wird viel zuviel Aufwand dafür verbraten.
Dies.
In Zeiten mit 100 Nutzeranwendungen war das vielleicht mal praktikabel.
"Das würde bedeuten, das
a.die Maintainer in den Distris unfähig sind"
------------------------------Auszug Ende-------------
Schau doch mal, wie wenig Distributionen wirklich in der Lage sind, KDE oder etwas anderes hinreichend Funktionales mit der entsprechend benötigten Komplexität funktionierend abzuliefern.
Selbst bei den meisten großen Distributionen hapert es an allen Ecken und Enden.
Wenn ihr mal wieder jemanden über KDE-Bugs jammern hört, sollte man wirklich erstmal prüfen ob das nicht mal wieder ein Fehler der Distributoren war.
KDE ist hier nur ein Beispiel, weil man Aufgrund der recht homogenen Nutzfläche garantiert auf das ein oder andere faux pas stößt.
Es gibt natürlich noch andere Stellen, wo sich die Überforderung der Distributoren bemerkbar macht.
Das es viele Maintainer gibt, die irgendwelche simplen Serverdistributionen paketieren und zuverlässig mit Updates können bestreitet hier sicherlich niemand, aber das ist nunmal leider nicht der Maßstab für Desktopnutzer.