Programme starten subjektiv wesentlich langsamer als unter Linux

M

Morfio

Well-Known Member
Hallo,

ich nutze jetzt seit ca. einem Jahr FreeBSD als Workstation. Was mir immer wieder auffällt, wenn ich an Linux-Workstations sitze ist, dass dort die Programme wesentlich schneller starten (bsplw. dauert es unter Ubuntu ca. eine Sekunde, bis Terminator aufgeht, unter FreeBSD ca. zehn bis fünfzehn, bei Firefox und Thunderbird und allen anderen grafischen Anwendungen ist es ebenso).

Ist das generell so oder liegt das daran, dass ich unter Ubuntu Gnome nutze (GTK) und unter FreeBSD WindowMaker? Kann man daran was machen?

Viele Grüße, Morfio
 
Hi,

muss ich widersprechen. Kollege hat aktuelles Ubuntu mit kde 4. Ich habe 8-STABLE + kde 4 + langsamere Hardware. Und die Progs gehen bei ihm im Vergleich extrem langsam auf! Auch das Feeling bei dem Ubuntu ist sehr träge.

Ist natürlich nur ein Eindruck 2er Installationen ... müsste man nachforschen warums bei ihm so lahmt, aber er ist zufrieden :)

Ich bins auch :cool:

Kai
 
Gerade mal nachgeschaut: http://www.freshports.org/x11-wm/windowmaker/
Der Windowmaker benutzt kein GTK oder irgendwelchen Gnome Kram.
Wenn man also Gnome vergleichen mag, dann sollten wohl besser komplette Gnome verglichen werden.
Wenn ich zum Beispiel unter der leichtgewichtigen Fluxbox irgendwelche KDE Bestandteile aufrufe, lädt auch erst mal jede Menge KDE Kram,
was eine gewisse Weile extra braucht. Wenn ich aber ohnehin schon KDE laufen habe, dann ist zum Beispiel der Konqueror blitzschnell da.
 
Morfio schrieb:
Hallo,

ich nutze jetzt seit ca. einem Jahr FreeBSD als Workstation. Was mir immer wieder auffällt, wenn ich an Linux-Workstations sitze ist, dass dort die Programme wesentlich schneller starten (bsplw. dauert es unter Ubuntu ca. eine Sekunde, bis Terminator aufgeht, unter FreeBSD ca. zehn bis fünfzehn, bei Firefox und Thunderbird und allen anderen grafischen Anwendungen ist es ebenso).

Ist das generell so oder liegt das daran, dass ich unter Ubuntu Gnome nutze (GTK) und unter FreeBSD WindowMaker? Kann man daran was machen?

Viele Grüße, Morfio
Zum Vergrößern anklicken....

Hallo also aus Deinem Post entnehme ich das Du gerne Gnome nutzt Eric Turgeon ist gerade dabei das umzusetzen schau mal hier >

http://ghostbsd.org/

Allerdings kann das auch noch andere Gründe die technisch bedingt sind haben aber Ferndiagnose schwierig!
Du schreibst allerdings nicht ob Du Multiboot fährst dann könnte man es schon etwas mehr eingrenzen!

Das Programm das Du ansprichst Du meinst Doch terminatorX jetzt? >
http://terminatorx.org/

http://www-stud.fht-esslingen.de/bugzilla/buglist.cgi?quicksearch=terminatorX

Das von Dir benannte Programm ist auch Bestandteil von Ubuntu soweit ich weis seit der HardyHeron also der Version 8.04 und sehr gut ins System integriert!

So zu den anderen Problemchen die Xulbasiert sind Firefox und Thunderbird nutzen den XulRunner was allerdings den Nachteil mit sich bringt das diese Programme selbst unter anderen Linuxen im Verhältnis zu Ubuntu oder Ubuntu basierten Mint -Symphony OS etc.pp sehr träge starten das ganze verstärkt sich noch je mehr Erweiterungen man nutzt!

In Ubuntu wurde der Firefox sowie der Thunderbird dem System angepasst um einen Vergleich mal zu sehen könntest Du Dir mal den

http://projects.gnome.org/epiphany/ anschauen

MFG
 
Moin,

Morfio schrieb:
Hallo,

