On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: I'm happy with it, you silly twisted boy, you.

I think that "Where can I find a clean copy of an HJ Lu boot/root set?" is an acceptable-for-here Linux tech support question, to be honest. On Fri, Jul 17, 2020 at 12:58 PM Larry McVoy <lm(a)mcvoy.com> wrote: > On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: > > On Fri, Jul 17, 2020 at 02:08:31PM -0400, Norman Wilson wrote: > > > In my humble-but-correct opinion*, Linux and its > > > origins fit into the general topic of UNIX history.. > > > Warren gets final say, of course, but to encourage > > > him I will say: Ploooogie! > > > > I'm happy with it, you silly twisted boy, you. > > But +1 to Grant's point not to turn TUHS into a Linux support forum. > Quite frankly, I'm old dude who relies on his kids to fix his phone > and I can google and find answers to just about any Linux problem. > So no need for that here. >

On Fri, Jul 17, 2020 at 3:58 PM Larry McVoy <lm(a)mcvoy.com> wrote: "Back in my day, we had VAXen! And you couldn't carry them anywhere! And the disc drives weighed a hundred pounds! AND WE LIKED IT THAT WAY!" :-D - Dan C.

But +1 to Grant's point not to turn TUHS into a Linux support forum.

On Fri, Jul 17, 2020 at 12:57:18PM -0700, Larry McVoy wrote: Correct. It's all about Heritage on The Unix Heritage Society mailing list. Chat about the early days of Linux is fine; helping to get Wayland to work isn't (at least, not for another 20 years or so). Cheers, Warren

On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: But +1 to Grant's point not to turn TUHS into a Linux support forum. Quite frankly, I'm old dude who relies on his kids to fix his phone and I can google and find answers to just about any Linux problem. So no need for that here.

Eh ... can I get something to wash that down? I'm "okay" with such designations if you will back them up with a hard definition of what qualifies or not.

Oh, boy, now you've got me started. I worked on A/UX at Apple back around 1992. I'd love to find a copy of that!

On Sat, Jul 18, 2020, 2:23 PM Ed Carp <erc(a)pobox.com> wrote: Google can find it, if you really need it. Warner On 7/17/20, Michael Kjörling <michael(a)kjorling.se> wrote:

On 7/18/20 9:46 PM, Wesley Parish wrote: I think I've seen articles about people running it running virtualization / emulation.

ISTR that A/UX was nothing special as a Unix. Am I failing to remember?

On 7/20/2020 5:46 AM, Arno Griffioen wrote: I was involved in USENET back in the early-to-mid 90's, and never heard of Mac stuff going on, but then, I'm in the US. The USENET stuff I built was Intel as front-end w/SVR4.2, and SPARC (-LX) as the backend file server. I never realized there was any sort of "-nix" for Macs back then.

A number of A/UX boxes were purchased and immediately reloaded with Mac OS (because only the A/UX boxes were available with 80 MB disk drives).

I also had one of the few copies of MacMach that ran on a IIfx. No one in Cupertino was very interested in Mach.

sort of cool. When you typed "ls", for example, it would pop up a window that would show you all the options that you could select for that command. That was new and different. Too bad it didn't stick around.

The window had checkboxes corresponding to the options and text fields corresponding to their values, if any. I can't remember if it parsed the output of --help or equivalent, though.

I also don't recall if such commands were supported in pipelines, though I see no reason why they should not have been.

SMIT was quite nice

Me neither. SMIT was HORRIBLE [...]

On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: Me neither. SMIT was HORRIBLE if you understood the files in /etc and knew what to do with them. It might be nice if you had no understanding of how to admin a Unix system and here is this "nice" curses based way to do admin.

To anyone remotely competent, and I don't mean edit sendmail.cf, I mean you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a nightmare that made something that should be vi $FILE, done 20 seconds later, a hellish journey through their menus. It was AWFUL.

Ask me how I know.

The SMIT I had did*not* show you what files it was editing

