nodak.edu>@adm.BRL.MIL (05/30/89)
I can't really claim the know-how to back my opinions up, but there they are anyway : Concepts: Message passing kernal, virtual memory, threads Kernal Contains: Message Handler Scheduler Swapper FileSystem and device/network drivers are user mode processes locked into real memory to prevent swapping. This way you need only 1 filesystem on a network (the server) while network workstations need only a network driver & small kernal loaded. The filesystem could be bypassed, and the device drivers accessed directly, but it provides a nice, clean, virtual interface. Enforce device access through this interface, and you have a high level of security for a slight penalty in network activity (ex. a consol message to a workstation would go to server and back to workstation). More filesystem ideas: Add another permission 'l' - link permission: permision to add or delete a hard link to the file. Ie, you'd need link permission to delete a file or move it across directories. Extend symbolic links to be able to include more than one 'real' file. This would add all the functionality of VMS logicals to sym links. Things would obviously have to be fleshed out a lot more than this, but it's a good start. Furthermore, SVID and/or Berkley compatability could be provided by special device drivers that would trap system calls. Patrick Spinler BITNET: pspinler%mkvax1@msus1 115 Parkway Apt 102 Mankato State University Mankato, Mn 56001 388-3085
Rex_E._Robards.DlosLV@xerox.com (06/01/89)
Three things that should not be in an efficient OS: 1) virtual memory 2) symbolic links 3) long file names (BSD directories)
dsill@relay.nswc.navy.mil (06/01/89)
>From: Rex_E._Robards.DlosLV@xerox.com > >Three things that should not be in an efficient OS: > 1) virtual memory > 2) symbolic links > 3) long file names (BSD directories) There's a tradeoff between efficiency and functionality. Personally, I'm not willing to give up all of the above listed items for even a 50% increase in efficiency, which I don't think could be achieved even if we could agree on a measure of efficiency. You're welcome to hack them out of your copy of GNU, though. -Dave (dsill@relay.nswc.navy.mil)
decot@hpisod2.HP.COM (Dave Decot) (06/02/89)
Three things that should not be in an unusable OS: > 1) virtual memory > 2) symbolic links > 3) long file names (BSD directories) Dave Decot
deraadt@enme3.ucalgary.ca (Theo Deraadt) (06/03/89)
In article <14020064@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >Three things that should not be in an unusable OS: > >> 1) virtual memory >> 2) symbolic links >> 3) long file names (BSD directories) Exactly. If anyone thinks that an GNU OS would not have virtual memory and BSD filenames, they have not played with GNU emacs lately. <tdr. Theo de Raadt CPSC student Calgary, Alberta, Canada (403) 289-5894
cherry.STCWR@xerox.com (06/04/89)
> Three things that should not be in an efficient OS: > 1) virtual memory > 2) symbolic links > 3) long file names (BSD directories) I disagree here. An OS should be compatible with estensions and facilities offered by other vendors/releases. Since many other systems offer these things, it would be nice to have them. Long names are a pain when used on systems which don't support them. this makes using Makefiles and other parts of PD software almost 'not worth the time' to port to these short-name systems. VM and Symbolic links are nice features. I'd say put them in. Let the user determine whether to use them or not. the fact that they are there doesn't hurt an OS. But, let the user, not the author, be the deciding factor. B.C. & Zot PUP/GV : Cherry.STCWR XNS : Cherry:STC WR:Xerox | cherry%anb02.CTS:COM:Xerox ARPA | cherry@anb02.CTS.COM : cherry.STCWR@Xerox.COM UUCP : arisia!cherry | {rocksanne | gryphon | wright}!anb02!cherry TPC : (714) 474-2273 _ /| XPC : 8 * 825-2273 \`o_O' MS : LARH 5007 =( )= Aachk! Phft! U work = : home = |
ugkamins@sunybcs.uucp (Dr. Chandra) (06/05/89)
Rex_E._Robards.DlosLV@xerox.com wrote: =>Three things that should not be in an efficient OS: => 1) virtual memory => 2) symbolic links => 3) long file names (BSD directories) VM: nice, but certainly not efficient. Point well taken. symlinks: somewhat stupid in the first place, to me. There are already normal links. About the only advantage I can see is that when copying files, links duplicate files whereas symlinks can be "detected" and remade on the destination device/directory. Not sure how they impact on EFFICIENCY though. long names: depends what you consider efficient. Trying to remember and mixing up cryptically shortened up and munged filenames cuts productivity and in that respect causes inefficiency. --- We can only contemplate the facts as we are able to perceive them. Do we get what we deserve, or deserve what we get? "Answer my question, tell me no lies. Is this the real real world, or a fool's paradise?" -- Eric Woolfson & Alan Parsons (Lately, I'm beginning to believe the truth is the second case.)
friedl@vsi.COM (Stephen J. Friedl) (06/05/89)
GNU oughta have a file-creation limit (call it "ulimit" maybe?)
and default it _real_low_. Also make it impossible to change the
default.
Steve :-)
--
Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442
3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl
You can't have everything: where you would put it?tim@crackle.amd.com (Tim Olson) (06/05/89)
In article <6275@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (Dr. Chandra) writes: | Rex_E._Robards.DlosLV@xerox.com wrote: | =>Three things that should not be in an efficient OS: | => 1) virtual memory | => 2) symbolic links | => 3) long file names (BSD directories) | | VM: nice, but certainly not efficient. Point well taken. Efficient in what sense? VM makes more efficient use of "relatively scarce" main memory -- processes only need to keep their working sets in memory instead of their entire image. This potentially allows more processes to run than would normally fit in main memory. | symlinks: somewhat stupid in the first place, to me. There are | already normal links. About the only advantage I can see is that | when copying files, links duplicate files whereas symlinks can be | "detected" and remade on the destination device/directory. Not sure | how they impact on EFFICIENCY though. Try linking to a file on another file system without symlinks! -- Tim Olson Advanced Micro Devices (tim@amd.com)
rec@dg.dg.com (Robert Cousins) (06/05/89)
IMHO, the features of such an operating system should be (in approximately this priority): 0. Semantic compatibility with Unix 1. Portability 1.5 Multiprocessor support 2. Functionality 3. Extensability 4. Innovative While I am sure that many people will disagree with the above priority list, relatively few will disagree with the contents (save to add some important ones I can't think of right now). The real issues will be choosing the reference hardware and establishing some form of ABI/BCS for the hardware. It is important to note that there is a tremendous amount of room left for inovation while maintaining compatibility with Unix. One of the common complaints is that there is no user level facility for asynchronous I/O, yet there is an easy way to provide a form of it -- remove the buffer from the user's address space and cause a page fault on the next reference to the page(s). The faulted program is then suspended until the completion of the I/O request (which may be immediate if the I/O request has completed). This allows the user task to return from the I/O call immediately yet have the Unix semantics remain the same. Other examples of potential innovation include an improved interface between X windows and the operating system, improved file systems (which take advantage of implicit parallelism in file operations), better networking support (it seems that EVERYONE (except for one or two) runs the BSD networking code with only minor hacking), making the kernel REENTRANT would also help. Lastly, creating a new algorithm to replace linear searches might just help a lot. Just my $.02 worth. Robert Cousins Dept. Mgr, Workstation Dev't. Data General Corp. Speaking for myself alone.
guy@auspex.auspex.com (Guy Harris) (06/06/89)
>symlinks: somewhat stupid in the first place, to me. There are > already normal links. Which don't work between file systems; if you're going to nuke symlinks because you think normal links are enough, you'd better make normal links work between file systems (yes, even if the file systems aren't on the same machine).
roy@phri.UUCP (Roy Smith) (06/06/89)
In article <19851@adm.BRL.MIL> cherry.STCWR@xerox.com writes: > I'd say put [VM & symlinks] in. Let the user determine whether to use > them or not. The fact that they are there doesn't hurt an OS. It is thinking like this that led us from the 40k kernels I used to run back in the v6 days to the 500+k kernels we see today. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (06/08/89)
? From: Guy Harris <guy@auspex.auspex.com> ? >symlinks: somewhat stupid in the first place, to me. There are ? > already normal links. ? Which don't work between file systems; if you're going to nuke symlinks ? because you think normal links are enough, you'd better make normal ? links work between file systems (yes, even if the file systems aren't on ? the same machine). Don't forget links to directorys. And there are times when symlinks to plain files are useful as well. Root Boy Jim is what I am Are you what you are or what?
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (06/08/89)
? From: Roy Smith <roy@phri.uucp>
? In article <19851@adm.BRL.MIL> cherry.STCWR@xerox.com writes:
? > I'd say put [VM & symlinks] in. Let the user determine whether to use
? > them or not. The fact that they are there doesn't hurt an OS.
? It is thinking like this that led us from the 40k kernels I used to
? run back in the v6 days to the 500+k kernels we see today.
Perhaps a bit of arithmetic is in order. A V6 machine had 256k or perhaps
512k of core. Call it a ratio of 1:10. Todays machines have typically
4 or 8M. Again, call it 1:10. It takes more to do more.
? Roy Smith, Public Health Research Institute
? 455 First Avenue, New York, NY 10016
? {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
? "The connector is the network"
Root Boy Jim is what I am
Are you what you are or what?peter@ficc.uu.net (Peter da Silva) (06/08/89)
In article <19918@adm.BRL.MIL>, rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes about bigger kernels today... > It takes more to do more. But is it really doing that much more? What's the 5.2.3 kernel doing that the V7 kernel didn't do? VM. Streams. RFS support (basically modifying namei() to support the network). termio instead of sgtty. ? What have I missed? And how much does it really take? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/09/89)
In article <4455@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >But is it really doing that much more? Ay, there's the rub. >What's the 5.2.3 kernel doing that the V7 kernel didn't do? > VM. Adds a modest amount of code, for the SVR3 "region" approach. > Streams. May actually save code, slightly. (Replaces clists.) > RFS support (basically modifying namei() to support the network). Having any network protocol stuff in the kernel takes up space. > termio instead of sgtty. Adds a modest amount of code. >What have I missed? And how much does it really take? SVR3 also has three additional types of IPC, not counting FIFOs (which take up a modest amount of additional code). It has record locking, and in general an fcntl mechanism. It has larger buffers and more caching, for performance reasons. It has a bunch of administrative, logging, tracing, etc. features that we probably agree it could do without. Generally, there doesn't seem to be very good reason for the kernel being as large as it currently is.
peter@ficc.uu.net (Peter da Silva) (06/10/89)
In article <10389@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <4455@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >What's the 5.2.3 kernel doing that the V7 kernel didn't do? > Generally, there doesn't seem to be very good reason for the kernel > being as large as it currently is. OK. How about the BSD kernel? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
pcg@aber-cs.UUCP (Piercarlo Grandi) (06/10/89)
In article <4455@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: In article <19918@adm.BRL.MIL>, rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes about bigger kernels today... > It takes more to do more. But is it really doing that much more? Rhetoric question! V7 was (like Classic C) a remarkable balance of economy and power. Power has increased a bit, economy has worsened a lot. What's the 5.2.3 kernel doing that the V7 kernel didn't do? VM. Streams. RFS support (basically modifying namei() to support the network). termio instead of sgtty. ? What have I missed? And how much does it really take? On my SysV 3.2 I have potentially FIVE different pseudo terminal implementations (xt???, sxt???, pty??, pts???, vt??), FOUR different IPC mechanism (FIFO, shm+sem, streams, msg), FOUR different filsystem types (S51K, S52K, Xenix, RFS), and so on, and so on, and so on, and so on, and so on, and so on, .... (BSDs are occasionally even worse, and thank goodness that BSD is still only a very partial implementation of Bill Joy's & C. grandiose and hacky plans... :-<). Not only each of them takes space if configured in (which for many is the default), they also take space for the hooks, as each version does much the same but in slightly different or totally incompatible ways, that require different hooks. Why this proliferation of (mostly pointless and misdesigned) variants? Easy answer: because not many self styled Unix gurus are like the original designers, have their depth and breadth of knowledge of other systems and languages[**see note**], and (just like certain standard committees) are not as gifted for simplicity and don't know what points of diminishing returns are. The idea that since we can afford more memory we can also afford sloppier programming is as always ludicrous -- we want the extra memory for more interesting applications, not to "afford" not much improved but badly designed ones. [**note**] to understand Unix/C and their evolution one must see them against a cultural background that includes CTSS, Multics, Tenex, GCOS, PDP/1, BCPL, Algol68, PL/360, etc..., things with which the original designers were directly or indirectly familiar and influenced by. It is terribly sad that the very diffusion of Unix/C (which was not meant as research but as a convenient tool, and was essentially a very clever retrenchment from more advanced designs under the pressure of limited hw resources) in Universities has meant that many CS grads and postgrads have not been exposed to anything else, except maybe cursorily. I am afraid that the phenomenon of the shallow (uncultured, historyless) Unix hacker is here to stay. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
richard@aiai.ed.ac.uk (Richard Tobin) (06/11/89)
>>symlinks: somewhat stupid in the first place, to me. There are >> already normal links. > >Which don't work between file systems; if you're going to nuke symlinks >because you think normal links are enough, you'd better make normal >links work between file systems (yes, even if the file systems aren't on >the same machine). And anyway, it's not universally agreed that symbolic links are just a substitute for "real" links. Sometimes the semantics of symbolic links are the ones you want. For example, it's nice to be able to make a link to a file and know that it will always point to the current version of that file, even if the file is updated by renaming and creation of a new one. Symbolic links also have the nice property that you can see what they point to, e.g. emacs -> gnuemacs-18.52 (of course, they also have the property that you can't see whether a file is pointed at, which may be bad). Back to the original question of what we'd like in GNU, one thing I hope it will have is the ability to write user programs that provide functionality equivalent to devices (one way to do this is to have something like a fifo that passes through ioctls as well as data). I assume this will come for free, since it seems to be a current view that as much functionality as possible should be moved out of the kernel. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
fischer@iesd.dk (Lars P. Fischer) (06/12/89)
Rex_E._Robards.DlosLV@xerox.com wrote: >Three things that should not be in an efficient OS: > 1) virtual memory > 2) symbolic links > 3) long file names (BSD directories) CP/M, guys, CP/M. -- Copyright 1989 Lars Fischer; you can redistribute only if your recipients can. Lars Fischer, fischer@iesd.dk, {...}!mcvax!iesd!fischer Life is hard, and then you die. - The Immaterial
peter@ficc.uu.net (Peter da Silva) (06/12/89)
[Piercarlo Grandi waxes eloquent about people whose views are tightly channeled into the UNIX mould] UNIX introduced a wonderfully clean and simple program interface that has been widely (and often poorly) imitated. Unfortunately, too many fans of this interface confuse it with the common implementations. They're like the Zen students who, when the master points at the moon, continue to stare at his finger. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.