You and any big company patent litigation department.
I was in Google's. The thing about old manuals and technology is:
It's all prior art. All of it. It doesn't matter at all if it no one used it and it faded into obscurity (I see you there: OS/2, BeOS, and Magic Cap). An inventor is assumed to be familiar with every single piece of technology that was published anywhere, anytime. You build a case that some patent was anticipated or rendered obvious by X, and you've usually won.
Working hardware is useful, but not essential.
If someone sues you for something you're sure was done in 1980: that 1980 manual is gold.
In the old days, manuals had to describe EVERYTHING, because you couldn’t Google/YouTube for your questions. Thus the 500-page beasts. Quite a contrast to today, where an iPhone comes with just a teensy pamphlet that if you’re lucky has an arrow to indicate the power button, and some 4-point type telling you not to stick it in boiling water.
Apple actually has pretty thorough user guides in the Apple Books store not just for each iOS major version, but for point releases as well. The latest one is iOS 15.2.
These also exist for other Apple products, but Apple could do a better job advertising them.
They might be somewhat thorough in the amount of features covered, but they are severely lacking regarding explanations and illustrations, compared to pre-internet documentation. My father, who is the type who reads manuals, but isn’t computer-savvy, has a hard time with the iPad manual.
Agreed! The team puts a lot of work into consumer documentation, wish their developer documentation was much better. There are so many undocumented intricacies in Swift, SwiftUI, and pretty much every framework or API Apple provides.
There is. Last christmas I had the idea to buy iPhones for my parents, side effect of that was finding out that there is 1000+ page manual for every iOS/iPadOS release which is localized for every country where the relevant thing is sold (well, there even is 200+ page manual for AirPods…)
Death Star supersite for old docs is bitsavers.org.
It doesn't have much consumer tech - Spectrum, Amiga, Atari, Apple - but it does have a lot of mainframe and mini manuals and docs, quite a bit of a S100 and PC, and even a few internal development and strategic memos and other historical docs from some of the major manufs.
In passing - minor grammar nitpick for OP. In a couple of places you've written "than what", which is not commercial English. "Than" is better on its own.
Wow, thanks, turns out bitsavers has firmware and information about a thin client terminal I recently was tinkering with. Neato! Actually want to contact the owner as, in the photos, the serial number of their device is 2 digits off from mine, interestingly!
Old documentation was based on the didactic principle of presenting the foundation before jumping into the specifics. Online documentation seems to forget that there's even such a thing as "foundational background".
I read a comment once (that it will be impossible for me to find again), that suggested that this is actually a baked in assumption and it depends on the audience.
Audiences in Europe were more likely to find it useful to be presented with the working theory first, and examples later, as a specialization of the theory.
American audiences tended to prefer working examples first, and then a generalization to form a theory.
The best datasheets do this too. However, I'm getting quite tired of skipping the section about I2C every time. I get it, there's logical highs and logical lows and those need to happen with certain timing constraints. Still, there those pictures are, every time.
Yeah, but it's easy to skip once you know what it is and that you understand it already. For someone who doesn't, having it present may be vital.
In my opinion, the same is true of computing - as a mentor, especially when working with folks who don't come to programming from a "typical" background, there's a lot of basic context that has to be conveyed precisely because so much of our docs assume they can leave out all the stuff that "everybody knows".
The worst is where you assume a vanilla implementation of some basic functionality, so you skip the explanation, but actually, there's a quirk inside that you only discover after scratching your head for a while.
Newbies are lucky in this way, that they don't have even a mistaken reason to skip reading the basics.
True, but they make up for it by being also very difficult to use in their intended role as aides-memoire, both because of the way they're written and because the relatively primitive format provides no aid to search or navigation.
I find `man X | grep Y` actually works OK, and the "see also" at the bottom is quite helpful for finding related information.
But if I don't already know exactly what I'm looking for, it's hard to use. It's really difficult to "learn about" how to open sockets if I can't remember sockaddr_t exact spelling or the right header to include.
On a BSD, try ‘man -Otag=l ls’ or ‘:tl’ (from less) for e.g. ls -l. This also works for larger man pages: ‘man -Otag=OCRNL termios’. More specifically, this requires the mandoc man implementation, which is also available on Linux — it’s what I prefer for all my machines.
tl;dr: it’s groff(1), not the -man and -mdoc formats, which is primitive (in this sense).
I2C is one thing, Dallas datasheets that completely document the relevant subset of the 1wire state machine are another beast…
On the other hand in the last month I have seen 40 page datasheets from Phillips/NXP/Nexperia that contain highlevel description of what the thing is supposed to do, ridiculously detailed description of I2C and reference to some kind of SDK that you should use to actually interface with the thing…
Lol, guilty - years ago I wrote a hardware manual / datasheet for a device with I2C interface. And I wrote yet another thorough I2C protocol section - and if I recall, nobody in the documentation department specifically asked for it - but all the similar datasheets did it so why not us - probably explains a lot. Did the timing diagrams in xfig.
I often find this for some libraries. Like the new library Foo.js "inspired by Bar and Baz, but better", where the documentation is made up of, say, two simple examples and that's it. Fortunately, often this is not the case and documentation is very well written.
The only reason you know not to put metal in the microwave is exactly because of 60 years of manuals. It's common knowledge now. You bet they talked about radiation and how a magnetron works in a microwave back the 60s.
Some of the 60 years worth of manuals get forgotten along the way. That's why you'll sometimes run into people who think you can protect your food from radiation by covering the food with a paper or plastic cover.
Or people who avoid microwaves because of radiation poisoning.
Maybe there's like a compromise where every X number of years, a product will come with a hefty manual which doesn't assume knowledge and starts at the basics as a refresher of sorts.
Actually, what I want more than anything to ship with thick manuals is skincare products. I have these more high end skincare products that came as a set and, let's be honest it was likely a waste of money. But I got it for the "experience," y'know?
Anyway, none of the products tell me how to use them. They don't tell me what order to use them in. They don't tell me how often to use them.
These are all things that you know if you're a girl and you don't know if you're a guy because, like you said, there are years worth of manuals--I just skipped those "lectures."
“Don’t put metal into the microwave” requires neither a thick manual nor theoretical underpinnings of electromagnetism. It requires a warning sticker.
Incidentally, there are types of metal dishes that can go into the microwave and yet most people today don’t know that, probably because nobody actually read the manuals, just the warning stickers.
I am by no means against understanding the theory behind what you are doing. My degree is in physics for a reason. But the “older is better” adage is tiring. I guarantee you that most people didn’t read the 200 page manual for their microwave oven and neither would most people today.
I also enjoy reading old computer manuals. You can learn a lot from reading them about how to structure technical material and how to write clear explanations (without assuming the reader is an expert). Sometimes, it's even a pleasure to read old computer manuals. And who can say the same about documentation today?
Here are two excellent examples of computer-related writing:
Usborne 1980s Computer Books
These books have been discussed a few times before here on Hacker News. Children's publisher Usborne have made available for free some classic computer books from the 1980s aimed at kids. The books use illustrations extensively to explain concepts. Not only are these books well written with clear, concise explanations, they are also more readable and enjoyable than many programming and computing books published for adults today. Anyone writing a technical guide (of any kind) would benefit from reading these as a source of ideas and inspiration:
Every entry in the Language Reference manual is formatted in a clear structured form. It still stands as an excellent template for any programming language reference:
Our first computer was a Mac Plus. As a kid, I read the various system manuals from front to back, several times over. Ditto for the manuals that came with different software programs, our printer, etc.
As I grew up, we got replacement computers, and I read the manuals for those too, building on the knowledge from the first computer. At some point, computers stopped coming with manuals. This seems a shame, but it's understandable since there are so many features.
Any tips on how to teach kids the basics of how to use a computer? Obviously they pick up a lot of stuff by watching, but how do you give them a good foundation in what an OS is, the basics of RAM, paging, etc.?
Video games can be great to introduce kids to computers and hardware. They might get interesting in building a computer to get good performance, which requires picking parts, looking at reviews and so on.
You can introduce them to more advanced OS concepts like memory through hacking. It's better if you have something to show and impress. Try following a tutorial beforehand to cheat in a solo game by changing some memory values. Try something old, most modern games have protections in place.
There is also the more creative aspect with modding. A kid making a map mod might begin to understand the concept of vertices, polygons, shading and so on. Shaders are an awesome too, although more advanced. ShaderToy has a nice interactive library.
It's very hard to get kids into something that's not immediately gratifying. It's better to go steps by steps, let them pick interests by themselves, and support them when they want to learn more. Torrent some CAD software if they need it!
Partial reason why I got into programming was because games I liked had map editors and mod support. At first the basics were fine, just making levels but the more and more I did them, the more power I wanted over the mods.. And thats when I got interested in programming. :)
I must have read the manual to our Star dot-matrix printer about twenty times. It had BASIC source code, all kinds of examples and illustrations and even info on how the parallel port worked.
To this day I remember the "crack" noise of flipping open the spiral-bound Applesoft BASIC manual (https://archive.org/details/apple-ii-basic-programming) and even the smell (slightly musty, slightly plasticky, slightly waxy- not like any book I've held before or since).
I liked it so much, I bought an Apple IIe and a copy of the manual on Ebay. It helped this old programmer remember learning to program.
When I reread it, I realized I've been programming BASIC in every computer language I used since I learned BASIC. That includes C, C++, Python, Perl, and even LISP. Well, not LISP.
I used to do Oceanographic research and we had a piece of equipment called a "shipboard gravimeter" originally built in the 1950s.
It was basically a very sensitive spring in a gyro stabilized platform attached to a bunch of analogue circuitry and was designed to measure the strength of the gravitational field (on a moving ship).
The manual for this equipment was amazing -- it literally taught you everything about the device and how it worked -- from the theory behind it to the purpose and function of each component.
In some sense writing a complete manual was easier to accomplish then than an equivalent manual would be now -- the a to d circuit used in a modern implementation would likely be more complex than the whole 1950s device ... but old manuals really are of a different quality and thoroughness than anything written for a modern audience ...
This is great. I regret getting rid of my old computers and manuals. The ZX Spectrum+ manual was indeed a joy, the C64 manual less so, and the Amiga manuals were a bit boring (though a friend kindly gave me some replacements for the latter a couple of years back). Anyway, I learned to program, in BASIC of course, from the ZX Spectrum+ manual, so I'll always have a soft spot in my heart for it. It's still genuinely better than most modern technical documentation and, though it covers all the bases quite thoroughly (excluding assembly and machine code), it's not even a very long read.
Now I'm really sad that I don't have the manual for the TI-99/4A which was the first computer I used. IIRC it's where I learned everything about both operating it and programming it, starting from nothing. It's so true that we just don't have anything like it anymore.
In the late 70s and early 80s I did a lot of programming on Texas Instruments DS/990 computer systems.
The manuals for those systems were quite interesting.
If you had a question, you could read the manual and swear that the manual did not answer the question.
Once you figured out the answer by some other means, if you went back to the manual and read it carefully you would discover that it actually did answer the question precisely.
I don’t think it was just me. Several of the people that I worked with on that project reported the same thing.
I really enjoyed working on the 16 bit mini computers from Texas Instruments. They were a lot of fun.
I have some of the TI-99/4A stuff that I had as a kid (and a few machines), but now I notice that the hardware is notoriously undocumented. Compare to something like the TRS-80 Model 100, which has full schematics and even a book written about things like how to write 8085 assembly to get the PIO chip to buzz the buzzer[1]. I have read that TI was very un-hobbyist/tinkerer and suffered in the market as a result.
For another era of stuff that I used growing up, PCs were by then complex enough (286/386/486 era) and/or commoditized enough that the systems weren't well documented.
I have a medium-sized collection of vintage 6502 assembly language books. I pick them up whenever I see them cheap. Some of the more sought after ones (like for the Atari 6502-based machines) are quite pricey.
Tangentially related, but as my hobby is game development, I love collecting old tomes of how to make different game engines in DOS. They're such a great blend of math, design, and hardware tricks.
The ZX Spectrum manual reminds me of the time in the UK when you had to purchase a plug in addition to your electrical appliance. It was also the consumer’s responsibility to ensure the plug has the right fuse. (The plug you just bought probably had a 13 amp fuse fitted.)
The Toshiba HX-10 MSX came with 2 plugs and a screwdriver. This was considered important enough to include a picture on the box, never mind the manual.
I saw it in eBay Germany years ago, but I did not realize on time that I wanted and missed the chance.
If someone has an original copy they’d like to send my way (at my expense of course), contact data is in my profile.
Having been too young to experience that period firsthand, those listings are a godsend when trying to work out what exactly the firmware does. The IBM PC manual doesn't even include an API table, it instead has it in the listing comments.
Manuals probably are the thing I miss most about older tech. Every electronic purchase came with a useful manual. Now even high price electronic items forgo a proper printed manual. I wish companies would value the magic a manual can add to the experience of getting to know a new piece of kit.
I was in Google's. The thing about old manuals and technology is:
It's all prior art. All of it. It doesn't matter at all if it no one used it and it faded into obscurity (I see you there: OS/2, BeOS, and Magic Cap). An inventor is assumed to be familiar with every single piece of technology that was published anywhere, anytime. You build a case that some patent was anticipated or rendered obvious by X, and you've usually won.
Working hardware is useful, but not essential.
If someone sues you for something you're sure was done in 1980: that 1980 manual is gold.