ich nutze jetzt seit ca. einem Jahr FreeBSD als Workstation. Was mir immer wieder auffällt, wenn ich an Linux-Workstations sitze ist, dass dort die Programme wesentlich schneller starten (bsplw. dauert es unter Ubuntu ca. eine Sekunde, bis Terminator aufgeht, unter FreeBSD ca. zehn bis fünfzehn, bei Firefox und Thunderbird und allen anderen grafischen Anwendungen ist es ebenso).

Ist das generell so oder liegt das daran, dass ich unter Ubuntu Gnome nutze (GTK) und unter FreeBSD WindowMaker? Kann man daran was machen?

Viele Grüße, Morfio
Zum Vergrößern anklicken....

Das ist mir auch schon aufgefallen. Anwendungen wie OpenOffice, Thunderbird usw., die gegen GTK oder Qt gelinkt sind, benötigen unter FreeBSD i386 auffallend länger beim Erststart(!) als unter Fedora i386 (auch GTK oder Qt). Beim zweiten Aufruf sind die Unterschiede dann vernachlässigbar.
Allerdings starten die Daemon-Prozesse bei FreeBSD schneller.

JueDan
 
Also ich habe beim starten von qt/gtk Programmen noch keinen Unterschied gemerkt. Im prinzip stimmt es das sich qt schneller anfühlt weil es schneller dem Anwender ein Feedback gibt, aber von der wirklichen Geschwindigkeit sind die Unterschiede eher minimal.

Ich selbst hatte unter Gnome/Xfce auch mal die erscheinung das Programme ewig brauchten zum starten, der Fehler war ein falsch eingerichtetes Netzwerk. Durch einen Fehler in der Namensauflösung dauerte das starten ewig. Schau mal ob es daran liegen könnte.

Das Problem was du beschreibst besteht nur bei grafischen Programmen und auf der Konsole klappt alles? Liegt es evtl. an einem schlechten Grafiktreiber, falsch eingerichteten Xorg?

Grüße
 
Hi,

ich nutze letztlich einen GENERIC-Kernel, zwar selbst kompiliert, aber nichts geändert.

Mit Terminator meine ich den Terminal-Emulator, der mehrer Terminals gesplittet darstellen kann.

Mal so pi*Daumen Starts (in Sekunden) (Ubuntu 10.04 zu FreeBSD 8.1);

Thunderbird: 2 zu 6 (zweiter Start)
Avidemux: 2 zu 5 (erster Start)
Pidgin: 1 zu 3 (zweiter Start)

Besonders fällt dieses Verhalten auf, wenn man zwei oder mehr Programme direkt hintereinander startet. Sobald Festplattenaktionen im Spiel sind (und das habe ich jetzt auf etlichen Rechnern mit IDE, SATA, SCSI, RAID) festgestellt, geht die Geschwindigkeit tierisch runter, bis Programme gestartet werden. Unter Linux ist das nicht so.
Wir haben damals herausgefunden, dass mallocs unter FreeBSD wesentlich länger dauern als unter Linux, vielleicht hat es auch damit zu tun. Kann es auch sein, dass der IO-Scheduler eher nicht auf solche Dinge optimiert ist?

Viele Grüße, Morfio
 
Aaalso... Das gibt da einige Dinge, die "Schuld" sein können. Erst einmal ist FreeBSD noch immer ein System, was sich in Voreinstellung in erster Linie an Server richtet. Dann sind einige dieser Voreinstellungen auch dort einfach bescheiden. Abschließend ist FreeBSDs IO nach wie vor leider weniger Duchsatzstark als das von Linux, wobei die praktische Relevanz in den letzten Jahren stark gesunken ist. Aber einmal 3 sehr konkrete Tipps:

1. UFS benötigt für den effizienten Zugriff auf Verzeichnisse sogenannte Dirhashes. Das sind Hash-Strukturen im RAM, die die linieare Struktur des Dateisystems abbilden. Normalerweise werden dafür 2 Megabyte reserviert, dass ist eindeutig zu wenig. Gerade die Personen, die sehr große Partitionen nutzen, werden davon gebissen. Also das Ganze drastisch erhöhen: "sysctl vfs.ufs.dirhash_maxmem=134217728". Das sind dann 128 Megabyte, nach dem Motto viel hilf viel.

