Hacker News new | past | comments | ask | show | jobs | submit login
Who's Writing Linux? (ieee.org)
102 points by powerbook5300CS on Feb 3, 2014 | hide | past | favorite | 27 comments



For those wondering:

Linaro is a not-for-profit engineering organization that works on consolidating and optimizing open-source software for the ARM architecture, including the GCC toolchain, the Linux kernel, ARM power management, graphics and multimedia interfaces. It was announced at Computex in June 2010 by ARM, Freescale Semiconductor, IBM, Samsung, ST-Ericsson, and Texas Instruments in a joint press conference. It also provides aligned engineering and investment in upstream open source projects, a monthly release of tools and software and support to silicon companies in upstreaming their system-on-a-chip (SoC) support.

That makes sense why Linaro is the 5th biggest contributer. (I'd never heard of them.)


might have heard of them but ignored it, because it didn't resonate as much with you.

http://arstechnica.com/gadgets/2012/06/android-performance-b...


This is off topic, but their main content is a small fixed-width area, and their related topics flow on the right. On a large monitor, this means that the screen is dominated by related story squares, and the main story is really hard to parse.


A Spectrum editor here- yes, we know the layout is far from ideal, especially on large monitors (I'm painfully aware-my primary monitor is a 30-inch cinema display). We just had a meeting about page templates for infographics last week, so hopefully it will me much better in a couple months.


A couple months? Aren't things supposed to move quickly in the Internet age?


I had the same difficulties. I commend them on a clean and unique design, but I'm not convinced it works all that well


Surprised at how fast the LOC are increasing in Linux. Makes the possiblity of exploits and vulnerabilities being slipped in increasingly likely.

Interesting graph I found while looking up LOC for comparable projects: http://www.informationisbeautiful.net/visualizations/million...


Interesting analysis. I didn't think that by this point volunteers would have the upper hand in %.


Does Ubuntu developers count as individual contributors or does Ubuntu not help?


You can see what people using canonical email addresses are contributing[1]. If you look at the changesets you can also also see the type of changes they're upstreaming, many are simply one liners for hardware support. Hardware support is clearly valuable, but it isn't the level of contribution some other companies put in by any stretch.

1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....


Canonical doesn't contribute a whole lot back upstream.


I have to admit I haven't been following the development as I used to. Could someone in here say to which FS the article is referring to:

"The increasing size of the Linux kernel is due to the incorporation of significant new features, including a file system optimized for solid-state drives"


I suppose he is talking about F2FS which is in kernel since 3.8.


How much do these types of jobs pay?


I worked at Red Hat for about 8 years. Red Hat pays at the top of the range for pretty much every position within the company. Engineers were starting at either high 5 or low/mid 6 figures, depending on experience and skill. Some made even more, and managers got paid more.

It was a really great place to work. I can't speak for now, although I'm sure it hasn't changed much, but back then, the corporate culture was excellent, very transparent and excellent communication on all levels. The company really is built on, and lives by its ideals. I loved every minute of working there. If you want to work on Open Source, definitely the company to work at.


Red Hat, or volunteering?


Red Hat, Intel, etc. -- People whose salary is earned by developing Linux.


Is there really 17 million lines of code for the linux kernel?

(from the chart at bottom)


Approximately, yes. (looking at 3.10 because that's what the graph was looking at for 17 million lines)

((v3.10))~/linux-2.6$ wc -l `find . -type f | grep -v [.]git ` | tail -1 16956298 total

Only 15.8M of that is C header/source + assembly,

Documentation is some ~450k.

There's about 260k lines spent for the build system and other scripts.

There's another 135k spent in other tools.

Leaving ~300k in README, TODOs and other misc files.

I'd say closer to 16 million for v3.10, including build scripts and other tooling.

For comparison, v3.13, ~ 6 months later, has 17.9M lines of C and assembly.


On 3.13.1, here's a breakdown of the top sources of code (using the same naive wc -l count), listing only dirs with >500k lines:

   arch/       3.2M
      arm/        0.7M
   drivers/    9.9M
      gpu/        0.6M
      media/      0.9M
      net/        2.1M
      scsi/       0.9M
      staging/    1.1M
   include/    0.6M
   net/        0.8M 
   fs/         1.1M
   sound/      0.8M


I wonder how many of those are compiled if the target is an x86 processor.


380280 total lines of assembly, but only 38925 lines of that are in arch/x86/ (again, v3.10), so barely a 10th of it.


There's also a bunch of stuff in drivers/ that would be excluded in a typical x86 build, though it (mostly) isn't explicitly architecture-dependent. Over half of the whole kernel LOC are in the drivers directory, which includes support for all sorts of unusual devices.


Oh good point.

I was curious so I did make allmodconfig (I'm on 64-bit x86) and 'made bzImage modules' and counted lines of c/asm source with a corresponding .o file, all the header files and Makefile/Kconfig lines and got:

headers: 3011226

c/asm source: 8264404

generated .mod.c: 8414151

makefile/kconfig: 2032728

total 21722509

(Again, this is v3.10) (I also included the generated .mod.c files) https://gist.github.com/fragmede/8782876


A naïve "wc -l /.[ch]" gives ~16.5 million for my lightly patched 3.13 tree. sloccount[1] which aims to count actual LoC says ~12 million(97% C) for the same tree.

Neither are a truly accurate measure, so help yourself to a pinch of salt to go with the numbers.

1. http://www.dwheeler.com/sloccount/


Sounds about right. Keep in mind the vast majority is drivers for ludicrous amounts of hardware.


Neckbeards.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: