@Metal_Warrior: Du möchtest Kenobi etwas helfen und nebenbei am Linux Stammtischdiskussionen Dampf ablassen in Form genervte Rants über die Geschwindigkeit der modernen Softwareentwicklung und die Menge an Dependencies moderner Systeme. Doch das hab ich verstanden.
Ja und nein. Wenn Kenobi ein Debian einsetzen möchte, soll er wissen, was das bedeutet. Und warum es grundsätzlich ne schlechte Idee ist, tausende Abhängigkeiten zu haben, weil es sowohl Stabilität als auch Sicherheit beeinträchtigt. Das kann durchaus bedeuten, dass er seinen Code zukünftig in einer anderen Sprache schreiben sollte, weil er denn wenige bis keine Abhängigkeiten zu Fremdquellen hat, was Stabilität und Sicherheit zugute kommt.
Die Code::Blocks IDE, um die es hier geht, wird in den offiziellen Debian Repositories nicht maintained.
Oldstable ist das neue newstable. Automatisch übertragen und umdeklarierte. Das hat mit rigorose testen gar nichts zu tun
Richtig, und das aus vermutlich wirklich gutem Grund, weil der Maintainer schon keinen Bock mehr auf ein moving target hat. Das ist genau das Problem, an dem wir hier auseinander driften: Die Developer arbeiten in eine Richtung, die durch Admins nicht mehr eingesetzt werden kann, weil die Fehler und Sicherheitslücken sich mehren und der Frustrationsgrad astronomische Höhen erreicht. Wenn aber die Admins die Software der Devs nicht mehr einsetzen können, dann müssen die Admins selbst wieder Software schreiben, und was die Devs dann abliefern, nutzt dann wer?
Nein, Stretch, das aktuelle stable, wird zu oldstable, bei dem nur noch Sicherheitslücken gefixt werden. Testing, d. h. Buster, wird zu stable. Der Weg ist Sid -> Testing -> Stable -> Oldstable (-> Oldoldstable). Das hat was mit Testroutinen zu tun, und zwar ganz massiv.
Die offiziellen Debian Repos sind für diese konkrete Software keine gute Quelle.
Sofern du dir sicher sein kannst, dass die Software, die du einsetzt, nicht aus ihren Repos Kernkomponenten des Systems antastet, kannst du ein Fremdrepo einbinden.
Süß. "cherry picked commits" aus der unveröffentlichten 3.0.5, die es noch in den Buster Freeze geschafft haben.
Ja, sowas kommt raus, wenn du für die nächsten 2,5 Jahre Software maintainen willst, die ein Verfallsdatum wie unbehandelte Kuhmilch hat. Dann nimmst du dir das Neueste und hoffst, dass die Probleme in den nächsten 2,5 Jahren nicht so astronomisch werden würden, wie sie es wären, wenn du die aktuelle Veröffentlichung nutzt, die ja schon älter ist. Das Problem ist die Software an der Stelle, und der Entwicklungstrend, nicht das Debian, denn das läuft seit mittlerweile 20 Jahren mit diesem Releasezyklus und wird deshalb auch auf ziemlich vielen Servern eingesetzt (neben SLES und RHEL, bei denen es übrigens nicht viel anders läuft; wir setzen beide Systemtypen auch bei uns im Team ein, und ich kann dir sagen, dass ein SLES 11.4 nur noch mit viel Überredungskunst zum Beispiel TLS 1.3 spricht, und das ist KEIN moving target).
@
Metal_Warrior zu
die PHP Entwickler sollen "PHP Rewrite-DOT-zero EOL Edition" benutzen, weil der OS-Distributor nur das liefert.:
Debian Stable liefert üblicherweise kein EOL-Zeug aus, sofern nicht die Entwickler Kuhmilch produzieren, die schneller schlecht wird, als du Buildchain sagen kannst.
Der Knackpunkt bei PHP aus den offiziellen Repos der PHP-Entwickler war, dass die irgendwann die libcrypt des Systems (in diesem Fall Oldstable, weil die Kunden-Entwickler, die das System eingesetzt haben, genauso agile arbeiten, aber zu blöd sind, ihr eigenes fucking System zu kennen) ersetzt haben, und insofern MASSIV ins Betriebssystem eingegriffen haben, was dann natürlich zu einem inkonsistenten Abhängigkeitsbaum geführt hat und apt aus guten Gründen alles weitere verweigert hat. Ja, ich hab das beim Upgrade gelöst bekommen, hat nur 2 Stunden gedauert und hat vermutlich auch dem ein oder anderen dieser saublöden Entwickler den Code zerschossen, weil ich dann nämlich nicht mehr PHP-nightly als Repo drin hatte, sondern PHP-debian-stable. Das ist grassierende Inkompetenz bei den Entwicklern gewesen, und zwar sowohl auf Kundenseite (man setzt kein Oldstable ein, wenn man mit aktuellem Code arbeiten will) als auch auf PHP-Devs-Seite (man liefert als Entwickler keine System-Kernkomponenten aus, und zwar NIE!), wenngleich unsere Kunden der Auslöser für den Fuckup waren.
Wenn du glaubst, das ist nen singulärer Vorfall, guck dir das mal an:
https://www.folio.org/
Build agile on Ubuntu Xenial (Release: April 2016), kommt daher mit Debian Stretch (Release: Juni 2017) nicht zurecht.
Der Punkt, um das nochmal ganz deutlich zu sagen, ist Folgender: Agile Builds sind mit stabilen Betriebssystemen oder IT-Sicherheit nicht vereinbar. Hört auf, agile Scheiße zu schreiben - Instabilen unsicheren Quatsch gibts genug da draußen.
Und für denjenigen, der jetzt sagt, das wäre auf Clients ja kein Problem: Wenn einer deiner 200 Abhängigkeiten-Entwickler irgendeinen Fehler baut oder sein Paket irgendeinem Malware-Entwickler gibt, und auf einen Schlag massiv Daten aus dem System abfließen oder der Code auf einmal eine Tür öffnet, dann ist das ein Problem.
"Aber so funktioniert OpenSource - tausende Entwickler schreiben, und du kannst dir alles anschauen."
Ja und nein. FOSS als Konzept sieht vor, dass du VOR dem Build den kompletten Code ansehen kannst, und dir daher sicher sein kannst, dass nicht irgendjemand Scheiße gebaut hat. Wie funktioniert das in einem agilen Umfeld? Gar nicht. Im Moment des Builds wird der ganze Schmodder vom Entwickler gezogen. Selbst wenn du dann den Build abbrichst, dir den ganzen Code durchsiehst, keinen Fehler findest, und dann den Build nochmal anstößt, zieht er von 20 Abhängigkeiten eine neuere Version, die du NICHT gesehen hast. Brichst du dann wieder ab, liest den Scheiß, stößt den Build wieder an und hast wieder neuen Code, ... Merkst du was? Das komplette Konzept am Arsch, weil du gegen ein moving target arbeitest. Damit ist das Argument "Du kannst ansehen, was du dir da zusammenbaust" nicht mehr gegeben, und damit die Säule, auf der sich die Sicherheit aufbaut, beim Teufel. Rocketchat (der Server) zum Beispiel zieht irgendwas um die 50-100 Abhängigkeiten. Ist ja nur eine Server-Software, was soll da schon schief gehen... Ach, und weil wir mittlerweile unüberschaubar kurze Releasezyklen haben, arbeiten wir am Besten mit Kubernetes und Docker, wenn da was gehackt wird, kann man es einfach wegschmeißen und neu aufsetzen. Vorausgesetzt, wir erkennen das. Und dieser Hacker bricht nicht aus dem Container aus und infiziert den Host. Dann sind wir nämlich am Arsch, weil alles so komplex ist, dass es nicht mehr wartbar ist. Wird schon nicht passieren?
http://lmgtfy.com/?q=mongodb+hacked