Slashdot Mirror

Jim Mock writes in to "announce the hardcopy release of the FreeBSD Handbook. Written by the FreeBSD Documentation Project, the FreeBSD Handbook is a comprehensive guide to installing and running FreeBSD, and covers the installation and day-to-day use of FreeBSD, the ports collection, kernel configuration, the X Window System, printing, FreeBSD's Linux binary compatibility support, upgrading your system from source by using the ``make world'' command, and much more." Read on for more details.

Integrity demands that I point out that in another window I'm the FreeBSD Documentation project manager -- that doesn't mean I get to see any of the money this raises though, so the black-helicopter gang needn't worry. Jim continues: "If you are interested in purchasing a copy of the handbook, you can do so online from the FreeBSDMall or Walnut Creek CDROM."

If you're involved in other open source documentation efforts you might be interested to know that the Handbook is marked up in (a slightly extended version of) the DocBook DTD (and more details about the extensions are available at the Doc. Project Primer). The "source" for the Handbook is (naturally) available in CVS, as are the tools and infrastructure used to build it.

Jim Mock writes in to "announce the hardcopy release of the FreeBSD Handbook. Written by the FreeBSD Documentation Project, the FreeBSD Handbook is a comprehensive guide to installing and running FreeBSD, and covers the installation and day-to-day use of FreeBSD, the ports collection, kernel configuration, the X Window System, printing, FreeBSD's Linux binary compatibility support, upgrading your system from source by using the ``make world'' command, and much more." Read on for more details.

Integrity demands that I point out that in another window I'm the FreeBSD Documentation project manager -- that doesn't mean I get to see any of the money this raises though, so the black-helicopter gang needn't worry. Jim continues: "If you are interested in purchasing a copy of the handbook, you can do so online from the FreeBSDMall or Walnut Creek CDROM."

If you're involved in other open source documentation efforts you might be interested to know that the Handbook is marked up in (a slightly extended version of) the DocBook DTD (and more details about the extensions are available at the Doc. Project Primer). The "source" for the Handbook is (naturally) available in CVS, as are the tools and infrastructure used to build it.

Their GIF patent expires in 2003, so Unisys is getting while the getting's good, according to CNET. They're not commenting on the record, but it seems they'll be kicking up their licensing fees. According to one source, they asked Accuweather for US$3.8million. Instead, AccuWeather forecasts switching to PNG next month (insert sound effect of burning GIFs.)

Update: 04/19 09:44 by J : I just checked the bug log for Mozilla's lack of PNG alpha transparency (which has been registered and debated for over a year, and which I gather is the major factor standing between Mozilla and PNG compliance).

Three days ago, after a little tweaking, Greg Roelofs reported significant progress on the latest build:

http://www.cdrom.com/pub/png/pngs-img-moz.html

It's gorgeous! Aside from the interlacing bug (bug 3195), it's the equal of MacIE 5.0. Well done, Tim and Pam! It's truly a lovely thing to behold. I look forward to seeing this bug closed out at last.

Their GIF patent expires in 2003, so Unisys is getting while the getting's good, according to CNET. They're not commenting on the record, but it seems they'll be kicking up their licensing fees. According to one source, they asked Accuweather for US$3.8million. Instead, AccuWeather forecasts switching to PNG next month (insert sound effect of burning GIFs.)

Update: 04/19 09:44 by J : I just checked the bug log for Mozilla's lack of PNG alpha transparency (which has been registered and debated for over a year, and which I gather is the major factor standing between Mozilla and PNG compliance).

Three days ago, after a little tweaking, Greg Roelofs reported significant progress on the latest build:

http://www.cdrom.com/pub/png/pngs-img-moz.html

It's gorgeous! Aside from the interlacing bug (bug 3195), it's the equal of MacIE 5.0. Well done, Tim and Pam! It's truly a lovely thing to behold. I look forward to seeing this bug closed out at last.

Bob Bruce writes: "There will be a BSD BOF (Birds Of a Feather meeting) at Spring Comdex, on Wednesday April 19 from 5:30 p.m. to 7:30 p.m. The BOF is at the Essex Inn at Grant Park, Chicago. You do not need to be a Comdex attendee to come along, everyone is welcome." Read on for more details.

Bob continues: "There will be speakers from BSD/OS, Darwin, FreeBSD, NetBSD, and OpenBSD. This is a great opportunity to meet some of the leaders in the BSD community. There will be plenty of technical information available. Whether you are a BSD expert, a newbie, or just thinking of switching over, you can get your questions answered."

"Several BSD celebrities will be attending, including Chris Coleman, an editor of Daemonnews, and cartoonist Susannah Coleman, creator of Darby Daemon, who will be signing prints."

"We will have installation CDROMs, BSD paraphernalia, and free food and beer. We will even have free Daemon horns!"

"This BOF is being co-sponsored by BSDi and Daemon News."

Jean-loup is the kind of person I love to see us interview here. He's important in the sense that work he's done (positively) affects almost every Linux or Unix user, but the chance of Jean-loup ever getting any "mainstream" media attention is zero. Or possibly less. Without people like Jean-loup there would be no Open Source movement, and I consider the chance to present him as a Slashdot interview guest a *huge* honor. The readers who asked the excellent questions, and the moderators who helped select them, also deserve major kudos. So thanks to all of you for an excellent Q&A session!

1) bzip2 Support
by Aaron M. Renn

When is gzip going to provide (transparent) support for bzip2 files and the Burrows-Wheeler algorithm?

Will BW be an algorithm option within the gzip file format itself ever?

Gailly:

I have worked very closely with Julian Seward, the author of bzip and bzip2. The goal was to integrate a Burrows-Wheeler algorithm inside zlib 2.0 (upon which gzip 2.0 is based). One of the requirements was to avoid the kind of arithmetic coding used in bzip because of both patent and decoding speed concerns, so Julian wrote the Huffman coding code now used in bzip2. Another requirement was to put the code in library form and Julian did that too.

Unfortunately, Julian decided to release bzip2 independently instead of staying within the gzip 2.0 project. It was mainly my fault, since I couldn't spend enough time on the other parts of the project, and the project was not advancing fast enough. Since Julian left, the project progressed even more slowly, and new blood is obviously necessary, because other responsibilities no longer leave me enough time for gzip. If you're an expert in data compression, e-mail me to convince me that you are the most qualified person to turn the zlib/gzip 2.0 project into an overwhelming success :-)

2) The Data Compression Book
by drudd

I am a happy owner of The Data Compression Book (2nd Ed). With the increasing availability of compression routines within libraries (Java's GZIP streams spring to mind), does this make your book a little unnecessary?

Should software authors continue to write their own compression routines, or simply trust the versions available to them in library form?

I can see some definite advantages to library code, i.e. the ability to upgrade routines, and having standardized algorithms which can be read by any program which utilizes the library.

Gailly:

The compression routines in The Data Compression Book were written mainly for clarity, not for efficiency. The source code is present to help understand how the compression algorithms work. It is not designed to be used as is in other software packages, although it does work if efficiency is not a concern. Consider the book as teaching material, not as a data compression library distributed in printed form.

This doesn't mean that the book is unnecessary. Good data compression libraries don't appear magically; their authors had to learn compression techniques one day. If the book helps one person to get started in the data compression area and this person later writes a great compression library, the book will have been useful.

Judging by the success of my zlib data compression library, I think that a vast majority of software authors prefer using an existing library rather than reinventing the wheel. This is how the open-source model works: building upon the work of others is far more efficient than rewriting everything.

3) Compression patents
by Stephen

The compression world has many patents, notably for Lempel-Ziv compression as used in GIF. What is your view on companies patenting non-obvious algorithms for such processes as data compression?

Gailly:

The worst problem is companies patenting obvious algorithms. There are far more patents on obvious ideas than patents on really innovative ideas. In the data compression area, even something as basic as run-length encoding (replace "aaaaa" with a special code indicating repeat "a" 5 times) has been patented at a time where this technique had been well known and widely used for many years.

It is distressing to see the U.S. patent office granting such patents, in contradiction with the law requiring an idea to be both novel and non-obvious to be patentable. Philip Karn has made a good analysis of the problem.

Patents on non-obvious algorithms are a different matter. One view is that algorithms should not be patentable at all, whether obvious or not. This used to be the case, until the US patent office started to grant patents on methods which were nothing else than pure algorithms. I'm afraid that a switch back to the original situation is extremely unlikely.

Several reforms are necessary:

• The patent term should be significantly shortened, at least for algorithms. The patent system was designed to benefit society as a whole, ensuring that new ideas would eventually be made public after a limited period of time instead of being kept as trade secrets. But 20 years is incredibly long in the software area. Granting a monopoly for such a long time no longer benefits society.
• The non-obviousness requirement should be applied much more strictly. A little bit of common sense would avoid a lot of patents on trivial ideas.
• Prior art should be checked more thoroughly. Even non-obvious ideas should not be patented if they have been in use for several years already.

4) A question about Mandrake...
by Mr. Penguin

As we all know, at first Mandrake was little more than a repackaged version of Red Hat. That's changed a bit with the newer versions. My question is this: to what degree will Mandrake continue to differ from RedHat and will there ever be a "developer" version (i.e. one that is centered towards those who are a bit more technically competant)?

Gailly:

That's changed more than a bit. Our distribution is now completely made by us. Believe me, doing everything ourselves represents a significant amount of work. Few people understand how much work is involved in making an independent distribution. We have our own development teams producing things like our graphical install DrakX, our disk partionner DiskDrake, management of security levels in msec, hardware detection with Lothar, etc... Our packages are more recent than those of Red Hat and have more functionality (such as supermount support in the kernel). Red Hat is now even copying packages made by MandrakeSoft (e.g. rpmlint). I hate having to speak like a salesman here, but it is really unfair to say that Mandrake just repackages RedHat; this is simply not true anymore.

Have you looked at Linux-Mandrake 7.0? It does include a developer version. At install time, select the option "Custom" then "Development". You will get all necessary development tools. We, as developers, use our own distribution :-)

5)Why is Mandrake better than Red Hat?

I guess that you have at least a little something to say about this.

Is the 586 optimization enough to justify Mandrake's position? Are you especially proud of any of the architectural differences between the distributions (from what I have been told, the Apache-PHP layout is quite a bit different).

How do feel about the steps that Red Hat has taken to change their distribution in reaction to yours?

Gailly:

Mandrake is far more than Red Hat plus 586 optimization. It is an independent distribution. (See the answer to A question about Mandrake above.) We have enhanced some packages (such as the kernel or Apache) to provide additional functionality for users.

It's clear that Mandrake pushes Red Hat to improve its own version and nowdays Red Hat includes some development from Mandrakesoft. There is a coopetition: Red Hat and MandrakeSoft both benefit from the same open-source community, but they compete for the customer. This coopetition is fully beneficial for the Linux users since we both need to constantly improve our version. We just make sure that Mandrake stays ahead :-)

6)Winzip
by Uruk

I noticed that you allowed the people who make the Winzip product to incorporate code written for Gzip. I think it's cool that you did that, because it would be horrible if winzip couldn't handle the gzip format, but at the same time, what are your thoughts about allowing free software code to be included in closed-source products?

Just out of curiosity, (tell me it's none of my business if you want to and I'll be OK with that) did you receive a licensure fee from the company that makes Winzip for the code?

Gailly:

I started writing compression code simply because my 20 MB hard disk, the biggest size one could get at the time, was always full. I didn't write it for money. Even after I got a bigger hard disk, I continued writing compression code for fun. In particular I was not interested in writing a Windows interface. This is why I allowed my code to be used in Winzip. I received exactly 0$ for this.

The zlib license also allows it to be used in closed-source products. This was an absolute requirement for the success of the PNG image format, which relies on zlib for data compression. If we had used a GPL license, Netscape and Microsoft Explorer wouldn't support PNG, and the PNG format would be dead by now. I also received 0$ for zlib, if you're curious...

