News Linux 6.0 erreicht End of Life: Anwender sollten jetzt auf Linux 6.1 (LTS) umsteigen

@SVΞN Kleiner Tippfehler in der Abschnitts-Überschrift:

AMD RNDA 3, PMF und Wi-Fi 7​

Ich hoffe, es soll RDNA heißen ;-).
 
undefined schrieb:
Ich nutze Gentoo zu Hause nun schon seit 20 Jahren. Mein aktueller Desktop-Rechner zu Hause ist 10 Jahre alt, mit einem i7-4930k und 32GB RAM. Da er schon seit dem Aufbau vollständig mit Wasser gekühlt ist, ist er auch unter Volllast sehr leise, was beim Kompilieren ganz angenehm ist. Dabei kann ich auch problemlos nebenher ein Spiel spielen oder sonst etwas machen, das kompilieren stört dabei nicht.
Mich würde das sehr stören, da ich es extrem ineffizient finden würde. Alleine schon, dass ich dann auch nicht rebooten kann. - Von den Stromkosten ganz zu schweigen.

Ich hatte 2004 einen schweren, unverschuldeten Verkehrsunfall und bin seit dem leicht behindert und arbeitslos: Aus finanziellen Gründen habe ich schon seit 2010 kein Breitband-Internet mehr, sondern nutze Mobilfunk (das meiste mache ich sowieso mit dem Handy, mit dem PC gehe ich nur selten online): Damals hatte ich zuerst nur 200 MiB/Mon., für 8,50€, inzwischen 5 GiB für 5,55€. - Für den normalen Gebrauch reicht mir das jetzt dicke, aber größere Downloads und Updates hebe ich mir weiterhin für Besuche bei Bekannten auf, um deren PCs ich mich kümmere: Dafür habe ich eine bootfähige 1:1 Kopie auf einer ext. SSD.

Deren PCs sind alles andere als aktuell: von 2,7 GHz AMD K9 bis 2,3 GHz Phenom (1) X4 (beide mit 4 GiB RAM): Wie lange würden LibreOffice, Opera, ein neuer Kernel und andere Schwergewichte dort kompilieren?

Die Gentoo-Features sind natürlich sehr interessant, aber so weit bin ich noch lange nicht: Ich habe auch so schon viele "Baustellen", die mich weit mehr interessieren (und mir auch viel mehr bringen), als dass ich mich auch noch damit beschäftigen will.
 
SVΞN schrieb:
Da stellt sich natürlich die Frage, auf welchen Kernel sollten Anwender setzen und welche Kernel werden überhaupt noch unterstützt?
Anwender sollten vor allem nicht ohne Grund mit irgendwelchen Kerneln herumspielen oder das Updaten des Kernels gar selbst übernehmen. Die häufigen neuen Kernel Releases selber zu kompilieren ist ein hoher Aufwand und nur die wenigsten können das besser als die Maintainer der Distribution.
Daher einfach immer den Kernel nutzen der von der Distribution gestellt und aktualisiert wird. Das können auch Kernel-Versionen sein die vom Upstream selbst nicht mehr gepflegt werden, in dem Fall kümmern sich die Maintainer um das Backporten von Fixes. Nur dass die Distribution noch unterstützt wird, darauf muss man achten.
 
  • Gefällt mir
Reaktionen: TechFunk, Caramon2 und SVΞN
Caramon2 schrieb:
Aber wenn man sich mit Linux beschäftigen und was lernen will, ist Solus IMHO die falsche Wahl.
Muss man bei Solus nicht zwangsläufig lernen, selbst alles zu kompilieren, wegen dem nicht so umfangreichem Repo? Oder habe ich das falsch in Erinnerung?
 
Imagine noch ein Android nutzen was mit 3.x läuft.

Warum sind die 4.er LTS eigentlich nicht zum Download hier?
 
SVΞN schrieb:
Der im Oktober 2022 erschienene Betriebssystemkernel Linux 6.0, der erstmals auch Intels Core-i-13000 (Test) und AMDs Ryzen 7000 (Test) unterstützt hat, hat offiziell sein Support-Ende erreicht und sollte deshalb umgehend durch das neueste Linux 6.1 (LTS) ersetzt werden, das noch über einen langen Zeitraum Updates erhalten wird.

