☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Beim Start lesen Anwendungen üblicherweise die Eingabemethoden des Systems aus der Datei /usr/share/X11/locale/<locale>/Compose aus, da diese Datei allerdings oft recht lang ist, lässt sich durch einen binären Cache Zeit beim Start der Anwendung einsparen. Laut einer Bug-Meldung auf bugs.freedesktop.org wird dieser Cache allerdings nur dann angelegt, wenn im Home-Verzeichnis des aktuellen Benutzers der Ordner ~/.compose-cache existiert.

$ mkdir ~/.compose-cache

Wenn ihr also das Verzeichnis über einen Dateimanager oder obigen Befehl anlegt, wird der Cache nach Angaben des Foren-Threads (der es mittlerweile auch ins Arch-Linux-Wiki geschafft hat) beim Start einer Anwendung mit Textbox gefüllt. Zum Testen könnt ihr zum Beispiel Gedit oder Kate probieren, nach dem Start der Anwendungen sollten sich in dem Verzeichnis Dateien mit Namen wie l4_024_313cb605_00280cc0 finden. Insgesamt soll der Trick beim Start einer Anwendung etwa 200 bis 400ms einsparen. Nicht viel für eine einzelne Anwendung, beim Einloggen allerdings können sich die Zeiten summieren.

Ich für meinen Teil kann hier unter Ubuntu 12.04 mit GNOME Shell nicht behaupten, dass dieser Hinweis überhaupt noch gültig ist. Wenn ich das Verzeichnis erzeuge und einen Texteditor oder auch Chat-Programme öffne, dann bleibt der Ordner leer. Entweder läuft der Cache also schon an einer anderen Stelle (das Blog spricht von /var/cache/libx11/compose, diesen Ordner gibt es bei mir allerdings nicht) oder der Tipp ist schon komplett veraltet. Es würde mich interessieren, ob der Hinweis bei euch klappt.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Um Support für NFS auf die gefreetzte FRITZ!Box zu bekommen, müsst ihr nfs-utils und NFSD_CGI in das Freetz-Image einbauen. Eine entsprechende Anleitung für Freetz habe ich ja schon hier im Blog gebracht. Ich konzentriere mich daher lieber auf die Konfiguration von NFS und die Auswirkungen auf die Netzwerkperformance der Box. Um Freetz auf die FRITZ!Box zu bekommen, lest euch zuvor bitte in den genannten Artikel zu Freetz ein.

Freigaben via NFS einrichten und konfigurieren

Nach der Aufnahme der beiden Module in euer Freetz-Image und einem anschließenden Neustart, könnt ihr NFS unter http://fritz.box:81/cgi-bin/conf/nfsd konfigurieren. Die Konfigurationen für die exports, hosts.allow, hosts.deny und Co. könnt ihr dabei aus der nfsd-Doku von Freetz übernehmen. Nehmt am besten auch den SSH-Server Dropbear mit in euer Image auf, so könnt ihr später ganz einfach über SSH mit der FRITZ!Box arbeiten, um etwa die Dateirechte auf dem externen Datenträger zu korrigieren.

Wichtig dabei ist allerdings, dass ihr als freizugebendes Medium Platten verwendet, die mit Ext3 oder ReiserFS formiert sind (Ext4 ginge natürlich auch, allerdings hatte ich Probleme beim Einbinden von mit Ext4 formatierten Partitionen, von daher gebe empfehle ich eher Ext3 als Dateisystem). Mit hoher Wahrscheinlichkeit müsst ihr auf dem Laufwerk auch noch die Dateirechte korrigieren, ich logge mich dazu via SSH auf der FreetzBox ein und übergebe die Daten dem User „ftp“ und der Gruppe „users“.

$ ssh root@fritz.box 
$ cd /var/media/ftp/
# Bitte passt den Pfad zur Platte an, bei mir nennt sie sich datengrab
$ chown ftp:users datengrab -R
$ find datengrab/ -type d -exec chmod 775 {} +
$ find datengrab/ -type f -exec chmod 664 {} +

