Schade :(

[nate]

Soviel zum Mythos "Debian ist auf Langzeitstabilität fokussiert" ... Wenn es nicht noch Millionen (Milliarden?) von Zeilen Code "da draußen" gäbe, die in Python 2 geschrieben und nicht mal eben schnell trivial auf Python 3 zu portieren sind, könnte man da echt drüber lachen, aber so ist's eher traurig.

[herrmausf]

Den schwarzen Peter muss man aber hier eher dem Python Team zuschieben, aus meiner Sicht haben die es hier ganz schön verkackt einen saubere. Übergang hinzubekommen.
Wenn Debian es trotz EOL seit 2020 noch bis Mitte 2024 in den stable repos hat ist das doch ein Zeichen von Stabilität.
Andererseits sollte Zombie-Software irgendwann aus dem Standard rausfliegen um sich keine unnötigen Probleme zu machen.

[gorden]

nate schrieb:
--------------------------------------------------------------------------------
> Soviel zum Mythos "Debian ist auf Langzeitstabilität fokussiert"
Langzeitstabilität Bedeutet nicht, dass man Pakete in jeder Version mitschleppt sondern, das die Debian Version lange gepflegt wird auf dem gleichen Softwarestand.

> ... Wenn
> es nicht noch Millionen (Milliarden?) von Zeilen Code "da draußen" gäbe,
> die in Python 2 geschrieben und nicht mal eben schnell trivial auf Python 3
> zu portieren sind, könnte man da echt drüber lachen, aber so ist's eher
> traurig.
Naja wenn man bedenkt, dass es mehr als 10 Jahre Zeit waren um auf die neue Major umzustellen ist es eher traurig wenn es nicht gemacht wurde oder es ist einfach nicht mehr wirklich gewartet wo die Frage aufwirft ob man dies dann noch nutzten sollte.

[nate]

> Naja wenn man bedenkt, dass es mehr als 10 Jahre Zeit waren um auf die neue
> Major umzustellen ist es eher traurig wenn es nicht gemacht wurde

Wieso sollte es? Wieso sollte man Scripte oder Programme, die hervorragend seit Jahren für den gedachten Einsatzzweck funktionieren, von Programmiersprache X auf Programmiersprache Y portieren? (Und ja, Python 2 und Python 3 *sind* verschiedene Sprachen. Sie sind sich ähnlich genug, dass man mit ein paar Verrenkungen "polyglotten" Code erzeugen kann, der auf beiden läuft, aber die Unterschiede sind groß genug, dass man weder von Auf- noch von Abwärtskompatibilität sprechen kann.)

> es ist einfach nicht mehr wirklich gewartet

Genau. Weil's halt einfach seit Jahren läuft und der ursprüngliche Entwickler evtl. auch schon längst weg ist.

> wo die Frage aufwirft ob man dies dann noch nutzten sollte.

Warum sollte man den Code wegschmeißen und neu machen? Einfach nur aus Spaß an der Freude, weil "neue Besen kehren gut"?

[gorden]

nate schrieb:
--------------------------------------------------------------------------------
> > Naja wenn man bedenkt, dass es mehr als 10 Jahre Zeit waren um auf die
> neue
> > Major umzustellen ist es eher traurig wenn es nicht gemacht wurde
>
> Wieso sollte es? Wieso sollte man Scripte oder Programme, die hervorragend
> seit Jahren für den gedachten Einsatzzweck funktionieren, von
> Programmiersprache X auf Programmiersprache Y portieren? (Und ja, Python 2
> und Python 3 *sind* verschiedene Sprachen. Sie sind sich ähnlich genug,
> dass man mit ein paar Verrenkungen "polyglotten" Code erzeugen kann, der
> auf beiden läuft, aber die Unterschiede sind groß genug, dass man weder von
> Auf- noch von Abwärtskompatibilität sprechen kann.)
Nein Python 2 und Python 3 ist keine Andere Sprach einfach nur eine neue Major Version ohne Forward/Backward Kompatible zu sein. Vielleicht verwechselst du das mit Perl. Wenn du das ganze so betrachtest würde es viel mehr Sprachen geben die neue Sprachen sind bei einer neuen Major Version.
Wenn es etwas ist was nicht komplex ist, dann sollte es kein Problem sein die paar Änderungen für den Versionswechsel zu machen. Und wenn es eine Komplexes Programm ist dann sollte man diese entweder Umgestellt haben oder nicht mehr nutzten.

> > es ist einfach nicht mehr wirklich gewartet
>
> Genau. Weil's halt einfach seit Jahren läuft und der ursprüngliche
> Entwickler evtl. auch schon längst weg ist.
>
> > wo die Frage aufwirft ob man dies dann noch nutzten sollte.
>
> Warum sollte man den Code wegschmeißen und neu machen? Einfach nur aus Spaß
> an der Freude, weil "neue Besen kehren gut"?
Keines Sagt etwas von wegschmeißen.
Aber was nicht mehr gewartet wird ist potentiell gefährdet weil noch Sicherheitslücken existieren können. Und da Python 2 schon seit 2 Jahren nicht mehr gepflegt wird ist es nicht empfehlenswert es noch zu nutzen.

[nate]

> Nein Python 2 und Python 3 ist keine Andere Sprach einfach nur eine neue
> Major Version ohne Forward/Backward Kompatible zu sein.

Wo ist da der Unterschied? Wenn ich zwei Dinge habe, die oberflächlich ähnlich aussehen, aber weder in die eine noch in die andere Richtung kompatibel sind, dann sind das eben zwei _verschiedene_ Dinge.

> Vielleicht verwechselst du das mit Perl.

Nein, aber Perl 5 vs. 6 ("Raku") ist ein guter Vergleich. Oder Visual Basic vs. VB.net -- wobei sich da wenigstens auch der Name deutlich geändert hat, so dass die Abgrenzung da etwas offensichtlicher ist.

> Wenn es etwas ist was nicht komplex ist, dann sollte es kein Problem sein
> die paar Änderungen für den Versionswechsel zu machen.

*Weit* gefehlt. Ich habe schon einige Python-2-auf-3-Portierungen hinter mir, und das ist nie ein Zuckerschlecken. Es gibt einige Aspekte, die einfach und sogar maschinell zu übersetzen sind, z.B. print und das geänderte Verhalten von (x)range, map und filter. Bei den Divisionen wird's schon schwieriger -- da Python keine stark typisierte Sprache ist, muss man sich den Code genau anschauen und für jede Division prüfen, ob dort Integer- oder Float-Werte verarbeitet werden. Und bei Strings wird's völlig unübersichtlich; was man da nach "bytes" konvertieren muss und was nicht, und wo man ein .encode() oder .decode() einstreuen muss, kann oft nur durch umfassende Analyse des Kontexts geklärt werden. Und wenn man's falsch macht, merkt man's mitunter nicht einmal sofort, sondern der TypeError, UnicodeEncodeError oder UnicodeDecodeError fliegt einem dann ein halbes Jahr später um die Ohren.

> Und wenn es eine
> Komplexes Programm ist dann sollte man diese entweder Umgestellt haben oder
> nicht mehr nutzten.

*Gerade* wenn es ein komplexes Programm ist, sollte man die Umstellung tunlichst vermeiden, solange "muss auf Python 3 laufen" keine harte Anforderung ist. Never change a running system.

> Aber was nicht mehr gewartet wird ist potentiell gefährdet weil noch
> Sicherheitslücken existieren können.

Für Anwendersoftware u.ä. ist dieser Standpunkt verständlich. Aber für Scripte, die komplexe Dinge in einem abgegrenzten Umfeld tun (also nicht mit SSL o.ä. hantieren, was sicherheitslückenanfällig ist), sind die einzigen relevanten Sicherheitslücken die, die im Code der Scripte selbst enthalten sind -- und die man bei einer Portierung auf Python 3 meist auch nicht findet.

[Engel]

nate schrieb:
--------------------------------------------------------------------------------
> Never change a running system.


Dieser Spruch war vor Jahren mal aktuell, mittlerweile kann man ihn aber getrost in die Tonne kloppen, mit gewissen Ausnahmen.

1.) Das System ist vollkommen abgeschottet und wird auch nicht über Drittwege (TeamViewer o. ä. auf einem Rechner installiert, der in-/direkten Zugriff auf das System hat).
2.) Es gibt keine wirtschaftliche Alternative (Spezialmaschienen in der Produktion, etc.).
3.) Man ist sich dem Risiko vollkommen bewusst und kann es auch stemmen.

