Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
This should help muffle all the cries that Apple gives noting back to the open source community.

In fact, Apple is famous for giving back to the open source community. Not sure where all those cries came from or what they're based on.
 
Aren't all code changes patches? No matter what, if you've been branched for a while and have multiple changes to multiple files, merging is time consuming when the branch and trunk are both changing.

No, I believe these were patches in the form of diffs - so only the changes between version x and version y, as opposed to the entire code file could be merged more easily.

updated: Links here - http://robertdot.org/2007/07/24/so-long-khtml-long-live-webkit/

There were issues of Apple including non khtml code in the patches.
 
Personally, I don't see how things like this were missed in the first place. All browser tabs should be 100% "independent" (or at the very least independently supervised), and, despite the FUD regarding race conditions, no application should get stuck in a loop waiting on network responses.
 
Performance will increase since things can b done in parallel.
Things are already done in parallel, its called threading. Process swicthing is alot heavier than thread switching, so performance will go down, but stability up, cause processes can't harm each-other directly.
 
In fact, Apple is famous for giving back to the open source community. Not sure where all those cries came from or what they're based on.

The cries come from the fact that there are a group of folks who love Apple gear, but want the hardware to be as open as Windows hardware. They want Apple software to be as open as Linux. They want to buy the cheapest hardware on the market and install OS X on it. Or they want an iPhone, but not AT&T, and they want to put forbidden apps on it.

Since Apple has a license that doesn't allow them to do anything they want to an Apple device, these folks whine and moan about how Apple is locking them in jail (ignoring the fact that they walked into the jail when they bought Apple stuff).

These folks have no respect for rights. They don't like the Apple licenses, so they hold their breath and turn red as they insist Apple goes "open." But what they really want is to undermine Apple's legal rights so they can expand their legal rights.

Apple can give lots back to the open source community, but until these selfish folks get their way completely, Apple will be the evil company that is trying to destroy their rights.

They'd say the same things about Microsoft and Windows, but nobody is passionate about those products.
 
What's not to like about Chrome? (I'm currently using Safari + a bit of Firefox but I'm seriously considering a switch to Chrome)...

I never said I didn't like Chrome, but I used Safari for so long I'm still not completely comfortable in Chrome. Mostly minor things, like Chrome's dictionary extension, which is terrible compared to OS X's built-in command-control-D.
 
No, I believe these were patches in the form of diffs - so only the changes between version x and version y, as opposed to the entire code file could be merged more easily.

Getting a bit off-topic, but if a file has versions 1.1, 1.2, 1.3, then there are two diffs. Even if Apple submitted the two diffs, instead of one diff covering the difference between version 1.3 and 1.1, it is straight-forward to generate that diff. It is a pain if the number of diffs per file are different. So, it's a bit more work but scriptable.

With any modern source control system, the real merging work comes when there are conflicts. I suspect this as the source of friction rather than how the patches were submitted.

Anyway, I've heard that build engineers get paid the most in the software industry. It's a rather bland job, but very important.

EDIT: I followed the link in Stella's edited post. It definitely sounds like the problem was "conflicts" in the code base caused by Apple making bug fixes that were incompatible with how/what the open source community wanted. For those who aren't SW engineers, a conflict could be two possible lines like:
"a = CONSTANT;"
"average = CONSTANT;"
Both are correct variable assignments, but one team might prefer the shorter name and the other the longer name. You can't have both and the merging engineer must make a choice.
 
Hopefully this will improve the overall stability and functionality of Safari.

On another note; who would like to see the ability to change the font of the webpages you visit, and ignore these websites' fonts (to the style of Firefox). I'd like that implementation.
 
Back to the more esoteric and technical rumors. I guess the ipad is out and the iphone OS 4 has been demoed. Also the next iphone's features are mostly known. Gonna get kinda dry around these parts I guess.
 
Back to the more esoteric and technical rumors. I guess the ipad is out and the iphone OS 4 has been demoed. Also the next iphone's features are mostly known. Gonna get kinda dry around these parts I guess.

No.

Remember, we still have the iPhone Hardware to discuss. Also, Macbook Pro updates. And ultimately, I think we'll start to hear some Mac OS X rumors.
 
Getting a bit off-topic, but if a file has versions 1.1, 1.2, 1.3, then there are two diffs. Even if Apple submitted the two diffs, instead of one diff covering the difference between version 1.3 and 1.1, it is straight-forward to generate that diff. It is a pain if the number of diffs per file are different. So, it's a bit more work but scriptable.

With any modern source control system, the real merging work comes when there are conflicts. I suspect this as the source of friction rather than how the patches were submitted.

Anyway, I've heard that build engineers get paid the most in the software industry. It's a rather bland job, but very important.

EDIT: I followed the link in Stella's edited post. It definitely sounds like the problem was "conflicts" in the code base caused by Apple making bug fixes that were incompatible with how/what the open source community wanted. For those who aren't SW engineers, a conflict could be two possible lines like:
"a = CONSTANT;"
"average = CONSTANT;"
Both are correct variable assignments, but one team might prefer the shorter name and the other the longer name. You can't have both and the merging engineer must make a choice.

