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

Polytropon <freebsd(at)edvax.de> wrote:
> Das ist immer so eine Frage, in welcher Art und Weise die
> graphischen Kontrollen in die UI eingeführt werden; beim
> "alten" Gimp war das relativ unproblematisch, da man viele
> Funktionen über das Rechtsklick-Menü erreichen konnte und
> daher kein Bedarf an überquellenden Icon-Leisten entstand.

Das mag von der persönlichen Arbeitsweise abhängen, aber
zumindest im Falle von Gimp finde ich, dass man gar nicht
genug Bildschirmfläche haben kann. In der Regel habe ich
eine Reihe von Fenstern gleichzeitig offen: Tools, Layers,
Brushes, Tool-options, um nur die wichigsten zu nennen, die
ich ständig brauche, und häufig habe ich auch mehr als ein
Bild zugleich geöffnet, und/oder dasselbe Bild mehrfach ge-
öffnet.

Also, mit 800x600 mag ich mir Gimp nicht antun. Es mag
theoretisch gehen, aber es würde weh tun. Und der Datei-
Öffnen-Dialog wäre da eher das kleinere Problem.

> Ähnlich ist es übrigens auch bei Textverarbeitungsprogrammen,
> die mit vielen Leisten, die übereinander liegen, mehr und
> mehr Y vom Bildschirm verbrauchen, daher bleibt immer weniger
> für das eigentliche Textfeld übrig. Bei Browsern ist es
> ebenso: Titelleiste, Menüleiste, Icon-Leiste, Lesezeichen-
> leiste, Tab-Leiste, diverse "Toolbars", Statusleiste. Da
> ist nicht mehr viel Platz.

Zum Glück kann man das alles nach Herzenslust konfigurie-
ren. Bei meinem Opera habe ich die Toolbars auf ein Mini-
mum zusammengestrichen, so dass da nur die Sachen sind,
die ich wirklich brauche. Ein paar Dinge, die ich seltener
brauche, habe ich auf eine separate Toolbar gelegt, die
ich nur bei Bedarf aufklappe. Und dann gibt's ja noch den
Fullscreen-Modus, den man bei Bedarf bequem mit F11 ein-
und ausschalten kann -- dann verschwinden sogar die Fen-
sterrahmen.

> (Nebenbei eingeführt: Aus diesem Grunde mag ich auch Window-
> Maker als primäre Arbeitsumgebung. Die paar Icons (Dock), die
> es benutzt, liegen fein am rechten Bildschirmrand, und zwar
> untereinander. Von X ist eh mehr auf dem Bildschirm als von Y,
> also warum Y verschwenden?)

Aus diesem Grund verwende ich seit mehr als 15 Jahren den
olvwm. Ich habe keinerlei Icons auf dem Bildschirm. Wozu
auch? Finde ich überflüssig. Das einzige, was ich über-
haupt von meinem Windowmanager sehe (abgesehen von den üb-
lichen Fensterdekorationen), ist ein Fenster in der Ecke,
das mir eine Übersicht über den virtuellen Desktop zeigt.
Und selbst das ist häufig von anderen Fenstern verdeckt.

> > Dort ist übrigens auch SCHED_ULE bereits der Default (es
> > wurde schon kurz nach der Release umgestellt).
>
> Ich hatte SCHED_ULE bereits eingetragen, d. h. ich laufe aktuell
> mit diesem. Kann es sein, daß mein Rechner für ULE zu lahm ist
> und der "alte" Scheduler da doch die bessere Wahl wäre? Da
> mangelt es mir wirklich an Praxiserfahrung.

Eigentlich sollte ULE in allen Fällen mindestens ebensogut
wie 4BSD sein, und in vielen Fällen besser.

Falls Du mit ULE eine spürbare Verschlechterugn feststel-
len kannst, wäre das eine Regression, und daher einen
Problem-Report wert.

> > Ü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.
>
> Hmmm... hatte ich bei 5.x eigentlich immer so gemacht und
> keinerlei Probleme damit erlebt. Aber gut zu wissen.

Kleiner Zusatz: Das Modul acpi.ko wird vom Boot-loader
bereits automatisch geladen. ACPIin den Kernel fest ein-
zucompilieren führt bestenfalls zu Warnmeldungen des Ker-
nellinkers, im schlimmsten Fall zu subtilen Fehlfunktionen.
Die Doku formuliert es vorsichtig: »Note that building
ACPI into the kernel is deprecated; the module is normally
loaded automatically by the loader.«

