Fast personal printing _without_ CUPS
This isn't really a question. It's more of a semi-rant, combined with some information that I wanted to put on the record (so that it can be googled) because it may benefit some folks, other than just me. I'm impatient by nature, and I don't like CUPS. (I would say that I hate it, but I don't actually feel that strongly.) I have two personal workstations. When I say personal I mean it. I'm the only one who ever touches them. One of them I have been bringing back up recently after a long hiatus, and I've just installed 8.2-RELEASE/amd64 on it. One of the first things I found I needed to do with it, after installing the OS and a bunch of my favorite ports packages was to set it up for printing to a crusty/trusty old workhorse... an HP Laserjet 3015. (This printer can print both plain text and Postscript, but if I just send it plain text the output doesn't really suit me, so I've made it prettier. See below.) Because I've never used 8.2 before... or even any 8.x release, I naturally went into the Handbook and looked for _current_ guidance on setting up printers. Most of that information was quite helpful, right up to the point where it started discussing CUPS. The bottom line is that CUPS is sophisticated, which is to say complex and convoluted. If you are impatient, then setting up CUPS properly is both tedious and time consuming. Of course, it _is_ essential that you properly set up CUPS if you are setting up a _server_ that multiple people will use, but for a personal workstation, the entire queueing structure is just overkill, in my opinion. More importantly, CUPS, for me at least, seems to be quite slow. There's a lng pause after I queue something for printing until something actually comes out of the printer. Maybe that's my fault, e.g. because I didn't con- figure CUPS correctly, and maybe it isn't. I don't know, and actually, I don't want to know, because I found a way to nicely print stuff that just bypasses CUPS entirely. And it works for me, so I am a happy camper. I just wanted to share what I did. In a nutshell, I moved/renamed /usr/bin/lpr to /usr/bin/lpr- and replaced it with this trivial script: #!/bin/sh printer='/dev/ulpt0' if [ $# = 0 ]; then cat | /usr/local/libexec/psif $printer else for arg in $* ; do cat $arg | /usr/local/libexec/psif $printer done fi My Laserjet 3015 used to be hooked up via a good old fashioned bulky centronix parallel cable, but I thought that I ought to finally get myself into this century, so I got a new USB 2.0 cable for it just the other day, and now it's name is /dev/ulpt0 rather than /dev/lpt0 as before. As you can see, the script above just takes whatever filnames are given on the cmmand line and cats them one-by-one through psif and then the output from that gets sent straight to /dev/ulpt0. One little snag though... as I found out, it doesn't matter if you try to set the SUID bit on this script and make it owned by root. Nowadays shell scripts simply do not do SUID anymore. The only reason that's even signifi- cant is that you'll probably want to be able to print while logged in as any old user, and in order to make that work with this scheme, you have to do: chmod 0666 /dev/ulpt0 so that any user can write to the printer device file. I only fiddled a couple of other small things in order to make this all work. Firstly, I created my own versions of /usr/local/libexec/psif-text and also /usr/local/libexec/psif-ps. Here they are: /usr/local/libexec/psif-text: = #! /bin/sh /usr/local/bin/textps -c 10 -l 60 -m 38 -t 46 printf \004 exit 0 = /usr/local/libexec/psif-ps: = #! /bin/sh /bin/cat printf \004 exit 0 = The parameters for textps that I have in my psif-text file were just some parameters that I slapped together after running a few tests to see what values created output that looked good to me. Your milage may vary. After I set up all of the above stuff, I noticed that my attempts to use the lpr command to print things from non-root user accounts was still resulting in very long delays before anything would print. It took me some head scratch- ing but I finally found the problem. In a nutshell, the problems was that at one point while I was trying to get this all going, I did in fact install the CUPS package (and friends). As I learned, when you do this you get the following _different_ version of lpr installed in a place where normal user accounts are likely to see it in their $PATH first: /usr/local/bin/lpr Yikes! So we've got
Re: Fast personal printing _without_ CUPS
From: Ronald F. Guilmette r...@tristatelogic.com To: freebsd-questions@freebsd.org Sent: Thursday, October 27, 2011 4:28 AM Subject: Fast personal printing _without_ CUPS This isn't really a question. It's more of a semi-rant, combined with some information that I wanted to put on the record (so that it can be googled) because it may benefit some folks, other than just me. I'm impatient by nature, and I don't like CUPS. (I would say that I hate it, but I don't actually feel that strongly.) I have two personal workstations. When I say personal I mean it. I'm the only one who ever touches them. One of them I have been bringing back up recently after a long hiatus, and I've just installed 8.2-RELEASE/amd64 on it. One of the first things I found I needed to do with it, after installing the OS and a bunch of my favorite ports packages was to set it up for printing to a crusty/trusty old workhorse... an HP Laserjet 3015. (This printer can print both plain text and Postscript, but if I just send it plain text the output doesn't really suit me, so I've made it prettier. See below.) Because I've never used 8.2 before... or even any 8.x release, I naturally went into the Handbook and looked for _current_ guidance on setting up printers. Most of that information was quite helpful, right up to the point where it started discussing CUPS. The bottom line is that CUPS is sophisticated, which is to say complex and convoluted. If you are impatient, then setting up CUPS properly is both tedious and time consuming. Of course, it _is_ essential that you properly set up CUPS if you are setting up a _server_ that multiple people will use, but for a personal workstation, the entire queueing structure is just overkill, in my opinion. More importantly, CUPS, for me at least, seems to be quite slow. There's a lng pause after I queue something for printing until something actually comes out of the printer. Maybe that's my fault, e.g. because I didn't con- figure CUPS correctly, and maybe it isn't. I don't know, and actually, I don't want to know, because I found a way to nicely print stuff that just bypasses CUPS entirely. And it works for me, so I am a happy camper. I just wanted to share what I did. In a nutshell, I moved/renamed /usr/bin/lpr to /usr/bin/lpr- and replaced it with this trivial script: #!/bin/sh printer='/dev/ulpt0' if [ $# = 0 ]; then cat | /usr/local/libexec/psif $printer else for arg in $* ; do cat $arg | /usr/local/libexec/psif $printer done fi My Laserjet 3015 used to be hooked up via a good old fashioned bulky centronix parallel cable, but I thought that I ought to finally get myself into this century, so I got a new USB 2.0 cable for it just the other day, and now it's name is /dev/ulpt0 rather than /dev/lpt0 as before. As you can see, the script above just takes whatever filnames are given on the cmmand line and cats them one-by-one through psif and then the output from that gets sent straight to /dev/ulpt0. One little snag though... as I found out, it doesn't matter if you try to set the SUID bit on this script and make it owned by root. Nowadays shell scripts simply do not do SUID anymore. The only reason that's even signifi- cant is that you'll probably want to be able to print while logged in as any old user, and in order to make that work with this scheme, you have to do: chmod 0666 /dev/ulpt0 so that any user can write to the printer device file. I only fiddled a couple of other small things in order to make this all work. Firstly, I created my own versions of /usr/local/libexec/psif-text and also /usr/local/libexec/psif-ps. Here they are: /usr/local/libexec/psif-text: = #! /bin/sh /usr/local/bin/textps -c 10 -l 60 -m 38 -t 46 printf \004 exit 0 = /usr/local/libexec/psif-ps: = #! /bin/sh /bin/cat printf \004 exit 0 = The parameters for textps that I have in my psif-text file were just some parameters that I slapped together after running a few tests to see what values created output that looked good to me. Your milage may vary. After I set up all of the above stuff, I noticed that my attempts to use the lpr command to print things from non-root user accounts was still resulting in very long delays before anything would print. It took me some head scratch- ing but I finally found the problem. In a nutshell, the problems was that at one point while I was trying to get this all going, I did in fact install the CUPS package (and friends). As I
Re: FreeBSD 8.2-RELEASE Install Failure: Unable to create a new /etc/fstab
Just following up...I resolved the issue by copying /etc/* to /stand/ in the mfsroot. On Tue, Oct 25, 2011 at 12:54 PM, Rick Miller vmil...@hostileadmin.com wrote: Hi All, I am Installing 8.2-RELEASE via PXE and receive an error stating that sysinstall was unable to create new /etc/fstab. Everything appears to function correctly, in that, the system TFTP's the pxeboot and mfsroot files as needed. However, When I switch to the holographic shell and poke around a little, I can see that there is no /etc, despite it's existence in the mfsroot.gz. I must be missing something and am hoping that someone might be able to point in the right direction. -- Take care Rick Miller -- Take care Rick Miller ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: nice man pages?
On Wed, 26 Oct 2011 19:08:47 +0200, Patrick Lamaiziere wrote: Le Tue, 25 Oct 2011 22:43:29 -0400, Robert Huff roberth...@rcn.com a écrit : I use sysutils/most to have nice manual pages in color, that's cool but is there a way to do this with the base system (ie without adding port)? I believe the answer will be Not going to happen. Color is nice, but the system is desugned so it can be easily run when the system console is something indeterminate at the other end of a 300 baud serial line. We have ls with color (and no problem with serial console, there is no color when using it). Why not a nice manual? The Midnight Commander comes with a file viewer that can display manpages in color: % mcview /usr/share/man/man3/signal.3.gz A very nice manual. Additionally, there's xman. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On Thu, 27 Oct 2011, Ronald F. Guilmette wrote: Because I've never used 8.2 before... or even any 8.x release, I naturally went into the Handbook and looked for _current_ guidance on setting up printers. Most of that information was quite helpful, right up to the point where it started discussing CUPS. There's a separate article about CUPS on the Books and Articles Online page: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/cups/index.html I just wanted to share what I did. In a nutshell, I moved/renamed /usr/bin/lpr to /usr/bin/lpr- and replaced it with this trivial script: ... As you can see, the script above just takes whatever filnames are given on the cmmand line and cats them one-by-one through psif and then the output from that gets sent straight to /dev/ulpt0. ... The only thing that worries me about my rather ad-hoc way of setting up a personal printer (as describe above) is that I sort of wonder what will happen if I ever try to print something when something else is currently printing. There's also the issue of printing large files, which will tie up the command line until the printer has buffered them all. It can be backgrounded, but... Setting up lpd isn't much more involved, and should be able to handle many more unanticipated corner cases. (Does anybody think that maybe this should go in the Handbook?) Maybe. The Handbook printing chapter is already kind of overstuffed and disjointed. Here's my take on setting up lpd, covering the current important stuff and building step by step: http://www.wonkity.com/~wblock/docs/html/lpdprinting.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
I'm not a huge fan of CUPS, but at this point it's the best of a bad lot. I find the queueing useful, since I often print documents long enough that I don't want to wait. More importantly, CUPS, for me at least, seems to be quite slow. There's a lng pause after I queue something for printing until something actually comes out of the printer. Yeah. I have a similar printer with a similar problem. I believe that what's going on is that the current version of CUPS tells all the clients to print to PDF, then for printers that don't handle PDF, converts that to postcript using ghostscript which is very, very slow. I think this is a bug. A few versions ago it used to tell clients to print postscript which it can send directly to my printer. I also looked at using pdftops, which is much faster, to convert the PDF, but the call to ghostscript and the ghostscript command options are wired into the CUPS code and were more hassle to change than I wanted to do. R's, John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: nice man pages?
Polytropon writes: I use sysutils/most to have nice manual pages in color, that's cool but is there a way to do this with the base system (ie without adding port)? We have ls with color (and no problem with serial console, there is no color when using it). Why not a nice manual? The Midnight Commander comes with a file viewer that can display manpages in color: The issue is not having a nice manual; the issue is having it in the base system. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On Thu, 27 Oct 2011 03:42:22 -0700 (PDT), Bill Tillman wrote:
This isn't really a question. It's more of a semi-rant, combined with some
information that I wanted to put on the record (so that it can be googled)
because it may benefit some folks, other than just me.
I'm impatient by nature, and I don't like CUPS. (I would say that I hate
it, but I don't actually feel that strongly.)
Let's shake hands, and allow me to add that I'm lazy. :-)
I have two personal workstations. When I say personal I mean it. I'm
the only one who ever touches them.
One of them I have been bringing back up recently after a long hiatus,
and I've just installed 8.2-RELEASE/amd64 on it.
One of the first things I found I needed to do with it, after installing
the OS and a bunch of my favorite ports packages was to set it up for
printing to a crusty/trusty old workhorse... an HP Laserjet 3015. (This
printer can print both plain text and Postscript, but if I just send
it plain text the output doesn't really suit me, so I've made it prettier.
See below.)
Using PS with a Postscript printer is the default. It's
exceptional (!) ability to also process pure ASCII text
isn't used in many cases, but can be helpful if you need
to bypass the printer spooler mechanism for some reason
and just have to print simple listings, like
% ls /etc | awk '{ printf %s\r\n, $0; }' /dev/lpt0
or /dev/u(n)lpt0 if the printer is connected locally.
Because I've never used 8.2 before... or even any 8.x release, I naturally
went into the Handbook and looked for _current_ guidance on setting up
printers.
Due to the many standards (correct: many deviations) in
what printer manufacturers sell to their dear customers,
there's hardly a one size fits all recipe. If you have
a _standard_ printer (ASCII, PS or PCL), things are quite
easy. If you haven't -- you usually have purchased a home
entertaiment ink pee sheet feeder egg-laying wool-milk-sow --
you need a more conplex solution.
Most of that information was quite helpful, right up to the point
where it started discussing CUPS.
The bottom line is that CUPS is sophisticated, which is to say complex and
convoluted.
In my opinion, CUPS is the Windows way of doing things,
not the UNIX way. Hate me for having that opinion, but I
feel to say it.
If you are impatient, then setting up CUPS properly is both
tedious and time consuming.
It is, I've tried it many times, and meanwhile I consider
writing my own printer filters the easier task!
Of course, it _is_ essential that you properly
set up CUPS if you are setting up a _server_ that multiple people will use,
but for a personal workstation, the entire queueing structure is just
overkill,
in my opinion.
Setting up printer server functionality without CUPS is
very easy, given the fact that you actually bought a
real printer. :-)
More importantly, CUPS, for me at least, seems to be quite slow. There's a
lng pause after I queue something for printing until something
actually
comes out of the printer.
Hmmm... In my experience, it depends on what you input
to the CUPS queue. Things like pictures may take a while
for rasterization and PS translation, other things are
out on paper much faster. I have to say that I'm using
an Ethernet-connected Laserjet 4000d here.
Maybe that's my fault, e.g. because I didn't con-
figure CUPS correctly, and maybe it isn't. I don't know, and actually, I
don't want to know, because I found a way to nicely print stuff that just
bypasses CUPS entirely. And it works for me, so I am a happy camper.
Isn't that what everyone wants?
BUT: CUPS seems to be hardcoded into many applications
today. They stopped working with the non-CUPS default
system tools. An example is Opera. Another one is Gimp
which works with system lp* tools, but has hardcoded
queries to lpstat (a CUPS program that doesn't exist
or cannot connect to the server). The upcoming question
here is: WHY???
I just wanted to share what I did.
In a nutshell, I moved/renamed /usr/bin/lpr to /usr/bin/lpr- and replaced
it with this trivial script:
#!/bin/sh
printer='/dev/ulpt0'
if [ $# = 0 ]; then
cat | /usr/local/libexec/psif $printer
else
for arg in $* ; do
cat $arg | /usr/local/libexec/psif $printer
done
fi
Yes, this is how many printer filters work. Collections
like apsfilter (that work WITH the system lp* tools, unlike
CUPS!) bring gs-based printer filters for PS, PCL and many
other devices.
% cat /opt/libexec/ps2pcl-dup.sh
#!/bin/sh
printf \033k2G || exit 2
gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER -dSAFER -sPAPERSIZE=a4 -r600x600 \
-sDEVICE=ljet4d -dDuplex=true \
-sOutputFile=- - exit 0
exit 2
This is one of my gs-based printer filters (derived from
apsfilter, no pretty-printing here,
Re: [zfs-discuss] ZFS on Dell with FreeBSD
Le 19/10/2011 à 19:23:26-0700, Rocky Shek a écrit Hi. Thanks for this information. I also recommend LSI 9200-8E or new 9205-8E with the IT firmware based on past experience Do you known if the LSI-9205-8E HBA or the LSI-9202-16E HBA work under FreBSD 9.0 ? Best regards. Regards. -- Albert SHIH DIO batiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 Heure local/Local time: jeu 27 oct 2011 17:20:11 CEST ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Status of linuxprinting.org
Does anyone know if this site: http://www.linuxprinting.org/ is down permanently? I has been off line for several weeks now. The friendly message greets a visitor to that site: *** * This site is down for maintenance. We will be restoring service * * shortly. Thank you for your patience. * * * * The Linux Foundation* *** That message has been in place for quite some time now. I was hoping to find a specific printer driver there. -- Carmel ✌ carmel...@hotmail.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On Thu, Oct 27, 2011 at 5:29 PM, Polytropon free...@edvax.de wrote: BUT: CUPS seems to be hardcoded into many applications today. They stopped working with the non-CUPS default system tools. An example is Opera. Another one is Gimp which works with system lp* tools, but has hardcoded queries to lpstat (a CUPS program that doesn't exist or cannot connect to the server). The upcoming question here is: WHY??? (...) CUPS also has program names that are derived from LPR's competitor. The lpstat command is such an example, and I think lpadmin also is. lpstat and lpadmin are standard SysV tools for printing. They existed LONG before CUPS: http://developers.sun.com/solaris/articles/print/sol_lp1.html Please note that there are two distinct toolsets for (traditional) UNIX printing: * lpr tools for BSD printing * lp tools for SysV printing Please don't call the BSD lpr toolset lp tools, that's pretty confusing to us old-gen sysadmins. ;-) Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On Thu, 27 Oct 2011 18:17:55 +0200, C. P. Ghost wrote:
On Thu, Oct 27, 2011 at 5:29 PM, Polytropon free...@edvax.de wrote:
BUT: CUPS seems to be hardcoded into many applications
today. They stopped working with the non-CUPS default
system tools. An example is Opera. Another one is Gimp
which works with system lp* tools, but has hardcoded
queries to lpstat (a CUPS program that doesn't exist
or cannot connect to the server). The upcoming question
here is: WHY???
(...)
CUPS also has program names that are derived from LPR's
competitor. The lpstat command is such an example, and
I think lpadmin also is.
lpstat and lpadmin are standard SysV tools for printing.
Ah, thanks for reminding me to that fact. As I said, I
knew they came from another system which was different
from BSD's lpr / lpd / lpq / lprm tools.
They existed LONG before CUPS:
http://developers.sun.com/solaris/articles/print/sol_lp1.html
Please note that there are two distinct toolsets for (traditional)
UNIX printing:
* lpr tools for BSD printing
* lp tools for SysV printing
Please don't call the BSD lpr toolset lp tools, that's pretty
confusing to us old-gen sysadmins. ;-)
I'll keep that in mind, thanks, and I hope to also grow
old as a sysadmin so I get educated properly to use the
correct terminology. :-)
toolsets = {
lp /* System V */
lpr /* BSD */
CUPS/* the future, the bright and happy future! */
}
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On 27/10/2011 16:29, Polytropon wrote: In my opinion, CUPS is the Windows way of doing things, not the UNIX way. Hate me for having that opinion, but I feel to say it. Actually you can't blame Bill for this one. CUPS is an Apple / MacOS X thing. I must say, it works really smoothly on my MacBook -- I just plug in the USB cable from my printer and hit print -- but I never got it to work properly under FreeBSD. (Mostly that was because I had the system lpr working just fine on my old FBSD machine connected to the printer using a parallel port. Newer hardware doesn't even have a parallel port now.) Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Fast personal printing _without_ CUPS
On Thu, 27 Oct 2011 17:41:38 +0100, Matthew Seaman wrote: On 27/10/2011 16:29, Polytropon wrote: In my opinion, CUPS is the Windows way of doing things, not the UNIX way. Hate me for having that opinion, but I feel to say it. Actually you can't blame Bill for this one. CUPS is an Apple / MacOS X thing. I must say, it works really smoothly on my MacBook -- I just plug in the USB cable from my printer and hit print -- but I never got it to work properly under FreeBSD. (Mostly that was because I had the system lpr working just fine on my old FBSD machine connected to the printer using a parallel port. Newer hardware doesn't even have a parallel port now.) If I remember correctly, CUPS started as a Linux project and was then incorporated into Mac OS X. Yes, no problems there, I've seen it work smoothly as intended, but not on FreeBSD so far. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
El día Thursday, October 27, 2011 a las 07:00:39PM +0200, Polytropon escribió: Actually you can't blame Bill for this one. CUPS is an Apple / MacOS X thing. I must say, it works really smoothly on my MacBook -- I just plug in the USB cable from my printer and hit print -- but I never got it to work properly under FreeBSD. (Mostly that was because I had the system lpr working just fine on my old FBSD machine connected to the printer using a parallel port. Newer hardware doesn't even have a parallel port now.) If I remember correctly, CUPS started as a Linux project and was then incorporated into Mac OS X. Yes, no problems there, I've seen it work smoothly as intended, but not on FreeBSD so far. :-) CUPS 1.4.3 is just working fine for me on FreeBSD 9-CURRENT, SunOS and Linux SLES. You configure the (network) printers through the web interface, or with lpadmin(8) and you just print from cmd line with lpr(1), from KDE or Gnome apps. It allows also to print UTF-8 textfiles (rendered to Postscript with the correct glyphs on the flight) or has a PDF backend to create PDF printouts the 'normal' way (by printing them to a PDF printer) to the local file system. HIH matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On Thu, 27 Oct 2011 17:41:38 +0100
Matthew Seaman articulated:
On 27/10/2011 16:29, Polytropon wrote:
In my opinion, CUPS is the Windows way of doing things,
not the UNIX way. Hate me for having that opinion, but I
feel to say it.
Actually you can't blame Bill for this one. CUPS is an Apple / MacOS
X thing. I must say, it works really smoothly on my MacBook -- I just
plug in the USB cable from my printer and hit print -- but I never got
it to work properly under FreeBSD. (Mostly that was because I had the
system lpr working just fine on my old FBSD machine connected to the
printer using a parallel port. Newer hardware doesn't even have a
parallel port now.)
Printing under MS Windows is a breeze. The *nix community has never
gotten printing up to that lever. 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.
Even the few companies that do write a limited set of drivers for the
exceedingly fragmented *.nix community tend to stick with vanilla Linux
and perhaps Debian. It took nVidia years (literally) to get FreeBSD to
update their product to the point when nVidia could supply 64 bit
drivers.
I recently spoke with a representative from Brothers regarding
securing a driver for one of their laser printers. He himself is a
Linux man and said that he felt my pain. He also informed me that while
it had been discussed from time to time, it was always felt that it
would be a lose-lose situation. They do supply drivers for Linux and
Debian but that is about it. He stated that it was felt that the cost
of writing drivers for a widely fragmented community and then having to
support said drivers would just not be financially feasible.
Printing has come a long way from the parallel port configuration.
Many now use wireless connections for instance. I love wireless
printers myself. However, here again problems arise. FreeBSD supplies
virtually no N protocol certified drivers which negates the
effectiveness of an N protocol based wireless printer.
--
Jerry ✌
jerry+f...@seibercom.net
Disclaimer: off-list followups get on-list replies or ignored.
Do not CC this poster. Please do not ignore the Reply-To header.
http://www.catb.org/~esr/faqs/smart-questions.html
signature.asc
Description: PGP signature
Re: Fast personal printing _without_ CUPS
Quoth Ronald F. Guilmette on Thursday, 27 October 2011: #!/bin/sh printer='/dev/ulpt0' if [ $# = 0 ]; then cat | /usr/local/libexec/psif $printer else for arg in $* ; do cat $arg | /usr/local/libexec/psif $printer done fi Not to be a pedant (okay, maybe I am), but you could eliminate the extraneous `cat` in both commands: #!/bin/sh printer='/dev/ulpt0' if [ $# = 0 ]; then /usr/local/libexec/psif $printer else for arg in $* ; do /usr/local/libexec/psif $arg $printer done fi Nice work, though! -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpwEVMHl5Jyk.pgp Description: PGP signature
Re: [zfs-discuss] ZFS on Dell with FreeBSD
On Thu, October 27, 2011 11:32, Albert Shih wrote: I also recommend LSI 9200-8E or new 9205-8E with the IT firmware based on past experience Do you known if the LSI-9205-8E HBA or the LSI-9202-16E HBA work under FreBSD 9.0 ? Check the man page for mpt(4): http://www.freebsd.org/cgi/man.cgi?query=mptmanpath=FreeBSD+9-current http://www.freebsd.org/cgi/man.cgi?query=mptmanpath=FreeBSD+8.2-RELEASE Or LSI's site: http://www.lsi.com/products/storagecomponents/Pages/LSISAS9205-8e.aspx http://www.lsi.com/products/storagecomponents/Pages/LSISAS9202-16e.aspx Do you know how to use a search engine? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On Oct 27, 2011, at 10:39 AM, Jerry wrote: Printing under MS Windows is a breeze. The *nix community has never gotten printing up to that lever. Of course Unix has had functional printing; the issue is mostly dumb printers which can't accept PostScript or at least PCL, and need an OS-specific driver to rasterize for the device. A secondary problem is X11's imaging model with the dichotomy between on-screen imaging and print imaging. For examples of Unix printing done right, look back to NEXTSTEP twenty years ago, using Display Postscript and Pantone colorimetry to provide true WYSIWYG; also, Sun's NEWS and OpenWindows also had the DPS extension to X. Most of that technology is still around under MacOS X, although DPS has largely been replaced by a PDF imaging model instead. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
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.
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'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.
Just imagine you had a printer that would work with
any OS. First of all, you wouldn't buy a Windows,
so the deal between the manufacturer and MICROS~1
would break: We make our devices for your 'Windows',
you tell us about your interfaces, and we make a
driver for your current product. You would be able
to use your printer with a free OS. Furthermore,
if this free OS got updated, you would continue
using your printer because the new OS would also
support it, unlike Windows that would not have
support for the printer anymore, encouraging you
to buy a new one.
On the other hand, this business model benefits the
development of new technology (financed by unit
sales), and making technology cheaper to purchase.
Downside here again: The cheaper printers become,
the more paper is wasted for printing. Yes, I know
the paperless office is a pure utopia, but I've
seen things... scary things...
Example: In a company I know emailing is quite new.
When office A wants to send a document to office B
per email, A prints the email message and faxes it
to B, where it also gets printed (inkpee and laser
faxes). After that, B checks for new messages and
then prints the message he received.
Even the few companies that do write a limited set of drivers for the
exceedingly fragmented *.nix community tend to stick with vanilla Linux
and perhaps Debian. It took nVidia years (literally) to get FreeBSD to
update their product to the point when nVidia could supply 64 bit
drivers.
Right, it simply doesn't pay in the first place to
support that fragmented... can I say target point?
It's more like a whole forrest of targets that's
changing very often. :-)
Really, I agree that the same business logic applies
in driver support. As the success of free systems is
not measured by unit sales, there is no such thing
as market share for them. But market share decides
about what manufacturers pay attention to.
In the past, they were forced to support certain
standards in order to get their devices sold. A
printer that could not be addressed by standard
Epson codes just wouldn't sell. Later on, PS was
the only thing you could sell a printer. (The same
applied to graphics cards which needed to support
standardized command sets in order to work properly.)
Today, this is not important anymore as individual
drivers for specific Windows versions are the key
to unit sales. This is of course a short-term
decision, but finally most three-letter-superiors
decide by quarterly numbers.
This _may_ turn out to be contraproductive in the
end. The decision makers just hope to have moved
to a different position when this happens where they
get a better wage for less responsibility. :-)
I recently spoke with a representative from Brothers regarding
securing a driver for one of their laser printers. He himself is a
Linux man and said that he felt my pain. He also informed me that while
it had been discussed from time to time, it was always felt that it
would be a lose-lose situation. They do supply drivers for Linux and
Debian but that is about it. He stated that it was felt that the cost
of writing drivers for a widely fragmented community and then having to
support said drivers would just not be financially feasible.
Interesting. I always thought CUPS (which is common across
the many Linusi, as well as standard in Mac OS X) would have
a PPD plugin (or was it the Foomatic stuff? I can't properly
tell...) that allows printer manufacturers to write
drivers according to that documented interface, so there's
no need to code hardare- or OS-specific things anymore,
Re: Fast personal printing _without_ CUPS
In message 20111027143609.60335.qm...@joyce.lan, you wrote:
I'm not a huge fan of CUPS, but at this point it's the best of a bad
lot. I find the queueing useful, since I often print documents long
enough that I don't want to wait.
I don't quite understand the issue you are raising john.
Even with my direct-to-/dev/{u}lpt0 approach, if I needed to print a really
big file, I would just start the print in one window and then minimize that
one and continue on working in my other windows. I mean in what way would
one need to wait?
More importantly, CUPS, for me at least, seems to be quite slow.
There's a lng pause after I queue something for printing
until something actually comes out of the printer.
Yeah. I have a similar printer with a similar problem. I believe
that what's going on is that the current version of CUPS tells all the
clients to print to PDF, then for printers that don't handle PDF,
converts that to postcript using ghostscript which is very, very slow.
Huh??
John are you saying that my documents, some of which *start out* as .PS files,
are converted by CUPS to .PDF and thence (since I don't have any printers
that speak PDF) the document is then converted *back* to Postscript for
actual printing??
If so, I can sure see why the multiple pointless conversion would indeed
take up a lot of time.
I think this is a bug.
If it is, then I think it may be a long-standing one.
I did something very like what I just described doing on FreeBSD 8.2 also
back on my old FreeBSD 7.0 system which I first installed maybe three years
of more ago.
I can't really remember anymore if I did it primarily for speed reasons or
because (as now) I just didn't want to have to go thru all fo the falderall
of properly configuring CUPS, but I suspect it was both.
Regards,
rfg
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
In message alpine.bsf.2.00.1110270834540.94...@wonkity.com, Warren Block wbl...@wonkity.com wrote: ... The only thing that worries me about my rather ad-hoc way of setting up a personal printer (as describe above) is that I sort of wonder what will happen if I ever try to print something when something else is currently printing. There's also the issue of printing large files, which will tie up the command line until the printer has buffered them all... Tie up the command line ?? John Levine attempted to make the same point, and I'm still not really getting it. This is why we have X! I can have all of the command lines that I want, and I frequently do. I have at least 15 different xterm windows open as we speak, so I really don't see tying up the command line as a real issue. Regards, rfg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
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.
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.
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.
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.
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. 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 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.
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. Locking yourself into any technology is
suicide. Classical Dinosaur Thinking as it is referred to in the
business world. You do know what happened to those creatures when they
could not adapt don't you.
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.
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.
Just imagine you had a printer that would work with
any OS. First of all, you wouldn't buy a Windows,
so the deal between the manufacturer and MICROS~1
would break: We make our devices for your 'Windows',
you tell us about your interfaces, and we make a
driver for your current product. You would be able
to use your printer with a free OS. Furthermore,
if this free OS got updated, you would continue
using your printer because the new OS would also
support it, unlike Windows that would not have
support for the printer anymore, encouraging you
to buy a new one.
I have the ability to use a driver from Win95 up to XP, and in a few
case even Vista. 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
Re: Fast personal printing _without_ CUPS
You've just made me a happy, happy user. I always wondered what it would take to get rid of CUPS, and today I've done it. Finally my print jobs are instantaneous here at work instead of being a mystery. Can't wait to go home and do the same with my personal laser. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
I'm not a huge fan of CUPS, but at this point it's the best of a bad lot. I find the queueing useful, since I often print documents long enough that I don't want to wait. I don't quite understand the issue you are raising john. $ lpr foo $ lpr bar $ lpr baz It will print the three files in a row, starting each when the previous one is done. Like, you know, a print queue. John are you saying that my documents, some of which *start out* as .PS files, are converted by CUPS to .PDF and thence (since I don't have any printers that speak PDF) the document is then converted *back* to Postscript for actual printing?? Seems that way, based on a little poking around. If I use something like evince, I think it will do whatever CUPS tells it to do. If I use the basic CUPS lpr command to print a .ps file, that's fast since there's nothing smart enough to do something stupid. I think this is a bug. If it is, then I think it may be a long-standing one. I did something very like what I just described doing on FreeBSD 8.2 also back on my old FreeBSD 7.0 system which I first installed maybe three years of more ago. My recollection is that CUPS on FBSD 7 printed a lot faster, although it also may have something to do with the fact that I used to use a USB to parallel thing, and since then I scored a print server card on ebay for about $15 and print over the network. (There are other computers on the network that other people print from, so this is an overall win.) R's, John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
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
Re: Fast personal printing _without_ CUPS
On Fri, 28 Oct 2011 00:52:49 +0200 Polytropon articulated: There isn't much you can invent on a hammer. :-) Absolutely true. However, as Abraham Maslow said in 1966, It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. This sort of tunnel vision, at least in my opinion, has infected the *BSD community in general. They look at a problem and then, rather than finding a solution, find someone to blame. My my late father was so fond of saying when someone complained, It's better to light a candle than curse the darkness. -- Jerry ✌ jerry+f...@seibercom.net Disclaimer: off-list followups get on-list replies or ignored. Do not CC this poster. Please do not ignore the Reply-To header. http://www.catb.org/~esr/faqs/smart-questions.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
From owner-freebsd-questi...@freebsd.org Thu Oct 27 16:46:51 2011
Date: Thu, 27 Oct 2011 17:46:21 -0400
From: Jerry je...@seibercom.net
To: FreeBSD freebsd-questions@freebsd.org
Subject: Re: Fast personal printing _without_ CUPS
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.
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.
There's no real need for a 'standard' for communication with dumb raster
devices, which is what most 'winprinters' are.
All that is needed is a _published_ specification such that others
can implement communications with that device.
And there isn't a whole lot to such a specification:
How start-of-page is marked
How start-of-line is marked
How end-of-line is marked
How end-of-page is marked
How pixels are represented
Pixels per raster line,
Raster lines per page,
How the bits are sequenced
The compression methodology, if any, used.
there is little reason _not_ to make such specification public.
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. 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.
You argued cogently _against_ manufacturers using standards.
Now you argue in favor of the entire *nix commnity agreeing on one.
Somehow, the phrase double standard' springs to mind. grin
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.
There is -no- need for *them* to actually write drivers for use in
'specialty'/'niche' markets.
*ALL* they have to do is release the 'specifications' for the communications
format and protocol that the device uses.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
On Thu, 27 Oct 2011 19:39:17 -0400, Jerry wrote: On Fri, 28 Oct 2011 00:52:49 +0200 Polytropon articulated: There isn't much you can invent on a hammer. :-) Absolutely true. However, as Abraham Maslow said in 1966, It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. Heh, I also thought about that saying after sending the message. Maybe a bad example. :-) This sort of tunnel vision, at least in my opinion, has infected the *BSD community in general. They look at a problem and then, rather than finding a solution, find someone to blame. My my late father was so fond of saying when someone complained, It's better to light a candle than curse the darkness. It's always a consideration of what to invest versus what to get out of the deal, considering risks and options. And often politics. Just imagine a thing like FreeBSD would implement a means to simply use Windows printer drivers. And then MICROS~1 starts suing, both FreeBSD and its users (!!!) for illegally using something. Sounds stupid and contraproductive? It is - but things like this seem to be common. You surely know that MICROS~1 has more revenue from its competitor HTC than from their own mobile phone platform? The idea: You know, maybe we have some patents, but we won't tell you which they are, even in a court trial we won't, but maybe we have some. And if you don't pay $5 per unit sold, then... maybe... we'll sue you and all your customers. The fee has been raised to $15 some time later. (If I understood the process correctly - I'm not much interested in this mobile stuff and all the ugly politics involved because this has nothing to do with a free market.) There needs to be some security both for developers and for users. Current market politics don't seem to provide them. On the other hand, implementing drivers for simple printers (typical inkpee products) is easy when you know the control codes to make the paper and the printing head move. Reverse-engineering such stuff isn't that easy, sadly. The question is: Are the manufacturers willing to publish those little details? Do they see that as too costly? This is the opposite approach to making a Windows-like driver interface in UNIX / Linux to use the currently (and on the long run, partially) working drivers. But see my concerns regarding politics blackmail. By the way, I'm also a fan of lighting the candle. After all, it's a consideration of how you value your time, if you see it worth investing in getting something to work, learn important things (for your IT career), or if you feel you should return something to the community that provides you a powerful OS for free. There are many ways you can light the candle, it's up to you _how_ you do it. Anyway, everything is better than staying in darkness and stumbling into a pile of garbage. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
acroread9-9.4.2 -- 100% CPU usage
I knew that this was a problem for older versions of the adobe acrobat reader (acroread) but I really thought that SOMBODY would have fixed this by now, as it has been a longstanding problem. But alas, acroread9-9.4.2 as installed from the ports tree on a reasonably up-to-date 8.2-RELEASE/amd64 system is still consuming 100% CPU whenever it runs. I googled around awhile trying to find the solution, and found a couple of suggestions for fixing this, but none of them worked. OK, so somebody please clue me in. What's the magic diddle I have to apply to this system in order to get acroread 9.4.2 to stop consuming 100% CPU? (I already tried diddling the direction connection / proxy thing in a couple of different ways and that makes no difference at all.) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Download this ONLY working *ABSOLUTE GUARANTEED FREE ENERGY DEVICE* ever invented that actually produces free electricity out of thin air
Hello, From: Purchased Download (sadakokaboomo...@motorjakmagnets.com) The person above has sent you the following message: [ IMPORTANT ] [ http://fzy.co/B5j ] The United States Patent and Trademark Office awarded the `HoJo Motor` 3 U.S. Patents for being the ONLY working `free energy device` ever invented that actually produces free electricity out of thin air! . This is the real deal! rushed to the appliance store and got all the parts for 92 bucks. http://fzy.co/B5j It took me approx. three hours to build my first device... and I built a second, larger one in under an hour! We`ve already cut our electricity bill by 60 percent and planning on building a new generator next week... we`ll let you know how it goes! http://fzy.co/B5j http://fzy.co/B5j Wishing All the best, Dean Schrock, Denver, Colorado http://fzy.co/B5j http://fzy.co/B5j Click below to view the page: http://fzy.co/4Yj ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Fast personal printing _without_ CUPS
Polytropon free...@edvax.de wrote: Companies that develop printers want money. They need to continuously sell printers ... This seems to be becoming less and less accurate. It has long been the case that consumer-grade ink-blot printers are sold below cost -- the money being made by selling ink cartridges. In recent years, some manufacturers of laser printers seem to be adopting this business model also. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [zfs-discuss] ZFS on Dell with FreeBSD
Le 27/10/2011 à 13:34:50-0400, David Magda a écrit On Thu, October 27, 2011 11:32, Albert Shih wrote: I also recommend LSI 9200-8E or new 9205-8E with the IT firmware based on past experience Do you known if the LSI-9205-8E HBA or the LSI-9202-16E HBA work under FreBSD 9.0 ? Check the man page for mpt(4): http://www.freebsd.org/cgi/man.cgi?query=mptmanpath=FreeBSD+9-current http://www.freebsd.org/cgi/man.cgi?query=mptmanpath=FreeBSD+8.2-RELEASE WellI don't find this LSI in the mpt driver. I find the chipset of the http://www.lsi.com/products/storagecomponents/Pages/LSISAS9202-16e.aspx in the mps drivers. But I don't known if it's enough to support le card. Or LSI's site: http://www.lsi.com/products/storagecomponents/Pages/LSISAS9205-8e.aspx this one use 2308 chip and I definitely don't find this chip on mps driver. http://www.lsi.com/products/storagecomponents/Pages/LSISAS9202-16e.aspx Do you know how to use a search engine? Don't knwon you tell me ;-) I going to spend lot of money to buy some card, I just hope I can sure the card going to work Thanks Regards. JAS -- Albert SHIH DIO batiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 Heure local/Local time: ven 28 oct 2011 07:48:55 CEST ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
