| Gegenüberstellung von Unterschieden | GNU (Linux) | BSD (FreeBSD) |
|---|---|---|
| zyklisches ausführen eines Kommando's | watch | gnu-watch |
| Datei rückwärts ausgeben | tac | tail -r |
| Datumsformate umwandeln | date -d 'Tue May 19 08:57:48 2009' +'%F %T' | date -jf '%a %b %d %T %Y' 'Tue May 19 08:57:48 2009' +'%F %T' |
| dynamisiertes “/dev“ | udev | devfs/devd |
Ich hatte mit FreeBSD im Jahre 2000 angefangen (FreeBSD 4.1 bis FreeBSD 7.2) und habe es bis ins Jahr 2005 auf all meinen Rechnern (Server, Desktop, Laptop und in der Firma am Arbeitsplatz) eingesetzt. Zwischen 2005 und 2009 habe ich daneben auch noch NetBSD, OpenBSD, Solaris und OpenSolaris ausprobiert. Leider konnte mich aber keines dieser Systeme vollkommen überzeugen und so habe ich mich 2009 mit FreeBSD 8.0, für meinen Server, wieder voll und ganz für FreeBSD entschieden. Auf meinen anderen Rechnern (Desktop, Laptop und in der Firma am Arbeitsplatz) setze ich allerdings (seit 2005) weiterhin Linux ein.
Denn leider ist die Pflege einer Desktop-Oberfläche auf FreeBSD-Basis für den Anwender nicht so Wartungsarm, wie eine auf Linux-Basis.
Zuerst Fedora und jetzt Ubuntum, wenn sich mit der neuen Ubuntu-Oberfläche „Unity“ aber nichts ändert, werde ich Ubuntu entweder durch Fedora oder durch UGR (Ubuntu Gnome Remix) ablösen.
FTP-Pfad:
.../releases/$(uname -m)/$(uname -p)/$(uname -r)
FreeBSD 9.0 Beta2: If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is “.“ (head).
den Port installieren:
# portupgrade -NRO devel/subversion-freebsd
für eine saubere Basis sorgen:
# rm -fr /usr/src
globaler Entwicklungszweig (Der ändert sich ständig! Hier gibt es die aktuellsten Bug's…):
# svn checkout svn://svn.freebsd.org/base/head /usr/src
Entwicklungszweig der Version 9:
# svn checkout svn://svn.freebsd.org/base/stable/9 /usr/src
Version 9.0 RELEASE + Sicherheitsupdates:
# svn checkout svn://svn.freebsd.org/base/release/9.0 /usr/src
Version 9.0 RELEASE:
# svn checkout svn://svn.freebsd.org/base/release/9.0.0 /usr/src
Status anzeigen:
# svn status /usr/src
aktuallisieren:
# svn up /usr/src
Um von seinen DVD's die „Daten“ lesen zu können, oder einfach die absolut nervige Werbung vor dem Film zu entfernen, braucht man nur das folgende Programm zu installieren:
# portinstall sysutils/vobcopy
oder aus den Ports ⇒ sysutils/livecd
Hier gibt es Images mit Live-FS für CD (livefs) und USB-Stick (memstick):
nicht nur WindowManager sondern auch DesktopManager wie Gnome:
shells/bash misc/mc misc/gnu-watch audio/cdparanoia audio/faac audio/vorbis-tools devel/libchipcard devel/subversion-freebsd ftp/wget mail/dovecot-sieve misc/cpuid misc/seq2 multimedia/gpac-mp4box multimedia/lsdvd multimedia/lxdvdrip multimedia/mencoder multimedia/mkvtoolnix net/bmon net/cvsup-without-gui net/isc-dhcp42-server net/samba35 net/vnc security/doscan security/nmap sysutils/bsdsar sysutils/cdrtools sysutils/cpupowerd sysutils/dmidecode sysutils/dvd+rw-tools sysutils/dvdbackup sysutils/dvdisaster sysutils/livecd sysutils/pwgen2 sysutils/smartmontools sysutils/udfclient sysutils/usbutils sysutils/vobcopy www/squid www/dokuwiki www/apache22 graphics/php5-exif emulators/virtualbox-ose x11-servers/xorg-server x11-wm/icewm x11/xterm
Zu beachten ist hier, dass nach der Installation von „graphics/php5-exif“ in der Datei “/usr/local/etc/php/extensions.ini“ das Modul „exif.so“ irgendwo nach bzw. unter dem Modul „mbstring.so“ aufgelistet wird!
zum Beispiel so:
extension=zlib.so extension=openssl.so extension=session.so extension=mbstring.so extension=xml.so extension=gd.so extension=exif.so
In der “/etc/ttys“ muss man im gewünschten „tty“ statt “/usr/libexec/getty Pc“, “/usr/libexec/getty autologin“ eintragen. Dann muss in der Datei “/etc/gettytab“, im Bereich „autologin|al.9600“ statt „root“ der gewünschte User eingetragen werden.
checking whether Python support is requested... checking whether /usr/local/bin/python2.6 version >= 2.5... yes
checking for /usr/local/bin/python2.6 version... 2.6
checking for /usr/local/bin/python2.6 platform... freebsd8
checking for /usr/local/bin/python2.6 script directory... ${prefix}/lib/python2.6/site-packages
checking for /usr/local/bin/python2.6 extension module directory... ${exec_prefix}/lib/python2.6/site-packages
checking for headers required to compile python extensions... not found
configure: error: Python headers not found
===> Script "configure" failed unexpectedly.
Please run the gnomelogalyzer, available from
"http://www.freebsd.org/gnome/gnomelogalyzer.sh", which will diagnose the
problem and suggest a solution. If - and only if - the gnomelogalyzer cannot
solve the problem, report the build failure to the FreeBSD GNOME team at
gnome@FreeBSD.org, and attach (a)
"/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.6.7/config.log",
(b) the output of the failed make command, and (c) the gnomelogalyzer output.
Also, it might be a good idea to provide an overview of all packages installed
on your system (i.e. an `ls /var/db/pkg`). Put your attachment up on any
website, copy-and-paste into http://freebsd-gnome.pastebin.com, or use
send-pr(1) with the attachment. Try to avoid sending any attachments to the
mailing list (gnome@FreeBSD.org), because attachments sent to FreeBSD mailing
lists are usually discarded by the mailing list software.
*** Error code 1
Stop in /usr/ports/devel/gobject-introspection.
Diesen Fehler kann man beheben, in dem die folgenden Befehlen Abgegeben werden:
cd /usr/ports/lang/python26 make rmconfig portupgrade -f --batch lang/python26
Joseph Jacobson wrote:
>
> Just got this error, doing a 'make fetch' over ppp, while running mpg123.
> Kernel config can be provided if needed.
>
> sio0: 1 more silo overflow (total 1)
> sio0: 1 more silo overflow (total 2)
> sio0: 1 more silo overflow (total 3)
> sio0: 1 more silo overflow (total 4)
> sio0: 1 more silo overflow (total 5)
> sio0: 1 more silo overflow (total 6)
This is a frequently reported problem. It is, for the most part,
harmless. You will find an abundance of history by searching the mail
archives. Apparently some recent changes involving 'fast' interrupt
handling will cause FreeBSD to neglect a serial port for a bit too long,
and incoming data isn't read from the device before it is lost.
The following patch seems to help. It lowers the fifo threshold a bit
causing more frequent reads from the device. It also increases
interrupt frequency which, to some, seems rather tragic. I've never
felt any pain as a result of 'too many' interrupts from a serial port,
but I like not getting the silo overflows. This hack isn't Right(tm),
but it does work.
--- sio.c.orig Wed Aug 16 09:29:34 2000
+++ sio.c Fri Sep 1 14:53:47 2000
@@ -2345,7 +2345,7 @@
* latencies are larger.
*/
com->fifo_image = t->c_ospeed <= 4800
- ? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX_HIGH;
+ ? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX_MEDH;
#ifdef COM_ESP
/*
* The Hayes ESP card needs the fifo DMA mode bit set
No promises about whether this patch will apply to your version of
src/sys/isa/sio.c. I usually just change the one line by hand.
###############################################################################
#
In FreeBSD 4.7 RELEASE,
in dem dieses Problem auch besteht, sieht der entsprechende Teil wie folgt aus:
2466 if (com->hasfifo && divisor != 0) {
2467 /*
2468 * Use a fifo trigger level low enough so that the inpu
t
2469 * latency from the fifo is less than about 16 msec and
2470 * the total latency is less than about 30 msec. These
2471 * latencies are reasonable for humans. Serial comms
2472 * protocols shouldn't expect anything better since mod
em
2473 * latencies are larger.
2474 *
2475 * Interrupts can be held up for long periods of time
2476 * due to inefficiencies in other parts of the kernel,
2477 * certain video cards, etc. Setting the FIFO trigger
2478 * point to MEDH instead of HIGH gives us 694uS of slop
2479 * (8 character times) instead of 173uS (2 character ti
mes)
2480 * @ 115200 bps.
2481 */
2482 com->fifo_image = t->c_ospeed <= 4800
2483 ? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX
_MEDH;
2484 #ifdef COM_ESP
2485 /*
2486 * The Hayes ESP card needs the fifo DMA mode bit set
2487 * in compatibility mode. If not, it will interrupt
2488 * for each character received.
2489 */
2490 if (com->esp)
2491 com->fifo_image |= FIFO_DMA_MODE;
2492 #endif
2493 sio_setreg(com, com_fifo, com->fifo_image);
2494 }
Beachten Sie, das hier der relevante Teil mehr als 130 Zeilen tiefer liegt als
in dem oben genannten Patch!
Obwohl die trigger point schon von "FIFO_RX_HIGH" auf "FIFO_RX_MEDH" gesetzt is
t
(wie duch den Petch "empfohlen") habe ich das Problem immer noch.
###############################################################################
#
Das Problem wird auch in der man-Page genannt. Die Puffer sind schon wieder leer
bevor sie ausgelesen wurden. Das Problem tritt meistens (aber nicht nur) auf,
wenn die Geschwindigkeit der seriallen Schnittstelle (oder des seriallen
Geraetes) zu hoch eingestellt wurde.
Auf einigen Internetseiten wird beschrieben wie man das Problem durch abschalten
des IRQ-sharings beheben kann. Dabei ist nur zu beachten, das der entsprechende
IRQ dann von keinem anderen Geraet mehr verwendet werden kann!
###############################################################################
#
LOESUNG in meinem Fall:
=======================
Das Problem trat mit einem "ASUS-P5A + K6-2-400" und FreeBSD 4.4 noch nicht auf,
nach dem Update auf FreeBSD 4.7 hatte ich den Fehler "silo overflow".
Dieser lies sich nur durch den Austausch der genannten Hardwarekomponennten
gegen "ABIT-PB6 + P2-Celeron-366" beheben! Seltsam, aber so war es...