Interview: David Roundy of Darcs Revision Control

comforteagle writes "In the aftermath of our last interview with Tom Lord, regardless of personalities, it became apparent that the idea of decentralizing CVS is a big deal. Many mentioned darcs as an alternative to Arch. Mark Stosberg has interviewed project head-hancho David Roundy about darcs, his 'theory of patches,' what's next, and on using Haskell for the project."

Comments

CVS

[CodeYoddler]

CVS is getting pretty old, I bet it will be replaced soon by 40 different things.

Re:CVS

[stoborrobots]

The Future was here in 1996 - Check out Reliable Software's Code Co-op.

The Peer-to-peer Version Control System for Distributed Teams
Code Co-op is the version control system for distributed development that adds mobility, simplicity, and robust functionality to your Windows development projects.

• Mobility for collaboration from any location using your existing infrastructure
  - no server required;
• Simplicity to give you quick access to project files and history regardless of a network connection;
• Robust functionality to give you all the control and security you require for managing your software assets.

With Code Co-op you can:
- Collaborate from anywhere using Email, LAN, and VPN
- Access your project files and history without a network connection
- Review file changes with the built-in Visual Differ or Beyond Compare Differ
- View, compare, or restore any iteration of your project or file regardless of a label
- Integrate with your favorite development tools
- Forgo costly server maintenance
- Rely on a secure, fully transactional database with automatic back-ups
- Implement source control in minutes for only $159 per user

Re:CVS

[Anonymous Coward]

Sounds a lot like Sun's TeamWare (TeamWear?) from about '90 or so.

Re:CVS

[Anonymous Coward]

I wouldn't know, I'm still using bare-bones RCS for my projects. ;)

Re:CVS

[Kaz Kylheku]

Check out Meta-CVS.

I think

[9-bits.tk]

that a system of round-robin mirroring should be implemented, if CVS doesn't go decentralised.

You could create a CVS cacheing service, a bit like Coral.

Re:I think

[Anonymous Coward]

Maybe we're using different Corals, but every time I use the damn thing it just times out. Please don't make CVS worthless ;P

Mature RCS?

[phoenix.bam!]

When do you move to your own RCS ro support it's own code? Kinda like bootstrapping the RCS? I really have no idea what i mean, but yeah, you get the idea. Did ARCH start out in a CVS somewhere? and where was bitkeeper kept in its infant days?

Re:Mature RCS?

[Vintermann]

GNU Arch has hosted itself for a very long time. As far as I know, it has never been publicly hosted in a different RCS. What, if anything, Tom Lord used to host it on his machine before the intial release, you'd have to ask him.

Re:Mature RCS?

[onesandzeros]

>>Did ARCH start out in a CVS somewhere?

BitKeeper would have been a good example here, because iirc, there's something in the BitKeeper licencse that forbids its use to develope other RCS apps. I realize that the licenses of cvs, arch, subversion (all gpl?) don't have such restrictions, but if I do indeed recall correctly, and I'd like to think that I do, it would be interesting to see how McVoy used someone else's RCS to develop his own, which then, by virtue of its license, can't be used to make another RCS.

Re:Mature RCS?

[David Roundy]

Actually, whether or not an RCS is self-hosting is a pretty useless test of the maturity of that RCS. It is incredibly easy to self-host an RCS, since the users are the developers. Darcs was self-hosting way back before I would even have considered suggesting that anyone else consider using it (as I'm sure was the case with Arch).

The hard part of writing an RCS is dealing with all those users who do things you never would have thought of, uncovering all sorts of interesting bugs.

Haskell just won't cut it

[PhYrE2k2]

While "Darcs is written in a Haskell, a functional language that is relatively unknown compared to C or Perl", this really does hurt it's common use. Not being able to get a larger group of developers such as C, C++, or even some interpreted projects means that it becomes one or a few developers working on this project which means fewer patches and additions. A community project will ultimately be the versioning system for community projects. -M

Re:Haskell just won't cut it

[QuantumG]

So basically you didn't read the article. He gets more developers because it is written in Haskell than he would otherwise because it's one of the few real applications that are written in Haskell - which means if you're someone who just learnt Haskell for the hell of it you've got somewhere to apply those skills.

Re:Haskell just won't cut it

[Pseudonym]

Just like how nobody uses CVSup because it's written in Modula-3, right?

Re:Haskell just won't cut it

[PhYrE2k2]

I did read the article, however I do DISAGREE with that comment in the article. People won't learn a language for one program, and there is not a large enough body who know the language to really truly UNDERSTAND the program and enough about it to make modifications and additions to it. Compare that to a bunch of C/C++/Java/Perl developers with a massive community body, it's a lot easier to get people to contribute. -M

Re:Haskell just won't cut it

[Anonymous Coward]

Haskell isn't mainstream like C/C++/Perl/Visual Basic, but there are a hell of a lot of people know it.

It's only one major OSS that's written in Haskell, the language itself is all over industry.

Re:Haskell just won't cut it

[pnot]

You wrote:

While "Darcs is written in a Haskell, a functional language that is relatively unknown compared to C or Perl", this really does hurt it's common use.

How will the choice of language hurt darcs's use? Why on earth would the users of a piece of software care about the language it's written in?

You wrote:

Not being able to get a larger group of developers such as C, C++, or even some interpreted projects means that it becomes one or a few developers working on this project

From the article:

I've been surprised by the number and quality of contributors darcs has had. There seem to be quite a few people out there just looking for somewhere to use Haskell! :) And in fact, there have also been developers who learned Haskell expressly for the purpose of contributing to darcs. It's such a pleasant language to work with that I think it's more of a draw to developers than a put-off.

So perhaps you should attempt to assimilate some facts before trotting out your tedious, ill-informed prejudices, hmmm?

Furthermore, it's not just about the sheer number of developers, it's about the power of the language. A million monkeys writing code are still only monkeys, and the more developers you have on a project, the more co-ordination is required (read Fred Brooks' The Mythical Man-Month if you don't believe me).

If "number of potential developers" were the only criterion for choosing a project's programming language, everything would be written in BASIC. And Paul Graham makes a good case for coding in less common languages: you'll get people smart enough to learn unusual languages for the hell of it, rather than a mass of monkeys who have little interest in building great software and just want to learn this week's marketable language to improve their employment prospects.

Re:Haskell just won't cut it

[cduffy]

Some people will learn a language because they want to know a language that has that specific set of features, regardless of what applications have already been written in that language.

It's a small group, but if you've the only game in town (in terms of OSS projects for them to work with)... well, that works out pretty well for you!

No, if Darcs has any major issues, it's the RAM and CPU time requirements, some of which the design makes inherently unresolvable.

Re:Haskell just won't cut it

[pnot]

You wrote:

I did read the article, however I do DISAGREE with that comment in the article. People won't learn a language for one program...

but the article says:

And in fact, there have also been developers who learned Haskell expressly for the purpose of contributing to darcs.

So either:

(1) You haven't read the article, or
(2) You have read the article, but you were incapable of comprehending that sentence, or
(3) You're calling David Roundy a liar.

I find it odd that you use phrases like "won't cut it" and "won't learn a language", as if this were all speculation. darcs has hit 1.0. People use it. It is actively developed by many people. People have learned Haskell solely to hack on it. The facts clearly contradict your unsupported assertions.

Re:Haskell just won't cut it

[Anonymous Coward]

It's only one major OSS that's written in Haskell, the language itself is all over industry.

In that case, it should be trivial for you to name several examples.

By the way, I've started down the path toward installing haskell a couple of times in an effort to try darcs, but gave up an hour or two in each time, because I do not want to run foreign binaries and therefore have to go through a pretty complex bootstrapping process to install haskell.

If darcs were written in any language that is already installed on my PC and had no other external dependency that I lack, I would probably at least have darcs installed on PC as well by now and might have become a darcs user. Granted, if running darcs were really that important to me (perhaps even if I did not have other doubts about darcs), I would spend a few days to really get Haskell and darcs installed, but it's not that important to me right now, and I think my calculation is probably typical of a potential user population that is probably a multiple of the size of the existing darcs population.

Now it might be that darcs would not be where it is today technical with the resources that were used to make it because Haskell is so much more super-productive of a language to work in, so the technical decision to go with Haskell really has maximized adoption or development or whatever metric you want to consider, although I would expect Haskell-based programs to be winning all sorts of evolutionary battles against competing projects, as seems to be the case with perl, python, zope, plone, and linux. The decision to use Haskell is a complex empirical judgement call that is not mine to make, but your omission of examples increases my skepticism.

Re:Haskell just won't cut it

[Earlybird]

• While "Darcs is written in a Haskell, a functional language that is relatively unknown compared to C or Perl", this really does hurt it's common use.

I call bullshit. First, the language that a product is written in doesn't hurt use -- it only affects the development process.

Secondly, what's in a language? I didn't know Haskell until I started looking at Darcs; now I know a bit of Haskell, and soon I hope to be proficient enough to contribute.

There's something to be said for language agnosticism. Haskell is a fine -- even brilliant -- language. The code is there, it's readable for anyone with half a brain.

In the end, the fact that Darcs is written in Haskell will not stop most people from being interested in developing it. Or at least, not the people you'd want to contribute; it's a nice prejudice filter.

• A community project will ultimately be the versioning system for community projects.

That sentence does not make sense. Are you saying the same people who use a version control system should also develop it? I'm sure you will find that most CVS users have never seen even a line of the CVS source code.

Re:Haskell just won't cut it

[Kesh]

... or, he's using "people" in the general sense. Yes, a few people have and will bother to learn a new language just for this purpose. There are always exceptions to any statement.

However, that number will be very, very small, especially compared to the number who would likely be interested if it used a more common language.

Re:Haskell just won't cut it

[user9918277462]

Remember when Arch was first being bandied about? Tom Lord made a big deal about how writing it as a bunch of shell scripts (err, "POSIX standard SH" not bash) was actually a good idea and helped speed development and didn't really hurt performance, etc. Guess what? No one used arch because as sound as the theory behind it might be, as concrete software it seemed like a joke.

So someone came along and did the hard work of reimplementing it in a real language and suddenly the world is taking Arch seriously. I wouldn't be surprised if we end up seeing a similar situation pan out with Darcs.

Re:Haskell just won't cut it

[ArbitraryConstant]

" Some people will learn a language because they want to know a language that has that specific set of features, regardless of what applications have already been written in that language."

I learn languages because it's impossible to respond to zealots talking about their language of choice otherwise. It usually works pretty well because zealots of languages nobody knows tend to be used to pontificating at people that don't know anything about the language in question. They're not used to people that can respond.

That's why I don't know Perl... lots of people know it, lots of people like it, but no one's going to deffend it.

Haskell is actually okay. The problem with it is that because it's functional you often end up restructuring half the program for what would have been a trivial change in an imperative language. Also, I/O is EXTREMELY counter-intuitive. Because it's functional, it's supposed to be stateless. Wrapping your brain around stateless I/O is hard for most people.

The good thing about it is the patterns. You can provide arbitrarily many implementations of a function, and which one gets evaluated is based on matching the arguments. You can match against arbitrarily many arguments of any type. After you've done this a few times, you feel really dirty using nested conditionals.

Re:Haskell just won't cut it

[Pseudonym]

I'm not the grandparent poster. I am a long-time Haskell user, though.

Saying that Haskell is "all over industry" is a gross exaggeration. Anecdotal evidence from Haskell users is that they are all over industry, and they tend to use Haskell in their work, though not necessarily in code that other people see. I, for example, have been known to prototype algorithms in Haskell and then translate them into C++ for our product.

Having said that, there are several consultants out there who write custom apps for clients in Haskell, and at least two companies who heavily rely on it.

It is fair to say that Haskell is all over academia, being used to solve difficult CS-like problems. However, academic uses tend not to impress people, even if it is the best tool for a particular job.

Re:Haskell just won't cut it

[Mr. Slippery]

Why on earth would the users of a piece of software care about the language it's written in?

If your users are FOSS developers, they quite likely care about the ability to modify the tool, which includes caring about the languate in which it is written.

Re:Haskell just won't cut it

[Pseudonym]

The problem with it is that because it's functional you often end up restructuring half the program for what would have been a trivial change in an imperative language.

While I don't disagree with this, there are some counter-arguments too:

• If you find yourself doing that, you may have written your original program in an imperative style in the first place. Alan Holub's argument about getter/setter methods applies to declarative programming too. If you wrote in a more language-ideomatic style, you might not be facing a huge restructure at all.
• Much the same problem can happen in imperative languages, only the class of changes which would trigger such a restructure are different. For example, in a non-GC'd language, you may end up restructuring your program if some critical data lifetime changes. Or, instead of restructuring your program, you might prefer to hack it up instead, making it less maintainable. (It might be argued that languages like Haskell, which discourage this kind of hackery, might be a good thing in the hands of a certain kind of programmer.)
• Even if you do have to restructure half the program, tools like Haskell's type system make this a less painful task than it would otherwise be.

Knowing a language also means knowing what kinds of changes are painful and what kinds of changes are not. Knowing this in advance helps you write your programs to be more future-proof.

Re:Haskell just won't cut it

[pnot]

me: Why on earth would the users of a piece of software care about the language it's written in?

you: If your users are FOSS developers, they quite likely care about the ability to modify the tool, which includes caring about the languate in which it is written.

Interesting point. Certainly FOSS developers care about being legally allowed to modify code, but I'm not sure that they care, on the whole, about the language.

emacs, for example, is largely written in elisp -- hardly a mainstream language. Yet it's extremely popular, even among people who don't know any lisp. People who find the need to extend it get a good excuse to learn lisp in a well-motivated, incremental way.

Speaking personally, I'd be ''more'' inclined to hack on a project written in something interesting like Haskell, ML, Smalltalk, or Lisp. (In fact I chose my current main project partly as an excuse to learn Lisp.) A lot of people like having a motivation for learning a new language, or a practical use for an "academic" language they happen to know. (I learned Haskell in university, so I'd be quite keen to get to use it in the "real world".)

I think the only time I'd care about the language of a program I'm using would be if it were written in something particularly horrible -- "urgh, if I ever want to modify this I'll have to learn befunge!" But perhaps that's the way some people view Haskell ;-).

It's a matter of taste, I suppose. I do acknowledge that I'm a bit of a language nut.

I still maintain that quality is more important than quantity, though. I've been teaching C and Java to second-year undergraduates this year -- having seen some of their code, I can safely say that if I were starting an OSS project, I'd rather have one seasoned Haskell hacker on board than the entire lot of 'em :-).

Re:Haskell just won't cut it

[pnot]

I wrote: I'd be ''more'' inclined...

Ugh. I meant: I'd be more inclined...

Sorry. Too much time on Wikipedia.

Re:Haskell just won't cut it

[Anonymous Coward]

Seriously, you might consider giving Haskell a little more respect. This was the language used for not only the first but also second place winner for the ICFP Programming Contest this year.

http://www.cis.upenn.edu/proj/plclub/contest/res ul ts.php

You don't need as many programmers when you have this kind of tool in your hands.

Re:Haskell just won't cut it

[Chuan-kai Lin]

(arguments that Haskell will not cut it because it does not have a large user community)

I have to say that I am troubled by this kind of attitude, especially on Slashdot. True, open source is mostly about freedom, but it is also about diversity, about innovation, and about trying to do things the right way. Since when do we condemn a project to failure just because it makes a non-mainstream choice, even if the choice was preferred by the developers due to technical superiority?

How do you feel when PHBs assure you that bringing Linux into the server room is sure to fail because it is not mainstream like Windows?

Since when do we let that stop us?

Re:Haskell just won't cut it

[Anonymous Coward]

Are comparing Haskell to "shell scripts" and saying that Haskell is not a real programming language?

That is like comparing smut to Michelangelo's David.

Re:Haskell just won't cut it

[ArbitraryConstant]

"If you find yourself doing that, you may have written your original program in an imperative style in the first place."

That wasn't the cause. Naturally, this claim is completely impossible to back up without a protracted debate that would require me to post code. I'm not up for that, so I'm just going to leave this here.

"Much the same problem can happen in imperative languages, only the class of changes which would trigger such a restructure are different. For example, in a non-GC'd language, you may end up restructuring your program if some critical data lifetime changes."

Well, this is where good language choice comes in. C can be okay for flat problems, but yes, when it starts getting more complicated, switching to a garbage collected language is usually a pretty good idea.

And, yes, there are times when Haskell is a good language choice. When I say it's "okay", it means I wouldn't be opposed to using it for a problem to which it's well suited. The only language that gets higher praise than that from me is Python. :)

"Even if you do have to restructure half the program, tools like Haskell's type system make this a less painful task than it would otherwise be"

I don't necessarily agree with that.

In OO languages, you often have problems with restructuring, but it's not a fair comparison. Objects have state. That's what they're there for. It's a pain to restructure class hierarchies sometimes, but Haskell can't even solve problem to begin with.

Also, dynamically typed languages like Python also make restructuring easier (using C++/Java as a baseline).

Re:Haskell just won't cut it

[Anonymous Coward]

The only reason that Haskell will hurt the adoption of Darcs is the fact that it doesn't have particularly good platform support.

While writing a program in a non-mainstream language will cause contributors to be selected from a smaller pool of people, that set of potential contributors will probably be better programmers (knowing and understanding more programming languages and techniques makes people better programmers).

Re:Haskell just won't cut it

[jpc]

nested conditionals, well yes, you should use case statements anyway. But then I program in C like a functional programmer anyway to a large extent. Everyone should learn a functional language, just to help you think about things in different ways. And Haskell does have the best type system of any language I have used.

Re:Haskell just won't cut it

[Pseudonym]

That wasn't the cause.

Right, hence I said it "may" be the cause. :-)

Having said that, your code still might not have been as ideomatic as it could be. For example, what was originally just IO could end up as a huge stack of monad transformers by the time you're done. Making a type synonym for the monad in the first place saves you a lot of hassle down the track.

I don't necessarily agree with that.

I say this from bitter experience. There is many a time when I've had to thread something through a lot of code, and the compiler found every place where it was needed. No, it wasn't pleasant. But it worked first time.

Also, dynamically typed languages like Python also make restructuring easier (using C++/Java as a baseline).

On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down.

Re:Haskell just won't cut it

[Anonymous Coward]

in a more language-ideomatic
I think you meant language-independent, rather than idiomatic.

Re:Haskell just won't cut it

[ArbitraryConstant]

"nested conditionals, well yes, you should use case statements anyway."

Not chained. Nested.

case statements can be useful in preventing chained conditionals if you're looking at a single value, but they can't really help with nested conditionals.

Re:Haskell just won't cut it

[cduffy]

