mwm@eris.UUCP (01/01/70)
In article <6365@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: <In article <738@hplabsz.HPL.HP.COM> kempf@hplabsz.HPL.HP.COM (Jim Kempf) writes: <>I, too, would like to see FSF's software on the PC/AT and PC/XT, but <>I think its unreasonable to expect FSF to do it. < <The hard part is the OS kernel, and for that you can use MINIX <(subscribe to comp.os.minix). User-mode utilities should not be <too hard to port to MINIX. Minix is v7 - (things you didn't know about, and don't want even if you did), the GNU kernel should be 4.3BSD + (things) - (security features). So for starters, you can expect the same set of things to break as you do when doing ports across Unix families: doing anything nontrivial with ttys, shared memory, networking, file name lengths, etc. To make things worse, the GNU utilities are mostly being written from scratch assuming they'll have 4BSD and a large machine underneath them. So expect daemons/utilities to want to talk to syslogd. Expect programs that will try to create file names longer than 14 characters. Expect programs that assume that memory is cheap. "Not to hard" being a relative term (i.e. - iron is "not to hard" compared to diamond, but not when compared to mud :-), I can't say that Gwyn was wrong. I just want to dispell any thoughts that this would be an easy project to tackle. Better to run raw Minix, and port the things you want. If you get the editor to work, let me know :-). <mike -- Here's a song about absolutely nothing. Mike Meyer It's not about me, not about anyone else, mwm@berkeley.edu Not about love, not about being young. ucbvax!mwm Not about anything else, either. mwm@ucbjade.BITNET
gamiddleton@orchid.UUCP (01/01/70)
In article <3470@islenet.UUCP> richard@islenet.UUCP (Richard Foulk) writes: > In article <8520@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > A less charitable view of this is that Stallman couldn't write a small > > program to save his life. Unfortunately, this is a common maladay nowadays. > > > > Leave it to someone who's been using small, out-dated equipment for > years now to be so publicly unkind. Henry's attitude may be uncharitable, but his complaints are valid. On a Mac-II, hardly an out-dated piece of equipment, and the kind of machine that emacs should be running on, it took GNU Emacs 60 seconds to start up. VI takes only 3 seconds. I use emacs myself, but only on big machines with fast disks. __ -Guy Middleton, University of Waterloo Institute for Computer Research gamiddleton@math.waterloo.edu, watmath!gamiddleton, gamiddleton@water.bitnet
fdr@apollo.uucp (Franklin Reynolds) (01/01/70)
In article <486@ast.cs.vu.nl> ast@cs.vu.nl () writes: > >640K? Why would he need 640K? MINIX runs quite well on a 512K AT >with one 1.2M floppy disk. Who needs 640K? > >Andy Tanenbaum (ast@cs.vu.nl) I assume you left off the ":)" by accident. If GNU is supposed to be BSD 4.3 compatable it is a significantly more ambitious effort than MINIX. MINIX is a decent, small system for teaching. GNU is supposed to be suitable for research or commercial development. I have been looking for an inexpensive, Unix-based system for my personal use. MINIX isn't powerful enough to be useful to me, even for hobby hacking. Hopefully GNU will be. Franklin Reynolds fdr@apollo.uucp
dhesi@bsu-cs.UUCP (01/01/70)
[lot of heated arguments pro and con Stallman's software plans] One thing that puzzles me about the Gnu versus Minix debate is why anybody should have any complaints at all to begin with. If you want something that runs on small systems, Minix is here now. If you're more ambitious, wait for the Gnu operating system. And if you want portability for your software that's possible too if you basically stick to version 7 system calls and define a few macros for the few things that might vary between systems. Similarly, if you find Gnu Emacs too bulky for your taste, there are alternatives. Both Jove and Microemacs are nice editors and they are free too. It's great to have choices. Stallman is adding to our choices, not detracting from them. So what am I missing? -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
kempf@hplabsz.HPL.HP.COM (Jim Kempf) (08/27/87)
In article <83@splut.UUCP>, jay@splut.UUCP (Jay Maynard) writes: > > I'll support the Free Software Foundation when they give up their processor > bigotry and decide to support the machine architecture that I use (PC/AT). > Until then, why should I waste my money? > I don't think it's a matter of bigotry. FSF has exactly three employees- Stallman, one full time programmer and a secretary. They are looking to hire a part time programmer this fall. With that kind of staff, it's astounding that Stallman gets as much done as he does, and that it is of any quality at all. Additionally, Stallman prefers using machines with larger address spaces because they're easier to program. This is understandable, since it allows him to concentrate his time on things other than trying to reduce the size of things to fit in 640K. I, too, would like to see FSF's software on the PC/AT and PC/XT, but I think its unreasonable to expect FSF to do it. Jim Kempf kempf@hplabs.hp.com Usual Disclaimer
kyle@xanth.UUCP (08/28/87)
> I, too, would like to see FSF's software on the PC/AT and PC/XT, but > I think its unreasonable to expect FSF to do it. > > Jim Kempf kempf@hplabs.hp.com Forthermore, it's unreasonable to expect the FSF to complete the entire GNU Project alone. The GNU system is being developed so ALL of us can use it, so we all should pitch in. Think how much sooner the GNU system would be completed if each one of us were to take one small part of the project and work on it in our spare time. kyle jones <kyle@odu.edu> old dominion university, norfolk, va
tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) (08/28/87)
I have directed followups to comp.os.misc. I'm now a GNU volunteer, and did spent a year being paid to work on GNU (the salary came from a private foundation [not FSF]). I've been a director (aka corporate officer) of the Free Software Foundation since it's beginning. In article <738@hplabsz.HPL.HP.COM> kempf@hplabsz.HPL.HP.COM (Jim Kempf) writes: > FSF has exactly three employees- > Stallman, one full time programmer and a secretary. Lot's of mis-information here. RMS has NOT been and is NOT currently an employee of the Free Software Foundation. He earns his livelihood as a consultant. FSF does NOT employ a secretary. FSF is employing a full time programmer and a part time shipping clerk. > With that kind of staff, it's > astounding that Stallman gets as much done as he does, and that it is > of any quality at all. RMS is quite productive. He has also had help from many hackers and quality programmers, who have volunteered their efforts. > Additionally, Stallman prefers using machines > with larger address spaces because they're easier to program. This > is understandable, since it allows him to concentrate his time on > things other than trying to reduce the size of things to fit in 640K. That's an approximation of RMS' feeling on the matter. I advise interested people to read the GNU Manifesto. It was published in the March 1985 issue of Dr. Dobb's Journal. It and answers to questions about the project GNU can also be obtained from: <gnu@prep.ai.mit.edu> aka <..!ucbvax!prep.ai.mit.edu!gnu> enjoy -len -- Len Tower, Distributed Systems Group, Boston University, 111 Cummington Street, Boston, MA 02215, USA +1 (617) 353-2780 Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739 UUCP: {}!harvard!bu-cs!tower INTERNET: tower@bu-cs.bu.edu
jay@splut.UUCP (08/29/87)
In article <2283@xanth.UUCP>, kyle@xanth.UUCP (Kyle Jones) writes: > > I, too, would like to see FSF's software on the PC/AT and PC/XT, but > > I think its unreasonable to expect FSF to do it. I'm not asking FSF to do it; I am asking that they not take the attitude of "286? Phooey!". If someone out there wants to take the GNU system stuff and make it work on ATs, then why not help them out? > Forthermore, it's unreasonable to expect the FSF to complete the entire > GNU Project alone. The GNU system is being developed so ALL of us can > use it, so we all should pitch in. Think how much sooner the GNU > system would be completed if each one of us were to take one small > part of the project and work on it in our spare time. Kinda hard for me to do, since my only Unix access is on my personal PC/AT. (Quite aside from my lack of experience of Unix-stuff...after all, I don't consider myself to be a Unix guru by any means [see the .signature]). After all, a fully-developed GNU is BOUND to be less buggy than Microport... :-) -- Jay Maynard, K5ZC...>splut!< | uucp: hoptoad!academ!uhnix1!nuchat!splut!jay "Don't ask ME about Unix... | (or sun!housun!nuchat) CI$: 71036,1603 I speak SNA!" | internet: beats me GEnie: JAYMAYNARD The opinions herein are shared by neither of my cats, much less anyone else.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/30/87)
In article <738@hplabsz.HPL.HP.COM> kempf@hplabsz.HPL.HP.COM (Jim Kempf) writes: >I, too, would like to see FSF's software on the PC/AT and PC/XT, but >I think its unreasonable to expect FSF to do it. The hard part is the OS kernel, and for that you can use MINIX (subscribe to comp.os.minix). User-mode utilities should not be too hard to port to MINIX.
peter@sugar.UUCP (08/30/87)
> GNU Project alone. The GNU system is being developed so ALL of us can > use it, so we all should pitch in. Think how much sooner the GNU > system would be completed if each one of us were to take one small > part of the project and work on it in our spare time. The problem is that the GNU project isn't being developed for ALL of us to use it, just the ones with virtual memory. I think they're too optimistic about the power of future machines. I don't think personal computers will have VM for a long time yet. This means that there's no incentive to work for GNU... we won't get anything for it... and even if we wanted to help them out anyway we don't have the VM machines to do the work on. Also, VM isn't always appropriate. You can't do real-time with VM, for example. Maybe we need a LLAMA project: Little League Amateur Mach Analog. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->
henry@utzoo.UUCP (Henry Spencer) (08/30/87)
> ... Additionally, Stallman prefers using machines > with larger address spaces because they're easier to program. This > is understandable, since it allows him to concentrate his time on > things other than trying to reduce the size of things to fit in 640K. A less charitable view of this is that Stallman couldn't write a small program to save his life. Unfortunately, this is a common maladay nowadays. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
tim@amdcad.AMD.COM (Tim Olson) (08/31/87)
In article <596@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: +----- | The problem is that the GNU project isn't being developed for ALL of us to | use it, just the ones with virtual memory. I think they're too optimistic | about the power of future machines. I don't think personal computers will | have VM for a long time yet. +----- Why does GNU require virtual memory? It seems to me that it would work fine on a machine with 4 - 16 MB of physical memory, using an MMU for relocation/protection; not unheard of. Besides, with most of the new 32-bit processors coming out having MMUs on-chip (MC68030, iAPX386, NS32532, Am29000...), and larger and faster SCSI drives, there is no reason why the very next generation of personal computers shouldn't support efficient virtual memory. -- Tim Olson Advanced Micro Devices (tim@amdcad.amd.com)
phil@amdcad.AMD.COM (Phil Ngai) (08/31/87)
In article <596@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >The problem is that the GNU project isn't being developed for ALL of us to >use it, just the ones with virtual memory. I think they're too optimistic >about the power of future machines. I don't think personal computers will >have VM for a long time yet. I think you are wrong about this. Any 386 machine will do just fine for GNU. And because it's upward compatible, the MS-DOS users we love to despise will be a ready market for 386 machines, helping to amortize the cost of development of hardware for us studly Unix users. 6 million PCs == 6 million potential customers for 386 boxes. Thousands of Japanese and Taiwanese are working on them this very second! -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com
adamm@encore.UUCP (Adam S. Moskowitz) (09/01/87)
In article <8520@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) says: >> ... Additionally, Stallman prefers using machines >> with larger address spaces because they're easier to program. This >> is understandable, since it allows him to concentrate his time on >> things other than trying to reduce the size of things to fit in 640K. > > A less charitable view of this is that Stallman couldn't write a small > program to save his life. Unfortunately, this is a common maladay nowadays. It's not only less charitable, it's dumb. Having met Richard and dealt with him technically (although not a lot), I'd bet he *could* write a small program. I know I can. [insert "war story" about growing up on an 8K machine here] The point being this: trying to squeeze complex programs into small spaces is a waste of effort. It often results in programs that either a) have some (often unusable) limits (file name sizes, # of files, &c.), or b) are hard to read/maintain, because too much thought had to go into trying to fit the damn thing into a small space, and not enough effort was left to making the program functional/maintainable. I'm not saying you can't write a program that does everything including wash the dishes, has no limits, is easy to maintain, and fits in 640K (or whatever), but why add the size limit? Why kill yourself to deal with what many people feel is a bad hardware design? -- Adam S. Moskowitz ...!{decvax,ihnp4,linus,necntc,talcott}!encore!adamm "Gonna die with a smile if it kills me!" -- Jon Gailerfut
richard@islenet.UUCP (09/01/87)
In article <8520@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > ... Additionally, Stallman prefers using machines > > with larger address spaces because they're easier to program. This > > is understandable, since it allows him to concentrate his time on > > things other than trying to reduce the size of things to fit in 640K. > > A less charitable view of this is that Stallman couldn't write a small > program to save his life. Unfortunately, this is a common maladay nowadays. > Leave it to someone who's been using small, out-dated equipment for years now to be so publicly unkind. How seemingly intelligent people can find the need to belittle others publicly, without provocation, is a mystery. But to attack someone who writes software and distributes it free of charge, to attack them because they don't cater to your particular obsolete machinery is amazingly selfish and stupid. -- Richard Foulk ...{dual,vortex,ihnp4}!islenet!richard Honolulu, Hawaii
aglew@ccvaxa.UUCP (09/01/87)
>I think they're too optimistic >about the power of future machines. I don't think personal computers will >have VM for a long time yet. I have just bought an AT&T UNIX PC for 2000$. Prices start at 1200$ It has virtual memory, albeit with a distressingly small (only 4M) address space. THIS I consider a personal computer. (No, I'm not a mini-chauvinist. I've owned a Sinclair, a Hyperion IBM PC compatible, and now the 3B1...)
preece%mycroft@gswd-vms.Gould.COM (Scott E. Preece) (09/01/87)
From: Peter da Silva <peter@sugar.uucp> > Also, VM isn't always appropriate. You can't do real-time with VM, for > example. ---------- Twaddle. While RT tasks often need to be locked into physical memory to meet response time limits, having VM on the system may mean that useful things can still be going on in the rest of the system while some specific tasks are locked down. It may also mean that some tasks use much less memory than would be necessary if they had to be completely resident before execution. RT users typically have some performance requirements that are real requirements, but having met those they usually want to get as much more out of their systems as they can. VM helps a lot there. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@Gould.com
allbery@ncoast.UUCP (09/02/87)
[comp.os.misc deleted because ncoast doesn't get it and inews got upset at me for trying to post to it. Maybe someone should copy it there for me, and remove comp.unix.wizards from it at the same time: it really doesn't belong here. ++bsa] As quoted from <596@sugar.UUCP> by peter@sugar.UUCP (Peter da Silva): +--------------- | > GNU Project alone. The GNU system is being developed so ALL of us can | > use it, so we all should pitch in. Think how much sooner the GNU | > system would be completed if each one of us were to take one small | > part of the project and work on it in our spare time. | | The problem is that the GNU project isn't being developed for ALL of us to | use it, just the ones with virtual memory. I think they're too optimistic | about the power of future machines. I don't think personal computers will | have VM for a long time yet. | | This means that there's no incentive to work for GNU... we won't get anything | for it... and even if we wanted to help them out anyway we don't have the VM | machines to do the work on. | | Also, VM isn't always appropriate. You can't do real-time with VM, for example. | | Maybe we need a LLAMA project: Little League Amateur Mach Analog. | -- | -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter | -- U <--- not a copyrighted cartoon :-> ----- News saved at 1 Sep 87 21:41:43 GMT As quoted from <596@sugar.UUCP> by peter@sugar.UUCP (Peter da Silva): +--------------- | The problem is that the GNU project isn't being developed for ALL of us to | use it, just the ones with virtual memory. ... | Maybe we need a LLAMA project: Little League Amateur Mach Analog. +--------------- Some of us are in the process of making MINIX into a useful operating system. It's possible that a rewrite of the MINIX kernel to replace AST's code with something not copyrighted by Prentice-Hall will be done as part of this, resulting in a truly PD UNIX for the smaller computer. (Unfortunately, we're hamstringed by the fact that the compiler and linker are copyrighted by CCA, and they're not even playing ball with the Minix owners (we still aren't allowed to use the 1.2 compiler!), much less the PD folks. A total reimplementation of the compiler system from scratch is indicated....) -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> ** Site "cwruecmp" has changed its name to "mandrill". Please re-address ** *** all mail to ncoast to pass through "mandrill" instead of "cwruecmp". *** Newsgroups: comp.unix.wizards,comp.os.misc Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?) References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <2283@xanth.UUCP> <596@sugar.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.unix.wizards Distribution: Organization: Cleveland Public Access UN*X, Cleveland, Oh As quoted from <596@sugar.UUCP> by peter@sugar.UUCP (Peter da Silva): +--------------- | The problem is that the GNU project isn't being developed for ALL of us to | use it, just the ones with virtual memory. ... | Maybe we need a LLAMA project: Little League Amateur Mach Analog. +--------------- Some of us are in the process of making MINIX into a useful operating system. It's possible that a rewrite of the MINIX kernel to replace AST's code with something not copyrighted by Prentice-Hall will be done as part of this, resulting in a truly PD UNIX for the smaller computer. (Unfortunately, we're hamstringed by the fact that the compiler and linker are copyrighted by CCA, and they're not even playing ball with the Minix owners (we still aren't allowed to use the 1.2 compiler!), much less the PD folks. A total reimplementation of the compiler system from scratch is indicated....) -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> ** Site "cwruecmp" has changed its name to "mandrill". Please re-address ** *** all mail to ncoast to pass through "mandrill" instead of "cwruecmp". ***
ast@cs.vu.nl (Andy Tanenbaum) (09/02/87)
In article <738@hplabsz.HPL.HP.COM> kempf@hplabsz.HPL.HP.COM (Jim Kempf) writes: > Additionally, Stallman prefers using machines >with larger address spaces because they're easier to program. This >is understandable, since it allows him to concentrate his time on >things other than trying to reduce the size of things to fit in 640K. 640K? Why would he need 640K? MINIX runs quite well on a 512K AT with one 1.2M floppy disk. Who needs 640K? Andy Tanenbaum (ast@cs.vu.nl)
jim@cs.strath.ac.uk (Jim Reid) (09/02/87)
In article <1883@encore.UUCP> adamm@encore.UUCP (Adam S. Moskowitz) writes: >.................................... trying to squeeze complex programs into >small spaces is a waste of effort. It often results in programs that either >a) have some (often unusable) limits (file name sizes, # of files, &c.), or >b) are hard to read/maintain, because too much thought had to go into trying >to fit the damn thing into a small space, and not enough effort was left to >making the program functional/maintainable. I'm not saying you can't write >a program that does everything including wash the dishes, has no limits, is >easy to maintain, and fits in 640K (or whatever), but why add the size limit? I agree with the gist of what you say, essentially that programmers need not have to worry too much about the underlying hardware. However, we should not forget that sometimes these "artificial" hardware constraints can be a benefit. Remember that the UNIX kernel in the days of V7 (and before) fitted into 64K because that was as big a program that a PDP could run (notwithstanding sep I/D or fancy overlays or extended addressing). To quote Ritchie and Thompson's original CACM paper: "the size constraint has encouraged not only economy, but also a certain elegance of design". Where would UNIX be today without that minimalism? Another case in point would be the evolution of the UNIX spell command and how a 30,000 word dictionary was squeezed into 64 Kbytes (the PDP limitations again) for an efficient and quick spelling checker. Now we have editors that easily guzzle a megabyte (or more) of memory and take forever to start up. So much for progress. A program's quality or usefulness is not necessarily related to its size. Jim
lawitzke@eecae.UUCP (09/02/87)
> Xref: eecae comp.arch:1452 comp.unix.wizards:3138 comp.os.misc:125 > > Minix is v7 - (things you didn't know about, and don't want even if > you did), the GNU kernel should be 4.3BSD + (things) - (security > features). > The GNU kermel should be 4.3BSD +(things) + (security features) Since GNU will be distributed in a source code form for next to nothing cost, it will be very attractive to small schools or companies that want to run UNIX but their gurus want source code. In anything but an environment where you have just a handful of people working on the system who know what they are doing, you have to have the security features. What security features don't you want? Separate userids and passwords? file protection modes? disk quotas? checking the name of a system uucping in? ....... -- John H. Lawitzke UUCP: ...ihnp4!msudoc!eecae!lawitzke Division of Engineering Research ARPA: lawitzke@eecae.ee.msu.edu (35.8.8.151) Michigan State University Office: (517) 355-3769 E. Lansing, MI, 48824
nather@ut-sally.UUCP (09/02/87)
In article <3470@islenet.UUCP>, richard@islenet.UUCP (Richard Foulk) writes: > > But to attack someone who writes software and distributes it free of > charge, to attack them because they don't cater to your particular > obsolete machinery is amazingly selfish and stupid. > Henry Spencer is anything but selfish and stupid, as you would know if you had spent any time on the net. He's entitled to his opinion. You'll be entitled to call him names when you've contributed as much as he has. -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.AS.UTEXAS.EDU
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/03/87)
[Followups directed to comp.os.misc]
In article <2117@eecae.UUCP> lawitzke@eecae.UUCP (John Lawitzke) writes:
<> Xref: eecae comp.arch:1452 comp.unix.wizards:3138 comp.os.misc:125
<>
<> Minix is v7 - (things you didn't know about, and don't want even if
<> you did), the GNU kernel should be 4.3BSD + (things) - (security
<> features).
<>
<The GNU kermel should be 4.3BSD +(things) + (security features)
Last time I checked with RMS, the line was "I certainly don't want any
hairy security features" in applications. There was also some
indication that the [gu]id manipulation code would be different than
stock 4.3. Knowing RMS's stand on such things, I would be greatly
surprised if "different" amounted "+(security features)."
<In anything but an environment where you have just a handful of people
<working on the system who know what they are doing, you have to
<have the security features.
Ask RMS. I suspect he would disagree. I will agree that there are many
environments where you need security. On the other thand, there are
many outside of the small set you describe that don't really need
security.
<What security features don't you want? Separate userids and passwords?
<file protection modes? disk quotas? checking the name of a system
<uucping in? .......
Did I say I didn't want security features? Doesn't look like it. Now I
did say there were some things in the set {v7 syscalls} - {Minix
syscalls} that I didn't want. For instance, Tannenbaum was applauded
at his talk in the south bay (SF bay) when he mentioned that he didn't
provide ptrace().
<mike
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@berkeley.edu
How many times do you have to fall ucbvax!mwm
Before you end up walking? mwm@ucbjade.BITNET
kyle@xanth.UUCP (Kyle Jones) (09/03/87)
In article <596@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > The problem is that the GNU project isn't being developed for ALL of us to > use it, just the ones with virtual memory. I think they're too optimistic > about the power of future machines. I don't think personal computers will > have VM for a long time yet. Future machines? There are PCs that ALREADY have VM. And the prices just keep coming down. But never mind that... > This means that there's no incentive to work for GNU... we won't get anything > for it... and even if we wanted to help them out anyway we don't have the VM > machines to do the work on. There's a lot more to the GNU project than just the kernel and GNU Emacs. Are you saying that you won't be able to use *any* of the general purpose utilities that will be available under the completed GNU system? I find this hard to believe. Even if you can't use any of the utilities whole, there is still plenty of useful code that can be spliced into applications that *will* run on your system.
molly@killer.UUCP (09/03/87)
In article <3470@islenet.UUCP>, richard@islenet.UUCP (Richard Foulk) writes: > In article <8520@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > > ... Additionally, Stallman prefers using machines > > > with larger address spaces because they're easier to program. This > > > is understandable, since it allows him to concentrate his time on > > > things other than trying to reduce the size of things to fit in 640K. > > > > A less charitable view of this is that Stallman couldn't write a small > > program to save his life. Unfortunately, this is a common maladay nowadays. > > But to attack someone who writes software and distributes it free of > charge, to attack them because they don't cater to your particular > obsolete machinery is amazingly selfish and stupid. I run on a 2MB 68000 and a 8MB 68020 machine, which to me has cheap memory. Now, I have compress 4.0 which uses about 400KB of memory. With 8 users on the 68000, suddenly loading 400K is a real shock, the 68020 just sort of sighs and goes on. Which machine do you think I worry more about keeping happy? A 68000 that is `outdated', or the 68020? The answer is so simple only totally stupid jerks (like the last bozo ;-) can't see it. Take care of the little things, like how much memory you use, and the big things take care of themselves. Any program I write for the 68000 runs better on the '020 without needing to recompile. Just crank up ftp and sending the puppy by way of the ether bunny. Goddess knows what he'd think of my poor 768K box at home ... Molly -- Molly Fredericks UUCP: { any place real }!ihnp4!killer!molly Disclaimer: Neither me, nor my cat, had anything to do with any of this "I love giving my cat a bath, except for all those hairs I get on my tongue" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fnf@mcdsun.UUCP (Fred Fish) (09/03/87)
In article <10495@orchid.waterloo.edu> gamiddleton@orchid.waterloo.edu (Guy Middleton) writes: >Henry's attitude may be uncharitable, but his complaints are valid. On a >Mac-II, hardly an out-dated piece of equipment, and the kind of machine >that emacs should be running on, it took GNU Emacs 60 seconds to start up. >VI takes only 3 seconds. I use emacs myself, but only on big machines Well, on a Sun-3/50 (comparable in hardware to a Mac-II) GNU Emacs takes about 4 seconds. Vi takes only a second or two. I suggest you look for a problem with either your machine or your OS. -Fred -- = Drug tests; just say *NO*! = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = seismo!noao!mcdsun!fnf (602) 438-3614
mitch@stride1.UUCP (Thomas P. Mitchell) (09/04/87)
In article <8520@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ... Additionally, Stallman prefers >> working with larger address spaces because.. > >A less charitable view of this is that Stallman couldn't write a small >program to save his life. Unfortunately, this is a common maladay nowadays. A charitable view of this is that Stallman shouldn't. The large number of recent TeX implementations faster and smaller (code size) than the original take nothing away from the design of D. Knuth. Large to small transitions will be in response to a useful design cleanly defined. Here most of us sit with sh, csh, sed, awk, lex, yac, 'C', assembler etc. yet some of us forget why all these tools were collected into what I think of as Unix. Recall that many 'C' programs were first designed in Shell, sed, awk, etc. Later rewritten in 'C' perhaps linked to libraries optimized in assembler. Those that have survived were useful and also cleanly defined. So .. Go for it RMS. and thanks for GNU Emacs. And thanks to others for all the different architectures which keep us from all being little blue sm*fs. Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.
snoopy@doghouse.gwd.tek.com (Snoopy) (09/04/87)
In article <596@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >The problem is that the GNU project isn't being developed for ALL of us to >use it, just the ones with virtual memory. I think they're too optimistic >about the power of future machines. I don't think personal computers will >have VM for a long time yet. My personal computer has demand-paged virtual memory. I know of quite a few other people who have personal computers with dpvm. IBM-PCs are toys. Memory management is a must for Unix, to keep one process from tromping on the memory of another process. What does Minix do about this? I assume the 386 machines have all the required goodies? Like someone posted that RMS said: by the time GNU is ready, many/most machine will have the power GNU needs. On the other hand, keeping things as small as is *reasonable* is a virtue. I normally run jove rather than GNUmacs because it starts up faster. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
peter@sugar.UUCP (Peter da Silva) (09/05/87)
In article <2348@xanth.UUCP>, kyle@xanth.UUCP (Kyle Jones) writes: > In article <596@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > > The problem is that the GNU project isn't being developed for ALL of us to > > use it, just the ones with virtual memory. I think they're too optimistic > > about the power of future machines. I don't think personal computers will > > have VM for a long time yet. > > Future machines? There are PCs that ALREADY have VM. And the prices > just keep coming down. But never mind that... I should have gone on to say that GNU needs not only VM, but also a large linear address space (there go all the 80286 boxes... even though the 286 can support VM), gobs of memory (1 megabyte for the editor? You'll want 16 megs for a small, personal, system then), and a very fast disk (cheap hard disks aren't fast, and the prices on good ones aren't coming down that much). > > This means that there's no incentive to work for GNU... we won't get anything > > for it... and even if we wanted to help them out anyway we don't have the VM > > machines to do the work on. > > There's a lot more to the GNU project than just the kernel and GNU > Emacs. Are you saying that you won't be able to use *any* of the > general purpose utilities that will be available under the completed > GNU system? I find this hard to believe. Even if you can't use any > of the utilities whole, there is still plenty of useful code that can > be spliced into applications that *will* run on your system. I'm sure there will be some fallout from GNU. I just don't think that my time is as well used supporting that fallout when there's the ARP project on the Amiga, and MINIX on the IBM-PC, and probably equivalent *small* systems on other personal computers, that I can work on and be *assured* of getting a good return from. I don't think something like the FSF should be deciding what hardware the system will run on. Start out with a small, extensible kernel... something on the order of XINU, MINIX, or TUNIS. Make sure it's designed with hooks in place to expand it... use message passing (I know AST claims it's not efficient enough, but it seems to work well on the Amiga). Keep it modular. Then you can add the VM memory manager, or the real-time scheduler. You'll have something you can build on. And it might even come out some time (yes, I also don't believe GNU will ever see the light of day). -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.
peter@sugar.UUCP (Peter da Silva) (09/05/87)
> Minix is v7 - (things you didn't know about, and don't want even if > you did), the GNU kernel should be 4.3BSD + (things) - (security > features). setenv SARCASM "on" You mean like being able to plug a terminal in and run multiuser? setenv SARCASM "off" -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.
ron@topaz.rutgers.edu (Ron Natalie) (09/06/87)
> (Unfortunately, > we're hamstringed by the fact that the compiler and linker are copyrighted > by CCA, and they're not even playing ball with the Minix owners (we still > aren't allowed to use the 1.2 compiler!), much less the PD folks. It is no wonder that you are having problems. CCA has nothing whatsoever to do with the MINIX C Compiler. The MINIX C compiler is generated by the Amsterdam Compiler Kit. It belongs to AST and his Amsterdam friends. Unipress Software has the distribution rights for ACK (which is very, very expensive) and the MINIX C Compiler. They made a special $99 deal for people who wanted the compiler. They don't sell many, they aren't making any money on it. The president of Unipress spent an entire day recompiling the compiler under MINIX to prove that it was doable before it was shipped. Even on a nice hard disk MINIX system it takes FOREVER to compile anything. I suggest that even though MINIX C compiler sources can be had, that you forget them. First, the performance of the compiler is awful. Second, the source code itself is awful since it is machine generated by the Compiler Kit. I'd start over or try porting GNU CC. (If anyone wants to bitch at Unipress directly, the phone number is (201) 985-8000). -Ron
pf@diab.UUCP (Per Fogelstrom) (09/07/87)
In article <677@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk writes: >I agree with the gist of what you say, essentially that programmers >need not have to worry too much about the underlying hardware. However, >we should not forget that sometimes these "artificial" hardware >constraints can be a benefit. Remember that the UNIX kernel in the days >of V7 (and before) fitted into 64K because that was as big a program >that a PDP could run (notwithstanding sep I/D or fancy overlays or >extended addressing). To quote Ritchie and Thompson's original CACM paper: >"the size constraint has encouraged not only economy, but also a certain >elegance of design". Where would UNIX be today without that minimalism? Unix today is not what it was many years ago. Nowdays it has viritual memory , networking and much much more built in. >Now we have editors that easily guzzle a megabyte (or more) of memory >and take forever to start up. So much for progress. A program's quality >or usefulness is not necessarily related to its size. I belive You refere to "emacs" type editors. The main reason for the slow stratup is not the size of the program, rather than it is reading a huge ammount of files, containing macros, key bindings, etc. A small program would not do that faster i belive. And using up a megabyte ? Not if You only use the simplest functions. The reason for being big is the ammount of more or less usefull functions and commands built in. By the way. One of the more important fetures with Unix is the ability to link programs together with pipes. In that way, functions could be put in to "small" programs like sed, cat, sort, etc and called up together in a shell script to form some complex functions.
franka@mmintl.UUCP (Frank Adams) (09/08/87)
In article <1883@encore.UUCP> adamm@encore.UUCP (Adam S. Moskowitz) writes: >Why kill yourself to deal with what many people feel is a bad hardware design? Well, I can tell you why *we* do it; but that particular reason isn't applicable to the Free Software Foundation. On the other hand, one can rephrase the question as: why kill yourself to produce code that lots of people can use right now? -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
jdg@elmgate.UUCP (Jeff Gortatowsky) (09/08/87)
In article <8907@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes: >In article <3470@islenet.UUCP>, richard@islenet.UUCP (Richard Foulk) writes: >> >> But to attack someone who writes software and distributes it free of >> charge, to attack them because they don't cater to your particular >> obsolete machinery is amazingly selfish and stupid. >> > >Henry Spencer is anything but selfish and stupid, as you would know if you >had spent any time on the net. He's entitled to his opinion. You'll be >entitled to call him names when you've contributed as much as he has. > >-- >Ed Nather >Astronomy Dept, U of Texas @ Austin >{allegra,ihnp4}!{noao,ut-sally}!utastro!nather >nather@astro.AS.UTEXAS.EDU Ed, pulllleeeezzzzeee! Henry normally doesn't make silly rash comments like the one he made. It's quite understandable that Rich might feel RMS is going in the right direction and to take exception ((trap 0xffffff I believe, "Nonsense Instruction Trap".)) to Henry's comments. Coming from a man who is normally the voice of reason, I too found Mr Spencer's comments off base and childish. I choose to encourage people like RMS. Hopefully, someday we will ALL own the type of machines RMS is writing for. Which brings me to my next comp.arch question. *WHAT ARE THOSE MACHINES GOING TO BE??*. Barring RISC vs. CISC debates. What is *THE* next great advance in computer technology. Better hardware? Not 64 bits.(?) I meant more in design. What do you guys at MIPS, LISP Machines, Motorola, Intel, NEC, Sun (yes they are now in the CPU game), etc.... see as the most promising area of exploration? Hopefully this is a more appropriate line of discussion..... 8^) Jeff -- Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg Eastman Kodak Company These comments are mine alone and not Eastman Kodak's. How's that for a simple and complete disclaimer?
gew@dnlunx.UUCP (Weijers G.A.H.) (09/08/87)
In article <2117@eecae.UUCP>, lawitzke@eecae.UUCP (John Lawitzke) writes: > > > > Minix is v7 - (things you didn't know about, and don't want even if > > you did), the GNU kernel should be 4.3BSD + (things) - (security > > features). > > > The GNU kermel should be 4.3BSD +(things) + (security features) > Since GNU will be distributed in a source code form for next to > nothing cost, it will be very attractive to small schools or > companies that want to run UNIX but their gurus want source code. The difference between Minix and the GNU kernel is the delivery date. Minix is available now for IBM PC clones. Adding features like networking and MMU/VM support should not be overly difficult. I wonder whether having a full 4.3BSD on a personal computer is not overkill. Personally I'd rather have an easily modifiable kernel. For most purposes V7 is entirely adequate, although it certainly has its shortcomings. G. Weijers PTT Dr. Neher Laboratories Leidschendam, the Netherlands disclaimer: the expressed opinions are entirely mine, and not necessarily the opinions of my employer. -- 1 2 3 4
karl@sugar.UUCP (Karl Lehenbauer) (09/09/87)
In article <3470@islenet.UUCP>, richard@islenet.UUCP (Richard Foulk) writes: > In article <8520@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > ...A less charitable view of this is that Stallman couldn't write a small > > program to save his life. Unfortunately, this is a common maladay nowadays. > Leave it to someone who's been using small, out-dated equipment for > years now to be so publicly unkind. > How seemingly intelligent people can find the need to belittle > others publicly, without provocation, is a mystery. > But to attack someone who writes software and distributes it free of > charge, to attack them because they don't cater to your particular > obsolete machinery is amazingly selfish and stupid. You chastise Henry Spencer for belittling others publicly but then you use this kind of inflammatory rhetoric to belittle him, publicly, in exactly the same manner you accuse him of doing, calling him "seemingly intelligent" and "amazingly selfish and stupid." I thought his posting was pretty funny, and it almost certainly had a far less scabrous and more harmless intent than your rather vitriolic followup. If everyone would work at using less confrontational language in their postings, I'd at least get a lot more of the things out of usenet that I'm looking for, spending my time on usenet more efficiently as well. Presumably others would also find this to be true. -- ...!soma!uhnix1!sugar!karl "Life, don't talk to me about life." - Marvin TPA
martillo@athena.mit.edu (Yakim Martillo) (09/09/87)
>The problem is that the GNU project isn't being developed for ALL of us to >use it, just the ones with virtual memory. I think they're too optimistic >about the power of future machines. I don't think personal computers will >have VM for a long time yet. Are you telling me that all these 80386 upgrade cards which are supposed to go into PC/ATs don't have virtual memory capability? >This means that there's no incentive to work for GNU... we won't get anything >for it... and even if we wanted to help them out anyway we don't have the VM >machines to do the work on. I have seen 80386 based machines with 80 Meg discs and the usual assortment of peripherals selling for 2800. I think this price will drop. I expect that between upgraded PC/ATs and 80386 PCs a lot of us will have VM machines to work on. >Also, VM isn't always appropriate. You can't do real-time with VM, for example. > The gnu kernal is based on trix supposedly which can support different types of schedulers as different threads I believe. If virtual memory pages can be locked in physical memory, if the active process can establish its own interrupt vector table (all of which should be possible on the 80386), real-time with VM should be possible. Other methods should be possible, and to tell the truth I think Intel microprocessors are rather wedged devices. >Maybe we need a LLAMA project: Little League Amateur Mach Analog. >-- >-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter >-- U <--- not a copyrighted cartoon :->
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/10/87)
In article <647@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<I don't think something like the FSF should be deciding what hardware the
<system will run on.
And I don't think that people not supporting a project should be
dictating it's goals.
<Start out with a small, extensible kernel... something
<on the order of XINU, MINIX, or TUNIS. Make sure it's designed with hooks in
<place to expand it... use message passing (I know AST claims it's not efficient
<enough, but it seems to work well on the Amiga). Keep it modular. Then you
<can add the VM memory manager, or the real-time scheduler. You'll have
<something you can build on.
Sounds like a nice project. Why aren't you working on it, instead of
grousing about how the people working on free software aren't doing it
for you?
And if you *are* working on it, let me know what I can do to help.
<mike
--
The sun is shining slowly. Mike Meyer
The birds are flying so low. mwm@berkeley.edu
Honey, you're my one and only. ucbvax!mwm
So pay me what you owe me. mwm@ucbjade.BITNET
msf@amelia (Michael S. Fischbein) (09/10/87)
In article <2346@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <1883@encore.UUCP> adamm@encore.UUCP (Adam S. Moskowitz) writes: >>Why kill yourself to deal with what many people feel is a bad hardware design? > >Well, I can tell you why *we* do it; but that particular reason isn't >applicable to the Free Software Foundation. [The "we" above is presumably Ashton-Tate ] How about rephrasing Mr. Moskowitz's comment to be: Why kill yourself to deal with what YOU feel is a bad hardware design? If someone else wants to work on it, fine. If someone wants to port the code that I've written and promulgated for general use to their favorite odd architecture, more power to them. I feel no constraint to write code with other people's machine peculiarities in mind, and do not attempt to constrain them to write code for my machine. If I did, I would be asking the intel proponents how they could be so clumsy as to write code that wouldn't run on my Iris. I don't; if someone is gracious enough to put useful code on the net and it won't run as is, I'll port it: that has to be faster and easier than starting from scratch. mike Michael Fischbein msf@prandtl.nas.nasa.gov ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization.
debray@arizona.edu (Saumya Debray) (09/11/87)
>>>> Stallman prefers using machines with larger address spaces ... >>>A less charitable view of this is that Stallman couldn't write a small >>>program to save his life. >>But to attack someone who writes software and distributes it free of >>charge, to attack them because they don't cater to your particular >>obsolete machinery is amazingly selfish and stupid. >I run on a 2MB 68000 and a 8MB 68020 machine, which to me has cheap memory. >Which machine do you think I worry more about keeping happy? A 68000 that >is `outdated', or the 68020? The answer is so simple only totally stupid >jerks (like the last bozo ;-) can't see it. Someone's giving you software free of charge. As I see it, he's doing you a favour. And what's the response? He gets called names, his professional competence is questioned. Is this how you treat people who do you favours? Sheesh! For all who're so upset about not getting Stallman to write their software for them, hey, port the software yourself if you have the balls, else shut up. If you're not paying this guy, he owes you nothing. -- Saumya Debray CS Department, University of Arizona, Tucson internet: debray@arizona.edu uucp: {allegra, cmcl2, ihnp4} !arizona!debray
peter@sugar.UUCP (09/11/87)
> I assume you left off the ":)" by accident. If GNU is supposed to be > BSD 4.3 compatable it is a significantly more ambitious effort than > MINIX. MINIX is a decent, small system for teaching. GNU is supposed > to be suitable for research or commercial development. Are you implying that Version 7 wasn't suitable for research or commercial development? Remember... UNIX didn't start out as BSD 4.3 either. Thank the gods (Thompson & Ritchie). BSD would never have run on the machines available in the early and mid seventies, just as GNU won't run on the personal computers available today. > I have been looking for an inexpensive, Unix-based system for my > personal use. MINIX isn't powerful enough to be useful to me, even > for hobby hacking. Hopefully GNU will be. MINIX probably needs a better message passing mechanism, to avoid some of the delays, and a bit of disk I/O optimisation. Otherwise it's quite a usable system if you don't have anything better. Personally I prefer AmigaDOS, but it's not designed to go anywhere... and MINIX is. I will venture to predict that by the time GNU is out MINIX will be big enough to satisfy you. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.
peter@sugar.UUCP (Peter da Silva) (09/12/87)
> [ Mike wants to know what I'm working on instead of supporting GNU or > enhancing MINIX ] Writing routines that help people write well-behaved Amiga applications without being an O/S freak or programming in (ick) Basic. That is, in between raising a kid and writing videogames. Pretty much same as you, I suspect. I regretfully decided I wouldn't work on polishing MINIX until I had paid off the Amiga and could afford a clone as well. I've already explained what I think is wrong with GNU. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.
gertjan@nlcvx.convex.nl (Gertjan Vinkesteyn) (09/12/87)
please keep this discussion out if this newsgroup. thanks -- UUCP and other network )\/( in America: ..!seismo!mcvax!nlcvx!gertjan connections via mcvax )/\( in Europe: ..!mcvax!nlcvx!gertjan This note does not necessarily represent the position of Convex Computer BV Therefore no liability or responsibility for whatever will be accepted.
ron@topaz.rutgers.edu.UUCP (09/12/87)
The MINIX kernel supports the most of the V7 system calls. That is not to say it is equivelent to what we grew up with as Version 7. MINIX does not swap (at least not the one I have). Devices work different. In addition, although it probably is good for it's intended purpose (teaching) they way it goes about doing certain things makes it a bit slower than it needs to be. In addition, the vast amount of user mode code are subsets of the V7 programs or not there at all. Anyhow, RMS is right. He shouldn't be re-implementing either V7 or BSD. If I just wanted to USE a UNIX-like operating system, I'd use one of the ones currently available that already runs on my PC. It's senseless duplication of effort. Since RMS is trying to bring about social change in computer use, I doubt that reimplementing the past is going to help. Systems he has developed previously have become succesful because they were novel and worthwile, not because they were given away free. I'd rather see him blazing his way for the next generation than forced to reimplement the same old stuff so a few lazy hackers could have free source code to diddle with. -Ron
dave@sdeggo.UUCP (09/13/87)
In article <692@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: (there was more up here about GNU being better than Minix for software development) > Are you implying that Version 7 wasn't suitable for research or commercial > development? Remember... UNIX didn't start out as BSD 4.3 either. Thank > the gods (Thompson & Ritchie). BSD would never have run on the machines > available in the early and mid seventies, just as GNU won't run on the > personal computers available today. It's not a case of wasn't; it was. It isn't today (at least not a PDP-11 based version), and neither is Minix in its present, IBM PC form. Minix is an impressive effort, and I give Dr. Tanenbaum his due, but I would hate to have to develop a large software package (has anyone ported "hack" yet?) under it. It's kind of like all the people who have taken Pascal (designed as a _teaching_ language, to be hand compiled by an instructor!) and wanted to try and develop real software in it. It's possible, but it ain't pleasant. BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's and 68020, so there is no reason that GNU wouldn't. "Personal computers available today" are available based on those chips, and that is where the market is heading. Wtih some work, (as Peter pointed out in his article, but I already threw away that part :-( ) Minix could be changed to be BSD compatible. The first task, though is to port it to a 68000 (with a good memory manager) or an 80386 and get around the 64K task size limit. The rest could be added in slowly. This might beat GNU out the door, but I'm not sure of the status of the GNU project. Why are so many people so anxious to beat on it? Someone's doing you a favor and all you can do is bitch about how "it's not here, it's too big, it doesn't do what I want it to do, my machine can't run it..."? Cripes, don't look a gift horse in the mouth. Especially one that nobody's really seen yet. -- David L. Smith {sdcsvax!sdamos,ihnp4!jack!man, hp-sdd!crash}!sdeggo!dave sdeggo!dave@sdamos.ucsd.edu "How can you tell when our network president is lying? His lips move."
ast@cs.vu.nl (Andy Tanenbaum) (09/14/87)
In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >With some work, ... Minix could be changed to be BSD compatible. The first >task, though is to port it to a 68000 (with a good memory manager) or an >80386 and get around the 64K task size limit. The rest could be added in >slowly. As has been pointed out already, MINIX has already been ported to the 68000, albeit without an MMU. That (Atari) version is now in beta testing. The Atari version does not have a 64K limit. Actually, I think that if anyone is going to do that much work, a much better idea is to modify MINIX to make if conform to the POSIX standard, which is the UNIX of the future. Here is a suggestion/request in that direction. Will someone who is familiar with POSIX draw up a list of POSIX system calls, noting for each one whether 1. it is identical to the corresponding MINIX call 2. it is different from the corresponding MINIX call 3. it is not present in MINIX at all Similarly, for each program and library routine in POSIX, a similar list would be useful. That way people who want to get together and make MINIX more "real world", could at least have a specific list of what needs to be done, and the target would be something that will eventually be an International Standard, rather than 4.3, which is not likely to survive once an International Standard has been established for UNIX systems. Andy Tanenbaum (ast@cs.vu.nl)
fdr@apollo.uucp (Franklin Reynolds) (09/14/87)
In article <692@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >> MINIX is a decent, small system for teaching. GNU is supposed >> to be suitable for research or commercial development. > >Are you implying that Version 7 wasn't suitable for research or commercial >development? Are you impying that MINIX is suitable for research or commercial development? All I implied was that MINIX was not suitable for research or commercial development. MINIX is similar, but not equal, to Version 7. Some of the features that are lacking are very important. On the other hand, Version 7 is pretty old and lacks some things that are important to *me*. > >MINIX probably needs a better message passing mechanism, to avoid some of >the delays, and a bit of disk I/O optimisation. Otherwise it's quite a >usable system if you don't have anything better. Personally I prefer >AmigaDOS, but it's not designed to go anywhere... and MINIX is. > >I will venture to predict that by the time GNU is out MINIX will be big >enough to satisfy you. It is not clear to me that MINIX needs much in the way of extentions. I think it is welled suited to the task it was designed for, i.e., teaching. However, I want a system with virtual memory (large address space), demand paging, distributed file system, communications and database support. I suspect, though I can't prove, that these facilities are important to an awful lot of researchers and commercial developers. If MINIX is extended along these lines then I will check it out again, otherwise, I will wait for GNU. Franklin Reynolds Apollo Computer mit-eddie!apollo!fdr
preston@felix.UUCP (Preston Bannister) (09/14/87)
In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >It's kind of like all the people who have taken Pascal ... >and wanted to try and develop real software in it. It's possible, but it >ain't pleasant. Please, no language R-wars. I've used C, Modula-2, Pascal and Lisp quite a lot at different times. None of them is universally preferable to the other. And yes, I _have_ developed "real" software in Pascal. >BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's >and 68020, so there is no reason that GNU wouldn't. "Personal computers >available today" are available based on those chips, and that is where the >market is heading. Close but not quite. The 68000, 68010 and 68020 cannot support demand paged virtual memory without an MMU. The (original) 68000 has a basic flaw that makes implementing virtual memory ugly even _with_ an MMU. The only easily availible (i.e. low cost) machine with a suitable support for demand paged virtual memory is the 80386-based PC family. The next closest candidate is the Mac II, which will have a reasonable MMU sometime soon (when Motorola gets it's new MMU chip out the door). That leaves out the vast majority of personal computers. >With some work, ... >Minix could be changed to be BSD compatible. I would think that the best long-term goal would be to make Minix as close to Posnix compatible as possible. >The first >task, though is to port it to a 68000 (with a good memory manager) or an >80386 and get around the 64K task size limit. The rest could be added in >slowly. The add something constructive to this discussion... :-) I think what we should _really_ be thinking about is how to make Minix match the availible machines more closely. One thing about Unix that has always bugged me is the fork() primitive. The fork primitive _assumes_ that you can make an _exact_ copy of a running process. That's rather difficult (expensive, ugly...) on a machine that doesn't support the right flavor of virtual memory. It also ties the process abstraction and the virtual address space abstraction together (i.e. you can't have more than one process in the same address space). Most uses of fork() are immediately followed by an exec() call. Why else do you think the BSD people came up with vfork()? A direct "start program in a seperate process" call would accomplish the same effect and would be easily implementable on machines without hardware support for (the right flavor of) virtual memory. I'd rather see primitives like "start process in same address space", "start process in new address space", and "start program in new address space". (Perhaps this could be orthogonalized by combining primitives for program-loading, process creation, and address space creation). I suspect with a little thought, the primitives could be implemented _efficiently_ on a much wider range of machines. -- Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister
henry@utzoo.UUCP (Henry Spencer) (09/15/87)
> Leave it to someone who's been using small, out-dated equipment for > years now to be so publicly unkind. Actually, I'm about to start using much larger and more modern equipment. This does not diminish my distaste for software that seems to be written on the assumption that 4MB memory boards cost a nickel apiece. To pick a non-GNU example, graphing the size of the ls(1) command versus time is an interesting exercise, not to be recommended if you are susceptible to nausea and vomiting. To pick an example that is ready at hand, the Sun 3.2 ls(1) is four times the size of the V7 ls(1). It's not four times as good; the improvement in functionality might charitably be put at 25%. This sort of gratuitous bloat is endemic in post-PDP11 software. While I do not claim that 16-bit address spaces are anything but a pain -- I have much more experience with this than most of my readers! -- they do tend to teach respect for resource consumption. I will not be sorry to leave the PDP11 behind, but it won't be trivial to make our glorious new 32-bit machine support as many users -- doing the same things! -- as our lousy little 11/44, despite much more memory and a much faster CPU. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (09/15/87)
> > A less charitable view of this is that Stallman couldn't write a small > > program to save his life. Unfortunately, this is a common maladay nowadays. > > It's not only less charitable, it's dumb. Having met Richard and dealt with > him technically (although not a lot), I'd bet he *could* write a small > program... Actually, having said as much in private mail, I might as well say it in public: Stallman *is* quite competent -- I may question his judgement but not his ability -- and certainly could write a small program to save his life. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
jbs@eddie.MIT.EDU (Jeff Siegal) (09/16/87)
In article <8579@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >[...] >To pick a non-GNU example, graphing the size of the ls(1) command versus >time is an interesting exercise, not to be recommended if you are susceptible >to nausea and vomiting. To pick an example that is ready at hand, the Sun >3.2 ls(1) is four times the size of the V7 ls(1). It's not four times as >good; the improvement in functionality might charitably be put at 25%. However, a more meaningful exercise would be to graph the cost of the memory used by ls(1) versus time. This is not recommended, if you are likely to be nauseated by the failure of Unix developers to take best advantage of available "resources". Seriously, rapidly changing conditions are a fact in the computer industry. To attempt to use such volitile constraints as a metric over time doesn't make too much sense. Jeff Siegal
rlk@think.COM (Robert Krawitz) (09/16/87)
In article <7320@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: ]In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: ]>BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's ]>and 68020, so there is no reason that GNU wouldn't. "Personal computers ]>available today" are available based on those chips, and that is where the ]>market is heading. [...386 boxen and Mac II w/68851] ]That leaves out the vast majority of personal computers. These days. How about t[gettimeofday()+2yrs]? That, after all, is what the FSF is heading for. ]>With some work, ]... ]>Minix could be changed to be BSD compatible. ] ]I would think that the best long-term goal would be to make Minix as ]close to Posnix compatible as possible. Minix was designed as a teaching system, not as a production system. It would take lots of hacking to hammer it into shape. For that matter, so would GNU, I suppose, but it's starting from a premise that strikes me as more amenable to a production machine. ]I think what we should _really_ be thinking about is how to make Minix ]match the availible machines more closely. One thing about Unix that ]has always bugged me is the fork() primitive. The fork primitive ]_assumes_ that you can make an _exact_ copy of a running process. ]That's rather difficult (expensive, ugly...) on a machine that doesn't ]support the right flavor of virtual memory. It also ties the process ]abstraction and the virtual address space abstraction together (i.e. ]you can't have more than one process in the same address space). Hmm...seems to me that you could implement fork() on an 8086, if you used a small memory model and programs cooperated (didn't play with the segment registers). The PDP11 didn't have virtual memory either, if my memory serves me. To run multiple processes concurrently you need memory management, but not necessarily virtual memory. To fork, you need some way of creating distinct address spaces. You certainly don't need virtual memory. Since Minix runs on an 8086 just fine, and that's the weakest processor that anyone has any interest in running multiprocess things on, I don't see why this is a problem. ]Most uses of fork() are immediately followed by an exec() call. Why ^^^^ ]else do you think the BSD people came up with vfork()? For these cases. A direct "start ]program in a seperate process" call would accomplish the same effect ]and would be easily implementable on machines without hardware support ]for (the right flavor of) virtual memory. That already exists in BSD and probably in SysV, but as a library call implemented in terms of fork() (or vfork()) and exec(). In fact, Kernighan & Pike give an example of a rewritten system() useful for special purposes (it's been a while since I read it, so forgive me for no page or context reference). ]I'd rather see primitives like "start process in same address space", ]"start process in new address space", and "start program in new ]address space". (Perhaps this could be orthogonalized by combining ]primitives for program-loading, process creation, and address space ]creation). I suspect with a little thought, the primitives could be ]implemented _efficiently_ on a much wider range of machines. Vfork in BSD is implemented reasonably efficiently (compared to fork, at least), and it's hard to see why it couldn't be implemented correctly on a non-VM machine. Remember that when you do a vfork, the child process shares the address space of the parent (indeed, the parent goes to sleep until the child exits or forks). This may be what you're looking for. But remember, fork() is useful by itself in many circumstances, such as daemons that handle more than one input or output channel (sendmail, inetd, etc.). Personally, I'd rather see machines that have facilities powerful enough to run big, powerful software like GNU and emacs. I don't care for software that's been held back because of {IBM,Microsoft,Intel} brain damage. Just because a large blue company and clones sell more computers than anyone else doesn't mean that it's the way to go. I'm more interested in 68020/68030, 80386 or 80486 whenever that happens because the life cycle will probably be a lot longer. Robert^Z
bzs@bu-cs.bu.EDU (09/17/87)
I would be happy to draw all this speculation about the future of GNU, Mach and the machines to run it on towards INFO-FUTURES@BU-CS.BU.EDU (...harvard!bu-cs!info-futures, some sites get it via USENET as comp.society.futures) where the conversation would probably even be appreciated. It's a large list, your prognostications won't go unheard. -Barry Shein, Boston University
kent@xanth.UUCP (09/17/87)
In article <6886@eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes: >In article <8579@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>[...] >>To pick a non-GNU example, graphing the size of the ls(1) command versus >>time is an interesting exercise, not to be recommended if you are susceptible >>to nausea and vomiting. To pick an example that is ready at hand, the Sun >>3.2 ls(1) is four times the size of the V7 ls(1). It's not four times as >>good; the improvement in functionality might charitably be put at 25%. > >However, a more meaningful exercise would be to graph the cost of the >memory used by ls(1) versus time. This is not recommended, if you are >likely to be nauseated by the failure of Unix developers to take best >advantage of available "resources". [...] >Jeff Siegal Not that I love jumping onto Henry's side of the fence; I still think his criticism of RMS was out of line, but... Here at school, and at every other facility I've used over 2.5 decades, the system is always constrained by storage resources. A program four times as big costs four times as much to store, and while it may be a nickel or a dime for ls(1), when creeping bloatitis overtakes all the software, you get nicke-dimed to death. Second, another correspondent noted that in ten million process activations on his system, 98% took less than two seconds of cpu time. This means that loading them was a significant fraction of all the work done in executing them. Because system bandwidth (Gee, an architectural issue in comp.arch!) increases drive up the cost of a whole system and almost all its components dramatically, this is the area where improvements are slowest. Tying up precious bandwidth to load unused portions of over-featured programs is a big loser, and I think this tips the scales to Henry's side of the argument. We are rapidly headed toward being I/O bound simply due to program load costs. To put it another way, graph the time to load ls(1) versus date of the version for the versions mentioned and the systems on which they run, and weep. For an example close to home, my Amiga is doing good if it can drag programs off a hard disk at 30K bytes/second over an SCSI interface. Even though, given the money, I can expand the system to 12.5 megabytes of memory, and put a 760 megabyte hard disk on it, waiting 15 seconds for a 0.5 megabyte editor to load from hard disk is a real drag. Kent, the man from xanth. "His expression lit up. 'Hey, you wouldn't be a dope smuggler, would you?' Rail looked confused. 'Why would anyone wish to smuggle stupidity when there is so much of it readily available?'" -- Alan Dean Foster, GLORY LANE
jbs@mit-eddie.UUCP (09/18/87)
In article <2473@xanth.UUCP) kent@xanth.UUCP (Kent Paul Dolan) writes: )In article <6886@eddie.MIT.EDU) jbs@eddie.MIT.EDU (Jeff Siegal) writes: ))In article <8579@utzoo.UUCP) henry@utzoo.UUCP (Henry Spencer) writes: )))[...]graphing the size of the ls(1) command versus )))time is an interesting exercise[...] )) ))However, a more meaningful exercise would be to graph the cost of the ))memory used by ls(1) versus time. [...] ) )[...] )We are rapidly headed toward being I/O bound simply due to program load )costs. ) On the system I am now on (and the Sun Henry was refering to) % file /bin/ls /bin/ls: demand paged pure executable ^^^^^^^^^^^^ )To put it another way, graph the time to load ls(1) versus date of the )version for the versions mentioned and the systems on which they run, )and weep. ) )For an example close to home, my Amiga is doing good if it can drag )programs off a hard disk at 30K bytes/second over an SCSI interface. )[...] Again, if you take into account the changing conditions that exist in computer technology, things look much better. 30KB/sec is horribly slow for a Unix system (Most Sun's use Eagles, with rates of 1.8MB/sec or higher). I suspect that over the past 15 years, typical transfer rates for disks on Unix systems have improved by at least a factor of four, although I do not have the hard data to present here. Jeff Siegal
peter@sugar.UUCP (Peter da Silva) (09/19/87)
In article <37461f69.ccb2@apollo.uucp>, fdr@apollo.UUCP writes: > In article <692@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >> MINIX is a decent, small system for teaching. GNU is supposed > >> to be suitable for research or commercial development. > >Are you implying that Version 7 wasn't suitable for research or commercial > >development? > Are you impying that MINIX is suitable for research or commercial > development? No, I was inferring that you were implying that Version 7 wasn't. > All I implied was that MINIX was not suitable for research or commercial > development. Actually, that's what you stated. You implied by the analogies between V7 and MINIX, and GNU and BSD, that V7 wasn't. Right now, neither MINIX nor GNU is suitable for commercial development... MINIX because it's incomplete, and GNU because it's nonexistent. > MINIX is similar, but not equal, to Version 7. Some of the > features that are lacking are very important. On the other hand, > Version 7 is pretty old and lacks some things that are important to *me*. MINIX can be made equal to V7. And then it can be made better. In the meantime you and I and everyone else can work on doing this. GNU might be the greatest system since OS/360, but first it has to come out. > It is not clear to me that MINIX needs much in the way of extentions. I > think it is welled suited to the task it was designed for, i.e., teaching. Yes, MINIX is now pretty much in the state UNIX was in the 5th edition days. UNIX was never intended to be the most popular minicomputer operating system ever, but it did a good job. I think that with today's software tools MINIX can follow the 12 year path of UNIX in considerably less than 12 years. > I suspect, though I can't prove, that these facilities are > important to an awful lot of researchers and commercial developers. Not important enough to keep them from using Messy-DOS, it seems. > If MINIX is extended along these lines then I will check it out again, > otherwise, I will wait for GNU. Got a good book to read? I'd recommend "Software Tools" by Kernighan and Plauger. If GNU ever comes out, then I'll check it out for the first time. If I worked at Apollo too then maybe I'd be content to just sit and wait. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Insert cute saying here.
lmcvoy@eta.ETA.COM (Larry McVoy) (09/19/87)
In article <2473@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >[ argument that says program should be small because of load time ] Um, it seems to me that this issue is nice handled by demand paging. Provided that your pages don't get big (1-10k is probably cool), you don't really pay for anything that you don't use. You lean on locality a lot, but if you're really worried about it, profiling and reordering code will kill that too. Get a VM machine & kwit yer bitchin :-) -- Larry McVoy uucp: ...!{uiucuxc, rosevax, meccts, ihnp4!laidbak}!eta!lmcvoy arpa: eta!lmcvoy@uxc.cso.uiuc.edu
chips@usfvax2.UUCP (Chip Salzenberg) (09/19/87)
In article <7320@felix.UUCP>, preston@felix.UUCP writes: > > Most uses of fork() are immediately followed by an exec() call. Why > else do you think the BSD people came up with vfork()? A direct "start > program in a seperate process" call would accomplish the same effect > and would be easily implementable on machines without hardware support > for (the right flavor of) virtual memory. There is one thing about UNIX fork()-exec() that you've overlooked -- after the fork(), the child process can set up the environment of the soon-to-be-exec'ed process by modifying its own environment. (Can you say `pipes, I/O redirection and current directory'? I knew you could.) > I'd rather see primitives like "start process in same address space", > "start process in new address space", and "start program in new > address space". > -- > Preston L. Bannister Under OS-9, there is no UNIX-style fork(); there is a combined fork()-exec(). Granted that it's efficient on 6809 and 680x0 even without an MMU, it's still a royal pain. The parent process must dup() its file descriptors, open the child's, fork(), close the child's, and restore its own. And those dup'ed file descriptors are still open on the child! Blech. I'd like `new process, same address space', but for spawning another program, E{NIX semanitics are elegant and useful. -- Chip Salzenberg UUCP: "uunet!ateng!chip" or "chips@usfvax2.UUCP" A.T. Engineering, Tampa Fidonet: 137/42 CIS: 73717,366 "Use the Source, Luke!" My opinions do not necessarily agree with anything.
mouse@mcgill-vision.UUCP (09/20/87)
In article <2117@eecae.UUCP>, lawitzke@eecae.UUCP (John Lawitzke) writes: >> Minix is v7 - (things you didn't know about, and don't want even if >> you did), the GNU kernel should be 4.3BSD + (things) - (security >> features). > The GNU kermel should be 4.3BSD + (things) + (security features) > What security features don't you want? In general, anything which serves no purpose but security. > Separate userids and passwords? Lisp Machines have userids but everyone is a super-user, to use the UNIX terminology. They have no passwords. They get by fine. > File protection modes? I could live without file protections. (I already do. My login has uid 0.) > Disk quotas? I could DEFINITELY live without disk quotas. We have them turned off at the moment! > checking the name of a system uucping in? Close call (pun deliberate). But if you are going to go passwordless there is no reason to bother checking this. I am clearly an extreme case. Let's provide a larger-scale example. We run a 4.3 derivative here. Two security "features" I wouldn't mourn come to mind immediately. One was simple to disable and benign once disabled; the other is inexcusable because NO MEANS WAS PROVIDED TO DISABLE IT. The first one is the "secure" option in /etc/ttys (all our lines are marked secure); the other is the restriction that only users in group 0 are allowed to su to root even with the root password. We had to recompile su to get rid of this one. I don't mind security "features" if they don't get underfoot (eg, distinct userids). But when they do, I'd better be able to disable them! For example, Sun's NFS normally maps uid 0 into uid -2 for remote requests, as a security "feature". However, I can live with this because Sun documents how to fix it and once fixed it is fixed for good. (Well, until the next release....) der Mouse (mouse@mcgill-vision.uucp)
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (09/21/87)
In article <8490@think.UUCP> rlk@THINK.COM writes: >.... The PDP11 didn't have virtual memory either, >if my memory serves me. .... At the risk of re-opening an old debate, the PDP-11 \does/ have virtual memory. It's just that, for various technical reasons, the original Unix implementation for it chose to use swapping instead of paging as its virtual memory technique. Yes, it's a nit, but the PDP-11 is a fine machine, and deserves to be remembered correctly. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
aglew%mycroft@gswd-vms.Gould.COM (Andy Glew) (09/21/87)
PROCESS TEMPLATES ----------------- ..> Cost of fork/execs, ..> Providing a fork/exec call ..> etc. An earlier poster is correct in saying that a combined fork/exec call is not as convenient as doing a fork followed by an exec, because the typical use of vfork is if( fork() == 0 ) { /* Copy parent process */ dup2(..) /* Manipulate parts of state to be inherited by new program */ exec(..) /* Bring new program in */ } I wonder, though, if we cannot divide this up into two operations?: (1) setting up a process (2) dispatching the process. (1) may be cheap on some systems, expensive on others. But (2) can probably be made inexpensive on all systems. There is probably a large class of programs where all the child processes that are likely to be used can be set up in advance, under no time constraints; and when you actually need them almost all the work has already been done, so you just set the PC and go. I call this idea "process templates", and introduce a data structure of the same name. The process template data structure contains slots for all the things that a process has to have - memory maps, descriptor tables, etc. - which you can fill in at different times. Or, you can provide options to copy everything appropriate from one process template to another... Types and Operations: typedef ... proctempT; extern proctempT CurrentProcess; /* The present state of the current process */ proctempT pt_new(); /* Returns a new, empty, process template */ pt_addmemorysegment(pt,memseg); /* Link a memory segment to a process template */ pt_open(pt,path,options,mode); /* Opens a file placing the descriptor in the process template pt */ pt_setpc(pt,pc); /* Set program counter */ pt_setsp(pt,sp); /* Set stack pointer */ pt_loadexecutable(pt,execfile); /* Load executable into template */ pid = pt_dispatch(pt) /* dispatch a process template as a process - error if not all features are set up */ pt_overlay(pt) /* Replace the current process by the new template */ oldpt = pt_wait() /* Wait on a child process, receiving its process template */ pt_copyunsetfeatures(ptfrom,ptto) /* copy all necessary but unset aspects of a process */ pt_linkunsetfeatures(ptfrom,ptto) /* link instead of copy */ Implementing fork/exec: fork() { proctempT childpt = pt_new(); int childpid; pt_copymemory(CurrentProcess,childpt); pt_linkdescriptors(CurrentProcess,childpt); pt_copyunsetfeatures(CurrentProcess,childpt); pt_setpc(&ChildFork); childpid = pt_dispatch(childpt); return childpid; ChildFork: /* ok, so you would probably use a longjump... */ return 0; } exec(execpath) { proctempT execpt = pt_new(); pt_loadexecutable(execpt,execpath); pt_linkunsetfeatures(CurrentProcess,execpt); pt_overlay(execpt); } Now, why would you do all this work? So that you can split out the functionality. Eg. in a math code on a multiprocessor, you want to have N processes working on a several loops, with serial code in between. Instead of repeatedly copying state in forks (or even tforks), set up all your process templates at the beginning of the program linked to share everything with the parent, and just change the pc i them when you need them. In addition, if the system guarantees that all processes created with pt_new() can be pt_dispatch'ed, then you don't have to worry about error conditions or deadlocks if one of the processes you wanted to spawn cannot be sent off. Implementation The process templates could probably be a combination of a kernel data structure, for fields that we cannot allow the user to put just anything in, and a user data structure for fields that are easy to check at dispatch time. The second class of fields could be directly manipulated without system calls.
preston@felix.UUCP (09/21/87)
In article <838@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes: >There is one thing about UNIX fork()-exec() that you've overlooked -- >after the fork(), the child process can set up the environment of the >soon-to-be-exec'ed process by modifying its own environment. >(Can you say `pipes, I/O redirection and current directory'? I knew you could.) The point I was trying to make was that the fork() is typically followed by an exec() call and that the full semantics of fork() are not needed in those cases. What I should have said :-) was that the code executed between the fork() and exec() call typically does not need the full semantics of fork(). An extreme example would be to imagine, say, a program that is using a large amount of memory that wants to run some other program with the output into a pipe that it would read. The sequence would be something like: - open pipe - fork - assign one end of pipe for child's standard output - exec - (parent process now can read output of child from pipe) The fork call is going to be awefully expensive, as a copy of the entire data space of the parent will be made. The code between the fork() and exec() really doesn't need that copy, as all it does is make a small modification to the context of the child process. We need to factor out the management of process contexts (the set of open files, mapping of signals, etc.) from the management of the address/data space. What I'm looking for is a good set of primitives. From my point of view, fork() and exec() are not really primitives, as they represent a number of different operations. Fork() can be factored to: - create new process context - copy parent process context to new context - create new address space - copy parent's data to new address space Exec() can be factored to: - delete address/data space - create new address/data space - load code from given file - begin execution of code from file (Did I miss something?) Current typical uses of fork()/exec() could be replaced by: - create new process context - copy parent process context to new context (typical code to reassign files, signals, etc) - create new address/data space - load code from given file - begin execution of code from file -- Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister
henry@utzoo.UUCP (Henry Spencer) (09/22/87)
> However, a more meaningful exercise would be to graph the cost of the > memory used by ls(1) versus time. This is not recommended, if you are > likely to be nauseated by the failure of Unix developers to take best > advantage of available "resources". In other words, the cheaper the memory gets, the sloppier the programmer can be? This sort of attitude leads to Mike O'Dell's complaint: "In spite of the fact that the hardware people keep giving us faster processors, the MIPS available to my programs stay the same." The idea is to deliver the lower costs and greater power to the *user*, not to squander them by doing everything much less efficiently. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (09/22/87)
> Most uses of fork() are immediately followed by an exec() call. Why > else do you think the BSD people came up with vfork()? A direct "start > program in a seperate process" call would accomplish the same effect > and would be easily implementable on machines without hardware support > for (the right flavor of) virtual memory. Be careful. Most uses of fork() are *not* immediately followed by an exec() call; the two are usually separated by some manipulation of things like file descriptors and signals. A combined fork-exec is definitely possible, since the OS/9 people did it, but it's not as simple as it sounds at first. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
peter@sugar.UUCP (Peter da Silva) (09/22/87)
> [you all know the argument: bigger programs means more time wasted > on loads] > > Again, if you take into account the changing conditions that exist in > computer technology, things look much better. 30KB/sec is horribly > slow for a Unix system (Most Sun's use Eagles, with rates of 1.8MB/sec > or higher). But people with personal computers usually have SASI or SCSI hard disks with really low transfer rates. This is the market a public domain O/S has to target. People with Big Iron aren't interested in public domain: the O/S software itself is a minor cost (well, except for IBM mainframes). Anything with an Eagle is effectively Big Iron to us peons. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?
bzs@bu-cs.bu.EDU (Barry Shein) (09/23/87)
This is really becoming a silly argument, it's obvious the two sides have completely different things in mind. Those justifying larger programs are envisioning more utility and thus hoping to save people-time over cpu-time or kilocore clicks. Those bashing larger programs are making the observation that much of the largeness in programs is just due to bad design or a brain-damaged idea about what people "need". I'd be the first to agree that many, many programs in the past got bloated just to sell it to non-technical manager types who had final budgetary decision and little or no idea about the real goals (oooh, good error messages! [too bad it doesn't *do* anything.]) On the other hand it's hard for me to see how a program with, for example, a sophisticated bitmap/mouse/window interface is going to be kept tiny relative to one which doesn't have such an interface, obviously the trade-off in terms of actual utility has to be examined. Certainly the first is a seductive rationalization for anything while the second is a cold, hard reality that people have a lot of trouble dealing with. But it seems silly to say one holds more truth in it than the other. Summary: It's breath mint! It's a candy mint! -Barry Shein, Boston University
brb@hafro.UUCP (Bjorn R. Bjornsson) (09/24/87)
In article <6886@eddie.MIT.EDU>, jbs@eddie.MIT.EDU (Jeff Siegal) writes: >In article <8579@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>... the Sun 3.2 ls(1) is four times the size of the V7 ls(1). ... > >However, a more meaningful exercise would be to graph the cost of the >memory used by ls(1) versus time. This is not recommended, if you are >likely to be nauseated by the failure of Unix developers to take best >advantage of available "resources". > >Seriously, rapidly changing conditions are a fact in the computer >industry. To attempt to use such volitile constraints as a metric >over time doesn't make too much sense. True as this may be, keep in mind that the programs in question: i) Provide comparable functionality. ii) Were written in the same source language. iii) Were compiled by compilers that produce code of comparable density. It follows that a step backwards has been taken in programming methodology, unless the newer version shows considerable gains in efficiency or the older version was highly optimized. It's dismaying to see minor [or no] upgrades to software functionality, eat up a good portion of the order of magnitude difference in hardware. If nothing else, the PDP-11s were good teachers to those of us fortunate [upto say 1980] enough to spend years working on them, as well as those of us that were unfortunate [say after 1980] to spend years with them B-). Maybe we should have started a relief fund for Henry years ago? Anyway I'm happy to see people get their hands on decent machinery, the ones that can use it that is. Bjorn R. Bjornsson {uunet!mcvax, enea}!hafro!brb
chips@usfvax2.UUCP (09/24/87)
In article <7672@felix.UUCP>, preston@felix.UUCP (Preston Bannister) writes: } In article <838@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes: } } >There is one thing about UNIX fork()-exec() that you've overlooked -- } >after the fork(), the child process can set up the environment of the } >soon-to-be-exec'ed process by modifying its own environment. } >(Can you say `pipes, I/O redirection and current directory'? } >I knew you could.) } } What I should have said :-) was that the } code executed between the fork() and exec() call typically does not } need the full semantics of fork(). } } An extreme example would be to imagine, say, a program that is using a } large amount of memory that wants to run some other program with the } output into a pipe that it would read. } } We need to factor out the management of process contexts (the set of } open files, mapping of signals, etc.) from the management of the } address/data space. } } -- } Preston L. Bannister I agree that fork() does much more than is necessary in some cases. For example, I use an editor that forks twice as preparation for running an area of text through a filter; that really _is_ expensive, since our editor is quite large. (No, not emassive :-}; the Rand editor `E'.) -- Chip Salzenberg UUCP: "uunet!ateng!chip" or "chips@usfvax2.UUCP" A.T. Engineering, Tampa Fidonet: 137/42 CIS: 73717,366 "Use the Source, Luke!" My opinions do not necessarily agree with anything.
root@hobbes.UUCP (09/25/87)
> Most uses of fork() are immediately followed by an exec() call.
When this came up last spring, someone (gwyn?) grep'd thru all the Unix
source and found a grand total of TWO places where fork() was immediately
followed by exec()! All the others had dup()s, close()s, and setuid()s, etc
stuck in between. In the future, please try to ground your "facts" in
something solid before making sweeping statements like that...
John
--
John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: > In article <8490@think.UUCP> rlk@THINK.COM writes: > >.... The PDP11 didn't have virtual memory either, > >if my memory serves me. .... > > At the risk of re-opening an old debate, the PDP-11 \does/ have virtual > memory. It's just that, for various technical reasons, the original Unix > implementation for it chose to use swapping instead of paging as its virtual > memory technique. And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), probably because it didn't in fact have the capability of supporting VM. Why do you think DEC developed the Virtual Address Extension (VAX) in the first place? > Yes, it's a nit, but the PDP-11 is a fine machine, and deserves to be > remembered correctly. As a great little non-virtual system. Nothing wromng with that. Sometimes virtual memory means virtual performance, as a good many PDP-11 fans have pointed out. You can run way more users on and get way better real-time response from a PDP 11/70 than any VAX you care to name. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (09/26/87)
Just one question. What are you doing between the time you deleted the address and data space and leaded the new one? Running out of /dev/null? Yes, fork isn't a machine primitive. Very few UNIX system calls are. Read, for example, "should" be: Read required block from file. Copy data from block to buffer. If any more blocks need to be read, repeat. Update current pointer. A number of operating systems expect you to do all this stuff. I'll stick with UNIX and read/write/fork/exec, thanks. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (09/26/87)
>In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: >> ... the PDP-11 \does/ have virtual >> memory. It's just that, for various technical reasons, the original Unix >> implementation for it chose to use swapping instead of paging as its virtual >> memory technique. In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), >probably because it didn't in fact have the capability of supporting VM. You don't give the criteria by which you make this rather bald claim, but I'll try to respond to it anyway. The test for virtual memory is whether the name space of the process is independent of the name space of the processor; that is, the memory seen by the process is the same, no matter where it is located in physical (real) memory. In other words, if the process can be moved to a new place in memory and is unaware that it has been moved, then the process memory is virtual, and the architecture supports virtual memory. The PDP-11 passes this test. If you are trying to say that the PDP-11 didn't permit a process to be run without all of its image mapped, that is indeed true of some processor models. (But not all models -- I've seen experimental versions of Unix on the PDP-11 that were demand paged.) But this isn't a requirement for virtual memory; it just makes alternative virtual memory schemes (like paging) more attractive. >Why do you think DEC developed the Virtual Address Extension (VAX) in the >first place? Yes, DEC did indeed extend the amount of virtual memory available, from a maximum of two 64k pieces to ~2G. I'll even agree that that's quite an extension -- over four orders of magnitude. But they extended the amount, not the concept. >..... Sometimes >virtual memory means virtual performance, as a good many PDP-11 fans have >pointed out. You can run way more users on and get way better real-time >response from a PDP 11/70 than any VAX you care to name. There's some truth in that. I suspect that it's more of a function of the increasing size of programs (and the disk cost to read them in) than a function of the virtual memory architecture (although it \is/ due to virtual memory that programs have been able to bloat so much). But that is currently being mooted elsewhere, so I won't get on that soap box here. BTW, I'm assuming that you meant "interactive" when you said "real-time," since in an actual hard-real-time environment, I would want my tasks running with the memory management turned off and in a soft-real-time environment, I would want my tasks locked down. In either case, the overhead for virtual memory would be similar and the faster processor would win. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
mash@mips.UUCP (John Mashey) (09/26/87)
In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: >> At the risk of re-opening an old debate, the PDP-11 \does/ have virtual >> memory. It's just that, for various technical reasons, the original Unix >> implementation for it chose to use swapping instead of paging as its virtual >> memory technique. >And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), >probably because it didn't in fact have the capability of supporting VM. >Why do you think DEC developed the Virtual Address Extension (VAX) in the >first place? Greg was right in the first place. As a good example, somebody at Naval Postgraduate school did a thesis where they modified UNIX to run demand-paged on an 11/55, and did various performance measurements. they found the paged version was superior in only a small domain. I recall the thesis included an honest, but somewhat chagrined comment like "Thompson was right; simple wins in this case". Why should this be? The technical reasons Greg alludes to are simple: If programs are relatively small [64K I + 64K D max] and if pages are relatively large (compared to size) [8K], then programs are likely to touch every or almost every page very quickly. In this case, you get better disk performance, and have simpler, denser kernel data structures, by swapping instead of paging. I.e., if working set = size of program, you might as well swap. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/27/87)
In article <7672@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: >The fork call is going to be awefully expensive, as a copy of the >entire data space of the parent will be made. It need not be; don't copy the pages until a attempt to modify them occurs.
peter@sugar.UUCP (Peter da Silva) (09/28/87)
In article <1755@ncr-sd.SanDiego.NCR.COM>, greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: > In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), > >probably because it didn't in fact have the capability of supporting VM. > > You don't give the criteria by which you make this rather bald claim, but I'll > try to respond to it anyway. Virtual memory == ability for a task to run without its entire address space residing in primary memory, in a manner that is transparent to the task itself. If you allow the task to manage the "VM", then you're letting overlays in and anything with secondary memory qualifies. This implies that it should be able to recover from a page fault. Now, someone else has claimed that the PDP-11 in some incarnations was able to do this. Since they seem to know whereof they speak, I'll accept it. But I stand on my claim that PDP11 does nore imply VM. What you're talking about... > The test for virtual memory is whether the name space of the process is > independent of the name space of the processor; that is, the memory seen by > the process is the same, no matter where it is located in physical (real) > memory. Is mapped memory (at least that's what DEC calls it, and it's a reasonable description. Especially since we're talking about DEC processors. > BTW, I'm assuming that you meant "interactive" when you said "real-time," > since in an actual hard-real-time environment, I would want my tasks running > with the memory management turned off and in a soft-real-time environment, I > would want my tasks locked down. In either case, the overhead for virtual > memory would be similar and the faster processor would win. Yeh, yeh. For hard real-time I wouldn't want anything more complicated in the way of operating systems than a scheduler. Down here in Houston real-time generally refers to SCADA, which makes most people's "soft realtime" look like granite. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
aglew%xenurus@gswd-vms.Gould.COM (Andy Glew) (09/28/87)
>Doug Gwyn <gwyn@brl-smoke.arpa>: > >>preston@felix.UUCP (Preston Bannister): >>The fork call is going to be awefully expensive, as a copy of the >>entire data space of the parent will be made. > >It need not be; don't copy the pages until a attempt to modify them occurs. I assume that you are talking about copy-on-write. On some systems COW is a big win - on others, maybe not as much as you'd hoped. (1) You still have to copy the PTEs, or whatever segment/page virtual addressing data structures you have. ON large codes (like, say, a big array muncher that calls a subprocess - or, closer to home, GNU EMACS) copying the PTEs can take a long time. (2) Each COW may be expensive - particularly if you have TLB/cache hardware with no flush-page command (or if you have such a command, but the implementation is simpleminded (ie. read optimized for regular accesses, not throughput)). (3) COW depends on precise interrupts, as does any type of page faulting. Big machines like Cray don't have virtual memory; moreover, the cost of RAM is falling fast enough that non-page-faulting machines become interesting again. (They may have memory mapping). On such a machine, COW doesn't help you much. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms.arpa I always felt that disclaimers were silly and affected, but there are people who let themselves be affected by silly things, so: my opinions are my own, and not the opinions of my employer, or any other organisation with which I am affiliated. I indicate my employer only so that other people may account for any possible bias I may have towards my employer's products or systems.
ejbjr@ihlpg.ATT.COM (Branagan) (09/28/87)
> > >.... The PDP11 didn't have virtual memory either, > > >if my memory serves me. .... > > > > At the risk of re-opening an old debate, the PDP-11 \does/ have virtual > > memory. It's just that, for various technical reasons, the original Unix > > implementation for it chose to use swapping instead of paging as its virtual > > memory technique. > > And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), > probably because it didn't in fact have the capability of supporting VM. > Why do you think DEC developed the Virtual Address Extension (VAX) in the > first place? Virtual memory != Support for demand paging The PDP-11 (later models only) does have virtual memory (i.e. supports a translation from logical to physical address). This was necessary to support more than 64K of physical memory on a machine only capable of addressing 64K - sort of backwards from the typical situation of using virtual memory to support processes which use more memory than physically available on the machine (or to the process). The PDP-11 does not have support for paging (i.e. does not generate convienient hardware interupts allowing a page to be brought into memory). Actually the problem here is that it is difficult to figure out how much of the instruction that faulted has executed already, and completing execution of the instruction which generated the fault (I've seen this done by interpreting the instruction in software, but it is very slow and gross). It looks like the designers made an attempt to add paging capabilities, but it was very difficult without major design and microcode changes (which lead to the VAX 11/780). SUMMARY: The PDP-11 (many models) does support virtual memory, though not for the same purposes as most machines. The PDP-11 has very poor support for paging, but it is theoretically (not practically) possible. -- ----------------- Ed Branagan ihnp4!ihlpg!ejbjr (312) 369-7408 (work)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/28/87)
In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >probably because it didn't in fact have the capability of supporting VM. Greg Noel was right -- the PDP-11 did support virtual memory. Basically, three things are necessary for full support of demand-paged virtual memory: mappable per-process virtual address space pages, generation of a trap when a reference is made to an unmapped page, and ability to restart the faulted instruction after changing the map. All these facilities existed on high-end PDP-11 models with KT11 MMUs. (The low-end models did not have such a memory management unit.) As others have pointed out, there were experimental virtual memory implementations of PDP-11 UNIX. >Why do you think DEC developed the Virtual Address Extension (VAX) in the >first place? To get a larger per-process address space! >You can run way more users on and get way better real-time response >from a PDP 11/70 than any VAX you care to name. Both 22-bit PDP-11s and VAXes have to perform two levels of address translation. Some VAXes provide poorer peripheral I/O paths, but apart from that there is little difference in their real-time abilities.
henry@utzoo.UUCP (Henry Spencer) (09/29/87)
> The fork call is going to be awefully expensive, as a copy of the > entire data space of the parent will be made... Nonsense, not on a sensibly implemented system (4BSD as shipped from Berkeley does not count, although in fairness I should say that this one is not entirely their fault -- hardware bugs got in their way). It just has to *look* like a copy is made. Any half-decent virtual-memory system will do this with copy-on-write, so the bulk of the data never gets copied and the fork is cheap. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
ron@topaz.rutgers.edu (Ron Natalie) (09/29/87)
Actually, the PDP-11 has a perfectly good interrupt for bringing in pages. UNIX uses it to know when to grow the stack. The problem is that there are only eight (or 16 segments) to memory, so paging doesn't get you a whole lot. In addition, the shell, does user mode page faults to know when to grow its heap. -Ron
dave@sdeggo.UUCP (David L. Smith) (09/29/87)
In article <6488@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >You can run way more users on and get way better real-time response > >from a PDP 11/70 than any VAX you care to name. > > Both 22-bit PDP-11s and VAXes have to perform two levels of address > translation. Some VAXes provide poorer peripheral I/O paths, but > apart from that there is little difference in their real-time abilities. There may be little difference in their actual processor speeds, but as far as actual response, it's pretty incredible. We used to run 30 users on a PDP-11/70 with 512K (bytes!) of memory and an RM03. No shared libraries, no shared executables, each user had their own task. However, since the swap size is so small (64 or 128K) you can swap them in and out without hardly even noticing it. It would have really flown with a full 4M. Heck, I used to run real-time terminal programs written in interpreted BASIC-Plus and have them work (but, there couldn't be much of anything else on the system). -- David L. Smith {sdcsvax!amos,ihnp4!jack!man, hp-sdd!crash, pyramid}!sdeggo!dave sdeggo!dave@amos.ucsd.edu "How can you tell when our network president is lying? His lips move."
tim@ism780c.UUCP (Tim Smith) (09/30/87)
In article <840@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes:
< For example, I use an editor that forks twice as preparation for running
< an area of text through a filter; that really _is_ expensive, since our editor
< is quite large. (No, not emassive :-}; the Rand editor `E'.)
Forking does not have to be expensive for large programs. Fork should
just increase the reference counts on the text pages and data pages, and
change all data pages to be read-only. Only copy pages that get a write
fault.
--
Tim Smith, Knowledgian {sdcrdcf,uunet}!ism780c!tim
tim@ism780c.isc.com
"Oh I wish I were Matthew Wiener, That is who I truly want to be,
'Cause if I were Matthew Wiener, Tim Maroney would send flames to me"
kent@tifsie.UUCP (Russell Kent) (09/30/87)
in article <6476@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) says: > Xref: tifsil comp.arch:729 comp.unix.wizards:1184 comp.os.minix:492 > > In article <7672@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: >>The fork call is going to be awefully expensive, as a copy of the >>entire data space of the parent will be made. > > It need not be; don't copy the pages until a attempt to modify them occurs. Unfortunately, the machines that MINIX currently runs on do not have the memory management hardware to support the copy-on-write interrupt (ala DEC VAX processors). Nice try though :-) -- Russell Kent Phone: +1 214 995 3501 Texas Instruments - MS 3635 Net mail: P.O. Box 655012 ...!{ihnp4,uiucdcs}!convex!smu!tifsie!kent Dallas, TX 75265 ...!ut-sally!im4u!ti-csl!tifsie!kent
chips@usfvax2.UUCP (09/30/87)
In article <15124@topaz.rutgers.edu>, Ron Natalie writes: > In addition, the shell does user mode page faults > to know when to grow its heap. > > -Ron Don't I know it! I tried to port the Bourne shell (v7) to a 68000 box running UNOS, which was Charles River Data System's answer to UNIX. UNOS was no problem, but since the 68000 doesn't know how to restart instructions that cause bus faults, I *never* got sh to work reliably. (People used it anyway, which shows you how bad CRDS's command interpreter was!) The C shell, on the other hand, worked right out of the box. (Thanks, Bill!) Of course, I had to adapt for UNOS job control -- wait() could return the same pid any number of times as processes were suspended and restarted -- but that's peanuts in the porting game. :-) -- Chip Salzenberg "chip%ateng.uucp@UU.NET" or "uunet!ateng!chip" A.T. Engineering, Tampa CIS: 73717,366 Last Chance: "chips@usfvax2.UUCP" "Use the Source, Luke!" My opinions do not necessarily agree with anything.
aeusesef@csun.UUCP (10/01/87)
In article <9510@brl-adm.ARPA> aglew%xenurus@gswd-vms.Gould.COM (Andy Glew) writes: >>Doug Gwyn <gwyn@brl-smoke.arpa>: >> >>>preston@felix.UUCP (Preston Bannister): >>>The fork call is going to be awefully expensive, as a copy of the >>>entire data space of the parent will be made. >> [some comments about cow and using it for the current topic] >(3) COW depends on precise interrupts, as does any type of page faulting. > Big machines like Cray don't have virtual memory; Since a Cray doesn't have cirtual memory, you can't do a COW at all. Copying the entire address/data space of the parent isn't all that painfull, either, unless you only have one process running. Cray's, like CDC 6600 etc. machines, have hardware that can shuffle memory around VERY quickly. In fact, an easy way to copy the parent is to: swap parent out to disk (this takes little CPU time); load wherever you wish, and then load the child wherever you wish. Very simple, quick, and the CPU doens't have to do much work (although te PPU does...). >Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew ----- Sean Eric Fagan Office of Computing/Communications Resources (213) 852 5742 Suite 2600 1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard Los Angeles, CA 90036 {litvax, rdlvax, psivax, hplabs, ihnp4}!csun!aeusesef
elg@usl (Eric Lee Green) (10/02/87)
>>In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: >>> ... the PDP-11 \does/ have virtual >>> memory. It's just that, for various technical reasons, the original Unix >>> implementation for it chose to use swapping instead of paging as its virtual >>> memory technique. I recently purchased the Bach book. The history he gives indicates that the probable reason Unix originally used swapping instead of paging, is because the early models of the PDP-11 that they originally implemented Unix on, did not support paging. In any event, you COULD run more programs than you had physical memory for, so I'd say that's virtual memory. -- Eric Green elg@usl.CSNET from BEYOND nowhere: {ihnp4,cbosgd}!killer!elg, P.O. Box 92191, Lafayette, LA 70509 {akgua,killer}!usl!elg "there's someone in my head, but it's not me..."
jfh@killer.UUCP (10/03/87)
In article <819@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article <1745@ncr-sd>, greg@ncr-sd (Greg Noel) writes: > > In article <8490@think.UUCP> rlk@THINK.COM writes: > > >.... The PDP11 didn't have virtual memory either, > > >if my memory serves me. .... > > > > At the risk of re-opening an old debate, the PDP-11 \does/ have virtual > > memory. It's just that, for various technical reasons, the original Unix > > implementation for it chose to use swapping instead of paging as its virtual > > memory technique. > > And neither did any other operating system for the PDP-11 (RSX, RSTS, RT-11), > probably because it didn't in fact have the capability of supporting VM. > Why do you think DEC developed the Virtual Address Extension (VAX) in the > first place? > > > Yes, it's a nit, but the PDP-11 is a fine machine, and deserves to be > > remembered correctly. > > As a great little non-virtual system. Nothing wromng with that. Sometimes > virtual memory means virtual performance, as a good many PDP-11 fans have > pointed out. You can run way more users on and get way better real-time response > from a PDP 11/70 than any VAX you care to name. > -- > -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter > -- 'U` Have you hugged your wolf today? > -- Disclaimer: These aren't mere opinions... these are *values*. No, the registers and micro-code were present in _certain_ PDP-11's to handle virtual memory. I believe that certain micro-Vaxen _didn't_ actually have enough support to handle virtual memory as well as, say, a PDP-11/70. All that is required to support virtual memory is the ability to generate a CPU trap/fault on a reference to a non-existence/non-resident page of memory, and then figure out how to restart the intruction so that it completes as if the page were resident. Might sound a bit simple, but for all it's greatness, the 68000 and 808[86] can't handle virtual memory because in the general case, an instruction can not be restarted. The PDP-11's of the larger type (44/45/70/73/(34?)) could support virtual memory if the memory management hardware had been installed. When a non-resident segment (8 8KB segments for instruction and 8 more for data, except the 34, which didn't support separted I&D) was referenced, a trap was generated and the address of the instruction and PSW were stacked. The operating system then needed to simulate the rest of the instruction, if the failing cycle was a write. In the case of a read, you could make the segment valid (load the MMU's and what not) if no registers had been modified during the instruction, or attempt to simulate the instruction. Whew! Needless to say, I'd much rather swap than go through that mess. Anyway, Unix on 11's did do some neat things. I seem to recall that a trap on a write into a deeper stack address caused the system to backup that instruction and expand the stack. This is the suggested use for the direction bit in the MMU, according to my old '45 manual. If I remember from the days of wierd gone by, we had a C compiler that on entry to a function generated a jump past the jsr pc,cret which was a jump back to the instruction after the first jump. I suppose this `feature' could have been used to demand page text in, had anyone bothered. Anyhow, go read a _modern_ (or even old, like 11/45) manual and you too will become a believer... - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
guy%gorodish@Sun.COM (Guy Harris) (10/04/87)
> I recently purchased the Bach book. The history he gives indicates > that the probable reason Unix originally used swapping instead of > paging, is because the early models of the PDP-11 that they originally > implemented Unix on, did not support paging. I would be very surprised if this were the case. The PDP-11/20 that was the first PDP-11 on which UNIX was implemented (the first *machine* it was implemented on was a PDP-7), and it didn't have an MMU of any sort. The PDP-11/45, which was the second PDP-11 on which UNIX was implemented, did, however, have sufficient support for paging. See John Mashey's article, discussing paging UNIX on a PDP-11/55 (which was an 11/45 with bipolar memory hung off a fast memory bus). That article also cites what is probably the *real* reason UNIX didn't use paging; it added complexity and didn't buy you much at all. Some of the later PDP-11s that UNIX was ported to had an MMU but may or may not have been able to support demand paging; the 11/45's MMU included a register that, by recording changes made to registers by auto-increment and auto-decrement addressing modes, permitted the OS to back up an instruction that faulted in midstream. Other PDP-11s, however, did not; a backup routine that was sufficient to handle the case of faults taken by references past the end of the stack was provided for those machines. I don't think this routine was sufficient to handle *all* the cases of faults taken in midstream, at least not in a machine-independent manner. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
guy%gorodish@Sun.COM (Guy Harris) (10/04/87)
> I believe that certain micro-Vaxen _didn't_ actually have enough support to > handle virtual memory as well as, say, a PDP-11/70. Micro-*VAXen*? As far as I know, the MMU on all VAXes is the same. Did you mean micro-PDP-11s? > Might sound a bit simple, but for all it's greatness, the 68000 and 808[86] > can't handle virtual memory because in the general case, an instruction can > not be restarted. Well, there *are* ways of doing virtual memory without that kind of support; I think both Apollo and Masscomp did it with two 68000s, one of which was halted in mid-bus-cycle when it referenced an invalid page. The other one would then wake up and fetch the page, and let the original one continue its bus cycle when the page had been read in. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
bzs@bu-cs.bu.EDU (Barry Shein) (10/04/87)
From: der Mouse <mouse@mcgill-vision.uucp> >I could live without file protections. (I already do. My login has >uid 0.) Remember, there's more danger to this sort of approach than simply security and file access. For example I remember that in 4.2 the statement (perhaps everywhere else, I haven't tried it): if [ -x foo ] in a shell script would always return true for any file if you were root for some obscure reason. I had written a simple shell script for the students called 'setpriv' which took either 'public' or 'private' and a list of files and did something reasonable with the permission bits. It had to propagate the execute bit and I noticed it behaved strangely under the root acct, this was the cause. I'm sure there are other gotchas lurking, I guess if asked to find some I would at things like mail locks and exclusive access bits that have nothing to do with security per se (in the sense of unauthorized access to data) but more to do with preventing accidents like race conditions. It can be very subtly introduced into a piece of software, such as in my example. -Barry Shein, Boston University
henry@utzoo.UUCP (Henry Spencer) (10/07/87)
> ... Other PDP-11s, however, did not; a backup routine > that was sufficient to handle the case of faults taken by references past the > end of the stack was provided for those machines. I don't think this routine > was sufficient to handle *all* the cases of faults taken in midstream, at > least not in a machine-independent manner. Correct. There were cases that simply could not be handled at all: when the same instruction modified the same register twice, in general one could not tell how many modifications had been done. The compiler largely avoided such instructions, fortunately. Making this work for floating point (another case where registers could get modified repeatedly, since e.g. pushing a double onto the stack required four one-word push operations) had at least the potential of requiring model-specific code; I don't know whether this was ever actually necessary, or whether the processors in question were all sufficiently similar to avoid it. I worked on dumb-MMU 11s and floating- point 11s, but never seriously on a machine that was both. (In case anyone is interested, the way the MMU differences came about was that the 11/45 MMU, the first for the 11 series, was kind of a kitchen-sink design with all sorts of vaguely useful-looking things. For the mid-range 11/40 a bit later, DEC simplified the design by taking out all the things that they had never bothered to use. Unfortunately, some of those things *were* in use by others. They eventually more-or-less fixed this; the 11/44 and [I think] all the 11s that followed it have an MMU that is only a slight subset of the 11/45 one, omitting only a few features that are *truly* more or less useless.) -- PS/2: Yesterday's hardware today. | Henry Spencer @ U of Toronto Zoology OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry
mike@turing.unm.edu.unm.edu (Michael I. Bushnell) (10/12/87)
In article <6488@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: ~In article <819@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: ~>Why do you think DEC developed the Virtual Address Extension (VAX) in the ~>first place? ~ ~To get a larger per-process address space! Perhaps it has something to do with the fact that VAX stands for VAST Address Extension? Or so I was told. Michael I. Bushnell a/k/a Bach II mike@turing.unm.edu {ucbvax,gatech}!unmvax!turing!mike --- Tex SEX! The HOME of WHEELS! The dripping of COFFEE!! Take me to Minnesota but don't EMBARRASS me!! -- Zippy the Pinhead
rbj@icst-cmr.arpa (Root Boy Jim) (10/20/87)
From: Doug Gwyn <gwyn@brl-smoke.arpa> In article <7672@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: >The fork call is going to be awefully expensive, as a copy of the >entire data space of the parent will be made. It need not be; don't copy the pages until a attempt to modify them occurs. Don't even copy them then. Copy only the stack. Why is it that people are are so resistant to the idea of sharing data space? Shared memory for free! It is conceivable (and probable) that this would be a separate system call because this feature is not always wanted. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Alright, you!! Imitate a WOUNDED SEAL pleading for a PARKING SPACE!!