They are in different locations. openbsd.org is updated first and in the same (physical) location as the CVS servers, build equipment, etc., and www.openbsd.org and the other mirrors are mirrors with much more bandwidth.

My feeling is still that if high performance is desired, FreeBSD is still preferred. For "normal" workloads though, I think OpenBSD would be a fine choice. I do like how "clean" an OpenBSD system feels.

[1]: http://openbsd.7691.n7.nabble.com/Performance-limits-with-Op...

[2]: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/0066...

Secondarily, I have a VM on BigV which seems to suffer less pauses and oddness than Ubuntu 12.04LTS did.

Works nicely on UltraSparc machines (U30 and U60 tested) as well which is a bonus. I still find them superior to Intel even if they are power hungry and rather old now. Context switch time seems pretty low on Sparcs. Not sure if it uses hardware contexts or not though - haven't looked at the code.

Darwin's the successor to NeXTSTEP, which included a Mach microkernel and some BSD APIs and userland. When they developed OS X, Apple updated much of the userland using more recent FreeBSD versions as a base.

Even more confusingly, Apple has contributed some subsystems to open source that have made their way into FreeBSD (notably the compiler and libc++).

So Darwin's not a fork in the same way that OpenBSD is a fork of NetBSD.

http://s24.postimg.org/n94n4dred/fonts.png

I fetch freetype via CVS from xenocara tree:

    cvs co xenocara/lib/freetype

http://dpaste.com/hold/1438578/

And use the following `~/.config/fontconfig/fonts.conf`:

http://dpaste.com/hold/1438579/

You might also want to delete `/etc/fonts/conf.d/30-lucida-aliases.conf`.

I'd say if you're needing extensive font support, or do any really heavy graphics work, OpenBSD may not work well for you as a desktop. For me, the stock fonts on OpenBSD meet my needs.

It is also pretty good practice for anytime those servers go bad. It helps to be able to put temporary replacements in service from whatever I have lying around. I can save the hot spares for machines that have user data on them (e-mail, file servers).

I.E. The default approach, incremental upgrade, is the only way to ensure your OpenBSD system doesn't fail.

I have had numerous problems on older Dell/HP machines with USB booting anything so it's reasonable. I buy the official media even though I rarely use it.

http://www.openbsd.org/faq/faq4.html#noflopcd

Can this easily be done from any Linux distribution? AFAIK it can not, instead they waste resources creating USB installs and images.

You can netboot Linux. Knoppix [1] offers Terminal Server which configures DHCP, TFTP and NFS so that you can boot Knoppix from the local network.

[1] http://www.knoppix.org/

The preferred document format for the GNU system is the Texinfo formatting language. Every GNU package should (ideally) have documentation in Texinfo both for reference and for learners. Texinfo makes it possible to produce a good quality formatted book, using TeX, and to generate an Info file. It is also possible to generate HTML output from Texinfo source.

[...]

Make sure your manual is clear to a reader who knows nothing about the topic and reads it straight through. This means covering basic topics at the beginning, and advanced topics only later. This also means defining every specialized term when it is first used.

Programmers tend to carry over the structure of the program as the structure for its documentation. But this structure is not necessarily good for explaining how to use the program; it may be irrelevant and confusing for a user.

Instead, the right way to structure documentation is according to the concepts and questions that a user will have in mind when reading it. This principle applies at every level, from the lowest (ordering sentences in a paragraph) to the highest (ordering of chapter topics within the manual). Sometimes this structure of ideas matches the structure of the implementation of the software being documented—but often they are different. An important part of learning to write good documentation is to learn to notice when you have unthinkingly structured the documentation like the implementation, stop yourself, and look for better alternatives.

For example, each program in the GNU system probably ought to be documented in one manual; but this does not mean each program should have its own manual. That would be following the structure of the implementation, rather than the structure that helps the user understand.

Instead, each manual should cover a coherent topic. For example, instead of a manual for diff and a manual for diff3, we have one manual for “comparison of files” which covers both of those programs, as well as cmp. By documenting these programs together, we can make the whole subject clearer.

The manual which discusses a program should certainly document all of the program’s command-line options and all of its commands. It should give examples of their use. But don’t organize the manual as a list of features. Instead, organize it logically, by subtopics. Address the questions that a user will ask when thinking about the job that the program does. Don’t just tell the reader what each feature can do—say what jobs it is good for, and show how to use it for those jobs. Explain what is recommended usage, and what kinds of usage users should avoid.

In general, a GNU manual should serve both as tutorial and reference. It should be set up for convenient access to each topic through Info, and for reading straight through (appendixes aside). A GNU manual should give a good introduction to a beginner reading through from the start, and should also provide all the details that hackers want. The Bison manual (https://www.gnu.org/software/bison/manual/html_node/Concepts...) is a good example of this—please take a look at it to see what we mean.

That is not as hard as it first sounds. Arrange each chapter as a logical breakdown of its topic, but order the sections, and write their text, so that reading the chapter straight through makes sense. Do likewise when structuring the book into chapters, and when structuring a section into paragraphs. The watchword is, at each point, address the most fundamental and important issue raised by the preceding text.

If necessary, add extra chapters at the beginning of the manual which are purely tutorial and cover the basics of the subject. These provide the framework for a beginner to understand the rest of the manual. The Bison manual (https://www.gnu.org/software/bison/manual/html_node/Concepts...) provides a good example of how to do this.

To serve as a reference, a manual should have an Index that lists all the functions, variables, options, and important concepts that are part of the program. One combined Index should do for a short manual, but sometimes for a complex package it is better to use multiple indices. The Texinfo manual includes advice on preparing good index entries, see Making Index Entries(https://www.gnu.org/software/texinfo/manual/texinfo/html_nod...) in GNU Texinfo, and see Defining the Entries of an Index(https://www.gnu.org/software/texinfo/manual/texinfo/html_nod...) in GNU Texinfo.

Don’t use Unix man pages as a model for how to write GNU documentation; most of them are terse, badly structured, and give inadequate explanation of the underlying concepts. (There are, of course, some exceptions.) Also, Unix man pages use a particular format which is different from what we use in GNU manuals.

[...]

It is complete.

There is nobody in the world outside of the GNU foundation who prefers using info pages to man pages.

http://xkcd.com/912/

There are many more people who know how to write web pages or forum posts than who know how to write "info" pages. There are also great tools for searching the web, but poor tools for search info pages. "info" pages can't even have diagrams or pictures. Consequently, information obtained via "info" tend to be stale, incomplete, and generally unhelpful.

The real question is why "man" pages are still useful in the era of the internet. The answer is that sometimes, you want a concise, accurate, quick reference to what is installed on your system. "man" fills this function admirably. "info" fills that function awkwardly and poorly.

Use the index – it’s what it’s there for. In the usual Info readers, it’s the “i” key. This is what I use when, for instance, reading the GNU C Library manual and wanting the documentation for a specific function, struct or macro. If you want the command-line switches for the “foo” command, the node to go to in the manual you find yourself when invoking “info foo” is called “foo invocation”; you go to a specified node using the “g” key. Then you simply use the space key to navigate serially through all the following nodes. There are only three more keys that I use when reading Info documentation.¹

I think it’s mostly a question of habit. Man pages has taught you to read mostly the whole document quickly, while scanning for the information you need. These are habits unsuitable to both to reading a book of printed documentation or Info documentation. If you have a specific idea of what you want to find, you use the index.

1) The “l” key – “l” for “last” – corresponds to a web browser’s back button, the “u” key goes “up” in the document tree, and the “t” key goes to the top of the current document. These five keys are all the keys I use for Info navigation, except for normal searching with C-s, but that’s Emacs. This should not be difficult, but it is. I suspect, as I wrote previously, that it’s not Unix-y enough.