GoLive Update Offers Speed & Bug Fixes — Adobe has released an update to GoLive 4.0, adding performance improvements and bug fixes to the powerful Web creation tool. GoLive 4.0.1, in addition to feeling speedier overall, fixes crashes caused by a font corruption problem with Mac OS 8.6 (see "Font Manager Update 1.0" in TidBITS-491) and fixes a crash associated with using GoLive’s PDF module, among several other repairs. If you’ve previously run Apple’s Font Manager Update on your copy of GoLive 4.0, we recommend reinstalling a fresh copy of GoLive before applying the 4.0.1 update to prevent crashing the updater. The 4.0.1 update is a hefty 10 MB download and is free for registered owners of GoLive 4.0. [JLC]

<http://www.adobe.com/prodindex/golive/>

<https://tidbits.com/getbits.acgi?tbart=05493>

<http://www.adobe.com/supportservice/custsupport /LIBRARY/5a62.htm>

QuickTime 4.0.3 Update Tweaks Streaming Performance — Apple has updated QuickTime to version 4.0.3, adding new content provider links to the QuickTime Player’s Favorites drawer and fixing a handful of bugs. The maintenance update improves audio and video synchronization in live streaming events, fixes a rare crashing bug while receiving streaming content, includes QuickTime for Java 3.0.1, and resolves a problem between QuickTime VR and the Grolier Encyclopedia. If you’ve already installed QuickTime 4, running the QuickTime Updater program will cause it to connect to Apple’s servers and download the updated components. Otherwise, you can download the 380K QuickTime installer. [JLC]

<http://www.apple.com/quicktime/>

<http://til.info.apple.com/techinfo.nsf/artnum/ n31089>

Feedback on TidBITS Size Change — We’ve long had a self-imposed limit of 30,000 characters in each issue of TidBITS. In the interests of editing articles to improve their content, rather than to reduce their size, we’re considering eliminating our strict size limit. Instead, we would have an issue size goal of 30,000 characters; if an issue was several thousand characters longer, we’d edit only as much as we felt necessary to present the best possible articles. We think this will improve our content by eliminating some last minute editing mistakes, plus remove an unnecessary task from our work each week.

However, every change has a downside. The 30,000 character limit kept issues small enough to fit through old email gateways and to display in old email programs. Most modern programs can now handle large messages, but we want to judge the potential impact of this change before making it. Some people undoubtedly still use older software; the question is, how many of these programs are still in place and how heavily are they used? If you would be affected by this change or have an opinion about it, please post to the TidBITS Talk thread on the topic. [ACE]

<https://tidbits.com/getbits.acgi?tlkthrd=772>

It’s about time someone realized what we in the Mac Internet community have been saying for years. Even better, that someone is the U.S. Army. Here’s the story. It seems that on 28-Jun-99, an intruder gained illegal access to the home page of the U.S. Army and modified its contents. Organizations like the Army hate that, and on 30-Aug-99, FBI agents arrested a 19-year-old Wisconsin man for "malicious altering to a U.S. Army Web page" in connection with the incident.

<http://www.army.mil/>

<http://www.dtic.mil/armylink/news/Sep1999/ a19990901hacker.html>

The compelling aspect of this story is that as a result of the break-in, the U.S. Army has switched the machines that serve the Army’s home page from Windows NT-based PCs to Power Macintosh G3s running WebSTAR from StarNine Technologies. Christopher Unger, Web site administrator for the Army Home Page, didn’t reveal the specifics of what was done to the page, how it was done, or what the Army planned to do to prevent further intrusions, but he did say that the Army had "moved its Web sites to a more secure platform," basing the choice of the Mac OS over Windows NT on information from the W3C (World Wide Web Consortium). Using Netcraft’s "What’s that site running?" utility, I was able to verify that the Army’s main Web server is now running WebSTAR 4.0 on the Mac OS. However, other less-obvious Army Web servers linked from the main Army home page generally run either Netscape Enterprise on Solaris or Microsoft IIS on Windows NT.

<http://www.starnine.com/webstar/>

<http://www.netcraft.com/whats/? host=www.army.mil>

