LWN.net Weekly Edition for June 16, 2005

A few notes on the OpenSolaris release

Sun has followed through on its promises, and placed the bulk of its Solaris source on OpenSolaris.org. Regardless of whether you intend to do anything with this code, or with Solaris in general, this release is a significant event. Observers have noted for years that Linux was likely to bring about the end of proprietary Unix systems. With the opening of Solaris, that prediction has come to pass. While some proprietary Unix offerings still exist, Solaris was the largest and most significant of them. With Solaris in the open, the proprietary Unix era is done.

OpenSolaris is not a small download. Anybody not already running Solaris will have to bootstrap themselves with a binary distribution. Then there's the core source tarball, compiler, and "closed binaries" packages. Throw in the BFU package to get the latest stuff: "BFU" is said to stand for "blindingly fast upgrade," but other interpretations of the acronym are certainly possible. Sun's site requires registration before it will allow you to download files; interestingly, however, it also makes torrents and a (no-registration) third-party site available.

Note that, if you simply want to wander around in the source code, it is not necessary to download the whole thing. Sun has provided a web-based source browser which makes digging through the code easy.

The "closed binary" package is said to be a temporary thing. It comes with a relatively reasonable "free beer" license, though it does require that you only run the binaries on an OpenSolaris system. The list of binary-only programs is somewhat strange: it includes od, patch, rdist, sed, ssh, telnet, and kernel drivers for hardware like the Intel e1000 network adaptor - stuff which, seemingly, should be free. The Sun compilers come with a rather more restrictive license; users are required to be "a participant of the OpenSolaris community," may not publish benchmark results, and cannot modify the "java technology" included with the software. Also:

So it is, perhaps, not surprising that even developers within Sun are interested in using free compilers with OpenSolaris. An effort to Build OpenSolaris with GCC is apparently well advanced, so the need for the proprietary Sun compilers should go away soon. Interesting, according to one developer, much of the pain of porting to gcc was caused by gcc's insistence on putting constant data into read-only memory. OpenSolaris, it seems, did a lot of writing to "constant" strings.

One of the more significant omissions from OpenSolaris currently is an X server. Two servers actually run on Solaris: X.org and the venerable Xsun server. The plan is, apparently, to move toward releasing a version of the X.org server, but that has not happened yet.

Much has been said about Sun's choice of the CDDL as the license for the Solaris source code; there is not much to add at this time. It is worth noting, though, that if you choose to contribute code to OpenSolaris, you not only have to contribute it under the CDDL, but you must sign Sun's contributor agreement [PDF] as well. That agreement has some obvious things, like patent licensing. It also, however, requires you to give Sun an ownership stake in your code:

Sun, in other words, can take your code and make it into a proprietary product, or release it under any other license that it sees fit. It doesn't seem to have occurred to Sun that terms like this might reduce the size of the "vibrant developer community" that it wishes to create.

The CDDL license will prevent any code in the Solaris kernel from finding its way into Linux - we can only hope that nobody tries to sneak some in anyway. It is amusing to note, however, that the first OpenSolaris-inspired kernel patch has already been posted; it is a small optimization to how SYSV semaphores work. With luck, good ideas will flow from the OpenSolaris kernel to Linux (and vice versa), even if the code itself cannot.

Large dumps of corporate code are always a little hard for the community to digest. So it may be some time before OpenSolaris grows into a true free software project with active user and developer communities. It will probably get there: the code is good enough, and there are enough established Solaris users now, to give OpenSolaris some momentum. Whether OpenSolaris can develop into a truly successful project over the long term remains to be seen, however. There is some good stuff there, but it may turn out to be too little, too late from a company which is still struggling to understand what free software is about.

Comments (10 posted)

What is firefox prefetching?

