Slashdot Mirror
Gnome Hackers Sorting Out Differences RE:2.0
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."
if they had to work on a project with components named libgnome, libbonobo, libbonoboui, libgnomeui, and so on.
Just looking at those words makes me kind of nauseous...
...the three beats of war, peace, and revolution repeated throughout time. I guess the same axiom can be applied to most open-source development projects.
It's not about the GPL really, more about jealousy, hate and blindly following the word of the holy RMS.
Stallman called GNOME into existence as a response to a desktop (KDE) created with a product (Qt) that did not conform to his idea of "free" software. It was free to download and to use, but did not meet some ideological criteria or another - perhaps it was only that it wasn't his.
Later, when Qt became GPL, Stallman was not gracious - in fact instead of welcoming them to the project and looking for a united approach he called for an apology.
A major reason why I have little respect for the man, and none for the people who still refuse to use KDE because they "support the GPL". No you don't, you support your slavish unquestioning devotion to the word of an obese, stinking communist.
These forms of communication are not good to express emotions. People tend to misunderstand one another way too often, and then all hell brakes loose.
e-mail is practical, bod please do your fighting IRL.
I understand that flaming is a natural, emergent part of the internet experience. But it still sucks. And it doesn't have to happen. Just as we form societies in real life, we can do it on the internet -- peer opinion means a lot on the internet (more when things aren't anonymous). If people show that they look down on flaming, that cruel words are not respected, then people will start (appropriately) censoring themselves.
The widely espoused alternative is to "put on your flame-retardant suit" and just suck it up. That works sometimes. I certainly won't be bothered if some AC writes "fuck you, idiot" in reply. But I think there are some major negatives to doing that all the time:
- Your sense of empathy doesn't kick in right. If you remain sensitive to flames, you'll be sensitive when writing flame material. I've seen a lot of cases where highly flame-resistant people can be short, dismissive, demeaning, and just plain cruel to innocent, though sometimes misguided newbies (among others).
- It might leak into your real life. Being a geek I had put up a lot of walls to defend myself from the ridicule of my peers. But now I'm an adult and my peers don't ridicule me. Those walls only harm me now and they probably didn't help much in my youth either. Trying to tear them down in one environment and keep them up in another is hard. I don't think my experience struggling with this is unique.
- You become naturally defensive. A truly well-formed argument is one that leaves room for your opponent to gracefully concede a point. If an argument involves neither side conceding any points, that's not a helpful experience. Maybe one side converted more bystanders into their camp, but ultimately some sort of concensus has to be reached -- even if it only means that the losers agree to stay silent. This is hard to come by after flaming, and seldom creates good feelings among the group.
- Flaming tends to degrade into point-by-point rebuttal and counter-rebuttal. This is closely matching the Lincoln-Douglas debating style, which I consider the least insightful way an issue can be argued (can anyone tell I wan't pleased with my brief debating experience?) This tends towards reactionary statements, which decay towards absurdity. Seldom does anything new come out of such discussions.
So yeah, you're going to get some flames. But I think they could be handled much more constructively by the group -- rephrasing vitriolic but valid flames into something more reasonable, matching flames with positive feedback, and having third parties confront flamers off-list. That last one particularly -- it's weird how a mail with a To: line that only points to one person is so much more intimate and personal than one that CC's the list. It makes people realize that there's individuals behind the email addresses, which usually is enough in itself to stop flaming. It also short-circuits the posturing that is behind many flames.More love.
I am a really, really big fan of GNOME. I think it's a beautiful and effective desktop environment - easily my favourite - that the GTK toolkit is fantastic (I've written a couple of GTK apps) and that it is GPLed is equally important, right, and good.
But goddamn, that's been hard to swallow lately....
I've been using the Ximian update service for getting GNOME, because I like the idea of getting regular updates as a tested group of binaries - with a project with as many different components as GNOME, it's tough to do all the "find newest version, ensure no compatibility issues, compile it, debug interactions" busywork yourself. The idea of a central source that would push the latest versions, tested to ensure compatibility with each other, down to my machines on a regular basis is VERY attractive.
But the releases coming out of Ximian have been few and far between, and the last one has resulted in Sawfish crashing more often than any program I have ever used. GNOME for me started off as stable as a rock, and has become increasingly UNSTABLE as time goes on.
It's getting to the point where I'm seriously considering dumping the whole thing, a concept that I find personally objectionable, as I strongly support the GPL and don't want to use KDE for that very reason.
Troubleshooting hasn't been very rewarding either, as it seems that even the tarball releases of key components like Sawfish seem to occur at infrequent intervals - even though I've seen indications that the "constant Sawfish crashing" (it hits an assertation that t cannot equal zero, but does) may be a known problem, and may be fixed in CVS. You have a crash problem, fix it, and don't _immediately_ cut a new release? Huh?
GNOME guys, what the hell is going on? Isn't this stuff supposed to get _better_ with time? What ever happened to "release early, release often"? And Ximian, where's the quality control? Where's the rapid release schedule? Where's the communication and feedback?
If I'm a _fan_ and getting this frustrated, what must the rest of the world feel like right now?
Want to learn about race cars? Read my Book
Here's the issue: when a given program (or set of programs) is touted as being "stable", then I expect it to be stable. If a bug - especially a crash bug - shows up, then I expect the fixed version to be released NOW, because the existance of the crash bug in the "stable" program invalidates it as being "stable".
I don't mind waiting for new features et al, but I do expect to get a feed of the latest bug fixes pretty well as they occur.
The idea that the fix for the "Sawfish constantly crashes" problem that is driving me nuts might have been found, written, and applied a month ago - but is still locked up in CVS instead of being released - is driving me right around the frickin' bend.
The Linux kernel has been really good at this. All the instability goes into the Developmental kernels, and the Stable kernels get nothing but the bugfixes - and those bugfixes are applied in very short order. Alan may like to do a lot of prereleases in between each "official" stable release, but there's a very good chance that if thge bug has been identified, there exists a tarball where it is fixed.
It would be a VERY good thing if, every week, each patch that fixed a bug without otherwise affecting the core functionality could get rolled into a tarball and placed out there for people like me to get their paws on - the bug you fix may well be the one I'm suffering from.
Want to learn about race cars? Read my Book
First time I hear it, but seems to me like a wonderful idea.
GNU Network Object Model Environment--as shown by the title of this page. It's kind of in the name. I know it doesn't just leap out and say "component!", but for the component people, "network object" is kind of a dead-giveaway. Then there is the fact that it is built on CORBA--which is all about objects working separately from one another and interacting and cooperationg via network wire protocols. ORBit is the key piece gluing GNOME together.
So it has been there from the beginning. Maybe it has been forgotten (I still have my orginal GNOME foot shirt from the Red Hat Linux conference in 98), but it was the original intent. Many, when it began, remarked it was like OS/2's presentation manager--which was all components and CORBA.
The fact that you haven't heard it could be seen as success or failure (since components are supposed to be seamless to end users). Bonobo is the bulk of the component work. By component, we mean objects that inherit useful, common functionality that allows them to team up with other GNOME apps. Bonobo provides those services. It's very cool stuff.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
I'm sure that someone will be pissed about me saying this, but it is pretty true. That person is Miguel. Now granted, he is not the only developer, but many people see him as the leader--even if it is unofficially. He helped start the whole project (with others), and he has been at the forefront from the beginning.
As to final say, I'm not so sure. ESR has long held Linux as THE example of the bazaar--but how? It still comes down to a cathedral like decision--i.e. Linus says yea or nay. In this case, Miguel is very loath to come out and say "Your right and you are wrong, now do what I say." I for one like it.
Is it as efficient? Probably not. But it is the true essence of Open Source software. Which has nothing to do with the GPL, but more to do with the democratic approach.
OTOH, I am a firm believer that my code is my code--if I am the sole starter of a project, I have a certain level of say in what happens to it. But then I release under the LGPL--anyone who doesn't like what I'm doing can fork ;-)
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
Miguel makes the point again and again throughout the threads that most of the flaming is from people making statements based on little or no information--i.e. people who did not write the code making statements about the code that are misinformed or just false. If you read it, you'll see that most of the arguments are started with developers and only worsened by non-maintainers crying for process. Most of the maintainers are coming to consensus (albeit slowly and with much replying back and forth).
For the "Is this why GNOME is [so slow/sucks/isn't as cool as KDE]?" people, this has nothing to do with GNOME really. How many times have people on the kernel lists gotten into these arguments? We have the basic thing happening here: people who write the code don't want to have to go through a committee to enact changes, and people who don't know a whole lot about what they are talking about are making very passionate claims in all sorts of directions.
I'm not on the list. I just read the list. I'm not taking sides, since I clearly don't know enough to say anything one way or the other. But for the GNOME naysayers and the prophets of doom, just read the threads. This is typical Open Source/Bazaar/Free Software conflict. It's pretty easy to see if you read the mailing list. But of course, that requires some time and forethought as well ;-)
It will work itself out eventually. The developers will come to a consensus. But people need to calm down and quit clammoring for committee rule. That's the whole reason people develop this stuff--personal freedom. It's like free speech: if you want it, you have to take the good and the bad. Same with free software--or so we claim ("software is speech", etc.).
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
--
ROTFL.. I think I've actually said that last one more then once..
-- I'm the root of all that's evil, but you can call me cookie..
How about
'Flames of our lives'..
'Lists of Flame'..
'One Life to code'..
-- I'm the root of all that's evil, but you can call me cookie..
Unfortionatly, forking and incompatible implementations also thrive on it.
It does look as though they came up with a 'compromise' in the case of gconf vs bonobo-conf, in the use of a wrapper, which is a good thing. Fortionatly, one side conceded in order to make things move forward.
And there are threats in working in an open source community. The threat is that your code will be ignored or allowed to rot, and all of your time will have been in vein. In many cases, it's great if you scratch an itch, but if every program decides it doesn't want to interact with your tool, in this case, gconf vs bonobo-conf, it's worthless, and your work was in vein..
Blech, sometimes life just sucks.. 8-)
-- I'm the root of all that's evil, but you can call me cookie..
Thanks for the post, is was an insightfull read to look into the logs.
But I gotta say, in all of the posts, I *NEVER* saw anyone say 'I could be wrong'. All I saw was 'I gave you a better way, and you rejected it'. No where in any of the posts did their seem to be any respect for the individual at the other end of the line. A little bit of charm, perhaps, but no real 'I respect you, man'..
One has to wonder if this is becouse working in a virtual environment leads to less personal relationships with your peers..
-- I'm the root of all that's evil, but you can call me cookie..
Could someone who has a few extra minutes please give me a summary of what "bonobo" is and what the "bonobo-conf versus gconf" war was about?
Thanks,
Derek
Just a quick note to all you slashdotters. The GNOME project is not dead. The GNOME project is not falling apart. In fact, things are going quite well. In every software project of this magnitude, free or not free, flamewars break out amongst developers occasionally, and are generally solved. The difference here is that GNOME is kind enough to be free in not only its software, but most of its mailing lists. They are not able to immedialtly cover things up like their closed source competitors.
Here is a better summary of what happened this past weekend. The release coordinator, Martin Baulig, has been working *very* hard and at an astonishing rate. His school work was suffering, and some people were criticizing a technical decision that he had made. Martin got very frustrated, and made a post that he probably shouldn't have in a tone that he probably shouldn't have. But, honestly, all of us have said things that we really didn't mean to when we have been frustrated. As a result of his post, a massive flamewar developed concerning the technical decision itself, maintainership of GNOME, how decisions are made, etc. In the end, it appears that only constructive discussion is going on now to put in place a process for proposing changes to GNOME before they are made. Havoc Pennington has written a nice process similar to the Python Enhancement process. While it is in discussion now, and will likely change a lot, it has very much promise!
As a long time GNOME user and a developer, I am actually *more* excited about GNOME right now after seeing a damaging argument turn into something productive. Every project is going to have bumps, but the measure of the project's maturity is how they deal with it. GNOME certainly hasn't handled it perfectly, but the GNOME development community is learning from its mistakes, and working to prevent them and grow in the future. So, stop complaining about "GNOME is dead", "the linux desktop is dead", and spouting off useless insults. It is clear to me that not only is GNOME alive, but it is growing in maturity.
Jonathan LaCour
I don't use Gnome (did for a while, but I'm over that). I don't use KDE. I don't want to use anything like them. All I want is a nice toolkit that makes my apps pretty. I don't need to turn my desktop back into a windows (work|look)alike.
That said, it is interesting to watch all that's going on here. I hope they get all their stuff straightened out soon.
Last I heard, QT was still under the QPL, which is a very different thing than the GPL or LGPL. KDE can't really be seperated from QT (alas, the Harmony Project collapsed), so using KDE still means using the QPL.
Like many, I find the QPL sufficiently disagreeable that I avoid KDE, even though I think it is a better system.
Of course, my "desktop" consists of FVWM, but I recommend Gnome to others. In the long run, I think it will "win". Types like me will choose it based on Freedom, and companies like HP and Sun will choose it because the LGPL license on GTK is a lot easier for them to swallow. They don't want to be beholden to some company named Troll Tech.
--Lenny
This is primarily an open source site, man. Darwin is open, sure, but the majority of the system is not. Hell, the hardware isn't open, either.
As for your description of KDE and Gnome as "marginally functional, amateur efforts", that's just flamebait. For the record, I was more impressed with KDE 1.0beta2 (1997) than with MacOS X (2001).
If you like MacOS X, and the licensing doesn't bother you, then use it. I'm interested in freedom, and I sure don't get that with an Apple platform.
--Lenny
this is where the gconf vs bonobo-config thread starts. Some Gnome hackers, notably Havoc, definitely do not want bonobo to be a requirement for gconf. Some Gnome hackers, notably Martin, think a bonobo-ized config system would be much better.
Both parties are attempting to predict future usage of gconf/bonobo-conf, as not a lot is dependent on gconf right now. AFAICT, all parties expect more of the core stuff to use the configuration database.
I'd kinda like to see the bonobo-conf for 2.0. According to a few posts in the thread, the gconf API has problems already and that a bonobo reimplementation would fix those problems as well as add the benefits of componentization. Since this is a new major release, I don't see why Havoc is so concerned with backwards compatibility for the gconf API since they already planned to wrap it.
but then, I've always been partial to the Linus Torvalds development kernel approach: ok you convinced me it's a good idea. Let's see what broke!
:-),
-l
References:
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
The main issue is whether or not Gnome 2.0 will be bonobo-ized. Martin resigned because he fervently wanted 2.0 to be bonobized. Instead, the goals for 2.0 have been lessened to porting to gtk 2.0 and some other odds and ends.
Bonobo is a cool component architecture. It's more complicated, but supposed to be much more flexible than KParts. Do some google research or dig around on gnome.org to find out more about it. I'm kind of sad that the core components won't be bonobo-ized for 2.0, there's lots of neat stuff a Gnome programmer could do. However, most of the other folks appear to feel that bonobo-ization would be biting more off than they could chew for the projected 2.0 release.
STill, I wish them luck.
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
After reading the entire flaming thread (plus some more), here are my contribution of ashdusts
1. It is not easy to be Humble.
Contrary to popular believe, we human being are not known to be humble.
Had people involved in the flamefest - anyone, - understand the importance about humility, this flamefest would have been better managed.
2. The problem with Complexity
One of the tap-root cause of this flamefest is the complexity of Gnome's architecture.
Sure, Miguel is not wrong to want Gnome to follow his vision of
The underlying structure of Gnome is too complex, and until SOMEONE start to deal with that problem, Miguel's vision of getting Gnome of being a true "component platform" thing may never come true.
And here is my suggestions -
A. There are a whole lot of great points being aired in this debate. Why don't someone - other than those whose blood are still boiling due to the debate/flamefest - collect all the great points, and list them out in the open, for ALL to view and review?
B. Cool Down Period - Please someone impose a cool down period for all involved. I understand that many an ego have been scratched, and a cool-down-period may heal the wounds caused by this debate. I hate to see anyone quit just because of this debate. We can always go back to point (A) - just above - and see what all of us can do with all those great points that were being aired, and use them to improve Gnome.
B1. Those who were involved in the debate - take time off, think over what has happened, and then, think of what Gnome is all about. If Gnome's future is what you care MORE than the rough-words hewn during the debate, ignore them and continue to churn out the code you want for Gnome's sake.
C. Havoc may have a good intention, but committee-level-decision-making-method won't fit Gnome's loose and free nature. Let Gnome be Gnome, and let Gnome become strong by the force of natural-evolution, and not the resulted of Kremlin-like central-committee I say this, you follow methodology. Let the component maintainers their free will to do whatever they want, and if what they do ends up incompatible with the general flow of Gnome, then, their "babies" will die natural death. If component A dies (or lack in compatibility), I am sure someone else will pick up the pace and launch a component A+ to take its place. The natural flow of Gnome must not be disturbed with any central-committee.
D. Listen to the critics, ask them to help out. There are lots of people willing to offer criticisms, but not many who will go beyond that. Gnome can benefits from the critics too ! Recruit them, ask them to get involved, so that they will know more about the inner operation of Gnome, and then ask the critics to offer suggestions on how Gnome can be improved. What we need is not only the brainpower of the coders, we also need the insights of those who have offered criticisms.
*** Note - The above are my own point of views. I may be wrong. If I am, please correct me. Thank you.
Muchas Gracias, Señor Edward Snowden !
Have the KDE crowd had any similar problems? There will always be dissagreements about how to go about things, but it always seems to me that Gnome is trying to do too much and isn't getting anwhere. At least, not anywhere stable.
I'll come out with it, then: sometimes they might not feel _good_ enough to contribute code. I was a competent engineer, but never brilliant, and my coding has slipped since I moved into management - I just don't have the time to write much anymore. But I'd like to be more involved, and just because I can't write low-level code at a good enough standard to contribute doesn't mean that I can't review design, features (and sometimes even code) and take an overview, or be involved in other ways.
Again, I think that we should look to involve people outside the tight coding community, and make the most of the skills they (we!) have to offer, if those people _believe_. And I, for one, do.
In the commercial world, you have people who are, to some extent, both inside and outside projects, with little power other than negotiation, and who are often looking not just at technical, but also external issues - Product Management. I'm not saying that we should turn the OSS movement over to middle managers (aargh, run away!), but the role of a Product Manager is an interesting,and often very useful one. Typically, they keep everything together, calm egos, make sure that documentation, testing, engineering, PR and all the other bits get seen to, and have the overall responsibility for making it all happen - getting a release out of the door. Their role is both more and less than project managers, and they typically (in the commercial world) sit on the interface between "customers" and "engineers", taking an overview of what features are most important IRL, etc..
What sprung to my mind when I started thinking about this is that Linus is a very fine Product Manager, in some ways, in that he takes a broader view than just a technical one. He's also a Project Manager, in that he has great technical input (may his guru-ness continue for ever), but he does more than that, too.
So, the question that springs to mind is - what place (if any) is there for Product Manager-type role within OSS projects? Don't forget - and I'll say it again - I'm not advocating handing over OSS to Middle Management. But there are people with good skills out there who maybe don't want to code on the projects that they really care about (maybe it's too deep for them, maybe they haven't got the time, whatever), but have real skills and experience to bring to bear. Can we use them? Should we?
I know that I'm going to be flamed for this post, but I really believe that as we move into the mainstream, we need to look beyond just code, and take a broader view. This is _one_ way - and maybe not even a very good way, but one _suggestion_ of a way as to how we might do that. We believe (I hope) that we can take the best bits of processes and systems, and make a bigger whole than the commercial world tends to - here's one piece we might "borrow". Or maybe not.
Oh, and BTW, yes, I'm a Product Manager. See - I'm "out" now.
IANAGH, but as far as I know, the main goal of 2.0 is to move it to GTK+2.0, Pango et. al., which is a highly nontrivial task. Moving everything to a pure component architecture at the same time was apparently considered, but it was decided that doing that as well would be trying to do too much at the one time.
As I understand, nobody has said that GNOME should not move to libgnomeui, just that it shouldn't be done at the same time as the move to GTK+2.0.
If I'm terribly, tragically wrong on this please feel free to flame...
/Janne
Trust the Computer. The Computer is your friend.
A "I-fed-the-trolls-and-all-I-got-was-this-lousy-shi rt" Tee shirt!
signal, noise, to me it's all the same.
Imagine KDE and Gnome were two railroad companies. Now, each company wants to be the 'standard', but they can't agree, so each one lay their own railroads. Fine, problem is, the distance between the rails are different.
Now, the train builders have to choose between the two rails. Instead of building one train that works on all railroads, they either have to choose one or the other. Now, of course, people who buys the train can refit the trains to their railroads, but this refitting is very expensive, so why bother.
A train builder who builds for one set of rails is not really competiting against another train builder that buils for the other set of rails.
Now, as a user, why would you care? Well, say one set of rails are put between your city and city B. You usually travel between your city and city A, so you have monthly pass. To get to city B, you have to pay an extra ticket instead of using your monthly + learning new schedules, changing trains etc etc. Waste of money and time.
In short, common infrastructure is good. KDE and GNOME pretty much split the infrastructure in two (actually three, third one for application that hasn't/won't be changed).
Je ne parle pas francais.
Proof.
Greetings Pointwood
I think it's fair to say that heirarchy or not, people in high demand will leave an organization if they can get a job elsewhere and are unhappy with their current position. This instability make the idea of a chain-of-command suspect. I've encountered this in science, where post-docs can get paid much more outside academia...I have to attract them through stimulating work and a good work environment. It's probably true of the computer industry (years ago if not now): anger your employee and they walk.
Imagine how this translates now to a group of talented, well-paid coders donating their time to a project. Sometimes (often?) these projects lack anyone with formal management training, and strong words fly quickly when personal contact doesn't exist between group members...digital relationships can be broken so cleanly. Look to online communities like MU* for solutions.
Lust
You compare this childish bickering and flaming with the recent CVS freeze and almost corporation-quality organization going on at the KDE camp and the difference is clear.
QT is now open source and it's incredibly organized. The Gnome libraries are a mess. KDE is also C++ while Gnome is C. KDE is also working on KOffice which is already completely usable and damn impressive.
The Gnome developers who have the maturity and intelligence to do so should start helping the KDE project. While competition is a good thing it really only serves a purpose when the competition competes. Gnome isn't anymore.
Flame away, perhaps I'm just an insane fanboy.
Does Microsoft "release early, release often"? Can you think of any major software project that does? As a developer, I like the sentiment, and we try to follow it in our own projects, but in large, complex systems like Gnome, it's unrealistic to expect an unending frequent stream of updates. Similarly, installing all the latest updates as soon as they're released is a recipe for frustration, again with any software.
If you want stability, pick a stable version and stay with it. If you want the excitement of continally experimenting with the latest stuff, then you have to live with bugs and instability. A "stable" release just means that it's been tested by beta testers, it's not truly stable until it's been tested by everyone else, too, and then patched with the necessary fixes.
It's your choice, don't make it and then complain about it once you experience the consequences.
I believe the is "software crisis" is a farce. People have been declaring a software crisis since the 1960s. Without a "crisis", snakeoil peddlers would have no MBAs to buy their wimpy $25,000 application servers or dynamic objected structured architecture modeling foobar chart solutions.
What people mostly call a software crisis is usually a problem with project management or ever-changing requirements. Look at the capabilities and performance of today's software compared to that of ten years ago. It's pretty amazing.
cpeterso
Can you provide a exact link to the start of this flamewar? I guess you can read it at lists.kde.org (or maybe not?).
But Red-carpet does not install packages unless it has all dependencies.
I've sometimes not been able to fetch some packages due to server-errors, but they've never created any problems, as red-carpet has just not installed any of them.
Have you filed any bug-reports, or asked around on monkey-chat? I bet that would be more useful than just naming problems on Slashdot.
If I wasn't being forced to use Windows 98 at the moment, which means I can't moderate when I have points because the boxes get randomly mixed around the screen whenever I scroll, I'd mod you up :)
-- Help Digitise the Public Domain at DP.
Increasing the major version number normally (i.e., in the part that isn't Microsoft :) indicates major incompatible changes to interfaces (both user and programmatic).
In this case, the GTK people are making binary incompatible changes to GTK+ (to include things like anti-aliasing, for example), so they will be increasing the major version number of their library. Because the GNOME people wish to use this library, they'll be using the opportunity to make binary incompatible changes to their system, and bump the release number up to 2 as well.
The same thing will happen with KDE when they port it to QT 3 (and QT 3 is QT 3 because it's a major binary incompatible change over QT 2).
-- Help Digitise the Public Domain at DP.
Having two 'rival' desktop environments is a very good thing for UNIX. Each has areas where they excel, and which point the way for the other. To take just a small example, Nautilus has a much higher 'prettyness' factor than Konqueror in KDE 2.1 -- so, what did the KDE developers do? They improved some features on Konqueror (the detailed list view and the file previews) in the direction of the trail blazed by Nautilus. Look for KDE 2.2 to see what I mean :). Similarly, KDE shows to the GNOME guys things to do and not do in getting a proper component and object model: it's always easier to implement something if someone else has done it first :). GNOME's panel, it's default window manager, many major applications (Pan, Evolution, ...), are all superior to KDE's.
With two seperate environments with distinct but similar goals around, they will *both* advance faster than they would do if only one of them was around. Hell, they're both infinitely better than CDE was (and I hate to think about how much was spent on developing that).
-- Help Digitise the Public Domain at DP.
It wasn't really a flamewar, and isn't of the same importance as the release coordinator quitting.
:)
One of the more abrasive characters in KDE circles is called Mosfet (real name Daniel Duley I think). He implemented much of the KDE 2 theming/widget styling support, as well as the image management software Pixie. He has a habit of finishing big batches of code about a week after the KDE code freeze dates, and then stamping his feet until he's allowed to check the code into CVS.
A while back, people were trying to reorganise the kdebase package, and split some of the less essential sections into two new packages: kdeaddons and kdeartwork. Mosfet had about seven or eight window border themes in kdebase, and they wanted him to move the less used ones into the addons package. He refused. Similarly for the less used widget styles. Then Mosfet developed a new widget style, which they wouldn't let him commit to CVS because it was past the feature freeze deadline for 2.2.
Mosfet, upset at this, decided to remove almost all his themes & styles from the KDE CVS, including the new default widget style. When this didn't get the reaction he expected, he removed Pixie from CVS as well (this is fair enough - there's no real reason for Pixie to be in the kdebase package anyhow: it's a distinct complete application).
A few days later, and with a cooler head, he's moved the styles KDE actually needs back into their CVS server. The rest will either go back in the future, or be a seperate download (i.e. from kde.themes.org).
And that's about the most exciting dissent to happen within KDE development for the last 18 months
-- Help Digitise the Public Domain at DP.
Hello. News for Nerds website here. At least we're in the ballpark with this story.
I don't want knowledge. I want certainty. - Law, David Bowie
At least the programmers are passionate about what they think is right, which means they are probably going to end up with a GREAT solution. Better than a world where the programmers just accept whatever comes their way even if it's a bad solution to the problem.
But other than that, I really hope they calm down the flamewars. Having a passionate discussion about something and harrassing or insulting someone else (often on something totally not related to the subject) will ruin relationships and break apart a good development team. If it's bad enough to drive someone to resign, it's pretty bad.
One thing about both the Gnome and KDE projects is that they do not do things the simple way. I click on a file in either one (konqueror, nautilus, or gmc) and I have to wait forever before I get to see the simple contents of the directory. Admittedly, there is a lot more to Gnome and KDE than the file managers, but this is just a simple example. The libraries and embedding may be useful, but when I do graphics, I have always steered clear of Gnome/KDE and stuck with the basic GTK/QT. After all, who needs all that fluff?
Also, with KDE, if you are not running KDE and you start even the most simple KDE app, it has to start up a hoarde of KDE helper applications, starting nearly all of KDE, just so I can edit a plaintext file. This seems too ridiculous.
As a programmer, I stick to more basic toolkits. As a user, I use something like WindowMaker or BlackBox and ROX. I think ROX is great, fast, responsive, gives me all I would want out of a "desktop environment" without the crap I don't need. And as a sidenote, strict application directories, imho, are great. I really think this project deserves a lot more attention for this. After giving it a chance, it managed to actually impress me, which is more than I can say for any other program in a long long time.
XML is like violence. If it doesn't solve the problem, use more.
Bear with me moderators, not trying to post flamebait....
Anyways - to me, his resignation shows an inherent flaw in the open source, or bazaar, type development environment. With closed source software one has to realize that most of the programmers, coordinators, graphics artists and whatnot are there because a) they hopefulyl want to be, b) they are paid to be there, and c) if they don't show up then they won't get paid and possibly fired. For many getting fired is not an option as they have families to support. This also requires them to listen to the people organizing things (good and bad, depending on which marketing idiots were hired).
However it seems that with open-source, since everything is on a volunteer basis (well ok, not everything...), there tends to be ego's going unchecked in multiple areas, leading to huge "wars" regarding issues, that, in a "normal" company would've been squelched by a single individual's decision.
S.t.e.v.e.
I don't disagree that C++ reduces complexity, but there are good reasons why people haven't moved to it:
1. Cost/Benefit ratio isn't great enough, there are a large number of applications already written in C, writing an app in C gives you a guarranteed audience of coders capable of working on your open source program. C++ does not reduce complexity well enough to make it work the price of losing that group of coders, and in many cases, learning C++.
2. There are better alternatives. Indeed, we are already way beyond C++ as the solution to complexity. Essentially, languages such as perl, haskell, python etc are the ones you move to if you wish to reduce complexity. They reduce it by massive degrees, not the increments that C++ does,
- they automate memory management
- they provide high level structures like associative arrays and string manipulation right there in the language
- they completely avoid pointer ops etc increasing reliability of cheap code
- they massively reduce code size by avoiding unnecesary overdeclaration
- in many cases they come with a central class archive where modules can be sourced, CPAN for perl for example
- In every non-performance-critical case, they will perform more than acceptably for the task. Additionally, the higher level definition of the task given to these interpreters leaves open long-run dynamic optimisation etc that we see being implemented in perl 6, allowing the programs to fit themselves to the use to which they are being put in any given execution, a task difficult to achieve well in lower level languages.
Essentially every argument that could suggest C++ as the better alternative to C, also suggests python as the better alternative to C++, and people are waking up to this rapidly. CPU cycles are, with the exception of games and other CPU hard tasks, no longer a resource to be carefully preserved.
Applications today need several important features:
1. Stability. It is trivial to write a stable application in perl, it is non-trivial in C or (to a lesser extent admittedly) C++
2. Adaptability. Less code = easier to refactor.
3. Easy interaction with other applications.
These are all served better by the higher-level languages available today, than they are by C or C++. By all means write your X window server in C++, or your kernel in C, but a word processor? it requires too many features too quickly and too much multi-app communication to be done effectively in C/C++. The over-long engineering times of many of todays open-source applications is due to the desire to stick to C/C++, and the DLL "hell" that many people are seeing is primarily due to attempts to create components of things that should never have been done as a shared library in the first place, but as a module in a higher level language.
You can't win a fight.
Now where can I go buy it for my hand-assembled K6 box?
Microsoft won't be trashing the BSDs explicitly any time soon. They are probably going to wait for their anti Linux/GPL FUD to bear fruit first. I don't think they'll target the BSDs and projects like Apache and XFree86 until they have significantly impeded Linux development. That said, I can see Mundie or Ballmer using choice quotes from the Gnome flamefest to make some suit-impressing zingers.
Oh yeah, If one hasn't gotten that impression yet, Microsoft is no friend of the BSDs either. They will come and destroy them once they finish off Linux. The anti-GPL arguments are the low hanging fruit. They won't trash the open source licenses but they WILL trash the process. So Codefreez is likely correct. Expect Microsoft propaganda flacks to be devel-list lurkers.
Last time I checked, about .5% of the population was willing to dump their x86 boxes and switch top MacOS X/PPC (which has serious speed problems btw) just for the desktop. Unless Quartz and Aqua become open source, this isn't even a point worth considering.
A deep unwavering belief is a sure sign you're missing something...
How about getting Linux's interactive GUI performance to equal Windows? It will never happen, if only because of the disadvantages it would introduce to other types of programs. This back and forth will never lead to anything. I value desktop performance over everything, you value open systems and generalized performance. Ideally, the two stances could be reconciled in one OS, but that isn't the case in the real world, so in the end, I use what I want, and you use what you want.
A deep unwavering belief is a sure sign you're missing something...
A big part of the problem is that systems like Gnome are written on such a primitive foundation (C/C++)
Just curious. What sort of higher-level tools do you suggest that they use. If you are going to call these two languages primitive you might as well call all other Procedural and Object Oriented languages primitive as well, since they all share certain common features.
Oh, I know we can implement the entire system in Perl or Python. Right. These languages are good for writing applications in, but I would not suggest writing your entire desktop environment in them. You could use Common Lisp or Scheme. Those, however, are basically dead languages in the Software Industry. Perhaps Java would be a good choice. Wait, I am wrong, it shares too much syntactically with C/C++ to be much of an improvement.
You have to face facts. C and C++ are induatry standard languages. They are two of the best that we have, as evidenced by their continued popularity. Currently this is the best that we can do. If you ask me we aren't doing that badly.
You should read Bjarne Stroustrup's paper Learning C++ As A New Language. It shows how C++ can be written in a style such that it looks very much like Perl or Python. It can be as high-level as you need it to be.
If it looks like a duck, and quacks like a duck, it must be a duck.
There is one thing that bothers me about this whole mess. (Yes, I have read the flamewar. I am on the gnome-components-list where it started. After being assaulted by almost 100 emails of ever increasing rage on Saturday, I feel qualified to call this a royal mess.) That thing is the fact that GNOME 2 is already about a year overdue. The original release date was supposed to be sometime near the release of KDE 2. GNOME has been delayed several times. Implementing a new process and starting up commitee meetings to discuss features will only slow the project more. For example, there is supposed to be an API freeze soon. This is what Martin B. was working so hard to meet.
I am just wondering how much this meltdown is going to set the project back.
It is not people flaming each other that will kill GNOME. It is the constant setbacks. I am an avid user of GNOME. I still have GNOME 1.2.x on my SuSE 7.1 box though. Looking at the progress of KDE development it is easy to see myself switching to it. Hell, the progress of GNUstep is happening at a faster rate than GNOME right now. There are too many other desktop projects out there for GNOME to survive many setbacks of this nature. There are KDE, GNUstep, XFCE (used by Alan Cox), FoxDesktop, and ROX Desktop just to name a few. I have a feeling that due to issuses like this GNOME is going to start loosing its userbase.
Falling into obscurity I think would be worse for them than a few developers quitting because of holes in their flame-retardant underwear.
If it looks like a duck, and quacks like a duck, it must be a duck.
With C++ you don't need to reinvent the wheel. It already supports similar features through the use of templates and RTTI (Run-Time Type Identification). Granted the features are not quite the same, I still don't see how you can say that C++ is a primitive tool.
If it looks like a duck, and quacks like a duck, it must be a duck.
Miguel: I do believe strongly on the vision of making GNOME a component platform: implementing well documented interfaces all over the system; reusing interfaces to improve programmer efficacy and to make a system that is fully scriptable.
I still believe in this, because I have seen Windows do an exceptional job at this, and I am sure we can do better than they can, I believe strongly that Open Source can build a platform that is as good and better than Microsoft can.
I realize Miguel is full of love right now and will not mind a little flammage. It took Microsoft at least a decade and hundreds of millions of dollars to get its COM/OLE architecture in place and stable enough for widespread use. The reason has to do with the time consuming task of taming code complexity and killing the bugs. In the face of such mounting complexity and the never ending pressure to produce, it's no wonder that emotions are running high within the Gnome development team. In my opinion it will take the Gnome (and possibly the KDE) programmers another ten years of hard work before we can see the kind of stability that the Windows desktop is now enjoying. I hope I am wrong in my assessment. By that time the world will be thinking of new things, especially new operating systems to replace Windows and Linux/Unix.
The software world is in a deep crisis characterized by low reliability and low productivity. It is time that the free software community realizes the seriousness of the crisis and begins to confront it. We need to form a reliability forum where we can assess the nature of the problem and formulate effective solutions. I think software engineering is due for a major overhaul. We need to reassess our current approach to software engineering at its most fundamental level. Needless to say, I don't think we are doing right. I think that we all took a wrong turn way back when and that is the reason why it takes so long for projects like Windows, Gnome and KDE to iron out the kinks and add new bug-free features. But I'll leave it at that.
I thought we were supposed to reserve the (sometimes mindless) flaming for Microsoft the Merciless and the assembled minions!?
How about a show of hands. Is there anyone who sees a benefit to this beyond taking the mind of the collective off their own problems?
Giving up is not a compromise.
It's not better.
It is quitting.
A great many people think they are thinking when they are merely rearranging their prejudices. -- William James
There's nothing you can code that can't be gcc'ed,
Nothing you can commit that can't be forked,
Nothing you can `make`, but you can learn how to gdb
It's easy...
There's nothing you can RPM that can't be tarred,
Nothing you can grep that can't use awk,
Nothing you can post that folks will listen to anyway
It's easy...
All you need is love,
All you need is love,
All you need is love, love,
Love and procmail
There's nothing you can 'make clean' without some SOAP,
Nothing you can ps that can't be killed
Nothing you can edit unless you learn how to use vi
It's easy...
All you need is love,
All you need is love,
All you need is love, love,
Love and procmail
(She'll flame you, yeah, yeah, yeah)
Frankly, flame wars in large development projects aren't really surprising. Whenever you have a group of exceptionally bright people with differing ideas you're bound to get some conflict. That's true for an open source project, a television show, or any other type of collaborative effort.
What makes situations like that spin out of control is when there's no one in charge. Decentralizing development is good to a point, but when there isn't one person responsible for solving these disputes and ensuring that development goes forward, you end up spinning around in circles. Linux has Linus (and to a certain extent Alan Cox and others) as having a good deal of responsibility for the Linux kernel. You need to have someone willing to step up and ensure that things go smoothly.
This is certainly a good case example of how open source development isn't a panacea. Even OSS isn't immune to the kind of managerial problems that are inherent in any kind of collaborative enterprise. I hope that the GNOME team manages to get things back on track and continues to put out some quality software.
Once again we see the commercial software world making excellent, quick progress (WindowsXP and OfficeXP) while the Free Software and Open-Source Software development communities waste their time bitching at each other and getting nothing concrete done. Centralized control is a GOOD thing, not a bad one, when it comes to ACTUALLY GETTING SOMETHING DONE. The sooner the free/open-source software communities learn this fact, the better.
- "It's just a matter of opinion!" - PRIMUS
i have the opposite problem, i have way too much memory right now, so i think i might start running gnome/kde now
"Weasling out of work is important to learn; it is what separates humans from animals. Except for weasels."
My K6-300 with 64MB of memory (can't be upgraded) is why performance matters.
I've been using linux again for the past week, and I'm remembering why I had problems. With KDE (I use a lot of the QT and Gnome apps, such as GnomeICQ and KMail, not to mention Konquerer) I have a miserable time trying to switch between windows, much less run anything even remotely intensive.
If I can't have my word processor running with 3 open web windows, mail, and ICQ (like I can in 98SE) I'm a bit impeded.
I can hear the objections already. Why are you using KDE then? Because the applications I like are KDE-dependant (other than GnomeICU) Why don't you just run win98 then if it's better for your feeble equipment? I like Linux better, frankly, even if I have to go back for video and a few other applications every once in a while.
Anyways, that is why Python is still 5 years away. It's going to take these ghz+ machines before we can say that we don't "need" all this performance. That memory and processing power that the word processor is taking up is hurting the performance of the application in the foreground and the memory footprint makes the word processor slower to task switch.
But just for that quick on topic part of the post... Conflict is inevitable. Politics is only the science of conflict management. Even subpar rules are superior to no rules so long as both/all parties abide by the results.
The court system, for all its flaws, is more accurate than duels and cycles of vengence.
Remember, the system that only bruises ego, pride, and reputation is far superior to the one that chops off the wrists or head so the competing programmer can no longer code.
I'm curious - if GNOME is right now at 1.4, just barely, why is bonobo-izing the whole project by 2.0 an insurmountable goal? If GNOME follows the usual release schedule, shouldn't it go 1.5-unstable, 1.6-stable, 1.7-unstable, 1.8-stable, 1.9-unstable, and then finally 2.0? Or is there going to be a huge jump from 1.4 to 2.0?
Does GTK follow this similar 1.4->2.0 jump?
(Was it Slackware that did this with some wry comments on the web site?)
It strikes me, this is the best of all worlds. TrollTech makes money off of closed source companies, the community gets QT, and the world at large is monetarily encouraged to write GPL-compatible software (whereas with the LGPL, it doesn't matter).
The only "intuitive" interface is the nipple. After that, it's all learned.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
Then we'll just have to ask the M$ spinmeisters to go down to the development areas, and ask the people how those coffee stains got on the conference room walls.
Having worked (and survived) in a corporate environment for a number of years, I feel it is a good thing that flame wars are fought in the open. I have seen really shrewd managers finding scapegoats with ease to save their own asses a lot of times. Thats another plus for open source!
--> Your Wisecrack Here
when a tension arises in a group of bonobos, it is normally resolved by having a group sex. I wish GNOME developers would have followed this fine example.
"Thats why I'm now mostly using XFCE. The component mess and the complete lack of thought on user requirements in things like bonoboconf (like inheritable non overridable policy items for sysadmins to set stuff up) really show how clueless the gnome design has become. Its no longer about building a cool environment its about a small number of companies trying to screw each other.
Fortunately for Gnome most of those companies wont be here in 12 months time because they don't have a credible business model. At that point it will be interesting to see how people work together again."
Something for fanboys to chew...
"Thread of Geeks"
and now back to our regular programming !!!
I think Martin was making a good contribution, and he had many good ideas. I also think Havoc (among others) should turn down his flamthrower a notch.
But quitting because of flames? Thats the same as quitting for no reason. Any technical decisions can be sorted out- ultimately by appealing to Miguel or the board, and everyone agreeing that the main branch will honor the decision.
Quitting because of a disagreement is just giving up. You want to get as many developers on a free project as you can, but theyve got to be willing to stand up for themselves.
The exact paragraph:
At this stage, we were running out of time, so he speeded up :) One huge thing that helped KDE and would probably benefit other very big projects was that KDE had the KDE Summit which was sponsored by Trolltech. When you get all the people in same place, then magic happens. At the KDE one, Matthias Ettrich and Preston Brown got drunk to the stage of claiming "We could write better than CORBA. Hic. In a day!" The next day, of course, everyone reminded them about this claim, so they had to do something about it. 36 hours later, DCOM (?) emerged. There was a similar effect with KOffice, which came on by leaps and bounds as a result of the summit. So, if you're big enough to get sponsors, get your people all in one place and watch the results pour out.
This probably (hopefully!) isn't the whole story though :-).
Monkey sense
Yep, QT went GPL back in September.
Ok I will play your game, will it run on my amd thunderbird? I would gladly buy it, if it in fact it did, that is why apple will always be a little player.
Got Code?
Thanks for the FUD.
Why do I keep typing pythong?
this is not a curse of open and free source; it is the curse of smart people. The nice thing about open and free source is that we get to see all the details, but these flamewars take place inside of companies, and people quit over them too.
the firm may have the responsibility to hire smart people, but 90-something percent of the time that never happens, especially after the politics start. And if productivity grinds to a halt on an open source project over a dispute like this, that is balanced by higher productivity when people work on what they love free from interference and distraction.
We have a healthy commercial software industry, and a healthy open and free software "industry" and their pluses and minuses are identifiable a priori. it is ridiculous to make sweeping statements "proving" that one or the other is ailing.
As a sys admin who doesn't develop in a real language (just php-mysql), I often push things to where I have questions and suggestions for improvement that I figure the developers might profit from. Maybe 40% of the time I'm right, the rest just missing some concept (which about half the time means room for improvement in the fine manuals). So I'm a nuisance more often than not, but there's a good size handful of bugs fixed in various open source products because of the hit rate I have, and developers sweating to follow up.
Problem: I'm a New Yorker. In this town it's not polite to let politeness stand in the way of getting a point across, when it's in the mutual interests of both parties to be communicating. Of course, many developers live in towns which have resisted NY cultural imperialism - who knows why? What to do? How to communicate to the thin skinned?
One surprising thing about the KDE/Gnome wars and the KDE team playing nicer together is that in academic conferences in the sciences, Americans tend to be much more collegial than Europeans - or so say the Europeans I've met at American conferences. What is it about software development that puts the Europeans ahead in collegiality? Or is this just a chance reversal of cultural averages in both camps?
"with their freedom lost all virtue lose" - Milton
In the world of Proprietary Software, if this happens and people quit, the firm has the responsibility to hire someone smart enough to keep it going.
What happens here is the productivity is stumped till those losers resolve your issues.
Rapid Nirvana
I thought Tinker Gnomes were bad. Turns out the Kernal is really some corn and the socket is really a wrench...
The Blaster Master Fighting for Truth, Justice, and Evil Pie since 1979
GNOME is trying to make the most flexible DE solution possible. This allows for very customizible desktop, I never see two identical GNOME desktops. KDE, and to an even further degree Windows, limit the users UI in the name of getting it done now and having it work now. I am not saying this is a bad strategy. Certainly people need software to use now. But only looking at the short term, small scope UI goals means that it is hard to add flexibility later on.
IMO, both ways are good for getting a project done. KDE has a great solution now, and GNOME is still working on their longer-term solution.
Flame wars may rage on and on. In the end, if all of the people care about getting the work done (rather than just doing it their way), the project will end up much better than if these issues were not fought out.
It is very easy to release a high quality, simple application quickly.
GNOME is not a simple project, and thus will go through ups and downs of release quality. Especially now, where they're trying to gear up to GNOME 2, there will be lots of glitches and problems while they develop the new software.
Also remember that the Evo/Naut problems were before either of them were even released. You can't expect coders to have release worthy software while they're still developing it, that would just be silly.
I think list should announce unilaterally to be
blackholed(not RBL kind) - recieve but not send
out any emails for few days, with announcement for
everyone to cool off, and then continue on. In
fact I think it should be blackholed without
announcement, because that group it seems has
exploded into whirlwind, just like group of small
kinds in a room, just looking for each own intersts disturbing everyone near them, in same space. What parents do in this case? Turn the
light off in the room... =)
Interesting to see that Gnome spawned by GNU crowd
looking to do some GNU damage, in response for
creation of KDE under not so free licence, that
was posed to dominate linux desktop.
Being politically motivated group seems exploding
onto itself(imploding?) with arguing over little
details, when big picture comes to mind as Miguel
pointed out.
Peace man...
ref. - Dragonlance Chronicles
I think the best part is when George (the Panel maintaner) jumps in and says:
he said he was going to FILTER his email, not delete it unread. he probably has filters in place for abusive language.
~sabine
Deleting whole messages, yes. That's the point. Deleting entire mail packets, no.
;)
Read before you flame next time, sweetie, it makes you look smarter.
~sabine
I certainly have no authority to say this because I don't commit code or write pacthes for the gnome project, but I for one would love to have more CORBA and reusable components into Gnome. Also, why rush to have Gnome 2.0 out of the door as soon as possible? As a user and potential application developer, I would love to see tons of new features in Gnome 2.0, both extendable and reusable. Otherwise, just call it Gnome 1.5/1.6 or August Gnome (' sounds cool, no?).
As a corolary, if you have a small team of people who use advanced tools and methodologies, they will sit around reading and writing books, and not write any new code.
I'm still trying to figure out what people mean by 'social skills' here.
Finally, a replacement for "ALL YOUR BASE ARE BELONG TO US"!
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
It's time for Miguel to show some leadership and fix this thing. If Martin was the problem, then his resignation is probably its own solution. Unfortunately, Havoc's swift attempt at putting a bandaid on the development-by-committee process seems to suggest that the problem is deeper, and that problem needs to be addressed and patched quicker than an emacs bugfix. KDE's already taken the lead in the X environment, and competition is only a good thing when everyone's up for it. Chances are everyone in the group knows deep down who or what the problem is, but the more the GNOME foundation builds itself into a bureaucracy, the harder it is going to be to fix these things without lawsuits -- anybody who's been involved in any sort of volunteer-driven collective that has a respectable operating budget knows exactly what I'm talking about.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
The debacle with Evolution and Nautilus (Medusa, etc.) come to mind. Slow releases of binaries, incompatibilities...
You win the award for the most rediculus and unfounded statment of the day. Jay, tell him what hes won....
Galeon .11 complied fine for me. Did you set the MOZILLA_LIBS_PATH correctly in the config file. And, I too noticed what you are speaking of about .10.6. .11 clears those stability problems right up.
I think the key is - SO FAR. Not that I don't hope it all works out in a cheery, mutually-acceptable fashion, but it doesn't seem headed that way.
is this.....is this for REAL?
great comedy company.
The bonobo info from the gnome office page http://www.gnome.org/gnome-office/bonobo.shtml talks about using bonobo in gnome office. Perhaps I don't really understand what gnome *is*, but what parts of gnome (that is besides base applications like the gnome office stuff) would need to be bonobo-ized?
As a gnome user, but not a programmer, I have been trying to follow the argument since yesterday. However, I have no idea what the argument is *really* about. Not the ego-who-can-make-decisions argument, but the bonobo vs. gconf and GNOME 2.0 argument. Can someone give a quick sum up of the two (?) positions?
I can hear the Microsoft media machine already...pretty soon we'll be hearing how open source projects can't work because people can't work together unless money is involved or something.
;)
Of course, this round they'll be including BSD (read: FreeBSD) in their argument.
Actually, Qt/X11 was never under a propreitary license. It was under the QPL, which made one important exemption to commercial companies. This also made it not GPL-Compatible. Just because a license is GPL-Compatable does not mean that it is a propreitary license. Just look at the Python 2.0 license. It qualified as a licensed under the Debian Free Software Guidelines and the Open Source Initiative guidelines, but it was dubbed by the Free Software Foundation as a propreitary license [it was not GPL-compatbile]/
Apple Cinema Display (22" flat panel) $2,499.00
Apple Studio Display (17" flat panel) $999.00
Apple Studio Display (15" flat panel) $599.00
And just in case you think they might change their minds later and try to close it back up and make it nonfree there is this
Hello, Nerd alert!
You should PHP-DEV when it gets to release time and people want to merge unneeded patches into the release branch.. now thats a flame war :)
Well at first i have to say i am a happy KDE user. I think the KDE team did a great work on KDE2, and for me it's fast enough and perfectly useable.
/. crowd ;-)
Anyway, i was wondering really what all that stuff about GNOME-2.0 means, and i'd wish to have some additional explanation.
As i understood there was two goals in GNOME-2.0:
1- use of GTK+-2.0
2- changes in the architecture (between gnome core and bonobo)
So, what exactly are the roles of bonobo, lignome and libgnome(ui) in gnome, and what exactly was at stake there ?
Thank you all,
I think they threw away the CORBA baggage because they refused to live with the BigDesignUpfront. I think this was a big mental shift for the KDE team that day. See my other post for more detail.
Your pizza just the way you ought to have it.
We don't need another hero(can you hear Tina Turner?) Join the communist revolution and become ONE with MSoft. Together we stand devided we fall. Help crush this democratic software by not supporting it and spreading lies. They don't allow any user input, just coder dictorialship. When was the last time YOU were in charge. At MSoft, YOU ARE. Really folks do I have to tell you the truth? Like electricity, the FLOW of money creates money. You take money out of software and you won't be able to perpetuate your pipe dreams...because you'll starve or crash the economy. With that said, we could eat the people of GNOME and LINUX for food to solve our economic peril.
You know the Microsoft destroys the night, Linux devides the day...
First time I hear it, but seems to me like a wonderful idea. In fact, IMHO, it's high time to start thinking about some "component standard" of sorts, at least at the OS level. Too much time lost doing the same ****dy things once and again.
Anybody knows more about it? Or where to find info of what's pretended (done I infer not much)? Thanks for any info. :)
--
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
it's a self organising network in effect!
i was angry:1 with:2 my:4 friend - i told:3 4 wrath:5, 4 5 did end.
i was angry:1 with:2 my:4 friend - i told:3 4 wrath:5, 4 5 did end.
i was 1 2 4 foe i 3 it not 4 5 did grow
I don't know the details of the situation but I do agree that you do need to be able to take some heat from those who disagree with your opinions. What you also need to be able to do is accurately guage the cost of "winning" or "losing" a battle like that and whether the fight is worth it in the end. Several years ago I worked on a large project for a year and a half where virtually nothing was accomplished due to various groups fighting over what the "right" solutions were. The fact was that any solution would have better than what was occurring. One of the issues was NeXTStep vs Windows 3.1 for a certain group of users. Even though technically superior, I eventually withdrew my support for NeXTStep because it became clear that the project needed more than grudging compliance from the technical staff that opposed NeXTStep in order for the project to succeed. My opinions from that point forward suddenly carried a lot more weight because I was seen as someone who was above the platform wars. I eventually left that project for another group because I wanted to do NeXTStep development, but I know my decision was the correct one. Forcing NeXTStep into that situation would have guaranteed its failure and would have cost me significant political clout.
I havent used GNOME for a long time. i didnt care for the look of it or its "features" which I never used. Plus, I have 28 MB of memory and found i hard to be productive.
Not always. A few years back, I ran a project that comprised a handful of sharp people who "got it" and a larger group who just didn't. (e.g. rather than reading configuration files at run time, they would look up the value of interest at development time and hard code it in "for efficiency"). Management was clearly on the side of the later camp (now, there's a long story). After about a year of trying to work things out, I came to a realization: if I left and turned things over to my second-in-command, the project could be completed in time. It would be brittle and hell to maintain, but it would be done. If I stayed it would fail, since my efforts to proselytize The Right Way had made me the focus of the flame war and was attracting way too much "help" from upper management. So, I turned it over to him, and switched to another project where I could be effective. Both get finished, while if I had "stuck to my guns" I suspect neither would have.
Without any reference to the specifics of the Gnome situation, quitting a project can be the right thing to do.
-- MarkusQ
I find it EXTREMELY surprising that some people are still under the impression that either KDE or Qt (or both) are not free software! I'm not involved in either project (I'm just a ordinary KDE-user), and even I know how things are! Then why do some people directly (more or less) involved in Gnome still think that KDE and/or Qt is not under GPL? I would think that they knew alot more about these things that I do, but apparently it's not so.
If you have spent 5 minutes going through trolltechs web-site and kde.org, you would have found out that Qt is licensed under QPL and GPL and KDE is licensed under GPL. So what's the problem?RMS has done ALOT of good things to Linux and Free Software in general, but the way he handled the KDE/Qt-issue is just plain awful! First he condemned KDE and Qt, because at that time Qt was under QPL and not GPL. Then with his blessing, Gnome-project was started. So I can understand why Gnome is his pet-project
And what happened when Qt got licensed under GPL? No, RMS didn't congratulate them for embracing Free Software. He said (and I quote here): "you have to beg for forgiveness". Oh come on!. Just what the hell is that about?
Maybe he was just annoyed that the project he loved to hate lost the only reason he had to hate it.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
The whole point is that if the software industry (including open source software) wants to advance, it needs to embrace better tools.
Perhaps Java would be a good choice. Wait, I am wrong, it shares too much syntactically with C/C++ to be much of an improvement.
Java shares very little with C/C++, other than a superficial syntactic similarity. Java is a safe language with reflection and dynamic typing. Java would be an excellent choice for open source projects. It's far from state of the art, but it is decades ahead of C/C++.
It shows how C++ can be written in a style such that it looks very much like Perl or Python. It can be as high-level as you need it to be.
Which only goes to show that people don't understand. You cannot write C++ code in a Perl/Python/Java style because C++ lacks the runtime safety and support for reflection.
In fact, a big part of the problems of systems like Gnome and KDE is that they are reinventing dynamic typing and reflection. The end product is a baroque, inefficient mess that is much more complicated to learn and maintain than if you used a language with those facilities built in.
Java allows data structures to be created, examined, and traversed at runtime. You can even load and generate Java code at runtime, portably and efficiently. Java has sandboxing that allows programs to protect themselves from faults in dynamically loaded components.
What C/C++ offer is completely inadequate for building easy to use GUI libraries, component systems, persistence, and distributed programming systems. Developers of systems like KDE and Gnome are misleading developers by claiming that their systems are written in industry standard languages, when what they actually deliver amounts to a non-standard object extension of a standard language that ends up being less reliable, less usable, and more complex than if they were based on well designed languages in the first place.
I think another, related problem we are seeing is that the open source developer community represents a wide range of skills (just like most commercial programmer communities). So, if you use advanced tools and methodologies, you get a tiny developer community. If you use primitive tools and technologies (like the tools and technologies Gnome and KDE are based on), you get lots of developers, but you run into maintenance and architectural problems down the road.
I don't have a good solution. I think things will only improve as the general level of education advances beyond what it is now.
Simple, C++ makes OO programming easier through classes, inheritance, polymorphism, etc. You can do OO analysis and design independent of the programming language you choose, and implement that design in C. But the code is harder to maintain and is more complex.
I suggest you pick up Bjarne Stroustrup's book on C++
I agree with your statements. I do believe that applications should definitely move past C and possibly even C++. However application frameworks (Gnome) and Widget sets (GTK) could benefit from C++ today! C++ is still a system-level language and is capable of very good execution speeds. It should be used as such.
Someday applications will be written in higher-level languages (not JAVA!)...but not yet...
By saying this, I'm begging to be flamed...here goes...
One of the problems with Gnome is that its too complex, and one of the reasons it is too complex is that it uses C.
C++, used correctly, reduces complexity. Anyone who disagrees with this just doesn't understand C++ and OO-programming. I attribute this to some of the success of KDE. They can do more with less code. Writing a QT app is *much* easier than writing a GTK app for a competent C++ coder. Period.
C++ has its problems, especially with Linux. GCC is just starting to become ANSI C++ compliant. Also loading a QT app takes forever because the Linux Dynamic Linker is slow when it has to resolve a zillion vtable entries when everything is derived from QObject. However, C++ is progress in the right direction. C++ encourages OO programming which is the biggest software engineering productivity increase in the last 20 years.
The Linux community needs to move past the traditional Unix-realm and start embracing C++. Especially for GUIs and application frameworks! They need to solve the remaining issues with C++ such as incompatible libraries.
is that it tries to get too much done at once. This makes it very unstable (from personal experience). KDE does have a few bugs but it seems to me like there are less. This is just what I have seen from experience so I don't want this to turn into another "KDE is better/worse than GNOME" fight.
---
------
Sig