> > 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. ;-)
>
> Und die sahen obendrein auch noch trantütig aus.

Waren sie auch. Mit IDE-Festplatten ausgestattet, die
per Default im PIO-Mode betrieben wurden. Und wehe, es
musste mal geswappt werden ... Kein Ruhmesblatt für Sun.

> Die schönsten
> Werke von Sun waren meiner Meinung nach die Ultra 1, die
> SS 20 (ich meine nicht die Rakete) "Pizzabox",

Eine SS10-Pizzabox mit zwei CPUs habe ich noch herumstehen.
Aber nicht in Betrieb (aus Ökologie- und Ökonomie-Gründen).
Wahrscheinlich werde ich sie demnächst entsorgen.

> > 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.
>
> Ich bemühe mich, die Dinger nicht mehr "Idiotentasten" zu nennen
> und freue mich über meine gute Komplianz. :-) Die Sun- und die
> Apple-Tastaturen erfreuen und wenigstens mit Modifier-Tasten,
> die solche Funktionen erfüllen können (Sun: Meta-L, Meta-R,
> Compose; Apple: Apfel+Raute).

Das sehe ich eher pragmatisch.

Mir ist es sowas von egal, ob auf den Tasten nun ein Sun-
Logo, eine Windows-Fahne oder ein angebissener Apfel drauf
ist. Den Fingerkuppen ist das wurscht. Entscheidend ist
die Funktion, mit der man sie belegt.

> > 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.
>
> Es ist etwas umständlicher, bietet jedoch die Möglichkeit, wie
> der Name der Taste sagt, sich Zeichen zu komponieren (soweit im
> Zeichensatz / Schriftart vorhanden).

Schon klar, aber ich ziehe es vor, stattdessen einfach eine
Alt-Kombination zu verwenden. Ich habe mir alle Zeichen,
die ich brauche, auf solche Kombinationen gelegt, in erster
Linie natürlich die deutschen Umlaute, aber auch einige
anderssprachige Zeichen, damit ich España, François und
Smørgrav halbwegs flüssig und ohne Hampeleien tippen kann,
sowie ein paar sonstige Zeichen, die man ab und zu braucht
(µ auf Alt-M, »« auf Alt-><, ° auf Alt-0 usw.).

Sorry, off-topic.

> > > 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.
>
> Das würde bedeuten, Ärger mit xorg und xorg-drivers zu bekommen,
> pkg_delete beschwert sich jedenfalls, kann aber mit -f mundtot
> gemacht werden.

Das muss gar nicht sein; ich habe xorg-drivers gar nicht
installiert, sondern einfach den betreffenden Treiber
direkt.

Aus ganz ähnlichen Gründen habe ich xorg-clients nicht
installiert. Das zieht einem 100 Slave-Ports rein, von
denen man die Mehrzahl nicht braucht. Stattdessen habe
ich nur diejenigen davon installiert, die ich benötige.

> > > 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«?
>
> Standby: 1200 Suspend: 1800 Off: 2400
> DPMS is Enabled
> Monitor is On

Aha, enabled. Mit "xset -dmps" kannst Du das abschalten.
Was mit der Option in der xorg.conf nicht stimmt, weiß ich
nicht, da ich die nicht verwende.

> Der LaserJet 4000 hat als gebürtiger Bürolaserdrucker bereits
> eine Netzwerkkarte eingebaut, ich war nur zu faul, noch eine
> Strippe zu legen, das mache ich erst beim Umzug, der demnächst
> ansteht. Da will ich dieser Empfehlung folgen und einfach mal
> schauen, wie es ist, (a) von mehreren Rechnern drucken zu
> können und (b) wie sich UTP zu Parallel von der Geschwindigkeit
> so verhält.

Es verhält sich um Größenordnungen schneller. Über eine
parallele Schnittstelle kriegst, je nach Art und Konfigu-
ration, ein paar hundert KByte/s rüber. Über FastEthernet
gehen run 10 MByte/s drüber.

Das wird natürlich dadurch etwas relativiert, wie schnell
der Drucker die Daten annehmen und verarbeiten kann. Das
hängt vom Drucker und den zu verarbeitenden Daten ab.