Even though I allowed my code to be used in closed-source products, I am a strong supporter of the open-source model. That's also why I work for MandrakeSoft. The open-source model is getting so much momentum that it will in the end dominate the software industry.

7) What about wavelets? by Tom Womack

The Data Compression Book was an excellent reference when it came out, but there are some hot topics in compression that it doesn't cover - frequency-domain lossy audio techniques (MP3), video techniques (MPEG2 and especially MPEG4), wavelets (Sorenson video uses these, I believe, and JPEG2000 will), and the Burrows-Wheeler transform from bzip.

Do you have any plans for a new edition of the book, or good Web references for these techniques? BZip is covered well by a Digital research note, but documentation for MPEG2 seems only to exist as source code and I can't find anything concrete about using wavelets for compression. The data is all there on the comp.compression FAQ, but the excellent exposition of the book is sorely lacking.

Gailly:

These are all very worthy topics, and Mark Nelson and I would like to incorporate them into a new version of the book someday. However, the decision to produce a new version is taken by the publisher, not us.

Note also that these are all very big topics, and it would be quite easy to write an entire book on each one. I don't think they will fit well in a chapter or two. Covering JPEG in one chapter was difficult, and Mark Nelson has been criticized for not describing the specifics of the standard algorithm.

You can find some Web references here and there, in addition to the comp.compression FAQ.

8) Compression software
by jd

It is a "truism" in the Free Software community that code should be released early and released often.

However, much of the software you've written has started gathering a few grey hairs. Gzip, for example, has been at 1.2.4 for many, many moons, and looks about ready to collect it's gold watch.

Is compression software in a category that inherently plateus quickly, so that significant further work simply isn't possible? Or is there some other reason, such as Real Life(tm) intruding and preventing any substantial development?

(I noticed, for example, a patch for >4Gb files for gzip, which could have been rolled into the master sources to make a 1.2.5. This hasn't happened.)

Gailly:

I knew this question would come when I accepted a Slashdot interview. But I had to face it :-(

In short, you are completely right. While working on gzip 2.0, I continued to maintain gzip 1.x, accumulating small patches, and answering a lot of e-mail. But I was hoping to be able to release gzip 2.0 directly, without having to make an intermediate 1.x release. See my answer to the question bzip2 support concerning the state of gzip 2.0 and the Real Life interference. I'd be glad to hand over all my patches for 1.2.4 to the person who can help me getting the gzip 2.0 project to full speed.

9) Proprietary algorithms
by Tom Womack

The field of compression has been thronged with patents for a long time - but patents at least reveal the algorithm.

What do you think of the expansion of trade-secret algorithms (MP3 quantisation tables, Sorensen, RealAudio and RealVideo, Microsoft Streaming Media) where the format of the data stream is not documented anywhere?

Gailly:

The hardware specifications for some video cards were kept as trade secrets. As a result, the XFree86 project couldn't support these cards. Increasing pressure from users who didn't buy those cards because they couldn't be supported has led the manufacturers to release the hardware specifications, and those cards are now well supported.

Similarly, I think that pressure from the open-source community can become strong enough to force companies to open their formats. We're not completely there yet, but I believe that the open-source model will win in the end. Even a giant like Microsoft starts considering Linux as a real threat.

10) Go and Compression
by Inquisiter

When I think of a game like go or chess, I think that each player develops there own algorithm to beat their opponent. If you agree, what relationships or similarities do you see between your intrest in Go and your intrest in compression?

Gailly:

What a nice question!

Even though the rules of go are very simple, the complexity of go is astonishing. The best go programs can be beaten by a human beginner. The search space in go is so large that is impossible to apply the techniques that are so successful in chess. Professional go players never evaluate all possible moves. They are able to compress an enormous amount of information into a relatively small number of concepts.

Where a human beginner would have to painfully examine many possibilities to realize that a certain group is doomed, and would most likely fail in the process, a go expert can immediately recognize certain shapes and can very quickly determine the status of a group. One gets stronger at the game by reaching higher levels of abstraction, which are in effect better compression ratios. A professional go player can elaborate concepts that an average player would have great difficulties to understand.

Current go programs are overwhelmed by the amount of information present in a game of go. They are unable to understand what is really going on. Since brute force techniques can't work in go, programs will only improve by compressing the available information down to a manageable level.

Earlier we announced that Walnut Creek CDROM and BSDI are merging. Obviously, this will shake up the BSD playing field considerably, and will doubtless have knock on effects with the Linux and other open source communities too, to say nothing of the various commercial organisations that already rely on FreeBSD or BSDI on their servers. Here, to answer questions about the merger, is Bob Bruce, president of Walnut Creek. Jordan Hubbard, FreeBSD core team member and release co-ordinator, and Gary Johnson, CEO of the new company, also contribute.

But first, a little bit of background.

Walnut Creek sells CDs full of freely available software, and run the world's busiest FTP server (ftp.freesoftware.com, formerly known as ftp.cdrom.com). Walnut Creek has been involved with FreeBSD since the early days, producing the first FreeBSD CD distribution, and providing gainful employment for some members of the FreeBSD development community. This article from FreeBSDzine explains some of the Walnut Creek/FreeBSD relationship.

BSDI was formed by members of the Computer Systems Research Group (CSRG) at UC Berkeley (i.e., the same group responsible for the Unix BSD in the first place). BSDI produce, market, and provide support and training for a commercial BSD Unix (or Unix-like) OS for the Intel platform, and as such, are competing in the same space that FreeBSD, NetBSD, OpenBSD, and Linux (not to mention Microsoft) all play in.

While there have been several IPOs, mergers, and acquisitions by various Linux-driven companies in the relatively recent past, this is the first in BSD space. Here Bob Bruce answers questions about the merger, some of which came from yourselves, via the earlier story.

[Disclaimer: in another xterm I'm nik@freebsd.org, which obviously gives me a greater vested interest in this event than most. Unless otherwise indicated, the answers are from Bob.]

What, exactly, is happening? The reports from DaemonNews are that the two companies are merging, the Wall Street Journal says that BSDI is "acquiring" Walnut Creek. Is this a merger of equals, or will one company be the dominant partner?

Walnut Creek CDROM and BSDI have merged into a single company. I don't think either partner will be dominant. Walnut Creek CDROM and BSDI had very similar company cultures, and both companies had a long history of involvement in the BSD community. Several BSDI people were members of UC Berkeley's Computer Systems Research Group (CSRG), and were key early contributors to the free software movement. Several of the top people in the FreeBSD project worked for Walnut Creek CDROM. So together we have an extemely talented group of people.

The two companies mesh well at the sales and marketing level, too. Walnut Creek CDROM brings online sales and retail channel expertise. Our shrink-wrap products are sold in nearly all major chains, including CompUSA, MicroCenter, Fry's, Border's, etc. BSDI brings expertise in VAR/OEM sales, embedded systems, corporate sales and infrastructure markets. For instance, UUNet runs on BSD/OS.

Why merge at all? FreeBSD and BSDI have coexisted for some years now. BSDI uses code from FreeBSD (I believe) and they have also contributed code back to FreeBSD. What benefits will merging bring?

The obvious advantage is that our development efforts will be sharing codebases. So we can make improvements faster and at lower cost. Our goal will be a single ABI for third party vendors to port to, which will mean more applications available on BSD.

People who are trying to decide whether to rely on Linux or BSD should note that the two commercial BSD-based companies are unifying at the same time that the Linux market is being divided up into smaller and smaller fragments. It seems like every few weeks another company announces a Linux distro. I just read that Motorola is producing their own. Now don't get me wrong, I really wish that Linux wasn't so fragmented. In fact, I would like to go back to the good old days when Slackware had a 90% market share ;-)

Gary adds: A merger makes a lot of sense from a promotion and funding perspective. You'll be seeing much more promotion about BSD in the future. It's often been said that we've got the superior technology, but the marketing has been nearly non-existent. That's going to change.

More money means more development funds as well. For example, an Itanium project is definitely in the pipeline. No firm details yet, but it will happen.

What's the new company going to be called?

Currently BSDI is the name of the company, but we are looking at alternatives.

Where is BSD's focus going to be? The traditional role has been servers, with some developers expressing a disdain for the desktop.

Gary says: We're committed to growing our position in the marketplace. Traditionally, the Internet Infrastructure market has been where we're strongest, and that's where we're going to focus. But not to the exclusion of promoting BSD for the desktop. FreeBSD and BSDI both have major customers in the embedded market, and among infrastructure suppliers.

What will happen to the FreeBSD codebase? Is it going to merge with the BSDI code, or vice-versa? Will there be two code trees?

There are plans for the two codebases to merge, but not immediately. FreeBSD 4.0 is scheduled for release very soon [4.0 should go gold on March 13th -- Nik] and will not contain any code from BSD/OS. Once 4.0 becomes the "stable" branch, the merging work will begin on the "current" branch. There will also be continuing improvements and enhancements to the proprietry BSD/OS.

Jordan adds: I also see us best doing this by gradual convergence, not by simply attempting to ram one group or code-base into another. It will take time for the FreeBSD developers to come up to speed on the various features in BSD/OS they may be merging and the converse is true for the BSDI developers; they've been working on BSD/OS for the last decade and will need time to familiarize themselves with the FreeBSD code base, its development methodologies and its culture.

There are a number of FreeBSD features which existing BSD/OS customers have requested just as there are a number of BSD/OS features which the FreeBSD project will be looking into merging. By doing this work in parallel, we can deal with the familiarization issues on both sides while making the eventual code merger progressively easier.

David Greenman and Mike Karels will be working together as co-architects for the new system. As features are merged in, they will be available for download at www.freebsd.org, and on "snapshot" CDROMs. The completely merged system will be released as FreeBSD 5.0.

Who 'owns' FreeBSD now? Jordan's been talking about a FreeBSD Foundation, is that going to see the light of day?

FreeBSD is "owned" by the FreeBSD Project, which is made up of the core team, the committers, and all the other people who write the code. No company can ever own FreeBSD, anymore than a company can own Linux. The FreeBSD Foundation will be an independent non-profit organization. It will be controlled by a board of directors, which will contain some members of the core team. The Foundation and the core team are still separate entities going forward.

What about the name "FreeBSD", and related tems, like the "PicoBSD" distribution? If someone wants to build the own CD-ROM release, can they call it "FreeBSD"?

The trademark "FreeBSD" was owned by Walnut Creek CDROM, so it is now a registered trademark of the merged company. But, by written agreement, the use of the trademark is controlled by the FreeBSD core team.

Roughly speaking, how many new, full time, developers is this going to bring to FreeBSD?

About twenty. But that will grow. We are hiring, so if anyone out there in Slashdot land needs a job and knows how to code, send your resume to jobs@cdrom.com.

Are there any BSDI only features that are slated for rapid integration into FreeBSD?

No. FreeBSD and BSD/OS have well deserved reputations for robustness and stability. We don't want to jeopardize that by rushing the integration process.

Are any features of the BSDI codebase going to stay proprietary?

At first much of the BSDI codebase will remain proprietary. It will only be freed as it is integrated with FreeBSD. There are some parts of the codebase that cannot be freed because the code was written under a contract that does not permit disclosure.

Jordan adds: This pertains only to the BSD/OS kernel. There is intention to merge the "userland" code as soon as is practical, since there are no issues with any of that code, according to Mike Karels.

Prompted by a question from "dcs" earlier; most of the FreeBSD developers meet through the mailing lists, and no one is "parachuted" in to a committer position without first submitting PRs, having them accepted, being proposed for committership, having a mentor, and so on. Everyone's got where they are by working with one another, and going through the peer review process.

Will the BSDI developers (those of them who will be working on the FreeBSD code) have to go through the same (or possibly accelerated) process? Or will they be dropped in as committers almost immediately?

