Frage an Testing/Sid-User - Welche Features braucht ihr wirklich?

[uname]

Mit großem Interesse verfolge ich die Umfrage und die Diskussion zu Umfrage Debian Releaselieblinge. Aktuell haben 27% (Mehrfachstimmen sind möglich) für Testing bzw. Sid abgestimmt. Das finde ich interessant.

Natürlich ist es so, dass Debian Stable über den Release-Zyklus von 2 Jahre (mit Freeze eher 2,5 Jahre) ziemlich stark veraltet. Das ist ja auch oft die Kritik an Debian aber auch an Ubuntu LTS. Ich habe auch schon Testing/Sid gefahren - heutzutage eher nur kurz vor Release - aber insgesamt sind mir die vielen Updates eines Rolling Releases doch zu anstrengend geworden.

Könnt ihr mir ein paar Softwareprodukte und Features nennen, die für euch die Verwendung von Testing/Sid sinnvoll machen? Oder habt ihr andere Gründe.

[rjh]

Ich habe auch schon Testing/Sid gefahren - heutzutage eher nur kurz vor Release - aber insgesamt sind mir die vielen Updates eines Rolling Releases doch zu anstrengend geworden.

Könnt ihr mir ein paar Softwareprodukte und Features nennen, die für euch die Verwendung von Testing/Sid sinnvoll machen? Oder habt ihr andere Gründe.

Bei mir ist der Grund ganz lapidar, dass ich großes Interesse an den neueren Entwicklungen habe. Mir macht es tatsächlich große Freude, täglich die Updates einzuspielen. Den "neuen" Entwicklungen von bspw. Systemd, Wayland und Pipewire stehe ich sehr offen, positiv und neugierig gegenüber. Nur ein funktionierendes Stable wäre mir einfach zu langweilig. Mit einer Ausnahme: Als "Rettungssystem" auf einem USB-Datenträger pflege ich immer auch ein Stable.

[QT]

Könnt ihr mir ein paar Softwareprodukte und Features nennen, die für euch die Verwendung von Testing/Sid sinnvoll machen? Oder habt ihr andere Gründe.

Auf Laptop und Desktop mit womöglich neuester Hardware benötige ich meistens auch die neueste Software. Hier will ich nicht auf Backports oder Fremdrepos oder gar TGZ Sourcen zurückgreifen müssen. Dazu geht es mir auf den Keks, mich alle x Jahre mit massiven Upgrades auf 1 Schlag auseinanderzusetzen sondern habe stattdessen einfach täglich oder wöchentlich einen Schwung an SID Updates. Mit geht ja sogar schon Testing auf den Keks, wenn nach 1 Freeze zB plötzlich massenhaft Updates kommen.

Mein aktuelles Desktopsystem ist zB im Jahr 2006 installiert und seither durch Updates erneuert worden. Einfacher und bequemer kann ich es mir nicht wünschen. Klar gab es in den 17 Jahren hier und da auch mal Situationen, wo es Probleme durch und mit Updates gab, aber gerade bei Sid darf man nicht immer erwarten, dass in jedem Moment die Repos ein perfekt aufeinander abgestimmtes System liefern können. Manches Update muss man einfach paar Tage verschieben, bis die Nachzügler im Repo aufschlagen, um dann die bestehenden Konflikte aufzulösen. Hier sollte man lieber "upgrade" statt "dist-upgrade" machen, um sein System nicht unnötig zu zerschießen.

Auf Servern dagegen habe ich dagegen aktuell noch Stable installiert, aber da war ich zB gerade genervt, dass ich x Systeme nun von Bullseye auf Bookworm ziehen muss und nicht überall läuft danach noch alles so wie vorher. Das ist ne Menge extra Arbeit und ich bin schon am Überlegen, auch die (privaten) Server auf Sid umzustellen.

[thunder11]

Könnt ihr mir ein paar Softwareprodukte und Features nennen, die für euch die Verwendung von Testing/Sid sinnvoll machen? Oder habt ihr andere Gründe.

Das entscheiden "Feature" ist das täglich Upgrade und die damit entstehende Spannung, ob auch alles hinterher noch funktioniert. Das lässt dann zumindest die Hoffnung auf erweiterte Aktivitäten aufkeimen.

Aber leider werde ich immer enttäuscht. Die Bruchlandungen der letzten 5 Jahre Testing-Gebrauch
lassen sich in meiner Erinnerung auf ganze zwei oder drei Vorfälle summieren.

