From: Jacob Todd <jaketodd422@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Plan9 development
Date: Sun, 14 Nov 2010 10:56:35 -0500 [thread overview]
Message-ID: <AANLkTimvK1DgikX6LQ_-LY7s99XZn2Mit7KQ_tk=VnEU@mail.gmail.com> (raw)
In-Reply-To: <A14A2743-F4E7-49B8-A5FB-7B9FC36FCAA5@vaughan.pe>
[-- Attachment #1: Type: text/plain, Size: 6022 bytes --]
The full standard c library isn't included in a statically linked
executable. Only what's needed is, at least on plan 9, i have no idea what
gcc does.
On Nov 14, 2010 3:14 AM, "Gary V. Vaughan" <gary@vaughan.pe> wrote:
> 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.
>>
>> 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
> 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,
> --
> Gary V. Vaughan (gary@gnu.org)
[-- Attachment #2: Type: text/html, Size: 7001 bytes --]
next prev parent reply other threads:[~2010-11-14 15:56 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-04 9:36 Admiral Fukov
2010-11-04 9:47 ` Lucio De Re
2010-11-04 10:20 ` Steve Simon
2010-11-04 11:30 ` Brantley Coile
2010-11-04 15:39 ` David Leimbach
2010-11-04 15:55 ` Stanley Lieber
2010-11-04 16:01 ` John Floren
2010-11-04 16:39 ` ron minnich
2010-11-04 16:57 ` Stanley Lieber
2010-11-04 17:01 ` Don Bailey
2010-11-04 17:19 ` Jeff Sickel
2010-11-04 22:20 ` Charles Forsyth
2010-11-05 1:41 ` Venkatesh Srinivas
2010-11-05 3:50 ` Bruce Ellis
2010-11-05 7:11 ` Lucio De Re
2010-11-05 7:55 ` Bruce Ellis
2010-11-05 13:31 ` Eric Van Hensbergen
2010-11-05 15:16 ` C H Forsyth
2010-11-05 17:07 ` dexen deVries
2010-11-05 17:18 ` Nick LaForge
2010-11-05 17:32 ` dexen deVries
2010-11-05 17:39 ` andrey mirtchovski
2010-11-05 17:55 ` dexen deVries
2010-11-05 17:45 ` David Leimbach
2010-11-05 18:14 ` erik quanstrom
2010-11-05 18:37 ` roger peppe
2010-11-05 19:06 ` erik quanstrom
2010-11-08 11:04 ` roger peppe
2010-11-08 21:24 ` Bruce Ellis
2010-11-08 22:22 ` Charles Forsyth
2010-11-08 22:25 ` Bruce Ellis
2010-11-08 22:33 ` Charles Forsyth
2010-11-09 2:10 ` Jeff Sickel
2010-11-09 3:18 ` EBo
2010-11-09 8:10 ` Bruce Ellis
2010-11-13 19:15 ` Enrico Weigelt
2010-11-05 20:37 ` Eric Van Hensbergen
2010-11-06 0:55 ` Charles Forsyth
2010-11-06 2:20 ` Bruce Ellis
2010-11-06 20:24 ` dexen deVries
2010-11-05 18:43 ` Bakul Shah
2010-11-13 19:24 ` Enrico Weigelt
2010-11-14 2:17 ` Gary V. Vaughan
2010-11-14 5:47 ` Anthony Sorace
2010-11-14 6:24 ` erik quanstrom
2010-11-14 8:13 ` Gary V. Vaughan
2010-11-14 15:56 ` Jacob Todd [this message]
2010-11-14 16:24 ` ron minnich
2010-11-14 6:26 ` Russ Cox
2010-11-14 8:03 ` Anthony Sorace
2010-11-14 15:23 ` erik quanstrom
2010-11-14 17:46 ` Russ Cox
2010-11-14 22:16 ` erik quanstrom
2010-11-14 9:10 ` tlaronde
2010-11-14 9:32 ` Gary V. Vaughan
2010-11-14 10:22 ` tlaronde
2010-11-14 10:50 ` Carl-Daniel Hailfinger
2010-11-14 11:47 ` tlaronde
2010-11-14 21:44 ` Charles Forsyth
2010-11-14 21:47 ` Ori Bernstein
2010-11-18 5:30 ` Joel C. Salomon
2010-11-18 5:57 ` erik quanstrom
2010-11-18 22:50 ` Federico G. Benavento
2010-11-19 2:06 ` Joel C. Salomon
2010-11-19 3:13 ` Federico G. Benavento
2010-11-25 9:39 ` Greg Comeau
2010-11-15 4:29 ` Gary V. Vaughan
2010-11-15 5:05 ` Carl-Daniel Hailfinger
2010-11-15 15:48 ` Dan Cross
2010-11-15 16:24 ` Lucio De Re
2010-11-15 17:26 ` Brian L. Stuart
2010-11-16 3:32 ` lucio
2010-11-16 4:53 ` erik quanstrom
2010-11-16 5:09 ` lucio
2010-11-16 22:18 ` Christopher Nielsen
2010-11-15 18:11 ` Dave Eckhardt
2010-11-15 20:04 ` Steve Simon
[not found] ` <79E9F966-3C4E-44D9-8B1F-D22C9548CE74@gnu.org>
2010-11-15 1:02 ` Enrico Weigelt
2010-11-15 4:17 ` Gary V. Vaughan
2010-11-15 16:22 ` erik quanstrom
2010-11-17 23:48 ` Enrico Weigelt
2010-11-04 16:00 ` erik quanstrom
2010-11-04 17:12 ` Admiral Fukov
2010-11-04 17:19 ` andrey mirtchovski
2010-11-04 17:30 ` Admiral Fukov
2010-11-04 20:27 ` David Leimbach
2010-11-04 12:15 dexen deVries
2010-11-04 12:48 ` Venkatesh Srinivas
2010-11-04 17:14 ` Admiral Fukov
2010-11-17 7:38 Pavel Zholkover
2010-11-17 7:44 ` Lucio De Re
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTimvK1DgikX6LQ_-LY7s99XZn2Mit7KQ_tk=VnEU@mail.gmail.com' \
--to=jaketodd422@gmail.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).