My recollection is that smit(ty) did /not/ show you the commands that would be run /by/ /default/. That being said, there was a (P)F key you could press prior to executing, one of the many (P)F keys smit(ty) used, that would show you the command and all of it's arguments which would be run.

SMIT was one just one of the systems that I had to sysadmin (along with Open/Xenix (hah!), Slowaris, PH-UX (as we called it), etc;

The Motif-version was especially horrible, and crashed all the time. The curses-based version was called `smitty`, which I found humorous in a way I wouldn't have expected coming from "This page intentionally left blank" IBM. In my mind, the worst part of admining RS/6000 boxes of that era was the little 3-digit LED code on the front: I guess those machines didn't assume that they had either a graphical head or a serial port, so this damn teeny tiny display would cycle through a sequence of codes that told you what the machine was doing; it came with a book that told you what each code meant. Something like "387" meant mounting /usr. Ugh; I just found a page on ibm.com describing these "IPL codes."

On Thu, Aug 13, 2020 at 1:19 PM Henry Bent <henry.r.bent(a)gmail.com> wrote: IPL = Initial Program Load = boot(strap), by the way. It also has the connotations of "toggle in".

But this reminded me: Does anyone remember a system of any sort where there were *two* corresponding sets of alphanumeric error codes, one short and meaningless like F32 and the other somewhat meaningful like POWER_LOW? I made up this example, but I have a feeling I saw or read about such a system. I can't pin it down with Dr. Google.

Such number-only error systems are still very common in things like "smart" washing machines, where the cost and unreliability of a non-tiny screen simply isn't acceptable.

Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it.

Adam On Thu, Aug 13, 2020 at 10:16 AM Dan Cross <crossd(a)gmail.com> wrote: > On Fri, Jul 31, 2020 at 9:37 PM Larry McVoy <lm(a)mcvoy.com> wrote: > >> On Fri, Jul 31, 2020 at 07:12:57PM -0400, Richard Salz wrote: >> > > SMIT was quite nice >> > >> > i have never seen those four words together like that before. >> >> Me neither. SMIT was HORRIBLE if you understood the files in /etc and >> knew what to do with them. > > > The sysadmin in the CS department had a USENIX button on his wall: "SMIT > happens." I always found that amusing. > > The Motif-version was especially horrible, and crashed all the time. The > curses-based version was called `smitty`, which I found humorous in a way I > wouldn't have expected coming from "This page intentionally left blank" > IBM. In my mind, the worst part of admining RS/6000 boxes of that era was > the little 3-digit LED code on the front: I guess those machines didn't > assume that they had either a graphical head or a serial port, so this damn > teeny tiny display would cycle through a sequence of codes that told you > what the machine was doing; it came with a book that told you what each > code meant. Something like "387" meant mounting /usr. Ugh; I just found a > page on ibm.com describing these "IPL codes." > > It might be nice if you had no understanding >> of how to admin a Unix system and here is this "nice" curses based way >> to do admin. >> > > The thing was that IBM changed a lot of stuff almost gratuitously. > Specifics I remember were the print daemon (I ported `lpd` from 4.4BSD for > that) and anything related to disks and filesystems. In fairness, they had > logical volumes that could split across disks before most other Unix > systems that I was working on at the time, but the commands were all custom > to AIX and, frankly, weird: I remember that one would "vary on" a logical > volume before one could mount a filesystem from it or something like that. > I was told at the time that the people who'd built that side of things had > come from the mainframe world, where that was the nomenclature. Creating > JFS filesystems required these tools as well; there was new `newfs_jfs` as > I recall. So I ended up using SMIT for basically anything related to > filesystems, but for almost nothing else. > > To anyone remotely competent, and I don't mean edit sendmail.cf, I mean >> you can edit inetd.conf, you can edit a crontab file, etc, SMIT was a >> nightmare that made something that should be vi $FILE, done 20 seconds >> later, a hellish journey through their menus. It was AWFUL. >> > > One of the more gratuitous differences I remember from AIX was that > instead of having e.g. /etc/shadow, they had /etc/password (all spelled > out), which had semi-structured stanzas for each user. That was just weird. > Fortunately, we were using NIS and it was smart enough to ignore that for > NIS users. > > Ask me how I know. >> > > I still have nightmares about AIX. > > - Dan C. > >

On Aug 13, 2020, at 12:18, Adam Thornton <athornton(a)gmail.com> wrote: Early AIX is what happens when you give a detailed description of Unix to mainframers who've never seen Unix, and then tell them to implement that system, and then ship it, without at any point letting someone who's used an actual Unix system touch it.

On 13 Aug 2020, at 21:09, Rich <rdm(a)cfcl.com> wrote: My favorite characterization of AIX came from Barry Shein: "It will remind you of Unix." -r

On Aug 13, 2020, at 9:06 PM, Christopher Browne <cbbrowne(a)gmail.com> wrote:  My favorite was from David Megginson, whose observation was that "you don't run AIX, you chase it"

I can’t recall the date, but I remember very clearly approaching an IBM sales rep who told me that they took UNIX and “fixed all the bugs”. I shook my head and laughed as I walked away.

On a vaguely related note, I found it amusing that there was a well known hack for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope probe on a test point that generally had one there during final system checkout. The load (extremely mnimal by design) was just enough to stabilize the system.

On Fri, 14 Aug 2020, Larry McVoy wrote: Yep, timing was everything in those days (and I'm still amazed at the people who believe that electricity moves at the speed of light). Wasn't it Grace Hopper who used to demonstrate a nanosecond by holding up a foot of wire?

I'm sure everyone here knows this, but the Cray 1 (I think, the one

On a vaguely related note, I found it amusing that there was a well known hack for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope probe on a test point that generally had one there during final system checkout. The load (extremely mnimal by design) was just enough to stabilize the system.

On Aug 14, 2020, at 11:08 PM, Andrew Hume <andrew(a)humeweb.com> wrote: not on the cyber 72 we shared, dave. it was, in fact, a length of wire. the 72 had one length, and the 76 had a shorter length. (i guess you could call that a sort-of timing capacitor?) i watched a cyber technician change the wires for the purposes of doing a verification test. > On Aug 14, 2020, at 7:02 PM, Dave Horsfall <dave(a)horsfall.org> wrote: > >> On Fri, 14 Aug 2020, Rich wrote: >> >> On a vaguely related note, I found it amusing that there was a well known hack for Cray's (or perhaps 6600's) which were misbehaving: put a Tektronix scope probe on a test point that generally had one there during final system checkout. The load (extremely mnimal by design) was just enough to stabilize the system. > > There was also the story about the major difference between a Cyber 72 and a Cyber 73 was just a timing capacitor... Very expensive capacitor :-) > > -- Dave