2. Bei allen statischen Speichermedien ist jeder Zugriff teuer. Es bietet sich also an Zugriffe zu minimieren. In der Standardeinstellung ließt FreeBSD immer mindestens 8 Blöcke ein. Das ist bei heutigen Platten zu viel wenig, in 9-CURRENT wurde es daher auf 32 erhöht. Man sollte es auch auf den 8.x Kisten umstellen: "sysctl vfs.read_max=32".

3. FreeBSD besitzt keinen "echten" IO-Scheduler. Gerade bei parallelen Zugriffen tut das weh. Es gibt seit 8.1 aber die GEOM-Klasse "gsched" die genau diese Aufgabe übernimmt. Jeder, der Durchsatzprobelem hat, sollte sich daher einmal "man gsched" durchlesen und damit ein wenig spielen. Meine Testläufe waren sehr beeindruckend, alles was man über FreeBSDs IO nörgeln kann, war danach verschwunden.

Davon einmal abgesehen sind viele Dinge zwischen Linux und FreeBSD sehr abhängig von der spezifischen Last, die man ans System anlegt. Der Linux-Malloc kann einige Sachen besser, der FreeBSD-Malloc aber auch. Unter FreeBSD sind Kontextwechsel aufwändiger als unter Linux, dafür sind Pipes wieder schneller.. Ich hoffe, es hilft ein wenig. :)
 
Morfio schrieb:
Hi,

ich nutze letztlich einen GENERIC-Kernel, zwar selbst kompiliert, aber nichts geändert.

Mit Terminator meine ich den Terminal-Emulator, der mehrer Terminals gesplittet darstellen kann.

Mal so pi*Daumen Starts (in Sekunden) (Ubuntu 10.04 zu FreeBSD 8.1);

Thunderbird: 2 zu 6 (zweiter Start)
Avidemux: 2 zu 5 (erster Start)
Pidgin: 1 zu 3 (zweiter Start)

Besonders fällt dieses Verhalten auf, wenn man zwei oder mehr Programme direkt hintereinander startet. Sobald Festplattenaktionen im Spiel sind (und das habe ich jetzt auf etlichen Rechnern mit IDE, SATA, SCSI, RAID) festgestellt, geht die Geschwindigkeit tierisch runter, bis Programme gestartet werden. Unter Linux ist das nicht so.
Wir haben damals herausgefunden, dass mallocs unter FreeBSD wesentlich länger dauern als unter Linux, vielleicht hat es auch damit zu tun. Kann es auch sein, dass der IO-Scheduler eher nicht auf solche Dinge optimiert ist?

Viele Grüße, Morfio
Zum Vergrößern anklicken....

Hallo Morfio,

erst mal danke für Deine Antwort zuerst ist es generell mal so das native Anwendungen wesentlich schneller starten als Nicht-Native Anwendungen

zur Erklärung >

http://www.apfeltalk.de/forum/was-bedeutet-nativ-t70058.html

Thunderbird Firefox sind keine native Anwendungen sondern setzen auf XulRunner auf !

http://de.wikipedia.org/wiki/XULRunner

was zwar ein einheitliches Interface unter den Verschiedensten Betriebssystemumgebungen gewährleistet ähnlich Java Look and Feel aber halt Performance Nachteile mit sich bringt die auch je nach Betriebssystemarchitektur unterschiedlich ausfallen!

So gibt es auch Unterschiede hierzu selbst unter den unterschiedlichen GnuLinux Distris unter PcLinuxOs startet bei mir Firefox Thunderbird wesentlich langsamer als unter Mint sowohl in der 8er als auch 9er Version. Besonders langsam starten der Feuerfuchs und Konsorten unter Mandrake basierten Systemen.

Ich schrieb Dir ja schon das Eric gerade dabei ist Gnome auf FreeBSD zu bringen Stichwort GhostBSD und da kommen wir zu den Punkt das QT besser in FreeBSD integriert als GTK und Avidemux kannst Du auch mit dem QT Interface nutzen was Dir Zeitvorteile bringen dürfte....

Dann seit etwa 2 Jahren kommt in Ubuntu cmake zum Einsatz was Performance Vorteile gegenüber den alten make bringt...
Ubuntu Entwickler arbeiten zum größten Teil mit cmake

http://www.avidemux.org/admWiki/doku.php?id=build:compiling_avidemux

https://launchpad.net/ubuntu

Gleiches gilt analog für Pidgin

