While he'd been working with and thinking about the problem for a long time the speed at which Linus produced Git always amazes me: "development of Git began on 3 April 2005...On 16 June, the kernel 2.6.12 release was managed by Git...Torvalds turned over maintenance on 26 July 2005".[1] Perhaps he should have some more breaks for side projects.
During his speech at Google "[after reviewing the alternatives] the end results was I decided I can write something better than anything out there in two weeks. And I was right"
Writing the basics of a DVCS in two weeks isn't a unique feat. Mercurial was created in almost exactly the same way, and was faster than git (and still is, e.g. for blame and clone operations) and actually was conceived with a UI from the beginning.
I'm pretty sure the only reason git took most of the mind share instead of hg was (1) github (2) Linus admiration.
- The index with git (git add -i) awesome for people doing patch maintenance
- the rebase workflow is great when you want to maintain against an upstream that you expect someone other than you to commit your changes to, or you have a "pre-publish" phase.
It's almost like those reasons follow the linux workflow.. almost perfectly.
Which is surprising, given how rough all the email-involving commands of git are. Badly documented (git-send-email man page doesn't even come close to documenting all options properly), awful error reporting and a badly explained (although, in itself, quite sane) workflow when sending the patches.
When setting up my email setup, I consulted the underlying Perl script more than the docs :(.
Sigh, I wish people would actually know about Mercurial. It was created for the exact same reason as git, at the same time, and is also intended for kernel development. In particular,
- The staging area can be achieved in hg in several ways, or it can be avoided as desired. One easy way is to just pick apart your commit with hg (c)record --amend and just keep adding to your commit as necessary.
- Rebasing has also been available in hg forever (and wasn't available in git from the beginning). We also have some really interesting changes brewing for rebasing in Mercurial: https://www.youtube.com/watch?v=4OlDm3akbqg
These ideas in hg were all for following the Linux workflow too.
Nothing against git, but it's important to not deify Linus as if he were a unique genius. He has his flaws, and so does the software that he's responsible for.
Mercurial went a long way down the "never modify history!" road (i.e. never rebase). Turns out that attitude, while theoretically pure, isn't very pragmatic. There are lots of valid reasons for rebasing.
Hg eventually came around but, for me, the damage had been done. It's the second biggest reason I went with git.
(The biggest, of course, is you use git if you want to interact with kernel devs. But lots of kernel devs hated git in 2005/2006. Mercurial had a reasonably big window of opportunity... all imo, fwiw)
Mercurial beat git past the starting gates, but git has the advantage of being used on a very widely used, widely developed, immensely high profile project. While Hg has its own commendable set of projects, git has simply won the mindshare battle.
Could be worse: there's arch and bzr and probably some others.
Hell, even GNU/EFF are looking to ditch their own VCS in favor of git from what I understand.
Yes, that's true git's main advantage is how widespread it is.
GNU Emacs decided to switch from bzr to git, but GNU as a whole doesn't have a recommended VCS yet. In GNU Octave we will keep using hg. I don't think the EFF is too public about which VCS they use.
There's a strong aversion of using tools done in Python outside of Python community. It is irrational, but it being an inherently interpreted language puts it into the same perception bucket as Perl and who'd want to use a control system written in Perl?
Something's still not clear about his assumptions in that talk. He says "you just continue to work" and "you could do everything you would do" [if you were connected online]. But this is not true when it comes to integration of source control with issue-tracking.
If you integrate source control with issue-tracking, you start to want source code changes to correspond to issue numbers, and changes to be pushed if an issue is in a certain state or owned by a specific developer. But you can't get this information when you are offline without access to the issue-tracker.
Either there's a case for distributed issue-tracking too, which would give you that information, or issue-tracking being centralized pushes back on source control wanting to be distributed.
I've been mulling over issue tracking lately, since I hate Jira and all the other ones I've used. Wouldn't issues being in states and having owners violate the distributed model? Version control used to have file owners and locks, which is the same thing, and git broke from that.
According to his recent save format post [1], he spends a lot of time thinking about something before he starts prototyping.
> So I've been thinking about this for basically months, but the way I work, I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding.
So two weeks seems reasonable to me, especially if he built a prototype first. (Did he?)
Isn't he blurring the line between "commit" meaning creating a state you can roll back to (in all version control systems), and "commit" meaning pushing to the "official" code base in a non-distributed system? In other words, some issues with non-distributed systems that he highlights (having to keep an elite group deemed smart enough to integrate changes, for example) still exist when pushing to a consensus "official" instance of a distributed repo.
His language is pretty muddled in this talk. It's clear he didn't really spend a lot of time thinking about precise and unambiguous language for all of the things he was talking about. He also seems to conflate "branch" and "clone".
This muddled language later turned into a muddled UI that was supposed to get cleaned up, but never did.
I can't help but think that he was conveniently leaving out details that give the entire story - clearly he thinks the audience are unintelligent sheep, so surely they'll take him at his word, right?
Probably because those two actions are identical in CVS, SVN etc, which most people at the talk were familiar with, unlike the commit and push states in a DVCS (hg, git, bzr etc).
Yeah, that was a great talk. I highly recommend people watch it.
He was definitely right about that, what I like about Linus is he really does seem to prefer to do things in as concrete and simple a way as possible instead of getting mired in abstractions.
Parent is downvoted but this seems like a valid question to me. The interface consists of git sub commands and their flags. One could argue that there are too many flags, or even too many commands, but why not offer flexibility when you can as long as you keep sane defaults?
I think that git commit, init, add, fetch, branch, checkout, merge, and push all have sane defaults and anybody can pick up very basic git usage using those commands in less than a few hours.
Things get complicated when you start looking at the details, but I don't see any way around that. And the interface doesn't change. It's just a matter of learning more flags and commands.
I have tons of little problems with it that would be silly to enumerate, but they fall into 3 broad categories.
1) Terrible tab completion support.
2) Multiple command/option permutations that do nearly the same thing with small subtle differences.
3) Lack of cohesion amongst the community around best practices (especially with regards to branching/merging/rebasing).
Each git command seems like it was done by its own subcommittee without regards to what the other commands do. Functionality overlaps. Mnemonics from one command don't carry to another. I forget the specific example, but one command would be colorized with command line options, and another would be colorized with environment settings.
I'll admit it's a little bit strange, but it's not like you can't just alias frequently used commands that are more complicated. Besides, Git's utility makes up for this by far.
Then again, I alias nearly all the CLI programs I use frequently. Grep's recursive search is aliased to `sr`, Python to `py`, Django's `manage.py runserver` to `run`.
We've already got a world with multiple inits. The rationale for adopting systemd is ... troubling. Clearly, Linus has some issues with the team involved, though I don't know whether or not he's also concerned with the deep coupling.
Hauling systemd out of udev (or offering a systemd-free alternative) would also make me far happier.
Complexity is the enemy of reliability. An expression dating back, I've recently discovered, to January, 1958, and The Economist Newspaper.
There's a lot of argument over just what that term means.
Many moons ago in an organizational behavior / group decisionmaking book whose title I can never keep in mind, I read a fascinating chapter on various group structures for decisionmaking.
Of the various models, the one which works best under more circumstances is that in which there is a leadership role (so there's no indecision over what decision has been made or when it's been taken), but that role is collectively assigned based on merits.
In other words, the leaders' tenure is at the consent of the group as a whole, and can be transfered. The one decision over which the leader has no effective say (or at least: no more than any other individual) is over the question of leadership.
Strikes me as very much the model that's followed by the most successful free software projects.
> Strikes me as very much the model that's followed by the most successful free software projects.
I believe Linus learning some manners for himself would hardly slow down neither of Linux or Git, and nor would make him a lesser leader. Seriously, there are better ways of putting things forth, than execrating persons who contribute to Linux/Git for a living, on public mailing lists. Leaders need be responsible of their public speech. Someone who is writing curse words in all caps is not speaking responsibly by definition.
Theo de Raat is another famously short-tempered project leader.
In both cases, the result doesn't seem to have hurt what matters: the project themselves and the utility they provide their users.
The goal of the projects isn't to protect tender egos. It's to get shit done and make the right decisions.
Linus answered one woman who'd criticized his behavior by noting that a key issue for him was making absolutely unambiguously clear how good or bad a given technical suggestion was. And he does that.
Because if you want me to "act professional," I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm ALSO not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways.
As I commented at the time:
There's something to be said for being an equal-opportunity asshole, in a fair and balanced manner.
And in running the most effective, successful, beneficial, and largest OS development project the world has ever seen.
I see Linus's behavior as being an instance of Celine's Second Law:
Accurate communication is possible only in a non-punishing situation.
"Huh?" you say? But Linus is punishing communication.
No. Linus is communicating. He's expressing a clear view of what is or isn't valuable. The punishment isn't in rating the quality of contributions to the kernel, or usefulness of others' participation in the LKML. It's in criticizing the communications methods used to convey that feedback.
Acting professional and being a moral vandal that runs around smashing people on a public mailing list is so far apart, there is a nice point to sit in between as a frank, sincere and straight out leader, that also knows how to speak and communicate. One can “express a clear view of what is or isn't valuable”, with a language that's not vulgar.
It's sad that people get so hung up on bashing personality differences (not flaws) that they can't even see the much greater good that some people do. Politeness is just the toleration of stupidity and the acceptance of mediocrity.
Given the average time it takes for people to receive these Linus is getting it very early. Super nice to see his contribution recognized like this. It will be very interesting to see in a hundred years from now or so what will be the longest living contribution he's made, Linux or git.
Looking through this list he is in very august company indeed.
First off, if Linux had a per-unit or similar usage charge, its adoption rate would all but certainly have been vastly lower. Factual basis: the many extant proprietary x86 Unix clones at the time Linux emerged.
There's the question of how to value "use value", and what the value of an OS actually is. Impressions are (IMO deceptively) skewed upward by the example of Microsoft, but it's the rare instance of a software-only mass-market OS platform -- actually, rare to the point of single-instance.
There's the question of what an ordinary or acceptable rate of return ought be.
And there's the question of how much of the returns should be shared with others.
Still, Linux as an enterprise might be compared with, say, IBM or Sun at their peak, possibly HP's server operations. There's the present valuations of Red Hat, Google, and Facebook, among other Internet companies based largely on Linux's capabilities.
Certainly multiples of billions in a traditional sense -- I'd argue for $5 - $20b.
In an alternate universe where Linus Torvalds did not exist, I think one of the other free Unix clones would have gained more traction and filled that niche in the ecosystem. It would be interesting to peek into the universe where FreeBSD really struck it big. (And I'd also like to see the universe where Gnu HURD took over, although that seems a lot less likely.)
Linus at an interview said that "If I didn't create Linux in 1992, by 1993 someone else would have done it. Linux was created because the time was right, the GNU ecosystem was there. The kernel was the missing part".
Of course this is kind of speculation on one hand, but there was the Hurd project which might have taken off, or someone else could really have created something similar a year later, if it did not exist.
BSD had it's licensing issues, which today seems more liberating - most programmers seem to embrace it - but in 1992 was seen a free ride license which is something most Linux developers did not like. That's why Linux grew so much,. Saying that FreeBSD would taken that niche seems a little bit off IMHO.
Hurd now as then simply lacks the technical and performance chops to cut it. Conceptually it's interesting, but this is a place where RMS's instincts lead him down the very wrong path.
I think one of the other free Unix clones would have gained more traction
Almost certainly, and also almost certainly FreeBSD. The UNIX Wars did more than anything to ensure that this didn't happen, though.
There's still a bit of an open question. Linux benefited over FreeBSD not only in not having a lawsuit looming over it, but in that its development process was far more open. Though it's arguable that FreeBSD is more stable (and for much of the 1990s had a superior networking stack -- hence its adoption at such shops as Yahoo), ultimately it was the addition of features, and drivers, to Linux which very much ensured its take-off, as well as the numerous distros, each of which had a slightly different focus (and often significantly different package management systems), some of which proved more attractive than others.
I find it interesting that of the two primary x86 unices, the more open one (Linux) beat FreeBSD, and of the Linux distros, a noncommercial and generally open one (Debian and variants) seems to be slowly trouncing the more closed corporate variant (Red Hat).
$5-20B. And the many x86 unix clones... not so much.
What's the difference? Was Linux technically superior? Freedom? Community? GNU?
Interesting questions indeed.
I remember going some of these questions over in the early 2000's. ('02, maybe.)
Around the time Linux was starting to make inroads into businesses. Usually by the backdoor - internal services needed platforms they could install without going through the usual acquisition processes. If it cost money, some beancounter was going to object. (I witnessed a couple of cases first hand.)
So the techies installed some flavour of Linux on decommissioned boxes instead and ran their systems where they could. Individually the cost savings were negligible, but when you suddenly find out that 30 or even 50 internal services are running on top of OS stack that had cost nothing, the upper echelons finally take notice. The fact that the OS could be customised and repurposed for a particular need was an amplifier, and only later became the core "feature".
I recall (with horror) the days when "tweaking the OS" meant running regedit.exe and turning a number of undocumented knobs in directions you could only guess at. Not to mention pray that the system worked on the next boot.
So Linux use began as a way to cut costs (or skip the acquisition process altogether). It ballooned because it was possible to customise and extend the system on the OS level as needed.
• Linux worked. It was "good enough". Once you reached the point of running a shell, GNU userland, an editor, and a compiler, it was off to the races. Not sufficient, but necessary.
• No lawsuit. The UNIX Wars put a multi-year crimp on FreeBSD. The BSD splits didn't help much either (these included not just the userland as in Linux distros, but kernel development --which for Linux distros remains unified).
• Freely hackable, but published changes are licensed under GPL. I don't know how much thought went into Linus's choice of license, but it proved highly fortuitous.
• The time was absolutely ripe. Even within proprietary Unix companies, people were advocating heavily for a freely-available, open-source operating system. See Larry McVoy's "The Sourceware Operating System Proposal", from his days as a SunOS engineer prior to founding BitMover: http://www.landley.net/history/mirror/unix/srcos.html
• Key early adopters and developers. Alan Cox on development, and John "Maddog" Hall at DEC were key in both pushing kernel development, facilitating early ports (to Alpha), and in putting legitimacy behind the effort.
• Multiple distros. Almost immediately a side-light of bundling up the kernel and a set of utilities into a usable package emerged: Boot Root, MCC, TAMU, SLS, Yggdrasil. I remember SLS ("soft landing systems") being explained, somewhat fondly, as "because it was a pile of shit". Eventually over a few months in 1994 Slackware, Red Hat, Debian, SuSE, and Caldera emerged, which with very few notable exceptions continue to rule the distro landscape. I find interesting that "bootable distros" were present from very nearly the start (my own first exposure to these was Linux Root Boot, a/k/a Lnxrtbt, on a single floppy, also Trinux, booting from 2+ disks into a ramdisk). LWN has a good early history: https://lwn.net/Articles/91371/
• As others have noted, functionality, cost, features, and exigency all meant that technical needs felt at the coalface by front-line engineering staff at many firms were being met with decommissioned server, or, very often, desktop systems. While Microsoft-bound CIOs were proclaiming "we run no Linux and never will" their organizations were in fact increasingly not only using, but dependent on it. These denials persisted through the early 2000s, though beyond 1998 or so it was largely only dead-enders maintaining this.
And from there it just continued to build. I'd argue that the linchpin argument wasn't money made selling Linux or Linux services, but companies based on it which simply couldn't exist by other means, of which the most notable early exemplar was almost certainly Google. Running its systems on proprietary Unix or Microsoft platforms would have been prohibitive in both cost and flexibility.
I'm not sure that it's a great idea to keep giving Linus prizes. He probably already has quite a collection of them. Instead I think some of the other kernel maintainers should get prizes.
Everyone I tried explaining to that it's GNU/Linux has rolled their eyes at me like I'm some kind of pedantic madman. Then I gave up doing it and went back just calling it Linux.
Potato, tomato. No one cares outside of the RMS cult.
Indeed. Ten years ago everyone made fun of Stallman for his insistence on calling it GNU/Linux (I was guilty of this as well). These days, with android so popular, it's very topical - I want GNU/Linux on my devices, not just linux.
[1]https://en.wikipedia.org/wiki/Git_(software)