On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down.

This is why I think Boo is so damn nifty. It's statically typed, but will infer types if possible (unless the user decides to use the optional explicit typing), and also allows duck typing to just resolve everything at runtime Python-style.

Re:Haskell just won't cut it

[MikeBabcock]

I was about to post more or less the same thing you did -- that users shouldn't care what its written in but I realized as I read your post that it isn't in fact true.

How would you feel if Microsoft released the source code to MS Excel in, say, Brainf*ck?

Actually, lets say its an obscure compiled language that can't be easily translated into another language at all.

Would you be praising MS for their contribution to the community or decrying their choice of language which limits the legibility and review of the code?

Haskell is completely opaque to me (as far as debugging is concerned) although I'm sure I could learn it if I wanted to (having tucked many others under my belt already, including most recently PostScript for some reason). That opacity does change my feelings about using a program -- RMS' views and paranoias notwithstanding, his thoughts about "what if the developper dies or quits maintaining the code?" are justified.

I have expectations that people would continue to maintain a Haskell program because I've met Haskell programmers -- but not as assured as I'd be if it were written in C, PERL or even Python. (I leave Java off that list since most Java programmers seem intent on code-hiding rather than sharing).

Re:Haskell just won't cut it

[PhYrE2k2]

I'm not saying it is wrong to bring it into a coding environment, however the choice of language means that the systems it runs on is not as simple (be it due to having to compile new programs or what not), nor is the understanding of the code itself. By all means, I _HOPE_ it takes off, but would you install a new language for one program? Maybe a library but not really a language. Plus making it harder to get a good audit of the code and figure out what is going on to make modifications. It's not mainstream and I'd love to see it happen, however I was stating that it just may have more trouble because of the choice of language not being as accessable, providing a higher initial implementation curve. Also, not being a up-front native language for many means that people have more trouble contributing. Linux was built upon existing C, C++, and even interpreted languages that people knew on other platforms. The development team for this project will always be limited in some way.

Re:Haskell just won't cut it

[rsheridan6]

When observed facts, based on actual experience, disagree with your theory, obviously the facts must be wrong.

Re:Haskell just won't cut it

[Anonymous Coward]

What is interesting (sort of) is that one "important" haskell project was cacheprof http://www-2.cs.cmu.edu/afs/cs.cmu.edu/academic/cl ass/15213-f01/L4/cprof/documentation.html

The most interesting thing is that, IIRC, the author said, in his page that rewriting cacheprof in C was an exercice in futility (because haskell was much much better at the kind of manipulations that cacheprof did). In one word, the author said that C was totally unsuited for writing cacheprof

Now, the main cacheprof page (http://www.maxuk.net/cacheprof.html just says that functionality have been rolled into valgrind, saying "[valgrind] is vastly superior in every way".

And guess, what, valgrind is... in C.

Which make haskell a nice prototyping language, but the vast amount of people knowing C blew it away in the long run.

(As a side point, I never seen a code migration from C to assembly, so I take all the opinion that C will be replaced by functional languages with a rock of salt...)

Re:Haskell just won't cut it

[Bob Uhl]

People won't learn a language for one program...

One word: elisp. And thus do I disprove thine assertion:-)

People will learn a language specifically to use a tool, provided that the cost of learning is less than the value added thereby.

Re:Haskell just won't cut it

[retinaburn]

And the FOSS developers are FREE to choose to learn the language, if they want to contribute.

Oh what's that? OSS should only be developed in the few standard languages that 'everyone' knows?

Bah I say.

Re:Haskell just won't cut it

[Chuan-kai Lin]

You do not need to install a Haskell compiler or interpreter if you just want to use darcs: the Haskell code is compiled into an ELF binary executable just like any other program; thus the user will not even be able to tell that it is written in Haskell.

As far as user contributions are concerned, I agree with your point that using a less mainstream language will pose some additional difficulties and limitations. But this is entirely different from your original thesis that "Haskell just won't cut it". Whether using Haskell is a wise choice depends on whether these difficulties can be offset by other technical advantages, and from the interview, so far the developer seems to think so.

Re:Haskell just won't cut it

[Mr. Slippery]

emacs, for example, is largely written in elisp -- hardly a mainstream language.

Do CS programs no longer at least touch on LISP?

I've been teaching C and Java to second-year undergraduates this year -- having seen some of their code, I can safely say that if I were starting an OSS project, I'd rather have one seasoned Haskell hacker on board than the entire lot of 'em :-).

Sure. It's easier for a good hacker to pick up a new language, that for someone who knows a language to become a good hacker.

Re:Haskell just won't cut it

[Anonymous Coward]

> People won't learn a language for one program

I *did* learn Haskell just in order to be able to hack on darcs.

Re:Haskell just won't cut it

[voodoo1man]

Yes, I think it's safe to discount Darcs because it's written in Haskell, because god forbid not every other C or Perl monkey who can't be bothered to read a language specification for a day won't be able to make their random changes on the system while I'm trying to use it. By your logic, CVS should absolutely be the cat's ass because of all the meaningful contributions coming from the large, trained and expert community of C developers. Or not.

Re:Haskell just won't cut it

[ArbitraryConstant]

"I say this from bitter experience. There is many a time when I've had to thread something through a lot of code, and the compiler found every place where it was needed. No, it wasn't pleasant. But it worked first time."

In Python, programs don't tend to involve the degree of recursion that they do in Haskell. Also, it tends to be flatter than Java (eg, you don't end up with subclasses five deep of an abstract class implmenenting some interface), largely because of the dynamic typing and dynamic binding, Typically, restructuring involves adding an argument to a function or set of functions. When one screws this up, it's rarely difficult to track down. I've found that changing the type of an argument is pretty rare (rather, it's removed for some reason and then another is added later for a different reason).

Also, one of the primary reasons for restructuring things in Haskell is also information availability... you need results for something available lower down in the recursing, etc. Much of that is solved by Python's OO-ness. Just have a field with the information.

"On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down."

People say this about Python a lot, However, the problem is easier because there aren't so many types. In C, you've got like const pointers to pointers to char or whatever. In Haskell, everything needs to be passed as an argument, there's no way to get at anything otherwise. In Python, you've got a char object that you pass around freely because it's garbage collected. It doesn't matter if it's const or not because the object is read-only. Then you give it a name like inputChar, and there's very little room for confusion. You don't need large numbers of arguments to functions because most of the time those five chunks of information are available from the one object you passed.

Yes, at the end of the day, Haskell gives you better type safety than just about any language... but that's because it needs it so desperately.

Re:Haskell just won't cut it

[Anonymous Coward]

> I do not want to run foreign binaries and therefore have to go through a pretty complex bootstrapping process to install haskell.

Interesting. How did you compile the C compiler on your machine?

Re:Haskell just won't cut it

[pnot]

How would you feel if Microsoft released the source code to MS Excel in, say, Brainf*ck? ... Haskell is completely opaque to me...

Then it wouldn't be free software: they didn't write it in brainfuck, so a brainfuck release is not a source code release. You could never develop an Excel-sized application in brainfuck.

I think I addressed your point in my post when I wrote:

I think the only time I'd care about the language of a program I'm using would be if it were written in something particularly horrible -- "urgh, if I ever want to modify this I'll have to learn befunge!" But perhaps that's the way some people view Haskell ;-).

So yes, some people might be put off by that. But comparing Haskell to befunge, brainfuck or a some hypothetical, deliberately obfuscated language is hardly fair. Roundy chose Haskell for ease of development (after a bad experience with C++) which should indicate something about its expressive power.

In summary: I don't know (and neither do you ;-). It's more to do with people's perceptions of Haskell than its actual merits, so you'd have to do some kind of a survey to find out. But darcs' success (so far) suggests to me that there's a sufficient talent pool for at least a few OSS projects in Haskell.

Re:Haskell just won't cut it

[pnot]

Do CS programs no longer at least touch on LISP?

Mine (1998-2001) covered, to varying extents, Haskell, Oberon, CAML, Prolog, C++, Java, MIPS assembler, and CSP. So I at least came away with a feeling of "if I ever need to use <language>, I'll just pick it up".

AFAIK my current university doesn't teach any non-imperative languages (unless you count SQL), though I'm using Lisp for a postgrad project.

I think Scheme still gets taught quite a lot, though I don't really know to what extent. I have a horrible feeling that a lot of CS courses these days are more or less vocational training.

Re:Haskell just won't cut it

[bcrowell]

I'm looking at Darcs for possible use in a project, so FWIW here's one data-point on how a potential user would see the Haskell issue. Basically, as a user, I don't care that much. Yeah, it slightly bugged me that I wouldn't be able to understand the code at all (whereas I do think I could at least catch the general drift of something written in Python or Ruby, even though I've never written much more than Hello World in either). But it's such a minor issue. Actually, the bigger thing that's holding me back right now is simply that my server has an older version of openssl, and updating openssl is apparently something that, if done the wrong way, can make sendmail not work, and cause other problems.

Let's face it: people will often say they're interested in reading or modifying the OSS code they use, but very few of them actually do. And there is already a tower of Babel in terms of programming languages being used on OSS projects: python, perl, ruby, lisp, C, C++, Java, ... I actually wouldn't consider myself competent to modify code written in 6 out of 7 of those languages, even for my own use.

I think the barrier to participation in OSS projects would actually be lowered significantly if the most popular languages, C and C++, were abandoned entirely. The reason is that you really need very specialized skills in order to do memory management competently in these languages. Witness the seemingly endless series of buffer-overflow bugs that have been discovered in C programs like sendmail, or the fact that people are reporting memory leaks in some recent versions of firefox. The skill of doing memory management in C/C++ is obviously such an arcane one that even the lead developers of C/C++ programs haven't mastered it.

Re:Haskell just won't cut it

[Anonymous Coward]

Valgrind is written in C becuase it isn't clear how to achieve its functionality given current Haskell implementations. It's portability would be limited as well. You can ask him yourself, but I'm willing to bet that if these issues could be overcome, the author would readily translate parts of Valgrind into Haskell.

Re:Haskell just won't cut it

[Anonymous Coward]

Tell that to RMS: http://www.gnu.org/prep/standards/standards.html#S ource-Language

Re:Haskell just won't cut it

[Pseudonym]

I meant what I said.

Re:Haskell just won't cut it

[Pseudonym]

Actually, that previous reply was a little dismissive. Let me explain.

If you write what is basically C code in Haskell, you will end up with maintenance difficulties. A small change may well result in a large restructure. You need to write Haskell code in Haskell (although ML code or Lisp code might also do if you're clever).

Re:Haskell just won't cut it

[jguthrie]

Historically speaking, hardly anyone has the expertise, the time, and the desire to contribute code to any open source project. So, the "number who would likely be interested" in modifying any project may be large, but the number who would actually contribute code is going to be very, very small compared to that. In other words, it's not obvious to me that being written in Haskell is necessarily a loss for darcs because it is excluding people from contributing.

In fact, I like seeing projects written in languages other than C or C++, even though they're mostly what I write in. There should be lots of widely-used languages with efficient compilers, and having major projects in different langauges promotes that. Monoculture is not just about operating systems, but about other ways of doing things.

And, as a matter of fact, I use darcs at home. I like the fact that it has some sort of theoretical basis.

Re:Haskell just won't cut it

[ArbitraryConstant]

haha!

" You need to write Haskell code in Haskell (although ML code or Lisp code might also do if you're clever)."

I've said exactly the same thing (the phrase "write X in X") about a) Paul Graham's comparison of Lisp to Python and b) the average C++ programmer's attempts to write anything in anything else. Probably at other times as well, but I don't remember.

I currently know 12 languages[1], and while I'm not a master at all of them, I always do my best to learn to write X in X. This has made me a better programmer in the languages I already use, and has allowed me to discover new favorite languages more than once. Haskell was no exception to this. :)

Re:Haskell just won't cut it

[Anonymous Coward]

They may get fewer developers due to using Haskell. But as a result of using Haskell they'll probably have less bugs, more productivity and easier maintenance as well.

Thus, I think the cons of using Haskell (that people haven't started looking at truly productive and high-level languages yet) are outweighed by the benifits.

CVS-style development with darcs

[Ashish Kulkarni]

There was a good post on this on the mailing list a while ago.

Decentralization

[eeg3]

The idea of decentralizing CVS is, indeed, a humongous deal. While, David's Advanced Revision Control System sound quite silly... it's a really great alternative. I'd like to see it implemented everywhere, although CVS is still better in some instances.

Re:Decentralization

[cduffy]

Mighty vague, that. What instances is CVS better in?

Compared to modern revision control systems, I don't think CVS is even in the running. It's SVN (in the non-distributed camp), and Arch, Darcs and Monotone in the distributed camp... with plenty of infighting between them.

Re:Decentralization

[Gopal.V]

> What instances is CVS better in?

When you need symlinks in the repository . When all you have for backup is a solaris machine with a tape drive , When you need a web interface to update password ... It has its Niche .

That said , I just love how easily you can setup a darcs repository (just like cvs)

Re:Decentralization

[eloki]

> When you need symlinks in the repository.

Um, I don't know what you're referring to, CVS ignores symlinks in checkouts. Maybe you meant symlinks literally in the repository itself, but I'm struggling to see a scenario where that is important and symlinks would simply be a workaround to the real problem.

Re:Decentralization

[cduffy]

>What instances is CVS better in?

When you need symlinks in the repository.

I'd think that having version-controlled symlinks in your source trees (which Arch supports but CVS doesn't) would be a more useful feature. Why would you want this?

When all you have for backup is a solaris machine with a tape drive

What's that have to do with the price of beans? Arch's archive format is actually *easier* to back up to tape because it's append-only (so you can have all changesets up to #500 on one archived tape and 501+ on another and never need to rewrite tho 1-500 tape because that history doesn't change).

When you need a web interface to update password...

What does that have to do with CVS? One can use PAM for authentication on the services Arch backends into (sftp, WebDAV, etc), so pretty much any kind of password store (and password change mechanism) one happens to want is possible.

I'd argue that setting up a darcs repository is easier than a CVS one -- you just initialize a working tree! (Even so, I'm not really a fan of darcs yet; my company works with very large trees, and so there's no way we could use it due to the memory and CPU time constraints; instead, we're switching to Arch).

Re:Decentralization

[Anonymous Coward]

• Compared to modern revision control systems, I don't think CVS is even in the running. It's SVN (in the non-distributed camp), and Arch, Darcs and Monotone in the distributed camp... with plenty of infighting between them.

Don't forget about ArX

Walter

Re:Decentralization

[cduffy]

Eh? How many users does ArX have?

If I'm going to be using an Arch branch, I'd far rather use one with an actual community around it. Last I glanced at the ML archive, ArX has so little of one as for me to consider it dead. Besides, I drink Tom's Kool-Aid wrt pika/furth/etc.

(Hi, Landry!)

MOD PARENT DOWN

[Anonymous Coward]

RTFA

Darcs is KISS

[Earlybird]

Among the plethora of emerging version control systems -- Subversion, Arch, Monotone and so on -- Darcs stands out for its simplicity and thoughtful design.

Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion. Let's see:

john@somewhere$ cd ~/myproject
john@somewhere$ darcs init

You now have a Darcs repository! Let's do something with it:

john@somewhere$ darcs add -r *
john@somewhere$ darcs record -am "Initial import."
Finished recording patch 'Initial import.'

Now your repository contains all your files. Let's look at the changelog:

john@somewhere$ darcs changes
Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

Now, where's the server? You need a server to share your repository, right? Nearly -- every repository is a potential server, as long as it's accessible either through the file system, through SSH/SFTP, HTTP or email. Let's go to another machine and check out the repository we just made:

jane@elsewhere$ darcs get john@somewhere:~/myproject
Copying patches...
.
Finished getting.

We now have a repository on Jane's box. Let's make a modification:

jane@elsewhere$ echo "#include <foo.h>" >>foo.c
jane@elsewhere$ darcs whatsnew --summary
M ./foo.c +1
jane@elsewhere$ darcs whatsnew
{
hunk ./foo.c 2
+#include <foo.h>
}

This last output, by the way, is Darcs' patch format. A "hunk" is a line-based diff. Other types of changes that may be contained in a changeset include renames, moves and binary changes. (Yes, you can also get a GNU-patch-compatible output similar to "cvs diff".)

Now let's commit and push the changes back to John's repository:

jane@elsewhere$ darcs record -am "Added a missing include."
jane@elsewhere$ darcs push -a
[...]
Finished applying...

Now we can go back to John's machine and look:

john@somewhere$ darcs changes
Thu Nov 25 06:26:10 CET 2004 janedoe@example.com
* Added missing include.

Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

(Note how Darcs generates a GNU-style changelog for you automatically.)

Where are the revision numbers, you ask? Well, they don't exist, because they're not needed. Darcs is changeset-oriented, not file-oriented. You can refer to a changeset by name, date, or a special hash identity.

Darcs changesets aren't just GNU patches; they have context, which means, for example, that someone can check out a repository, move a file "foo.c" into the directory "bar" and commit; meanwhile, another person, working on an older copy of the same repository, edits foo.c (which is still in its old location) and commits that. Darcs know that this edit should apply to foo.c in the new location -- and unlike CVS, you don't need to do anything similar to "cvs update" if you're committing files that have been changed on the server. In other words, people can freely commit changes, and the only kind of visible "conflict" will occur when you actually edit the exact same line.

Unlike CVS and Subversion, but like Arch and Monotone, Darcs is a distributed version control system. Repositories are islands which are constantly out of sync with each other, and Darcs' patch commutation system takes care of integration the changes that flow between them.

This system has several extremely useful effects:

• Offline mode. You can commit changes even if you're on the road with no access to the server. That's because your own working directory is a repository in its own righ

Re:Darcs is KISS

[mindstrm]

Some nice features there... but you open up with saying "Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion."

Subversion:

# Create a local respitory & add files.

svnadmin create /path/to/repository
svn import * file://path/to/repository

I'm really not quite sure how that qualifies as "can't be set up in minutes". Easily as fast as darcs, and very simple.

The distributed features are what make darcs unique.. it doesn't seem to me to be any fundamentally easier or faster for basic revision control than subversion, though.

Re:Darcs is KISS

[Earlybird]

• The distributed features are what make darcs unique.. it doesn't seem to me to be any fundamentally easier or faster for basic revision control than subversion, though.

Subversion seems similarly easy to get started with, but what about repository sharing? To let other people access your repository, you must set up a server of some kind, be it WebDAV, or svnserve -- although I'm sure Subversion must support something like an "ssh://" protocol.

Re:Darcs is KISS

[Koguma]

