Zed Shaw: Launchpad vs. Github/SysAdmin vs. Coder | Hacker News Reader

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

sheddingbikes.com

179 pointsthesethings64 comments

As a sysadmin, I have to say that I hate Launchpad. I always have click many levels deep to find the thing I want. The interface just sucks.

I also know plenty of other sysadmins who use github but find no value at all in Launchpad.

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.

Edited to add: I also think that if it's not immediately apparent which fork is the "canonical" one, it probably doesn't matter. Just grab whatever looks most popular. If you decide you'd rather have a different one, then grab that later. shrug

> 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...

Then you got no business being a sysadmin and working this way.

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)

Yeah, but I wouldn't install alongside. (Nor do I install anything via gem.)

I definitely live more in the sysadmin camp than the programmer camp, so I can see exactly what you're saying without even reading the links.

A programmer is prepared to dive deep. The programmer writes tests that validate their assumptions at ever level. The programmer lives intimately with their project.

Contrast this to the sysadmin. The sysadmin lives wide. He/she has to support many developers and many applications. These days, it's popular to use virtualization to isolate applications in their own little world, but it's also horribly inefficient. I love virtualization because it lets me get the most out of my hardware, but as a responsible sysadmin, I group applications in ways that make sense, rather than firing up a bare bones container for every app. This means that I must maintain some sense of consistency and order in the environment. Imagine the sysadmin's frustration when every programmer they work with thinks it's ok to grab any randomly forked lib from Joe Blow's GitHub repo and expects the sysadmin to integrate it in to the environment. It's a change management nightmare.

Being a sysadmin is about fostering stability and consistency. The server must be up. Apps must be up. The sysadmin's job is to make sure those two conditions remain true, and the "fork and go" mentality makes it a nightmare.

I'll agree to some extent about the consistency, but I don't think that the "fork and go" mentality makes stability any worse.

I mean, as it is, I see segfaults and whatnot regularly in the canonical, distro-released versions of Apache. Major software releases all the time with bugs that could potentially be a show-stopper. My experience hasn't shown this to be any worse with non-canonical sources. Sometimes it's better.

Further, I like to think of the sysadmin's job as fostering business continuity. While uptime is a primary indicator of this, I think it's lower in priority than say, losing a crapload of customer data. If I have to shut a site down for an hour to prevent losing all transactions for the previous 24 hours or something, then it's not a terribly difficult choice. (Having to make this choice at all, of course, means you should be engineering something better. But we don't have the luxury of infinite time.)

And having all the uptime in the world won't help you if your engineers can't do their jobs effectively because the tools you give them are insufficient. Sometimes the best option is to suck it up and try that patch.

It's a delicate balancing act, and I'm not by any means advocating running all your software out of unofficial repos. Sometimes you gotta make that call, though. And if I'm looking at github at all, it's probably because a package doesn't already exist, or because I need a fix for one specific bug.

Even worse nightmare is pretending that the code is more stable just by labeling it as "package vX.Y.Z" and hiding the actual meat behind such "profesionally" looking cortain.

And yes, I'm an admin for 15 years.

My experience is when software is bad, it's just bad. No packaging system will help it. If I have a suspicion it's bad, I want to see quickly just how bad it is and check if I can repair it in half of an hour or drop entirely. Github helps with such decision greatly.

I'm not making the argument that giving a package a static label makes it better, I'm arguing that it makes it more consistently identifiable. When you're trying to figure out what's breaking your system, consistency is the key to isolation.

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.

When I visit a GitHub page of a new project that I find interesting, I would like to hack on or use as an end-user I don't even have to click on the clipboard icon to get the URL. I just take the URL straight from my browser and put it into my terminal to obtain a local copy over https, or by changing https to git and adding .git at the end:

    git clone https://github.com/USER/PROJECTNAME
    git clone git://github.com/USER/PROJECTNAME.git

Can you tell me off the top of your head how to checkout the source for $RANDOMPROJECT on sourceforge? What's the common URL to browse the sourcecode? One of my buggest complaints about sourceforge is that there is no easy way to grab an actual URL of a package for a project to download without manually editing it if you wanted to cURL or Wget it to a remote server you are shelled into. After enough years I've learned to download packages from sourceforge using this URL form:

    curl -O http://MIRRORNAME.dl.sourceforge.net/project/PROJECTNAME/SOMERANDOMFOLDER/PROJECTNAME-PROJECTVERSION/PROJECTNAME-PROJECTVERSION.tar.gz

My hats off to the guys at GitHub. They took usability to the next level.

> Can you tell me off the top of your head how to checkout the source for $RANDOMPROJECT on sourceforge?

I can't. That was the point, I'm always lost there..

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. :-)

