Slashdot Mirror

An anonymous reader writes "For many of us our hosting providers are a way to hone our skills as well as run a business. Which provider out there gives the best bang for the buck for a FOSS developer? Virtually everybody provides Perl, PHP, Ruby, MySQL / MariaDB etc. but where can one get easy and cheap access to a stuff like NodeJS and Big Data? Companies such as Pair Networks are great but not quite on the mark with any of their service offerings for somebody looking to test out real world scenarios with these technologies from a hosted stance. Obviously hosting from home is always an option but that has the penalty of administration, backup, DR planning, bigger security footprint etc. and for those of us whose time is balanced between making money and friends / family time that's not very appealing."

An anonymous reader writes "For many of us our hosting providers are a way to hone our skills as well as run a business. Which provider out there gives the best bang for the buck for a FOSS developer? Virtually everybody provides Perl, PHP, Ruby, MySQL / MariaDB etc. but where can one get easy and cheap access to a stuff like NodeJS and Big Data? Companies such as Pair Networks are great but not quite on the mark with any of their service offerings for somebody looking to test out real world scenarios with these technologies from a hosted stance. Obviously hosting from home is always an option but that has the penalty of administration, backup, DR planning, bigger security footprint etc. and for those of us whose time is balanced between making money and friends / family time that's not very appealing."

Nat Friedman often seems to live in the shadow of his famous coworker, Miguel de Icaza, but today it's his turn to shine. You asked Nat questions last week. This week he answers, in detail, with lots of links, touching on subjects ranging from Gnome's future directions to how Microsoft is dealing with Linux as a competitor to Windows. 1) Exchange Like Product
by Kaypro

Currently the Exchange Connector seems to integrate quite well, are there any plans to create a standalone server with similar capabilities to Exchange Server?

Nat:

There are no plans today, but it's a really appealing idea.

Ximian's goal is to enable corporations to deploy and use open source-based desktops. One of the major barriers to this happening today is interoperability with the rest of the corporate computing environment. In the world we all inhabit, that means interoperability with Microsoft products.

When we were doing some product planning and market research early last year we found all these cases in big companies where people had to have two computers on their desk: a Unix machine for their real work -- development, CAD/CAM, 3d rendering, etc -- and a Windows machine so that they could speak all the protocols and file formats that the rest of the office speaks. And we were like: this just ain't right.

In many of these cases, when we asked people, they said that what was keeping that Windows machine on their desk was not, as we expected them to say in all cases, Word or Excel or Powerpoint, but it was actually in many cases Outlook. What happens is that the IT department will proclaim from on high that Exchange is the corporate scheduling standard, and if you ever want to coordinate a meeting or to schedule time in a room or with a projector or any other resource, you have to use Exchange, or you're simply out of the loop.

So this was a situation where providing this functionality under Linux eliminated the need for that Windows machine. This is a clear financial win for the customer and a clear win for the open source desktop. Basically, the Connector was a really obvious product to build.

Will we ever build a collaboration server of our own? It is something we've had some requests for before, and of course we're always listening to our customers and users, but we have no plans to build one today. Tell you what, if you would be interested in paying for such a thing, send email to sales@ximian.com and let us know. :-)

2) Microsoft and Mono?
by zoward

Have you gotten a sense of how Microsoft views the existence of an open source alternative to .NET? Do you think that, over the long term, Microsoft will grow to love, ignore or loathe (and perhaps seek to undermine) Mono?

Nat:

Open source software is a threat to Microsoft's business model, and it is a competitor which they cannot attack with their traditional maneuvers. At the same time, the events of the past seven years, especially the emergence of the web, Linux, Java and XML, have shown Microsoft the marketplace power of open standards. For these reasons, Microsoft's posture toward Mono and similar projects can be hard to gauge.

But the fact is, Linux and other open source efforts are a source of competition for Microsoft, and that is why they are investing 25 million dollars with Unisys to discredit Unix: they are once again facing competition, but this time there is a united front of users and companies around the globe that opposes them. Open source has given the world a common ground.