Danach könnt ist auf Seiten der FRITZ!Box alles erledigt. Ihr müsst nun auf eurem Linux-System den NFS-Client installieren und die Freigabe bei euch einbinden. Auf einem Debian/Ubuntu-System installiert ihr dafür erst einmal das Paket nfs-common, legt dann einen Mount-Punkt an (nichts anderes als ein Verzeichnis, in das die Freigabe geladen wird) und bearbeitet dann die Datei /etc/fstab so dass die NFS-Freigabe der FRITZ!Box geladen wird.

$ sudo apt-get install nfs-common
$ sudo mkdir /media/fritzbox
$ gksudo gedit /etc/fstab

Der Eintrag in die fstab sähe z.B. so aus. Den Pfad zu Freigabe und zum Mountpunkt müsst ihr natürlich noch an eure Situation anpassen. Den Rest könnt ihr direkt übernehmen und ans Ende der fstab kopieren.

# Freetzbox über NFS mounten
fritz.box:/var/media/ftp/datengrab /media/fritzbox nfs vers=3,rw,rsize=65536,wsize=65536 0 0

Nach dem Speichern der Datei, könnt ihr über das folgende Kommando alle über die fstab eingetragenen Mount-Vorgänge neu einlesen lassen, so spart ihr euch noch einen Neustart oder das manuelle Ausführen eines längeren mount-Kommandos.

$ sudo mount -a

Nun sollte die Netzwerkfreigabe der FreetzBox unter /media/fritzbox erscheinen. Testet am besten kurz aus, ob ihr dort lesen und schreiben könnt. Sollte das nicht der Fall sein, so wird vermutlich noch etwas mit den Dateirechten nicht stimmen.

Was bringt nun NFS auf der FRITZ!Box?

Zum Abschluss komme ich nun auf die ursprüngliche Frage zurück, lohnt sich der Aufwand eigentlich? Der springende Punkt dabei ist natürlich die Übertragungsrate von Daten zur FRITZ!Box. Ursprünglich hing an meiner unmodifizierte FRITZ!Box eine mit NTFS formatierte USB-Platte. Subjektiv beurteilt war diese Lösung grottig langsam, Transfers größerer Datenmengen von 3-4 GB dauerten Stunden und auch das Einlesen von Verzeichnissen mit vielen Dateien/Ordner war zeitraubend. Nach dem Freetzen und Umstellen auf Ext3 als Dateisystem und NFS als Dateifreigabe sieht das nun deutlich anders aus…

$ time cp 1gb.test /media/fritzbox_samba/
real	4m56.363s
$ time cp ubuntu-11.04-desktop-i386.iso /media/freetz_nfs/
real	1m58.300s
$ time cp ubuntu-11.04-desktop-i386.iso /media/freetz_samba/
real	2m14.387s

Errechne ich nun aus diesen Zeiten eine Datenübertragungsrate, so kommt wieder NFS vor Samba ans Ziel. Immerhin ist NFS nach wie vor rund 0,7 MB/s schneller als Samba, allerdings ist der Unterschied nicht mehr so gravierend wie damals mit meiner NLSU2.

Die Verbesserten Übertragungsraten spürt man auch im Linux-Alltag. Natürlich spart man beim Kopieren größerer Datenmengen deutlich Zeit, aber auch das „Browsen“ mit Nautilus auf der Freigabe geht spürbar schneller. Vorher war immer eine kurze Denkpause nach dem Wechsel eines Verzeichnisses nötig, jetzt ist der Inhalt sofort da. Vorher dauerte das Einlesen eines Verzeichnisses mit VIELEN Dateien wirklich lange, jetzt ist auch dieses Verzeichnis sofort da. Der Umstieg auf Freetz und NFS ist daher auf jeden Fall lohnenswert.

Den gewaltigen Performance-Vorsprung gegenüber der ursprünglichen Konfiguration (NTFS und Original-Firmware) führe ich auf das Dateisystem NTFS zurück. Ich habe schon selbst bei mir auf meinem Desktop-Rechner mit Intel Core i3 festgestellt, dass NTFS unter Linux ziemlich auf die CPU geht, das ist natürlich fatal bei einem auf einem Embeded-Linux, bei dem nur eine leistungsschwache CPU zur Verfügung steht.

