[Haifux] [W2L] Call for lecturer + "Linux guru"
shlomif at iglu.org.il
Sun Oct 18 18:07:45 MSD 2009
Trimming your message.
On Sunday 18 Oct 2009 08:51:23 Ohad Lutzky wrote:
> In the case that this is only a 20 minute lecture, I wholeheartedly agree.
> I do think that git should be mentioned, in a one-liner, as "a more
> advanced tool that also allows you to work offline".
Naturally, you should mention it for completeness sake. You should also
mention bzr and Mercurial and/or refer people to http://better-scm.berlios.de/
or something similar [better-scm] for further reading, a comparison and
Here is what I think of the various prominent FOSS VCSes :
* Subversion (svn) - naturally, I may be biased towards it because I'm still
using it for a lot (probably most) stuff, and have also contributed to it, a
long time before git or hg existed (or even Bazaar and Bazaar NG which is now
bzr), when its main competitors were Arch/larch/tla and Aegis and later darcs.
( Monotone is still around and served as the main inspiration for git, but
from my impression very few people use it. )
Subversion is very polished - it compiles and runs well on most (all?) modern
UNIXes and many old ones, works very well on MS Windows (as a client and as a
server), has an intuitive syntax and command output and mostly works as
expected. Branching and merging there is much nicer than with CVS, at least in
my opinion, though branches and tags are just free form directory copies - not
"real" repository-wide tags and branches which git and hg support.
I can probably rant a lot about the unjustifiably poor perception of
Subversion in the blogosphere that I read, where people often do a apples-to-
oranges comparison of it to something else. I have learnt git and hg and am
still more than willing to use Subversion for some stuff due to its usability,
portability and software engineering (having APIs, etc.) advantages, which I
have called its "polish".
In any case, as Ben Collins-Sussman notes, while Subversion has proven popular
in the open-source world to a large extent (though lately there was a trend to
use VCSes such as hg, bzr, git, etc. instead), it has been extremely popular
among the "80%" of software developers: various developers who are not working
on shrinkwrap software (or alternatively shrinkwrap software that is niche but
still profitable enough to make a living out of), and that are using it as a
high-quality, cheap (gratis in fact) and open-source alternative to Microsoft
Visual SourceSafe, CVS, Perforce, ClearCase, etc.:
I know at least two people in Israel who give Subversion consulting, and often
it just means they get a monthly or yearly consulting fee to agree to support
Subversion in case there's a problem with it, which usually does not happen
because it works very well, but is needed to settle the pointy-haired bosses
(PHBs) who need commercial support. This is still probably cheaper for them
than paying for a ClearCase licence, and naturally Visual SourceSafe, despite
an innocent and easy appearance, is much more hazardous and time consuming in
the long run (and obviously is not portable at all).
OK. enough about svn.
* bzr - my main problem with it is that it is painfully slow. Many local bzr
operations are slower than even the equivalent svn operations which finish
pretty quickly here. While it may be another SNAFU on my relatively-old-and-
constantly-updated Mandriva Cooker system, which works pretty well and is
fast, but sometimes acquires some weird problems, http://dazjorz.com/ have
said that a local filesystem bzr was slower for him than svn in conjuction
with Sourceforge, and he is using Debian I think.
Part of the problem seems to be that bzr is written in pure-Python, while hg
which is also mostly Pythonic has parts written in ANSI C for speed.
In any case, this horrible performance makes bzr a non-starter for me. As
patient as I can become, it is still too slow to be effective. Now the GNU
project wants to convert the Emacs CVS repository (with a large codebase and
years upon years of history) to bzr (which is not in the process of becoming a
GNU project - possibly a typical GNU NIH), so hopefully this will motivate
some work on optimising bzr and making it scale better.
* git - I've been using git in conjunction with github for a long time now.
github is a very nice service (though I'm skeptical about its profitability),
but git still leaves a lot to be desired. I still could not fully get to the
bottom of the program model of git, and a lot of git usability and tricks
stuff has been the topic of a lot of blog posts lately. I don't recall so many
blog posts about Subversion when it started to become popular.
There are several possible explanations for this, but I tend to think part of
the problem is that git has a more complex and counter-intuitive
architecture[intuitive] and provides more fodder for blogging than svn which
is easy, simple and easy-to-understand.
git often throws me off and gives me a weird error which I cannot tell how to
avoid or workaround . The Freenode #git people tend to be very helpful about
that (they never tell me to "RTFM" - :-)), but I still find it frustrating
that I cannot figure out something so mundane on my own. ("Why does git do it
git also lacks a good API that svn, bzr and hg have, and seems to be a mish-
mash of stand alone programs (with a monlithic library - ?) - some of which
are written in shell or Bash - that emit inconsistent output, which is mostly
human readable (though is often too verbose, IMO), but I'm not sure if it's as
easy to parse as that of the Subversion svn client, to say nothing of using
the svn ANSI C APIs or Perl/Python/Ruby/Java/etc. bindings.
Another aspect I dislike about git is not technical but social: its hype. git
converts tend to be arrogant, snobbish, boastful (about git at least) and blog
about it indefinitely to everyone's displeasure. It's possible that they are a
minority, but they are a loud and vocal minority and I dislike it. I don't
think believe in a conspiracy theory that there's a single corporate entity
hyping git as was the case for Sun and Java at the time, but even grassroots
hype tends to be a big red flag for me.
Looking back, I can recall many technologies that were not hyped at all,
whether by the community or by a company, and yet proved to be very popular:
HTML, C, Perl, Unix. They tend to have gotten established by the time most
people have heard about them. None of them are perfect, but many hackers are
still fond of them. There were many fine technologies that were hyped or even
still are, but I keep feeling that those who hype them tend to hide something,
and are not completely honest about their limitations, which may often make
them a non-starter even for hard-core hackers.
I have learnt git and it's not too bad, though as Shachar indicated may be
very dangerous and destructive for allowing you to lose history (at least from
what I understand). However, I still find the hype suspicious and a vice to
* Mercurial / hg - I've recently played with Mercurial, and even worked on a
few projects using it. I found it easier to use than git, a bit less counter-
intuitive than Subversion (there are usually useful workarounds) and pretty
nifty overall. I did run into a case where it didn't do the right thing after
having several clones of a remote repository which caused the Directed Acyclic
Graph not to merge gracefully. It's reversible, I think, but still threw me
off due to my expectations with the non-DAG-based Subversion.
Nevertheless, hg seems to combine some of the best advantages of git and svn,
while having relatively few disadvantages of its own.
There are many other FOSS players in the version control system, and naturally
there are many low-quality and high-quality proprietary alternatives, but
these seem to be the most popular 3rd generation version control systems
(after RCS and CVS).
[better-scm] Caveat: better-scm is a site I originated and still am the
primary maintainer - there may be similar sites elsewhere, and naturally, one
can contribute to it by sending me patches.
[intuitive] You are probably familiar with the old quote on one of the Linux
newsgroups that "The only intuitive interface is a nipple. Everything since
then is learned." This quote, while amusing and while it has a grain of truth
to it, is not true. First of all, intuition (as opposed to say "instinct" or
"inborn tendency") is something that we acquire as we go along. Reportedly,
the differences that were discovered in the brain's biology between males and
females, may be in a large part due to different treatment and baby care from
the parents and from other people. (On the other hand, according to Feeling
Good, one's favourite flavour of Ice Cream is believed to be mostly influenced
What I'm trying to say is that we come to use a certain program (or even a
library or API) with certain kinds of previous expectations brought on by
years of previous experience with the real world or with computers. Some
programs are very easy to use straight away. Some require a substantial amount
of training and research, even if you're a geek. I'm not claiming the latter
approach is necessarily worse, but we all agree that building an intuitive
interface that is easy to get accustomed to has its merits.
I recall that back when I was looking for a better job as a programmer and
went to visit my future boss who told me about the wonderful productivity of
Perl and showed me a small program he was working on (without syntax
highlighting, though), and despite the fact that I had already known C and
BASIC, I could not make a lot of sense of it. Later on, after I studied Perl,
I found it a joy to use and a good productivity boost, because it combined the
advantages of both BASIC/QBasic/etc. and C (while still being somewhat slow
and memory hungry, though, but this is usually not a large concern for me.).
On the other hand, a Teluxer once told me that he did not understand what the
Python-ILers have to discuss because Python was trivial. (He had done a lot of
Perl). He told us that he once looked at a Python program and while knowing
very little about Python, was able to hack on it right away. However, while I
can be productive in Python, I still often miss many of Perl's advanced
features, which are completely non-existent in Python due to design choices
and "There's one good way of doing it"-ism. This is similar to the fact that I
sometimes write funky code in Perl to work around the lack of Lisp's macros.
So Python is more intuitive than Perl, but it comes at the cost of smaller
expressiveness. (I don't want to start another Python vs. Perl holy war -
let's not go there.).
Shlomi Fish http://www.shlomifish.org/
Optimising Code for Speed - http://shlom.in/optimise
Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
More information about the Haifux