From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-30054325" Mime-Version: 1.0 (Apple Message framework v1082) From: "Gary V. Vaughan" In-Reply-To: <465c929faaa98f1a87f669d26a1549d4@plug.quanstro.net> Date: Sun, 14 Nov 2010 15:13:03 +0700 Content-Transfer-Encoding: 7bit Message-Id: References: <703b2539-027e-4f9f-a739-00b59f6d3d82@v28g2000vbb.googlegroups.com> <20101113192425.GC22589@nibiru.local> <284949CC-81F5-4791-91C1-13357BC23E7D@9srv.net> <465c929faaa98f1a87f669d26a1549d4@plug.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Plan9 development Topicbox-Message-UUID: 7d1acc9e-ead6-11e9-9d60-3106f5b1d025 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-30054325 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Erik et. al, Thanks for the feedback, all. On 14 Nov 2010, at 13:24, erik quanstrom wrote: >> You may well be right that there's too much momentum behind >> autoconf/automake to change GNU. But that doesn't mean it's the = right >> thing to do, or something sensible people ought to choose to >> participate in. >=20 > to be a bit more blunt, the argument that the tyrrany of the > auto* is unstoppable and will persist for all time is persuasive. Well, I wouldn't take it quite as far as that. My point is really that there is already a vast amount of (often good) software written by (often skilled) programmers who have invested a huge amount of time and energy into the existing eco-system, and (quite reasonably) want to enjoy the advantages of installing and utilising dynamic shared objects. I doubt that anyone would argue for a full static copy of the C runtime in every binary, and between there and making every code library a runtime linkable shared library is just a matter of degrees. Since you really need to solve the shared compilation unit problem at the lowest level anyway, you might as well expose it to at least the next few = layers in the application stack at least. > so i choose at this point to get off the gnu train and do something > that affords more time for solving problems, rather than baby > sitting tools (that baby sit tools)+. i believe "no" is a reasoned = answer, > when faced with an argument that takes the form of "everybody's > doing it, and you can't stop it". i suppose everybody has had that = ex-boss. I would be the last person to sing the praises of the existing GNU build system, and I hope the fact that I lurk on this list shows that I like to hang around smart people in the hope of picking up some good ideas. However, I don't really have the time to write the next big=20 build system that solves all of the growing pains of the GNU eco-system, and I'm almost entirely certain that even if I did... my efforts would go almost entirely unnoticed. Similarly, I don't have the luxury of letting the train leave the station without me, unless I first have another way of earning a living - and neither would I want to, I consider myself blessed that I can earn my living by being involved in, (and to a very small extent help to steer a proportion of) the Free Software community. On the other hand, I think that there must be room for incremental improvements to the incumbent GNU build system, but I doubt that I would see them right away when I'm so close to development of what is already in fashion. My ears pricked up when I saw someone claim that GNU Libtool is insane, because I'm interested to hear where the insanity lurks, and maybe even gain some insight into what the cure is. Not only that, I have the rare opportunity of being able to push the GNU build system forward if anyone can help me to understand where the bad design decisions were made. > i also think it's reasonable, as anthony points out, just to avoid = shared > libraries, if that's the pain point. :-o For an embedded system I would agree, up to a point. But when I'm trying to support hundreds of users each running dozens of simultaneous binaries, then forcing each binary to keep it's own copy of whatever = version of each library (and it's dependent libraries) were around at link time in memory simultaneously surely can't be the best solution? Or even a reasonable solution. I'm not even sure that statically relinking = everything on the system (actually 30 different architectures in my own case) each time a low-level library revs so that the OS memory management can = optimise away all those duplicate libraries is a reasonable solution. > sure, one can point out various > intracacies of bootstrapping gnu c. but i think that's missing the > point that the plan 9 community is making. many of these wounds > are self-inflicted, and if side-stepping them gets you to a solution = faster, > then please side step them. there's no credit for picking a scab. I have no doubt that the plan 9 community is doing something good for the future development of operating systems and software, but that = doesn't solve anything for my customers who want to run Gnome, KDE and Emacs on their AIX, Solaris and HP-UX systems. I still have to build that = software for them to make a living... and GNU Libtool makes my life immeasurably easier. I know this because porting an application written by a GNU build system using developer who only ever builds and tests on Mac OS usually takes much less than a day, and often no more than an hour to pass it's testsuite on all the platforms our customers care about. The packages that use cmake and scons and all the other "portable" build systems rarely take me less than a week and often somewhat longer to = port to systems the developer hadn't considered... to the point where = nowadays, it's easier to port all but the very largest software packages to the = GNU build system first. I'm still waiting to hear someone who can make a convincing argument = that GNU Libtool is not the least bad solution to the problems it wants to help developers solve. > please do take a look at plan9ports. it's portable across cpu type and > os without fanfare, or even much code. plan 9 is similar, but much > simpler, since it doesn't need to fend off the os. I have looked at length already, although upgrading to VMWare 4 last = year killed my Plan 9 VMs, and I didn't yet have the time to try to get them running again yet. Cheers, --=20 Gary V. Vaughan (gary@gnu.org)= --Apple-Mail-1-30054325 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkzfmg8ACgkQFRMICSmD1garRACgqFryLfO9gUkzU9wL/FVBJM0i LJYAn0lV0xud/IE9qkqQO2W7KM1/8zef =Y6s2 -----END PGP SIGNATURE----- --Apple-Mail-1-30054325--