Durch diese dämliche Mentalität, habe ich gerade massivst Probleme, weil uralte Käuze der Meinung sind, dass ihr 30/40 Jahre altes Zertifikat noch mehr Wert wäre, als das einlagige Toilettenpapier für die Angestellten.

Die Systeme wurden trotz 14 Jahre Support niemals von x/init auf systemd umgestellt (REHL 7 zu 8), UEFI wurde grundsätzlich deaktiviert, Firmwareupdates wurden so selten gemacht, dass es mich schon fast wundert, wenn ich als Jahr mal was über 2010 habe, 2020+ fällt sowieso weg, selbst bei nigelnagelneuen Systemen, die aktuellsten CPUs verbaut hatten, werden teils noch 10-20 Jahre alte Netzwerk/HBAs eingesetzt, die absolut veraltet sind und längst keinen Support mehr haben, etc. pp.

Eine aktuelle Standard-Anwendung normal zu betreiben, ist damit nicht möglich, egal was und wie du es machen möchtest, du musst zwangsweise auf einem supporteten OS (länger als 2 Jahre...), massenweise Softwarepakete querladen, selbst kompilieren und so weiter, damit man überhaupt arbeiten kann. Der Aufwand ist so astronomisch, dass ich manchmal gewillt bin, wieder REHL 6 auszupacken, was aber Sicherheitstechnisch einfach nicht geht, genauso wie man RHEL 7 mittlerweile vergessen kann, die nicht einmal TLS 1.3 unterstützen können, ohne manuellen Zusatzaufwand.