Jordan: I think it's too early to say how each and every case will be handled, but that it'd also be reasonable to assume that a hybrid approach will be used. In each case we'll be first estabishing just what each potential new committer will be doing and what the priority for that work is, then we'll look at their track record and take prior experience into account just as we've done with many other committers.

Some committers have approached us as complete unknowns and have had to enter the project "the slow way", by submitting PRs and essentially proving themselves to us over time. In other cases, a committer has approached us (or vice-versa) and the core decision to add him has gone in a matter of hours from concept to edits to the access file ("Kirk wants a commit bit? stamp Done! Somebody go grab him before he changes his mind!"). It all really depends on just how much of a known-quantity the person is and I expect that to work in everyone's favor in a good deal of the cases for BSDI developers.

It's been suggested that some of the BSDI people would be coming in as FreeBSD core team members. Is that right?

Jordan: This really isn't clear yet and all we've talked about is the fact that we'd be willing to take some on if they expressed a direct interest. This has yet to happen as I'm sure most of the folks over at BSDI are still too busy staggering around and trying to cope with this Brave New World to think about things like joining FreeBSD-core. I would also expect to be able to spend a little time explaining just what this means in reality to any prospective candidate in advance, such being only fair.

Are there any changes planned for the BSD license?

That is up to the University of California. We have no control over the BSD license. UC removed the advertising clause last year, which was the right thing to do. I can't think of anything else that should be changed. The BSD license is about as free as you can get short of public domain, and its "business friendly" nature is one of the reasons that BSD is so widely used in commercial applications which require customized kernels, such as the IBM Interjet, the Intel StorageServer, and Inktomi's network products.

Will the code still be released under the BSD license? If so, which one? There are three BSD licenses available; the original BSD license with four clauses, the new BSD license, without the advertising clause, and the FreeBSD license, which also omits the fourth clause as well.

It will be released under the newest license, without the advertising clause. Contrary to other reports, once the BSDI code is released under the three clause license it will be usable by anyone, not just other open source projects.

How will this impact on other organisations use of the codebase? For example, Apple use FreeBSD extensively in MacOS X.

It will have a positive impact. We have been unable to work more closely with partners like Apple because of limited resources, especially not enough people. That will change. We will be strengthening existing partnerships and building new ones.

Jordan adds: It should also be noted that people who are doing their own FreeBSD-based solutions can continue to do so, we're not changing the terms under which FreeBSD is being released or can be used in other products. Nothing changes for FreeBSD here and it's in the areas where a customer wants more than FreeBSD can currently deliver for, say, an embedded systems product that I see the commercial possibilities. Anyong buying a commercial RTOS today gets a lot more than a CDROM containing some bits, for example, they also get about four feet of printed manuals, a support contract, tools for doing cross-compilation on other platforms (like NT), etc. Providing those kind of value-adds for FreeBSD on a commercial basis would be a win-win scenario for everyone, I think, and that's just one possible avenue of exploration.

Living and working in the UK, BSD's presence here is limited. I can get various Linux flavours from the bigger PC stores, but BSD seems to be relegated to a few, more specialist, suppliers. Red Hat has announced plans to expand in to Europe, and Suse is based in Germany. Is this a market you're going for, or are you contentrating on the U.S. at the moment?

Gary: In the UK, you may find FreeBSD on the shelves of Dixon's soon [Big consumer electronics chain, computers, cameras, hi-fi systems, that sort of thing -- Nik]. You can expect to see big changes in our market presence in Europe, particularly over the next six to 12 months. I can't say more than that at the moment.

Walnut Creek sell 'competing' products, including Slackware and Redhat Linux. Is this going to change?

Our Slackware division will be spun off as an independent company: Slackware Linux, Inc. But our Linux and BSD developers will continue to work closely together. Patrick Volkerding has moved out here from Minnesota and is now managing Slackware development on a day-to-day basis. We will be releasing Slackware 7.1 by summer.

What about other distributions (or, indeed, other OSs). Would the new company release OpenBSD or NetBSD CDs, for example?

We have no plans to do that.

But we are trying to get the entire BSD community to work together more. For instance, our annual conference, FreeBSD'Con, is being renamed BSD'Con, and will now include all BSD software, not just FreeBSD.

There is frequent cross-fertilization of ideas and code between the Linux and BSD communities. Probably a lot more than most people realize. This is what "Open Source" is all about: both communities benefit from fresh ideas as well as healthy competition. We are at the focal point where these two communities come together, and this is a very exciting place to be.

Going to LinuxWorld this year? Robert Bruce, head honcho at Walnut Creek CDROM, writes "There is going to be a BSD BOF at the New York Linuxworld on Thursday, Feb. 3, from 5:30 p.m. to 8:30 p.m. We are in room 1D05, Jacob Javits Convention Center, near the conference area in the lower (2nd level down) of Javits. You do not need to be a Linuxworld attendee to come to the BOF. Everyone is welcome. There will be representatives from BSDi, FreeBSD, NetBSD and OpenBSD." If you're after installation CD-ROMs, or a bite to eat, this is the place to be. You might even be able to get one of the free Daemon Horns that will be given away. The BOF is being sponsored by BSDI, Walnut Creek CDROM, and BUNY (BSD Users of New York).

Fr05t asks: "Since the day the Internet became popular and the good old BBS's faded into the back ground, I myself have had a hard time finding the same kind of active community. Sure there's Slashdot, BugTraq, and IRC, but for whatever reason it seems people remain private and keep to themselves without a who's online option, and a message feature. I do see other Slashdot members posting often, but there are allot more people that read the articles and have opinions that remain in the background. I guess my question is if anyone has found the same kind of thing as the old BBS's?" (More)

I remember back in the 80's when I spent most of my waking hours after school in front of the monitor hooping from one BBS to another. I figure most of the BBSes have evolved in some way, shape or form and made the jump to the Internet. A few of them have evolved into Web Boards, which just don't have that same feel.