http://developer.pidgin.im/wiki/SummerOfCode2010

So aber das alles ist nur eine Seite der Medaille denn auch das Dateisystem spielt hier eine wesentliche Rolle wie auch Yamagi angemerkt hat.
Dann auch welche Dienste alles bei Dir am Start sind kann ja durchaus unterschiedlich sein das kann ich so aus der Ferne nicht beurteilen.

Zu Testzwecken nutze ich die unterschiedlichsten Betriebssysteme Windows GnuLinuxe Mac*s Unixe und auch Just 4 Fun Haiku Alpha2 und hier habe ich eine höhere Performance dank BFS bzw. OpenBFS als zum Beispiel mit Ext4 unter Ubuntu

http://de.wikipedia.org/wiki/Be_File_System
http://de.wikipedia.org/wiki/Ext4

Übersicht Filesysteme Infos

http://en.wikipedia.org/wiki/Comparison_of_file_systems

http://arstechnica.com/open-source/news/2010/06/the-beos-filesystem.ars

Dateisysteme>

http://www.amazon.com/exec/obidos/A...4537/sr=8-1/ref=sr_8_71_1/103-9130044-4352613

MFG
 
Zuletzt bearbeitet:
Yamagi schrieb:
Aaalso... Das gibt da einige Dinge, die "Schuld" sein können. Erst einmal ist FreeBSD noch immer ein System, was sich in Voreinstellung in erster Linie an Server richtet. Dann sind einige dieser Voreinstellungen auch dort einfach bescheiden. Abschließend ist FreeBSDs IO nach wie vor leider weniger Duchsatzstark als das von Linux, wobei die praktische Relevanz in den letzten Jahren stark gesunken ist. Aber einmal 3 sehr konkrete Tipps:

1. UFS benötigt für den effizienten Zugriff auf Verzeichnisse sogenannte Dirhashes. Das sind Hash-Strukturen im RAM, die die linieare Struktur des Dateisystems abbilden. Normalerweise werden dafür 2 Megabyte reserviert, dass ist eindeutig zu wenig. Gerade die Personen, die sehr große Partitionen nutzen, werden davon gebissen. Also das Ganze drastisch erhöhen: "sysctl vfs.ufs.dirhash_maxmem=134217728". Das sind dann 128 Megabyte, nach dem Motto viel hilf viel.

2. Bei allen statischen Speichermedien ist jeder Zugriff teuer. Es bietet sich also an Zugriffe zu minimieren. In der Standardeinstellung ließt FreeBSD immer mindestens 8 Blöcke ein. Das ist bei heutigen Platten zu viel wenig, in 9-CURRENT wurde es daher auf 32 erhöht. Man sollte es auch auf den 8.x Kisten umstellen: "sysctl vfs.read_max=32".

3. FreeBSD besitzt keinen "echten" IO-Scheduler. Gerade bei parallelen Zugriffen tut das weh. Es gibt seit 8.1 aber die GEOM-Klasse "gsched" die genau diese Aufgabe übernimmt. Jeder, der Durchsatzprobelem hat, sollte sich daher einmal "man gsched" durchlesen und damit ein wenig spielen. Meine Testläufe waren sehr beeindruckend, alles was man über FreeBSDs IO nörgeln kann, war danach verschwunden.

Davon einmal abgesehen sind viele Dinge zwischen Linux und FreeBSD sehr abhängig von der spezifischen Last, die man ans System anlegt. Der Linux-Malloc kann einige Sachen besser, der FreeBSD-Malloc aber auch. Unter FreeBSD sind Kontextwechsel aufwändiger als unter Linux, dafür sind Pipes wieder schneller.. Ich hoffe, es hilft ein wenig. :)
Zum Vergrößern anklicken....

Hi Yamagi,


Kurze Frage zu Geom Sched:
Kann man den auch für ZFS nutzen ?

Bzw.: Wenn der Provider (ad0) mit ZFS läuft, kann der Sched da noch Performance rausholen, bzw. Funktioniert das zusammen ?


Grüße
 
Ja, tut es. gsched ist ja eine GEOM-Klasse, sie liegt damit unterhalb der Dateisysteme. Es bringt bei ZFS nicht so viel wie bei UFS2, aber es ist noch messbar. :)
 
Hi,

vielen Dank für die Antworten.

