Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Oct 2011 00:52:49 +0200
From:      Polytropon <freebsd@edvax.de>
To:        FreeBSD <freebsd-questions@freebsd.org>
Subject:   Re: Fast personal printing _without_ CUPS
Message-ID:  <20111028005249.5977ec0c.freebsd@edvax.de>
In-Reply-To: <20111027174621.2dda6bdc@scorpio>
References:  <15996.1319704110@tristatelogic.com> <1319712142.89939.YahooMailNeo@web36507.mail.mud.yahoo.com> <20111027172944.75a96733.freebsd@edvax.de> <4EA989C2.6060909@infracaninophile.co.uk> <20111027133905.34315b83@scorpio> <20111027211132.78d4d1e4.freebsd@edvax.de> <20111027174621.2dda6bdc@scorpio>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Oct 2011 17:46:21 -0400, Jerry wrote:
> On Thu, 27 Oct 2011 21:11:32 +0200
> Polytropon articulated:
> 
> > On Thu, 27 Oct 2011 13:39:05 -0400, Jerry wrote:
> > > Printing under MS Windows is a breeze.
> > 
> > > The *nix community has never
> > > gotten printing up to that lever.
> > 
> > It _had_, past tense. :-)
> > 
> > > While there are those who continually
> > > blame the "manufacturers", the truth is that any COO, CFO {or any
> > > other alphabetic combination that you like} that seriously proposed
> > > the creation of a department dedicated to the writing of drivers for
> > > non-windows based systems, a department that would therefore have a
> > > zero based projected cash flow, would be removed from office
> > > posthaste.
> > 
> > Fully agree, but if established standards would have
> > been truly adopted by the manufactueres for their
> > products, there would be no need to develop any drivers.
> > One standard interface could address all printer
> > functionality, and maybe even more, such as scanning
> > or faxing functionalities quite common in the "egg-laying
> > wool-milk-sows" we see on the consumer markets.
> 
> First of all let me say that I love standards; there are so many of
> them to choose from.

I _knew_ you would bring that statement. :-)



> Secondly, I seriously hope that never comes to pass. Once you lock
> yourself into one specific interface the ability to innovate has been
> removed. I cannot think of a worse possible scenario.

Yes, this is a common problem with standards that are
narrow enough to _prohibit_ innovations, instead of
providing help for them. Standards like bus architecture
and cabling are the reason why many new products have
been developed in the past, bursting the margins of
what those standards provided. Just think about the
transition of buses where GPU hardware plugs in. Still
we do _not_ see a situation where every GPU manufacturer
requires its own expansion slot.

Other standards come from the media industry. Again,
selling items is the key here. If each publisher would
have used his own format to distribute music or movies,
what a mess it would be. "No, you can't play a Warner
movie on a Sony player, you need a Samsung player of
2008 or 2009 to play it. The 2010 version cannot be
used anymore, as they switched to a new innovative
format."

In such an imaginary case, it would be nonsense to
speak of standards. Standards are a form of consensus
among many parties. Sadly, some standards are seen
as "the worst common solution" in some fields, especially
from a technical point of view. Still they are used
because they just work. They have _proven_ to be
reliable - this is something new technology CAN'T
simply because it's too new. It's comparable to
claim that a pharmacy product doesn't have any
long-term effects right after introducing it to the
market!



> Three million years ago a branch of man figured out that he could
> sharpen a stone and use it to cut with. A new standard was born. One
> million years later that same branch had not figured out that they could
> attach a short piece of wood to that stone thus creating a handle and a
> new tool. They died out obviously. A perfect example of what happens
> when you cannot adapt.

Adoption is the strength of the week. :-)



> Standards in some circumstances may have their place; however, when
> they lock you into a culture where you are unable to adapt to newer
> technology or where your ability to innovate has been squashed, then you
> too are doomed to oblivion.