There’s no telling if the Army will move its secondary servers to the Mac OS to prevent them from being cracked as well, but the W3C does compliment the security of the Mac OS in its WWW Security FAQ, saying "The safest Web site is a bare-bones Macintosh running a bare-bones Web server." In information specific to WebSTAR, the W3C notes:

"As far as the security of the WebSTAR server itself goes, there is reason to think that WebSTAR is more secure than its Unix and Windows counterparts. Because the Macintosh does not have a command shell, and because it does not allow remote logins, it is reasonable to expect that the Mac is inherently more secure than the other platforms. In fact this expectation has been borne out so far: no specific security problems are known in either WebSTAR or its shareware ancestor MacHTTP."

<http://www.w3.org/Security/faq/wwwsf1.html#Q3>

<http://www.w3.org/Security/faq/wwwsf8.html#Q84>

This logic also applies to other Web servers for the Mac OS, such as Quid Pro Quo, AppleShare IP’s built-in Web server, NetPresenz, and even Personal Web Sharing.

<http://www.socialeng.com/>

<http://www.apple.com/appleshareip/>

<http://www.stairways.com/netpresenz/>

Old News — Of course, this information isn’t news to the Macintosh Internet community, where the security of the Mac OS and Macintosh Web servers has long been known. In "Macintosh Web Security Challenge Results" in TidBITS-317, Chris Kilbourn outlined the approaches used by would-be-crackers looking to take home a $10,000 prize. Then, in "The Crack A Mac Story" in TidBITS-378, Joakim Jardenberg and Christine Pamp talked about the success of the first Crack A Mac challenge. Geoff Duncan look at the motivations behind a glut of subsequent Mac OS security challenges in "The Mac Security Challenge Fad" in TidBITS-385. And finally, we reported briefly on the successful cracking of the second Crack A Mac challenge, a far more complex setup that was compromised via a long-since patched security hole (See "Cracked!" in TidBITS-393).

<https://tidbits.com/getbits.acgi?tbart=01107>

<https://tidbits.com/getbits.acgi?tbart=02166>

<https://tidbits.com/getbits.acgi?tbart=02204>

<https://tidbits.com/getbits.acgi?tbart=04093>

What’s also old news is Apple’s lack of support for the Mac OS as an operating system suitable for use with Internet servers. Since the Apple Internet Server Solution bundles disappeared years ago, Apple has barely acknowledged the reality of running Internet servers on the Mac OS, despite the many happy Mac users relying on Mac OS-based Internet servers. Even now, servers from Apple run Mac OS X Server, which is essentially Unix. There’s nothing wrong with Unix-based Internet servers, and for very high-volume sites, they’re essential. Even the performance arguments brought up against Macintosh Web servers are essentially moot now, with WebSTAR and Tenon Intersystems’ WebTen providing far more performance than most Web sites require. For the vast majority of Web sites, email servers, and FTP servers, the Mac OS and commonly available Mac OS software provide a familiar, easy-to-use solution without the fuss or security issues of Unix or Windows NT.

<http://www.tenon.com/products/webten/>

Looking forward, it’s almost inconceivable that Apple would once again put forth the Mac OS as a serious Internet server platform. Companies seldom recant a technical stance, and more important, with Mac OS X in the works, Apple doesn’t want to do anything that will reduce Mac OS X’s impact. But it remains to be seen how secure Mac OS X will be when exposed to the Internet’s crackers. With the power and flexibility of Unix at its base, Mac OS X will certainly be attractive to many classes of users – let’s hope that crackers aren’t among them.

In some circles, the term "Slashdot Effect" refers to the substantial increase in traffic a Web site receives after it is mentioned on Slashdot, a geek-oriented Web site (the name refers to the root directory on a Unix system, which can be specified as "/."). But we recently saw another kind of Slashdot Effect when one of the nerds who frequent the site spotted a vaguely worded document on Unisys’s Web site indicating that the company is now offering LZW compression licenses to Web sites that use GIF images – for a flat rate of $5,000. LZW, or Lempel-Ziv-Welch, is a fast, efficient compression algorithm used in modems, disk controllers, hard disks, compression utilities, and tape drives. Unisys owns a patent on the LZW algorithm, and since the GIF file format employs LZW compression, any software that creates GIF files requires a license from Unisys. For coverage of the original licensing furor, see "The End of the GIF-Giving Season" in TidBITS-259.

<http://www.slashdot.org/>

<http://corp2.unisys.com/LeadStory/lzw- license.html>

<https://tidbits.com/getbits.acgi?tbart=01670>

In short order, the Slashdot denizens – many of them free software advocates – had interpreted the release in the worst possible way, turning it into a Unisys plot to extort $5,000 from every site that contains GIF images, which would be pretty much all Web sites. A heated thread erupted to discuss the travesty, and a site, Burn All GIFs, appeared to combat the nefarious scheme by urging webmasters to show up at Unisys headquarters (on a day to be determined) and "burn their GIFs," however one is supposed to do that.

<http://slashdot.org/article.pl?sid=99/08/29/0722236&mode=thread>

<http://www.burnallgifs.org/>

Belay Those Lighters! The GIF-burning is all smoke and no fire. A close reading of the Unisys announcement makes clear that you need a license "[i]f you use any of the types of images specified above on your Web site that you received from an unlicensed software developer or service." In other words, if the developer of the software being used to create the GIFs has a license, the site itself does not need one. All popular GIF tools, including Photoshop, DeBabelizer, ImageReady, Fireworks, and WebPainter, are properly licensed, so the impact on most users will be nil.

In point of fact, Unisys could not claim a patent on the GIF file format itself even if it wanted to – or for that matter on any file format that contains LZW-compressed data. The patent covers the LZW algorithm: the series of steps software (or an intrepid human being with pencil and paper) must perform to compress data using the technology. A GIF file, or any LZW-compressed data, does not embody the LZW algorithm itself, only the results of the algorithm. Only software can be in violation of a software patent. If Unisys attempted to sue a Web site operator merely for including LZW-compressed files on the site, the case would be thrown out of court; it’s unsupportable under current U.S. law.

My reading of Unisys’s announcement is that they want to make it easy for Web sites that use unlicensed LZW technology to "get legal." If your site uses GIF files created by a tool that does not have a valid LZW license from Unisys, paying the licensing fee will cover your liability, no matter what. It’s unclear whether end users can be held responsible for using software that violates patents, but my guess is that this new license is aimed mostly at CGI programs, running on a Web server, that use freely available C libraries to output GIF files like real-time stock graphs.

At the time Unisys received its LZW patent, patents were good for 17 years from date of issue. This was later changed as part of the multi-national GATT (the General Agreement on Tariffs and Trade) to be 20 years from the date of first filing. That means Unisys’s LZW patent will expire in mid-2003; under the old rules, it would have expired near the end of 2002 (there was a two year gap between the initial filing and the original patent being granted). Interestingly, according to a Free Software Foundation page explaining why the FSF site does not include GIFs, IBM applied for a patent on LZW at about the same time as Unisys – and because someone was asleep at the patent office, both IBM and Unisys received patents. IBM’s runs out at about the same time as Unisys’s. The FSF page also contains the interesting tidbit that the patent does not apply to software that only decodes LZW data, so all GIF display programs are free and clear. The page is a useful overview of the patent issues involved with LZW and GIF, albeit slanted toward Richard Stallman’s slightly skewed (from the rest of us) point of view.

<http://www.gnu.ai.mit.edu/philosophy/gif.html>

It seems unlikely in the extreme that Unisys will actually conduct a sweep of all Web sites to see who’s using the company’s patented technology without permission. There are simply too many sites, and it’s impossible to tell what program created a GIF simply by examining the image (unless the software intentionally adds a comment tag providing such information). There is, in short, no way to enforce any requirement that Web sites obtain the offered license. So relax; the GIF Gestapo is not knocking on your door.

But many corporations have whole departments devoted to finding and correcting licensing issues (that is, illegal software) in the company. And most such companies have Web sites these days, many of which were built using software developed in-house. These companies may be willing to pay Unisys the $5,000 just to be safe. If only a hundred sites do, that’s a cool half-million for Unisys – and all they had to do was move a press release. Not a bad increase in shareholder value for a day’s work, which is, after all, what this flap is really about.

[Jerry Kindall is a freelance writer and contributing editor to MWJ, the Weekly Journal for Serious Macintosh Users, where this article was originally published. For more insightful Macintosh news, sign up for a free, no-obligation, three-issue trial subscription to MWJ at the journal’s Web site. For more information on Jerry’s work, visit the Web site of his company, Manual Labor.]

