5 ms·

Here's the change itself: https://github.com/openbsd/src/commit/a6105854a9e3aab642e6a0fc34d464b61ded7d92 https://github.com/openbsd/src/commit/a6105854a9e3aab64

by rany_ 2y ago

Here's the change itself: https://github.com/openbsd/src/commit/a6105854a9e3aab642e6a0fc34d464b61ded7d92 https://github.com/openbsd/src/commit/a6105854a9e3aab642e6a0... I know that OpenBSD doesn't actually use GitHub, but it was the easiest way I could find the diff. I don't know how to otherwise get it from that mailing list entry.

asveikau 2y ago
They have a cvsweb instance on their website, but the UI is a little more old school than github, so the github mirror is often good for browsing anyway. https://cvsweb.openbsd.org/ https://cvsweb.openbsd.org/
- OJFord 2y ago
  > the UI is a little more old school No kidding! GP's point stands though, how are you supposed to get there from the submission? I assume if you subscribed to the mailing list yourself the patch would be attached, but afaict TFA doesn't even show that. I don't really understand how people can work like this, not anti-email, or everything must be GitHub, or anything - but it can still be a lot more modern and featureful than this can't it? I don't really understand why it isn't.
  - asveikau 2y ago
    I think the best way is probably to check out the CVS repo on your machine, then run cvs log, and cvs diff. That's the way everybody used to work? I can't recall if there were local x11 visualizing tools like gitk is today. (Google says tkcvs) I remember there were some graphical diff programs, you could set an environment variable and make the "cvs diff" command show something nicer looking. Recall that git was also designed to work over mailing lists. git format-patch, git apply, etc.
    - mlyle 2y ago
      > I think the best way is probably to check out the CVS repo on your machine, then run cvs log, and cvs diff. I've used cvs a bit recently. It's amazing how poor the performance is on large repositories, even on modern machines. I can't figure out how I put up with this 20 years ago.
      - asveikau 2y ago
        I remember following the openbsd stable branch about 20 years ago and it was indeed very slow to simply check out and update. Svn felt much better even though it wasn't a revolutionary improvement. I guess that's why the errata page has source patches. It's also great that they have syspatch now for fast binary patches
      - toyg 2y ago
        Everything was slower back then; we just worked at a slower pace and "disconnected". Turn on the PC, and go make coffee; start a build, and go over notes and comments again; start a download, and clean up the desk or go for a drink at the cooler; launch a big report, and make a phone call. Now we're so completely absorbed by the screen for so long, we get irritated by any perceived delay.
        Bagged2347 2y ago
        I want to work in the world you described. I'm 28 and irritated by the pace of modern work, but I have nothing to compare it to and your comment made me ponder. I feel as if there's no room to breathe. Do you have any stories to share?
        anthk 2y ago
        Get an Usenet account at https://www.eternal-september.org https://www.eternal-september.org, roam around the comp.lang.* groups, setup slrn to fetch news offline and answer to the groups in 'batch' mode, there's slrnpull for that. Learn the basics of C and Perl for automation, Perl can do tons of *unix stuff (awk/sed... but better). Mark Burguess has books on Perl/C (ANSI C and GNU C) and the basics of C++ with systems' programming. I know today Golang would be more apt but if you know how the things work under the shiny stuff, you will apply most of the knowledge from Unix systems' programming to Go in a breeze. Once you begin to automate scripting, testing and repetitive stuff, you will spend less time with computers.
    - eru 2y ago
      > That's the way everybody used to work? No. In the bad old days, for many people version control software wasn't sufficiently better (and in some respects much worse) than just not using any. So many people didn't use any.
      - asveikau 2y ago
        You're right, I forgot that it was common to not use source control. However I feel like it was pretty universally recognized to be the "proper" thing to do.
      - medoc 2y ago
        This is true but it was certainly not considered good practise even at the time. I've been on the seller part of a few software companies acquisitions from the early nineties, and checking what kind of source control we were using and how was part of every audit. A long history of sccs -> cvs -> subversion ->mercurial or git...
        eru 2y ago
        Yes, though eg Linus Torvalds famously said that them mailing around tar-balls was better than CVS.
    - OJFord 2y ago
      Like I said, not anti-email. I don't see why it's git vs cvs: > Recall that git was also designed to work over mailing lists. git format-patch, git apply, etc. Right, and when you do web things with that same git in 2024, it looks and works like it's 2024. You could use an old git server/file browser UI, or the built-in gitweb[0] for example, but you don't, you use something more modern & featureful, working better on mobile, looking prettier, etc. Even Linux (with its history intertwined with git) uses Github[1] as its mirror, not gitweb or anything looking like the link above for OpenBSD. [0]: https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/ https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/ [1]: https://github.com/torvalds/linux https://github.com/torvalds/linux
      - asveikau 2y ago
        If it's something I work on habitually and keep clones of, I prefer to use gitk to browse a local repo over something like GitHub web ui. Maybe I've just gotten old though.
        OJFord 2y ago
        Sure, but you presumably don't put up a bad/old-looking web UI to not use as well? That was my point, given that it's hosted somewhere, why so poorly.
  - SoftTalker 2y ago
    > I don't really understand how people can work like this It's all what you're accustomed to. Git confuses the heck out of me every time I use it for anything more complicated than clone, pull, commit, or push.
    - asveikau 2y ago
      I highly recommend learning about rebase. Very handy to be able to re-order, re-word, merge multiple commits into one, fix issues within a commit ... Basically tidy up the history locally before you push it.
      - andybp85 2y ago
        wholeheartedly agree, git rebase -i is a game-changer once you get comfortable with it
    - nine_k 2y ago
      Have you tried reading https://tom.preston-werner.com/2009/05/19/the-git-parable https://tom.preston-werner.com/2009/05/19/the-git-parable ? I bet you're smart enough to understand it. Inside, git inside is much more logical and neat that the (unfortunate) historical CLI makes it feel. It's a shame it holds people back from using this very powerful and useful tool. (Once you've reached understanding, switch to magit, gitui, tig, etc, for comfort and speed.)
      - SoftTalker 2y ago
        No, I just don't use it often enough in any other scenarios. I pretty much do solo work these days, I don't need rebasing or branches or pull requests or anything like that. I honestly don't really need version control at all but it's a pretty baked-in habit. I thought svn was nice, a good balance of capability and understandability. It worked well in the "central respository" style of the day, which is effectively how I work. On the other hand I'm quite comfortable with long shell pipelines using find and xargs and awk and other utilities that are at least as arcane as git, so like I said, it's all what you are accustomed to. If I were doing git feature branches, rebases, and pull requests every day at work, I'd probaly feel that they were pretty easy.
  - inopinatus 2y ago
    Back when I was directly subscribed to various bsd src/commit lists, I had a delivery filter that would attach the delta if the list didn’t do so already.
  - mbivert 2y ago
    [0] offers a few insights: license, habits, history, why change something that works, etc. You might also be interested in[1]. [0]: https://cvs.afresh1.com/~andrew/o/why-cvs.html https://cvs.afresh1.com/~andrew/o/why-cvs.html [1]: https://gameoftrees.org/index.html https://gameoftrees.org/index.html
    - playingalong 2y ago
      > It is unlikely that any alternative versioning system would improve the developer's productivity or quality. This is likely true for existing developers. But might discourage some fresh blood from joining. So in the long run the overall productivity might suffer from this.
      - mbivert 2y ago
        > But might discourage some fresh blood from joining. That's probably more of a feature than a bug: it acts as a "natural" filter.
        playingalong 2y ago
        If you assume willingness to learn CVS is in line with being able to provide valuable contributions. I have worked with CVS myself in the past and would probably have no problem getting used to again. Some fresh out of school smart people might consider it a thing of the past. And just decide not to deal with it. Like COBOL.
        mbivert 2y ago
        > If you assume willingness to learn CVS is in line with being able to provide valuable contributions. This, but also: "can you make an effort to conform yourself to others instead of forcing others to conform to you;" Inexperienced people often lack the visibility of their elders, so it really makes sense to see whether they can lower their ego. > Some fresh out of school smart people might consider it a thing of the past. And just decide not to deal with it. Like COBOL. Are you using "smart" positively or not? Being smart is often frowned upon in SE. Then, driving smart people away still is a good thing. If you meant positively... considering things of the past to be useless by mere virtue of being of the past, is definitely not a positive character trait, so we'd have a contradiction. Side note, but the problem with COBOL is not that it's old; to quote wikipedia: > COBOL has been criticized for its verbosity, design process, and poor support for structured programming. These weaknesses result in monolithic programs that are hard to comprehend as a whole, despite their local readability.
  - dn3500 2y ago
    It's not hard if you understand how cvs works. The email says the files are in the "src" module, so you select that from the cvsweb page. Then it's just a matter of drilling down to the individual files. Here is the diff for the Makefile for example: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games/quiz/Makefile.diff?r1=1.8&r2=1.9 https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games/quiz/Mak... As for how you work like that, the number of people with commit access is small and they all know each other. There aren't a lot of branches. Most of the collaboration features of git aren't needed.