Fully agree - and if you are honest, it's the same
thing with proprietary products that live under the
reign of planned obsolescense. They are defined to
work under specific circumstances for a finite time
that the manufacturer sets up implicitely. This means
you have to say goodbye to a technology that exactly
fits your needs, but its manufacturer wants to sell
you something new that _maybe_ fits your needs, _maybe_
not, or with increased work or time (to _make_ it
work _again_).

Standards are the key to introduce new products.
Even in the realm of innovation, the typical
question of customers is: "Can I use it with...?",
and that is also the reason why there's still so
much legacy technology around. Just think about a
quite popular 10 year old "Windows" that's still
in wide use, even though it's obsolete since its
introduction. Adoption? Innovation? Improvement?
No thanks, we use what we know.



> > Sadly, "the one standard" doesn't seem to exist, and
> > manufacturers are not willing to discuss one. Of course,
> > such a standard would have to be free and open, so any
> > OS could implement it.
> 
> There you go putting restriction on how such an "standard" should be
> implemented.

Yes. In my opinion, this is a requirement to be
provided on a free market. Or people wouldn't have
learned anything from the big fails of history.



> I have a better idea. Why doesn't the *nix/*BSD {pick any
> other letter combination that turns you on} agree to one uniform method
> of implementing printer drivers and then let the manufacturers
> implement it on their end.

I would _LOVE_ that to happen! You can't imagine how
often I'm claiming that the UNIX and Linux world should
be the first one to introduce a really universal interface
where hardware developers could simply plug into, and then
write their drivers, open source or not (it's their
decision). Stable ABI and API are mandatory here.

On the other hand, such a stable interface could also
be seen as limited. "It doesn't have the feature XY we
want for our driver" could be a typical claim.

Really, I always did assume that some part of CUPS (or
Gutenprint, Foomatic, choose one, I've not fully understood
what those exactly are, I admit) _is_ that uniformed
method you're talking about.



> I have spoke to two company reps in the
> past year, one regarding printers, and both stated outright that the
> thought of writing and maintaining drivers on a multitude of platforms
> scares them to death. The problem is not with the manufacturers but
> rather with the fragmentation of the non-windows arena.

Even the "Windows" land is fragmented, as there are so
many of them with incompatible infrastructures, leading
to obsolescense because a driver of version X doesn't
work anymore on version Y, and the printer manufacturer
did decide not to support version Y.

According to market share, UNIX and Linux are not important
enogh on the main market, which is the home consumer market.
This might chance when more and more "deviants" walk out
of "Windows" land and move to Linux. Still "the Linux" is
not a target, as you correctly pointed out.

The "problem" with the manufactuers, as I explained, is
that they think in unit sales. The majority decides here,
or let's say the percentage of market share. It is that
simple, and even understandable from a financial point
of view. Units can be produced cheaper, so more units
are sold, and the investition for keeping the drivers
for _one_ version of "Windows" seem to justify it.



> I remember when "Hayes" ruled the modem world. The "Hayes command set"
> was the de facto standard. The along came U.S. Robotics and said, "Screw
> you Hayes and your friggin command set. We can do it faster and better
> without your crap." And, they did. The same can be said about Epson and
> their printer command set. Hell, the list goes on and on. Today, PS or
> PCL (there are strong supports on both sides of the aisle) might be
> king, but what about tomorrow.

Yes, that's what I'm also thinking of. It's not hust a
transition in protocols or languages, but also in hardware,
in cables and connectors, in form factors and slot sizes.



> Locking yourself into any technology is
> suicide.

The term "vendor lock-in" appears in this relation. It's
as dangerous and expensive as _any_ lock-in. As soon as
your own business is blocked because a key technology isn't
supported anymore, you're out of business.



> Classical "Dinosaur Thinking" as it is referred to in the
> business world.

