Considering the broad range of such softwares that already exist, written by people such as Felix von Leitner, Gerrit Pape, Laurent Bercot, and so on, why do you think that Linus Torvalds is the person to write one? Or needs to write one?
There were many version controls systems before Git came along. He doesn't need to write it. But if he wants, he has the technical chops to do a damn good job of it.
I sure hope so... I've had to revert several Ubuntu machines to upstart and I have to "sudo service restart network-manager" 3 of 10 times my primary desktop starts (so I scripted it..)
Based solely on my personal experience (which is mainly Ubuntu desktop and server) Systemd is a hot broken mess. To me it feels like good goals with poor implementation.
I actually miss how simple init used to be... I understand the motivations for improving it, but if I had to choose ease of grokability or better boot times, I'll take grok every time.
Given how many things systemd does and how this set of things is increasing with every version (lately including dhcp and ntp client, for example), it feels to me that the goal is to bring as much things under systemd (and thus Red Hat) as possible.
It's a sad day that the biggest Linux company is doing Embrace, Extend, Extinguish, but I guess I shouldn't have expected more from RH.
Linus wrote git because BitKeeper was taken away from him due to the Andrew Tridgell incident, not because he disliked BitKeeper; he didn't even mind that it was closed source.
I wonder, how many people reading that article would predict the rise of stuff like GitHub and GitLab and the success of Git to the point of crushing CVS and making SVN decline in popularity?
> [...] the success of Git to the point of crushing CVS and making SVN decline in popularity?
CVS was already on the way out even prior to git's inception, because of SVN. SVN's unofficial goal is essentially to be a better CVS, and it was a great success on that front. However, IMO its success made its core dev team complacent.
For example, one complaint I hear often of SVN is that it's slow. Go use CVS for a week -- and I mean not just doing a checkout and make a few commits, but merge, diff, switch branch, add / remove / rename sub-trees, etc.; bonus points for involving >3 people trying to do the same simultaneously -- then try and tell me SVN is slow.
Nonetheless, SVN is not fast, but it's fast enough when there was no viable competition. Then git came along, and even the staunchest opponents must conceded that it's lightning quick. And people will tolerate a lot of BS from a tool if it does the job and does it quickly.
SVN's performance has improved significantly since the 1.4.x days, around the time when git first made its appearance. No doubt some improvements were on the roadmap regardless, but surely having competition lit a fire in getting them out the door.
Considering the architecture of the git and fundamental tradeoffs that you make after deciding on: content addressability, internal data representation, tracking content instead of files, taking snapshot of the content of entire commit as opposed to just its diff - the only avoidable BS people get from git is its "porcelain" CLI. There have been many tools tools to address it (like easygit).
Git is extremely well engineered, it's just that its UI is not conducive to learning it.
For me, there are numerous advantages of git over svn:
1) git log uses a pager by default and is lightning fast compared to svn log which needs a server connection and is not paged
2) the "current commit id" is the same across all directories in a repo, while in svn every directory can be at a different revision
3) side benefit of #2, a "git status" in a subdirectory also shows the status of files in upper-level paths of the repo
4) backup-ability: every git checkout is a full clone, so if the server is down, or you're on the road without wifi, you can still work even with history
5) partial commits (git add/commit -p) is a godsend, I don't get why svn still hasn't implemented this
6) the tooling around hosting is way better - websvn is a laugh compared to gitweb and even more so compared to gitlab/bitbucket/github
CVS was already being kicked out the door at that time by SVN. A lot of people looked at Git as a potential replacement for SVN (at least, I did. Took several years for me to really 'get' it, though. I'm not sure even today I completely 'get' Git: there are a lot of possible workflows).
> I'm not sure even today I completely 'get' Git: there are a lot of possible workflows
In my experience most people are using git with a svn workflow. They use github (gitlab, or something internal to the company) as the central server, and work only from the central server. Make github speak svn, and alias all the git commands to svn and they couldn't tell the difference.
In my experience most people are using git with a svn workflow.
Yeap, but with a lot of local branches, and that makes a huge difference. Branching with SVN seriously sucked (although I've heard it's gotten better).
Please no. That would be like if Gandalf wielded the One Ring. I've no doubt the result would be very functional and well engineered, but it would be awful in other ways.
Unlikely, for the same reason that he didn't tackle application packaging[0]: because writing a successful init system would necessitate either perfect backwards compatibility with shell scripts (next to impossible unless you're basically just copy-pasting sysvinit) or a massive coordination problem of rewriting the long tail of all the crazy different daemons people run to be compatible with the new system.
Git didn't have this problem because:
0. Version control systems don't have to interact with as many other software packages anyway (editor/shell integration is nice, but you can live without them and just run git directly from the command line);
1. There were compatibility layers that let Git talk to popular VCSes;
2. The fact that you use Git personally does not affect anyone else, obviating the bulk of the need for coordinated upgrades (there were stories, from before GitHub was a thing, of 'guerrilla Git users' in companies that officially used CVS).
These three things ensured that a relatively painless incremental upgrade path existed; in the case of init systems, it will be much harder to establish.