- tambourine_man 2y ago
  IMO we got used to GitHub’s UI, but it’s far from intuitive. Just watch someone who never use it before.
egorfine 2y ago
...are they actually using CVS? the CVS?

by rany_ 2y ago

asveikau 2y ago

They have a cvsweb instance on their website, but the UI is a little more old school than github, so the github mirror is often good for browsing anyway. https://cvsweb.openbsd.org/ https://cvsweb.openbsd.org/

OJFord 2y ago
> the UI is a little more old school No kidding! GP's point stands though, how are you supposed to get there from the submission? I assume if you subscribed to the mailing list yourself the patch would be attached, but afaict TFA doesn't even show that. I don't really understand how people can work like this, not anti-email, or everything must be GitHub, or anything - but it can still be a lot more modern and featureful than this can't it? I don't really understand why it isn't.
- asveikau 2y ago
  I think the best way is probably to check out the CVS repo on your machine, then run cvs log, and cvs diff. That's the way everybody used to work? I can't recall if there were local x11 visualizing tools like gitk is today. (Google says tkcvs) I remember there were some graphical diff programs, you could set an environment variable and make the "cvs diff" command show something nicer looking. Recall that git was also designed to work over mailing lists. git format-patch, git apply, etc.
  - mlyle 2y ago
    > I think the best way is probably to check out the CVS repo on your machine, then run cvs log, and cvs diff. I've used cvs a bit recently. It's amazing how poor the performance is on large repositories, even on modern machines. I can't figure out how I put up with this 20 years ago.
    - asveikau 2y ago
      I remember following the openbsd stable branch about 20 years ago and it was indeed very slow to simply check out and update. Svn felt much better even though it wasn't a revolutionary improvement. I guess that's why the errata page has source patches. It's also great that they have syspatch now for fast binary patches
    - toyg 2y ago
      Everything was slower back then; we just worked at a slower pace and "disconnected". Turn on the PC, and go make coffee; start a build, and go over notes and comments again; start a download, and clean up the desk or go for a drink at the cooler; launch a big report, and make a phone call. Now we're so completely absorbed by the screen for so long, we get irritated by any perceived delay.
      - Bagged2347 2y ago
        I want to work in the world you described. I'm 28 and irritated by the pace of modern work, but I have nothing to compare it to and your comment made me ponder. I feel as if there's no room to breathe. Do you have any stories to share?
        anthk 2y ago
        Get an Usenet account at https://www.eternal-september.org https://www.eternal-september.org, roam around the comp.lang.* groups, setup slrn to fetch news offline and answer to the groups in 'batch' mode, there's slrnpull for that. Learn the basics of C and Perl for automation, Perl can do tons of *unix stuff (awk/sed... but better). Mark Burguess has books on Perl/C (ANSI C and GNU C) and the basics of C++ with systems' programming. I know today Golang would be more apt but if you know how the things work under the shiny stuff, you will apply most of the knowledge from Unix systems' programming to Go in a breeze. Once you begin to automate scripting, testing and repetitive stuff, you will spend less time with computers.
  - eru 2y ago
    > That's the way everybody used to work? No. In the bad old days, for many people version control software wasn't sufficiently better (and in some respects much worse) than just not using any. So many people didn't use any.
    - asveikau 2y ago
      You're right, I forgot that it was common to not use source control. However I feel like it was pretty universally recognized to be the "proper" thing to do.
    - medoc 2y ago
      This is true but it was certainly not considered good practise even at the time. I've been on the seller part of a few software companies acquisitions from the early nineties, and checking what kind of source control we were using and how was part of every audit. A long history of sccs -> cvs -> subversion ->mercurial or git...
      - eru 2y ago
        Yes, though eg Linus Torvalds famously said that them mailing around tar-balls was better than CVS.
  - OJFord 2y ago
    Like I said, not anti-email. I don't see why it's git vs cvs: > Recall that git was also designed to work over mailing lists. git format-patch, git apply, etc. Right, and when you do web things with that same git in 2024, it looks and works like it's 2024. You could use an old git server/file browser UI, or the built-in gitweb[0] for example, but you don't, you use something more modern & featureful, working better on mobile, looking prettier, etc. Even Linux (with its history intertwined with git) uses Github[1] as its mirror, not gitweb or anything looking like the link above for OpenBSD. [0]: https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/ https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/ [1]: https://github.com/torvalds/linux https://github.com/torvalds/linux
    - asveikau 2y ago
      If it's something I work on habitually and keep clones of, I prefer to use gitk to browse a local repo over something like GitHub web ui. Maybe I've just gotten old though.
      - OJFord 2y ago
        Sure, but you presumably don't put up a bad/old-looking web UI to not use as well? That was my point, given that it's hosted somewhere, why so poorly.
