Don't forget the other cool feature of smit: the running man.

When you started an operation, there was animated icon of a man running. If your command succeeded, he'd stop and cheer. If you got an error, he'd trip and fall on his face.

Also, another advantage of AIX was that it included a volume manager and it was enabled by default. Back in the early 1990s, this was fairly unique. Some other operating systems offered, but only as an expensive add-on, so in practice you did without it. Being able to add a disk and just tell the system to move a filesystem over to it was pretty amazing.

Where I worked we got an early system as we made graphical desktops for workstations. IBM required that we have a separate locked room for the system!

Despite having over 20 different brands/Unix systems, AIX was the only one we had to pay a 3rd party consultant to come in and do installations and upgrades. That was back in the days of tapes. It used some convoluted volume management system where the tape contents got spooled into the disk and then the installation absorbed that.

smitty always felt so slow. There was a release where it was sped up. They didn't actually make it do the work any quicker - they just doubled the animation speed of the running man that was shown.

One of the big differences is that it is also COFF based like Windows, and Aix shared objects have similar capabilities, with private by default, import files, and having the capability to let the compiler handle delay loading of specific symbols.

I used Aix 5 series quite a bit, and looking at docs it seems to still have the same capabilities.

Yes, the sysadmin tool was awesome. There were 2 versions: one graphical (smit) and the other text/console based (smitty). Both versions had the same capabilities.

I think the other thing is the Object Data Manager (ODM)- configuration data about devices, networking configuration, etc. is stored as objects, as opposed (or in addition to?) to text files.

I also believe the AIX software package manager uses ODM.

`smit`, IIRC. Most workstation platforms, you mainly just had to know whether they were based on BSD or System V (or Apollo Domain, or the VMS of the VAXstations), but AIX had this interactive UI thing that was different.

Three other things nice about the RS/6000 and AIX:

* When it first came out, it was noticeably faster than the SPARCstations at the time.

* The hypertext documentation browser was nice. (This was slightly before the Web.)

* IBM would send two field technicians, in suits. (Which was funny, when they were meeting with frumpy nerdy teenager me.)

