<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Openbsd on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/openbsd/</link><description>Recent content in Openbsd on Karpoke - Just Another Blog</description><generator>Hugo -- 0.167.0</generator><language>es</language><lastBuildDate>Tue, 06 Jan 2015 19:14:00 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/openbsd/index.xml" rel="self" type="application/rss+xml"/><item><title>Code rot &amp; OpenBSD</title><link>http://karpoke.ignaciocano.com/2015/01/06/code-rot-openbsd/</link><pubDate>Tue, 06 Jan 2015 19:14:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2015/01/06/code-rot-openbsd/</guid><description>&lt;blockquote&gt;
&lt;p&gt;The background is set, you know why I took interest now it’s time to
tell what solidified the decision. Each change made to the OpenBSD
codebase undergoes a code review before it’s committed to the tree. If
you managed to get that far in this article you perfectly know why I
deem that of upmost importance. No matter how many features your
software has, if your documentation is sub-par then your software is
most likely useless. The quality of OpenBSD documentation is on a
level I didn’t expect even after reading about it in so many places.
Not only will you get information on how something works, what’s
possible and how to use it. It will also tell you the best practices
for using the tool and warn you about the common pitfalls.&lt;/p&gt;
&lt;/blockquote&gt;</description></item></channel></rss>