From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:36:12 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFABB16A41F; Fri, 6 Jan 2006 10:36:12 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39A3343D45; Fri, 6 Jan 2006 10:36:12 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06AZQpA079593; Fri, 6 Jan 2006 02:35:58 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AYfTE056690; Fri, 6 Jan 2006 02:34:41 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06AYesb056687; Fri, 6 Jan 2006 02:34:40 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:34:40 -0800 From: Jo Rhett To: "Patrick M. Hausen" Message-ID: <20060106103440.GB54324@svcolo.com> Mail-Followup-To: "Patrick M. Hausen" , Daniel O'Connor , freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor References: <20060105093220.GJ1358@svcolo.com> <200601050947.k059lctk024288@hugo10.ka.punkt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601050947.k059lctk024288@hugo10.ka.punkt.de> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:36:13 -0000 On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote: > > > > 1. modified kernels are foobar > > > > ..yet are practically mandatory on production systems > > > Look around. Every major commercial OS does it just fine. > > While I agree with much of your reasoning, I know exactly zero > people running a modified kernel of any version of Windows, > Mac OS X or Solaris, to name just three commercial OS's. You're tickling a different subject here. All three of these operating systems have loadable kernel modules that work. I mean, they dynamically load the modules they need, and you can disable kernel modules in configuration files. FreeBSD has loadable kernel modules, but they don't autoload (you have to modify rc files) and you can't trim down the kernel to minimize unused memory without recompiling. To give you a specific example: if we could remove NFS and the 3ware driver from the kernel in a configuration file, we could probably run GENERIC. (we do *a lot* of other modifications, but NFS is the main memory hog we have to remove on small footprint systems, and the 3ware driver we have to update independently, which requires that it be a loadable module and not compiled in) So yeah, this is a different problem. However I wasn't going to tackle this issue in this thread because the -core team appears to be very aware of this issue and it seems to improve a bit in every release. > And third party drivers (which one could count as "kernel modifications") > did fail and will fail sometimes in weird ways even for minor > version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, > Mac OS X updates, reboot, *boom*, because some hardware suppliers > driver didn't adhere to the OS manufacturer's standards or because > the latter silently changed something undocumented. I don't know what you're trying to say here. I don't disagree, I'm just not sure what you mean. It almost sounds like you're trying to make my own point about having the ability to backout patches, which we don't have today. > While I would appreciate a packaged core system or at least a > better definition of "core system" at all, I strongly believe > that binary updating a custom kernel is impossible. If the kernel is consistent across the enterprise (but not, say GENERIC) then binary updates would be trivial. > With "better definition of core system" I mean, if you have a > long lived production system that you might have upgraded > from 4.x to 5.x to 6.0, you will have a lot of cruft lying > on your filesystem that once was part of the "core" and now > isn't. And there is no simple and automated way to find out > what to delete ... That's another good point for having file revisions. We don't have that particular problem, but I can easily imagine how having versioning of the core OS would be useful to help isolate these orphaned files. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation