There's a big difference between GDI and PostScript. GDI is a very limited "draw here" type of interface, while PostScript is a full-blown language that must be interpreted in order to produce a page.
That said, Ghostscript already provides a GDI interface, so it might be possible to use WINE with Ghostscript and the vendor print driver to produce a print driver. *However*, many Windows printer drivers have their own parallel/USB drivers, so it may not be possible to do this within WINE (maybe VMWARE, tho)
How about FLTK?
on
GTK-- vs. QT
·
· Score: 1, Troll
Haven't seen anyone mention FLTK, but it is a cross-platform C++ GUI toolkit. It is a lot smaller than Qt or GTK+/--, and it used by a lot of the embedded Linux projects to provide their GUIs. OSX support is currently under development...
Well, under Linux anyways there are at least 3 packagers that are used for Linux distributions.
In any case, programs like my EPM (see http://www.easysw.com/epm/
for more info) are designed to create installation scripts, or RPM packages, etc. Definitely worth a look if you want to ship binaries for multiple platforms or even just multiple Linux distributions...
Um, HP-UX 11 *is* 64-bit. This bunch is/was just working on porting HP-UX to IA64 - the PA-RISC chips have been 64-bit for a while, as have MIPS, SPARC, etc.
The current version of MySQL supports both atomic operations and transactions - transaction support depends on your table storage format... Please read the documentation (there are several sections on it...)
If MySQL AB reads the user comments in the manual, I'm betting that they will be implementing view and foreign key support soon.
As for a full SQL92 implementation, I think the only major issue remaining is nested SELECTs, right?
Re:We 'share', and you grant us back all your 'wor
on
Shared Source?
·
· Score: 1
We're one of those "self-proclaimed" open-source companies, so let me set some things straight.
First, we *do* require that contributions to the project be "signed over" to the project owner (us). This avoids several legal issues of ownership and is something that most open source projects (commercial or otherwise) do once you have more than a few developers. It isn't always about money, it's usually about more practical issues such as "do I have the right to release this code?".
Now, clearly there is a difference between open source and shared source. Not having looked at the MS license yet, I can't comment much, but my guess is that the MS license is a "look but don't touch" type of license, which doesn't meet the OSI definition/requirements for open source. The reasons for using this license point to a clear desire to NOT share and NOT promote code reuse and innovation.
A company that releases their product as open source is going out on a limb - there are no guarantees that people will help fund or contribute to the continued development, and many people assume that the company is there to support people for nothing in return. Also, there is always the risk that someone will take the code and create a competing application that puts the original company out of business.
Our CUPS software is used by many Linux distributors, but we don't see a penny or contribution from many of them. There are a few really good vendors, SuSE and Caldera come to mind, that have done audits, submitted feature enhancements, etc., and Mandrake has contributed GUIs and support to the picture.
Sometimes releasing a free open-source version and a pay closed-source version of a product is the only way to make money. Sometimes that choice is forced on the vendor because of NDA information (that is the case for our ESP Print Pro product).
In any case, I think that any vendor that does make the effort to open-source all or part of their products is truly participating in the open source process. Having a commercial version of a product is the price you pay (literally) to get a supported open-source product.
Actually, we've been looking into adding support for Windows-native distributions in EPM. The current offerings (InstallShield, etc.) are not suitable for large projects and can't be automated like they can under UNIX...
I've found that releasing binaries are essential
to making an open source project successful.
That said, I usually don't release binaries for
alpha releases or early betas that are likely to
contain bugs - better to let the more experienced
hackers (in the true sense of the word) run into
any problems and report (or even better - fix!)
them than spend days with a newbie only to find
that they haven't found a problem but are using
the thing wrong.
Once you know the code is stable enough for
mere mortals to use, get the binaries out! A lot
of inexperienced users (and experienced ones,
too!:) don't want the hassle of compiling the
software themselves if they don't have to.
I'm always *so* encouraged that after paying huge amounts of money and (usually) racking up large student loans, the work that a student does for a class or his/her thesis becomes the property of the school...
P.T. Barnum would be proud of the fraud that schools and their lawyers are getting away with.
I'm glad I don't have to go to college these days...
Not all software companies support the UCITA. In fact, if any of them have any brains, few will support it except the big ones.
Reason: all software companies depend on other vendors' software (compilers, etc.) Without legal means of assuring a minimum level of functioning and reliability, a software company will be on very unstable ground.
I've sent in some "official" letters from my company to the Maryland reps we have outlining many of the problems with UCITA from both the end-user and software developer perspective.
* LPR * CUPS * Ghostscript * Minolta / SuSEs new printing system * HP / VAs new printing system * StarOffice's printing system * The GNOME print architecute * The KDE print architecture * XFS and Xfree86 4.0 [both have font servers which could benefit fron print integration]
I think you're confusing printing systems and printing interfaces.
CUPS and LPR are the only printing systems listed above. To the best of my knowledge the HP and Minolta efforts are just filters and helper apps layered on top of LPR.
GhostScript is just a program. It can be used to filter output for a printer (PostScript to PCL, for example), but it isn't a printing system.
StarOffice (and Word Perfect, and name your application) include printer drivers but not a printing system.
GNOME and KDE (and Corel, don't forget them) are providing an application interface for printing; they still need a printing system (currently LP/LPR/LPRng/CUPS)
XFS and XFree86 can provide bitmapped fonts, but quite frankly they are not designed for the high-resolution output of a printer. Do you want your graphics card generating 600 DPI fonts and freezing your display while doing it? (GhostScript already supports Type1 and TrueType fonts, and you can share them with X to get the same widths, etc.)
Try using the DeskJet 660C (or 600 series, I forget) drivers with the 812C; the 812C does 600x300 DPI instead of the 300 DPI CREt in the older 800 series printers.
HP has become more and more closed over the years with the DeskJet printers. Even registered developers (that have to sign a non-disclosure agreement) can't get a lot of the information.
ALL of the newer DeskJet printers (970C, 2000C, 2500C) provide both the PPA and PCL interfaces; the PCL interface allows you to do 600 DPI in color, but not the multi-level stuff supported by the printer, and AFAIK not the duplexing stuff either (still waiting for a response on that one...)
Of the vendors out there, ALPS has to be the most open, at least to developers. They gave us everything so we could write a driver for Linux that is as good as the Windows driver. EPSON gives us all the printer control info, but nothing on dithering algorithms or strategies to improve the output.
That architecture (to develop printer drivers for Linux) is already available with CUPS (http://www.cups.org, GPL'd)
Debian is including CUPS and LPR in their next distribution, and we're hoping more vendors will do the same.
As for libraries, there are several people working on that, most notably Corel, the KDE folks, the GNOME folks, and the VA Linux folks. We've contributed code to the Corel (LGPL'd) and VA Linux efforts already.
We have prepared the paperwork... Yes, there may be issues with the "CUPS" acronym, but the logo and full name shouldn't be a problem. We'll see what the PTO says...
We haven't had a chance to finish the incoming LPD interface; it will be a separate thing from the scheduler and *won't* work if you've turned printer authentication on (that is, requiring a username and password.) It'll probably show up on the 'bazaar and then become integrated once we start the 1.1 betas (not anytime soon;)
The main goal of 1.0 was to implement a new printing system that would work on all UNIX's. We originally were going to base it on LPD but extend the hell out of it.
Shortly after we finalized a preliminary design we discovered IPP. The switch to use IPP caused a complete redesign and required development of the network stuff in a completely different direction, so all of the LPD client stuff went out the door, at least for 1.0.
Noooo, you just can't call your product "CUPS". You *can* call it "Gnomo CUPS", etc.
Trademarks protect names from getting "diluted". You can use the name all you like, so long as you are referencing *the* CUPS distribution. If you have a derivative then you just have to modify the name accordingly.
Please, think about Linux - it is trademarked but used regularly at part of the name of many Linux distributions.
Please support any problems you find to us at "cups-support@easysw.com". We *do* try to fix any problems that are reported as quickly as possible. Remember, the point of Open Source is to allow things like that to happen, making the software better!;)
As for NULL checks, they aren't always needed, and we've tried to the checks where they aren't needed (or are duplicated) for efficiency... If you've found one missing that needs to be there, please let us know!
Slashdot Mirror
There's a big difference between GDI and PostScript. GDI is a very limited "draw here" type of interface, while PostScript is a full-blown language that must be interpreted in order to produce a page.
That said, Ghostscript already provides a GDI interface, so it might be possible to use WINE with Ghostscript and the vendor print driver to produce a print driver. *However*, many Windows printer drivers have their own parallel/USB drivers, so it may not be possible to do this within WINE (maybe VMWARE, tho)
The FLTK web site is http://www.fltk.org/.
In any case, programs like my EPM (see http://www.easysw.com/epm/ for more info) are designed to create installation scripts, or RPM packages, etc. Definitely worth a look if you want to ship binaries for multiple platforms or even just multiple Linux distributions...
Um, HP-UX 11 *is* 64-bit. This bunch is/was just working on porting HP-UX to IA64 - the PA-RISC chips have been 64-bit for a while, as have MIPS, SPARC, etc.
If you have to pay to get the source code, then what is the ssh-3.0.1.tar.gz file on their FTP server:
ftp://ftp.ssh.com/pub/ssh/
???
The current version of MySQL supports both atomic operations and transactions - transaction support depends on your table storage format... Please read the documentation (there are several sections on it...)
If MySQL AB reads the user comments in the manual, I'm betting that they will be implementing view and foreign key support soon.
As for a full SQL92 implementation, I think the only major issue remaining is nested SELECTs, right?
We're one of those "self-proclaimed" open-source companies, so let me set some things straight.
First, we *do* require that contributions to the project be "signed over" to the project owner (us). This avoids several legal issues of ownership and is something that most open source projects (commercial or otherwise) do once you have more than a few developers. It isn't always about money, it's usually about more practical issues such as "do I have the right to release this code?".
Now, clearly there is a difference between open source and shared source. Not having looked at the MS license yet, I can't comment much, but my guess is that the MS license is a "look but don't touch" type of license, which doesn't meet the OSI definition/requirements for open source. The reasons for using this license point to a clear desire to NOT share and NOT promote code reuse and innovation.
A company that releases their product as open source is going out on a limb - there are no guarantees that people will help fund or contribute to the continued development, and many people assume that the company is there to support people for nothing in return. Also, there is always the risk that someone will take the code and create a competing application that puts the original company out of business.
Our CUPS software is used by many Linux distributors, but we don't see a penny or contribution from many of them. There are a few really good vendors, SuSE and Caldera come to mind, that have done audits, submitted feature enhancements, etc., and Mandrake has contributed GUIs and support to the picture.
Sometimes releasing a free open-source version and a pay closed-source version of a product is the only way to make money. Sometimes that choice is forced on the vendor because of NDA information (that is the case for our ESP Print Pro product).
In any case, I think that any vendor that does make the effort to open-source all or part of their products is truly participating in the open source process. Having a commercial version of a product is the price you pay (literally) to get a supported open-source product.
Actually, we've been looking into adding support for Windows-native distributions in EPM. The current offerings (InstallShield, etc.) are not suitable for large projects and can't be automated like they can under UNIX...
I've found that releasing binaries are essential
:) don't want the hassle of compiling the
to making an open source project successful.
That said, I usually don't release binaries for
alpha releases or early betas that are likely to
contain bugs - better to let the more experienced
hackers (in the true sense of the word) run into
any problems and report (or even better - fix!)
them than spend days with a newbie only to find
that they haven't found a problem but are using
the thing wrong.
Once you know the code is stable enough for
mere mortals to use, get the binaries out! A lot
of inexperienced users (and experienced ones,
too!
software themselves if they don't have to.
I'm always *so* encouraged that after paying huge amounts of money and (usually) racking up large student loans, the work that a student does for a class or his/her thesis becomes the property of the school...
P.T. Barnum would be proud of the fraud that schools and their lawyers are getting away with.
I'm glad I don't have to go to college these days...
$3500 list for the EOS D30 - better than the current Nikon and Kodak offerings, but it only has a 3 megapixel CMOS sensor (36-bit, tho...)
r oducts&subprodtype=13&product=478
Links:
http://www.canon.co.uk/cgi-bin/parser.pl?page=p
http://www.usa.canon.com/press/051700a.html
Another good one from Canon to look at is the PowerShot Pro70 - 1.6M sensor (24-bit) with 28-70mm zoom lens (will take screw-on filters) for $600.
Reason: all software companies depend on other vendors' software (compilers, etc.) Without legal means of assuring a minimum level of functioning and reliability, a software company will be on very unstable ground.
I've sent in some "official" letters from my company to the Maryland reps we have outlining many of the problems with UCITA from both the end-user and software developer perspective.
I think you're confusing printing systems and printing interfaces.
CUPS and LPR are the only printing systems listed above. To the best of my knowledge the HP and Minolta efforts are just filters and helper apps layered on top of LPR.
GhostScript is just a program. It can be used to filter output for a printer (PostScript to PCL, for example), but it isn't a printing system.
StarOffice (and Word Perfect, and name your application) include printer drivers but not a printing system.
GNOME and KDE (and Corel, don't forget them) are providing an application interface for printing; they still need a printing system (currently LP/LPR/LPRng/CUPS)
XFS and XFree86 can provide bitmapped fonts, but quite frankly they are not designed for the high-resolution output of a printer. Do you want your graphics card generating 600 DPI fonts and freezing your display while doing it?
(GhostScript already supports Type1 and TrueType fonts, and you can share them with X to get the same widths, etc.)
1440x720 DPI for the EPSON printers *is* available today; we have our ESP Print Pro drivers based on CUPS, and Robert Krawitz has been extending my print plug-in to support the Photo printers and the 1440x720 DPI modes in GIMP (available in the 1.1.x development versions.)
Try using the DeskJet 660C (or 600 series, I forget) drivers with the 812C; the 812C does 600x300 DPI instead of the 300 DPI CREt in the older 800 series printers.
ALL of the newer DeskJet printers (970C, 2000C, 2500C) provide both the PPA and PCL interfaces; the PCL interface allows you to do 600 DPI in color, but not the multi-level stuff supported by the printer, and AFAIK not the duplexing stuff either (still waiting for a response on that one...)
Of the vendors out there, ALPS has to be the most open, at least to developers. They gave us everything so we could write a driver for Linux that is as good as the Windows driver. EPSON gives us all the printer control info, but nothing on dithering algorithms or strategies to improve the output.
HP is right above Canon and Lexmark...
That architecture (to develop printer drivers for Linux) is already available with CUPS (http://www.cups.org, GPL'd)
Debian is including CUPS and LPR in their next distribution, and we're hoping more vendors will do the same.
As for libraries, there are several people working on that, most notably Corel, the KDE folks, the GNOME folks, and the VA Linux folks. We've contributed code to the Corel (LGPL'd) and VA Linux efforts already.
Look at the README file at least.
There's a PCL driver for HP LaserJets. If you have a PostScript model just grab the PPD file and you'll have full functionality that way, too.
We have prepared the paperwork... Yes, there may be issues with the "CUPS" acronym, but the logo and full name shouldn't be a problem. We'll see what the PTO says...
We haven't had a chance to finish the incoming LPD interface; it will be a separate thing from the scheduler and *won't* work if you've turned printer authentication on (that is, requiring a username and password.) It'll probably show up on the 'bazaar and then become integrated once we start the 1.1 betas (not anytime soon ;)
The main goal of 1.0 was to implement a new printing system that would work on all UNIX's. We originally were going to base it on LPD but extend the hell out of it.
Shortly after we finalized a preliminary design we discovered IPP. The switch to use IPP caused a complete redesign and required development of the network stuff in a completely different direction, so all of the LPD client stuff went out the door, at least for 1.0.
Which printers do you have?
Noooo, you just can't call your product "CUPS". You *can* call it "Gnomo CUPS", etc.
Trademarks protect names from getting "diluted". You can use the name all you like, so long as you are referencing *the* CUPS distribution. If you have a derivative then you just have to modify the name accordingly.
Please, think about Linux - it is trademarked but used regularly at part of the name of many Linux distributions.
Please support any problems you find to us at "cups-support@easysw.com". We *do* try to fix any problems that are reported as quickly as possible. Remember, the point of Open Source is to allow things like that to happen, making the software better! ;)
As for NULL checks, they aren't always needed, and we've tried to the checks where they aren't needed (or are duplicated) for efficiency... If you've found one missing that needs to be there, please let us know!
Oops- you probably saw that in the old "overview" document; it should be updated now...