Slashdot Mirror

Roanld Bultje writes: "According to this article on LinuxToday, Gnome 1.4 has just been released! Gnome and all other required packages can be downloaded from Gnome's FTP or a mirror. Medusa seems to have been removed from the final release due to some bugs that were found recently. Let's hope that this new release puts Gnome next to KDE's 2.x-version." Download.gnome.org will pick a mirror site for you automagically.

Roanld Bultje writes: "According to this article on LinuxToday, Gnome 1.4 has just been released! Gnome and all other required packages can be downloaded from Gnome's FTP or a mirror. Medusa seems to have been removed from the final release due to some bugs that were found recently. Let's hope that this new release puts Gnome next to KDE's 2.x-version." Download.gnome.org will pick a mirror site for you automagically.

GlockaDe writes: "FreeBSD is now a supported platform for the GNOME project. This means that now, new GNOME releases will not ship unless they successfully build and run on FreeBSD. The actual note is buried in these minutes."

Maciej Stachowiak writes: "The GNOME 1.4 Release Team is proud to announce GNOME 1.4 Beta 2 "Hit Me Baby, One More Time". This is only a beta and there may be problems with compiling and running. However, if you are adventurous and would like to help with testing, get it from your favorite GNOME mirror site in /pub/gnome/stable/betas/gnome-1.4beta2. We would also like to announce the GNOME Fifth Toe 1.4 Beta 2 release, a collection of additional packages that are not part of the core desktop but designed to work well with GNOME. This should also be available on gnome mirrors in /pub/gnome/stable/betas/gnome-fifth-toe-1.4beta2. Bug reports for most packages should go in one of the following, depending on the module: GNOME Bugzilla, Eazel Bugzilla or Ximian Bugzilla."

Maciej Stachowiak writes: "The GNOME 1.4 Release Team is proud to announce GNOME 1.4 Beta 2 "Hit Me Baby, One More Time". This is only a beta and there may be problems with compiling and running. However, if you are adventurous and would like to help with testing, get it from your favorite GNOME mirror site in /pub/gnome/stable/betas/gnome-1.4beta2. We would also like to announce the GNOME Fifth Toe 1.4 Beta 2 release, a collection of additional packages that are not part of the core desktop but designed to work well with GNOME. This should also be available on gnome mirrors in /pub/gnome/stable/betas/gnome-fifth-toe-1.4beta2. Bug reports for most packages should go in one of the following, depending on the module: GNOME Bugzilla, Eazel Bugzilla or Ximian Bugzilla."

Navarre asks: "While I really like the GNOME desktop, and it's good to see that it's being taken up by HP and Sun, I noticed that it's a little weak on manpages. While I know that GNU prefers Info pages, I personally hate them and greatly prefer man. It's bad enough already when half the GNU apps I use refuse to give decent manpages in favour of info. Now GNOME includes help in HTML format, but no manpages that I've seen. Are we now at a point where we cannot survive on a Unix box without some kind of web browser? What happened to that great common-demoninator of a terminal, troff and a pager? The minimum bloat on Linux continues to increase, and I question if it's a good thing. How much trouble is it to include a manpage anyway?" I'm all for better documentation in formats that have richer functionality than troff, but let's not forget that man pages have worked for years and is still standard on just about every Unix system out there. I'm not as much of a fan of GNU Info, but that's probably more due to my familiarity with man than anything else. How do you all feel? Should we retire man for info or HTML (you can always use lynx)? Or do you think man pages still have a place on modern Unix systems?

On a side note, I'm sure maintainers who currently do not have man pages wouldn't mind it if someone out there would take the time to convert whatever has been provided into proper man pages.

The folks at GNOME have released GNOME 1.4 beta 1, code name "oops, we did it again". You can find the packages at your favorite mirror. If you're testing, then please fill the bug reports in the "right place" (either Eazel's bugzilla or Ximian Bugzilla). Good work, guys.

Ur@eus writes "Want to see how nice your GNOME desktop and Mozilla browser will look anti-aliased? We have just posted screenshots and a non-stable patch on Gnotices" Here's evolution and mozilla displaying slashdot. Neither are perfect, but its still exciting to see progress.

starseeker writes: "It looks like the financial picture is not good for Applix - "the company intends to report VistaSource as a discontinued operation in its audited financial statements." The financial report is online. What happens to Applixware Office now?" For the backstory: Vistasource is the division of Applix - we've talked about this before. Still with the various K* options, the G* options, and OpenOffice the competition is tough - not to mention Abiword and all the others.

Rayban writes: "Just noticed on news.gnome.org that the Linux framebuffer support for Gtk+ is now in CVS. This means that you can now write a quick Gnome app that doesn't require X at all! Imagine a Gtk+-based distro installation that can run solely off the framebuffer! No more VESA hack and a significant disk space savings - maybe even a Gtk+-based bootloader? The screenshots are here, here and here." Obviously the screenshots aren't very special, but I'm having no problem thinking of interesting, useful tasks for this.

brandonj writes "Looks like the new movie, Antitrust, will be using GNOME as their desktop in the movie. Here are screenshots and the Antitrust movie homepage is here. The movie will in theaters January 12." The website has a little bio for Maddog and Miguel.

Charles Northrup (followed by many others) writes: "After a long battle with the POSIX.DLL from AT&T's U/WIN, we finally have recompiled over 4 million lines of code for the Gnome Desktop running on Windows. We had to change just under 100 lines to do this. Amazingly, the recompilation of Gnome only took 1.5 weeks. Then we had to spend the next 3 months working on the 47,000 line POSIX.DLL to get Gnome working." Here are some screenshots of this odd hybrid, pointed to by reader dimator. (Northrup invites e-mailed comments and questions, too.) And jumbolo points out the discussion about this at The GNOME Project's Gnotices site.

Charles Northrup (followed by many others) writes: "After a long battle with the POSIX.DLL from AT&T's U/WIN, we finally have recompiled over 4 million lines of code for the Gnome Desktop running on Windows. We had to change just under 100 lines to do this. Amazingly, the recompilation of Gnome only took 1.5 weeks. Then we had to spend the next 3 months working on the 47,000 line POSIX.DLL to get Gnome working." Here are some screenshots of this odd hybrid, pointed to by reader dimator. (Northrup invites e-mailed comments and questions, too.) And jumbolo points out the discussion about this at The GNOME Project's Gnotices site.

bratislav writes: "Eazel just released the 2nd Preview Release for the upcoming GNOME filemanager, browser and general-nice-app Nautilus. This new release comes with additional features, improved usability and a first look at Eazel Services. " The integrated network file system stuff is interesting.

Motor writes "The final 33 candidates for election to the GNOME foundation have been announced." It looks like a great list of people.

dclatfel writes "Just wanted to let everyone know that the latest beta of Mandrake for Intel is up - 7.2 Beta - and it's called Ulysses. (Now where is that Golden Fleece?)" They've got notes regarding it as well - KDE 2 Beta 4, and Gnome 1.2, as well as XFree86 4.01 as the default X server.

With a planned move to San Francisco next summer, last week saw San Jose's last Linux World Expo, at least for now. The future as always is stubbornly uncertain, but it's impressive that the serendipitous combination of Free tools (from GNU) and a Free kernel (from Linus) has inspired enough interest and prosperity to excite a larger group of people each year. If you've not had the chance to attend one of these expositions, we hope this article will give you a flavor of what it's like. Note: Here are a few pictures from the floor (Day 1 & Day 2) contributed by Sensei^); do you have any cool shots to link to in comments?

First, the prelude: If you've worked on the pre-show aspects of anything from a high-school play to a LAN party, you know all those booths, displays, people and computers don't materialize by themselves. For several days before the show floor opened on Tuesday, forklift crews zipped cargos of wooden, fiberglass, plastic, aluminum and steel cases from moving trucks to exhibit spaces. These contained banners, snap-together modules, computers, lighted signs -- and Yes, more gratis logo-imprinted toys than you can wave a TuxTops LED light at.

Spiderwebs of CAT-5 and electric cord (run beneath the show floor) sprouted from the centerpoints of many booths, with strands for each computer to be connected to the Net during the show. Rolls of padding and carpet came next, then the slow assembly of display booths. These ranged from no-nonsense fabric partitions that housed companies like TuxTops and Sendmail (and legions of volunteers from PerlMonks, the Simple End User Linux project, Flightgear, and many others), to elaborate constructions with motorized signs, projected lasers and huge illuminated logos. Note: Slashdot (the site) was put together last week mostly from the comfy chairs of the PerlMonks booth.

The "C" (as in conference) part of LWCE got started on Monday, and for the days that followed, attendees got instruction -- on everything from Linux security to evangelizing Free software to their bosses-- in half-day doses. Meanwhile, the setup work continued into the wee hours, as exhibitors raced the clock to make sure that at least their signs, if not their networks, were up for the next day. And at the OSDN booth (home of the red-carpeted Slashdot stage and beanbags), prep work included stacking thousands of boxed distributions of Debian, and attempted to pawn a few copies off on every passer by.

Tuesday morning, at a shade before 10:00, visitors willing to miss Michael Dell's keynote began to stream into the halls, on a quest to find new distros, old friends, and swag. It's amazing what companies will give away in order to snag a little nook in your brain. Besides the usual trinkets (keychains, T-shirts, stickers) and the distributions that a Linux show would be empty without, booth visitors were handed everything from knives (Sendmail) to cute monkeys (Helixcode) to embarrassing pictures of themselves (BSDi), as well as too many toys with embedded LEDs to bother counting. Rather than a full swag accounting (which would only annoy those unable to attend), let me just say that you won't hurt for toys when the chance presents itself. (CT:I just wanted to note that VA gave away 2300 pounds of shrink-wrapped boxed Debian. Like 5000 copies. It was beautiful)

The things on display around the LWCE floor were more interesting than the toys, though. (And unlike a museum, most were available for hands-on demonstration, not hidden behind glass.) Indrema showed a prototype player (not in the sleek black box you see on their Web site, but still sporting that cool blue LED) hooked up to a HDTV display, playing a very fast game of Quake. (CT:Actually it was an HDTV demo, they promised the real deal will be less vaporous before I have children) In the Intel booth were server clusters populated with quad Itanium processors, demonstrating failover when one system was rudely but intentionally shut down. The amazing-like-emacs-is-amazing Flightgear project showed a really nice looking demo which is enough incentive by itself to invest in a better video card for my system so I can play with it.

