4 ms·

Just to show how good OpenBSD's manuals are, look at those: http://www.openbsd.org/cgi-bin/man.cgi?query=strncpy http://www.openbsd.org/cgi-bin/man.cgi?query=s

Just to show how good OpenBSD's manuals are, look at those: http://www.openbsd.org/cgi-bin/man.cgi?query=strncpy http://www.openbsd.org/cgi-bin/man.cgi?query=strncpy http://www.openbsd.org/cgi-bin/man.cgi?query=malloc http://www.openbsd.org/cgi-bin/man.cgi?query=malloc They don't just explain what strncpy & malloc do. They also explain how to use these functions correctly and securely. With examples. Compare that to glibc's manuals (pretty typical of what you can find under Linux): http://linux.die.net/man/3/malloc http://linux.die.net/man/3/malloc http://linux.die.net/man/3/strncpy http://linux.die.net/man/3/strncpy Clearly OpenBSD folks care.

silentbicycle 17y ago
The OpenBSD community has a reputation (sometimes deserved, sometimes not) for getting irritable when people ask questions that are answered in the documentation. To some extent, it's because the community isn't large enough to answer all the questions that come in, but mostly, it's because the documentation really is that good. Any changes to the system have to be accompanied by a change to the relevant man page, and they are usually as clear as possible. If you want to learn to use Unix (not some specific Linux distro, but Unix in general), you could do a lot worse than just starting with "man afterboot", apropos, and the tutorials in /usr/share/doc. A post in-thread linked to the online man pages, here's the FAQ (http://openbsd.org/faq/index.html http://openbsd.org/faq/index.html). Another good documentation example is the man page for the filesystem layout (http://www.openbsd.org/cgi-bin/man.cgi?query=hier http://www.openbsd.org/cgi-bin/man.cgi?query=hier). For this release, tmux (http://tmux.sourceforge.net/ http://tmux.sourceforge.net/) is in the base system, and there's a new security-audited SMTP daemon (http://www.openbsd.org/cgi-bin/man.cgi?query=smtpd&sektion=8 http://www.openbsd.org/cgi-bin/man.cgi?query=smtpd&sekti...). :)
Erwin 17y ago
Hah, check out that malloc page for OpenBSD for how you configure malloc globally (to e.g. enable debugging): you create a /etc/malloc.conf which is a symbolic link to a non-existant file the name of which determines options, e.g. "G<" to enable extra malloc debugging and half the cache size!
- rbanffy 17y ago
  This debugging method seems like an ugly hack. Why not use a plain text file that could be read when the program (or the computer) starts with options written in human-readable form? Assuming it is a short file, it would require only one block read (the block pointed to by the directory entry). The broken symlink method may be faster (one less disk read, a lot less parsing overhead) but is much less human-friendly. And the added speed would only be meaningful if the file got checked more often than at program start.
  - amalcon 17y ago
    It would also never hurt most users at all, as the standard configuration (no file) is the same for both.
  - silentbicycle 17y ago
    If you're having to debug something carefully with malloc, the readability of a list of single-letter flags is probably not a big deal. (I'm not sure why the symlink filename is used, though.) The code is in /usr/src/lib/libc/stdlib/malloc.c . I didn't know OpenBSD's malloc was under the "beer-ware license". :)
  - cperciva 17y ago
    Why not use a plain text file that could be read when the program (or the computer) starts with options written in human-readable form? Reading a symlink is one system call. Reading a file is three or more system calls. There is an overhead cost for each system call -- and if you're going to be doing something for almost every process, you might as well be as efficient as possible.
    - rbanffy 17y ago
      Except that if you were using a text file, you use different flags or turn it on or off on a per executable file basis checked on process start and would not have to re-parse the symlink every time you malloc something.
pfedor 17y ago
Actually, the primary documentation for glibc is available in the info format (preferred by the gnu project.) You can check it out by typing "info libc" on Linux (or by googling [info libc]), and I really encourage you to do it, because you may learn new and interesting things (I know I had when I first discovered it.) Most man pages on Linux have a note saying that the documentation in man format is obsolete and the info format should be used instead. This is not to say anything bad about OpenBSD which I have no doubt is a great system, just that the comparison is somewhat unfair.

silentbicycle 17y ago

The OpenBSD community has a reputation (sometimes deserved, sometimes not) for getting irritable when people ask questions that are answered in the documentation. To some extent, it's because the community isn't large enough to answer all the questions that come in, but mostly, it's because the documentation really is that good. Any changes to the system have to be accompanied by a change to the relevant man page, and they are usually as clear as possible. If you want to learn to use Unix (not some specific Linux distro, but Unix in general), you could do a lot worse than just starting with "man afterboot", apropos, and the tutorials in /usr/share/doc. A post in-thread linked to the online man pages, here's the FAQ (http://openbsd.org/faq/index.html http://openbsd.org/faq/index.html). Another good documentation example is the man page for the filesystem layout (http://www.openbsd.org/cgi-bin/man.cgi?query=hier http://www.openbsd.org/cgi-bin/man.cgi?query=hier). For this release, tmux (http://tmux.sourceforge.net/ http://tmux.sourceforge.net/) is in the base system, and there's a new security-audited SMTP daemon (http://www.openbsd.org/cgi-bin/man.cgi?query=smtpd&sektion=8 http://www.openbsd.org/cgi-bin/man.cgi?query=smtpd&sekti...). :)

Erwin 17y ago

Hah, check out that malloc page for OpenBSD for how you configure malloc globally (to e.g. enable debugging): you create a /etc/malloc.conf which is a symbolic link to a non-existant file the name of which determines options, e.g. "G<" to enable extra malloc debugging and half the cache size!

rbanffy 17y ago
This debugging method seems like an ugly hack. Why not use a plain text file that could be read when the program (or the computer) starts with options written in human-readable form? Assuming it is a short file, it would require only one block read (the block pointed to by the directory entry). The broken symlink method may be faster (one less disk read, a lot less parsing overhead) but is much less human-friendly. And the added speed would only be meaningful if the file got checked more often than at program start.
- amalcon 17y ago
  It would also never hurt most users at all, as the standard configuration (no file) is the same for both.
- silentbicycle 17y ago
  If you're having to debug something carefully with malloc, the readability of a list of single-letter flags is probably not a big deal. (I'm not sure why the symlink filename is used, though.) The code is in /usr/src/lib/libc/stdlib/malloc.c . I didn't know OpenBSD's malloc was under the "beer-ware license". :)
- cperciva 17y ago
  Why not use a plain text file that could be read when the program (or the computer) starts with options written in human-readable form? Reading a symlink is one system call. Reading a file is three or more system calls. There is an overhead cost for each system call -- and if you're going to be doing something for almost every process, you might as well be as efficient as possible.
  - rbanffy 17y ago
    Except that if you were using a text file, you use different flags or turn it on or off on a per executable file basis checked on process start and would not have to re-parse the symlink every time you malloc something.

pfedor 17y ago

Actually, the primary documentation for glibc is available in the info format (preferred by the gnu project.) You can check it out by typing "info libc" on Linux (or by googling [info libc]), and I really encourage you to do it, because you may learn new and interesting things (I know I had when I first discovered it.) Most man pages on Linux have a note saying that the documentation in man format is obsolete and the info format should be used instead. This is not to say anything bad about OpenBSD which I have no doubt is a great system, just that the comparison is somewhat unfair.