Als ich mir vor 4 Jahre einen neuen Rechner zulegte, habe ich ganz gezielt auf Strom sparen und
Einfachheit der Komponenten geachtet.Daraus erwuchs eine mehr oder weniger reine Intel - Maschine
mit einem Intel Core i9-9900.
Das reicht mir von der Grafik-Leistung völlig aus, hat aber den Vorteil, dass hardwareseitig
keinerlei Probleme entstehen. Da bin ich sozusagen in der Kategorie "Oldoldstable" einzuordnen.


Die Aktualität von irgendwelchen Programmen, wie z,B. FF / Thunderbird / LO ist mir - wen ich es mal
genau betrachte - egal.Trotzdem hole ich mir die Programme bei Mozilla (Beta-Zweig) / LO ab.

Sicherheitsprobleme sind für mich nebensächlich. Ich verschlüssele meinen Rechner nicht. Das einzige
was ein bisschen geschützt ist, sind meine persönlichen Korrespondenzen / Daten die in einem verschlüsseltem Archiv liegen. Da muss ich auch nicht allzu oft ran. Also können mich eventuell ungebetenen Gäste ruhig mal besuchen, solange das Archiv nicht geöffnet ist.
Banking z.B. wird auf meiner "Produktiv- Maschine" überhaupt nicht gemacht.
Dafür gibt es eine VM mit einem kastriertem Windows und einem Banking Programm mit einem
Foto-TAN Generator. Über den Monat gerechnet, ist die vielleicht 2 - 3h geöffnet (wegen der Win-Updates )

[TRex]

+1. "Brauchen" tu ich da selten was. Auf meinem Desktop läuft Arch, weil sowohl die Hardware bleeding edge ist und ich auch bei der Software keinerlei Garantien brauche und auf das AUR zugreife. Auf dem Notebook testing, weil ähnliche Umstände, aber seltener in Gebrauch. Überall, wo ich das System gerne ohne Frickeln verwenden will, läuft stable - aber dafür gabs keine Auswahl ging ja um die "Lieblingsversion", und die existiert eigentlich nicht.

[michaa7]

Mit großem Interesse verfolge ich die Umfrage und die Diskussion zu Umfrage Debian Releaselieblinge. Aktuell haben 27% (Mehrfachstimmen sind möglich) für Testing bzw. Sid abgestimmt. ...

Ich war auch überrascht wie viele Nutzer sid verwenden. Auch weil das pur ja nur über eine vorangehende testing Installation möglich ist .... soweit man nicht wie ich siduction benutzt.

