Hacker News

4 years ago by totorovirus

In next version of Sid Meier's Civilization there should be Linux Kernel in technology tree.

4 years ago by 1_player

Wouldn't that make it available to only one civilization?

Should be a shared Wonder all civilizations would benefit from.

4 years ago by nicklecompte

Shared wonder is a much better idea - every civilization that researches Computers tech will have operating systems, but only one gets to develop Linux (let’s say it grants a science boost to everyone who finished researching Computers, but a huge culture/diplomacy boost to the civ that actually ā€œbuiltā€ Linux).

Similar to every civ gets a library, but there’s only one Library of Alexandria, etc.

4 years ago by 1_player

That's the thing. Linux wasn't made by any one culture or country. Linux is a distributed product of the world no one can claim in good conscience. It's not Finnish, nor American, nor by Intel or by Google. It's not even Linus'. It's made by all of its contributors from all over the world.

In Civ parlance, whoever gets the Linux Kernel technology gets the same benefit as anybody else. No one is richer or better than the other civilization because of it, everybody is.

4 years ago by Waterluvian

The tech tree is researchable by everyone.

4 years ago by pletnes

Exactly - linux was built only once in real life.

4 years ago by eru

Technologies are usually available for everyone to research.

4 years ago by nicklecompte

I think they mean that when a civ researches (or ā€œbuildsā€) Linux every player in the game should have access to it (but the civ who spent the resources building Linux gets something extra).

If Linux was on the tech tree, only the civilizations who researched Linux could use it. That’s not very FOSS! Every civilization who had computers should be able to get Linux once it’s out.

4 years ago by Redoubts

Well, it could also be like the Manhattan Project. Once you do it, everyone can get nukes.

4 years ago by indy

And one of the disasters should be a craze for Bitcoin mining.

4 years ago by peterkelly

The next time you hear someone make an argument against remote work, remind them of what has been achieved in the last 30 years by the Linux kernel developers working across so many different countries and time zones.

4 years ago by wheels

So, I like working remotely, but there are many fallacies in your statement:

Distributed open source projects are obviously an example of survivorship bias: the people who thrive in them are those that work well in a distributed environment. Contributors are also usually self-motived (again, by survivorship) in a way that one wouldn't expect of rank-and-file office workers.

Also, the existence of a thing doesn't show that its genesis was an optimal path to its current state.

Additionally, large open source projects are not necessarily good at converging upon a particular goal. They do well when the goals of many individuals or small groups aggregate well. It would be very difficult to convince all of the kernel team to, e.g. optimize for mobile performance for the next two years.

Nobody contests that large things can be done by distributed teams. Usually there's contention that a particular set of employees, that work on a particular set of projects / goals can be transitioned to working that way.

4 years ago by u801e

> Distributed open source projects are obviously an example of survivorship bias: the people who thrive in them are those that work well in a distributed environment. Contributors are also usually self-motived (again, by survivorship) in a way that one wouldn't expect of rank-and-file office workers.

Couldn't the same argument be made for those who thrive in an office environment and need to be around other people to work effectively as well as those who are not self-motivated?

I guess it really depends on what the majority prefers from a worker/contributor point of view.

4 years ago by whazor

Interesting enough, the Linux kernel as a whole is growing exponentially in size but this is mainly because of new drivers being added and maintained. The base code has a linear growth. The interfaces allow driver developers to work on the kernel asynchronously, and are I think the key.

4 years ago by readams

Just imagine how much easier it would have been if they were all in the same place.

4 years ago by GoOnThenDoTell

The core devs meet up all the time at conferences

4 years ago by NieDzejkob

Perhaps I'm blind, but I can't actually see the number of commits on this page.

4 years ago by dorianmariefr

visible on the github repo https://github.com/torvalds/linux

4 years ago by gigatexal

The world is so much better off with Linux and Linus and his merry band of hackers. They do an amazing job keeping up with the sheer amount of work that goes into the kernel from everyday needs like you and me to patch sets from companies. But what I am most proud of is git. It’s not perfect but since learning its warts it’s the Swiss Army knife of awesome just like GNU find is for me on the terminal.

4 years ago by sfgweilr4f

Which files get the most commits?

Which sections of each files get more than usual commits? eg which functions?

Who wrote this particular function first? who subsequently?

How many of those include expletives? Curious minds need to know.

If I want to answer these earth shattering questions, could I just grab the entire git repo and go from there? is it that simple? is it text exportable without too much "other" scary?

4 years ago by sega_sai

