Miguel de Icaza On GNOME 2.0 58
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.
Re:KDE idiots (Score:1)
The KDE project has a habit of choosing quick to implement, but technically flawed solutions - and not laying the groundwork properly. A perfect example is QT.
So if you want to say Gnome is previewing... fine, but don't claim that KDE stuff is ready to be used because it simple isn't. I've lost count of the number of KDE advocates claiming the Koffice is ready for primetime - these people live in fantasy land.
I detest the idea of my file manager being a memory hog due to its own inadaquencies
You base this on what? Nautlius is not out yet... I'll judge it when it is.
KDE is already a whole level above GNOME
Well Gnome started in response to KDE's corrupt decision to use a proprietry toolkit... so it started later. Quite apart from that, the GNOME project does considerably less bragging about upcoming improvements... Pango, the Gnome Canvas, are all superb pieces of foundation software but they aren't quite as sexy and appealing to cheerleadering airheads as aRts.
BTW: most of the stuff KDE announces these days is preview... whether it is Koffice, or Magellan or anything by TheKompany, or most stuff by TrollTech (other than QT itself).
they sound like they maintain a healthy outlook
I prefer to judge them on their actions, not on carefully prepared press releases. Ever since the announcement of the Gnome foundation, there has been a shocking increase in the volume and amount of KDE fudding. The overreaction to the Ximian advert is just the latest example.
Re:Internal conflicts (Score:1)
Re:KDE idiots (Score:1)
Re:VFS (Score:1)
Re:Gnome zealots refuse to admit it... (Score:1)
People are misunderstanding "Aiming Low" (Score:1)
I think a simple example will best explain and summarize what Miguel was trying to convey in the article. When he said "aiming low", he is not advocating throwing away the "blue sky goal", but instead he's suggesting to approach it gradually, rather than in one BIG jump.
Here is the example. Say we think we need 6 months to do all the architectural changes and stuff to get to Gnome 2.0. Based on the "delays" examples he's given, we'll probably end up taking 12 months to actually finish it. Meanwhile, in those 12 months, the stable Gnome 1.2 (or 1.4) will languish and just have bug fixes, with no preview of what's to come. Rather, if we "aim low" at first, then in 6 months we are sure to have *some* extra features/improvements. Gnome 2.0 might (and probably will) take 12 months, but at least we have *something* in 6 months to work with and use.
Remember that Gnome is not an Application, not even just a Desktop Environment. IMHO the most important aspect of Gnome is that it is a Development Environment across Unices. If things break all of a sudden, a whole strew of applications will break with it. If Gnome 2.0 takes 12 months to be declared stable, a whole strew of applications will be unstable for 12 months, or use the old Gnome instead. However, if we have something not as good in 6 months, and then the blue sky goal after another 6 months, the applications can do the same.
This approach follows quite nicely with the "release early, release often" mentality. Instead of doing a massive upgrade, Miguel is proposing taking smaller steps and releasing something stable each time. The key here is to aim at something reasonable each time.
------------------
another approach (Score:1)
they could order the things that they are going to change, do the most important first (eg gtk 2.0 compatibility), progressing in small steps from one stable state to another stable state. (kind of like refactoring).
then of course you can branch your source control to attack 2 goals at the same time.
Re:Nautilus really ready for primetime? (Score:1)
5 seconds for opening a window is at least 25 times too slow. And for the memory, don't even get me started.
I am not saying that other programs don't equally suck, but we should be straight on one thing: if the window doesn't open within 0.2 seconds it is too slow (independent of how much work it has to do).
Re:Nautilus really ready for primetime? (Score:1)
Call me impatient, but user experience is all about speed, and gnome isn't going to gain more users by having them wait 5 or 7 seconds to open every new window.
Re:Nautilus really ready for primetime? (Score:1)
I'm running it on a Celeron 466 with 196meg, and after the initial startup time of about 7 seconds (which you only need to do once...) it takes 5 seconds to open a window with my home dir that has 100 items and a nice image as a background. The AA text stuff and translucent selection indicator don't slow down very much either.
So, yes....bullshit it's too slooooooooooooooooow. It's running slightly slower than GMC, and does a hell of a lot more.
And as for RAM sucking...it's only using about 20meg, which I think is pretty acceptable.
Re:Both (Score:1)
Gnome core is at 1.2.4
Dunno about the rest, that's pretty much all I have.
Re:Nautilus really ready for primetime? (Score:1)
but yeah, maybe I do have low expectations, but I'm content with them.
Re:Both (Score:1)
the only reason you dont see more people using the unstable version is because you have to grab it from cvs (or random tarballs which are in various stages of out-of-date-ness) then try and compile all the individual bits which have the high probability of not compiling on any given day. so unless you're one of the developers, it's far easier to just stick with the stable.
matt
Re:Internal conflicts (Score:1)
i'd been of the impression that people were generally happy with gconf. maybe this is a fairly new development, where a better implimentation idea has popped up.
anyone have links to discussion on what's up with this gconf vs corba_any thing?
matt
Re:Gnome zealots refuse to admit it... (Score:1)
Come on.... OO is an aproach, not a language.
The language is a tool, though. Some are much more appropriate for a given task or job. Consider an analogy of eating. Using a fork to eat is good. Using a chainsaw probably is a bad idea.
Re:Nautilus really ready for primetime? (Score:1)
Re:Nautilus really ready for primetime? (Score:1)
As for why it takes so long... couldn't tell you.
Re:Interesting comments on KDE 2.0 and Konqueror (Score:1)
But will it be fast? (Score:1)
--------
Genius dies of the same blow that destroys liberty.
What do you mean what a pity?? (Score:1)
Besides, GNOME 2.0 is not the end of GNOME. GNOME 2.0 is just the next major release of GNOME. There is always a chance for us to redeem our pride as programmers, hackers and architects with GNOME 3.0 and GNOME 4.0
So there will be plenty of opporunity for GNOME to have all the cool stuff that we want to see! Rather than criticize Miguel for being realistic, I say we applaud him for avoiding the mistakes (overly optimistic + feature creep) that delayed Linux 2.4, KDE 2.0, Windows 2000, Gtk 2.0, etc. Miguel is smart enough to realize that for GNOME to effectively compete with Windows and KDE, it will have to release frequently and not remain vapor-ware forever.
Good reason to "aim low" (Score:1)
GNOME is no longer a "spare time" effort, and several commercial companies depend upon it. I think Miguel is suggesting an intillegent approach.
Re:What do you mean what a pity?? (Score:1)
Re:KDE idiots (Score:1)
Re:KDE idiots (Score:1)
Re:Gnome zealots refuse to admit it... (Score:1)
Examples: Ruby, Python, Eiffel, Smalltalk, Object Pascal, Oberon, Modula-3.
These are just examples I thought up in less than a second.
Not to mention that C++ does NOT even belong to the good OO languages. Design some large project using UML and implement it in C++ and you'll know why.
Each one of my examples (except maybe Object Pascal) are by FAR better OO languages than C++.
Re:Gnome zealots refuse to admit it... (Score:1)
I'm sure some Perl affictionados says they can build a desktop too in OO Perl. And a Java/Python/Ruby desktop can be built - well, speed can be an issue, but Perl code runs as fast as C code nowadays, and Ruby code is only half that speed.
Other than that, there's nothing stopping people using a scripting language to write a desktop. In fact, the interactive nature of scripts makes debugging and maintenance a breeze. Plus, the desktops will be more scriptable than the current ones too.
Re:Both (Score:1)
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 ).
If I want bugs of 1.2 fixed, I shall wait for 1.4, which also includes large new features ( and new bugs ).
As developer, I understand it is resource-consuming and not much fun to mantain a double versioning like this. ;) ).
But as a user, I'd appreciate it. ( users always demands more than what they get - even if they don't pay for it
Re:Gnome zealots refuse to admit it... (Score:1)
Interesting comments on KDE 2.0 and Konqueror (Score:1)
Re:What do you mean what a pity?? (Score:1)
I posted this to the dot.kde.org forum:
You make some very good points. Its true the Ximian and Eazel will be making their cash out of seducing wide eyed newbies like my mom into their branded Gnome, complete with paid product placements and banner adds riddled through the interface like MSN and NS6.... but like Mozilla, those of us who care will go ahead and ignore their branded version and use the less commercially polluted Branch. And this is great. The people who don't care (my mom) fund the development by paying the wages of the developers, which gives back to those of us who do care. Not much to complain about at all. I'm damn happy running my Gnome, KDE and Mozilla, and am very thankful for all the companies paying developers to bring them to me faster.
Re:Internal conflicts (Score:1)
It's about time they started work on Gnome 2.0. (Score:1)
Re:KDE idiots (Score:1)
Re:Gnome zealots refuse to admit it... (Score:1)
Re:Gnome zealots refuse to admit it... (Score:1)
Re:Gnome zealots refuse to admit it... (Score:1)
Re:Gnome zealots refuse to admit it... (Score:1)
Re:Good reason to "aim low" (Score:1)
Khyron
Do you know that ... (Score:1)
Re:Gnome zealots refuse to admit it... (Score:1)
---
Re:In three lines: (Score:1)
. Retard.
---
Nautilus really ready for primetime? (Score:2)
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:What do you mean what a pity?? (Score:2)
2) I never claimed they did.
3) You're referring to "release early, release often". That's The Cathedral and the Bazaar, not Slashdot.
--
Re:Nautilus really ready for primetime? (Score:2)
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
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? (Score:2)
Re:Nautilus really ready for primetime? (Score:2)
Re:Nautilus really ready for primetime? (Score:2)
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.
It's not a big deal, or even new .... (Score:2)
Re:What do you mean what a pity?? (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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" (Score:2)
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?? (Score:2)
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 (Score:3)
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? (Score:3)
Khyron
Re:What do you mean what a pity?? (Score:4)
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?? (Score:5)
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.
--