Mein Linuxeinstieg vor knapp 20 Jahren führte mich zu Debian (wg. der Philosophie) und gleichzeitig zu Kanotix (Debian Derivat). Ich hatte alte hardware, dort jedoch einen nagelneuen Hostadapter verbaut, der unter Debian noch nicht unterstützt wurde. Bei Kanotix gab es ein script (ich hatte als windows NT4.0 user keine Ahnung was ich damit anfangen sollte) um den Treiber zu installieren, in der folgenden Kanotix Ausgabe (wenn ich nicht irre "Bughunter) war das im Debian testing/sid Kanotix Hack integriert .... mein Rechner lief mit Linux.

Zur damaligen Zeit unterhielt ich einen kleinen homeserver der parallel zu meinem Kanotix Desktop mit Debian stable lief, wenn ich mich recht erinnere Woody oder Sarge. Das war völlig problemlos und auch das bald folgende Versionsupgrade lief mit ein paar kleinen hickups
gut durch.

Ich lernte parallel im Kanotix- und Debianforum was als als Anfänger zu lernen gab ... aber auch worin man sich verlieren und viel Zeit verpulvern kann. Zur damaligen Zeit war es noch viel häufiger so dass einen neue Graka, soundkarte, netzwerkadapter nur von neuester SW/kerneln unterstützt wurde, oder ich bei GIMP irgend eines der neuesten features nutzen wollte (ohne hier Fachman zu sein).

Kanotix entwickelte sich rasch zu sidux, und später über aptisod zu siduction. Gemeinsam war diesen Distributionen, dass sie Debian/sid als basis nutzen, direkt aus den Debian repos, und lediglich die zur *direkten* Installation notwendigen Pakete zusätzlich bereitstellten, nebst eigenen Artwork. Damit verbunden war der Ansatz, dass neueste SW/Kernel unter Sicherheitsgesichtspunkten für Angreifer das unbequemste Ziel darstellt und Sicherheitspatches schneller in sid als in testing eintrudeln. Jeweils den neuesten stable Kernel zu verwenden ergänzt diesen Ansatz ... und ermöglicht für die die es benötigen den bestgeeigneten Kernel für cutting edge HW.

sid ist so stabil wie windows nie war. In soweit ist die Bezeichnung "unstable irreführend un unnötig abschreckend. Und wenn ich heute sehe wie viele Probleme Nutzer beim Übergang von bullseye auf bookworm haben, wie schnell sie die Flinte ins Korn werfen und das wort "Neuinstalltion" in den Ring geworfen wird, dann bin ich um all die Jahre froh die mich mit sid Problemchen geschult und abgehärtet haben. Zumal sid über die beiden Jahrzehnte zahmer und zahmer geworden ist. Die Kooperation zwischen HW Herstellern und Kernelentwicklern ist heute unvergleichlich besser (auch wenn nvidia immer noch hinterherhinkt). Wer einmal an den Punkt gekommen ist beim releaseupgrade neu zu installieren weil er es entweder muss (muss man nicht) oder glaubt zu müssen (darauf läuft es hinaus), der sollte gleich zu testing oder sid greifen, weil der Aufwand und die LErnkurve nicht viel größer ist und mit der Zeit abflacht.

Abschließend ein Wort aus 20 Jähriger Erfahrung (vs. theoretischer Argumentation): Mit einer AUsnahme, und da saß das Problem eher zwischen Tastatur und Bildschirm, waren alle von mir hier im Forum als (KAnotix-, sidux-, aptosid-) siduction Nutzer geposteten Fragen Debian related, nicht durch das entsprechende Derivat induziert. Auch habe ich seit einigen Jahren neben dem siduction Kernel (der ggf mehrfach wöchenlich neu erscheint, und ein Debian basierter KErnel mit selectiven patches von Kernel org bzw HW Herstellern wie nvidia etc. ist)) auch immer den neuesten Debian Kernel installiert um bei Problemen und einem ggf. abgesetzen Bugreport so pur Debianisch wie irgend möglich zu sein.

Was ich hier also sage ist: ... gibt keinen Grund vor sid Bedenken zu haben

[MSfree]

sid ist so stabil wie windows nie war.

Nein, siehe nächster Absatz.

In soweit ist die Bezeichnung "unstable irreführend un unnötig abschreckend.

Weil auch du den Begriff "stable" falsch deutest.

Stable bezieht sich nicht auf die Softwareeigenschaft, absturzfrei zu sein, sondern auf die Eigenschaft, die Versionen der Bibliotheken, Executables und Kernel nicht zu wechseln. So hat ein Debian Jessie einen Kernel 3.16, und dieser wurde nie hochgezählt. Es gab nur Bugfixes, diese aber immer auf 3.16, obwohl schon längst neuere Kernel zur Verfügung getsanden hätten.

Insofern ist Windows sogar deutlich stabiler als es Debian je war. XP, Win7 und Win10 wurden über 10 Jahre (Versions)stabil gehalten (nicht absturzfrei), bei Debian gibt es nur 4 Jahre.

Wer einmal an den Punkt gekommen ist beim releaseupgrade neu zu installieren...

Nunja, ich habe letztes Jahr meinen Heimserver von Jessie auf Bookworm umgezogen. Das habe ich dann auf anderer Hardware neu installiert. Einerseits hatte ich keine Lust, 4 dist-upgrades zu fahren, und den Server wollte ich während dessen auch noch im Zugriff haben. Daß dabei dann auch aufgefallen ist, daß es einige Pakete, die ich auf dem Jessie laufen hatte, gar nicht mehr für Bookworm gibt oder auf Alternativen umgestellt wurden, hat mit mit der Neuisntallation am Ende recht gegeben. Der Zeitdruck war raus, der alte Server ging ja noch und Probleme mit der Portierung von Konfigurationen und Datenbanken konnte ich in aller Ruhe angehen.

Man kann sich leider nicht darauf verlassen, daß ein dist-upgrade in jedem Fall klappt. Mir sind z.B. squirrelmail und ViewVC abhanden gekommen und mysql wurde durch mariadb ersetzt. Auch meine alte Fotogallerie hat nicht mehr funktioniert, weil die PHP-Version inkompatibel war.

Andererseits nutze ich zur Zeit Trixie auf ein paar Rechnern, was bisher völlig unproblematisch ist. Dafür gibt es nicht einmal einen Grund, einfach weil es Spaß macht und es sehr zuverlässig seinen Dienst macht.

