Miguel de Icaza On GNOME 2.0

Dan93 writes: "Here is an article on what is planned for GNOME 2.0. Pretty interesting stuff such as GNOME VFS, and the cleanup work that is supposed to fix every known architectural problem in GNOME." Also, I heard at LWCE as well from the Eazel folks that by this point in the evolution (ha ha) of GNOME, the nearly-ready-for-prime-time Eazel desktop will be included as well.

Comments

Nautilus really ready for primetime?

[Alan]

I've been running the latest CVS snapshots (debs) of nautilus and IMHO it's not ready for primetime. Unless they have a LOT of debugging code still in there, it's just too slow.

On my P3-550/256 it runs slooooooooooow, from starting up, opening new windows, rendering files in a directory, etc. Yes, turning off the "extra sweet" icons helps things, but should this really be needed? What sort of machine are they aiming for?

Now I don't use nautilus that much, or gmc for that matter, because if I want to do file maintenance I'm more comfortable doing it on the command line, but that's just me. However, one of the reasons that sawfish, and gnome is good (IMHO) is that it doesn't require huge amounts of hardware. Now if suddenly nautilus goes in and requires a P3 just to run at an acceptable speed, suddenly down comes gnome (for the people who are installing for the first time anyway, or who don't know how to disable nautilus or replace it with gmc).

Don't get me wrong, I think it's a pretty cool file manager, I just hope that by the 1.4 release it's not the ram/cpu sucking pig I've seen it to be.

Re:Nautilus really ready for primetime?

[ikekrull]

5 seconds to open a a window with only one hundred items???

Thats terrible performance.. I would expect, on a P2-class machine, to be able to open a window with a hundred items near-instantaneously.

How long does it really take to do a 'ls -l', parse the result, determine which icon to display for each file, do a visibility check to see which icons need to be shown, render the visible icons/text with antialiasing and bitblt the result into a buffer?

Consider a game like Quake 3 - Q3 needs to do a similar operation - determine where you are in a large indexed structure, manage caching and loading texture images - analogous to icon images, perform visibility detection - i.e. mark what you can't see in your window so time isn't wasted displaying it, render the resulting image using various compositing aids - texture interpolation, perpective correction etc. and bitblt the result to a framebuffer.

Except Q3 can do this at least 30 times a second, and can go much, much faster than that with better hardware.

Of course Q3 uses accelerated graphics, but if software-rendered Quake 2 had a framerate of .2 fps on a Cele-466, i doubt they would have sold many copies.

The number of instructions per second a C-466 can perform is astounding, how do they manage to misuse so many of them?

Re:Nautilus really ready for primetime?

[be-fan]

What exactly is the XML snapshot used for, and why does it take so long to list the whole filesystem?

Re:Nautilus really ready for primetime?

[be-fan]

5 seconds is too slow for me to apply a filter to a graphic, much less open a folder! I think the Alex St. John (DirectX Evangalist) said it very well. "How can they [Microsoft] manage to make IE visably refresh drawing some text and graphics when Carmack is spewing tons of AI-driven monsters on the screen at 30fps?... (some not-so-nice comments about MS programmers follow)" (BTW, this was before hardware acceleration was common!)

Re:Nautilus really ready for primetime?

[be-fan]

Oh, you mean kinda like BeOS's attributes in a slower, clunkier, less efficient manner?

Sorry, had to get the plug in there. Actually, I believe that XFS (which, BTW is as fast as all hell) already has attributes and ReiserFS is getting them soon, so we can soon get rid of clunky hacks like this.

Re:What do you mean what a pity??

[RPoet]

1) Yes, but there's an accompanying cultural tradition that doesn't involve strict release schedules like corporate culture does.

2) I never claimed they did.

3) You're referring to "release early, release often". That's The Cathedral and the Bazaar, not Slashdot.

--

It's not a big deal, or even new ....

[taniwha]

KDE has done the same for a long time (pre 2.0) to provide this sort of network transparency ... I read between the lines here to see the Gnome mob checking a bullet on their "KDE feature list" in the ongoing KDE/Gnome mini-conflict (unlike many I don't think this competition is a bad thing - having KDE continually raising the bar for Gnome and vice-versa means we all win)

Re:What do you mean what a pity??

[Error27]

1) Actually the term "open source" has more to do with releasing the source under an open source license.

