trost@crl.labs.tek.com (Bill Trost) (07/12/89)
In article <1481@ns.network.com> hughs@ns.UUCP (Jim Hughes) writes:
"I would pay for that service (porting to my machine) especially
if the source is still provided. Is that against copyleft?"
Not only is that permissible under the copyleft, it is being actively
encouraged by the FSF. The "GNU manifesto" has something to say on
the issue:
"Meanwhile, the users who know nothing about computers need handholding:
doing things for them which they could easily do themselves but don't know
how.
"Such services could be provided by companies that sell just hand-holding
and repair service. If it is true that users would rather spend money and
get a product with service, they will also be willing to buy the service
having got the product free. The service companies will compete in quality
and price; users will not be tied to any particular one. Meanwhile, those
of us who don't need the service should be able to use the program without
paying for the service."
Michael Tiemann (the author of g++) has been talking about starting a
GNU support company in the spirit described above. And, from the
various comments around this newsgroup, it sounds like finding someone
to get that done _now_ would be no problem.
Bill Trost, Tektronix Laboratories
trost@tekcrl.labs.tek.com / tektronix!tekcrl.labs!trost
(trost@reed.bitnet, but probably tektronix!reed!trost)benson@odi.com (Benson I. Margulies) (07/14/89)
This message is part if a chain departing rapidly from the charter of this newsgroup. I can't claim the right to the last word, but I can warn people uninterested in FSF politics to type "n" before reading further. This idea about consultants has been part of the FSF manifesto from day one. Selling a program is evil. Charging an arbitrary cost to make a program work (at all or in a particular environment) is fine. Just like blackmail: you pay again and again, but you never get the real negatives. If an FSF product was ever complete and relatively bug-free, the consultants would see their income drop considerably. This produces some curious incentives. For people who aren't building products atop FSF code, it makes the FSF indistinguishable from any other vendor. "Oh, you want a G++ that WORKS? Just sign a blank check for one of our approved consultants, and we'll fix it up in a jiffy." There is no guarantee that these fixes will ever be seen by the rest of the users of the particular item. It the employer of the consultant dosen't distribute their fixed-up copy of the FSF product, they have no obligation to make the fixes available. Consultants have an economic disincentive to see the fixes distributed. The less they spread around, the more times they can sell the same work. So the end user spends the money one way or the other. The notion that only some small subset of the industry "need their hands held" is laughable in general and insulting to many. I imagine that most c++ customers (if not most readers of this list) would be delighted to be able to buy a stable, bug-free binary, so they could get on with their real work. One of the useful (IMO) contributions of Marxist thinkers to the world is to analyze any supposedly policical situation in terms of economics. Who Benefits? In the situation at hand, consultants can make money but others can't. And, of course, FSF approved consultants have an edge over everyone else. Perhaps the first "r" should be removed from the name of the FSF. Benson I. Margulies
jima@hplsla.HP.COM (Jim Adcock) (07/15/89)
>/ hplsla:comp.lang.c++ / trost@crl.labs.tek.com (Bill Trost) / 9:33 am Jul 12, 1989 / >In article <1481@ns.network.com> hughs@ns.UUCP (Jim Hughes) writes: >"I would pay for that service (porting to my machine) especially >if the source is still provided. Is that against copyleft?" > >Not only is that permissible under the copyleft, it is being actively >encouraged by the FSF. The "GNU manifesto" has something to say on >the issue: I believe the only sticker is that neither the person paying for the port can keep the person doing the port from propagating the software, nor can the person doing the port prevent the person paying for the port from propagate the software. These people are even allowed to charge a reasonable fee to propagate the port to other people. They just can't put restrictions on the software preventing the people who recieve it from further propagating it..... This all may well be acceptible, if someone is willing to pay a consultant for the priviledge of being the first with a port to their machine, and if the consultant can keep finding new machines to do ports to [and people will to pay him/her for the priveledge of being the first on their block to have a g++ port]
scs@itivax.iti.org (Steve C. Simmons) (07/15/89)
Gee, I was wondering why all the discussion of FSF politics and copyright had vanished from gnu.gcc. This is where they went. No smiley. -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
jxw@RODS.IUS.CS.CMU.EDU (John Willis) (07/27/89)
After reading several diatribes in this newsgroup against the Free Software Foundation and G++ in particular, I feel compelled to share an alternate viewpoint and experience. For the last 9 months I have been working on a parallelizing compiler written in C++. After starting with AT&T tools, I ended up using GNU tools because in all cases they were more reliable, faster, and had better turn-around on problems than any commercial software I've used in fifteen years of programming. GNU's Flex (Lex upgrade) and Bison (YACC upgrade) are used to support multiple language frontends and parallel parsers including a language which has most of Ada's complexity (VHDL). Most compilations of YACC have tables too small to have any hope of handling the job. Even with early versions of Flex and Bison, there were never any problems which slowed down debugging of my compiler. Flex provides tunable parameters which result in a scanner faster than I am willing to hand-craft. They are grade-A tools. I initially started working with AT&T's C++ translator. It dumped core, produced cryptic diagnostics, or bogus code so often that I was about to dump C++ when I ran across Michael Tiemann's G++ effort. From day one it was an uplifting experience. Although I avoid using features like virtual classes for performance reasons, I have never run into any bugs with G++ that stalled progress or took substantial time to isolate. Even while in Europe, Michael provided updates to the software every 2 to 6 weeks. Little bugs were removed and available QUICKLY. The resulting code generation is excellent. And I have little or no problem rapidly moving the project from one host to another (because of G++, the software is portable to many more machines than I could ever afford to worry about on my own with native tools). This is a single person PhD project. I don't have the time to play games with tools that don't work, take a lot of hand-holding, or translate into a game of prepetual telephone-tag with technical support. I want to finish this degree and be able to use (and share) the resulting VHDL compiler and simulator. Even at the old prices AT&T was asking for their translator, I was puzzled why anyone would not use the GNU tools. Now, with the proposed quantum increase in price, I can't see a good technical reason for not trying GNU and G++. Are those steering you away from GNU and GNU tools actually speaking out of experience? If so, how do they get anything done with the average commercial software? Try GNU and G++ yourself! If you like what you see, do yourself and your profession a favour by supporting the GNU project. -John
peterd@june.cs.washington.edu (Peter C. Damron) (07/29/89)
In article <5670@pt.cs.cmu.edu>, jxw@RODS.IUS.CS.CMU.EDU (John Willis) writes: > I initially started working with AT&T's C++ translator. It dumped core, > produced cryptic diagnostics, or bogus code so often ... I have been using AT&T's C++ translator for about a year now. It has never dumped core or produced bogus code. The diagnostics are better than the usual C compiler diagnostics, and have always pointed me right at the problem. You do not say which version of the C++ compiler you were using. I am using version 1.2.1 of cfront. > ... Michael Tiemann's G++ effort. ... > I have never run into any bugs > with G++ that stalled progress or took substantial time to isolate. Even > while in Europe, Michael provided updates to the software every 2 to 6 > weeks. Little bugs were removed and available QUICKLY. Ahh, but there were bugs. I have not had to deal with bugs at all. > This is a single person PhD project. ... So is my project. I cannot afford to waste time debugging a compiler I depend on. > ... I can't see a good technical reason for not > trying GNU and G++. Are those steering you away from GNU and GNU tools > actually speaking out of experience? ... > > -John The only technical reason for not using G++ seems to be those bugs. There are also political reasons for not using GNU software. I do not mean to say that the AT&T C++ compiler has no bugs, just that I have not run accross any. I also do not mean to endorse C++ as a language, but that's another topic. Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (07/29/89)
re: bugs in AT&T C++ vs. bugs in G++ I've used both (cfront 1.2.1, g++ various versions). Except for a brief period of bugs, G++ has consistently been less buggy. Furthermore, updates are frequent and bugs *do* get fixed. Our version of cfront still doesn't complain if you delete an instance of a class you haven't seen the definition for (bad hole: what if the class defined delete?) + Try using more than 9 arguments to ``form'' in cfront. + Try having a class contain an instance of a class using a destructor. + Try using inlines for non-trivial functions, like spinlocks + Try getting cfront to accept a gnu format ``asm'' so you can try to do spinlocks inline. ....and then, try to get a `cfront' program debugged. The fusion of GDB and G++ make it significantly better than cfront. -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)