Edd Dumbill, valuable member and developer of the GNOME Desktop Environment, author of the “Mono: A Developer’s Notebook” book, speaks up his mind about GNOME in one of his recent blog entries.
Edd Dumbill, valuable member and developer of the GNOME Desktop Environment, author of the “Mono: A Developer’s Notebook” book, speaks up his mind about GNOME in one of his recent blog entries.
I instantly felt lost when I tried to do something in Gnome
I recently gave an Ubuntu disc to someone fed up with Windows. So far she has managed to play CD’s with oggs, surf the web for help and copied a complet fat32 partition to her home folder. Not the action of someone beeing lost is it?
Granted, I had to help her setup /etc/fstab to have the disc availble, and help her find the right /dev/ttyS (echo atdtblah ) for her modem to setup ppp.
This is stuff that Gnome could handle better, there allready is facilities to manage /etc/fstab and scaning for a modem can’t be that hard… but it isn’t a problem with UI architecture, simply lack of tools.
Go back and re-read the thread, perhaps you’ll answear in the right context next time.
Glade is a step in the right direction but Gnome needs more easy to use development tools. Writing a Gnome application is still a hassle and that’s not what it should be. It prevents many prospective programmers from contributing. Overall Gnome is making slow but significant progress and the availability of better and easy to use development tools will tremendously speed up the process.
Your “rant” was a very interesting to read, thank you for taking the time and writing all this up. I agree with most of what you have written. To answer some of your questions concerning KDE:
Arthur was developed by Trolltech and not by the KDE developpers. Arthur can in principle use Cairo as a backend, but right now it doesn’t. Zack Rusin, a KDE developer recently hired by Trolltech to work on X wrote in his blog, that currently it just doesn’t make sense to support Cairo because Cairo is not mature enough (http://www.kdedevelopers.org/node/view/978)
KDE also does not use its own zeroconf stuff, but Apple’s client library. There is an interview with one of the KDE zeroconf developers: http://dot.kde.org/1114696139/. It seems that Apple changed the licence of their zeroconf client library at some point so that KDE could use it. The developers says Avahi is just not mature enough.
KDE also doesn’t decide to implement their own nx server/client stuff. They basically used the GPL’ed code from NoMachine. Maybe it would be nice if this would be implemented within the XServer but I am not sure if this is feasable.
And I think the answer why KDE developers do not contribute to Beagl is pretty obvious: Beagle is based on Mono and I doubt that we will see any Mono based code in KDE soon.
But there is obviously another point: many of the KDE people code on KDE in their spare time, it is their hobby. It is obviously much more exciting to code your own search engine then to just take a project and help to improve it.
I would also really like to see more corporation between KDE and GNOME. Right now both DE’s are lacking a lot of things, especially applications and things like X could really need some helping hands. But on the other hand I don’t blame people for doing what they like best in their spare time, even if I would prefer if they would work on something else.
http://www.themacobserver.com/article/2002/10/28.7.shtml
Just to round out what an above link doesn’t seem to state…….
We could be nice for argument’s sake and say that in the past 3 years, apple has grown so incredibly fast that they multiplied their server share by a factor of 10…..
they still can’t touch the 20-something percent of linux on the server………
Who just said c was never meant to write OO code? Do you have any clue what you are talking about?
Yes. C was never meant as an OO language at all. Even C++ can do a lot of strange things in terms of OO development (down to the programmer and/or the toolkit really), but it was designed to support OO development.
COBOL wasn’t written to create any kinds of objects or organization for that matter; c on the other hand provides structs, enumerations, strong typing, full scoping, and an arrangement of other things allowing and ENCOURAGING use of objects.
If you think C is an object oriented language because it provides some of these things then you’re totally mad and don’t understand the OO concept. Encouraging the use of objects is not object oriented programming.
And no, I’m not going to pay TT $1500 for the choice. I don’t have to pay anyone when I write software for Windows/OS X/Gnome/Java/Etc. I’m not about to do it for QT.
Then you’ll continue to be using programming tools and libs that aren’t good enough to get where some people want to go. I hate to paraphrase Microsoft, but nothing is completely free in that context.
Besides, if it comes down to it then I’m sure we’ll see LGPL, Qt-compatible extensions to Qt to allow people to do what they want.
And GTK+ is not?
No.
It’s called bugzilla.
Using Bugzilla doesn’t magically get anything fixed.
Yeah, let’s dump Qt, and use GTK+ instead. It’s C, the most used language on Unix, and provides excellent bindings for higher level languages and a multitude of libraries which are eons more productive than C++/Qt.
Oh yer, that’s why people are complaining about the Gnome and GTK development infrastructure and talking about higher level environments and languages? Give me a break. If you think that’s eons ahead of something like Qt then you’ve got some very strange ideas.
The fact is that a desktop environment (or anything at a desktop level) is inherently object-oriented in its nature, and that’s what C++ and Qt gives you. You need to have that solid base – bindings don’t bloody cut it!.
And if you are really dieing to use C++, then use GTKmm, at least GTKMM doesn’t try to reinvent the bloody wheel.
Pardon? If you’re referring to the C++ standard then for the Nth time, the C++ standard is rubbish and is not condusive to actually getting any work done.
There are even other key GNOME people who think about stopping the work on their products. Read what Damien Sandras (author of GnomeMeeting) has to say:
Just because somebody is asking questions and is possibly suffering from a bit of burnout (possibly), that hardly means that GnomeMeeting is somehow dead.
I just wonder how many bits of software we would think ar totally dead if we could read internal posts and e-mail at Microsoft and Apple.
Large parts of VegaStrike are also written in Python.
http://vegastrike.sf.net
And we (the vegastrike and privateer remake devs) wish we hadn’t used python. The lack of static typing makes debugging and following someone else’s code utter hell.
In a statically typed language, when I see some varialbe I am not familiar with I can look for where it was declared and know what sort of object it is: I can quickly find the code for that class and see what methods and variables it has available.
With Python, Something gets passed in from another file and I have no idea what it is. I have to hunt down the file that passed it in (and sometimes yet another file passed it there) and so on until I can get a clue what sort of object it is supposed to be.
Debugging is also hell. There’s nothing less fun than launching Vegastrike and trying to ensure that every possible random occurance in the random universe happens so we can be sure there isn’t some type error in the code. It would be so lovely to know at compile time if there were any glaring errors or omissions. I’m sure there are some workarounds, some way of type checking beforehand but who needs workarounds? I’d rather simply have the functionality in the language.
In short, after having used python in a large project, we wish we hadn’t.
Developer technologies. If you feed your developers, they’ll feed your desktop with apps. KDE is executing comparatively better in this regard, the core team spends a lot of time on frameworks and making the developers life easier. I’m always surprised that even the smallest one off KDE apps, are of rather high quality and are complete in a rather short period of time, accompanied by loads of goodies, largely because the environment is rich.
I’ve said this many times before, but it bears repeating, gnome needs to work on developer technologies by way of frameworks and libraries so that they’re more compelling. Build technologies and make them easy to roll in.
The desktop is basically a run time environment, language support is an issues you have to deal with. If you’re going to do it in a language make sure it’s not going to create problems for you down the road. Gnome could be smart about things extend C, C99 or what have you so it’s easy for them to develop like Qt/C++, rather than maintain some moronic attachment to “purity” and get things going. Due to C heritage, they could still interface with languages easily.
It’s because of KDE’s rich libraries. In actual fact besides core classes and QT tutorials, KDE documentation is really poor, it’s just that it’s well made and rather digestable that you can really fly through it and do some amazing stuff.
As for Freedesktop.org and KDE. KDE technology has moved into FD.o so KDE does put in. Others put out solutions and then morons here and elsewhere say, “why doesn’t KDE use it?” That’s simple, FD.o is not a standards body, so just because it’s up there, doesn’t make it relevant or legitimate in anyway. Also, these “compelling” technologies aren’t quite there yet, usually they’re immature; moreover, KDE has existing, tested and understood versions, why change for the sake of changing? Remember, it’s not a standard, so that’s not the answer. Even still a lot of them already exist in KDE.
Speaking of KDE and freedesktop, one thing I never understood is how KDE could have the excellent DCOP only to have someone else decide to make DBUS and convince a load of people that KDE should switch to it.
KDE implements something, someone else makes a knockoff and pushes it as the standard. Seems pretty much par for the course.
>It would be so lovely to know at compile time if there were any glaring errors or omissions. I’m sure there are >some workarounds, some way of type checking beforehand but who needs workarounds? I’d rather simply have the >functionality in the language.
Not a workaround, you can consider it a part of the compile. Set it up to be a part of your makefile if you like.
PyChecker: http://pychecker.sourceforge.net/
PyLint: http://www.logilab.org/projects/pylint/project_view
As for the code folowing problem, have you considered using a better tool(editor)?
Another of the core developers who feels like Edd Dumbill. Read the blog from Mickael Hallendal
http://micke.hallendal.net/archives/2005/05/what_is_gnome.html
Sigh… Comments like this only provide food for the haters. The DBUS situation is really very simple and unspectacular:
KDE has DCOP, which is excellent but was never really meant to be used outside of KDE (or Qt).
DBus was created when some people realized that it would be mighty cool to have this kind of simple interprocess communication throughout the whole system, ideally spanning multiple desktop environments and even the kernel! So DBus was built with a goal to be as simple and independant as possible, to make it an interesting and feasable option for as many projects as possible (including KDE).
Now DBus exists and is getting used left and right. Everyone is fairly happy with it, even the KDE developers who participated in the design of it. If people ask for KDE to use DBus, they don’t do it because it’s “recommended by freedesktop.org” (it’s not) or because “Havoc says so” (he’s not), but simply because those people see the value of KDE communicating not just with itself but with everything else out there. It is _not_ important which technically ends up being used, as long as it was carefully designed to not step on anyone’s toes. DBus now exists and you may use it or not. That’s all.
Personally, I’d love to see the KDE project pushing for more desktop independant software in the future, that would be a huge win for everyone. But right now most KDE technology depends on KDE, so it’s just silly to complain about everyone else developing new technologies!
> PyChecker: http://pychecker.sourceforge.net/
> PyLint: http://www.logilab.org/projects/pylint/project_view
Are there any equivalents to these for Ruby?
> Now DBus exists and is getting used left and right. Everyone
> is fairly happy with it, even the KDE developers who
> participated in the design of it. If people ask for KDE to
> use DBus, they don’t do it because it’s “recommended by
> freedesktop.org” (it’s not) or because “Havoc says so” (he’s
> not), but simply because those people see the value of KDE
> communicating not just with itself but with everything else
> out there
Well it’s not only DBus that makes a whole Desktop. Now we have DBus inside GNOME but does it do anything spectacular yet ? or is it embedded in a way to make it look less hacky ? DBus besides Bonobo is what we have now and all the other stuff to be deprecated. Atm GNOME is getting bigger and bigger and I ask myself what problems are we going to solve ? Temporarely we cause more problems than solving them.
KDE also asks what problem does DBus solve for them ? Their Desktop seem to work perfectly, has a good framework, nice tools and the applications look and feel similar. Maybe DCop wasn’t meant for outside KDE but think back, the KDE people warned Miguel de Icaza years ago because they ran in the same problems, they initially wrote one Object Model based on CORBA, failed and then invented DCop. Miguel de Icaza could have easily jumped on the DCop process with KDE during that time and would have till now a forked, working version of DCop for GNOME.
DCOP is for IPC, so programs can communicate with other programs and scripts can work with programs and all that jazz.
Anonymous (IP: —.dip.t-dialin.net), you are thinking of kparts, which allows embedding and is a “leaner” version of CORBA. Problem with CORBA is weight, problems with KParts is if the part crashes, the app crashes and it’s a C++’ism.
But yes, KDE learned a lot from KDE 2.x and got a lot of wonderful technologies out of it, KDE 3.x a testament to that work, it’s absolutely wonderful how things, just come together, especially for the developer and thusly for the user.
The minor improvements that have been made since are made by standing on that foundation. The really slick thing is that KDE will be another slew of wonderful technologies in addition to what KDE has now.
You can use reflection to determine the type of a parameter passed from anywhere in your code base, to enumerate its methods and attributes, and read its documentation.
Happily, I only work with the python code infrequently. Nonetheless, Python is a big part of the project now so it behooves me to learn it better; thank you all for your pointers.
It certainly has its place, I’m just not convinced it has a place as part of a large codebase. I’ve got a slew of fun comments from old IM logs where the guy who does work with the python code mitches and boans about python It has done a good job controlling the AI and random universe logic once the code gets solidified, so it’s not all bad
Here’s a wild idea: Use Free Java with Gnome. Wait — read on.
Step 1: Take the GCJ and Classpath projects, rename the language they implement from Java to something else, like, say, “tofu”. Remove all mention of that word “Java”. This should remove any legal worries about using an “illegal” or non-compliant Java implementation. Hmm… GCJ–>GCT ? Of course, Tofu happens to be just about exactly like Java (who knows; maybe it will even have const. (There ya’ go Dianne ).
Step 2: Use Java-Gnome (Tofu-Gnome? . Since the Gnome and GTK+ libs provide much of the foundation classes/API that’s needed, *much* of Classpath can be omitted for simple use with Gnome. This eliminates tons of overlap (with regard to API functionality).
Step 3. Tell the now teeming and excited masses (“Java” devs who want to write desktop Gnome apps) that they can now start using Java^h^h^h^hTofu with Gnome via Tofu-Gnome for their apps.
Check you incoming type like this if you want.
foo = 5
if type(foo) == int:
print “its an int”
Contrary to what this guy says. Bloat is a major problem with GNOME. Sure, Windows suck but is that a reason to be content with sucking as well?
The recent initiative which aims to reduce the memory footprint of common GNOME components is very much needed.
That the project is a mess of small libraries that nobody can untangle and use without everything else is another, and totally different bloated beast…
Regarding my oriiginal post:
My question about the work of KDE to integrate nx instead of puishing towards gettting it into xorg was, well, somewhat baked. I realized what I had written not 5 minutes afterwords…oh for hindsight. Yes, as others have mentioned and thoughtfully corrrected- nx is GPL’ed which means it could not go into xorg even if there were no orther outstanding political issues involved therein. So basically that part of my rant was nonsense…just erase your memory of it and we will act as if I didn’t say it _;)
@Brad Hards…
“A: Have you worked with Cairo? Have you worked with Arthur? Do you understand that Qt is cross platform? Do you understand the issues with Cairo? They aren’t comparable.”
No I have not worked with Arthur and my ‘work’ with cairo has been closely following it’s evolution.
And yes I am sure that cairo and Arthur are considerably different with only a degree of overlap. But I made this comment after having learned about Lars Knoll and Zack Rusin contributions to render. The fact is that for years there was virtually no distro/toolkit direct participation in the XFree developpment process-due, at least in no small part, to the structure of XFree itself-Xfree has been replaced by xorg which is open and inviting, actually encouraging participation. When I saw the what those 2 developers were contributing my initial reaction was -hey great, someone is finally addressing some of the performance problems with render that Rasterman has been bitching about over and over again. And of course I am very happy that they, trolltech employees, are now actively contributing- but I can’t suppress the reaction- why only now-why haven’t they been working more closely together. Of course it’s foolish to complain about something after the fact but it is mind boggling how little communication, let alone cooperation actually occurs.
Keith Packard wrote the original implementation of Render- something which was part of the reason why he got locked out of CVS commit access to Xfree-precipitating the formation of xorg. People have been lamenting render’s performance since it came out-although everyone has greatly benefitted from the work which Keith Packard did. Finally Trolltech has decided to contribute the man-hours of some of there dev’s to help common cause-great. Of course Arthur and Cairo are different-but cairo would be stable by now if more talented developers had been contributing to it all along.
Cairo has tremednous input from Owen Taylor from GTK-it is being desgined to be usefull for toolkit developers-now if Trolltech, or the KDE community at large, had invested more energy into Cairo, Cairo might be better suited for the range of things dev’s need in QT…of course there may be other issues involved which I am no looking at- but the participation of Trolltech/KDE dev’s in the core technologies involved in xorg is paramount-the benefits go far, far beyond QT/KDE-everyone benefits….I am sure that the cross-platform aspect of QT/Arthur refers to QT rendering independently of Xorg-x11…but more communication and working together between the respective groups can help both projects…
As regards Avahi:
My point is that all of the desktop environments are confronted with the same licenscing problems-the distributors have the say over what tech is used in the last instance. If you are saying that there is no licenscing issues involved in using the Apples mDns software then I have to ask why the hell someone is working on avahi…I suspect that the people working on Avahi are workin on it due to some percieved licensce issues. And if this is the case it would just make far more sense for the KDE and GNOME folks to use the same underlying code.
I know that KDE dev’s don’t want to touch anything with a ten-foot pole which dependes on glib-asied from gstreamer…And I know that such issues are akin to religious holy-wars…but I really wish there were more people involved in this who would keep an eye towards the broader issues involved-the issue of seemless integration of such tech into all cross-desktop applications far outweighs, IMHO, such relatively small issues like whether or not one needs to depend on glib….
@cm,
I seriously doubt that Tenor goes far beyond the scope of Beagle let alone Storage. I read the posts about Tenor written by the author and aside from his ‘this is soo much better than x,y,z’ I see little in the way of concrete fuinctionality which it provides which is adressed in Beagle/Storage. And of course the dependency issues which preclude most meaningful cooperation are exagertaed once mono comes into spiel. I am aware of this-but again I only wish to see the people involved in these projects actually communicating with each other and sharing ideas-sharing code is secondary-because if they share ideas then there is a possibility of convergence in the future.
What Beagle is bringing to the desktop is the equivalent of NT/XP streams implemented via xattr attributes-a fundamentally differnet and superior way of dealing with metadata. If Beagle is suscessfull we may be looking at an actual change in how people work with metadata and consequently things like xattr may become a new requirement for the future Linux desktop..Now if Tenor shares some of these ideas then work can be done to enable a comprhensive and inclusive approach to providing such functionality system wide-beyond the confines of this or that metadata searching utility….
@eu,
Firstly I completely agree with you regarding Egroupware and Hula is just Novell hot air…
Secondly, although I admire the work that has gone into kiosk and wish that GNOME had more of this functionality I see little in the way of overlap between saybayon and kiosk- saybayon(sp?) is only really usefull for prototyping and then deplyoying the unique arangement of the desktop/panel/icons-whereas kiosk can be used to lock down virtually all aspects of all programs. Saybayon is extremely useful and extremely vaulable for those admins that most tailor the look of GNOME desktops..particularly in LTSP settings-I simply cannot wait to try it out. Moreover something like kiosk is totally incompatible with the gconf system used in GNOME-i think kiosk is a function of the wonderfully simple kde .ini files-the configuration subsystem of KDE is far, far simpler to administer than the gconf system- but gconf offers certain benefits such as dynamic apply which is where things like saybayon are needed…manyually hacking exported gconf trees into something usable a true nightmare and saybayon can make this step really, really simple-open up a Xnest login and create your desktop-save it and apply it for that group which needs this desktop….
Again I am not so convinced that Tenor is so much ‘more’ than Beagle…
@ Michael Taler,
Thanks for not ripping me to shreds over the my nx remark…;)
If Apple did change the license on Zerofconf such that KDE can use it I see *zero* reason for the GNOME folks to be working on a replacement library. My point was, and is, that where it’s possible both projects should be using the same code, where this is not possible they should be sharing implementation ideas.
Thanks for the links posting to more concrete information much appreciated.
to everyone:
I really appreciate the hard work that the Trolltech/KDE dev’s are doing. My *rant* was not meant to belittle the ongoing work or to make light of the contributions involved. But I am not the only one who percies this Not Invented Here Syndrome. And KDE is certainly not the only guilty party here-there are probably an equal number of GNOME devs who suffer from the same problem. But GNOME take on a whole is not known for a bad case of NIHS whereas KDE has been seen this way-perhaps unjustified, perhaps it is now changing.
The comments of some in this thread only serve to illustrate what I have pointed out here. Some view Mathias Ettrich(sp?) as a traitor due to his willing *collaboration* with Freedesktop.org. I witnessed the heroic battles around Dbus-and I saw some KDE dev’s really work hard at making Dbus plausible and appealing for KDE. Dbus is after all the only tech worth mentioning in the past years where KDE and GNOME worked together for the benefit of everyone. I guess we must label Dbus a relative success-relative against the void of cooperation which has been the rule over the past several years.
And for those who rail against Freedesktop.org as some kind of front for GNOME-get a grip and come back to reality. There is a whole world of other WM’s out there that are profitting everday from work at Freedesktop.org. Most of the stuff at Freedestkop.org does not come from GNOME developers and *gasp* not even Redhat employees. Sure Freedesktop.org is *not* a standardization body-standards bodies are of questionable utility in something as quick and free evolving as the free desktop. But you cannot at once both disdain freedesktop.org and the approve of the goals of cross-desktop interoperability- it is *the* venue for said such interaction-there is no substitute.
I don’t really care if KDE and GNOME use the same library for, say zeroconf, as long as it works well. The real problem for the user is, that right now GNOME applications integrate terribly in a KDE desktop and the other way round. Everytime I have to use gimp (which is a really fine applicatio), I get totally annoyed by the gtk file selector. It is just a pain to use the gtk file selector if you are used to the KDE one. I don’t want to start a flamewar which one is better. I just want to point out that it is really important that GNOME applications integrate well in KDE and KDE applications well into GNOME because neither of these desktops has enough (really good) applications and the big majority of people is probably using applications from both projects. I think this is far more important then sharing some underlying libraries (at least for the users). Maybe dbus can help with this, I don’t know. But I really would like to see someone working on this.
I seriously doubt that Tenor goes far beyond the scope of Beagle let alone Storage.
Beagle is pretty much nothing, and is simply a way of merging document search, e-mail and IM search within one application – albeit reasonably nicely. It deserves nowhere near the amount of hype it generates however. Microsoft has simply been doing this with their new search mechanisms now that WinFS has effectively died.
I thought Storage sounded interesting when I first read about it in detail, but it seems to have stagnated a bit now as implementing it in the Gnome infrastucture and the VFS seems to have presented some problems.
The way KDE infrastructure works and is structured means that they have a really good shot at making Tenor work well, but you always have to be careful about implementing layers above a filesystem in that manner, performance being a concern. Tenor, however, will do so much more than a simple search tool in that it is a framework programmers can use and it will save contextual link information so that you know what each document and bit of information was related to and searching those relationships.
i’ve read your comments in this thread and the errors and mischaracterizations in them just make my stomach turn. bleh.
Matthias Ettrich is not viewed as a traitor. i have no idea where you got that impression. we don’t need people stirring up muck that doesn’t exist and doing so is truly a low-class act.
asking why Trolltech hadn’t done more for Free X in the past is to completely ignore the realities of X development politics in the past as well as Trolltech’s position historically as a small company in the industry at large.
as for your assertion that “you cannot at once both disdain freedesktop.org and the approve of the goals of cross-desktop interoperability- it is *the* venue for said such interaction-there is no substitute.” .. that is so amazingly flawed logically it’s not even funny. i can support cross-desktop interop AND note problems in FD.o’s current processes.
your statement is exactly akin to those who used to say “you can not at once like X11 and not approve of XFree86 – it is *the* venue for X development these days.”
such ideas are amazingly dangerous to progress, because if we do not allow ourselves to examine (and re-examine) the structures and processes we put in place to achieve our goals, those structures tend to stop being useful at some point. FreeDesktop.org is not the purpose, interoperability is the purpose. therefore FreeDesktop.org is not the goal; it is a means towards that goal.
the only thing i’ll comment on is Tenor, and to just say this: i completely understand that you don’t see how it’s more than Beagle. but when you get to play with it in KDE4 you’ll understand. 😉 we’ve been doing development rather quietly, and experimented with “coming out of the closet” briefly. the next time you’ll hear more about Tenor is probably when there are applications using it.
I think the layer between the toolkit and the X server should be a participative project. On top of that, we should have a toolkit/desktop that just follow a phylosophy and an ideology (a la windows(kde), a la apple(gnome), a la nostalgy(gnustep), a la what you want). Then Developpers should then use a something like wxwidget, which will be directly build against the toolkit/desktop/preference of the user. so if you are in kde, you the app will be native QT, gnome/xfce native GTK, windows … Apple …
This will also give a incredible advantage to un*x; develop once, deploy everywhere. What is not the case with MS nor Apple OS. KDE/XFCE/Gnome/what_you_want would shared instantly, without putting a mass of developer in a ideology war but in a co-operative work and then offert a real bunch of competiv and quality apps that all user and programmer will benefit.
Integration/interoperability of the too, will be an endless battle in my opinion.
@about python
I have start coding in my free time in python a year ago, and sincerely I think it is the best language I have used. But I don’t think it is suit for everything. personally I prefere statically typed variable.
I think, that to write simple gui application or console tools, python is *the_ proper language.(mail, word, calendar, messenger, etc…, portage, top, parser,etc…) Fast enough, really powerful, rich in feature, rapid development and validation.
Python could, if it were more used, bring more powerful, more rapidly, more evolutionary programs to programmers and users. I also believe that a project Like OO.o would be far more advanced now if it was coded in python. (but we can debate endlessly on that 😉 But python need a good IDE. yeah I know boa-constructo, eric3 and company. In fact, gnome need a good IDE. and no gedit+glade is not one.
Secondly, python need a cleanup in is library, java+.net+gnustep should be closely look to help python library coders to regroup it nicely.
This thread show somehow, that opensource project are repeating history. The unix war that give Microsoft the easy opportunity to eat everything.
Beagle is pretty much nothing, and is simply a way of merging document search, e-mail and IM search within one application – albeit reasonably nicely
…using kernel hooks to do on the fly indexing, and adding a full, customizable metadata engine a la spotlight.
winfs and storage are about at the same level as a full document store, beagle/tenor/spotlight/longhorn search are all more or less the same thing, at various states of readyness, and with slightly different feature sets. as for tenor > beagle, its more that tenor has loftier initial goals, and beagle is alot closer to being done. more or less the same kind of tech.
Aaron please note that I am simply reiterating what I have seen in the way of comments of others. Perhaps such rhetoric is purely an example of fandom/zealotry and I am sure that no serious dev’s actually think that way. One only need frequent the venues where ongoing software developments are being discussed to find that attitude which I paraphrased-yes such comments are assinine, but the sheer contensiousness surronding such issues provides a fertile ground for fermenting such reactions.
As regarding your response concerning Trolltech please note that I did mention how closed XFree once was and that I am applauding Trolltech(and the their resp. employess Zack Rusin, Lars Knoll) for contributing to xorg. I know that Trolltech is rather small and that it only has become recently feasible, with the advent of xorg, for third-parties(distros/toolkit dev’s) to easily make contributions. Perhaps I came across as harping at Trolltech, if so that was not the intended effect.
Aaron I read your blog concerning the role of f.d.o. Perhaps my way of enthusiastically embracing f.d.o. triggers such a negative response-almost all of these issues boil down to name- and word games, it’s all about language,identity and communication. My pointing out that f.d.o is *the* venue is only pointing out the abundanlty obvious-at this point in time it is the only publicly known venue for such desktop interoperability. I myself have issues with the way certain issues are framed at f.d.o due to the particular interpretation of the boundaries and goals of the ‘desktop’. Yet I do not see any other venues for such- perhaps due to my ignorance. My stating this does not mean that I wish to exclude other possibilities as your reading of my text supposes-on the contrary what I wish to see is more cooperation where such makes sense and fruitfull communication between GNOME and KDE dev’s and all those other dev’s of the other free desktop wm’s and I would heartily applaud a multitude of venues for advancing a reasonable degree of common cause. I do not envision a totally unified venue which shoots for some kind of far-fetched uber-intergration. What I envision is talented intelligent people willing to do the horrificly difficult task of trying to slowly form certain specfic consensi-ie. multiple point of consensus without the need for some over-arching grand consensus. It most certainly is tiresome, wearisome work, something which requires immense patience and something which gives little in the way of short-term positive feedback. But over the long run it could produce the best software ever known.
I’ll have to take your word regaring Tenor. But I wrote what I wrote because Beagle is actually necessitating the use of extended attributes for our filesystems and harnessing these for metadata (if I understand correctly). Such issues effect the entire operating system-requiring those fs’s which support xattr’s,kernel modules for support, recompilation of kernel-or alternatively becomming part of default distribution of kernels, etc. These are far ranging effects and the reason I made the comment I did about sharing of ideas between Beagle/Storage and Trenor is that if such were to occur we might be more likely to see a more powerful widely adopted metadata subsystem. From this viewpoint the questions become:a) will Tenor also require such complex changes in our configurations ? b) will Tenor be able to make use of the xattr’s for managing metadata c) will it possible to have access to the same metadata in both ? I just hope that the interested parties can find points of common ground at least conceptually.
> but the sheer contensiousness surronding such issues
> provides a fertile ground for fermenting such reactions
i completely agree. in the complex system that is open source development, it’s useful to allow such contention to take its course between those doing the work, and equally useful to try and restrain from reacting blindly.
i know how hard the latter is, as i have failed at that more than once myself
re:FD.o:
> It most certainly is tiresome, wearisome work, something
> which requires immense patience and something which
> gives little in the way of short-term positive feedback.
> But over the long run it could produce the best software
> ever known.
i complete, 100% agree =) the challenge is to ensure that the tiresome, wearisome work is both encouraged and done. and that’s been the problem recently, is that it has not been encouraged enough (this is mostly a marketing issue; i’ve discussed it at length with Waldo =) and too much non-productive work has tried to use the FD.o channel to gain canonicalization despite that not being FD.o is for.
it’s the swapping of the concept that “we need interop” with “we need FD.o” that is, IMHO, unuseful. as you said, it’s largely a matter of phrasing and how Fd.o is marketed to developers.
right now it’s been marketed in such a way as to attract certain types of projects that are best done elsewhere, and it’s made it harder than necessary to gain acceptance for the newer stuff that the people with their heads screwed on straight have been working on within the venue of FD.o =)
> a) will Tenor also require such complex changes in our
> configurations ?
no, or at least from the perspective granted from working on the third revision of the concepts, it doesn’t seem that way at this point.
> b) will Tenor be able to make use of the xattr’s for
> managing metadata
there’s no reason one couldn’t write (parts of) the storage system to use xattrs. for day 0 we are working at something that is platform agnostic and so aren’t thinking we can rely on such things.
i fully expect/hope that once Tenor emerges into something resembling stability and usage, that people will target the backend towards things like reiser4, xattrs and .. well, who knows what =)
> c) will it possible to have access to the same metadata
> in both
this would be up to the storage backend, which is fairly modularized from the guts of what makes Tenor itself tick.
I feel that the thing about documentations is… REALLY BAD…
I mean…
The app that would allow me to connect to the net (modem, lan)… how do I see if the modem works, …er… fives minutes later… OK so I go to the help file, and what do I get:
“Bla Bla Bla”
FOR REAL… I am not kidding you… and thats at the user end of things, if it is like that at the developer end they are doomed…
For all its virtues… they are laking in what they are supose to be better at… userability, which needs documentation which needs well documented programing so that others can jump in and help…