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.'"
When are people gonna understand that companies like Apple are not in the market coz they like it ???
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?
No, 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.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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.
English is easier said than done.
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".
Uh, just how is this a GPL violation? They're providing the modified source code. The GPL doesn't require you to explain how you wrote your code or how you got from the old code to the new.
If you've got the modified files you most certainly can tell how they've changed. You do a diff.
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.
Given that some developers reverse engineer protocols by sniffing TCP packets, your task really doesn't sound that difficult...
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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();
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? Come on.
I'm getting really sick of the anti-corporate bullshit that gets thrown around so copiously by a certain faction of the OSS community. And it's not just Apple being treated this way either.
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, and they'll eventually turn on us.
Well, given the way we treat them, I wouldn't blame them for turning on us.
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.
This is open source. Other people can modify it how they choose. They then post back those changes. Tough shit if those changes aren't useful.
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...
So what are Apple supposed to do? Not use OS X features? Wait for KDE to integrate their last set of patches before doing any more work?
They have to supply their changes. They are. They *don't* have to do free work for KDE just to make KDE development easier.
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
For god's sake, RTFP, Rusin didn't complain about the fact that he couldn't merge the patches on the trunk, he is annoyed by the fact people think it is, and think Apple is all great and mighty and actually cooperates with the KHTML team, which is not true.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
It's like called courtesy?
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.
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
This story really separates the actual coders on the site from the wannabe's.
Nothing like someone without a clue saying "just diff it" to help illustrate that most slashdotters can code "hello world" but would crumble if ever given a real program to write.
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!
The parent may seem like a Troll, but I've worked on Darin Adler's code before, and it's "messy."
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.
Pretty code is much easier to extend and maintain than hacked together 'the browser fucking works' code.
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.
What I'm listening to now on Pandora...
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.
Actually, as has been proved many many times in previous threads, most Slashdoters can't write Hello World and get it right. I'm not even talking 100% C&V ISO C99 standards compliance, I'm talking basic just plain compiles. I'd be surprised if more than 40% of Slashdoters even know what "Hello World" is.
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.
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.
This is embarrassing for the Free Software community. You guys should be more professional. If someone doesn't want to hand over code in nice neat bite-sized packages with comments and documentation and a thank-you note, then shrug it off.
:P
It doesn't matter what they give back as long as they don't break the license. We may have to buy their product or know someone who did, but at least we have the right to get access to their source code. But whining that they aren't doing your job for you is stupid. We're better than this.
khtml developers are lazy. Wheres the fun in that?
First I would like to say _Thank You_ to all the KDE developers working on KHTML and Konqueror. Without you, well, we'd be stuck with Nautilus and Firefox.
And being lazy is part of the fun. Writing code is fun. I love to do it while I'm stoned. I smoke a phat bowl and get to hacking on my objects and get this wonderful sense of accomplishment when I fix annoying bugs or add new features. I suck at writing C/C++, but Perl is so much fun for me. If I knew how to manage datastructures in C/C++ like I do with Perl I'd have just as much fun with it.
NO STRESS!!! And deoxy.org/endwork.htm. Just relax and hang out with friends and play games and write up some colorful fun entertaining and encouraging documentation/tutorials/propoganda when you get code burn-out. Or take a break and come back with a new clear and focused perspective on getting standards compliance into KHTML or whatever your goals. There's no rush. We'll love you all the same. Just have fun.
users DO NOT CARE if your code is 'elegant' and 'easier to mantain', users WANT THINGS TO WORK whether or not they are 'elegant' or 'adequate'.
I stopped using Konqueror ages ago because it just had way too many incompatibilities with sites I visited, I know the sites were non-standard, likely poorly written or written with IE in mind, but if I need them to do my work, I'll find a web browser that renders them properly.
It's really easy for an OSS project to get caught up in 'elegance' and just keep rewriting and rewriting and rewriting things to make it 'clean' or 'modular' code-wise, while the users get fed up with the glacial features development pace and move on to OS/X or Win32 because they actually need to USE the product rather than look at the pretty code.
-- the cake is a lie
From a cursory look, that simply turns off anti-aliasing for the following display drawings. If the Konqueror guys need help were to turn off anti-aliasing, maybe they should read the KDokumentation.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
The reference here has tremendous potential, but you really dropped the ball on the "funny" part.
If Apple does not publish revision histories (patches & description of each patch), then their code will not become part of KDE. Who loses? Well, Apple, KDE *and* users because all everyone ends up doing is redoing the same work over and over again. It kind of defeats one of the purposes of open source.
Safari is Satan's browser, as far as I'm concerned. It's hell to develop DHTML for once you get past intermediate DHTML and into more advanced stuff.
I see nothing good about this browser:
- It is bound to OS version (like MSIE on Windows) so if you want to do comprehensive QA testing on all versions you need a dedicated box running now-obsolete OS's just to test.
- Its "performance" optimization have resulted in some DHTML oddities surrounding when and how things get loaded on the page which differ greatly from MSIE, Mozilla, ECMA and W3C.
- It has the most god-awful script error messaging system I've seen since Netscape 2. Not joking about this, it's literally as bad as Netscape 2 in this area, just ten years newer.
- And for fuck's sake, why does the world need yet another browser? Why not just re-skin Mozilla and be done with it?
At work I refer to this piece of shit as "Satan's Browser" and everybody knows what I'm talking about. Go ahead and flame me if you want, but if you defend this thing, you're either bought and paid for by the Apple propaganda machine or you're not a client-side developer and don't know the pain I'm talking about.At some point it seems like they have to do a re-synch to get more in line with what you are doing, or they're not going to be able to patch in changes you make either - is that in the works at some point?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
The "Mac only" patch is in KWQPainter.mm, which is the implementation of the Qt drawing abstraction layer. The patch is properly contained in Safari's version of Qt. There is nothing wrong with this patch (the Konqueror guys probably don't even suffer from the bug).
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.
The gripe of the khtml guys is pretty simple: Apple is providing the required minimum, which makes it hard for the khtml team to integrate any changes. If Apple would cooperate just a little bit more, both parties would gain in the end.
On top of this, a lot of end users seem to think that Apple is to be credited for a lot of development in khtml while in reality there's a lot of work done by the khtml team. A lot of OSS developers are doing what they do (partly) because of the recognition. Currently they're not getting that much...
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
Analogies don't equal equalities, they are merely somewhat analogous.
Sorry, gotta call BS on that.
For one thing, KHTML is saving them money, since it gave Apple a great basis for a browser by which they could (at least partially) unhitch themselves from their direct competitor, who otherwise had them by the nuts on browsing.
Secondly, many computer science projects rely on academia for fundamental algorithms etc., and that generally works just fine.
In IT, just as in science, cooperation works, and competition harms not only the wider IT culture, but the individuals who try to go proprietary. And no, MS didn't get where they by going proprietary, they did that by monopolistic practices which have been ruled illegal in courts of law.
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.
So the concern here is that reproducing their work takes time and effort that is only aided in part by their source code?
Isn't that a heck of a head-start?
No, but when Apple takes an open source code base and forks it to make new features OS X specific it makes them no better than Microsoft. Apple is specifically making it difficult for KDE users to gain from the benefits of this code. Yes, its ok to do this by the letter of the license, but you cannot deny that what Apple is doing harms the very people who gave them a helping hand in the first place.
Wikipedia nothing more than a place for people to congregate and write about whatever they find is worth writing about. You don't think that he does not deserve an Wikipedia article, that's fine don't look it up, but if the article is factualy correct you have nothing to complain about (fix it if it isn't :-). If I wanted to know who Dave Hyatt is (if I read about him somewhere like /. first) and whoever wrote the article propably felt the same and ensured that I find what I am looking for.
Anyway, do you have any evidence about the article beeing from Dave Hyatt himself or are you just full of yourself.
Analogies don't equal equalities, they are merely somewhat analogous.
Since its so easy to merge patches from safari into khtml, why don't you stfu and do it? Clearly you are so much smarter than the konq developers since you find this such a trivial task, so go ahead and do it. Prove how smart you are. Its open source, you are welcome to help. Or are you really only capable of critisizing others anonymously when you don't even understand what you are talking about?
Perhaps we should just omit the writeups and just post the TFA links. The /. main page is (-1 Troll) more often than not these days.
Free Mac Mini Yeah, it's
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.