<http://www.gcsf.com/>

<http://www.manual.com/>

Judging from much of the email we at TidBITS receive, many Macintosh owners desperately want to provide feedback to Apple about the Mac OS, Apple’s advertising, Macintosh hardware specifications, hardware color choices, and almost anything else related to Apple. In one respect, Apple should be flattered – the fact that Macintosh users care enough to want to offer their ideas and opinions is impressive. But Apple is a huge company and has no official channel for users to pass on their feedback. The zeitgeist of the industry does filter into the company through indirect means; stories in the press, friends of Apple employees, comments from Apple dealers, the occasional transmission from outer space, and so on.

Part of the problem is simply Apple’s size. Even if there were an email address to which you could send comments (the previous attempt at this, <[email protected]>, appears defunct), it would be difficult for anyone to distribute comments to the appropriate departments, much less the proper people within those departments. Apple has too many employees and too much turnover and movement for anyone to direct feedback effectively.

As much as Apple may not have effective ways of soliciting or managing user feedback, the company does listen, at least sometimes, to Macintosh developers. Apple’s Worldwide Developers Conference (WWDC) offers one forum for that, but Apple’s goal at WWDC is as much to evangelize Apple technologies as to accept feedback on those technologies. But there is another way.

Bash Apple — A long time ago at the MacHack developers conference, there came to be this event called "Bash Apple." As the oral tradition relates, a bunch of developers were sitting around at MacHack bashing on Apple for some stupidity or another. After a bit, one person in the group, a new Apple employee named Jordan Mattson, said, "Look, I’m a nobody at Apple, but I’ll write all this stuff down and when I get back, I’ll see if I can find someone appropriate to tell it to. No promises, no guarantees." And he did, though it was unclear if his efforts had any effect back at Apple. That was immaterial, though, because the developers had had a chance to vent at someone from Apple and, feeling much better, they stayed up the rest of the night writing hacks so useless they produced awe and admiration among the other developers at MacHack (for this year’s hack contest details, see "The MacHack Hack Contest 1999" in TidBITS-488).

<http://www.machack.com/>

<https://tidbits.com/getbits.acgi?tbart=05470>

The developers so enjoyed having someone at Apple to vent to that they did the same thing the next year, and the year after that. These sessions became formalized under the rubric of "Bash Apple" and grew to include numerous Apple engineers, many of whom had been independent developers in previous years. Jordan even became immortalized in the MacHack argot in the phrase "It’s Jordan’s fault," and though of course essentially none of Apple’s problems actually were Jordan’s fault, he continued to play. The sessions continued to provide a forum for frustrated developers to let off steam, but equally important, they gave Apple folks ammunition to take back and say, "Look, it’s not just me saying this – 200 developers are also ticked off about it."

Apple Handshake 1999 — In recent years, Bash Apple (saddled this year with the horrible moniker "Apple Handshake Session") has evolved to the point where a senior Apple person fields questions and criticisms from developers, backed up by various other Apple folks in attendance. This past MacHack in June (see "MacHack: The Ultimate Macintosh Event" in TidBITS-487) was no exception, with Apple’s vice president of Mac OS engineering, Steve Glass, fielding most questions with assistance from other Apple employees. For instance, in response to a question regarding whether Apple planned to release any more Appearance themes, Apple evangelist Tim Holmes stated unequivocally, "As I’ve said numerous times in numerous places, there is no future for themes. None, nada, zip, zero," and sat down, only to bounce to his feet a second later to reiterate the more carefully phrased, and officially blessed version, "Apple Computer has no plans to offer additional themes, either now or in the future, but the company reserves the right to change its mind, blah, blah, blah."

<https://tidbits.com/getbits.acgi?tbart=05463>

Every now and then during the session, important bits of information either became public or were emphasized. For example, Steve Glass was adamant about how he was clamping down on shipping independent components of the Mac OS separately from full Mac OS releases. He felt that shipping different versions of Open Transport, for instance, separately from the Mac OS itself made for configuration and testing nightmares; plus it could cause problems for users who were mixing and matching components in combinations that Apple hadn’t tested. In addition, in response to another query, Tim Holmes made the important point that although Mac OS 9 will have multiple user support in the sense of both individual and shared preferences, the feature is aimed at home and small office users, not large installations with many users.

