Like what happened to git in the past, will Linus write a new init himself this time?
* http://blog.darknedgy.net/technology/2015/09/05/0/
* http://skarnet.org/software/s6-linux-init/
Most that came before were good at forking, but not so good at merging.
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.
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.
Found this article: https://www.pcworld.idg.com.au/article/129776/after_controve...
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?
I didn't dream of it in terms of GitHub.
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.
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).
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.
Git is extremely well engineered, it's just that its UI is not conducive to learning it.
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
7) support for branches
Depends on the business area. I am still using SVN in 100% of our customers.
And they don't seem keen to move into Git anytime soon.
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.
[0] He talks about it in https://www.youtube.com/watch?v=1Mg5_gxNXTo ; can't find the timestamp right now, but it's in the latter half of the video IIRC.