home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / gnu / misc / discuss / 4645 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  2.9 KB
  1. Path: sparky!uunet!mcsun!ub4b!alcbel!se.alcbel!btma74.nohost.nodomain!cgra
  2. From: cgra@btma74.nohost.nodomain (Chris Gray)
  3. Newsgroups: gnu.misc.discuss
  4. Subject: Re: harmful effects of gnu software
  5. Message-ID: <1450@se.alcbel.be>
  6. Date: 25 Jan 93 09:23:43 GMT
  7. References: <H.eg.PBnsFDbblsM@jonh.wimsey.bc.ca> <1993Jan19.152054.29805@klaava.Helsinki.FI> <H.eg.sISqCqbnpuk@jonh.wimsey.bc.ca> <1993Jan22.222424.24191@klaava.Helsinki.FI>
  8. Sender: guest@se.alcbel.be
  9. Reply-To: cgra@se.alcbel.be
  10. Distribution: gnu
  11. Lines: 47
  12. Nntp-Posting-Host: btmw58
  13.  
  14.  
  15.  
  16. In article <1993Jan22.222424.24191@klaava.Helsinki.FI>, lukka@klaava.Helsinki.FI (Tuomas J Lukka) writes:
  17.  
  18. >... Gcc is slow in compilation 
  19. > (especially on a machine like mine at home), but still, it's free...
  20. > why not be satisfied? This attitude is very dangerous, it leads into 
  21. > accepting much lower quality software, because of the concentrated 
  22. > effort. GNU has several people working on this stuff, why would I
  23. > want to do anything about it, even though I knew how to? 
  24.  
  25. Well I haven't quite got hold of g++ yet (didn't fill in the cheque properly :(
  26. OK, Bjarne, email on its way), but I can imagine that it'll run pretty slow
  27. on my Atari ST. And will probably fill most of my 4 MB of RAM.
  28.  
  29. I can live with this, or upgrade my machine, or ... well I do have the source
  30. code, don't I? I would be very surprised to find that g++ was already optim-
  31. ised for speed or space, written as it is for the Un*x make-believe world
  32. where memory is infinite and CPU cycles plentiful (see under "VM considered
  33. harmful", etc :)). I would be prepared to bet, um, a copy of Llamatron :>
  34. that the contraption could be made smaller and faster without compromising
  35. correctness or functionality. Not because the gnu programmers aren't the best
  36. in the world, but because the general tool is never as efficient as the specific.
  37.  
  38. This could make me very popular in the ST world, tho' not necessarily very
  39. rich - I can try and add value in the form of support (for those switches I
  40. added :>), but I can't stop "my" STg++ from joining the pool of "`free'"
  41. software on the bulletin boards etc..
  42.  
  43. BTW on comp.os.minix or whatever (yes I've been looking at minix too) there
  44. has recently been some lively discussion og g++ vs. the Amsterdam Compiler
  45. Kit (commercial). "Why pay $200 when g++ is free", "g++ won't run on my 286",
  46. "g++ is slow", "ACK is buggy",... seeming to confirm that gnu doesn't lock
  47. out other software, but does serve as a baseline.
  48.  
  49. > Just look at Gnu Emacs... several megabytes of an EDITOR in memory.
  50.  
  51. Emacs an EDITOR???
  52.  
  53. >    TJL
  54.  
  55.  
  56. __________________________________________________________________________
  57. Chris Gray        | Any views expressed are those of the author and not of 
  58. cgra@se.alcbel.be | Alcatel Bell, Technology Project Services, the British
  59. Compu$erve:       | Computer Society, Whale and Dolphin Conservation Soc.,
  60. 100065.2102       | Scottish Youth Hostels Association, etc. etc. etc.
  61.