[geeks] Writing software [was Re: Can't decide on an OS]

[Jonathan Patschke]

On Tue, 1 Oct 2013, Mouse wrote:

> The biggest damage is the erosion of caring.  There was a time when it
> was reasonable to expect the admins of some random other site to (a)
> make a point of being reachable and (b) to actually care about things
> like protocol nonconformance.

That sounds like factually-incorrect nostalgia.  Systems that wanted to
interact with the net at-large have always had bletcherous hacks to work
around remote lossage.  There's an argument to be made that most of
Sendmail was written with that in mind.  Certainly that's been the case
with X--on both the toolkit and server ends.

> "Just" that?!  That's quite enough to be problematic.  I don't quite
> understand how people can think "here, execute this code some random
> server you don't know from Adam just handed you" can _not_ be a
> security issue.

It's mostly not-an-issue because of sandboxing.  There is the occasional
escape, but they're getting rarer.  Modern web user-agents go far above
what any of the published standards require for protecting the user,
largely because end-users demand this sort of thing.

>> I'm trying to think of what a parametric search would look like on
>> Mouser or Digikey without the web, though.
>
> I'm not sure what a "parametric search" is, so I can't do more than
> speculate wildly.

Okay, let's say you want a bipolar transistor with particular gain
characteristics, particular lead spacing, RoHS-compliance, and a thermal
response under some amount.  You don't care about the manufacturer, other
than you care about being able to order them in quantities of at least two
full reels at a time.  You need to commit to a specific part to finalize a
design's bill-of-materials.

This is the sort of question that required a dedicated person (either
within the customer's organization or sitting on a phone at each supplier)
to answer.  This question takes less than a minute to answer at either of
those two web sites, and I can't fathom any other way of doing it other
than having some vendor-specific application that talked to a remote
server (or logging into a vendor's server to run such an application on
their system).

It's a question of where you want the intelligence.  If you want it in the
client, and you don't want to be in the business of supporting client-side
software, AND you don't want to be in the business of supporting anonymous
access to some sort of interactive login session, you need something like
a web browser: it's scriptable and adept at tossing large documents back
and forth.  Yes, the UI is awful, but it gets the job done better than
anything that came before it.

Sure, these same things could be exposed to both the "web" and more
generically over a "restful" API[0].  Most sites don't do this because web
stuff is usually considered marketing or PR, and the art guys tend to be
in charge of that sort of thing.

And, yes, this is something that used to be a task that only a very very
small number of people cared about.  That's what I keep coming back to:
a widely-accessible way of presenting this information means that anyone
can be, for instance, an electronic hobbyist building things with a level
of fit-and-finish that you could never do with just your neighborhood
Radio Shack as a supplier.

> I once was able to get part datasheets out of Digikey's webpages, but
> last time I tried to do that - and every time I've tried to use Mouser
> for anything - I've failed completely.

Looking at the results from some random search, this looks like the sort
of thing[1] that Perl and LWP could do without too much trouble, although
it would require knowing the category ID they stuff into the URL (or
getting it from a more generic search).

So, get from /product-search/en/?k=thing-you-want, get again from the
anchor with the ID you care about, and then comb through the dreck for a
part number and its associated PDF link.  Done.

For automated fetching, this sub-optimal, but they're not exactly in the
business of providing an easy-to-automate datasheet clearinghouse.
They're in the business of moving product.

> They've improved their world-facing interfaces to the point where they
> are completely useless to me.  Worse than useless, because they lead
> them to provide no alternative.

It's useless to you because you will not use the tool it is designed to
interoperate with.  On a CP/M box or Commodore 64, FTP is useless to me,
but that doesn't make it useless in general.

>>> I'm having trouble finding that "beauty", much less finding enough
>>> of it to outweigh the dross.
>> In 1996, I was convinced that this web thing was just a fad.
>
> I wasn't.  I was excited by it.
>
> But that was before it got overrun and corrupted.  See my blah post of
> 2009-10-25, about how the amazing potential has been frittered away.

Use a user style sheet.  Render pages in whatever way you want.

No, lynx doesn't support them.  Lynx also doesn't claim to support the
HTML standard the doubly-indirectly-referenced CIO page requires (the
DOCTYPE element at the top of the HTML source indicates this).

For what it's worth, the CIO page renders beautifully in ELinks 0.11.7,
which actually receives standards-compliance upgrades from time to time.

>> Somewhere along the line, I came to the realization that I can bend
>> this clumsy tool into a thing that reduces the non-creative work I
>> need to do in my life.
>
> I probably could too, if I could tolerate it.
>
> I can't.  At least not yet.  Possibly never.  See, again, the post of
> 2012-10-31 and the various other posts on the same general topic.

That post describes a phobic response that I truly hope you can work past.
That level of frustration at something isn't healthy, and it's hurting you
a lot more than it's hurting any equipment manufacturer.

Going back to that moment, would you think on why a company would do such
a thing?

Consider the costs of printing, and how an "update-the-manual" step in the
firmware development loop would severely impact the response time for
correcting bugs, especially as a bug fix or enhancement that impacted the 
setup procedure would necessitate a "pipeline flush" of all the
documentation.

Now, documentation and device firmware must be synchronized, and there's
no way to do this that benefits either the vendor or the customer.

What would be an alternative?  An FTP URL is more-or-less the same to an
end-user, so that's a possibility.  What else?  If you were the
manufacturer, how would you have distributed the setup documentation in a
way that does not inhibit firmware development?

> Or you can push up the liability to them of doing so.

This is America.  Liability is in the eye of the company with the
better-paid representation.  YMMV up north.

>> It's in that company's interests for you to use the web site instead of
>> the phone number.  Their costs are less, and httpd doesn't ask for
>> smoke breaks.
>
> That option is not available to them and will not be.  Yet they insist
> on annoying me EVERY SINGLE CALL with those ads

I'm really trying to identify with this, and the closest I can come to is
my reaction to hearing an advertisement for USAA.  USAA is an organization
that provides various financial services solely to former and current US
Department of Defense employees and their immediate families.  By many
different measures, they're a really excellent company.

I don't really appreciate what the DoD does in my name on a global scale,
and I bristle at the notion that a company would only want business from
DoD employees, yet place their ads where anyone would hear them.  Is
something like this, perhaps, close to what prompts your response?

Because the company really isn't trying to annoy their customers.  They're
foremost trying to reduce costs and secondly realizing that, apart from
exceptional cases, most customers can meet their own needs faster through
the facilities provided by a comprehensive web interface than going
through a CSR over the phone.

Everyone has their preferences, and they're reminding you that there's a
potentially faster answer to your concern or inquiry than waiting in a
call queue.

> Not as "the market" is usually protrayed.  "The market" involves
> competition.  Where is the competition?  Where are these companies'
> competitors, the ones who _don't_ annoy callers with ads for their
> websites?

As recently as five years ago, there was a local bank that poked fun at
online banking.  Their radio advertisements featured a gravel-voiced old
man poking fun at the idea and emphasized "friendly-style banking, like
your grandfather expected."

They ceased posting a profit and were eventually absorbed.  Right now,
being web-hostile is not a way to win customers.

There's more competition against the web from the "apps" craze on these
hand-held computers that people call "smartphones," in spite of
ever-degrading audio quality.  In many ways, it's what you're asking for:
a purpose-build interface for each information source.

However, don't even think about separating presentation; increased
monitoring and control over presentation is the entire reason those things
exist.


[0] Which is, incidentally, how I design most of my web things so that I
     can enumerate/peek/poke the objects from another interface.
[1] Incidentally, a scraper/gatherer for this sort of thing is on my backlog of
     projects, but I never got past the part of figuring out how to legally
     run it on enough machines slowly enough that it wouldn't annoy the
     supplier.
-- 
Jonathan Patschke | "No matter how much the government controls...any
Elgin, TX         %  problem will be blamed on whatever small zone of
USA               |  freedom that remains."         --Sheldon Richman