From owner-freebsd-questions@FreeBSD.ORG Wed Mar 7 17:42:54 2012 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 1A2AF106566C for ; Wed, 7 Mar 2012 17:42:54 +0000 (UTC) (envelope-from djackson452@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF8C8FC0C for ; Wed, 7 Mar 2012 17:42:52 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so7333288bkc.13 for ; Wed, 07 Mar 2012 09:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SNVxc2dcl1MIP1IAbMc52W1OfBVFxWpLkF66BQXzkXY=; b=k0hAQBSiZoLOFgPNBlfbaL03hJ9Neq3wajSf4LDcPnS8weK3/02dutvIKxwQiJEKtG LlU8oPM5TUmxLmWKDeZu+02H1j4H9ye3NDtSla2uZ+Nis+AtGdANMroKZvNOulN/xmYR wmDUckWnXysFmlVE0ZJvhNo5uTQCH7IohQKEswPjrUvy8jDI9uA9lgBigo3nEhnWK0Qp ByuzSb/QkZnkZuC7VYQH1nEGri0u/JrPxAnIYKFPriyTaO79BaCJwMwla0NMWXJ5ScK8 tpmz5M7jad2vUseB1GxIiQ/KXsDY2ieRWmVqueurQT2x/R7Jf5HTUAF7hf9vZcdyRweh PY3g== MIME-Version: 1.0 Received: by 10.112.84.233 with SMTP id c9mr1064251lbz.1.1331142172114; Wed, 07 Mar 2012 09:42:52 -0800 (PST) Received: by 10.112.45.137 with HTTP; Wed, 7 Mar 2012 09:42:52 -0800 (PST) In-Reply-To: <20120307175852.7de93d6f.freebsd@edvax.de> References: <20120307175852.7de93d6f.freebsd@edvax.de> Date: Wed, 7 Mar 2012 12:42:52 -0500 Message-ID: From: David Jackson To: Polytropon , freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Still having trouble with package upgrades 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: Wed, 07 Mar 2012 17:42:54 -0000 On Wed, Mar 7, 2012 at 11:58 AM, Polytropon wrote: > David, allow me to add a few thoughts: > > On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote: > > As for compile options, the solution is simple, compile in all feature > > options and the most commonly used settings into the binary packages, for > > the standard i386 CPU. > > I think this can develop into a major problem in certain > countries where listening to MP3 is illegal. :-) > > You are talking about the codec. What Ubuntu seems to do is distribute these codecs as a seperate nonfree addon package which are then loaded by applications at run time. You see, options do not necessarily have to be compiled into programs, they can be loaded at libraries and then loaded by programs at run time if they are available. This is also a rare circumstance, and there are workaround as above. > > > If people want customisations then they can build > > the software for themselves. > > That's what they'll do anyway. :-) > > No, usually they do not. Few people except for hard core geeks want to mess around with compile options. most will use runtime configuration through a GUI which is faster. > Especially on systems low on resources, compiling from > source is _the_ way to squeeze every required (!) bit > of performance out of code. Even if compiling may require > some time (due to optimization flags), the result can > be really usable. > > > > > When a new kernel is released, there is no reason to reinstall all of the > > packages on the system at the same time. Since the kernel and userland > > packages have different development cycles, there is no reason why there > > has to be synchronization of the upgrading. > > It sometimes is neccessary, for example if kernel interfaces > have changed. There is some means of compatibility provided by > the compat_ ports. But if you start upgrading things, libraries > can break, and the system may become unstable (in terms of not > being able of running certain programs anymore). Just see how > "kernel and world are out of sync" errors can even cause the > system to stop booting. Degrading the inner workings of the OS > to "just another package" can cause trouble. "Simple updates" > as they are often performed on Linux systems can render the > whole installation totally unusable because "something minor" > went wrong. :-) > > > A well designed system will provide backwards compatability through various strategies and this does not necessarily need to affect internal software design as the backwards compatability can also be provided by compatability layers and glue code. Programs communicate with the kernel via interrupts, pushing arguments for the system call onto the stack. The format of this closely matches the source code API. The API is used with the system calling convention. These are mostly mature and do not need to change much. Considering it also a bad practice to create an incompatable system API, there is little reason to change the system call interface. The system call interface has little impact on internal kernel except where adding a new feature can require additional kernel code. Most system calls are mature and do not need to change much. If a system call is needed to provide new functionality, a new system call can be added, which can if needed duplicate the functionality of an older system call. There is also ELF and binary code linking and calling conventions. This can also be maintained to be backwards compatability, if necessary through the use of compatability layers and glue in this process. Another strategy that is unlikely to be needed, since there really is not much reason to make non backwards compatable changes to the current system call set, and is only now used for Linux binary compatability is to mark a binary for a certain system call interface, that system call interface can be backed by glue code to the the main kernel interfaces. Other means of communicating with the kernel which are possible include the /proc interface and as as well UNIX domain sockets. Again if the format of these needs to changed in a non backwards compatable way, a new file or socket can be created at a new location for the new version, the old file or socket location would provide the old interface backed by glue code to the new interface. It is possible to provide backwards compatability through compatability layers and glue code like this, without in anyway impacting the internal design of a kernel or other software system. > > > An OS that requires a user to reinstall > > everything just to upgrade the kernel is not user friendly. > > Why do consider a user being supposed to mess with kernels? > This question can show that I'm already too old: Programs > are for users, kernels are for sysadmins. Sysadmins do stuff > properly, even if they shoot their foot in order to learn > an important lesson. :-) > > Users have to upgrade the kernel, with a well designed OS this is a process that does not require any sort of problems for the user. Since good kernel backwards compatability strategies will assure that the new kernel will drop into place of the old one without causing problems. Kernel upgrading should be done through the main package update tool and the kernel itself distributed as a package, as Ubuntu does it. This is also how Windows Update does it as well. It can be done automatically with automatic updates and the user does not need to worry about it. Not everyone who uses an OS is a system administrator. Do you really think that anyone who owns an Ipad or has a home desktop computer should be required just to apply a kernel upgrade? The good thing is that kernel upgrades do not need a system administrator. A well designed kernel will not be so problematic that this will be required. > As I said before: Updating the kernel _may_ cause many "dependency > programs" (the userland and often the installed 3rd party > applications) to become target of updating in order to keep > their functionality. New kernel interfaces, changes in ABI > or API, new libraries, as well as obsoleted things may be > a valid (!) reason. > > > Dependancy problems will not exist if the kernel development follows sound strategies for backwards compatability, which can include providing a compatability layer with glue code, which means backwards compatability need not necessarily affect the internals of the software system. > > > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... >