From owner-freebsd-questions@FreeBSD.ORG Sat Dec 31 20:32:19 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02F8F106566B for ; Sat, 31 Dec 2011 20:32:19 +0000 (UTC) (envelope-from djackson452@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 785518FC08 for ; Sat, 31 Dec 2011 20:32:18 +0000 (UTC) Received: by eaaf13 with SMTP id f13so19004223eaa.13 for ; Sat, 31 Dec 2011 12:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/QozcrkY9Sp4sLSItdPMHlnpA3hpSoMqE9Ka+2/bTCY=; b=BxOu42WvgLVTphEMSU9T3JjeFblFMrJA2bnxON7QzZEMc+l2YZfzYf8AEeJtP91QDw arDezau4PF+UZcq71G/K4SGCq8xzcJHySBbYLtxHJ7GjP7PdT495LvqdOyNIFEOOXkSe yvV7Si7F2J/472IhiI3TPVSKebBUgaamBzaCk= MIME-Version: 1.0 Received: by 10.204.153.216 with SMTP id l24mr10469539bkw.64.1325363537289; Sat, 31 Dec 2011 12:32:17 -0800 (PST) Received: by 10.204.130.27 with HTTP; Sat, 31 Dec 2011 12:32:17 -0800 (PST) In-Reply-To: References: <201112302138.pBULcZfw076474@mail.r-bonomi.com> <4EFF19A7.2060800@ose.nl> Date: Sat, 31 Dec 2011 15:32:17 -0500 Message-ID: From: David Jackson To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: FreeBSD Kernel Internals Documentation X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 20:32:19 -0000 An OS should strive to be a better platform for many people, including techies and non-techies. A good software design philosophy is that good software works out of the box without configuration using reasonable defaults, but, that that the software should be flexible, very configurable, the user should be able to configure everything how they need it, but they should not be required to. This allows the user to configure as much or as little as they want. Everything should be able to be accomplished with both GUI and CLI, and API. The entire system should be well understood, well documented and transparent . Its like a car, its better to have a car that has a spacious engine compartment and is very well documented in service manuals so that a car mechanic can easily fix it. While not every user may want to get under the hood, a spacious, well documented and easy to fix space under the hood makes the mechanics job easier of fixing the car. The car being made more reliable and easier to use as well means that the common driver has fewer breakdowns. Windows is a terrible OS because its like a car with the entire engine area sealed in a compartment that can only be opened with the car manufacturer with a key, so mechanics cannot even repair it. There is no dount that UNIX is a better design system, due to the fact it is open and the underlying systems are well understood, well defined and well known, including due to the Unix philosophy of modularisation of components. I am in full agreement with Unix design philosophies and unix conventions. I definitely oppose any effort to re-invent Unix or break with unix conventionsand philosophies. It has been said that people who try to reinvent Unix will do so poorly. I agree. I am very much in favour of respecting Unix traditions, backwards compatability and conventions. For instance, supporting the X11 Window System i think is something that we should always commit to, it is important for compatability and for the flexibility it provides. I think tis okay to build additions to the system, but in addition, to the existing components, not to overthrow existing parts of the system. Backwards compatability is very important which is why it is important to respect conventions such as POSIX. I think that we can create a GUI front end built on top of the Unix system that helps manage and configure the underlying Unix system for non-techie users. This is layered design that gives us both the techie friendliness and controllability of Unix and a GUI front end over that for non-techies. No one should be required to use a GUI front end and should be able to directly edit configuration files if they want and use the rich CLI that FreeBSD has. This is a philosophy i like of allowing users to exercise as much or as little fine control over the system as they want. An OS can be both techie and non-techie friendly by create GUI layer that is built over the underlying Unix system where more common features are put up front in the GUI, and advanced configuration in advanced screens, and layering the GUI on top of other layers which can be directly accesssed by techie users if they need to do so. This is the layered design where the GUI can serve as a front end layer to the underlying Unix system components. The techie users can directly access these underlying components if needed. GUIs as well can serve and be useful to both techie and non techie users, advanced configuration settings can be placed in advanced screens and so forth. A good GUI does not come from having few features, good, useable software has lots of features and is very flexible. Features should never be withheld because users are viewed to be too stupid. Good GUI design comes from good layout and putting more advanced features deeper in the UI, so they are there if needed. I think that we should be pragmatic about binary drivers and that it better to accept and welcome binary drivers from hardware companies. Open source drivers should of course be developed, then users can use the open source drivers as they become available, but, until then, they can use the binary driver, or use a binary driver for more rare and unusual hardware. I do think that, hardware driver backwards compatability should be provided perhaps through a compatability layer that can be loaded into the kernel as a module, and perhaps could be a porting of the IOKit driver system from Darwin, perhaps even allowing Darwin drivers to be used on FreeBSD. All of this can go into a kernel module so that if all one uses is native FreeBSD drivers made for FreeBSDs normal driver API, they won't need to load this subsystem.