When I speak of "that BBS feel", I mean having the ability to go through different sections of the system, actually browsing the messages left by others in a free-forum (as opposed to moderated forums like Slashdot), actively seeing who was on the system at the time (the afore mentioned "who" command), the ubiquitous file transfer areas (which, for the most part have been surplanted by your mega-FTP sites like WcArchive and Freshmeat and others of their ilk). And door games....anyone remember door-games? (I'm still waiting for an online version of TradeWars for the Internet...)

Of course, my free time online has dropped dramatically due to my day-job and Slashdot, so I don't have the time to search for such online communities anymore. If anyone cares to make recommendations to any IBBS systems that may still exist, please feel free.

Anonymous Coward writes "The ChangeLog as well as a readme for Slackware 7 are out and ready. Proceed with caution, ftp.cdrom.com's server has a new limit on the number of simultaneous user's (5000)... " It's out apparently - I cannot get on the servers though. Have fun!

Anonymous Coward writes "The ChangeLog as well as a readme for Slackware 7 are out and ready. Proceed with caution, ftp.cdrom.com's server has a new limit on the number of simultaneous user's (5000)... " It's out apparently - I cannot get on the servers though. Have fun!

ESR writes "Remember the flap back in 1994-1995 about the GIF format, with Unisys behaving like jerks over the LZW compression method and threatening to charge license fees for use of their bogus patent? Well, brace yourselves. It just got worse. Under Unisys's new policy, they've gone beyond shaking down software authors. They're now threatening to sue even noncommercial websites that carry GIFs for a $5000 license fee, regardless of whether the GIFs were generated by licensed software or not. The gory details are at Don Marti's Burn All GIFs Day site. Time to convert all your GIFs to some other format. I like PNG better than JPEG, as it's lossless. The PNG site carries a gif2png tool that does a good job; I just used it to clean up my personal website. GIF animations won't survive the conversion, however...uh, wait. Maybe Unisys just did us a favor after all... " Here is the Unisys page that started it all.

cyan writes "It appears that Slackware is finally going to be glibc based. This was revealed today via an announcement which was sent to the slackware-announce mailing list. A directory called "slackware-current has appeared on cdrom.com, so people may take a look at what's in store if they wish. Note that this should in no way be considered "stable", it's more for testing purposes. Check out the ChangeLog.txt for details; looks promising for all us Slackware freaks ;) " It seems the Slackware folks have been quite busy recently...

cyan writes "It appears that Slackware is finally going to be glibc based. This was revealed today via an announcement which was sent to the slackware-announce mailing list. A directory called "slackware-current has appeared on cdrom.com, so people may take a look at what's in store if they wish. Note that this should in no way be considered "stable", it's more for testing purposes. Check out the ChangeLog.txt for details; looks promising for all us Slackware freaks ;) " It seems the Slackware folks have been quite busy recently...

xlogan writes "I received my FreeBSD 99 catalog in the mail today from Walnut Creek and The FreeBSD Mall and it included a little brochure about FreeBSDCon '99. Hope I can get work to pay for the trip ;-) "

crunge writes "SlackWare 4.0 is now available. It is based on the 2.2.x kernel. It is still libc5-based (but glibc 2.0.7pre6 compatibility libraries are available for those who want/need to run glibc2 applications. (My understanding is that the next release will be glibc2.1-based). Grab it from the usual usual places.

aqua writes "Just noticed that ftp.cdrom.com, renowned for being the single biggest/fastest FTP server in history, yesterday quietly received its first hardware upgrade in two years -- the old machine was a single PPro200 / 2GB RAM; it's now a Xeon500 / 4GB. Software and disk stayed the same. Nice to see such a venerated old server get some more ponies under its hood. For the first time it also includes a credit for where they buy their hardware. The message is here. " The good news is that the max. user limit is 5000 now - I hope they have the bandwidth for it. And phil thinks he sends out a lot of data.

aqua writes "Just noticed that ftp.cdrom.com, renowned for being the single biggest/fastest FTP server in history, yesterday quietly received its first hardware upgrade in two years -- the old machine was a single PPro200 / 2GB RAM; it's now a Xeon500 / 4GB. Software and disk stayed the same. Nice to see such a venerated old server get some more ponies under its hood. For the first time it also includes a credit for where they buy their hardware. The message is here. " The good news is that the max. user limit is 5000 now - I hope they have the bandwidth for it. And phil thinks he sends out a lot of data.

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Kragen Sitaker has written a brutal reply to the story Sengan posted yesterday on the The Open Source Acid Test. It goes down and point by point shows the factual errors and fud in the story. It pleases me greatly to post this feature. Check it out. The following was written by Slashdot Reader Kragen Sitaker

I read Ted Lewis's article, _The Open Source Acid Test_, on your web pages.

I was appalled that an organ of a prestigious international society like the IEEE would publish such error-riddled, poorly-researched, deliberately deceptive nonsense. It's as if the _New England Journal of Medicine_ had published a case study of a zombie animated by voodoo!

The author did not cite sources for any of his dubious statistics, and they are therefore hard to disprove. Given the remarkable lack of factual accuracy in the article, I doubt that they have any basis in fact.

To begin with the most obvious errors:

