5 ms·

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

tomjakubowski 10y ago
Check the README :-) http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/README?rev=1.2&content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/README?rev=...
- Esau 10y ago
  Seems to me that it should be renamed.
  - notaplumber 10y ago
    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.
    - int_19h 10y ago
      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).
      - Gracana 10y ago
        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.
        int_19h 10y ago
        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.
        IcePic 10y ago
        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.
        int_19h 10y ago
      - avar 10y ago
        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.
        int_19h 10y ago
        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.
        ben_bai 10y ago
        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.
        alex_hitchins 10y ago
        > 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.
- jaytaylor 10y ago
  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 http://cvsweb.openbsd.org/cgi-bin/cvsweb/#dirlist And wish github provided navigation that was as easy and lightweight as this.
flupzor 10y ago
See the README file in src/gnu/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/gnu/README?rev=1.2&content-type=text/plain http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/gnu/...
tobik 10y ago
src/gnu already has Perl in it, which isn't a GNU project or under the GPL either.
- avar 10y ago
  Perl is dual-licensed under the GPL & the Artistic license: https://github.com/Perl/perl5/blob/blead/README#L83 https://github.com/Perl/perl5/blob/blead/README#L83

Check the README :-) http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/README?rev=1.2&content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/README?rev=...

Esau 10y ago
Seems to me that it should be renamed.
- notaplumber 10y ago
  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.
  - int_19h 10y ago
    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).
    - Gracana 10y ago
      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.
      - int_19h 10y ago
        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.
        IcePic 10y ago
        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.
        int_19h 10y ago
    - avar 10y ago
      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.
      - int_19h 10y ago
        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.
        ben_bai 10y ago
        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.
        alex_hitchins 10y ago
        > 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.
jaytaylor 10y ago
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 http://cvsweb.openbsd.org/cgi-bin/cvsweb/#dirlist And wish github provided navigation that was as easy and lightweight as this.

flupzor 10y ago

See the README file in src/gnu/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/gnu/README?rev=1.2&content-type=text/plain http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/gnu/...

tobik 10y ago

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

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