Hacker News Reader

Hacker News

Comment by wolf550e | Hacker News Reader

Full thread

wolf550e

Why under src/gnu ? It's not a GNU project, it's not under GPL.

View on HN

Check the README :-)

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/README?rev=...

Seems to me that it should be renamed.

CVS versions files, not directories.. and it also doesn't support renames or moves, not without some repository hackery. The historic purpose of src/gnu/ is irrelevant now, it's just a common place for "Gigantic and Nasty, but Unavoidable" software.

So the more appropriate question is, why is someone still using CVS? In 2016? For a collaborative open source project?

I understand that a certain degree of conservatism in software can be beneficial, but given just how limited CVS is, it would be kinda like writing code in ed (now I hope no-one actually does that).

Because it works for the people who are doing the work. Many outsiders have suggested that they switch, but that advice never seems to take hold.

There are a lot of things that "work". If you need to edit files, "ed" works to edit files, for example. But if someone was using that outside of scripts today, I think it's not unreasonable to ask why.

The question is, why, knowing that there are things that work vastly better (I'm not speaking hypothetically here - I used CVS for many years myself, and I remember all the painful limitations, and the nearly universal joy on the team when we finally migrated to Subversion), they still stick to that old stuff?

Sure, there's some cost to migration, but it's been done thousands of times before by other people, so there are a lot of tools that automate all that, and vast knowledge about how to do it right. So the cost really low compared to the objective benefits that they would get - such as, well, being able to rename things without wiping history, or tracking changes across several files etc.

So, is it really just the "that's how we did that in the good old days, and that's how we like it - now get off my lawn" sort of thing, or are there some technical reasons why they consider CVS good enough? I'm hesitant to assume the former until I can definitely ascertain that it's not the latter.

Well, your ed comparison could aswell be made for vi -vs- emacs (or Eclipse spit). As long as the code being written is entered as fast as someone can type on the keyboard, it really doesn't matter which editor they use. Sure, vim and emacs and bloaty-stuff-in-java can help in various ways, but since they aren't really writing the code for you, if the limit is how fast you can write the code, the amount of java or elisp or vim-scripts around your text editor won't have a large impact on how good network code or how safe your string handling is.

I won't argue that the opposite is true, but the general speed limit in openbsd is not the tooling or even the meta-tooling around the source tree, but rather how many decent coders is active at this moment and how much useful code can they get reviewed and committed.

I don't think I've ever seen something along the lines of "phew, if I hadn't had $weird-dvcs in place, I could not have invented this provably correct parallel AVX-accelerated version of SHA768" or something to that effect.

But it isn't vim vs Emacs, that's the whole point! If we were talking about two different apps with comparable feature sets, at least for common operations, sure. But CVS is really vastly inferior even to Subversion, to which e.g. FreeBSD migrated 7 years ago.

Just to make it clear, I'm not complaining about OpenBSD using CVS in general, or claiming that they are too slow or missing features because of it. I'm just wondering why, in this day and age, anyone would use CVS when so many clearly better alternatives exist. I know I would be frustrated if I had to code in a CVS repo, and would push to get it migrated to at least SVN just to make my own life more comfortable. So it naturally makes me wonder why other people in that situation, who presumably know at least as much as me, do not.

I think the reason is that the versioning tooling is 1% of the work, so making it 0.5% would not be "twice as effective", it would move from 100% to 99.5% work to be an openbsd dev.

Diffs mailed between devs still look the same, oks for diffs are still a social construct that needs persons and not programs.

No, the real question is why certain people on HN that likely won't even use OpenBSD let alone contribute to its source code are complaining about what VCS it's using, or what the directory structure of its source repository is like.

You seem to be making an awful lot of assumptions about someone you don't know.

I was actually picking a BSD to install on a laptop recently. OpenBSD got dropped off the list when I found out that they still use CVS for base system and ports (because, yes, I do intend to hack on those).

In any case, your basic premise is wrong. If you see someone riding a horse buggy on a freeway, it's not unreasonable to ask why they're doing that.

I thank you for your wise decision. The question gets old, but CVS fits their development style and release cycle fine. Yes it's ancient but the-known-evil (against the unknown-evil), and it's the whole CVS, AnonCVS, Patch, Mail, Build cycle that would need changing.

> If you see someone riding a horse buggy on a freeway, it's not unreasonable to ask why they're doing that.

Surely it must work for them I'd be thinking. If you use a tool that still works and has worked, changing for the sake of it seems unnecessary.

I really dig that the entire source tree is navigable and viewable via a familiar FS-like tree layout: http://cvsweb.openbsd.org/cgi-bin/cvsweb/#dirlist

And wish github provided navigation that was as easy and lightweight as this.

See the README file in src/gnu/

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/gnu/...

src/gnu already has Perl in it, which isn't a GNU project or under the GPL either.

Perl is dual-licensed under the GPL & the Artistic license: https://github.com/Perl/perl5/blob/blead/README#L83

Reply on news.ycombinator.com