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.
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.
It’s a more basic conceptual mistake to say that Linux is a technology on the tech tree alongside Telecommunications / Computers / Wheel / etc. It would be like having “Automobilism” but then later “Lincoln Town Car.”
I get what you are saying about Linux being available to all (hence a shared wonder - the boost to the civilization who developed Linux can be interpreted as increased academic prestige, etc). The point is that Linux is a specific product of technology, not a broad area of human tech.
At the time Linus got started in 1991, *BSD was tied up in a legal dispute (which was not resolved until 1994), and Minix was only available under a restrictive license (Minix was relicensed BSD in 2000)
If either of those legal issues had not existed in 1991, Linus probably would never have started Linux [0], and Linux's place in history would have been assumed by something else – most likely some BSD derivative or a descendant of Minix.
(Minix's microkernel architecture, while elegant, has a performance cost. However, Minix could have easily been hacked into a monolithic kernel, which is basically what Apple did to Mach, and Microsoft did with win32k.sys. Or maybe it could have evolved towards a higher performance microkernel architecture, such as is found in L4)
In terms of the "technology tree", Linux occupies the place of "leading openly developed FLOSS operating system". If Linux hadn't occupied that place, some other system would have instead. And there is a chance even that one day Linux might be dethroned. (Unlikely to happen any time soon, but maybe some decades or centuries from now.)
Don't forget GNU Hurd, which had its first release in 1990. Had Linux not taken off it is possible Hurd would have taken a more practical approach and become a production OS.
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.
> 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).
Actually that would be an interesting mechanic: to move forward in the tech tree you have to research something, but by researching it you give it all the players.
Do you stall your own progress, or take the hit to move forward and float all ships higher by raising the technological tide? How do the devs program the AI countries to make choice(s) in single-player, and what would a human player do?
This isn't new, so we don't need to speculate about it. Older civs had this. Civ IV has the Manhattan Project, and the Apollo Program, both of which enable new stuff for all civilizations, once built (nukes, and space race).
In addition to the comments below, I think a way to implement your idea is to have certain technologies automatically shared between trading partners and/or alliances - and also wars.
This exists in other 4X games but not really any of the Civ series IIRC. You can trade generic science points but certain technologies and civics could be shared directly by trade and military engagements with foreign powers (wheel, military tactics, currency, printing press, etc).
One of the games has something like this. After researching the internet technology (or maybe it's a wonder?), any time any tech has been researched by any two civs, you instantly research the tech for free.
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
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
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.
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).
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.
By "scalable" I assume you mean "centralized". As in the repository is hosted on a single machine, so you only have to worry about one machine meeting the hardware requirements for storing all that data. That scales better with repo size, but it scales worse with the size of your development team. I'm sure the Linux kernel has orders of magnitude more developers than a typical video game or engine.
Yes, at scale it has to be. Google has hundreds of terabytes of data in their monorepo, you can't check out it all! Historically centralized used to be the norm - previous popular VCS generations (CVS, subversion) are all like that. DVCS (git & co) came into dominance only in the last decade or so.
> That scales better with repo size, but it scales worse with the size of your development team.
Google switched to piper around 2014 when they had ~50k employees. Perforce monorepo worked pretty well for them until then. It has certain costs to scale a monorepo that far - lots of investment into tooling to make it all work, needs dedicated teams. But it can be scaled. And it offers certain benefits that are very difficult to harness in multi-repo setups - ability to reason about and refactor code across entire repo is the biggest one.
> I'm sure the Linux kernel has orders of magnitude more developers than a typical video game or engine
Linux kernel development is very different, decentralized across many different companies and ICs, hence the need for DVCS systems like git. In a corporate environment like google or gamedev, it is much easier to keep version control centralized and dedicate a team to maintaining it.
Epic Games' p4 depot has well over 1mm changelists. Many of those numbers are taken up by developer changes that never get submitted, and many are automated merges though
I thought I read that Linux jettisons old history every few years for the sake of practicality, and that if you want the full history you have to look at special archive repos. Am I wrong? I wouldn't blame them; git is fast, but it's not that fast, and cloning becomes a bear after only a few hundred thousand commits (and I would be surprised if that's the only operation that scales poorly).
Lot of people view 1mm as a huge number of commits. Which maybe it is... if your team has a habit of big PRs + rebasing.
On the other hand, if your team is used to making quick iterative commits, throwing them in a PR, never rebasing, and pulling in merge commits all over the place, uh, I can attest that you can get to a million commits pretty fast.
Git's data model doesn't care how many commits there are. It doesn't care how many objects there are and commits are just one type of object. The git repo probably has tens to hundreds of millions of objects. The limiting factor is probably the filesystem, but I think most can handle it just fine.
How do other open source projects compare? I'll admit, I would have figured that Linux had passed one million commits some time ago, and I feel like web browsers might give Linux a run for its money here.
It truly is the greatest open source project of all time. I just wish they moved away from email as the only way of contributing. It doesn't really scale well and definitely doesn't make contributing for newbies easier.
And Stallman likes Lynx. Does it mean it's somehow the best tool for the job because a famous person likes it? Times change, tool evolve and most opensource projects catch up. There is no reason why Linux kernel project shouldn't adapt some of the quality-of-live improvements of modern day tooling.
> I just wish they moved away from email as the only way of contributing.
What alternative do you suggest, and in what way is it better than email?
> It doesn't really scale well [...]
There are few things that scale better than email...
> [...] doesn't make contributing for newbies easier.
That's a good thing: If you haven't even mastered sending a plaintext email, I really wouldn't expect you to be able to constructively contribute to kernel development. Feel free to experiment with your local copy, though – it's open source after all.
Assuming you have your git config set up to use git format-patch and git send-email, they're pretty easy to use. Plus keeping your local copy of the git repo up to date is easier than keeping your github fork up to date.
> If you haven't even mastered sending a plaintext email, , I really wouldn't expect you to be able to constructively contribute to kernel development.
That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that: it's the sort of things that's easy in retrospect, but the UX is hard to discover and the lack of parallel with other tools we regularly use (such mailing lists aren't a thing that most devs use) adds a huge amount of friction.
And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions)...
It's not impossible, but there's a dozen things you need to figure out, half of them you don't even _know_ you need to figure out, so it's a lot of friction. This friction might be a good thing (that's another debate), but saying "you just need to be able to send a plaintext email" is completely false and dismissive.
> That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that
This belief that people aren't able to figure out things on their own is the problem. You're basically telling people that it's hard and they'll never figure it out. You're telling people that there are so many things they need to do that they'll never be able to do them.
Have you ever considered that these statements themselves are ones that drive away potential contributors? Why not let people make their own judgment about the process after they've gone through it instead of adding your own bias to it?
> And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions)
This is all described in the submitting patches[1] document in the source tree. It even links to an interactive tutorial regarding how to set up git-send-email[2]
> It's not impossible, but there's a dozen things you need to figure out [...]
Most of those things don't go away if you send a pull request via the Github web interface, because they boil down to "follow the rules and guidelines of the Linux kernel developers".
Oh, and not everyone is intimately familiar with the Github pull request interfaces.
I do think committing via Github would significantly lower the friction of contributing to the Linux kernel for a chunk of the developer population, and there might actually be a decent well of untapped potential there.
Of course there will also be a lot of pull request noise, so I can't say if that tradeoff is ultimately worth it.
Edit: well I guess OSS people are extremely hostile to even the discussion of more people contributing to the Linux kernel. My bad.
> committing via Github [...] there might actually be a decent well of untapped potential there
I don't buy it. Contributing to the Linux kernel is inherently non-trivial, and I find it completely implausible that any non-negligible number of developers are able to do that while not knowing how to send a mail.
Seriously, what's the scenario supposed to be here? "I've found a bug in low-level C code, and it's not a false positive, and I fixed and tested it, and I've looked up and followed the kernel coding guidelines, but I don't know how/am too lazy to send a patch per mail"?
> don't know how/am too lazy to send a patch per mail"?
Arguably, it's even easier to do so with git format-patch and send-email commands, since they address the issue of MUAs mangling the patch before sending it to the mailing list.
It’s not hostility per se, it’s gate keeping/admission. Linux is arguably the greatest OSS ever made and jumping the gun to whatever’s the next trend (GitHub has only been around for ten years) is just unwise. Shiny object syndrome. What happens when GitHub is down and the thousands of projects that depend on Linux (device drivers, networking stacks, soc’s for instance) can no longer access it? Why don’t we just move LWN to Notion? And we can use React 17.8b for the man pages! /s
Also GitHub is owned by Microsoft and I hope I don’t need to explain why Linux-users wouldn’t be comfortable with that…
This push for every project to be as 'easy' as possible to contribute to is just weird to me. Like entering a room and immediately uplifting their entire productivity flow.
I’m curious if you use the Linux email list and archive?
I’ve been thinking about how Linux and Wikipedia use an email list that is archived to a website. The archive can be browsed like an issue tracker. Many people spend their day in their email app. I wonder if maybe most projects aren’t using email correctly…
If I were contributing to Linux I would prefer some nicer methods of submitting patches, but email seems to be working out just fine for the project. Also I wonder if doing it by email creates a bit of quality filter by adding that little speed bump. It's not as simple to contribute as clicking "fork" and then "submit pull request", but also not something that discriminates since email is a system open to anyone.
Does Github work on a dial up connection? Does it work when you don't have an internet connection?
Improvements in technology can do everything that old technology can do and more. Not supporting use cases that old technology did isn't an improvement.
You know, that's not really true. For road transportation, a car is a great improvement on a horse — but it can't take you home when you're too drunk to guide it. Some things are an improvement in general, but still a compromise.
A stronger argument would explain why the better technology is a bad compromise for this application.
You're working off an assumption that Github is a better technology. Many people who make this argument do not have extensive experience using both technologies. The arguments I've seen presented comes down to the fact that people cannot figure out how to set up email clients or how to send patch sets via email. It's not around an actual comparison of how these technologies operate or what compromises one has to make to use email versus Github or vice-versa.
I see that argument about client setup too, but it's not the reason I don't prefer email, especially for something like kernel development. I think there are real disadvantages to the sort of queue management required of the maintainer using email that can be alleviated by a specialized tool. It also separates the communication history from the code history, which can sometimes lead to confusion about when a specific person became aware of a patch, which is often important. I'm usually against integrating too many functions, but I think GitHub does a good job of it.
Basically, I prefer GitHub's approach. I'm not deeply experienced managing open source projects, though, so my opinion is not that valuable. My basic contention was with the idea that a technology can't be better unless it's an unmixed good.
Part of me wonders why nobody tries to make software like we make buildings... After some time, it's all done and nothing else needs to be added.
People will be quick to point out that "the hardware keeps changing so the software has to adapt".
This is true, but why not design the software in such a way that different drivers can easily be substituted (so the drivers can change but the interface doesn't)?
I did this with my open source project. I haven't made any code changes for over a year and it still works perfectly and still relevant.
I don't understand why there is such a fetish in this industry for never finishing any project. I find the whole attitude very frustrating.
Hardly any compared to software. We're talking about 1 change every 20 years versus 1 to 100s of changes per day. That's a huge magnitude of difference. But that's not even important to my argument.
To suggest that software maintenance and building maintenance are anything alike is ignoring the entire context of the two activities.
With buildings, builders have very little control over the wear and tear caused by the environment. In software, developers collectively have total control over the software and hardware environment which determines whether or not software breaks.
Most of the wear and tear in software is a direct result of people compulsively changing stuff in other software (or hardware) up the stack - It's all 100% avoidable. If the software never changed materially (aside from bug fixes), it would not break. Simple as that.
And most of the software changes are simply taking us round in circles. New generations of developers undoing the work of the previous generation, then later reversing direction again, surely we've all seen it happening at most of the software companies we've worked at...
> Hardly any compared to software. We're talking about 1 change every 20 years versus 1 to 100s of changes per day. That's a huge magnitude of difference.
Linux is more akin to a template of all buildings in the world, which are all the Burj al Arab (of course each building is mostly empty, everyone just uses some part of it). If someone in Mongolia finds a wrongly tiled bathroom in room 221B, Linus changes that tile in its template. A few weeks later, all Burj al Arab in the world are torn down and replace with a new one, only slightly better.
This sounds terribly inefficient. Why include the tiles as part of the design? Why not instead have a specification about what kinds of tiles are supported and how they should be laid out instead (just an interface)? Then other projects could take care of providing designs for tiles... Tile providers will need to change to adapt any changes to the core layout, but the core layout doesn't need to change often since the fickle parts are not part of it.
Ain't nobody got the time to select all the sub-specifications for a simple house. It's simpler to live in a small corner of the Burj al-Arab, you can piggyback on some work made by the big hoteliers.
> so the drivers can change but the interface doesn't
This is already how it is. Take write(sockfd, …). Sure there are some configuration options in the parameters but nothing compared to the real complexity of networking. This is the downside to abstraction; roughly, the least complex implementation wins. Eventually, we shift and add more and more standards, but it’s never cutting edge (and for good reason).
> I haven't made any code changes for over a year
Relatively speaking, a year is nothing in the timeline of software, so this is not surprising and it’s likely that even if you hadn’t written your software in a abstracted way (which kudos to you for doing so), it would still be fine after only one year. write() has been the same interface for over 40 years.
Also, not to rain on anybody’s parade, but OSS is - generally - not held to the same performance standards that proprietary code is. This makes sense intuitively right? “If I’m paying for it, it better work.” And the vast, vast majority of code is not OSS. We just get a false impression since, by definition, we only have access to OSS. The worst that can happen for bad OSS is lack of adoption or a tsunami of incoming GitHub issues. For proprietary code, you could lose your job if a product doesn’t take.
> I don't understand why there is such a fetish in this industry for never finishing any project
This is similar to the argument that a company, once it has a good product, should just stop. Why do we need updates?, I like the features we have, Don’t change it, it’s perfect. But to survive in the market - not just on GitHub or code coverage tests - requires constant competition and innovation. If Intel launches a new multi-register write feature, Chip Company X can’t just say “Well our project is done.” It’s not anymore! And if it, then Chip Company X might be done too…
> Also, not to rain on anybody’s parade, but OSS is - generally - not held to the same performance standards that proprietary code is. This makes sense intuitively right? “If I’m paying for it, it better work.”
I've noticed the opposite to be true. Code from a proprietary vendor is buggy? Too bad, the corp just a faceless, nameless borg of an entity that doesn't care about your bugs. OSS has bugs? You can easily go rant at the poor coders who are working on it
It really depends on the software: I have a maintenance contract for LispWorks and, whenever I report a bug, I get a custom patch and/or a resolution in an impressively short window. For a lot of SAAS-type products (JIRA, for example), oftentimes the users are fairly decoupled from the company: since the admins/purchasing people have more contact with the vendor, but less direct usage of the software, it’s harder to get this sort of support.
Yes, this is also my experience. In fact, proprietary products are more likely to break because it means the company has to come back to the provider an pay them to have it fixed... These big bureaucratic corporations have infinite patience... It's like these big companies expect things to constantly break.
> This is similar to the argument that a company, once it has a good product, should just stop. Why do we need updates?, I like the features we have, Don’t change it, it’s perfect.
The annoying thing to me is that the actual software development rule seems to be “improve it until it breaks”: Slack was pretty great for a while, but at a certain point they started adding misfeatures (the new rich text input is still really annoying in a hundred little ways) and eventually the app just became really buggy: I’m still stuck with it for Reasons, but I’m constantly reloading/force-quitting it just to read messages and bits of the UI appear and disappear seemingly at random.
A work of art is never finished, merely abandoned. Also, Why do you think building are finished at any time? The insides change a lot, living space expands to the attic, old wiring get replaced, walls get extra support, roof gets patched, replaced, or maybe they even build a new story.