At the O'Reilly Developer Conference last year on a panel with Michael Tiemann, Tim O'Reilly, and others, Craig Mundie, Microsoft's CTO of Advanced Strategies and Policy, said (I am paraphrasing): "The thing Microsoft does not like about the GPL is that it creates a closed community." Yes, he actually said this, and while the entire audience sat stunned and struggling for oxygen, I remember Tim O'Reilly did not miss a beat, responding with "But so does Microsoft!"

Mono is an open source implementation of the C#, CLR and CLI cross-platform development framework that have been submitted to ECMA for standardization. We are implementing this framework because we believe it is important technology, and that the world should have a free, standards-compliant version of it.

Microsoft wants the ".NET platform" to be adopted, which is why they submitted it to ECMA. Whether or not Microsoft will change their minds, retract their submission, and decide that they do not like Mono is not something I can predict, but if they do, we are ready to adapt to the change and ensure that this technology is available to the world.

3) Core Gnome technologies
by wrinkledshirt

Despite its relatively short lifetime, Gnome's been really great about embracing all sorts of different technologies -- gtk, ORBit, bonobo and now Mono. However, it's sometimes difficult trying to figure out how this all ties together (if it's supposed to at all). Generally speaking, if someone's going to want to develop for Gnome in the future, how should they prepare themselves? What should they want to learn?

Nat:

Actually, the goal of the infrastructural work in GNOME is to abstract all of the underlying technologies away from you so that you can focus on writing your application. We want you to feel the joy of being able to sit down and easily build something, not to hand you a whole bunch of new stuff to learn.

Nowadays GNOME application development can be done rapidly and easily using Python or Perl and the Glade GUI construction tool.

For a lot of people, these languages and tools are the best way to build an application. The GtkPerl site has an example of a GNOME panel applet written in just 60 lines of Perl (and I'm sure it could be done in less). Not everyone knows that Anaconda, the Red Hat Linux installer is actually written using PyGtk.

Using Glade to create your user interfaces not only frees you from the arduous task of manually doing all of the widget creation and packing, it also makes your application more flexible because the GUI layout is loaded at run-time from an XML file. For the GNOME project this has been really helpful, since it means that a lot of UI design and prototyping work can be done without the need to even touch the code.

If you want to learn more, developer.gnome.org has a pretty good overview of the GNOME architecture.

All of the GNOME technologies that you've heard about work under the hood to provide consistency, configurability, and scripting features that you, as a programmer, only come into contact with if you need them. The goal, to steal directly from Larry Wall, is to make the easy things easy and the hard things possible.

For example, you might (or might not) have heard of Atk, Gail and at-spi. These are accessibility ("a11y") technologies that are in GNOME 2 to make it possible for applications to be used by people with various kinds of impairments. But you do not need to be exposed to any of the details of CORBA in order to use them, and in fact, some of the a11y features come for free just from building your application using GNOME 2.

By the way, I happen to think that accessibility is a killer feature in GNOME 2. At GUAD3C, Marc Mulcahy gave a great demo of how a sightless person can navigate the desktop using a screen reader. And we have been working on a set of accessible icons for GNOME 2 as well. There are cool side effects too: Because GNOME's accessibility infrastructure is done programmatically and at the widget level, you can actually attach to a remote running application and introspect and act on its widget tree. This may make it possible for us to eventually have a very high-quality automated UI testing tool.

Check out the GNOME Accessibility Project web page for more information.

As for Mono, it is still a technology under development, and the GNOME project has not made a decision to adopt it in any way yet. Work on C# bindings for Gtk is progressing, however, so you will be able to write Gtk and, eventually, GNOME applications in C#.

4) Usability research
by nakhla

One of the big problems facing GNOME and other open-source software is that of ease-of-use. Microsoft and Apple spend millions of dollars when developing new operating systems or UIs in order to ensure that their product is easy to use for the non-geek end user. What kind of useability studies has Ximian conducted? What is Ximian doing to correct any problems that the research has brought to light?

Nat:

Ximian and the GNOME project have learned from standard, existing industry practices for building usable software. In short this means designing for usability, performing formal usability testing on real users, and treating usability problems as first-class bugs.

The GNOME Usability Project is a nice central resource for a lot of the usability work that has gone into GNOME. Recently the project has been making a lot of progress on the GNOME Human Interface Guidelines, a set of UI rules that will help GNOME achieve much better consistency in its user interfaces. The results of the comprehensive GNOME desktop usability study that Sun performed last year are worth a read, too, even if we've already overcome a lot of that stuff in GNOME 2.

In the course of the design of Evolution 1.0 and 1.2 (due out this summer), Anna Dirks, our UI designer, performed many dozens of usability tests on various parts of Evolution, using a wide variety of people with varying degrees and types of experience using computers. Anna delivered a nice talk on the usability testing process at the GUADEC Conference

An application's usability is directly related to the ease with which a user can predict its behavior when he gives it input. This is why usability testing is a productive activity. In its basic form, it goes like this:

1. Create a prototype of the interface you are designing. In some cases prototypes are created using "scripting" languages or "RAD" tools, and sometimes they are just printed onto "paper." This last type is called a "paper prototype," the name deriving from the "paper" on which it is printed, and the fact that it is a prototype.

2. Coerce an appropriately representative set of individuals into participating in the usability test. The use of lethal force may be necessary.

3. Ask the user to perform a certain task, using the prototype.

4. Observe and record the steps the user takes, with particular attention to his mistakes.

5. Rinse, lather, repeat.

The fundamental premise of the usability test is that the user has certain expectations of how a given interface will behave, and the thing that a designer must do is to identify the places where his interface does not conform to those expectations, and to fix them.

At Ximian we've gotten subjects for our usability tests from a variety of places; there's a movie theater downstairs from our office and sometimes we'll hang out there and offer people free movie passes to participate in usability tests. So we get a pretty broad audience.

All usability issues that arise during a usability test are filed as bugs in bugzilla alongside other issues, and of course the subject's comments inform the revised design of the interface in question.

For GNOME 2, we decided to revamp all of the GNOME stock icons to improve their consistency, usability and to brighten up the style a bit. Ximian has contributed all of these new icons back to GNOME; you can check them out on developer.ximian.com.

Havoc recently wrote a nice piece which covers UI design in free software, and in GNOME in particular.

5) Conflict of Philosophies
by polyphemus-blinder

I would like to know:

What is your take on the apparent paradox resulting from:

1. the goal of uniformity on the Linux desktop, and

2. the many, many, groups who have this as their own special goal?

Mandrake and RedHat work toward this on the OS level, and Gnome and KDE battle it out on the desktop integration level, and many others espouse some sort of a "grand unification theory" of Linux.

Do you subscribe to the theory that less is more, or that multiple groups with a common goal will result in the goal's earlier acheivement?

Nat:

In any large-scale human endeavor, consistency is a very difficult goal. I once heard a senior Microsoft project manager express the goal of consistency in software thusly: "A program should look as if it were written by one person." This is a thing that everyone struggles with.

To give you a short summary of my answer:

(1) Consistency is hard.

(2) Decentralization and parallel development are inherent to open source software.

(3) Open standards and making an effort to work together are key. Let's try to do more of that.

Consistency in software applications means fewer surprises, a gentler learning curve, and being able to get your work done without tripping over an application's special quirks along the way. This is especially true of the interfaces that the application exposes.

For human interfaces, consistency means that the elements of the application do what the user expects them to do, and that the interface, consequently, does not get in the user's way. This means that a dialog's Close button is always in the same place, the menubar always appears at the top of the window, and Ctrl-Q always quits. Usability flows predictability which flows from consistency.

For programming interfaces, or APIs, consistency means that the methods you invoke have predictable characteristics: similar naming, the same memory management semantics, the same return values in an error condition. This means cleaner code, less time spent hunting through documentation, and fewer bugs.

So we can agree that consistency is a good thing. Two things are needed to achieve it: a standard, and a way to enforce that standard.

