Correct me if I'm wrong, but other builds are not supposed to use Mozilla's branding anyway.
You are more or less correct... it depends on how close the compile flags a distro uses are to those used by the mozilla project. They don't need to match one by one, they just need to be close enough (so I can imagine that a simple i686 optimized build with -O will pass - see this email.)
17.3. How many FreeBSD hackers does it take to change a lightbulb? One thousand, one hundred and sixty-nine: Twenty-three to complain to -CURRENT about the lights being out; Four to claim that it is a configuration problem, and that such matters really belong on -questions; Three to submit PRs about it, one of which is misfiled under doc and consists only of “it's dark”; One to commit an untested lightbulb which breaks buildworld, then back it out five minutes later; Eight to flame the PR originators for not including patches in their PRs; Five to complain about buildworld being broken; Thirty-one to answer that it works for them, and they must have cvsupped at a bad time; One to post a patch for a new lightbulb to -hackers; One to complain that he had patches for this three years ago, but when he sent them to -CURRENT they were just ignored, and he has had bad experiences with the PR system; besides, the proposed new lightbulb is non-reflexive; Thirty-seven to scream that lightbulbs do not belong in the base system, that committers have no right to do things like this without consulting the Community, and WHAT IS -CORE DOING ABOUT IT!? Two hundred to complain about the color of the bicycle shed; Three to point out that the patch breaks style(9); Seventeen to complain that the proposed new lightbulb is under GPL; Five hundred and eighty-six to engage in a flame war about the comparative advantages of the GPL, the BSD license, the MIT license, the NPL, and the personal hygiene of unnamed FSF founders; Seven to move various portions of the thread to -chat and -advocacy; One to commit the suggested lightbulb, even though it shines dimmer than the old one; Two to back it out with a furious flame of a commit message, arguing that FreeBSD is better off in the dark than with a dim lightbulb; Forty-six to argue vociferously about the backing out of the dim lightbulb and demanding a statement from -core; Eleven to request a smaller lightbulb so it will fit their Tamagotchi if we ever decide to port FreeBSD to that platform; Seventy-three to complain about the SNR on -hackers and -chat and unsubscribe in protest; Thirteen to post “unsubscribe”, “How do I unsubscribe?”, or “Please remove me from the list”, followed by the usual footer; One to commit a working lightbulb while everybody is too busy flaming everybody else to notice; Thirty-one to point out that the new lightbulb would shine 0.364% brighter if compiled with TenDRA (although it will have to be reshaped into a cube), and that FreeBSD should therefore switch to TenDRA instead of GCC; One to complain that the new lightbulb lacks fairings; Nine (including the PR originators) to ask “what is MFC?”; Fifty-seven to complain about the lights being out two weeks after the bulb has been changed. Nik Clayton <nik@FreeBSD.org> adds: I was laughing quite hard at this. And then I thought, “Hang on, shouldn't there be '1 to document it.' in that list somewhere?” And then I was enlightened:-)
The question is: is your account of the events as trustworthy as your summary of ScottL's words? In your reading, ScottL called open's devs a bunch of fuckers, whereas he merely criticized Theo's style. Now I don't agree with ScottL's criticism - he should have told (I assume he didn't) of a better way of getting Adaptec to cooperate, instead of just saying that Theo's is wrong. But given your (mis)representation of ScottL's point, you don't expect me to take your word on PHK's actions on its face value, do you?
I don't see in any way Scott's comment implying that OpenBSD's devs are a bunch of fuckers. Also, he seems to agree with the points Theo makes and criticizes his style - that is nowhere near to what your original post implies. Actually, I don't agree with Scott's criticism here - I don't have anything agains Theo's style in this instance, but I can see that there might be valid arguments against the way he presented his case. However, I disagree with calling names and blowing the issue out of proportions - or "hyping up the myth" of tensions between various BSD projects. There are occasional tensions, yes, but I very much doubt that ScottL thinks of Open's devs as a bunch of idiots. Implying that he does will do a great disservice to all of us.
Where do you get that idea from? (I'm referring to Scott Long's opinion). For one thing, Scott Long is quick to put down trolls who try to foster the myth of some kind of politics taking place between the various BSDs.
There really are very few political forces that shape things between
the BSD's, whereas the amount of cooperation is actually quite strong
and pleasant. Hyping up the politics myth only does a disservice to
everyone.
Why do you have to do exactly the thing ScottL speaks about there?
Have your read the article?;) That's one of the questions it answers very clearly:
I was curious to understand more about what happens at the OpenBSD hackathons, and if there is a goal or focus behind each one. Henning Brauer laughed and explained, "there is no focus for the hackathons. I mean, get real, you can't work on a single thing with over 50 (over 60 this time) developers." Peter Valchev added, "there is no specific focus for any of the events, everyone gets together and works on whatever they want to. Really it all works out by itself, because the developers know what's important to work on - it's not something they need to be told."
This is a really nice interview - and shows that openbsd is a nicely managed distribution... I mean there is a strong sense of community among their developers, and social events like these serve to enchance that sense. This was funny:
Bob Beck, who is responsible for making the barbecue happen, notes, "the barbeque has become sort of a tradition, We host it at Theo's house, normally with whatever meat I've managed to bag the previous hunting season. Normally it's moose and/or deer marinated kebabs with raisin rice pilaf. The recipe is recorded for posterity in any openbsd distribution in/usr/share/games/recipes, in hackathon proportions."
Yeah... and not only that, but it is somewhat ironic to hear them scolding KDE developers for not making the mistake they made (code bloat pre-1.4 mozilla). Also, Opera's engine as well as khtml is much much faster than gecko, especially rendering tables like these - try it out with both browers (or see rendering if multiple tabs are open, not to mention memory consumption). I think this is an excellent example of sour grapes (many considered - don't ask me why - that Apple's choice of using khtml was an insult to gecko, or at least that's what people read between the lines in the original announcment by an apple engineer, who emphasized correctness, elegance and compactness (10th the size of gecko at that time) of the khtml codebase.
Well, I didn't think that my post was particularly interesting, stating the obvious and all;) On the other hand, you clearly missed the "They are customized for my own needs and are not representative." part of parent's post, so your Gollum act on KDE 3.4 was unresonable. Even if GP's screenshots were representative of the defaults of KDE, the point that for the end-user kde will look like the way its vendors customize still remains.:)
on second thought: maybe I took your post too seriously, but then, a funny mod would have been more appropriate:)
No, your interpretation is right... more or less. There are some instances where there is a single application that blends in nicely (fitting in well with the look and feel) of the environment - kopete is one of those instances. It is also a pretty good IM, so I feel that there is little or few reasons one might be clamoring for alternatives. In other instances, there are multiple applications performing the same function, the same way as there are multiple apps for certain tasks in Windows. Music players (Juk, Amarok, Noautun, etc.), office tools (oo.o 2.0 will have a native look on kde, so you can choose b/w it and koffice), movie players (kaffeine, kplayer, KMplayer), ftp clients just to name a few.
So the range of applications is perhaps not as wide as in windows (but then, when it comes to quality, there is hardly any good and free alternative to nero that matches the quality of k3b), but then you'll have users complaining that there is too much choice;) I can see their point too, even though too much choice never really bothered me in KDE: instead of having to choose between one or two really good quality progs, the user must spend a lot of time finding the app that suits his or her needs. This can get really counterproductive - I went through this experience when I was fishing for a good CMS on opensourcecms.org - and I saw comments implying that many users spent considerable time trying to find the right one, for there are hundreds of open source CMS out there (I saw someone who tried out 17!). The problem is that most of them are mediocre and they are not that different from each other, so in this instance, having fewer but better quality CMS systems would be better.
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
You forgot the chronology when you write that "And Apple's team spent countless man hours on their fork. Should we expect them to give it up because their changes aren't compatable or easily integrated into KHTML?" - Apple spent two years writing safari providing only the bare minimum required by law to satisfy khtml's licence. Khtml devs expected more? Was it their fault to expect more? No, because apple likes to trumpet how good citizens they are in the OSS community. If they they said it upfront that they gonna take the code, don't intend to cooperate, will release source as required by the GPL every now and then, than nobody would have a problem with that. The 'offer' you cite is dated mai 5 - a week ago. I speak of two years of unwillingness to cooperate, than suggesting somthing that is - understandably - not acceptable.
But most importantly, khtml developers are pissed by ignorant users who demand them to merge changes back, and if they are not fast enough they attribute it to their laziness or somesuch. And even if they implement something (probably from scratch, for going through a 60Mb codebomb might be more difficult)./ posters will attribute the success to Apple, which is no fun.
For more clue, read Pete's post - I entirely agree with whatever he wrote there.
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
Yes, I read the article, and you conveniently ignore the fact that "[khtml devs] suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code." This is not about cooperation or providing useful changelogs and patches - it is about the barrier Apple raised for sharing even bug reports. Saying that you have to do this and this and this otherwise we don't share bug fixes with you is not a good sign of cooperation.
So, back to my point, which still stands: APPLE ignored any request for incremental changelogs in the past, and even the offer to sign an NDA. In other words, APPLE ignored any attempt on the part of kde devs to faciliate cooperation. They are far from being equally uncooperative, and even APPLE knows that. That is what the article is about btw - Apple recognizing their mistake (or at least one of their safari developers) and trying to come up and asking for solutions. And there goes you saying that Apple is no more responsible for this situation than KDE developers while "Apple declined to comment for this story. But Safari engineer David Hyatt did acknowledge KDE complaints in his blog, defending the scope of recent patches and soliciting suggestions on improving Apple's relationship with KDE."
While I have to applaud David Hyatt efforts, I don't think that everything we see as a solution from Apple is entirely honest. You can't expect khtml developers to ditch their own codebase in favour of webcore - that is a pretty cruel thing to ask from people who spent hundreds of manhours polishing, refining and improving their code, and became somewhat attached to it. And I believe Apple knows that as well.
So about this 'patches' thing? What did you have in mind when you wrote: "Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches."
Are you aware of the fact that you can configure almost every aspect of KDE - including colors, icons, style? Also, KDE doesn't have its own distribution - so it is up to distro makers to change the default look to whatever they like.
...but I am a programmer and user interface designer
Yeah, sure, and you have a degree in communication as well I assume? (BLEAH. Positively BLEAH.). (Come on mods, who modded that post interesting?)
Am I the only one who hates the way the whole GNU/Linux community is split up?
Unfortunately, no, you are not alone with this opinion. What you fail to see is that there developers are not droids. In other words, you can't think of them as a pool that you can shape into whatever form you like. You can't tell a GNOME developer to work for KDE because the latter has a better chance of success (as it seems now). The GNOME developer works on GNOME because that is what he wants to work on. And this is not necessarily a bad thing: competition between the two major desktop environments might be considered as a driving force behind the rapid growth of linux DEs actually.
For instance GNOME and KDE have incompatible aims - they approach usability from different perspectives ("less is more" vs. "more and more, better organized" to put it very simply). On the other hand, standardization of low level services/components might be a good thing, and work is already in progress (albeit I have to admit it is slow) to achieve that via freedesktop.org. Also, you have to be aware of the contradiction of your post: your problem is that there is too much and too few choice at the same time. You'd prefer to use GAIM instead of kopete (you have a choice) but because you choose KDE, you have to use Kopete for a consistent look (no choice). The question you need to ask is this: what is the problem with Kopete? What I'm trying to say is that KDE's application stack becomes more and more complete. They have their own, well integrated office suite (koffice). They have kopete, music players, webbrowser, even a viable gimp replacement for average needs (have you seen krita in koffice 1.4beta? - it is absolutely fascinating!) - and so on.
What needs to be done is to improve that application stack. So if Kopete is not fully satisfactory (you would like to use GAIM, don't you?) - than you should specify the problems. If a number of users agree with your claim - and that's the point of this article - you would be able to communicate your needs/problems to the developers, helping them improve the app you are currently 'forced' to use.
Hmmm... that's very nice. KDE can learn a lot from the pitfalls GNOME went through in their quest for usability. I'm thinking of the failure to provide facilities to establish communications between developers, users, and usability experts. This was one of the gripes of Eugenia not so long ago (and as much as I hate to admit it, she was right!). It seemed to me that the main problem was that usability changes was decided by fiat - spatial browsing as the default, reverse button order, and a few years ago, the file selector - there was and still is a sense that some of these are 'forced' down the users throat by developers who like to cite their HIG (yet they violate it in the next turn by frustrating user-expectations). Anyway, the sign that KDE is heading towards the right direction is the effort they put into providing a framework with the purpose of faciliating communication between users, experts and developers. What I have in mind is the bugzilla equivalent for usability suggestions/comments that the article mentions.
The work they have done with KDE 3.4 speaks volumes about the success and the potential of these efforts. If you had problems with the 'clutter' of KDE before (I never had I might add) and haven't tried KDE 3.4... you should. And they did it without frustrating their present userbase: no features were removed, they were just reorganized. This seems to be the difference between gnome and kde approach to usability. GNOME seems to have the 'less is more' mantra, while KDE has the 'more, better organized' mantra. Both have its merits btw - I can very well imagine that GNOME's approach suits some user's taste better, so no flames please. Me, I love every feature, and those that I don't use can be easily removed (more easily than in previous KDE iterations).
It is also interesting to see how developers had to be "converted" to cooperate with openusability folks - and it is really nice to hear that this has been a success story so far (11 KDE projects already work closely with openusability - and what's more, they enjoy it:) For instance:
"The reports produced by OpenUsability are, according to Adam, "full of clear, concrete ideas that are well-reasoned, that have an overall vision, and that follow principles. They are also an appropriate length, without being too long or vague."
For the Nth time: they don't have a problem with apple using their code. They have a problem with clueless users thinking that the relationhip between apple and khtml is excellent, so whenever something present in safari is not immediately incorporated in khtml, they blame khtml devs (thinking they are lazy or simply they just don't want to incorporate new features).This has been posted over and over and over again as a reply to ignorant posts like yours - so here we go again:
In the past when someone spent long hours implementing something in KHTML, they at least got a thank you from people using Konqueror. Now its well finally! It was working in Safari. khtml developers are lazy. Wheres the fun in that?
Do you have any idea how hard it is to be merging between two totally different trees when one of them doesnt have any history? Thats the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDAs with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.
And you know what? Thats their right. They made a conscious decision about not working with KDE developers. All Im asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. Theres absolutely nothing great about it. In fact it doesnt exist. Maybe for Apple - at the very least for their marketing people. Clear?
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 5, Insightful
This is unbelievable (I mean the +5 insightful moderation). How can one claim that KDE developers have been just as uncooperative. They set up a mailing list specifically for Apple devs. They gave CVS access. All they asked was incremental changelogs instead of 60Mb code dumps. They even offered to sign NDAs with apple (and their offer was completely ignored) in order to get them.
"The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version."
This is quite ignorant. There are, admittedly some OSS project that are perpetually at a BETA stage. KDE is not one of them. KDE 3.4 had a few weeks of beta testing, and then it was released as final. Just as Tiger. Yes, there were a few bugs found since RELEASE - just as there were bugs in Tiger, and probably there will be more till the next release.
KDE developers did everything they could to help cooperation - in vain. And they don't even regret that as much as they regret that there are clueless users who overestimate APPLE's contributions.
And this makes hardly any sense:"Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches." Excuse me? What were you trying to say?
Mods: congrats!
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 1
That's quite interesting... now GP is modded down, AC up - without checking the facts. Is a 2003 posting to a mailing list evidence? In fact, the current issues in the safari vs khtml debate that none of the cooperation that khtml devs were hoping for happened. This is the first reply to the email:
I love them!! That's something I would never have expected, simply
overwhelming! Apple cooperating with KDE, that deserves a party;-)
And this is how two years later things are:
All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist.'(Zack Rusin)
Quote from AC: "Again, people, stop modding this up, he's a clueless idiot spreading lies." Yeah, right, and a two year old mailing list message is all the evidence that AC comes up to support his claim.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 4, Interesting
You miss the point. The main complain of khtml developers is that clueless users think that once a feature is present in Safari, it would be easyt ot port it to konqi. Quote:
And you know what? Thats their right. They made a conscious decision about not working with KDE developers. All Im asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. Theres absolutely nothing great about it. In fact it doesnt exist. Maybe for Apple - at the very least for their marketing people. Clear?
Also, this is not just "a problem for KDE." One reason for the difficulties is that Apple has different sets of priorities than khtml devs. Apple wants feature X present by a deadline. KHTML devs place equal importance on keeping the code clean and optimized. As a result, the Safari code is not up to KDE's coding standards:
Actually the biggest problem right now is that Apple are not keeping up with code-cleanup. We constantly try to develop more elegant easier to maintain code, where as Apple wants the right features - right now.
Safari is basically still KHTML from KDE 3.1 with a ton of bug fixes and features. Many of the features takes time to port because they do not live up to our coding standards.
I think this situation could have been avoided if Apple tried to cooperate with KDE from the very beginning - and kde guys did quite a lot (creating specific mailing lists, giving cvs access, etc) to help apple devs. What KDE guys were asking for would have benefitted everyone: code cleanup could have been easily integrated into safari (some kde devs even offered to sign an NDA's to help!) while features might have been integrated into khtml. This is clearly a win-win situation that Apple missed.
A note on zealotry (not directed to parent post... it is a general complaint).
1) It is quite funny that when I was discussing this on osnews, a bunch of people jumped on my posts calling kde devs names (whiners, zealots, whatevers) and praising apple for their huge contribution to OSS. And no matter how hard I tried, I couldn't get them understand that the main problem of khtml developers is not that Apple didn't contribute back enough (although that is part of the problem). Their problem was that - the result of Apple's marketing campaign about being first class citizens of the OSS community - users thought that they don't implement features present in Safari because they are lazy or they just don't want to or whatever. In other words, their gripe was with clueless users.
2) Check the asnwers to Carewolf's post. Apology, apology, apology... like "users DO NOT CARE if your code is 'elegant' and 'easier to mantain', users WANT THINGS TO WORK whether or not they are 'elegant' or 'adequate'." (why is he shouting? - and most importantly, why is he modded insightful?). IMHO, this kind of APPLE can't do wrong does disservice to APPLE - one of the keys to do successful business is to recognize the mistakes one makes in order to avoid them in the future. You can love APPLE and be critical at the same time!
Re:I hope it's better than 5.3
on
FreeBSD 5.4 Released
·
· Score: 2, Informative
If you read the ext2 notes, it is not supported very well. Nevertheless, I have never had any issues with it - except for dirty filesystems after boot. One of them devs sent a patch (Michael Nottebrock) - download it here. - that will unmount your ext2 filesystem before running the rest of shutdown procedure.
I agree with you. On the other hand it would be fun to reverse the challenge - lets leave a site online with 0 effort of trying to secure it.
Now I think it would interesting (and risky too) if one would just install... lets say FreeBSD, and leave everything as it is: firewall is off by default in such an instance, securelevel is at 0 I think (or -1), etc. Install apache current version, copy some htmls (and later perhaps a php-based CMS) in public www area, and leave it at that. In other words, do nothing to secure your server. Than make a big brouhaha of a challenge to hack in in a few weeks timeframe.
I think it would be devastating for MS if it would survive for the same amount of time, as their locked down and secured and patched server, especially since they would probably publish a longish article about how to secure IIS6...:)))
Next you'll be telling us that someone could just look at an application working and then write their own implementation incorporating some of the same ideas.
I know, it's old, but that's exactly what Linus agreed to by using BitKeeper - effectively Linus granted a software patent to BitKeeper when he agreed that no OpenSource replacement (read: software implementing similar functionality) will be written in exchange for using it.
Slashdot Mirror
You are more or less correct ... it depends on how close the compile flags a distro uses are to those used by the mozilla project. They don't need to match one by one, they just need to be close enough (so I can imagine that a simple i686 optimized build with -O will pass - see this email.)
And then:
Anyways, feel free to view things as you will, I really don't mind - but do try not to dismiss one person being an ass...
Now who is overreacting? Ironically, my whole point was that you are overreacting some of the things some of the FreeBSD developers said ;)
The question is: is your account of the events as trustworthy as your summary of ScottL's words? In your reading, ScottL called open's devs a bunch of fuckers, whereas he merely criticized Theo's style. Now I don't agree with ScottL's criticism - he should have told (I assume he didn't) of a better way of getting Adaptec to cooperate, instead of just saying that Theo's is wrong. But given your (mis)representation of ScottL's point, you don't expect me to take your word on PHK's actions on its face value, do you?
I don't see in any way Scott's comment implying that OpenBSD's devs are a bunch of fuckers. Also, he seems to agree with the points Theo makes and criticizes his style - that is nowhere near to what your original post implies. Actually, I don't agree with Scott's criticism here - I don't have anything agains Theo's style in this instance, but I can see that there might be valid arguments against the way he presented his case. However, I disagree with calling names and blowing the issue out of proportions - or "hyping up the myth" of tensions between various BSD projects. There are occasional tensions, yes, but I very much doubt that ScottL thinks of Open's devs as a bunch of idiots. Implying that he does will do a great disservice to all of us.
Oh no, not that kind of trolling again about PHK and others. MODS????
Yeah... and not only that, but it is somewhat ironic to hear them scolding KDE developers for not making the mistake they made (code bloat pre-1.4 mozilla). Also, Opera's engine as well as khtml is much much faster than gecko, especially rendering tables like these - try it out with both browers (or see rendering if multiple tabs are open, not to mention memory consumption). I think this is an excellent example of sour grapes (many considered - don't ask me why - that Apple's choice of using khtml was an insult to gecko, or at least that's what people read between the lines in the original announcment by an apple engineer, who emphasized correctness, elegance and compactness (10th the size of gecko at that time) of the khtml codebase.
on second thought: maybe I took your post too seriously, but then, a funny mod would have been more appropriate :)
So the range of applications is perhaps not as wide as in windows (but then, when it comes to quality, there is hardly any good and free alternative to nero that matches the quality of k3b), but then you'll have users complaining that there is too much choice ;) I can see their point too, even though too much choice never really bothered me in KDE: instead of having to choose between one or two really good quality progs, the user must spend a lot of time finding the app that suits his or her needs. This can get really counterproductive - I went through this experience when I was fishing for a good CMS on opensourcecms.org - and I saw comments implying that many users spent considerable time trying to find the right one, for there are hundreds of open source CMS out there (I saw someone who tried out 17!). The problem is that most of them are mediocre and they are not that different from each other, so in this instance, having fewer but better quality CMS systems would be better.
But most importantly, khtml developers are pissed by ignorant users who demand them to merge changes back, and if they are not fast enough they attribute it to their laziness or somesuch. And even if they implement something (probably from scratch, for going through a 60Mb codebomb might be more difficult) ./ posters will attribute the success to Apple, which is no fun.
For more clue, read Pete's post - I entirely agree with whatever he wrote there.
So, back to my point, which still stands: APPLE ignored any request for incremental changelogs in the past, and even the offer to sign an NDA. In other words, APPLE ignored any attempt on the part of kde devs to faciliate cooperation. They are far from being equally uncooperative, and even APPLE knows that. That is what the article is about btw - Apple recognizing their mistake (or at least one of their safari developers) and trying to come up and asking for solutions. And there goes you saying that Apple is no more responsible for this situation than KDE developers while "Apple declined to comment for this story. But Safari engineer David Hyatt did acknowledge KDE complaints in his blog, defending the scope of recent patches and soliciting suggestions on improving Apple's relationship with KDE."
While I have to applaud David Hyatt efforts, I don't think that everything we see as a solution from Apple is entirely honest. You can't expect khtml developers to ditch their own codebase in favour of webcore - that is a pretty cruel thing to ask from people who spent hundreds of manhours polishing, refining and improving their code, and became somewhat attached to it. And I believe Apple knows that as well.
So about this 'patches' thing? What did you have in mind when you wrote: "Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches."
Unfortunately, no, you are not alone with this opinion. What you fail to see is that there developers are not droids. In other words, you can't think of them as a pool that you can shape into whatever form you like. You can't tell a GNOME developer to work for KDE because the latter has a better chance of success (as it seems now). The GNOME developer works on GNOME because that is what he wants to work on. And this is not necessarily a bad thing: competition between the two major desktop environments might be considered as a driving force behind the rapid growth of linux DEs actually.
For instance GNOME and KDE have incompatible aims - they approach usability from different perspectives ("less is more" vs. "more and more, better organized" to put it very simply). On the other hand, standardization of low level services/components might be a good thing, and work is already in progress (albeit I have to admit it is slow) to achieve that via freedesktop.org. Also, you have to be aware of the contradiction of your post: your problem is that there is too much and too few choice at the same time. You'd prefer to use GAIM instead of kopete (you have a choice) but because you choose KDE, you have to use Kopete for a consistent look (no choice). The question you need to ask is this: what is the problem with Kopete? What I'm trying to say is that KDE's application stack becomes more and more complete. They have their own, well integrated office suite (koffice). They have kopete, music players, webbrowser, even a viable gimp replacement for average needs (have you seen krita in koffice 1.4beta? - it is absolutely fascinating!) - and so on.
What needs to be done is to improve that application stack. So if Kopete is not fully satisfactory (you would like to use GAIM, don't you?) - than you should specify the problems. If a number of users agree with your claim - and that's the point of this article - you would be able to communicate your needs/problems to the developers, helping them improve the app you are currently 'forced' to use.
The work they have done with KDE 3.4 speaks volumes about the success and the potential of these efforts. If you had problems with the 'clutter' of KDE before (I never had I might add) and haven't tried KDE 3.4... you should. And they did it without frustrating their present userbase: no features were removed, they were just reorganized. This seems to be the difference between gnome and kde approach to usability. GNOME seems to have the 'less is more' mantra, while KDE has the 'more, better organized' mantra. Both have its merits btw - I can very well imagine that GNOME's approach suits some user's taste better, so no flames please. Me, I love every feature, and those that I don't use can be easily removed (more easily than in previous KDE iterations).
It is also interesting to see how developers had to be "converted" to cooperate with openusability folks - and it is really nice to hear that this has been a success story so far (11 KDE projects already work closely with openusability - and what's more, they enjoy it :) For instance:
"The reports produced by OpenUsability are, according to Adam, "full of clear, concrete ideas that are well-reasoned, that have an overall vision, and that follow principles. They are also an appropriate length, without being too long or vague."
Nice!
"The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version."
This is quite ignorant. There are, admittedly some OSS project that are perpetually at a BETA stage. KDE is not one of them. KDE 3.4 had a few weeks of beta testing, and then it was released as final. Just as Tiger. Yes, there were a few bugs found since RELEASE - just as there were bugs in Tiger, and probably there will be more till the next release.
KDE developers did everything they could to help cooperation - in vain. And they don't even regret that as much as they regret that there are clueless users who overestimate APPLE's contributions.
And this makes hardly any sense:"Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches." Excuse me? What were you trying to say?
Mods: congrats!
Quote from AC: "Again, people, stop modding this up, he's a clueless idiot spreading lies." Yeah, right, and a two year old mailing list message is all the evidence that AC comes up to support his claim.
A note on zealotry (not directed to parent post ... it is a general complaint).
1) It is quite funny that when I was discussing this on osnews, a bunch of people jumped on my posts calling kde devs names (whiners, zealots, whatevers) and praising apple for their huge contribution to OSS. And no matter how hard I tried, I couldn't get them understand that the main problem of khtml developers is not that Apple didn't contribute back enough (although that is part of the problem). Their problem was that - the result of Apple's marketing campaign about being first class citizens of the OSS community - users thought that they don't implement features present in Safari because they are lazy or they just don't want to or whatever. In other words, their gripe was with clueless users.
2) Check the asnwers to Carewolf's post. Apology, apology, apology... like "users DO NOT CARE if your code is 'elegant' and 'easier to mantain', users WANT THINGS TO WORK whether or not they are 'elegant' or 'adequate'." (why is he shouting? - and most importantly, why is he modded insightful?). IMHO, this kind of APPLE can't do wrong does disservice to APPLE - one of the keys to do successful business is to recognize the mistakes one makes in order to avoid them in the future. You can love APPLE and be critical at the same time!
If you read the ext2 notes, it is not supported very well. Nevertheless, I have never had any issues with it - except for dirty filesystems after boot. One of them devs sent a patch (Michael Nottebrock) - download it here. - that will unmount your ext2 filesystem before running the rest of shutdown procedure.
Now I think it would interesting (and risky too) if one would just install ... lets say FreeBSD, and leave everything as it is: firewall is off by default in such an instance, securelevel is at 0 I think (or -1), etc. Install apache current version, copy some htmls (and later perhaps a php-based CMS) in public www area, and leave it at that. In other words, do nothing to secure your server. Than make a big brouhaha of a challenge to hack in in a few weeks timeframe.
I think it would be devastating for MS if it would survive for the same amount of time, as their locked down and secured and patched server, especially since they would probably publish a longish article about how to secure IIS6 ... :)))
I know, it's old, but that's exactly what Linus agreed to by using BitKeeper - effectively Linus granted a software patent to BitKeeper when he agreed that no OpenSource replacement (read: software implementing similar functionality) will be written in exchange for using it.
Mod parent up please +extrainsightful (methinks).
Linky. Somehow I screwed that in my post :(