2) And besides gnome didn't decide to "aim low" read the article more carefully.

3) Another slashdot philosophy is "release early and often."

Both

[bockman]

Projects as large as Gnome (or KDE) should follow Linux (or Debian) example and split in a Stable branch ( doing small changes/fixes/cleanup and keeping users happy on short-term ) and an unstable branch ( pursuing the 'blue sky' goals ).

Not that it solves all problems they have (for instance, which branch should adopt GTK 2.0 ? ), but it should help. The only problem : has Gnome enough developers to do it ? .

Re:Both

[rgmoore]

However my feeling is that the 'stable' version, once released, is left to itself. At least, I never read of Gnome 1.2.x ( that is a version with the same functions of 1.2 but with more bug fixing ).

That's only because GNOME is a tied set of components, rather than a monolithic system. When they moved to GNOME 1.2, they upgraded all of the components at once, but since then they've patched each part independently as needed. There hasn't been a GNOME 1.2.1 (or 1.2 SP1), but there have been gnome-core-1.2.1, gnome-libs-1.2.1, etc. Different components have different patch numbers now because they've required different amounts of patching, but IIRC every single component has undergone some minor changes since 1.2 was released.

Re:Interesting comments on KDE 2.0 and Konqueror

[rgmoore]

But this is a reasonable complaint. He makes several comments that IMO are right on the mark. There are a whole bunch of projects (not just KDE 2.0, which you seem to be focusing on) that have seen serious schedule slippage. Why? Because they tried to do too much. They aimed further than they could see, and that meant that they had serious changes in component APIs as they discovered problems. Every time the API changed, they had to go back and rework the other components that depended on it, resulting in wasted effort.

I think that Miguel's view is something like this. If they aim to produce the "Blue Sky" version of Gnome, it will wind up taking twice as long as they expect, and users will be stuck with the existing version that whole time. If they go for the "aim low" version instead, it will come out much faster and provide a stepping stone to where they want to be. It's quite likely that they'll actually reach the "Blue Sky" point just as fast as if they had started straight for it, but with the added benefit of an improved version for general use while getting there.

Re:Good reason to "aim low"

[_ganja_]

Totally agree with this: "often the mentality many software companies take that lead to increasingly bad software"

There is an old saying, If you can't beat em join em. I have a feeling this is exactly where Ximian is going and it's a really pity. First dirty marketing tactics and now not even planning to release software at it's full potential. This reminds me of some other software company.....

Open source uses release early release oftern, kinda nice idea and it works with opensource software. Add in a dash of commercial vendor (Sun for instance) and this doesn't work that well because it raises the total cost of ownership when admins have update the desktop software once a month.

Ximian are going to get pressured by the commerical vendors to release a stable product and on time, something the I can't recall any other opensource project having to do on this scale. Even the kernel doesn't have these presures.

Also what about the volenteer programmer? The opensource projects I've been involved in, I wanted to do the best possible job and release something of technical excellence, release it oftern, yeah but it's the users risk and once it gets a stable version number it will work and work well. Are the volenteer programmers going to want to continue on a project where one they have release deadlines but also where there code, even indirectly, goes to make commercial companies money?

Re:What do you mean what a pity??

[_ganja_]

There is a good (and long post) on dot.kde.org by some dude called david. http://dot.kde.org/982011852/

Kinda sheds some new light on Gnome and what's happening since commercial companies (mainly Xinian) got involved. Made me think about it anyway, I don't agree with some of the points but I'll watch the future with interest.

Your post above brough it home a bit more, as basically you sum up a risk assesment. When did GPL projects start doing risk assesments? What happened to it'll be done when it's done or lets do the best technical job?

I'm not saying any of this is wrong, it very subjective, but I do agree with the original poster, he talks about the fact that Opensource doesn't use release schedules or panders to the expectations of share holders. When you answer him you talk about "strategy" and "risks". Is this the turning point for some of the community, I have a dreadful feeling it is.

I'd like to keep the community aspect of Free software, re-read your post, you can't deny that you have accepted the commericalization of it with all the bad points. My friend, your post looks more like an analysis from a broker than a comment on an GNU software project.

Re:KDE idiots

[MwtrV]

I hate to join in this inevitable flamewar, but I really have to disagree with your view on GNOME and it being the superior offering CURRENTLY. And this is coming from someone who uses GNOME entirely -- I don't even have KDE installed. I have tried a recent incanation of KDE (2.0.)

KDE is offerring a lot, and GNOME is letting users "preview" a lot. There is substantial difference. The only real advantage I see GNOME having is the OpenOffice commitment, but QT ports of OpenOffice are possible, too. The cutting edge GNOME applications thus far has shown us lots of quirky framework, crashing, and nowhere near completeness in its two biggest offerrings, Nautilus and Evolution. Evolution in its current state looks less then alpha. I haven't tried Nautilus and really don't want to. On both sides, it's a shame developers can't get away from the notion that the file manager must contain web browser capability. Don't get me wrong, Konquerer has nice HTML rendering, but it would do better on its own. It seems hypocritical for Miguel to criticize Unix for not being "componentized" enough, and then stand for an application [Nautilus] that does the work of two. I know his arguement was along different lines -- programming ones -- but it is still easy to point out flaw in Nautiuls from a certain perspective with it in mind. I perfer GNOME over KDE for looks, mainly, but I detest the idea of my file manager being a memory hog due to its own inadaquencies and use of library from mozilla while not being the *COMPLETE* embodiment of Mozilla (an even greater memory hog...)

Anyhow, these applications that show the new advancement of GNOME come in June/July while KDE is already a whole level above GNOME. I really don't understand your argument at all. I use software I like, but I don't illogically dismiss the competitor (unless it's Microsoft, which we all are morally obligated to despise.) Lastly, the GNOME foundation. It's a commitment, nothing more at this point. Having read the official HTML release regarding their opinion of the GNOME foundation development, they sound like they maintain a healthy outlook -- may the best desktop win, regardless of names behind it.

Ever be fixed?

[khyron664]

I've read through Miguel's comments and I agree with his reasoning for the most part. GTK+ 2.0 breaking binary and source compatibility is a mess in itself, but I worry that if they "Aim Low" then the problems they see that need to be fixed to obtain the "Blue Sky" will never be done. How many times do developers say "I'll fix that later" and then never do because they run out of time or have to implement too many other features? As a result, problems in the design get worked around and tweaked. It then becomes next to impossible to fix the problems because it would involve and even bigger undertaking than before. I would like to see his ideals met, but I do worry that by not fixing the major problems you see in your product by the next release that those problems will then stay in the product forever. I hope the Gnome team is considering this and realizes this potential danger.

Khyron

Re:What do you mean what a pity??

[gawi]

IMHO it would be a pity if GNOME decided to "aim low" just because of fear of falling behind the competition. This is open source, where we compete on technical merits, not release schedules or the expectations of share holders.

I think that "aiming low" is a strategy that makes a lot of sense. If I were a GNOME developper, I would prefer having a new version of GNOME containing less changes coming out earlier than something blue six months late. Miguel is proposing a plan that will prevent GNOME to be obsolete at some point. He's also making sure that application will be able to keep up with the changes. He's not pushing the blue sky scenario that much. Think of Blue Sky as the ultimate goal and "Aim Low" as the path.

Many projects depend on GNOME. Miguel is well aware of that and understand that the key to success is to be there at the right time. It is a matter of risk. Not to release something for a long period of time increase the risk. Some projects have choose that path and are doing fine (like Mozilla and KDE) but they had a hard-time. GNOME doesn't need that risk.

A schedule for open-source project... I agree that this is something unusual but for something important like GNOME, we cannot afford to miss that. Or at least, we need to define milestones. You're confusing "necessary delays" and "necessary changes". A good plan would make thoses changes appear gradually and safely. Unplanned delays come from bad planning.

ooh boy, now I'm talking like a project manager...

Re:What do you mean what a pity??

[RPoet]

How about thinking in long terms instead? In the case of KDE, there was a long period without releases. But in return, KDE2 is quite mature, has a stable and extensible architecture and is now improving incrementally because of the "revolutionary" changes made between versions 1 and 2. And although W2k was very belated, it is now the most stable Windows release ever. If anything, I think Miguels examples of delayed projects only goes to show that such delays and revolutionary design changes are sometimes *necessary* in order to lay the foundations for future development.

IMHO it would be a pity if GNOME decided to "aim low" just because of fear of falling behind the competition. This is open source, where we compete on technical merits, not release schedules or the expectations of share holders.
--