Hallo zusammen, ich bin ich Python relativ neu und durch einen anderen Thread (Beitrag "Julia, verwendet das hier jemand?") hat sich mir eine Frage aufgedrängt: Wie kann ich ein Python-Programm so sichern, daß ich es in 10...15 Jahren noch ausführen/ändern kann (und auch noch das Gleiche herauskommt). Für das Programm selbst: Trivial. So wie meine anderen Quelltexte auch. Für den Python-Installer: Auch trivial. Muß ich mir eben sicherheitshalber eine virtuelle Maschine bereithalten, um Python dann auch installieren zu können. Und jetzt der Knackpunkt: Die Pakete/Libraries. Die meisten davon wurden über PIP aus einem Repository installiert. Das Repo wird garantiert nicht für alles Ewigkeit vorhanden sein oder gar die alten Versionen der Libraries vorhalten. Wie bekomme ich meine benötigten, per PIP installierten Libraries gesichert? Viele Grüße W.T.
Walter T. schrieb: > Die meisten davon wurden über PIP aus einem Repository installiert. Und? Die liegen dann bei dir lokal und du kannst sie sichern.
Bei Python gibt es sogenannte "virtual environments" bzw. virtualenv. Damit kannst du pip dazu bringen, alle per pip installierten Pakete in einen Ordner deiner Wahl zu installieren: https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv
Abradolf L. schrieb: > Und? Die liegen dann bei dir lokal und du kannst sie sichern. Wie kann ich die lokal liegenden Pakete so sichern, daß sie anschließend wieder installierbar sind? Manche Pakete sind ja nur Bindings und verteilen noch munter Executables, die anderweitig installiert werden.
Der Pragmatiker verlässt sich nur auf Pakete mit breiter Nutzerbasis, also solche die zu seinen Lebzeiten garantiert nicht mehr wegsterben werden und passt dann vielleicht alle 12 Jahre mal das eine oder andere Script das mit irgendeiner neuen Version nicht mehr läuft geringfügig an so daß es auf den jeweils aktuellen Versionen wieder läuft. Wenn er das Script dann überhaupt noch braucht. Es hat sich nämlich gezeigt daß diese Vorgehensweise 100 mal weniger Aufwand ist und viel entspannter als sich in der Gegenwart schon den ganzen Tag lang über ungelegte Eier der Zukunft den Kopf zu zerbrechen von denen sich bei 99% herausstellen wird daß alle Bedenken vollkommen unbegründet waren. Disclaimer: * Übertreibungen erhöhen die Anschaulichkeit. * Der Sinn ist zu entnehmen und zu verinnerlichen
:
Bearbeitet durch User
Wenn dir das mit virtualenv nicht reicht und du gerne die Sachen wirklich aus den Quellen installieren willst, dann kannst du auch bei pypi die Pakete als .whl bzw. .tar.gz herunterladen. Das ganze lässt sich dann von einem lokalen Ordner per pip installieren. Downloaden kannst du die Dateien auch mit pip: https://pip.pypa.io/en/stable/reference/pip_download/
Christopher J. schrieb: > Wenn dir das mit virtualenv nicht reicht Ehrlich gesagt: Ich habe die VirtualEnv und das Sichern für unabhängige/komplementäre Konzepte: Das Eine kann ich machen, wenn ich ein vorliegendes Alt-Projekt ans Laufen bekommen will, wenn ich die Libraries bekomme. Das andere ist, die Libraries erst einmal zu sichern, um sie später virtuell einbinden zu können. Christopher J. schrieb: > und du gerne die Sachen > wirklich aus den Quellen installieren willst, dann kannst du auch bei > pypi die Pakete als .whl bzw. .tar.gz herunterladen. Super! Das habe ich gesucht. Bernd K. schrieb: > on denen sich bei 99% herausstellen wird daß alle Bedenken vollkommen > unbegründet waren. Schreibt vermutlich jemand, der noch nie ein altes Laufwerk für ein Band gesucht hat, auf dem der Quelltext für ein Fortran-Programm lag, mit dem vor 25 Jahren ein Walzgerüst ausgelegt wurde. Ich halte es für elementar, die Möglichkeiten für eine Datensicherung zu kennen. Nur auf dieser Basis läßt sich eine Entscheidung treffen, ob man den Aufwand wirklich betreiben will.
Walter T. schrieb: > Schreibt vermutlich jemand, der noch nie ein altes Laufwerk für ein Band > gesucht hat, auf dem der Quelltext für ein Fortran-Programm lag, mit dem > vor 25 Jahren ein Walzgerüst ausgelegt wurde. Wenn es 25 Jahre lang im Keller lag ohne daß jemand es mal für nötig befunden hat es am Laufen zu halten und zu pflegen oder wenigstens mal auf irgendwas neueres umzukopieren als die betreffenden Bandlaufwerke aus der Mode kamen dann kann er es auch genausogut auf den Müll werfen denn dann braucht er es offensichtlich sowieso schon lange nicht mehr.
:
Bearbeitet durch User
Walter T. schrieb: > Ich halte es für elementar, die Möglichkeiten für eine Datensicherung zu > kennen Ich sichere meine eigenen Scripte. Die Abhängigkeiten kann ich mir jederzeit wieder aus dem Netz laden.
Also ich bin auch für eine VM. Eine Strategie fahren und bei Umstieg schauen, dass man die Kurve kriegt. Evtl. mit Clonezilla Img. ziehen und ablegen. Nun wäre dieser Ansatz für ein einzelnes Programm überdimensioniert. Aber so doll kann das doch nicht sein. Und wenn es tatsächlich hochverfügbar und kritisch ist, dann findet doch meist da eine Weiterentwicklung statt. Und dazu gehört nun mal die Pflege der Abhängigkeiten.
Bernd K. schrieb: > Ich sichere meine eigenen Scripte. Die Abhängigkeiten kann ich mir > jederzeit wieder aus dem Netz laden. Nö
Walter T. schrieb: > Schreibt vermutlich jemand, der noch nie ein altes Laufwerk für ein Band > gesucht hat, auf dem der Quelltext für ein Fortran-Programm lag, mit dem > vor 25 Jahren ein Walzgerüst ausgelegt wurde. Echt jetzt? Hatte ich noch nie. Aber vmtl. dann nicht Teil der SW Entwicklung. Die Maschinenbauer pythonisieren auch alles mögliche, ist auch keine Kunst. Von der Seite aus betrachtet - VM, VM. ODer vielleicht doch VM?
Wie wärs mit compilieren via PyInstaller? Das packt den Interpreter inklusive Paketabhängigkeiten in ein executable.
Ewig gibt im digitalen Bereich noch nicht. Theoretisch können Daten 10 bis 20 Jahre lagern ohne Schaden zu nehmen. Was dabei Schaden nimmt sind die Speichermedien. In Granit meißeln war also wirklich das einzigste was an die Ewigkeit rankommt.
Walter T. schrieb: > Ehrlich gesagt: Ich habe die VirtualEnv und das Sichern für > unabhängige/komplementäre Konzepte: Das Eine kann ich machen, wenn ich > ein vorliegendes Alt-Projekt ans Laufen bekommen will, wenn ich die > Libraries bekomme. > > Das andere ist, die Libraries erst einmal zu sichern, um sie später > virtuell einbinden zu können. Naja, das kann man natürlich miteinander kombinieren und sein virtualenv-Verzeichnis einfach mitsichern. Davon abgesehen sind virtualenvs natürlich toll, um Pakete für bestimmte Projekte in bestimmten Versionen am System vorbei zu installieren, ohne das System zu "verschmutzen" oder an die vom System mitgelieferten Versionen und Pakete gebunden zu sein. Mittlerweile installiere ich nur noch sehr selten Pakete aus dem Systemrepos und mache fast alles mit virtualenvs.
Bernd K. schrieb: > Ich sichere meine eigenen Scripte. Die Abhängigkeiten kann ich mir > jederzeit wieder aus dem Netz laden. LOL Lass mich raten: Du bist ein Millenial DevOp mit Schwerpunkt NodeJS?
1. Verschlüssle es mit einem guten Verschlüsselungsverfahren. 2. Verschlüssle das Ergebnis mit einem schwachen Verfahren. 3. Nenne es Anti-NSA-Hack-very-streng-geheim.doc. 4. Schicke es "versehentlich" an eine US-Behörde. Danach kannst Du davon ausgehen, daß das sehr lange gespeichert bleibt...
Bevor man gleich mit der dicken VM kommt: Ein Docker Container tuts evtl. auch. Hängt ein bisschen davon ab was das Python Skript macht (z.B. wenn viel Hardware gesteuert wird, wirds mit den Treibern vll. etwas eklig).
VM-Image oder kompletter Rechner der in der Ecke steht. Alles andere wird in 15 Jahren garantiert Arbeit. Docker-Images, pfff, keiner kann mir erzählen dass Docker in 15 Jahren noch ein Image lesen kann, was der heute erstellt hat. Kann ich mir einfach nicht vorstellen.
Sven B. schrieb: > Docker-Images, pfff, keiner kann > mir erzählen dass Docker in 15 Jahren noch ein Image lesen kann, was der > heute erstellt hat. Kann ich mir einfach nicht vorstellen. Sollte das wirklich der Fall sein, kann man immer noch auf Plan B zurückgreifen: Docker in einer VM installieren. Würde mich allerdings wundern, wenn Docker keine 15 Jahre mehr leben sollte.
hah schrieb: > Bernd K. schrieb: >> Ich sichere meine eigenen Scripte. Die Abhängigkeiten kann ich mir >> jederzeit wieder aus dem Netz laden. > > LOL > > Lass mich raten: Du bist ein Millenial DevOp mit Schwerpunkt NodeJS? Nein, ich benutze aber auch einfach keine dubiosen Abhängigkeiten mit weltweit nur 3 Nutzern die nächstes Jahr plötzlich nicht mehr existieren. Ich recherchiere vorher welche Pakete auch von den meisten anderen eingesetzt/benötigt werden und daher ausreichend Pflege erfahren. Und schon ist das Problem verschwunden. Und bei Python ist noch nicht so ein unheilbares Chaos ausgebrochen wie bei NodeJS, da kann man das noch gut im Griff behalten.
:
Bearbeitet durch User
Bernd K. schrieb: > Und schon ist das Problem verschwunden. Probleme mit Backups tauchen grundsätzlich erst auf, wenn sie tatsächlich im Falle eines Falles gebraucht werden. Vorher ist grundsätzlich immer alles in Ordnung, man hat ja ein Backup ;) Oliver
Bernd K. schrieb: > Nein, ich benutze aber auch einfach keine dubiosen Abhängigkeiten mit > weltweit nur 3 Nutzern die nächstes Jahr plötzlich nicht mehr > existieren. Ich recherchiere vorher welche Pakete auch von den meisten > anderen eingesetzt/benötigt werden und daher ausreichend Pflege > erfahren. Und schon ist das Problem verschwunden. > > Und bei Python ist noch nicht so ein unheilbares Chaos ausgebrochen wie > bei NodeJS, da kann man das noch gut im Griff behalten. Doch, auch bei Python liegt das Problem nicht anders (wenn auch (noch) geringer als bei Chaos^H^H^H^H^HNodeJS). Wenn Deine Deps ihrerseits Deps ziehen, verlierst Du spätestens hier die Kontrolle. Stichwort Dependency-Hell. Hat pip mittlerweile einen funktionierenden Resolver, oder werden immer noch Versionskonflikte einfach ignoriert? Und nein, Du brauchst nix dubioses was nur 3 Leute nutzen. Erinnerst Du Dich evtl nicht mehr an left-pad? Oder man denkt einfach mal ganz banal und nimmt an, daß in x Jahren das heute weltbeherrschende Repo einfach nicht mehr existiert. Wie war das mit MySpace und Geocities? Komm mir nun nicht mir "Repos sind was anderes", denn das sind die eben nicht. Wenn der Heuschreckenschwarm der DevOps auf ein neues Spielzeug schwenkt, dann kann das Alte recht schnell verschwinden. Archiveren geht nur mit allen Deps. Und wer sagt denn daß in x Jahren Dein Python2 überhaupt noch auf Deinem OS dann läuft, Deps hin oder her?
hah schrieb: > Archiveren geht nur mit allen Deps. Und wer sagt denn daß in x Jahren > Dein Python2 überhaupt noch auf Deinem OS dann läuft, Deps hin oder her? Wenn man Langzeitstabilität braucht, nimmt man ja auch weder Frickelkrams noch rein proprietäres Zeugs, sondern wählt eine Sprache, für die es einen brauchbaren ISO-Standard nebst etlichen Implementationen gibt. C89 kann auch heute noch jeder C-Compiler, nach 3 Jahrzehnten, und mit C++ sieht's vergleichbar aus.
Microfilm oder mit Laser auf Klebeband. Eine goldene Scheibe soll auch gehen und wenn es ein Screenshot sein soll, kann man auch ein Video-Signal auf Schallplatten bringen…die goldene Scheibe mit deinem Python-Screenshot wird in 3000 Jahren DER Hit.
Nop schrieb: > C89 kann auch heute noch jeder C-Compiler, nach 3 Jahrzehnten, und mit > C++ sieht's vergleichbar aus. Nur kann man damit in der Praxis nicht viel machen ohne zusätzliche Bibliotheken, von denen man dann wieder abhängig ist.
Rolf M. schrieb: > Nur kann man damit in der Praxis nicht viel machen ohne zusätzliche > Bibliotheken, von denen man dann wieder abhängig ist. Der Unterschied ist: Wenn ich eine C-Entwicklungsumgebung unter Windows installiert habe, habe ich im Normalfall vorher jede einzelne Komponente heruntergeladen und sinnvollerweise auch die Installationsdateien gespeichert. Wenn ich die Installation über einen Package-Manager mache, bin ich darauf angewiesen, dass dieser in der Zukunft noch existiert und kompatible Komponenten anbietet. Da sein Daseinszweck aber genau das Gegenteil ist (immer aktuelle, fehlerbereinigte Komponenten anbieten), haben das Package Repository und ich hier einen erheblichen Interessenskonflikt.
Rolf M. schrieb: > Nur kann man damit in der Praxis nicht viel machen ohne zusätzliche > Bibliotheken, von denen man dann wieder abhängig ist. Welche meinst Du? Die für das GUI-Handling sind überall ein Problem, weil sich da in 20 Jahren soviel ändert, daß oftmals nichts mehr geht. Das umgeht man aber, wenn man das Programm modular aufbaut, so daß die eigentliche Programmfunktion über ein Terminalprogramm erreichbar ist. Das geht mit definiertem Interface über stdin/stdout, und im GUI-Programm forkt man das dann bloß noch. So ähnlich ging das ja schon unter Unix und heute unter Linux, daß man eben nicht riesige monolithische Anwendungen baut, sondern lieber viele kleine Programme mit genau definiertem Zweck. Geht es hingegen darum, daß man sich DLLs ins Projekt zieht, zu denen man nicht den Quelltext hat, dann ist nicht die Programmiersprache das Problem, sondern daß Anwendungen ohne Source naturgemäß nicht besonders portabel sind.
Nop schrieb: > Rolf M. schrieb: > >> Nur kann man damit in der Praxis nicht viel machen ohne zusätzliche >> Bibliotheken, von denen man dann wieder abhängig ist. > > Welche meinst Du? Die für das GUI-Handling sind überall ein Problem, > weil sich da in 20 Jahren soviel ändert, daß oftmals nichts mehr geht. Dir fällt also ernsthaft außer GUI nichts weiter ein, was ein modernes Programm noch so über den reinen Grundumfang von ANSI C hinaus verwenden könnte? > Geht es hingegen darum, daß man sich DLLs ins Projekt zieht, zu denen > man nicht den Quelltext hat, dann ist nicht die Programmiersprache das > Problem, sondern daß Anwendungen ohne Source naturgemäß nicht besonders > portabel sind. Ich sagte ja nicht, dass die Programmiersprache das Problem sei, sondern nur, dass nicht alles automatisch problemlos ist, nur weil man eine langlebige Sprache verwendet, so wie hier behauptet. Und wenn man den Quelltext der Bibliotheken hat, löst das auch nicht alle Problem einfach so auf. Denn niemand hat Lust, erstmal ein Dutzend veraltete Libs auf ein neues System zu portieren, um das Programm wieder zum Laufen zu bekommen.
Rolf M. schrieb: > Dir fällt also ernsthaft außer GUI nichts weiter ein, was ein modernes > Programm noch so über den reinen Grundumfang von ANSI C hinaus verwenden > könnte? Das war ein Beispiel. Da Du damit angefangen hast, ist es ja wohl an Dir, mal konkreter zu werden. > Ich sagte ja nicht, dass die Programmiersprache das Problem sei, sondern > nur, dass nicht alles automatisch problemlos ist, nur weil man eine > langlebige Sprache verwendet, so wie hier behauptet. Das hat ja auch niemand außer Dir behauptet. Notwendig != hinreichend.
Moin, für nen Kunden, der mal Langzeitverfügbarkeit haben wollte, habe ich mal ne Ubuntu-Live-CD remastered, da gibt's ne Menge Anleitungen. Die kann er, solange er noch irgend einen PC findet, der von CDROM booten kann, in ein paar Minuten hochstarten und ist lauffähig. Fazit: Die CDROM liegt mit dem eigens dafür angeschafften Laptop irgendwo gut aufbewahrt im Keller, denn wer weiss, ob die HW in 20 Jahren noch i86 kompatibel sein wird.. Jetzt kann höchstens das Laufwerk wegen Nichtgebrauch irgendwann einharzen...aber die jährlichen Paranoia-Checks sind nicht mehr mein Bier :-) Aber ganz im Ernst: Die Prozedur ist teurer als Ausdrucken des Source auf Papier und Reverse-/Re-Engineering mit der gängigen Technik in 20 Jahren.
schreibe Dir Funktionstests, mit denen Du die korrekte Funktion auch nach einem Update von Bibliothek und/oder Python überprüfen kannst. Oder erstelle ein Docker-Image, wie schon geschrieben wurde.
Nop schrieb: > Das geht mit definiertem Interface über stdin/stdout, und im > GUI-Programm forkt man das dann bloß noch. mhm... wird sicher super lesbarer Code und schnell dazu, wenn da irgendwelche nichttrivialen Datenstrukturen oder -Mengen ausgetauscht werden sollen ...
Sven B. schrieb: > mhm... wird sicher super lesbarer Code und schnell dazu, wenn da > irgendwelche nichttrivialen Datenstrukturen oder -Mengen ausgetauscht > werden sollen ... JSON-Parser gibt's wie Sand am Meer, da muß man gar nichts mehr entwickeln. Zudem erlaubt es auch das gescriptete Ausführen ganz ohne GUI. Das ist der zweite Grund, wieso das unter Unix so entwickelt wurde. Drittens generieren GUIs normalerweise keine nennenswerten Daten, sondern die kommen üblicherweise woanders her und werden dann allenfalls noch visualisiert. Bei nennenswerter Komplexität ist es jedenfalls allemale besser, wenn man Teilmodule mit sauber definiertem Interface hat, als wenn alles in einem Monolithen mit geteilten Datenstrukturen steckt.
Nop schrieb: > Sven B. schrieb: > >> mhm... wird sicher super lesbarer Code und schnell dazu, wenn da >> irgendwelche nichttrivialen Datenstrukturen oder -Mengen ausgetauscht >> werden sollen ... > > JSON-Parser gibt's wie Sand am Meer, da muß man gar nichts mehr > entwickeln. Abgesehen davon, dass halt die typische C++-Datenstruktur sehr weit davon entfernt ist, automatisch in JSON serialisierbar zu sein. Und davon, dass JSON unendlich langsam wird, wenn man mehr als 3 Integer verschickt. > Zudem erlaubt es auch das gescriptete Ausführen ganz ohne > GUI. Ok, das kann ich aber auch anders erreichen, z.B. indem ich eine GUI- und eine CLI-Anwendung schreibe, die beide gegen dieselbe Shared Library linken. > Drittens generieren GUIs normalerweise keine nennenswerten Daten, > sondern die kommen üblicherweise woanders her und werden dann allenfalls > noch visualisiert. Genau. Und dazu muss ich die Daten ja von meinem CLI-Programm an die GUI weitergeben. Das Tool, was ich gerade bastle, visualisiert zum Beispiel einige MB Samples die in ein paar Sekunden von einer Photodiode gesammelt werden. Das Visualisieren dauert ca. 1 Sekunde, konvertieren in und von JSON wird mindestens 10 dauern. > Bei nennenswerter Komplexität ist es jedenfalls allemale besser, wenn > man Teilmodule mit sauber definiertem Interface hat, als wenn alles in > einem Monolithen mit geteilten Datenstrukturen steckt. Bis auf den letzten Satzteil stimme ich dem zu. Es ist auch nicht so, dass ich den "CLI-Anwendung mit stdout das von der GUI-Anwendung visualisiert wird"-Ansatz prinzipiell immer falsch fände. In vielen Fällen ist das aber keine brauchbare Lösung, weil die ausgetauschten Daten entweder zu komplex oder zu viele sind. Dazu kommt noch eine Menge Komplexität, weil du Situationen handhaben musst wie "das CLI-Tool ist eine andere Version als das GUI-Tool", "das CLI-Tool ist gecrasht", "das CLI-Tool braucht ungewöhnlich lange um eine Antwort zu senden" etc. Unter Umständen brauchst du auch Dinge wie Events, die von der CLI-Anwendung generiert werden usw. Diese Dinge erhöhen natürlich auch die Stabilität der GUI-Anwendung, aber wenn du sie nicht machst, hast du tendentiell eher weniger Stabilität als ohne extra-Prozess.
:
Bearbeitet durch User
Nop schrieb: > Das umgeht man aber, wenn man das Programm modular aufbaut, so daß die > eigentliche Programmfunktion über ein Terminalprogramm erreichbar ist. Du hast noch nie eine richtige GUI-Anwendung geschrieben: -Client/Server -dutzende Dialoge, die mit Controls so vollgestopft sind, dass ein 24"-Monitor zwingend erforderlich ist -komplexe DB-Zugriffe -... JSON? LOL! merciless
Vincent H. schrieb: > Wie wärs mit compilieren via PyInstaller? > Das packt den Interpreter inklusive Paketabhängigkeiten in ein > executable. Damit kannst du das Binary vielleicht in 20 Jahren noch ausführen, aber ändern wird definitiv schwierig. Den Quellcode würde ich auf alle Fälle sichern. @Threadstarter Wie wäre es, wenn du die wenig unterstützten Abhängigkeiten los wirst und dir deine eigene libs schreibst? So dass du nur den Pythoninterpreter und die paar wenigen von vielen benutzten Libs sichern musst?
Sheeva P. schrieb: > Davon abgesehen sind virtualenvs natürlich toll, um Pakete für bestimmte > Projekte in bestimmten Versionen am System vorbei zu installieren, ohne > das System zu "verschmutzen" oder an die vom System mitgelieferten > Versionen und Pakete gebunden zu sein. Mittlerweile installiere ich nur > noch sehr selten Pakete aus dem Systemrepos und mache fast alles mit > virtualenvs. Und Sicherheitspatches bekommen die dann keine mehr.
Strubi schrieb: > Moin, > > für nen Kunden, der mal Langzeitverfügbarkeit haben wollte, habe ich mal > ne Ubuntu-Live-CD remastered, da gibt's ne Menge Anleitungen. Die kann > er, solange er noch irgend einen PC findet, der von CDROM booten kann, > in ein paar Minuten hochstarten und ist lauffähig. Fazit: Die CDROM > liegt mit dem eigens dafür angeschafften Laptop irgendwo gut aufbewahrt > im Keller, denn wer weiss, ob die HW in 20 Jahren noch i86 kompatibel > sein wird.. > Jetzt kann höchstens das Laufwerk wegen Nichtgebrauch irgendwann > einharzen...aber die jährlichen Paranoia-Checks sind nicht mehr mein > Bier :-) Da reicht ein Sturmregen mit überschwemmtem Keller und das Notebook und Laufwerk ist hin. Lediglich die CD-ROM selbst hat geringfügig bessere Chancen das zu überleben, wenn man sie schnell aus dem Wasser befreit. Irgendwo habe ich mal gelesen, dass das Material einer CD Wasser auf Dauer nicht mag. > Aber ganz im Ernst: Die Prozedur ist teurer als Ausdrucken des Source > auf Papier und Reverse-/Re-Engineering mit der gängigen Technik in 20 > Jahren. Das NB ist wahrscheinlich billiger als der Programmierer. Aber man könnte auch einen Raspberry Pi 3 aufbewahren, der ist klein und kostengünstig und könnte auch wasserdicht verpackt werden. Python läuft auf dem auch.
Nano schrieb: > Lediglich die CD-ROM selbst hat geringfügig bessere Chancen das zu > überleben, wenn man sie schnell aus dem Wasser befreit. > Irgendwo habe ich mal gelesen, dass das Material einer CD Wasser auf > Dauer nicht mag. CD ROMs haben auch ohne Wassereinwirkung eine relativ kurze Lebensdauer, da gibt es deutlich bessere Medien. Z.B. RDX Laufwerke sollen 30 Jahre Lebensdauer haben. Ob das aber wirklich eingehalten wird in der Praxis, steht auf einem anderen Blatt. Zumindest jede CD ROM sollten sie überleben.
Nano schrieb: > Sheeva P. schrieb: >> Davon abgesehen sind virtualenvs natürlich toll, > > Und Sicherheitspatches bekommen die dann keine mehr. Tipp: wir reden über Langzeitarchivierung. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.