It's just coloring the standard diff output so lines starting with > or + are yellow and ones starting with < or - are green. This is also what "git diff" does by default: http://www.jefftk.com/git-diff-color-2x.png
diff -y is side-by-side. As far as I know colordiff does per-line coloring, while icdiff seems to have finer granularity. This dude really should have patched colordiff, though. Or just used emacs.
colordiff is just a perl script to colorize diff's output. Patching it to add support for the kind of coloring I want to do here would be a lot of work.
As for using emacs, there are many cases when I want a stand-alone diff tool.
Correct me if I'm wrong, but most of the things (or maybe just the ideas?) you have implemented seems to be coming from NetBSD. If so, could you share other NetBSD stuff you'd like to see on Bitrig ?
For me personally, better armv7 support. Even though many things stem from our hands, NetBSD and FreeBSD are a great resource. I have already started working on SMP support, based on their example.
Otherwise I do not have any NetBSD stuff in mind. Can't speak for our other developers though. ;)
I would love to have FreeBSD's bhyve on Bitrig. I will dedicate some time in January for that goal. DragonflyBSD is an inspiration for us, too. We have an experimental branch (smpns) for revamping the kernel for decent SMP support.
Just curious, what's wrong with Homebrew? I'm just a student, not a full-time developer, but I've never had problems with it and find it pretty pleasant to use.
I use a macbook for the battery life and the no-hassle experience (which is getting worse everyday, but that's a different discussion). Homebrew works against these two principles in multiple ways. Compiling software takes massive amounts of time; if I need to install something I want it now, dammit. In principle, there are some binary packages too, but when I tried homebrew there were not for anything that I needed.
Apart from time, compiling software consumes energy, decreasing the autonomy of my laptop.
But those are not the main reasons I dislike homebrew so much. My main gripe is that the packages are of extremely poor quality. When I needed something, it was not compiled with the options I needed. E.g. packages were missing DTrace integration, QEMU was missing the one target I cared about etc.
I am a Go developer; you have no idea how many problems people have had with the homebrew package. It is garbage. And Go is quite trivial to package compared to other stuff. I simply gave up on helping anyone reporting a problem if he is using homebrew. I ask them to recompile Go from official source first.
And then there's the whole curl into bash things, gah I'll just stop now.
The biggest advantage of pkgsrc (apart from quality binary packages) is that I can use the same package versions, compiled exactly the same (to the extent possible) on OS X, Linux, and Solaris; and these are production-ready releases used in production by Joyent (and others) vetted by actual release engineers.
And with pkgsrc it is trivial to install from source when you need to modify a package locally (unlike, say, with apt).
It's slow and it has to build the packages most of the time. pkgin will install a precompiled packages very quickly. It is also a whole C program and Homebrew is just ruby scripts.
> It is also a whole C program and Homebrew is just ruby scripts.
And that's a problem?
I would argue that it's a feature. Due to Homebrew being written in Ruby, it has easily allowed over 4,000 contributors [1]. Recipes are easy to read and inspect for verification purposes.
So the opaque pre-compiled blob that installs other pre-compiled blobs is somehow better than a collection of scripts that lets you build from source? I don't think so... As an update is something that is done occasionally and in the background "slow" is not exactly a reason to change.
(On a sidenote, I got into Arch because I heard hype, but did not even like it until I recognized the BSD outlook, with ports and pkgsrc style tools. This is very cool, and now I know what to use if I deal with OSX again!)
