Slashdot Mirror

This does not affect the users directly, but it is a major pain for integrators/porters. OO.o has a terrible habit of bundling all of the 3rd-party software packages, that it uses, into its own source tree. I'm talking about (probably missed some):

• agg
• bash
• bitstream-vera
• bsh
• bison
• boost
• curl
• db42
• dmake
• expat2
• freetype
• icu
• jpeg
• firefox (or some other Mozilla-based browser)
• libmspack
• libsndfile
• libtextcat
• libwpd
• libxslt
• neon
• nss
• nspr
• python
• sane-backends
• STLport
• unixODBC
• unzip
• vigra
• xmlsec1
• xt
• zip
• zlib

If they could, I'm certain, they would've bundled Java too, but — fortunately — Sun's license prohibits that... Now I realize, that this is done to offer "a single package" to those, who build it on their own, but nobody does. Everybody gets these from their OS' integrators. And the pain for us is enormous, because to force OO.o build to stop its silly ways is a serious undertaking. For some of the above packages there is --with-system-foo configure-flag, but not for all, and the default is to always use the bundled one, so support for the external ones bitrots quickly...

Most of the local builds don't bother and so end up wasting disk space and CPU-time rebuilding packages, which are external to OO.o. The end results are also bloated, duplicating stuff, that's already installed on the users' systems and without bug-fixes, which have already gone into each of the respective package since its most recent "bundling" into OO.o tarballs.

Download a source tarball and see for yourself... Something like: tar tjf OOo_OOG680_m9_source.tar.bz2 | grep 'z$'. No other software project does this on this scale and for good reasons — it is Just Wrong[TM]. OO.o better clean up their act in this respect...

It should also be noted that as of the Current the MTA [Multi Theft Auto] project uses libjpeg in their project without any recognition to libjpeg itself (which violates the libjpeg licensing agreement). So if you want a real story, why not add another project that violates open source licensing to your list. (By decompiling the DLL's you can clearly see code from the libjpeg project as well as a copyright notice from Thomas G. Lane).

As another poster pointed out, Microsoft didn't actually write the vulnerable jpg code.

They used the OpenSource implementation by IJG

No, Mozilla uses libpr0n AKA libimg2 which uses libjpeg code.

libjpeg has a quite explicit requirement for credit in documentation:

If only executable code is distributed, then the accompanying documentation must state that "this software is based in part on the work of the Independent JPEG Group".

Why is it OK to use this in GPL software? (libjpeg is ubiquitous and it appears that all GNOME applications are linked indirectly with libjpeg.)

It doesn't seem to acknowledge the widespread availability of file format libraries that are suitable for use with C++, such as libjpeg from the Independent Jpeg Group.

It also repeats the commonly stated claim that Java is free from memory leaks. Nothing could be further from the truth. While it is possible to carefully write a Java program that doesn't leak, I don't think it's any easier than making a leakproof C++ program.

How does Java leak memory? Simple. Just hold references to memory you don't need anymore. Holding a reference to any node in a DOM Tree will prevent the entire tree from being garbage collected. That's an easy way to leak tens of megabytes.

Garbage collection is no substitute for responsible memory management.

It also says that in C++, you have to implement graphics calls by coding to the native API of the OS. It says in Java, you have a portable way to do that.

But that's just bullshit. The article makes no mention of cross-platform application frameworks, a number of which were around before Java was ever dreamed off. If you use ZooLib, for example, to code in C++, you can do everything you want with graphics with no need for platform-specific code. There's lots of other cross-platform frameworks, such as wxWindows and Mozilla, even GTK+.

There are a great variety of cross-platform libraries and frameworks that you would find useful. For example, for a humble JPEG coded, the Independent JPEG Group's JPEG library works really well and runs on everything from DOS to a Cray. It is portable beyond belief. For a lossless graphics format there is libtiff. (I don't know what's available for cross-platform video format software, but I'm sure there is some.)

