Das stimmt, aber auf 16 Farben wäre die Farbpalette eine leicht andere, verglichen mit den 20 reservierten Farben im 8-Bit-Modus.
da schau her, wusst ich gar nicht. erklärt den unterschied bei dem petrolgrünen hintergrund wenn man zwischen 16 und 256 farben (oder mehr) wechselt. bei 16 farben ist er heller..
Überraschende Wendung: Mangels regelmäßiger Verwendung und Bastellust handelt es sich in Wirklichkeit nur um ein Debian 9 mit standardmäßigem LXDE-Desktop.
Ist das Fefe im Wallpaper?
Ja. Ein werter Internet-Mitbenutzer hatte einen Schnappschuss auf den heise Internet Security Days für die „Rare Fefes“-Sammlung angefertigt.
12"-PowerBook (letzte Generation).
Schick 
HPE MicroServer Gen8. 2012 R2 Datacenter verschwindet darauf absehbar kurzfristig, Debian kommt.
freeesh
ja hab mit dem Snippingtool verschissen den anderen Monitor sauber abzuschneiden, aber Murray kann man nicht oft genug haben yo
Testaufbau mit Asrock A780LM-S:
Testaufbau mit Asrock A780LM-S:
nur 3 GiB RAM mit Linux x86_64 – das wird schon etwas eng. Für'n Testlauf reicht es natürlich.
nur 3 GiB RAM mit Linux x86_64 – das wird schon etwas eng. Für'n Testlauf reicht es natürlich.
Was hat die Architektur mit dem verbauten RAM zu tun? Entscheidend ist, was an Diensten/Software darauf läuft.
Was hat die Architektur mit dem verbauten RAM zu tun? Entscheidend ist, was an Diensten/Software darauf läuft.
Missverständnis erkannt: "Linux x86_64" meint schon die Software (im Unterschied zum ebenfalls existenten "Linux ia64", was auf der x86_64-Architektur natürlich nicht nativ laufen würde). Die 64-Bit-Version (x86_64) einer Linuxdistro braucht nach meiner Erfahrung bei gleichen laufenden Diensten/Programmen mehr RAM als die entsprechende 32-Bit-Version (ia32).
Im Bild ist zu lesen:
OS: Ubuntu 16.04.3 LTS x86_64
Missverständnis erkannt: "Linux x86_64" meint schon die Software (im Unterschied zum ebenfalls existenten "Linux ia64", was auf der x86_64-Architektur natürlich nicht nativ laufen würde). Die 64-Bit-Version (x86_64) einer Linuxdistro braucht nach meiner Erfahrung bei gleichen laufenden Diensten/Programmen mehr RAM als die entsprechende 32-Bit-Version (ia32).
Kann ich mir beim besten Willen nicht vorstellen. Hast du da unter exakt gleichen Versionen der Software getestet?
Kann ich mir beim besten Willen nicht vorstellen. Hast du da unter exakt gleichen Versionen der Software getestet?
Es fiel mir bei Slackware 13.0 vs. Slackware64 13.0 auf x86_64-Architektur auf. Da das aber schon eine Weile her ist, habe ich keine Details mehr. Wenn bei der Portierung von ia32 nach x86_64 aus 32-Bit-Variablen 64-Bit-Variablen werden, steigt zwangsläufig der Speicherbedarf.
Wäre mal interessant, das unter kontrollierten Bedingungen nochmal zu testen.
Es fiel mir bei Slackware 13.0 vs. Slackware64 13.0 auf x86_64-Architektur auf. Da das aber schon eine Weile her ist, habe ich keine Details mehr. Wenn bei der Portierung von ia32 nach x86_64 aus 32-Bit-Variablen 64-Bit-Variablen werden, steigt zwangsläufig der Speicherbedarf.
Letzteres trifft primär nur auf alle Stellen zu, an denen Zeiger verwendet werden. Das betrifft je nach Komplexität die internen Strukturen des Programms und zu einem kleinen Teil den Stack jedes seiner Threads, wo Rücksprungadressen auch in 8 statt 4 Byte Größe abgelegt werden.
Eigentliche Zahlwerte (z. B. "int" oder "uint32_t" in C) bleiben in den meisten Fällen 32 Bit groß, ebenso codeinterne Referenzen, die auf x86_64 meist 32-bit-relativ vom Compiler ausgedrückt werden, da das übliche Programm nicht mehr als 2 GB reinen Code am Stück hat (bzw. wenn, dann dieser in viele Bibliotheken modularisiert ist).
Der Speichermehrverbrauch unter Linux hält sich jedenfalls definitiv in Grenzen und ist kein ausschlaggebender Grund, mit 3 GB (solange man damit nicht schon nahe an der Grenze des von der Hardware in Beschlag genommenen Adressraums stößt) noch 32-Bit-Kernel + -Userland zu fahren, wenn man ähnlichen Speicherdruck auch mit 4 GB RAM hätte (z. B. durch den allseits beliebte Speicherfresser, den modernen Browser), aber dann kein Problem bei einem späteren Upgrade hat.
Als Sonderfall gibt es auch noch die Konstellation "64-Bit-Kernel + 32-Bit-Userland", welche nicht nur bei manchen Recovery-Linux-CDs zum Einsatz kommt (man muss dann nur zwei verschiedene Kernel anbieten, je nachdem, ob man z. B. Chroot in eine 64-Bit-Umgebung ermöglichen will), sondern auch auf Produktivumgebungen als "x86_32"-Plattform (streng genommen kein "wahres" 32-Bit, da damit z. B. von den zusätzlichen AMD64-Registern und SSE2 Gebrauch gemacht werden kann) angeboten wird, da z. B. PostgreSQL ein Multi-Prozess-Modell verfolgt, mit dem auch mit 32-Bit-Code problemlos mehr als 4 GB RAM verwendet werden können.
Auf Windows sieht das minimal anders aus – durch die weite Verbreitung von 32-Bit-Anwendungen müssen außerhalb kontrollierter Umgebungen (Windows PE standardmäßig ohne WOW64) ständig auch zusätzlich 32-Bit-Bibliotheken geladen sein.
EDIT: Neben anderen Dingen (frühere Popularität von 32-Bit-Plugins; JIT-Javascript-Compiler, die ursprünglich nur 32-Bit-Code erzeugen konnten) ist das auch ein Grund, warum alternative 64-Bit-Browser so lange gebraucht haben, sich auf Windows/Mac durchzusetzen: Das Konzept "Pointer auf Pointer auf Pointer von Pointer" ist eine beliebte Implementations-Krankheit von VM-Programmiersprachen.
Als Sonderfall gibt es auch noch die Konstellation "64-Bit-Kernel + 32-Bit-Userland",
Es gibt auch noch 64-Bit Kernel + 64-Bit Userland + 32-Bit multilib, womit dann 64-Bit- und 32-Bit-Programme parallel laufen können. Das bläht die Sache natürlich auf.
Es gibt auch noch 64-Bit Kernel + 64-Bit Userland + 32-Bit multilib, womit dann 64-Bit- und 32-Bit-Programme parallel laufen können. Das bläht die Sache natürlich auf.
War für Pakete wie Skype sehr lange notwendig auf Linux. Glaube z.B. Teamviewer braucht das heute noch.
War für Pakete wie Skype sehr lange notwendig auf Linux. Glaube z.B. Teamviewer braucht das heute noch.
Der Linux-Treiber für den Brother MFC-9142CDW braucht es leider immer noch. Sonst hätte ich mir die Einrichtung der multilib-Umgebung unter Slackware64-14.2 nämlich erspart.
nur 3 GiB RAM mit Linux x86_64 – das wird schon etwas eng. Für'n Testlauf reicht es natürlich.
Hat problemlos funktioniert und die 3 GB RAM waren schon auf dem Board und zum testen reichen die dicke.
Inzwischen sind eh 2x 4 GB DDR2-800 auf dem Board und ein Athlon II X4 630 ...
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!
