Hacker News Reader

Comment by bretthopper | Hacker News Reader

It's not just Launchpad that's "SysAdmin" friendly. Sourceforge and Google Code are much closer to the Launchpad model than to Github's.

I know Zed Shaw isn't saying one is better, but doesn't the popularity of Github compared these sites tell us something?

View on HN

All its telling me is that I want a whole OS based on the Github model. I like the feel of working on github, I'd like to take the RVM/rubygems/github theme and extend it past Ruby, to the whole OS and its package manager.

That was my idea too, and why I started working on a light fork of pkgsrc to try it. Sadly, nobody who has to maintain systems at scale will use a package manager that just pulls random repos and "makes and prays". I've been trying to find the middle ground since then but haven't come up with it yet.

Though I presume you know about it, I haven't seen Homebrew[1] come up yet. It has native support for installing from tarballs and pulling from repos.

[1] http://mxcl.github.com/homebrew/

Maybe I misunderstand how MacPorts works, but I vaguely recall seeing it pull source code directly from projects.

MacPorts? I was using NetBSD pkgsrc, which does either source builds or packages from the same system. So, you can lock it at a particular source revision/release and make an official package like a .deb, or do a gentoo/MacPorts style source build.

As I understand it, Arch's pkgbuilds are similar. The nice thing is that they have the flexibility to do whatever you want, whether it be updating a svn repo, downloading a binary, curling a script, building from source, whatever.

You wonder how much sysadmin effort would be saved if they didn't have to deal with shared libraries between packages. Is it a case of the sysadmin practices not keeping up with the current abundance of disk space/ram or is there still a case for the efficiencies of the shared library model?

The shared library model ensures (at least for C/C++) that if a bug has been found and fixed in certain library, all packages that depend on it will take advantage of that bug fix. Imagine how many packages would need a rebuild if let's say the openssl package has been updated by the vendor and openssl has been linked statically into applicatons. Using the shared library model eliminates the need for rebuilding all packages that depend on a given library, if the given library has been updated.

Shared libraries can also make more efficient use of RAM and sometimes even of cache RAM. Every time you don't have to move something to where you want it because it's already there, you get a speed win.

Reply on news.ycombinator.com