Live data from Hacker News

Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

sheddingbikes.com

41–50 of 67 posts

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#41
post #4

It's definitely annoying when you are trying to find the "canonical" fork of a project on Github, but it's not THAT hard to just look under the project name and click on the "forked from xyz/project" link (projects rarely go more than a couple of forks deep), or in the worst case click on the network tab and look at the tree. Edit: If it's a Ruby Gem, you can also look up the gem on rubygems.org and click the Homepag…

Looking at the "forked from" field doesn't tell you whether a) it's a random forker who wanted to make a few changes, in which case you want the original, or b) the original project changed hands or was abandoned and the forked version is canonical, in which case you want the fork.

That's not the only problem.

Even with the network tree, you're still screwed, because Github's network graphs are incomplete. Take this brief conversation from ruby-talk last year:

    http://www.ruby-forum.com/topic/203100
I challenge you to deduce the result of that discussion from the information available here:

    https://github.com/rightscale/right_aws/network
Right now, without delving into the code, I still can't tell which one is supposed to be canonical, if they've diverged irreparably, or if it just doesn't matter which I pick.

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#42
There's also one issue not mentioned in this article:

Lots (if not most) of the code has documentation so poor, that there's no way to determine what it's really worth other than looking at the code, examples, tests. Github does it right by enabling you to browse the code right away and make your opinion.

This is also the reason why Sourceforge and other *forges are doomed - and to a lesser extent google code too. They present complicated interface but all in all you end up downloading the tgz only to determine later that in most cases it wasn't what you're looking for. All that buzz because of the premise that said package is actually worth your attention. Well, usually it's not (but probably is for someone else). So it is right and sane to give an opportunity to decide it as quickly as possible, by showing the code tree as quickly as possible.

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#43
post #32

Earlier quoted context omitted.

Anyone who's paying attention will update the readme in the stale fork to make it really obvious. People don't sometimes because they're lazy, but this is an application of the more general "people suck" rule, and not very specific to Github.

Oh, in the README? Duh. I totally didn't think of that awesome way to communicate to all the package management build systems out there that the repository has moved. I'll get right on building the Turing Oracle so I can solve that "README File English As Redirect" problem.

Right, because package management build systems have obsoleted the need to package managers to be actual people that keep track of the packages that they manage...

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#44
post #35
post #15

Earlier quoted context omitted.

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.

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.

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#45
Launchpad was conceived from the perspective of an organisation optimising the process of working on and building Debian packages (Ubuntu/Canonical), designed the same way 90s three-tier systems were: database schema first, and built as a monolithic platform rather than iteratively as a user-facing product.

Zed Shaw is trying to divine the failures of Launchpad backwards. When you know the story behind it, it becomes brutally obvious. :-)

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#46
post #38

Good open source projects are projects , which are made up of code and people. I've never cared for the idea that a project belongs to one person on github.

Agreed. I've seen projects that have their own username to host the project repository (or repositories), rather than using the author's username. Quicklisp does this, for instance.

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#47
The problems I personally find with launchpad are:

a) It's slow. Pages seem to take an age to load.

b) I can never find anything.

My problems with github:

a) Fork queues never seem to work. Support will occasionally respond to complaints and fix a specific one, but never the general problem.

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#48
post #13

I really wish Launchpad had at least some support for the GitHub model. Sometimes I don't want to register a project for some half-hour code dump; I want to push it out, namespaced under my uid† to an easily locateable repository. The +junk feature sort of does this, but it's a lot more awkward to use than GitHub because viewers have to jump through flaming hoops to get to the code. Ideally, there would be a http://j…

Hmmmm, that's a damn good idea. /project is for projects, and the canonical true ruler of such. /~dude is for programmers and their forks, half-baked ideas, and random pushes. Yeah, that'd work.

If anyone does something like this, I'd suggest supporting not just http://junk.launchpad.net/~jmillikin/ but also something like http://junk.launchpad.net/~~jmillikinpersonalwebsite.com/ , embedding other domain names in URLs for your service (with a policy of only permitting people to set up such double-tilde URLs in your service when they control the corresponding domain). Then to the extent that your service ever enjoys a success disaster where newbies naturally discover that all the mnemonic usernames like newman and whn and wnewman are already taken, you have relieved the pressure by providing a mechanism to delegate the unique name problem to the existing domain name system.

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#49
post #16
post #15

Earlier quoted context omitted.

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/

Re: Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder

#50
post #36
post #30

Earlier quoted context omitted.

> Also: FWIW, I never notice folks' names on github. The important thing for me is that the code is right there front and center. If I want to download it, I click the clipboard button and then go clone it. Boom. Yeah, I think "BOOM!" is right. If you can't see the flaw in stuff like this: http://drnicwilliams.com/2009/11/04/hacking-someones-gem-wit... http://groups.google.com/group/gemcutter/browse_thread/threa... T…

I see a number of things discussed in those links. Could you clarify which you're referring to?

From my reading of it (disclaimer: I've only done a tiny amount with ruby) A package uses rubygem to install a-blah 1. This causes packages using require 'blah' that are not connected to rubygems to break if the a-blah installation overwrote an existing version of blah 1.1 (which you installed alongside said packages)
Post reply on HN