The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Will Senn <will.senn@gmail.com>
To: Marc Rochkind <mrochkind@gmail.com>,
	Kevin Bowling <kevin.bowling@kev009.com>
Cc: TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: Proliferation of book print styles
Date: Sun, 2 Jun 2024 08:50:02 -0500	[thread overview]
Message-ID: <8d091003-2e75-45f1-a233-1a577265c3d7@gmail.com> (raw)
In-Reply-To: <CAOkr1zWE6OHC_d0ZbU3rni6NLRbyjp0XHHF1=AQ4fBgnezYbxg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 8492 bytes --]

Marc, it and its successors are great books for sure, thanks for writing 
them!

I like having access to digital works, no complaints about access other 
than I wish I had access to everything ever written and some way to sort 
through it all quickly and easily. I'm more inclined to gripe about the 
quality of the work than it's medium. Both the writing quality and the 
production quality. If the target is pdf, make it a good pdf that when 
printed is a space considerate, easy to read, and efficient to process 
work, and when it's target is screen, do the same.

My only real gripe about the medium, is the disconnect between quality 
writing and production, and the unavoidable but hidden nature of 
proportions that are inherent in the virtual medium. A crazy example... 
I recently got out my 8086 handbook because I was doing x64 assembly 
work and couldn't locate what I was looking for in the x64 equivalent 10 
volume set online. A quick flip through the pages found what I needed 
and I was on my way. So, being a thoughtful person ;), I figured it was 
just a matter of having the book on hand, so I order one up... a week 
later, my x64 "manual arrived", all 10 volumes in a box about 14 inches 
tall, and 8 1/2 by 11 and weighing, well, I only picked it up once, but 
it was friggin' heavy as in bend the knees heavy. Anyhow, I dutifully 
opened it up, pulled out the relevant "book", volume 3 part 3 or 
something and flipped and flipped and flipped some more and found the 8 
pages discussing the same thing covered in a paragraph in the 8086 book. 
Now, I realize that parallel pipelines of AVR 512 SIMPLEX/42 has some 
impact on the REPNZ command in situations where the quarf rejects the 
quam, but really pages for a paragraph and not because it required 
pages, they could have single spaced the document, proportioned the 
margins to a readable width, put the base cases in prominent positions 
and put the quarf and quam notes in separate appendices. They didn't - 
they just keep adding and adding and adding and the page count just 
keeps growing and growing. Why? Because they can and because folks are 
hungry for information.

I appreciate that they put it out there, but is it ok for me to wish it 
were of higher quality and to note that the old stuff was better? BTW, I 
didn't read the 8086 manual back in the day, when it was printed, I read 
it the day after I went looking at the x64 docs.

Will



