I’m presented with a difficult decision, and I’d like some feedback.

First, the status: DOSBox 0.63, as it currently stands, is G3 optimized, and will work with MacOS 10.2.6+.

I was contacted earlier today by Aubin Paul, a rather nice fellow developer who asked me if I wanted to host his build of CVS (bleeding edge) DOSBox. His is G4 optimized, and being CVS, is much, much faster. Sadly, I don’t have the bandwidth to host both builds, so I had to refer him to Qbix, to see what Qbix wished to do.

Aubin’s build essentially (ab)uses several gcc/g++ optimizations – and they do make a difference. However, one of the options which decreases overhead (if gprof is to be believed) is gcc 4.0 centric.

Currently, my builds are for/with gcc 3.3, which work with MacOS X 10.2.6 and higher, as noted above. gcc 4.0 is 10.4 specific; there’s no way of ‘backporting’ it to work without doing things which are not benificial for development – or your computer. Basically, at best, it’d probably make DOSBox a 50MB program, since EVERYTHING would have to be self contained – and then there would still be horrid debugging issues since the system libraries wouldn’t match up.

Should I drop future support for MacOS 10.3 so soon? Should 0.6.3 be the last G3/10.2&10.3 release – or do I release a slower, yet more compatible version?

Recently I’ve wanted to send some new data to my rather cheap mobile phone.

It was represented to me as supporting WML 1. Guess what? It doesn’t. This sent me looking for a prerolled system – since I honestly don’t even know where to start, I was hoping to find something.

I did. It’s called HAWHAW!. While reminding me of Nelson, from the Simpsons, laughing at me for undertaking such a silly project, this HAWHAW framework is pretty stable – and it’s GPL. My old system was hard-coded WML 1. I never bothered to learn HDML, or MML – and trying to parse the phones’ abilities would drive me insane.

So far, I’ve put up a small test framework that I can toy with, and finally get my pictures and ringtones onto my Nokia 6010. I hope.

I’ve finally obtained my 1Ghz G4 eMac, and with it, Tiger. It’s low on memory as the memory sent to take it to 1GB does not work with my eMac. Oh well. I can try to limp by at 256M until MemoryX replaces it, right?

One of the first things that I’ve noticed is the lack of Startup Items and /etc/hostconfig presets for BIND that are still there in MacOS X 10.3.x.

A short list of no-longer-there-as-startup-items-but-still-installed programs which are no longer controlled via /etc/hostconfig:

DNSSERVER (Bind) MAILSERVER (Postfix) RPCSERVER (NFS)

The support software is still there, but the Startup Scripts are not. They’ve been moved to the new ‘LaunchDaemons’ system, which is basically a hybrid idea of djb’s daemontools, xinetd, and far too many drugs. I know everyone’s jumped onto the XML train, but COME ON, PEOPLE.. EVEN CRON? Ahem, anyow..

Being that I run a nameserver on my iMac (which will now be secondary to my eMac), I find this a bit disappointing. For the last few years, I’ve usually used djbdns on my other UNIX hosts, but in an effort to be more compliant (and to play with encryption for subdomain transfers, etc), I’ve opted to drop back to BIND.

[Update:]

I had ended up re-setting the DNSSERVER variable in my /etc/hostconfig, and copying across the startup script structure from /System/Library/StartupItems/BIND/ – This wasn’‘t the ‘Tiger’ way to do things, but it worked. However, I generally want to do things ‘right’, so… After doing a bit of further research, I discovered that these services are now managed by YET ANOTHER Apple tool, specifically ‘LaunchDaemons’.

Since someone’s already written the article on how to do it properly, I’ll link to Dan’s “Bind on Tiger” article rather than making my own.

There are many articles found on the internet which attempt to assist with installing and configuring the CUPS printing system under Solaris.

CUPS has been available as an unofficial ‘companion utility’ since Solaris 9, which has foomatic drivers native – so, I find this article to be the most useful.

