I built XFCE4 for OpenBSD on the Z and once I had turned off the AntiAliasing it seemed attractive enough to live with the speed, however, it was a little unstable and the bar kept crashing... then when I relaunched the bar the Window manager crashed.
Then I tried the same version out on OpenBSD running on VMWare and it behaved exactly the same
I have switched over to running WindowMaker for the time being which is nice and very easy to customise once you understand the environment... it's also much lighter weight than XFCE.
If I really need as much free memory as possible I still switch back to X and TWM though.
So far the only complaints I have with OpenBSD are that the gtk, gdk, pygtk etc.etc. are all a little old. I'm interested in running Python and since gtk is 2.2.6.10 (with a patch) it means that I would have to rebuild a helluva lot of base stuff from unpatched source to get 2.9 (or 2.
gtk required to have the latest version of pygtk which is required to do things like put images on buttons.
I have had a lot of 'easy wins' though in building stuff... for example gtkam just built no problem, plugged in my IXUS 750 and I could browse and download images... Gimp is a little sluggish at editing a JPEG from a 7 Megapixel camera on a Z though - lol, as you can see it has tried to make a 27Mb image cache
[ Invalid Attachment ]
I have also had a couple of occasions where the whole X server has crashed and exited leaving the console unusable... not sure what happened to the console tty here but the frame buffer seemed to be in a state where I couldn't do anything. My only way out of it was to restart the X server from an ssh session and then gracefully close it down.... I may switch on xdm instead... at least this should clear up the frame buffer if xinit dies in future. Note that this has only happened whilst I was doing something heavy with a compile running in the background (typically when the swap partition was getting hit a lot)... I'm starting to wonder about event queueing problems in these circumstances since dmesg seems to be hinting that there were a lot of missed events from wxmouse.
One thing that I couldn't get answered before I installed was if OpenBSD on this platform used a software floating point library linked into executables or required on trap emulation of fp instruction (hardware emulation in kernel). So for anyone interested in knowing the answer here is the evidence...
$ gdb test
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "arm-unknown-openbsd3.8"...
(gdb) list
1 #include <stdio.h>
2
3 main()
4 {
5 float f1, f2, f3;
6 f1=3.14159;
7 f2=2.37653;
8 f3=f2/f1;
9 }
(gdb) disassemble main
Dump of assembler code for function main:
0x0000872c <main+0>: mov r12, sp
0x00008730 <main+4>: stmdb sp!, {r11, r12, lr, pc}
0x00008734 <main+8>: sub r11, r12, #4 ; 0x4
0x00008738 <main+12>: sub sp, sp, #16 ; 0x10
0x0000873c <main+16>: ldr r3, [pc, #36] ; 0x8768 <$d>
0x00008740 <main+20>: str r3, [r11, #-16]
0x00008744 <main+24>: ldr r3, [pc, #32] ; 0x876c <$d+4>
0x00008748 <main+28>: str r3, [r11, #-20]
0x0000874c <main+32>: ldr r0, [r11, #-20]
0x00008750 <main+36>: ldr r1, [r11, #-16]
0x00008754 <main+40>: bl 0x84a8 <__divsf3>
0x00008758 <main+44>: mov r3, r0
0x0000875c <main+48>: str r3, [r11, #-24]
0x00008760 <main+52>: mov r0, r3
0x00008764 <main+56>: ldmdb r11, {r11, sp, pc}
0x00008768 <$d+0>: ldrmid r0, [r9], #-240
0x0000876c <$d+4>: andmis r1, r8, r1, lsl r9
End of assembler dump.
(gdb)
As you can see the simple C program (compiled with no special flags) generates calls to a floating point software library (bl 0x84a8 <__divsf3>), this would actually be the floating point instruction if this were a hardware emulation based system.
- Andy
