Fast personal printing _without_ CUPS

[Polytropon]

On Fri, 28 Oct 2011 16:04:19 -0400, Jerry wrote:
> On Fri, 28 Oct 2011 21:12:54 +0200
> Polytropon articulated:
> 
> > So let me make this more clear: IF the hardware manufacturer
> > wants to allow developers to write drivers for their hardware
> > for free, THEN everything they'd have to do is to publish the
> > control codes for the sheet feeder and the ink pee motors.
> > Conclusion: If they don't do it, they don't want developers
> > to do so. It is their RIGHT, because they own the product,
> > and they may sell it under any circumstances they think will
> > lead to profit. Market rules again.
> 
> I am just going to reply to this one point because it is where you
> entire argument breaks down.
> 
> Assume Big Corporation creates a new printer known as "Printer-101" and
> releases its code for any moron, sorry I meant expert to use to write
> OS specific drivers for.
> [...]
> We haven't even touched on what happens if Big Corporation finds a
> glitch with the printer and needs a modification in its firmware and
> modifications to Poly's driver script. Who supplies them and what
> happens when Poly disappears?

Valid point, haven't thought about that yet. The
implications are interesting...

It does not invalidate my argumentation, but it is
worth being considered. "Bad advertising" could be
considered a downside in unit sales, such as it
happens with GPU vendors whose cards to not work
properly on Linux -- they won't get recommended
for use, instead a competitor will make the sale.
But the manufacturers can create that effect theirselves
by releasing crappy drivers. Due to the short life
of hardware, they don't seem to consider drivers
an essential part of their product, as it "does
break next year anyway", an attitude fully matching
the current "state of the art", the throwaway society.
That's why driver support is often designed towards
(and limited to!) a specific kind of "Windows" (as
they make the main target audience, the majority,
the biggest slice of market share).

Fully understandable from a corporate point of view.
Shortsighted in many cases maybe, but understandable.

Why invest time (and therefore, money) in developing
Linux drivers when the product will be withdrawn in
the next year anyway, and the amount of Linux users
going to buy the product are nearly zero, so the
revenue will be quite small, and in _no_ relation
to the investition of developing drivers.

Take USB hard disks for example. As manufacturers
have decided to use _one_ plug, as well as _one_
command set, I can virtually buy any external hard
disk without worrying about compatibility, and I
don't need any company to develop a driver for
that disk for the OS I'm using.

I wish this could be the default situation with
any device, be it a media player, printer+scanner,
USB toy or anything else. A standard that gives
a broad interface with _all_ options available
so the manufacturer can invent any extraordinary
functionality he wants, depending on that "tool-
set". Basically, that's what their current drivers
do: They take a limited set of commands (in some
programming language, assembler, C, whatever is
currently considere "modern" in "Windows", who knows)
and implements the functionality with this _closed_
set of tools, creating something new. Why not do
that with a toolset that's available anywhere, and
that can be ported to any new platform? Without
paying license fees and handing them over to
customers, hoping on the "good will" of possible
competitors who hold the licensing rights so
they won't destroy the product, and maybe the
whole manufacturing company?

The big chance: The "Yes, it also works on ..."
could increase unit sales, and the perspective for
the future would be good: Without developing sets
of new drivers (for different kinds of "Windows"
on different architectures, {m,n}-matrix) they
could state that their product will also work with
future devices. Interoperability, maybe this will
also be more important in the future?

A unified structure that gets PROPERLY (!) implemented
on different platforms could be the solution. It
would not limit inventions or further development.



> Check out "MOVED" in the ports. There are numerous applications that
> are just abandoned or discontinued. If something breaks I want someone
> to contact. I realize that is not the Open Source way however. The
> thought of someone actually being responsible is rare indeed.

There are companies offering support for payment, while
the product they are using and promoting basically is
free of charge. Maybe such a model could be adopted in
such cases?



> I buy my cars from known corporations and not the local chop-shop. My
> drugs come form known pharmaceutical corporations and not the local
> pusher. I like my device specific codes to come from those best able to
> supply them, the OEM.

This is what you _need_ to rely on as long as you cannot
validate the products yourself. In many cases, you need
very precide knowledge, maybe technology and tools, to
be sure. This is _knowing_. By purchasing, you can only
hope that the seller didn't lie to you. I would call
that _believing_.

After all, prices do _not_ imply quality! I think you
can remember many "established and trusted companies"
that came out with absolutely overpriced crap.

Just because you _trust_ them does NOT mean that they
are worth being trusted. Their goal is not to provide
you a safe, ecological and easy to use car, a good
medicine curing you, or a device that will do what
you need. You _hope_ they do, and you often _feel_
they do, but without validation, you can't be sure.



> As stated in another post, if a suitable platform were created for
> manufacturers to distribute their drivers, whether it be printers,
> modems, wireless devices, etcetera, the problem would be solved.

I agree it's complicated, but with some consensus
it sounds at least possible. In other fields it is
reality (like unified plugs, unified chargers,
unified rules), why not regarding drivers?



> Of
> course it is easier for all the non-windows based OSs to have a pissing
> contest rather than create a unified front so I am confident that the
> prospect of that occurring in my life time are nil.

Diversity vs. unification... a discussion going
to burst the list's capacity and purpose. :-)

You just have to consider what's the trend at the
moment, and in my experience, the trend is growing
diversification, not just within the Linux and UNIX
world, but also in "Windows" land, as well as among
devices in general (esp. mobile market).




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