The nightmarish problem of installing a printer
freebsd at edvax.de
Sat Sep 18 13:40:38 UTC 2010
On Sat, 18 Sep 2010 08:50:30 -0400, Jerry <freebsd.user at seibercom.net> wrote:
> On Sat, 18 Sep 2010 14:15:25 +0200
> Polytropon <freebsd at edvax.de> articulated:
> > Obviously not. Look at the dependencies, the bloat, and the
> > overall complicatedness of installing a printer. Also, the
> > documentation situation could be better. When dealing with
> > CUPS, foomatic and Gutenprint also enter the field, as well
> > as hp*d stuff that is not included (and needs additional
> > attention). There needs to be lots of action besides CUPS to
> > get it working for certain printers.
> The same could be said in regards to a lot of other applications.
That's sadly true. Many years ago, you could "pkg_add -r progname"
and then be sure that you have exactly what you needed. Today,
this is often a problem, just think about OpenOffice or Firefox.
Mainly X related stuff tends to "dissolve", as X itself does.
Parts of such software get faster obsoleted than properly docu-
mented. I think this is just a normal side-effect of "rapid
application development", or maybe the natural way of how soft-
ware evolves per se, to take advantage of faster and better
> You keep insisting that it is complicated; yet, you fail to
> specifically state what it is that you are failing to comprehend.
I mentioned the inability to install a printer that is currently
not connected, and in this special case, it was a parallel dotmatrix
> "bloat" comment makes no sense at all.
With today's big hard disks, lots of RAM and fast processors you will
be mostly right: Resources are plenty, so the need for efficient
programming isn't present anymore. Especially in GUI projects there
are abstractions of abstractions of abstractions of libraries
depending on libraries depending on libraries - of course intended,
as it's much easier to access resources in this way than accessing
the "bare metal".
> What you consider "bloat"
> another user might well consider essential.
That's surely true.
> Should we deny them in order
> to satisfy you?
I'm speaking out for choice. If tool A isn't able to do the job, there
is another tool B that is. But as soon as tool A is mandatory and
can't be replaced, subsequent calls will refer to A statically, and
B will be out of scope, and out of support, so it won't work anyway.
Pop goes the choice.
> What standards? Some arbitrary protocol that you or some other
> unofficial entity has determined to be the ONLY ACCEPTABLE protocol.
In X, PS is the standard for printing output. For printers itself,
there is PS, PCL and ESC/P, to name the three most known ones. But
what about printers that need to be injected a firmware before they
will be a printer? Or a printer that just as a specific driver for
some arbitrary outdated "Windows"? This is NOT standards. Just
imagine every printer manufacturer would make his own plugs. With
parallel / Centronics, USB and RJ45 (for network printers) we have
standardized connectors. Why can't we have standard printer protocols,
which means: Why can't manufactureres just use what's already
established? Now you might ask: WHERE is it established? Compare
office-class equipment to home consumer crap. You will see that
all the "expensive" printers can do at least PS or PCL (and in
most cases both, and maybe some more). They use the standards that
are common for those printers. Why not use them for home consumer
products as well? Where's the big problem (the BIG problem that
causes it NOT to be possible)? Technical answers are welcome.
> could very well be said that FreeBSD, and perhaps others, are failing
> to implement the commonly used protocols presently in effect by
> printer manufacturers.
That could be said, yes. Implementing a protocol requires the
protocol to be KNOWN. That might often be a problem.
> It is THEIR product. They have an ABSOLUTE right
> to create and distribute THEIR product as THEY see fit.
You are right. The conclusion on my side is NOT to by products that
> The constant and repetitious rantings that manufacturers are failing to
> follow some arbitrary, self proclaimed "standard" is wearing thin.
As I did prove, it's not about "self proclaimed standards", it's
about established ones, and they don't seem to be very arbitrary
as they are widely spread. You will notice that arbitrary stuff is
only present in niche markets, or already died out.
> Perhaps if the FreeBSD team decided to jump on the band wagon as
> opposed to trying to reinvent the wheel, the ease of integrating
> devices into the system would be simplified and thereby enhance the
> OS's standing and acceptance.
I'd love to see that - just an example: If one buys a combined inkpee
printer with scanner, attaching it to the system should make an ulpt
and uscanner device available. The ulpt will understand PCL or any
halfway standardized protocol that can easily be installed to the
system as a printer filter ("driver"). The uscanner will be accessible
by (x)sane / scanimage through its connection to a standard (!) SCSI
scanner device (pass).
> They again, bitching, complaining and
> blaming others is easier, and unfortunately, the common norm in today's
I think that's not true. See how many proprietary crap devices today
work well with FreeBSD. To be able to do so, developers did a really
great job - working with blackboxes isn't as funny as it may sound.
> "Never do for yourself, what you can blame on others" has
> become the new battle call.
Well... no. Where do you think most software for FreeBSD comes from?
We can even run "Flash" and other stuff that doesn't even support
the FreeBSD operating system!
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions