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!dhesikempf@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
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.BITNETkyle@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.
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.BITNETmsf@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
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
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
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
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)
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
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?
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