On 6/2/24 3:08 AM, Marc Rochkind wrote:
> True enough, Kevin, but with the decline of printed books and the 
> increase in online docs, I rarely find what I'm looking for in a 
> printed book and, when I think I have, the price is very high for what 
> may turn out to be a bad guess. Browsing a bookstore for serious 
> computer books is no longer possible, except maybe in very large cities.
>
> For example, for an upcoming project I need up-to-date and 
> authoritative information on Kotlin and AWS S3 APIs.
>
> Living in the past, I find, is no help!
>
> Marc Rochkind
> (author of the first book on UNIX programming)
>
> On Sun, Jun 2, 2024, 7:12 AM Kevin Bowling <kevin.bowling@kev009.com> 
> wrote:
>
>     On Sat, Jun 1, 2024 at 7:31 PM Will Senn <will.senn@gmail.com> wrote:
>     >
>     > Today, as I was digging more into nroff/troff and such, and
>     bemoaning the lack of brevity of modern text. I got to thinking
>     about the old days and what might have gone wrong with book
>     production that got us where we are today.
>     >
>     > First, I wanna ask, tongue in cheek, sort of... As the inventors
>     and early pioneers in the area of moving from typesetters to print
>     on demand... do you feel a bit like the Manhattan project - did
>     you maybe put too much power into the hands of folks who probably
>     shouldn't have that power?
>     >
>     > But seriously, I know the period of time where we went from hot
>     metal typesetting to the digital era was an eyeblink in history
>     but do y'all recall how it went down? Were you surprised when
>     folks settled on word processors in favor of markup? Do you think
>     we've progressed in the area of ease of creating documentation and
>     printing it making it viewable and accurate since 1980?
>     >
>     > I didn't specifically mention unix, but unix history is forever
>     bound to the evolution of documents and printing, so I figure it's
>     fair game for TUHS and isn't yet COFF :).
>     >
>     > Later,
>     >
>     > Will
>
>     I think your other topic is closely related but I chose this one
>     to reply to.
>
>     I own something well north of 10,000 technical and engineering books
>     so I will appoint myself as an amateur librarian.
>
>     When I was younger, I had the false notion that anything new is good.
>     This attitude permates a lot of society.  Including professional
>     libraries.  They have a lot of collection management practices around
>     deciding what and when to pitch something and a big one is whether the
>     work is still in print, while a more sophisticated collection will
>     also take into account circulation numbers (how often it is checked
>     out).  A lot of that is undoubtedly the real costs surrounding storing
>     and displaying something (an archived book has a marginal cost, a
>     publically accessible displayed book presumably has a higher
>     associated cost) as well as the desire to remain current and provide
>     value to the library's membership.
>
>     From what I have seen, there isn't much notion of retaining or
>     promoting a particular work unless it remains in print.  As an
>     example, K&R C is still in print and would be retained by most
>     libraries.  The whole thing becomes a bit ouroboros because that leads
>     to more copies being printed, and it remaining in collections, and
>     being read.  Obviously, this is a case of a great piece of work
>     benefiting from the whole ordeal.  But for more niche topics, that
>     kind of feedback loop doesn't happen.  So the whole thing comes down
>     in a house of cards... the publisher guesses how many books to print,
>     a glut of them are produced, they enter circulation, and then it goes
>     out of print in a few years.  A few years later it is purged from the
>     public libraries.  As an end user, one benefit to this collapse is
>     that used books are basically flooded into the market and you can get
>     many books for a fraction of their retail price used.. but it becomes
>     difficult to know _what_ to get if you don't have an expert guide or
>     somewhere to browse and select for yourself.
>
>     So why does this all matter to your more meta question of why less
>     great books?  There is less to no money in it nowadays for authors.
>     The above example of library circulation represented a large number of
>     guaranteed sales to wealthy institutions (academic and government =
>     wealth, don't let them pretend otherwise).  Except now many libraries
>     have downsized their physical collections to make room for multimedia
>     or just lower density use of space.  So there are less guaranteed
>     sales.
>
>     Another facet of the same coin, one reason printed books are great has
>     to do with the team surrounding their production.  If you look near
>     the colophon, you will often find a textbook will have quite a few
>     people involved in moving a manuscript to production.  This obviously
>     costs a lot of money.  As things move more to ebook and print on
>     demand, it's an obvious place to cut publishing expenses and throw all
>     the work directly onto the author.  That may result in cheaper books
>     and maybe(?) more revenue for the author, but it won't have the same
>     quality that a professional publishing team can bring to the table.
>
>     As to my deliberate decision to accumulate the dead trees and ink,
>     it's because although online docs are great I find my best learning is
>     offline while I use the online docs more like mental jogs for a
>     particular API or refamiliarizing myself with the problem domain.  I
>     have some grandeur ambitions that first involve a large scanning
>     project but that will have to await more self funding.
>
>     Regards,
>     Kevin
>

[-- Attachment #2: Type: text/html, Size: 11342 bytes --]

  reply	other threads:[~2024-06-02 13:50 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-02  2:31 [TUHS] " Will Senn
2024-06-02  2:44 ` [TUHS] " Peter Yardley
2024-06-03 21:42   ` James Frew
2024-06-04  5:49     ` Dave Horsfall
2024-06-04 22:54       ` Dave Horsfall
2024-06-07  7:58         ` Peter Yardley
2024-06-02  4:03 ` Kevin Bowling
2024-06-02  8:08   ` Marc Rochkind
2024-06-02 13:50     ` Will Senn [this message]
2024-06-02 21:21     ` Kevin Bowling
2024-06-02 13:13   ` Will Senn
2024-06-02 12:39 ` Douglas McIlroy
2024-06-02 12:45   ` arnold
2024-06-02 12:55   ` Will Senn
2024-06-02 14:31   ` Al Kossow
2024-06-03  9:53     ` Ralph Corderoy
2024-06-04  4:26       ` Dave Horsfall
2024-06-02 14:48   ` Stuff Received
2024-06-02 17:44     ` Ralph Corderoy
2024-06-02 15:21   ` Michael Kjörling
2024-06-02 20:22     ` Åke Nordin
2024-06-04 13:22   ` Marc Donner
2024-06-04 14:15     ` Larry McVoy
2024-06-04 14:48     ` Ralph Corderoy
2024-06-04 14:53     ` Warner Losh
2024-06-04 15:29       ` Grant Taylor via TUHS
2024-06-05  0:13       ` Alexis
2024-06-07  7:32       ` arnold
2024-06-04 21:46     ` Adam Thornton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d091003-2e75-45f1-a233-1a577265c3d7@gmail.com \
    --to=will.senn@gmail.com \
    --cc=kevin.bowling@kev009.com \
    --cc=mrochkind@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).