You should read Section 8 of the Unix User's Manual If, like me, you were a computer-science graduate student who cut your teeth on Berkeley Unix – complete with the first open-source implementation of TCP/IP – you know Section 8 as the cryptic System Maintenance Commands section of the Unix User's Manual. It was obvious, to me, that this concluding section warranted a closer …
"Would BSD Unix have had the same impact in the 1980s and 1990s if the university computer center had supported it rather than the computer-science department letting its grad students take ownership of the operations problem?"
There are users and then there are those others, well, "... all progress depends on the unreasonable man."
If the students had been forced to be 'users', then much less would have been accomplished, invented. Here's a fishhook and some string, figure out what you can do with them.
"... an opportunity to manage systems that deliver services to actual users is a great source of systems research problems, as well as fertile ground for platform innovations."
And maturity, and responsibility, and insights into what a product must be to be useful.
Unfortunately, too many developers are really just users. For many of the rest of us, fulfilling a need of others fulfils a need of our own. (sic itur ad astra ?)
"Unfortunately, too many developers are really just users."
This one kind of resonates with me; especially in the 3D graphics area. So many talented young guys are effectively stagnating by just consuming products like Unity3D rather than exploring new ideas, creating new technologies and learning!
(even worse with Unity's strict DRM meaning that all their hard work is guaranteed to be worthless once the company ceases to trade!)
Even worse was the JANET to Internet mail translation: JANET domain names were the other way round.
An old friend and colleague wrote the definitive Sendmail config so that (in SMTP terms) usr@dept.university.ac.uk could be munged into usr@uk.ac.university.dept. And then added in rules to correctly handle UUCP delivery (which was where the !-path and % came in)
One problem arose with Computer Science depts. Before the iron curtain came down, the country code for Czechoslovakia was CS. So (for instance) cs.bath.ac.uk got swapped to uk.ac.bath.cs. It turned out that the Sendmail rules struggled with this. Stuff got sent to Prague. The solution was a filter/reflector over there that sent if back again.
And of course, the most famous UUCP !-path hostnames: Kremvax and Kgbvax.
https://en.wikipedia.org/wiki/Kremvax
I was a big user of Jim Crammond's UK-Sendmail package until I wrote my own sendmail config from scratch as I was a know-it-all postgrad.
For those who remember the days of bang paths, rapid re-routers, EAN, EARN, BITNET and the UKs NRS hell where the Computer Science email would all get redirected to Czechoslovakia, here's Jim's take on it
https://www.netfunny.com/rhf/jokes/90q3/fig1.html
Somewhere I've still got my university sweatshirt with uk.ac.stir.cs printed on it. :)
My first two real paid jobs involved nursing and configuring sendmail, with some bits of rewriting as well. Usefully, I came from a background of having written a sendmail program* for networked Beebs five years earlier. :)
*And an instant messaging system**
**And a distributed information browsing system***
***And a multi-user networked gaming system****
****Youngsters today, think they invented everything....
You could use multiple "@" signs in an address and they were read right to left. The need for "%" was so that you could mix SMTP and UUCP hops in one address.
The precedence was that @'s are processed before UUCP's ! so if you needed to have a UUCP hop followed by an SMTP one you used the lower precedence % format.
I also benefited because the IP network wasn't rolled out in the company I was working for by their IT network but rather by the companies research division who then allowed the rest of us techies to come on board and play too. You learn so much more when you need to do stuff for real.
The bang path UUCP addresses let you specify a specific path to take (the machines to pass through).
I vaguely remember the ability to do this using % symbols; the mail went to the system after the @. then the @ and everything after it was stripped off and the rightmost % became an @ - then processing continued.
I remember winning a successful challenge to get an email from the Oxford engineering department VAX to an oil rig in the Hudson Bay. As I recall it had to go from uk.ac.ox.engvax (an 11/780) to uk.ac.ox.vax (a cluster of 2 8800s and 2 8700s) to uk.ac.convex (the only Unix machine with public access) to somewhere at Sussex University (which had a uucp to IP gateway) to New York University to the oil rig, Memory may have diminished or embellished this, but it was tricky.
Having spent Christmas (with family - lucky me!) in Hawaii, I made a pilgrimage to UHawaii to see the IEEE marker commemorating ALOHAnet. ...and took a selfie. Curiously, there was no crowd...
Abramson died just after the marker was placed last year. Kuo is still with us.
Have just returned, and good God is it cold in Boston! 10 hours on a plane and you get off to 0F and 20 mph wind that goes right through the minimal cold weather clothing I had brought.
I went from VAX VMS to Unix. I could make VMS do almost anything I wanted after 10 years of it. It took a while to get anywhere near that kind of fluidity with Unix. I think you learn a subset of 'computers' that is sufficient for almost any task you need and even though unix had everything I needed it took a long while to work out where it was. It didnt help the machine I was using was managed by someone who never found out how to turn of full disk checking on bootup which was a good hour or so of the day drinking enough tea to interrupt all later procedures.
TOPS-10, VMS etc. came from a particular school of thought where commands had consistency. So once you had learnt the general format and vocabulary it was generally very easy to either locate the right command for what you were wanting to do and get the parameters right. Obviously, CP/M and PC/MS-DOS borrowed and created a much-simplified command set. Unix was very much counter-culture being intentionally designed for two-finger typists and commands made obscure so you had to read the 'manual'.
I think the two fingered typist thing works well until about 1980 when the abbreviation space starts to seriously flood. I came to it from chip design so I probably had two or three hundred well worn commands that were nothing to do with the underlying OS by which time brevity was a | dream! The commands I found useful where used for building up long command scripts from directory contents and managing errors to drive the files through various routes to make/validate the bits of chips in the directories. I look back on some of the stuff I have on fanfold and wonder how I actually got it to work - lots of sed and yacc and cshell I can not longer understand off the top of my head but the VMS script collection uses commands I cant even remember!
>That wasn't obscurity, that was brevity
Maybe, but then Unix was intended for the "priesthood", which was stronger in academic institutions (and their IT departments/schools) than commercial IT departments running proprietary systems.
Obviously, with the rise of microprocessors in the 80's and the availability of an open OS ie. portable Unix source code, many new entrants were able to build and sell boxes using Intel/Motorola/National Semiconductor CPU's, chipsets and buses and running 'Unix'; its how Sun started.
What would have been interesting is whether Unix would have become so dominate so quickly, particularly in the server space, if there had been other viable releases of open source code. Whilst I know there are reasons why it didn't happen, I suspect Unix would have lost out to VMS had DEC released their source code in the mid 80's.
>Why on Earth would you want a sysadmin to NOT read the fine manual? Do you expect them to learn the finer points of the OS by osmosis?
There is reading the manual and having to use the manual to ensure you are using the right set of parameters and even then not all parameters were documented! :)
With the early 80's releases, there were key variations between Unix distributions and commands.
The issue isn't not reading the manual, but finding you way around it - there is no comparison between the Unix Reference manual and the bookcase of documentation systems such as VMS had.
"I suspect Unix would have lost out to VMS had DEC released their source code in the mid 80's."
Having worked at DEC, and put in a boat-load of time on BSD long before that, and knowing that DEC's source was available to researchers (at Berkeley and Stanford, certainly) ... no. DEC's code wasn't built to be flexible enough for the (then) modern world of near-ubiquitously networked systems. UNIX (and by extension, BSD) was.
Note that this wasn't a war of attrition, rather it was a fine example of evolution in action. None of us had any clue what it would all lead to, we just used what worked & built upon it, sometimes throwing out a whole chunk and starting fresh, until it worked the way we wanted it to work. All in all, I think it turned out OK.
Except the monstrosity known as the systemd-cancer, of course.
I get what you are saying, however, remember outside of academia, Unix was largely unknown and a bit of a joke (early 80's). Business was familiar with VMS and liked what they saw, so a bit like how Microsoft subsequently became, so given a choice between: VMS with its catalogue of business applications and Unix, I would have expected business to have chosen VMS.
Whether (open source) VMS would have been as adaptable as Unix was, is a slightly different, but still relevant question. However, many think it would have killed Microsoft...
On the contrary, by the late 70s UNIX was well enough known, and being used in proto Silicon Valley startups, to the point that Gates & Co. (always looking to make a fast buck) licensed the source for AT&T's very own Unix Version 7 in order to re-sell it. (You didn't really think that Microsoft actually wrote Xenix, did you?)
I did minor consulting work for Onyx Systems in 1979, which lead to some moonlighting at RDS (later known as Informix, you may have heard of them) in 1980. I also did work for plenty of others in the same time frame. Lots of UNIX, making quite a bit of money. At the time, only the dinosaurs were still using VMS for new projects ... and being made fun of by us young whippersnappers.
Microsoft's NT was largely architected[0] by Dave Cutler, who pretty much wrote the core of VMS singlehandedly while at DEC. That's why NT looks so much like VMS. Sadly, Microsoft turned what could have been a truly great operating system into a joke.
[0] I really, really hate that word ...
There was a difference between what was going on in the Valley and in the world outside of the USA.
>You didn't really think that Microsoft actually wrote Xenix
...
Microsoft's NT was largely architected by Dave Cutler, who pretty much wrote the core of VMS singlehandedly while at DEC.
Funnily enough by the beginning of 1985, I was sitting on the core to an OS that ran on the x286/386, we debated whether to release it and decided being UK-based and with the massive increase in Unix (on Intel), plus the MS-DOS battles, the field was getting a little crowded. Instead, I got into Unix and with some friends delivered LivingC to market (on MS-DOS).
>Sadly, Microsoft turned what could have been a truly great operating system into a joke.
Agree an opportunity wasn't just missed it was positively ballsed up.
The best manual I have ever seems was for the Coherent 3 unix clone operating system I used during my time at Uni. The university had Solaris machines, all I could afford was a 486 SX 25 and the $99 OS to go with it. The manual got me through Uni, it covered everything Unix right down to C programming. It was about a thousand pages thick. I’ve never seen anything like it since.
After I left Uni they did release a Coherent 4 which had X11 Windows support in 1992 which I did purchase, but having left Uni I never found a use for it. Windows for Workgroups was taking over the world, and it was another decade before I even came across another Unix implementation of any kind, and that was A Red Hat Linux web server circa 2005ish.
Nowadays any manuals don’t match the product I have in front of me. They don’t seem to keep up. Screen shots and instructions are just plain wrong and you’re pretty much left to fend for yourself.
That wasn't just a manual, that was The Coherent Lexicon. Possibly the best over-all operating system book ever published. It is still a valuable tool today, with the caveat that the details of CLI commands have changed, but that's easy enough to check with modern man pages.
It is available for the download here, but I suggest finding a dead-tree copy on fleabay or the like. I've also seen it in used bookstores, mainly in University towns. Why dead-tree? Because it doubles as a reference manual, and to date computers don't come close to actual books when looking up shit in a hurry.
Couple the Lexicon with a copy of ORA Power Tools, 2nd Edition (the Drill Book) and you've got a really, really good starter's kit on REAL system administration ... but again, with the above caveat.
You can also download & play with the actual Coherent OS, should you want to. A legally downloadable copy is archived at TUHS, here.
Have an upvote for having been a Coherent user. I purchased it back in the day to run on old 286 (IIRC) when the other alternative (for x86) was considerably more expensive Interactive UNIX. Probably the only example I can think of from top of my head, where something rather cheap was very very good. Thanks MWC! It was few years later when Tanenbaum's MINIX started to emerge.
Minix was fun - I had a 286 that I hammered it on for a while. Seems to no longer function as per the instructions any more. Though I'll just update VBox and have a check to make sure.
Still think the book that came with it was one of the most useful ever.
Update - seems Minix is all ok now and with X11 functioning. The 286 was a bit slower ISTR!
Just wondering if reading certain old software induces the smell of the manual? Different computers and OSes came with manuals all of which had different smells. Just writing about old code distantly triggers memories of the manual smells and the desks and near environments where I poured over them! I think if left in a library I could probably track down Prentice-Hall manuals by year!
Ah, that's synOSthesia that you're experiencing…
Even better if the manuals are rainbow 'colour book' series, for extra stimulus!
(And then there's the animals…)
Good pun - but actually memory not synaesthesia (I do that a bit with taste<>musical tones!!!). It seems the human smell and memory are really quite entwined. I paid a visit to a research lab my dad had been working at when I was 3 or so. I was surprised to discover as I walked down the long driveway in feelings of home despite the visual clues not working. Somehow bored a Masai warrior with this and he explained that even when things like fire wipe out trees that would normally be landmarks smell can still guide them to long used rest stops and water sources! Seems some aspect of smells is like GPS in the way it can get you from D,E and F to B after a long hike from A!
"Orchestration and lifecycle management have become the dominant operational issues because... Certainly not everyone who writes programs... needs to know how to keep that program running 24/7"
Mmmmm sorry, everyone who writes a program, especially server bound, will undoubtedly know how to keep the program running as a daemon or whatever, at least as far as RTFM'n to understand the runtime (X.500 was a shiny, painful examplel). Otherwise you're point of view is pretty spot on because If you're fond of 8, then you're probably a scripter, so yes it's very important for you. Then again, you're probably not the typical "user" nor a "programmer", thus an "admin" (which validates you're point of view).
Where the article's general point of view falls down is when things are broken... what do you do? Are you REALLY still an administrator or do you fallback to becoming a "user"? Or worse, a victim? (8) won't help you here the same way it can in a non-cloud environment, or course neither will 1,2,3,4...n.
Being a "cloud administrator" is the equivalent of being someone who excelled at MS FrontPage in 1999. It's handy and you can make money, but the manpages for what you're doing might not be aligned to where the end product runs. Stating 8 is very useful is a fact, so is mentioning that extra layer of abstraction that might make 8 not so useful.
But I can see everything that goes in and out of it, and I can physically reboot it (or turn it off!) whenever I like and according to whatever criteria that I like, and I can add and subtract hardware whenever I like, and I can be pretty certain that nobody is snooping on my business in any way, all unlike the meta-goo cloud.
Certainly clouds can be managed/micromanaged to an inordinately convenient degree, but to contend that can be a perfectly secure and exclusive gig provided by one favoured party, to the exclusion and detriment of all others, is not anything that real experience can endorse and support, because of what one then discovers is on offer just for the free taking.
The advantages and benefits which are delivered with such are/can be just too great a temptation with unparalleled reward to expect mere mortals and pirates and daemons to resist without sugaring that bitter pill.
The best that one can surely only hope to do is to make it very attractive, as in lucrative and extremely rewarding, for competent cloud managers/micromanagers to play nice and not misuse or abuse their intimate knowledge of systems processes/performance triggers/crash levers.
"Also, the config file looked like compressed EBCDIC. M4 files weren't much better."
Ha! I was going to post a comment to say: My limited experience of sendmail (strictly read-only, for a very very very limited value of "read" (I'm assuming that it is really mostly write-only code of a different form that generates the even more ghastly config files?), and thankfully it's very much Somebody Else's Problem [1]), is that as a daemon it surely must be a real eldritch horror, a Great Old One ensnared and trapped in silicon, yet still squirming as an iridescent many-dimensioned morass of transient black holes, and begetting madness on those who stare at it too long… (And never ever start sendmail with the --fhtagn option…)
[1] Makes me very glad that Debian uses exim by default, and has an idiot-proof configurator for the (very) limited use that I need to make of it on my home boxen.
20 years ago I've really enjoyed when a TCP/IP IBM redbook came to me just by luck.
I just don't know is they were the most accurate/precise/whatever but, for me, was the first time I've read a technical book both complete and also well writen.
Then 10 or so years later I've found another Redbook about Data Warehousing (my topic of interest) and again the same sensation of good quality reading arised.
(please forget my grammar, no native english here)
IBM did marvelous documentation. Not just the Redbooks but all the rest of it.
I still have my 1401 Autocoder manual and I have no doubt that I could relearn Autocoder from it if the need ever arose. I don't have my IBM 360 manual but it was detailed enough that I could probably take apart a 360, possibly test the components, and just maybe put it back together.
Then there are the most useful pieces of cardboard ever - the green (and other color) IBM Quick Reference Cards.
So much nicer than a QR code that directs you to the user forum.
The IBM manuals from back then are, indeed, good enough to restore the gear. That's why my 1401 (and attendant bits & bobs) runs today as well as it did back then. If you are fortunate enough to own any of that documentation, hang onto it. If you can't hang onto it, find a place to donate it. There are many places that accept such material for long-term storage and proper archiving.
I don't doubt that your recollections are correct, but mine vary.
At the time I was working for an IBM "mid-range" (i.e. AS/400) shop as "the PC guy".
AS/400 documentation was certainly comprehensive. It was also, most of the time, entirely useless. For a function named "bifurcate_differential_flange (or whatever) it would simply state something like "this function bifurcates differential flanges".
Microsoft adopted the same mindset for a time before abandoning the whole concept of technical documentation completely.
I do carry to this day an affectionate affectation for "this space intentionally left blank".
-A.
The original paper documentation for the RS/6000 was pretty good, having a reasonable UNIX-type manual with all the normal sections, together with a number of additional manuals on using, managing and programming for the RS/6000. Took up about around a metre of shelf space.
I suspect that this was because they were late to the UNIX market (yes, I know about the 6150, but that was a very halfhearted system), and wanted to try to impress people to switch from Sun, Apollo and SGI workstations, while having a stab at the VAX BSD and Ultrix, and HP/UX commercial market as well. That was certainly their intention with their telephone support, where they spent a lot of money recruiting people who could actually answer the questions directly without having to escalate.
But eventually, they stopped automatically shipping the paper manuals, making them a chargeable option on the order, and switched to an on-line (not internet, hosted on the system), CD (or on hard disk) Hypertext system.
Nowadays, it's all hosted on the Internet, and frankly a bit rubbish, as much of the info relates to very old AIX software that is no longer used, or has been watered down and spread about so much that it is almost useless (at least they've removed the section on graPHIGS which existed long after everybody stopped using it!) The RedBooks now contain much more useful information, as long as they last.
IBM also used to combine packages into big boxes strapped to pallettes when shipping kit, and sometimes needed to fill empty space to keep things from moving around.
I wish I had kept one of the boxes that said "This box is intentionally empty". It had an IBM part number and everything.
I have more positive memories of the AS/400 documentation. The doc shelf was about the size of the machine itself (the exact model of the machine and disk drives will come back to me eventually). It seemed like the manuals had everything needed.
Of course, I was more involved with the hardware, not the software.
AS/400 software was bash F4, F1, and F11 (or was it F10?) Until you got where I needed to be.
I remember reading the Novell APIs and discovering that if you were a print server, you could ask for owner rights on a file, so that you could access and print that file.
Unfortunately, if that owner was SUPERVISOR (Novell's version of root) then you also got supervisor rights.
And you could be a print server simply by advertising as one! So if a supervisor tried to print, then you could ask for rights on the file, become supervisor, then say you couldn't print the file anyway, so it went back in the queue and was printed by the real print server, with no one the wiser.
I also discovered that when you advertised as something, you got put in the bindery (a sort of object registry) of all the fileservers on the network.
Hmmm. What if I advertise as type "user" then I should be put in as a user for all the servers!
Well, you do!! Plus since it's the fileserver putting the object in, and FILESERVER > SUPERVISOR, then the other supervisors see this new user, go "huh?", try to delete it, and CAN'T.
Result: A bunch of pissed off fellow supervisors whom you now owe beers!!
The mentions of sendmail reminded me, because the ORA book on Sendmail was a godsend to a young wet-behind-the-ears sysadmin.
I remember when a couple entire shelves in the bookstores (remember bookstores?) were entirely ORA publications.
Now they've disappeared into their own navel and I haven't seen an ORA book in ages. I see they stopped publishing in 2017 according to Wikipedia.
I remember my company getting Safari, and Safari telling me to piss off because I wasn't running IE on Windows, and so I couldn't do its DRM. So much for open systems.
"In 2011, Tim O'Reilly stepped down from his day-to-day duties as O'Reilly Media CEO to focus his energy and attention on the Gov 2.0 movement. Since then, the company has been run by Laura Baldwin. Baldwin comes from a finance and consulting background. "
There ya go. That's why they're dead.
Dammit, I didn't know that O'Reilly, as we knew them, were no more. I only have a handful of O'Reilly books myself, but they were very useful, and generally well-written.
I suppose the thing is that as time passed it gradually became more and more easy to find the answer to your tech question somewhere on the web (the web that was originally built with the help of a lot of O'Reilly books, no doubt), and so we all gradually stopped buying the books as much?
The commodification/wikipedification of knowledge as it were, although, for tech questions, probably StackExchange sites just as much as Wikipedia itself (not necessarily a bad thing, as it makes knowledge available to those less financially well off).
Only in some regions. Elsewhere even a singular plethora (plethorum, anyone?) is clearly understood to be lots of things and therefore attracts a plural verb.
See also:
Microsoft are planning...
The red team are attacking...
But you could get away with "is" in all these cases if the context was clearly considering the group as a single-minded actor.
Your recollections of 4.2 BSD ring a clear bell with me indeed. Those memories go back to my first job with a Vax/780 which seemed to fall a large part of a room, though it did a commendable job of coping with a pretty big room of C programmers throwing work at it. Kudos to DEC for good hardware and the Berkeley and Bell labs for a well crafted bit of code that did a lot with very little (the MIPS rating of that machine was not high, but the I/O architecture was very good. Since I had (relatively) a lot of time on my hands I did read the fine manual, including some of section 8, and other sections on file formats and other arcana. The BSD manuals came with quite technical descriptions of Lex and the DSMs, written by somebody who went on to a certain fame at a well known search engine company, YACC and even as a recall quite a comprehensive description of how the Maclisp implementation worked.
As a famous author wrote “It was the best of times, it was the worst of times” - best because you could focus, the BSD manuals could actually be read in their entirety, there was no Internet, and the relatively low power of the machine (I think it had 4MB of memory for the whole company) meant you had to think about what you programmed in order that it would ever work. It was the worst of times since the software was much more limited, closed source (the company was not a university) and the network was limited to the local Ethernet- not even a UUCP connection, so no sharing of code, knowledge or ideas outside of that enclave.
My next job was with workstations, which were not only networked over the LAN, but connected to the outside world via UUCP over X.25. An amazing eye opener to the joys of open source on USENET groups and the oft time consuming battle of making it compile on a Unisoft Unix. A later encounter with sendmail marks my time there with a lot of pain - trying to understand how sendmail did what it did from the man pages was really hard. After weeks to wrestling with M4 macros and learning all about the ! Notation and % hacks, I finally got things to work, though the arrival of the O’Reilly sendmail book made me realize there was more to Mr Allman’s creation than met the eye. Around that time the Morris worm hit, and I learned about the wizard mode you mentioned, and discovered how buffer overflows had a wider consequence than segv: core dumped message I saw all too often when running my C applications. A little (OK a lot) later (with an interlude reading “The Cuckoo’s egg”) I was able to work in networks then computer security. Never a dull day since. Thank you BSD, section 8, chroot() and all the multitude of other good things that were invented then. We owe you a lot.
Will always have good memories of BSD 4.2 on VAX-11/750 and Sun 2/160 with a MC-68010 cpu. It was after Unix V7 on pdp-11 and VM/CMS on a IBM 370 the first modern OS I used, offering vi, a full screen editor which felt like science-fiction after using ed for years to edit files.
When it comes to concise technical specifications, the older the better.
There are many great documents available written by Dennis Ritchie en Ken Thompson: https://www.netbsd.org/docs/bsd/lite2/psd.html
NetBSD is a great replacement for BSD 4.2. For those needing a dedicated appliance like service on a Unix system, NetBSD is a viable alternative on bare metal or VmWare. Surprise your colleagues, "look, it runs on 256MB memory". It lacks the bloat of mainstream Linux, since people like Pottering wouldn't be allowed to go near it. Check out the CVE database for NetBSD
NetBSD runs on everything but Azure, since MS didn't compile its spyware, which comes with every Azure VM and runs with root privileges, for NetBSD.
lI remember starting with linux long long ago and just going into /bin /sbin etc and running man * and reading. Taught me so much, then I ran into crontab 5 mentioned, realized there were other man sections and read those. It was great foundational learning. That was always something I respected about OpenBSD--attention to man pages. Too many modern users really don't know how things work or care. To each his own, it fascinated me.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
