Re: [tlug] Printers for linux, was: refurbished Thinkpad X60 with Coreboot & Linux

[Benjamin Tayehanpour <benjamin@example.com>]

On 29 December 2013 01:30, Stephen J. Turnbull <stephen@example.com> wrote:
> Maybe, but my experience with that has been rather disappointing.
> Projects where documentation is neglected typically do not change
> their practices simply based on public pressure.  I think there's also
> a pretty strong pressure on copycat projects to get their user
> documentation up to snuff, so the documentation they produce ends up
> like commercial product documentation with video tutorials and screen
> shots of menus and dialogs with the relevant entry fields circled in
> red, you know the drill.

Ugh. Yes. This drill I know. While I suppose video tutorials might be
a good idea for people with reading or other cognitive disabilities, I
fail to grasp why (and when) they suddenly began to threaten to become
mainstream. Images and videos are impenetrable blobs of
human-eyes-only information. I don't want to listen to some dude
wheeze for half an hour into my ears, I want to ^F (or ^S or / or
whatever) and skip to the information I want, then absorb it at my own
rate. Fscking videos.

> Even with CUPS, I have to admit that their "documentation for the rest
> of us" is pretty good.  But from my point of view, CUPS does have a
> lot of accessible and repairable moving parts under the cover, and
> documentation on how to work with that is woefully sparse.  And I
> don't think that's going to change.

I admittedly haven't had to work a lot under the bonnet with CUPS, so
I'll take your word for it.

> Not at all.  If there was only doc, that makes a certain kind of
> sense.  But where there is doc and code, there are several possible
> outcomes -- I didn't say the doc was always right, only that the doc
> makes it possible to be *sure* there's a bug when doc and code differ.

Well, isn't that what code comments are for? *ducks* Seriously though,
you have a point there. Although one could argue that the definition
of right or wrong behaviour in code available for your perusal and
modification is simply "does it do what *I* want it to do?". In
theory, of course. Subject to massive amounts of can-be-botheredry.

> Broadly, they are make the doc fit the code, make the code fit the
> doc, and make both doc and code fit the specification that was
> intended.  (And of course there's the X.org approach, which is to
> shove your head in the sand and claim that "nonblocking" doesn't mean
> "in the face of error system states" if that would require another
> branch in your event loop.  Although actually they eventually put my
> patch in function, since experience showed it really sped up the
> function in practice (ie, compared to the infloop).)

It's a fossil, to be sure. What do you think of Wayland? Both the "is"
and the "could be".

> No, that's what you get for collaborating with people who work in
> native file formats for *their* system.  I really can't force my
> colleagues or my kids' teachers to use OOo or lo.
>
> Eg, did you know that top computer science departments have settled on
> Word files as their preferred format for admissions-related documents
> (student application essays, recommendations)?

I actually fought my university over the matter, and won. Though,
admittedly, it would be surprising if a university didn't listen to
reason and rational arguments. They'd kinda miss the whole point of
higher education if they didn't.

> No, I haven't.  XEmacs *used* to have a rather flexible and
> user-friendly graphical menu for setting default fonts, and excellent
> convenience APIs for creating faces.  Had that still been true, yes, I
> would have tried.
>
> But then two things happened: GNU Emacs got serious about GUI[1], and
> antialiased fonts.  The former turned what used to be an elegant API
> implementation into a mess, as GNU uses an ever-changing structure
> built of lists of alists of lists of plists (ad nauseum) to represent
> various GUI properties of interest in calculating faces, and we had to
> patch our implementation to match.  (And they declared this structure
> to be "internal", so backward compatibility didn't apply....)
>
> The latter was simply so attractive that even without menus, after
> about two years of vetoing inclusion of various Xft patches because
> they didn't include documentation or updates to the face configuration
> API, I was forced to swallow a patch that didn't include those
> features, on the grounds that the "many eyes would fix such shallow
> bugs quickly."  7 years later, although I ended up doing a lot of
> documentation, the UIs for dealing with fonts are still basically
> non-existent.  At least we've fixed the problem that prevented
> specifying Xft/fontconfig fonts from Lisp (actually only a small patch
> as it turned out, but the menus and customize are much harder).  When
> we first distributed betas with the patch included, the only way to
> set Xft fonts was through X resources!

Why did the song "Viva la vida" start playing in my head when I read this?

Thanks for an insightful history lesson. I never tested emacs myself,
so I've been blissfully out of range.

> Footnotes:
> [1]  RMS just started a thread about providing a mode for WYSIWYG word
> processing.  If they seriously try that, XEmacs will have an excellent
> chance to catch up and pass them in actually desirable features by 2020!

Sounds about right. :)

I never really understood the point of WYSIWYG word processing. Why
would I have the computer do something I can do better, and vice
versa?