> Aber bei "normalen" Webseiten wie OSNews, google, eBay sollte
> eigentlich keine solche Lahmarschigkeit auftreten. Wie gesagt,
> solche Erscheinungen, daß der Browser für mehr als 15 Sekunden
> stillsteht und gar nichts mehr macht, kannte ich bis dato noch
> nicht.

Stimmt, das ist eher nicht normal. Da sollte man unter-
suchen, woran es liegt -- ob z.B. die DNS-Abfrage so lange
braucht (das Problem gibt's öfters), oder ob evtl. ein
Proxy seine Finger im Spiel hat.

> [Flash]
> Vor allem beim grundlegenden Konzept. Sollnse das als offenen
> Standard freigeben

Haben sie.

> und sich aus systemrelevanten Dingen raushalten, dann kann man
> da gern weiterreden.

Mir ist nicht ganz klar, was Du damit meinst.

> Aber solange dieses
> proprietäre Mittel dazu benutzt wird, Seiten unzugänglich zu
> machen und Menschen mit Behinderungen auszusperren, nehme ich
> das nicht ernst.

Nunja, Flash wird für viele verschiedene Dinge verwendet.
Wenn es zum Zugriff auf Inhalte notwendig ist, weil z.B.
die Site-Navigation ausschließlich mit Flash möglich ist,
dann ist das Pfusch (unter anderem, weil es gegen die
Barrierefreiheit verstößt). Da gebe ich Dir vollkommen
recht.

Aber es gibt auch Flash-Anwendungen, die sinnvoll und nicht
schädlich sind. Ich erinnere mich da ein ein nettes Spiel,
das in Flash geschrieben ist, bei dem man eine Yeti-Figur
mit einem Baseball-Schläger steuert, und die Aufgabe ist
es, herabfallende Pinguine möglichst weit zu schlagen.

> > 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.
>
> Soll aber auch nicht ganz unproblematisch sein.

Mit der aktuellen Wine-Version funktioniert das erstaunlich
stabil und performant, und auch die Installation ist rela-
tiv einfach. Ein weiterer Vorteil dieser Vorgehensweise
ist, dass der Browser sozusagen in einer Wine-Sandbox
läuft, d.h. »böswillige« Webseiten können nicht so ohne
weiteres Zugriff auf die FreeBSD-Umgebung nehmen.

Für diejenigen, die interessiert, wie man das macht:

http://lists.freebsd.org/pipermail/freebsd-hackers/2008-June/025021.html

> [opera + linux-opera]
> Soweit ich weiß, können beide Versionen auch parallel genutzt
> werden, sie stützen sich dann sogar auf ein und dasselbe
> EInstellungsverzeichnis (~/.opera).

Nein, sie verwenden unterschiedliche Verzeichnisse, nämlich
~/.opera und ~/.linux-opera. Ich glaube nicht, dass beide
parallel genutzt werden können, da sie teilweise dieselben
Dateien enthalten, insbesondere /usr/local/bin/opera.

> > 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).
>
> Leider stimmt das nicht immer mit dem tatsächlichen Druck-
> resultat überein.

Tatsächlich? Bei mir stimmte der Ausdruck bisher immer mit
dem Preview überein.

> > 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.
>
> Halte die Taste mal gedrückt, so daß mehrere Sprünge vollzogen
> werden;

Ah, jetzt, ja ... Auf die Idee, die Taste gedrückt zu
halten, bin ich noch nie gekommen. Stattdessen verwende
ich immer die verschiedenen Sprungfunktionen (PagerUp/
Down, CursorUp/Down, CursorLeft/Right). Damit kann man
die gewünschte Stelle sehr bequem und schnell erreichen,
in Verbindung mit der OSD-Zeitanzeige.

> > > > 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?
>
> Woher weiß ich das? (Ehrliche Frage, weiß ich nämlich wirklich
> nicht, ist immerhin eine 21"-CRT, kein LCD, Röhren haben doch
> keine fixe dpi-Auflösung, da sich das je nach Bildfrequenz
> ändern kann.)

Dividiere die Anzahl der Prixel pro Zeile durch die Breite
der Anzeige in Zoll. Beispiel: Bei meinem Notebook ist
das Display 30,6 cm breit. Ein Zoll ist 2,54 cm. Das
Display stellt 1400 x 1050 Pixel dar. Die Auflösung ist
somit 1400 / (30,6 / 2,54) = 116,2 Pixel pro Zoll. Ich
habe das auf 120 aufgerundet und dem X-Server mitgeteilt.

