How kernel development goes wrong and why you should be a part of it anyway

Share

by Jonathan Corbet The Linux kernel is at the core of any Linux system; the performance and capabilities of the kernel will, in the end, place an upper bound on what the system as a whole can do. The Linux kernel is at the core of any Linux system; the performance and capabilities of the kernel will, in the end, place an upper bound on what the system as a whole can do. This talk will review recent events in the kernel development community, discuss the current state of the kernel and the challenges it faces, and look forward to how the kernel may address those challenges. Attendees of any technical ability should gain a better understanding of how the kernel got to its current state and what can be expected in the near future.FOSDEM (Free and Open Source Development European Meeting) is a European event centered around Free and Open Source software development. It is aimed at developers and all interested in the Free and Open Source news in the world. Its goals are to enable developers to meet and to promote the awareness and use of free and open source software. More info at fosdem.org

6 Responses to “How kernel development goes wrong and why you should be a part of it anyway” »

  1. Comment by moveaxebx — January 16, 2012 @ 7:05 pm

    @Salemboot
    Reiser is dead.
    Con’s scheduler works good only on desktops.
    Ext4 shouldn’t be considered FS for production environment…at least until they introduce “bigger” block size and other features.

  2. Comment by Garegin — January 16, 2012 @ 7:56 pm

    @Salemboot your talking about the kernel, propably the most stable piece of software in the linux stack. the rest is mostly alpha quality cack compared to windows, osx or other nixes. if finder was as buggy as nautilus there would have been mobs of people with firetorches.

  3. Comment by Salemboot — January 16, 2012 @ 7:59 pm

    Intel was allowed to make massive changes graphics stack: regressions.
    The changes made to Reiser3 to remove the Big Lock hurt performance.
    Con’s scheduler used round-robin for allotment of resources to processes. CFS caused major regressions compared to O(1). Hence why Google removes Ingo’s code in favor of O(1).
    Ext4 has huge regressions with various tests run by Phoronix.
    In the real world, stable stays untouched, feature complete. Company can’t afford breaks. Takes Millions to fix.

  4. Comment by shaurz — January 16, 2012 @ 8:49 pm

    @moveaxebx It was just a rumour I heard on reddit. I am hoping to switch from ext4 to btrfs in the future when it is mature.

  5. Comment by moveaxebx — January 16, 2012 @ 9:21 pm

    @shaurz
    Dead? Far from that. Check out btrfs mailing lists.

  6. Comment by shaurz — January 16, 2012 @ 9:57 pm

    I though btrfs was dead? I’m glad to hear it’s still being worked on.

RSS feed for comments on this post. TrackBack URI

Leave a comment