"Programmers don't care about version numbers, release history, bug trackers, mailing lists, nothing. Especially if the project is relatively small. Just the code please."

I disagree. Experienced programmers definitely care about bug trackers and version numbers. Once you get bitten by version skew or lose a day trying to reproduce a bug against a wrong version, you start to care about such things.

And small projects are just big project that haven't grown yet :)

As a programmer using the code others publish on Github, I'm definitely interested in those, the more so when I want to contribute. Many project are sorely lacking a way to report and discuss (possible) bugs (bug tracker, mailing list, hell, an email address would be fine) and to figure out what version of the code contains what (release history/changelog and version numbers). However small, I find projects without those much harder to use and improve.

Yes - the administrative stuff is important when contributing. Bug tracker + versioning might save you effort in cases when the bug you found is already being worked on or maybe even has a fix waiting for release.

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://junk.launchpad.net/~jmillikin/ that I could just ``bzr push`` random stuff to and have it show up.

† Zed suggests this is due to developer vanity, but actually I see no need to pollute the precious global namespace with half-baked code.

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.

That's about the model Gitorious uses (minus the integration into debian packaging and apt repositories).

In Gitorious the project is the main resource. Developers can be working on a project and they get their own area where they can put forks of the project or other one-off stuff.

You can even easily (for a definition of easy as "doable with some effort") host one yourself for internal projects as it's available under AGPL.

It's still not as easy to use as github (due to the project hurdle and less refined UI) and the public service lacks what makes github especially good: the large community of users

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.

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 Homepage link.

See? That's the same as me telling you that to find the code on Launchpad you just... A packager doesn't want to navigate the bizarre tree of forks and junk, they just want official releases. A programmer could care less though.

Then, because projects live under a person, if they want to transfer ownership, the whole damn project basically goes dead and you have to track it down again. Again, if I'm a sysadmin that sucks since I have to keep up on their internal politics. If I'm a programmer I go, meh, and just pull the new stuff.

Haha, I guess I'm proving your point since I'm a programmer and I'm having a problem seeing why navigating forks is such a bad thing.

Plus, I usually just let Moonshine/Puppet take care of the sysadmin part for me and trust that it will grab all of the right packages. The people who write the Puppet recipes would probably feel very differently though.

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.

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...

It's not a "people" issue. How does one discern the canonical source of a package on GitHub? Take GitX as an example:

The "top parent" project: https://github.com/pieter/gitx

Andre Berg's fork: https://github.com/andreberg/gitx

The Brotherbard fork: https://github.com/brotherbard/gitx

Which is "the project"? The answer is all of them AND none of them. That's the nature of GitHub. Zed's point is that for a sysadmin, all this obscurity is unacceptable. Having a canonical source for a package is important. That source should obscure away who the actors are making the package happen. If Pieter wants to hand the project off to Andre, who in turn hands it off to Nathan, that's great, but the sysadmin doesn't really want to track that for every package he/she installs on their server.

That is why launchpad is better for sysadmins. Not because it is better in any general sense. Just because it meets a different set of needs. These are not criticisms of GitHub, these are statements of the reality.

The closest thing GitHub has to a "project" abstraction is the organization:

https://github.com/blog/674-introducing-organizations

One could, conceivably, create an organization to manage a project's code, but that doesn't address all of the other package ecosystems that Launchpad executes more deftly.

I was responding to Zed complaining about automatic build systems knowing where to pull their sources/builds from.

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?

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.

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.

Well, github can do that too. You can set up an organization that isn't tied to any particular account and manage repos from there.

Projects start out as one person messing with code. Of course the project belongs to one person at that point. As more people join in you can re-structure the project into an organization with multiple owners.

Check out the announcement from June 2010 https://github.com/blog/674-introducing-organizations

The problem is that GitHub has no way to point the original project to the official project. The new organization project will still say "forked from" the original person's project.

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.

The last paragraph is making me think...

"Really I think you need a 3rd system that's radically different."

I think he's right. I'm not sure what that 3rd system would look like. I wonder if a meta-service piggybacking on both Github and Launchpad would work?

Well, I cooked up an idea:

http://fmlr.me/

But, sort of got stuck at how to do the client. I've recently relearned GUI coding and will probably dust the idea off and try it again soon.

Hmm...It would be interesting if one could subscribe to a personalized feed of some sort. Currently I skim my github feed in Google Reader every couple days. The biggest problem with it is that I watch RVM, which is fairly high traffic. It would be neat if I could subscribe to, say, only tag pushes on the RVM repo.

This is a superb concept. Would you subscribe to people or projects or both? Where would the user questions come from?

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.

Here's a thought-bubble about packaging and distributions.

In a single piece of software, the compiler can enforce some degree of consistency between different components. In a distribution this is done manually. That's why it scales poorly.

Possible solutions:

* Cross-application consistency checks. This seems to be the way Singularity is heading.

* Smaller distributions -- or rather, standalone VM images that have a carefully curated mini-distro built around single applications.

The VM image idea might be most palatable under a kernel-threading scheme like Linux OpenVZ or Solaris Zones. They are very inexpensive and quite efficient.

The key is not about CPU/RAM/IO efficiency, it's administrator time efficiency.

I mean, you're absolutely right; but at a certain level it's irrelevant.

The key is not about CPU/RAM/IO efficiency, it's administrator time efficiency.

Launchpad is kind of poorly designed, looks a bit messy. I think that matters too.

As a middle ground, how does Google Code work? The project lives under its own name and has specific, transferrable maintainers, but pulling source code is very easy and it's easy to see changes as they come and go. On the other hand, GCode isn't based only around DVCS, so the fork model doesn't work as well.

I thinks this is fairly wrong as its more of a project based (launchpad) vs code based(github) approach. Sys admins can write a decent amount of short scripts which don't mesh well with a project based approach, many programmers may prefer github for scaling down more and making the code easier to find but the more stability you want the more you might like a project like approach(until you want to make a quick contribution). I bet lots of larger teams might prefer to grab a library of launchpad.

> The second you made Github more "SysAdmin friendly" you'd piss off the Programmers. Their egos are too softly stroked by having their name first in the URL.

I don't think that's true. Having the name first is great for uniqueness of the fork, but has been a pain when finding the canonical version. I've seen plenty of projects that adopt the similarly named user account, which is great.

Especially with organizations being free (for open source projects at least), I think this usage will increase for github.

As for Zed main argument, I am not sure it is the whole story. I think the launchpad vision is great, but the delivery mostly a failure. The fundamental idea of being able to track downstream bugs in a project sounds really right to me, but launchpad UI is really a big mess: you need a lot of hoop to get the code. Sure, you can do lp:foo for project foo, but few people know bzr, and for a long time, there were numerous issues between different incompatible bzr versions (which have been fixed ever since I think). Forcing people to use bzr has been one cause of failure I think.

I also wonder how much differences can be attributed to how the things came to life: launchpad wanted to do many things from the start, wherease github grew organically.

I don't think the launchpad UI is a mess, if you don't expect to be able to browse code in it. The code browsing is horrible. But, the PPA, branch tracking, bug tracking, and other stuff is great.

I can tell you from personal experience though that github's bug tracking is stupid as all hell. Remember that whole blow-up over my book and people turning one damn bug into a massive flame war? That all happened because I couldn't figure out how to contact the project owner directly and figured the bug was the best way to do it. Little did I know that this would turn into a massive idiot festival with no way to turn the damn bug or emails off.

So, I disagree, launchpad's UI is only broken if you're into code. Github's is broken if you're into projects. Too bad they both can't just make both use cases a nice experience.

i think the odds of the github folks figuring out projects are far greater than the launchpad folks sorting out code (or proper whitespace and padding, for that matter).

that said, i do think that launchpad has some excellent attributes, like a bug tracker that doesn't make me want to defenestrate its author.

I agree that github's bug tracker is quite limited (for some reasons that I cannot pin point, bug tracking seems really hard to do: that's the only example I can think of of a fundamental part of any developer toolbox that has no great open source implementation).

As for launchpad UI, code browsing is indeed the worse part, but I find the whole thing difficult to understand. For example, we created a page for scipy quite some ago (https://launchpad.net/~scipy), and still today, there is no hierarchy in the information. For example, where can I download the software(and I do mean the releases, binaries if possible) ? A lot of the UI space is spent to convince me to subsribe to the project, or give me information that I really do not care about if I just want to use or install the damn thing for my users if I am an admin.

Also, stuff like email UI to subscribe/create bug has been horrible for a long time in launchpad(I have not checked recently, maybe it has been fixed).

That was a joke. You know, those things that make people laugh? In seriousness, it sort of doesn't matter if you're a programmer. Either way works so long as the first thing you get is code. If you're a sysadmin or packager though, that's annoying as hell. You want to just go to /project and not worry about the who's-who of forks.

Zed, I'm a robot, so I'm impervious to jokes, especially deadpan sarcastic ones without proper metadata :-)

And I agree with your serious statement. Yay, happy!

False dichotomy. Also, github puts the author name before the project name for namespace reasons, not for egotistical ones. At least do your research before bashing them.

You know, I think the cornerstone of Lame-Trolling is pretending like you failed every reading comprehension class in grade school.

Reply on news.ycombinator.com