
OpenBSD 5.4 Released - sramov
http://www.openbsd.org/54.html
======
earlz
I found out that [http://openbsd.org](http://openbsd.org) is not the same as
[http://www.openbsd.org](http://www.openbsd.org) (one is much lower bandwidth)
and apparently it's intentional that one doesn't redirect to the other. And
that's not even to mention the website not using a static generator or CSS
(despite
[http://www.openbsdfoundation.org/](http://www.openbsdfoundation.org/)
actually being modern and good looking). From what I understand is the reason
it's not changed is because it'd be too much work because it's duplicated
everywhere, but they won't accept contributions to change it.

I love OpenBSD as a piece of software, but I don't understand it's developers
or community at all.

~~~
tedunangst
openbsd.org is a different machine than www.openbsd.org. Why are you using
openbsd.org? Who gave you a link to it? Tell them to stop.

~~~
VMG
I think I'm getting a little glimpse of the community here

~~~
_pmf_
Yeah, god forbid people having actual tasks to do instead of micromanaging
their online presence like a SF web monkey.

~~~
ciupicri
As if it's very hard to make a redirect to the www domain. It takes only a
couple of minutes.

~~~
cdmckay
Takes a couple of seconds.

------
sramov
Packets already flowing through 5.4 - _release_ on my 'lil ALIX home router.
Workstation on - _current_ , of course.

There is _nothing_ quite like OpenBSD out there. Thank you OpenBSD developers!

~~~
csmuk
Signed up to agree.

Canned 6 Ubuntu machines (servers) and replaced with OpenBSD 5.3 recently. So
much goodness ships with openbsd it's unreal. Bar Theo's sharp tongue (which
is usually spot on), you get pf, opensmtpd (so much cleaner than postfix),
nginx in base, miles better manual pages than Linux, no horrid gnu info, small
and simple base system, absolutely no surprises, no bloated crap like
dbus/upstart, tmux in base and what I can only describe as a warm fuzzy "why
the hell isn't everything like this" feeling.

Also, it's just about the only thing I've found that can work adequately
entirely offline without having to use google to fix obscure problems and
decypher documentation.

I've got a bootable USB stick that contains the base packages, entire FAQ
(main documentation source outside manpages), all normal binary packages I
use, WiFi firmware and its less than 2Gb.

Thanks as well.

~~~
ape4
Yeah, what is the point of gnu info?

~~~
teddyh
From [https://www.gnu.org/prep/standards/html_node/GNU-
Manuals.htm...](https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html)

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...](https://www.gnu.org/software/bison/manual/html_node/Concepts.html))
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...](https://www.gnu.org/software/bison/manual/html_node/Concepts.html))
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...](https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Index-
Entries.html)) in GNU Texinfo, and see _Defining the Entries of an Index_
([https://www.gnu.org/software/texinfo/manual/texinfo/html_nod...](https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Indexing-
Commands.html)) 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.

[...]

~~~
csmuk
Unix manpages are fine. If you've read the GNU awk manual vs BSD awk, you'll
understand what I mean. GNU awk manual is hundreds of pages long and serves
only to confuse the user. Not only that, half of it is listing differences
between GNU awk and other awks which is just mindnumbing. A fine case of cat
-v. And don't get me started on glibc.

The bit that pisses me off is: man awk (see info awk instead). I think they
fixed that but it was a pain in the butt for years. Is it in man or is it in
info?

One tool for the job.

Edit: cite your sources :)

1 - OpenBSD awk (6 pages if I print preview it): [http://www.openbsd.org/cgi-
bin/man.cgi?query=awk&apropos=0&s...](http://www.openbsd.org/cgi-
bin/man.cgi?query=awk&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html)

