Safari And KHTML May Never Meet 765
diegocgteleline.es writes "Announcing that Safari passes the Acid2 test has raised some voices in the KDE world. Apple, they say, isn't playing friendly. They don't provide a CVS history, just the modified files where nobody can understand how and when things have changed. It's quite likely that KHTML developers will have to write their own code to pass the acid2 test. Zack Rusin writes: '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.'"
He posted patches! (Score:5, Informative)
Re:He posted patches! (Score:5, Informative)
Re:He posted patches! (Score:5, Insightful)
Re:He posted patches! (Score:5, Interesting)
Unfortunately they don't merge very well. I've spend a few hours to merge two of them. The rest will probably require redeveloping.
Re:He posted patches! (Score:4, Insightful)
Re:He posted patches! (Score:3, Insightful)
Isn't that a heck of a head-start?
Re:He posted patches! (Score:3, Insightful)
Re:He posted patches! (Score:4, Insightful)
impossible reasoning (Score:4, Insightful)
as an open source developer, you either take what you can get (ie spend the time integrating the changes into the primary build) or you don't.
having patches that are 'compatible with the rcs system used by the original developers' is absolutely ridiculous. this is what diff is for.
trying to enforce things like specific commenting types and 'descriptions of the code' is just ludicrous - you should be happy people provide you with code, period - if it's too difficult to integrate, perhaps the original developers need a better revision control system that has a diff that works?
i can't count the number of days that i have spent integrating code from random developers around the world into our own open source project - could i have developed said features from scratch?
possibly, depending on what is being submitted.
could i have better spent the time doing new development for the project? potentially...
this kind of 'take what you can get' system is the foundation of open-source. you either take the contributions, or you don't.
whining about it because you have a big company that happens to have adopted your program is ridiculous.
there are hundreds of thousands of open source projects out there that would kill for a company like apple to donate code to them.
open source simply requires that they post their changes, not that they provide you with a 1-step integration of their forked code into your who-knows-what-has-changed 'primary' branch.
trying to force people to specifically donate their changes to the specific developer that happened to have posted the original code completely breaks the open-source model as well.
our current generation open-source game engine has gone through multiple lead developers - several of which just 'disappeared' off the face of the earth. being open source, other developers picked up the ball and continued the development of the engine.
in our case, the underlying graphics engine is owned by a company that has zero interest in supporting the open-source community (they bought the technology after it was open sourced) so this kind of forced submission process just will not work in the real world.
not only will it not work, but if the 'official' development team decides not to implement the code changes, who knows - perhaps there is another team out there that WILL integrate the changes...
this is the world of open-source. not every project has a linus at the top with the override of every step of the process.
Is this a joke? (Score:3, Insightful)
Re:Is this a joke? (Score:3, Insightful)
Even *Microsoft* does what they're legally required to do. If Apple wants to differentiate themselves, they have to do more than the minimum.
Re:Is this a joke? (Score:5, Funny)
And how many pieces of flare are you wearing?
Re:Is this a joke? (Score:3, Funny)
Just one.
Put it out! Put it out!
Re:Is this a joke? (Score:3, Insightful)
They're actually doing considerably more than the bare minimum, though I agree they should do more.
The bare minimum would be to provide, on request, to customers, the source code of the product shipped to the customer. This means they'd only give you their code when you ask for it, once it's out the door. The fact that we even have this acid test code, which might never ship, is proof that they're doing more than the "bare minimum".
Re:Is this a joke? (Score:5, Insightful)
Re:Is this a joke? (Score:4, Insightful)
Apple is developing "WebKit", not KHTML. They both have just evolved from a common codebase in the past.
Re:Is this a joke? (Score:5, Informative)
Re:Is this a joke? (Score:5, Interesting)
Funny thing is, I think you could argue that the GPL already more or less requires this:
Now it doesn't say that the changes actually have to be documented, but I am reading "the date of any change" to mean that the date for each single change needs to be specified, which would necessitate specifying what change belongs to which date, which comes pretty close to documenting the changes.
To get back on-topic, I'm actually curious if Apple is complying with this rule, and if so, with what interpretation of it. :-p
Comment removed (Score:5, Insightful)
But... But... (Score:5, Funny)
I give up, no more computers for me.
As if that ain't enough... (Score:5, Informative)
Hey, that gives me an idea - find a nice little comment somewhere a week or so back and submit it as news... yeah...
Apple tries to woo KDE folks (Score:5, Funny)
KTiger (Score:3, Funny)
Has anyone asked Hyatt? (Score:5, Informative)
Email him - ask? [google.com]
Re:Has anyone asked Hyatt? (Score:5, Interesting)
They don't look like they're asking for much, basically they'd like access to the Safari team's changelogs (and internal CVS I think) in order to see how the changes happened, why the modifications were made (because knowing that a modification was done but having no damn clue about why it was done can be quite useless) and where, and which internal of external features the modification uses.
From what i understood, in a nutshell, the KHTML guys merely used to ask for a documentation that was supposed to exist instead of big webcore tarballs, that was more or less denied and the KHTML guys stopped asking for it.
But they're quite annoyed about the buzz over Safari's change getting back to KHTML, which is something that they're not able to do.
On a side note, it should be reminded that KHTML is only part of the K distribution, which means that they can't afford to put more work in KTHML engine alone that on KDE for example.
Re:Has anyone asked Hyatt? (Score:5, Informative)
If this isn't enough info, I don't know what is. I suppose code for regression tests, etc. would be nice. But complaining about this is more likely to piss off Apple/Hyatt than to help. Plus, he does have his email address posted on his blog if you have questions. Or just post a comment, and I'd bet he'd answer it.
Re:Has anyone asked Hyatt? (Score:3, Interesting)
Re:Has anyone asked Hyatt? (Score:5, Insightful)
I understand why that can't simply be slapped into the KDE codebase but, c'mon -- is there now some obligation for everyone modifying GPL code to keep their modifications cross-platform? Apple's job is to improve and ship Safari, not to fix Konqueror.
With all due respect to Rusin and any other KHTML devs complaining, I don't get what the problem is. They're getting diffs in manageable chunks (some of which look directly usable), they're getting bugs pointed out and solutions offered -- it looks pretty helpful to me.
Re:Has anyone asked Hyatt? (Score:3, Insightful)
Re:Has anyone asked Hyatt? (Score:3, Informative)
Re:Has anyone asked Hyatt? (Score:3, Interesting)
Possibly, possibly not ... but if it's supposedly so bad for them to do what they are doing, why are you complaining.
They'll learn better from their own mistakes, if they are mistakes. All the complaining does is piss them off, and blind them to any problems they are creating because they won't want to admit the annoying people are right.
And as I said in the previous story [slashdot.org], there is a big difference between "what customers wa
Public release of Safari does not pass yet. (Score:5, Informative)
From yesterday's summary:
The patched Safari is not yet avaliable for public consumption. It is unknown when the patches will appear in a public version of Safari.
GPLv3? (Score:3, Interesting)
Or will any attempt to do so put too much burden on the users/modifiers of code?
Why cvs history is important for Khtml etc. (Score:5, Informative)
If you get fixes with no log of what they fix you will end up with bunch of code which you have no idea how to test for regressions. This is just one of the reasons why diffing codebase doesn't cut it.
Another good reason is damned diff is ~6mb because Apple guys never send small patches but only dump WebCore tarballs.
Re:Culture conflict? (Score:4, Insightful)
Blog Entry (Score:5, Informative)
You cant even imagine how I hate that question. The truth is most probably never. I just read the article on
Code in Safari is hugely inconsistent and changes are always interdependent. Theres basically no way of merging in one change without bringing a whole bunch of others in. And you know what? Dont even tell me about merging stuff like render_canvasimage.h,cpp. It outright uses OS X apis. Well never be able to merge that in - someone will have to implement it. And whats going to happen when someone does? Some jackass on
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?
The Sky Is Falling!!!! (Score:3, Insightful)
Woe! Disaster! JWZ's changes to the Emacs codebase can't be easily folded back into GNU/Emacs. It's full of things that are XEmacs specific!
It's called a fork, folks. It's very possible, albeit not very common, with Open Source software. You've given your code to people to use how *they* want, not how *you* want them to. Deal with it.
Re:The Sky Is Falling!!!! (Score:5, Insightful)
RTFA (Score:5, Insightful)
Or even read just the Slashdot summary. You will find this quote:
'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.'
This KDE developer is frustrated because people misunderstand the contribution (or absence thereof) Apple is making to KHTML; he's not flaming Apple or suggesting Apple's duty is to be more helpful to the KHTML people.
not just KHTML (Score:3, Interesting)
Apple's samba patches have also never made it into the main code because they break samba on windows.
Anyone can create a patch. The hard part is working with others.
Again, it's the "Power of open source. The Stupidity of Apple."
This is natural (Score:5, Insightful)
First of all, anytime you fork off a large project like KHTML the source code bases will start to grow apart. When the new fork has a dedicated group of engineers updating it for their needs then it will quickly diverge to the point where it makes little sense to attempt to keep patches in lock step. In my career I can recall several times where this has happened, and it always seems to come as a surprise to the people maintaining the less active fork.
Apple doesn't use CVS as their normal source control system. To provide CVS documentation, Apple engineers would have to maintain a CVS database as well as maintain their patches in their standard internal SCS. This used to be perforce, I believe, and probably still is as switch a SCS is generally a royal PITA.
Because the sources have been diverging for several years, it's unrealistic to expect that the Safari patches will be directly applicable to KHTML, and I frankly doubt that even having the Safari patch documentation would help very much after several years of Apple patches. This probably isn't anything underhanded on Apple's part. It's just the way engineers work - they change the code to fit their needs, and rarely consider the impact on the old fork that they started from in the absence of an explicit mandate to stay compatible with the old fork. That level of compatibility would require the Apple folks to always have the current KHTML sources and be familiar with that source and particularly to understand the differences between the KHTML code and the Safari code.
Apple does provide the modified files, and usually this is a huge improvement on starting from scratch in implementing a new feature or fixing bugs. It does require the KHTML engineers to be able to read and understand the Safari code. To say that nobody can do that sounds a little strange.
It's quite likely that KHTML developers will have to write their own code to pass the acid2 test.
Well, yes. Should Apple engineers be expected to maintain the KHTML engine also? Apple's engineers are probably focused on their code base exclusively. The KHTML engineers are the right people to modify their own code base. Does anyone expect Apple engineers to be responsible for maintaining compatibility between Safari and KHTML? Apple makes changes, and they provide the changes files to the KHTML team. The rest is up to the KHTML folks if they want to extract the Apple code they want to use and put it into their code.
Missing their point (Score:5, Informative)
Why is everybody missing this KHTML developer's point? It's right there in the short Slashdot summary. He acknowledges that Apple is fulfilling their legal obligations by providing the modified files. But they're not providing any help at all in making their changes useful to the KHTML team. So, there's no "collaboration" at all from Apple's side. That's all. He's not even flaming Apple. If anyone, he's flaming people who misunderstand this situation.
Re:This is natural (Score:5, Informative)
Business Plan (Score:5, Insightful)
2. Get lots of FREE BSD & GPL Unix utilities.
3. Use FREE browser source code from KHTML.
4. Beg & plead with MS to continue making Office for Mac.
5. Write the GUI in house and a few other cool apps.
6. Bundle it up and sell it for lots and lots of money and take credit for it all.
Re:Business Plan (Score:4, Insightful)
Re:Business Plan (Score:4, Informative)
They don't take credit for the lot, last time i checked
They only take credit for the inovations they add , apple have been quite open as to the fact that alot of darwin is based on free OS software ( i would say they publicised that to gain the OSS vote )
As for the rest well , Apple Dont want to reinvent the wheel and i dont see the problem with that .
Ultimate Battle (Score:3, Funny)
Another way to say it (Score:3, Interesting)
If you have a problem with how apple is handling the code releases
Personaly i belive perhaps they could make it a little easier on the KHTML Devs , though they are under no obligation to do this
Talking crap. (Score:5, Insightful)
- A bunch of developers finds a bunch of bugs and fix it in their source base.
- They hand you their source base, along with loads of information on where the bugs are, and patches that you can't integrate into CVS HEAD.
And the KHTML team is sitting around bitching about the fact that KHTML != WebCore anymore, and how none of the patches can be run against HEAD...
Ok, I was *at* Netscape at the time. I have no doubt that he and his team continue to bust their asses to ship good code, and they're passionate about doing so.
That is not to say that they:
1) Should feel restricted to KHTML's API. That's not in Apple's best interest, and they're not doing this *for the KDE team or organisation*. It's also not fun - they don't run Linux desktops, or KDE, and don't feel like re-entering Netscape's cross-platform hell.
2) Is KHTML nice and segregated? The whole reason WebCore happened was that KHTML was littered with KDE calls. Now the KHTML team is complaining that the WebCore code is littered with Mac API? Imagine my shock. Really.
3) A bunch of people just gave you a ton of information, bug reports, and example code you can *LIFT OUT AND REWRITE*.
Lazy? You're damn right you are. Disillusioned? Yeah, I'll bet. Apple didn't add developers to the KDE project - they added them to Safari. Any idiot can tell *from the starting point* that the only way the browser would happen was to do in WebCore what the KDE team did in KHTML; utterly fail to abstract platform-specifics from the rendering engine.
Personally? I could wish that some big commercial development house would take an open source product I was on, commercialise the development, submit its source code quarterly for me to scavenge for ideas and code where possible, and for it to remain legal to do so.
Is it "ideal"? What's "ideal"? A bunch of other people bend over backwards to make your codebase a nicer place to live in, so they can throw away their deadlines, fix the fact that you didn't separate out the platform dependency in the first place, and burn money on things in the codebase that don't have *any* outward impact except to make it easier for someone else to suck up the code into their tree?
I'll bet you're frustrated. All those damn clouds keep getting in the way of your panoramic view.
It may not be perfect - but it's more than just a little better than nothing; it's actually a hell of a lot of time and effort spent to give back to the community. Even if, in this specific instance, what's given back isn't instantly reusable by that community.
Meanwhile, you can go back to KDE. Not a bad product, but strangely enough, it's hard to run KDE applications without running KDE. It's hard to develop a KDE application that would/could. If anyone has experience with writing applications in an environment that has to cross APIs with fundamental differences in how they perform simple actions, it's the person you're accusing of... of what? Of not being "helpful enough"? Of not being a KHTML team member? Of not being an Apple employee paid to work on a KDE-specific project?
I'm having a really hard time imagining what the fuck is going on in your head, and I'm just not sure it's worth bothering; I suggest you start a rock band and burn off some of that angst on teenagers who are more likely to think that every word that comes out of your mouth is gospel, rather than the drivel it sounds like to those of us of older generations.
Re:Wow - vitriolic (Score:4, Insightful)
Re:Wow - vitriolic (Score:3, Insightful)
Someone spends years writing some code which X company uses to give their OS a severe boost in the browser department. An OS with a poor browser is a poor internet desktop, you would think Apple would be grateful for the groundwork done by the KDE team.
Re:Wow - vitriolic (Score:3, Insightful)
And that only, nothing more at all, which is the part that annoys the KHTML team.
Re:Wow - vitriolic (Score:4, Insightful)
They are doing more than the license forces them to. They are just getting criticised because some developer wants them to do more.
Also, everybody whining about suing them for GPL infringement? You are clueless. Not only are they abiding by the license, it's LGPL, not GPL. You haven't even bothered to read the license and you are advocating suing them? Typical American attitude.
Re:Wow - vitriolic (Score:4, Insightful)
Re:Wow - vitriolic (Score:3, Informative)
They are just getting criticised because some developer wants them to do more.
Read this [slashdot.org], as I don't feel like typing it again.
You are clueless... You haven't even bothered to read the article...? Typical Slashdot attitude.
Re:Wow - vitriolic (Score:5, Informative)
it seems like they're doing everything they're legally bound to do. And that only, nothing more at all, which is the part that annoys the KHTML team.
Not even that: it's *other people's* attitude that the KHTML devs dislike - from TFA:
I've changed my mind (Score:3, Interesting)
I guess I'm more accepting of Apple's "evil" behavior because their stuff works better than Wintel. The hardware's (mostly) great, the OS is vastly superior, the apps I use work and look better, etc.
Re:Isn't this the Apple way? (Score:3, Insightful)
What difference would it make to Mozilla if they had used Gecko? Absolutely none. RTFS, it doesn't even make a difference to KHTML. It would be nice if Apple contributed more to KHTML, but they're not hurting them any more than you and I are.
Why give back? (Score:3, Insightful)
If KHTML was a strong, vibrant project that was making steady advances, there would be a motivation for Apple to fold their changes back into the trunk so they can continue to reap the benefits of other peoples improvements. If Apple aren't making an effort to fold their changes back in, it indicates that they don't feel having easy access to future
Re:Why give back? (Score:4, Informative)
Re:Why not give back? (Score:4, Interesting)
Either HTML is portable or it's not, and Apple does not have the market power to succeed with a non-portable version.
The larger the pool of standards-compliant web browsers (whether on Macs, Linux or Windows boxes), the better chance Apple has to complete on a level playing field. As it is, Apple's still in a position to be screwed by websitest supporting non-standard ie-only extension.
So when it comes to KHTML, I ask, why *not* give back.
Re:Isn't this the Apple way? (Score:5, Insightful)
Bitch all you want, but Dave Hyatt's changes to WebCore stand a good chance of finding their way back into KHTML
Do you even RTFA? Hell, do you even read the headline? It's written by one of the KHTML Developers.
If you had RTFA, you would have noted that he's not complaning about Apple. He's complaining about you and your uninformed comments. He's asking you, in a more polite way than I will, to shut the fuck up. Because most of Apple's code is completely unusable to KHTML.
Re:This sounds like something SCO would say... (Score:5, Insightful)
Without the revision history, it can be very difficult to track what effect particular changes actually have. Intermediate code cleanups, reorganizations, additional features, etc. can combine to make the code look much different in a fairly short amount of time.
Looking at "what has been changed" makes it much easier to figure out "what does the changed code do".
Re:This sounds like something SCO would say... (Score:5, Informative)
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.
Re:This sounds like something SCO would say... (Score:3, Insightful)
That said, the problem for KHTML is that they're working with Rolling Thunder. I mean come on, these dudes are cranking the stuff out. They're not going to take the time to go through Radar and pull their changelists.
If you can't keep up, stay home.
Doing stuff like this isn't going to win you any friends either.
Re:This sounds like something SCO would say... (Score:5, Insightful)
Re:this is such a typical response... (Score:3, Insightful)
Re:this is such a typical response... (Score:3, Insightful)
Re:this is such a typical response... (Score:3, Insightful)
Re:License violation and legal action against Appl (Score:3, Informative)
a) it's the LGPL
2) they're doing everything they have to
d) the ACID2 patches have been released to KHTML developers before Apple have actually released them, themselves.
Sure, Apple could be doing more, but they're not violating anything.
Re:License violation and legal action against Appl (Score:3, Interesting)
>Here: The source code for a work means the preferred form of the work for making modifications to it.
Um, I hate to break it to you, but the "preferred form" wording in the (L)GPL is an anti-obfuscation clause. It means that I have to give you the code in the form that I actually use for development -- no stripping out all the whitespace and comments, changing function names and variables to random strings, etc.
It does not mean th
Re:diff -uBwr KDE_KHTML/ Safari_KHTML/ (Score:4, Informative)
Re:diff -uBwr KDE_KHTML/ Safari_KHTML/ (Score:4, Informative)
(see article, those patches actually require MacOs functions)
Re:They have the code (Score:3, Informative)
Re:Stop complaining (Score:5, Informative)
Re:Stop complaining (Score:5, Insightful)
Re:Stop complaining (Score:5, Insightful)
What have they done for KHTML exactly?
At this rate, Safari will end up with a completely different engine from KHTML. How will n million installations of a distantly related browser help KHTML?
we do understand that (Score:4, Insightful)
Well, confusion on this point is probably the result of Apple using open source as a marketing gimmick [apple.com]:
While it is doubtlessly good for Apple customers that Apple uses standard and high-quality open source components, they seem to have forgotten about the "contributing useful stuff back to the community" part that goes along with it. Oh, they put out a lot of code, but it's usually not useful: their gcc hacks haven't been useful, their KHTML hacks haven't been, Darwin isn't used much or very useful, etc.
So, we people understand that Apple is a business and doesn't want to help other companies. Now, if only they could be more honest about it in their marketing materials.
Re:Isn't that what opensource is about ? (Score:5, Insightful)
I'm not sure about that. From what I understand, open source doesn't mean you have to give other people everything verbatim, and explain the changes.
You have to make available the source you based your code on. That's all. Apple would be under no obligation to make modifications publicly available. It's just a bit silly not to contribute back, otherwise they end up working off a completely different source tree, and lose most colateral benefits of having an open-source basis.
Apple might simply plan to let the open-source crowd stay a few months behind their closed source implementation. That way the community still contributes useful bits, but doesn't ever get in Apple' face with competition for users.
Re:Isn't that what opensource is about ? (Score:3, Informative)
See this previous comment on how the patches released don't allow to understand or modify the changes made by Apple [slashdot.org].
Re:Isn't that what opensource is about ? (Score:5, Informative)
In fact, forking is not a bad way to describe what they're doing. They've made a legitimate fork. They're releasing patches, they're playing by the rules.
The OP is right. They're not 'cooperating'. Guess what--they don't have to. The GPL, however much RMS would like it to, doesn't mandate having a social conscience.
Re:Isn't that what opensource is about ? (Score:4, Funny)
Re:Isn't that what opensource is about ? (Score:3, Insightful)
Re:Isn't that what opensource is about ? (Score:4, Insightful)
Complaining about idiots never works.
Re:Come on, Apple.. (Score:3, Funny)
Re:Wow, pick on apple day (Score:3, Insightful)
It's strange, where should we draw the line for what we expect from private companies?
That they allow fair-use and backup?
That they make file-formats public?
That they go open-source?
That they make all their software free?
That they not make any money?
hmmn...
Re:Wow, pick on apple today (Score:3, Insightful)
You've got it backwards.
We should pick on any company (or person) who merits it.
We shouldn't give Apple a free ride because they aren't MS and have the most popular brand in the world (according to some article I saw here on
MS, Apple, Red Hat, IBM, etc. they should all be judged on their merits.
Not to mention Linux, Gates, Elison, etc.
Re:Hmmm... (Score:5, Informative)
You obviously didn't read the blog entry.
The problem here is that Apple drops a huge diff on them for every release. It's not individual diffs for each change, but one massive one. We're talking about a diff several megabytes in size consisting of hundreds of changes. With all kinds of changes mixed in with eachother and mixed in with all kinds of Safari-specific stuff.
Yes it is possible to sit and pick that apart. But it's a lot of work. It may very well take more work to seperate out a change than to re-implement it from scratch.
On top of that it's unnecessary work, because there's no reason Apple wouldn't be able to hand over all individual patches seperately, which would make things immensely simpler for the KHTML guys.
Apparently the KTHML guys have tried and tried to get Apple to do this. And they haven't helped.
Re:Hmmm... (Score:3, Interesting)
I see you've spent some time involved in the Apple workflow. Has it occurred to you that the Safari team's development methodology might not easily lend itself to individual diffs and CVS logs?
Re:Hmmm... (Score:3, Interesting)
I didn't really say that must mean that either. But regardless of what version control system they are using, they do have a version history saying what changed and why. And whatever version control system their using, it's likely trivial to export that.
stop whining
Who's whining? I've just stated what I believe the KHTML guys were saying. I don't deny that Apple is within their rights not sharing any form of
Re:Hmmm... (Score:3, Insightful)
And how do you think the KHTML base that Apple got for free was worth? How much would it have cost Apple to replicate it (assuming they COULD produce a browser of equal quality on their own)?
Cooperating with the KHTML team results in a more closely matched codebase. This means the work done by the KHTML team has a greater chance of being relevant in Safari and Apple benefits immensely from that. In the end that saves more work than it creates and therefore results in a better
Re:Hmmm... (Score:3, Informative)
Even if you're checking in stuff weekly, you're still checking it into a local source control system. I promise you that... anyone's who dealt with "weekly" checkins, and lost 4 days of code on an early Friday morning is motivated to do this stuff.
Either that, or the developers at Apple are dumbasses who love living on the edge. And I don't think they are.
They just don't want to play nice. That's their right.
Re:Hmmm... (Score:3, Insightful)
And obviously you have little experience of version control systems. I have yet to see one (including perforce) which can't export diffs and changelogs to some simple format. Why would they need to write a script for that?
And you're completely missing the point: If Apple
Re:Hmmm... (Score:5, Insightful)
And why is this important, you ask? KHTML, like any rendering engine for a complex document format, is a complex piece of software. If you're going to change it, you need to be absolutely sure that the changes aren't going to have an impact on another part of the rendering pipeline. You can't do that when you have 5+MB worth of multiple possibly-unrelated changes to sort through.
Re:Diff? (Score:4, Insightful)
Since Safari is a big fork, in order to know how to reintegrate the files, you need to know WHEN as well as WHICH LINES of code changed in order to reintegrate major changes into the source management, or you'll run substantial risk of overwriting previous patches the other fork doesn't have or need, especially if there aren't a lot of people and time to figure this out. Otherwise, the time to reintegrate is much more than...just writing it yourself from scratch.
Your comment is so moronic and naive that it is officially a troll. If a key guy like this is complaining, then: THERE'S SOMETHING WRONG. He's not lazy and he's not whining, you dumb fuck, he's legitimately frustrated. I would say this is very helpful, since it straightens up all the iPod-hypnotized Apple apologists on this site. If there are a million consumers who buy Apple's marketing, fine. But this was supposedly a site for intelligent technical people.
Apple is what it is: a talented amoral corporation led by a greedy egotistical amoral CEO. They aren't "Different", they aren't "feeeel-gooood", and they don't care about OSS unless it makes them money.
Re:Diff? (Score:3, Interesting)
Its not the end of the world, but obviously Zack Rusin got tired of being called lazy or some other intollerable (read: typical) OSS user crap while Apple is snowballing their changes (
Re:Diff? (Score:4, Interesting)
Re:Sick of the complaining. (Score:3, Insightful)
You seem to think they we, we the users, we the stockholders, we the buyers (and I'm all 3), can't ask a company for more, that we should be happy with whatever they offer. All this guy was saying is that the cooperation between apple and KHTML is basically the minimum required by the license, and people should characterize it as that.
I can understand though how you would be scare
Re:the drawbacks of open source (Score:3, Insightful)
Since khtml is LGPL, they are obliged to release the source; even though technically they only have to release it on request to anybody who also has the binary.
Actually: Apple started out with getting a lot of code from the KDE team, so I wouldn't call it "one way". I can imagine that they are still integrating bugfixes/fe
Re:Satan's Browser (Score:3, Interesting)
Problem: I want to test my code against Safari 1.0, 1.1, 1.2, 1.3, and 2.0.
Solution: I need 5 different machines (virtual or otherwise) to run five different browsers?
That's a shitty dilemma, isn't it? Somebody's underlying architectural problem becomes my QA problem.
Why does half the browser have to live in the OS libraries?
Why can't these same libraries be bundled up in developer releases so I can at least have five ex