> Damit, I don't want to move to OpenBSD.
Why not? OpenBSD's awesome.
Why not? OpenBSD's awesome.
We would consider OpenBSD if it ran on AWS and stably supported ZFS. (We use FreeBSD with PF and ZFS.)
"NIH syndrome" resulted in signify rather than using normal, proven tools like GPG which Debian-base distros use for package management.
It probably could if Amazon wanted to support it. It does already run on Xen (which is what AWS is built on, IIRC).
> "NIH syndrome" resulted in signify rather than using normal, proven tools like GPG
Whoa there, pardner! Let's not be so quick to label every attempt at improving the selection of software in a given category as "NIH syndrome", eh? By that logic, "NIH syndrome" resulted in GnuPG rather than using normal, proven tools like the original PGP :)
GnuPG is great. Don't get me wrong. I use it all the time, even on OpenBSD. GnuPG is also a big program. It has a lot of features, and tends to be very complex. In the context of package signing, most of those features - like encryption, webs of trust, all that jazz - are way overkill; the OpenBSD folks just needed a tool that can apply a digital signature and verify that signature, and signify does that job pretty darn well.
There's also the fact that GnuPG is GPL-licensed, and OpenBSD has a pretty strict policy against including copyleft software. The implications of copyleft might not be important to you or me or the dog next door, but they're very important for the OpenBSD folks.
Re: package signing: yes, this was a strange oversight, and I'm glad they sign their packages now.
> Then there is limited choice of packages
It's not that limited, at least on i386 and AMD64 (other platforms are a bit more limited). Are there particular packages that are missing that you'd prefer to be available?
> and I don't trust randomers maintaining them.
So compile them yourself, with or without ports. OpenBSD ships with GCC, binutils, etc. Besides, I'm pretty sure this is the same situation as with Gentoo, Arch, etc. (and know for a fact that it's the same situation as Slackware's SlackBuilds.org).
> In practice OpenBSD is good only for servers where you are willing to put some effort in maintaining them
I run multiple OpenBSD servers. I can personally attest that the effort required to maintain them is minimal.
The only situation where OpenBSD maintenance is less than dead simple is when it comes to upgrading a machine where you don't have console access (such as a server in a remote datacenter), since now you have to do the installer's job yourself. When you do have console access, however, OpenBSD's installer makes it dead-simple to upgrade. Plus, it does so safely; no more total breakages like you'd get in, say, Ubuntu.
I will say, however, that it would be very nice to be able to track the stable branch without having to pretty much build OpenBSD from source. I think there are some folks that maintain stable-following ISOs, but this is really something that could and should be supported as a first-party feature.
> but it isn't prepackaged solution like Ubuntu is.
I'm pretty sure Ubuntu uses AppArmor - not grsecurity - so I'm not really sure how that's relevant in this particular discussion. Unless, of course, you happen to install grsecurity on Ubuntu, at which point I highly doubt OpenBSD not being an Ubuntu-like "prepackaged solution" is really as much of a problem as you make it out to be :)
Regardless, OpenBSD has as of late been progressing toward such a prepackaged solution. Boot the CD-ROM, mash the Enter key a few times (interrupted by entering some usernames and passwords), and you have a complete server operating system ready-to-go; a webserver or mailserver or fileserver or DNS server or timeserver or what have you is just an edit of /etc/rc.conf.local away. Maybe not a prepackaged desktop solution, there are plenty of other operating systems for that.
With that said, I'm not sure if the OpenBSD folks want to be comparable to Ubuntu. Canonical's demonstrated a willingness to compromise security and privacy for the sake of convenience (see: shopping lens), that's (hopefully) not something de Raadt and friends would want to emulate.
> companies like Verisign aren't likely to burn their CA business for anyone
Not voluntarily. You're inherently trusting some random company to be up to snuff on their security.
Because the CD-ROMs can't be intercepted and replaced, right?
That said, it's arguably easier to intercept and replace a CD-ROM traveling on the Internet than to intercept and replace a CD-ROM traveling in a padded envelope between the UK and wherever you're having it shipped to (though various entities - like U.S. customs - could do so trivially, other entities would have to go through the extra trouble of bribing customs - not impossible, but it's a barrier to entry for quite a few potential attackers). Such an interception also requires good timing, lest you be sitting around somewhere for a few days waiting for the package to arrive at the particular point in the shipping route you're waiting at.
Plus, if I remember right, the physical OpenBSD media is done using a proper CD press. While plenty of people could conceivably access such a press, that's yet another step an attacker would need to take to create a convincing forgery.
Really, though, this just highlights why software distribution is such a difficult thing to pull of securely. The ideal solution would be to drive to Calgary and pay Theo de Raadt to burn you a CD-ROM, but I'm not sure how receptive he is to houseguests :)
octave, mono, etc. The whole reason openports.se exists. It's more an outcome of how small openbsd team is so it's not intrinsically their fault, but nonetheless is something that prevents wider adoption.
> So compile them yourself, with or without ports.
And track upstream for security issues and possibly apply patches to make it work on OpenBSD and whatnot which can easily turn into 30 minute dance each day just to maintain the system. It's fine on a servers where you are paid to administer it, but it's not fine on workstation dekstops.
> the actual "blessed method" involving getting install media is actually to order a CD-ROM set
What glandium said + it's rather anachronistic to expect operating systems to arrive by mail in the age of computers.
> so I'm not really sure how that's relevant in this particular discussion.
Ubuntu has its own (numerous) flaws, but it requires less work to maintain. It was more a remark that if grsecurity becomes unavailable on servers then even if you don't run it on desktop we should start thinking about moving to other platforms out of the principle that if the system can't be hardened then it shouldn't be used.
Both of these are available as OpenBSD packages (as evidenced by running "pkg_info octave" or "pkg_info mono", assuming you have a $PKG_PATH set). No openports.se required! :)
Why would you have to migrate to OpenBSD? Is the test series unstable?
Does your laptop have an Nvidia GPU, by chance? In my experience, those do tend to have very bad performance on OpenBSD. Intel and AMD/ATI GPUs should work better.
Also, it's worth mentioning that OpenBSD's kernel has a whole slew of debugging and error checking features compiled in by default; compiling a custom kernel without such features can be done, but the docs don't really recommend it, since it becomes excruciatingly difficult to troubleshoot any problems with it.
You are free to be surprised all you wish: I went back to linux because I was sick of dealing with the system locking up for 5-10 seconds every time I opened, closed, or switched to a new browser tab. Couple that with 1-2 fewer hours' worth of battery life and I found myself very quickly asking what the point of "code correctness" was if the system just doesn't work.
A thoroughly frustrating experience from top to bottom.