1. Linus Torvalds's name is not Linus Torvold.
2. Applix, Tower Technology, and NewMonics do not sell open-source software.
3. There is no such company as "Walnut Creek Stackware". www.cdrom.com belongs to Walnut Creek CDROM. There is no such company as "Tower Tech JVM". www.twr.com belongs to Tower Technology, which sells a (non-open-source) JVM. There is no such web site as www.debian.com.
4. www.python.org is operated by the Python Software Association, not CNRI, although it is currently hosted on CNRI's network.
5. Several of the "commercial enterprises" listed in Table 1 are not commercial enterprises at all. www.hungry.com, www.python.org, and www.debian.org are all operated by nonprofit organizations. The Corporation for National Research Initiatives, which was incorrectly listed as operating www.python.org, is actually a not-for-profit research organization.
6. It is absurd to say that Unix was the foundation for Hewlett-Packard and IBM, as Lewis does in his introductory paragraph. Both companies had been established for more than thirty years when the first line of Unix was written.
7. On page 126, Lewis claims that the open-source community admits that its organizational structure is weak. The evidence he adduces is a quote from a document published on www.opensource.org. What he doesn't tell you is that the document is *a leaked internal Microsoft memo*. Unless Lewis missed the 115 references to Microsoft in this document and also failed to read the introductory paragraphs, the only reasonable conclusion is that he is being deliberately deceptive.
8. On page 125, Lewis claims that "Currently, Linux's installed base numbers 7.5 million". As usual, he cites no source. However, the most widely-cited source for such figures is Robert Young's paper, Sizing the Linux Market eight different data sources to obtain an estimate of between five and ten million Linux users. However, this paper has a date of March 1998. If Linux's growth had continued to double yearly in 1998, as it did from roughly 1993 to 1998, the number of Linux users would be between ten and twenty million.
9. On page 128, Lewis says, "Windows NT market share smothers all Unix dialects combined". According to International Data Corporation's Server Operating Environment report, Unix and Linux together had 34.6% of the server market in 1998, while Windows NT had 36%. See more information. The actual number of server Linux shipments IDC tallied in 1998 was only three-quarters of a million; that suggests that if you include people installing multiple servers from the same CD and installing from Internet downloads, you would find that Linux's server market share is much greater than Windows NT's.
10. Lewis remarks, "With few exceptions, open source software has never crossed the chasm into the mainstream without first becoming a commercial product sold by a commercial enterprise." Does he think that Linux is not a commercial product sold by commercial enterprises? If not, there are literally dozens of "exceptions" to this statement -- Perl, Apache, sendmail, BIND, Linux, Tcl/Tk, Berkeley DB, Samba, the X Window system, FORTH, GNU Emacs, and trn, for example. Many of these became popular before they were commercially sold at all.
11. Lewis misstates the business case for Linux and "its open source software cousins". According to Eric Raymond -- whom Lewis quotes extensively elsewhere in this article -- a much more compelling business case is founded on the better quality of the software, choice of suppliers, choice of support and maintenance, freedom from legal exposure and license tracking. More details are available at opensource.org/for-buyers.html.

These minor factual errors, so far, merely indicate that the author knows very little about the topic he writes about and is deliberately trying to mislead his readers; they do not directly undermine his conclusions. However, as I shall show, each of his supporting arguments consist of incorrect facts and lead to faulty conclusions.

One of the author's major contentions is that as Open Source software adds more features and becomes more comparable to proprietary software, it will lose many of its advantages. He cites as examples Linux's supposed lack of video card support, wireless LAN support, and "a good selection of productivity software."; he claims that Unix contains 10 million lines of code, while Linux contains only 1.5 million. On page 126, he says, "Maintenance and support grow more complex, and costs increase due to a scarcity of talented programmers. Success leads to features, and feature creep leads to bloated software."

With regard to video card support, it is true that the Linux kernel does not have video card support in it. That facility is provided by video drivers in other software; nearly all graphical software available for Linux uses X11 for access to those video drivers. Open-source X11 drivers for most video cards are available from www.xfree86.org; the list of supported cards there currently lists 555 different kinds of video cards, many of which include numerous individual models.

For those few cards for which XFree86 support is not available, proprietary X11 drivers are available from Xi Graphics and Metro-Link.

With XFree86, Linux's video card support is better than either Windows 98 or Windows NT, and considerably more extensive than any Unix that does not use XFree86.

To claim that Linux lacks video card support is merely laughable.

With regard to wireless LAN support, it is true that many of the recent wireless LAN products do not currently have support in Linux. However, Linux has had support for packet-radio wireless networking and several kinds of LANs for years, and has supported several wireless LAN products since at least late 1997, including most of the most popular ones:

Lucent Wavelan
DEC RoamAbout DS
Lucent Wavelan IEEE
Netwave Airsurfer
Xircom Netwave
Proxim RangeLan2
Proxim Symphony
DEC RoamAbout FH
Aironet ARLAN
Raytheon Raylink
BreezeCom BreezeNet

This information is readily available on the Web in the Linux Wireless LAN Howto.

With regard to productivity software, there are several office suites available for Linux, and there have been for several years. ApplixWare and StarOffice are the two most common.

With regard to the size of Linux: first, among the utilities tested in the failure-rate study (the latest report on which is entitled "Fuzz Revisited: A Re-examination of the Reliability of Unix Utilities and Services". the quote used on page 125 appears to be from the original paper, which I cannot find on the Web) are the standard set of Unix utilities, awk, grep, wc, and so forth. These utilities have a standard set of functionality common across all Unix systems, except that the GNU utilities tend to have a great deal of extra functionality included. If the GNU utilities really are only one-sixth the size of the corresponding utilities on a Unix system, yet provide much more functionality, and still have one-third to one-sixth of the failure rate, that is not an indictment of the defect rate of free software, but rather a vindication of it -- which is why this study is linked to from the Free Software Foundation's Web pages. The study is unfairly biased in favor of less-featureful proprietary software, and that software still came out way behind.

(From my own experience, I know that frequently, the best workaround for a bug in a Unix utility is to install the GNU version.)

Lewis's claim that this represents "a single-point estimate of defect rate" is incorrect. The paper includes detailed results of the tests on 82 different utilities, along with aggregate statistics by operating system. 63 of these utilities were available either from GNU or from Linux, and were tested in this study.

With regard to the lines-of-code figure: it is not easy to measure the number of lines of code that constitute "Linux", because it is not easy to define what constitutes "Linux" -- or, for that matter, "Unix" either.

If we mean just the kernel, this site has some figures for the sizes of several OS kernels in 1994. SunOS 5.2's kernel is listed as containing 680,000 lines of code, while SunOS 5.0's kernel is listed as containing 560,000 lines of code. If the rate of increase per version remained constant (doubtful, because 5.0 and 5.1 weren't really finished products) then the latest SunOS (the one that's the kernel of just-released Solaris 7) would contain 1,280,000 lines of code.