SID ist mir aber trotzdem zu anstrengend. Dort kommt es doch öfter vor, daß ein gerade upgegradetes Paket die Funktinalität des halben System beeinträchtigt. Dann muß man wieder 1-2 Tage warten, bis alles wieder im Lot ist. Testing ist da deutlich handzahmer.

[michaa7]

sid ist so stabil wie windows nie war.

Nein, siehe nächster Absatz.

In soweit ist die Bezeichnung "unstable irreführend un unnötig abschreckend.

Weil auch du den Begriff "stable" falsch deutest.

Stable bezieht sich nicht auf die Softwareeigenschaft, absturzfrei zu sein, sondern auf die Eigenschaft, die Versionen der Bibliotheken, Executables und Kernel nicht zu wechseln. ...

Gut. Das leuchtet ein.

Nur werden das die meisten Nutzer (einschließlich teilweise bislang mir) intuitiv falsch interpretieren, also im Sinn von zu erwartender Fehlerhaftigkeit und weniger im Sinn von Versionsnummerstabilität. Allerdings macht deine Klarstellung daher um so mehr Sinn und räumt die unzutreffende Annahme auf das stabel testing unstable wörtlich zu nehmende Aussagen über die jeweils zu erwartende Stabilität der Performance wären. Sie sind das nur bedingt und im Beispiel unstable eben eher Hinweis über schnell anwachsende Versionsnummern oder Versionssprünge als Warnung vor (temporär) instabiler Performance. Letzteres ist die Ausnahme ... und für Interessierte gibt es ggf. auch ein spezielles Forum um dem so weit wie möglich auszuweichen.

[Chameleon]

Banking z.B. wird auf meiner "Produktiv- Maschine" überhaupt nicht gemacht.
Dafür gibt es eine VM mit einem kastriertem Windows und einem Banking Programm mit einem
Foto-TAN Generator.

Also warum man jetzt ausgerechnet für eine der sensibelsten Geschichten ein Windows installiert, erschließt sich mir nicht - gerade fürs Banking ist ein Rolling Release wahrscheinlich der sicherste Weg überhaupt.

[KP97]

Also warum man jetzt ausgerechnet für eine der sensibelsten Geschichten ein Windows installiert, erschließt sich mir nicht - gerade fürs Banking ist ein Rolling Release wahrscheinlich der sicherste Weg überhaupt. ;)

Genau das habe ich auch sofort gedacht.
Wenn man dann noch eine Software wie Hibiscus wählt, die auf einem Linux System bei mir seit Jahren völlig unproblematisch läuft, kann man auf so eine "Krücke" jederzeit verzichten.
Der Entwickler Olaf Willuhn reagiert auch sofort auf Anfragen und evtl. Fehlermeldungen, da kann sich jede kommerzielle Firma ein Beispiel dran nehmen.
https://www.willuhn.de/products/jameica/
https://homebanking-hilfe.de/forum/index.php?f=33

@Chameleon
Ich nutze nun seit bestimmt 18 Jahren durchgängig Sid und habe in dieser langen Zeit nicht einmal erlebt, daß das System unbrauchbar war bzw. nicht starten konnte.
Sicher hat das ein oder andere Paket auch mal einen Fehler, aber das ist meistens am gleichen oder am nächsten Tag gefixt. Und es kommt auch eigentlich selten vor, alles in allem läuft so ein Sid stabiler als manche andere Distro. Es kann z.B. bei großen Änderungen wie Qt5 nach Qt6 vorkommen, daß nicht alle Pakete sofort fertig sind und noch eine lib fehlt, dann wartet man mit dem full-upgrade halt solange, bis alles komplett ist.
Trotzdem sollte man schon einige Basiskenntnisse haben, einem Anfänger würde ich es nicht empfehlen.

[Chameleon]

@Chameleon
Ich nutze nun seit bestimmt 18 Jahren durchgängig Sid und habe in dieser langen Zeit nicht einmal erlebt, daß das System unbrauchbar war bzw. nicht starten konnte.
Sicher hat das ein oder andere Paket auch mal einen Fehler, aber das ist meistens am gleichen oder am nächsten Tag gefixt. Und es kommt auch eigentlich selten vor, alles in allem läuft so ein Sid stabiler als manche andere Distro. Es kann z.B. bei großen Änderungen wie Qt5 nach Qt6 vorkommen, daß nicht alle Pakete sofort fertig sind und noch eine lib fehlt, dann wartet man mit dem full-upgrade halt solange, bis alles komplett ist.
Trotzdem sollte man schon einige Basiskenntnisse haben, einem Anfänger würde ich es nicht empfehlen.