Ich hatte es leider verpasst die Netzwerkperformance einer freigegeben und mit FAT formatierten Platte zu messen, aber ich denke dass hier ein Plus an Geschwindigkeit definitiv messbar sein wird. Wer also mit den Übertragungsraten seiner FRITZ!Box nicht zufrieden ist, die Box jedoch nicht „freetzen“ möchte, der kann ja mal seine externe Platte auf FAT umstellen [UPDATE: Neuere FRITZ!Boxen können auch direkt mit Ext2 formatierte Laufwerke einbinden, vielleicht ist das die beste Option für ungefreetzte Boxen].

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Video wird erst nach Klick von YouTube geladen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Die Übertragungsrate vom Rechner auf das Handy liegt bei sage und schreibe 0,45MB/s. USB 2.0 könnte in der Theorie 60MB/s transferieren. Das Handy kommt also gerade mal auf 0,75 Prozent der theoretischen Übertragungsrate. Kompliment Sony, für diese Nicht-Performance hättet ihr eigentlich eine olympische Holz-Medaille mit rostigen Nägeln kassieren sollen, die euch in den „where the sun never shines“ geschoben werden sollte! Technisch kann man diese Glanzleistung recht schön nachvollziehen. Stöpselt man das Handy per original Datenkabel von Sony an einen aktuellen Rechner an – das Handy wird dann als Wechselmedium erkannt – so sieht man in der /var/log/messages folgende Meldungen:

$ tail -f /var/log/messages
...
Jul 23 00:57:35 isleofskye kernel: [ 3104.835115]  sdg: p1 exceeds device capacity
Jul 23 00:57:35 isleofskye kernel: [ 3104.872860] attempt to access beyond end of device
Jul 23 00:57:35 isleofskye kernel: [ 3104.872870] sdg: rw=0, want=959338, limit=958999
Jul 23 00:57:35 isleofskye kernel: [ 3104.872881] attempt to access beyond end of device
Jul 23 00:57:35 isleofskye kernel: [ 3104.872883] sdg: rw=0, want=959339, limit=958999
...

Kopiert man dann eine 100MB große Testdatei auf das Handy, so demonstriert das Handy seine ganze Stärke.

$ time cp 100mb.test "/media/PHONE CARD/"

real	3m42.545s
user	0m0.000s
sys	0m0.552s

Das Problem betrifft übrigens nicht nur Linux oder meinen Rechner oder die genutzte Speicherkarte. Auch auf einem anderen Rechner, mit einer anderen Karte und unter Windows bleibt die Übertragungsrate unterirdisch.

Ich habe dann spaßeshalber mal beim Support von Sony Ericsson angerufen und gefragt, ob diese atemberaubende Performance wirklich nicht zu steigern ist. Die Dame am anderen Ende der Strippe beantwortete die Frage mit „Theoretisch können die Daten mit bis zu 480mbit/s übertragen werden“ – ja gut, ist klar, die maximale Geschwindigkeit von USB 2.0, die Praxis sieht jedoch anders aus – „Aber warum ist denn das so langsam? Ich kann hier mit [irgendein aktuelles Modell von SE] in 15 Minuten ein Album auf mein Handy übertragen, das hat mich noch nie gestört“… Einen Kommentar verkneife ich mir hier lieber.

Willkommen Sony in der Welt von Speicherkarten mit bis zu 8GB. In nicht einmal 5 Stunden kann man diese über ein Handy von Sony befüllen. Ich kann ja verstehen, dass eure Schnittstellen wohl noch aus einer Zeit stammen, als nur Kontakte, Termine etc. mit dem Handy abgeglichen wurden, doch wenn selbst aktuelle Modelle von Sony so lahm sind, dann solltet ihr mal über eure Technik etwas nachdenken! Bleibt also nur der Umweg über einen Kartenleser. So labrig wie der Deckel für den Kartenslot gebaut ist, wird dieser jedoch recht schnell abfallen. Also lieber Sony Ericsson. Mich habt ihr als Kunde verloren. Schade eigentlich, sonst gefallen mir eure Modelle ganz gut.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Plattformunabhängige Neuerungen