By comparison, the source code of the 2.2.1 Linux kernel totals 1,676,155 lines of code, including comments and blank lines, counting only .c, .h, and .S (assembly) files.

The Linux project's source code has already reached a level where we would "expect Linux defect densities to get worse". They haven't.

On page 125, Lewis cites Apache as an example of support diminishing when "the hype wears off", saying "it is currently supported by fewer than 20 core members" -- implying that the "cast of thousands" is a thing of the past. The truth is that the core Apache team has never been larger than 20 people, and they *still* receive contributions from many people outside the group. He also says that "Apache is losing the performance battle against Microsoft's IIS." But Apache has never been intended to be the fastest HTTP server around -- it's already more than fast enough to saturate a T1 when running on a puny machine, so its developers have been concentrating on things like adding more features and making it more reliable.

On page 128, Lewis says, "The concept of free software is a frequently practiced strategy of the weak". While free-as-in-price giveaways are common -- Microsoft's Internet Explorer strategy is a perfect example -- they are not related to open-source software, and their patterns of success and failure have little relevance for us here.

Greg Roelofs writes "Graphics developers (yo, GIMP folks!) will be mildly amused to know that the PNG Development Group has released version 1.1 of the Portable Network Graphics specification. It includes a significantly rewritten section on gamma correction, a couple of new chunks for color correction, and some little stuff relating to suggested palettes, alpha-channel processing, etc. A complete pseudo-context-diff is available. Note also that ISO/IEC standardization is underway, and the PNG home page has even been spiffed up a tiny bit. Whoa. "

Greg Roelofs writes "Graphics developers (yo, GIMP folks!) will be mildly amused to know that the PNG Development Group has released version 1.1 of the Portable Network Graphics specification. It includes a significantly rewritten section on gamma correction, a couple of new chunks for color correction, and some little stuff relating to suggested palettes, alpha-channel processing, etc. A complete pseudo-context-diff is available. Note also that ISO/IEC standardization is underway, and the PNG home page has even been spiffed up a tiny bit. Whoa. "

Greg Roelofs writes "Graphics developers (yo, GIMP folks!) will be mildly amused to know that the PNG Development Group has released version 1.1 of the Portable Network Graphics specification. It includes a significantly rewritten section on gamma correction, a couple of new chunks for color correction, and some little stuff relating to suggested palettes, alpha-channel processing, etc. A complete pseudo-context-diff is available. Note also that ISO/IEC standardization is underway, and the PNG home page has even been spiffed up a tiny bit. Whoa. "

Jon DeNardis wrote in to tell us that Slackware 3.6 has made an appearance. Then FRaNKy wrote in to say that AmigaLinux 5.1, based on RH5.1 is also available for those of you still in the amiga clan.

Nirvani writes "check here. Some other mirror have it to, ie: wcarchive. Have fun! " Ok, are we sure that this is the real one? I see files at least *grin*.

DrZiplok writes "There's a picture of ftp.cdrom.com, the world's largest and busiest FTP archive online. At least, I think it looks boring. Some heavy-duty nerds might like it though. It might even qualify as ammunition in a "we don't need an entire room of servers" argument." Key attached to the link below. Key to the picture, from top to bottom.

1. www.cdrom.com
2. remote console server
3. 3com 100Mbps switch
4. Kingston RAID chassis x2
5. ftp.cdrom.com (P6/200, 1GB memory)
6. Kingston RAID chassis x2

The inset panel on the left front of ftp.cdrom.com is a Mylex RAID controller.

DrZiplok writes "There's a picture of ftp.cdrom.com, the world's largest and busiest FTP archive online. At least, I think it looks boring. Some heavy-duty nerds might like it though. It might even qualify as ammunition in a "we don't need an entire room of servers" argument." Key attached to the link below. Key to the picture, from top to bottom.

1. www.cdrom.com
2. remote console server
3. 3com 100Mbps switch
4. Kingston RAID chassis x2
5. ftp.cdrom.com (P6/200, 1GB memory)
6. Kingston RAID chassis x2

The inset panel on the left front of ftp.cdrom.com is a Mylex RAID controller.

luqin wrote in with the news: FreeBSD 2.2.7 is available via CVSup. He says a cvsup followed by a make world should bring you up to date. It should be available from Walnut Creek CDROM soon. Now, if only those CheapBytes CDs were bootable...

Jouni K Seppänen wrote in to tell everyone that Lars Wirzenius typed in his speech from LinuxExpo. It was pretty cool and I'm sure many of you will enjoy it. Mircea Ciocan wrote in to tell us that the indestructable distribution has risen from ages of silence. We now have Slackware 3.5b2 online for those daring slackers willing to join in. I started with Slackware years ago, and Dave still prefers it. And I know he and the other diehards will be happy that it's still alive. Finally, for a laugh, ewjc wrote in to give us a link to This Wired Article about a nudist who allows access to her site for anyone, unless you have Microsoft affiliations. On one hand, It's a blatant PR stunt designed to cash in on the current tidal wave of anti MS feelings, on the other hand, it's free nudity! (Laugh! I'm kidding! Sheesh. I better go back to the homework before I try to be funny again *grin*.

The FreeBSD Project, Inc. released FreeBSD 2.2.6 to the world. The release may be downloaded or purchased on CD from Pacific Creek CDROM shortly. Definately worth a look- a rock-solid and speedy OS.

Zooko writes " Eiffel, an object oriented programming language, has been getting some good press as an alternative to Java. Today, Interactive Software Engineering, a maker of Eiffel development tools, announced the availability of the latest version of their software for Windows and Linux.

It is nice to see serious support of Linux by a commercial software company. Bertrand Meyer of ISE (and also noted object oriented guru) says: "Linux has been very good to us, and I hope we have been good to Linux too. It's one of our most important commercial platforms. And it's our #1 or #2 development platforms (#2 by a short distance from Windows if you count the number of machines, #1 if you ask developers what they want to develop on...)". See also the GNU Eiffel compiler, SmallEiffel"