From: mleech@bnr.ca (Marcus Leech) Subject: LINUX, Unix, and opportunity for change Date: 17 Dec 92 15:45:05 GMT Unix provides an extremely rich programming environment, but it has traditionally been weak in the areas of system management and administration. With LINUX, comes an opportunity to address many of these issues. We have an opportunity to build a robust, manageable system, with true "Industrial Strength". I've been a Unix system programmer and manager and support person for nearly 14 years. I'd like to review some of the areas that I think need attention, and solicit comments [no flames, please, let's maintain our objectivity]. Parameterization of system modules, including the kernel and critical system processes. It is desirable to have a highly parameterized kernel with as many of the system parameters tunable dynamically as possible. There needs to be a consisent mechanism for specifying and tuning system parameters; anyone who's used SYSGEN on VMS knows what I'm talking about. The ability to dynamically load device drivers [LINUX may already have this--I'm not yet a LINUX system manager]. Along with parameterization, theres a *strong* (IMHO) need for *instrumentation*-- a system manager needs to know what's going on in the system, its peripherals, and its user processes. Too often, writers of device drivers ignore instrumentation, even though it's cheap and highly useful. I'd like to (for example) be able to do the Unix equivalent of the [VMS] SHO DEV/FILES command. Instrumentation should be considered at least as important as functionality and performance. There needs to be a consistent and flexible accounting mechanism. Such a mechanism is crucial to tracking security problems, finding out the gory details of why a cron job failed at 03:00 last Thursday, etc, etc. For those who want to charge for computing services (eeek!), good accounting is vital to business objectives. The current Unix accounting mechanism is not very flexible, lacks certain details, and lacks good tools for dealing with system accounting records. It's also rather more expensive to run than it should be. More of the system should use the syslog() mechanisms, and there should be standards for use of this mechanism. When the system crashes, or a peripheral runs into trouble, I want the details recorded by the system as it's happening. Look at the VMS OPLOG and ERRORLOG facilities for a flavour of what I mean. /etc/dmesg simply doesn't cut it. The notion of allocation of peripheral devices to specific sessions is important when you're running a large timesharing system [with the advent of cheap 486/50MHZ systems, people *will* do this with LINUX and other systems]. When I'm making a load of tapes, I don't want someone else to be able to grab the tape drive between tapes. On a large system, this is vital. Unix totally lacks the notion of "allocation" of objects, which I think is a big gap in functionality. With LINUX, we still have the opportunity to address this issue. A coupla changes to the proc table, and a couple of systems calls, and voila--allocation. So, is anybody *else* interested in this stuff, or am I preaching to an empty church? I'd like to make it clear that I'm as rabid a Unix fanatic as the next guy, but I have the wisdom to see where other OSes have done some things better. If you flame me because you think I'm a VMS weenie, I'll not reply. -- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not ml@ve3mdl.ampr.org Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs
From: dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci) Subject: Re: LINUX, Unix, and opportunity for change Date: 18 Dec 92 17:56:28 GMT In article <1992Dec17.154505.8927@bcars6a8.bnr.ca> mleech@bnr.ca (Marcus Leech) writes: > >Parameterization of system modules, including the kernel and critical > system processes. It is desirable to have a highly parameterized kernel > with as many of the system parameters tunable dynamically as possible. > There needs to be a consisent mechanism for specifying and tuning > system parameters; anyone who's used SYSGEN on VMS knows what I'm > talking about. The ability to dynamically load device drivers [LINUX > may already have this--I'm not yet a LINUX system manager]. > Yes! Most people can't (or won't) compile the kernel, but the ability to configure kernel parameters and device drivers is more common-place. > Along with > parameterization, theres a *strong* (IMHO) need for *instrumentation*-- > a system manager needs to know what's going on in the system, its > peripherals, and its user processes. Too often, writers of device drivers > ignore instrumentation, even though it's cheap and highly useful. I'd like > to (for example) be able to do the Unix equivalent of the [VMS] SHO DEV/FILES > command. Instrumentation should be considered at least as important as > functionality and performance. Sure would be nice! Then again, let me say I am quite grateful for what has already been accomplished. Thank-you Linus!!! -- =========================================================================== phil perucci | "Any opinions expressed are solely my own views and ssb1pzp@digex.com | do not reflect the position of any organization" ===========================================================================
From: mleech@bnr.ca (Marcus Leech) Subject: Re: LINUX, Unix, and opportunity for change Date: Sat, 19 Dec 1992 17:01:43 GMT In article <BzGv65.KKI@nmrdc1.nmrdc.nnmc.navy.mil>, dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci) writes: |> Then again, let me say I am quite grateful for what has already been |> accomplished. Thank-you Linus!!! |> Lest anyone think my post was a shot at Linux and its progenitors--that's *not* what I intended. I see Linux a completely fresh implementation of a Unix-esque system. It strikes me as an opportunity to fix many of the long-standing problems with Un*x, and to address those areas that the commercial Un*x vendors have been either too timid, or too stupid to address. I think that what Linus and the assembled multitudes here have done is a tremendous testament to the vitality of the free sofware "industry". Let's leverage that vitality, and build something truly fresh and exciting. Were it not for the fact that I have a job where everything I create is owned by my employer, I'd be as busy as Linus; contributing, rather than just pontificating. [Though it's certainly not unheard-of around here to be able to release freeware, just rather rare]. -- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not ml@ve3mdl.ampr.org Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs
From: pmacdona@sanjuan (Peter MacDonald) Subject: Re: LINUX, Unix, and opportunity for change Date: Sat, 19 Dec 92 17:33:16 GMT In article <1992Dec17.154505.8927@bcars6a8.bnr.ca> mleech@bnr.ca (Marcus Leech) writes: >Unix provides an extremely rich programming environment, but it has ... >Parameterization of system modules, including the kernel and critical There are two schools of thought on this. Please allow me to... And please don't make me ... The VMS tunable kernel is necessary because Digital is not giving out source. Linux comes with source so you are free to tune the source to your hearts content. If want to avoid recompiles, you can use lilo to pass in parameters. For run time tuning, you can hook into the ioctl calls, to modify kernel parameters. Having the source is far superiour because it is less indirect, and indirection always exacts a price, in terms of simplicity, flexibility and power. >There needs to be a consistent and flexible accounting mechanism. Such a Ditto what someone else said (mkj?). This is overhead few will want. If it isn't to extensive, we might consider adding it to the kernel as a conditional compile. >More of the system should use the syslog() mechanisms, and there should be Syslog (which I have started to add to SLS) is not in the kernel. It is supported or not, by the system utilities login, etc. Note, things like xlock, and xdm and ftpd need source modifications, to participate. >I'd like to make it clear that I'm as rabid a Unix fanatic as the next guy, Glad to hear it. But there are probably more differences than similarities between VMS and Linux (I work supporting products on a 6*6000 VAX cluster). Some of these differences are more than just philosophy. VMS is single sourced, and tightly controlled. Linux is great :-). Peter pmacdona@sanjuan.uvic.ca
From: mleech@bnr.ca (Marcus Leech) Subject: Re: LINUX, Unix, and opportunity for change Date: 20 Dec 92 22:14:58 GMT In article <1992Dec19.173316.7680@sol.UVic.CA> pmacdona@sanjuan (Peter MacDonald) writes: >The VMS tunable kernel is necessary because Digital is not giving out >source. Linux comes with source so you are free to tune the source >to your hearts content. If want to avoid recompiles, you can use >lilo to pass in parameters. For run time tuning, you can hook into >the ioctl calls, to modify kernel parameters. > Only partly true. What if I had to recompile grep(1) every time I wanted to use a different option? Having a dymamically tunable kernel is useful. VMS tends to overdo it, and a certain amount of autoconfiguration at system startup would probably be more useful than the vast majority of many tunable parameters. The VMS mechanisms for this don't just apply to the kernel, however, which is nice. It means you can (for example) tune the parameters of system daemons from a single place. >Having the source is far superiour because it is less indirect, and >indirection always exacts a price, in terms of simplicity, flexibility >and power. > >>There needs to be a consistent and flexible accounting mechanism. Such a > >Ditto what someone else said (mkj?). This is overhead few will want. >If it isn't to extensive, we might consider adding it to the kernel >as a conditional compile. > Put together a 50MHZ 486(586) system, with 16M of memory, a coupla Gs of disk space, a coupla tape drives, and 16 or 32 serial ports. Suddenly, this isn't a "desktop, single-user PC", it's a compact timesharing system suitable for a variety of business and technical uses. Some people need good accounting, either for customer chargebacks, or as part of ongoing system administration. None of the commercial vendors have very good tools for this, maybe Linux can address this. >>More of the system should use the syslog() mechanisms, and there should be > >Syslog (which I have started to add to SLS) is not in the kernel. It >is supported or not, by the system utilities login, etc. Note, things >like xlock, and xdm and ftpd need source modifications, to participate. > I realize that syslog() isn't in the kernel. My point is that there should be a consistent, centralized logging mechanism used by ALL parts of the system that ever need to log anything. In Unix, this has been handled rather poorly in the past, with every program and subsystem choosing to do this in incompatible ways. Syslog() was introduced to alleviate this, and it's a shame that more parts of the system don't use it. Just like more parts of the system (daemons, applications) don't yet use getopt() and perror(). Yes, source code modifications will be necessary, but somebody with a work-term student with time on their hands..... ;-) -- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not ml@ve3mdl.ampr.org Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs