Oje nun heißt es wieder umbauen...Da hat man es mal gut eingerichtet und dann kommt schon wieder ne neue Version. Ich wäre für eine 10 Jahre Lts. So wie bei einer gewissen rpm Distro.
Du hast noch mindestens bis 2020 Security Updates.
Wenn dir 10 Jahre Support wichtig sind, nimm doch RHEL, aber erwarte das nicht einfach so von einem vollständig Community basierten Projekt. 10 Jahre Support zieht halt ohne Ende Manpower und das ergibt nirgendwo sonst Sinn als in Unternehmen.
CentOS macht virtualisiert Probleme mit Performance, Guest-Module, crashed bzw. Freezed. RHEL & Fedora laufen higegen prima! In der gleichen Umgebung, und auf der gleichen Hardware. Einfach nur merkwürdig!
absolut nicht nachvollziehbar was du schreibst CentOS ist genau so stabil wir RHEL, updates kommen halt einige Stunden (security) oder Tage (feature/versions) später, doch ansonst ist es doch das selbe wie Red Hat, oder meinst du das entfernen von Red Hat logos und anderen Trademark Texten beeinflusst die Stabilität?
Komm vorbei! Schaue es dir an! Ich habe es noch nicht weiter analysiert, was hier schiefläuft. Der Effekt tritt über mehrere Virtual-Environments (Vmware, Virtualbox, KVM), mit unterschiedlichen CentOS-7-Versionen, auch die ISOs-Checksummen habe ich bereits gecheckt. Passt, aber es läuft einfach nicht sauber. Alle anderen VMs laufen anstandslos! Nur CentOS zickt. Warum auch immer!
Was fuer ein bullshit...einfach mal etwas schreiben. Was läuft nicht sauber? Und nein ich komme nicht vorbei, das ist der Vorteil an Internet...schick Screenshots.
Ja du kannst auch kernel-dumps schicken, einfach labern und was behaupten. Was fuer Probleme mit "Guest-Module" was crashed und was freezed? Und wieso hast Du Guestmodule bei KVM? Und ja screenshots wuerden beweisen dass die performance vergleichsweise schlechter ist (tip: benchmark)
Kannst du bitte genauer werden, was nicht läuft? Es will dir keiner deine Erfahrungen absprechen, einige (wie ich z.B.) wollen nur nachvollziehen können, wo genau das Problem liegt. Es ist halt tatsächlich schwer nachvollziehbar, da CentOS nunmal binärkompatibel zu RHEL ist...
Sie nutzen MX Linux? Gibt es da Probleme beim upgraden? Ich hoffe nicht. Alles läuft super und ich nutzte bereits den Debian 4.19.37-2~mx17+1 (2019-05-15) Kernel.
Aber vermutlich nicht genau in der Form wie zur Veröffentlichung von Debian 10 Buster am 6. Juli, insbesondere aber mit all' den tollen Fehlern, die noch nicht behoben worden sind und bis zum Veröffentlichungstermin behoben werden.
Bis dahin fließen noch Änderungen ein. Und erst ab Veröffentlichung kümmert sich das Security Team aktiv um zeitnahe Sicherheitsaktualisierungen; für den testing-Zweig ist da typischerweise langes Warten angesagt.
Genaugenommen kann niemand etwas (Debian 10 Buster) verwenden ("betreiben"), das nicht existiert, weil es z.B. noch nicht erschienen ist - wie in diesem Fall. Debian 10 Buster betreiben Sie gewiss nicht. Also was genau betreiben Sie seit Ende 2018? Den Entwicklungszweig Debian testing?
Allein den Entwicklungszweig schon vor Veröffentlichung einzusetzen (Debian testing ist per Definition immer vor der Veröffentlichung), ist zunächst kein großes Kunststück. Setzen Sie es produktiv ein? Welchen Einsatzzweck erfüllt es? Was/Wie testen Sie? Wer ist "wir"?
Aber vermutlich nicht genau in der Form wie zur Veröffentlichung von Debian 10 Buster am 6. Juli, ...
Nun, das ganz sicher nicht.
Genaugenommen kann niemand etwas (Debian 10 Buster) verwenden ("betreiben"), das nicht existiert, weil es z.B. noch nicht erschienen ist - wie in diesem Fall. Debian 10 Buster betreiben Sie gewiss nicht.
Nun ja, mein Test(ing)system zeigt mir bspw. als Desktophintergrund den Swirl mit Debian 10 Beschriftung an.
Ich verwende also auch Debian 10 (Buster). Nur eben (noch) nicht als Stable-Release.
Irgendwann vor einer Veröffentlichung muss ein System entwickelt werden. Das ist testing. Es wundert daher nicht, dass in den Entwicklungszweig ab einem gewissen Datum Anpassungen zu Version, Namen und Branding vorkehrend eingepflegt wurden. Es ändert aber nichts an der Tatsache, dass es nur ein Entwicklungsstand von Debian 10 Buster ist.
Wie dem auch sei; ich wollte eigentlich keine Haarspalterei betreiben. Wenn man diesen Entwicklungsstand Debian 10 Buster (o.Ä.) bezeichnen mag, sei es drum. Ursprünglich wollte ich dem passiv-aggressiven Subtext in Tuxedos Kommentar entgegnen. Dieser suggeriert, dass Tuxedo etwas außerordentliches geleistet hätte, obwohl nicht genau zu erkennen ist, worum es sich dabei handelt (daher meine Fragen an Tuxedo, s.o.), und sich nun dafür rühmt. So zeichnet sich ein Bild der unbegründeten Überheblichkeit. Das kann ich nicht so stehen lassen.
Wir betreiben das auch schon seit ende letzten Jahres, jedoch auch mit allen Nachteilen. Es gab z.B. bei einem Apache2 Security Fix erst knapp einen Monat nach Release für Stretch das Update für Buster. Das war sehr ärgerlich, weil wir halt Apache einsetzen ...
So ein Vorab Release ist für produktive Umgebungen daher nur bedingt geeignet
Von kamome umidori am Mi, 12. Juni 2019 um 15:36 #
Das hat doch wohl nichts mit „nicht bis ins letzte Detail vorkonfiguriert“ zu tun – ein „letter“ bei DE-Locale ist schlicht ein Fehler, auch bei Debian! (Bei mir ist es „a4“, die Installation ist aber auch schon lange her, könnte sogar ein Upgrade gewesen sein.)
Netinstall mit Daily build vom gleichen Tag. Wenige Minuten vor der Installation gezogen. Nicht darauf geachtet, wie sich das zu dem Zeitpunkt schimpfte.
Ich habe gerade eben eine Minimalinstallation ohne Desktop mit dem netinst Image http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware /daily-builds/sid_d-i/20190612-5/amd64/iso-cd/[ in Virtualbox durchgeführt mit Auswahl Germany, deutsch, deutsche Tastatur und bekomme bei /etc/papersize weiterhin "letter".
Erst durch sudo dpkg-reconfigure libpaper1 und dort dann Auswahl A4 bekomme ich das DIN-Format.
Guck gleich noch nach, ob auch die locale Pakete für KDE und Firefox-ESR installiert werden. Die habe bei meinem letzten Test von Debian testing (Buster) auch noch gefehlt und mussten manuell nachinstalliert werden.
Die Loginbildschirm blieb allerdings bei der US Einstellung. Sehr ärgerlich das ganze, so etwas sollte out of the Box funktionieren, wenn man schon eine andere Sprache als Englisch ausgewählt hat.
Das das Papier auf A4 eingestellt sein sollte, da gebe ich dir natürlich auch vollkommen recht.
Ja, mit rustc 1.32 - vermutlich so lange sinnvoll nutzbar, bis rustc 1.37 mit async/await erscheint, und sich das crates.io Ökosystem in diese Richtung bewegt, dann muss man wieder verschiedene crates in älteren Versionen verwenden, was schnell ziemlich hässlich werden kann.
Ich installiere übrigens in meinem Home-Verzeichnis mit rustup den stable und den nightly compiler. Dazu richte ich mir entsprechend https://github.com/rust-lang/rustup.rs#working-with-distribution-rust-packages den Compiler von Debian als Standard ein. Damit kann ich dann aber auch z.B. rustfmt und clippy von rustup verwenden, was ganz praktisch ist.
Und mit Debian 11 Bullseye ist das dann hoffentlich auch alles direkt in Debian verfügbar. Auch so eine signifikante Änderung wie async/await wird danach hoffentlich nicht mehr allzu schnell folgen. Aber bis dahin dauert es vermutlich noch ca. 2 bis 2,5 Jahre.
Das ist kein Problem, das wird erst in einer Rust 2018+Next Edition relevant.
So hatte ich mir das auch mal gedacht. Aber leider nein, die jeweils letzte Edition "lebt", wird also aktiv um Features erweitert. Voraussetzung ist, dass die Keywords in der vorherigen Edition bereits reserviert waren, was auf async und await zutrifft. Siehe z.B. Changelog von rustc 1.33:
You can now have multiple patterns in if let and while let expressions.
if let Creature::Crab(name) | Creature::Person(name) = state {…}
Dieses Feature wurde in 1.33 stabil veröffentlicht, und neu geschriebener Code, der es verwendet, baut nicht mit älteren Compilerversionen, obwohl bereits rustc 1.31 die 2018 Edition unterstützt.
Von Manfred Tremmel am So, 7. Juli 2019 um 13:07 #
Ich hab Buster (Testing) jetzt seit ein paar Wochen am laufen und heute beim Update kam von apt dann die Meldung:
E: Für das Depot »http://deb.debian.org/debian buster InRelease« wurde der »Suite«-Wert von »testing« in »stable« geändert. N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie weitere Informationen benötigen. Möchten Sie diese Änderungen übernehmen und mit der Aktualisierung von diesem Depot fortfahren? [j/N] J
Also Buster ist das neue stable! Der Rest ist wohl nur noch eine Frage der Zeit. Ich vermute mal Debian wartet noch ab bis die Mirrors alle die Änderungen drüben haben
Oje nun heißt es wieder umbauen...Da hat man
es mal gut eingerichtet und dann kommt schon wieder ne neue Version. Ich wäre für eine 10
Jahre Lts. So wie bei einer gewissen rpm Distro.
Du hast noch mindestens bis 2020 Security Updates.
Wenn dir 10 Jahre Support wichtig sind, nimm doch RHEL, aber erwarte das nicht einfach so von einem vollständig Community basierten Projekt. 10 Jahre Support zieht halt ohne Ende Manpower und das ergibt nirgendwo sonst Sinn als in Unternehmen.
...oder CentOS, ein Community-Projekt, das RHEL nachbaut.
Wobei es Unterschiede zu geben scheint!
CentOS macht virtualisiert Probleme mit Performance, Guest-Module, crashed bzw. Freezed.
RHEL & Fedora laufen higegen prima! In der gleichen Umgebung, und auf der gleichen Hardware.
Einfach nur merkwürdig!
Ich kann dein Problem nicht nachvollziehen, läuft bei mir reibungslos.
Hat dich auch keiner danach gefragt. Ich habe lediglich festgestellt, das anscheinend doch Unterschiede gibt!
absolut nicht nachvollziehbar was du schreibst
CentOS ist genau so stabil wir RHEL, updates kommen halt einige Stunden (security) oder Tage (feature/versions) später, doch ansonst ist es doch das selbe wie Red Hat, oder meinst du das entfernen von Red Hat logos und anderen Trademark Texten beeinflusst die Stabilität?
Komm vorbei! Schaue es dir an! Ich habe es noch nicht weiter analysiert, was hier schiefläuft.
Der Effekt tritt über mehrere Virtual-Environments (Vmware, Virtualbox, KVM), mit unterschiedlichen CentOS-7-Versionen, auch die ISOs-Checksummen habe ich bereits gecheckt. Passt, aber es läuft einfach nicht sauber. Alle anderen VMs laufen anstandslos! Nur CentOS zickt. Warum auch immer!
Was fuer ein bullshit...einfach mal etwas schreiben.
Was läuft nicht sauber? Und nein ich komme nicht vorbei, das ist der Vorteil an Internet...schick Screenshots.
LOL! Das kommt vom richtigen!
Wer lesen kann ist ganz klar im Vorteil:
Klar, ich schicke dir einen Screenshot davon! Macht in dem Fall voll den Sinn!
Ja du kannst auch kernel-dumps schicken, einfach labern und was behaupten.
Was fuer Probleme mit "Guest-Module" was crashed und was freezed? Und wieso hast Du Guestmodule bei KVM?
Und ja screenshots wuerden beweisen dass die performance vergleichsweise schlechter ist (tip: benchmark)
Völliger Unsinn!
CentOS ist binärkompatibel und unterscheidet sich nur bei den Logos und trademarks
Kannst du bitte genauer werden, was nicht läuft? Es will dir keiner deine Erfahrungen absprechen, einige (wie ich z.B.) wollen nur nachvollziehen können, wo genau das Problem liegt. Es ist halt tatsächlich schwer nachvollziehbar, da CentOS nunmal binärkompatibel zu RHEL ist...
Dat is nicht nur echt billig, dat is kostnlos!
Sie nutzen MX Linux? Gibt es da Probleme beim upgraden? Ich hoffe nicht. Alles läuft super und ich nutzte bereits den Debian 4.19.37-2~mx17+1 (2019-05-15) Kernel.
Ist doch kein Aufwand! Du verwendest ja schliesslich Linux, und kein Windows!
Was gibt es wegen etwas trivialem wie einem dist-upgrade großartig umzubauen? Habe gehört dass das auch unter Debian funktioniert
Ähm - wir betreiben das schon seit Ende 2018!
Aber vermutlich nicht genau in der Form wie zur Veröffentlichung von Debian 10 Buster am 6. Juli, insbesondere aber mit all' den tollen Fehlern, die noch nicht behoben worden sind und bis zum Veröffentlichungstermin behoben werden.
Bis dahin fließen noch Änderungen ein. Und erst ab Veröffentlichung kümmert sich das Security Team aktiv um zeitnahe Sicherheitsaktualisierungen; für den testing-Zweig ist da typischerweise langes Warten angesagt.
Genaugenommen kann niemand etwas (Debian 10 Buster) verwenden ("betreiben"), das nicht existiert, weil es z.B. noch nicht erschienen ist - wie in diesem Fall.
Debian 10 Buster betreiben Sie gewiss nicht. Also was genau betreiben Sie seit Ende 2018? Den Entwicklungszweig Debian testing?
Allein den Entwicklungszweig schon vor Veröffentlichung einzusetzen (Debian testing ist per Definition immer vor der Veröffentlichung), ist zunächst kein großes Kunststück.
Setzen Sie es produktiv ein? Welchen Einsatzzweck erfüllt es? Was/Wie testen Sie? Wer ist "wir"?
Nun, das ganz sicher nicht.
Nun ja, mein Test(ing)system zeigt mir bspw. als Desktophintergrund den Swirl mit Debian 10 Beschriftung an.
Ich verwende also auch Debian 10 (Buster). Nur eben (noch) nicht als Stable-Release.
Irgendwann vor einer Veröffentlichung muss ein System entwickelt werden. Das ist testing. Es wundert daher nicht, dass in den Entwicklungszweig ab einem gewissen Datum Anpassungen zu Version, Namen und Branding vorkehrend eingepflegt wurden. Es ändert aber nichts an der Tatsache, dass es nur ein Entwicklungsstand von Debian 10 Buster ist.
Wie dem auch sei; ich wollte eigentlich keine Haarspalterei betreiben. Wenn man diesen Entwicklungsstand Debian 10 Buster (o.Ä.) bezeichnen mag, sei es drum.
Ursprünglich wollte ich dem passiv-aggressiven Subtext in Tuxedos Kommentar entgegnen. Dieser suggeriert, dass Tuxedo etwas außerordentliches geleistet hätte, obwohl nicht genau zu erkennen ist, worum es sich dabei handelt (daher meine Fragen an Tuxedo, s.o.), und sich nun dafür rühmt. So zeichnet sich ein Bild der unbegründeten Überheblichkeit. Das kann ich nicht so stehen lassen.
Wir betreiben das auch schon seit ende letzten Jahres, jedoch auch mit allen Nachteilen. Es gab z.B. bei einem Apache2 Security Fix erst knapp einen Monat nach Release für Stretch das Update für Buster. Das war sehr ärgerlich, weil wir halt Apache einsetzen ...
So ein Vorab Release ist für produktive Umgebungen daher nur bedingt geeignet
Busters zweiter Name ist ja im Moment immer noch "testing" und nicht "stable"
Bin ich eigentlich der Einzige, der bei Neuinstallationen von Buster trotz deutscher Locale Letter statt A4 als Standard eingerichtet bekommt?
Klar kann ich /etc/papersize von Hand korrigieren, aber von "It just Works" doch weit entfernt.
Bei meinem Devuan steht a4 drin
Von Devuan gibt es auch bereits einen RC von Buster/10?
Stretch hat das Problem ja auch nicht gehabt.
es geht hier um Debian!
für ootb gibt es gewisse Nachkommen
Das hat doch wohl nichts mit „nicht bis ins letzte Detail vorkonfiguriert“ zu tun – ein „letter“ bei DE-Locale ist schlicht ein Fehler, auch bei Debian! (Bei mir ist es „a4“, die Installation ist aber auch schon lange her, könnte sogar ein Upgrade gewesen sein.)
Ubuntu 19.04 (neuinstalliert) hat übrigens dasselbe Problem.
Installation 23.05.19
A4
Mit dem RC1 von Buster?
Netinstall mit Daily build vom gleichen Tag. Wenige Minuten vor der Installation gezogen. Nicht darauf geachtet, wie sich das zu dem Zeitpunkt schimpfte.
Ich habe gerade eben eine Minimalinstallation ohne Desktop mit dem netinst Image http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware /daily-builds/sid_d-i/20190612-5/amd64/iso-cd/[ in Virtualbox durchgeführt mit Auswahl Germany, deutsch, deutsche Tastatur und bekomme bei /etc/papersize weiterhin "letter".
Erst durch sudo dpkg-reconfigure libpaper1 und dort dann Auswahl A4 bekomme ich das DIN-Format.
Ja, dann schreib halt einen Bugreport
Es gibt bereits einen Fehlerbericht.
Guck gleich noch nach, ob auch die locale Pakete für KDE und Firefox-ESR installiert werden.
Die habe bei meinem letzten Test von Debian testing (Buster) auch noch gefehlt und mussten manuell nachinstalliert werden.
Die Loginbildschirm blieb allerdings bei der US Einstellung.
Sehr ärgerlich das ganze, so etwas sollte out of the Box funktionieren, wenn man schon eine andere Sprache als Englisch ausgewählt hat.
Das das Papier auf A4 eingestellt sein sollte, da gebe ich dir natürlich auch vollkommen recht.
$ cat /etc/papersize
# Simply write the paper name. See papersize(5) for possible values
Es gibt bereits einen Fehlerbericht.
und das fest als offizielles Paket.
Ich freue mich schon auf Buster.
Ja, mit rustc 1.32 - vermutlich so lange sinnvoll nutzbar, bis rustc 1.37 mit
async/awaiterscheint, und sich das crates.io Ökosystem in diese Richtung bewegt, dann muss man wieder verschiedene crates in älteren Versionen verwenden, was schnell ziemlich hässlich werden kann.Ich installiere übrigens in meinem Home-Verzeichnis mit
rustupden stable und den nightly compiler. Dazu richte ich mir entsprechend https://github.com/rust-lang/rustup.rs#working-with-distribution-rust-packages den Compiler von Debian als Standard ein. Damit kann ich dann aber auch z.B. rustfmt und clippy von rustup verwenden, was ganz praktisch ist.Und mit Debian 11 Bullseye ist das dann hoffentlich auch alles direkt in Debian verfügbar. Auch so eine signifikante Änderung wie async/await wird danach hoffentlich nicht mehr allzu schnell folgen. Aber bis dahin dauert es vermutlich noch ca. 2 bis 2,5 Jahre.
Das ist kein Problem, das wird erst in einer Rust 2018+Next Edition relevant. Also eventuell Rust 2020 oder später.
Siehe dazu:
Edition Guide
asyncundawaitzutrifft. Siehe z.B. Changelog vonrustc1.33: Dieses Feature wurde in 1.33 stabil veröffentlicht, und neu geschriebener Code, der es verwendet, baut nicht mit älteren Compilerversionen, obwohl bereitsrustc1.31 die 2018 Edition unterstützt.Siehe dazu auch die Kommentare zu diesem Beitrag auf Reddit.
Ach so, hm, das ist schade. Dann habe ich das mit den Editions falsch verstanden.
Dann hast du recht, dann müssen wir auf Backports hoffen.
Ich hab Buster (Testing) jetzt seit ein paar Wochen am laufen und heute beim Update kam von apt dann die Meldung:
E: Für das Depot »http://deb.debian.org/debian buster InRelease« wurde der »Suite«-Wert von »testing« in »stable« geändert.N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie weitere Informationen benötigen.
Möchten Sie diese Änderungen übernehmen und mit der Aktualisierung von diesem Depot fortfahren? [j/N] J
Also Buster ist das neue stable! Der Rest ist wohl nur noch eine Frage der Zeit. Ich vermute mal Debian wartet noch ab bis die Mirrors alle die Änderungen drüben haben