Zur News: Linux 6.0 erreicht End of Life: Anwender sollten jetzt auf Linux 6.1 (LTS) umsteigen
Überschrift "AMD RNDA 3, PMF und Wi-Fi 7".
Ich glaube das sollte RDNA heißen oder irre ich grad?
 
  • Gefällt mir
Reaktionen: SVΞN
Fedora ist jetzt auch auf 6.1.5, hab gerade geupdated
 
  • Gefällt mir
Reaktionen: polyphase und or2k
daivdon schrieb:
Muss man bei Solus nicht zwangsläufig lernen, selbst alles zu kompilieren, wegen dem nicht so umfangreichem Repo?
Als ich mich Mitte 2020 näher mit Solus beschäftigt habe, hatte ich außer Xfce eigentlich nichts vermisst: Hätte es eine Xfce-Version gegeben, wäre die mein neues Produktivsystem geworden, nachdem sie LinuxMint nach der Version 18.3 (die habe ich deshalb bis Ende 2020 genutzt) für mich immer mehr disqualifizierte. *)

Mangels zRAM und dann auch mangels ntfs3, hätte ich Solus nicht lange genutzt und wäre spätestens dann bei Artix-Runit gelandet: Es war also gut, dass es keine Xfce-Version gab. ;)


*) Offenbar in Ubuntu begründet, weil ich das mit Zorin reproduzieren konnte und als ich mir neulich seit langen mal wieder angesehen habe, fingen beide schon bei der Installation an, irgendwelchen neuen Mist zu machen, dabei basieren Zorin 16.2 und LinuxMint 21.1 nicht mal auf der selben Ubuntu-LTS-Version.

Für mich hat Ubuntu inzwischen schon fast den selben Stellenwert wie Windows: Finger weg!

Einzig das Ubuntuuser-Wiki ist größtenteils sehr gut. Das von Arch ist aber noch besser: Z. B. bzgl. "chroot" habe ich im Ubuntuuser-Wiki nicht mal verstanden, wozu das überhaupt gut sein soll. Im Arch-Wiki wurde es mir dagegen sofort klar.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
undefined schrieb:
Ich kann mich absolut nicht beklagen, dass das kompilieren besonders lange dauern würde. Für eine Angabe wie "Lange" hat natürlich jeder eine andere Wahrnehmung. Größere Pakete wie Firefox oder LibreOffice dauern zwar auch bei mir (FF) 33 und (LO) 55 Minuten, aber das ist für mich vollkommen in Ordnung.
Das weiter oben war keine rhetorische Frage: Wie lange würde eine Aktualisierung auf so einer lahmen Kiste dauern?

Ich kenne kompilieren nur bei einigen Sachen aus dem AUR und selbst bei einem kleinen Tool wie 7zip dauert das auf meinem 4 GHz FX-8350 schätzungsweise ca. 2 Min.

Konkreter Fall:

Um Traffic zu sparen, aktualisiere ich gewöhnlich nur am letzten des Monats (auch um möglichst wenig Traffic verfallen zu lassen), wobei dann sehr vieles aktualisiert wird. Besonders die größeren Sachen: Kernel, LibreOffice, Opera und oft auch Gimp, Audacity, AVIdemux, usw.

Mit welcher Dauer einer kompletten Aktualisierung müsste ich auf einem 2,7 GHz Athlon 64 X2 mit 4 GiB DDR2-800 und einer 160 GB Samsung P80 SATA (max. 60 MB/s) ungefähr rechnen?

Das interessiert mich wirklich, um mal eine Vorstellung davon zu bekommen.

Mein System ist dabei zwar auf einer ext. SSD, aber da der PC nur USB2 hat, wird das vermutlich nicht viel schneller als mit der HD sein.

Als Tipp für dich (nicht für die 4 GiB Kiste):

Da Quellcode üblicherweise Text ist und sich damit gut komprimieren lässt, könnte bei größeren Sachen ggfs. eine zRAM-Disk nützlich sein:

https://www.computerbase.de/forum/threads/zswap-vs-zram-vs-zram-disk.2107871/

Mit lz4 ist auch die noch sehr schnell.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
@Caramon2
Ich hatte mal vor ca. 15 Jahren ein ähnliches System wie Du und habe darauf Gentoo laufen lassen.
Wenn ich mich recht erinnere hat das schon mehrere Stunden gedauert, bis ein großes Update durchkompiliert war.
Vielleicht hast Du ja noch einen anderen modernen Rechner, den Du mit "distcc" einbinden kannst.
(ich würde es vielleicht sogar der Toolchain-Kompatibilität wegen komplett dort kompilieren)
Ach ja, Du darfst bei distcc dann natürlich kein
Code:
-march=native
nehmen.
 
