Xref: utzoo comp.sys.amiga:74324 alt.religion.computers:2211 Path: utzoo!utgpu!cs.utexas.edu!usc!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga,alt.religion.computers Subject: Re: A3000UX competition Message-ID: <1990Dec13.064424.1276@zorch.SF-Bay.ORG> Date: 13 Dec 90 06:44:24 GMT References: <36488@cup.portal.com> <1990Dec11.164431.819@jarvis.csri.toronto.edu> <16482@cbmvax.commodore.com> Organization: SF-Bay Public-Access Unix Lines: 76 martin@cbmvax.commodore.com (Martin Hunt) writes: >cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes: >> Despite what vendor propaganda would have you believe, the reason so >> many production sites want OS source code is not so that we can make >> custom hacks but so that we can fix bugs. No smart system admin >> counts on timely bugfixes from major vendors like SUN and DEC and >> SGI, not even for important or critical bugs. > Generally, only large companies or universities have system > administrators who are able to fix bugs in the Unix kernel. Does this > mean that small and medium size companies cannot use Unix? Do Sun, DEC > and SGI ship software with critical bugs and fail to fix them? Would > you buy an OS that was so buggy that the sources were included so you > could fix it yourself? No wonder the business world has been avoiding > Unix. Compared to what? In the micro world, MS-DOS has still got bugs in it from the first release. In the mainframe world, the most successful vendor, IBM, releases OSs so buggy it is standard practice for big businesses to "rent" _several_, full time (in some cases, 24 hours, 7 days a week) IBM systems analysts to be on-site to fix problems that would otherwise prevent them from conducting business. Compared to the general run of commercial OSs, Unix is a marvel of robustness and utility. Watch a Unix site bring itself back on line from a cold, dropped power shutdown, unattended, including fixing the corrupt file structures on its way up. Compare that to the one armed paperhanger mood bringing up a mainframe from a similar shutdown. I'm talking from person experience in all these cases. >> A secondary issue is to be able to adapt the system to important >> local requirements, such as a special 'nice' value for processes you >> want to run only when the system is utterly idle, mass creation of >> (student) accounts from canned data, a passwd command that refuses to >> let you use stupid passwords and lets instructors change student >> passwords, a new working SMD disk driver, or a rdump that understands >> using a remote account besides "root", or similar things (all these >> examples are real ones from around the University of Toronto). A >> tertiary issue is the ability to make disparate systems look and feel >> the same (by such methods as modifying SGI's stty to understand a >> number of BSDoid options -- things like this are surprisingly >> important to local users). > If you need OS source code to do this, then you bought the wrong OS. Nonsense. I've visited many vendors _making_ computers who do their own software development for their machines on a VAX under BSD. It isn't an accident that every OS that matters is either adopting Unixisms or being replaced by Unix. Take a look again at the principals in the two competing "standard" Unix efforts; no one of consequence is left out. Except for extremely special purposes, it won't be long before "the world's not Unix" will no longer be a fair putdown. > Perhaps the problem is that Berkeley admitted that BSD was broken and > AT&T refused to admit their Unix was broken? Whichever, distributing > sources is a good thing in an academic environment, but a very bad > idea if you are trying to capture the business market. Perhaps your experiment has been limited to talent-free businesses; the ones I've worked at had programmer staffs in the hundreds; one sold computers, one sold software, one sold ships. The one selling ships had the most programmers. Source code access is just too important to be hindered by the false image of people randomly hacking the kernel; that's not what happens in the real world. In the real world, user found patches go back to the vendor, where they are evaluated, added if sound, and distributed in the next release. No business is _forced_ to hack the source code it has available, or to run anything but a clean, vendor release OS. Every site that _does_ do kernel hacks also knows that the way to isolate problems with newly installed software is to go back to the clean release, and install patches one by one until the one causing the problem is isoleted. That's standard practice, well known, and completely removes the "hacked OS" bugaboo. Kent, the man from xanth.