Both Helixcode and Eazel made their first LWCE appearance this time around, exciting for those filling their anti-FUD cannon for the perpetual "Linux is tough to use" argument. The Eazel folks showing off Nautilus seemed to be all but cackling as they showed off the smoothness of the zooming information available for documents and the cool music-integration abilities it contains. It would have been cool if they'd had some sample CDs, but they promise a developers' release soon. (CT:They also promised .deb's, but I'll believe it when I see it. The UI was awesome, I just hope that someone hacks in something like the GUI command line in EFM)

Considering that Sun was showing off the GNOME desktop on Solaris (hinting at its inclusion in stock Solaris systems sometime very soon, too) and that the GNOME project itself was not only in one of the small booths against the wall but the subject of a big announcement -- about the advent of the GNOME Foundation -- it looks it's showing up everywhere. Happily, there seems to be no shortage of room for window managers right now: the KDE folks were also there not only in their own booth, but showing up in software demonstrations all over the floor, as SuSE, Caldera and others demonstrated the very slick KDE 2.0. (Can't we all just get along, anyhow?)

SuSE, by the way, was the only distributor I noticed showing off Linux on Apple hardware, and their current distro was sweet and fast on a G4. Beyond the curious lack of Apples, and the obvious ubiquity of x86 machines, there were machines based on everything from microcontrollers to StrongArm, MIPS, Alpha, Itanium ... even the IBM S/390s which have gotten attention for the ridiculous number of concurrent Linux systems they can support.

For all the cool hardware and cusp-of-reality, bleeding-edge distros, it's interesting that the announcement which seemed to generate the most buzz of the entire show was the long-awaited release of Debian's Potato. Considering the reputation that Debian has for intelligent upgrading, stability, and diligence in guarding the license of the software which makes it up, it's not as surprising as it might otherwise be that Debian's new release made people sit up a bit more than the newest offerings from the large commercial distros.

(CT: Also extremely impressive was the Pocket Linux booth, where they actually had iPaq's running Linux. The first dude that demoed the box to me was very nice, but what I really wanted to see was X11 running on it ... oddly enough, I encountered one of his cohorts in the bar later that night who showed it to me: X, xeyes, xterm, and twm running on an iPaq. When they get the wireless action going on these things I'm totally there ... I'll just need to hack minimalist interfaces onto pronto and my MP3 player software and use the thing as a portable X terminal on the local 802.11 wireless lan. Yum.)

Oh, and there were people on the floor as well -- close to 20,000, all told. I met some folks I've known previously only through IRC, and quite a few I might never have otherwise encountered.

It's interesting to see in the space of a few hours many of the smart people who you may experience vicariously through writings, speeches, code, art or IRC chatter -- and it also belies the idea that software celebrities of the Free software world are becoming celebrities of the traditional variety, since everyone from ESR to Jon "maddog" Hall (and Linus himself) are willing to talk to anyone who catches up with them long enough to say hello. The atmosphere (especially outside the mondo corporate-castle booths) is mellow and accomodating, and suprisingly so even within most of those castles. There were undoubtably personality conflicts at work, but it seems like most people have the good grace to deal nicely with each other for these few days at least.

At the close of each day, people shuffle out to drop laptops, T-shirts and bags of stuff at their hotels, then thousands of them show up to parties sponsored by companies from AMD to Red hat to VA, which are full-blown events in themselves. Mandrake's party, for instance, had go-go dancers in cages, which may be the most bacchanal thing I have ever witnessed. Ironically, though, many coders couldn't attend even events sponsored by their own companies, or thrown in the honor of their projects, because of strict carding policies. Wouldn't a chem-free party or two be a thoughtful way to include people?

(CT: This has been a consistent problem for several years. Although I know at "Someones" party (no names *grin*) they weren't carding, and I recieved many a happy note from fellow attendees proclaiming that they were able to get in. The parties themselves weren't bad: the OSDN/Potato release party was fun, with San & Zak spinning the tunes (next time we'll force CowboyNeal to scratch for us under threat of death). They had 2 buildings: one was a pool hall, where we tormented The Pope for nearly an hour, carefully distracting him, and then returning his balls to the table. He never noticed. We also met up with Nitrozac from After Y2k, and I snuck accross the street to the Eazel party for a bit, and got to meet Dave "You might remember me from cheat codes in some first person shooter" Taylor.) Attendeees mostly filed out for flights or drives home Thursday and Friday, but some are still in San Jose for the Intel Developers Conference, or otherwise enjoying the Northern California weather. It's a strange familiarity that many of them will feel when the next big conference rolls around, to see many of the same fellow attendees or workers -- of course, by the time the next big conference happens, perhaps we'll all be too excited by the release of 2.4 to notice.

The ongoing debate between KDE and GNOME has calmed down a lot in the last year as each system became stable and usable. Recent announcements regarding the Gnome Foundation has caused some tension (ranging from words to DNS hijaacking). Kurt Granroth, a KDE Core Team Member, and the KDE US Press Rep has submitted his opinions on the subject, are in some cases very good points, and in other cases extremely inflammatory, but in both cases, worth reading.

The following was written by Slashdot Reader and KDE Core Team Member, Kurt Granroth

One developers Opinion of Sun + GNOME

Recently, Sun and HP (but mostly Sun) announced that they will be using Gnome as their default desktop. As a member of the KDE Core Team and as a US press-rep, announcement, I have been asked more then a few times what KDE thinks of this. I have also been asked if KDE user should be worried about the future of KDE now. I've given a rough idea of what "KDE thinks" to those journalists.. but the answer must be pretty generic since KDE is too distributed and diverse to permit me to speak for everybody.

But the wishy-washy answer that I am forced to give doesn't mean that I don't have strong *personal* opinions on the matter -- I do. So I'd like to take this time to offer a few of them for your enjoyment.

I look at the Sun announcement and I try to imagine how it can effect the KDE project. Let's look at the absolute *worst* case situation (from our point of view). Say Sun and HP contribute a significant amount of top-notch programmers towards the Gnome project and as a result, they overtake us. Perhaps for the first time, Gnome is better designed, easier to program for, easier to use, and more stable then KDE. Meanwhile, with the momentum gained by it being the "commercial Unix standard", more and more vendors use Gnome in porting their apps without giving KDE a second thought. Maybe as a result, even "Joe Hacker" in his dorm room might not want to work with KDE.

That's the "worst" case. But say, even if that *did* become true (doubtful, see below), it still wouldn't take away from the fact that KDE is very well designed, incredibly easy to program for, intuitively easy to use and rock solid stable. We have managed to attract hundreds of developers and millions of users to KDE and we will continue to attract the numbers after words. Remember, even if Gnome does become a great desktop, that doesn't mean that KDE will stop being a great desktop. Put another way, KDE will always be around and it will always be a worthwhile desktop to use and platform to develop on.

But let's back-pedal just a bit. I personally find the above scenario *incredibly* unlikely. It has never been shown that throwing more developers on the project will guarantee that the project will succeed, and you can show that it often makes no difference at all. Sun may have a lot of developers, but it remains to be seen if it will matter.

I have reason to be skeptical. Let's not forget just how the backers of the Open Group/Motif and CDE were. That's right -- Sun and HP. Two large companies with all their resources thrown at this that couldn't compete with *either* Gnome or KDE. The Sun website talks glowingly of all the really cool things they will do with Gnome... but those with a memory (and a web browser pointed towards the Open Group's website) will remember that Sun said pretty much the same thing for Motif/CDE.. and look where that went.

No, Sun's developer resources don't worry me in the slightest. We have already shown that we can take them on and win convincingly. I don't see that they will magically change anytime soon.

I do worry a *little* bit more about the PR aspects of this, though. There will be a temptation among the less-dedicated journalists to say that now that Sun and HP and RedHat all favor Gnome, then it must be a standard for Unices. After all, everybody knows that Linux *is* RedHat, right? I am already seeing mentions of this and as people jump on the bandwagon, we'll likely see it even more.

This may have nothing to do with any kind of reality, though. Already, for every new Solaris or HP workstation, there are likely several computers running Linux. Looking at the demographics of all the Linux distributions worldwide, we see that KDE focused distributions are still the norm. All in all, there are likely a LOT more workstations running KDE then there are running something else.

This somehow brings me to the another question that has been frequently asked: Will KDE ever have a corporate-backed "foundation" deciding it's future? While I'm not arrogant enough to think I can guarantee what the future will hold, I am still reasonably secure in saying that pigs will probably fly first. A board like that flies square in the face of everything that the KDE project stands for.

KDE is, has been, and always be governed and managed by those *developers* that actually do the work on it. Working code is what matter, not your market capitalization. Commercial entities may sponsor development on various aspects of KDE, but they will never be allowed to decide what KDE will become. KDE is a desktop "by the people and for the people" and if we were to prostitute ourselves to big-money for the chance of being a media-recognized standard, we would be stomping on all the people that have supported, developed, and used KDE throughout the years. We can honestly say to all developers that if you contribute good code to KDE, we will welcome it and assure you that it will never be subject to the whims and fancies of a company under the gun from shareholders. Your code will be judged purely on it's merits. More to the point, your contribution will make a difference -- it will *matter*.

I do find it ironic, though, that it is *Gnome* taking this step. Could anybody have possibly imagined this when Gnome started? Weren't they the "hacker desktop"? Didn't they have all the "desktop for the people" principles? Hmm... times change, I guess.

But back to KDE and the possibility of a great Gnome. I get the feeling that most of the people that are comparing Gnome and KDE are doing so with current Gnome and KDE 1.1.2 (or less). Even though a version of KDE that *old* still compares favorably, it's a pale shadow to the upcoming KDE 2.0. A comparison between current Gnome and current KDE (in my opinion, of course), shows KDE really shining. I *strongly* urge everybody to check out 2.0 before jumping to any kind of conclusion -- it is a truly kick-ass desktop with by far the best development architecture out there.

So I'll end this longish, partially incoherent ramble with this disclaimer: These are all my personal (largely un-filtered) opinions on these matters. They *may* reflect the views of other KDE developers, but there is no possible way I'm going to be presumptuous enough to claim that they *do*. I may be a little bit pro-KDE in thinking it is superior to Gnome, but I still have the utmost respect for the Gnome developers themselves. I've met a number of hackers -- both "free-agent" ones and HelixCode/Eazel/RedHat paid ones -- and all have demonstrated immense talent and a genuine hacker mentality. Please don't take any of what I said as a attack on *any* person or persons.

Spasemunki writes: "The NYTimes has a piece today on an agreement reached among I.B.M., Compaq, Hewlett-Packard, Sun Microsystems and several other developers to create the Gnome Foundation, a developer consortium that will undertake, among other things, the creation of a standardized desktop interface for Linux, and a suite of productivity programs designed to compete with MS office. As the name might imply, their efforts will center around the Gnome desktop manager, with Sun moving to adopt Gnome as the GUI for Solaris. Looks like some big names are getting interested in putting Linux on the desktop."

A couple people wrote in regarding the ZD article talking about Gnome taking the battle to Windows. Having talked with Nat Friedman ^[?] and Miguel de Icaza ^[?] , I can definitely say that is their intent - and with how good both Gnome and KDE look, Windows should be getting some serious desktop competition.

The above is a title of the talk that Miguel de Icaza of Gnome and now Helix Code fame gave at OLS concerning the look and feel of the UNIXs. From what I've heard from attendants the talk was great - and now you too, in the privacy of your own home/cube/lean-to/car can read it.

realberen writes: "Visual Python 0.1 is released. Quoting the Web site: Visual Python, at its current stage of development, is a set of components aimed at GNOME and KDE application developers to enable them to easily add scripting capabilities to their applications. Ah, how I love Python! :)" Does this neatly counteract the argument that MS Office applications are necessary for complex, scripted integration (via Visual Basic)?

psycona asks: "This may seem kind of a nonsensical question, but it has been bugging me for some time now. When does a window manager become a desktop environment? Where's the point of transition? I've been a big fan of Window Maker for some time now, and here's the thing; it has wmfinder, FSViewer and a few other file managers, it has postilion and Aileron and probably other email clients, it has a ton of dockapps to do most desktop, filesystem, LAN, ppp etc. monitoring and even admin work and gawdknowswhatelse. It even has scripts to change screen resolution and colour on the fly. So can it start calling itself a desktop environment like kde,gnome,cde and xfce? And if not, what else is needed?" A simple answer might be: 'when it does more than manage windows', but that would describe most of our current crop WMs, wouldn't it?

tjgoodwin asks: "I'm the SysAdmin in an astronomy department. Our currently supported mail user agent is pine ^[?] , but I'm looking at alternatives. I'm particularly interested in strong support for qmail's maildirs. I need to support at least one text-based UA: mutt ^[?] does what I need with maildirs, but is it really suitable for a user base, many of whom are new to Unix? I'm also considering graphical UAs, preferably gnome-based. I've failed to find any useful comparison information (the UNIX Email Software Survey FAQ is seriously out of date). Any pointers?"

Well, those wacky Gnome boys have gone and done it again - you can grab Gnome 1.2.0 from the FTP site. Nat e-mailed me last night to say that it was coming out. As well as the above distro-friendly link, we've got a link for the stable sources ftp site.Update: 05/25 12:25 by H :Hey, I got e-mail from the Gnome folks again - they're going to update the mirrors and everything in half an hour (9 a.m. EDT), so hold off until then on downloading.Update: 05/25 02:12 by H : Check out HelixCode for an update on the release.

Skipping, hopping (and bumbling amd wheezing) toward inevitable perfection, we're pleased to bring you another handful of updates, re-instatements, "that is no longer the operative statement" disclaimers and at least one general thought provoker.

After francokleptomania, restoring GNOME dignity. Bob Smith writes: "KDE beta was anounced but GNOME beta wasn't." Well, GNOME's latest freeze stage on the way to 1.2 was announced back in January, and Miguel answered questions about the state of GNOME in March, but point taken. With all the developments in GNOME, neither Miguel or his programs are likely to hurt for Slashdot coverage. You can grab the beta Bob mentions here.

Now, gentlemen, is there a way to perhaps merely maim this Golden Goose? Misch writes to point out this item on "ABCNews [which]reports that the House of Representatives has passed an extension of the Internet Tax Moratorium. Looks like it's tax free time on the Internet (depending on where you shop)."

Barely enough for a coven ... nullstar writes: "The NTIA has posted its report to Congress concerning the comments it received in regard to section 1201(g) of the DMCA, which deals with exceptions to the prohibition on circumventing encryption techniques intended to protect access to copyrighted materials. They basically claim, 'it's too soon to tell what effects the restriction will have on encryption research, etc., as the exception doesn't go into effect until October, so we're not yet recommending changes in the wording of the law.' Only 13 people submitted comments. "

Conflict of interest is an interesting term here ... full_tide writes "2600 has posted some news about how the MPAA is trying to get Martin Garbus (2600's hot-shot defense attorney) disqualified for a conflict of interest. Cryptome has posted a very long, but equally interesting, reply brief Mr. Garbus has writting in response to the injunction (damn, he's good). Also, the MPAA's web site is back up after a DDOS attack a few weeks back, and much downtime since. They appear to have added some fresh, juicy propaganda concerning the case."

Yessir, the gen-yoo-ine article, you betcha, mate. Jai From Insane Hardware writes: "Well, you may have heard all the rumours and whatnot about the Australian Fake Athlon deal and I confirm that it is true. But we have more info on the subject like on how they came about arriving in Oz and how they leaked thru the channel. This issue is very "close to home" for me so it's worthwhile reading for all the Aussies that go to your site. We also have exactly how the chips were modded. link " Meanwhile, Netsnipe wrote to point out that "Lucien Wells has updated his Web site Techwatch's coverage of the AMD Athlon tampering scandal. "Techwatch has now received press releases from two distributors involved, DMA and RTV Computers which claim that 'Neither RTV Computers Pty Ltd nor DMA (Direct Memory Access Pty Ltd) whom have their stickers on the CPU's knowingly at fault in this situation. At present legal action is underway to find the source of this problem.' At this stage AMD has not yet responded to Techwatch's requests for more information, says Lucien."

sigsegv writes: "The first preview tarball of Evolution is out on the Gnome FTP site. Pretty slick looking for those attached to gui e-mail clients. Personally, I still prefer mutt, but I know a few people very eager to see this. =8] "

How many of you are using Gnome right now? Wow! A lot of hands went up. How many of you have had a chance to meet or chat with Miguel de Icaza, Gnome's chief instigator? Hmmmm ... not nearly as many. Miguel's a cool dude, way out there on the forefront of Linux GUI development, and well worth meeting. If you don't get to a lot of Linux conferences, here's your chance to get to know him a little better. Take a look at his activity log and you'll see that he's about as busy as a human can be. What should you ask Miguel? Up to you. Post your questions below. One question per post, please, and try to keep things brief instead of submitting extended essays. We'll forward 10-15 of the highest-moderated questions to Miguel by e-mail shortly after 12 noon Tuesday (US EST -- that's 17:00GMT); his answers will run within the next week.

Havoc Pennington writes: "Some reports from the GNOME Users and Developers Conference are coming in; see one on the O'Reilly site and in the weekly GNOME Development Summary." Sounds like some good stuff was accomplished -- a GNOME Steering Committee, work towards 2.0, and setting up a non-profit among other things.

dfallon writes, "A GNOME development roadmap is available over on developer.gnome.org. Highlights include: a 1.2 release targeted for April, followed by another 1.X release in late summer (1.4?), which will include Nautilus, the desktop shell being worked on by Eazel, which will lead into a 2.0 release sometime in the fall. " This is, of course, subject to the mad revisions of Nat and Miguel - but it's cool to see what the future /might/ hold.

dfallon writes, "A GNOME development roadmap is available over on developer.gnome.org. Highlights include: a 1.2 release targeted for April, followed by another 1.X release in late summer (1.4?), which will include Nautilus, the desktop shell being worked on by Eazel, which will lead into a 2.0 release sometime in the fall. " This is, of course, subject to the mad revisions of Nat and Miguel - but it's cool to see what the future /might/ hold.

sheldie wrote to us to say that those wild and wacky Gnome guys have released Gnome-core/gnome-applets 1.1.4. As we've said before, they are currently in a feature-freeze, working towards 1.2. Of course, I do think that the best part of 1.1.4 is the name: "Ponies for Sale!" does a great job of drawing it all together. *grin*

naasking writes, "A new desktop project has been started by former Apple and AOL employees. Their goal is to create a graphical environment for Linux that "your mother could use." The company doing it is called Eazel. " It also is supposed to be based on GNOME. CT: Several people noted that this shell is destined to be the GNOME 2.0 shell/file manager.

A reader wrote to us with the news from Gnome.org stating that the freeze for 1.2 has begun. Gnome-core and gnome-applets 1.1.1 (Beantown) was released at the same time, but is meant for "advanced users and developers" so play carefully kids. This release marks the last release with new features until post-1.2 - a full list of the new features/fixes is in the changes list of 1.1.1.

A reader wrote to us with the news from Gnome.org stating that the freeze for 1.2 has begun. Gnome-core and gnome-applets 1.1.1 (Beantown) was released at the same time, but is meant for "advanced users and developers" so play carefully kids. This release marks the last release with new features until post-1.2 - a full list of the new features/fixes is in the changes list of 1.1.1.

Skeezix writes "Miguel de Icaza has delivered the State of Gnome Address in which he gives an excellent summary of the current state of Gnome, what is being worked on, what the future looks like, and how you can help."

Skeezix writes "Miguel de Icaza has delivered the State of Gnome Address in which he gives an excellent summary of the current state of Gnome, what is being worked on, what the future looks like, and how you can help."

Prince Caspian writes "There is a rather lengthy and informative interview with several key GNOME developers available, a good balance to the recent Slashdot KDE interview. Particularly interesting are the UI improvements with screenshots. " Mmmm. Eye Candy.

Prince Caspian writes "There is a rather lengthy and informative interview with several key GNOME developers available, a good balance to the recent Slashdot KDE interview. Particularly interesting are the UI improvements with screenshots. " Mmmm. Eye Candy.

Gnome has gotten the lion's share of Linux desktop publicity lately. Meanwhile, KDE has been quietly working on KDE2.0, which will hopefully contain several interesting features including a WWW browser called Konqueror and the long-anticipated KOffice, a free office suite that may provide a viable GPL *nix alternative to StarOffice and Applixware. Rather than speculating, we've decided to ask the people who are actually doing the work what they're up to. Post your questions below. Tuesday we'll send 10 - 15 of the highest-moderated ones to selected KDE developers. Answers will appear Friday.

The original concept of free, Open Source software was that of programmers writing software they wanted for themselves and sharing it with their peers like poets writing work that only other poets would ever read. Now Open Source and free software are getting major attention. There is suddenly an adoring public out there beyond the footlights. And the presence of this audience is changing the entire Open Source "movement." (more below)

Coming Out of the Programming Closet
I remember the first time I suggested an improvement to a piece of free, Open Source software. The testy response I got was, "Learn to program and do it yourself." This attitude was similar to that displayed by what I call "academic writers," whose fiction and poetry is so obscure that no one reads it except other academics.

But in the last few years, I've noticed a slow change in attitude among the Open Source and free software developers I know personally. More and more of them seem to be thinking in terms of writing software that is useful to others, not just what they want for themselves.

There is nothing wrong with this. Artists need audiences. So do techies. Sure, it's nice to write a "deep" piece of fiction that only top-rung English professors will appreciate, but it's also nice to write something that a whole bunch of people will read and understand, and perhaps even write you a letter or e-mail now and then that says "Thanks. Nice work."

Playing an instrument, reading a poem or performing a dramatic work on a stage in a theater full of adoring fans is certainly more gratifying than doing it alone, in private, or strictly in front of other musicians or actors.

Let's not veer off into the skeptical-but-valid "Is programming really an art?" question. Let's just say that it is a skill that takes both talent and practice, and that not everyone can do it well. In this way, if no other, it is similar to acting, singing, and other performing arts. And there is no reason talented programmers shouldn't get the same level of recognition as talented actors and musicians.

Will Success Spoil Rock Codeson?
It depends on what you call "success." By monetary standards, Bill Gates is more "successful" than Alan Cox a million times over. But I know who I'd rather invite over for a beer, and I'm sorry, Bill, it's not you. I can also think of dozens of actors and musicians whose work I think is wonderful, but who have never been (and may never be) nearly as famous or rich as others for whom I have no respect.

To go back to the theatrical metaphor, there are plenty of marvelous shows that run for months in off-Broadway and off-off-Broadway theaters without taking in one percent of what a big-time musical like Cats can earn on a single weekend night. But the small theatrical productions often have better acting than what you see in the "major" shows. The music is often more interesting. Scripts in low-budget shows are often far superior to the blanded-down words used in productions with millions of dollars invested in them, that have been tested and revised in so many out-of-town tryouts that somuch life has been squeezed out of them that all they have to offer is glitz and glitter with little or no underlying value. The soul of theater, if you will, is in people working out on the edge, going beyond the norm, thinking with their hearts instead of reading market research studies and holding "focus group" sessions with audience members.

There is beauty in putting your heart into a creation, and there is beauty in watching others respond to that creation. Whether that creation is a song or a piece of code hardly matters; the "click" that comes from connecting with an audience can and should be there in either case. Actors generally recognize this, which is why there are dozens of small stage theaters in and around Los Angeles where screen actors perform - almost always unpaid - works that would never make it onto TV or into movie theaters. There is commercial success, and there is satisfaction. The two are not always the same.

Most of the "free software" writers I know make their livings writing commercial software or from some sort of programming-related consulting. But, like auto mechanics who build race cars on weekends for fun, when they go home they work on projects of their own choosing.

Mechanics who prove their creds on the racetrack always have their pick of the best "shop" jobs. Actors who get good reviews in small stage productions tend to get steady work in movies and TV. And a programmer who has gained recognition by doing excellent free software development is likely to have his or her pick of jobs. In this sense, fame gained by writing free software has direct financial value, and if it is widely-used software, not something that will be used only by a few other programmers, that value is increased substantially.

Building a Portfolio
When an actor, musician or writer goes looking for a job, he or she is expected to show potential employers or freelance clients samples of previous performed or published work. If that work has been performed or published to great public acclaim, so much the better.

Right now, programmers, like auto mechanics, are in short supply. A resume that says you have worked for So-and-So inc. for X amount of time, and have experience with Y language (or for the mechanic, on Z make of car) will get you in the door and will probably land you a decent job. And if you're satisfied with that, fine. The world needs ordinary grunt-work coders and ordinary "do brake jobs all day" mechanics. But in either field, the plum jobs go to those who can point to extraordinary individual accomplishments.

For the mechanic, the best proof of accomplishment has traditionally been the winning race car. For the programmer, the stellar proof of personal accomplishment is a popular piece of free software.

Look at Miguel de Icaza. A few years ago he was an obscure listing in the Linux Source, best known for his work on Midnight Commander. Today he's running a well-financed startup, and I'm sure he didn't have to look very hard for backers. But his work on Midnight Commander and other free software projects, even before Gnome made him famous, was more than enough to guarantee him not only an excellent living as a programmer, but complete freedom from "industrial-style" code writing for the rest of his life.

I suspect we'll see a lot more energetic, imaginative young programmers following in Miguel's footsteps instead of going into the highest-paying jobs they can find as soon as they can find them. Will some of them be doing this so that they can reap great financial rewards later? Of course! Not everyone can be a saint like Richard M. Stallman; Jean-loup Gailly, previously best-known as the principal author/maintainer of gzip, is now CTO of MandrakeSoft. And I'm sure there are countless others whose free software fame is getting them not only kudos but excellent salaries. And there's nothing wrong with that.

Passing Batons
We can sit around and cry about how free software developers are being "corrupted" by fame and money, but it's pointless. For one thing, just as the mechanic who gets promoted to shop foreman can still build race cars on his own time, and successful movie actresses often do unpaid stage acting on the side, there's no reason for people who use free software work as a springboard to fortune to give up their prior love. And many don't. They keep on doing what they always did, after work, on their own time. (And a few exceptionally lucky ones actually get to develop free software all day long for pay, but they're still a rare breed.)