One reason many of us insist on using free software is its relative lack of surprises. Free programs rarely contain features which cause them to behave in a way which is contrary to the interests of their users. Unlike many proprietary programs, free applications tend not to phone home without permission, unnecessarily restrict what their users can do, or perform unexpected operations behind users' backs. As Lauren Weinstein recently discovered, however, the Firefox browser can be made to behave in a way which is surprising indeed - and Google, in the name of faster browsing, is taking advantage of that behavior.

In particular, Firefox will, at times, "prefetch" the contents of a web page which it thinks you might want to see soon. If a page is marked as being the "next" page in a series, Firefox, by default, will prefetch that page's contents. (And, yes, for those who have asked for "next" tags for the LWN Weekly Edition, it will happen when we get a chance). When the user hits the link for the next page, it will already be resident in the Firefox cache, and will display more quickly.

The interesting thing is that Firefox can be told explicitly to prefetch pages; all it takes is a tag like:

    <link rel="prefetch" href="URL">

Google will, if it decides that you should be feeling lucky, add such a tag to the first in a series of search results, causing that first result to be prefetched. Among other things, this prefetch can cause cookies to be set in the browser even though the person ostensibly in control of the browser never decides to visit the site. An easy experiment will verify this behavior: turn on cookie notifications, then search for a term with a relatively obvious top result - Lauren used "soundbite." The result will be a screen somewhat like that shown on the right: the soundbite.com web server is attempting to set cookies, even though your editor never clicked on a link which would lead to that site.

Prefetching in this way can lead to a number of undesirable consequences: unwanted cookies, bandwidth use, etc. More seriously, it could lead to accesses to truly unwanted sites: stumbling into non-work-safe sites is already too easy, without one's browser deciding to fetch additional pages from arbitrary servers with no user participation. Should an unpleasant Firefox security hole be discovered, prefetching could, for the right sort of vulnerability, be exploited to compromise systems. That would be an unwelcome sort of surprise.

Google's use of prefetching in this way is unfortunate; it seems certain to lead to trouble for somebody, somewhere down the line. The real problem, however, is with Firefox, which is shipped with prefetching turned on. There is no indication, anywhere in the preference screens, that an option controlling prefetching even exists. Anybody wanting to disable prefetching will have to edit their prefs.js file, or tweak the network.prefetch-next option on the about:config screen. Turning off prefetch in this way will slow down some page loads, but, for many users, the extra delay will be worth it.

[As a postscript, your editor can't help but poke at a bit of poor user interface design in Firefox. An attempt to pull up a long page yielded this dialog, asking: "A script on this page is causing mozilla to run slowly... Do you want to abort the script?" The two buttons are marked "Cancel" and "OK". It is nice that Firefox does not entirely lose control in such situations. But does "Cancel" kill the script, or let it run?]

Comments (13 posted)

A foundation for Zope

Back in 1998, LWN got one of its first scoops by reporting that a company called Digital Creations was planning to release its well-respected Principia product under an open source license. Even more interestingly, this release had been advocated by the company's venture capital backers. Over the years, both the software and the company were renamed "Zope," and the Zope platform has been used for many applications, including the popular Plone framework.

Zope Corporation has, throughout, retained copyrights for - and control over - the Zope platform. Recently, however, the company announced that a foundation would be created for Zope. This foundation will be given the copyrights to the code and the right to the Zope trademark; its task will be to ensure the future success of Zope independently from Zope Corporation. We talked briefly with Zope Corp. head Rob Page about this change.

Why have you decided to make this move at this time?

Were there any particular problems or pressures which led to the creation of the foundation?

How many engineers do you have working on Zope now? Do you expect that to change as Zope moves over to the foundation?

What sort of governance structure do you see for the foundation?

Will Zope Corp. retain any sort of veto power over changes it doesn't like?

How will you ensure that the development of Zope continues to meet your business needs?

How will the foundation be funded?

What's the status of Zope 3? There does not appear to have been a Zope X3 release since last November; has development stalled?

How's business? Is the services model working for you?

We thank Mr. Page for taking the time to answer our questions.

Comments (3 posted)