Mit solchen Problemchen kann ich umgehen - hatte genau so etwas in der Art (qt5/qt6) vor kurzem unter Tumbleweed mit Stellarium, da wartet man halt ein, zwei Tage und dann ist das gefixt.

Aber ja, hast mich überzeugt (18 Jahre sind ne echte Nummer) - hab auf nem alten Läppi ein testing am laufen - das werd ich wohl auf unstable hochziehen und einfach mal schauen, was passiert.


Nachtrag: so liebe sid-User, könnt ihr mir kurz unter die Arme greifen und mir "Starthilfe" geben - ist das hier jetzt ein unstable/sid und falls ja, warum hab ich so einen alten Kernel und warum steht da trixie als Codename?

Code: Alles auswählen

root@T420:~# uname -a
Linux T420 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.11-1 (2023-08-17) x86_64 GNU/Linux
root@T420:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux trixie/sid
Release:        n/a
Codename:       trixie
root@T420:~# cat /etc/apt/sources.list
# deb cdrom:[Debian GNU/Linux testing _testing_ - Official Snapshot amd64 DVD Binary-1 with firmware 20230417-03:12]/ testing main non-free-firmware

deb http://ftp-stud.hs-esslingen.de/debian/ sid main contrib non-free-firmware non-free
# deb-src http://ftp-stud.hs-esslingen.de/debian/ testing main non-free-firmware

# deb http://security.debian.org/debian-security unstable-security main contrib non-free-firmware non-free
# deb-src http://security.debian.org/debian-security testing-security main non-free-firmware
root@T420:~# exit

[michaa7]

da steht trixie/sid, das ist auf allen sid systemen so, weil sid und testing ja nicht unabhängig voneinander sind. Testing (derzeit trixie) ist ja nur ein 14 Tage abgehangenes sid.

Was ist alt an diesem Kernel? 17.08.23? Kernel 6.4.x, kernel 6.5 wurde gestern erst freigegeben von Linus.

Die sources.list ist ok, auch wenn ich statt spezifischem Repo das generische deb.debian.org bevorzuge.

Alles ok. Allerdings scheinst du keine signierten Repos zu benutzen.

[schwedenmann]

Hallö

@Michaa7

da steht trixie/sid, das ist auf allen sid systemen so, weil sid und testing ja nicht unabhängig voneinander sind. Testing (derzeit trixie) ist ja nur ein 14 Tage abgehangenes sid.

Sid kannst du ja nur installieren,wenn du erst testing (also trixie,was dann auch in der sources.list steht) installierst und dann die sources.list anpaßt,also dort sid einträgst,wobei bei mir überall dort unstable steht und sid ist ja afaik kein codename für unstable, wie trixie für testing.

mfg
schwedenmann

[Chameleon]

Was ist alt an diesem Kernel? 17.08.23? Kernel 6.4.x, kernel 6.5 wurde gestern erst freigegeben von Linus.

Naja, ich hätte nen Zwinker-Smilie setzen sollen - hab halt noch ein anderes System, das ist bei Kernel 6.4.11 an stelle von 6.4.0 - wie erwähnt, da fehlt der Zwinker-Smilie.

Die sources.list ist ok, auch wenn ich statt spezifischem Repo das generische deb.debian.org bevorzuge.

Alles ok. Allerdings scheinst du keine signierten Repos zu benutzen.

Kannst du mir das genauer erläutern, kann dem gerade nicht ganz folgen - was ist "spezifisches Repo" vs. "deb.debian.org" und was ist mit dem "signierten Repo" gemeint?

[rhHeini]

Ich hab die letzten 9 Monate vor der Freigabe von Bookworm Testing verwendet damit meine RDNA2-Karte saubere Graphik lieferte.

[michaa7]

Was ist alt an diesem Kernel? 17.08.23? Kernel 6.4.x, kernel 6.5 wurde gestern erst freigegeben von Linus.

Naja, ich hätte nen Zwinker-Smilie setzen sollen - hab halt noch ein anderes System, das ist bei Kernel 6.4.11 an stelle von 6.4.0 - wie erwähnt, da fehlt der Zwinker-Smilie.

Achso, es geht um den größeren Kernel:

Found linux image: /boot/vmlinuz-6.4.12-1-siduction-amd64

hier.

Die sources.list ist ok, auch wenn ich statt spezifischem Repo das generische deb.debian.org bevorzuge.