> > > 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.
>
> Ich dachte immer, das wäre beim Pentium 4 günstig hinsichtlich
> des Stromverbrauchs. Vielleicht eine dumme Idee.

Ich glaube nicht, dass das nennenswert Einfluß auf den
Stromverbrauch hat.

> > > # CPU frequency control
> > > device cpufreq
> >
> > Hast Du eigentlich powerd(8) laufen? Wenn ja, mit welchen
> > Optionen, und was sagt »sysctl dev.cpu«?
>
> Nein, powerd läuft nicht;

Wenn Dir der Stromverbrauch wichtig ist, solltest Du den
mal in rc.conf enablen.

> > > > - /etc/make.conf
> > >
> > > CFLAGS= -O -pipe
> >
> > Das ist schlecht. Bitte streiche die Zeile ersatzlos.
>
> Entsinne ich mich richtig, oder ist das nicht eventuell sogar die
> Vorgabe?

Das war mal der Default vor langer Zeit. Momentan ist der
Default bei i386 + amd64 »-O2 -fno-strict-aliasing -pipe«.
Natürlich kann sich auch das bei Bedarf wieder ändern, und
das geschieht in der Regel aus gutem Grund. Irgendwelche
CFLAGS in make.conf reinzubraten ist daher eher eine ganz
schlechte Idee. Im allgemeinen kann man davon ausgehen,
dass die Default-CFLAGS auf die im Basis-System befindliche
gcc-Version optimiert sind.

> > 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.
>
> Vor Jahren habe ich zumindest mal gelernt, daß Kernel und
> Welt nie -O2 oder -O3 oder sonstige Parameter haben sollten;

Das war vor Jahren auch mal gültig.

> bei
> mplayer, insbesondere auf älteren Kisten (ich meine solche bis
> 500 MHz) kann eine höhere Optimierung durchaus was bringen.

Ja, und dafür hat der mplayer-Port eine entsprechende
Option im config-Menü. Kein Grund, die CFLAGS global
in make.conf zu modifizieren.

> > > 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.
>
> Sehr praktisch, werde ich mir näher zur Lektüre reichen.

Da muss man nicht viel lesen. Kommandozeile und sup-
Datei sind mit cvsup kompatibel, d.h. Du musst wirklich
nichts weiter tun als csup statt cvsup aufzurufen.

Das einzige, was momentan noch nicht geht, ist der Reposi-
tory-Modus (falls Du nicht nur einen Tree auschecken, son-
dern das ganze Repository herunterladen möchtest). Dafür
gibt es bisher nur experimentelle Patches für csup.

> > > 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.
>
> Da hatte ich schonmal Probleme mit letzterem, daher der Verweis
> auf den "Hauptserver". Aber das ist alles schon laaaange her.

Ich verwende immer irgendeinen von cvsupN.de.freebsd.org
(N = 1...8). Wenn der mal nicht geht, nehme ich einfach
den nächsten. Das ist kein Grund, gleich den erheblich
langsameren Hauptserver in den USA zu verwenden.

> > > 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.
>
> Das kenne ich eigentlich nur aus C, aber eine guter Hinweis.

Naja, die meisten Tools sind halt in C geschrieben. ;-)

Mach mal »ping 0127.0.0.1« und schau ganz genau hin.

> > > ntpdate_enable="YES"
> >
> > ntpdate, aber kein ntpd? (Mag Absicht sein; ich frag nur.)
>
> Ich dachte, das genügt so... vorher hatte ich xntpd, wenn ich
> mich da richtig entsinne. Und jetzt fällt es mir auch auf: Im
> Systemhochlauf steht gar nichts von NTP! Der Knilch stellt
> seine Uhr nich! :-)

xntpd wurde schon vor Jahren in ntpd umbenannt:
ntpd_enable="YES"

> > > update_motd="NO"
> >
> > Warum?
>
> Keine Ahnung, ich weiß nicht, was da passiert

Per Konvention steht in der ersten Zeile der motd die
Kernel-Version, z.B. so:

FreeBSD 7.0-STABLE-20080714 (VOLTAGO)

Die Option update_motd (wenn nicht ausgeschaltet) bewirkt,
dass diese Zeile automatisch aktualisiert wird, wenn nötig.
Ich persönlich finde das ganz praktisch und sorge daher
dafür, dass zumindest diese Zeile in der motd drin ist,
auch wenn sie sonst leer ist.

Ist natürlich Ansichtssache.

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
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message