We've seen this pattern before. We've seen it with the Linux
kernel itself, we've seen it with kernel side-projects, we've seen it
with individual distributions, and we've seen it with all manner of
open source software. I don't think it's unique to open source
projects, but it seems very typical of their natural life cycle.
The project starts out as a toy. We have some sample code, a
prototype, a proof of concept, or the like. Hey, everyone, it's a
dancing dog! It doesn't do anything useful, but it sure is fun
to watch.
Most projects die right there. But, in a tiny number of cases,
people are sufficiently interested in the toy that they start playing
with it, too. They fiddle around with the code, add a few features,
fix a few bugs, show it to their geekier friends, and so on. Now,
it's an interesting hobby.
Many projects die right there. But, in few cases, people find the
toy sufficiently practical that they actually start using it.
I mean, to be honest, the toy is still barely usable. It's
bug-ridden, it's lacking important features, better products are
available. But these people buck convention. They fiddle with the
code a little more furiously. A few people actually redesign and
rewrite big chunks of it. It looks like the "toy" warrants a couple
dedicated mailing lists. People fix the most egregious usability
problems and add features from the "most wanted" list. They also
start in with childish advocacy in inappropriate forums, and they look
like idiots, but they recruit other idiots, too, idiots who want to
try out this toy. It's become an unnatural obsession or even a
dangerous cult (though to the people closest to the project,
it's still an interesting hobby).
A lot of projects die right there. But, in some cases, the project
achieves a certain critical mass of interested developers and users.
(The critical mass required differs from project to project, of
course.) Now there are a few core developers that take the project
very seriously indeed, lots of sophisticated users that are applying
the project in the "real world" and contributing bug reports and
patches. People are less likely to "pooh pooh" comparisons to
competing projects, and missing features and poor performance in
"fringe cases" are objects of legitimate discussion. The division
between advocates and developers becomes a little clearer, mostly
because the developers are less self-conscious about public perception
of the project. The [open cheek, insert tongue] Holy Grail of Open
Source, namely actual BUSINESS INTEREST, might be spontaneously and
mysteriously generated. The project is a respectable
undertaking (though to the people closest to the project, it's
still an interesting hobby that for a few lucky ones pays
the bills).
A good number of projects die right there, though their "death" is
now a little more complex. Regardless, in many cases, the project has
too much momentum to die (or at least the corpse is still animate).
The project is seen as a serious competitor to other products, and
it's moving in some dangerous circles. Advocacy becomes
simultaneously more shrill and more subdued, depending on who's
advocating. The project still has some serious shortcomings, and
these bugs or misfeatures are---hardly surprisingly---concentrated in
the areas that don't much interest the developers. The project's
installation and configuration is too complex, the user interface is
weak, there are small but vocal groups that want to take the project
or parts of it in new directions of interest to them, someone suggests
in all earnestness that the project be reimplemented in Java or
C++. Influx and outflux of users and developers, which has been
ramping up throughout this process reaches a fever pitch. Long-time
advocates of X suddenly advocate Y or even not-X.
People jump ship, or from ship to ship, or just decide to do
something else for a while. There's a little too much screaming all
round, but the developers keep developing. Though no one is paying
any attention, somewhere along the line the project becomes really
useful to lots of people (though to the people closest to the
project, it's not clear anymore exactly what it is).
At this point, a few projects begin to collapse under their own
weight, though their deaths are a long way off. But, in most cases...
Or maybe not. No project has gotten this far, yet.
Linux is probably in the really useful to lots of people
stage. "Linux on the desktop", as a concept, is probably buried in
the interesting hobby stage, even though it's showing signs of
starting into the really useful to lots of people stage.
Mozilla was fast-tracked through the whole process, even though
everyone seems to think it took an interminably long time. I used
Mozilla from dangerous cult through really useful to lots of
people, and I think one should compare Mozilla of a year ago to
Mozilla today before concluding that Linux will never be a desktop
contender. Or, people who are suddenly so willing to write off
desktop Linux might want to ponder Linux kernel version smaller
than 1.0.
Desktop Linux (and BSD, excepting MaxOS X) is really only appropriate at large installations where the environment is completely controlled and administered by professionals.
I think it'd be fairer to say that Linux works well on the desktop wherever there's a Linux geek to set it up. It's not limited to large installations, and the geek doesn't have to be a Linux or IT professional. It works great in small organizations, on Mom and Dad's machine (whenever they have a penguin-loving son or daughter), or on Joe User's machine when he has a geek buddy (or can find a Linux Users' Group) to help him set it up.
That's not to say that Linux can't be used on the desktop in the absence of a qualified geek, but, obviously, that seems to be where the disagreement starts.
Where's the reason not to use it, other than for those who hate MS?
There are several reasons, some of which you list, such as tabbed browsing, availability of skins, and a perception (right or wrong) that it is more secure. These things may not be important to you, but they may be important to others.
It's too bad your experience with the Password Manager was a bad one. I find it a useful feature. However, Mozilla shouldn't have saved a password without specifically asking you if you wanted to remember it. Perhaps you unthinkingly clicked "Yes" both times Mozilla asked you about it? In any event, it's easy to delete those passwords from the "Tools -> Password Manager -> Manage Stored Passwords" dialogue. You can shut off the feature entirely by unchecking "Remember passwords" under the "Privacy & Security -> Passwords" Preference.
Perhaps this is of interest. Hal Puthoff, the "Texas physicist considered an expert in the concepts Priest said he was using", is---I believe---also known as Harold Puthoff.
Together with Russel Targ, this infamous team produced, let us say, somewhat credulous studies of spoon-bending psychic Uri Geller's remote viewing abilities. They also have the dubious distinction of having provided some of the best evidence that positive feedback improves ESP ability. Tragically, no skeptic who uses reasonable experimental controls seems to be able to duplicate their results.
The fact that Priest's box has something to do with Puthoff's area of expertise is hilarious! I wonder if the author of the article was being *intentionally* ironic.
Everyone loves license managers! As the most critical piece of unwanted software on your network, it's important that license managers be stable and reliable. Fortunately, they always are, so desperate IT managers have never had to waste hours on the phone with tech support fixing license manager configuration errors that have brought the entire company to its knees.
Microsoft has enough trouble now, with its perpetual licenses, helping enterprise customers help themselves ensure that all Microsoft software is appropriately licensed. An innovative new software delivery technology requires innovative new software, so it's clear that integrated LicenseManagerWizard (trademark pending) technology is going to be an important part of Windows 2002 (available Q1 2004).
It's difficult to overstate the benefits. Microsoft's stamp of approval on your license manager software is Bill Gates' personal software-quality guarantee to you that your LM won't let you down. Microsoft's tech support will be happy to assist you (for a nominal fee) with your LM configuration, in the unlikely event that the comprehensive online help ("How do I use the mouse?", "Why is my printer icon greyed out?") doesn't answer your question.
What's more, Microsoft's OpenLicense API will permit (and encourage!) even the smallest Windows software developers to deliver their software on a subscription basis with only minimal testing of their licensing infrastructure, leveraging this important new technology to help simplify and streamline your organization's license management policies and procedures.
LM technology is also an important part of Microsoft's.NET initiative, in the sense that organizations will be encouraged to adopt.NET technology by the absence of any legal means to continue licensing discontinued non-.NET software.
For very small applications, this is feasible, though it's not clear that there's any gain with respect to security.
On the other hand, this is a hopeless approach for big applications. Can we really expect a consumer to spend 30 minutes installing a minor usability upgrade to their KDE desktop? Won't eyebrows be raised when the Mozilla installation program asks the user to free up 515 megabytes of disk space to install a security update?
"Please wait a moment (where, by `moment', we mean 60 to 180 minutes, depending on the speed and memory capacity of your system)..."
or maybe
"The installation process has determined that you have 64 megabytes of memory and a 200MHz Pentium Pro processor or compatible. Installation of GNU/RedHat X-Emacs4Linux version 28 requires a minimum of 96 megabytes of memory an 800MHz Pentium III or compatible. Please upgrade your system before continuing."
The explanation is simple. Under Linux, the FPU control word has its precision control field set to 3: extended (80-bit) precision. Under FreeBSD and NetBSD, it's set to 2: double (64-bit) precision, same a C "double"s.
As a result, the Linux FP calculations are slightly more accurate. The constant 0.3, represented as a 64-bit C double, is slightly less than 0.3; the double constant 0.7, similarly, is slightly less than 0.7. Using 80-bit arithmetic, it's clear that (double)0.3*10 + (double)0.7*10 should be less than 10; truncated, it should be nine.
On the other hand, when all the calculations are done with 64-bit precision (as under Free/NetBSD), effectively the result is rounded after each multiply. As luck would have it, the results of the multiplies are rounded up to the exact values 3 and 7, so the sum is 10.
You can cry yourself to sleep, or you can decry various compilers, libraries, and OSes as L4M3. Alternatively, you can add:
The problem is two-fold. First, these modems are broadband devices that transmit and receive at different sets of frequencies. The downstream signal is transmitted from the cable head-end and received by the modem at relatively high frequencies (above 550MHz, up past most analog broadcast channels). However, the modems transmit at relatively low frequencies (down at 5-42MHz, below the analog broadcast channels). Worse yet, the modems use different modulation techniques for transmitting and receiving. Even if modem 2 could "hear" what modem 1 was transmitting spectrum-wise, it couldn't understand it anyway.
Second, the modems rely very heavily on control software at the cable head-end. This software, in addition to doing the usual high-level configuration like authenticating users and assigning IP addresses, also does low-level configuration, like telling a cable modem what channel it should transmit on, what time slot it can transmit in, and so on.
The bottom line is that the technology was cleverly and carefully developed to make the client technology as cheap and simple as possible. All the intelligence and complexity is in the head-end.
Getting two cable modems to talk without the cable company is exactly like getting two cell phones to talk without the phone company.
I probably shouldn't be contributing to this tangent, but just to set the record state, Mozilla is not moving to a GTK interface. In fact, it's moving away from it.
Mozilla uses a brand-new, cross-platform toolkit (important buzzwords: XPFE and XUL) that's rendered and scripted, more or less, by the same machinery that renders and scripts web page content.
Granted, under Linux, GTK is currently used to actually draw pixels on the screen, but it's used, more or less, the same way other toolkits use Xlib. Dialog boxes, scrollbars, and geometry management are all implemented in cross-platform toolkit code, and GTK just draw lines, rectangles, and pixmaps, really. For the most part, it just gets in the way, since GTK has different ideas than XPFE about geometry management, styles, and even which widgets should get which events.
Say, maybe this is on-topic! In an ideal world, there.is.only.xul, and GTK, Qt, and Motif are all obsolete. You pick a XUL rendering engine of your choice, tweak your style sheets and pixmaps as needed, and hack away at the totally scriptable GUIs boasted by all your K-RAD XUL APPS. <BL1NK>3l33t h4x0rs 43v3r!!!</BL1NK>
One of the points implicitly made in the article is that big on-chip caches running at (or close to) full processor speed act a lot like big banks of registers. A Pentium II might look, superficially, like its got only a handful of general-purpose registers, but your average C compiler treats it like its got a whole gaggle of them, indexed by %ebp.
From this point of view, the difference in the way "CISC" and "RISC" chips interact with memory is that, with a CISC chip, memory is implicitly used as a backing store for register contents while, with a RISC chip, the backing store is managed explicitly.
In practice, then, even this seemingly fundamental difference may not be that big a deal.
Did anyone else notice that the code generated by the author's hypothetical H Compiler produces buggy code on the ARS-1 architecture? The code for "B = CUBE(A)" calculates A^4 rather than A^3 (in addition to its unintended side effect of modifying register A).
I haven't seen anyone point out the obvious red flag here.
Suppose I am part of a crack research team, and we succeed in building the world's first, working quantum computer, one capable of almost unbelievable feats of brute-force code-breaking. Imagine our conversation:
"Ladies and gentlemen, by God I think we've done it!" smiles the project coordinator. "Where do we go from here? Ideas, anyone?"
"Publish!" cries a fresh, young intern. Having barely a handful of articles under his belt, he's eager to get his name on something like this.
"Well, perhaps we should hold off, give the world time to prepare," suggests an older and wiser researcher. "This caliber of cipher is still in active use worldwide. It's protecting some pretty sensitive data." She pauses, then adds jokingly, "maybe we could sell it to the highest bidder." This is greeted by nervous laughter.
Me, I'm looking at the mess of patch wires and tangled circuit boards. The machine must cover two desktops! "Why don't we turn it into a handheld device?" I suggest.
The others are startled at first. But as they exchange looks, I see some nods and hear muttered agreement. This is the only logical course of action, and now we all know what must be done.
The problem isn't with RedHat's "lpr" implementation but with certain older versions of the JetDirect firmware. See, for example, this ISS Security Advisory which describes the problem, and related DOS attacks, in detail.
Newer versions of the JetDirect firmware have working TCP/IP stacks, which may explain all the wise-asses who wonder what "you're doing wrong".
The easiest solution for those of us unlucky enough to be saddled with bad firmware is to switch to LPRng and, following the advice in the LPRng-HOWTO, use the printer's port 9100 as a direct link to the print engine.
At our site, we had no end of problems with HP printers crashing, locking up, and loosing jobs whenever two people tried to print at once. One day, I bit the LPRng bullet (and even installed "magicfilter" while I was at it). The configuration was a little work, but it was worth the effort. Finally, we have a printing system supporting Linux clients (using both LPRng and legacy "lpr") and Windows clients (via a Samba server acting as an LPRng client) that seems to work flawlessly.
Of course, all our printers are PostScript, so we don't have to worry so much about this newfangled CUPS stuff.
Slashdot Mirror
We've seen this pattern before. We've seen it with the Linux kernel itself, we've seen it with kernel side-projects, we've seen it with individual distributions, and we've seen it with all manner of open source software. I don't think it's unique to open source projects, but it seems very typical of their natural life cycle.
The project starts out as a toy. We have some sample code, a prototype, a proof of concept, or the like. Hey, everyone, it's a dancing dog! It doesn't do anything useful, but it sure is fun to watch.
Most projects die right there. But, in a tiny number of cases, people are sufficiently interested in the toy that they start playing with it, too. They fiddle around with the code, add a few features, fix a few bugs, show it to their geekier friends, and so on. Now, it's an interesting hobby.
Many projects die right there. But, in few cases, people find the toy sufficiently practical that they actually start using it. I mean, to be honest, the toy is still barely usable. It's bug-ridden, it's lacking important features, better products are available. But these people buck convention. They fiddle with the code a little more furiously. A few people actually redesign and rewrite big chunks of it. It looks like the "toy" warrants a couple dedicated mailing lists. People fix the most egregious usability problems and add features from the "most wanted" list. They also start in with childish advocacy in inappropriate forums, and they look like idiots, but they recruit other idiots, too, idiots who want to try out this toy. It's become an unnatural obsession or even a dangerous cult (though to the people closest to the project, it's still an interesting hobby).
A lot of projects die right there. But, in some cases, the project achieves a certain critical mass of interested developers and users. (The critical mass required differs from project to project, of course.) Now there are a few core developers that take the project very seriously indeed, lots of sophisticated users that are applying the project in the "real world" and contributing bug reports and patches. People are less likely to "pooh pooh" comparisons to competing projects, and missing features and poor performance in "fringe cases" are objects of legitimate discussion. The division between advocates and developers becomes a little clearer, mostly because the developers are less self-conscious about public perception of the project. The [open cheek, insert tongue] Holy Grail of Open Source, namely actual BUSINESS INTEREST, might be spontaneously and mysteriously generated. The project is a respectable undertaking (though to the people closest to the project, it's still an interesting hobby that for a few lucky ones pays the bills).
A good number of projects die right there, though their "death" is now a little more complex. Regardless, in many cases, the project has too much momentum to die (or at least the corpse is still animate). The project is seen as a serious competitor to other products, and it's moving in some dangerous circles. Advocacy becomes simultaneously more shrill and more subdued, depending on who's advocating. The project still has some serious shortcomings, and these bugs or misfeatures are---hardly surprisingly---concentrated in the areas that don't much interest the developers. The project's installation and configuration is too complex, the user interface is weak, there are small but vocal groups that want to take the project or parts of it in new directions of interest to them, someone suggests in all earnestness that the project be reimplemented in Java or C++. Influx and outflux of users and developers, which has been ramping up throughout this process reaches a fever pitch. Long-time advocates of X suddenly advocate Y or even not-X. People jump ship, or from ship to ship, or just decide to do something else for a while. There's a little too much screaming all round, but the developers keep developing. Though no one is paying any attention, somewhere along the line the project becomes really useful to lots of people (though to the people closest to the project, it's not clear anymore exactly what it is).
At this point, a few projects begin to collapse under their own weight, though their deaths are a long way off. But, in most cases... Or maybe not. No project has gotten this far, yet.
Linux is probably in the really useful to lots of people stage. "Linux on the desktop", as a concept, is probably buried in the interesting hobby stage, even though it's showing signs of starting into the really useful to lots of people stage. Mozilla was fast-tracked through the whole process, even though everyone seems to think it took an interminably long time. I used Mozilla from dangerous cult through really useful to lots of people, and I think one should compare Mozilla of a year ago to Mozilla today before concluding that Linux will never be a desktop contender. Or, people who are suddenly so willing to write off desktop Linux might want to ponder Linux kernel version smaller than 1.0.
I think it'd be fairer to say that Linux works well on the desktop wherever there's a Linux geek to set it up. It's not limited to large installations, and the geek doesn't have to be a Linux or IT professional. It works great in small organizations, on Mom and Dad's machine (whenever they have a penguin-loving son or daughter), or on Joe User's machine when he has a geek buddy (or can find a Linux Users' Group) to help him set it up.
That's not to say that Linux can't be used on the desktop in the absence of a qualified geek, but, obviously, that seems to be where the disagreement starts.
There are several reasons, some of which you list, such as tabbed browsing, availability of skins, and a perception (right or wrong) that it is more secure. These things may not be important to you, but they may be important to others.
It's too bad your experience with the Password Manager was a bad one. I find it a useful feature. However, Mozilla shouldn't have saved a password without specifically asking you if you wanted to remember it. Perhaps you unthinkingly clicked "Yes" both times Mozilla asked you about it? In any event, it's easy to delete those passwords from the "Tools -> Password Manager -> Manage Stored Passwords" dialogue. You can shut off the feature entirely by unchecking "Remember passwords" under the "Privacy & Security -> Passwords" Preference.
Perhaps this is of interest. Hal Puthoff, the "Texas physicist considered an expert in the concepts Priest said he was using", is---I believe---also known as Harold Puthoff.
Together with Russel Targ, this infamous team produced, let us say, somewhat credulous studies of spoon-bending psychic Uri Geller's remote viewing abilities. They also have the dubious distinction of having provided some of the best evidence that positive feedback improves ESP ability. Tragically, no skeptic who uses reasonable experimental controls seems to be able to duplicate their results.
The fact that Priest's box has something to do with Puthoff's area of expertise is hilarious! I wonder if the author of the article was being *intentionally* ironic.
Everyone loves license managers! As the most critical piece of unwanted software on your network, it's important that license managers be stable and reliable. Fortunately, they always are, so desperate IT managers have never had to waste hours on the phone with tech support fixing license manager configuration errors that have brought the entire company to its knees.
Microsoft has enough trouble now, with its perpetual licenses, helping enterprise customers help themselves ensure that all Microsoft software is appropriately licensed. An innovative new software delivery technology requires innovative new software, so it's clear that integrated LicenseManagerWizard (trademark pending) technology is going to be an important part of Windows 2002 (available Q1 2004).
It's difficult to overstate the benefits. Microsoft's stamp of approval on your license manager software is Bill Gates' personal software-quality guarantee to you that your LM won't let you down. Microsoft's tech support will be happy to assist you (for a nominal fee) with your LM configuration, in the unlikely event that the comprehensive online help ("How do I use the mouse?", "Why is my printer icon greyed out?") doesn't answer your question.
What's more, Microsoft's OpenLicense API will permit (and encourage!) even the smallest Windows software developers to deliver their software on a subscription basis with only minimal testing of their licensing infrastructure, leveraging this important new technology to help simplify and streamline your organization's license management policies and procedures.
LM technology is also an important part of Microsoft's .NET initiative, in the sense that organizations will be encouraged to adopt .NET technology by the absence of any legal means to continue licensing discontinued non-.NET software.
It's good news for everyone.
For very small applications, this is feasible, though it's not clear that there's any gain with respect to security.
On the other hand, this is a hopeless approach for big applications. Can we really expect a consumer to spend 30 minutes installing a minor usability upgrade to their KDE desktop? Won't eyebrows be raised when the Mozilla installation program asks the user to free up 515 megabytes of disk space to install a security update?
or maybe
The explanation is simple. Under Linux, the FPU control word has its precision control field set to 3: extended (80-bit) precision. Under FreeBSD and NetBSD, it's set to 2: double (64-bit) precision, same a C "double"s.
As a result, the Linux FP calculations are slightly more accurate. The constant 0.3, represented as a 64-bit C double, is slightly less than 0.3; the double constant 0.7, similarly, is slightly less than 0.7. Using 80-bit arithmetic, it's clear that (double)0.3*10 + (double)0.7*10 should be less than 10; truncated, it should be nine.
On the other hand, when all the calculations are done with 64-bit precision (as under Free/NetBSD), effectively the result is rounded after each multiply. As luck would have it, the results of the multiplies are rounded up to the exact values 3 and 7, so the sum is 10.
You can cry yourself to sleep, or you can decry various compilers, libraries, and OSes as L4M3. Alternatively, you can add:
at the top and: just before the printf and get the same answer under Linux as under all those far better operating systems and architectures you tried.The only other thing you need is a cable company.
The problem is two-fold. First, these modems are broadband devices that transmit and receive at different sets of frequencies. The downstream signal is transmitted from the cable head-end and received by the modem at relatively high frequencies (above 550MHz, up past most analog broadcast channels). However, the modems transmit at relatively low frequencies (down at 5-42MHz, below the analog broadcast channels). Worse yet, the modems use different modulation techniques for transmitting and receiving. Even if modem 2 could "hear" what modem 1 was transmitting spectrum-wise, it couldn't understand it anyway.
Second, the modems rely very heavily on control software at the cable head-end. This software, in addition to doing the usual high-level configuration like authenticating users and assigning IP addresses, also does low-level configuration, like telling a cable modem what channel it should transmit on, what time slot it can transmit in, and so on.
The bottom line is that the technology was cleverly and carefully developed to make the client technology as cheap and simple as possible. All the intelligence and complexity is in the head-end.
Getting two cable modems to talk without the cable company is exactly like getting two cell phones to talk without the phone company.
I probably shouldn't be contributing to this tangent, but just to set the record state, Mozilla is not moving to a GTK interface. In fact, it's moving away from it.
Mozilla uses a brand-new, cross-platform toolkit (important buzzwords: XPFE and XUL) that's rendered and scripted, more or less, by the same machinery that renders and scripts web page content.
Granted, under Linux, GTK is currently used to actually draw pixels on the screen, but it's used, more or less, the same way other toolkits use Xlib. Dialog boxes, scrollbars, and geometry management are all implemented in cross-platform toolkit code, and GTK just draw lines, rectangles, and pixmaps, really. For the most part, it just gets in the way, since GTK has different ideas than XPFE about geometry management, styles, and even which widgets should get which events.
Say, maybe this is on-topic! In an ideal world, there.is.only.xul, and GTK, Qt, and Motif are all obsolete. You pick a XUL rendering engine of your choice, tweak your style sheets and pixmaps as needed, and hack away at the totally scriptable GUIs boasted by all your K-RAD XUL APPS. <BL1NK>3l33t h4x0rs 43v3r!!!</BL1NK>
From this point of view, the difference in the way "CISC" and "RISC" chips interact with memory is that, with a CISC chip, memory is implicitly used as a backing store for register contents while, with a RISC chip, the backing store is managed explicitly.
In practice, then, even this seemingly fundamental difference may not be that big a deal.
Did anyone else notice that the code generated by the author's hypothetical H Compiler produces buggy code on the ARS-1 architecture? The code for "B = CUBE(A)" calculates A^4 rather than A^3 (in addition to its unintended side effect of modifying register A).
I haven't seen anyone point out the obvious red flag here.
Suppose I am part of a crack research team, and we succeed in building the world's first, working quantum computer, one capable of almost unbelievable feats of brute-force code-breaking. Imagine our conversation:
"Ladies and gentlemen, by God I think we've done it!" smiles the project coordinator. "Where do we go from here? Ideas, anyone?"
"Publish!" cries a fresh, young intern. Having barely a handful of articles under his belt, he's eager to get his name on something like this.
"Well, perhaps we should hold off, give the world time to prepare," suggests an older and wiser researcher. "This caliber of cipher is still in active use worldwide. It's protecting some pretty sensitive data." She pauses, then adds jokingly, "maybe we could sell it to the highest bidder." This is greeted by nervous laughter.
Me, I'm looking at the mess of patch wires and tangled circuit boards. The machine must cover two desktops! "Why don't we turn it into a handheld device?" I suggest.
The others are startled at first. But as they exchange looks, I see some nods and hear muttered agreement. This is the only logical course of action, and now we all know what must be done.
Newer versions of the JetDirect firmware have working TCP/IP stacks, which may explain all the wise-asses who wonder what "you're doing wrong".
The easiest solution for those of us unlucky enough to be saddled with bad firmware is to switch to LPRng and, following the advice in the LPRng-HOWTO, use the printer's port 9100 as a direct link to the print engine.
At our site, we had no end of problems with HP printers crashing, locking up, and loosing jobs whenever two people tried to print at once. One day, I bit the LPRng bullet (and even installed "magicfilter" while I was at it). The configuration was a little work, but it was worth the effort. Finally, we have a printing system supporting Linux clients (using both LPRng and legacy "lpr") and Windows clients (via a Samba server acting as an LPRng client) that seems to work flawlessly.
Of course, all our printers are PostScript, so we don't have to worry so much about this newfangled CUPS stuff.