Subversion runs through Apache/2, so if you've got ssl setup in Apache, you have SSL on your repository. What I really love about Subversion is that it grabs the Apache authenticated user and uses that as the repository user. Once you set it up, it's really neat, and you get fine grained control. Setting up the repository is quick, but setting up acl's to it is trickier. Still with WebSVN and other tools, it's really sweet.

Re:Darcs is KISS

[jbert]

Yup.

svn co svn+ssh://user@host/path/to/repo repo

will check out a repository, tunnelled over ssh. No need to run a subversion server to do that.

One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.

Another notable thing (for windows users) is TortoiseSVN, (an explorer shell extension) which is just great.

I can see how the distributed, multi-repo model of bitkeeper/darcs/arch is superior but svn looks good if you only need single-repo.

Also, bitkeeper has some powerful gui tools (and probably the kitchen sink too). Haven't really used arch/darcs.

Re:Darcs is KISS

[Earlybird]

• Subversion runs through Apache/2, so if you've got ssl setup in Apache, you have SSL on your repository ...

Sorry, but we were talking about simplicity here. Apache 2.0, SSL, authentication, WebDAV... Setting up a repository with what you suggest is more than one step -- it's usually a lot of steps, especially considering Subversion's external dependencies.

Setting up a Darcs repository consists of doing this:

$ darcs init

And Darcs works over SSH:

$ darcs get bob@example.com:/some/project

This gives you security (leveraging the public-key encryption system of OpenSSH) without having to set up Apache, SSL, virtual hosts, WebDAV or authentication.

You can also use Darcs read-only over HTTP (the following will check out the Darcs sources):

$ darcs get http://www.abridgegame.org/repos/darcs/

All that's required is a web server mapping the URL to your repository -- any one will do.

I'm sure Subversion works similarly, though.

Re:Darcs is KISS

[DrEasy]

Wow... This looks so much simpler even than CVS, especially as soon as things get hairy with parallel development.

Perfect sales pitch! I'll have to "check it out" now, guess I should say "whatsnew it" instead! :)

Re:Darcs is KISS

[Earlybird]

• One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.

Darcs and Arch both have this. (Arch undoubtedly has the most extensive protocol support of any revision control system.)

• Another notable thing (for windows users) is TortoiseSVN, (an explorer shell extension) which is just great.

Tortoise is quite nice indeed -- I used TortoiseCVS for years.

• I can see how the distributed, multi-repo model of bitkeeper/darcs/arch is superior but svn looks good if you only need single-repo.

Need is just one aspect of the development process; right now CVS gives most people what they need, despite the cracks in the lacquer. Darcs doesn't just erase the cracks, but improves the process.

For example, I occasionally submit patches to certain open-source projects. The easiest way to do this is to check out the CVS repository, make my changes, and do "cvs diff -u" to get the patches in that format, which I tend post to some Bugzilla server or email to somebody. But I can't commit them. I don't mean to the master repository -- I mean locally. There's no way I can bundle my file patches in a changeset and keep its history. I'm basically managing a CVS working directory where my changes are never checked in.

With Darcs, I just do "darcs get" to get the master repository, make my changes, commit them locally. I can use "darcs send" to submit my changes to the project maintainer. Anyone else can grab my patches with "darcs get" or "darcs pull". I can be Alan Cox to some Linus without breaking my back over patch management.

Re:Darcs is KISS

[boa13]

Your comment would still be correct if I changed every occurence of "darcs" with "arch" (except for the command lines, of course).

So, what's the difference between Arch and Darcs?

Re:Darcs is KISS

[Vintermann]

"The distributed features are what make darcs unique.."

Hardly, as it is the defining feature of BitKeeper and GNU Arch. It's a very good idea, however.

Re:Darcs is KISS

[grumbel]

The only problem with Arch is that while the implementation might be KISS, the user interface is not and its almost impossible to map a good old CVS-users workflow onto Arch.

Re:Darcs is KISS

[David Roundy]

Darcs and Arch both have this. (Arch undoubtedly has the most extensive protocol support of any revision control system.)

Although Arch does have extensive protocol support, I'm not sure it's up to par with darcs, since I think it's missing support for some obscure protocols such as http and gopher.

Re:Darcs is KISS

[o1d5ch001]

You can run Subversion using the svnserve tool as well. To start the server:

svnserve -d -c /repo

To access it:

svn co svn://somehostname

or with ssh

svn co svn+ssh://somehostname

Re:Darcs is KISS

[HermanAB]

john@somewhere$ cd ~/myproject
john@somewhere$ mkdir RCS

You now have an RCS repository! Let's do something with it:

john@somewhere$ ci -u -t-FirstPost *

Now your repository contains all your files.

Oh, wait, rcs is old and uncool...

Re:Darcs is KISS

[Sunthalazar]

Missing support for http?

I'm pretty sure it doesn't support gopher, but it supports http just fine. (You have to add .listing files so that it can look in directories, but plain http is supported for get.)

It even supports webdav if you want to get and put into an http source.

Does darcs support webdav to push to an http archive, or do you have to run a darcs server on that machine?

I'm not really sure who runs over gopher, or really why, but that's interesting nonetheless.

(I'm not sure if you meant a different protocol, but I'm sure arch supports http/webdav, ftp, sftp, and the local filesystem)

Re:Darcs is KISS

[Earlybird]

• Oh, wait, rcs is old and uncool...

If you had tried to duplicate the other steps in my little tutorial, you would have seen why RCS doesn't cut it. RCS isn't a distributed system.

Re:Darcs is KISS

[Earlybird]

• Your comment would still be correct if I changed every occurence of "darcs" with "arch" (except for the command lines, of course).

Not quite. Arch isn't simple to use.

• So, what's the difference between Arch and Darcs?

From the perspective of a Darcs user:

Darcs is much simpler to use.

Darcs doesn't have branches, because every repository is conceptually a branch.

Darcs' patch format is just text (Arch uses a tarball).

Darcs has no notion of persistent file identity (which I consider a plus).

Darcs involves less typing; a repository is just a directory, or an SSH path, or an HTTP URL; compare that to Arch's tendonitis-inducing archive/patch/branch names: lord@emf.net--2003-example/hello-world--mainline-- 0.1--patch-1. (Yes, you will need to type this all the time on command lines.)

Arch has the concepts of archives -- every user first has to set up an archive into which you pull repositories. You then check out code from your archive, check it back in it. Very tedious. In Darcs, a repository is analogous to Arch's archive.

The archive concept also increases the number of commands Arch has support: in addition to the normal checkout, commit etc. commands, it must support a similar, orthogonal set of commands for manipulating archives, and it has to have all this glue for tying archives and repositories.

How many commands do Darcs and Arch have?

$ darcs -h | grep "^ " | wc -l
30
$ tla help | grep "^ .*:" | wc -l
104

To Arch's defense, you don't need to know every command; some of them are fairly esoteric.

Try the Arch tutorial someday. It's an incredibly long and tedious tutorial, and by the end of it, you probably won't remember the command to set up a new archive.

Comparing Darcs and Arch feels a bit like comparing Python and Java (or, in terms of typing, Lisp and Dylan).

Re:Darcs is KISS

[Anonymous Coward]

Disk space being as cheap as it is, I find it easier just to maintain separate repositories for any projects I hack on: 1 "official" repository that is synced to mainline, and a second repository that I hack on directly, and merge changes in from the mainline every now and then (the vendor branch concept, although with separate repositories). Actually, I think Subversion will let you import trees into your working directories, but I digress.

The thing about this system is (1) the underlying SCM can remain simple, which means I'm going to have more confidence in it, and (2) I have more control over how I want my patch sets to appear in the final product.

In my usual working mode, I might be hacking on several systems at once, and it's error prone to only check in those files that apply to a single patch set. Besides, what's the point of an SCM if you can't compulsively commit your work every 5 seconds? However, when I merge changes back, I can go through the patches carefully and only transfer those changes that logically go together. This means the public repository looks quite clean, while the "development" repository can be as messy as I like.