But today's free software developers are not the be-all and end-all of the idea. Free software is starting to produce enough success stories that even if all of today's luminaries end up working for Microsoft, Adobe, and other big proprietary development houses within the next decade, plenty of new ones will come along, as hungry for applause as any group of talented young actors and singers.

And as more free software developers realize that by treating users as adoring fans - not as annoyances - they can earn even more applause, there will be more users. And more applause. And more developers. And if this upward spiral can become self-perpetuating, in a few years movie stars may be asking free software developers for their autographs instead of the other way around.

The original concept of free, Open Source software was that of programmers writing software they wanted for themselves and sharing it with their peers like poets writing work that only other poets would ever read. Now Open Source and free software are getting major attention. There is suddenly an adoring public out there beyond the footlights. And the presence of this audience is changing the entire Open Source "movement." (more below)

Coming Out of the Programming Closet
I remember the first time I suggested an improvement to a piece of free, Open Source software. The testy response I got was, "Learn to program and do it yourself." This attitude was similar to that displayed by what I call "academic writers," whose fiction and poetry is so obscure that no one reads it except other academics.

But in the last few years, I've noticed a slow change in attitude among the Open Source and free software developers I know personally. More and more of them seem to be thinking in terms of writing software that is useful to others, not just what they want for themselves.

There is nothing wrong with this. Artists need audiences. So do techies. Sure, it's nice to write a "deep" piece of fiction that only top-rung English professors will appreciate, but it's also nice to write something that a whole bunch of people will read and understand, and perhaps even write you a letter or e-mail now and then that says "Thanks. Nice work."

Playing an instrument, reading a poem or performing a dramatic work on a stage in a theater full of adoring fans is certainly more gratifying than doing it alone, in private, or strictly in front of other musicians or actors.

Let's not veer off into the skeptical-but-valid "Is programming really an art?" question. Let's just say that it is a skill that takes both talent and practice, and that not everyone can do it well. In this way, if no other, it is similar to acting, singing, and other performing arts. And there is no reason talented programmers shouldn't get the same level of recognition as talented actors and musicians.

Will Success Spoil Rock Codeson?
It depends on what you call "success." By monetary standards, Bill Gates is more "successful" than Alan Cox a million times over. But I know who I'd rather invite over for a beer, and I'm sorry, Bill, it's not you. I can also think of dozens of actors and musicians whose work I think is wonderful, but who have never been (and may never be) nearly as famous or rich as others for whom I have no respect.

To go back to the theatrical metaphor, there are plenty of marvelous shows that run for months in off-Broadway and off-off-Broadway theaters without taking in one percent of what a big-time musical like Cats can earn on a single weekend night. But the small theatrical productions often have better acting than what you see in the "major" shows. The music is often more interesting. Scripts in low-budget shows are often far superior to the blanded-down words used in productions with millions of dollars invested in them, that have been tested and revised in so many out-of-town tryouts that somuch life has been squeezed out of them that all they have to offer is glitz and glitter with little or no underlying value. The soul of theater, if you will, is in people working out on the edge, going beyond the norm, thinking with their hearts instead of reading market research studies and holding "focus group" sessions with audience members.

There is beauty in putting your heart into a creation, and there is beauty in watching others respond to that creation. Whether that creation is a song or a piece of code hardly matters; the "click" that comes from connecting with an audience can and should be there in either case. Actors generally recognize this, which is why there are dozens of small stage theaters in and around Los Angeles where screen actors perform - almost always unpaid - works that would never make it onto TV or into movie theaters. There is commercial success, and there is satisfaction. The two are not always the same.

Most of the "free software" writers I know make their livings writing commercial software or from some sort of programming-related consulting. But, like auto mechanics who build race cars on weekends for fun, when they go home they work on projects of their own choosing.

Mechanics who prove their creds on the racetrack always have their pick of the best "shop" jobs. Actors who get good reviews in small stage productions tend to get steady work in movies and TV. And a programmer who has gained recognition by doing excellent free software development is likely to have his or her pick of jobs. In this sense, fame gained by writing free software has direct financial value, and if it is widely-used software, not something that will be used only by a few other programmers, that value is increased substantially.

Building a Portfolio
When an actor, musician or writer goes looking for a job, he or she is expected to show potential employers or freelance clients samples of previous performed or published work. If that work has been performed or published to great public acclaim, so much the better.

Right now, programmers, like auto mechanics, are in short supply. A resume that says you have worked for So-and-So inc. for X amount of time, and have experience with Y language (or for the mechanic, on Z make of car) will get you in the door and will probably land you a decent job. And if you're satisfied with that, fine. The world needs ordinary grunt-work coders and ordinary "do brake jobs all day" mechanics. But in either field, the plum jobs go to those who can point to extraordinary individual accomplishments.

For the mechanic, the best proof of accomplishment has traditionally been the winning race car. For the programmer, the stellar proof of personal accomplishment is a popular piece of free software.

Look at Miguel de Icaza. A few years ago he was an obscure listing in the Linux Source, best known for his work on Midnight Commander. Today he's running a well-financed startup, and I'm sure he didn't have to look very hard for backers. But his work on Midnight Commander and other free software projects, even before Gnome made him famous, was more than enough to guarantee him not only an excellent living as a programmer, but complete freedom from "industrial-style" code writing for the rest of his life.