Aber zuerst ein kleiner Überblick über die wichtigsten neuen Funktionen des Firefox 3. Hier ragt sicherlich die neue Verwaltung von Lesezeichen heraus. Anstatt wie früher die Bookmarks in einer Ordnerstruktur zu organisieren, die dann in einer einfachen Datei (bookmarks.html) gesichert wird, nutzt das neue System (von den Entwicklern „Places“ genannt) Tags zum Einordnen der Bookmarks, so wie man es von sozialen Netzwerken oder Blogs her kennt. Die Tags selber werden dann in einer SQLite-Datenbank gesichert. So lassen sich Bookmarks zu so genannten „Smart Folders“ zusammenfassen und schnell organisieren. Entwicklern von Erweiterungen für den Firefox steht eine umfangreiche API zur Verfügung, über die das neue Bookmarksystem erweitert werden kann.

Ein weiteres sehr praktisches Feature ist, dass Firefox beim Vergrößern bzw. Verkleinern mit [Strg]+[+] bzw. [Strg]+[-] nun auch die Bilder vergrößert bzw. verkleinert. So bleibt das Layout der betrachteten Webseite beim Zoomen vollständig erhalten. Wer diese neue Funktionalität nicht mag, kann diese jedoch auch wieder abstellen, und das alte Verhalten einstellen, wo nur der Text einer Webseite in seiner Größe verändert wird.

Ebenfalls deutlich verbessert wurde die Adresszeile, also der Bereich in dem man Webadressen eingeben kann. Bei Eingabe einer URL wird nun nicht mehr nur die Browser-Chronik durchsucht, sondern auch die Bookmarks. Treffer werden schon während der Eingabe zweizeilig und inklusive des Favicons dargestellt. So findet man schnell eine Seite, die man schon besucht bzw. in den Bookmarks abgelegt hat, wieder.

Als Referenz für die Einhaltung der Webstandards dient der Acid2-Test. Firefox 2 hat diesen Test bislang nicht bestanden. Firefox 3 hingegen hält sich nun an alle üblichen Webstandards.

Auch unter der Haube hat sich viel getan. Mozilla nutzt nun Cairo für sämtliche Seiteninhalte wie auch zum Zeichnen der Programmoberfläche. Cairo ist eine Softwarebibliothek zum Darstellen von zweidimensionalen Inhalten auf dem Bildschirm. Dadurch geht Firefox deutlich flotter zu Werke, wenn aufwändige Webseiten gezeichnet werden sollen.

Mit den weiteren neuen Funktionen wie einem verbesserten Phishing-Schutz, einfacherer Installation von Add-Ons, die nicht über addons.mozilla.org installiert werden sollen und den schon beschriebenen neuen Funktionen macht Firefox 3 ein gutes Bild. Vor allem das neue und generalüberholte Bookmarksystem überzeugt, erfordert aber vom Anwender ein Umdenken, da sich Tags deutlich anders verwalten lassen als eine statische Ordnerstruktur.

Linux-News

Die auffälligste reine Linux-Neuerung ist, dass Firefox nun richtige GTK-Widgets benutzt. Widgets sind Schaltflächen, Scrollbalken und Buttons. Diese wurden bisher nicht passend zum verwendeten Thema der Desktopumgebung gezeichnet. Nun endlich fügt sich Firefox wunderbar in die Desktopumgebung ein und übernimmt das Aussehen von GNOME. Ja, nur von GNOME bzw. genauer gesagt das Aussehen von GTK. Es gibt wohl ein paar Animositäten zwischen den Entwicklern von Mozilla und KDE, so dass es nach wie vor keine Qt-Variante von Firefox gibt, die sich nahtlos in KDE einfügen würde. Schaut man sich weiter um, so sieht man, dass Firefox nun auch das eingestellte Icon-Theme nutzt.

Überall, wo möglich, bindet Firefox nun Icons aus dem Icon-Theme der Desktopumgebung ein. Des Weiteren sehen nun auch die Tabs des Firefox inklusive des Buttons zum Schließen eines Tabs aus, wie die aller GNOME-Anwendungen. Auch hier hat sich Firefox davon verabschiedet, unter allen Plattformen gleich aussehen zu wollen.