If you're going to write in in C++, my favorite framework for GUI, file API's, TCP networking, multithreading and database is ZooLib. (But note that presently the best code to use is what's in CVS because it hasn't had a release in a long time (Real Soon Now, really!).

I've started writing a book about ZooLib that is released under the GNU Free Documentation License.

But if you don't like ZooLib, it's important to use some cross-platform framework. There are many to choose from.

Another important framework is the Simple DirectMedia Layer. You will want this for your rendered scenes and for sound (ZooLib does 2-D graphics, it's not a 3-D API).

If you write in C++, do as much as you can with the Standard Template Library. There are some excellent books that teach how to use it.

For a long time, the STL has got a bad rap, in part because the template definitions in the header files are hard to read, and in part because of poor compiler implementations of the C++ ISO standard, or poor implementations of the library itself. But by now there are excellent implementations for every OS that is in common use. For example, on Windows, don't bother with Visual C++ - use Metrowerks CodeWarrior or Comeau C/C++.

Even if you choose to work with a broken compiler, the STLPort library provides a compliant standard library that will work almost anywhere.

I was rather intimidated by the STL when I first encountered it but once I got a good book and learned how to use it, I thought it was the best thing since sliced bread.

Boost has many portable C++ libraries that are of excellent quality.

Finally, I am (slowly) building a website devoted to educating developers in cross-platform and portable programming called ByteSwap.net. Read my first article there Writing Cross-Platform Software - Getting Started. More articles will appear when I get more free time!

JPEG does appear to be patent-encumbered...

Most (all?) of the JPEG patents cover the arithmetic coding method that can be used with JPEG. IBM holds several of the relevant patents; there are one or two other companies whose names I don't recall off the top of my head. Most JPEG implementations (including the Independent JPEG Group implementation that most people & companies use) don't implement arithmetic coding of the quantized DCT coefficients for this reason. Huffman coding (usually with a fixed table, though adaptive Huffman coding is also doable) is the predominant method, and isn't patent-encumbered. (I don't think Huffman coding was ever patented. If it was, it would've run out long ago since Huffman coding has been in widespread use since the '50s.)

It is rediculious to think that Forgent Corp owns the JPEG data compression technology. Many movements and groups have contributed to improve JPEG compression. For example, the Independent JPEG Group is an independent group that writes and distributes a widely used free library for JPEG image compression. Their website features the source code and some documentation.
More information can be found on the ISO JPEG standards committee webpage.
-Tom

There's countless others, but I don't feel like looking for them.

I remember back when binary packages weren't released for damn near anything - after all, with gcc, everyone could have a C compiler. Wanted to run the newest afterstep or fvwm? Guess what? Download the source.

For linux, it's the distribution's job to provide binaries. For other systems like solaris and HP-UX there are places like Sun Freeware or HP-UX Software Porting Archive to get it. Some projects do so as a courtesy, but it's hardly required.

For something like XFree86, a binary distribution would almost certainly screw up your linux distribution's packaging system. Very few people would be able to utilize a binary distro of X that isn't tailored for their flavor of linux.

Besides, if you run something like linux from scratch then you don't want to download binaries anyway.

I'd like you to understand why cross-platform code is incredibly important (note that this page quotes Judge Jackson of the MS vs. DOJ case as to why Microsoft felt it was so important to put a stop to cross-platform code as to break the law.)

But I think what we have lost sight of is maintaining both the usefulness of our code and our independence as programmers by not remembering how to write cross-platform code.

What Sun got wrong was not making Java cross-platform, but trying to bind us all into proprietary platform of Java while sweetly singing into our ears that it was platform independent. Sun did this and continues with it to serve its own marketing and political purposes, purposes which may not serve the interests of either the public or the independent developer.

You too can write cross-platform code, in almost any compiled language. Check out the ZooLib cross-platform application framework for C++, as well as the Boost C++ Libraries.

Jon Watte of Be, Inc. told me "Portable, to some people, means it builds on at least two linux distributions with several flavors of GCC".

Here's a list of a bunch of application frameworks, many of which are cross-platform, and many of which are open source - so there's more than just ZooLib to pick from.

Get off your duff and ship your executables for all platforms in common use - and not just ones with POSIX system call APIs!

And here's a hint for making your code buildable cross-platform - ever try to run "./configure" on a computer that doesn't have a command shell? Pretty hard. Makes folks like me struggle to write all the makefile's and config.h's by hand. But look at how many platforms the Independent JPEG Group's JPEG codec library builds on - DOS, MacOS, Cray, you name it, and it builds with both ANSI-C and old K&R c compilers (using macros for the function interfaces).

Kids these days... damn it makes me mad.

Michael D. Crawford
GoingWare Inc

Written by the Independent JPEG Group.

The best thing to do if you want something supported is to create a free library written in C like IJG did for normal JPEG. Almost everybody is using their code because it's stable and portable.

That way, all browser creators have to do is link it into their project... At least that works for an additional image file format decoder.

More information on JPEG 2000 can be found at http://www.jpeg.org.

I am wondering if the IJG is planning to (and has sufficient resources to) implement JPEG 2000 support quickly as the specification finalizes. Does anyone know? I asked Tom Lane about this indirectly a while ago, and he just pointed me to the www.jpeg.org web page.

The IJG did a great job on the current library, and I hope that they can do JPEG2000. I also think that if they need support (manpower/money) it would behoove the OSS comunity to provide it.

If for one agree that wavelet based approaches to compression are the future off lossy continuous tone compression. The MrSID technology for instance is great, but they hold a very tight hold on their proprietary technology. I think it is important to establish a popular, and public format and technology to fill this void or proprietary interests will damage OSS efforts.