For the most part, though, I got the impression that developers weren’t entirely happy with the session, perhaps because even though they were talking with an Apple VP, he wasn’t able to be concrete about much. Steve Glass could and did respond to issues surrounding Mac OS 8.x, since that’s his team. He was also able to offer standard industry platitudes about concerns that either were outside his field (Mac OS X, hardware) or that undoubtedly are not yet even decided at Apple. Trade-offs, resource allocation, ship time, investigating the issue now… all of these meaningless phrases came forth at one time or another. But what should he have said? The problem with those industry platitudes is that they’re often true – there are trade-offs between offering individual component releases versus unified system releases; Apple does have to pay attention to how they allocate engineering resources to future projects versus maintaining backward compatibility to System 7.x; and so on. In short, Steve Glass was incapable, through no fault of his own, to offer any sort of official assurances about how, for example, Steve Jobs may have traded his soul and a total lack of commitment for Java 2 for Apple’s recovery. Even if Steve Glass knew that Apple had decided to ignore Java 2, he wouldn’t break the news at MacHack.

Top Ten Developer Issues — In the last few years, the organizers of MacHack decided to create a list of the top ten developer issues, rightly believing that it would be easier for the press to write about than a two-hour Q&A session. The list, voted on by the gathered attendees, was an attempt to collect and prioritize the concerns held by the Macintosh development community. Here then is a slightly edited version of this year’s list, with links to relevant TidBITS articles where possible.

1) MacsBug support: The MacsBug debugger is a critical Macintosh development tool. Developers need Apple to dedicate engineering resources to this tool and to new ones like it. If you’re interested in what it can do for you, check out Geoff Duncan’s three-part series on MacsBug.

<https://tidbits.com/getbits.acgi?tbser=1057>

2) Greater stability and easier debugging: Developers need increased reliability and greater ease in debugging software on Mac OS. Apple has done a good job of improving stability since System 7, but more stability is always welcome.

3) Mac OS X look and feel: Developers want Mac OS X to look like a Macintosh, not like a Unix workstation. We touched on this topic with "Mac OS X or Mac OS NeXT?" in TidBITS-483.

<https://tidbits.com/getbits.acgi?tbart=05415>

4) Documentation improvements: Developers need technical documentation to be available sooner, and to be more complete, accurate, and accessible. Although our "Death of Documentation" article focused on user documentation, many of the issues are similar.

<https://tidbits.com/getbits.acgi?tbart=04865>

5) Better mouse and keyboard: Developers believe that high-end Macs need a better standard mouse and keyboard with a full set of keys. Smaller is not always better with keyboards. Amazingly, the new Power Macintosh G4 does not include an improved keyboard and mouse.

6) Machine differentiation for support needs: Developers need Macs to be more clearly marked because support staffers need to identify users’ machines easily. I raised this issue at the session and was gratified to see that developers shared my concern. See "Macintosh Model Implosion: What’s in a Name?" in TidBITS-485.

<https://tidbits.com/getbits.acgi?tbart=05436>

7) Extending the OS: The "patching" mechanism for extending the Mac OS in unplanned ways is important for many reasons, including providing disability access. Developers need a similar mechanism in Mac OS X.

8) Cleaning up Mac OS: Developers believe that Mac OS would benefit from being further cleaned up. Removing vestigial code from the OS would improve memory footprint and performance, including faster booting.

9) Java: Developers need a clear direction on Java. A commitment from Apple regarding support for Java and Java 2 would be greatly beneficial.

10) Release discontinued development tools as open source: Many developers still rely on tools that Apple no longer supports, like MPW. Releasing such tools as open source would allow developers to maintain and improve the tools they find essential.

Tracking the Feedback — One aspect of this year’s Bash Apple session that was missing was a recap of the previous year’s Top 10 list. It’s instructive to see both how Apple has responded to items on the list and how developers’ opinions of what’s important changes from year to year. I’ll be sure to see how this year’s list fares at MacHack 2000, by which time we might have various new Macs, Mac OS X, and inconceivable policy changes from Apple.