Google chrome code reuse nightmareTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Well this is probably because they were first targeting Windows where embedding third party libraries into your app is the norm. Hopefully, once this gets release on platforms with sane package management, this will not be the case.
Why this? I mean windows has ddl files as shared "libraries" and the installer could still download the needed libraries and install them.
The reason most developers pack together dependent libraries on Windows is because shared library installation is only marginally controlled by the user. If you depend on system installed libraries it is very common to see your code break when some (badly written) application installs an older, buggy version of the library. This is in stark contrast to most non-Windows distributions (Linux/BSD) where system wide installation is controlled by the user (or at least the packager).
Mozilla does the same thing more or less. They have various copies of libraries in the source tree. But you can always compile/link to systemwide versions.
yes true, as i wrote "but I hope it has at least a way to link against the system-wide copies without patching the makefiles."
Them incorporating libraries into the source is only problematic iff(!) they patch it. Otherwise the system libraries could be used.
I'm not sure what you are on about....
This is the job of linux distributions, to coordinate the release of all these libraries in a sane manner. Linux code reuse is very high because they do it well. When there is a linux build that is worth going into debian they will sort it out.
I disagree, it should not be the job of the distributors to patch upstream source code in order to use system-wide libraries. By patching I don't mean some configure flags.
Anyway, we'll see when they release the linux version.
Well, guess what happened after the first beta was released? It was already vulnerable because of a security bug in webkit which was fixed in the current upstream version. I don't think this is a good indication of a working security infrastructure which can act fast. Have they even released a fixed beta yet?
I disagree. These libraries at their specific version make a apecific version of Google Chrome. Imagine the following scenario:
Google releases Chrome version X linked with WebKit version Y. So web applications start to get build against Chrome X. But after a while bugs are discovered in WebKit Y and they are fixed in WebKit version Y.z. Subsequently the new WebKit version gets automatically pushed into Linux clients by the distribution update mechanism. So you end with installations of Chrome X that use different WebKit versions and so behave differently.
No, I think you misunderstood. ABI has nothing to do with what I said.
Different WebKit versions can have the same ABI but render the same pages in a different way. This is also true and for the Javascript engine V8 and for the other libraries. A specific version of Chrome should be accompanied with the specific library versions that are included upon its release. Add Comment
|
Calendar
QuicksearchSupportRecent Entries
CategoriesTag cloud23c3 acpi advertising annouce announce april argh art awards bash blogging bugs c cli code conferences config configuration data mining debconf debian dell dns documentation email errm? events exploit fail fail2ban filesharing films flame fun gcc google graphs grml gsm hacking hacks hardware heise images information installation internet irc knowledge libacpi links linux mobile phones network news newsbeuter omg open source opera passwords php power privacy programming qa random blurb rant release releases rss scripts security service setup shell sms software spam ssh stfl stuff terminal tests text mode tip tips tools troubleshooting unix user video vim.editing web web 2.0 websites wordpress wtf www youtube zsh
|