I suspect we'll see a lot more energetic, imaginative young programmers following in Miguel's footsteps instead of going into the highest-paying jobs they can find as soon as they can find them. Will some of them be doing this so that they can reap great financial rewards later? Of course! Not everyone can be a saint like Richard M. Stallman; Jean-loup Gailly, previously best-known as the principal author/maintainer of gzip, is now CTO of MandrakeSoft. And I'm sure there are countless others whose free software fame is getting them not only kudos but excellent salaries. And there's nothing wrong with that.

Passing Batons
We can sit around and cry about how free software developers are being "corrupted" by fame and money, but it's pointless. For one thing, just as the mechanic who gets promoted to shop foreman can still build race cars on his own time, and successful movie actresses often do unpaid stage acting on the side, there's no reason for people who use free software work as a springboard to fortune to give up their prior love. And many don't. They keep on doing what they always did, after work, on their own time. (And a few exceptionally lucky ones actually get to develop free software all day long for pay, but they're still a rare breed.)

But today's free software developers are not the be-all and end-all of the idea. Free software is starting to produce enough success stories that even if all of today's luminaries end up working for Microsoft, Adobe, and other big proprietary development houses within the next decade, plenty of new ones will come along, as hungry for applause as any group of talented young actors and singers.

And as more free software developers realize that by treating users as adoring fans - not as annoyances - they can earn even more applause, there will be more users. And more applause. And more developers. And if this upward spiral can become self-perpetuating, in a few years movie stars may be asking free software developers for their autographs instead of the other way around.

Quite a number of people have been writing to us about Dave Whitinger's column that ran on LinuxToday and was sent over here as well. Dave's contention is the browser compatibility is a crucial battle for the success of Linux - and things don't look so good. Click below to read the column, and contribute your thoughts.

By Dave Whitinger, dave@wmkt.com (Temporary E-Mail account)

Linux is quickly becoming the operating system of the future, thanks in part to the advanced type of development that we refer to as Free Software, or Open Source, as well as the rock-solid features that are present in Linux. It is the ultimate server platform.

Linux is also enjoying success as a desktop workstation. My wife, Trish, makes the perfect example of the typical desktop user.

When we became married in August of 1996, she was a complete computer illiterate, having never even used a Windows or Unix machine. I presented her with a choice:

1. I will give her a Windows computer, but will offer nothing in the way of technical support or training assistance.
2. I will give her a Linux box, and will give her complete technical support and training assistance.

A New Hope

Not knowing the difference anyway, she chose the latter, and found herself extremely happy with a rock-solid desktop.

She enjoys her Red Hat Linux 6.1 workstation. Coupled with the K Desktop Environment and various applications that I have installed for her, she's ready to go. She has her TkRat E-Mail program, Netscape Navigator, notepad text editor, licq, games, the Gimp, and a variety of other nice applications, all accessed via a friendly interface.

Finding friends in mailing lists and on-line web-based chat groups, she was happy as a clam. She would fire up her Netscape Navigator and hit any web site she wanted, and was constantly bragging to her friends about this great computer operating system that she had the privilege of using.

The Empire Strikes Back

...Until the day that Netscape Navigator, her web browser, her window to the outside world, the major purpose for using the computer, simply disappeared from her desktop while she was browsing.

Trish turned to me, confusion spread across her face, and opined, "Dave, my Netscape has simply vanished from my screen. Perhaps you have telneted in and did a kill -9 on it?"

Dave responds, "Absolutely not! Why would I do that? Let's examine the problem more closely, that the answer to this perplexing issue will reveal itself."

Upon further investigation, it turns out that Netscape apparantly did not "like" the Java code that was being incorporated into one of the websites that Trish frequents. My solution: Turn off Java.

A very important and critical issue is realized here. At this point, Trish's computer is not as powerful as all of her friends' Windows computers. If they can access certain Java-enabled pages that she cannot, she is being left out, all because she chose to use Linux.

Fade to 2 or 3 weeks later.

Trish: "Dave, this website is telling me that I cannot use their services."

Dave: "What's the URL?"

Examining the website, it turns out that it is using some special kind of plugin that is only available for Windows or Macintosh platforms. I explained to Trish that she simply will not be able to access the services on this website, until they decide to make this plugin available for Linux. A short and polite note to the webmaster later, there was nothing we could do, and the issue was closed, and Trish's computer became even less valuable to her.

Fade to 2 or 3 more weeks later.

Trish: "Dave, this website is telling me that I am using an unsupported web browser, and cannot view the pages within."

Dave: "Okay, this is starting to make me angry. The web was initially created as a completely open environment where multimedia can be viewed, regardless of your platform. It's a platform independant medium, yet here are people making platform dependant websites."

Trish: "That's great that you feel that way, but I just want to access this coupon website! All my friends say they are getting great deals, and I'm missing out! Oh, and now my netscape just froze again! Argh, (killall -9 netscape ; rm ~/.netscape/lock) again. I want a Windows computer like all my friends have."

I hung my head in shame, realizing that if she is going to be able to take full advantage of the web, she will need a Windows computer. Trish, who has used nothing but Linux for over 3 years, and is completely happy with her computer, now feels the need to switch to Windows so that she can get the same web-browsing features as her friends.

Does this sound like a big deal to you, gentle reader? If it does, than I have accomplished my mission. If it does not, read on:

In 1994, I hated Netscape Communications, Inc. The way they were embracing and extending the HTML standards was starting to become very disturbing for me. The more websites that I found that said that it uses Netscape Extensions, the more angry I became.

Then Netscape released Navigator for Linux, and everybody loved them again. They were our saviour, completing the picture of a perfect desktop for Linux users. We were all Linux users, browsing any site we wished, enjoying the satisfaction of having a great web browser for our desktop.

Then Microsoft created Internet Explorer. Then Microsoft won the "Browser War". Then webmasters began using some of the "advanced" features of Internet Explorer, shutting out Netscape users.

Problem yet? Still not convinced? Okay, let's fast forward 1 year:

Microsoft owns 99% of the web browser market share, and they control the HTTP protocol. They start adding a huge variety of features to their "Internet Information Server", their competitor to Apache, to offer advanced features to Internet Explorer clients. At this point, sites being served by Apache become useless. Then Linux becomes obsolete as a web server platform. Then Microsoft wins the war, and we're right back to square one, and proprietary technology wins again.

Return of the Jedi

On April 1st, 1998, Netscape Communications, Inc. made one final redeeming move. They released the source code to Netscape Navigator, freeing it to the Free Software community to do with as they chose.

1 and a half years later, this browser is still nowhere near completion. There is a band of rebels working feverishly on the code, trying to bring it to a usable state as quickly as possible. Plagued with problems and set-backs, Mozilla continues forward, currently at "Milestone 10". Will we see a completely usable web browser for Linux in time to save us from seeing a new monopoly for Microsoft be created?

Attention: This is the battle that could cost us the war. If we come together and push all of our might toward a Free Web Browser for Linux, we have a good chance of winning this battle. If we fail, we will lose the war. This is the issue that Microsoft wants us to overlook.

I am making a personal committment to get involved with the Mozilla project. It is the project with the most potential to become this Free Web Browser that we so desperately need. Netscape is NOT going to save us this time. Netscape has failed us, and it's time to take matters into our own hands.

If we fail, we will lose the war.

Add that to your .signature:

If we fail, we will lose the war.

And repeat it every morning to yourself:

If we fail, we will lose the war.

When you are looking over Mozilla, finding items that could use your contribution, remember:

If we fail, we will lose the war.

The truth of the matter, friends and esteemed members of the community:

If we fail, we will lose the war.

Foaf writes "According to his activity log, Miguel of Gnome and Gnumeric fame is quitting his university job and moving to the US to provide 'kick-ass applications for users all around the globe.' " And, yes, now I can rest easy knowing that Miguel will be unfettered in his attempts to consume all of the world's coffee *grin*. Seriously, this is the continuation of a wonderful trend - more time developing Linux applications is good for everyone.

k_wayne writes "The Gnome team have finished an amazing bug hunt and we are left with a pretty cool stable release of the Gnome system. See the announcement made by Elliot Lee. The gnome developers are now moving their attention toward the next generation gnome release. This new Gnome stuff is not only very stable, it's got some very cool stuff in it. " One really nice new feature is dingus-clicking: you can click on a URL in the terminal and have Netscape come up. XChat, glade, more translations, and easier bug reporting some of the most significant features.

Monday we requested questions for Havoc Pennington, who is (among other things) author of GTK+/Gnome Application Development- and got plenty of them. Today we have Havoc's answers (click below). Read and enjoy!

Signal 11 asks: There has been a lot of discussion about merging KDE and Gnome together either via a universal toolkit, or by actually merging the two code-bases together.

What are the technical (and legal?) obstacles that need to be overcome for this to succeed? How does the KDE and Gnome developers feel about such a merger? Is there currently any work being done to further this goal at present (by either camp)?

Havoc answers:

Merging the entire code base is completely impossible, both technically and legally - not to mention that it would involve scrapping and rewriting close to a million lines of code, actually more I think, once you count applications. So we can consider that an official Bad Idea.

However there is a lot of room to share code. Some things aren't really desktop-specific; for example, a sound server or my GConf configuration storage library or libxml or libart. These are components the desktops could easily share.

We're making lots of progress on interoperability. For example, the window manager hints spec, so your KDE desktop icons won't show up underneath your GNOME panel, your GNOME panel will work with the K Window Manager, etc.

Some work has been done on "themeballs" which are collections of "matching" themes; we'd have an app that knows how to install the theme collection as a group, so your GNOME app, KDE apps, and window manager would all reflect the same theme. Someone from GNOME has been trying to write a GTK pixmap theme that loads the Qt pixmap theme format, as well. (For proof-of-concept, check out the Sawmill window manager, which automatically "matches" the current GTK theme.)

CORBA is sort of inherently interoperable, modulo some small details. Things are looking pretty good on this front.

BadmanX asks: When do you see Gnome getting some sort of threading capability, like that which makes the Be operating system so integrated?

Havoc answers:

I think GNOME is a bit too high-level for this; I would expect it to be more of an X server or kernel issue. GNOME should be able to take advantage of multimedia speed enhancements almost automatically. Of course the Linux kernel and GNU C library already have a fairly solid threading capability, but it isn't used as pervasively as it could be perhaps.

As an aside, the glib library used in GTK+ provides a nice main loop abstraction that allows us to avoid the need for threads in many cases, which can make writing applications much simpler. There are some cases where threads are necessary (a server that does blocking IO for example), but we try to minimize their use because they are a maintenance and portability problem.