There are a few differences between Solaris 9 and Solaris 10. Solaris 9 still relies upon ‘init scripts’ for many tools and utilities, whereas with Soalris 10, Sun has opted, in their wisdom, to implement smf, which basically makes specific tasks a bit more archaic to configure (at first).

As a purely technical note, which has no specific use in this article – SMF also controls the kernel runlevels; so ‘single’ mode is now controlled via SMF rather than init.

Anyway, back to the little article:

Where the article suggests to stop the LP service:

# /etc/init.d/lp.stop

1. mv /etc/rc2.d/S801p /etc/rc2.d/s801p

This is now controlled by SMF. Note that I am also disabling Solaris’ bizarre IPP system built upon Apache, in order to use CUPS’ internal IPP system:

#svcadm disable application/print/ipp-listener #svcadm disable application/print/server #svcadm disable application/print/rfc1179

Note that CUPS by default does probe your local subnet, and will note (as well as add) any printers already configured via IPP.

This is the end of my little ‘addition’. I assume you know how to navigate CUPS’ tools, and manage your printers.

Here’s one other purely-informational tip: The NetGear PS101 print server will begrudgingly support LPD printing. After configuration, change the ‘hostname’ for the PS101 when you configure your WINS workgroup. This, combined with the port number (Parallel 1), will become your print queue.

So, if you set the IP address to 10.0.0.20, and the hostname to “HELLOPS101”, you would print to (Pardon the URI syntax; it’s easier for CUPS users) lpd://10.0.0.20/HELLOPS101_P1. The P1 is appended as there is only one parallel port with the PS101, and the underscore is obviously just an informational terminator between the host name and port addressed.

I’ve been tracking OpenSolaris for both Sparc and Intel (x86) platforms. Despite the fact that I primarily use MacOS X at home for my personal UNIX based systems, have owned and operated various UNIX derivatives, including Solaris, since 1995.

Although Solaris really shines on Sparc, the x86 beast is a functional ugly duckling. It’s SMP is, and was stronger than NT 4, and it was the first x86 commercial UNIX variant that supported SMP. However, being that it is Solaris on x86, it tends to offend those who have used it on Sparc, and are used to the advantages of it natively – and the x86 hardware support is dodgy, at best. As it is fully SMP capable, and has everything active ‘by default’, with few choices to disable them, it tends to run slower on x86 platforms than, say, Linux and FreeBSD – rather, it feels that way, which is a ‘good enough’ excuse to dislike it for most users.

I’ve dealt with this “ugly duckling” professionally since Solaris 2.6 (5/98 forever!) – and mighty changes are afoot for the release of Solaris 11.

From Solaris 2.x/x86 through Solaris 11 b19, the x86 variant still had four different bootstrap stages, where, upon being the active operating system, it first loaded the device configuration assistant, then the pre-boot system, which somewhat emulated the OpenFirmware functionality on the Sparc platform, and finally, if everything worked, would load the kernel.

With b20, this is no longer the case. The bootloader now uses GRUB, and seems to chain directly into the kernel. (I say ‘seems’, as I am still in the process of updating to it, and haven’t had the chance to poke about within it, yet.)

This makes things a bit bizarre, at least for me, as when adding device drivers, or modifying support to boot into single user, or reconfigure the onboard devices, I’ve become used to the ‘’, ‘’, ‘’ selection which would rescan the system’s devices and chain back to the kernel.

I find that this new functionality is certainly more condusive for ‘flow’, but I am a bit curious how they’ll eventually replace the DCA system.

[Note for would-be tinkerers]: Solaris 11 b20 is not quite ready for prime time. The new GRUB loader doesn’t like to work with the older boot system, so you’ll likely want to do a full reinstall, since an ‘upgrade’ does not quite work. The install system is also currently limited to text mode.

Oddly, audio drivers have been updated and imported, but the NIC drivers are still quite lacking.