Did you know that Open Firmware has its own theme song?
https://web.archive.org/web/20060111132138/http://playground...
http://everything2.com/title/The+Open+Firmware+Song
Sung to the tune of "The Flintstones"
Firmware
Open Firmware
It's the appropriate technology,
Features
FCode booting
Hierarchical DevInfo tree.
Hack Forth
Using Emacs on the keys,
Save in
NVRAM if you please.
With your
Open Firmware
You can fix the bugs in no time
Bring the kernel up in no time
We'll have an FCode time!
For production slated machines, we were usually running commands such as "copy-clock-tod-to-io-board", nothing too creative.
While I was there, the Sparcstation 20's reached end-of-life and we were allowed to bring one home (I still have it). At home I had gotten ADSL through a reseller that had an odd routing setup - they wanted the MAC address of my desktop so that they could assign an IP to it. I guess I should have gotten a hub that could do NAT, but I gave them my Intel PC MAC, and then went into the SS20 OBP and changed the MAC address to that of my PC. It worked too, both machines got ADSL. Actually what I wound up doing is doing NAT with the SS20, after I swapped out the PC ethernet card with a spare one lying around.
the whole devlop on a mac book when the actual production systems are linux makes me wince.
I did not stay in enterprise for long. I like mainframes, but I hate the culture of big companies. I next helped founding a university, and when tired by ivory tower, I left uni to fund a company to focus on machine learning for industrial applications.
So, most important advise from an old sack: stay flexible, and dont be surprised that old skills in solid technology might be worth good money at the moment when the hypes end.
It was very different. At the dot-com's that I was at, web servers and application servers were Red Hat Linux, and only the databases were Sun boxes, with E4500 being a high end box. At a post-IPO dot-com there might be one E6500 and maybe a few Sun E4500's, and lots of Red Hat machines. At the investment bank they were all Solaris on the Unix side, and had dozens of E6500's in my city, and hundreds of E4500's. The investment bank had admins in the OpenBoot PROM all the time, whereas I had barely been in it. The investment bank was always replacing disks in the hundreds of external RAID arrays they had whereas only our database had a large external RAID array. They used NFS extensively and you had to know it thoroughly. My knowledge about Red Hat Linux, Apache web servers, Java application servers etc. didn't amount to much.
It was qualitatively (and quantitatively) very different, and in interviews it sounded like I didn't know what I was talking about.
On the developer side, the bureaucracy is very different. If a minor change in a software package is being pushed to New York, London and Tokyo, which often it is, you might have five meetings about it, and the code push might take weeks or even months. No matter how trivial the change. Three different divisions might have to sign off on the change. It's definitely not an agile code process, with code going from your fingers to the production web/app within the week.