In more centralized environments, such as companies, these things are easier to do. It is naive to think that any company, even Microsoft is fully centrally controlled, but it is certainly much easier to enforce a single standard on people when you are paying them, and when you have editorial control over the final product.

But even with a single, documented standard and even if you are paying people's salaries, consistency does not come easily, even in the most centralized environments. At one point Microsoft had at least nine separate internal implementations of SOAP, and only recently have these all been consolidated...into four.

So how on earth do we achieve consistency in a decentralized environment? Given that starting your very own open source "project" is a matter of a few clicks on sourceforge, how do we "prevent" people from creating applications that do not adhere to some common set of ideas as to how they should behave? Given that there is no central control of what happens in the open source desktop world, how can we even create a standard that we all agree on?

I remember when Mac OS X first came out, people asked a lot of similar questions: How can we ever create an interface that is as consistent as this in our weirdo free code, free love, gift economy, bazaar-inspired noospheric environment?

This question can be considered at different scales: how can consistency be achieved within a single project, and how can it be achieved in the open source world in general.

And this issue of decentralized development comes up in other guises as well. In addition to bemoaning a lack of consistency, people talk about duplication of effort and fragmentation. They say things like: "If only we could focus all of the energy that has gone into producing all of the IRC clients in the world on building just one IRC client, think how awesome it could be!" People really say this sort of thing. I have heard them.

And, of course, there are those in the press and on the mailing lists who see this very same pattern in what they call the "GNOME vs KDE wars" or "the desktop wars." This is the "How many Linux distributions can you count?" conundrum.

Many people who are much smarter and better looking than I have responded to this question at various times.

Linus has said that he believes that in the Linux development community today, there is a "psychological barrier to fragmentation," and that this barrier is the learned result of the Unix wars of the 1980s.

Alan Cox has said that implementation fragmentation is not important, as long as care is taken not to break interface compatibility. The important thing, quoth Alan, is the existence and adherence to open standards. And Eric Raymond has pontificated at length about how it is the nature of the open source community, when confronted with a problem to solve, to try "all solutions at the same time." That is, I think Eric would tell you, the nature of the open source world, and, in many ways, its greatest strength. And of course, Eric is right. Seriously, I love that guy.

If on an iron-gray fall day you have looked up and seen a dark spot moving against the sky and changing shape and size but still moving smoothly in one direction and then it came closer and when you looked you could see the individual birds flapping their wings and shifting forward and back in the formation and alternately turning against and away from each other but still somehow moving all together as one mass, I think you have seen something that resembles the greater open source development community, if there can be said to be such a thing.

The thing that the birds are doing is called "flocking," and today the problem of flocking is still an interesting issue in algorithmic circles. The basic scenario is that, with each element in the flock making its own individual movement decisions based on its own individual and unique sensory input of what is happening immediately around it, the flock must somehow move along a single path, as a whole. The analogy of the Boids flocking algorithm actually runs deeper than you might expect; check it out sometime.

What is important in open source software is doing the actual human work of getting people together and creating the open standards that will allow us to function as a group, and to move in the same direction. And the way to do that is through open, shared standards.

I'm not talking about a kind of abstract standards process where an aesthete group of monks argues for centuries in the thin mountain air about file system standards before descending with etched tablets, but a process where implementors agree on good-enough standards of existing practices in the places that matter, today. Standardization is a way for us to align our directions, maintain implementation distance, and follow a common flight path, not an end in and of itself.

The thing to recognize is that the problem of creating a consistent desktop experience and the fact that our approach is a multi-pronged, decentralized, evolutionary one do not have to be at odds with each other. The key to consistency is to work toward it.

6) As a business
by Fizzlewhiff

Is it frustrating to see potential revenue lost due to offering the same products for free? Do you ever run the numbers to see what your income potential might be if you stopped giving away the same software you sell or do you believe that the Linux community, as a whole, cannot and will not support companies who only sell Linux software?

Nat:

If in the last two years we hadn't put out approaching 2 million lines of GPL'd and LGPL'd code, we would not have nearly the success that we have today.