2 - GNU awk (330 pages if I print preview it):
[https://www.gnu.org/software/gawk/manual/gawk.html](https://www.gnu.org/software/gawk/manual/gawk.html)

~~~
teddyh
Even the document I cited conceded that there are some very good Unix man
pages — BSD Awk may very well be one of many, I have not read it. It follows,
logically, that there could be some very bad Info documentation manuals, and
the GNU Awk manual may very well be one of many; I have not read it.

This does not disprove the point the citation made; namely, that the Unix man
page structure is _unsuitable_ for many things since its structure tends to
make people write manuals badly, and there is no place for the kind of
introductions and tutorials that good manuals should contain. On the contrary,
the man page format lends itself to very strict and terse reference
documentation, which is not what I would call a “manual”, as such.

Someone should perhaps do a study of which of the two formats seem to generate
the better documentation.

> _The bit that pisses me off is: man awk (see info awk instead). I think they
> fixed that but it was a pain in the butt for years. Is it in man or is it in
> info?_

The official GNU system documentation is in Info. Now, the GNU system is meant
to be _compatible_ with Unix, and Unix uses man pages. And since many GNU
tools were (and are) not actually developed to be used in the GNU system as
such, but instead find their major use and development as parts of various
Unix variants, it follows that most of them have Unix have man pages too.
Since writing documentation is work, and writing _duplicated_ documentation is
even more work, the man pages for GNU tools are often overly terse, incomplete
and/or out of date compared to the Info documentation, which is the official
documentation. Some well-known exceptions exist, notably GNU Bash does not
have any Info documentation, but instead has an (enormously long) Unix man
page.

~~~
nodata
> The official GNU system documentation is in Info

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

~~~
teddyh
(You are demonstrably wrong, but I will address your implied point instead of
your hyperbole.)

I think that the hostility to Info comes from exposure to the standalone Info
reader. It is non-intuitive, non-Unix-like, and does, as far as I know, not
even support text attributes, so it looks bad even for a text-based UI. It is
not very newbie friendly (like GNU nano with its _very explicit_ menus to
guide you). Nor is it consistent with other Unix-based text UIs like “vim” or
“less”. Instead it behaves like a brain-damaged Emacs, but without even many
basic text-navigation features from Emacs, so even Emacs users feel lost in
Info.

I feel that if someone made a module for vim or something to read and navigate
Info documentation (and made it the default instead of the barebones
standalone Info reader), _then_ Unix people would warm up to Info
documentation.

Personally, I read Info documentation using the Emacs built-in reader. It is,
unofficially I think, the _canonical_ Info documentation reader, and it is
beautifully integrated with Emacs. I prefer reading most manuals this way (if
they have an Info version).

~~~
clarry
My problem with info is the document structure. The manual for each
application seems to be structured so differently with topics under specific
titles and subtitles, I always get lost and it takes me a while to find the
thing I'm looking for. And it really is frustrating to stumble in the dark
looking for that one command line flag or input format that you've found and
used many times before.

For me the consistent reference-like structure and terse language of man pages
is ideal. The whole document is shorter than a bunch of info pages will be,
and because of the structure, I always know where to expect specific things to
be. Some man pages do not quite fit the traditional model so there is a bit of
compromise, but I still find it easier to scan through such pages and remember
the location of things than I do with info pages.

The difference between (Open)BSD and GNU/Linux world man pages is that the
former group spend plenty of effort on polishing the language & structure to
make the text clean, short and to-the-point, as well as consistent. So exactly
the qualities I prefer man for are taken as far as possible. And because we
love well written man pages, there's a man page for damn well near anything in
the base system; whereas on other systems you're sometimes looking at info
pages, sometimes html documentation installed where-ever or nowhere, READMEs,
comments in config files, howtos and tutorials via Google, or at the source
because nobody bothered write real documentation. If the source isn't at hand
or you don't have the time for it, you try imitate what you see in use
already, and pray..

~~~
teddyh
> _My problem with info is the document structure. The manual for each
> application seems to be structured so differently with topics under specific
> titles and subtitles, I always get lost and it takes me a while to find the
> thing I 'm looking for._

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.

~~~
clarry
The index is the problem. The index for each application and library looks
different. There are headings and subheadings and subheadings.. sometimes
they're descriptive enough to help you find what you need, but in my
experience, they often are not. But in either case you still need to read
through them and interpret them. And reading through tens of headings is a
pain, especially if after reading them you navigate to the seemingly most
relevant page and find it doesn't have the information you need. ("Where the
hell was it?!" is something I've said more than once, trying to battle info
documents.) This is what I mean when I complain about structure; it's not
consistent, it's not predictable. I don't want it to read like book, I want it
to be useful and being consistent in such a manner that I can always find my
answer quick helps there. Good man pages more or less have this consistency.
And because they're terse, it's still quite easy to scan even when the
structure for some reason does not conform to the tradition.

