Note that I needed to retain the ability to log in to Solaris hosts with the same home directory and files, and I didn't want to make it hard to revert to Solaris if necessary. So starting from scratch was out.
I love tcsh, but it's not a standard part of Solaris and it's dangerous to place your faith in a shell whose binary is mounted via NFS. Sooner or later, one logs into a client that reads the NIS passwd file but doesn't have the NFS mounts, at which point /usr/local/bin/tcsh fails. This is quite apart from what happens when the NFS server goes down (Solaris uses demand paging).
My Cshrc file (actually files) is an overlong piece of historic spaghetti designed to work with Solaris, SunOS4 and now Linux. I added a few bits to take advantage of the extra facilities under Linux, such as native tcsh, and bit the bullet by adding yet another separate file to source on Linux hosts. (Received wisdom has it that csh startup files should be small and fast. I wish that wisdom would spread to my home directory.)
I also reorganised my own binary directory to make room for separate Linux binaries. I still haven't found an elegant way to add the right paths to my PATH for every version of every OS, but what the heck. (People thinking it just involves `uname -s`: wrong! There's more to it than that.) My lib directory is still common which occasionally causes hardship (e.g. with the additional Netscape supporting library I load), but I can live with that for now.
XFree86 uses different startup files to OpenWindows, Sun's X11 environment. I created a separate startup file rather than try to make the old one work for both.
Keyboard mapping was a pain. XF86 for SPARC doesn't seem to even use the keyboard configuration available in the obtuse config file for the Intel release. It works fine out of the box with US keyboards, but I was using a UK Type 5 Sun keyboard (and I'd like to point out that we invented the USA anyway ;-). So no bar or backslash key - great, how do I use pipes in the shell?!
The fix was a one line xmodmap command, as most X11 users will have guessed. I eventually worked out what it was on my own. Trouble is, I have to execute it at startup for any user, including root. Can I be bothered to customise each .Xclients file? Nah ...
The keyboard problem persists on the console. After consulting the mailing lists on the S/Linux site, I eventually tracked down the updated kbd programs and maps I needed. Sadly, XF86 doesn't inherit this mapping.
Obviously I wanted to customise the root menu. Then I wanted to reclaim some screen real estate by forcing all those icon bars and window lists to go to the background if necessary (I hate big, fancy application launchers that take up half the available screen - ref. CDE). And I nearly gave up when I couldn't discover how to make windows sticky straight away. (Under OLVWM, you choose `Sticky' from the titlebar menu. Under AfterStep, you click the little horizontal bar icon in the titlebar with the middle mouse button. Got that? S'obvious, innit?!)
I played around with some of the available look and feels, but I don't favour trendy colour schemes as a rule (OW uses mainly grey, which can be dull but gives a nice clean look). The flashiest I got was the clever twirling outline as a window is iconised or de-iconised; looks good the first ten times, grows old rapidly after that.
AfterStep's configuration files are fairly logical once you get the idea. In the later versions, you only need to copy and modify the files you want from the defaults supplied. Making changes on the fly is a bit awkward, usually involving a restart, but again the latest version is more flexible.
There are major colourmap problems that I will address later.
We use the Solaris Automounter extensively on our network. Everything that isn't on the Solaris CD is generally automounted from the servers, including home directories, binaries, sources, patches and mail spool.
The original automounter in SunOS4 was something of a joke; I believe it provided at least part of the impetus for the BSD version (which ironically suffers some of the same problems). However, the automounter in Solaris 2.x is a complete rewrite, has its own virtual filesystem (which lets it do nifty things like in-place mounts) and in later releases is even multi-threaded. More importantly, you can restart it without needing to reboot, unlike early AMD releases.
Linux only has AMD. We used to employ it at Aber until we realised how much superior the Solaris one had become and dumped it, but at least I have some familiarity with it. Fortunately, AMD has also been rewritten in the interim. Given that we already generate AMD maps from our automount maps and I wasn't going to create a whole slew of static NFS mounts, I wanted AMD.
Couldn't find it on the Red Hat CD though. Actually, it was there and I'm not sure how I missed it (the package is am-utils), but I only discovered this after downloading a patched version from Red Hat. I had some initial problems getting it to work with NIS, and eventually gave up and stuck a copy of the NIS map in /etc instead. Now it works, although it still uses those annoying symbolic links that we left behind in the SunOS4 automounter. (AMD is now acquiring autofs support.)