Alles ok. Allerdings scheinst du keine signierten Repos zu benutzen.

Kannst du mir das genauer erläutern, kann dem gerade nicht ganz folgen - was ist "spezifisches Repo" vs. "deb.debian.org" und was ist mit dem "signierten Repo" gemeint?

Das ist dein Repo, ein konkret benanntes. Von hier und nur hier bekommst deinen Pakete

deb http://ftp-stud.hs-esslingen.de/debian/ sid main contrib non-free-firmware non-free

Das ist an sich vollkommen in Ordnung! Fällt das aber aus irgendeinem Grund aus oder ist es temporär überlastet guckst du in die Röhre. Das kommt selten vor. Zudem werden so per Zufall einige Repos stark, andere selten oder gar nicht benutzt. Der Nutzer weiß ja nicht wieviele andere Nutzer welche Repos wann nutzen.
Bei Nutzung von deb.debian.org nutzt du eine generische URL, die weltweit gültig ist und abhängig von deinem Standort und abhängig von der Auslastung eines von deb.debian.org angefragten Repos dir immer die schnellstmögliche Verbindung zu einem der Repos in deiner Nähe sucht. Ich verwende dies seit Jahren ohne Problem. Das ist nur eine Hinweis und eine Empfehlung, kein richtig oder falsch.

Eine *andere Sache* ist das signieren der Repos, wobei ich mich da nicht so gut auskenne. Aber bei mir funktioniert apt mit unsignierten Repos gar nciht mehr. Der grundgedanke dabei ist wohl auf diese Weise man-in-the-middle Angriffe auf Repos ausschließen zu können. Dazu findet ein gpg Schlüsseltausch statt den du einmalig einrichten mußt. Zudem ändern sich die URLs:

deb [ signed-by=/usr/share/keyrings/debian-archive-keyring.gpg] http://deb.debian.org/debian/ unstable main contrib non-free non-free-firmware

wie du das einrichtest , dazu suchst du am besten hier im Forum nach entsprechenden postings.

[Chameleon]

Die sources.list ist ok, auch wenn ich statt spezifischem Repo das generische deb.debian.org bevorzuge.

Alles ok. Allerdings scheinst du keine signierten Repos zu benutzen.

Kannst du mir das genauer erläutern, kann dem gerade nicht ganz folgen - was ist "spezifisches Repo" vs. "deb.debian.org" und was ist mit dem "signierten Repo" gemeint?

Das ist dein Repo, ein konkret benanntes. Von hier und nur hier bekommst deinen Pakete

deb http://ftp-stud.hs-esslingen.de/debian/ sid main contrib non-free-firmware non-free

Das ist an sich vollkommen in Ordnung! Fällt das aber aus irgendeinem Grund aus oder ist es temporär überlastet guckst du in die Röhre.

Ok, das hab ich verstanden - hatte eh schon vermutet, dass es darum geht -> nun ja, das ist seinerzeit bei der Installation wohl so aus dem Gedanken mit dem "regional" entstanden, ich wohne in der Nähe von Esslingen.
Aber ja, ich werd das bei Gelegenheit wohl umändern auf das Hauptrepo - Danke für den Hinweis.

Eine *andere Sache* ist das signieren der Repos, wobei ich mich da nicht so gut auskenne.

naja, da wäre jetzt mein Gedanke, das liegt am T420, das Gerät kann UEFI, hat aber noch kein Secureboot - sprich, es benötigt einfach auch keine signierte Repos - > kann aber durchaus sein, dass ich das falsch interpretiere.

Wie auch immer, Danke schön für die "Starthilfe" - für den Moment ist es für mich ok, zu wissen, dass ich die sources.list so stehen lassen kann, darauf kann man aufbauen, der Rest ergibt sich dann aus dem Alltag.

[Meillo]

Nachdem mir nun seit Jahren old*stable neu genug ist, kann ich nur Gruende von frueher anfuehren, als ich auch mal Testing und Unstable verwendet habe.

Testing habe ich damals zeitweise genutzt, wegen der neueren Hardwareunterstuetzung. Auch mal fuer neuere Programmversionen, bevor es Backports gab oder ich mir die selber hergestellt habe. In der Zeit, in der ich selber Pakete gebaut habe, habe ich mich mit Testing naeher an der Entwicklung gefuehlt und es auch darum genutzt. Die Debian-spezifischen Entwicklungswerkzeuge waren damit auch neuer. (Gebaut habe ich dann in einer Unstable-Sandbox.)

