On May 18, 2010, at 7:14 AM, Jack Howarth wrote: > I can't find the link at the moment but I am pretty sure that > hardlinks have a significant performance penalty under HFS > compared to symlinks. I recall it being something like 10-fold > slower because the hardlinks are kept in a flat file system > and HFS would require an rewrite to solve this.
So, so far we have a number of "interesting assertions" here: 1. Hard links don't play nicely with Time Machine 2. Hard links are not adequately accounted for by du/Finder/etc in determining the number of blocks allocated to MacPorts 3. Hard links are slower than symlinks under HFS Sadly, each and every one of those assertions is also false and would have been provably false had anyone actually decided to crunch some numbers (or "try it") for each assertion. Can we try to keep things at least reasonably factual as we debate the differences in Homebrew vs MacPorts? It will save time and energy. :-) FWIW, we *did* have problems with ports not respecting symlinks or otherwise becoming confused, which is why the current hard link scheme is used. I'm sure it would also be simplicity itself to make this a knob (use_hardlinks: true) in ports.conf and let folks try the hardlink or softlink approach to activation to see if it's still a problem or if those historically misbehaving ports have since started to behave better in the presence of symlinks. If you're genuinely curious about this then knock yourself out, in other words, since it's probably under 10 lines worth code change, max, to substitute one type of link for another. On the subject of Homebrew's advantages, I guess we have at least a few obvious ones. 1. It's easy to create a fork of a port, using git to do the branch management. This is similar to what various folks envisioned for the "remote index" feature which was never completed. Joe Blow can grab a port, edit it or use it as seed corn for an entirely new port, and submit the results of their work back up to the main repo without having to necessarily be a committer. The committers, in turn, can look through all the submissions to some "experimental, public contributed branch" and merge things as they have the opportunity to test them, those "pre-ports" also being available to the community at large until such time as the committers get around to either incorporating the port or arguing why it needs to stay experimental. 2. Ruby's iterators do make some things more concise / easy to understand than they are in Tcl, e.g. inreplace filelist do |contents| ... stuff which munges file contents ... end. You could also ostensibly inherit from one Formula to another, though I don't see any evidence that this is used anywhere in Homebrew 3. They have some cool beer related terminology throughout their system, and who doesn't like beer? Other than that, I really don't see a lot of value, and I see a lot of things still missing over what MacPorts already has. I don't see a replacement yet by any means, no matter what the folks on twitter are saying. :-) - Jordan _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