Caramon2 schrieb:
Mit welcher Dauer einer kompletten Aktualisierung müsste ich auf einem 2,7 GHz Athlon 64 X2 mit 4 GiB DDR2-800 und einer 160 GB Samsung P80 SATA (max. 60 MB/s) ungefähr rechnen?
Wie soll man das denn beantworten? Das hängt doch individuell von der Software ab, die bei dir zu diesem Zeitpunkt zur Aktualisierung ansteht. Das muss dir doch klar sein, dass das hier niemand wissen kann.

Das ist in etwa so, als würdest du jemanden Fragen, wie lange du brauchst, alles zu besorgen, was auf deiner Einkaufsliste steht, ohne dass die Person, die du fragst, den Zettel je gesehen hat und sich dessen Inhalt jedes Mal verändert.
 
Y-Chromosome schrieb:
Ich hatte mal vor ca. 15 Jahren ein ähnliches System wie Du und habe darauf Gentoo laufen lassen.
Wenn ich mich recht erinnere hat das schon mehrere Stunden gedauert, bis ein großes Update durchkompiliert war.
Danke. :)

So ähnlich hatte ich mir das vorgestellt: Also nichts für meinen Anwendungsfall.

Ich fand schon "apt" rel. lahm (ganz zu schweigen von "eopkt" bei Solus). "pacman" war eine gravierende Verbesserung.

Y-Chromosome schrieb:
Vielleicht hast Du ja noch einen anderen modernen Rechner, den Du mit "distcc" einbinden kannst.
Das ist nicht mein Rechner, sondern der eines Nachbarn, um den ich mich gelegentlich kümmere und dann auch mein System boote und aktualisieren, um den Traffic zu sparen. - Das hatte ich weiter oben genauer beschrieben.

Mein PC hat einen FX-8350 "Black Edition": Als Amazon den 2018 "Boxed" für 76€ verramscht hat (und ich ein passendes Board hatte), konnte ich nicht widerstehen. ;)

Grimba schrieb:
Wie soll man das denn beantworten? Das hängt doch individuell von der Software ab, die bei dir zu diesem Zeitpunkt zur Aktualisierung ansteht. Das muss dir doch klar sein, dass das hier niemand wissen kann.
1. Wenn man nur monatlich aktualisiert, gibt es dabei keine große Fluktuation.

2. Reichte mir ein grober Richtwert.

Grimba schrieb:
Das ist in etwa so, als würdest du jemanden Fragen, wie lange du brauchst, alles zu besorgen, was auf deiner Einkaufsliste steht, ohne dass die Person, die du fragst, den Zettel je gesehen hat und sich dessen Inhalt jedes Mal verändert.
Ich kaufe alle 2-3 Wochen ein, so dass es auch dabei keine große Fluktuation gibt. Je nachdem wie voll es ist, bin ich 20-30 Min. im Supermarkt.
 
Caramon2 schrieb:
Wenn man nur monatlich aktualisiert, gibt es dabei keine große Fluktuation.
Blödsinn. Es macht sehr wohl einen riesen Unterschied, gerade wenn alles kompiliert werden muss, ob nicht zufällig ein großes Softwarepaket, wie z.B. KDE oder Gnome oder auch alles, wo WebKit mit kompiliert werden muss, zur Aktualisierung ansteht oder nicht, weil ein neues Release raus ist. Oder ein neuer Kernel. Und nicht nur diese Pakete stehen dann ggf. zur Neukompilierung an, sondern ggf. auch daran anhängende Abhängigkeiten. Das richtet sich in keinster Weise nach deiner monatlichen Routine. Daraus kannst du dann für dich auch keine Regel ableiten. Das ist rein individuell, wie lange das dauert, und zwar für den jeweiligen Zeitpunkt, je nachdem, was du installiert hast, und je nachdem, was du nicht gesperrt hast. Es interessiert übrigens niemanden, wie oft du einkaufst.
 
Zuletzt bearbeitet:
Alexander2 schrieb:
Wow, der 5.10 reicht am Längsten, könnte mir vorstellen das Debian stable da grad drauf läuft.
Richtig. Aber hier läuft auf Debian 11.6 der 32bit Kernel
5.15.88. Eine Sekunde schneller als der 5.10. [IMG]https://www.computerbase.de/forum/styles/smilies/wink.gif[/IMG]
 
