Weekly Edition
Return to the Distributions page
| |||||||||||||
|
| |||||||||||||
Callaway: Chromium: Why it isn't in Fedora yet as a proper package
Fedora engineering manager Tom "spot" Callaway looks at Chromium development on his blog. Specifically, he has been building Chromium from source and makes it available for Fedoras 10-12, but hasn't packaged it up officially; in the blog post, he outlines reasons why. "Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as 'I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.'. A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct."
(Log in to post comments)
Other Webkit based browsers Posted Dec 1, 2009 20:02 UTC (Tue) by dowdle (subscriber, #659) [Link]
I haven't had a chance to read the fine article yet but I thought I'd mention some other Webkit based browsers for those who are interested in them... since that is what Chromium is.
There is Epiphany, Midori(sp?), and rekonq. Give them a try. I still primarily use Firefox but it is fun to try out other stuff.
Other Webkit based browsers Posted Dec 1, 2009 20:21 UTC (Tue) by drag (subscriber, #31333) [Link]
If they followed the same "new-window/tab = new process" then I'd switch
back to Epiphany or use Midori.
Going multithreaded for a application like a web browser was a bad move.
That is, basically, why I run Chromium nowadays. I would be using Epiphany
Other Webkit based browsers Posted Dec 1, 2009 20:34 UTC (Tue) by endecotp (guest, #36428) [Link]
> Going multithreaded for a application like a web browser was a bad move.
> Performance-wise the Linux kernel is much better at application scheduling > then application developers are.
The kernel schedules threads much like it schedules processes.
As I understand it, the issue with "traditional" browsers is that they are not even multithreaded between tabs, so that a long-running script in one tab blocks the whole app. Going multithreaded would fix this; going instead to multi-processes fixes it and also adds some security benefits.
Other Webkit based browsers Posted Dec 2, 2009 0:16 UTC (Wed) by ikm (subscriber, #493) [Link]
Processes do happen to have separate memory spaces, but they still can wait on one another. It is still an application developer who controls their interaction. The only difference, is, well, separate memory spaces, and hence "gated" way to communicate between them. Meaning if one process goes rogue, it would do less damage -- but that's it, nothing more.
Going multi-process (instead of threads) was done for security reasons only.
Other Webkit based browsers Posted Dec 2, 2009 1:33 UTC (Wed) by cortana (subscriber, #24596) [Link]
Mmm? A compromised process can still ptrace another process running as the same user. The multi-process nature of Chromium gives you stability benefits, but not security.
Perhaps we need selinux separating web pages from different domains from one another? :)
ptracing Posted Dec 2, 2009 4:04 UTC (Wed) by martine (guest, #59979) [Link]
We use a new PID namespace for renderers (which are also chrooted) to
prevent the attack you suggest.
However, we can't prevent them from e.g. connecting to dbus so your point
ptracing Posted Dec 2, 2009 8:57 UTC (Wed) by ebiederm (subscriber, #35028) [Link]
What application uses a new pid namespace? The conversation thread
got a little confused.
A new mount namespace would be better than chroot (inescapable even to root).
Do you have a suid binary that raises the privelege so you can set
ptracing Posted Dec 2, 2009 15:55 UTC (Wed) by martine (guest, #59979) [Link]
Sorry, we=Chrome. Yes, we currently use a small suid helper binary to set
things up. Source for it is here: http://src.chromium.org/cgi-bin/gitweb.cgi? p=chromium.git;a=blob;f=sandbox/linux/suid/sandbox.c;h=f54bcd14fdbb43dc0492e ceeac2658d5ae50847f;hb=HEAD
The plan is to get rid of all of this and switch to a seccomp-based sandbox,
ptracing Posted Dec 3, 2009 1:33 UTC (Thu) by ebiederm (subscriber, #35028) [Link]
seccomp may be a better solution. Just as a point of reference you could add a network namespace and get the ability not to connect to unix domain sockets aka dbus.
The plan is to eventually support proper uid/security credential namespaces and allow all of this as non-root. Unfortunately we aren't quite there yet.
ptracing Posted Dec 2, 2009 10:21 UTC (Wed) by cortana (subscriber, #24596) [Link]
Now I think about it, didn't Chromium at some point use seccomp? That seemed like a pretty
effective way to separate processes off from one another. Or was that idea abandoned because the seccomp mechanism was broken in the Linux kernel?
ptracing Posted Dec 2, 2009 15:56 UTC (Wed) by martine (guest, #59979) [Link]
The seccomp approach is still underway. It mostly works but there are a few
bugs left before we can drop the suid approach: http://code.google.com/p/chromium/issues/list?q=SeccompSa...
Threads are evil Posted Dec 2, 2009 12:18 UTC (Wed) by marcH (subscriber, #57642) [Link]
> The only difference, is, well, separate memory spaces, and hence "gated" way to communicate between them. Meaning if one process goes rogue, it would do less damage -- but that's it, nothing more.
The only difference between programming with shared memory versus not is that using shared memory generally produces buggy applications that crash in ways impossible to understand. That's it, nothing more.
Other Webkit based browsers Posted Dec 1, 2009 20:33 UTC (Tue) by SEJeff (subscriber, #51588) [Link]
But the real secret sauce is v8. Like spot rightly points out, they don't
seem very interested in v8 outside of chromium.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 1, 2009 20:17 UTC (Tue) by Cyberax (subscriber, #52523) [Link]
That's quite unfair to Java developers, because most of well-behaved Java projects now use Mavenized builds which utilize an explicit dependency tracking. With the central repository ( http://repo2.maven.org/maven2/ ) for most of artifacts.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 0:28 UTC (Wed) by motk (subscriber, #51120) [Link]
... which is out of band of system package management, so java apps tend to be a great big warfile full of specific libraries anyway.
When maven can truly understand, say, rpm targets and can be plugged into a distro build system we'll be somewhere. It's getting there, but the world as it exists today has build-random-everything-in-a-jar as the standard methodology for java apps.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 3:56 UTC (Wed) by jameslivingston (subscriber, #57330) [Link]
You could just as easily say "When rpm can truly understand, say, maven goals and can be plugged into a java build system we'll be somewhere."
Just because java builds aren't done the same was as some linux distribution do them doesn't magically make it wrong.
The issue isn't the build system, it's that java libraries often don't provide the same API/ABI stability guarantees as a number of C libraries do. Exactly the same problem happens when C libraries don't provide those guarantees, such as ffmpeg, and there is a large amount of work dealing with that. The only difference is that not providing that guarantee is much more common in the java world.
There is also the issue of putting archives inside archives, but that is just how Java works and there are some good reasons it does work that way.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 7:56 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
Java devs have been saying for years they didn't need to participate in the rpm/deb/linux package ecosystem and their way was better
How many java apps are widely used on Linux systems today?
How many persons will just reject java apps on sigh because they've tried the "java way" before and made their own opinion ?
How many php/python/etc apps were written because it was "just there" in the system and people didn't need to learn a "php" or "python" way of deploying apps to use it?
Looks like a huge *FAIL* to me
The only people that can use the "java way" are java developpers. Just developpers do not make an healthy ecosystem. Sysadmin, users, etc need to be part of it too and they care nothing about dev preferences.
PS If Java libs don't provide API/ABI stability guarantees that's also because:
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 8:28 UTC (Wed) by kragil (guest, #34373) [Link]
Java isn't _that_ special in this regard. Rails devs are even worse.
That said, I really hope Java apps will retreat to some enterprise niche I won't have any contact with. So I don't mind their unpopularity.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 13:52 UTC (Wed) by robilad (guest, #27163) [Link]
The number of packages with reverse deps on java-common in Ubuntu has gone from around 300 back in late 2006, to around 600 now.
I assume that the numbers for Fedora are similar.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 14:24 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
Given enough resources and motivation you can package anything (hell, JPackage managed to get a working tomcat package back when half the stack was closed-box SUN jars that changed location and name every time SUN re-published them)
That does not mean some software does not make it as painful as pulling teeth.
Given Java's propensity for multiplying components 600 packages is not big at all. Java has a long, long, way to go.
PS I stand by the "efficient" claim. We live in an insanely competitive world, given the number of persons that dislike the Linux model, if theirs was so much better Linux distributions would be cloning their work instead of the reverse (hi OpenSolaris).
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 15:29 UTC (Wed) by robilad (guest, #27163) [Link]
Well, I think that, objectively speaking, Apple's AppStore has been a lot more efficient at providing an 'industrialized' software distribution channel then any mainstream Linux distribution up til now - many more apps served to many more users in a much shorter time frame.
Afaict, the centralized AppStore encourages the 'binary blob of made of stuff upstream made' model of software delivery over the 'set of interdependent binary blobs made of most of the stuff upstream made' delivery model centralized Linux distributions encourage.
It seems to work pretty well for its audience despite breaking such basic taboos of Linux package management. That hasn't escaped the attention of Linux distribution makers. So now many distribution makers are racing to provide their own AppStores.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:24 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
I think the 'many more apps' could easily be disputed. What can not be disputed is that Apple relies on needing to support a small set of hardware. It is easy to make app distribution work when your hardware diversity is limited.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:46 UTC (Wed) by robilad (guest, #27163) [Link]
Apple announced over 100k applications being available in their store a few weeks ago:
http://www.apple.com/pr/library/2009/11/04appstore.html
I'm not aware of any Linux distribution that has that many packages, let alone applications.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:55 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
In the Apple world, an "application" can be anything from Photoshop to an iphone screen that links to random web content.
Do you want to bet which kind of app makes the bulk of their numbers?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:59 UTC (Wed) by robilad (guest, #27163) [Link]
Well, the quality of the content doesn't say anything about the quality of the distribution mechanism, and vice versa. We're still discussing distribution mechanisms here, right?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 19:35 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
It's not about the quality of the content, it is about the constrains it poses.
To take a real-world example, just because an army of bicycle postmen can deliver an astounding number of small letters in a city, does not mean they won't fare miserably as soon as you give them a big parcel,something to deliver long-distance, a container, or some refrigerated content, live animals, etc to distribute
So your comparison is ridiculous. I'm sure yourtube or "social" web sites could blow Apple numbers out of the water by counting the pictures, songs, or bits of javascript, they deliver to a large number of people of everyday. That does not make them examples to follow when assessing ways to distribute complex application ecosystems where multiple components interact with each other.
You can try to avoid dealing with the problem by bundling everything in one place (as Apple does, and SUN tried to with Java). It only does so far before the impedance mismatch between different un-cooperating binary bundles forces you to dedicate separate un-upgradable systems for every one of them (as is commonly seen in the Java world, where supposedly multi-purpose flexible app servers are usually dedicated to a few closely cooperating apps, as they can't cope with real diversity). It is highly ironic that you point out the Apple Appstore where this logic led to two special-purpose products, ipod and itune.
I suppose one could claim this model is "efficient" at the software level. It only multiplies your hardware needs many times over. Unsurprisingly, SUN and Apple are in the hardware business.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 20:48 UTC (Wed) by robilad (guest, #27163) [Link]
Do you have a link to some 'complex application ecosystem' distribution of JavaScript applications that has 100k apps?
I am not sure I can follow your 'Apple is in the hardware business' line of thought. You seem to believe that Apple designed their software distribution mechanism to force users to eventually buy an iphone/ipod for each application separately, multiplying their hardware needs many times over, if I understand you properly?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 22:35 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
I'm saying the "100k" apps Apple claim are
1. mostly trivial stuff, declined many times over to increase the advertising surface in the app store and get more customers
2. not a complex code ecosystem (unless you remove most of the content, and then the numbers don't look so good)
It is easy to inflate numbers when counting trivial apps (Palm did it a decade before Apple). A site like tesnexus is at ~ 30k (their latest mod today is 28515) that would all qualify as applications under Apple's definition. I hope you're looking hard at this new software power house
And yes, I claim Apple is very happy to foster habits where you by one device for music, one to telephone, etc even thoug most of the hardware inside is the same.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 22:48 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
And just to show how pointless Apple brags are
1. there are almost 20k binary packages in Fedora x86_64 development version alone (about 19500) 2. Add the i386, ppc, etc package numbers 3. Add Fedora 1 to 12 packages 4. Add updates
Suddenly 100k does not look such a high number
And that was one Linux distribution. I could have inflated the numbers even more by counting its predecessor (Red Hat Linux), all its derivatives (OLPC, RHEL, EPEL, CentOS, Moblin, etc)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:03 UTC (Thu) by robilad (guest, #27163) [Link]
Well, it may help to put that 100k number from November in context, that Apple was bragging about 85k apps in late September:
http://www.apple.com/pr/library/2009/09/28appstore.html
Thank you for looking up the Fedora package numbers. They are interesting, so let's play a bit with them. As we are comparing single, centralized distributions of upstream software here, I think it's more adequate to pick a single Fedora release - the one you provided numbers for.
As Fedora packages developer-oriented parts of an upstream separately, I'd assume that's around 10k upstream applications for the current distribution. For the sake of inflating Fedora's numbers, let's count libraries as applications, too.
For the sake of deflating Apple's numbers, let's apply the Pareto principle, and weed out 80% of the apps as trivial. That leaves 20k non-trivial apps in November, and 17k in late September.
Let's also assume that the Pareto principle does not apply to Fedora at all - everything that gets packaged into Fedora is a non-trivial labor of love, and so on.
Even with all that, Fedora is still quite a bit behind Apple's distribution in raw numbers. In particular, just the increase in non-trivial apps in Apple's distribution in the course of a couple of weeks is almost a third of all of all applications in Fedora.
I'd be very surprised if the growth of packages in Fedora is remotely close to that. So I think that maybe there is more then 'one true way' to implement 'industrialized', 'efficient' software distribution.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:56 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
You continue to be disingenuous
Apple counts *all* apps, for *all* its systems (itune, iphone, etc)
So it is not fair to remove older releases, Apple counts them too
It is not fair to count only Fedora but not OLPC, Centos, RHEL, etc Apple counts different lines of products too
And lastly, Apple does not have the aggressive culling processes of a distribution like Fedora. Fedora worries about mirror space, Apple worries about getting the highest number count possible in press releases.
Yet, even given all this, Apple does not manage to equal the Fedora ecosystem alone.
So your chosen example nicely disproves your point.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 15:37 UTC (Fri) by robilad (guest, #27163) [Link]
"You continue to be disingenuous"
Well, thank you for your polite, respectful and informative words. You have eloquently convinced me, now I see that I was wrong all along.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Jan 7, 2010 21:27 UTC (Thu) by ceplm (subscriber, #41334) [Link]
Really the number of apps is not the point ... complexity is. Try to
understand all packages required when you install some substantial program (firefox, postgresql, eclipse-platform ...) and then compare them to (comparably) trivial tiny apps available for iPhone. Just pure numbers are absolutely meaningless.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 9, 2009 20:55 UTC (Wed) by leoc (subscriber, #39773) [Link] How many of those "apps" are anything other than a launcher for a web link? Also, as was pointed out in this item, the vast majority of available apps in the app store (as in 80% to 90%) are not really even maintained any longer. Considering the level of unprecedented hype that the iPhone and app store have received, you would expect the tail on this graph to be a little less flat.Ignoring things like application size and complexity, duplication of function, actual level of use, end user quality, and the heavy hand of Apple censorship makes your argument about it somehow being a model to 'copy' specious at best. If any Linux distribution ever does consider adopting such a broken and anti-developer model, I'd keep away from it with a 20 foot pole.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:21 UTC (Thu) by motk (subscriber, #51120) [Link]
False equivalence. Show me how a shiny webdav client that copies binary blobs has anything to do with a rich dependency management system like rpm/yum.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:34 UTC (Thu) by robilad (guest, #27163) [Link]
Both copy software provided as binary blobs with associated metadata from one central place to some other place.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 23:43 UTC (Thu) by motk (subscriber, #51120) [Link]
That's a little ... simplistic, shall we say. If you can't understand the difference between rich dependency management and a sexified webdav client then I don't know what to say.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 11:51 UTC (Fri) by Cyberax (subscriber, #52523) [Link]
Have you _ever_ used Maven?
It's much more than a 'webdav' client. For example, Maven can be used to build application, run tests, bundle it and then upload to a repository. With source code attachments, if desired.
Your assertion is like saying that 'APT just downloads some files' or 'dpkg just unpacks archives'.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 0:07 UTC (Mon) by motk (subscriber, #51120) [Link]
I've used maven, and quite like it! I was refering to the Apple app store, not maven in this case.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 15:49 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Watch out your prejudices: with jpackage.org I can use RPM-packaged java components, including integration in Maven2.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 16:05 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
I am well aware of JPackage. They do a wonderful job, but their life is not simplified at all by Java common practices (the same ones Tom Callaway complains of in his message)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 7:08 UTC (Fri) by jameslivingston (subscriber, #57330) [Link]
That's right, as the Java and linux packaging practices don't mesh well together. It's not the fault of either side, it's just that they were developed independently with different goals, so just make it hard to mix the two.
There are some quite easy ways to make Java packaging fit with a distro's packaging system, it's just that it would violate most of their policies:
Of course your linux packagers will have a fit, because you're abusing their packaging system, but it works :)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 8:53 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
It only works in the fork and forget mode Java developpers are so found of (secrutity issues, who cares about security issues, didn't SUN promise me a language that voided them all?)
FFmpeg does *not* have an unstable API Posted Dec 2, 2009 12:36 UTC (Wed) by DonDiego (subscriber, #24141) [Link]
> The issue isn't the build system, it's that java libraries often don't
> provide the same API/ABI stability guarantees as a number of C libraries > do. Exactly the same problem happens when C libraries don't provide those > guarantees, such as ffmpeg,
All false claims to the contrary notwithstanding, FFmpeg has never had a volatile API. Please stop claiming otherwise.
FFmpeg does *not* have an unstable API Posted Dec 3, 2009 10:42 UTC (Thu) by alankila (subscriber, #47141) [Link]
So...why exactly did everyone seem to fork a copy of ffmpeg into their video players at some point of time, then?
FFmpeg does *not* have an unstable API Posted Dec 4, 2009 7:17 UTC (Fri) by jameslivingston (subscriber, #57330) [Link]
The people I've directly talked with who forked copies of ffmpeg into their projects would disagree.
Take another example: Gecko. While it has "stable" and "unstable" APIs, you can't (or couldn't, last time I checked) realistically embed gecko into your app without using API marked unstable. So for all practical purposes it has doesn't provide any real API stability.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 0:34 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Nothing unfair about it. Whenever we run into Java programs, they are
typically very difficult to package due to the problems Spot is talking about. Apparently well-behaved Java projects are low in number still.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 1:21 UTC (Wed) by robilad (guest, #27163) [Link]
Is there a translation of what he is talking about into English? Bedazzler Jewels? Huh?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 2:01 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
There are many issues but the most common one is bundling patched copies of other Java libraries in a single massive zip file with no attempt to even contact the developers of the libraries they have been patching with the excuse that they are too unique.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 10:09 UTC (Wed) by robilad (guest, #27163) [Link]
Is there a specific instance you're talking about? Searching the web for java+"we're too unique" gives me no useful hits among the one or two hits it finds.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 4:53 UTC (Thu) by Imroy (guest, #62286) [Link]
I've recently been looking for calendar/contact syncing software for my family network. Most of them appear to be Java based. Go look for "Funambol" and their 170M bundle which includes a Java 1.5 JRE (x86 only), Tomcat, and hsqldb. Or how about "Bedeworks" and their 225M "quick start package" with even more thrown in.
As a long time Linux (Debian) admin and Perl programmer, I look at this and can only say a huge WTF! I guess this is what happens when a language/environment is mostly used for developing private software inside companies and the like. The programmers see their software as being part of a "bundled" system, instead of simply being a component that works with other (separate) components.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 10:46 UTC (Thu) by alankila (subscriber, #47141) [Link]
I concede that adding a JRE to your software's package is stupid & shouldn't be necessary.
The reason why java apps do bundle a lot of software is generally to have a single file that can be downloaded, dumped on any system, and which then works if you just execute it. Java sort of solves the distributing problem, and the accepted solution is to simply package the entire world into one giant bundle. Where I'd draw the line is with including a runtime environment, though.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:24 UTC (Thu) by robilad (guest, #27163) [Link]
Well, sure, but that doesn't validate rahulsundaram's claim.
He is claiming that:
"bundling patched copies of other Java libraries in a single massive zip file with no attempt to even contact the developers of the libraries they have been patching with the excuse that they are too unique"
So: Are those copies patched? Are they delivered as a single zip file? Did they attempt to contact developers of the patched libraries? Did they claim that they are too unique?
The claims rahulsundaram makes should be easily verifiable for him by showing an instance of all that actually happening in the last year or two. After all, he claims that it's the 'most common one' among the issues spot is alluding to in his bizarre quote.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 1:31 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Several people have given you many examples. You seem to ignoring them all. How about this, show us a few popular counter examples?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 14:30 UTC (Fri) by robilad (guest, #27163) [Link]
Actually - no - all that I've seen so far has been highly amusing ranting about the oh so horrible ways of Java developers and a few pointers to some applications having large downloads. Nothing that actually confirms the very specific claims about Zip files, "we are too unique" etc. you have made.
Please back those claims up with references.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 15:29 UTC (Fri) by robilad (guest, #27163) [Link]
And I should point out that I'm interested in evidence to help me understand whether your translation of spot's words (thank you for doing that) is based on your actual, personal experiences packaging Java software for Fedora, or on a 'a friend of a friends once read on LWN ...' sort of experience ;)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 5, 2009 7:31 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
FYI, I maintain several packages for Fedora and Java software has usually
been a severe pain point. Freemind for example is still not in Fedora after several failed attempts because of problems like the one I noted. So yes, it is personal experiences I am talking about. Whats your experience?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 12:20 UTC (Sun) by robilad (guest, #27163) [Link]
Thank you for your work on packaging in Fedora, and thank you for coming out with an example for your claim that Java developers claim that they are too unique, etc.
Rather then taking your claims at face value, I thought I'd see for myself. Not that I don't trust your authority, with you being a packager and all that, but I have not seen you post once to fedora-devel-java in the past 15 months, so I assume that is not your area of expertise. In particular, I can't find your name in the conversation in the Fedora bugzilla entry for freemind.
The last attempt in the Fedora package database that I can find is
https://bugzilla.redhat.com/show_bug.cgi?id=428413
It's a packaging attempt by Alex Leamas. A quick check on the freemind site confirms that he is not one of the freemind developers. That's not a good sign - the freemind source code tarball is larger then a megabyte, so understanding it in order to make significant modifications likely requires a significant investment in time.
In addition, Alec says:
"This is my first attempt to provide a package for Fedora...
Also, it's a java application. There is an obvious need for guidelines for java apps, hav'nt found any."
Attempting to package a large application in a domain where the distribution has no obviously findable guidelines as one's first package - what could possibly go wrong with that?
Then, after some initial work, some license issues are discovered by spot, and he says:
"Yeah, you are going to need to get upstream to resolve these license issues."
Now this could be the moment where the upstream shows uncooperative, and the oh so horrible ways of Java developers are unmasked. Amusingly enough, that's not what the bug says - it says nothing at all about the packager communicating with the upstream and reporting back how that went. So one has to search for it and finds an upstream developer say:
http://www.mail-archive.com/freemind-developer@lists.sour...
"I change the licence of my file soon and have a look at the others."
I tried hard to figure out how one could possibly take that to mean "we're too unique". I don't see it - to me that sounds like a Java upstream bending over backwards to help with licensing changes to ease the packaging into Fedora. Quite a different picture in reality then being painted here by spot & rahulsundaraman, apparently.
But, as I said, no word about that in the bug report.
So, why does the packaging attempt, unsurprisingly, eventually fail?
"file bindings.jar is the result of a compilation of a xml file which defines the interface. It might be impossible to get this compilation, involving JAXP API:s to work.
When rebuilding jaxme and running the compiler I run into problems since the source xml file contains constructs not supported by the jaxme xsd compiler. It might be possible to walk around this, but I don't know enough about the JAXP interfaces to do this, at least not now."
Translation to English: Because the prospective Fedora packager doesn't know enough about the software he's trying to package.
But that's not the only reason, there is also
"Even worse, current CVS sources shows that freemind now uses Sun's JAXB suite to handle this. It does support all constructs, but it is at best GPLv2 only. And it does not build for me, some kind of config problem."
JAXB is, of course, part of the Java SE 6 platform, so it's in IcedTea, OpenJDK 6, etc. It's dual licensed under CDDL 1.0 & GPLv2 with the Classpath Exception. No one of Fedora's licensing experts catches that mistake, and asks the prospective first-time packager to try using IcedTea or OpenJDK instead.
So it all predictably ends with:
"My first attempt to submit a package has, for now, failed.
The main reason is that recent code (after 0.0.9Beta15) has became heavy
So, the legal reasons come down to Fedora's experts not bothering to check the first-time packager's assumptions about licensing of an upstream dependency and fix his mistake.
The technical reasons come down to the lack of prospective packager's technical prowess with the upstream codebase, and its dependencies. On a meta-level, attracting contributors for the jobs they don't have a chance of doing well is a failure in Fedora's recruiting & mentoring process.
Through the whole effort, the upstream project does not claim that they're too unique, apparently. There is nothing in the bug report indicating that the bundled libraries were patched and the upstream refused to send their patches further upstream, either, even though rahulsundaraman claims that is the most common issue.
So for someone familiar with Java development, the sweeping statements about Java developers made by rahulsundaraman & spot looks more like playing on a bias for the purpose of blame shifting to the upstream for inadequacies in Fedora's processes, recruiting & mentoring in the area of packaging Java applications.
What has happened since?
"Could this be reopened? The latest Freemind release candidates (I've tried 0.9.0-RC3 and RC4) work just fine with the OpenJDK VM supplied with Fedora 10 (java-1.6.0-openjdk-1.6.0.0-15.b14.fc10.i386"
"Please file a new review request and mark this bug as
No duplicate marked so far.
There has been a freemind package in Debian since 2004.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 13:39 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Btw, there are several review failed review requests. You just managed to pick one. Feel free to research others and the long history of JPackage or Eclipse or any major Java software.
Spot maintains the largest number of packages in Fedora and nim-nim has been very involved with JPackage before. I have personal experiences which tell me the same thing. If you don't want to disagree with everyone's expertise, be my guest.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 15:36 UTC (Sun) by robilad (guest, #27163) [Link]
I looked at freemind because you told me it backed up your claims. I didn't pick a project at random to make you look bad.
There is only one review request for freemind in the Fedora bugzilla as far as I can tell. I'd appreciate a pointer to a review request that shows that the freemind upstream is shipping patched libraries and refusing to upstream their patches with the excuse that 'we're too unique', as you imply.
But maybe you meant to point me to another package, and made a typo, or something. Would you please be so kind to point me to the failed review request for Fedora 12 that backs up your sweeping claims about Java developers?
What is the ratio of the review requests failing for Fedora-specific reasons like freemind vs. those failing for the reasons you attribute to Java developers in general in Fedora 12? Since you make the claim that it's the majority of cases, it should be trivial for you to back that up, right?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 15:47 UTC (Sun) by robilad (guest, #27163) [Link]
My apologies for asking you to back something up you didn't literally say - you did not claim it was problem in the majority of cases, you said it was the 'most common one'. I'm curious how common it actually was for Fedora 12.
Is there a query for the Fedora bugzilla that lets me see those most common cases for Fedora 12?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 1:43 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
You continue to attribute claims that I did not make to me. I must ask you to stop doing that. I said, the most common problem with Java software is that they bundle copies of other Java software often with patches (to avoid dealing with dependencies). I did not say it is the most common problem in Fedora or Fedora 12.
A simple query on bugzilla doesn't return such information. Feel free to talk to package maintainers with some significant experience in maintaining packages for a large distribution and they would likely have noticed similar patterns. So would have the security teams of such distributions. You can also talk to folks involved with JPackage.
It was much more difficult a few years back
http://www.linuxjournal.com/article/7413
Red Hat's involvement with OpenJDK/IcedTea and other Java software has helped here and atleast some upstream projects have gotten better over a period of time as well, notably Eclipse. Some of it is a mismatch between tools. One effort to tackle the problem is at http://fedoraproject.org/wiki/KojiMavenSupport
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 18:26 UTC (Mon) by xkahn (subscriber, #1575) [Link] I usually try not to reply to a thread until I've read all of it, but look at Alfresco. Here's a page where the Fedora project tried to create a package:
You can see that Alfresco bundles a large number of JARs and that some of them have "_patched" in their name. And this is a package with a reasonably large company backing it! Alfresco themselves mention this as a problem: http://forums.alfresco.com/en/viewtopic.php?f=8&t=11744
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Jan 7, 2010 22:44 UTC (Thu) by ceplm (subscriber, #41334) [Link]
Just to add one more example which you would ignore, I have tried to
package OpenFire for Fedora (http://www.igniterealtime.org/downloads/download-landing.... file=openfire/openfire_src_3_6_4.tar.gz, 48.81 MB) and after couple of days of attempts I just gave up ... not only that the tarball contained JRE, it also contained many many other packages (couple of database connectors, couple of building tools like ant, and others ... did they really need their own fork of ant, or did they just dump their working directory to the tarball?).
When discussing this with the upstream programmers, and arguing with the
Another example, I have really liked the idea of blueMarine
Could you actually show me one large Java project, which has proper tarball
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 9:44 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
He talks about broken ecosystems such as Java where there is no industrialized efficient way to make code flow from creator to distributor to user.
As a result it is easier for someone deep down in the distribution chain to fork code and make bastardised zombie private copies of someone else's code than to try to make the original code authors aware of the problem, have them fix the original component (the years of closed black-box SUN stewardship didn't help either), and wait for the fixed copy to flow downwards.
I wrote bastardized because such local changes are rarely tested except for a very specific use case (so they usually break as soon as you try to use the fork for something else) and zombie because after the initial fork the local developer rarely bothers trying to follow upstream changes and just freezes his version.
Of course since bastardized zombie is not something customers and bosses would approve of, it is presented in glowing self-flattering terms by the person who forked the code (cheap Bedazzler jewel bling that shines but is still crap).
Projects like maven that make their primary use case "download specific file with checksum X for location Y, and hide it from other apps so they don't have to be coordinated" contribute to this vicious circle by making it even easier to access local forked code copies, and removing the few remaining incentives to have code fixed (properly) at the source.
Linux packaging systems push every app to use the same component versions and declare non conflicting identifiers. It is an intentional choice to fight short-term forking temptations, make people work with each other, and promote virtuous circle practices.
Chromium is walking down the well-known old short-term private fork road to hell. It can not be packaged in distributions because their tools and organisations were designed to oppose this kind of practice (many people claim this is misguided angelism; none of those ever managed to build a successful system the size of current Linux distributions).
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 12:27 UTC (Wed) by robilad (guest, #27163) [Link]
None of that seems Java specific to me.
Open source enables the existence of more then one redistributor, and allows them to take matters into their own hands. And, in practice, they do. The long tail of open source production will only get longer with better, distributed tools making fork-n-forget easier, in my opinion. Regardless of the programming language used to produce the open source software in question.
The embedded Linux world is a good counterexample to your claim - there is nothing Java specific about the forked and forgotten vendor kernels. I somehow doubt that blaming that on some made up 'C developer mentality' would get much support on LWN.
So, let's take your argument half-seriously and try to apply it, tongue-in-cheek, to Linux distributions.
Linux distributions, for example, rarely package applications in the 'pristine' upstream form, regardless of the programming language used to write those applications. Instead they often make local changes called patches. The patches they make are typically tested on the distribution they are made for, and not, say, on Microsoft Windows, Mac OS X, or some other operating system the upstream project may chose to run on for whatever weird reason. They often freeze their local, forked version of upstream software for years during a release cycle and present those versions in glowing self-flattering terms as 'enterprise' releases. Projects like Linux package managers make their primary use case to download specific files with checksums from some remote location to put it on the user's system so that it doesn't have to be coordinated with whatever mechanisms applications use to implement similar functionality.
Using your rationale, we should call Linux distributions 'cheap' for doing all those things.
I disagree - the Linux packaging model works. I think it works because there is an acceptance among its users for a centralized distribution model where software flows through distributors to them, and it has evolved tools, policies and, in particular, taboos to make it all more or less work. Whether the Linux software distribution model is 'industrialized' and 'efficient' is, in my opinion, debatable.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 21:07 UTC (Wed) by nevyn (subscriber, #33129) [Link]
> Linux distributions, for example, rarely package applications in the
> 'pristine' upstream form,
You obviously have a different definition of "rarely" or "pristine" than
[snip]
If a distribution did all those things, without co-ordinating with upstream
All sane distributions "enterprise" or otherwise, do the vast majority of
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 22:21 UTC (Wed) by robilad (guest, #27163) [Link]
I'm not aware of any 'enterprise' Linux distribution that comes with the pristine upstream kernel, without any patches, over its entire support period. I may be wrong, of course - I'd appreciate a pointer in that case.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:08 UTC (Thu) by motk (subscriber, #51120) [Link]
That's dissembling - the kernel is a special case, and of course all distros rebase to the latest and greatest whenever they can.
The whole javacentric development/distribution model is just indefensible in 2009. I guess it's a natural outcome of a language that was designed for portable devices, but the community should know better by now.
I do in fact love some java apps - the entire Atlassian suite springs to mind - but I do wish they could make the things build natively instead of requiring a 300M download of hundreds of bundled libs.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 11:07 UTC (Thu) by robilad (guest, #27163) [Link]
OK. If the kernel is a special case, what about glibc? Which enterprise distribution ships glibc without any patches applied over its support time? Or gcc, if glibc is too special?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 23:50 UTC (Thu) by motk (subscriber, #51120) [Link]
Examples?
There is tight coupling between distribution glibc maintainers and the core glibc developers. As kernel+glibc is pretty much the core of a given linux system, I'd argue that yes, this is a special case also.
You're dissembling again - you can hardly compare glibc or the kernel to tens of thousands of random library snapshots bundled up in apps, never to be seen again until something explodes.
It's just laziness at this point - bundling up a selection of stuff that you've managed to finagle into working, declaring it 'finished', and then chucking it over the fence.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 15:11 UTC (Fri) by robilad (guest, #27163) [Link]
Well, I think that's the whole point - developers patch third party code because they have their own good reasons. Or so they believe. ;)
From the perspective of a platform provider, like a distribution, having control over what goes into the platform, and being able to tweak it to assemble one's platform built on own software along with various third party components into a coherent whole is a really good thing.
From the perspective of an application provider, being able to do the same is a good thing for pretty much the same reasons.
It's where the two worlds are forced to coexist that the conflicting interests collide. Blaming the conflicting interest on a particular programming language is quite short sighted, though - the ISVs struggling to get native code packaged for Linux across distributions are fighting with the same impedance mismatch between the interests of the platform provider and their own, and of course the regular 'language-specific dependency system sucks because it doesn't play well with my package manager' provides another set of evidence for that conflict - whether that's Ruby Gems, Python Eggs, or Maven.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 16:18 UTC (Fri) by nevyn (subscriber, #33129) [Link]
I can't work out if you are trolling (badly), or are really failing to
understand what everyone is trying to tell you. Being optimistic I will, probably stupidly, try again:
1. Changing code from "your upstream" isn't great, but does have to be done
2. If you do #1 without contacting your upstream, or (less often) directly
3. As a corollary to #2, if you are a significant portion of upstream then
4. As a corollary to #3, if you are just backporting patches from upstream
...Java code (and Chromium) are doing #2, and "enterprise Linux" are #4 in
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 14:37 UTC (Sun) by robilad (guest, #27163) [Link]
"I can't work out if you are trolling (badly), or are really failing to
understand what everyone is trying to tell you."
Thank you for your kind words, I appreciate your help in helping me understand what everyone is trying to tell me. If it helps, I think that your argument is sound - I just disagree that it in practice distribution developers really act very differently from Java developers.
Your basic claim here is that Java developers in general engage in activity #2, whereas other developers, in particular developers of distributions, don't. So, let's see if that claim is true.
In another thread, rahulsundaraman mentioned the troubles to package freemind in Fedora. I find that example slightly ironic, in light of the claim above:
https://bugzilla.redhat.com/show_bug.cgi?id=428413
After some struggling, the prospective packager decides to do some more radical changes on the upstream sources:
"Swinging the machete this way means to remove all export/import functionality from Freemind. However, the core functionality create, edit, open & save works fine, as does the browser applet. Plan to add some plugins later, if/when this package is approved."
None of the Fedora reviewers objects to the packaging technique of 'swinging the machete' to remove major functionality of the upstream application, or asks if the prospective packager coordinated that action with the upstream - after all, the upstream may prefer not to see users of its app struggling with a heavily locally patched version that lacks certain features, and see it more worthwhile to work on a long term solution instead.
Nothing in the bug report shows that such coordination took place, or that the first-time packager was encouraged by the reviewers to follow such basic rules of packaging upstream code.
Is that really a failure of the upstream to communicate with their upstreams, or is it a failure of the Fedora downstream to communicate their heavy, local patch attempts to the upstream?
From looking at the bug report, it seems like a case of the latter. No communication at all with the upstream is mentioned in the bug report, fwiw, and none of the Fedora reviewers seems to think that could be something worth pointing out in the bug report, which is rather surprising given the scope of the proposed machete swinging to get the application packaged.
So, I'd disagree, based on the attempt to package Freemind for Fedora, that Fedora packagers don't do #2.
Whether Java developers in general follow the same engineering practice of machete swinging, is an interesting question. From what I can see in the open source Java world today, the answer is 'not any more'. ;)
I have been following different packaging efforts in this space for a little while, so I know how hard it was to package Java libs & apps back in the last century. With the arrival of OpenJDK in distributions a year or so ago, this has become much simpler, due to the existence of a full, working implementation to build upon, and at the same time, because of the gradual move of many Java upstream projects towards Maven, Ivy and other forms of declarative dependency management.
Maven has been a thorny issue for many distributions, because it by default resolves the dependencies using repositories on the Internet. In the last year, both Fedora & Ubuntu have made significant progress on getting maven to be 'distribution-friendly', so that it can be used for building packages.
So I'd expect to see a lot more Java upstream packaging attemps in Fedora in the coming years - and that's why I'm interested in finding out whether the problems spot alludes to are indeed structural to the 'annoying' ways Java upstreams work today, as you imply, or are simply caused by a lack of technically competent communication between the Fedora downstream and the Java based projects that are being packaged. If the case is actually the latter, then the 'bah, stupid Java upstreams don't know anything about software development' mindset would seem to be harmful to improving Fedora in the long run.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 16:55 UTC (Sun) by nim-nim (subscriber, #34454) [Link]
> After some struggling,
Thank you for the “some”. Good way to paper over multiple recursive build and legal problems which seem to be the norm as soon as you lift a typical java bundle lid. Bugzilla is not a blog people only write a few lines here for hours of work.
Swinging the machete is highly unusual for non-Java packages. For Java packages, well, packagers are human too and there is a limit over which they give up or swing the machete. No one is going to spend multiple hours writing long bug reports when upstream does not care a nit (as evidenced by the dismal quality of their source release)
FYI I spend 4 years of my time packaging Java stuff at JPackage (non trivial packages such as tomcat, which have been copied almost all rpm-based distributions) and am still on their admin list, which is experience enough to have some idea of what the average Java source looks like. (I won't claim I was particularly good or inspired, except strangely enough there was no one better asking to take my place). I have been following different packaging efforts in this space for more than a little while. It takes 4 or 5 Java people to make 10% of the progress one person does naturally in other languages. There is such a legacy of forks, non-cooperative reinventing of the wheel, and other bad practices people always try to invent ways not to fix them because as soon as they realise the huge problem pile they want to forget it. Maybe SUN will manage to break the vicious circle with Java 1.7. It will have to release it first however. Also it needs to attain J2EE status before people start to take notice of it (ie it is years away). There is too much money in Java right now to make a purge easy, “lesser” languages at least have no illusion they must strive for the best to survive.
In more than a decade of packaging I've only encountered once a non-java package which was as rotten to the core as the average java package is (argyllcms).
And the problem never was technical (one could have done clean Java releases with make or ant a long time ago) but 100% cultural. JPackage antedates projects like maven yet maven developers quickly ignored all the early feedback JPackage gave them as soon as they realised it went contrary to the usual Java developper (bad) habits.
This is how bad the situation is.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 11, 2009 0:23 UTC (Fri) by gwg (guest, #20811) [Link]
> In more than a decade of packaging I've only encountered once a non-java
> package which was as rotten to the core as the average java package is (argyllcms).
Nothing like slandering someone in passing, eh ?
Lets see, ArgyllCMS is about 6M of source (it's got a way
Actual users of Argyll appreciate that it installs and runs
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 11, 2009 6:52 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
And I should have added in all fairness that ArgyllCMS's upstream tried to fixed some of those problems when notified, which is more that can be said about the average Java project.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Jan 7, 2010 22:53 UTC (Thu) by ceplm (subscriber, #41334) [Link]
You obviously never tried to package Amaya ;). Oh well, one of the biggest
perpetual source of frustration and disappointment.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 16:57 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
The theory is that the same pressures apply to all languages and they all suck equally.
The practice is that given the same constraints as every one else, Java developers fare a *lot* worse than others and make life a *lot* harder for their distributors.
You can check this easily by asking integrators from *any* Linux or BSD distribution
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 13:12 UTC (Sun) by robilad (guest, #27163) [Link]
"The practice is that given the same constraints as every one else, Java developers fare a *lot* worse than others and make life a *lot* harder for their distributors.
You can check this easily by asking integrators from *any* Linux or BSD distribution"
Ok. Let's take that claim seriously and check the fedora-devel-java mailing list. If the packagers were facing extremely uncooperative upstreams of the kind rahulsundaraman claims to exist, there surely should be no lack of traffic about it on that mailing list, right?
I have not found a single post on the fedora-devel-java mailing list in the last year complaining that a Java upstream is claiming to be too unique and refusing to upstream their own local patches further. If the claim about Java developers being exceptionally uncooperative in that regard is factual, it should be no problem for its makers to produce evidence on fedora-devel-java backing it, right?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 13:52 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Wrong. Review requests are processed via bugzilla. Not in mailing lists. Looks like you are going to a great extend to avoid facing the fact that Java software has for a very long time sucky to package. It is common practise for Java software to bundled binary Jar files of other software. Go look at the source code for Eclipse or JBoss or ANY major Java software. Come back when you have done this analysis.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 17:20 UTC (Sun) by robilad (guest, #27163) [Link]
"It is common practise for Java software to bundled binary Jar files of other software."
Indeed. But you claimed that Java developers were rather special in that regard, afaict. You may be surprised to find out that bundling one's dependencies is not a practice limited to Java developers. If you look around the free software world carefully, you'll find that native cross-platform applications like Firefox embed their dependencies as well, and so on. This whole article is about the native application Chromium. No Java in there at all, afaict.
In the Firefox example, let me pick a dependency recently meantioned on LWN: jemalloc. It is the default malloc on FreeBSD, but you will have a hard time finding it packaged on Fedora. You'll find it's in the upstream sources, and if you look carefully, you'll find that Fedora even carries a local patch for jemalloc in Firefox: http://cvs.fedoraproject.org/viewvc/F-12/xulrunner/mozill... .
I'll have to leave it to you to decide whether that local change is good or bad engineering practice depending on the programming language background of the packager creating it ;) I tend to assume that Fedora packagers have at least as good reasons for the local changes they make to the dependencies of their project as well as anyone else has for their local changes in their projects.
Anyway, there is a bit of a difference from the perspective of a packager between bundling binary jars of one's dependencies coming from upstream projects (you communicate, strip & recursively replace dependencies with packaged versions), and your general claim that Java developers modify their bundled dependencies locally, and refuse to share their changes with the upstream claiming that they are too unique.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 1:22 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
"Indeed. But you claimed that Java developers were rather special in that regard, afaict"
No. I did not. It is quite clear that it is not because this news story is not about a Java app. Java software is quite common and hence used often as an example but there are other offenders as well such as web apps. Java developers merely tend to make the problem worse because they continue to believe that they can ignore platform integration and just pass zip files holding large binary blogs of dependencies (with patches that have not been pushed to upstream) to users and JVM will take care of everything.
Unfortunately, it is not a simple problem space and their approach creates difficulties for integrators such as package maintainers. They have been ignoring this problem quite often although this appears to be changing over time.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 10:53 UTC (Thu) by alankila (subscriber, #47141) [Link]
I'm a bit puzzled at how it can be so difficult to package something which works if you decompress a .tar.gz to a directory, cd there and execute the program contained therein?
I have seen Debian (and Ubuntu) people trying to package new versions of eclipse and it took several years to go from 3.2.3 to 3.5.1 and the last time I tried their package it still had something broken in it, like java content assist didn't work at all. Oops!
So how can it be that a simple dumb extract of a .tar.gz is a better, more working approach than all this effort spent on packaging which:
a) is apparently so difficult that it doesn't get done for years and years;
I think part of the problem with a) was that they insisted on using GCJ originally, when Java wasn't free software and openjdk didn't exist. GCJ is not a good java implementation, so that added extra difficulties along the way.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 20:52 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Java "solves" dependency problems by stuffing everything in a single huge blob. Apart from the terrifying waste of resources, that means you hit a wall as soon as you need to make two such bundles talk to each other. They only work in isolation (that made the fortune of SOA ESB and EAI sellers: hardware is getting so fast you need VMWare and friends to cut it in useful slices, and at the same time java enterprise "solutions" can not coexist on the same server and need dedicated software to help them to talk to one another)
Packaging complex stuff like eclipse is very hard because you need to re-discover all the component interdependencies that have never been properly documented by upstream (when they still know what they are)
However, modular design and packages is how Linux scales from embedded to mega-clusters.
Interestingly, the JVM itself has been managed by SUN using the big blob no dep tracking model (can not deploy dependencies, so need to put every important lib in the jvm to deploy it). As a result, the JVM is cracking at the seams, and Java 1.7 is getting forever to get done (with "interesting" release history such as open sourcing early java 1.7 code, downgrading it to java 1.6, blowing up this work by releasing new java 1.6 versions that add new closed code to the mix, etc, etc)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Feb 4, 2010 19:40 UTC (Thu) by ceplm (subscriber, #41334) [Link]
I was still around Debian (couple of years ago) when there was a serious security bug found in libz (compression library behind gzip and many many other programs). Suddenly all Debian maintainers were running around and finding more and more copies of libz in source trees of their applications (heck, even kernel had one for ppp). Something which would couple of lines fix in one package, was a month long disaster which took a lot of time and effort. I remember it well as a lesson why this "Java" (not limited to Java) approach is completely insane and irresponsible. Are you sure that Google fixed that security bug in (say) libpng which was discovered last week?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 2:16 UTC (Wed) by mmcgrath (guest, #44906) [Link]
> That's quite unfair to Java developers, because most of well-behaved Java projects now use Mavenized builds which utilize an explicit dependency tracking.
The whole concept behind java is to completely ignore the operating system instead using a jvm. Which sounds great when one java developer is talking to another but when a sysadmin like myself tries to use java, I end up having to learn a completely new package management system.
Not only that, but I now have additional upstream vendors and for java apps that aren't using maven and have bundled a bunch of libraries into their app I have to track each library to ensure it they're not vulnerable.
Java isn't wrong for doing this, but it is completely contrary to the way an admin does their normal work. This fundamental difference provides several conflicts for me which is why after two jobs having java apps forced on me I chose not to use them at my current job.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 3:06 UTC (Wed) by ncm (subscriber, #165) [Link]
"Java isn't wrong"
I had to stop reading there.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:10 UTC (Thu) by motk (subscriber, #51120) [Link]
>The whole concept behind java is to completely ignore the operating system instead using a jvm.
Well, it was, but since they gave up the entire sandbox idea and started using native system calls etc they now have the worst of both worlds.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 11:20 UTC (Wed) by buchanmilne (subscriber, #42315) [Link] That's quite unfair to Java developers, because most of well-behaved Java projects now use Mavenized builds which utilize an explicit dependency tracking. With the central repository ( http://repo2.maven.org/maven2/ ) for most of artifacts. As quite an experienced software packager, I tried to package a Java application which uses Maven. In 2 hours of figthing, I could not get Maven to *not* dynamically check for newer Java and/or Maven dependencies, even if the dependencies were already satisfied on the system. This means, it will be impossible to get the software through a well-architected (meaning, repeatable without any external factors) package building system (such as the ones that Fedora, Mandriva, and OpenSUSE use). So, I gave up, and used an alternative application. It is quite apparent that Maven focuses on developer priorities (IOW, making it easy to build a big ugly compiled mess you can put in a tarball) and not about a clean build process that allows re-using existing software on systems with multiple java applications.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 20:50 UTC (Wed) by oblio (guest, #33465) [Link]
If you already have everything locally, mvn --help is close, and it says:
-o,--offline Work offline -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins
Using -o turns off any updating. So there's your problem solved right there.
I work daily with this stuff, it has a certain purpose. Enterprise build system, for Java applications. Nothing more, nothing less. It's definitely not going to replace RPM or DEB, which are mostly user/admin oriented package managers. Maven is oriented much more toward builds.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:14 UTC (Thu) by motk (subscriber, #51120) [Link]
That's not the point - you wouldn't reasonably use maven as a package manager for a system. The ideal use case would be for, say, rpmbuild to get a tarball, point it at a suitable maven environment, and then package the resulting fileset.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 7:24 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Enterprise build system? Not
Enterprises have proxies that gate access to the internet. Guess what happens when you drop Internet-happy maven inside their gated Network? It takes about 1 hour before someone asks to remove this hobbyist tool that thinks the Internet is free for use and replace it with real "Enterprise" tools.
maven works for Apache developers that do not like Linux developers and have a faint notion of Enterprise needs. Put it in anyone else's hand and he'll complain at you about the inadequacy of the thing.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 13:18 UTC (Thu) by oblio (guest, #33465) [Link]
Not sure what this reply is about. The fact that Maven gets stuff from the internet or that its proxy support is poor?
If it's:
It does have inadequacies, like the XML config syndrome, the complexity of its configuration, it's lack of proper support for OSGi.
Could you please present a real "enterprise build system" for Java? Just curious ;)
PS: The fact that the system can be abused and that Maven allows artefacts to specify dependencies on random servers on the internet is part of the "rope to hang effect". Some people need more rope, some people don't need any :)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 1, 2009 20:30 UTC (Tue) by joey (subscriber, #328) [Link]
Is chromium in any linux distrubution yet? spot's list certianly applies
to getting it into Debian and I think Ubuntu as well.
Even v8 has some non-free bits that can luckily be easily ripped out
Re using other webkit browser: I'm much happier with chromium on my
Whatever one's opinion of chromium, there is clearly going to be
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 5:12 UTC (Wed) by tetromino (subscriber, #33846) [Link]
Naturally, Chromium is already in Gentoo, both in the traditional build-from-source and the prebuilt binary versions. See http://packages.gentoo.org/package/www-client/chromium and http://packages.gentoo.org/package/www-client/chromium-bin
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 21:27 UTC (Wed) by rich0 (guest, #55509) [Link]
Yup, and this article explained why the source package is 150M. I looked at
it and almost all of the data is in a third_party directory, which looks like nothing but a bunch of other libs that are bundled.
I can't wait to see how many security updates this leads to down the road...
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 4:49 UTC (Thu) by motk (subscriber, #51120) [Link]
Why, you can just rebuild it, chuck it through some smoketests and then get your 'updater' app (one of the brazillions of updater apps you'll have by now) to do a bsdiff/xdelta on list of binaries. What could possibly go wrong?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 7:39 UTC (Wed) by jwb (guest, #15467) [Link]
There's a PPA for Ubuntu.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 1, 2009 20:48 UTC (Tue) by robert_s (subscriber, #42402) [Link]
I'm afraid I gave up expecting Chromium to be an example of good engineering when I first heard they'd built the UI in win32 widgets.
And now I think I'm right in saying they use GTK for their X11 interface. For a C++ application that inherits Qt design methodology.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 1:31 UTC (Wed) by SEJeff (subscriber, #51588) [Link]
What are you talking about? chromium and chrome use Skia[1] not gtk or win32.
Please don't spread nonsense if you are misinformed.
[1] http://www.atoker.com/blog/2008/09/06/skia-graphics-libra...
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 2:34 UTC (Wed) by Sho (subscriber, #8956) [Link]
While Google uses Skia as their backend for WebKit, and presumably for parts of the UI, parts like the menus, settings dialogs and so on do use GTK+.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 14:08 UTC (Wed) by drag (subscriber, #31333) [Link] Yeah.Chrome on Linux is definitely a GTK application. from: http://groups.google.com/group/chromium- dev/browse_thread/thread/d86faf0eff41b998/5e74522ae540adcd? lnk=gst&q=Why+is+Linux+Chrome+so+fast%3F#5e74522ae540adcd Off the top of my head, the tabstrip and the floating bookmark bar are the only pieces of the linux UI drawn with skia. And using GTK was one of the smarter moves on Google's part with the Linux port.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 1, 2009 21:20 UTC (Tue) by rfunk (subscriber, #4054) [Link]
Just as another data point: I've been using Chromium (from the nightly-build
PPA) on 64-bit Kubuntu for months, and by now it has become my primary browser. (Despite the annoying and ugly GTK toolkit.)
I was a longtime Konqueror fan, but that hasn't kept up with the reality of
I still keep Firefox around for the occasional chromium breakage, but it
So thanks to those behind the Ubuntu Chromium nightly-build PPA!
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 15:12 UTC (Wed) by MarkWilliamson (guest, #30166) [Link]
I'm posting this from rekonq 0.3. WebKit-based, KDE integrated, the KDE web shortcuts I always
missed from Konqueror work. It feels nice and the UI is quite slick, though it's still got some visual glitches. Stable so far, though.
One thing I will probably miss from Chrome is the ease with which I can kill Flash when it's
Compared to Firefox, rekonq has a much more space conserving UI, Compared to Chrome it
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 17:25 UTC (Wed) by drag (subscriber, #31333) [Link]
Chrome's use of windows decorations is configurable.
Click the wrench thingy --> Option --> Personal Stuff --> "Use System title
Probably won't solve most of your problems, but it's a option I prefer to
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:26 UTC (Wed) by MarkWilliamson (guest, #30166) [Link]
Thanks - I had found that option somewhere but it didn't work for me the first time I tried it with KWin;
it just made Chrome's titlebar disappear. I've just tried it again and restarted Chrome - that did work. That could equally be a KWin bug :-/
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 19:13 UTC (Wed) by martine (guest, #59979) [Link]
It is a kwin bug. We (the Chrome team) contributed a fix for it:
https://bugs.kde.org/show_bug.cgi?id=201523 So it is fixed upstream, but we have to wait until users like you get the fix distributed to them. We get this bug reported pretty frequently. :(
(If only we had bundled our own "fork" of kwin in Chrome that included this
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 19:52 UTC (Wed) by MarkWilliamson (guest, #30166) [Link]
Ah! Thanks for that. I did actually test restarting Chrome earlier so that
partly I could double check that I wasn't maligning Chrome's handling of window borders unfairly... Turns out I was, sorry :-(
Thank you for contributing the fix upstream, I will look forward to seeing
Please keep up the good work ;-)
Cheers!
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 0:25 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]
I wouldn't mind Chrome drawing its own window borders & title bar if it had a mechanism for recognizing and emulating my custom title bar button order. I have my close button on the left and minimize/maximize on the right and the default border chromium draws is the broken design of having all three buttons right next to each other, so needless to say until I activated the system window borders, I had many instances of unintentionally closed windows....
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 1, 2009 21:38 UTC (Tue) by leoc (subscriber, #39773) [Link]
Does Chromium support anything like NoScript? I love the speed (using this build on F10), but I find internet browsing to be extremely aggravating when I surf without NoScript so I usually switch back to Firefox after a short time.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 1, 2009 21:49 UTC (Tue) by ncm (subscriber, #165) [Link]
I keep Chrome open to look at some less-annoying pages, particularly those that involve "next" buttons. Such pages in firefox use up may swap space at a terrifying rate, but cause no problem in Chrome.
Firefox is amusing in that if I leave it untouched for a week, when I come back it has doubled its memory footprint.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 7:24 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
(So the answer is "no - there isn't").
If I wanted a trollish reply, I would say that I keep NoScript to know when a certain site sends my data to Google (and also wastes my time with that).
Not yet, adsweep is about the closest. Posted Dec 2, 2009 12:20 UTC (Wed) by gmatht (subscriber, #58961) [Link]
In the last fortnight (Nov 24, 2009) Giorgio Maone said that "Chrome's
extension API is currently too much limited to support even NoScript's core feature." but that he's "still keeping an eye on its future developments.". -- http://forums.informaction.com/viewtopic.php?f=10&t=1676
Additionally, he has been "contacted by the Google Chrome engineers who are
* http://www.mychromeaddons.com/chrome-addon-adsweep-a-chro...
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 1, 2009 23:59 UTC (Tue) by sharms (subscriber, #57357) [Link]
It's amazing how many people have negative opinions on what other people
are doing, yet are doing so little / nothing themselves.
Creators have little time to bicker.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 0:31 UTC (Wed) by motk (subscriber, #51120) [Link]
Are you seriously saying that spot is not a 'creator'? Seriously?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 5:20 UTC (Wed) by mattdm (subscriber, #18) [Link]
Yeah, that's by far one of the silliest comments I've seen on LWN.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 1:08 UTC (Wed) by sbergman27 (guest, #10767) [Link]
He'll come around once he sees that the distro he represents will be left behind if he doesn't.
Or someone else will step in if he proves to be too stubborn.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 2:04 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Considering that no distribution seems to be including Chromium for the same set of problems, you are just engaged in wishful thinking. Upstream is well aware of these problems and tracking these issues.
Not saying it's right, but.. Posted Dec 2, 2009 1:03 UTC (Wed) by dw (subscriber, #12017) [Link]
..the only people I ever hear complaining about bundled libs are people packaging free software. At the same time, these are the same people who layer other peoples' codebases with unreviewed patches that end up installed on peoples' desktops labelled with the same name as the 'official' tree, often with comedic effect (e.g. in the Debian OpenSSL fiasco).
Going from my reading of LWN, Fedora is one pot that should not be calling other kettles black in the release engineering department, especially when those other projects are likely to have much better infrastructure in place for dealing with things like security bugs in highly exposed software.
But fork the tree all you like, layer it with unofficial patches to use the 'system libs', feel free to create yourself an entirely unique self-supported attack surface and force it upon your users, all because you know just enough about shared libraries and how they're supposed to be Good(tm) to shoot yourself in the foot.
Not saying it's right, but.. Posted Dec 2, 2009 2:37 UTC (Wed) by joey (subscriber, #328) [Link] Go read this and come back. I'll wait.So, which do you prefer, evil stupid linux distibutions messing about with shared libraries, or holes in zlib remaining exploitable for years because hundreds of packages embed their own copy?
Not saying it's right, but.. Posted Dec 2, 2009 3:01 UTC (Wed) by dw (subscriber, #12017) [Link]
Right, but I don't count many of those as equipped with a security team able to act quickly. As I alluded to, I trust Goog to respond faster and more maturely to security holes in a heavily exposed application like Chrome than I'd ever trust any distribution.
In principle it's good to have as little as possible duplication of code within a distribution, but turning this into a hard rule is just stupid. Perhaps we should patch forked zlib out of the Linux kernel, since it might have vulnerabilities too? Of course doing so would be stupid, both because the kernel team are (mostly) very on the ball w.r.t. security issues, and also, out of sheer practicality.. the effort and hoops involved, if not impossible, would be ridiculous and probably lead to problems all of their own.
I'd rather have a non-crashy browser supported by a proven security team, with code I can fetch easily from chromium.org rather than tucked away in some .diffs somewhere on redhat.com, that doesn't suffer a performance hit compared to official builds because it depends on some shared libs a bunch of smelly nerds update whenever they feel like it, than one that follows some rule to the letter and ends up suffering from such problems.
Not saying it's right, but.. Posted Dec 2, 2009 3:19 UTC (Wed) by dw (subscriber, #12017) [Link]
Hate to reply to my own comment, but perhaps a little more insight:
I guess this comes down to ones' notion of package purity, for me the purity is in whether bytes reaching the instruction decoder on my CPU are the very same bytes the original engineer intended, and the memory layout isn't randomly changing because of some extra field appearing in some struct in say, the system libpng. Too often I think the regressive boxes-and-arrows notion of purity is more damaging than it is good. This is just one example. I'm all for having those libraries live in chromium.org's RCS if it guarantees a working, stable, predictable product at the end of the day.
Also, some of the examples in that list are just ridiculous. Oh noes, your 'fork' of ConfigParser.py is a security risk! You must depend on a version of Python recent enough to have this in its standard library, otherwise no packages for you. And if any existing environment has code running just fine on Python 0.0001 and has done for 100 years, to hell with you, this is a change required for security and stability!
It's just ass-backwards.
Not saying it's right, but.. Posted Dec 2, 2009 3:31 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
"I'm all for having those libraries live in chromium.org's RCS if it guarantees a working, stable, predictable product at the end of the day."
The problem is not that. The problem is that Chromimum doesn't have a *option* of building against the system copies instead of its own bundled versions and bundling doesn't guarantee stability or predictability. Far from it.
Build and participation Posted Dec 2, 2009 15:38 UTC (Wed) by dmarti (subscriber, #11625) [Link] A straightforward, reasonably fast build (using system libraries where possible) is an invitation to participation. A tweaky build, or a build that takes a long time because every user has to rebuild a fresh copy of lib*, is a KEEP OUT sign. After all, what if you report a bug, and they ask you to pull the latest version to test a fix, or apply a patch, or bisect?
Not saying it's right, but.. Posted Dec 2, 2009 10:55 UTC (Wed) by epa (subscriber, #39769) [Link]
Tom C's blog is not saying that you can't run Chromium (or Chrome) on Fedora; it just outlines the difficulties in packaging it to comply with the Fedora guidelines. Those guidelines (or 'package purity') don't prevent you from downloading Google's build of their browser and installing it, perhaps even by adding Google's repository to your yum sources list. However, part of the raison d'etre of Fedora (and other Linux distributions) is to have software packaged in a standard way; if it's more important to keep the vanilla upstream 'product' for each application then perhaps Fedora is not the distribution to choose.
I think the Fedora people have enough experience with building and maintaining a large distribution that I trust them when they say bundled libraries create a real (rather than purely theoretical) maintenance burden.
There is something to be said for having the exact same binary blob running on your system as the upstream project supplied, and the same as most other users are running. It does in some ways narrow the range of problems and bugs that can occur. It has been suggested before (I remember the Linux Hater advocating the same thing) but for whatever reason it isn't a popular way of doing things in the free software world.
Not saying it's right, but.. Posted Dec 2, 2009 21:26 UTC (Wed) by nevyn (subscriber, #33129) [Link]
> As I alluded to, I trust Goog to respond faster and more maturely to
> security holes in a heavily exposed application like Chrome than I'd ever > trust any distribution.
How? By having their own updater? That's fine, they can release a giant blob
But IMNSHO, if "yum --security update" doesn't update all security errata
And before you want to say you think Google will produce a better repos. and
Not saying it's right, but.. Posted Dec 2, 2009 5:52 UTC (Wed) by sjlyall (subscriber, #4151) [Link]
A fun one I've is when (usually java) apps embed the timezone data files (along with their other libraries).
So when the government decides to change the daylight saving date the OS/distribution will be fixed but come the change you find your app is still one hour out.
Not saying it's right, but.. Posted Dec 4, 2009 18:12 UTC (Fri) by alankila (subscriber, #47141) [Link]
If linux distributors want to mess with the things they package, then feel free to do so. I guess that's what they are going to do, with their guidelines and all. What irritates me is the whining that everyone else is not making your job easy for you.
Not saying it's right, but.. Posted Dec 4, 2009 18:26 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
pick your poison
developers have the right to make things hard for the distros, but if they choose to do so they don't have the right to complain that the distros don't include their program and include a competing program instead.
Not saying it's right, but.. Posted Dec 7, 2009 3:58 UTC (Mon) by alankila (subscriber, #47141) [Link]
Perhaps we just need different kind of distros.
Not saying it's right, but.. Posted Dec 7, 2009 4:16 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Are you volunteering? Talk is cheap.
Not saying it's right, but.. Posted Dec 7, 2009 14:56 UTC (Mon) by alankila (subscriber, #47141) [Link]
My trollish response was just expressing a dissatisfication that there does not seem to be such a thing as a stable linux platform. Something that contains pile of software that tries not to change for a few years, and to which you can dump large code blobs like eclipse, or chromium, or whatever, without that distro's contributors going ballistic about how everything is not done according to their guidelines.
In short, I'd like to see a linux like windows: one which is as minimal as possible and where it is an endorsed practice to install 3rd party software, and such installed software exists, will work, and will continue to work for as long as humanly possible. If such a distro does decide to package proprietary software, it acts merely as glue and distributor channel, and doesn't spend years changing/breaking any of it, or removing useful blobs of functionality, or whatever.
Why do I think this way? Because I believe the open source community is not able to write drivers for all the new hardware, is not able to write decoders for all interesting codecs out there, is not able to keep things working even if someone does write such software. Proprietary code tends to bitrot at an alarming rate, and open source code bitrots and gets depreciated as well. I have had to throw out networking cards which no longer have working drivers, no matter they were once driven by open source code. Stability would be great. Rewriting the community to respect proprietary code, and the constraints such code is written in would be even better.
Not saying it's right, but.. Posted Dec 8, 2009 11:55 UTC (Tue) by mpr22 (subscriber, #60784) [Link]
Doesn't the "pick a version of RHEL and stick with it" model basically fit the "Something that contains pile of software that tries not to change for a few years"?
Not saying it's right, but.. Posted Dec 9, 2009 14:32 UTC (Wed) by alankila (subscriber, #47141) [Link]
True, I suppose. Now if only such a thing also exposed a functional stable driver ABI for things like wlan cards and graphics drivers...
Not saying it's right, but.. Posted Dec 10, 2009 0:44 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
RHEL also has a "stable kernel ABI" essentially because it is the same base kernel with backported patches till the end of the release.
Not saying it's right, but.. Posted Dec 2, 2009 2:47 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
The reason that distributions are the ones who worry about this most is because they are the ones with a long history of experiences that guide their behaviour.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libra...
https://fedoraproject.org/wiki/Staying_close_to_upstream_...
Fedora has guidelines that cover not bundling system libraries but also one that avoids deviating from upstream. The net result is that upstream often do change their codebase to accommodate. Anything else requires special precautions from the security team and generally is a hassle.
What about firefox? Posted Dec 2, 2009 5:43 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
Firefox also duplicates a multitude of packages, for example:
[gmaxwell@sonolumen xulrunner-1.9.1]$ strings libxul.so | grep -i libTheora
(pretty sad too, because the greatly performance enhanced libtheora 1.1 was a headline feature for Fedora 12, but probably the now most common user of the library has its own copy of libtheora 1.0)
What about firefox? Posted Dec 2, 2009 7:51 UTC (Wed) by tajyrink (subscriber, #2750) [Link]
I don't think the 1.0-decoder has any problems decoding superior 1.1-encoded material. Though indeed there may have been decoding performance improvements as well, but I think the main improvement was that 1.1 makes more sensible data which also decodes better (and with better quality).
What about firefox? Posted Dec 2, 2009 15:16 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
Right. The 1.0 decoder decodes everything, visually identical ouput too. But the 1.1 decoder is also considerably faster— this is pretty relevant because the HTML5 video model forces software yuv->rgb conversion that takes a lot of CPU. Because of that 1.0 vs 1.1 is the difference between smooth HD playback and not on a fair number of computers. ::shrugs:: I mostly mentioned the difference so that no one would say 'it doesn't matter'.
It does, but the point is that Firefox in Fedora ships with duplicated libraries (and has had security bugfixing desync in libvorbis as a result, with Mozilla shipping with fixes ahead of the rest of Fedora).
What about firefox? Posted Dec 2, 2009 17:02 UTC (Wed) by spot (subscriber, #15640) [Link]
For what it's worth, I wasn't aware of this until you pointed it out. Do you know if there is an open bug here? I'm guessing that it is reasonably straightforward to fix Firefox to use the system libtheora. (I say that without having looked at all at the relevant code, so I very well could be wrong.)
What about firefox? Posted Dec 3, 2009 9:28 UTC (Thu) by glandium (subscriber, #46059) [Link]
The problem is that they have added APIs in liboggz and liboggplay, used to better seek in ogg streams, avoiding the ugly rendering when seeking between 2 key frames. They also have a bunch of non upstreamed fixes.
I sent a list of the patches applied on the Firefox 3.5 branch to the relevant persons, and hopefully the patches will be applied upstream.
What about firefox? Posted Dec 3, 2009 10:37 UTC (Thu) by nix (subscriber, #2304) [Link]
More disturbing is that they patched libpng with APIs that were rejected upstream and subsequently decided that the right thing to do was to carry along their own fork forever... and have you seen how *many* libpng security-fix releases there have been in the last few years? Are you sure FF got all of them? I'm not. And exploits via hostile PNGs that buffer-overrun image-handling libraries have been reported (though admittedly only on Windows), so this is not academic.
What about firefox? Posted Dec 3, 2009 15:45 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
I specifically mentioned libtheora because I know there aren't any non-upstreamed fixes.
What about firefox? Posted Dec 2, 2009 11:23 UTC (Wed) by pabs (subscriber, #43278) [Link]
Added this to Debian's embedded-code-copies file, thanks.
Needless Forks Posted Dec 2, 2009 12:14 UTC (Wed) by pboddie (subscriber, #50784) [Link]
Usually, the argument against forking software projects, or rather the argument for working as closely as possible with the upstream source, is that it can be costly to take advantage of upstream development work (to incorporate security updates and fixes, for example) if you've veered off and started doing your own thing. For any development team who doesn't have the luxury of dedicating time and people to maintaining a proper fork of a project, particularly in corporate environments where costs are under scrutiny, there is an incentive to collaborate with the upstream project, even if it means persuading the company lawyers.
However, for development teams with enough resources to outrun upstream projects - to develop their own stuff and to see specific benefits faster than waiting for such things to appear upstream, if ever - it becomes tempting to fork the code and ignore the community. With Google, it would seem that money isn't so much of a concern that they can't just fork more or less everything, presumably justifying the "special" nature of their stuff to management who don't mind getting the chequebook out.
(Of course, the frugal kind of behaviour doesn't punish projects - people genuinely collaborate for everybody's benefit - but the latter, free-spending kind of behaviour can be particularly damaging to permissively-licensed projects (as compared to, say, copyleft-licensed projects) because a wealthy, motivated organisation can start offering something which tempts people away from the original source of the software, and by adding proprietary licensing terms, they can effectively undermine that other work.)
Needless Forks Posted Dec 8, 2009 17:14 UTC (Tue) by marcH (subscriber, #57642) [Link]
> However, for development teams with enough resources to outrun upstream projects - to develop their own stuff and to see specific benefits faster than waiting for such things to appear upstream, if ever - it becomes tempting to fork the code and ignore the community.
And it is also tempting since it also isolates you from the opposite problem: inconsiderate upgrades causing regressions and lack of backward compatibility. Honestly, which distribution cares about backward compatibility from one release to another? Just for fun compare with Windows. Or even worse, think about Fedora who keeps issuing hundreds of non-security upgrades after the release. And this not just on the latest release but even for older "releases".
I realize backward compatibility is expensive while most Linux distributions are free. But still: if you do not care about external developers then you cannot ask them to behave and not fork.
(RedHat is off topic here since we are talking about a web browser)
Needless Forks Posted Dec 9, 2009 9:56 UTC (Wed) by mpr22 (subscriber, #60784) [Link]
It's amusing that you mention Windows on the backwards-compatibility score, when just about every Windows application I've ever installed appears to follow the "big ball of binary blobs" approach.
Needless Forks Posted Dec 10, 2009 0:16 UTC (Thu) by marcH (subscriber, #57642) [Link]
Even on an underlying OS that actually cares about stability you can still find some independent developers doing "the wrong thing". So guess how much chance there is of independent developers ever relying on system librairies provided by Linux distributions which do not care about stability at all? None.
Needless Forks Posted Dec 10, 2009 0:49 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Yet, that is what is happening a lot more than before. The problem is not that distributions do not care about it (although the level will vary) but a lot of upstream projects have historically ignored this problem. Projects like GTK have been exceptions. A lot of base platform libraries are adopting a saner model (as defined in http://www106.pair.com/rhp/parallel.html) over time and distributions will naturally inherit this trait. The alternative is just sticking to a base version and backporting which has its own tradeoffs.
|
|
||||||||||||