I first ran across A/UX at a tradeshow. I can’t recall the date, but I remember very clearly approaching an IBM sales rep who told me that they took UNIX and “fixed all the bugs”. I shook my head and laughed as I walked away. On Aug 13, 2020, at 9:06 PM, Christopher Browne <cbbrowne(a)gmail.com> wrote:  On Thu., Aug. 13, 2020, 4:11 p.m. Rich, <rdm(a)cfcl.com> wrote: My favorite was from David Megginson, whose observation was that "you don't run AIX, you chase it"

Except that it had a rudimentary option completion feature that was sort of cool. When you typed "ls", for example, it would pop up a window that would show you all the options that you could select for that command. That was new and different. Too bad it didn't stick around.

A/UX runs Mac OS as a Unix process (its default GUI is Mac OS although it does also support a traditional X server), making it the opposite of MachTen. It has considerable integration between Mac OS and Unix, and supports "hybrid" programs (Unix programs that make Mac OS system calls and Mac OS programs that make Unix system calls) (which I don't think MachTen supports, but I'm not completely sure of that). It is one of only two Unices that I'm aware of that runs another OS in a process to provide its main GUI (the other is a much more recent Linux distribution that runs AROS; I'm not counting things like running Windows under Merge or VP/IX because those were usually used in addition to X11).

This isn't quite the same but Victor Yodaiken wrote a real time kernel that ran all of Linux as a user process.

