Slashdot Mirror
Safari And KHTML May Never Meet
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.'"
Looking at Safari developer Dave Hyatt's blog it looks like he's provided some patches. I'm sure it will take some work to get those into KHTML, but that seems to be a pretty good start to me.
... they're duping comments.
Hey, that gives me an idea - find a nice little comment somewhere a week or so back and submit it as news... yeah...
We Build Beautiful Websites
Dave Hyatt seems fairly responsive to emails. He's replied to one's I've sent in the past asking questions about Safari. He's a Free Software guy, I'm sure he can appreciate the frustrations here, and might be able to help - afterall, I don't believe he, or Apple really want to 'screw over' the KHTML people - it might just be that communications haven't been really made.
Email him - ask?
Join the Free Software Foundation
This might be a good time to remind everyone that the patch has not yet been released to the public. The patch might make the browser unstable - further testing will be required. Depending on how long it takes before the patch makes it into the public version, Safari might not be the first browser to support Acid 2.
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.
I'll probably be modded down for this...
Nice idea, except they're not violating the GPL!.
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.
Join the Free Software Foundation
When the diff is 6MB yes its damn hard.
Never learn by your mistakes, if you do you may never dare to try again
Come back when you'll actually have seen code
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Huh? They got Khtml and Kjs from KDE, without them there is no Safari , No Dashboard. Got it?
Never learn by your mistakes, if you do you may never dare to try again
They always have been. It's just that most of the Slashdot crowd has been choosing to ignore it lately because they've been turning out better stuff than the Other Evil Empire. Their product is better , and they've been playing kind of nice with Open Source because they haven't had a choice (Apple doesn't really have the resources to develop everything in OS X and have it be as good as it is - They've gotten a hell of a lot of milage out of FOSS with OS X). However, make no mistake about it Apple is at least as abusive legally as Microsoft is. Have been for years.
Every change in khtml has to be run through a regression suite to make sure it doesn't break anything. Now if you fix something a new regression test is added for that.
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.
Never learn by your mistakes, if you do you may never dare to try again
There are no trails. There are no trees out here.
That would be flair. They are two very different words...
Now that diff can't tell you why they've changed, but for Pete's sake, you're a developer. You've got the code. You've got the standard. You've got the changes in the code. You've got the old code. You can see how behaviour changes in each. You've (hopefully) got an reasonable general understanding of the codebase.
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.
I can't access kdedevelopers.org, so here's the blog entry:
/. about Safari supporting the all crack Acid2 test and people raving how great it is for KHTML. The truth is that KHTML will probably never get those patches. Whats most probably going to happen is that one of us will simply reimplement it from scratch (and at the moment the reality is that if its not going to be Allan or Germain its not going to happen).
/. or some other equally stupid site will be praising Apple.
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?
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:
This is where the serious fun begins.
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.
The source is intended to be understandable. Not only that, it has to be "the preferred form of the work for making modifications to it". If you release something that is not, you're not fulfilling the terms of the GPL license.
See this previous comment on how the patches released don't allow to understand or modify the changes made by Apple.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
The code for the Acid2 test fixes was all given to you in a nice list of small easily applied patches (which was posted on /. no less), and you still can't manage to integrate it without having full logs of Apple's interval versioning system?
Correct. Because - here's the rub, genius - those diffs are between Safari versions, and therefore they can not be applied directly to KHTML source code. Because Safari is, like, different?
I'll tell you what I'm sick of - people like YOU, who show no evidence of understanding anything remotely resembling the development of a complex platform, yet somehow feel they are qualified to spout off and start criticising the people who really do give vast amounts of their own free time to develop software they give away for free, whenever those people make valid complaints. And in this case you seem not even to have read the fucking article - you're making an assumption about what he says which is not justified.
No matter how much a big corporation gives to the community in terms of money, code, paid personnel, free advertising, etc..., there's always some crank complaining that they're not giving enough.
What has Apple given the KHTML developers?
Money: $0
Code: as little as they can get away with, packaged in the format that's most convenient for Apple and least convenient for KHTML
Paid personnel: none
Free advertising: a handful of mentions of KHTML in various Safari-related press releases
In other words, they are doing the absolute minimum they can get away with within the bounds of their legal obligations. Are we supposed to bow before their nobility and thank them profusely for the quarter they tossed into our collection bowl from the window of their limo?
Only if you have OSX installed...
(see article, those patches actually require MacOs functions)
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
They are just getting criticised because some developer wants them to do more.
Read this, as I don't feel like typing it again.
You are clueless... You haven't even bothered to read the article...? Typical Slashdot attitude.
Did you even read the linked articles? He isn't complaining about Apple. He is complaining about jerks like you bashing KHTML on Slashdot for not incorporating Apples sloppy hacks back into KHTML.
apt-get install redhat please god - Me (take it easy, I love Debian)
They're providing the modified source code. What they're not doing is adhering to the project management standards (version control, changelogs, whatever) that KHTML uses. The GPL doesn't require this. As I see it, Apple is modifying and using KHTML and releasing the modified source back to the KHTML team, thus fulfilling the GPL. There's no requirement that it be easy to build or that they document their changes well or that they not fork the project.
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.
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.
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.
a flying fuck what apple does. What pisses him off are clueless assholes who keep spouting how great Apple is for making KHTML better, and how the KHTML Devs are so lazy because Safari had x feature yesterday and why the hell isn't it in KHTML already, cause Apple works so well with the KHTML team.
He's setting the record straight that the Apple Safari team ISN'T working well with them, they just drop huge batches of changes in a single diff, with no rhyme or reason. It's more work for the KHTML guys to figure out these patch bombs, than it would be to reimplement them from scratch.
He wants clueless asshats to quit talking about how great Apple is for releasing all their wicked cool Safari features back to the KHTML team.
SO your basicaly saying Apple has a good business plan and make a quality product which they totaly admit partly comes from others work.
.
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 .
The only things certain in war are Propaganda and Death. You can never be sure which is which though
If you distribute the binary, then you must make available the source code to anyone that receives *your* binary. So let's say I give you a binary of my GPL application, but you don't know it's GPL because I didn't tell you (violation of the license, I have to at least tell you). You copy it for a buddy, and he recognizes it as a GPL application. He asks you for the source, you don't have it. He can climb the ladder to me and ask for it and I have to comply.
In Apple's case, they only have to provide the source code to KHTML (with their modifications) to the people who receive a binary for Safari. And that's it. Not the KHTML team, not KDE, not you (unless you have a copy of Safari), and not me.
A little side point that's worth mentioning. :) Both the GPL and LGPL require you to mark your modifications to the code. You can't just change the code and claim ownership to it. If you change my GPL code and don't put your name around the parts that are yours, then you have just given me your code. You haven't licensed your code to me under the terms of the GPL, you've given it to me. Later on, I decide to take my GPL code and wrap it up as shareware and start charging all users of it. Since you didn't mark your code, you have no claim of ownership on it, you can't force me to back off and release my now proprietary code as GPL again.
what's the moral of the story? Apple needs to be marking their changes to KHTML. It's part of the license. So these complaints about the code not being easy to see what they changed are actually valid--the license does require it. Without doing so, Apple can't claim ownership of that code.
SO all you open source developers out there, make sure you put your own copyright notice in the patches you send in!
Realistically, using version control reports and stuff as evidence APple can probably get a court to respect their ownership of the code they wrote that wound up in KHTML, but why go through all that expense for the sake of promoting bad coding habits? Mark your code if you own it, otherwise don't bitch about it when someone claims it as theirs.
Like what I said? You might like my music