- SoftTalker 2y ago
  > I don't really understand how people can work like this It's all what you're accustomed to. Git confuses the heck out of me every time I use it for anything more complicated than clone, pull, commit, or push.
  - asveikau 2y ago
    I highly recommend learning about rebase. Very handy to be able to re-order, re-word, merge multiple commits into one, fix issues within a commit ... Basically tidy up the history locally before you push it.
    - andybp85 2y ago
      wholeheartedly agree, git rebase -i is a game-changer once you get comfortable with it
  - nine_k 2y ago
    Have you tried reading https://tom.preston-werner.com/2009/05/19/the-git-parable https://tom.preston-werner.com/2009/05/19/the-git-parable ? I bet you're smart enough to understand it. Inside, git inside is much more logical and neat that the (unfortunate) historical CLI makes it feel. It's a shame it holds people back from using this very powerful and useful tool. (Once you've reached understanding, switch to magit, gitui, tig, etc, for comfort and speed.)
    - SoftTalker 2y ago
      No, I just don't use it often enough in any other scenarios. I pretty much do solo work these days, I don't need rebasing or branches or pull requests or anything like that. I honestly don't really need version control at all but it's a pretty baked-in habit. I thought svn was nice, a good balance of capability and understandability. It worked well in the "central respository" style of the day, which is effectively how I work. On the other hand I'm quite comfortable with long shell pipelines using find and xargs and awk and other utilities that are at least as arcane as git, so like I said, it's all what you are accustomed to. If I were doing git feature branches, rebases, and pull requests every day at work, I'd probaly feel that they were pretty easy.
- inopinatus 2y ago
  Back when I was directly subscribed to various bsd src/commit lists, I had a delivery filter that would attach the delta if the list didn’t do so already.
- mbivert 2y ago
  [0] offers a few insights: license, habits, history, why change something that works, etc. You might also be interested in[1]. [0]: https://cvs.afresh1.com/~andrew/o/why-cvs.html https://cvs.afresh1.com/~andrew/o/why-cvs.html [1]: https://gameoftrees.org/index.html https://gameoftrees.org/index.html
  - playingalong 2y ago
    > It is unlikely that any alternative versioning system would improve the developer's productivity or quality. This is likely true for existing developers. But might discourage some fresh blood from joining. So in the long run the overall productivity might suffer from this.
    - mbivert 2y ago
      > But might discourage some fresh blood from joining. That's probably more of a feature than a bug: it acts as a "natural" filter.
      - playingalong 2y ago
        If you assume willingness to learn CVS is in line with being able to provide valuable contributions. I have worked with CVS myself in the past and would probably have no problem getting used to again. Some fresh out of school smart people might consider it a thing of the past. And just decide not to deal with it. Like COBOL.
        mbivert 2y ago
        > If you assume willingness to learn CVS is in line with being able to provide valuable contributions. This, but also: "can you make an effort to conform yourself to others instead of forcing others to conform to you;" Inexperienced people often lack the visibility of their elders, so it really makes sense to see whether they can lower their ego. > Some fresh out of school smart people might consider it a thing of the past. And just decide not to deal with it. Like COBOL. Are you using "smart" positively or not? Being smart is often frowned upon in SE. Then, driving smart people away still is a good thing. If you meant positively... considering things of the past to be useless by mere virtue of being of the past, is definitely not a positive character trait, so we'd have a contradiction. Side note, but the problem with COBOL is not that it's old; to quote wikipedia: > COBOL has been criticized for its verbosity, design process, and poor support for structured programming. These weaknesses result in monolithic programs that are hard to comprehend as a whole, despite their local readability.
- dn3500 2y ago
  It's not hard if you understand how cvs works. The email says the files are in the "src" module, so you select that from the cvsweb page. Then it's just a matter of drilling down to the individual files. Here is the diff for the Makefile for example: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games/quiz/Makefile.diff?r1=1.8&r2=1.9 https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games/quiz/Mak... As for how you work like that, the number of people with commit access is small and they all know each other. There aren't a lot of branches. Most of the collaboration features of git aren't needed.
tambourine_man 2y ago
IMO we got used to GitHub’s UI, but it’s far from intuitive. Just watch someone who never use it before.

egorfine 2y ago

...are they actually using CVS? the CVS?