(We developed workstation software engineering tools for mil/aerospace/datacomm, which seemed to be wanted on everything except SGI. So, every time there was a new architecture, or a major OS change like SunOS 4 to Solaris 2, we'd get it immediately for porting.)

HPUX had a similar thing, called SAM.

Eh, smitty could be irritating because it persisted some changes but not others. So it was unclear if things you did outside it would get undone at boot time.

As a sysadmin in a mixed shop in the early 1990s I found that I could do just fine with traditional CLI and scripting tasks without using HP-UX's SAM or Sun's Solstice tools, but AIX's SMIT and smitty really got in the way of that sort of cheap and dirty automation. I understood the purpose of all those tools, but AIX pretty well made SMIT and smitty obligatory and that did not sit well with me back then. In the context of what you've said comparing SMIT and systemd, I would agree based on my experiences of way back then.

AIX on RT PC had a rather interesting architecture: the AIX kernel ran on top of a microkernel called VRM. VRM also supported two other operating systems, AOS (IBM’s port of 4.3BSD) and PICK. VRM could run multiple operating systems simultaneously, with a hotkey to switch which had access to the keyboard, mouse and screen. Similar idea to Windows NT’s environment subsystems, and IBM’s later Mach-based Workplace OS (cancelled before it ever went GA, but shipped in beta form to customers as OS/2 PowerPC Edition).

VRM was written, not in C, but in a PL/I dialect (not sure which, but probably PL.8). So AIX for RT PC is a rare example of a Unix whose kernel is (partially) written in a language other than C. The only other example of that I know of is IBM z/OS (which most people don’t think of as a Unix, but officially it is one, since it passes the certification test suite and IBM pays The Open Group the Unix trademark license fees.)

I say partially because the actual AIX kernel is in C, but it then calls to the VRM microkernel which isn’t in C. But a lot of basic functions which normally belong in a Unix kernel are in the VRM instead and the AIX kernel is just a thin wrapper over them.

When AIX moved to the RS/6000, the VRM microkernel was dropped, and AIX from then onwards was a classic monolithic kernel all in C.

Well, historically “AIX” has been a brand for (many but not all) IBM Unixes, with several unrelated code bases being labelled “AIX”. One of those, AIX/ESA (for IBM mainframes), was actually based on OSF/1, and hence used the Mach microkernel. But it was discontinued in the first half of the 1990s, when MVS gained Unix compatibility support. And all the other “weird” AIX variants are also now long dead, so in practice AIX for RS/6000’s descendant is the only AIX left.

AIX is a bit like DB2, in that both were brand names for multiple distinct code bases. The difference is all but one AIX code base died, whereas multiple DB2-branded code bases are actively supported today.

> This system was a bit before my time.

Not mine. First Unix box I ever touched, in my first job, here on the Isle of Man 36Y ago.

It was a demo machine, but my employers, CSL Delta, never sold any AFAIK. It sat there, running but unused, all day every day. Our one had a mono text display on it, and no graphics ability that I know of.

I played around, I wrote "Hello, world!" in C and compiled it and it took me a while to find that the result wasn't called "hello" or "hello.exe" or anything but "a.out".

If I had the knowledge then, I'd have written a Mandelbrot generator or something and had it sit there cranking them out -- but I was not skilled enough. It was not networked to our office network, but it had a synchronous modem allowing it to access some IBM online service which we used to look up tech support info.

Synchronous modem comms, or serial comms, are very different indeed to the familiar Unix asynchronous serial comms used on RS-232 connections for terminals and things. Sync comms are a mainframe thing, more than a microcomputer thing.

https://wiki.radioreference.com/index.php/Asynchronous_vs_Sy...

That modem was a very specialised bit of kit that cost more than a whole PC -- when PCs cost many thousands each -- and it couldn't talk to anything else except remote IBM mainframes, basically.

The RT/PC felt more powerful than a high-end IBM PC compatible of the time, but only marginally. It had a bit of the feeling of Windows NT about 6-7 years later: when you were typing away and you did something demanding, the hard disk cranked up and you could hear, and even feel the vibrations, that the machine was working hard, but it stayed responding to you the same as ever. It's a bit hard to describe because all modern OSes work like this, but it was not normal in the 1980s.

Then, OSes didn't multitask or they did it badly, and things like hard disk controllers of the time took over the CPU completely when reading or writing. So on MS-DOS, or PC-DOS or OS/2 1.x or DR Concurrent DOS, when you typed commands or interacted with programs, the computer responded right away as fast as it could. But if you gave a command that made the machine work hard, like asked for a print preview or a spell-check of a multi-page document, or sorted a spreadsheet of thousands of rows, or asked it to draw a graph from hundreds of points of data, the computer locked up on you. The hard disks span up, you heard the read/write heads chattering away as it worked, but it was no longer listening to you and anything you pressed or typed was lost. Or, worse, buffered, and when it was done, then it tried to do those commands, and quite possibly did something very much not what you wanted, like deleted loads of work.

(Decades later something similar happened with cooling fans, and now that's going away too. But with hearing the fans spin up, there's a hysteresis: it takes time, and tens of billions of CPU cycles, for the CPU to heat up, so the fans come on later, and maybe stay on for a while after it's done. A PC locking up as the hard disk went crazy was immediate.)

The RT/PC was a Unix box. It didn't do that. No idea how much RAM or disk ours had: maybe 4MB if that, perhaps 100-200MB disk. A lot for 1988! But if I did, say,

cd / ls -laR

... then it would sit there for several minutes with the HDD chuntering away, listing files to screen... but what was remarkable was that you could switch to another virtual console and it stayed perfectly responsive as if nothing were happening. That hard disk was SCSI of course, so it didn't use loads of CPU under heavy disk load.

The machine always felt a little slower, a little less responsive than DOS, but it never slowed down even when working hard. You had the feeling of sitting behind the wheel of a Rolls Royce with some massive engine there, but pulling a massive weight, so it didn't accelerate or brake fast, but could just keep accelerating slowly and steadily 'til you ran out of road... and you'd make an impressively large crater.

We sold a lot of IBM PS/2 machines with Xenix, and it was a Unix too and felt the same... but limited by the puny I/O buses of even high-end 1980s IBM PS/2 kit, so it sssslllloooowwwweeeedddd way down doing that big directory listing.

Whereas contemporary PC OSes responded quicker but just locked up when working hard. This included Windows 2, 3.x, 95, 98 and ME, and also OS/2 1.x, 2.x, and Warp. The kernels did not support multithreading and background I/O very well, so it didn't matter that the hardware didn't either.

Then Windows NT 4.0 came along, and it did. Suddenly the hardware mattered. But if you had a Pentium 1 machine, with an Intel Triton chipset on the motherboard, there was an innocent looking driver floppy in the box. On that was a busmastering DMA driver for the Intel PIIX EIDE controller. Install it on Win9x and it could see a CD-ROM on the PATA bus. Handy but not world-shattering.

Install it on an NT machine and once the kernel booted, the sound of the hard disk changed because the kernel was now using busmastering to load stuff from disk into RAM. As the machine booted the mouse pointer kept moving smoothly, with no jerkiness. When the login screen appeared it blinked onto the screen and you could press Ctrl-Alt-Del and start typing and your username appeared slowly but smoothly. The stars representing your password, the same.

It suddenly had that "massive computer power being used to keep the machine responsive" feeling of an RT/PC the decade before. Like that PIIX driver had made the machine's £100 cheapo IDE disk into a £400 SCSI disk.

There is also a 1h video from NCommander, where he ports Doom to AIX on an RS/6000: https://www.youtube.com/watch?v=XzhCGSE7KKw

At the time also posted on HN: https://news.ycombinator.com/item?id=31485616

It provides a few details on the software stack, particularly also the set of compat-APIs for porting Linux applications.

They are not that hard to find on eBay. Unfortunately, here in Europe they are quite rare, but I bet that, in the US, there are abandoned warehouses full of these.