Here is the top 20 files by the number of commits

  12846 MAINTAINERS
   4167 drivers/gpu/drm/i915/intel_display.c
   3330 drivers/gpu/drm/i915/i915_drv.h
   2360 drivers/gpu/drm/i915/i915_gem.c
   2328 arch/arm/Kconfig
   2118 arch/x86/kvm/x86.c
   2079 sound/pci/hda/patch_realtek.c
   2019 Makefile
   2001 fs/btrfs/inode.c
   1927 include/linux/sched.h
   1903 net/core/dev.c
   1888 drivers/gpu/drm/i915/i915_reg.h
   1824 arch/arm/boot/dts/Makefile
   1801 drivers/gpu/drm/i915/intel_pm.c
   1781 include/linux/fs.h
   1763 arch/x86/Kconfig
   1737 mm/page_alloc.c
   1643 kernel/sched.c
   1628 fs/btrfs/extent-tree.c
It's quite interesting how present intel gpus are in the list, which probably tells something about the code on them...

4 years ago by NullPrefix

>which probably tells something about the code on them...

Million ways to interpret this.

Lots of commits could mean that it was constantly improved or there was a constant stream of bugs.

A single commit could mean that it was a perfect masterpiece on first try or it was simply forgotten.

4 years ago by sdesol

Here is what I got with additional information

   commits | authors |       first_commit       |      last_commit       |                 path
  ---------+---------+--------------------------+------------------------+--------------------------------------
     12846 |    2438 | 16 years 16 days         | 00:00:00               | MAINTAINERS
      4167 |     205 | 12 years 4 mons 4 days   | 1 year 10 mons 13 days | drivers/gpu/drm/i915/intel_display.c
      3330 |     205 | 12 years 9 mons 19 days  | 2 days                 | drivers/gpu/drm/i915/i915_drv.h
      2360 |     146 | 12 years 6 mons 16 days  | 1 mon 9 days           | drivers/gpu/drm/i915/i915_gem.c
      2328 |     429 | 16 years 16 days         | 2 days                 | arch/arm/Kconfig
      2118 |     315 | 13 years 3 mons 3 days   | 1 day                  | arch/x86/kvm/x86.c
      2079 |     216 | 16 years 16 days         | 4 days                 | sound/pci/hda/patch_realtek.c
      2019 |     300 | 16 years 16 days         | 1 day                  | Makefile
      2001 |     186 | 13 years 10 mons 20 days | 5 days                 | fs/btrfs/inode.c
      1927 |     367 | 16 years 16 days         | 2 days                 | include/linux/sched.h
      1903 |     388 | 16 years 16 days         | 6 days                 | net/core/dev.c
      1888 |     177 | 12 years 6 mons 16 days  | 1 mon 9 days           | drivers/gpu/drm/i915/i915_reg.h
      1824 |     494 | 8 years 7 mons 18 days   | 6 days                 | arch/arm/boot/dts/Makefile
      1801 |     101 | 9 years 14 days          | 4 days                 | drivers/gpu/drm/i915/intel_pm.c
      1781 |     306 | 16 years 16 days         | 2 days                 | include/linux/fs.h
      1763 |     392 | 13 years 5 mons 20 days  | 2 days                 | arch/x86/Kconfig
      1737 |     391 | 16 years 16 days         | 2 days                 | mm/page_alloc.c
      1643 |     258 | 16 years 16 days         | 9 years 3 mons 27 days | kernel/sched.c
      1628 |     121 | 12 years 4 mons 4 days   | 1 year 8 mons 12 days  | drivers/gpu/drm/i915/intel_drv.h
      1628 |     118 | 14 years 2 mons 4 days   | 13 days                | fs/btrfs/extent-tree.c
Note: Authors may and probably is incorrect since a single user could have committed with different emails.

4 years ago by sfgweilr4f

Personally I'd like NVidia to be somewhere in the Top 50 of commits, or Top 100, Top 200. At least for a few weeks. Just saying.

Is wanting them in the top 1000 being too cynical or just wishful thinking?

4 years ago by sdesol

