Date: Fri, 26 Mar 2010 08:45:10 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: perryh@pluto.rain.com Cc: freebsd-hackers@freebsd.org Subject: Re: Another tool for updating /etc -- lua||other script language bikeshed Message-ID: <alpine.BSF.2.00.1003260833580.30574@fledge.watson.org> In-Reply-To: <4bac66f6.4sYPjsI4heo4SpWm%perryh@pluto.rain.com> References: <201003231108.45102.jhb@freebsd.org> <hod31p$qlc$1@dough.gmane.org> <alpine.BSF.2.00.1003250842520.14365@fledge.watson.org> <4bac66f6.4sYPjsI4heo4SpWm%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Mar 2010, perryh@pluto.rain.com wrote: > Robert Watson <rwatson@freebsd.org> wrote: >> ... web browsers [are] basically operating systems at this point ... > > Isn't this a bit of an exaggeration? Not too many browsers have to deal > with process/thread scheduling, or device drivers, or booting, or file > system issues -- they rely on the OS for that (as does any other > application). I think it's more of an anaology than an exageration. The FreeBSD kernel, including device drivers and architectures, is around 3.9 million lines of code. Google's Chromium, including WebKit, is around 4.1 million lines of code. Both provide an extensive runtime environment for applications that run on top of them, security domains, storage services, and management models. I'm not arguing that web browsers are a substitute for our current operating system layer: they clearly build on it. However, in terms of their goals in providing an execution environment, user interface, etc, they fill a very similar niche by being a general-purpose platform for many specific things. And, to get back to the point I was making: if you toast your Chromium update or get configuration management wrong, then your applications (Google Docs, GMail, ...) on ChromeOS won't work any more than if you toasted your /lib or /etc in FreeBSD. For example, if the Chromium configuration files change and it forgets about web proxies, Chromium won't be able to call home to pick up a fix any more than if etcmerge toasts resolv.conf. Making updates easy is, to a large extent, about avoiding the creation of foot-shooting opportunities. Some of it is about tools (binary updates, mergers, rollbac, etc), but most of it is about avoiding scenarios in which a previously valid configuration becomes invalid. And if we look at problems FreeBSD has had with updates in a past, a lot come down to precisely that: for example, renaming serial port device names (several times in as many years). Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1003260833580.30574>