If you're going to run those kinds of numbers, you should also calculate:

1. How much extra would you have to spend on development in order to compensate for the fact that you will no longer have the help of a large community of testers, translators and hackers?

2. How much do you have to spend on marketing to even reach the same level of name recognition you can achieve by being a responsible, active open source software development company? Would you have the same amount of credibility?

During the several months that preceded Evolution 1.0, we averaged around 10,000 daily downloads of the Evolution snapshots, and many of the downloaders were actively reporting and fixing the bugs that they found. How much would it have cost us to manually test Evolution against the wide variety of IMAP, LDAP and Palm devices that the Evolution codebase was exposed to by this army of users?

This kind of thinking may sound cold and not particularly ideological, but if you're going to perform one kind of calculation, you gotta do them all. I have actually heard of open source companies sitting down and working out the second, marketing calculation, and including it in their business plans as a rationale for writing free code.

7) Co-existance of Red-Carpet and up2date/RHN
by yusufg

Hi, Red-Carpet seems to offer functionality similar to up2date/redhat network. However, there seems to be a very substantial lag between packages made available via Ximian's redhat channel and up2date.

An example being (till now, RPM 4.0.4) is not available via the Redhat 7.2 channel. Is Ximian going to ever make a policy statement as to what is the maximum duration their userbase will be diverged from receiving the latest updates of their respective distributions.

If there are specific packages which are likely not to be made available via red-carpet, can their be an official statement on this so that users are aware of the pros/cons of using multiple update mechanisms?

Nat:

Our policy is that all distribution and third-party updates are made available through Red Carpet as soon as they can reasonably be pushed without breaking other software for the user.

For example, with security updates, these are always made available as soon possible, often within just a few hours, always within a day.

With something like the RPM 4.0.4 update, however, sometimes we have to lag behind the upstream provider, in order to ensure compatibility. This does not mean that we hate Red Hat or that we do not care about users, or that we are lazy.

In the particular case of RPM, new releases of RPM often break binary or database compatibility with old versions (this was true with 4.0.4), and so we are cautious about making these available to users until we have first ensured that Red Carpet will continue to work on your system. I am not trying to pass the buck to Red Hat here. They are great people. Our userbase, in running Red Carpet, just happens to have a different set of needs than Red Hat's, and this is what, in the case of RPM 4.0.4, created the delay you noticed.

To answer your second question, as long as the packages that are shipped by the upstream providers are open source, and as long as we can legally redistribute them, we will make them available via Red Carpet.

8) Lack of documentation for GNOME internals
by Tet

Are there any plans to increase the amount of documentation on GNOME internals? While GNOME seems to have plenty of trivial documentation (such as the GNOME User's Guide [redhat.com], there's virtually nothing that explains what's going on underneath. Are there any plans for a "GNOME Administrator's Guide"? I'm thinking of something that documents usage of files in $HOME/.gnome, what session management is and how it works, what controls the contents of the GNOME menu, and so on. For example, when GNOME fails to correctly save session information, I'd like to be able to check the documentation to see what should be being written to .gnome/session. At the moment, I just have to guess. Some of it is reasonably obvious from context, but it's the sort of thing that really needs formally documenting.

Nat:

So, for a lot of the stuff you're talking about, the documentation is out there. If you want to learn about the session manager and how to configure it, check out the man pages for "gnome-session" "default.session" and "save-session". There's also a white paper covering a lot of the configuration files, though it is out of date. Collecting and updating all of these things into a single "GNOME System Administrator's Guide" sounds like a great idea for a project for someone :-).

The GNOME Documentation Project and the individual efforts of developers and users have produced a large amount of documentation to date. In addition to the GNOME User's Guide that you mention, there is the user's manual work that Sun has been doing. There is also a lot of developer documentation on developer.gnome.org, including some useful tutorials and white papers.

With all of the large vendors that are shipping GNOME on their workstations, I think it's a safe bet that the components of an administrator's guide will come together in the near future. I know that, inside Ximian, we have recently written for a customer some documentation specifically focused on issues that would be interesting to system administrators, and naturally we will be working to release this to the community at some point soon.