~~~
teddyh
I think you misunderstood me; the Index is not the table of contents or the
list of headings. The index is what you access with the “i” key, and can also
be read directly using the “g” key to go directly to the “Index” node.

I agree, reading headings and navigating that way is mostly a waste of time
when trying to find something specific. Which is why I never do it; I use the
_Index_.

------
jorgecastillo
If you haven't tried OpenBSD yet I invite you to try it, you might like it. A
long time ago I used OpenBSD as my sole desktop for six months and I fell in
love with it. Right now OpenBSD is not a viable solution for my needs, but
depending on your use case it might be for you. I definitely hope that one day
I can use OpenBSD as my main operating system.

My favorite OpenBSD features:

-Awesome documentation (FAQ & Man Pages)

-Small installation media (amd64/install54.iso - 232MB)

-OpenBSD developers eat their own dog food

-Just works philosophy

------
pimeys
I'm a big OS geek, I love to install and test all new operating systems. Does
anybody use OpenBSD as their main development OS? At least there's ports, and
looks like you can compile all the necessary tools (xmonad, vim, firefox, zsh)
from the ports system. But is this the ideal use of OpenBSD? Do I gain
something if changing from Gentoo?

~~~
ams6110
I use OpenBSD as my main desktop and dev machine, with Awesome as the window
manager (it's a tiling window manager).

[http://awesome.naquadah.org/](http://awesome.naquadah.org/)

I use Xombrero (formerly called xxxterm) for browsing, or Chromium from
packages if I'm working with anything on Google.

[https://opensource.conformal.com/wiki/xombrero](https://opensource.conformal.com/wiki/xombrero)

I use Emacs as my editor and email client, and do pretty much everything else
in a terminal.

~~~
pimeys
Are you using any specific font setup? Infinality patches etc? At least
default install leaves the fonts in a pretty bad state.

~~~
sramov
The fonts are looking nice and sharp for me:

[http://s24.postimg.org/n94n4dred/fonts.png](http://s24.postimg.org/n94n4dred/fonts.png)

I fetch freetype via CVS from xenocara tree:

    
    
        cvs co xenocara/lib/freetype
    

Apply the subpixel patch (the Adobe CFF stuff is already default in -
_current_ ):

[http://dpaste.com/hold/1438578/](http://dpaste.com/hold/1438578/)

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

[http://dpaste.com/hold/1438579/](http://dpaste.com/hold/1438579/)

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

~~~
sramov
Forgot to add, after you uncomment the subpixel stuff, just do a `make && sudo
make install && make clean` from the `xenocara/lib/freetype` directory.

Also, repeat the same after each snapshot upgrade, as the X sets will
overwrite it every time, naturally. Don't forget to keep it updated as well,
with `cvs up`.

------
simonw
The vocals on the release song are lovely
[http://www.openbsd.org/songs/song54.mp3](http://www.openbsd.org/songs/song54.mp3)
\-
[http://www.openbsd.org/lyrics.html#54](http://www.openbsd.org/lyrics.html#54)

------
brunoqc
What is the best hardware for a home router? Soekris was very popular in the
past but I'm wondering that maybe there's cool hardware out there.

I also wonder if carpd is usable with a DHCP connection.

~~~
abjr
I'm not sure you'd consider it "cool", but I've been using one of these for
the past 5 months with OpenBSD 5.3 with no issues:

[http://www.newegg.com/Product/Product.aspx?Item=N82E16856205...](http://www.newegg.com/Product/Product.aspx?Item=N82E16856205007)

~~~
wglb
Your use is mainly as a router?

~~~
abjr
Yes. I basically just use it for router/firewall with pf.

~~~
wglb
Thanks. will try one to replace some old hardware.

------
spetsnaz
Great for Firewall or Gateway...simply the best!

------
jtth
This building is energy neutral because all the lights are off and there's no
power.

