OpenBSD Passes 300,000 Commits
undeadly.org
undeadly.org
The synchronization likely won't 100% work, with cron script you maybe able to just do that with git.
>It provides a similar function as FreeBSD's jail(8) utility while being significantly more flexible. The package provides jail(1), a drop-in replacement of FreeBSD's jail(8)
Relevant paper: http://www.watson.org/~robert/2007woot/2007usenixwoot-exploi...
Learned something new today thanks :)
It's not quite "set it and forget it" for servers, but pretty close IMHO.
There's an attitude among the developers of making it extremely difficult to run sub-par code on the OS, which makes the overall quality of most ported apps high, quite stable and (unpleasant)surprise-free.
A buddy of mine is an overworked (and underpaid) sysadmin for a small ISP, and commented the other day that the OpenBSD firewall that I built for them 7 years ago (!) is still humming along nicely, they're still using and tuning its rulesets, and it wasn't vulnerable to shellshock.
(This isn't to say that not updating a firewall for 7 years is good practice, obviously. I shouldn't have to say that, but HN.)
Would you recommend the patch by patch process or the full check out code and compile?
1. Install a release.
2. Subscribe to the security list.
3. Patch any issues that turn up and may affect you using the instructions in the patch. Rarely this requires a reboot. Don't patch anything you don't need to.
4. Upgrade release a couple of weeks after it is released (everyone else has found the bugs then ;-)
5. To manage ports, subscribe to the ports mailing list, create packages yourself from ports on another machine and install them and upgrade them yourself if there is an upgrade or security hole posted.
Before you do anything though, test it on another host properly. YMMV with all updates on all platforms.
That's a pretty bold statement. Care to elaborate?
Everything is more reliable. Not one crash yet. When I use Linux, I would have expected several by now.
Everything works perfectly out of the box and has sane and safe defaults.
Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized.
The code is substantially better. Less macrotanium, better naming, more understandable.
There is clearly more attention to (and more expertise about) security. This is, of course, what OpenBSD is (rightfully) known for.
Also true with Linux, of course.
> Everything works perfectly out of the box and has sane and safe defaults.
Same with Linux, at least in the distros I use.
> Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized.
"My way or the highway", in other words. Use the Only OpenBSD Toolkit or get out?
> The code is substantially better. Less macrotanium, better naming, more understandable.
Readability is subjective. Macros aren't inherently bad.
> There is clearly more attention to (and more expertise about) security. This is, of course, what OpenBSD is (rightfully) known for.
At the expense of everything else, it seems, including hardware support.
Summary: Basically, the development process for OpenBSD is the same as stomach acid. To survive this environment is an exercise in code correctness. I.E. It's designed to break things that aren't up to par. The end result is a platform that doesn't sacrifice stability and security (the two often are two sides of the same coin) for the sake of compatibility.
Yes it is bold by the user but I agree entirely.
I spent the best part of a decade running Solaris and Linux machines from 1998-2008. The Solaris kit was easy to keep running once you'd got over the initial configuration hell and was very stable. The Linux stuff however was nasty at best. From CIFS/SMB crashes taking out the VFS layer to drivers packing in to incorrect documentation to random hangups. That is across CentOS and Debian. They are not even remotely stable IMHO. Debian is far better than CentOS was but that still pales in comparison to even, dare I say it, Windows Server 2008.
As a sideline, I'd been using OpenBSD on a couple of test machines because it was interesting and I encountered entirely the opposite of the above. I threw it into production instead of a CentOS 5 box that we were retiring as a postfix/dovecot SMTP/IMAP box. The throughput is about 10-15%[1] less but my word the thing is a million times easier to administer and is absolutely bomb proof. Every configuration option, tool etc is entirely and perfectly documented. It is nothing but bliss. It just keeps ticking. We now have 3 hosts on it. The only missing bit is a decent OpenJDK port but the software guys are starting to use Python for a lot of stuff so that may be moot shortly anyway.
My metric for an operating system's reliability is if it goes wrong, how much crap do I have to deal with? Well I'm confident that if an OpenBSD host went down that I could have it back up, even if the internet connection was out and all I had was an OpenBSD CD. I can't say the same about anything else these days. Last time I lose an md raid on Linux, it took me a day to get it back due to nothing but crappy documentation and bugs even those it was a tested recovery strategy.
[1] The thing is a hefty HP Xeon box so this is background noise compared to the actual load.
It might be good on firewalls though where they don't expose a lot of services to the internet.
Their lifecycle is security oriented and you only get reliable security coverage if you keep something up to date. There's no point in sitting around living off backports and patches forever as all that does is create work.
It's pretty easy to upgrade as well.
With respect to application services, they can evolve independently to the base OS as well.
This one took out our SMB/CIFS implementation in CentOS 6.2 forcing us to grab some windows licenses in the end (which I will add has been damn reliable):
https://bugzilla.redhat.com/show_bug.cgi?id=476442
Still broken in CentOS 6.5 and Centos 7.0. Many people have raised this issue (google it) and it's always "fixed next release".
Patched and built my own kernel in the end but by then it was too late.
No thanks. Had enough of crap like that.
Having said that, switching to OpenBSD is not as simple. It's not just some random web server with 2 sites on it; we're talking many, many servers with a great range of software running on them and so on. Some of this software will not even run on OpenBSD at all and so on. The problems are many. :)
The big linux distros - buggy as they are - are here to stay.
Also, some interesting "statistics" from $dayjob. Our DC workload (dedicated servers) is mostly web stuff; when I joined the company in 2009 there were a reasonable amount of FreeBSD servers around; that number is now 0 (or very close); my opinion is that it went "extinct" because of poor binary updates and package management as well as lack of long term support. CPanel stopping to support it was probably the last nail in the coffin. I'm seeing a similar thing with Debian, Ubuntu LTS took over that customer base.
OpenBSD - from our pov - is facing the same issues. I'd love to see more BSDs deployed, but this will not happen unless the above points are addressed. Add to that the lack of "kickstart"-like functionality, as well.
How much did you pay for CentOS? Perhaps if more people were willing to pay for RedHat and/or Samba, some of the more obscure bugs would more readily get fixed.
In the general case, developers need to put food on their dinner table and put a roof over their heads. Good quality "free" software only goes so far, OpenBSD pulls it off because they limit the scope of their efforts.
So, instead of complaining about CentOS, buy some RedHat licenses. The end result might not be any different but you'll at least have paid for the right to complain.
If you write kernel code, you may like, vkernel, which is full blown kernel that runs on userspace. Speeds up kernel development process.
but consider an unsolvable problem that tempts developers, yet stumps them at the same time. they could all commit a solution thinking it's the right one, yet nobody actually solves a problem.
not saying this about BSD ... obviously, but: high number of commits is not a very good metric besides indicating that people are committing.
But, to be fair, everything is a sign of bloat.