You may refer to IBM as a living dinoraur. I'm sure you
know that essential (!) infrastructures, hardware and
programs are run on OS/360 derived systems. They date
back more than 40 years, and they are closed source.
Still there is a massive backup with money to keep that
technology alive and IN USE. Also see the AS/400 derived
systems, same thing.

This means: With enough money, you can keep any technology
running, be it superior or inferior, intelligent or
stupid, efficient or consuming. (You can easily conclude
WHERE such dinosaur-like technology is in use: Yes, in
fields where money doesn't matter, i. e. governmental
installations and other areas funded from public money
or big corporations that see a SHIFT in their technology
as even more expensive than keeping their dinosaurs on
artificial life support.)



> You do know what happened to those creatures when they
> could not adapt don't you.

They live in museums where people pay money to see them. :-)



> The fact that companies do not directly support *BSD, etcetera is not
> news. The fact that FreeBSD does not support the technology that is
> available (does the phase "N Protocol ring a bell") is the problem that
> should be addressed. 

Yes, it should. I just think it's again a problem (or a
fact) of financial backup on BSD's side. Here the fact
applies that BSD isn't measured in unit sales (and
therefore not in market share), so it's considered
fully unimportant, even non-existent.



> > There's a reason for that: Companies that develop
> > printers want money. They need to continuously sell
> > printers, and there's an ongoing "renewal" of hardware
> > and software, e. g. new printer requires new OS, new
> > OS requires new printer. This is done by planned
> > obsolescense.
> 
> You can make that statement in regards to cars, airplanes, etcetera. It
> is just an empty sound bite. By the way, since the days of DOS, I have
> never purchased a printer that then required me to update my OS.

Usually the printer version X doesn't require it, but
the printer version X+1 does. It's often "the next thing"
that reaches the border of what's possible with the
current installation.

I've seen companies moving complete infrastructures to
the garbage dump because one "key feature" wasn't supported,
and therefore everything was bought new. The "rotation time
of hardware" depends on many factors.

To name one example: A small company has been using
a set of card readers. Then a new appliance was introduced
to the company, but this one, the "key technology", did
not work with the established card readers anymore. The
"next thing" in the product line of card readers didn't
have support for their current "Windows", so they had to
buy a fleet of new PCs to run a newer (today also outdated)
"Windows" in order to fully activate the "key technology".
Just maybe... if they had purchased a different product
for their "key technology" that did work nicely with the
established equipment, they could have saved lots of
money - assumed of course that a competitor would offer
such a product on the market.



> I have  the ability to use a driver from Win95 up to XP, and in a few
> case even Vista.

Depends on the hardware and the driver. As I said, I've
seen many contrairy examples.



> On the other hand, updating FreeBSD to a new major
> version number and in the case of the nVidia display driver even a
> minor number, causes me to force a rebuild of the system. Just for
> clarification, a minor system update with nVidia only causes me to have
> to rebuild that port. The same exists also for at least LSOF. There may
> be more however.

Since the introduction of binary updates, this shouldn't
be a problem. Even on our today's plentycore processors
with tenmelonhundred gigahertz and tons of GB RAM this
should be a simple task. In my opinion, this is far
easier and more comfortable than some... alternatives.

There's always the option _not_ to update, as it is also
very common in "Windows" land. Just keep what you have,
and never touch a running system.

However, introducing _new_ hardware to such a system
can lead to problems. I'm typically encountering this
with home consumer products in the printing, scanning
and multimedia sector, and of course very often in wireless.
Then I remember how easy the use of a SCSI scanner was.
Put in controller card, load ahc module, start xscanimage.
No drivers, no fiddling with permissions, no compiling,
not tons of ports to install - just works.



> At some point though support for anything will cease, unless you prefer
> to live in the dinosaur age.

Again, this _highly_ depends. There are many customers
who do not intend to "advance" as industry wants them to.
They do a specific set of actions and establish a toolset
that exactly does that. In their opinion, they want to use
that toolset until they will be retired. And there are
also examples where handcrafters use tools they got from
their father, and the father got them from his father and
so on. There isn't much you can invent on a hammer. :-)