On 7/20/20, Larry McVoy <lm(a)mcvoy.com> wrote: Agreed.

The issue is that there aren't that many good real-time programmers Tavailable. Furthermore, many real-time applications need to do a lot more than data acquisition, so having access to POSIX API's in the real time task is very attractive. Sure, you can try to interchange information between the real-time task and the POSIX task, but that's a lot more complicated, and that's where the "not enough real-time programmers" rears its head again. ... Sure, there will be some number of real-time task which needs single-digit millisecond real-time guarantees --- in which case you can write it in C using Real-time Linux. And for those really cases where you need latencies which are in the tens of microsecnds; then yeah, at that point you might need specialized OS's. But the cases where you need fast, hard real-time is pretty rare compared to those cases where real-time Java is sufficient.

On Jul 20, 2020, at 4:47 AM, arnold(a)skeeve.com wrote: ISTR that A/UX was nothing special as a Unix. Am I failing to remember? I had had a DMD 5620 at my job, and after I moved to a different place and requested one, they graced me with a Macintosh. It could sort of do multiple windows, but it was like having a piper cub after being used to a 747. Other interesting bits for the Mac to maybe recover would be Mach Ten, which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) There was also a Mach/Linux that I think ran on the Mac at some point. Arnold Michael Parson <mparson(a)bl.org> wrote:

On 7/20/20, Larry McVoy <lm(a)mcvoy.com> wrote: QNX manages to do realtime fairly decently while still being Unix-like, although it's certainly not a conventional Unix. With a multi-server OS with a properly designed microkernel, it is possible for realtime threads to more or less ignore the fact that they're running on a Unix-like OS (provided that they can access some kind of IPC API that closely matches that of the kernel) since all the OS services other than the microkernel are running beside them at non-realtime priorities, and not underneath them as in a conventional OS. It's kind of doing the same thing as running a Unix kernel as a process under a realtime kernel, but the Unix environment is implemented by servers and libraries instead of a monolithic kernel.

On Jul 20, 2020, at 4:47 AM, arnold(a)skeeve.com wrote: ISTR that A/UX was nothing special as a Unix. Am I failing to remember? I had had a DMD 5620 at my job, and after I moved to a different place and requested one, they graced me with a Macintosh. It could sort of do multiple windows, but it was like having a piper cub after being used to a 747. Other interesting bits for the Mac to maybe recover would be Mach Ten, which ran Mach on top of regular MacOS. (Talk about inverted pyramids...) There was also a Mach/Linux that I think ran on the Mac at some point. Arnold Michael Parson wrote:

Other interesting bits for the Mac to maybe recover would be Mach Ten, which ran Mach on top of regular MacOS. (Talk about inverted pyramids...)

There was also a Mach/Linux that I think ran on the Mac at some point.

A/UX boots macOS, then loads a loader app that takes over the machine and boots the kernel. The emulator Shoebill “cheats” and reads the kernel from the UFS disk directly and jumps to that.

On Sat, Jul 18, 2020, 2:23 PM Ed Carp <erc(a)pobox.com> wrote: Google can find it, if you really need it. Warner On 7/17/20, Michael Kjörling <michael(a)kjorling.se> wrote:

The emulator Shoebill can run A/UX https://github.com/pruten/Shoebill It’s pretty awesome. 3.0 is the last version that is stable(ish).  Naturally the MacOS installer won’t run so a bunch of Unix legwork is required. I’m not sure if this email will make the list but I’ll try.... Anyway the developer of Shoebill got snapped up by a certain fruit vendor so no updates...

As for A/UX it’s SYSV with the c and fortran compilers built in.  Apparently it was going to be Steve’s “Big Mac” project that was sidelined after he was pushed out.  Although there is so many crazy rumours of that window at the end of Apple and the start of NeXT.

On Sat, Jul 18, 2020 at 05:53:58AM +1000, Warren Toomey wrote: But +1 to Grant's point not to turn TUHS into a Linux support forum. Quite frankly, I'm old dude who relies on his kids to fix his phone and I can google and find answers to just about any Linux problem. So no need for that here.