Skeezix asks:

Could you give us a rough timeline of what we can expect to see coming from the GNOME project in the next months, and years? Could you give us an idea of when we can expect to see the 1.0.50 and 2.0.0 releases of GNOME? And what will those releases look like?

Havoc answers:

1.0.50

1.0.50 may have come out by the time you read this. It has lots of small new features; the file manager has been significantly enhanced, the libraries have some new stuff for developers, there are "segfault dialogs" that come up and tell you when apps have crashed, control center fixups, logout animation, gdm2 (the first PAM-compliant X login daemon, someone told me today), gnome-session has no known crashes, removable media is auto-detected, etc. Just incremental enhancements.

Actually this release may not be called 1.0.50, I think we are calling it "September GNOME" or something. In any case; we've been releasing some component or other every week since GNOME 1.0, but this is a synchronized release of all the components and represents the end of our active work on the 1.0 series. (Though there will doubtless be a few small releases for whatever reason.)

I noticed a little flame war in the comments for the first article about "what has GNOME been doing"; basically we have been working on applications and next-generation development infrastructure. GNOME Workshop totals 400,000 lines of code, counting a semicolon as a line; this is close to a million lines if you use the plain "wc -l" method of counting. That's a whole lot of code hidden behind the sucky GNOME Workshop web page. Other GNOME projects over the last few months include the Bonobo component architecture, libglade, and bug fixes. :-)

2.0

It's probably a bad idea to announce a date for 2.0 at this time. Most likely in the first half of next year. Well, we are going to try our damnedest to get it done within 6 months I think.

One thing I'd like to see in 2.0 are multiple releases, not necessarily at the same time. The components as I see them are:

• GNOME Developer Toolkit: Libraries and development tools like Glade
• GNOME Desktop Environment: File manager, window manager, panel, trash can, etc.
• GNOME Application Suite: The 20 or so small utility apps that are distributed with GNOME itself.
• GNOME Workshop: The office suite

I'd like to see these four major parts of GNOME released as separate packages. But it remains to be seen what we'll decide.

Here are some of my thoughts on 2.0, obviously it will evolve a little bit along the way and other GNOME project members will disagree:

• Bonobo component architecture library (already mostly done, has to be released and stabilized)
• New file manager (asynchronous virtual file system layer is done, code such as metadata database will be reused from gmc, but lots of stuff to rewrite).
• Hopefully a default window manager that we know works well with GNOME and we have enough influence over to "sync" with our release and be sure it has an interface we can live with. Of course you will still be able to choose your favorite WM if you want, we're working with KDE on a nice WM spec.
• Mozilla-based help system. The Mozilla build tree already has a GtkMozilla widget in it, and we're standing ready to slap a Bonobo wrapper around Mozilla as soon as the thing shows signs of stabilizing. Dave Mason at RHAD Labs is an expert on online help and SGML/XML (he wrote the 100 page illustrated GNOME User's Guide as well), and Mozilla hacker Chris Blizzard also works at Red Hat though not in the labs. We think that together they can create a sweet system.
• Replacing Imlib. This should result in some small performance gains, and a simpler codebase for us to maintain. The gdk-pixbuf replacement library has already been written.
• libglade integration. libglade is already in use, but we have to integrate it with gnome-libs. This is a library which parses an XML resource file and creates an interface. This makes for some serious rapid application development.
• GConf configuration system. This makes it much easier to deploy the desktop in computer labs or larger offices.
• Enhanced language bindings. We want to flesh out any remaining gaps in the language bindings and be sure these work well.
• Internationalization. Owen Taylor at RHAD Labs is working full-time on internationalization issues in GTK+; we will support Unicode, and all kinds of writing systems (including bidirectional text). Very few (if any) toolkits support internationalization to this extent.
• Printing. We already have a gnome-print library, which needs some polishing up for a stable release. It will be included in GNOME 2.0. Gnumeric and Dia already print using gnome-print, however.

As you can see we have quite a bit of code waiting in the wings ready to go in GNOME 2.0; that's why we hope to finish on a tight schedule. But of course things could go wrong, you never know.

Hackers who want to get involved are encouraged to start lurking on the mailing lists and the #gnome IRC channel, and start reading documentation on our developer's site. There's a lot of stuff to do and the future looks exciting.

Tet asks:

There have been many half hearted explanations for GNOME's poor performance, ranging from Gtk to CORBA to X itself. However, none of those really cut it. Given the responsiveness of standalone Gtk apps, I think Gtk can be ruled out. Orbit is supposedly 3 the fastest CORBA implementation by a factor of 3, even with all the assertions left in. While the X protocol may be somewhat slower than it could be, X is still quite responsive on my old 486.

I now have an AMD K62-450, and GNOME still feels sluggish, about the same speed as Windows 95 on my P75. That has to be wrong. Yes, GNOME probably does more than W95, including things like network transparency, and the like, but even taking that into account, along with Gtk, CORBA and X itself, you shouldn't be looking at more than, say, reducing performance by half, and that's being pessimistic. In reality, you're looking at GNOME being 3 or 4 *times* slower than it ought to be. Simple question: why?

Havoc answers:

This question is really too vague; let me know if my answer is still half-hearted. What is your setup? What theme? What window manager? Is your X server good or is it one of the semi-finished ones? What things are slow for you? Are you actually timing things?

I have a Pentium 166 laptop and GNOME is very fast and responsive. But I do two things:

I use only theme engines, especially the GTK default theme, no pixmap themes. If you use the glitzy themes you pay in speed and memory.

I use WindowMaker or Sawmill, not E.

There are some specific things we know are slow:

• Application startup is slow. This is primarily due to the fact that a GNOME application links to so many separate shared libraries; if we merged all the libraries into one or two giant libraries, you would have many fewer system calls on startup and faster start time. However, there would be some disadvantages from a maintenance/download-size standpoint. We've addressed this problem by changing Imlib to dynamically load libpng, libtiff, etc. on-demand instead of on startup; we'll probably be removing Imlib in the next release. We could probably change things so the sound libraries are also loaded on demand.
• GTK flickers a lot if you have opaque resize turned on. This is a complicated problem that's hard to address; the long term solution is probably to move GTK+ to an architecture like the GNOME Canvas widget instead of the more traditonal toolkit architecture based on X windows. The flicker isn't really slow, but it makes people feel that things are sluggish.
• Some versions of E do some things slowly. For example moving windows around can be slow. WindowMaker is much more consistenly snappy, and Sawmill is nice too. Those are just my preferences, lots of people swear by icewm, fvwm, scwm, etc.
• Some specific applications may be slow for whatever reason - if some particular operation seems too slow, please file a bug on http://bugs.gnome.org.

Anonymous Coward asks:

You are known to be a programmer, and a programmer always has some ideas on languages and tools. What of the currently available languages would be your programming language of choice now? What about two years from now? Why? How would you change it so it becomes the ideal language? What's the worst language you've written something substantial in? How would you change it so it becomes the absolutely most evil language?

Havoc answers:

OK, you are setting me up to be flamed. :-)

I don't think the language is really the primary issue right now. People are interested in the quality of the available implementations, the availability of support and training, the kind and number of useful add-on modules, the documentation, and so on. Basically for any project, you decide whether you need the speed of C/C++, and if you don't you do your best to use a higher-level more reasonable language with a good implementation. "Academic" languages like Haskell and Eiffel, while much nicer languages than Perl or Python or C++ or Java, have implementation issues that often restrict their use.

With the Cygnus/GNU Java compiler, lots of GNOME people are cheering for Java. We even have a good start on the Java bindings for GNOME. Java offers an object oriented environment syntactically similar to C/C++, but has some important safety advantages (no pointers), reduced complexity, and lots of nice libraries.

For rapid application development I like to suggest Python as a sort of "Visual Basic equivalent"; PyGNOME and libglade by GNOME's James Henstridge allow you to write a fairly complex, nice-looking application in a couple days. The Red Hat 6.1 installer is written in PyGNOME.

I've used Guile some as an extension language; the Guile-to-C API is very simple and easy to use. Again, an implementation issue that becomes important.

There's an O'Reilly book coming out about Perl/GTK, I'm told, so I assume those bindings are pretty good. Judging by the list traffic quite a few people are using them.

Anyway I've been playing with Haskell lately and I think there are some practical issues with it, but it's improving and I enjoy it a lot. So if I'm having a language war I like to defend it. But in practice I end up using C to write libraries, if I were writing a high-level tool I'd probably use Python. My largest two projects to date (Guppi and gnome-apt) are in C++. gcj makes me want to have another look at Java. Just use whatever works.

Ian Bicking asks:

There are a ton of preceding and current desktop environments: KDE, CDE, GNUStep, Windows, MacOS, Xerox Star, BeOS, QNX/Photon, and a whole bunch of others.

Are there any ideas from other such environments that you think are really neat? Any ideas that you would like to be part of Gnome, or even plan to try yourself?

Havoc answers:

We do our best to steal shamelessly from all other user interfaces; we have the Mac UI guide and a Windows box at RHAD Labs, as well as KDE installations, and we often look at how these other groups implemented a given dialog or widget. I'm sure the GNOME hackers on the net do the same thing; Miguel is always talking about the latest Excel feature he just cloned in Gnumeric.

In general we want to keep the UI "sufficiently similar to" the windows-mouse-icon model of Windows and Mac, because trying to be revolutionary on this point would be a disaster (read the gnome-gui-list archives if you have any doubts). But we like to add nifty enhancements, such as themes or the GNOME panel. And of course hackers who work on innovative stuff are welcome.

Most of my interface ideas are for particular applications. Having just written a book, I have an elaborate plan for the ultimate document-writing application. But Emacs will have to do until I get some more time. :-)

SEGV asks:

Havoc, how did you find the process of writing a book? Can you tell us more about the process? How long did it take? How did you find the time? What were some of the hurdles you had to overcome? Are you as pleased with the final product as you imagined when you began? Would you do it again?

Havoc answers:

Writing a book involves sitting down for long periods of time and typing. As an activity, that's pretty much what it involves. :-) Well, there's some thought that goes into it.

Seriously. I wrote a "fast book," it took about 4 months. Lots of books are written in well over a year, but I wanted to write a book that people could begin using as soon as possible. If it sells well there may be a second edition sometime after GNOME 2.0 (even without the second edition it will continue to be maintained as part of the GNOME project).

