HELLO AND WELCOME! Before you can post your question, you'll have to register -- it's completely free and registered users see less advertising! If you just want to browse through the existing questions, just select the forum that you want to visit from the selection below. Otherwise, click here to register!. We highly recommend that you print a copy of our Guide for New Members. Enjoy!

Red Hat Linux Professional is for professional workstations and servers. It includes everything in Red Hat Linux 7.2, plus:

* A printed Customization Guide
* A Web Server Applications CD with application development tools
and Interchange ECommerce package
* Workstation Applications CD with full Adobe Acrobat, IBM Java Run
Time Environment and more
* System Administrator CD
* 60 days of Web-based support
* 60 days of Telephone-based support, including 2 incidents
* 180-day subscription of Red Hat Network Software Manager for 1 system

Only real problem I have seen reported so far. There seems to be a problem printing with some printers. Doens't seem to affect me. There were also a couple of really stupid syntax errors in a couple of the Config.in files in the kernel source. I had to fix these first before I could re-compile the kernel. They should have fixed these. This was reported last week when the errrata kernel was released for 7.1.

> Now, if only I could get the printer working. Anyone had any experience
> with a local printer setup on Roswell? This printer worked fine when
> connected to a windows machine, and accessed as a smbprinter from a
> Seawolf machine. Now that it is connected locally, I can't make it print
> at all.

We use the data from the www.linuxprinting.org database to configure
drivers, and that data is rather large. The old version of the database
was in perl DataDumper formot (nasty, eh?), and a migration to XML
happened after the 7.1 freeze, but before the release.

But the original perl data was generated from a PostgreSQL database,
and the _real_ data existed as rows in that database, so the migration
to XML exported that data to XML files, but the semantics of tables and
constraints was kept.

So now, the foomatic system is a relational database of XML files. DBAs
can start crying now.

Using the perl XML parsers which where originally used on this version, it
took a VERY long time (~5 minutes) and a LOT of memory (~150 megs) to
compile the combo data for ONE printer/driver pair; and it took about 15
minutes to compile the overview.

Needless to say, this was a bit much, and prompted the distros (Mandrake
and Red Hat) which use this data to pre-compute the cache. This took
about a day of build time. I am not joking.

So I proposed to the linuxprinting.org people that we needed a C compler
for this, and that I would write one after we agreed on semantics and
everything for it's integration. I was trying to not step on toes.

4 days latter, Till Kampeter, who co-maintains the database, and works
for Mandrake, submitted a C program which compiled this data. I took
about 5 seconds to compile a printer/driver combo.

This was late in my development cycle, but I really needed this, so we
switched. It was FAST, everything was cool.

2 days after we went Gold, we discovered that there was a bug in Till's
code, which caused it to miscompute the constraints in a very few cases.

And the 'PrinterModel' option of the 'stp' driver, which is required for
the driver to work, was one of those cases. I was a bit upset.

There was a risk. The rewards were very high. We lost the gamble. There
is an update coming out SOON, it works but must be QAed.

#else

Yeah. I'm sorry (personally). An errata is being tested right now to fix
this bug.