Of course, if you or anyone else out there wants to join up with the GNOME Docs team and start assembling such a guide, you would be welcomed with open arms :-). If you don't have time to do that, you can contribute by filing bugs in bugzilla.gnome.org whenever you find problems or missing pieces and by contributing fixes to the individual projects. Check out the gnome-doc-list mailing list for more information on how you can help.

9) Why subscribe?
by JThaddeus

I was considering subscribing in order to improve the performance of downloads (which have gone to a snail's pace since the subscription program began) but two out of three of my last update attempts have ended in file not found errors. This type of error doesn't give me confidence in how well RedCarpet setups are tested. So why shouldn't I just forget about subscriptions and go with KDE?

Nat:

Without more information, I can't say exactly what the problem is that you were experiencing. That type of issue can sometimes happen if you're updating from one of our mirrors that is in the process of syncing from our master site.

I can tell you that we do directed testing on all updates that are pushed to Red Carpet, on every single supported platform, before an update is released. Additionally, we pay close attention to the bug reports that our users file in our bug tracking system, and make an effort to address all of those as quickly as possible.

Just last week we released a new channel in Red Carpet called "Untested," which contains the pre-QA versions of all of our Ximian GNOME updates before they hit the main channel. Similar to the Mandrake Cooker or Debian unstable, this is a way for the update junkies of the world to get an early glimpse at new packages and versions before they hit the official channel. And of course, this is a way for us to get broader user testing and resolve problems earlier.

Also, by the way, the bandwidth we've allocated to our free public Red Carpet servers has been steadily increasing since the launch of the subscription program. If the servers have gotten slower, it's because the user demand keeps increasing.

But whatever your experiences with Red Carpet, they should not be brought to bear on your choice of desktop. Red Carpet is a software management service that is independent of your choice of desktop or web browser or editor or whatever. And because the Red Carpet client is statically linked, you don't even have to have GNOME installed to use it. In fact, about 20% of Red Carpet usage is by people who want to get updates to the packages provided by their distribution, not Ximian GNOME.

10) External Compatibility
by dspeyer

What plans do you have to improve compatibility with the non-GNOME world?

For example, do you think it's practical to implement Xaw as a front-end to GTK? That would get OpenOffice integration real fast, among others. What about a unified theme format with KDE? Or a common protocol for copy/paste?

It seems like this sort of stuff would be really helpful -- what's actually in the works?

Nat:

Compatibility actually has less to do with an application's choice of drawing toolkit than you might think. Of course, there's nothing to prevent you from running a non-GTK application in GNOME, and it's not necessarily the case that the user experience is hugely degraded if you do. I know of a lot of KDE users who started using Evolution in the last couple of months, because the functionality is so rich, which is great.

GNOME and KDE have had drag-n-drop and cut-n-paste interoperability for quite a while, and we also use the same .desktop file format to store launchers and menu items. You can track a lot of this stuff at freedesktop.org.

Open Office does not use Xaw. That being said, it would be great if OpenOffice used the Gtk drawing primitives so that OpenOffice would be theme-compatible with GNOME. It would not be a total integration, and the behaviour might still be different, but it would help the desktop to look more like a single unit. In fact, it would be possible to get Qt to use Gdk as well, which could make shared themes possible there too.

Another step would be to adopt a common set of icons; baby steps like this can improve visual harmony a lot, even if the "compatibility" is only at a very superficial level. These first steps could be followed by deeper integration, like a working bridge between Bonobo and Uno, the OpenOffice component system.

A unified theme format with KDE would probably be difficult, having a theme or set of core themes for GNOME and KDE which looked and felt the same on both would be a nice step toward making the desktops more compatible to the user. There have been noises made recently that this kind of thing is a possibility, and Ximian would be fully supportive of that.

Though these surface integration steps would be nice, the area where inter-project compatibility is most badly needed is configuration. If someone is running a mixture of GNOME and KDE applications, Mozilla, OpenOffice, and older Xtk-based programs, they need to be able to make configuration changes that are reflected in every application. Having to go to N different places to set your default URL handler, theme, or MIME type bindings is a real usability problem. Jim Gettys talked about this a lot at the most recent GUADEC. Keith Packard's recent fontconfig work is an excellent example of this.

Andrew writes: "My host pair.com has an interview with Damian Conway in which he talks a lot about his upcoming modules, and what skills a Perl programmer needs. I'm personally waiting on Parse::FastDescent." Conway talks about some interesting modules he's working on, Perl 6, and on programming in general, too.

Andrew writes: "My host pair.com has an interview with Damian Conway in which he talks a lot about his upcoming modules, and what skills a Perl programmer needs. I'm personally waiting on Parse::FastDescent." Conway talks about some interesting modules he's working on, Perl 6, and on programming in general, too.

Slashback brings you updates tonight on book reviews past, intentionally defective CDs, failing disk drives, and joining the HURD. Enjoy!

Spin control for some IBM drives? If you are one ofthe people who have the same results with IBM 75GXP hard drives that Sean Kelly did when he posed a recent Ask Slashdot, you may be interested in this report from legLess, who writes: "Pair Networks is swapping out every IBM 75GXP hard drive they have "[b]ased on an amazingly high failure rate." Pair is a big host: 114,000 sites all running on FreeBSD 4.1.1, including cdrom.com and Tom's Hardware. "We currently use and recommend Maxtor drives" they say. Big black eye for IBM."

GNU isn't Linux, either. Amid the stream of recent and upcoming software releases (Suse 7.3, Red Hat 7.2, Qt 3.0), it's sometimes easy for projects with smaller followings or more esoteric goals to get lost. BorrisYeltsin writes: "The Debian HURD iso images are now available from your local ftp.gnu.org mirror. There are 3 iso's available, so get downloading now!" (And read through the recent months' on the HURD Kernel Cousin too.)

Update: 10/16 14:20 GMT by T : Please note that the GNU Project maintains a list of ftp mirrors -- look for one local to you for best results all around :)

Placing warning signs along the road to consumerism brigc writes: "Good interview in the Chronicle of Higher Education with Jessica Litman about changes in the copyright arena since the publication of her book.

For those who were asleep, Litman's book 'Digital Copyright' does a good job of discussing why the copyright process got handed over to the industry and Congress has failed to protect the rights of the public."

Litman's book got a rave review from Michael a few months back; I suggest you check it out, and better yet ask you local library to put it up on display. Libraries have a strong vested interest in not ceding all control to copyright holders forever and ever amen.

It might pay to have a big fat mouth and ask for a refund on defective merchandise, too. anonicon writes: "Here's a heads up to the web site I'm running at http://www.fatchucks.com. I've started both a Corrupt CDs list for people who wish to report 'copy-protected' CDs or find out which ones they are, and an Indie Rec for people who want to recommend independent artists to the public. Thank you."

Slashback brings you updates tonight on book reviews past, intentionally defective CDs, failing disk drives, and joining the HURD. Enjoy!

Spin control for some IBM drives? If you are one ofthe people who have the same results with IBM 75GXP hard drives that Sean Kelly did when he posed a recent Ask Slashdot, you may be interested in this report from legLess, who writes: "Pair Networks is swapping out every IBM 75GXP hard drive they have "[b]ased on an amazingly high failure rate." Pair is a big host: 114,000 sites all running on FreeBSD 4.1.1, including cdrom.com and Tom's Hardware. "We currently use and recommend Maxtor drives" they say. Big black eye for IBM."

GNU isn't Linux, either. Amid the stream of recent and upcoming software releases (Suse 7.3, Red Hat 7.2, Qt 3.0), it's sometimes easy for projects with smaller followings or more esoteric goals to get lost. BorrisYeltsin writes: "The Debian HURD iso images are now available from your local ftp.gnu.org mirror. There are 3 iso's available, so get downloading now!" (And read through the recent months' on the HURD Kernel Cousin too.)

Update: 10/16 14:20 GMT by T : Please note that the GNU Project maintains a list of ftp mirrors -- look for one local to you for best results all around :)