Admittedly, it's slightly more work for me than an automagic SCM that just "works", but I don't have any confidence yet that any of the proposed solutions just work, either (other than maybe BK, battle tested on the kernel and all, which I haven't looked at in case I ever want to work on an SCM in the future--and still, I get nervous whenever people spend that much time talking about fixing "corner cases"). I also think the process of manually merging changes between repositories really helps keep the process clean.

Re:Darcs is KISS

[HermanAB]

If you want either a centralized, or a distributed system, then use CVS - there is even a version of CVS that works via email. If you want a simple system, then use RCS. If you want a wide choice of client programs, then use CVS. Note that RCS is contained in CVS.

I'm not a CVS fanatic, not at all, but I am seeing many people recreating the features of CVS with great effort, while all they really need is a better client.

The CVS server doesn't matter, it works, it is debugged, it is reliable, there really is no need to mess with it. It is the clients that need to be improved.

Re:Darcs is KISS

[Anonymous Coward]

• Arch undoubtedly has the most extensive protocol support of any revision control system.

Definitely not. ArX uses gnome-vfs, and so supports all of the usual suspects (ssh, sftp, ftp, http(s)), as well as some of the more obscure (smb).

Walter

Self-hosting

[Earlybird]

I believe the term you're looking for is self-hosting. Subversion, for example, was originally maintained in CVS, and has a CVS gateway for maintaining redundant systems.

For pilot-testing a migration to Darcs, there are scripts available that convert other repository formats (Subversion, CVS, possibly others) into Darcs (and back, actually), so you avoid losing history when making the transition.

I agree

[LearnToSpell]

I agree.

Its the clients and API that matter

[monkeyboy87]

no matter what the change set "theory" are implemented into the product if it's not easy to do things with it, it will languish. VSS and CVS are still used widely becuase there are lots of clients and tools that make it useful. the draw of SVN (loved or hated) is that it has a good client and the command line client is easy to drive with scripting tools

Re:Its the clients and API that matter

[MassacrE]

the draw of SVN (loved or hated) is that it has a good client and the command line client is easy to drive with scripting to

Even more than that, SVN actually has an API. CVS does not; you must exec the cvs process and read out its results, or attempt to re-implement CVS in order to get a direct API (such as Eclipse has done).

Interesting app. non-troll questions

[mattr]

The previous poster who showed how easy it is to use darcs sold me, I am thinking it could be real useful
right away just for my own work.

Took a brief look at the pretty site. Personally I've been intrigued by Haskell for a while though never jumped in, and I use Perl. My questions:

1. Can the elegant quantum reality inspired code be separated off? Though my take is that it is already separate, as a Haskell function.. the reason for the question is that it sounds like it would be useful for a whole lot of things. Instead of implementing app/protocol X over darcs, I am wondering if you could include an (inline) Haskell module in a Perl app that would do the rest.

1.5 ..or is there another way to access the Haskell theory of patches functionality from outside the app?

2. Next question, can Haskell be embedded inline in Perl code?

3. Can the quantum theory of patches be implemented as a Perl module, and ignoring the probably truth that anything not Haskell will not be as elegant as Haskell, would such an implementation benefit/be renedered possible by using the Perl functional or Quantum:: modules?

3.5 At risk of a flame war I'd love to use this in XEmacs. Anybody? This post written in vim so no flames please!

4. Reading about the symmetry or lack of it, concepts of physics this is helping me think about an app of my own. I'd like to read more about this does anyone have links?

5. Time to learn Haskell!! Great!

Re:Interesting app. non-troll questions

[Earlybird]

I can't answer all of your questions. The mailing list would be the place to ask.

• 2. Next question, can Haskell be embedded inline in Perl code?

Not that I'm aware. However, all you need is an embeddable Haskell interpreter. I believe this is possible with Hugs, which has a "server interface", and possibly even with ghc (the native compiler that Darcs is compiled with). You'd probably have to write the C/Perl interface yourself.

• 3. Can the quantum theory of patches be implemented as a Perl module ...

Certainly.

• 4. Reading about the symmetry or lack of it, concepts of physics this is helping me think about an app of my own. I'd like to read more about this does anyone have links?

More than anything it's mathematics. But David Roundy, the author of Darcs, is a physicist, and may have some pointers for you.

• 5. Time to learn Haskell!! Great!

If you're a Perl hacker, you might be interested in this. Scary, eh?

Re:Interesting app. non-troll questions

[Earlybird]

• 3.5 At risk of a flame war I'd love to use this in XEmacs. Anybody? This post written in vim so no flames please!

This may be useful

Re:Interesting app. non-troll questions

[David Roundy]

1. It's actually hard to use the patch commutation code to do any good outside the concept of a darcs repository.

1.5 I've thought about creating a C library for manipulating/querying darcs repositories, but haven't gotten around to it. The hard part would be of course designing the API. Ideally I'd like the interface to be such that programs using the library couldn't accidentally corrupt the repository.

2. Darcs requires ghc, since it uses some library code only available in ghc to do more efficient IO, string manipulation and to access zlib. It turns out to be a pain on many systems to link with the necesary libaries when using the interpereted version of ghc. So probably accessing darcs from perl will have to go through the executable until a C library is written (which could of course have perl bindings).

3. Rewriting darcs in perl (or parts of it) would be possible, but would be a pain. In particular, the commutation of patches which have conflicts is pretty complicated.

Re:Interesting app. non-troll questions

[mattr]

Excellent link. Thank you very much! I also note belatedly that there is a link in the wiki about an emacs mode.

I don't know why they have marked my last two serious questions in threads as trolls, especially when I say this is not a troll. Is there a filter that makes everyone who says that a troll?? Sheesh. Of course if this reply is marked as a troll too then we know..

Re:Interesting app. non-troll questions

[mattr]

Thank you *very* much for your responses!!

I'll definitely study the wiki. I'm interested in using darcs as darcs, and also in the theory and how it came out of quantum reality concepts. I'm not about to write darcs in perl, but was intrigued with the possibility of accessing the theory side in perl for other applications than strictly controlling patches of source code for developers. Probably it would be more helpful to learn about how you came up with the theory itself than to actually try to implement something that tries to solve problems by talking to darcs. If I get anywhere in my thinking you'll be sure to hear from me again, but for now thank you very much and good luck!

Theory of patches

[geneing]

Let me summarize the "theory of patches": you reverse patches in the opposit order of applying them.

I don't know why anyone would make a big deal out of that.

I have to agree with many other comments: the use of haskell eliminated it as a choice for me. I use subversion instead, and still looking for a better vcs. I checked all the available free (and some non-free) systems and all of them have major warts.

Re:Theory of patches

[Animats]

And what do you do when you merge together two divergent versions? That's what patch theory is all about.

Re:Theory of patches

[Anonymous Coward]

> the use of haskell eliminated it as a choice for me. I use
> subversion instead,

So... How many times have you made local modifications to Subversion, and how many patches have you submitted?

Which language is Subversion coded in ...without looking it up?

Thanks.

Re:Theory of patches

[Earlybird]

• Let me summarize the "theory of patches": you reverse patches in the opposit order of applying them.

No. Darcs can, and will, apply patches out of order. From the Darcs manual:

• The development of a simplified theory of patches is what originally motivated me to create darcs. This patch formalism means that darcs patches have a set of properties, which make possible manipulations that couldn't be done in other revision control systems. First, every patch is invertible. Secondly, sequential patches (i.e. patches that are created in sequence, one after the other) can be reordered, although this reordering can fail, which means the second patch is dependent on the first. Thirdly, patches which are in parallel (i.e. both patches were created by modifying identical trees) can be merged, and the result of a set of merges is independent of the order in which the merges are performed. This last property is critical to darcs' philosophy, as it means that a particular version of a source tree is fully defined by the list of patches that are in it, i.e. there is no issue regarding the order in which merges are performed.

A distributed version control system that required all patches to be applied in order would be painful indeed to use.

• I have to agree with many other comments: the use of haskell eliminated it as a choice for me.

Why? Are you a Subversion contributor?

Re:Theory of patches

[IrvineHosting]

Wow, that actually sounds really cool! I just be happy if I could get my SourceSafe repository to stop corrupting.

Re:Theory of patches

[Deusy]

"I have to agree with many other comments: the use of haskell eliminated it as a choice for me. I use subversion instead, and still looking for a better vcs. I checked all the available free (and some non-free) systems and all of them have major warts."

Why did it being in Haskell eliminate it as a choice? What kind of anal reason is that? Surely it's irrelevant what language anything is written in, insetad what matters is how good the program is. Or do you eliminate Haskell-based apps because you are a doting user who commits bug fixes back to projects? I doubt it.

The theory of patches is also more complex than you make it out to be. You only describe one of the simpler facets of the theory.

Re:Theory of patches

[jeif1k]

I have to agree with many other comments: the use of haskell eliminated it as a choice for me.

What should eliminate something as a choice for you is the use of a language with an un-sound and demonstrably error prone type system. You know, a language like C. But perhaps the source you maintain just isn't very important.

Needs wider adoption

[haeger]

While darcs is nice it needs wider adoption. When it comes to a project that people are working on, you have almost as many boxes as you have developers and for a revision control program to be adopted and used there has to be binaries for all those devels. AFAIR there are some issues with the win32 binary? One of our devels had major problems with it and now we're living with both a cvs and a darcs repository, and noone really knows where to send patches. I think it's safe to say that our project is dying, if not dead already.

Not that I blame darcs or anything, just that one need to be sure that darcs work for everyone before commiting to it. CVS works on all platforms and is well tested. Darcs will hopefully get there.

And yes, I did my part and created a package for my platform. It's linked from the binary download page.

.haeger

Re:Needs wider adoption

[Anonymous Coward]

CVS works on all platforms

... for an appropriate definition of "works".

CVS doesn't have atomic check-in, it's directory handling is crap, etc. etc. Still, like you said, it's probably still the best bet if you want to do development on both UNIX and Win32, although Subversion(!) is catching up fast.

Re:Needs wider adoption

[OldMiner]

One of our devels had major problems with it and now we're living with both a cvs and a darcs repository, and noone really knows where to send patches. I think it's safe to say that our project is dying, if not dead already.

Isn't the problem that you didn't make a firm commitment one way or another at that juncture? You had the option of either going all darcs or all CVS. It seems like instead of confronting the issue at the time, you let your project self destruct.

You could have chosen to switch to CVS and accepted losing the features of darcs.

You could have set an ultimatum for that developer. It's a small project, and you can't afford to be split. Most large projects can't. Offer a Knoppix CD, a shell account somewhere, to take patch files, or help getting the Windows binary working. Or give them the option of developing a fork on their own. I find it unlikely your developer would have left, and even if she had, your project might be better off for the lack of division. Meanwhile, a bug report might get the Win32 port fixed. But what was broken with it exactly which made it so bad?

Naturally, I don't know the details, so pardon me if darcs ate your developer's favorite president and she was sworn to revenge. But, it doesn't sound like the current state of events is very positive either.

Re:Needs wider adoption

[JamieF]

Har har har, thanks for trolling.

CVS "works" on all platforms as much as it "works" on any platform, which is obviously what the poster meant.

Subversion is catching up fast, because it has crossed the line of "better than CVS" for direct use by developers, though CVS still wins in terms of IDE integration. SVN was designed to replace CVS, but not to revolutionize the theory of version control. Based on TFA, it sounds like Darcs isn't mature enough to adopt quite yet, but in a few months it may be. (I felt the same way about Subversion a couple of years ago and now my project is using it and we're very happy with it.)

Already happened

[Hammer]

In my systems and my company CVS has long since been replaced with subversion. This is a OSS replacement that fixes CVS's shortcomings (such as atomic check in and directory versioning) It works real well, i'll never turn back.

Re:Already happened

[Anonymous Coward]

most likely stupid
most likely lie

Well said, sir. [nt]

[Anonymous Coward]

nt means there is NO text.

Choose the development tool you prefer

[curne]

It seems to me that a LOT of people in these comments are remarking that David's choice of Haskell makes darcs a no-go. I would make this comment:

If someone told you to use <Tool X> for a project, you would say, "No way, <Tool Y> is more suitable for this job, and it's what I want to use." (substitute X and Y with whatever - C/Java/Perl/VB - you want).

I think David chose what he felt was the best tool for the job, taking the problem-to-solve and his own expertise into consideration. In the light of Paul Graham's insights I really think he should be applauded rather than criticised.

decentralize CVS?

[Skadet]

Decentralize CVS? I have a hard enough time getting to the cash registers as it is, dammit!

Here:

[warrax_666]

I think you may find this page interesting.

Major differences:

1. Darcs is must less strict: For example, it doesn't have a built-in concept of branches/versions (which is necessary in Arch because of the patch ordering/application constraints).
   
2. All working directories are repositories themselves. This can be very useful (for example, it makes it trivial to manage /etc using darcs), but also somewhat dangerous.
   
3. Interactive approval of every recorded diff chunk (change). This may not sound like a big deal, but if you have spurious changes in a tree which you'd rather not record(*) in a given changeset, interactive prompting makes it a a lot easier to achieve clean changesets which only touch one "aspect" of the source at a time.
   

(*) Such as typo fixes, comment fixes, etc. which you just happened to notice while fixing a particular bug.

Re:Here:

[bani]

going by that page, subversion looks like a better deal than darcs.

Re:Here:

[Anonymous Coward]

going by that page, subversion looks like a better deal than darcs.

I fail to see that.

Re:Here:

[boa13]

One important feature is missing from the page:

Support for signing patches and archives

Allows to verify who created/commited the patches. Allows to verify the integrity of a repository in case of compromise.

* Arch: Excellent. Each patch can be signed, repositories can be fully verified.
* Darcs: Incomplete. Patches sent by email can be signed so the recipient can verify the identity of the submitter. No support for verifying repository integrity. [1]
* Subversion: N/A

[1] Problem is: You can only sign something that will not vary once distributed, Darcs patches vary once distributed.

Our experience CVS vs. DARCs

[ites]

We are looking at something to replace our ageing CVS system. We have large OSS projects, worked on by teams of 3-10 people. CVS is very good for what it does but we are feeling its limitations. The biggest problems are that forks are too delicate to use, so we don't use them, and that in order to work you need access to the central archive.

Darcs looked like the best choice. We converted and imported some of our archives. Then we tried checking them out. With CVS, 2-3 minutes. With darcs, 30 minutes.

Our conclusion: darcs is not scalable. Admittedly our code base is large and has a huge history, but in order to use darcs we would have had to break our projects into many small pieces, each with their own repository.

Darcs looks good. But it needs to be made much, much faster if it's to work with large projects.

Re:Our experience CVS vs. DARCs

[bani]

you might want to try subversion?

Re:Our experience CVS vs. DARCs

[eloki]

> Our conclusion: darcs is not scalable.

Um, isn't that basically in the article? In fact, when you read about darcs this caveat is described everywhere - the manual, webpages comparing OSS version control systems, posts I've seen about darcs on LWN, here on /. etc... A good investigation would have tipped you off to this fact before you started.

Re:Our experience CVS vs. DARCs

[master_p]

Is it because Haskell is an interpeted language, or it is a design fault? I doubt it is the language, but I thought to cover that base too.

Re:Our experience CVS vs. DARCs

[sinistral]

Haskell is typically compiled.

Re:Our experience CVS vs. DARCs

[David Roundy]

Darcs get (equivalent to CVS checkout) is the single least efficient command in darcs. People keep telling me I need to fix this, since it's the first thing users see, but it's really not an important command to optimize (apart from first impressions issues). When run locally (to create a new branch) it's fast.

And comparing darcs get with cvs checkout really isn't fair, since darcs gives you a copy of the full history of the repository, a separate branch on which to record changes before committing them to the centralized repository, and the ability to browse the history offline.

If you want a fast get, just run optimize --checkpoint on the parent repository (assuming you've tagged recently--if not, then tag the current state first), and then use the --partial flag when running darcs get. It'll still give you more flexibility than a cvs checkout, and will be much faster.

Re:Our experience CVS vs. DARCs

[lars_stefan_axelsson]

Haskell is typically compiled.

In the case of Darcs it can be said a bit stronger as Darcs relies on GHC (the Glorious Glascow Haskell Compiler) which doesn't even have an interpreter. The interactive command line of ghc (ghci) is really just an compile-then-immediately-execute line by line interactive environment.

That's not to say that Haskell is necessarily blazingly fast, it's somewhat difficult to compile lazy languages. If you want fast functional (as in micro benchmark fast) you should look towards O'Caml, that has been known to do as well as gcc in some cases.

Re:Our experience CVS vs. DARCs

[sirReal.83.]

"Darcs get (equivalent to CVS checkout) is the single least efficient command in darcs. ... And comparing darcs get with cvs checkout really isn't fair.."

You've lost me, unfortunately. Darcs does seem, in some ways, to be fantastically simple, but your explanation of how to do the real equivalent of a cvs checkout just sounds irritating.

Re:Our experience CVS vs. DARCs

[benja]

So why don't you make 'darcs get' use --partial by default, and require 'darcs get --all' to get the full history? Since most people will be familiar with 'cvs checkout' and a couple of people with 'tla get,' both of which get only the current version, it seems reasonable to me to make the default what people expect -- with the speed that people expect?

I like having the full history, but I think that in the usual case "check out the current version in 3 minutes" is a more reasonable default than "check out the whole history in 30 minutes." I think most 'darcs gets' will be of projects maintained by someone else where you want to look at the source or perhaps make a small modification to the current version. In that scenario, you want to go ahead ASAP, and you don't usually need the history.

BTW -- congrats on the great work on darcs!

Re:Our experience CVS vs. DARCs

[Anonymous Coward]

And comparing darcs get with cvs checkout really isn't fair, since darcs gives you a copy of the full history of the repository, a separate branch on which to record changes before committing them to the centralized repository, and the ability to browse the history offline.

Sure, even when not needed/wanted ...

Now, I've been reading dars-users, specially the "Colin Walters blogs on Arch changesets vs Darcs" thread, and it seems to me that adding the notion of globally unique entity ID's would be an easy way to solve some ugly problems, like these .

Also, I'm thinking that not having unique ID's is a flaw. My intuition is that an abstract notion of identity, outside of the space where patches work, is needed to solve all possible know and still-unknown problems with entity modification/history/etc. (not only contents).

it cuts it just fine

[jeif1k]

Lots of people know how to program in C or Perl to some degree, but you wouldn't want most of them modifying the version control system you are relying on. The pool of capable C or Perl programmer is actually much smaller. And even inexperienced Haskell programmers can do considerably less damage modifying Haskell code than they could modifying C or Perl code.

Furthermore, darcs doesn't need a "large group of developers", both because it's not a huge system and because it's written in Haskell. Being written in Haskell probably makes it an order of magnitude smaller and easier to maintain.

If you're currently using CVS...

[Phil John]

...why not make the jump to a system meant to replace CVS's centralized model, such as subversion. Forks are very easy to do, truly atomic commits, CVS to SVN repository converter, similar command line params to CVS etc. etc.

Our current repo is 9 gigs and works beautifully.

Linus opinion

[Anonymous Coward]

Do you see Darcs as a viable version control system for the Linux kernel?

How do you view Linus opinion on version control systems?

Huh?

[warrax_666]

I fail to see how. It isn't strictly superior in all categories, and there are certainly some significant differences which would make either (but not both) viable in certain scenarios.

Disclaimer: I'm currently using Arch for all my repos, but that's mainly because Haskell is not really supported properly on my architecture (by my distro). Yet.

Re:Huh?

[bani]

1) Subversion doesnt use haskell
2) File and Directories Copies (big feature!)
3) Repository Permissions
4) Ability to Work only on One Directory of the Repository (svn is much more flexible in this regard)
5) Availability of Graphical User-Interfaces.

the cvs-ish syntax is also a plus.

Re:Huh?

[Earlybird]

• 1) Subversion doesnt use haskell

How does this affect users?

• 2) File and Directories Copies (big feature!)

It's a big feature because it underlies Darcs' branching support. Darcs doesn't have a command to copy something within the repository; rather, you copy the entire repository.

• 3) Repository Permissions

Do you use them? Most people don't, as far as I know.

• 4) Ability to Work only on One Directory of the Repository (svn is much more flexible in this regard)

Agreed.

• 5) Availability of Graphical User-Interfaces.

Agreed. They're coming.

• the cvs-ish syntax is also a plus.

Darcs is also CVS-ish.

• "darcs init" -- "cvs init".
• "darcs get" -- "cvs checkout".
• "darcs pull" -- "cvs update".
• "darcs record" -- "cvs commit".
• "darcs whatsnew", "darcs diff" -- "cvs diff"
• "darcs changes" -- "cvs log"

Re:Huh?

[bani]

svn syntax is exactly the same as cvs for those:

svn init -- cvs init
svn checkout -- cvs checkout
svn update -- cvs update
svn commit -- cvs commit
svn diff -- cvs diff
svn log -- cvs log

its nice to have the same syntax, especially when youre working on multiple opensource projects using a mix of cvs and svn. (where the repositories arent under your control, youre just a developer)

Who cares?

[Julian Morrison]

Sure, if he wants to get a couple hundred entry-level code grinders in a hurry, if he were a business hiring modular, replaceable Windows monkeys, then Haskell would make his life hard.

However, neither of the above apply. This is basically a hobbyist project, a rare and rarified subject in both its spheres (version control and Haskell), with considerable overlap between the academic C.S. community that truly understands either.

"People won't learn a language for one program"? Not even if that program is one of the few and best in their area of expertise? Not even the handful of people needed to keep alive a tightly focused project like this?

Mostly agreed, but

[warrax_666]

I suspect your footnote is incorrect (although it been a long time since I looked at darcs and may remember incorrectly). IIRC, the patches themselves don't vary once distributed, just the ordering of them, so it should be possible to sign individual changes. Of course, this isn't nearly enough to verify repository integrity/authenticity, but I think something could be added relatively easily.

Re:Mostly agreed, but

[evvk]

Patches themselves do vary at least when a merger patch is needed (conflict). But this could be stored as a patch to the patch. It might even be possible to verify that the stored changes are correct.

Re:Mostly agreed, but

[David Roundy]

No, I'm afraid the footnote is dead on. When patches are commuted their content changes, although their meaning remains the same. This happens when people pull (or push) patches from one repository to another.

There is an idea, a repository of patch bundles, which could allow signed patches to be kept, at the cost of either duplication of information or inefficiency. It would "just need to be implemented." It would be a bit tedious, but is simple enough that it could be done (terribly inefficiently) using external scripts.

why not improve CVS?

[f3773t]

I have use CVS (and believe it or not ... I am ashamed to even say it I am now a source safe man)

Anyways ... why would one not rewrite CVS to make it better instead of running off and doing a new version control system in some obscure language?

After all CVS is established, been debugged for years by tonnes of users.

Re:why not improve CVS?

[HermanAB]

Exactly.

CVS is a client server system. People interface with the client. If anyone feels that CVS sucks, it is because they are using a bad client.

There are many CVS clients out there and all the issues people complain about can be fixed by finding a better/different one. With any other version control system, you are pretty much stuck with whatever kludge the project has, bacause there is only one.

Re:why not improve CVS?

[Alioth]

They have. It's called Subversion.
http://subversion.tigris.org/

Re:why not improve CVS?

[Anonymous Coward]

If anyone feels that CVS sucks, it is because they are using a bad client.

Nah.. CVS sucks by (lack of) design.

Re:why not improve CVS?

[f3773t]

I just checked out subversion ... it does seem a more sensible idea than going off on a tanget like darcs ... Still I reckon that is how innovation happens ppl trying out new things!

Re:why not improve CVS?

[f3773t]

That too is a valid point ... What would be interesting to note would be what is the proportion of CVS to RCS to SubVersion to Source Safe users out there!

RCS?

[HermanAB]

How would decentralizing CVS be an improvement? CVS utilities can already work in both RCS and CVS modes.

Re:RCS?

[Anonymous Coward]

Makes it easier to create your own local repository, i.e. make changes/fork when you don't have commit access to the official version?

Re:Darcs vs Svn

[imbaczek]

Install your first ever copy of Haskell, and begin to learn the 'theory of patches'...

That's bullshit. You don't need to know even Haskell's name to use darcs. Same applies to theory of patches.

Re:Darcs vs Svn

[jeif1k]

You need to "learn Haskell and the theory of patches" to use darcs about as much as you need to learn C programming and diff algorithms in order to use Subversion, namely not at all.

How does Darcs handle patches by email?

[Anonymous Coward]

Do you need to run a unique UNIX user account and have a special program to pop3 the patches? How can you "cherry-pick" the patches - is there a GUI?

Re:How does Darcs handle patches by email?

[Earlybird]

• Do you need to run a unique UNIX user account and have a special program to pop3 the patches?

No. The receiver end is you and your email program. You accept patches by piping the patch to "darcs apply". You reject patches by doing nothing (or replying with a rejection note). Writing a macro in Mutt og Emacs or whatever should be trivial.

• How can you "cherry-pick" the patches

You pull selectively by patch name: "darcs -p regexp".

Re:How does Darcs handle patches by email?

[Anonymous Coward]

Thanks for the detailed explanation. Darcs looks pretty cool.

Fragmentation?

[Anonymous Coward]

Isn't OSS generally fragmented enough already? Distributed version control is all about making forking easier, or am I missing something?

Patches applied out of order - freedom or folly?

[Anonymous Coward]

Having designed,implemented and supported an enterprise-wide (1200+ user) Configuration Management services for over 3 years, I find that the number one thing that most developers want is version control that STAYS OUT OF THE WAY. They DON'T want every bell and whistle. They have to concentrate on their code, not some "neat" (or read pain in the a$$) way to do something.

I support ClearCase/ClearQuest worldwide for a large corp. I deal with the helpdesk calls, the support, the engineering efforts the "best practices", and sometimes the teaching of best practices.

Why would anyone want to deliver a patch out of sequence? It should make sense in the simplest sense, i.e. "if I apply this I get that". Most developers don't concentrate that deep.

I personally think ClearCase is great if your industry is software development, but for regular development, it's like driving a tank to the store for a loaf of bread. and it's EXPENSE!!!!!

If I had to move to another product, I would at this time choose Subversion. It's super simple, fast, distributed (for world-wide development efforts or content submissions) and well supported. It has support for Eclipse, a Windows client and a good security model.

I looked at other systems and was always amazed by the convoluted version models.

And why would I let developers "declare" a set of files as a "change"? It's hard enough to get the concept of a baseline into their heads. They always look at it as "I only changed 2 files, why do I have to label everything?" and I always have to ask "How do you tell what made up a version?".

There's a LOT more than neat ways to do things involved in configuration management.

I would LOVE to see a simple application that could track defects/Change Requests and link them to a version or baseline SIMPLY. Simple is not easy, because the truth is that managing change in a distributed model is very difficult. By simple I mean simple to use, simple to manage, and simple to maintain.

I haven't found it yet, but I have found parts. I may have to roll up my sleeves soon.

Readable version

[Anonymous Coward]

http://shit.slashdot.org/article.pl?sid=04/11/25/0 136249

Larry McVoy speaking at SCALE 3x

[Anonymous Coward]

Larry McVoy, founder of BitMover will be speaking about distributed revision control at SCALE this February.

footnote -- whoops

[ArbitraryConstant]

er...

1- C, C++, Objective C, Java, Python, {SPARC, x86} assembly, LISP, Haskell, Prolog, Pascal, VB (blearghhh), shell

Uhm.

[warrax_666]

its nice to have the same syntax

Only if the semantics are the same. If the semantics differ (subtly) it's not a good thing. Besides, you still haven't shown your original claim (that svn is strictly superior to darcs). Yes, svn is superior to darcs in some ways, but darcs is also superior to svn in some regards.

Re:Uhm.

[bani]

the semantics are exactly the same.

svn is superior to darcs in every way that matters to me -- darcs does not have a single point win over svn for me, and many point losses.

but the fact you're using arch instead of dacs speaks volumes.

Distributed vs. centralized repositories

[Ian Bicking]

I played around with several source control systems a while back; I like Darcs, it was the easiest of the distributed systems to understand, with a concise and easy-to-understand command-line interface.

But in the end I think a centralized repository is right for many (most?) projects: Why Bitkeeper Isn't Right For Free Software (by Greg Hudson) was the most convincing argument to me.

Of course, you can simulate a centralized model with a distributed system (just don't use the distributed bits), but it seems like you are on your own at that point. Subversion is behind when you compare distributed features (of course), but when you compare the other features (usability, access via various method, programmatic access, etc), it's way ahead. As it would be; centralized systems are easier to think about, so they are easier to develop with and on top of.

Why is it slow?

[Julian Morrison]

I mean, a get as I comprehend it should consist of 2 operations
- get all the changesets, and an annotation of how they fit together
- compute (or for efficiency merely copy) the end product

Both ops could be implemented as straight-up file copies, duration: sod all (give or take bandwidth). So why isn't it so simple?

As an alternative

[Julian Morrison]

...you (or someone) could work out a way to canonicalize the "meaning" of a patch, so this canonical form would be immutable across commutations, and could be signed.

... like these (forgot slashdot URL: ...)

[Anonymous Coward]

... like these: http://www.abridgegame.org/pipermail/darcs-users/2 004-November/004396.html

(Sorry, fscking slashdot tags...)