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.

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.

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.

Git bisect is one example of this. If you know roughly when a bug was introduced, you can do an O(log n) binary search to find what commit introduced it.

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.

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.

Now we're so completely absorbed by the screen for so long, we get irritated by any perceived delay.

This said, you can and should slow it down if you feel overwhelmed, generally speaking. Use reminders to break every 45 minutes or so, then stand up and walk around. Take longer lunches. Generally speaking, lower expectations about your productivity - which, in itself, should not be a life goal. The cult of productivity helps capital, not people. We should be kinder to ourselves.

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.

I guess that's why the errata page has source patches. It's also great that they have syspatch now for fast binary patches

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.

> 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/

[1]: https://github.com/torvalds/linux

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.

There are strong mindset differences between various software communities; it might takes a little bit of time & effort to appreciate a more frugal/conservative approach to software engineering.

The previous links highlighted some aspects of those mindset differences. [0], while unrelated to OpenBSD, is another good illustration.

That's to say, OpenBSD people probably don't care much for a more featureful experience: it won't make them more productive, even if it may look like it would from the outset.

[0]: https://rachelbythebay.com/w/2011/09/24/editor/

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.

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.

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.

    $luw$:{I} [loose|destroy]
    $eluon$:{I} [loosed|destroyed|was loosing|was destroying]
    $elusa$:{I} [loosed|destroyed]
    $leluka$:{I} have [loosed|destroyed]
    $lusw$:{I} will [loose|destroy]
    $luswn$:[loosing|destroying]
    $lusas$:{having} [loosed|destroyed]

The worst part of this format is probably that if you did "quiz english greek" it wouldn't accept any form of accent or breathing marks, even though these are also standardized in beta code and some people would probably try to type them, like "e)luon" to show that there's no /h/ sound at the beginning of that word. And I don't think typing beta code in between dollar signs is a very common convention today, but the quiz would require it; you can't just type "luw", you have to type "$luw$".

If we are using two valid ending forms of Subjunctive (-era/-ese) since forever, IDK why couldn't we set these irregular verbs back to regularity.

The Spanish conjugations -ar, -er, and -ir derive from Latin conjugations, which are usually analyzed as having four different regular conjugation patterns (there are long and short e, giving -ēre and -ere, in addition to -āre and -īre), although one can choose to make additional distinctions.

Generally older Indo-European languages have more complex morphology than newer ones, including more paradigms and more irregular forms. Ancient Greek verbs are definitely morphologically more complex than modern Spanish verbs.

Am I interpreting this correctly in that, given that OpenBSD was created as a fork from NetBSD - there's now not a single line of (original) NetBSD code left in OpenBSD?

If it weren't for such an incredible specific example of how it wasn't so you would feel extremely justified in your initial position though. That's the danger with these types of thoughts, they are often easy to come up with, easy to feel confident about, and hard for anyone else to disprove.