Login
Newsletter

Thema: Wann haben Sie zum letzten Mal eine Fremdanwendung kompiliert?

10 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von sbsjsjsjs am Fr, 29. September 2017 um 17:33 #

So? Was genau willst du denn besser können als der Dev selbst?

[
| Versenden | Drucken ]
  • 0
    Von Alter Sack am Fr, 29. September 2017 um 20:35 #

    Was hat denn deiner Meinung nach Kompilieren mit Entwickeln zu tun?

    [
    | Versenden | Drucken ]
    • 0
      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.

      [
      | Versenden | Drucken ]
      • 0
        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?

        [
        | Versenden | Drucken ]
        • 1
          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

          [
          | Versenden | Drucken ]
        0
        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.

        Unsinniger geht es nicht mehr, oder?

        [
        | Versenden | Drucken ]
        • 0
          Von sbsjsjsjs am Mi, 4. Oktober 2017 um 17:19 #

          > 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.

          [
          | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten