Re: Fragen zu Ungereimtheiten mit FreeBSD 7.0 und anhängiger Software

Polytropon <freebsd(at)edvax.de> wrote:
> Ähnlich geht es mir auch, ich versuche, ein Siemens-Fujitsu-
> Notebook, das eine neue Platte spendiert bekommen hat, als
> portables Programmiergerät zu gestalten. Es hat einen 500-MHz-
> AMD-Prozessor und 512 MB RAM, aber eben nur 800x600 als Display.

Was natürlich ein generelles Problem ist ... Viele aktu-
elle Webseiten sind auf 1024x768 »optimiert«, und auch
eine Reihe von Anwendungen geht davon aus, dass man min-
destens 1024x768 hat.

Um ehrlich zu sein, ich kann das bei Anwendungen mit gra-
phischem Schwerpunkt (z.B. Gimp) ganz gut nachvollziehen.
Photoshop, CorelDraw o.ä. machen bei niedrigen Auflösungen
auch nicht richtig Spaß.

> Das Teil lief immer gut und ist dank der neuen Platte nun auch
> akustisch erträglich (die alte machte Geräusche wie eine Kreis-
> säge). Übrigens auf diesem Gerät erschien der Compilierungsfehler
> von mplayer (wie später diskutiert).

Hmm ... Bei so einem Rechner (500 MHz, 800x600) würde
ich eher auf das GTK-GUI von mplayer/mencoder verzichten,
was ja auch offenbar ursächlich für den Compilierungsfehler
war (indirekt).

> > > Da die Kiste tadellos funktioniert, gedenke ich auch nicht, mir
> > > was neues zu kaufen, weder mein Gehalt noch meine moralischen
> > > Vostellungen würden einen solchen Schritt rechtfertigen. :-)
> >
> > Verständlich. Den technischen Daten nach sollte die Kiste
> > für normale Anwendungen vollkommen ausreichen.
>
> Für normale Anwendung? Ich hab bisher *alles* mit dieser Kiste
> gemacht, beginnend mit C/Gtk-Programmierung, über LaTeX bis hin
> zu digitaler Videobearbeitung und DVD-Mastering, alles ohne
> Probleme.

Ja, das alles würde ich zu »normale Anwendungen« rechnen.
Alles das (oder Vergleichbares) mache ich auch auf einer
ähnlich ausgestatteten Kiste.

> > Eine Frage: Verwendest Du 7.0-Release, oder 7-stable (d.h.
> > RELENG_7, *nicht* RELENG_7_0)?
>
> Ich habe 7.0-RELEASE, auf dem 2. Rechner 7.0-RELEASE-p2 (glaube
> ich), da meine Update-Funktion in RELEASE-Strang bleibt; -STABLE
> hat eher experimentellen Charakter (wenngleich nicht so "bleeding
> edge" wie -CURRENT).

So würde ich das nicht formulieren; -stable hat keinen
experimentellen Character. Selbst -current ist heutzutage
vergleichsweise stabil, da die meisten experimentellen
Dinge vorher in Perforce-Zweigen (zukünftig Subversion)
getestet werden.

In -stable wiederum landen nur Dinge, die vorher hinrei-
chend lange in -current getestet wurden. Es kommt nur
sehr selten vor, dass mal etwas in -stable »bricht«, und
wenn das passiert, wird es i.allg. sehr schnell gefixt.

Als Faustregel würde ich behaupten, dass, wenn in der
stable-Mailingliste alles ruhig ist, ein aktuelles -stable
genauso stabil ist wie eine Release. Und da in -stable
laufend Bugs gefixt werden (im Gegensatz zum Security-
Branch, den Du RELEASE-Strang genannt hast), würde ich
es jederzeit gegenüber der Release vorziehen. Ich habe
fast immer nur -stable verwendet und hatte nie Probleme,
allerdings ist das Verfolgen der stable-Mailingliste dann
Pflicht, zumindest zu dem Zeitpunkt, zu dem man ein Update
plant.

Es einige Leute (auch Firmen), die bei einem anstehenden
Update in stable-Liste gucken, und wenn dort alles ruhig
ist, auf das -stable von vorgestern oder letzter Woche
updaten. Auf diese Weise kriegt man Code, der bei den
meisten anderen schon eine gewisse Zeit problemlos läuft.

Natürlich kann es theoretisch immer passieren, dass es
trotzdem irgendeinen obskuren Bug gibt, von dem man be-
troffen ist. Eine Garantie gibt es nie, auch nicht bei
den Releases.

Langer Rede kurzer Sinn: Ich würde Dir empfehlen, auf
7-stable (RELENG_7, _nicht_ RELENG_7_0) zu updaten.

Dort ist übrigens auch SCHED_ULE bereits der Default (es
wurde schon kurz nach der Release umgestellt).

> Dieser Empfehlung werde ich alsbald folgen und auch den gesamten
> Programmstand nochmal neu einspielen, wobei ich ein Augenmerk
> auf die Zeitkomplexität haben werde. Der neue cc optimiert ja
> mehr, was sich in diesen Zeiten niederschlägt: buildworld dauert
> 11457.047u 2151.158s 3:54:15.31 96.8%, buildkernel mit KERNCONF
> dauert 3289.368u 529.669s 1:05:25.90 97.2%. Die install* sind
> mir zeitmäßig egal.

Du könntest mal einen Blick in src.conf(5) werfen. Dort
kannst Du einige Dinge disablen, wodurch das buildworld
etwas verkürzt wird. Z.B. nehme ich an, dass Du Dinge
wie Kerberos, ATM, NIS oder I4B nicht benötigst.

> Gute Idee, tausche ich dann auch gleich mal aus. Richtig, ich
> habe, ausgehend vom 7.0er GENERIC eine neue Kernelkonfiguration
> erstellt. Das ist so eine Macke: Ich habe gern einen Kern, der
> genau für das System gedacht ist, das er am Laufen halten soll.
> Alles, was er braucht, bekommt er direkt eingebacken, also kein
> Nachladen von Modulen.

Die Mühe mache ich mir nur auf Rechnern mit sehr wenig RAM,
wo die Größe des Kernels von Bedeutung sein kann. Anson-
sten ist es das einfachste, wenn man in seiner eigenen
Kernel-config GENERIC included und dann lediglich ein paar
Sachen hinzufügt oder löscht (per nooption, nodevice usw.),
die man benötigt bzw. die man keinesfalls haben möchte.

Übrigens, einige Sachen sollte man nicht statisch in den
Kernel eincompilieren, weil es nicht offiziell supportet
wird oder schlichtweg nicht funktioniert. Insbesonderer
Die Linux-ABI und ACPI sollte man ausschließlich als Modul
verwenden.

> > Schuld ist letzlich das Gerät.
>
> Und das sagt der Mann über schweineteure Sun-Hardware! :-)

Nicht alles, was von SUn kommt, ist gut. Ich denke da
z.B. an die alten Ultra5/Ultra10, die im Grunde nichts
weiter waren als normale PCs (und genauso billig verar-
beitet) mit einer UltraSparc-CPU. Und das ganze zum
üblichen Sun-Preis. ;-)

> Naja, die beste Qualität bei Tastaturen ist und bleibt das
> Klappermonster von IBM ohne Werbetasten. :-)

Bzgl. Qualität gebe ich Dir recht (habe auch eine).
Allerdings vermisse ich die »Werbetasten«, da ich da
normalerweise diverse nützliche X11-Modifier drauflege.

> > > In Deutschland hat man ja auch gern deutsche Tastaturunter-
> > > stützung.
> >
> > Dazu kann ich leider nicht viel sagen, da ich US-Belegung
> > vorziehe. Eine speziell abgewandelte US-Belegung, mit der
> > ich auch deutsche und andere Sonderzeichen bequem erreichen
> > kann, setze ich per keymap="..." in /etc/rc.conf.
>
> Eine ähnliche Bequemlichkeit bietet die Compose-Taste der Sun-
> Tastatur.

Da gehen unsere Meinungen wohl etwas auseinander ... Eine
Compose-Taste finde ich eher umbequem, da man da nacheinan-
der drei Tasten drücken muss, um ein bestimmtest Zeichen zu
erhalten. Das finde ich eher unergonomisch.

> Mit XFree86 war die ATI Radeon eigentlich sehr gut, auch OpenGL-
> Anwendungen (in Form einschlägiger Spiele und Mesa-Zeux, auch
> gern xlock -nolock -mode { lament | gears | fire }) waren kein
> Thema.
>
> Eine Beschwerde, die ich häufig lesen muß, lautet:
>
> libGL warning: 3D driver claims to not support visual 0x6b
>
> Sagt mir so jetzt aber auch nix ausm Hut...

Mit »xpdyinfo« kannst Du alle Visuals auflisten, die unter-
stützt werden, und »xdriinfo« sagt Dir, ob und welcher DRI-
Treiber installiert ist. Natürlich solltest Du dri und
libdrm installiert haben, und im Kernel die enstprechenden
Treiber haben (bei mir »device drm« + »device i915drm«).

> > Bei mir weniger als 2 Sekunden. Welche(n) Treiber hast Du
> > installiert? --> pkg_info | grep xf86-video
>
> xf86-video-ati-6.7.195 X.Org ati display driver
>
> Daneben sind noch welche für i810, nv, vesa, vga und via
> installiert, aber die habe ich ja alle nicht.

Dann solltest Du die alle deinstallieren.

> > Falls mehr als einen, entferne bitte alle, die Du nicht
> > brauchst. Möglicherweise ruft der X-Server beim Starten
> > die Probe-Routinen aller Treiber auf, was natürlich eine
> > Weile dauert.
>
> Sollte er eigentlich nicht. Wenn mich meine (sicherlich veralteten)
> Kenntnisse von xorg.conf (ex XFree86Config) nicht enttäuschen,
> kann der zu ladende Treiber explizit benannt werden (Driver "ati"),
> dann wird auch kein anderer versucht.

Da bin ich mir nicht so sicher. Xorg enthält eine Menge
Pseudo-Intelligenz. Ich würde dem alles zutrauen.

> Aber vielleicht ist die
> Radeon RV250 einfach zu alt für das neue X.org?

Ich kann mir kaum vorstellen, dass irgendeine Karte zu alt
sein kann, wo sogar meine alte Tseng ET4000-W32 noch geht.

> > Xorg-Configuration und das Xorg-Logfile anschauen, um das
> > näher zu untersuchen. Ohne weitere Infos kann man da
> > leider nicht helfen.
>
> Achtung, jetzt kommt eine Datei:
> [...]

Sieht soweit OK aus.

> Ach, und wo ich grad beim Thema bin: Für die explizite Abschaltung
> des DPMS scheint sich X auch nicht zu interessieren, der Monitor
> geht nach einigen Minuten aus - sehr lästig, so man mal einen Film
> schauen will.

Was sagt »xset q«? Hast Du mal »xset s off« probiert?

> > Du solltest auf jeden Fall mal prüfen, dass Dein X-Server
> > tatsächlich den betreffenden Hardware-Treiber verwendet
> > und nicht etwa den VESA-Treiber. Letzteres könnte evtl.
> > einige der Symptome erklären.
>
> Den VESA-Treiber verwendet er nicht. /var/log/Xorg.0.log sagt
> dazu:
>
> (II) LoadModule: "ati"
> (II) Loading /usr/local/lib/xorg/modules/drivers//ati_drv.so
> (II) Loading sub module "radeon"
> (II) LoadModule: "radeon"
> (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so

Und »grep -i vesa /var/log/Xorg.0.log« sagt nichts?

> > Ist mir ein Rätsel. Hast Du lpt(4) fest im
> > kernel oder als Modul geladen?
>
> Kernel.

OK. Wie gesagt, ich habe keine Erklärung dafür.

Meinen Laserdrucker habe ich mit einem kleinen Parallel-
port-Netzwerk-Dongle (gibt's recht günstig bei pearl.de)
an mein Netzwerk angeschlossen. Hat den Vorteil, dass
man von mehreren Rechnern aus auf den Drucker zugreifen
kann, oder dass man sich Gedanken darum machen muss, einen
Printserver selbst zu basteln. Evtl. wäre das ja auch
eine Möglichkeit für Dich.

> Hier 9.26. Nur ungern aktualisiere ich Software (ausgenommen
> sicherheitsrelevante Dinge wie bei SSH, Apache u. dgl.), wenn
> sie einmal drauf ist.

Geht mir eigentlich ähnlich, aber ich betrachte auch einen
Web-Browser als sicherheitsrelevant. Ich gehe davon aus,
dass in jeder Opera-Release auch Security-Bugs gefixt wur-
den. Es gibt ja imemr mal wieder irgendwelche Kleinig-
keiten, die z.B. Cross-Site-Skripting erleichtern, und
ähnlicher Krempel.

> > > Es produziert sogar Systemlasten von bis zu 100%, dann
> > > geht nix mehr.
> >
> > Huch. Das passiert bei mir nur, wenn eine Flash-Anwendung
> > mal in eine Endlosschleife gerät und 100% CPU verbrät, was

Ich vergaß zu erwähnen: Mit JavaScript kann das natürlich
ebenso passieren wie mit Flash.

> > aber am Flash liegt und nicht am Opera (aus diesem Grund
> > habe ich Flash auch nur für wenige, ausgewählte Sites
> > enabled).
>
> Mit "Flash" befasse ich mich auf FreeBSD-Basis gar nicht (dafür
> habe ich ein iBook), die Unterstützung ist einfach zu mies.

Ich stimme Dir zu, dass es da Verbesserungspotential gibt.

Flash7 läuft zwar sowohl mit FreeBSD- als auch Linux-
Browsern recht stabil, allerdings reicht Flash7 inzwischen
für einige Sites nicht mehr aus. Und Flash9 ist sowohl
unter FreeBSD als auch Linux nicht besonders stabil.

YouTube-Videos u.ä. kann man mit separaten Tools herunter-
laden (z.B. ports/www/youtube_dl) und dann z.B. mit mplayer
abspielen.

Eine weitere Möglichkeit ist, die Windows-Version von Opera
(oder Firefox) mit Hilfe von Wine (ports/emulators/wine)
laufen zu lassen. Auf diese Weise kann man das aktuelle
Flash-Plugin (Windows-Version) verwenden.

> Das soll keine Kritik an FreeBSD sein, sondern an proprietärem
> Krempel, der im Grunde den Status eines animierten GIFs hat,
> auch exzessiv so verwendet wird, aber nicht frei und offen ist

Nunja, die Flash-Spezifikation ist (iznwischen) öffentlich.
Es gibt ja auch eine GNU-Implementation von Flash, aller-
dings ist die noch nicht so weit fortgeschritten, dass sie
praxistauglich wäre.

> > Verwendest Du den native Opera oder Linux-Opera? Wenn
> > letzteres, hast Du eine aktuelle Linux-Umgebung (d.h.
> > den entsprechenden linux_base-Port)?
>
> Seit Opera für FreeBSD nativ verfügbar ist, lieber dieses:
>
> opera-9.26.20080215

Hm, OK. Ich verwende linux-opera. Ich weiß aber nicht,
ob das im vorliegenden Fall irgendeinen Unterschied machen
würde. Ich glaube nicht.

> Müßte ich mal schauen, da ich unter X eigentlich nur das X und
> den angenehmen schwarzen Mauszeiger kenne; ob X auch weiße
> Mauszeiger mit Sanduhren mitbringt, damit sich gewisse Leute
> wie zu Hause fühlen können... :-)

Wenn Du Dir den Standard-Cursor-Font angucken willst:
 - /usr/ports/x11-fonts/xfs installieren
 - /usr/ports/x11-fonts/showfont installieren
 - xfs starten (als normaler User genügt, nicht root)
 - showfont -fn "*cursor*"

Man muss beachten, dass im Font die Zeichen immer paarweise
zu interpretieren sind, d.h. zu jedem Cursor gehören zwei
Zeichen: eine Schwarz-Weiß-Bitmap und eine Transparenz-
Maske. Eine Anwendung kann jede Bitmap invertiert verwen-
den, d.h. ein Pfeil kann sowohl schwarz als auch weiß dar-
gestellt werden.

Die Eier-Uhr vom Opera habe ich jetzt auf Anhieb nicht
darin gesehen (nur die X11-typische Armbanduhr, die ich
aber eher hässlich finde). Opera hat seinen Cursor daher
vermutlich selbst definiert.

Es gibt Tricks, wie man X11-Anwendungen (auch Closed-
Source-Binaries) dazu bewegen kann, andere Cursor zu
verwenden, aber ich denke nicht, dass das die Mühe wert
ist.

> > > und kann auch bessere Ausdrucke erstellen.
> >
> > Kann ich nicht kommentieren, da ich noch nie mit Firefox
> > gedruckt habe. Die Ausdrucke von Opera haben für meine
> > Zwecke bisher immer genügt.
>
> Bei mir stimmt die Skalierung meistens nicht, entweder zu
> groß oder zu klein.

Kann man doch im Druck-Dialog in Prozentschritten einstel-
len. Mit dem Print-Preview kann man dann kontrollieren,
ob es passt (wobei ich es inzwischen ganz gut im Gefühl
habe).

Das mag natürlich Ansichtssache oder Gewöhnungssache sein.
Wenn's Dir bei Firefox besser gefällt, ist das OK.

> > > Das hängt sich an libgiofam.so auf, soweit ich sehe,
> > > ein Teil des Gnome- bzw. Gtk2-Rattenschwanzes.
> >
> > Die ist bei mir nicht installiert, daher kann ich das
> > nicht kommentieren.
>
> Bei mir ja auch nicht! Auf der 1. Kiste geht mplayer durch, auf
> der 2. Kiste aber aufgrund des Fehlens von libgiofam nicht.

Vielleicht fehlt da irgendeine Dependency. libgiofam wird
vom Port devel/gio-fam-backend installiert, was man z.B. so
herausfinden kann:

http://www.secnetix.de/tools/porgle/porgle.py?plst=1&q=libgiofam

Um das Problem zu beheben, müsste es also genügen, diesen
Port manuell zu installieren. Evtl. sollte man auch den
Maintainer des mplayer-Ports auf das Problem aufmerksam
machen. Aber seltsam ist das schon; eigentlich sollte der
FreeBSD-Package-Cluster solche Bugs feststellen.

> > Ähm, »glucksende Tonfragmente«? So kenne ich das eigent-
> > lich nicht (und fände ich auch nicht in Ordnung). Bei mir
> > verhält sich der Ton völlig normal.
>
> Beim Abspielen ja, beim Spulen hört man immer so kurze Tonbrocken
> im Rhythmus des Spulvorganges, aber ich glaube, das war auch
> schon immer so und ist in Ordnung.

Vermutlich meinen wir das gleiche. Also, wenn ich vor-
spule (was bei mplayer ja eigentlich kein Spulen, sondern
ein Springen ist), indem ich z.B. die Cursor-Taste einmal
drücke, dann überspringt er sowohl beim Video als auch
Audio das entsprechende Intervall und spielt dann normal
weiter. Ein »Glucksen« oder sonstige Störungen kann ich
nicht wahrnehmen.

> Vielleicht fehlen da noch irgendwelche Fonts... ich entsinne mich,
> daß es da irgendwie mal mplayer-fonts gab, nahm aber an, daß die
> automatisch dazugehören... man lernt halt nie aus.

Ja, da war so was ...
cat /usr/ports/multimedia/mplayer/files/pkg-message.in

> > richten sich nach der Display-Auflösung, um die Größe von
> > Fonts und Dialogen anzupassen. Prüfe mal, ob die Auflösung
> > bei Dir korrekt eingestellt ist (xdpyinfo | grep resol).
>
> resolution: 96x96 dots per inch

Und? Passt das zum Display?

> > - Am besten wäre es, die komplette Kernel-Config zu sehen.
>
> Vorsicht, viel Text:

Im großen und ganzen OK, aber ich habe mal ein paar Klei-
nigkeiten herausgepickt:

> cpu I486_CPU
> cpu I586_CPU
> cpu I686_CPU

Die ersten beiden cpu-Zeilen solltest Du löschen; Du
brauchst nur I686_CPU. Das macht den Kernel kleiner und
schneller.

> options CPU_SUSP_HLT

Bei dieser Option bin ich mir nicht sicher, ob sie nicht
vielleicht kontraproduktiv sein könnte. Ich würde sie
eher weglassen.

> # CPU frequency control
> device cpufreq

Hast Du eigentlich powerd(8) laufen? Wenn ja, mit welchen
Optionen, und was sagt »sysctl dev.cpu«?

> > - /etc/make.conf
>
> CFLAGS= -O -pipe

Das ist schlecht. Bitte streiche die Zeile ersatzlos.

Ich habe es hier in der Mailingliste schon oft predigen
müssen, dass es meistens eine schlechte Idee ist, die
Default-CFLAGS zu ändern, und dass man damit eher eine
Verschlechterung herbeiführt. So auch in diesem Fall.

> #For mplayer:
> #CFLAGS= -O2 -pipe -mfpmath=sse -ffast-math

Noch schlechter. Zum Glück auskommentiert. :-)

> SUP_UPDATE= yes
> SUP= /usr/local/bin/cvsup

Übrigens -- nur so am Rande: Seit einiger Zeit gibt es
im Basissystem das Tool csup(1), so dass man cvsup nicht
mehr installieren muss.

> SUPHOST= cvsup.freebsd.org

Da würde ich doch einen der deutschen Server empfehlen.
Die sind näher und schneller, und i.allg. nicht weniger
aktuell.

> DEPENDS_TARGET= package

Das halte ich auch für keine gute Idee. Damit funktioniert
z.B. »make reinstall« nicht mehr korrekt, und evtl. einige
andere Dinge auch. Möglicherweise ist das sogar für das
Dependency-Problem mit libgiofam verantwortlich.

Wenn Du rekursiv Packages für Dependencies bauen möchtest,
gibt es dafür »make package-recursive«.

> WITH_LIBMAP= yes

Das ist schon seit ein paar Jahren Default. Die Zeile
kannst Du getrost streichen.

> > - rc.conf,
>
> ifconfig_xl0="inet 192.168.000.001 netmask 0xffffff00"
> ifconfig_rl0="inet 192.168.001.001 netmask 0xffffff00 media 10baseT/UTP"

Vorsicht: Manche Tools interpretieren führende Nullen als
oktale Schreibweise. In diesem Fall ist es egal (001 = 1),
aber man sollte trotzdem auf diese Falle hinweisen.

> ntpdate_enable="YES"

ntpdate, aber kein ntpd? (Mag Absicht sein; ich frag nur.)

> update_motd="NO"

Warum?

> > sysctl.conf etc. (sofern potentiell wichtige
>
> compat.linux.oss_version=198144
> compat.linux.osrelease=2.4.20
> compat.linux.osname=Linux

Warum modifizierst Du das osrelease? Die beiden anderen
Variablen sind eh Default.

Generell wird davon abgeraten, die compat.linux-Variablen
zu ändern, da sie dann nicht mehr zur ABI/API der Emulation
passen. Setzt Du z.B. osrelease auf 2.4.20 statt 2.4.2,
dann kann das dazu führen, dass Programme versuchen,
Linux-Systemcalls zu verwenden, die (noch) gar nicht
implementiert sind.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
Perl is worse than Python because people wanted it worse.
        -- Larry Wall
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message