@Yamagi Ich werde das mit den Werten und gsched mal ausprobieren und berichten.

Morfio
 
Kann es sein, dass die gsched Klasse gsched_as in 8.1-STABLE noch nicht drin ist?
In der gsched Manualpage wird sie beschrieben im Example wird sie aufgeführt.
Mein FreeBSD 8.1-STABLE, bei dem ich zuletzt gestern Abend world und kernel frisch gebaut habe, will von der gsched Klasse gsched_as nichts wissen.
ls -la /boot/kernel/gsched* sagt auch nur:
Code: 
ls -la /boot/kernel/gsched*

-r-xr-xr-x  1 root  wheel  12648  7 Okt 02:20 /boot/kernel/gsched_rr.ko

Ich habe daher experimentierfreudig dann nur folgendes mal zum ausprobieren gemacht:
in die /boot/loader.conf das hier reingesetzt:
Code: 
gsched_rr_load="YES"
Und folgendes Script als /etc/rc.d/gsched:
Code: 
#!/bin/sh
#-------------------------------------------------------------------------------
# Take it from here: 
# http://forums.freebsd.org/showthread.php?t=16489
# Thank you lily
#-------------------------------------------------------------------------------

# REQUIRE: FILESYSTEMS
# PROVIDE: geom_rr

. /etc/rc.subr

name=geom_rr

start_cmd=${name}_start
stop_cmd=:

geom_rr_start() {
        geom sched insert -a rr ada0
###        geom sched insert -a rr ada1
}

run_rc_command "$1"
Schamlos von da kopiert:
http://forums.freebsd.org/showthread.php?t=16489
Ich habe nur eine SSD drin, die ich mit dem ahaci Treiber benutze.

gsched list sagt jetzt:
Code: 
gsched list

Geom name: ada0.sched.
Providers:
1. Name: ada0
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r4w4e9
Consumers:
1. Name: ada0.sched.
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r4w4e9
 
Ich habe mal mit dem Entwickler von gsched einen Mail-Austausch, was ein guter Weg ist gsched beim Boot zu aktivieren. Momentan mache ich das tatsächlich von /etc/rc.local aus.

Meine Schluss daraus ist, dass die Information direkt auf dem Datenträger liegen sollte (also, dass gsched erwünscht ist und welcher Algorithmus verwendet werden soll). Denn nur dort kann man unmissverständlich den zur Hardware passenden Algorithmus ablegen. Nur implementieren müsste es jemand. :)

Ich habe inzwischen genug im geom-Code gewühlt (wegen automounter) um das zu machen aber pkg_upgrade ist immer noch nicht fertig.
 
Ich kann dir verraten, dass es auf jeden Fall deutlich schneller ist.

Hast du mal mit der aktuellen Version ein pkg_upgrade -ncfrRrR www/firefox probiert? Bei mir dauert das Preprocessing da über 6 Minuten.

Die Entwicklerversion macht das komplette Preprocessing (Abhängigkeiten auflösen, sortieren) in deutlich unter 2 Minuten.

Der Hintergrund-Downloader ist auch deutlich cleverer geworden und scheint hervorragend zu funktionieren. ...

Naja, ich hebe mir das für den Vortrag auf. Vielleicht schaffe ich ja noch rechtzeitig etwas für den FreeBSD Status Report rauszuhauen.
 
Wird schon, uma erkennt jetzt automatisch, wenn PACKAGESITE auf einen lokalen Ordner zeigt, dann zeigen PKG_INDEX, PKG_MOVED und PKG_UPDATING direkt ins lokale repository und werden nicht mehr heruntergeladen.

Auch PACKAGESITE_MIRRORS bleibt dann leer. Auch wenn man PACKAGESITE_MIRRORS leer definiert, wird das von uma nicht mehr mit den Standardmirrors aufgefüllt. pkg_upgrade hat den nötigen Read-only Support für lokale Repositories (es versucht nicht herunterzuladen, wenn die Pakete da sind und die Abhängigkeiten in den Paketen zum INDEX passen).

Was noch fehlt ist das Tool zum INDEX generieren.
 