> > On the other hand, this business model benefits the
> > development of new technology (financed by unit
> > sales), and making technology cheaper to purchase.
> 
> Business 101
> 
> I know dozens of college students that use inexpensive ink-jets
> printers because the are:
> 
> 1) inexpensive
> 2) easy to install

Inexpensive is a typical short-term view. The printer
is cheap, as it doesn't contain much electronics (as
there is no "intelligency" for turning data into inkhead
movements, this is done by the PC, the printer just needs
to count page loads to determine when it's supposed to
be BROKEN), but the ink may be more expensive than the
printer. Recently seen: Printer for 25 Euro, cartridges
(ink reservoir plus printing head) 20 Euro + 30 Euro.

Oh, and regarding printing: The Jevons paradox:

http://en.wikipedia.org/wiki/Jevons_paradox

Just BECAUSE it's so inexpensive, it will consume resources
much faster (ink and paper).

The "easy to install" claim can be invalidated by the
fact that most "computer-illiterate" people delegate
the work to install a printer to someone else, leading
to the misbelief that it has been easy (as they didn't
have to do it theirselves); I know many "PC professionals"
who are fully unable to perform an "easy install" on
their own, even _if_ it is really easy.



> Trying to get an ink-jet printer to work on FreeBSD can be a whole new
> experience in frustration.

Oh yes.



> The manufacturers created a product to fit a
> particular niche in the market place. The fact that FreeBSD cannot
> accommodate that is a problem.

FreeBSD simply isn't an attractive target audience at
the moment. See market share for a "non-market product".



> I just spent several hours trying to convert a linux printer driver to
> work on FreeBSD. Of course, both platforms use a different hierarchy
> which then requires me to attempt to manually modify the files to point
> to the right location, etcetera.

A commonly known program. And hierarchies differ among
Linux distributions too, so even if there's a driver for
one system, it doesn't neccessarily work on a different
one.



> I still have not gotten it to work.
> This is with only one driver on one PC. I can easily see why any
> manufacturer would not want to be bothered with this bullshit.

Most "help centers" would be unable to deal with UNIX
stuff as it requires thinking, reading, deduction and
abstraction, and it cannot be run by a "point by point"
checklist.



> Microsoft has used the same basic method for the installation of
> printer drivers since Win95.

System's "Add / Remove", installer provided by the
manufacturer, .INF files, various "wizards", use
of the printer "control panel"... all with a
different look & feel depending on the kind
of "Windows" you're using - yes, this colorful
dance is the basic method since "Windows '95".



> However, you cannot even get Linux/*BSD,
> etcetera to agree on a common, uniform hierarchy for and method of
> implementing printer drivers. I couldn't care less if they used CUPS.
> LPR or whatever just as long as they get a unified method in place.

Yeah... still returning to business 101... as
unit sales are insignificant in the Linux and BSD
markets, manufacturers wouldn't invest work in
making separate printer drivers.

The idea would be to have an OS-independent solution,
but I would assume this never gets through.



> If such a system were in place, there would be no problem in getting
> developers to write the necessary drivers. Hell, if they did it right
> they could use the Windows drivers.

Yes, as I said! This of course would require some very
specific kind of compatibility that is not given in
relation with proprietary closed-source products. As
I mentioned in my previous message: This would introduce
the ability of free operating systems to keep things
working that the manufactueres want to remove from the
market to sell a new product.



> However, we both know that they
> (the OS developers) would rather bite off their nose than do that out
> of pure spite.

Hmm... I wouldn't see any problems here as long as it
is possible with acceptable investition. Of couse, as
soon as lawsuits in patent law, licensing and other
non-market stuff enters the field, every attempt is
sentenced to die before it starts. When customers can
be held liable for using a printer driver...



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111028005249.5977ec0c.freebsd>