Slashdot Mirror
OpenBSD: Hackers Meet Soldiers
BSDForums writes "OpenBSD has a well-deserved reputation for fanatical security. Why is the U.S. military funding it? What do you get out of it? Cameron Laird and George Peter Staplin investigate and talk to Theo de Raadt, the creator, overseer, and taskmaster of the OpenBSD project!"
Ok, before I get started, let me say that OpenBSD developers and users have no patience for people who aren't willing to read documentation, since they pride themselves on it (even man pages) being extremely well written and kept up to date. If it's not, file a bug, and _IT WILL GET FIXED_ (of course if it's just _your_ problem, then don't file a bug regarding the project, file one in your own bugtracking system as something you need to work on).
That said, the following FAQ explains the installation process far better than anyone writing you email ever will be able to, including a complete install process in grey, which has example responses in bold [for the most part]. If you can't get it from this, then you aren't reading, and it doesn't matter if someone writes you an email message with the same thing (written more poorly no doubt). If you can't read and follow instructions, then OpenBSD is not for you, and honestly - you shouldn't bother.
Most people don't have this problem, but there are always some feeble minded folks who think that life is easier if they're spoonfed on IRC and the like. To such people: you aren't welcome. The answer to this attitude has already been given: don't ask questions that already have explicit, clear answers publically available.
If you have a problem with the instructions (not enough detail supplied, typos, etc.) then please let the OpenBSD developers know about them in order that they may be corrected. If _you_ have a problem, in that you can't understand them, well... maybe it's _JUST YOUR PROBLEM_. It might be something that you need to work on. Of course, there is an opportunity for things to be unclear, and in such cases - again, submit a bug: "such and such statement regarding fdisk is unclear, suggest more detail on partitioning so that xyz is unabiguous"
Now, if you -want- to install OpenBSD, go read:
http://www.openbsd.org/faq/faq4.html
Way offtopic here now, but it was Ken Thompson, not Donald Knuth. Here's the discussion in question: Reflections on Trusting Trust.
Also a summary entry in the Jargon File, for those who don't want to read the paper: http://www.catb.org/~esr/jargon/html/entry/back-do or.html
This is actually a very simple thing to do. Any OS designed for minicomputer-class hardware (e.g. VAX, RISC or 386+ CPUs) will include this magic ability (including NT). Such OSes will only crash if there is a bug in the OS itself, or in code that is treated as part of the OS.
One of the flaws with UNIX and NT, as compared to systems like VMS (with four protection modes) and Multics (with up to sixty-four protection rings), is the existence of only two protection modes: User and Kernel. This means that code which requires elevated privileges must be given the same privileges as the kernel itself, since Kernel mode is the only alternative to User mode.
This problem of only two protection modes is deeper than the OS design, however. Most RISC CPUs provide only two modes (the x86 provides four rings; the VAX provided four modes), so in order for an OS to be portable to such architectures, it must be limited to two modes like UNIX. This is probably why NT, which was designed by the architect of the four-mode VMS system, itself only supports two modes (like UNIX).
Remember that UNIX was considered very buggy and unstable in the 1980s, where as VMS (which is a younger system) was seen as rock solid. This reflects the design advantages of VMS, in being tied to the VAX architecture, with its four protection modes and robust instruction set, but that reliance on the VAX architecture was also a major weakness: unlike UNIX, VMS could not be ported to most RISC architectures, or the 386, and so only runs on VAX and Alpha. Both of these architectures support the four modes it requires, but are now niche CPUs with declining user bases. This limited hardware support was the most important reason for the decline of VMS, where as the portability of UNIX and NT were very important factors in their success.
UNIX, BSD, Linux and Windows 2000/XP show that a system with only two protection modes can eventually become stable, through simplified design and/or extensive testing on supported hardware configurations over time, but there is always the risk that new hardware will introduce new device-driver bugs, which automatically become new kernel bugs, thereby reducing any of the OSes to an unstable disaster again. The broader the hardware support is, the likelier it is this will happen.