The process is simple. You make an outline and get opinions on it from all your editors and technical advisors, then you revise it a few times. After that you start to write the chapters in the outline; each chapter is reviewed for technical accuracy and writing quality, then sent back to you. You make the suggested changes, then submit the final chapter. After you've done that for all the chapters, you just wait for the book to appear in print. That's about it, modulo some boring details.

I found the time by spending a lot of weekends with my computer instead of doing something fun, and by staying up late some nights. I think in general there is a poor work/pay ratio, so it's important to want to get the information out there, you won't be getting rich on book-writing.

ajs asks:

I hear things about Glade getting sucked into core GNOME libraries as a way of dynamically reconfiguring applications (an ambitious goal!) How much planning has been done for this, and is it expected to impact application performance?

Havoc answers:

Well, we are already using libglade in some applications, such as Gnumeric, and it doesn't seem to be causing a problem. :-)

Glade won't be sucked in, but rather libglade. libglade has about two function calls in the whole library; all it does is load an XML file generated by the Glade GUI builder. It uses the file to create widgets for your user interface. You can avoid writing widget-creation code; you just have to write the callbacks that actually implement the functionality of your application.

There is some amount of performance overhead but it is fairly small and only at application startup time; once you've loaded the widgets, they are just as fast as they would be if hand-coded. There are also some performance advantages:

• You can often halve the number of lines of code in the application itself, thus reducing application size.
• You save tons and tons of programmer time, so hackers can focus on optimizing the truly time-sensitive portions of the application.

If speed becomes a genuine problem we can implement a way to "compile" the XML files into some kind of high-speed binary format I guess. That would be pretty trivial and would avoid the XML parser overhead. But as I said, we're already using libglade in several places and I haven't noticed a speed problem.

Next week: Eric S. Raymond

Monday we requested questions for Havoc Pennington, who is (among other things) author of GTK+/Gnome Application Development- and got plenty of them. Today we have Havoc's answers (click below). Read and enjoy!

Signal 11 asks: There has been a lot of discussion about merging KDE and Gnome together either via a universal toolkit, or by actually merging the two code-bases together.

What are the technical (and legal?) obstacles that need to be overcome for this to succeed? How does the KDE and Gnome developers feel about such a merger? Is there currently any work being done to further this goal at present (by either camp)?

Havoc answers:

Merging the entire code base is completely impossible, both technically and legally - not to mention that it would involve scrapping and rewriting close to a million lines of code, actually more I think, once you count applications. So we can consider that an official Bad Idea.

However there is a lot of room to share code. Some things aren't really desktop-specific; for example, a sound server or my GConf configuration storage library or libxml or libart. These are components the desktops could easily share.

We're making lots of progress on interoperability. For example, the window manager hints spec, so your KDE desktop icons won't show up underneath your GNOME panel, your GNOME panel will work with the K Window Manager, etc.

Some work has been done on "themeballs" which are collections of "matching" themes; we'd have an app that knows how to install the theme collection as a group, so your GNOME app, KDE apps, and window manager would all reflect the same theme. Someone from GNOME has been trying to write a GTK pixmap theme that loads the Qt pixmap theme format, as well. (For proof-of-concept, check out the Sawmill window manager, which automatically "matches" the current GTK theme.)

CORBA is sort of inherently interoperable, modulo some small details. Things are looking pretty good on this front.

BadmanX asks: When do you see Gnome getting some sort of threading capability, like that which makes the Be operating system so integrated?

Havoc answers:

I think GNOME is a bit too high-level for this; I would expect it to be more of an X server or kernel issue. GNOME should be able to take advantage of multimedia speed enhancements almost automatically. Of course the Linux kernel and GNU C library already have a fairly solid threading capability, but it isn't used as pervasively as it could be perhaps.

As an aside, the glib library used in GTK+ provides a nice main loop abstraction that allows us to avoid the need for threads in many cases, which can make writing applications much simpler. There are some cases where threads are necessary (a server that does blocking IO for example), but we try to minimize their use because they are a maintenance and portability problem.

Skeezix asks:

Could you give us a rough timeline of what we can expect to see coming from the GNOME project in the next months, and years? Could you give us an idea of when we can expect to see the 1.0.50 and 2.0.0 releases of GNOME? And what will those releases look like?

Havoc answers:

1.0.50

1.0.50 may have come out by the time you read this. It has lots of small new features; the file manager has been significantly enhanced, the libraries have some new stuff for developers, there are "segfault dialogs" that come up and tell you when apps have crashed, control center fixups, logout animation, gdm2 (the first PAM-compliant X login daemon, someone told me today), gnome-session has no known crashes, removable media is auto-detected, etc. Just incremental enhancements.

Actually this release may not be called 1.0.50, I think we are calling it "September GNOME" or something. In any case; we've been releasing some component or other every week since GNOME 1.0, but this is a synchronized release of all the components and represents the end of our active work on the 1.0 series. (Though there will doubtless be a few small releases for whatever reason.)

I noticed a little flame war in the comments for the first article about "what has GNOME been doing"; basically we have been working on applications and next-generation development infrastructure. GNOME Workshop totals 400,000 lines of code, counting a semicolon as a line; this is close to a million lines if you use the plain "wc -l" method of counting. That's a whole lot of code hidden behind the sucky GNOME Workshop web page. Other GNOME projects over the last few months include the Bonobo component architecture, libglade, and bug fixes. :-)

2.0

It's probably a bad idea to announce a date for 2.0 at this time. Most likely in the first half of next year. Well, we are going to try our damnedest to get it done within 6 months I think.

One thing I'd like to see in 2.0 are multiple releases, not necessarily at the same time. The components as I see them are:

• GNOME Developer Toolkit: Libraries and development tools like Glade
• GNOME Desktop Environment: File manager, window manager, panel, trash can, etc.
• GNOME Application Suite: The 20 or so small utility apps that are distributed with GNOME itself.
• GNOME Workshop: The office suite

I'd like to see these four major parts of GNOME released as separate packages. But it remains to be seen what we'll decide.

Here are some of my thoughts on 2.0, obviously it will evolve a little bit along the way and other GNOME project members will disagree:

• Bonobo component architecture library (already mostly done, has to be released and stabilized)
• New file manager (asynchronous virtual file system layer is done, code such as metadata database will be reused from gmc, but lots of stuff to rewrite).
• Hopefully a default window manager that we know works well with GNOME and we have enough influence over to "sync" with our release and be sure it has an interface we can live with. Of course you will still be able to choose your favorite WM if you want, we're working with KDE on a nice WM spec.
• Mozilla-based help system. The Mozilla build tree already has a GtkMozilla widget in it, and we're standing ready to slap a Bonobo wrapper around Mozilla as soon as the thing shows signs of stabilizing. Dave Mason at RHAD Labs is an expert on online help and SGML/XML (he wrote the 100 page illustrated GNOME User's Guide as well), and Mozilla hacker Chris Blizzard also works at Red Hat though not in the labs. We think that together they can create a sweet system.
• Replacing Imlib. This should result in some small performance gains, and a simpler codebase for us to maintain. The gdk-pixbuf replacement library has already been written.
• libglade integration. libglade is already in use, but we have to integrate it with gnome-libs. This is a library which parses an XML resource file and creates an interface. This makes for some serious rapid application development.
• GConf configuration system. This makes it much easier to deploy the desktop in computer labs or larger offices.
• Enhanced language bindings. We want to flesh out any remaining gaps in the language bindings and be sure these work well.
• Internationalization. Owen Taylor at RHAD Labs is working full-time on internationalization issues in GTK+; we will support Unicode, and all kinds of writing systems (including bidirectional text). Very few (if any) toolkits support internationalization to this extent.
• Printing. We already have a gnome-print library, which needs some polishing up for a stable release. It will be included in GNOME 2.0. Gnumeric and Dia already print using gnome-print, however.

As you can see we have quite a bit of code waiting in the wings ready to go in GNOME 2.0; that's why we hope to finish on a tight schedule. But of course things could go wrong, you never know.

Hackers who want to get involved are encouraged to start lurking on the mailing lists and the #gnome IRC channel, and start reading documentation on our developer's site. There's a lot of stuff to do and the future looks exciting.

Tet asks:

There have been many half hearted explanations for GNOME's poor performance, ranging from Gtk to CORBA to X itself. However, none of those really cut it. Given the responsiveness of standalone Gtk apps, I think Gtk can be ruled out. Orbit is supposedly 3 the fastest CORBA implementation by a factor of 3, even with all the assertions left in. While the X protocol may be somewhat slower than it could be, X is still quite responsive on my old 486.

I now have an AMD K62-450, and GNOME still feels sluggish, about the same speed as Windows 95 on my P75. That has to be wrong. Yes, GNOME probably does more than W95, including things like network transparency, and the like, but even taking that into account, along with Gtk, CORBA and X itself, you shouldn't be looking at more than, say, reducing performance by half, and that's being pessimistic. In reality, you're looking at GNOME being 3 or 4 *times* slower than it ought to be. Simple question: why?

Havoc answers:

This question is really too vague; let me know if my answer is still half-hearted. What is your setup? What theme? What window manager? Is your X server good or is it one of the semi-finished ones? What things are slow for you? Are you actually timing things?

I have a Pentium 166 laptop and GNOME is very fast and responsive. But I do two things:

I use only theme engines, especially the GTK default theme, no pixmap themes. If you use the glitzy themes you pay in speed and memory.

I use WindowMaker or Sawmill, not E.

There are some specific things we know are slow:

• Application startup is slow. This is primarily due to the fact that a GNOME application links to so many separate shared libraries; if we merged all the libraries into one or two giant libraries, you would have many fewer system calls on startup and faster start time. However, there would be some disadvantages from a maintenance/download-size standpoint. We've addressed this problem by changing Imlib to dynamically load libpng, libtiff, etc. on-demand instead of on startup; we'll probably be removing Imlib in the next release. We could probably change things so the sound libraries are also loaded on demand.
• GTK flickers a lot if you have opaque resize turned on. This is a complicated problem that's hard to address; the long term solution is probably to move GTK+ to an architecture like the GNOME Canvas widget instead of the more traditonal toolkit architecture based on X windows. The flicker isn't really slow, but it makes people feel that things are sluggish.
• Some versions of E do some things slowly. For example moving windows around can be slow. WindowMaker is much more consistenly snappy, and Sawmill is nice too. Those are just my preferences, lots of people swear by icewm, fvwm, scwm, etc.
• Some specific applications may be slow for whatever reason - if some particular operation seems too slow, please file a bug on http://bugs.gnome.org.

Anonymous Coward asks:

