Berlios is dying…

I just got word that berlios.de, where I have several projects hosted including GPSD, is going to shut down at the end of the year.

This is a huge pain in the ass. It means I’m going to have to bust my hump to get us to new hosting space. Moving the git repo won’t be bad, but moving the mailing list and bugtracker content is going to suck. What’s worse, all the project URLs are going to break.

Back in 2009 I launched a project called forgeplucker to address this sort of migration problem. It stalled due to a flaky hosting site…

36 thoughts on “Berlios is dying…

  1. Imma let you finish but I just got to say that GitHub is the best open source repository host of all time!

  2. You’re a Unix guy. The solution is obviously to finish forgeplucker and move it that way rather than an ugly manual hack.

    Isn’t that the Unix gestalt?

  3. >What’s worse, all the project URLs are going to break.

    I am no expert about these things but there should be a way of making these relative and thus easily to survive moving with a bit of dynamism, some sort of a $ourcurrendomain/projectscope.htm way of thing…

  4. What’s worse, all the project URLs are going to break.

    Domain names are cheap enough that you ought to be able to buy a domain name for each project and point it at whatever server is actually hosting it. Redirection from project.org/$foo to hosting.com/blah/blah/whatever/$foo should be fairly painless as well, but the trick is to get people to bookmark the right page.

  5. Hrm, maybe some sort of listserve, forum integration within gitthub or a package that can connect it, which would make migration trivial… or is that what forgeplucker was trying to do?

  6. Most of the major branches of berlios,de are of the form xxxxx.berlios.de.

    Possibly you could get them to agree to allow standalone domains to be created for each section: ie sourcewell.berlios.de would point to a new IP address not the present address.

    Effectively they would have to licence the use of the berlios.de portion. If that is not possible for DNS reasons (and I think it might be) then how about using redirection as Monster posits, but from the sourcewell.berlios.de level.

    Wonder how many gigs they are presently hosting. Been years since I have looked there, but they had a great OS/2 repo many years ago…and still do I suspect.

  7. Use the Donald Knuth method. Offer $0.01 for the first broken link that users find, $0.02 for the second, $0.04 for the third, and so on…

  8. wonders if it would be possible to dual host this sort of thing – use say Sourceforge and github and have emails/links etc. replicated from one to the other. That actually could be a really useful extension to forgeplucker*

    And er yes I know I’m proposing someone else do more work.And err 2 I know that you might need to require that a project, email list etc. conform to certain normalization standards before it can be dual hosted. But it would be very good for these kinds of situation

    PS I’m with David Scott Williams – mad props regarding the name

  9. I’m with Archive Team; we’re gearing up to snarf down the entire site. I’ve been looking over the ForgePlucker source code, and I have to say that I like it; we’ll be using it to grab the BerliOS Developer portion of the site.

    I’d like to invite everyone here to jump in and lend us a hand; we’re coordinating the project on our wiki at http://www.archiveteam.org/index.php?title=BerliOS#Site_Organization.

    Eric, were there any known bugs in ForgePlucker that didn’t get filed? These kinds of things can fall by the wayside in a moribund project, so I want to make sure we get those out of the way first.

  10. >Eric, were there any known bugs in ForgePlucker that didn’t get filed?

    No. It works pretty well, as far as it goes.

  11. I see you’re shutting down hosting the code I love, and I’m like,
    Pluck you!
    Oo-oo-ooo

    I guess the change in your pocket wasn’t enough; I’m like,
    Pluck you!
    And pluck them too!

  12. And then the company that’s providing your server’s connectivity charges you too much for bandwidth when your server gets popular, and you can’t find someone more reasonable, and you go offline for financial reasons.

  13. Quit whining like a little bitch, Eric. Just do the goddamn work and if you mean to ask someone here for hosting space or help, ask.

  14. >Are we not hackers? There is no substitute for running your own servers!

    Hacker we are, but we like system administration to be someone else’s problem whenever possible.

  15. > Hacker we are, but we like system administration to be someone else’s problem whenever possible.

    No true hacker believes this. Yes, SA is a PITA, no we don’t think others can do it better than we.

    > Moving the git repo won’t be bad, but moving the mailing list and bugtracker content is going to suck.

    To their credit, Berlios is giving directions on how do accomplish exactly that.

    http://developer.berlios.de/docman/display_doc.php?docid=2056&group_id=2

  16. On a possibly-related note, wesnoth.org seems to be missing–cached copy works, but the browser can’t find it and pinging gives a DNS error. Thoughts why?

  17. > wesnoth.org seems to be missing

    Works for me, but whois shows that something changed in the DNS for wesnoth.org yesterday.

    In other news, Chrome should ship for Android in October.

    http://www.conceivablytech.com/9480/products/google-ready-to-run-with-chrome-for-android

    I really need some session syncing between laptop, phone, and tablet. This should be the beginning of the end of Android apps written in Java, too.

    Nexus prime and Ice Cream Sandwich are also due to ship in October.

  18. Seems to me that the most robust long term solution is to point git.yourdomainname.com to github.com/yourproject using a CNAME

    Then if github goes evil, crazy, or goes out of business, or you decide you like a cooler git hosting service, then point git.yourdomainname.com to the new service, reducing, though not eliminating, url breakage.

  19. > Hacker we are, but we like system administration to be someone else’s problem whenever possible.

    I am not a hacker; more like a hobbyist, but I believe in this principle. Routine things should not be our headache, particularly if it’s not our actual profession or job.

    Moreover, not all of us have the facilities, infrastructure or the money to lavish on high-bandwidth web servers.

  20. >No true hacker believes this. Yes, SA is a PITA, no we don’t think others can do it better than we.

    You should study the principle of comparative advantage. No matter how exceptional I am at system administration, if I’m more exceptionally effective at programming the efficient allocation of time is for me to do programming and someone else to do SA.

    In fact, I’m not an exceptionally effective SA, because I don’t enjoy accumulating the kind of domain-knowledge details that an exceptional SA requires. I’m extremely experienced, and possessed of a sort of hard-won cunning that sometimes substitutes effectively for domain knowledge, but…it’s not quite the same thing. The world is better served when I program.

  21. > Hacker we are, but we like system administration to be someone else’s problem whenever possible.

    >> Routine things should not be our headache, particularly if it’s not our actual profession or job.

    Routine things ? Isn’t that what computers are for ? Whenever I have to do something system administration task a second time, I try to find ways to automate, so I won’t have to do it a third time – except for things that I anticipate to be recurring, those I try to automate from the start.

    “data availability”, especially making your data future-proofing in the light of vendors or service providers going out of business or technology and media becoming obsolete, is one of the things a decent system administrator would concern himself with.
    It’s not an easy problem with routine answers (yet).

  22. >>Routine things ? Isn’t that what computers are for ? Whenever I have to do something system administration task a second time, I try to find ways to automate, so I won’t have to do it a third time – except for things that I anticipate to be recurring, those I try to automate from the start.

    I think there’s a difference between having SA as a job and SA your own machine for optimized hacking efficiency.

  23. > I think there’s a difference between having SA as a job and SA your own machine

    sure.
    As long as it’s just your machine, your data, etc, who cares how you manage it ?

    But I think being responsible for other people’s data — which includes open source projects’ source repos and communication infrastructure — is worth doing right, whether it’s a (paid) job or not.

  24. > In fact, I’m not an exceptionally effective SA, because I don’t enjoy accumulating the kind of domain-knowledge details that an exceptional SA requires.

    ESR knows nothing about *nix.

    ’nuff said.

  25. “ESR knows nothing about *nix. ”

    *nix SW dev knowledge != *nix SA knowledge.

    You’d think anyone who knows anything about any OS would know that. You’d think.

  26. kn said: But I think being responsible for other people’s data — which includes open source projects’ source repos and communication infrastructure — is worth doing right, whether it’s a (paid) job or not.

    I think (guessing, but I think fairly and accurately) that ESR thinks that, too.

    Which is why he doesn’t want to do it himself.

    (And on the SA/domain-specific knowledge thing, I’m with The Monster; I’m sure Mr. Raymond knows how to do pretty much every normal unix SA task.

    I’m also sure that someone that does them for a living, and is Good At It, knows how to do them more efficiently.

    At a lower level, I’m in the same place; I’ve run unix for a long time, and continuously at home for over 15 years now. I can do pretty much anything I need to with my home server… but it won’t be effortless, or efficient, or fast, compared to a professional who touches it more than once a year*.

    * It works. Why would I poke it?)

  27. (And on the SA/domain-specific knowledge thing, I’m with The Monster; I’m sure Mr. Raymond knows how to do pretty much every normal unix SA task.

    True with one major exception; I do have a tendency to forget the arcana of the bind daemon because I mess with it so seldom. I usually end up calling Jay Maynard to jog my memory.

  28. Slightly OT. I always wondered if a Wikipedia-style of software development (i.e. anonymous write) would work. It seems to be the logical conclusion to the bazaar model. Has anyone tried that, and are there any oss dvc packages out there that would easily support that?

  29. @Phil

    No, it wouldn’t work, because it is NOT the logical conclusion. A key element in the open-source community is reputation. There is simply no way I want a situation where the equivalent of an unregistered Wiki editor just happens to be the last person to touch the source tree before I compile a driver, a whole kernel, or even an application. It is the reputation of the maintainers that gives me the confidence to use something from Linus’ tree, or Ubuntu’s repositories downstream.

    I do need to disambiguate (heh) between “anonymous” and “pseudonymous”. I have chosen the latter for my online persona, because a link between what I say on the Internet and my meatspace self is Considered Unhelpful (by me). But a pseudonymous contributor can earn a reputation (provided that there are ways to protect against identity theft), and that reputation can help get a code maintainer to read your patches. I believe that particularly in the security field, where hats can be various shades of gray, pseudonymity is fairly common.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">