UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
Berlin_1946 schrieb: "MEDION AKOYA® E4241, Notebook mit 14.0 Zoll Display, Atom® Prozessor, 4 GB RAM, 64 GB Flash, Intel® HD-Grafik, Dark silver " mit einer Platte < 1TB. Ob der jetzt auch Ubuntu kann ???
Klar, warum sollte das nicht gehen. Ich hatte mal einen ASUS hier mit 1 TB Platte und 32 GB internem Flash. Davon nutzte Windoof knapp 20 GB. Also habe ich die Windoof-Partition auf 22 GB verkleinert, die restlichen 10 GB konnte ich dann für Ubuntu nutzen. Dabei habe ich in /home/user die Ordner .thunderbird, .mozilla/firefox, Dokumente, Musik etc. per symlink auf die Windoof-Datenpartition auf der 1-TB-HD umgeleitet, um genug Platz für Daten zu haben, und eine gemeinsame Nutzung mit Windoof zu ermöglichen. Startet super schnell das System, sowohl mit Ubuntu als auch mit Windoof. hakel schrieb: Muß man 32bit eigentlich noch berücksichtigen?
Warum nicht, schließlich ist es oft der einzige Weg, Ubuntu auf schwachbrüstigen Rechnern flüssig zum Laufen zu kriegen, und das sogar mit GNOME oder Unity, wenn man auf solche modernen Oberflächen Wert legt.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
hakel schrieb: Muß man 32bit eigentlich noch berücksichtigen?
Es gibt kein offizielles Derivat, dass sich nach Canonicals Abwendung dafür ausgesprochen hat, die 32-bit Unterstützung aufrecht zu erhalten - selbst Xubuntu und Lubuntu haben die 32-bit Unterstützung in der aktuellen Version offiziell eingestellt. Mehr gibt es dazu nicht mehr zu sagen.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53484
Wohnort: Berlin
|
Berlin_1946 schrieb: Ob der jetzt auch Ubuntu kann ???
Naja, Medion ist da immer ein wackliger Kandidat. Mit einer Atom x5-Z8350-CPU (erschien erst 2016) und 4GB RAM als Schreibmaschine und zum Surfen sicherlich brauchbar.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Wieso wackliger Kandidat?
Sofern die IGP nicht zu langsam ist und genug RAM da ist kein Problem, das geht selbst mit nem Pentium 4.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53484
Wohnort: Berlin
|
DJKUhpisse schrieb: Wieso wackliger Kandidat?
Sofern die IGP nicht zu langsam ist und genug RAM da ist kein Problem, das geht selbst mit nem Pentium 4.
Mir geht es nicht um die Hardware an sich, Medion hat oft sehr seltsame UEFI-Implementationen.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
Auf Wunsch von tomtomtom äußere ich mich dazu nun doch mal. Letalis_Sonus schrieb: UlfZibis schrieb: 64-Bit braucht je nach Anwendung bis zu 40 % mehr RAM (z.B. Firefox)
Vorsicht: Der RAM Verbrauch ist bei Firefox seit längerem von der Anzahl der Kerne abhängig,
Ich hab' keinen einzigen Kern ausgebaut, als ich das 32-Bit-Ubuntu installiert habe. Also für beide Test stand dieselbe Hardware und damit auch dieselbe Anzahl von Kernen zur Verfügung. mal abgesehen davon, ob die billige Atom-CPU überhaupt mehrere Kerne hat.
da die Anzahl der verwendeten Web Content Threads einen massiven Einfluss auf den RAM Verbrauch hat. Wer diese nicht von Hand stark beschränkt hat bei einer entsprechend großzügig ausgestatteten CPU Ruckzuck einen massiven RAM Verbrauch. Wenn man das ganze von Hand auf nur 1-2 Threads beschränkt bleibt der RAM Bedarf auch bei fetten 64-bit CPUs im Keller. Inwiefern Firefox bei solchen "automatisch" gehandhabten Einstellungen sein Verhalten von der benutzen Architektur abhängig macht ist noch einmal ein anderes Thema, gut möglich dass er in der 64-bit Version allgemein eher mehr Threads startet als in der 32-bit Version - letztendlich konfiguriert man mit der änderbaren Einstellung nur das Maximum und nicht die Zahl der wirklich genutzten Threads.
Nun, meine Tests erfolgten mit jeweils standardmäßig konfiguriertem Firefox. Das ist doch erst mal die Basis, von der man ausgehen sollte. Ob manuelles Umkonfigurieren des 64-Bit-Firefox was bringt, habe ich nicht ausprobiert, bezweifle aber sehr die Wirkung, denn warum sollte FF mehr Web Content Threads starten, als dafür Platz im RAM ist. Wie schon im anderen Thread beschrieben, brauchte das reine fertig geladene 64-Bit-Ubuntu ca. 100 MB mehr RAM als das 32-Bitter, was den dann noch zur Verfügung stehenden Platz für Firefox schon deshalb beschränkte.
Unter Ausblendung solcher Seiteneffekte ist der Mehrverbrauch von 64-bit Software eher vernachlässigbar, da die größere Busbreite ausschließlich zum Speichern von Speicheradressen durchgängig genutzt wird, um den Mehrverbrauch minimal zu halten
Verstehe ich nicht. Das durchgängige Nutzen der größeren Busbreite, also 64 Bit, soll den Mehrverbrauch minimal halten?
- eine 64-bit große Variable bringt auch nur dann einen Vorteil, wenn du den größeren Wertebereich auch konkret für etwas gebrauchen kannst. Linux nutzt LP64 und Windows LLP64 als Datenmodell, dadurch nutzt die Software weiterhin 32-bit große Variablen wenn sie nicht explizit im Source Code Datentypen fester Größe benutzt.
Ja sicher, für "normale" Integer-Variablen werden in beiden Fällen 32 Bit genutzt, nicht aber für Zeiger auf Speicheradressen, da müssen im 64-Bit-Programm 64 Bit genutzt werden, und davon macht Firefox offensichtlich reichlich Gebrauch, anders kann ich mir den höheren RAM-Verbrauch des 64-Bit-Firefox nicht erklären.
UlfZibis schrieb: Auf Systemen mit wenig Speicher ist ein 32-Bit-System schneller, ab ca. 3 GB RAM wird das 64-BitSystem schneller.
Die Speichermenge hat nur dann einen Einfluss auf die Geschwindigkeit, wenn das System dazu gezwungen wird zu Swappen - und wenn der Punkt erreicht ist, ist ohnehin Hopfen und Malz verloren.
Ganz genau! Und weil sowohl das 64-Bit-OS als auch der 64-Bit-Firefox bei gleicher Anzahl geladener Tabs mehr RAM brauchen ist diese Grenze bei nur 2 GiB RAM schneller erreicht, wie meine Tests eindeutig zeigen.
Davon abgesehen hat dies höchstens einen Einfluss auf den Datenträgerzugriff da der freie Speicher als Cache für eben jene Verwendung findet, was in Zeiten von SSDs aber auch an Bedeutung verloren hat.
Der Datei-Cache musste im 64-Bit-System aber erheblich kleiner ausfallen, da OS und Firefox weniger freien Speicher übrig ließen. Im Extremtest mit dem Umladen von 70 auf 210 Tabs ging die Cachegröße sogar ganz auf Null runter. Und da hier keine SSD im Einsatz war führte das dann zum Kollaps des 64-Bit-Systems, was bei 32-Bit nicht passierte.
Die 64-bit Architektur ist nicht deshalb schneller weil man mehr Speicher auf sie werfen kann, sondern weil sie Altlasten entfernt, effizientere Instruktion eingeführt und den Registersatz deutlich erweitert hat. Gerade letzteres war bei der ursprünglichen x86 Architektur ein ziemliches Problem, man hatte nur 4 Universalregister zur Verfügung welche bei diversen Instruktionen auch noch fest definierte Rollen hatten - AMD hat bei der 64-bit Erweiterung einfach mal 16 frei benutzbare Register hinzugefügt. Alles was man nicht in den Registern halten kann muss in den deutlich langsameren Hauptspeicher geschrieben werden, dadurch macht man sich sehr von den CPU Caches abhängig, deren Nutzung immer noch ein gutes Stück langsamer als die eines Registers ist.
Das trifft zu, wenn Du eine 32-Bit-CPU mit einer 64-Bit-CPU vergleichst. Hier lag aber in beiden Fällen eine 64-Bit-CPU vor und auch das 32-Bit-System kann die effizienten Instruktionen und die zusätzlichen Register voll nutzen. Genaugenommen sogar noch besser, denn bei 32-Bit kann das Programm die 64-Bit-Register splitten und so gleich 2 Adresszeiger reinschreiben. Weiterhin muss das 64-Bit-Programm erst mal eine 64-Bit-Basis-Adresse laden und dafür ein ganzes 64-Bit-Register belegen um den 32-Bit-Offset nutzen zu können, was beim 32-Bit-Programm entfällt.
UlfZibis schrieb: und knapp 1 GB mehr auf der Platte.
Einer dieser neuen effizienteren Instruktionen ist ein relativer Sprungbefehl mit einem 32-bit großem Offset, dadurch kann sogar im Programmcode selbst die Verwendung von 64-bit großen Speicheradressen zu Gunsten von nur 32-bit großen Offsets größtenteils vermieden werden.
Da ein 32-Bit-Programm aber von Haus aus grundsätzlich nur 32-Bit-Adressen verwendet, sehe ich da keinen Nachteil ggü. einem 64-Bit-Programm welches selbst größtenteils 32-Bit-Offsets nutzt.
In der Realität sind die resultierenden ELF Dateien nur unwesentlich größer als ihre 32-bit Versionen.
Naja, die 64-Bit-Installation benötigte 10..20 % mehr Platz auf der Platte. Ob das unwesentlich ist überlasse ich dem Auge des Betrachters.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
UlfZibis schrieb: anders kann ich mir den höheren RAM-Verbrauch des 64-Bit-Firefox nicht erklären.
Unterschiedliche Caching-Strategien fressen auch unterschiedlich viel RAM, ohne überhaupt eine Abhängigkeit von der Pointer Größe zu haben - und Firefox hat einen riesigen Haufen an potentiell cachebaren Daten, der macht mit dem RAM praktisch nichts anderes. Da wären wir wieder bei Architektur-abhängigen Einstellungen. UlfZibis schrieb: Ganz genau! Und weil sowohl das 64-Bit-OS als auch der 64-Bit-Firefox bei gleicher Anzahl geladener Tabs mehr RAM brauchen ist diese Grenze bei nur 2 GiB RAM schneller erreicht, wie meine Tests eindeutig zeigen.
Solange die Grenze nicht erreicht ist, spielt dies aber keine Rolle. UlfZibis schrieb: Der Datei-Cache musste im 64-Bit-System aber erheblich kleiner ausfallen, da OS und Firefox weniger freien Speicher übrig ließen.
Jener Cache ist jedoch ohnehin permanent überdimensioniert. Solange freier RAM vorhanden ist wird alles in den Cache geladen was nicht Niet- und Nagelfest ist, ganz egal ob es Sinn macht oder nicht. Wirklich bemerkbar wird der Unterschied hier auch erst wenn man eine Anwendung hat die mit entsprechend großen Datenmengen um sich wirft. UlfZibis schrieb: Das trifft zu, wenn Du eine 32-Bit-CPU mit einer 64-Bit-CPU vergleichst. Hier lag aber in beiden Fällen eine 64-Bit-CPU vor und auch das 32-Bit-System kann die effizienten Instruktionen und die zusätzlichen Register voll nutzen.
Nein, genau das ist nicht der Fall. Wenn die CPU im 32-bit Modus läuft, steht ihr auch nur der alte x86 Instruktionssatz zur Verfügung - und dieser kann nicht einmal einfach um weitere Register erweitert werden, da die dafür vorgesehenen Bits in den Instruktionen eben nicht einen beliebig großen Wertebereich haben. Dazu kommt die Sache der Abwärtskompatibilität: Die Register werden nicht von der CPU "verwaltet", sondern direkt von der Software genutzt. Sobald du irgendwelche neuen Instruktionen oder Register in deiner Software benutzt, ist diese komplett inkompatibel zu älteren Prozessoren - du müsstest schon explizit separate Codepfade zur Verfügung stellen, was wirklich nur Sinn macht wenn du diese Features extensiv nutzen kannst und dadurch einen exorbitanten Vorteil bekommst, wie zB die Verwendung von SSE2 bei bestimmten Algorithmen. SSE2 kriegst du bei AMD64 nebenbei "umsonst", es ist fester Bestandteil der Grundarchitektur. Was du dir da mental zusammengezimmert hast ist die Linux ABI x32, welche spektakulär gescheitert ist - der Vorteil war schlichtweg verschwindend gering. UlfZibis schrieb: Genaugenommen sogar noch besser, denn bei 32-Bit kann das Programm die 64-Bit-Register splitten und so gleich 2 Adresszeiger reinschreiben.
Man merkt, dass du keine Erfahrung mit Hardware-naher Programmierung hast... Nein, das kannst du nicht. Nicht alles was theoretisch möglich ist, wird auch praktisch umgesetzt - und nur was praktisch umgesetzt wurde, steht dir als Programmierer auch zur Verfügung. Solch ein Register-Splitting wird in der Praxis nur in Rechenmodulen mit eigenen Registern und Vektorerweiterungen umgesetzt, wie zB SSE und einigen ARM FPUs, da es die ganze Architektur ziemlich aufbläht. UlfZibis schrieb: Weiterhin muss das 64-Bit-Programm erst mal eine 64-Bit-Basis-Adresse laden und dafür ein ganzes 64-Bit-Register belegen um den 32-Bit-Offset nutzen zu können, was beim 32-Bit-Programm entfällt.
Aus dem RAM wird nur in ganzen Cache-Zeilen geladen, und die sind um ein vielfaches größer als das. x86 hat zwar keinen Alignment-Zwang wie fast alle anderen Architekturen die es so gibt, aber es wird aus Performance-Gründen trotzdem gemacht, damit man gerade eben nicht mehr wie eine Cache Zeile laden muss. Ob das Register jetzt mit 32 oder mit 64 Bits gefüllt werden muss ist unerheblich, es geschieht sowieso parallel innerhalb eines einzigen Taktzyklus - und üblicherweise werden die ungenutzten Bits dabei auch explizit genullt und daher ebenfalls beschrieben. UlfZibis schrieb: Da ein 32-Bit-Programm aber von Haus aus grundsätzlich nur 32-Bit-Adressen verwendet, sehe ich da keinen Nachteil ggü. einem 64-Bit-Programm welches selbst größtenteils 32-Bit-Offsets nutzt.
Ein expliziter Sprung zu einer Adresse setzt voraus, dass sich die Adresse bereits in einem Register befindet - ansonsten muss diese erst dort hinein geladen werden. Relative Spungbefehle haben üblicherweise immediate Formate, d.h. der relative Wert um den gesprungen wird kann direkt in der Instruktion enkodiert werden, das muss nicht erst in ein Register geladen werden. UlfZibis schrieb: Naja, die 64-Bit-Installation benötigte 10..20 % mehr Platz auf der Platte. Ob das unwesentlich ist überlasse ich dem Auge des Betrachters.
Was meist in erster Linie an 32-bit Altlasten liegt, die mit installiert werden. Man gibt sich zwar Mühe die 64-bit Installationsmedien möglichst sauber zu halten, aber irgend etwas findest du dort immer.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
Letalis_Sonus,
vielleicht liest Du mal das hier: 64-Bit-Architektur Nachteile. Darauf basiert meine Argumentation! Wenn dann noch dazukommt, dass wie in meinem Fall das 2-GiB-RAM auf 64-Bit-Ubuntu durch Firefox mit 5 Tabs von speicherhungrigen Web-Sites wie z.B. Facebook voll ausgelastet ist, kommt dann noch das Swap-Problem dazu.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
UlfZibis schrieb: Darauf basiert meine Argumentation!
Offensichtlich hast du die letzten beiden Sätze selbst nicht gelesen, denn genau darauf basiert meine Argumentation... ich empfehle dir hier auch den deutlich umfangreicheren englischen Artikel. Viel relevanter wäre allerdings der X64 Artikel, da sich dieser auf die konkrete AMD64 Implementierung bezieht und auch Unterschiede zur x86 Architektur stärker beleuchtet, die nicht für andere 64-bit Architekturen verallgemeinert werden können. UlfZibis schrieb: von speicherhungrigen Web-Sites wie z.B. Facebook
Eine Webseite muss schon ziemlichen Murks mit Javascript anstellen, um signifikant mehr RAM wie andere zu fabrizieren. Der Löwenanteil des Bedarfs läuft auf Sachen wie Bilder hinaus, welche überwiegend statisch sind und gerade bei solchen Seiten nicht mehr als anderswo auftreten. Einzig das sogenannte "Endless Scrolling" kann dir bei exzessiver Nutzung wirklich den Speicher zum platzen bringen - dieser Mist gehört wirklich verboten...
|
Berlin_1946
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 18. September 2009
Beiträge: 8564
|
Hallo in die Runde, die gleiche Energie in die Überarbeitung des Wiki- Artikels gesteckt und vllt die hier angeregte Redundanz ausgebaut, dann wäre das der Artikel im "Netz". Sry Was ist an dem Gedanken so falsch: Alles über 32- Bit ist hier Alte Hardware, Lubuntu und speziell hier Lubuntu (Abschnitt „Problembehebung“) gesagt. Hauptpunkte sind doch Installation mit der Firmware UEFI und der 64- Bit- CPU- Struktur. Das sind sicher 90% der Fälle und wie gesagt die Freunde und Anhänger der 32- Bit- CPU's haben viele Hinweise im Wiki. Siehe oben. Warum reicht dieser Hinweis nicht aus?
Die allgemeinen Mindestanforderungen an die Hardware sind im Artikel Alte Hardware näher beschrieben.
Hier ist sogar noch der Fall für diese Installation behandelt.
Systemanforderungen | Derivat | Mindestanforderung | Empfohlen | Ubuntu GNOME | 1,5 GB | > 4 GB |
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
Letalis_Sonus schrieb: Offensichtlich hast du die letzten beiden Sätze selbst nicht gelesen, denn genau darauf basiert meine Argumentation...
"nicht wesentlich langsamer" ist immer noch langsamer, und auf keinen Fall schneller.
ich empfehle dir hier auch den deutlich umfangreicheren englischen Artikel. Viel relevanter wäre allerdings der X64 Artikel, da sich dieser auf die konkrete AMD64 Implementierung bezieht und auch Unterschiede zur x86 Architektur stärker beleuchtet, die nicht für andere 64-bit Architekturen verallgemeinert werden können.
Auch da heißt es "Nachteil – Speicherverbrauch". Und der erreicht bei gleicher Anwendungskomplexität (hier Firefox mit 5 geladenen Tabs) unter 64-Bit-Ubuntu bei nur 2 GiB RAM schneller die Grenze ab der das Swapping einsetzt. Der Vorteil von mehr Registern im 64-Bit-Modus ist dann nur noch Theorie.
UlfZibis schrieb: von speicherhungrigen Web-Sites wie z.B. Facebook
Eine Webseite muss schon ziemlichen Murks mit Javascript anstellen, um signifikant mehr RAM wie andere zu fabrizieren.
Genau das scheint bei Facebook der Fall zu sein. Anders kann ich mir den hohen Speicherverbrauch nicht erklären. Facebook-Seiten brauchen auch auf meinem 8-GiB-P8600-Rechner erheblich mehr Zeit (bis zu 1 Minute), als andere "normale" Web-Seiten, bis sie vollständig geladen und gerendert sind. Auch das spricht für die extensive Nutzung von Javascript.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
Berlin_1946 schrieb die gleiche Energie in die Überarbeitung des Wiki- Artikels gesteckt und vllt die hier angeregte Redundanz ausgebaut, dann wäre das der Artikel im "Netz". Sry
Sehe es als den Kampf einer scheinbar Minderheiten-Meinung, wenigstens mittels eines einzigen einzeiligen Hinweises Ausdruck zu finden. ♥ Was ist an dem Gedanken so falsch: Alles über 32- Bit ist hier Alte Hardware, Lubuntu und speziell hier Lubuntu (Abschnitt „Problembehebung“) gesagt.
Leider eben nicht alles, siehe weiter unten ... ... die Freunde und Anhänger der 32- Bit- CPU's
Darum geht es nicht, sondern um die leider dominant bestrittenen Vorteile eines 32-Bit-OS auf 64-Bit-CPU-Hardware mit wenig RAM.
haben viele Hinweise im Wiki.
Seit der letzten Änderung von Dir einen weniger. ☹ Der Anfänger, der einen schwachbrüstigen Rechner vor sich hat, auf dem Windows nicht mehr flüssig läuft, und es deshalb mal mit Ubuntu versuchen will, bevor er den Rechner entsorgt, stößt nun mal zuerst auf hiesigen Artikel. Bis er sich zum "Alte Hardware"-Artikel durchgeklickt und dessen Erklärungen durchschaut hat, hat er möglicherweise schon aufgegeben. Außerdem beschränkt sich letzterer auf die Empfehlung, Lubuntu oder Xubuntu zu nutzen, was nur für wirklich sehr alte Hardware nötig ist. Netbooks mit 64-Bit-Architektur, aber nicht erweiterbarem 1..2 GiB-RAM sind aber durchaus eher "modern", und erlauben auch durchaus flüssiges semi-anspruchsvolles Arbeiten unter GNOME oder Unity, sofern man die 32-Bit-Variante installiert. Genau deshalb verteidige ich den einzeiligen Hinweis unter der deutlichen Relativierung "kann von Vorteil sein" in hiesigem Artikel.
Die allgemeinen Mindestanforderungen an die Hardware sind im Artikel Alte Hardware näher beschrieben.
Hier ist sogar noch der Fall für diese Installation behandelt.
Systemanforderungen | Derivat | Mindestanforderung | Empfohlen | Ubuntu GNOME | 1,5 GB | > 4 GB |
Die Unterscheidung zwischen 32 und 64 Bit fehlt auch dort.
|
Berlin_1946
Supporter, Wikiteam
(Themenstarter)
Anmeldungsdatum: 18. September 2009
Beiträge: 8564
|
UlfZibis schrieb:
Der Anfänger, der einen schwachbrüstigen Rechner vor sich hat, auf dem Windows nicht mehr flüssig läuft, und es deshalb mal mit Ubuntu versuchen will,
1. Voraussetzungen 1.1 Minimalanforderung 1.2 Empfohlene-Ausstattung
Die allgemeinen Mindestanforderungen an die Hardware sind im Artikel Alte Hardware näher beschrieben.
als 3. Satz. Ich finde das sollte man schon durchlesen. Wohin denn? Noch viel früher im Artikel? Voraussetzungen sollte schon geprüft werden. Nachtrag: Der o.g. "Anfänger" muss schon ganz schön versiert sein, damit er überhaupt eine Ubuntu 32-Bit-Version findet. Siehe mal die Tabelle vom Wiki Downloads/Bionic Beaver an. Die gibt es schlicht und einfach dort nicht.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
UlfZibis schrieb: "nicht wesentlich langsamer" ist immer noch langsamer, und auf keinen Fall schneller.
Es geht in dem Satz explizit um ungünstige Programme. Dass die Auswirkungen dieser Architekturunterschiede extrem von der jeweiligen Software abhängt brauch ich dir ja wohl hoffentlich nicht zu erklären, oder? Im anderen Artikel ist durch die zusätzlichen Register sogar von einem allgemeinen Geschwindigkeitsvorteil von 25-30% die Rede, dies müssen die Nachteile erst einmal wegfressen. Du wirst ebenso in den Paketquellen auch Software finden, die in der 64-bit Version kleiner ausfällt. Letztendlich haben auch die Compiler im Laufe der Jahre mächtig dazugelernt und können dahingehend kräftig optimieren. UlfZibis schrieb: Genau das scheint bei Facebook der Fall zu sein.
Es könnte natürlich auch an den ganzen eingebundenen Tracker- und Werbeframeworks liegen, gegen die man nichts unternimmt... Lösungen wie AdBlock sind nebenbei auch Gift für kleinen Arbeitsspeicher, da diese gewaltige Blocklisten im Speicher halten müssen. Whitelist Lösungen wie Noscript bereiten zwar mehr Arbeit, haben dieses Problem allerdings nicht - insbesondere wenn man die permanenten Freigaben auf das wesentliche beschränkt. UlfZibis schrieb: Sehe es als den Kampf einer scheinbar Minderheiten-Meinung, wenigstens mittels eines einzigen einzeiligen Hinweises Ausdruck zu finden. ♥
...sprach Don Quijote. Windmühlen sind leider aus, hier hast du eine Ente: 🦆 UlfZibis schrieb: Darum geht es nicht, sondern um die leider dominant bestrittenen Vorteile eines 32-Bit-OS auf 64-Bit-CPU-Hardware mit wenig RAM.
Wenn diese wirklich so signifikant wären, hätte sich x32 durchgesetzt. Immerhin wurden in alten SPEC Benchmarks ein Performancevorteil von bis zu 40% gegenüber AMD64 ermittelt - nur bilden solche synthetischen Einzelfälle selten die allgemeine Realität ab. Es gibt ganze Industriezweige mit derartigen Hardware-Nischen, die dort sofort drauf angesprungen wären. Aber dort läuft ja auch kein Firefox. Vor einem Jahr wurde übrigens vorgeschlagen, die x32 Unterstützung wieder komplett aus dem Kernel zu werfen, was auch bei Torvalds Anklang fand. Die Diskussion ist dann aber eingeschlafen. UlfZibis schrieb: Netbooks mit 64-Bit-Architektur, aber nicht erweiterbarem 1..2 GiB-RAM sind aber durchaus eher "modern"
Laut Wikipedia starb der Netbook-Trend gegen 2011 aus, insbesondere in den Staaten wurden diese zu der Zeit durch die Chromebooks abgelöst. Nach einer halbwegs aktuellen Studie von Avast ist der durchschnittliche Bestands-PC 6 Jahre alt - da würde ich Netbooks nicht mehr gerade als "modern" bezeichnen, zumal diese ja ohnehin sehr weit unten im Preisspektrum zu finden waren.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
Berlin_1946 schrieb: UlfZibis schrieb: Die allgemeinen Mindestanforderungen an die Hardware sind im Artikel Alte Hardware näher beschrieben.
als 3. Satz. Ich finde das sollte man schon durchlesen.
Und was hat man dann davon? Man wird auf Lubuntu etc. verwiesen und dann ist Ende Gelände. Auf die Möglichkeit von Unity oder GNOME als Aufsatz auf eine Lubuntu-32-Bit-(Minimal-)Installation wird dort nicht hingewiesen. Der Leser des hiesigen Artikels hat sich höchstwahrscheinlich für Ubuntu (mit GNOME) entschieden, denn sonst würde er die Installationsanleitung eines der anderen X-buntu-Derivate lesen. Hat er eine 32-Bit-CPU oder weniger als 1,5 GiB RAM wird er komplett im Regen stehengelassen, obwohl das nicht grundsätzlich ein Ausschlusskriterium für Ubuntu (mit GNOME) ist. Hat er eine 64-Bit-CPU mit nur 1,5..2 GiB RAM bekommt er ein System, was ihn wegen baldigem Swappen ähnlich frustrieren wird, wie ein ruckelndes Windows.
Der o.g. "Anfänger" muss schon ganz schön versiert sein, damit er überhaupt eine Ubuntu 32-Bit-Version findet.
Genau dem sollte IMHO abgeholfen werden.
Siehe mal die Tabelle vom Wiki Downloads/Bionic Beaver an. Die gibt es schlicht und einfach dort nicht.
Jedenfalls kein out-or-the-box-Installationsmedium für den GNOME- oder Unity-Desktop, für die anderen schon.
|