You are known to be a programmer, and a programmer always has some ideas on languages and tools. What of the currently available languages would be your programming language of choice now? What about two years from now? Why? How would you change it so it becomes the ideal language? What's the worst language you've written something substantial in? How would you change it so it becomes the absolutely most evil language?

Havoc answers:

OK, you are setting me up to be flamed. :-)

I don't think the language is really the primary issue right now. People are interested in the quality of the available implementations, the availability of support and training, the kind and number of useful add-on modules, the documentation, and so on. Basically for any project, you decide whether you need the speed of C/C++, and if you don't you do your best to use a higher-level more reasonable language with a good implementation. "Academic" languages like Haskell and Eiffel, while much nicer languages than Perl or Python or C++ or Java, have implementation issues that often restrict their use.

With the Cygnus/GNU Java compiler, lots of GNOME people are cheering for Java. We even have a good start on the Java bindings for GNOME. Java offers an object oriented environment syntactically similar to C/C++, but has some important safety advantages (no pointers), reduced complexity, and lots of nice libraries.

For rapid application development I like to suggest Python as a sort of "Visual Basic equivalent"; PyGNOME and libglade by GNOME's James Henstridge allow you to write a fairly complex, nice-looking application in a couple days. The Red Hat 6.1 installer is written in PyGNOME.

I've used Guile some as an extension language; the Guile-to-C API is very simple and easy to use. Again, an implementation issue that becomes important.

There's an O'Reilly book coming out about Perl/GTK, I'm told, so I assume those bindings are pretty good. Judging by the list traffic quite a few people are using them.

Anyway I've been playing with Haskell lately and I think there are some practical issues with it, but it's improving and I enjoy it a lot. So if I'm having a language war I like to defend it. But in practice I end up using C to write libraries, if I were writing a high-level tool I'd probably use Python. My largest two projects to date (Guppi and gnome-apt) are in C++. gcj makes me want to have another look at Java. Just use whatever works.

Ian Bicking asks:

There are a ton of preceding and current desktop environments: KDE, CDE, GNUStep, Windows, MacOS, Xerox Star, BeOS, QNX/Photon, and a whole bunch of others.

Are there any ideas from other such environments that you think are really neat? Any ideas that you would like to be part of Gnome, or even plan to try yourself?

Havoc answers:

We do our best to steal shamelessly from all other user interfaces; we have the Mac UI guide and a Windows box at RHAD Labs, as well as KDE installations, and we often look at how these other groups implemented a given dialog or widget. I'm sure the GNOME hackers on the net do the same thing; Miguel is always talking about the latest Excel feature he just cloned in Gnumeric.

In general we want to keep the UI "sufficiently similar to" the windows-mouse-icon model of Windows and Mac, because trying to be revolutionary on this point would be a disaster (read the gnome-gui-list archives if you have any doubts). But we like to add nifty enhancements, such as themes or the GNOME panel. And of course hackers who work on innovative stuff are welcome.

Most of my interface ideas are for particular applications. Having just written a book, I have an elaborate plan for the ultimate document-writing application. But Emacs will have to do until I get some more time. :-)

SEGV asks:

Havoc, how did you find the process of writing a book? Can you tell us more about the process? How long did it take? How did you find the time? What were some of the hurdles you had to overcome? Are you as pleased with the final product as you imagined when you began? Would you do it again?

Havoc answers:

Writing a book involves sitting down for long periods of time and typing. As an activity, that's pretty much what it involves. :-) Well, there's some thought that goes into it.

Seriously. I wrote a "fast book," it took about 4 months. Lots of books are written in well over a year, but I wanted to write a book that people could begin using as soon as possible. If it sells well there may be a second edition sometime after GNOME 2.0 (even without the second edition it will continue to be maintained as part of the GNOME project).

The process is simple. You make an outline and get opinions on it from all your editors and technical advisors, then you revise it a few times. After that you start to write the chapters in the outline; each chapter is reviewed for technical accuracy and writing quality, then sent back to you. You make the suggested changes, then submit the final chapter. After you've done that for all the chapters, you just wait for the book to appear in print. That's about it, modulo some boring details.

I found the time by spending a lot of weekends with my computer instead of doing something fun, and by staying up late some nights. I think in general there is a poor work/pay ratio, so it's important to want to get the information out there, you won't be getting rich on book-writing.

ajs asks:

I hear things about Glade getting sucked into core GNOME libraries as a way of dynamically reconfiguring applications (an ambitious goal!) How much planning has been done for this, and is it expected to impact application performance?

Havoc answers:

Well, we are already using libglade in some applications, such as Gnumeric, and it doesn't seem to be causing a problem. :-)

Glade won't be sucked in, but rather libglade. libglade has about two function calls in the whole library; all it does is load an XML file generated by the Glade GUI builder. It uses the file to create widgets for your user interface. You can avoid writing widget-creation code; you just have to write the callbacks that actually implement the functionality of your application.

There is some amount of performance overhead but it is fairly small and only at application startup time; once you've loaded the widgets, they are just as fast as they would be if hand-coded. There are also some performance advantages:

• You can often halve the number of lines of code in the application itself, thus reducing application size.
• You save tons and tons of programmer time, so hackers can focus on optimizing the truly time-sensitive portions of the application.

If speed becomes a genuine problem we can implement a way to "compile" the XML files into some kind of high-speed binary format I guess. That would be pretty trivial and would avoid the XML parser overhead. But as I said, we're already using libglade in several places and I haven't noticed a speed problem.

Next week: Eric S. Raymond

This week's interview victim ... er, guest ... is Havoc Pennington of Debian and Gnome fame. He's one of the world's most stalwart open source developers, and has recently written a book called GTK+/Gnome Application Development. Please post your questions below. Assorted Slashdot moderators, editors, and hangers-on will select 10 - 15 questions and forward them to Havoc via e-mail Tuesday. Per usual, the complete Q&A session will appear Friday.

Thanks to our own Justin for the review of author Havoc Pennington (excellent name)'s GTK+/Gnome Application Development. Click below to learn more.

GTK+/Gnome Application Development author Havoc Pennington pages 492 publisher New Riders: ISBN 0-7357-0078-8 rating 6.5/10 reviewer Justin ISBN summary Learn how to develop a GNOME application from scratch using gnome-libs and various GNU development tools. Master the canvas, and expand your knowledge of GTK+/GDK/glib while you're at it. The book is released under an open license so that the book will have no problems keeping up to date with whatever is current in GNOME. It is browseable on the web at http://developer.gnome.org/doc/GGAD/ and can be checked out from GNOME CVS - it is in the GGAD module.

The book is not just a simple explanation of gnome-libs. Rather, it is a book meant to take you from beginning to end of a full GNOME application. GGAD starts off just where it should, with a ~50 page review of glib and GTK+. These sections were fairly well written, and I was able to understand them well. Keep in mind, however, that they are not for beginning glib/GTK+ hackers. The internals of how the libraries work are sometimes mentioned and I can imagine them being confusing to the first time GTK+ hacker. More advanced hackers can probably skip most of these sections, but even an intermediate GNOME hacker could gain a better understanding of how glib and GTK+ work.

The next sections discuss topics like what non-code files are required for a GNOME application (Makefiles, .desktop files, documentation, pixmaps, etc.) They are useful, and I thought occupied the right amount of space (not too little, not too much :)

Next comes a chapter I probably expected to come a bit later on. "Gnome Application Basics" is a summary of internationalization, popt, and configuration data. Unfortunately, I found the sections on configuration data a bit difficult to understand, and disliked seeing example code using some of C++'s more advanced features. Now we arrive at chapter 6, the chapter I think most GTK+ hackers looking to get into GNOME development will find most interesting. It is a discussion of the GnomeApp widget, GnomeUIInfo structs for menus, status bars, online help, tooltips, etc. Chapter 7 will probably also be useful to the same people. It is a quick (10 page) discussion of the GnomeDialog widget, and discusses several types of widgets. It well-written and very complete. Finally we have arrived at the last section of the book - "Advanced GTK+/Gnome Techniques". It is definitely for the more advanced hackers in the house. Chapters 10 and 11 are a very intensive (read: decently written chapter covering some slightly obscure topics in a lot of depth) overview of the GTK+ object system and a somewhat lengthy how to on the use of GDK (some parts I think may come in hand, some parts are probably pretty obscure). Chapter 11 is a titled "Writing a GtkWidget" and is well-written, but I question its usefulness to anyone but library developers. Unlike other sections, I felt this chapter had far too much actual code embedded within it (at least in the second half).

Next is a chapter I expect many people have been waiting their entire lives for ;) It is the long-awaited GnomeCanvas chapter. It is a ~25 page chapter which explains how to use the GnomeCanvas widget. The next chapter, Writing a GnomeCanvasItem makes a good counterpart, and the two work well together to teach the use of the canvas. It is a complex widget, so it may be hard to understand, however. I was lost at times, but I think this was probably me and not the book.

And that's most of it. The next 140 pages or so are all Appendices, some I found useful and interesting, others I found boring and skippable. However, I really must say that Appendix C, "Frequently Asked Questions", was very good and one of my favorite parts of the book :) The only remaining disappointments I had were the fact that the book was aimed towards very advanced developers (which was probably the major disappointment for me), and that libxml was not covered in at least small detail. I know that not everything can be covered, but XML is becoming central to many parts of GNOME.

Purchase this book at Amazon

1. Overview
   1. Introduction
   2. glib: Portability and Utility
   3. GTK+ Basics
2. Building a Gnome Application
   1. Creating Your Source Tree
   2. Gome Application Basics
   3. The Main Window: GnomeApp
   4. User Communication: Dialogs
   5. Gnome Applicatio Checklist
3. Advanced GTK+/Gnome Techniques
   1. The GTK+ Object and Type System
   2. Gdk Basics
   3. Writing a GtkWidget
   4. GnomeCanvas
   5. Writing a GnomeCanvasItem
4. Appendices
   1. GTK+/Gnome Object Hierarchy
   2. Table of Header Files
   3. Frequently Asked Questions
   4. Online Resources
   5. Code Listings
   6. Open Publication License Version 1.0

Mandrake, AKA Geoff Harrison, is a heavy contributor to the enlightenment project and has also left his mark on Gnome, XFree86, and a bunch of other excellent free software projects. In real life, he works for VA Research as (surprise!) a software developer. Mandrake is, without question, one of the leading lights of the Linux and free software development communities. Check his Web site, and post any question(s) you have for him below. Answers to most or all of the highest-moderated ones will be posted Friday.