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.
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.
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!
That's a feature of phkmalloc (written by Poul-Henning Kamp) that was brought forward into jemalloc (used by FreeBSD and Firefox/Windows, among others) and OpenBSD's malloc (written by Otto Moerbeek et al, borrowing from phkmalloc)
As cperciva already noted below, readlink() is one syscall, whereas reading and parsing a configuration file is many syscalls and much more code. This is malloc we're talking about here, not general purpose user-configurable software.
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.
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.
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.
Then why parsing a human-readable file that could, conceivably, activate a much richer debugging option-set is such a huge overhead as to make the symlink way a better option? Is the setting system-wide or process-wide?
Sorry, but I just can't see why it would be a better option.
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". :)
My play machine runs OpenBSD. I can't say enough good things about it. If you want a (very) secure machine which runs on a slew of different platforms, has an awesome package tree, and a solid developer base of pragmatic and opinionated unix nerds... look no further.
OpenBSD is a fine operating system. In the words of Neal Stephenson: "Accept one of our free tanks! It is invulnerable, and can drive across rocks and swamps at ninety miles an hour while getting a hundred miles to the gallon!"
And just like a tank it has no ESP, ABS etc. OpenBSD forces you to do to many things by hand, instead of automating them as much as possible (just like some Linux distros).
Buy the CD, install it on an old machine and play with it over a weekend. OpenBSD has some unique and fantastic features.. everything from PF (its firewall) to spamd (Spam trapping daemon).
It's also nice to use a finely crafted piece of software that doesn't feel like it has been bolted together haphazardly (like your typical Linux distro).
I wouldn't take it personally. Ubuntu made a specific effort to improve the Linux end-user experience, and they've pretty much succeeded. In the process, their rapid rise to popularity has pushed a bunch of the other distributions into making their systems more homogenized, so Linux has really gotten a lot better for the end-user in the last decade.
That said, OpenBSD is probably the most organized project out of all open source projects close to the same size and scope. They release like clockwork, they do not (or try not to) rush new features out just so they can make the next release, and there really is an uncompromising drive for perfection.
I would love to contribute code to the project, but I have to be honest: though I'm by no means a slouch programmer, those guys seriously outclass me, and I'd be completely out-of-my-league.
Having perused bits of Linux source from time to time, I don't feel that's so much the case outside of OpenBSD.
I don't use OpenBSD - but I plan to some day, and I really like their attitude. Specifically, it is very refreshing to see a piece of software where "Quality is the #1 goal, it takes a back seat to NOTHING else."
I use OpenBSD at home for my router and my desktop. I don't plan to go back to Linux anytime soon. OpenBSD is robust, well documented, and simple.
On the other hand it lacks many fancy features. For example it filesystem is somewhat dated compared to ZFS or BFS. But that's the price to pay to get a stable, secure, and well polished operating-system.
Quite true, and if your serious about security, you'll be sure to follow any packages you're using. The benefit of OpenBSD is that it ships "Secure by Default", unlike a ton of other distro's:
"To ensure that novice users of OpenBSD do not need to become security experts overnight (a viewpoint which other vendors seem to have), we ship the operating system in a Secure by Default mode. All non-essential services are disabled. As the user/administrator becomes more familiar with the system, he will discover that he has to enable daemons and other parts of the system. During the process of learning how to enable a new service, the novice is more likely to learn of security considerations.
This is in stark contrast to the increasing number of systems that ship with NFS, mountd, web servers, and various other services enabled by default, creating instantaneous security problems for their users within minutes after their first install."
Yeah, i got a new server recently that comes with centos 5.3. When i ssh'd into the box i saw about 15 services running. I was like wtf why does a server need gpm and avahi ??
Most linuxes are pretty good these days about security, there was a time when it seemed like every redhat version came out of the box with a remotely exploitable hole.
But Ubuntu is locked down by default now. And their security responsiveness seems pretty good.
Security from external threats is what most people tend to look at, but OpenBSD takes security of local users just as seriously. Personally I would feel very uneasy about giving other users accounts on most *nix machines, but I wouldn't worry much about making an account on my OpenBSD box.
Yeah. There were some bad days with default linux installs circa 1998 or so (Red Hat 6.0 was a disaster, IIRC), but everyone learned their lesson and in fact linux distros have been extraordinarily proactive about security since. Witness Red Hat with SELinux, FORTIFY_SOURCE, ExecShield, etc...
One of the ironies is that the "only two remote holes in the default install" bit, while impressive compared to, say, Microsoft, is still two more than Red Hat and Ubuntu have shipped over the same period. (Disclosure: that's from memory. I'd have to look up dates on remote exploits to be sure.)
I guess I was counting since the first hole in 2002. Have there been any in common linux distros since then? OpenBSD got caught once.
But even so: Ubuntu has had zero remote holes in the default install in 5 years. I'm getting hung up on a divide by zero bug somewhere, but I think that works out better if you want to be pedantic about this stuff, no? :)
Seriously: it's a dumb marketing slogan, and it means next to nothing. In point of fact over the last 6-7 years OpenBSD doesn't have a particularly distinguished security record according to their own metric. It's better than Microsoft.
2002 and 2007, according to Wikipedia. I'm skeptical about OpenBSD being more secure overall, in the real world (who has time to apply patches manually?!) But, to be fair, I'm pretty sure Debian and Ubuntu had a big OpenSSL-related fiasco just recently.
There have been lots of security bugs. But no "remote holes in the default install", which is OpenBSD's marketing slogan. That's the point that I was making. It's a dumb metric.
I don't want to be killed for asking this (I probably will get buried in seconds), but it's a legitimate question: isn't this precisely the reason why GPL is such a nice license for new projects?
If, say, vendor A, gave US$ 1 million to the OpenBSD project, vendor B could pick the improvements and incorporate in their own proprietary products for no cost, creating a competitive advantage unless the improvements are so narrow they only apply to A's products. If, however, vendor A donated the same amount to a GPL-licensed project, vendor B could not take unilateral benefit from the money invested and would have to either use the improvements from within another GPL-like product or not at all, effectively negating any competitive advantage it could acquire from A's investment.
I think the AT&T legal imbroglio had little to do to the comparative success of the GNU/Linux system.
I've been procrastinating on my first OpenBSD install, and this pushed me over the edge. I just bought the CD set, and I'll have a go at it this weekend (or maybe next weekend).
The spartan text-based install is also remarkably fast. Once you've done the installation a few times, it's possible to get the whole system up and running in five minutes.
> It doesn't have even half of anaconda's features and it installs only a few packages.
That's often a good thing. For headless installs, a Python and GTK-based install doesn't cut it.
"pkg_add pkgname" fetches a package and its dependencies once you choose a mirror, anyway, and using text files rather than menus to configure the system means you can keep your configuration in VC, configure a typical system by just applying patches, etc.
Anaconda has a text mode install, so GTK+ is not always used. But I do agree, that it can't be used on resource constrained systems.
> using text files rather than menus to configure the system means you can keep your configuration in VC, configure a typical system
What configuration? We were talking about installers and anaconda can use kickstart files to automate the installation. And of course they can be kept in a VCS.
Last time I exchanged messages with him he certainly looked like 13.
The other day we were talking about the need for social skills in large projects mostly because of CK's message exchange on LKML about BFS. Theo is a very clever guy and does some truly outstanding work, but I would not like to work with him on anything important. I love what I do and I have no need to get burned.
He might have been. He was definitely - if it was him - a teenager. Also, according to the newspaper article that cost him the $ from the US Army, his age was such that he would have been 15 in 1981.
The thing I remember the most was he had long spider-like fingers and could touch type.
I was at a company called Rainbow Software in Calgary.
http://www.openbsd.org/cgi-bin/man.cgi?query=strncpy
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/strncpy
Clearly OpenBSD folks care.