Gerade bei KDE-Programmen könnte auch relevant sein, dass sie kein Speicher teilen können und deswegen viel verschwenden. Dazu vor kurzem auf kde-freebsd@
At Thu, 09 Sep 2010 17:06:47 +0300,
Andriy Gapon wrote:
>
>
> I've just upgraded to kde-4.5.1 and during startup it spits out a lot of messages
> like the following:
>
> KSharedDataCache::Private::mapSharedMemory: Failed to establish shared memory
> mapping, will fallback to private memory -- memory usage will increase
>
> Is this something to worry about?
> What causes these messages? Perhaps some local misconfiguration on my part?

KSharedDataCache has been mostly rewritten for the 4.5 release, and
the new code relies on _POSIX_THREAD_PROCESS_SHARED being correctly
defined and implemented, which is not the case on FreeBSD.

Alberto Villa (xzhayon) was interested in working on that in a few
weeks time, but any help from the core team wrt implementing this part
of pthreads would be really appreciated.
Zum Vergrößern anklicken....

Und dann kurz darauf schon die gute Nachricht, dass etwas mit Semaphoren implmentiert wurde:
ok, i had the patch committed in rev. 1181777. i'll wait for another
modification to make it into svn, then i'll patch kdelibs 4.5.2

unfortunately that will work only with 9-current, so i'll also write a
temporary hackish implementation for 7 and 8 users
Zum Vergrößern anklicken....
 
Hi,

koennten die Leute, die gsched im (Dauer)einsatz haben, hier evtl. kurz Feedback geben. Mich stoert die diskutierte Zaehheit naemlich auch ein wenig. Bis auf Kamikazes Post, aus dem ich auf dauerhaften Einsatz schliessen kann(?), kann ich aus den anderen Antworten nur "mal getestet" und "herum experimentiert" heraus lesen.
Konkret interssiert mich, ob man gsched schon produktiv einsetzen kann ohne dabei Angst um seine Daten haben zu muessen (ist ja erst neu in 8.1)?. Kann ich das auch mal eben einfach so mitten im Betrieb an- und ausschalten, wie es die Manpage suggeriert? Oder doch nur lieber beim Booten? In beiden Faellen habe ich ja keine direkte Kontrolle mehr darauf, was und wieviel alles an die Platte geschickt wird und sehe also, ganz naiv betrachtet, erstmal keinen Unterschied zwischen den beiden Szenarien.

Speziell @Kamikaze: Kam bei dem erwaehnten Mail-Austausch evlt. auch noch etwas mehr zu dem Thema "geom_sched influence on SU consistency", das du vor einer Weile mal auf stable@ angesprochen hast, rum?

teuk
 
teuk schrieb:
Hi,

koennten die Leute, die gsched im (Dauer)einsatz haben, hier evtl. kurz Feedback geben.
Zum Vergrößern anklicken....

Ich habe gsched ja gestern Abend das erste mal aktiviert, Dauereinstatz wäre also übertrieben, aber seitdem lasse ich gsched laufen.
Mir ist aufgefallen, dass mein System beim locate Datenbank aufbauen geschmeidiger lief.

In der /etc/sysctl.conf habe ich das schon länger drin, was Yamagi weiter oben erwähnte:
Code: 
# For AHCI and NCQ
vfs.read_max=32
# More memory for dirhashes
vfs.ufs.dirhash_maxmem=134217728

Beim benutzen von rm mit dem P Schalter für viele große Dateien scheint gsched auch für verbesserte Geschmeidigkeit zu sorgen.
 
teuk schrieb:
Speziell @Kamikaze: Kam bei dem erwaehnten Mail-Austausch evlt. auch noch etwas mehr zu dem Thema "geom_sched influence on SU consistency", das du vor einer Weile mal auf stable@ angesprochen hast, rum?
Zum Vergrößern anklicken....
Ja, da kam noch etwas bei rum.

Gsched lügt nicht über erfolgte Writes, also wird die SU Konsistenz auch nicht unterwandert.

Ich habe die Sache auch mal intensiver gestestet, gsched auf einen USB-Stick losgelassen und den im gemounteten Zustand abgezogen. Sogar das ging. Danach habe ich das beim Schreiben einer Datei wiederholt, hat das System auch nicht in eine Panic gerissen. Das Dateisystem brauchte natürlich ein fsck, aber sonst war es in Ordnung.

Und ja, ich habe das auf allen meinen Rechnern im Dauereinsatz, allerdings nur bei den fest eingebauten Platten.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben