1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Security: Google fordert…

Linux braucht schon länger 1000 vollbezahlte Entwickler

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: Trockenobst 04.08.21 - 17:52

    Stattdessen gibt es 20 komplett neue Distris weil sie sich nicht auf einen Standardeditor einigen können

  2. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: Thargon 04.08.21 - 19:58

    Es gibt nur einen Linux-Kernel - in verschiedenen Versionen natürlich. Dann gibt es Unternehmen, die eine bestimmte Version grforkt haben und ihr eigenes Süppchen kochen. Aber genau so ein Vorgehen moniert Cook eben.

    Es gibt natürlich auch Linux-basierte Betriebssysteme welche als sog. Distributionen bezeichnet werden, aber die nutzen eigentlich alle den "offiziellen" Kernel.

  3. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: Steffo 04.08.21 - 20:45

    Was du willst, ist BSD. - Gut, davon gibt es auch ein paar Versionen, aber die sind überschaubar.
    Dennoch hat sich dieser zentralistische Ansatz nicht durchgesetzt. So ein modularer Ansatz: Linux-Kernel, GNU- Tool-Chain, diverse Dienste, verschiedene Desktops etc. ist wohl einfach schmackhafter.
    Ich würde mal sagen, dass das auch zu Innovationen geführt hat, weil eine Distribution neue Techniken ausprobieren konnte und andere Distributionen sie teils übernommen habe.

  4. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: nille02 04.08.21 - 21:00

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Ich würde mal sagen, dass das auch zu Innovationen geführt hat, weil eine
    > Distribution neue Techniken ausprobieren konnte und andere Distributionen
    > sie teils übernommen habe.

    Auf jeden Fall. Aber die Bundleung mit den Anwendungen sehe ich als Problem. Die Distributionen können nicht die Pflege für alle Anwendungen selber übernehmen, also warum arbeitet man da so gegen den Upstream? Es gibt ja mehrere Distributionen die "alte" Anwendungen ausliefern für eine vermeidliche Stabilität. Warum macht man das nicht direkt im Upstream? Es gibt ja mehrere Distributionen die vergleichbare Ziele verfolgen. Aber nein, jeder kocht seine eigene Suppe.
    In allen Wikis werden Fremdrepos als Sicherheitsrisiko genannt, aber im selben Atemzug auch als Heilsbringer für aktuelle Anwendungen wenn das in der Distro zu alt oder nicht vorhanden ist.

    Warum also reist man mit jedem Release immer alles wieder ein? Dann sind im Repo halt mehrere Versionen einer Bibliothek, eben um die Abhängigkeiten der Alten Anwendungen zu bedienen als auch neue Versionen für neue Anwendungen. Da könnte man noch eingreifen und Probleme beheben an einer stelle für alle. Aber nein, wir bekommen nun das schlechteste, App Images die ihren eigenen Kram mitbringen der eventuell nicht gepflegt wird.

  5. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: Steffo 04.08.21 - 21:34

    Inwiefern arbeiten Distributionen gegen den Upstream, wenn sie ihren eigenen Release-Zyklus haben?
    Der Upstream kann mit einer neuen Version das komplette OS lahm legen, deshalb brauchen Distributionen die Kontrolle welche Version wann veröffentlicht wird. Das Ganze muss ja kompatibel bleiben und getestet werden.
    Ferner spielen ja auch Paket-Formate und Compiler-Versionen, Compiler-Optionen und auch Kompilieroptionen der Anwendung (bspw. Anwendungs-Plugin ein oder ausschalten), eine Rolle.

  6. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: nille02 04.08.21 - 22:24

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Inwiefern arbeiten Distributionen gegen den Upstream, wenn sie ihren
    > eigenen Release-Zyklus haben?

    Weil alle ihre eigenen alten Versionen versuchen zu Pflegen.

    > Der Upstream kann mit einer neuen Version das komplette OS lahm legen,
    > deshalb brauchen Distributionen die Kontrolle welche Version wann
    > veröffentlicht wird. Das Ganze muss ja kompatibel bleiben und getestet
    > werden.

    Genau, und dafür kann man mit dem Upstream zusammenarbeiten. Und das komplette lahm legen sollte eigentlich nie passieren aber im Userspace scheißt man halt darauf und macht ständig alles kaputt was es fast unmöglich macht Anwendungen für GNU/Linux außerhalb zu verteilen wenn man den ganzen Kram sich nicht selber ans Bein bindet und damit wieder die alten Probleme der alten und vermutlichen unsicheren Kram den man sich damit ins System holt.

    > Ferner spielen ja auch Paket-Formate

    Genau, wieder was für die Spezielle Schneeflocke die man sein will. Aber die Formate sind weniger ein Problem, letztlich sind es meist nur Archive mit Metadaten wo denn was hin soll. Das kann man durch aus lustig hin und her konvertieren. (LSB und rps setzen wohl einige Dinge voraus die man nicht konvertieren kann, aber warum gibt es noch andere Formate wenn man meinen könnte man habe sich auf rpm geeinigt weil es in der LSB ist. )

    > und Compiler-Versionen,

    Ist unter Windows und Mac kein Problem, warum sollte es nun unter Linux eins sein?

    > Compiler-Optionen

    Man kann die des Upstreams nutzen.

    > und auch Kompilieroptionen der Anwendung (bspw.
    > Anwendungs-Plugin ein oder ausschalten), eine Rolle.

    Und hier wird es richtig ekelhaft. Denn du bekommst teilweise nicht mal die volle Anwendung sondern nur einen Krüppel weil jemand meinte eine Funktion zu deaktivieren zu müssen die ihm nicht passt oder er ein Problem mit einer Abhängigkeit besitzt. Denn das macht es noch komplizierter in einer Anwendung mehr voraussetzen als die LSB und die ist inzwischen schon unattraktiv und veraltet (2015).

  7. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: Steffo 04.08.21 - 23:14

    Also der Upstream sollte da erst mal mitmachen wollen. Nur weil jemand Software veröffentlicht, hat diese Person nicht unbedingt auch noch Lust Pakete von Distributionen zu pflegen.
    Und das Problem der Kompatibilität solltest du nicht unterschätzen.
    Wenn z. B. eine Anwendung eine Lib oder Tool in Version 1.x voraussetzt und du machst ein Update auf Version 2.0, kann es sein, dass die besagte Anwendung nicht mehr funktioniert.

    Und du kannst nicht einfach Compiler-Optionen des Upstreams verwenden, weil bspw. der Flag -Wall mit dem GCC 9.2 noch durchkompiliert hat, aber mit Version 10.0 einen Compiler-Fehler wirft, weil die neue Version neue Warnungen wirft, die mit -Wall zu Fehlern werden.

    Wenn das alles so einfach wäre, wie du dir das vorstellst, hätte man das schon längst gemacht.
    Deshalb bleibt die Zusammenarbeit mit dem Upstream die Ausnahme.

  8. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: nille02 05.08.21 - 09:58

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Also der Upstream sollte da erst mal mitmachen wollen. Nur weil jemand
    > Software veröffentlicht, hat diese Person nicht unbedingt auch noch Lust
    > Pakete von Distributionen zu pflegen.

    Das muss die Person im Upstream auch nicht machen. Von den 300 die die Anwendung eh packetieren werden sich sicher welche Finden die das im Upstream erledigen werden.

    > Und das Problem der Kompatibilität solltest du nicht unterschätzen.
    > Wenn z. B. eine Anwendung eine Lib oder Tool in Version 1.x voraussetzt und
    > du machst ein Update auf Version 2.0, kann es sein, dass die besagte
    > Anwendung nicht mehr funktioniert.

    Dann verteilt man beide. Es hat auch einen Grund warum es nicht Version 1.X ist sondern 2.X. Das ist ja etwas was ich ankreide. Man versucht möglichst wenig Versionen zu haben und Patcht zur not an anderen Anwendungen herum oder reduziert die Funktionalitäten von Anwendungen damit das Kartenhaus irgendwie steht.

    > Und du kannst nicht einfach Compiler-Optionen des Upstreams verwenden, weil
    > bspw. der Flag -Wall mit dem GCC 9.2 noch durchkompiliert hat, aber mit
    > Version 10.0 einen Compiler-Fehler wirft, weil die neue Version neue
    > Warnungen wirft, die mit -Wall zu Fehlern werden.

    Dann soll auch auch im Upstream gefixt werden.

    > Wenn das alles so einfach wäre, wie du dir das vorstellst, hätte man das
    > schon längst gemacht.
    > Deshalb bleibt die Zusammenarbeit mit dem Upstream die Ausnahme.

    Das bezweifle ich. Meist hat man eher das Gefühl man will halt nicht mit anderen Zusammenarbeiten, denn damit macht man sich selbst eventuell überflüssig. Sicherlich gibt es Probleme die man beseitigen müsste, aber man Steckt seine Energie jetzt lieber in Snap, Flatpack etc um das schlimmste aus allen Welten zu haben.

  9. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: fabiwanne 05.08.21 - 14:14

    > Dann sind im Repo halt mehrere Versionen einer Bibliothek, eben um die Abhängigkeiten der Alten Anwendungen zu bedienen als auch neue Versionen für neue Anwendungen.
    Weil man bei 20 Versionen einer Lib halt 20 mal so viele Sicherheitslücken hat.
    Darum kann sich die Distro dann wirklich nicht kümmern. Man sieht das an selbstgepflegten Anwendungen wie diversen Spielen wo dann Anwendungen (setup.exe, snap, Docker-Container, AppImage...) wo es eher der Normalfall ist, dass Sicherheitslücken von vor 20 Jahren nachgeliefert werden.
    In einer vernünftigen Distro hat jedes Paket (und damit jede Lib) einen Maintainer der sich gewissenhaft darum kümmert, dass da alle Sicherheitslücken gestopft werden.
    Die Alternative wäre, dass jedes Entwicklerteam für alle genutzten Libraries Maintainer pflegen müsste. Kein mir bekanntes Softwareprojekt abseits von Mozilla macht das.
    Der Aufwand wäre exorbitant. Denn Pakete gibt es doch ein paar mehr wie Distros.

  10. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: fabiwanne 05.08.21 - 14:40

    > Weil alle ihre eigenen alten Versionen versuchen zu Pflegen.
    Nein. Bis auf einige wenige Ausnahmen (apt-get, debianlive und RH mit seinen eigenen Java EE verionen.) Pflegen Distributionen keine Software. Sie wählen lediglich LTS Versionen deren Support für Sicherheitspatches länger als bis zum nächsten Reelease ist. Dann hast du ein stabiles System und du kannst ohne Aufwand abseits des Paketierens einfach ein funktionierendes System bereitstellen. Krüppelsoftware die es nicht mal schafft für 18Monate Sicherheitsupdates (ohne API-Changes, die Inkompatibilitäten verursachen können) zu liefern kommt da schlicht nicht rein.
    Oder das war zumindest so, bis Chrome/Chromium das nicht gemacht hat und aber alle Chromium in ihrer Distro haben wollten.
    Und wenn es die Ausnahme für Chrome gab, wurden immer mehr das auch haben.
    Problem ist, dass die die Ressourcen für die Verwaltung nicht haben. Und so gibt es mittlerweile massenhaft Schrott-Software, die zwar alle 2 Wochen ne neue Version mit API-Changes raus bringt und ab da Sicherheitslücken für alte Versionen zu stopfen aber gleichzeitig Von der API von irgend einer Lib von vor 10 Jahren sind, die seit 5 keine Sicherheitsupdates mehr dafür liefert.
    So gibt es jetzt immer mehr Ausnahmen für irgend welche Patch-Backports meist in Combo mit "die Community kümmert sich drum". (Arch-AUR Ubuntu-Universe...)

    > Ist unter Windows und Mac kein Problem, warum sollte es nun unter Linux eins sein?
    Nein. Es war ein Dickes Problem. Erinnerst du dich noch an dll-Hölle und Codec Packs die dir irgend welche Filme nicht abspielten, weil sich Player in unterschiedlichen Versionen gegenseitig kaputt schossen? Oder das neue DirectX-Update, dass dir die alten Spiele kaputt schoss?
    Das Problem wurde dadurch behoben, dass die Betriebssysteme nur noch 3 Programmarten Starten: Chrome. Da läuft die eigentliche Software dann serverseitig und da liegt dann ein Linux mit Paketmanager
    Steam: Bringt intern sein eigenes Abhängigkeitsmanagement mit. (Ganz am anfang war das btw. ein Fork von Portage ;-) )
    Beide haben keine anderen Abhängigkeiten als Windows selbst, das ein sauberes Release-Modell hat.
    MS-Office Produkte: Da managt MS die Abhängigkeiten intern.



    1 mal bearbeitet, zuletzt am 05.08.21 14:49 durch fabiwanne.

  11. Re: Linux braucht schon länger 1000 vollbezahlte Entwickler

    Autor: fabiwanne 05.08.21 - 14:49

    > Dann soll auch auch im Upstream gefixt werden.
    Da hast du prinzipiell recht. Nur wollen die wenigsten das. Die meisten Entwickler sind zufrieden, wenn die Software bei ihnen tut. – Du hast eine ARM CPU? Keine Ahnung was das ist. Aber hier tuts! Kauf dir nen Intel! Sicherheitslücke? Nicht mein Problem, wenn bei dir jemand einbricht. Die Software tut! Das Programm tut nicht, wenn auch XY läuft. – Ja dann deinstalliere halt XY!
    Du willst dass deine Configs aller Programme einheitlich abgelegt werden?
    Also wir machen das einheitlich nach unserem eigenen Standard auf allen 2 Systemen, die wir supporten.
    Distributionen sind in erster Linie externe Qualitätskontrolle die vor allem auch Userinteressen vertritt die man als einzelner User gegen Entwickler nie durchsetzen könnte.
    Leider blicken es immer weniger User und hören immer häufiger auf irgend welche Aufrufe, dass man sich die Software doch lieber direkt Upstream holen soll und dann die viel neuere Version mit ganz tollen neuen Features hat. Inklusive allen Sicherheitslücken und Bugs in Libs der letzten 20 Jahre.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Datenbank-Administrator (m/w/d)
    KVJS - Kommunalverband für Jugend und Soziales Baden-Württemberg, Stuttgart
  2. Fachinformatiker für Systemintegration (m/w/d)
    Erlanger Stadtwerke AG, Erlangen
  3. Senior Storage Engineer (m/w/d)
    operational services GmbH & Co. KG, Zuffenhausen, Wolfsburg
  4. Storage Architekt (m/w/d)
    operational services GmbH & Co. KG, Wolfsburg, Zuffenhausen

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499€
  2. (u. a. Ryzen 7 5800X für 469€)


Haben wir etwas übersehen?

E-Mail an news@golem.de