From owner-freebsd-chat Fri Aug 29 07:51:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA07929 for chat-outgoing; Fri, 29 Aug 1997 07:51:56 -0700 (PDT) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA07915 for ; Fri, 29 Aug 1997 07:51:43 -0700 (PDT) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.5/8.8.5) with SMTP id JAA13593; Fri, 29 Aug 1997 09:51:32 -0500 (EST) Date: Fri, 29 Aug 1997 09:51:32 -0500 (EST) From: John Fieber To: Peter Korsten cc: "freebsd-chat@FreeBSD.ORG" Subject: Re: Rumors of the death of Unix have been greatly exaggerated... In-Reply-To: <19970829011410.35329@grendel.IAEhv.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 29 Aug 1997, Peter Korsten wrote: > So, Pedro, get out of your ivory tower and check your facts before > you start making statements from other people's experience. There's > a world out there that's using these products. You may not like it, > but you can't get around it either. Devil's advocate here, how about when other people's experience matches your own? The part of the article that struck home with me was about (mis)management of system files: In the most recent case, an update to the bank order-entry software I use, which does nothing other than display forms and write files, modified thirty-seven files in my C:\WINNT directory tree (without asking for confirmation first), then crashed when attempting to import the database from the previous version with a numeric error code from ODBC. Customer support for problems like this in these enlightened times seems to have converged onto the All Purpose Answer: "Reformat your hard drive, then re-install Windows and all your applications". It isn't necessairly Microsoft's fault that this is the norm rather than the exception, but they do set a precedent for it with how their own applications install. In the windows world there has historically been no separation of application and system filespaces and it doesn't seem to be changing for the better very fast. Without that separation the instability describe in the article is inevitable. The reason is exactly the why user processes are not allowed to muck around with the kernel's memory. The other thing that irks me--and it seems to be a more general PCism than a Microsoft-ism--is that installation instructions of even the most trivial software so often include the last step "Reboot your computer". I'm sorry, but for a workstation that is also a server, that is just isn't acceptable. (Granted, there are some justified cases, such as installing new hardware....) -john