From owner-freebsd-questions@FreeBSD.ORG Fri Jun 22 11:05:03 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AAE1106566B for ; Fri, 22 Jun 2012 11:05:03 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id ED0188FC08 for ; Fri, 22 Jun 2012 11:05:02 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q5MB5DNS041174 for freebsd-questions@freebsd.org; Fri, 22 Jun 2012 06:05:13 -0500 (CDT) Date: Fri, 22 Jun 2012 06:05:13 -0500 (CDT) From: Robert Bonomi Message-Id: <201206221105.q5MB5DNS041174@mail.r-bonomi.com> To: freebsd-questions@freebsd.org In-Reply-To: Subject: Re: Why Clang X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 11:05:03 -0000 > From owner-freebsd-questions@freebsd.org Thu Jun 21 06:07:49 2012 > Date: Thu, 21 Jun 2012 13:06:12 +0200 (CEST) > From: Wojciech Puchar > To: Michel Talon > Cc: FreeBSD Questions , kpneal@pobox.com > Subject: Re: Why Clang > > > for commercial sponsors of FreeBSD, it has zero bearing on FreeBSD itself. If FreeBSD appears > > as a subsidiary of some commercial company (say Juniper) i am not sure this will be good > > I think any project that size is actually a subsidiary and must be. Which simply proves you don't know what you don't know. > I just don't like that it isn't stated openly! No one on the Project would consider lying about such things, "just to make Wojciech happy." > instead of personal attacks, messing with my (and others) sentences and > posting evident lies just to "explain" the decision. Maybe when you stop lying about what the others say. > It is a difference between honest people and fools. You have made it clear that -you- are a name-calling fool. People have tried to explain, clearly, and politely, the *multiple* factors that went into the decision. You ignore everything else, and fixate on the one that seems specious to you. > There is nothing to prevent giving source with system. Non-Free software > doesn't have to be binary only. Nice strawman. But you cannot show where anybody has claimed it did. > For paying this i would like FreeBSD to be maintained with quality and > performance being the only reason, not politics. A demonstrable lie -- the only thing you care about is speed of execution. > Nothing against Juniper (the make truly good working hardware), but if > they enforce decision because of their personal likes then it must be > stopped. Therefore, _your_ attempts to enforce decisions because of your personal likes must be stopped. > GPLv3 based C compiler does not prevent making closed source software like > JunOS for example. You don't _know_ that. It is only your -opinion-. How much of a financial bond are you willing to put up, payable to, say, Juniper, if they "rely" on your _opinion_, and it turns out to be wrong?` > It is only "i hate GNU" type decision. You lie. > I hate too, and in spite of this am against removing gcc and replacing it > with much worse product. Your closed--mind bias is showing. You think it's ok to get _wrong_ answers rather than correct answers, if you get the wrong answeers faster and the correct answers somewhat slower. GCC, even 4.21., is well known for generating "bad code" -- meaning 'logically incorrect and gives wrong answers', and sometimes 'code that cannot be successfully executed' -- e.g. it always segfaults or has some other fatal exception -- under a number of conditions. The variety of such instances increases with vritually -every- minor "upgrade' to the compiler. Code that worked under minor release 'x', not work under x+1, because 'yet another' of these 'features' crept in.. There are "known bugs" of this sort in GCC that have been identified for over a -decade-. But, the GCC source-code is such a swamp that *nobody* has been able to figure out, or find, *where* the problem is occurring -- let alone determine what needs to be changed, to fix it.