Unstable habe ich eine Weile verwendet, weil ich damit durch die verschiedenen Probleme allerlei gelernt habe. Das war zwar anstrengend und zeitaufwaendig, aber lehrreich.

[uname]

Sid kannst du ja nur installieren,wenn du erst testing (also trixie,was dann auch in der sources.list steht) installierst und dann die sources.list anpaßt,also dort sid einträgst,wobei bei mir überall dort unstable steht und sid ist ja afaik kein codename für unstable, wie trixie für testing.

Ist das wirklich so, dass man vorher testing/trixie installieren muss?

Mindestens bei grml-debootstrap ( Doku grml-debootstrap bei Grml) gibt es die Option direkt sid auszuwählen. Entweder als Parameter --release sid oder wenn man es ohne Parameter aufruft in den Menüs. Also entweder das Grml-Livesystem booten, anderes debian-basiertes beliebiges Live booten (z. B. BunsenLabs) und grml-debootstrap nachinstallieren oder wenn man ein altes Debian-basiertes System platt machen möchten (auch z. B. Ubuntu), grml-debootstrap (Paket bei Ubuntu) installieren und ausführen. /usr/sbin/grml-debootstrap installiert pures Debian und kein Grml. Ich weiß nicht, ob man auch debootstrap verwenden kann. Wenn ja wird es aber wohl komplizierter sein, da grml-debootstrap eigentlich nur ein Wrapper von debootstap ist. Vielleicht kann das jemand eben ausprobieren.

Ich habe im Internet auf die Schnelle ein Video gefunden. Ist aber schon fast 10 Jahre alt. Hier der relevante Auszug bzgl. grml-debootstrap und Sid: https://www.youtube.com/watch?v=chWw_Z1t_oI&t=140

Ich habe mal bei Grml 2022.11 (verwendet selbst testing laut Paketquellen) im Live-System auf die neusten Pakete aktualisiert. Dort gibt es dann in /usr/sbin/grml-debootstrap die Alternativen buster, bullseye, bookworm und sid. Interessant, dass es testing/trixie nicht gibt. Die Installation selbst habe ich nicht ausprobiert. Vielleicht kann man jemand ausprobieren, ob mit der Option Sid wirklich Sid oder doch testing/trixie installiert wird.

[fischig]

Welche Features braucht ihr wirklich?

Es gibt verschiedene Arten von „Gebräuchen“.
Die Frage setzt eigentlich voraus, dass ein Betriebssystem/die Version eines Betriebssystems ein Mittel zur Erreichung eines Zweckes/Zieles ist. Um also ernsthaft auf die Frage einzugehen, müsste man explizieren, zu welchem Zweck man das OS denn nutzt. Den bisherigen Antworten entnehme ich, dass dort das Mittel selbst der Zweck ist, ohne dass das expliziert wird.
Mich tät mal interessieren, ob jemand, der z.B. einen Roman schreibt, ein Bild/Video bearbeitet, selbst programmiert, (OSM zuarbeitet ), etc., sagen kann, warum er/sie „Testing/Sid“ dafür „wirklich“ benötigt.

[Meillo]

Sid kannst du ja nur installieren,wenn du erst testing (also trixie,was dann auch in der sources.list steht) installierst und dann die sources.list anpaßt [...]

Ist das wirklich so, dass man vorher testing/trixie installieren muss?

Meines Wissens ist Testing sozusagen nur ein Unstable mit Filter: Die Basis ist die Gleiche, allerdings wandern Pakete aus Unstable nur dann nach Testing, wenn sie zehn (?) Tage lang keine schwerwiegenden Bugs hatten und nicht explizit geblockt sind. Pakete ohne schwerwiegende Bugs (oder sonstige Besonderheiten) sind also die gleichen bei Testing und Unstable.

Gleichermassen ist Experimental auch nur ein Unstable, das allerdings zusaetzliche explizit als experimental hochgeladene Pakete, die potenziell noch verbuggter sind, enthaelt.

Testing und Experimental sind somit nur Sonderformen von Unstable, mit weniger oder mehr potenziellen Bugs. Und Unstable ist einfach der Stand der Paketsammlung, an dem die Entwickler gerade arbeiten.

So zumindest mein strukurelles Verstaendnis. Korrekturen sind willkommen.

[thunder11]

Chameleon hat geschrieben: 28.08.2023 18:55:31
Also warum man jetzt ausgerechnet für eine der sensibelsten Geschichten ein Windows installiert, erschließt sich mir nicht - gerade fürs Banking ist ein Rolling Release wahrscheinlich der sicherste Weg überhaupt.