Eine weitere Änderung betrifft das Verhalten beim Scrollen mit dem Mausrad. Gerade Umsteiger von einem anderen bekannten Betriebssystem merken, dass sie nicht mehr mit dem Mausrad in einer Webseite scrollen können, sobald der Mauszeiger über einem Plugin (Also einem Java-Applet oder einer Flashanimation) steht. Hier hat das Plugin bisher das Scrollen des Mausrades abgefangen und man musste die Maus erst aus dem Bereich des Plugins herausfahren. Nun kann man einfach weiterscrollen.

Schaut man sich die aktuelle Nightly Build von Firefox 3 an, so kann man bereits Funktionen entdecken, die es wohl erst ab der Beta 3 geben wird. Hier können Bilder per Copy&Paste in andere Anwendungen übernommen werden. Also beispielsweise durch einen Rechtsklick auf ein Bild und Copy Image und dann z.B. in Gimp Datei | Holen | Als neues Bild einfügen. Ein Bild per Drag&Drop auf den Desktop oder in eine Anwendung zu ziehen, klappt bisher jedoch leider immer noch nicht.

Letztendlich bietet der Dateidialog bei der Auswahl eines Bildes eine Dateivorschau. So kann man schnell sehen, welches Bild man auf seine Profilseite bei StudiVZ und Co. hochlädt, ohne vorher mit einem Bildbetrachter das richtige Bild raussuchen zu müssen. Alles in allem ist Firefox 3 für den Linux-Desktop ein wichtiger Baustein. Die Anwendung integriert sich nun fast nahtlos in den Linux-Desktop. Leider müssen Benutzer, die KDE als Desktopumgebung bevorzugen, mal wieder zusehen, wie man sich auf GTK konzentriert.

Performance

Firefox hat nicht den Ruf, der schnellste Browser zu sein. Laut den Entwicklern von Mozilla wurde jedoch nun bei Firefox 3 viel an der Performance gedreht. Grund genug auch hier mal etwas genauer hinzusehen. Wir vergleichen Firefox 2.0.0.11 sowie Firefox 3 Beta3pre und als Referenz Opera 9.25 in der 32-bit Version, sowie Opera 9.5 Beta2, der bald erstmals in einer 64-bit Version erscheinen wird. Die Tests werden auf einem System mit einer AMD Athlon 64 X2 AM2 3800+ CPU, 2GB RAM und Ubuntu Gutsy Gibbon 7.10 (64-bit) als Betriebssystem durchgeführt.

Im ersten Test wird analysiert, wie lange der Browser braucht, um eine aufwändige Webseite mit CSS-Layout zu laden. Hierfür wird die Testseite CSS Rendering Benchmark lokal abgespeichert, im Browser geöffnet und die Zeit für das vollständige Rendern der Seite gemessen. Dies macht ein in die Seite eingebautes JavaScript automatisch. Da die Werte stärker schwanken, wird der Test jeweils zehnmal wiederholt und ein Mittelwert gebildet. Hier zeigt sich, dass der gute alte Firefox 2 tatsächlich noch ein bisschen schneller ist. Der Benchmark braucht für FF2 im Schnitt 692 ms, FF3 lässt sich im Durchschnitt rund 845 ms Zeit. Eventuell muss hier noch von den Entwicklern nachgebessert werden.

Als nächstes analysieren wir die Zeit, die Firefox zum Rendern einer Webseite mit einer größeren Tabelle braucht. Hierfür installieren wir das Add-On Load Time Analyzer, dieses Add-On kann die Zeit bis zum vollständigen Aufbau einer Webseite messen und anzeigen. Als Referenzseite verwenden wir diese Seite. Die Seite wird wieder lokal abgespeichert, zehn mal neu geladen und aus den gemessenen Zeiten ein Mittelwert gebildet. In diesem Benchmark schneidet Firefox 3 nun deutlich besser ab als sein Vorgänger. Firefox 3 braucht im Mittel nur rund 675 ms während FF2 1002 ms beim Aufbau beschäftigt ist. Dies ist ein deutlicher Gewinn an Performance von von 32%.

