Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
If you were using two processes then I'd cheerily blame the
scheduler. Because blaming the scheduler for WeirdShitWhichBroke
is usually correct.
-- Andrew Morton
The Red Hat Enterprise Linux 6 kernel includes numerous subsystems and enhancements from 2.6.34, as well as its predecessor versions. As a result, the Red Hat Enterprise Linux 6 kernel cannot be simply labeled as any particular upstream version. Rather, the Red Hat Enterprise Linux 6 kernel is a hybrid of the latest several kernel versions. And, as Red Hat provides regular updates over the lifecycle of the product, we expect that the Red Hat Enterprise Linux 6 kernel will incorporate selected features from future upstream kernels that have yet to be developed.
-- Red Hat Enterprise Linux Team
My problem is I'm incredibly busy at the moment, and I've
already done Ubuntu a huge favor by spending ten minutes to do a
quickie investigation. Ubuntu needs to learn that it can't rely on
upstream developers to jump through flaming hoops on short notice
before a LTS release deadline as a cost-saving mechanism to avoid
hiring their own senior kernel engineers.
-- Ted
Ts'o
Talk about high level designs rarely gets any traction, and often
goes nowhere. Give us an example implementation so there is
something concrete for us to sink our teeth into.
-- David Miller(Log in to post comments)
Quotes of the week Posted May 6, 2010 20:24 UTC (Thu) by jengelh (subscriber, #33263) [Link]
>the Red Hat Enterprise Linux 6 kernel cannot be simply labeled as any particular upstream version.
Perfect. Then, would they please remove LINUX_VERSION_CODE from their tree, or just generally _DO SOMETHING_ so that L_V_C does not represent "any particular upstream version" evermore. Note that all values >= 65875 belong to upstream anyway.
Quotes of the week Posted May 13, 2010 23:03 UTC (Thu) by jd (guest, #26381) [Link]
I'm much more interested in how they propose to include code which hasn't been developed. This takes wormhole networking to a whole new level.
Quotes of the week Posted May 14, 2010 10:34 UTC (Fri) by nix (subscriber, #2304) [Link]
To engage in some unjustified snarking, it's just a simple extension of their current habit of including code which hasn't been debugged ;))))
Quotes of the week Posted May 6, 2010 23:52 UTC (Thu) by gerdesj (subscriber, #5446) [Link]
>and I've already done Ubuntu a huge favor
As a Gentoo user I'm sure I'll probably also reap the benefits of whatever that favour was all about.
Funny how even a senior kernel developer can forget that one distro. is not the whole effort. Canonical have a very large user and developer base and hence managed to get his ear.
It is not inconceivable that Google will benefit from that work either.
Quotes of the week Posted May 7, 2010 3:46 UTC (Fri) by clugstj (subscriber, #4020) [Link]
I think his point was that the "one distro" is the one that thinks it is the "whole effort", not Ted.
Quotes of the week Posted May 7, 2010 7:41 UTC (Fri) by farnz (guest, #17727) [Link] I think you've missed the point - it's not that that work wasn't worth doing for the benefit of Linux as a whole (with the exception of Ubuntu-specific bugs, fixing a bug benefits everyone), it's that Ubuntu can't rely on upstream working to their schedule. If the bugfix is too late for 10.04 LTS, well, that's not upstream's problem, that's Ubuntu's problem. They can either delay 10.04 LTS indefinitely, until upstream fixes it, or fix it themselves. In this case, Ubuntu had found a bug in ext4 near their LTS release date, and for some reason (as yet undetermined), this affects Ubuntu far more than the other major distros. Obviously, the bug will get fixed eventually, but Ubuntu want it fixed or worked around by their release date; what Ted's saying is that if Ubuntu need that, they need their own developers in-house who can do it, and they can't rely on upstream (whose employers are setting their priorities).
Quotes of the week Posted May 7, 2010 7:48 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
Developers are, sadly, mortal and therefore have finite quantities of time. The decision making process as to how to spend that time is complicated. To a first approximation, time that you are contractually obliged to spend on your employer is good time because that earns you money to spend on other situations. Time that you're spending on improving things that don't benefit your employer are more difficult. If you do it too much during work time then you risk your employer no longer giving you money, which means you have less money to spend on cheese, wine, ice cream and houses. So you don't want to do that. If you do it too much outside work time then you risk your significant other leaving you and taking your cheese, wine, ice cream and house with them. So you don't want to do that either.
The fundamental issue is that it's difficult to ask professionals to do things unless those things provide a direct benefit to that professional. And so when someone declines to spend their free time doing work that may benefit the company they work for, the likely reason is that their company wouldn't recognise that effort but the rest of their life would hate them for it. The end result is that people will do what they have to and potentially some more because they're good people, but a refusal to do even more does not indicate that they're bad people.
Quotes of the week Posted May 7, 2010 9:23 UTC (Fri) by paulj (subscriber, #341) [Link]
+1 on this.
Do we perhaps need to re-foster a culture of Linux users buying desktop distro box-sets^W^Wsupport to help pay for things? I have a sneaking suspicion sometimes that Linux users in the aggregate might be funnelling more money towards Apple for OS-X updates than they do into Linux desktop funding...
One problem here is that of the 3 major distro producers, 2 which employ a good number of Linux developers are not really interested in accepting money from random end-users for reasonably modern desktop support.
Basically, is there a funding problem with Linux/Unix desktop development and support? Granted, we still have the former, but how long can that go on when the latter is largely unavailable? Will users get fed up running development playgrounds and hearing "you don't set my work priorities" when they complain about ongoing instability? (With apologies to a certain Linux developer - I don't mean to pick on them or criticise them here, their response simply is indicative of the reality of the funding/reward situation many important free software developers are in).
I accept I may be talking out of my arse ;) - I'm just interested to hear whether other people perceive the same or not, and I'm quite interested to hear the counter-arguments. Indeed, I wouldn't mind one bit to be re-assured that my fears above are unfounded.
Quotes of the week Posted May 7, 2010 12:00 UTC (Fri) by Klavs (subscriber, #10563) [Link]
IMHO a distro needs to do that - Red Hat did have a desktop edition, but abandoned it - so only Novell is left doing support to Desktop users on paid subscription basis.
So - all that wants support on their Desktop install - should consider SUSE/Novell Desktop edition with paid premium (or whatever they call their "we'll actually fix your problems/help you identify the source" level).
It's a very expensive thing to do - so I expect only large companies (who today, pay for Microsoft Licenses/support I guess) would be interested.
If people we're actually buying the box models from distro's - I'd expect more distro's to have kept producing them.
Quotes of the week Posted May 7, 2010 12:51 UTC (Fri) by paulj (subscriber, #341) [Link]
I didn't realise Novell did desktop support. Thanks for informing me. Seems a reasonable cost too. Note that Canonical offer support too.
I don't know much about the SuSe desktop, however it's pitched as "Enterprise". That would make me worried that it'd be like RHEL Desktop - only attractive as a desktop for a year, maybe 2, out of every decade (ala Debian stable). And that's NOT cause the desktop itself somehow magically becomes unable to do what it did from one year to the next, but instead because the general Linux desktop ecosystem - which te apps you want to use rely on - can tend to be too fast changing and interface-unstable for "enterprise" distros to be able to offer :(.
I don't think 50 or so a year is too much to ask of Linux users. Perhaps I would previously said it was too much, but I can see lots of Linux users happy to pay Apple 100+ every other year for OS-X upgrades.
If Linux/Unix desktop users forget that Free != free, if we users don't start consistently putting money into distros, then we perhaps should fear for the viability of that desktop. Particularly when proprietary OSes are not having problems getting users to invest in further development.
Quotes of the week Posted May 11, 2010 14:33 UTC (Tue) by njwhite (subscriber, #51848) [Link]
> I don't think 50 or so a year is too much to ask of Linux users.
Indeed. I'd be very happy to give that much each year. The tricky part is that I use so many disparate bits. So I'd like my amount to be split, so a little goes to the kernel folks, a little for my window manager, a little for distro infrastructure, some for GNU, and so on. But it's a lot of hassle (and often not possible) for me to manually go around and say "here's 5 kernel guys, split this how you like," etc. Things are complicated further by the fact that I have a fairly unusual setup which wouldn't be well represented by "enterprise desktop" priorities.
It's a tricky problem. I suspect there's enough money attached to the good will of the free software community that quite a few more developers could buy food from contributions.
At the moment I mostly just donate to SFLC and the FSF. But that doesn't do much to solve the paying developers in ways other than depending on the intersection of my and large companies' interests.
1000 people? Posted May 11, 2010 15:34 UTC (Tue) by dmarti (subscriber, #11625) [Link] Or we could get 1,000 people together and just hire Ted.
Quotes of the week Posted May 14, 2010 0:14 UTC (Fri) by robert_s (subscriber, #42402) [Link]
So drop $50 each year on one of those projects at random.
I've just done that. ($45 actually)
Quotes of the week Posted May 15, 2010 10:33 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]
googling opensuse box brings you to the opensuse page where you can buy the boxed version - being brought back to life recently. The company behind it supports opensuse with (part of) the revenue and is working to expand that business...
Quotes of the week Posted May 7, 2010 21:40 UTC (Fri) by mjw (subscriber, #16740) [Link]
> Red Hat did have a desktop edition, but abandoned it
Seems you can still buy it: https://www.redhat.com/apps/store/desktop/
Quotes of the week Posted May 13, 2010 9:18 UTC (Thu) by jmansion (guest, #36515) [Link]
> Talk about high level designs rarely gets any traction, and often
> goes nowhere. Give us an example implementation so there is something > concrete for us to sink our teeth into. >-- David Miller
I have to say, I would regard this as unprofessional in every workplace I've been and I personally think acceptance of this is the single worst aspect of much community development.
Quotes of the week Posted May 13, 2010 10:37 UTC (Thu) by farnz (guest, #17727) [Link] Having worked in places where high-level designs are the norm, and in workplaces where sample implementations are the norm, I disagree with you, and think this is one of the things community development gets right. My experience of talk about high-level designs that isn't quickly converted to sample code is that it leads to one of three places:
In contrast, a sample implementation demonstrates that your design can be implemented (otherwise the sample wouldn't exist). You also have the implementation experience to tell you which bits of your original design can't be implemented sanely, enabling you to adapt your design before other people go off and work against it. This is not to say that design is a bad thing, but that by the time you're bringing your design to a large group, you should have some form of implementation, so that we can see that your design is implementable, and so that where your design isn't clear, we can look at the implementation to clarify things, and you have no room to handwave away objections with "it won't ever be implemented like that". In the specific case David's talking about, the design sounded OK, until they were poked into talking about details that an implementation would include; at that point, it became clear that the driving forces behind the design were not ones the Linux kernel folk were happy to support.
Quotes of the week Posted May 13, 2010 17:51 UTC (Thu) by nix (subscriber, #2304) [Link]
Hear hear.
This is even more important when standards of some kind were being proposed, as here. The last thing we need is another C++ standard, unimplementable as specified and agonizing even when the bugs making it unimplementable were ironed out (and the feature that made it agonizing wasn't even particularly *useful* because it had never been implemented before specification; it just seemed like a good idea.)
|
|||||||||||||