For my pi I want something that I don't have to think about. A colleague pwned my rpi because I hadn't updated it in ages. OpenBSD seems like a better choice...
you are correct. we suck at marketing. which is OK, because the focus of the project is to produce free and quality code. any time we spend in marketing is time we don't spend in the tree.
OpenBSD is a project, not a company. If a company decides to build an OpenBSD AMI and support it, it's the company choice alone. The project has no such goals. This is of course not limited to a company, an individual or a group can do so too.
Should also add that they are a very different type of events than the ones outlined in this post. Competition is replaced by collaboration. Prizes by internal reward. Junk food by beer drinking.
Development is done in the upstream OpenBSD codebase. A github clone
of the official repositories is kept at:
https://github.com/libressl-portable
We update this repository from the OpenBSD respositories
semi-frequently, so changes may not show up in GitHub immediately.
The GitHub repository should be used for informational purposes
only.
Again, XP works for many. That doesn't mean there aren't vanishingly few reasons to use it anymore. For CVS, there's the whole non-atomic changes thing, the whole no renaming files thing, no binary file support, no amending commits, no bisect (a feature which I believe sells the software even if everything else sucked), it's harder to collaborate with other users..
Holding onto objectively inferior tools due to a lack of desire to migrate because "it works for me!" is a huge plague on technology.
Perhaps "workflow" was the wrong word. What I am talking about is fundamental to how the project manages sources.
And again, they likely also have tools built around CVS. From my understanding of OpenBSD's build system, it would ALSO require significant effort to divorce it from CVS and marry it to git.
Similarly, Arch Linux switching from SVN to git for the packages repositories is very unlikely to happen. They've discussed it a number of times, but besides all the tooling that has been written around the SVN setup, it isn't well-suited to their use case. That isn't to say that switching to git wouldn't have benefits, or that SVN is perfect, but: It would take substantial development and testing effort to make it happen, as well as ALL contributors having to change how they work (not "learn git" (all of the other repositories for Arch are git anyway), but "re-learn all the Arch-specific tools that were built around SVN, but are now built around git").
> Holding onto objectively inferior tools due to a lack of
> desire to migrate because "it works for me!" is a huge
> plague on technology.
That's a broken argument.
Sure, it is in the case where an organization is hanging onto SVN because none of the developers want to take the effort to switch, and that is a drag on development. But, at the same time, if it is what the developers actually chose; it's not a drag. (The "users refusing to upgrade" is also a drag on technology because of support costs; that is irrelevant here, but is a cause of much of the "must upgrade" feelings among developers)
But the opposite is also true, switching to the latest thing without actually evaluating why is also a HUGE plague on technology. Git in most aspects is a far better tool than CVS. But, there are still things that CVS and SVN are better at (managing subprojects is the biggest one). These are things that I know in Arch mostly outweigh git's benefits, and I presume the same is true of OpenBSD.
You can't really compare Windows XP and CVS. It's disingenuous.
CVS isn't deprecated. You can't say that it's fundamentally obsolete, either. It's just really primitive, compared to modern DVCS like Git and Mercurial.
But if the primitive functionality fulfills their use case, why should they switch?
"Unlike Git, you can check out only a subset of the repository."
Maybe useful, you can do that in SVN, also checkouts in GIT are very fast, the point may be moot.
"So I find CVS (and sometimes even RCS) convenient when the repository is a collection of largely unrelated files, and I'm more interested in tracking changes on individual files"
Ok, I guess it makes sense in this strict case (for example, a collection of config files). Apart from that, if you're wondering with version of file A works with which version of file B you lost.
"At least once, I've had to manually reconstruct a saved CVS file that had become corrupted. I'm not sure how I could have done that with SVN or Git."
They wouldn't have corrupted the file in the first place more likely... And yes there are ways to recover it.
Valid points; I never claimed that CVS is better than Git in general. I still use it for some things mostly out of habit and the fact that it's not really worth the effort of migrating (again, this is mostly for collections of files that don't depend on each other).
As for the (rare) corrupted files, I don't know what caused that. They were single-bit errors that I could correct by manually editing the *,v files. I know of no reason to assume that such errors are more or less likely with Git vs. CVS.
Isn't it? I thought SVN was designed to be a similar but better system? Also cvs(the gpl one, not opencvs) seems to not have had any commits for several years.
I think there is a much more important feature in git for OpenBSD: cryptographic hashes of all commits that depend on the parent commit (=> cryptographically hashed history). Combine that with commit signing and detecting tampering gets easy. There are reported cases where this helped the Linux kernel project detect tampering.
Or have they implemented something like this on top of CVS?
OpenBSD combines two seldom used techniques. First, not having millions of lines of code written by random untrusted people. This allows them to use the second technique, which is to actually read their code.
Well, that is not good enough. How can you proof that already read (audited) code wasn't tampered afterwards by a hacker? If you don't use cryptographic hashes you can't.
It's probably because, true or not, not the best argument. Other than the fact Microsoft ended support Windows XP is fine. It does the job. It's not the latest and greatest, but right to the end it was better than acceptable or tolerable, it was downright decent.
A hardware refresh at work gave me a 7 box, but I've still got my old XP box in a corner somehwere, heavily firewalled ofc now that support has ended, I remote desktop into it 5-10 times a month now for the few straglers I haven't migrated off, and its fine.
Yeah legacy does have support costs, but as I said, you're not building openbsd from source nor would you be if they were on a trendy vcs. That's why they mirror libressl on github, this is a case where they know outsiders might care. And one vcs or another you're going to the mailing list to submit a patch to them, so until you're in it, don't really matter.
I'm all for migrating to git, but at least one aspect of the OpenBSD workflow would take some serious thought to migrate: CVS supports having one giant repository containing everything (at least, as well as it supports anything else), even including project source code, whereas git really wants smaller per-project repositories that share common history with the corresponding upstreams. In light of that, migrating to git would require some non-trivial workflow changes, making it understandable that it hasn't happened in a hurry.
It depends how you work and how stable your product is. I think they are patch heavy i.e the CVS tree is used to apply patches to and that is that. CVS has some advantages then as you can pin individual file versions on a tag rather than having to fuck around merging things. Individual files might be ethernet drivers, scheduler etc because TBH the BSD codebase is a hell of a lot better decoupled and modular than most things out there.
License is one of the reasons. OpenBSD uses the BSD license, and has a strong preference for it when it comes to the base system, base tools, etc. There's no chance they'll move something so critical to GPL-licensed software.
$ uname
OpenBSD
$ cvs -v
Concurrent Versions System (CVS) 1.11.1p1 (client/server)
Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn,
Jeff Polk, and other authors
CVS may be copied only under the terms of the GNU General Public License,
a copy of which can be found with the CVS distribution kit.
Specify the --help option for further information about CVS
Unfortunately CVS isn't the only GPL-licensed piece of software in OpenBSD. But slowly, one by one, these things seem to get replaced with free and better alternatives. I can imagine a future in which we're free of GPL tentacles.
You might consider cross-referencing the authors of commits to the LibreSSL project with the authors of comments in this thread. You might be surprised.
If this fork makes OpenSSL developers be more responsive to patch fixes and have them improve their documentation it's a win for OpenSSL and their users at large.
OpenBSD is already reaping the benefits from a better TSL implementation in -current so it's a win for our project as well.
Exactly. When a popular security project has no clear competition, a code "monopoly" may exist and it's much easier to get complacent. By introducing "competition," it tends to keep both projects adversarial and vigilant... which is exactly what a security project needs.