Und um das Ganze noch schön abzurunden, muss für jedes dämliche Update, egal ob Kernel, System oder Anwendung, zig Pakete neu für den Kernel kompiliert werden, damit überhaupt was läuft. Das ist kein "running System", das ist ein Krebsgeschwür, dass 80% meiner Zeit frisst und jedes Update meiner Anwendung zu einem Nervenkitzel werden lässt, nur weil die Verantwortlichen der abhängigen Systeme, ihre Scripte, Anwendungen und Systeme nicht sauber auf den aktuellen Stand bringen möchten...

Ich kann es wirklich nicht mehr hören, aber selbst Linus Torvald, sieht systemd als eine absolut nötige Komponente, für einen sicheren Betrieb der aktuellen Technik und das sagt mehr aus, als ein eingerosteter Spruch, der in der Birne von Menschen festhängt, die vor 30-40 Jahren das letzte Mal ein Seminar oder eine Fortbildung über eins ihrer betreuten Anwendungen/Systeme besucht haben...

[gorden]

Kann mich dem Anschliessen. Ist bei Software Entwicklung nicht anders, wenn man den Code nicht Pflegt und die Technischen Schulden ab und zu abbaut kommt man irgendwann in die Mühle wo man mehr Zeit Aufwenden muss für Gebsattel damit es irgendwie läuft oder der eine Bug den anderen Jagt als dass man etwas neues Bauen oder Erweitern kann.

[nate]

Ich glaube, du hast da etwas falsch verstanden.

Mir ging es um die Ausführbahrkeit von anwender- oder unternehmensspezifischen Scripten mit viel "Business Logic", die vor mehr als 10 Jahren entwickelt wurden und seither ihren Dienst tun.

Du schreibst hier von Systemkomponenten -- und da gebe ich dir recht, die sollte man dringend aktuell halten. Genau deswegen bin ich ja etwas angesäuert: Die Entscheidung, Python 2 zu entfernen, bedeutet, dass man die betroffenen Systeme eben *nicht* ohne Weiteres auf Debian 12 upgraden kann.

[gorden]

nate schrieb:
--------------------------------------------------------------------------------
> Ich glaube, du hast da etwas falsch verstanden.
>
> Mir ging es um die Ausführbahrkeit von anwender- oder
> unternehmensspezifischen Scripten mit viel "Business Logic", die vor mehr
> als 10 Jahren entwickelt wurden und seither ihren Dienst tun.
>
> Du schreibst hier von Systemkomponenten -- und da gebe ich dir recht, die
> sollte man dringend aktuell halten. Genau deswegen bin ich ja etwas
> angesäuert: Die Entscheidung, Python 2 zu entfernen, bedeutet, dass man die
> betroffenen Systeme eben *nicht* ohne Weiteres auf Debian 12 upgraden kann.

Nein er schreibt auch Anwendungen. Und genau das ist der Punkt, es braucht immer mehr Zeit wenn Software nicht gepflegt wird.

[laserbeamer]

nate schrieb:
--------------------------------------------------------------------------------
> Bei den Divisionen wird's schon schwieriger -- da Python keine stark typisierte Sprache ist, muss man
> sich den Code genau anschauen und für jede Division prüfen, ob dort
> Integer- oder Float-Werte verarbeitet werden.

Sollte ja kein Problem sein, da man sowas ja als guter Programmierer dokumentiert, gerade bei sprachen die keine starke Typisierung haben.

> Und bei Strings wird's völlig unübersichtlich; was man da nach "bytes" konvertieren muss und was nicht,
> und wo man ein .encode() oder .decode() einstreuen muss, kann oft nur durch
> umfassende Analyse des Kontexts geklärt werden.

Oder eben aus der Dokumentation der Funktionen und Klassen.

> Und wenn man's falsch
> macht, merkt man's mitunter nicht einmal sofort, sondern der TypeError,
> UnicodeEncodeError oder UnicodeDecodeError fliegt einem dann ein halbes
> Jahr später um die Ohren.

Wenn man seine Tests nicht ausführt ja, deshalb hat man doch seine unit Tests geschrieben und eine Code coverage von 100%.

> *Gerade* wenn es ein komplexes Programm ist, sollte man die Umstellung
> tunlichst vermeiden, solange "muss auf Python 3 laufen" keine harte
> Anforderung ist.

Es gibt mittlerweile wenige Distributionen die Python 2 noch anbieten, davon ab sollte man halt tote Software nicht mehr benutzen, das sind potentielle Sicherheitsrisiken (also Python 2).

> Never change a running system.

Die Anforderung sollte sein: Es läuft mit aktueller Hardware und Software.

Das bedeutet bei Software immer das man sie von Zeit zu Zeit umschreiben muss, ob weil Python 2 nur noch ein Risiko ist oder weil die Software nur mit Windows XP läuft oder aktuelle Standards nicht mehr unterstützt werden (z.b. tls1.3).

Software ist nie fertig, sondern muss gewartet werden.
Und genau deshalb sollte man seinen Code gut dokumentieren und Testen, dann sind solche Portierungen nicht geschenkt aber immerhin zügig und zuverlässig erledigt.