I think "diff" in this context means version number, but rather Apple just gave the open source community a file that said what was different. For example: say you had a file with 1 paragraph of text in it. Apple comes along and adds a second paragraph to the file. Instead of giving back a file that has both paragraphs, Apple gave back a file that says, "Add this paragraph to the end of the original file". That means there are two files and someone has to go in and merge Apple's file back into the original file. WHile it's fairly easy to just add something to the end, if it's a word here, another word there, that's hard to do. Kinda like the difference between Apple's delta updates & combo updates. The person you quoted might mean Apple should give the WHOLE file, original + changes, not just the changes.
 
It's great to hear about something not iPhone / iPad related, especially if it's gonna benefit the open-source community :)
 
This should help muffle all the cries that Apple gives noting back to the open source community.

Oh no. You'd think so, but there will always be someone who is not happy, no matter what happens. They contribute, someone complains. They don't, someone complains. They're going too fast, they're going too slow, they're taking too much leadership, they're not taking enough... it will always be there. They're already complaining about the simple fact that there's going to be a "WebKit 2". People are just messed up.
 
So, if Apple borrowed (not stole, Apple would never steal anything) this concept from Chrome, do this make Google a good company again. Or, are they still evil?
 
I think "diff" in this context means version number, but rather Apple just gave the open source community a file that said what was different. For example: say you had a file with 1 paragraph of text in it. Apple comes along and adds a second paragraph to the file. Instead of giving back a file that has both paragraphs, Apple gave back a file that says, "Add this paragraph to the end of the original file". That means there are two files and someone has to go in and merge Apple's file back into the original file. WHile it's fairly easy to just add something to the end, if it's a word here, another word there, that's hard to do. Kinda like the difference between Apple's delta updates & combo updates. The person you quoted might mean Apple should give the WHOLE file, original + changes, not just the changes.

Um, sorry, no. I take it you aren't a SW engineer, because that's not how it works.

There is a tool called "diff" that can list the differences between two files and a tool called "patch" that takes those differences as input.
The output of diff will list changes as line numbers for deletion and line numbers for additions in reference to one of the files. If you have the original file and this output in reference to original file, then you can create the new file using "patch" tool.

Now you have the new file (the branch file from Apple), but that is still different from the last version of the trunk file. So you use "diff" between the branch file and the trunk file to generate the differences. You now have 2 sets of differences, the one from Apple and the one from trunk. These differences may conflict. One literally says add line 44 as "a=CONSTANT" and the other says add line 44 as "average=CONSTANT". You cannot do both, so you must choose one. In this simple case, if you have coding guidelines then your choice could be easy. In complicated cases involving code logic, the choice is non-obvious.
 
I think "diff" in this context means version number, but rather Apple just gave the open source community a file that said what was different. For example: say you had a file with 1 paragraph of text in it. Apple comes along and adds a second paragraph to the file. Instead of giving back a file that has both paragraphs, Apple gave back a file that says, "Add this paragraph to the end of the original file". That means there are two files and someone has to go in and merge Apple's file back into the original file. WHile it's fairly easy to just add something to the end, if it's a word here, another word there, that's hard to do. Kinda like the difference between Apple's delta updates & combo updates. The person you quoted might mean Apple should give the WHOLE file, original + changes, not just the changes.

If they were standard diff files, why would the patch command not be able to apply all the patches automatically?

edit: jpyc7 beat me to it.
 
The issue that the open source community complained about earlier was that Apple would go off and develop in private for a year or so, then send them *one* patch containing all the changes, and no real way to separate them. Considering KHTML had an intervening year of development in between as well, this made merging hell, and there was no real way to decide which patches to accept; it was all or nothing.

The current model of having a public svn repository works a lot better :)
 
Wirelessly posted (Opera/9.50 (Nintendo DSi; Opera/507; U; en-US))

in one ear said:
does this mean security will become as good as chromes ?

If Apple does what they say they will do, then yes.
 
Back to the more esoteric and technical rumors. I guess the ipad is out and the iphone OS 4 has been demoed. Also the next iphone's features are mostly known. Gonna get kinda dry around these parts I guess.

Never. We will still hear about:

- when will the next MBP come out?
- Will Safari run faster in the next version?
- Why evil Apple won't support Flash
- When a camera will be added to the iPad
- When TWO cameras will be added to the iPad (one forward and one rearward)
- Why multitasking requires iPhone OS developers to implement it correctly
- Why Apple should ship their iPhones unlocked
- Why Apple should support app sales through third parties

And a million other inane arguments. The whining will NEVER end.
 
Because Apple has not come out yet with it's new MacBook Pros :p

And you know what's sad? As soon as new MacBook Pros are announced, those same people will vote negative because they don't like a) the price; b) the specs; c) their lives.
 
EDIT: I followed the link in Stella's edited post. It definitely sounds like the problem was "conflicts" in the code base caused by Apple making bug fixes that were incompatible with how/what the open source community wanted. For those who aren't SW engineers, a conflict could be two possible lines like:
"a = CONSTANT;"
"average = CONSTANT;"
Both are correct variable assignments, but one team might prefer the shorter name and the other the longer name. You can't have both and the merging engineer must make a choice.

Offtopic more - a lot of opensource projects have coding standards that will contributors should follow. I'm wondering if there were any for KHTML.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.