I recently switched to using xfce on my FreeBSD desktop. Window Maker is nice but it was starting to feel a bit dated. Thus far I like xfce, but I had one problem with Terminal. Whenever I tried to resize it or switch desktops to one with Terminal open in it I could see it painstakingly render the window. Xterm and aterm didn't exhibit this behaviour, my 3d was accelerated, and other screen drawing didn't show problems either (do note I am using NVIDIA's binary driver for my GeForce 8800, the nv driver from X.org is unusable at this point).

Someone pointed me at the environment variable XLIB_SKIP_ARGB_VISUALS=1. Once added to .zshenv, properly exported on my shell and an X restart later I find Terminal to zoom along as expected. It turns out that the NVIDIA driver doesn't properly accelerate alpha channels.

If we consider common available technology and the average use of a FreeBSD installation as desktop or server then I think these are sensible defaults for /etc/src.conf under FreeBSD 7.

WITHOUT_ATM=yes

How many of you run ATM to your FreeBSD box?

WITHOUT_BIND_DNSSEC=yes
WITHOUT_BIND_ETC=yes
WITH_BIND_LIBS=yes
WITHOUT_BIND_MTREE=yes
WITHOUT_BIND_NAMED=yes

Do you really need a full installation of BIND on your machine? In most cases you simply need a caching, recursive resolver. For this just install unbound (found in ports/dns/unbound). Do note that I did not specify WITHOUT_BIND_UTILS so tools like dig and nslookup will still be installed. Only if you need an authoratative nameserver might you want BIND. On the other hand, you might prefer to install NSD (ports/dns/nsd).

WITHOUT_BLUETOOTH=yes

Most systems will probably not use Bluetooth at all.

WITHOUT_I4B=yes

Do you even use ISDN?

WITHOUT_IPFILTER=yes

Most people I know use either ipfw or pf, so little need for ipf.

WITHOUT_IPX=yes

You seriously still use IPX? Even NetWare is IP-native nowadays.

WITHOUT_NIS=yes

I would hope most systems are using some sort of LDAP lookup nowadays. NIS seriously doesn't scale.

WITHOUT_SENDMAIL=yes

Given the ease of configuring Postfix, why would one want to bother with the archaic syntax of Sendmail? It has served faithfully for many, many years, but its design and configuration are archaic.

Marc Balmer (of the OpenBSD Project) investigated reports of weird filesystem behaviour and found a 25-year old bug in the BSD libc implementation of readdir().

The fix should be in the trunk of all BSDs now and scheduled for merges or backports soon (e.g. see https://svnweb.freebsd.org/base?view=revision&revision=178772 ).

So I was working with a Japanese .xla (Excel add-in) file. I needed to look at something in the source so I fired up the Visual Basic editor within Excel. Upon investigating the form and the various captions it turns out that the Visual Basic editor only displayed them in gibberish (typical decoding issues) or question marks (substituting the .notdef glyph for codepoints). So it seems the Visual Basic editor is either not multi-byte capable (typing directly a string in Japanese into the caption yielded question marks) or it is bound to the locale of the system.

I then remembered AppLocale and fired up Excel through it, setting it to think it is on a Japanese system. Then within Excel I proceeded to start the Visual Basic editor and, sure enough, the text was showing me the Japanese I needed.

I am not sure if I should find this lame or understandable.

Now that Microsoft allows you to download the Consolas font the question becomes how to add it to the list of choices for the command prompt properties.

In the Microsoft Knowledge Base article 247815 you can find instructions on how to add a font.

Basically on most default Windows XP installations it boils down to adding a String name '00' to the HKLMSoftwareMicrosoftWindows NTCurrentVersionConsoleTrueTypeFont with a value of 'Consolas' (the corresponding name from HKLMSoftwareMicrosoftWindows NTCurrentVersionFonts).

In a SIGGraph 2006 presentation by NVIDIA it shows that Microsoft has revisited its stance on how they will support OpenGL within Windows Vista. You may recall when I first wrote about this last year that Microsoft's initial plan was to layer OpenGL through DirectX:

This time last year…

The plan for OpenGL on Windows Vista was to layer OpenGL over Direct3D in
order to obtain the Aeroglass experience

The situation today…

OpenGL accelerated ICD now fully supported under Windows Vista
OpenGL works fully with the Aeroglass compositing desktop
Performance and stability will rival Windows XP by driver release

So it seems some complaining still works given sufficient pressure.

According to [a post by Keith Packard on the Linux kernel mailinglist](http://marc.theaimsgroup.com/?l=linux-kernel&m=115536806403908&w=2 "Re: Announcing free software graphics drivers for Intel i965"):

This module contains stuff which Intel can't publish in source form, like
Macrovision register stuff and other trade secrets. It's optional, so if you
don't want to use a binary module, you don't get to use code written by
Intel agents for these features. And, we also haven't figured out how and
when to release this binary blob, so there's no way you can use it today.
The driver remains completely functional in the absense of the binary piece,
and in fact has no reduction in functionality from previous driver releases.

So much for that idea eh?

From http://www.schmidp.com/index.php?option=com_files&path=/haiku/images/ download a VMWare file.

Within VMWare create a new machine based on 'Other', name the virtual disk haiku.vmdk. After creating the machine replace the generated haiku.vmdk with the contents from the downloaded tarball from the schmidp website. Next you might need to select VM > Upgrade Virtual Machine.

When you start the virtual machine you will see the Haiku boot screen. After a few seconds you will be greeted with a graphical user interface which has a Terminal 1 window open with the text: Welcome to the Haiku shell.

Welcome to Haiku.

Addition: for those of you with VMWare Player, use VMXWizard to create a .vmx file to use with the downloaded .vmdk.

I have a 256 colour xterm set up on my DragonFly box.

Works perfectly. Especially for vim.

Now, I use FreeBSD 5.x as a gateway box to ssh into and have irssi and likewise programs screened.

Now, I was surprised to learn that I had only 16 colours. Outside of screen I had a full 256 colour palette (make sure to fix your PuTTY configuration by the way), but inside I was stripped of my colour scheme.

So I set off to find what was causing this. Interestingly enough one of the first emails encountered was from Jeremy Chadwick who had the exact same problem.

Turns out that screen needs to be compiled with 256 colour support (a knob should be in your ports Makefile now).

Since FreeBSD's and DragonFly's termcap is bereft of any 256 colour definitions for xterm apparently, you need to add the following to $HOME/.screenrc:

termcap xterm* 'Co#256:AB=E[48;5;%dm:AF=E[38;5;%dm'
terminfo xterm* 'Co#256:AB=E[48;5;%p1%dm:AF=E[38;5;%p1%dm'

This overrides your termcap settings with the appropriate definitions.

If you now start screen from a shell that has TERM exported as xterm or xterm-color (xterm* wildcard actually) it will fork off to a screen with 256 colour support.

You might need this in $HOME/.vimrc:

if &term =~ "xterm" || &term =~ "screen"
  set t_Co=256
  if has("terminfo")
    let &t_Sf=nr2char(27).'[3%p1%dm'
    let &t_Sb=nr2char(27).'[4%p1%dm'
  else
    let &t_Sf=nr2char(27).'[3%dm'
    let &t_Sb=nr2char(27).'[4%dm'
  endif
endif

Was converting files to proper ANSI C function declarations and a user tripped over the fact that old 4.4 BSD's function prototype of strmode() had int as a parameter, whereas it has been mode_t for a long, long time (read 1994 at least).

This broke buildworld of course.

Also asked Dima Dorfman to fix this for FreeBSD (broken in 4.x, 5.x, and 6.x).

NetBSD is fixed (as was to be expected to be honest).

And OpenBSD made the parameter int everywhere with a XXX comment in the strmode.c file that it should be mode_t actually. Weird.