stsp

My dad has very bad hearing, and can be quite noisy sometimes to the point of being annoying. I remember complaining to him about this occasionally. I never considered he might be worried about annoying others, and may be trying to hide his anxiety on top of that. I'll have to ask him. Thanks Mel.

vi history in BSD goes back to 1980

Sources are at http://svnweb.freebsd.org/csrg/usr.bin/ex/

Yes, that's known. Coincidentally, this came up today: http://marc.info/?l=openbsd-misc&m=141501277608157&w=2

The device timeout message might not necessarily be a fatal problem. If it doesn't have an impact on actual usage you can just ignore it. Otherwise, please file a quality bug report so we can learn more about it.

> Only exception I ran into is wireless card in an old MacBook Pro which should work but doesn't.

If this was a bwi(4) card, the problem is probably fixed in 5.6: http://marc.info/?l=openbsd-cvs&m=140585757928895&w=2

I like the default pager in 'git log', too.

Some work has been done on the svn side: http://svn.apache.org/repos/asf/subversion/branches/automati...

However, it's not on trunk yet because it's hard to find good defaults. An automatic pager makes sense for some commands, but not all -- and in a meritocratic development model this kind of thing can cause an endless discussion... I suspect we'll eventually merge the feature in a disabled by default state and allow users to enable it on a per-command basis.

Git's hard-coding of options passed to the pager has problems, too: https://mail-archives.apache.org/mod_mbox/subversion-dev/201...

Fossil is great. I've been using it increasingly for some of my projects, mostly OpenBSD related where I need versioning before the code moves into CVS. E.g. I used fossil for about a year during the initial development phase of OpenBSD's rtsx(4) card reader driver.

Since fossil has the ability to open a repository (which is a single sqlite database file) in any arbitary directory it nicely overlays with other versioning systems without wanting to store its meta data in hidden directories within the same tree. I often add a bunch of files from /usr/src to a new .fossil file in my home directory for temporary local version control.

You can migrate to fossil from CVS by converting to git first (using e.g. uwe's excellent git-cvs converter at https://github.com/ustuehler/git-cvs), and then generate a git-fast-export stream which you can import into fossil with 'fossil import'. I once tried this with the OpenBSD CVS repository but aborted the import after 7 days. By then it had imported history from 1995 to somewhere in the year 2000, and I was convinced that fossil can't handle trees this large (or histories this deep? Not sure which). This was with a hack to the fossil import code to make it use less sqlite transactions... without that it was even worse (sqlite can handle many queries per second but not so many transactions). So if your code base is large your should consider Subversion or (unless your code base is humongous) git instead.

It is not mere stubbornness.

The main reason is that CVS works well enough for our purposes. Most of the diff sharing and discussion happens over email anyway. That's where all the action is.

The main use case is that CVS distributes OK'd patches and allows us to revert them if they are later found to cause problems.

Everyone works on the head branch so there are never any surprises caused by delayed integration. Instead of using branches, the workflow switches between development mode and release mode when the time is right. Release branches receive only a handful of patches (usually less than 10) for the most critical issues discovered during their 1 year maintenance period. Again, CVS is entirely adequate for that.

It's not like there was no usage of git at all. Some devs actually use git in private and even mail git-generated diffs around. If those diffs fail to apply to the CVS tree the burden is on them to fix that. Since x.org runs git, all the X11 and other graphics code is ported to OpenBSD in git branches by our X maintainers and committed to the main CVS tree once it's ready to go live. This can be cumbersome but there's always a price to pay when integrating code from third parties that use different tooling.

The Atheros HAL was reverse engineered for OpenBSD. adrian@freebsd used to work at Atheros and managed to get them to open source their HAL. The code is now in FreeBSD where the HAL was a blob for years. AFAIK no hardware docs are available for people outside the company.

Ralink used to provide documentation on request. They've been acquired by Mediatek since. Mediatek allows OpenBSD to distribute binary firmware images under free terms (for the run(4) driver). Perhaps they'd still provide docs. I haven't asked yet.

Realtek's engineers tend to be kind and helpful, but they don't provide docs on request, citing NDAs, and management has ignored my requests. There are several open source drivers for Linux written by Realtek engineers which can be used as a reference but they are pretty large so studying them takes time.

Broadcom's open source drivers are unreadable to the point of being more or less equivalent to binary blobs. If you want to see why try to make sense of this file in Linux: drivers/netwireless/brcm80211/brcmsmac/phy/phy_n.c