christian83
Well-Known Member
Mhh dann warte ich lieber noch 4 Versionen 
FreeBSD 10.0 erschienen
- Ersteller Yamagi
- Erstellt am
h^2
hat ne Keule +1
hier gibts automatisiert neue Pakete:
https://wiki.freebsd.org/i386-Wine
Allerdings leider noch nicht für 10.0, aber ich hab mal nachgefragt wann die kommen.
h^2
hat ne Keule +1
Jetzt auch für FreeBSD10 und CURRENT
namor
Imperator
Jetzt auch für FreeBSD10 und CURRENT
Wo? Auf dem FTP auf der Wiki Seite gibt's noch kein freebsd:10:... Verzeichnis.
namor
Imperator
So:
Code:pkg install i386-wine
Oh, wow, haha!
So ganz ohne gefummel. Ich installier dann mal. :-)
Elwood
Naiver Mutmaßlicher
Moin, warum wird eigentlich converters/libiconv immer von einigen Ports benötigt (glib20), wenn libiconv zur Base gehört?
Okay.. Frage zurückgezogen, die Antwort findet sich im Makefile vom glib20-Port:
Okay.. Frage zurückgezogen, die Antwort findet sich im Makefile vom glib20-Port:
Code:
# iconv:wchar_t - our iconv in base doesn't support utf-8 -> wchar_t (boooo)
# (wchar_t is used by glibmm, rawtherapee triggered this)Nur weil's mir gerade auffällt: vm.kmem_size entspricht der Größe meiner Memory. Heißt das, dass ich habe jetzt wirklich den kompletten RAM als Kernel Memory zur Verfügung und kann sie auf Routern oder sie sagen wir zum Beispiel potentiell für den pf State Table nutzen?
EDIT: Oder habe ich das nur extrem verschlafen und es ist seit FreeBSD 8 der Fall?
EDIT: TCM's Kritik entsprechend den Artikel von Speicher geändert.
EDIT: Oder habe ich das nur extrem verschlafen und es ist seit FreeBSD 8 der Fall?
EDIT: TCM's Kritik entsprechend den Artikel von Speicher geändert.
Zuletzt bearbeitet:
Kommt auf deine Plattform drauf an. vm.kmem_size gibt die Größe des virtuellen Adressraums des Kernels an. Das ist hauptsächlich der Heap des Kernel, ein Großteil alles dynamisch allozierten Speichers im Kernel liegt darin. Auf 32 Bit Plattformen ist das Problem, dass der virtuelle Adressraum sehr begrenzt ist. vm.kmem_size kann daher nur einen Bruchteil des gesamt verfügbaren Adressraums und damit heute meist auch physisch vorhandenen Speichers abdecken. Das führt grob gesagt zu zwei Problemen. Einmal zu zu wenig Speicher für speicherintensive, im Kernel laufende Anwendungen wie ZFS. Dazu unter Umständen zu einer Fragmentierung des Kernelspeichers, die früher oder später bis zur Kernelpanic degeneriert. Auf 64 Bit Plattformen hat man das Autotuning des virtuellen Adressraums des Kernel seit FreeBSD 8.0 nach und nach immer aggressiver gemacht, bis er inzwischen einen Großteil des RAMs abdeckt. Daher kannst du nun, sofern pf virtuelle Adressen nutzt, deinen Statetable tatsächlich einen Großteil des RAMs belegen lassen.
vm.kmem_size gibt die Größe des virtuellen Adressraums des Kernels an. Das ist hauptsächlich der Heap des Kernel, ein Großteil alles dynamisch allozierten Speichers im Kernel liegt darin. Auf 32 Bit Plattformen ist das Problem, dass der virtuelle Adressraum sehr begrenzt ist. vm.kmem_size kann daher nur einen Bruchteil des gesamt verfügbaren Adressraums und damit heute meist auch physisch vorhandenen Speichers abdecken. Das führt grob gesagt zu zwei Problemen. Einmal zu zu wenig Speicher für speicherintensive, im Kernel laufende Anwendungen wie ZFS. Dazu unter Umständen zu einer Fragmentierung des Kernelspeichers, die früher oder später bis zur Kernelpanic degeneriert. Auf 64 Bit Plattformen hat man das Autotuning des virtuellen Adressraums des Kernel seit FreeBSD 8.0 nach und nach immer aggressiver gemacht, bis er inzwischen einen Großteil des RAMs abdeckt. Daher kannst du nun, sofern pf virtuelle Adressen nutzt, deinen Statetable tatsächlich einen Großteil des RAMs belegen lassen.