Kees Cook: yay for barriers
The bug was, from my perspective, a serious issue. Since I'd managed to reproduce it in another distro, it was my duty as a Free Software developer to report it to them. And, in what I felt was an unambiguous gesture, I made sure to include the link to the upstream kernel bug. Reproducing it in Ubuntu, in Fedora, and with a stock kernel had me confident that it was an upstream issue. While Ted did correctly suspect the issue was upstream, I really didn't want to just open an upstream bug and have it be ignored. I wanted some additional proof of reproduction, which I got when I tested it on Fedora."
Posted May 18, 2010 2:30 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (55 responses)
Posted May 18, 2010 3:27 UTC (Tue)
by ajross (guest, #4563)
[Link] (42 responses)
Posted May 18, 2010 4:38 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (40 responses)
The whole affair is extremely juvenile. But in any case, "high powered filesystem developers" or not, I decided years ago that I'd only ever give Red Hat / Fedora another try if they based themselves off Debian, as all sane distros do. Serious kernel bugs are rare (yes, RH and others deserve some credit for employing some of the developers that ensure this, but in my opinion most of the credit goes to Linus). Meanwhile, broken upgrades are common and annoying, and I'm glad Debian and its derivatives have nearly solved that problem, and am baffled that the solution has not been adopted.
It's ok if Ubuntu doesn't do kernel work. Userspace work is equally important.
Posted May 18, 2010 4:54 UTC (Tue)
by jwb (guest, #15467)
[Link] (14 responses)
As an aside, the willingness to believe that a bug does not exist in one's favorite distro is widespread in the Ubuntu project, too. It seems like they go through Launchpad every six months and set every bug to the Incomplete state, even if there's no evidence whatsoever that the bug was fixed, and even if he bug report contains complete instructions for reproducing it.
Posted May 18, 2010 11:15 UTC (Tue)
by kragil (guest, #34373)
[Link] (13 responses)
Posted May 18, 2010 11:50 UTC (Tue)
by nye (subscriber, #51576)
[Link] (10 responses)
Why? Why does some unflattering comment in an LWN thread make 'Fedora guys look like complete über-assholes'? The actual bugzilla entry doesn't contain any of this mudslinging that everyone's so unhappy about; it all happened here on LWN.
And in fact, the most negative comments I could even find looked like these (from different posters):
Those don't even get into my top thousand list of offensive LWN comments.
Posted May 18, 2010 12:32 UTC (Tue)
by seyman (subscriber, #1172)
[Link] (7 responses)
I believe that the OP is referring to the comments from Theodore T'so that this discussion snowballed out from.
Posted May 18, 2010 12:40 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (5 responses)
When a upstream bug report was filed, the Fedora maintainer was aware of the problem. A comment on the upstream bug report would have been enough to notify the maintainer. When a downstream bug report was filed, it was closed against the upstream report in Fedora. Meanwhile a fix was pushed to Fedora 13 as an update. As simple as that.
Posted May 18, 2010 21:16 UTC (Tue)
by mcornils (guest, #50906)
[Link] (1 responses)
I firmly believe this is the way to go - and I did so before: without being paid by any distro, I have still done the same thing as Kees - I found a bug upstream, verified on two distros (even installing one) and reported on those two bug trackers, with a link to the upstream report. Users can then profit from all the advantages mentioned above. If this behavior was incorrect, I would really like to know (and be told by the bug submission guidelines).
Posted May 18, 2010 21:20 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 20, 2010 12:46 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (2 responses)
http://airlied.livejournal.com/72817.html, and it _makes_ him look like an a**hole when one learns about the whole story.
FTR: I use neither RHEL, Fedora, nor Ubuntu on my company or personal systems, and I'm not involved with Linux development on that layer. (My OSS contribution is TeX software development since 1982.) So I don't consider myself biased.
Posted May 20, 2010 20:49 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
It's just generally about the sub-surface tensions that can arise when multiple commercial organisations have to co-operate on some large, shared code-base. The question is how it should be addressed (if at all)?
Posted May 20, 2010 21:35 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
I would never judge a guy only singly a blog entry, but I can judge a blog entry. That's why I wrote "it makes him look like" and not "he is". I don't know how it is and what the tensions are that made him post this really distateful blog entry. Thus, I judge the blog entry and not the guy.
And I have to say that the RH guy (who's name I have forgotten) who made the snide remark in RH's bugzilla entry reacted great: He came forward and apologized in Kees' blog for jumping to wrong conclusion. That's the professional way to address it.
And here I come to your question: IMNSHO, there is no silver bullet that makes us handle these situations in all cases or even prevent them. The whole point is how we handle them *when* (not if) they happen. Then the principals in such a conceived conflict must step back and revisit their positions. (As Kees did in his comment to his own blog as well, btw. I was very impressed by that, that's seldom.)
This is not a new thing. I was active in the late-80s in X server development, when the switch from X10 to X11 happened. This was very much dominated by commercial players at this time, the Unix turf wars were going on. Snide remarks about each other's company abounded. XFree86 was a very small player then. Well, my 30 years of involvement in free software has teached me that improvements of flame wars' aftermath handling is much more important than mailing list's code of conducts or such in the first place. Normally, you don't loose contributors by flame wars, they Just Happen(tm). We loose them if tensions are allowed to be continued on a personal level and we need to speak up against that as a community if it happens continually.
FWIW, my 0.02 EUR
Joachim
PS: Not that I consider this a flame war, it's more a storm in the teapot. r.a.sf-lovers split, *that* was a flame war... :-) :-) :-)
Posted May 19, 2010 9:15 UTC (Wed)
by AndreE (guest, #60148)
[Link]
Posted May 20, 2010 12:42 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (1 responses)
Probably it's more something like http://airlied.livejournal.com/72817.html, and AFAICS Dave Arilie is a RH employee.
Posted May 20, 2010 15:39 UTC (Thu)
by nye (subscriber, #51576)
[Link]
Kees did, in the very post this article is about. It's the topic in question.
Posted May 18, 2010 12:23 UTC (Tue)
by seyman (subscriber, #1172)
[Link] (1 responses)
I believe almost everybody hates upstream bugs being filed in Fedora's bugzilla.
* Upstreams prefer them to be filed in their own bug tracker.
Posted May 18, 2010 21:32 UTC (Tue)
by jrn (subscriber, #64214)
[Link]
https://wiki.ubuntu.com/Bugs/Responses#A%20bug%20that%20s...
Posted May 18, 2010 7:24 UTC (Tue)
by seyman (subscriber, #1172)
[Link] (2 responses)
Fedora does try to fix such bugs but they do it as part of upstream. It is a huge waste of time and energy to try to fix a bug in two different bug trackers.
Posted May 19, 2010 11:00 UTC (Wed)
by jond (subscriber, #37669)
[Link] (1 responses)
Also a bug might be an upstream issue but only triggered in a distribution due to an interaction with another component.
I disagree that it is a waste of time to track a bug in two places. It makes sense to *fix* it upstream, if that's where it occurs, and for that fix to trickle down into the distro as part of packaging more recent updates. But again, that's all the packagers job, not the users.
Posted May 19, 2010 13:25 UTC (Wed)
by zooko (guest, #2589)
[Link]
Here is a recent example: there was a bug in binutils and... well, it would take a while to type in the whole story, but you can see from this launchpad page that it would be a pain in the neck to keep track of this issue across all the open source projects that it touches just by bouncing back and forth among all their trackers:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/4...
Note that this issue -- 461303 -- affects Fedora, Ubuntu, and an upstream just like the issue that is the subject of this LWN.net story does. I don't think that there is a launchpad ticket for that latter issue. If there were I could tell at a glance which distros have this bug and which releases have fixed it and how they did so...
Posted May 18, 2010 7:46 UTC (Tue)
by ncm (guest, #165)
[Link]
Posted May 18, 2010 7:49 UTC (Tue)
by renox (guest, #23785)
[Link] (2 responses)
Sane? I remember a certain patch which impacted OpenSSL security AFAIK this patch wasn't sent upstream at the same time it was applied to Debian..
I'm not sure that things have changed.. Not a very good policy especially for such critical component.
Posted May 18, 2010 8:17 UTC (Tue)
by mbanck (subscriber, #9035)
[Link] (1 responses)
Still a big fuckup on Debian's part, of course, but upstream wasn't totally innocent.
Michael
Posted May 18, 2010 10:40 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link]
Someone spotted a genuine bug (well, poorly written code, it used uninitialised memory but not for anything important) involving a single line of code.
A patch to this line was posted to an upstream discussion without much context, and some vague grunts of approval were among the replies along with dismissal of the problem as irrelevant (guess OpenSSL's developers aren't big valgrind users)
Debian applied this change in two places. The afore-mentioned bug, and a nearby line of code which was textually identical (or very nearly) but not a bug at all, and instead critical to the security of the system but in a subtle way that wasn't picked up by regression tests.
As is usual with terrible mistakes, there were several failures, some causal, some contributory and others merely coincidental. But they were failures, and all of them are worth some effort to correct/ prevent. People make mistakes, our best hope is to design systems that reduce the severity of the consequences of mistakes.
Posted May 18, 2010 9:24 UTC (Tue)
by epa (subscriber, #39769)
[Link] (17 responses)
Posted May 18, 2010 9:38 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (16 responses)
Posted May 18, 2010 9:48 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (12 responses)
Posted May 18, 2010 16:44 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (11 responses)
Sorry for being slightly off-topic here, but how well does upgrading from one version of Fedora to the next work without doing a re-install, as compared to Debian or Ubuntu? The Fedora documentation seems to rather discourage it.
Posted May 18, 2010 16:53 UTC (Tue)
by zeekec (subscriber, #2414)
[Link]
Posted May 18, 2010 16:54 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
Other than that, it works fine. I have machines that go back to RHL days and have been upgraded all the way through to the most recent Fedora.
Posted May 18, 2010 17:27 UTC (Tue)
by cry_regarder (subscriber, #50545)
[Link] (1 responses)
Cry
Posted May 18, 2010 20:07 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link]
Current versions of Fedora bring a special package called preupgrade which sets up a painless upgrade (details for Fedora 12 upgrade). I haven't tried it (my last upgrade was a fresh install on a new machine, now 64 bits).
Posted May 18, 2010 16:58 UTC (Tue)
by cry_regarder (subscriber, #50545)
[Link] (1 responses)
Cry
Posted May 19, 2010 11:24 UTC (Wed)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link]
Posted May 18, 2010 18:37 UTC (Tue)
by ewan (guest, #5533)
[Link] (4 responses)
That helps to avoid some of the difficulties that live upgrades can encounter (even on Debian) but still gives most of the advantages.
Posted May 18, 2010 19:17 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (3 responses)
That answers my question rather well. The most important point for me there is that the result of the upgrade is the same as a Debian-style upgrade and not like a clean install. That was not quite clear to me from skimming the Fedora documentation, and seemed, shall we say, rather surprising to me.
How much of the upgrade requires taking the system offline? Can the new system be built up while the old one is running and (more or less) just restarted into once the upgrade is done?
Posted May 18, 2010 19:36 UTC (Tue)
by paulj (subscriber, #341)
[Link]
$ rpm -qa --qf '%{RELEASE}\n' | sed -e 's/^.*[.]//' | grep ^f | sort -u
How's that? :)
Posted May 18, 2010 20:45 UTC (Tue)
by cry_regarder (subscriber, #50545)
[Link] (1 responses)
preupgrade is just like a dvd upgrade but it doesn't require you to burn media to reboot into. It does a bunch of work while the system is online, then when you are ready, you trigger the offline upgrade. In my experience, you are looking at maybe an hour offline depending on the machine and internet connection.
Cry
Posted May 19, 2010 8:07 UTC (Wed)
by michich (guest, #17902)
[Link]
There's one more difference and it's even more important: preupgrade takes post-release updates into account:
In my experience the methods to upgrade a Fedora installation ordered from the most reliable to the least reliable are: Note that I realize well that official documentation disagress with me.
Posted May 18, 2010 10:51 UTC (Tue)
by epa (subscriber, #39769)
[Link] (2 responses)
Now, a good package management system doesn't prevent breakage if the packages themselves are of poor quality. You can have automated dependency resolution using apt, yum, smart or whatever and still get problems caused by incompatible changes. Debian stable certainly has a good record of not breaking things on update, but so too does RHEL for example.
The view that Debian and its derivatives are the only distributions to have reliable, automated package installation and upgradability is at least five years out of date.
Posted May 18, 2010 15:14 UTC (Tue)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted May 18, 2010 16:43 UTC (Tue)
by jengelh (guest, #33263)
[Link]
Posted May 19, 2010 20:48 UTC (Wed)
by plougher (guest, #21620)
[Link]
Posted May 18, 2010 6:24 UTC (Tue)
by lkundrak (subscriber, #43452)
[Link] (11 responses)
By the way, Kees Cook has done awesome work for Ubuntu security response. Without exaggeration he's one of key figures in free software security. I am also aware that he's one of major contributors to the Inkscape code base, which is a rather important free software project. I'm not going to guess how does he feel reading that response. I'm just ashamed he's reading it in Fedora's bugzilla.
Posted May 18, 2010 8:15 UTC (Tue)
by AlexHudson (guest, #41828)
[Link] (7 responses)
What's really happening here is that the undercurrent of dissatisfaction with Canonical's contribution to the community has bubbled to the surface, and this was just a convenient place to vent it. Fundamentally, T'so various (snide) comments are essentially right: if Canonical purport to be an enterprise Linux vendor, they should be able to fix stuff like this themselves.
Posted May 18, 2010 9:30 UTC (Tue)
by hppnq (guest, #14462)
[Link] (6 responses)
I disagree, they are essentially utterly wrong. What the distributor should be able to do is communicate in a normal way with the developer, so that issues get solved appropriately. It seems the Fedora, Ubuntu and kernel people all agree on that. The rest is politics.
Of course there is nothing wrong with a patch that originates downstream.
Posted May 18, 2010 11:54 UTC (Tue)
by AlexHudson (guest, #41828)
[Link] (3 responses)
As for the rest being politics - I disagree, but I understand where you're coming from. A distributor could just play middle-man to resolve bugs, sure - but I don't think that's good enough for an enterprise vendor. At that level you get paid for being able to solve any problem a customer has, and that's exactly what the likes of Red Hat, Novell, and to a large extent Oracle (to name a few) are able to do.
If you're reliant on the engineering expertise of some other people, be they in another business or just in the community, it's difficult to claim that you're an enterprise vendor. It's pretty much a statement of fact.
Posted May 18, 2010 14:04 UTC (Tue)
by hppnq (guest, #14462)
[Link] (2 responses)
That is not how it works in practice. In general enterprises simply maximize profits using limited resources, which means that some problems really won't be solved, not even if you are a really Important Customer who pays an incredible amount of money.
But also in theory it is not true. If there are reasons to duplicate the effort to solve bugs in libredhat, they must be even slightly worse than having to choose between libgoogle and libcanonical. Optimally, and this is actually the whole idea behind Free Software, everyone helps a bit to solve the omnipresent problems in libwonderful, whether it is testing for bugs, reporting and tracking them, or fixing them.
Posted May 18, 2010 15:17 UTC (Tue)
by AlexHudson (guest, #41828)
[Link] (1 responses)
The whole reason big customers will pay big bucks for enterprise support is not to have some go-between who knows the relevant bug trackers to file their bugs for them. That's a totally valid model, but it's not enterprise support.
Posted May 19, 2010 7:24 UTC (Wed)
by hppnq (guest, #14462)
[Link]
You can easily verify this by just looking up on the websites of the companies you mention what exactly they mean by "enterprise support". Look at the partner programs, the training, the certifications and don't forget the small print.
Posted May 18, 2010 15:21 UTC (Tue)
by blitzkrieg3 (guest, #57873)
[Link] (1 responses)
But lets look at another "enterprise Linux" vendor. Let's assume that Kees never found the bug and no one identified the patch that caused the regression, and that the patch was merged into RHEL 6. I know from my experience at Red Hat that if some Enterprise Linux customers hit this issue later on, the first that the community (and probably Ted Tso) would ever hear of it would be on lkml, where someone (probably Sandeen) would have explained the reproducer, RCA, and patch. Then there would probably be a little discussion, followed by an ack or possibly a small rewrite.
What is striking about this bit of drama isn't the Fedora bugzilla, which wasn't wrong by any means. What is striking is Kees did the virtual equivalent of standing up and looking around the Ubuntu HQ, and couldn't find *anyone* that would be able to fix this problem. Instead, his first inclination was to ask the maintainer out of band, who was good enough to look into the issue for him and find a workaround. If you're an Enterprise Linux salesperson in the process of converting an LTS customer, you now have a pretty good sales pitch. "What if Ted isn't so gracious next time?"
Posted May 18, 2010 16:53 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
My reading of the original ticket is that an attempted fix was committed in April... but it hasn't completely solved the issue. My understanding is that LTS was still being impacted in some situations and that is what prompted Kees to open up the upstream ticket in May.
-jef
Posted May 18, 2010 8:23 UTC (Tue)
by tajyrink (subscriber, #2750)
[Link] (2 responses)
When high profile developers take juvenile stabs at other distros/communities/persons, it tells me a bit sad story about what's allowed in the community. Free software has a long history of also unfriendliness and exclusion of new people, and Ubuntu was in my opinion the only big, bright light that started a change in 2004 and onwards. I like also Fedora's new "Freedom, friends, features, first" thing, since it has also the "friends" there. And code of conduct like things have now started spreading more as well.
Posted May 18, 2010 14:04 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
Oh, come on. Each large enough community contains its share of juvenile (acting) members; each of us has acted childish from time to time (and regretted it later). Please don't generalize this one dumb remark and ensuing flamefest as the normal (or even tolerated) behavior of the many people who work on the kernel or on a distro, be this Ubuntu, Debian or Fedora.
Disclaimer: I'm a long time Fedora user, and a Fedora Ambassador.
Posted May 20, 2010 6:16 UTC (Thu)
by tajyrink (subscriber, #2750)
[Link]
I haven't recently seen any truly active Ubuntu contributors calling other distributions with names like "loldora" or such, but it probably cannot be that it wouldn't ever happen.
Posted May 18, 2010 14:19 UTC (Tue)
by blitzkrieg3 (guest, #57873)
[Link] (1 responses)
I have mixed feelings on the issue. Kees didn't really do anything wrong. Ted said that Fedora doesn't have the problem, so I think anyone's natural reaction would be to test Fedora and then, if it didn't have the problem, bisect the patches. Then he linked the upstream bug so Fedora guys essentially had no overhead in finding the fix and closing the bug.
However, the fact remains that Eric Sandeen, a Red Hat employee, did a good deal of root cause analysis on the bug. Was this bug more deserving of his attention than the 1628 other bugs for fedora+kernel that are presumably impacting fedora users? Or the bugs filed against RHEL+kernel that paying customers want fixed?
The short answer is that he would have gotten involved anyway since he's an upstream dev, and the bug was also filed against upstream. And Kees may have done a lot to help out Red Hat here, after all he did a lot of analysis and found a reproducer, which is a mundane and time consuming job. Maybe the per-bdi thread flush patch is in RHEL 6, and Red Hat wouldn't have caught it until after a customer hit it. Then Red Hat has to do all of Kees work anyhow, and the customer leaves with a bad taste in their mouth. Or maybe no one would have hit it in any Red Hat distro. Who knows?
The point is that Kees did the right thing, and Fedora has a right to be miffed. Not that they are, mind you. As others have pointed out, almost none of the criticism has come from Fedora devs.
Posted May 18, 2010 16:43 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
If I went to all the trouble I'd certainly let the Ubuntu maintainers know, but maybe back channel and only file it after it was clear that an active ubuntu user was going to take responsibility for the report if more information is needed. I've shared crash fix patches with Ubuntu maintainers in the past for an application project with an effectively dead upstream. Though I'm not sure if making a habit of cross-distro bug reports that don't include patches would be considered.. neighbourly. Even more so if I'm just driving by and not planning on continuing to run the distro so I can provide additional feedback as the reporter.
-jef
Posted May 18, 2010 14:42 UTC (Tue)
by ricwheeler (subscriber, #4980)
[Link] (6 responses)
I think that others have clarified that Fedora/RH developers actually did engage.
As part of the RH file system team, I think that the right way to answer users (even when they work for distros) is to help them understand how to engage effectively and leverage the community.
For ext3/4 bugs, we have a weekly ext4 call, an open IRC channel and the ext4 mailing lists. We get a lot of issues to debug and everything needs to be prioritized. You don't need to hire developers, but clearly having active developers gives you more weight in pushing for your issues.
No slight meant or intended, but a part of open source is learning how to engage and motivate others to fix your issues first for free (often on their own time!).
Posted May 19, 2010 20:39 UTC (Wed)
by plougher (guest, #21620)
[Link] (5 responses)
In other words you're advocating what many RedHat/Fedora fanboys regularly bash Canonical for doing. Surely the whole point of this thread is you can only take this so far, once you get a reputation for freeloading, you loose the goodwill of upstream developers and this winning strategy ceases to work.
As an ex-kernel maintainer for Canonical I'm no fan of Canonical, however, the whiter than white holier than thou attitude of RedHat/Fedora fanboys astonishes me. As an upstream author I have had instances where both Canonical and RedHat have "engaged" with me to fix bugs, and frankly their behaviour is identical, if anything I've had more patches from Canonical than RedHat.
Posted May 20, 2010 0:14 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
Ted's very expansive comment in the launchpad ticket commenting on Canonical's resource staffing touched off some latent frustration to be sure. But I'm pretty confident that latent frustration goes beyond the Red Hat fenceline and further even than the Fedora bleachers where I'm munching on popcorn watching the show.
If that comment from Ted wasn't there coloring the discussion would have this been an issue at all? probably not. I doubt Dave Airlie would have dropped a note in his blog about the incident. I doubt arjan would have broadcasted it to lwn. What's sensational and atypical about this situation is Ted's comment... not anything in particular that Kees has done. If you look really closely people have been reacting primarily to Ted's comment not to the handling of the bug itself.
Ted's comment even colored the response to the Fedora ticket, which has been apologized for:
And furthermore, the historic Canonical criticism over upstream contributions have come primarily from other quarters than Red Hat/Fedora.
You see more upstream patches from Canonical as an external corporate entity? Great! What codebase are you talking about exactly? I'm sure Canonical supporters would find that a refreshing change from the linux kernel development reports that lwn produces which don't rank Canonical as a significant contributor.
In fact I would love to see the sort of contribution analysis that has been used in the kernel and plumbing layers extended further up the stack. I'd love to see the extent to which corporate entities are contributing to GNOME and KDE for example or the collections of projects hosted under the freedesktop.org banner. Credit where credit is due.
-jef
Posted May 20, 2010 0:58 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
You're right though, this isn't about RedHat per se. People representing various vendors and/or projects have vented about their competition at various times. It's not that abnormal an urge. However, it's an urge that's best resisted - it doesn't look good. Worse, given we all depend on the same code base, it raises barriers between people.
There are some big questions here about how different vendors should inter-operate when each specialise in different areas, each employ maintainers of different parts of a shared software stack, and hence all are inter-dependent (to various degrees) on each other. Clearly this is raising tensions.
I wonder how those tensions could be resolved though?
Posted May 20, 2010 3:01 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
Red Hat isn't. They are up and down the stack from kernel up into user facing GNOME UI.
Novell isn't. They are up and down the stack from kernel up into user face GNOME UI.
If I were a betting man I would wager that Red Hat and Novell's relative contributions compared to other corporate entities are probably similar at every level of the software stack...up through freedesktop components into the GNOME project...as well as Apache projects as well.
What about Intel and Nokia? What about Google? What about Oracle/Sun? Are they specializing at one level of the stack are are they investing in engineering expertise at all levels? Obviously Intel and Nokia are building a common stack in MeeGo..but its an entire stack. It may diverge from GNOME and KDE...but its an entire stack from the kernel on up and both companies are contributors at multiple layers.
Who are the top ten corporate code contributors to GNOME? Who are the top ten corporate contributors at the freedesktop component level? Do you think they are significantly different than the corporate entities that are pulling the work in at the kernel level? Noone has done the analysis of contribution beyond the plumbing layer
And let me remind you...that Canonical executives specifically and repeatedly has been trying to make the argument that there should be a core around which many vendors agree to work from and then specialize out from there. These sort of statements add to the tension because its clear that Canonical isn't doing the upstream work to shape the core. Whatever they are specializing in.. its not the core components. And its not GNOME,not KDE and its not freedesktop, and it doesn't appear to be MeeGo either.
Canonical wants to sell the story that they are a design specialist up high in the stack. Great. Good for them, if you are willing to buy that story. But that doesn't imply that other vendors are also specialists..and it doesn't mean its a successful strategy for a vendor who ultimately is relying on support contract revenue for the entire integrated stack.
And even then the specialist concept rings hollow for Canonical. How much effort on behalf of ARM OEMs is Canonical putting into in-house kernel and kernel plumbing engineering? Would you say its a trivial amount? How much of that work is making its way into the upstream ARM kernel? I don't know the answer to any of those questions. I suspect its a non-trivial amount of engineering work going on there deep in the stack.
-jef
Posted May 20, 2010 2:57 UTC (Thu)
by plougher (guest, #21620)
[Link] (1 responses)
But that's slightly misinterpreting the point of my comment, my point was that all distros rely on the goodwill of upstream authors, and to repeatedly single out Canonical for this practice is disingenuous. Ted Tso criticised Canonical for immediately passing a bug upstream to him with tight time constraints, but this is no different to what Redhat and other distros regularly do with their practice to quote Ric Wheeler "engage and motivate others to fix your issues first for free (often on their own time!)".
Posted May 20, 2010 3:38 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
I don't think anyone could suggest that Red Hat isn't pulling its fair share of the upstream project engineering weight anywhere in the software stack.
I'm really not sure you can make the argument stick that Red Hat's engineering practises encourage passing along difficult bugs to developers outside the corporate fenceline when time constraints are tight. Considering the amount of involvement that Red Hat has up and down the stack. I really doubt anyone feels pressured to fix an issue for Red Hat on Red Hat's behalf on Red Hat's release timescale. Assuming that really was Ted's motivation for venting in the launchpad bug..which I can't really know for sure.
I think what Ric was trying to talk about how one specific Red Hat team tries to set prioritizes in a collaborative open fashion at the upstream project level to maximizing long term benefit to the project's goals by taking into account both vendor staffed manpower as well as volunteer manpower to get the most work done.
There's always tension between business interest and volunteer interests. I think Red Hat does a very good job of delineating the two and staffing paid manhours for the items that are critical to their business interest. So when push comes to shove...Red Hat can allocate its own manpower to solve its business problems. In this way Red Hat's engineering investments do more to serve the larger upstream project's interest than the volunteers serve Red Hat's business interest. I get the sense that with Canonical that relationship is backwards. Canonical is trying to organize as much volunteer interest to serve their business interests primarily. And that is where the frustration lies. Not with Kees specifically.. but with a engineering management practise that expects more from upstream projects than is given back.
-jef
Posted May 20, 2010 20:36 UTC (Thu)
by petegn (guest, #847)
[Link]
We will get nowhere at all unless people start pulling together for once and quit the flaming bickering all the time it serves zero use wake up
Linux should be on at least 50% of the worlds PC's by now but too much bickering and in/out fighting is not helping at all
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
>Note that Fedora has a policy that all upstream bugs should be taken care of in the upstream bug tracker. That's why bugzilla.redhat.com has an UPSTREAM resolution and that's why this bug was closed with this resolution. The only thing filing it accomplished was wasting people's time
and
>Besides which, I'm not sure that's the point - surely the problem is that Canonical is selling people contracts in which they agree to support Ubuntu, despite (apparently) not having the necessary expertise to actually do that. Would you buy a support contract from them if all they're going to do with the hard problems is file a bug with Redhat? That's an awfully expensive way to avoid having to deal with bugzilla.
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
* Package maintainers prefer to only handle packaging bugs. If they do handle bugs in the software per se, they usually do so within the upstream community so it makes sense for the bug to be in the upstream bug tracker.
* Users get annoyed because they believe developers to be passing themselves the buck and/or fear the bug will get lost in the shuffle.
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kernel bugs rare?
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Fedora version upgrade
Kees Cook: yay for barriers
updates vs re-install
If you are doing this process from FC1, I beleive (could be proved wrong) that you are still using an ext2 filesystem with a small inode size.
That will still work, but will not be optimised (very high percentage of fragmented files), mostly with Fedora's tagging of each file for selinux.
Moreover you obviously are not using ext4 and delayed allocation which may have few problems after crash, but at least do not create so many fragments.
I always do a full re-install for that reason.
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
fc10
fc7
fc8
fc9
fc11
Kees Cook: yay for barriers
Kees Cook: yay for barriers
preupgrade is just like a dvd upgrade but it doesn't require you to burn media to reboot into.
yum update in a running system (BUT one must know what he's doing and must read http://fedoraproject.org/wiki/YumUpgradeFaq!)Kees Cook: yay for barriers
Exactly. In my house we run both Fedora and Ubuntu systems, and I really don't perceive any difference: package management and dependency resolution just works.
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Fundamentally, T'so various (snide) comments are essentially right: if Canonical purport to be an enterprise Linux vendor, they should be able to fix stuff like this themselves.
Kees Cook: yay for barriers
Kees Cook: yay for barriers
At that level you get paid for being able to solve any problem a customer has, and that's exactly what the likes of Red Hat, Novell, and to a large extent Oracle (to name a few) are able to do.
Kees Cook: yay for barriers
The whole reason why customers pay for enterprise support is that they get appropriate support. Somewhere down the line, bug fixing is obviously a part of this, but there is not a single company I know that prefers the ability to be able to fix bugs in production over not running into them in the first place. Enterprises whose core business is to unmount ext4 filesystems will have their own expert, and they will get the training from IBM, who may not even be able to correctly spell "ext4".
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
No slight meant or intended, but a part of open source is learning how to engage and motivate others to fix your issues first for free (often on their own time!).
Kees Cook: yay for barriers
Kees Cook: yay for barriers
http://www.outflux.net/blog/archives/2010/05/17/yay-for-b...
It's a bit revisionist to lay this at the feet of Red Hat. The video where GKH(Novell employee) made his initial off-the-cuff remark about Canonical not contributing was actually a talk meant to shame Google into doing more upstream contributions. I find it more than a little ironic that a Google employee is now harshing on Canonical's staffing practises so publicly given that Google's less than stellar track record with regard to mainlining kernel code..cough android patches..cough. Doubly ironic that somehow Red Hat/Fedora is getting a black eye over getting suckered into reacting to an emotive display from a Google employee when Canonical and Google are ostensibly partners on ChromeOS development. Perhaps its time for GKH to ratchet up the scrutiny of Google again.
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers
Kees Cook: yay for barriers