Placing warning signs along the road to consumerism brigc writes: "Good interview in the Chronicle of Higher Education with Jessica Litman about changes in the copyright arena since the publication of her book.

For those who were asleep, Litman's book 'Digital Copyright' does a good job of discussing why the copyright process got handed over to the industry and Congress has failed to protect the rights of the public."

Litman's book got a rave review from Michael a few months back; I suggest you check it out, and better yet ask you local library to put it up on display. Libraries have a strong vested interest in not ceding all control to copyright holders forever and ever amen.

It might pay to have a big fat mouth and ask for a refund on defective merchandise, too. anonicon writes: "Here's a heads up to the web site I'm running at http://www.fatchucks.com. I've started both a Corrupt CDs list for people who wish to report 'copy-protected' CDs or find out which ones they are, and an Indie Rec for people who want to recommend independent artists to the public. Thank you."

jacobito writes "Perhaps this hasn't been posted because it could ignite a flame war, but here goes: The gnome-hackers list has been the center of some high drama lately. Martin Baulig, the Gnome 2.0 release coordinator, resigned this weekend due to disagreements over the use of bonobo-conf versus gconf and his license to implement architectural changes more or less unilaterally. Through the ensuing melee, fingers have been pointed both at individuals and at corporations, harsh language has been used, and at one point Miguel de Icaza made the memorable proclamation "You can now flame me, I am full of love." Really, though, neither the bickering nor the technical details are what make this affair newsworthy--what is exciting about this is watching a decentered, non-hierarchical, mostly-cooperative group of talents work through the process of getting along with each other and settling disputes, all without resorting to imposing a single dictatorial will upon the group (so far). To that end, Havoc Pennington has posted a draft of a Gnome Enhancement Procedure to provide a structured change process which will hopefully prevent future flamefests. Good reading."

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.

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.

phred writes "In yet another sign of advanced corporate megalomania, Chris Clough, a spokesman for Network Solutions, Inc., is quoted in an ABC News online story as claiming that the whois database is a proprietary product of NSI and is being provided to the net as a "community service." (This item first noted Tomalak's Realm)." And I for one am oh-so-pleased that NSI is using their property to Spam us with commercials about NSI so that they can protect their butts when they lose their monopoly.

tj jones writes " This article claims that the big music industry will be the losers and that independent labels and unknown musicans will be the winners. It also says that what is needed is a more secure way of storing music other than mp3. Expect to see a secure format from microsoft(ack) that will handle all types of media. Five bucks says it won't be an open format. "

I fell across a website which summarises nicely why I have so many difficulties with Windows. It's not that I'm a console biggot, since I was very impressed both by the original Mac and the NeXT. Rather... it's do to do with the logical consistency of the interface, be it GUI or console. I'm posting it not for its "Bash Microsoft value", but for the use it might give anyone coding a new program with a GUI: designing an interface is not just an issue of throwing in every good idea you might have. Anyone else have any other similar sites out there worth having a look at?

DX writes "I have been reading how Tom was taking a portion of his site to a subscriber system. People were not reacting well. Now the main page has a crazy password auth on it..." Cool site. Too bad, but web sites need to make money to survive (first hand experience here) and people hate banner ads with a passion (dozens of emails a week over here to prove that too) so some sites have no choice to go subscription-based. I won't do pay-for-access here, I hate them with a passion, but peoples opposition to banner ads drive sites to subscriptions. That blows- if the ~15 sites I visit daily went to subscriptions, I couldn't afford to subscribe to all of 'em. Besides, subscribing is a hassle... I want my clicks to go straight to a page without any registration or subscription hassles. I'll take a banner ad on a free page over a subscription any time. What do you guys think? Update Andrew Shugg wrote in to tell us that the old URLs are subscription based, but Tom's Hardware.com is going to remain free, also Tom has written A Letter addressing the fuss.