From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Emacs vista build failures Date: Tue, 15 Jul 2008 01:28:19 -0700 Message-ID: <487C5FA3.4070603@emf.net> References: <36366a980807101702r5677d096g8e62ef5b3e278868@mail.gmail.com> <4eb0089f0807111217m66d6cf4el777c197c107ce034@mail.gmail.com> <87skug6tq5.fsf@catnip.gol.com> <4eb0089f0807111345h13eccdds9b2cf43370b94074@mail.gmail.com> <4eb0089f0807121340x5e26f6dbve03ef50b238f3a3a@mail.gmail.com> <87k5fph5rh.fsf@stupidchicken.com> <20080713214648.GB1076@muc.de> <20080714195651.GF3445@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1216107653 20955 80.91.229.12 (15 Jul 2008 07:40:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Jul 2008 07:40:53 +0000 (UTC) Cc: drobinow@gmail.com, Richard M Stallman , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 15 09:41:40 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KIfAH-0002oh-J6 for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2008 09:41:38 +0200 Original-Received: from localhost ([127.0.0.1]:43906 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIf9P-00045J-Bm for ged-emacs-devel@m.gmane.org; Tue, 15 Jul 2008 03:40:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KIf9K-00044M-9V for emacs-devel@gnu.org; Tue, 15 Jul 2008 03:40:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KIf9G-00042G-Dw for emacs-devel@gnu.org; Tue, 15 Jul 2008 03:40:37 -0400 Original-Received: from [199.232.76.173] (port=36033 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIf9G-00042D-9r for emacs-devel@gnu.org; Tue, 15 Jul 2008 03:40:34 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:45174) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KIf99-0008Fl-JG; Tue, 15 Jul 2008 03:40:28 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KIf97-0003yI-Kj; Tue, 15 Jul 2008 03:40:26 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.114.9] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 35000675; Tue, 15 Jul 2008 00:40:18 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <20080714195651.GF3445@muc.de> X-detected-kernel: by mx20.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:100723 Archived-At: re much discussion around the general theme of: Alan Mackenzie wrote: > 'Evening, Richard! > > On Mon, Jul 14, 2008 at 01:38:28PM -0400, Richard M Stallman wrote: > >> Richard, you're perhaps the brightest guy around, here. How long >> did it take you to get your first GNU/Linux installation installed >> and _fully_ working (i.e. all peripherals, networking, X-Windows, >> email, web-browsing, .... all satisfactory)? All of user-space needs to be done over. The root problem with install difficulties, network config difficulties, and divergent opinions about how to lay out an emacs install is simply that unix user space and unix "best" practices for source management haven't much improved for almost two decades. People are using tools closely related to those meant to manage *one* or *fifteen* of 100,000 unix installs (way back when) to now manage 100s of millions of installs, often enough 10s of millions at a time. Nobody has successfully bothered to revisit the fundamentals. The GNU project as originally conceived by some close to it involved fairly radical surgery to rationalize the "complete system" source tree and to rationalize user-space by homogenizing around a lispish approach. For example, what should a default "load path" be? Well, that's not just an Emacs question -- it's generic for many apps (e.g., a C compiler). It merits a generic solution which is then adopted as a coding / configuration / & source management standard. It is a failure of the GNU project and of the free software movement that there is so much emphasis on monolithic distributions and binary package distributions. It is a failure of the GNU project and the free software movement that one so often encounters distros that offer to not install source trees and even offer to not install development environments. These developments systematically and by design deprive users of incentive to actually *exercise* their software freedom as individuals. These developments encourage a *de facto* (even if not licensing-based) ceding of software freedom to distribution projects like Debian or any of the commercial distros. It is a failure of the GNU project and the free software movement that there is such a large technical gap between "upstream" projects and installed systems that massive "distribution projects" (commercial or Debian) need to exist in between. *Vetting services* should exist between upstream and end-users -- not "distribution vendors". Vetting services should be in the business of publishing links to source and checksums, not binaries. The most important thing in such a large effort as a complete system is the standards: standards for coding, for documentation, for source code management, for configuration, build, install, patching and rebuild/reinstall, and uninstall. Have you noticed that these are exactly the weak areas that cause nearly all of the friction people are kvetching about in this thread? (Some HW vendors keep secrets and that amplifies the problem -- but they are not the root of the problem.) Yes, some binaries are needed to bootstrap from a raw box running a (hopefully free) BIOS but those should be minimal -- not the state we see today where you pick your distro. *My* mentor, 20 years ago, was having fun debating with his peers whether the number of programs a set of bootstrap binaries required for a complete unix was closer 10 or closer to 20. Let's see, you'd want /bin/sh, for sure. and /usr/bin/cc. There's "awk" and "make" but maybe there's a sweeter spot that slices that a bit differently..... And in that view a "package" was a version controlled source bundle with facilities for patching and a very clean, flexible, configure/build/install procedure that was *standardized*. Not at the anemic level of the "GNU Coding Standards" -- but, rather, usefully standardized. Where today we have factional camps around RPM and other package systems -- those shouldn't be afterthought. Where we have "autoconf" and friends -- those should be central, not the obscure, resented power-grab of a few. Instead, we neglected all that grunt work and thus gave rise to Debian and all of the commercial vendors and all of the problems those "mid-stream" players create as they dominate the entire economics of our efforts to create software freedom. So, now, as a result: we've "succeeded" to the extent that most GNU/Linux users don't possess most of the source for what they run; can't rebuild from source; are "locked in" to one distribution vendor or another -- like RMS hisself, apparently. And all needlessly so because we failed to put forward good standards for source code management for a couple of decades. It's amazing, pathetic, and embarrassing to be associated with. -t