Here are the top nvidia driver files

         3975 |      98 |      54 | 9 years 8 mons 21 days   | 5 mons 28 days           | drivers/net/ethernet/nvidia/forcedeth.c
         7187 |      63 |      33 | 16 years 16 days         | 7 years 3 mons 16 days   | drivers/video/nvidia/nvidia.c
        16033 |      31 |      23 | 16 years 16 days         | 7 mons 5 days            | drivers/char/agp/nvidia-agp.c
        22720 |      22 |      11 | 16 years 16 days         | 11 years 1 mon 3 days    | drivers/video/nvidia/nv_i2c.c
        28134 |      17 |      10 | 12 years 9 mons 10 days  | 10 years 1 mon 10 days   | drivers/video/backlight/mbp_nvidia_bl.c
        28390 |      17 |       7 | 14 years 10 mons 7 days  | 10 years 1 mon 10 days   | drivers/video/nvidia/nv_backlight.c
        30344 |      16 |      10 | 2 years 5 mons 23 days   | 22 days                  | drivers/i2c/busses/i2c-nvidia-gpu.c
        33584 |      14 |      10 | 16 years 16 days         | 11 years 1 mon 3 days    | drivers/video/nvidia/nv_setup.c
        39992 |      11 |      10 | 7 years 15 days          | 7 mons 24 days           | drivers/video/fbdev/nvidia/nvidia.c
        40300 |      11 |       9 | 16 years 16 days         | 7 years 6 mons 3 days    | drivers/video/nvidia/nv_hw.c
The first column is rank, second column is commits and third column is authors so they are in the top 4000.

4 years ago by mobilemidget

After you calculated all that and let us know :)

https://gource.io

To create visuals of the gitrepo history/commits.

4 years ago by sfgweilr4f

what a fascinating tool.

4 years ago by 19h

I’d find a list of files that have the least changes more interesting (excluding text files et al.).

And then check if the lack of activity is related to the stability of the code, lack of use or its complexity.

4 years ago by bogota

You could. But I would recommend downloading it to a RAM disk to make generating that a bit faster. The which function sees the most use would likely take a bit of work to figure out.

4 years ago by DecoPerson

This really speaks to the reliability of Git.

Are there any examples of projects with 1kk+ commits that use SVN, Mercurial, Perforce, or some other SCM?

4 years ago by Cyph0n

Mercurial was used at Facebook afaik, and I would guess they ended up exceeding 1 million.

4 years ago by frob

When I left, the diff number was in the 15 million range. Not all diffs are landed, but I would assume >60% are, so FB's repo is almost certainly above 10M commits

4 years ago by papito

Sheeeit. At some point, just easier to archive the thing and start with a fresh import.

4 years ago by eru

And Google uses a hacked up Perforce.

4 years ago by quantumofalpha

Nothing hacked about it. They rewrote it completely, keeping just the interface for compatibility. Perforce scales very well but still has a single server at its core - at some point no matter how much money google threw at that machine (it used to be the beefiest single server they had), it just couldn't keep up.

4 years ago by Calzifer

Apache had a single SVN repository for all projects in the past. That reached 1889412 commits.

https://svn.apache.org/viewvc

4 years ago by jcranmer

http://hg.mozilla.org/try appears to have over 3M commits, and probably in excess of 100k heads (effectively git branches, although I don't think git has any proper term for a commit with no children that isn't referred to by a branch).

Strictly speaking, it's not actually the main project repository (which has closer to 600k commits), but the repository that contains what is effectively all of the pull requests for the past several years (more specifically, all the changes you want to test in automation).

The closed-source monorepos of Google (perforce IIRC), Facebook (Mercurial), and Microsoft (Git) are all going to be far larger than any open-source repository, of which Linux is in the largest size class but not the largest (I believe Chromium's the largest open-source repo I've found).

4 years ago by elteto

> although I don't think git has any proper term for a commit with no children that isn't referred to by a branch

I think this would be one case of a ā€œdetached headā€.

4 years ago by mfateev

Google is mimicking perforce command line. The backend is 100% proprietary.

Microsoft is based on Git, but with a lot of engineering on top of it: https://devblogs.microsoft.com/bharry/scaling-git-and-some-b...

4 years ago by jeffbee

Google announced they had 35 million commits to their monorepo, five years ago.

4 years ago by WanderPanda

Do they have a quick response team to incarcerate newbies who commit binaries to their giant monster?

4 years ago by jeffbee

No, because piper doesn’t care how big your files are, and devs don’t ever need to pull or clone the repo locally.

When they were still using actual Perforce there was a team who would browbeat people who had more than a hundred clients. That is they only time I can remember running up against a limit of the SCM.

4 years ago by quantumofalpha

That's a non-issue for scalable version control systems they use - perforce and now its in-house replacement (piper).

Gamedev companies LOVE perforce because it scales, they keep game assets in it and those can be huge.

4 years ago by eru

They have extensive code review.

4 years ago by tannhaeuser

Now, the question is when systemd surpasses Linux in terms of commits/LOCs ;)

4 years ago by tofof

Surpassed, not bypassed.

Daily digest email

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.