Nach den Tests an statischen Webseiten soll nun die JavaScript Engine getestet werden. Dazu wird der JavaScript Benchmark von SunSpider genutzt. Dieser testet eine Reihe von nicht browserspezifischen Routinen und misst die Zeit. Auch hier wieder zieht der neue Platzhirsch an seinem Vorgänger vorbei. Laut SunSpider geht Firefox 3 bei JavaScript ca. 1,13 mal so schnell zu Werke wie Firefox 2. Dies dürfte sich besonders bei den derzeit so beliebten Webseiten mit AJAX bemerkbar machen.

Letztendlich möchten wir noch einen Blick auf die Speicherauslastung des Browsers werfen. Firefox 2 hat den Ruf RAM regelrecht zu fressen. Um dies zu analysieren wird Firefox mit einem sauberen Profil gestartet und zehn Webseiten mit größeren Inhalten (spiegel.de, slashdot.org, sueddeutsche.de…) in neuen Tabs geöffnet. Mit der GNOME Systemüberwachung wird dann der belegte Speicher des firefox-bin Prozesses betrachtet. Auch hier wieder scheinen die Entwickler ganz Arbeit geleistet zu haben. Anstatt 100 MB wie Firefox 2 braucht der Neue nun nur 75 MB.

Im Bereich der Performance des Browsers hat sich demnach viel getan, doch nach wie vor kann Firefox dem vermeintlich flottesten Browser Opera nicht das Wasser reichen. In allen Tests ist Opera immer noch deutlich schneller. Eventuell bessert sich das Bild noch etwas, wenn Firefox offiziell freigegeben wird und dann in einer 64-bit Version getestet werden kann.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Oftmals wird diskutiert, welcher Software nun der Vorzug gegeben werden soll. Doch was ist eigentlich die bessere Plattform, um virtualisierte Dienste anzubieten? Im Folgenden wird ein VMware Server auf demselben Rechner mit jedoch unterschiedlichen Betriebssystemen installiert und die Performance des virtuellen Systems gemessen…

Testhardware

Dies geschieht auf folgendem System (Dual-Core mit 3Ghz, 4GB RAM, VMware Server 1.0.4) und unter diesen Betriebssystemen (Windows XP 32-bit, Windows 2003 Server 64-bit, Ubuntu Gutsy Gibbon 7.10 64-bit). Als Gastsystem wird ein Windows 2000 mit den Standardeinstellungen installiert, die VMware beim Erzeugen der virtuellen Maschine vorgibt.

Tests

Die Performance des virtuellen Systems wird mit PerformanceTest von Passmark und einer speziellen Software zum Geokodieren von Ortskoordinaten und dem Berechnen der Route zwischen den Koordinaten gemessen, dem späteren Einsatzbereich des hier virtualisierten Systems. Hierfür wird besonders RAM und CPU belastet.

Im ersten Schritt wird die Performance des virtuellen Systems mit dem Benchmark-Tool gemessen. Hierfür werden nur Tests herangezogen, die für das virtuelle System von Relevanz sind. Die 3D-Leistung des Systems ist beispielsweise nicht von Interesse, da die virtuellen Maschinen derzeit noch nicht in der Lage sind, auf die für 3D optimierten Routinen der Grafikkarten zuzugreifen.

Hier zeigt sich ein recht ausgeglichenes Bild. Laut Passmark ist die CPU-Leistung unter Ubuntu etwas geringer, die 2D-Leistung der Grafik jedoch um fast 30% höher. Diesen Unterschied merkt man auch im Umgang mit der virtuellen Maschine. Fenster verschieben sich flüssiger, der ganze Desktop fühlt sich einfach nicht so langsam an, wie auf einer unter Windows laufenden virtuellen Maschine. Man könnte fast meinen man würde auf einem normalen Desktoprechner arbeiten.

Eklatant wird der Unterschied beim „Real Life“-Szenario. Die Berechnung von rund tausend Routen erfolgt unter Ubuntu doppelt so schnell wie unter beiden Windows Systemen. Anstatt über eine halbe Stunde zu rechnen, ist die Berechnung innerhalb der VM unter Ubuntu schon nach weniger als 18 Minuten beendet.

Fazit

Soll über die Einrichtung eines eigenen VMware Servers entschieden werden, so muss man die Entscheider davon überzeugen, auf Linux zu setzen. Neben den gesparten Kosten für die Lizenz eines Serversystems von Microsoft erhält man das System mit der besseren Performance.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.