Wie sehen eure Desktops aus?

Hellsing, ist Top!

Zitat von Pain

Frisch durch. Der lausige Anime und die grandiose Ultimate OVA.

good old times, wenn commo es gefeiert hat das london hakenkreuzartig abgebrannt ist

aber wie sich der anime wandelt, das schon herber shit

Zitat von mrshadowtux

Könntest du auch auf 8 oder 4 Bit stellen, sähe identisch aus. Einfach weil die Icons nicht mehr als 16 Farben haben.

Das stimmt, aber auf 16 Farben wäre die Farbpalette eine leicht andere, verglichen mit den 20 reservierten Farben im 8-Bit-Modus.

Zitat von DosAmp

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.

Zitat von mrshadowtux

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:

Zitat von Sje

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.

Zitat von mrshadowtux

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:

Zitat

OS: Ubuntu 16.04.3 LTS x86_64

Zitat von mrshadowtux

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.

Zitat von Arnulf zu Linden

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.