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.
Apple has abided by Safari's license and released their changes. This is what is required and expected. I don't remember reading anywhere that they have to hand-hold you through understanding their code.
Interested in open source engine management for your Subaru?
I give up, no more computers for me.
Love many, trust a few, do harm to none.
... 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
In a shocking and unsuspected announcement, Apple will change their name to 'KApple' in an effort to patch relations with other Kommunities.
Have you ever worked on a large project?
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".
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...
When the diff is 6MB yes its damn hard.
Never learn by your mistakes, if you do you may never dare to try again
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
I would agree. Nowhere does the GPL require you maintain and distribute CVS logs so everyone can see what changes have been made. Nor does it require you detail what has been changed from the original source. It's good enough to say "Here is the code after we made it do x y and z". If the original developer wants to see how they did x y and z, then he can diff the code.
I don't see how fragmenting KHTML is going to help it much... If people code for Safari, and Safari is the only KHTML based browser that acts lke Safari, the what good does it do for anyone else?
using namespace slashdot;
troll::post();
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.
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
This isn't true. They are legally bound to include a notice telling their customers that they are entitled to source, and they are legally bound to supply it to a customer of theirs, should they ask for it, for the price of shipping. They don't even have to send patches back to the KHTML team.
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.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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.
1993 called, they want their flamewar back.
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.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
You obviously work on a grand total of a couple thousand lines of code at work, if at all, and aren't working in a source control managed environment.
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.
Hey, I'm just your average shit and piss factory.
It's really simple. If you're going to release your code under a license that makes it easy for them to fork your codebase, you'd better be setting the pace.
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 KHTML improvements is worth the trouble.
Improve the KHTML code enough that Apple is losing out by not being able to easily fold changes into the next version Safari and see their stance change. Complaining isn't going to get respect from Apple or from anyone else.
-1 Uncomfortable Truth
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.
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."
Let me guess... you're not a developer, right? From what I understand, Apple doesn't send back patches for specific issues, they just periodically make a tarball of their webcore tree and lob it at the KHTML devs. A 'diff -u' would probably give you a 5-10MB patch file. Is it useful? Sure. But it's a royal pain in the ass to sort through it and figure out what does what.
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.
Xfce: Lighter than some, heavier than others. Just right.
Unlike Apple's own GCC team you mean who works side by side with other gcc hackers and even some of them takes care of gcc bugzilla.
Never learn by your mistakes, if you do you may never dare to try again
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.
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.
It isn't because the KHTML developers want them to do more. That isn't the complaint. The complaint is that all the Slashbots read the Acid2 article and assume that those changes will quickly make it into Konq thanks to Apple's good will. That isn't the case. It is the misperception that is being complained about.
Lasers Controlled Games!
I was a borderline "fanboy" when I switched to the Mac a couple of years ago, but once I got past the "ooooh, shiny!" stage, I realized that Apple was no beter than Microsoft or Dell or Intel. Okay, maybe a _little_ better, but still. So, yes, at least one of us changed our minds.
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.
Nothing is inexplicable; only unexplained -Tom Baker, Doctor Who
Pretty code is much easier to extend and maintain than hacked together 'the browser fucking works' code.
The APSL does not play well with OSS. If I hack on APSL code, and then end up suing Apple for, say, anything, even if it's unrelated to the software, I lose my rights to use that software. An old link that still rings true.
Even if the diff-logging process was made automatic someone has to script that and then make sure it doesn't break. Even if their VCS has easy-to-use changelist descriptions like Perforce someone still has to go extract them all for you.
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 did cooperate more with KHTML, then that would be beneficial for Apple, too. It's not just a question of giving.
What's happening now is a release is getting diffed against the previous one and the results shared - very simple and easy.
Simple for Apple, and not very useful for the KHTML guys.
I'm amazed at the whining that's going on here. How about Apple gives you NOTHING, and you get something real to complain about, eh?
That's just trolling.
Only if you have OSX installed...
(see article, those patches actually require MacOs functions)
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
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.
Please, just read the article. He's not complaining about Apple. He's complaining about people who think there is some big cooperation between Apple and KDE when there really isn't.
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.
Dont you think Apple has already done enough for KHTML?
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?
Malike Bamiyi wanted my assistance.
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 scared of apple 'turning on' you based on their childish actions, like pulling books because a publisher is publishing a bio of Mr Jobs that apparently he doesn't like. Now that is a good move for the stockholders how? Seems like it's using corporate muscle to squash a personal dispute. All this KHTML developer was doing was informing the general public of the state of affairs between apple and KHTML, from the KHTML perspective. I think this is a good thing, Apple has multiple channels to spread whatever message it chooses to. Where besides /. will you get to see this side of the story? If all you want is the business side of the story I humbly suggest you are browsing the wrong site.
1. Use FREE source code from BSD & Darwin.
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.
What does Apple stand to gain from having a better HTML renderer than Linux (or even Windows for that matter)?
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.
Posted from my Android phone. Oh, I can change this? There, that's better...
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.
My preferred form for making modifications would be CDs made out of gold. Actually, I'd like to have one CD for each source file.
Free Manning, jail Obama.
" He's complaining about people who think there is some big cooperation between Apple and KDE when there really isn't."
Complaining about idiots never works.
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.
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.
Well, confusion on this point is probably the result of Apple using open source as a marketing gimmick:
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.
as a developer that has worked with open source projects and developers (from the contributing and organizing sides both), this kind of 'requirement' would be absolutely impossible to enforce.
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.
Gekido's Lair
Let's be frank, folks.
- 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.
-- A mind is a terrible thing.