Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sheddingbikes.com

Post reply on HN
Print view View original

51–60 of 67 posts

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

#51

Post by thyrsus »

ollysb wrote: post #35
Andys wrote: 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?

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.

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

#52

Post by bradleyland »

zedshaw wrote: post #30
tedreed wrote: post #24

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…

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

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

#53

Post by bradleyland »

pyre wrote: post #43
zedshaw wrote: post #32

Earlier quoted context omitted.

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.

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

#54

Post by mpk »

davidw wrote: 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.

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

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

#55

Post by jacques_chester »

rbranson wrote: post #22
jacques_chester wrote: post #18

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…

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.

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

#56

Post by jacques_chester »

rbranson wrote: post #22
jacques_chester wrote: post #18

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…

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.

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

#57

Post by uxp »

kunley wrote: post #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. Th…

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.

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

#59

Post by tedreed »

Macha wrote: post #50
tedreed wrote: post #36

Earlier quoted context omitted.

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

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

#60

Post by tedreed »

bradleyland wrote: post #52
zedshaw wrote: 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 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 applicati…

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.

Post reply on HN