Caramon2 schrieb:
Mit welcher Dauer einer kompletten Aktualisierung müsste ich auf einem 2,7 GHz Athlon 64 X2 mit 4 GiB DDR2-800 und einer 160 GB Samsung P80 SATA (max. 60 MB/s) ungefähr rechnen?
Normalerweise weniger als eine Stunde wobei der Download nicht dabei ist da dies davon abhängt wie schnell die Verbindung ist.
 
  • Gefällt mir
Reaktionen: aklaa und Caramon2
@ModellbahnerTT mit der Zeitangabe bei der Hardware kannst du ja nur von nicht Source Paketen ausgehen? aber da geht es um die kompilierung aller Pakete. Gentoo ...
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Caramon2
undefined schrieb:
Ich nutze Gentoo zu Hause nun schon seit 20 Jahren. Mein aktueller Desktop-Rechner zu Hause ist 10 Jahre alt, mit einem i7-4930k und 32GB RAM. Da er schon seit dem Aufbau vollständig mit Wasser gekühlt ist, ist er auch unter Volllast sehr leise, was beim Kompilieren ganz angenehm ist.
Dito, ich habe 2006 mit Gentoo angefangen – war mein erstes Linux überhaupt. Erst mit Laptops: Pentium M Centrino, später Core2Duo, dann ein PC mit i5-4590 und Thinkpad mit i5-5200U. Zwischendurch auch mal Netbooks(!) mit Atom N450 und eines mit Celeron 847.

undefined schrieb:
Ich kann mich absolut nicht beklagen, dass das kompilieren besonders lange dauern würde. Für eine Angabe wie "Lange" hat natürlich jeder eine andere Wahrnehmung. Größere Pakete wie Firefox oder LibreOffice dauern zwar auch bei mir (FF) 33 und (LO) 55 Minuten, aber das ist für mich vollkommen in Ordnung. So oft kommen solche großen Updates nicht vor.
Hier muss ich sagen, dass ich bei großen Paketen (Firefox, Libreoffice & Co) stets die Binärversion genommen habe. Mit Optimierungen ist da nicht viel rauszuholen und use-Flags bringen da oft auch nicht viel.

undefined schrieb:
Der Kernel wird dabei über die SATA-SSD kompiliert. Alle anderen Pakete werden in einer Ramdisk (tmpfs) kompiliert, um hier nicht unnötig Schreibzyklen auf der SSD zu verschwenden. Die SSD (Samsung 840 EVO) hält aber auch schon 10 Jahre durch.
Auch zu Festplattenzeiten habe ich Ramdisks dazu verwendet, weil einfach schneller (und der Platz oft so eng war). Damals haben auch 2 GiB RAM für das meiste gereicht.

Caramon2 schrieb:
Deren PCs sind alles andere als aktuell: von 2,7 GHz AMD K9 bis 2,3 GHz Phenom (1) X4 (beide mit 4 GiB RAM): Wie lange würden LibreOffice, Opera, ein neuer Kernel und andere Schwergewichte dort kompilieren?
Ich habe aus Spaß und Neugier mal auf dem N450 Firefox kompiliert. Das hat knapp 24 Stunden gedauert. An der Startzeit von 20 Sekunden hat es auch nichts geändert.

Caramon2 schrieb:
Das weiter oben war keine rhetorische Frage: Wie lange würde eine Aktualisierung auf so einer lahmen Kiste dauern?
WIMRE (ist lange her) hat auf meinem i5-5200U QtWebEngine, also praktisch die Chrome-Engine, um die zwei Stunden gedauert (oder war das doch auf dem i5-4590?). Das war einer der Hauptgründe, warum ich letztlich von Gentoo auf Arch gewechselt bin. Ich hatte irgendwann keinen Bock mehr, weil die Updates immer häufiger wurden. Außerdem wurde mir Portage (die Paketverwaltung) immer fetter. Hunderttausende Dateien, die fast 1 GB beanspruchen, dazu die immer länger werdende Abhängigkeitsberechnungen… Nur auf dem NAS habe ich jetzt noch Gentoo laufen, dort ist es relativ schlank. Dessen Kernel kommt direkt von kernel.org, muss aber aktuell noch auf 5.19 bleiben wegen ZFS.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Caramon2
Zurück
Oben