Genau das habe ich auch sofort gedacht.
Wenn man dann noch eine Software wie Hibiscus wählt, die auf einem Linux System bei mir seit Jahren völlig unproblematisch läuft, kann man auf so eine "Krücke" jederzeit verzichten.
Der Entwickler Olaf Willuhn reagiert auch sofort auf Anfragen und evtl. Fehlermeldungen, da kann sich jede kommerzielle Firma ein Beispiel dran nehmen.

Will mal dazu was sagen - ohne dass es jetzt weiter hier diskutiert werden sollte:
Ich nutze Online-Banking seit X-Jahren (geschäftlich noch mit BTX im vorigen Jahrtausend).

Mein jetziges Banking-Programm (ALF-BANCO) nutze ich seit 12 Jahren. Bei mehreren Banken mit verschiedenen
Verfahren. Es ist äußerst zuverlässig und stabil. Die grafische Darstellung ist für mich ausreichend und übersichtlich.

Die Entscheidung für ein Windows Programm fiel zur damaligen Zeit, in der ich privat auf Linux umgestiegen bin.
Ich habe damals alles getestet, was für Linux auf dem Markt war (natürlich auch Hibiscus). Aber über "Poppelreuters Begnügungsgesetz"
ging das alles leider nicht hinaus. Meine damaligen Anforderungen :
Börse / Auslandskonto / mehrere Banken / interne Umbuchungen / Damals noch so einen Seconder mit Chip.Karte.
Dies war mit Linux- Programmen praktisch nicht erreichbar, oder nur mit Fehlern und unterirdischer Grafik.

Mag ja sein, dass sich bis heute einiges getan hat, aber bei einer so essentiellen Sache bin ich halt konservativ
und hab auch nicht die geringste Lust, mich diesbezüglich in nicht überschaubare Abenteuer zu begeben.

[Freeman]

Hi,
tatsächlich ist es der Spaß am Gerät bei mir warum ich sid nutze (Siduction). Ich mag das einfach, wenn sich was im System rührt . Gerne lese ich dann die Änderungen zu Paketen welche mich interessieren. Für Server und Clients, welche etwas kritisch sind, muss mein Spieltrieb aber pausieren und da läuft entweder Stable oder je nach Einsatzzweck was passendes.

[fischig]

tatsächlich ist es der Spaß am Gerät bei mir warum ich sid nutze (Siduction).

Und das halte ich für völlig in Ordnung! Nur sagen sollte man es schon, so wie du das jetzt machst.
Es ist halt ein ziemlicher Unterschied, ob man sagt, ich brauche das, weil mir die Beschäftigung damit Spß macht, weil ich OS-Strukturen erforschen will, oder ob man sagt, man benötigt sid, weil z.B. nur die LO-Version in sid mich schreiben lässt, was ich schreiben will („feature!“). Allgemeiner, aber immer noch metaphorisch, formuliert: Ob der Weg das Ziel ist oder ob man mit dem Weg ein bestimmtes Ziel außerhalb desselben erreichen will. Sowas in der Richtung habe ich im df und nicht nur in diesem Thread bisher noch nicht gelesen.

[Draal]

Damals betrieb ich ein NAS, auf dem CS Server betreiben wollte. Erstaunlicherweise verlangte ein Linux CS Dedicated Server eine CPU, die sse2 unterstützt. Meine 32bit CPU (1100 MHz) gab das nicht her. Witzigerweise verlangte die Windows CS Variante das nicht.
Ich hab dann damit 2 Dedicated Server unter Wine aufgesetzt. Die liefen auch, aber waren nicht wirklich spielbar.

Im Laufe der Zeit hatte ich dann 64Bit Hardware. Ich weiss nicht mehr wann das war, aber ab einer gewissen Debian Variante konnten man dann auch i386 Software integrieren, was ein CS Dedicated Server nun mal ist, Seit dem laufen sie spielbar mit Bots. Das NAS lief eigentlich immer auf Testing. Mittlerweile läuft auf Stable, sehr langweilig.

Die Maschinen auf denen ich arbeite laufen seit je her auf Testing. Anfang des Jahrtausends hab ich sogar CS Clienten unter Wine mit erheblichem Auffwand zum Laufen gebracht. Mittlerweile geht das ja auch ohne Aufwand.

Überwiegend surfe und moderiere ich noch, gelegentlich Onlinebanking, Office und E Mails