Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: GitHub: 70 Prozent der Quellen Duplikate

17 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von gaga am Mo, 27. November 2017 um 09:54 #

Der Artikel ist ein wenig unklar warum Javascript an erster Stelle ist.

https://blog.acolyer.org/2017/11/20/dejavu-a-map-of-code-duplicates-on-github/

"The reason the duplication level is so high for JavaScript turns out to be related to NPM: many projects are committing libraries available through NPM as if they are part of the application code. “This practice is the single biggest cause for the large duplication in JavaScript.” Even though only 6% of projects include their node\_modules directory, they are ultimately responsible for almost 70% of the entire files."

  • 0
    Von ac am Mo, 27. November 2017 um 11:16 #

    Steht doch da: "many projects are committing libraries available through NPM as if they are part of the application code". Jedes §$%"§$§" Programm bringt die Bibliotheken statisch mit sich.

    Für Javascript gibt es keine saubere Modularisierung und Versionierung. Das greift leider immer mehr um sich. Go und die ganze Docker-Fraktion sind weitere Beispiele dafür, dass jüngere Entwickler-Communities wenig Sinn für sauberes Paketieren haben. Irgendwann werden nur noch statische Blobs installiert - mit entsprechendem Laufzeitverhalten (ggf. höherer Speicherverbrauch) und den höheren Risiken betreffend der Sicherheit dieser Computersysteme.

    • 0
      Von pessimist am Mo, 27. November 2017 um 11:29 #

      agree. was ich im enterprise projektumfeld und in der opensource community feststellen muss ist eine nicht unerhebliche zunahme von software architekten, die auf jeden hype aufspringen ohne sich gedanken über sicherheitsrelevante themen zu machen.

      es werden weitestgehend codemonkeys herangezogen, die es verstehen in einer IDE tolle dinge zu machen, was aber im hintergrund passiert ist offenkundig irrelevant, solange das entwickelte tool seine aufgabe erfüllt.

      best practices zum thema patch management, wartbarkeit, sicherheitsanforderungen und requirements engineering werden garnicht mehr angegangen.

      so kommen dann applikationen zustande, die drei api endpunkte ohne nennenswerte logik bereitstellen aber dennoch 4gb ram fressen und das entwicklerteam einen komisch anschaut wenn man behauptet, das hätte man auch resourcenschonender implementieren können.

      meine lieblingsaussage: "4gb ram ist doch heute nichts mehr"
      richtig mag ja sein, aber 4gb hier, 8gb da, hier ein octa-core, da ein hexa-core... das ganze dann noch in der skalierung betrachtet, da wirds mir schlecht.

      vor ewigkeiten habe ich gelernt: wenn deine applikation schlecht performt, wird wohl was am algorithmus nicht passen.
      die praxis zeigt mir: wenn deine applikation schlecht performt hast du einfach zu wenig hardware bereitgestellt.

      • 0
        Von ac am Mo, 27. November 2017 um 13:25 #

        > best practices zum thema patch management, wartbarkeit, sicherheitsanforderungen und requirements engineering werden garnicht mehr angegangen.

        Exakt. Das Problem ist das das nicht spannend ist, sondern Arbeit macht und damit Geld kostet. Die Firmen müssen in die Verantwortung genommen werden. Schlechtes bzw. nicht vorhandenes Sicherheitsmanagement hört erst dann auf, wenn die gesetzlichen Vorgaben so sind, dass daraus eine betriebswirtschafliche Notwendigkeit wird. Die entsprechenden ISO-Zertifizierungen sind meiner Erfahrung nach eine Lachnummer. Vielleicht verbessert die Datenschutzgrundverordnung die Lage auf längere Sicht; Ich wünsche mir hier exemplarische Urteile, die für Firmen und Geschäftsführung schmerzhaft sind.

        • 0
          Von pessimist am Mo, 27. November 2017 um 15:03 #

          ich denke je mehr Objekte ans Netz angebunden werden, desto wahrscheinlicher wird der Gesetzgeber reagieren.

          Solange es sich bei technischen Schwachstellen allerdings auf "verlorengegangene" Daten beschränkt und niemand physisch wirklich verletzt wurde, können wir jedoch wenig erwarten.

          Damit wir uns jetzt aber nicht falsch verstehen, ich würde mir eine Situationsänderung wünschen, bevor es verletzte gibt.
          Aber ich bin Realist genug um zu sehen, dass in diesen Bereichen die Politik eher reaktiv unterwegs ist und es nur wenige mit Visionen gibt.

          Eigentlich schade, da die technischen Möglichkeiten unserer Zeit sehr viel Spielraum für Zukunftsvisionen übrig lässt-

          • 0
            Von kamome umidori am Di, 28. November 2017 um 08:41 #

            > je mehr Objekte ans Netz angebunden werden, desto wahrscheinlicher wird der Gesetzgeber reagieren

            Vermutlich, sobald wir uns einer Million „angebundener“ Objekte nähern … oh, äh, vergiss es …

          0
          Von Holmaabier am Mo, 27. November 2017 um 16:45 #

          Wenn das Budget für eine richtige Entwicklung nicht da ist?

          Wer seine fancy-App schnell und billig haben möchte, der bekommt eben einen Blob.
          Wenn das Teil dann noch fein ziseliert in ein System eigearbeitet werden müsste, aber dafür weder Geld noch Zeit vorhanden ist, liegt's nicht am Entwickler.
          Und kein geistig klarer Manager kann - vergiss das -
          kein Manager _sollte_ erwarten, daß ein Entwickler gleich für alle möglichen Permutationen an Softwarekomponenten die perfekt passende Lösung liefert.

          • 0
            Von pessimist am Mo, 27. November 2017 um 17:35 #

            natürlich liegts nicht am entwickler wenn das geld nicht da ist.
            aber genau da ist ja die kernaussage der letzten zwei antworten verankert.

            man sollte ganz einfach keine produkte anbieten dürfen, wenn das geld nicht da ist um es richtig zu machen. vergiss das richtig, das endet nur in einer philosophischen diskussion über richtig und falsch - um es sauber zu machen.

            auf der anderen seite - und das ist meine quintessenz - entwickler mit genügend berufserfahrung können hier differenzieren und müssen in den sauren apfel beisen, wenn es schnell und ugly sein soll. ein neueinsteiger lernt dagegen garnicht mehr, was sauber oder ugly ist, sondern sieht in verschiedenen projekten die gleiche grütze und nimmt das für best-practice. zumindest ist es das, was ich tag ein tag aus beobachte, wenn wir junior-entwickler frisch von der uni einstellen.

      0
      Von LH_ am Mo, 27. November 2017 um 12:18 #

      Du irrst dich. Genau das Gegenteil ist das Problem. Die Paketierung ist im JS Umfeld bereits heute sehr beliebt, was auch die Ursache für den duplizierten Code laut der Quelle ist.
      Das genannte Verzeichnis stellt die heruntergeladenen Versionen der Pakete da, die ja nun einmal irgendwo lokal liegen müssen. Die Entwickler haben schlicht vergessen, dieses Verzeichnis via .gitignore aus dem Commits heraus zu halten.

      • 0
        Von ac am Mo, 27. November 2017 um 13:16 #

        > Die Paketierung ist im JS Umfeld bereits heute sehr beliebt

        Saubere Paketierung ist das, was z.B. Linux-Distributionen machen, nicht das, was das "JS Umfeld" darunter versteht.

        Wer sagt mir bei "require foo", dass ich dem, was in irgendeiner Form geladen wird, vertrauen kann!? Ich spreche hier von standardisierten und verifizierbaren weil signierten Paketen, die über einen Distributor verteilt werden und systemweit ausgetauscht werden können.

        • 0
          Von blablabla233 am Mo, 27. November 2017 um 13:26 #

          Ich verstehe ja was Du meinst...ABER weshalb vertraust einer Distribution mehr wie dem Upstream? Ist ja nicht/nicht-unbedingt so wie wenn eine Distributionen einen Codeaudit macht bevor es gepackt wird.

          • 0
            Von ac am Mo, 27. November 2017 um 13:35 #

            > weshalb vertraust einer Distribution mehr wie dem Upstream?

            - Prinzip "Second pair of eyes" - was sicherlich nicht im absoluter Sicherheit garantiert ist
            - Saubere Integration ins Gesamtsystem.

            • 0
              Von ac am Mo, 27. November 2017 um 13:41 #

              Nachtrag:

              > weshalb vertraust einer Distribution mehr wie dem Upstream?

              Andersrum wird übrigens auch ein Schuh draus: Projekt X verwendet eine z.B. veraltete, unsichere oder lokal gepatchte JQuery-Bibliothek. Ich möchte aber ein signiertes ungepatchtes Original von Upstream. D.h. wenn Projekt X eine Verbesserung oder eine Fehlerkorrektur macht, dann soll Projekt X bitte mit dem JQuery-Team zusammenarbeiten und nicht den Andwender die Scheiße ausbaden lassen.

              Übrigens gibt es tatsächlich Umgebungen, in denen Code Audits, Pentests usq. "vorkommen"...

          0
          Von ac am Mo, 27. November 2017 um 13:32 #

          > Die Entwickler haben schlicht vergessen, dieses Verzeichnis via .gitignore aus dem Commits heraus zu halten.

          Nachtrag: Derartige Pakete auf lokaler Projektebene zum Entwicklungszeitpunkt sind verständlicherweise bequem; Aber diese Herangehensweise ist im Grunde schon Teil des Problems.

          • 0
            Von LH_ am Mo, 27. November 2017 um 15:53 #

            Mir ist nicht klar, welche Alternative zu dazu siehst. Die Dateien müssen für das Projekt verfügbar sein, sonst wären sie nicht nutzbar.
            Dateien außerhalb eines Projektes zu speichern ist unsauber und fehleranfällig, speziell wenn verschiedene Projekte unterschiedliche Versionen eines Pakets benötigen.

            Das Vorgehen ist an sich absolut ok, es ist eben nur ein Fehler in der .gitignore Datei. Die Dateien müssen nicht commited werden, da hat jemand einfach gepennt.

            • 0
              Von ac am Mo, 27. November 2017 um 16:25 #

              > Dateien außerhalb eines Projektes zu speichern ist unsauber und fehleranfällig, speziell wenn verschiedene Projekte unterschiedliche Versionen eines Pakets benötigen.

              Dafür gibt es die Möglichkeit virtueller Umgebungen - ist zugegebenenermaßen Aufwand. Fehleranfällig - ja klar, wenn man auf saubere Buildskripte und hinreichende Testabdeckung verzichtet. Das ist genau der gesparte Aufwand, der Anderen später doppelt und dreifach auf die Füße fällt.

              > Das Vorgehen ist an sich absolut ok, es ist eben nur ein Fehler in der .gitignore Datei. Die Dateien müssen nicht commited werden, da hat jemand einfach gepennt.

              "Gepennt" ist gut. Die Realität ist doch, dass das vielen sch...egal ist. Viel zu oft findet man Drittcode (nicht nur JS), der sinnlos statisch eingebacken wird. Die Pflege von Abhängigkeiten sollte in eigenen Paketen/Repositorien geschehen und die über möglichst portable Buildskripte sauber referenziert werden.


              Es ist nicht so, dass ich deinen Ansatz nicht nachvollziehen kann; Ist ja Aufwand, den man nicht bezahlt bekommt.

      0
      Von aaa am Mo, 27. November 2017 um 15:21 #

      Gemeint war der Prolinux Artikel

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung