Juan M. Mendez wrote:
> On 02/02/2008, Martin Neubauer wrote:
>> * Uriel (uriel99@gmail.com) wrote:
>>> Autotools badness is way beyond most peoples wildest imagination...
>> Unfortunately, you don't have to imagine.
>
> So what are the facts to back up so many posts regarding autotools badness?
> Just curious.

An alternative interpretation is that the facts are skewed by the Bell
Labs reality distortion field. The syllogism goes something like this:

All things not made at Bell Labs are bad
GNU is not made at Bell Labs
Therefore, GNU is bad

> An alternative interpretation is that the facts are skewed by the Bell
> Labs reality distortion field. The syllogism goes something like this:
>
> All things not made at Bell Labs are bad
> GNU is not made at Bell Labs
> Therefore, GNU is bad
>

If you think about what the letters of GNU stand for, you might appreciate
that the forms are in mutual opposition. They provide completely different
approaches to software. "Good" and "Bad" are value judgments. If
you think GNU is the right way to build things, Plan 9 is probably not
for you, and vice versa.

-rob

Except that Bell Labs has shown much more appreciation for things
invented outside than anyone else. Some of the best ideas in Unix were
lifted from Multics, the genius was to drop all the cruft. CSP is
another good example, ignored by a world that thinks pthreads is the
only way to write concurrent applications... and there are many other
examples that anyone that has done even the most cursory reading of
the Plan 9 will already know about.

Now, can you point to *anything* gnu has ever produced that is not at
best a hideously grotesque copy of something that might have made
sense thirty years ago.

uriel

P.S.: Sorry for being so easily trolled, but seems that I'm not the only one

On Feb 3, 2008 2:17 AM, Robert William Fuller wrote:
>
> Juan M. Mendez wrote:
> > On 02/02/2008, Martin Neubauer wrote:
> >> * Uriel (uriel99@gmail.com) wrote:
> >>> Autotools badness is way beyond most peoples wildest imagination...
> >> Unfortunately, you don't have to imagine.
> >
> > So what are the facts to back up so many posts regarding autotools badness?
> > Just curious.
>
> An alternative interpretation is that the facts are skewed by the Bell
> Labs reality distortion field. The syllogism goes something like this:
>
> All things not made at Bell Labs are bad
> GNU is not made at Bell Labs
> Therefore, GNU is bad
>

> An alternative interpretation is that the facts are skewed by the Bell
> Labs reality distortion field. The syllogism goes something like this:
>
> All things not made at Bell Labs are bad
> GNU is not made at Bell Labs
> Therefore, GNU is bad

if this holds, then

plan 9 uses ip, smtp, dns, ntp, ethernet, x86, &c.
these were not invented at bell labs
thus using plan 9 is bad.

- erik

Circular cause and consequence is funny. Let me add to this list:
- jpg
- png
- tiff
- PostScript
- TeX (tpic)
- HTML
- Mahjongg, sokoban, sudoku, tetris (games/4s)
- SPARC, MIPS, x64
- MP3, PCM, OGG (PAC was made at Bell Labs)
- SoundBlaster 16

Let me put it this way:
GNU software is good, except for GNU development tools, which,
except for the gcc program itself, are mediocre and break
compatibility (try using a Bell Labs makefile with GNU make).

On Feb 2, 2008, at 8:42 PM, erik quanstrom wrote:

>> An alternative interpretation is that the facts are skewed by the
>> Bell
>> Labs reality distortion field. The syllogism goes something like
>> this:
>>
>> All things not made at Bell Labs are bad
>> GNU is not made at Bell Labs
>> Therefore, GNU is bad
>
> if this holds, then
>
> plan 9 uses ip, smtp, dns, ntp, ethernet, x86, &c.
> these were not invented at bell labs
> thus using plan 9 is bad.
>
> - erik

>> An alternative interpretation is that the facts are skewed by the Bell
>> Labs reality distortion field. The syllogism goes something like this:
>>
>> All things not made at Bell Labs are bad
>> GNU is not made at Bell Labs
>> Therefore, GNU is bad
>
> if this holds, then
>
> plan 9 uses ip, smtp, dns, ntp, ethernet, x86, &c.
> these were not invented at bell labs
> thus using plan 9 is bad.
>
> - erik

I don't know that x86 qualifies as non-bad.

John

On Sun, 03 Feb 2008 00:30:38 -0000, Rob Pike wrote:

>> An alternative interpretation is that the facts are skewed by the Bell
>> Labs reality distortion field. The syllogism goes something like this:
>>
>> All things not made at Bell Labs are bad
>> GNU is not made at Bell Labs
>> Therefore, GNU is bad
>>
>
> If you think about what the letters of GNU stand for, you might
> appreciate
> that the forms are in mutual opposition. They provide completely
> different
> approaches to software. "Good" and "Bad" are value judgments. If
> you think GNU is the right way to build things, Plan 9 is probably not
> for you, and vice versa.
>
> -rob

Is that "the" Rob Pike? "The R?"

If so, please accept me humble reverence, sire! Hallowed be thy practice
(of programming)!

P. S. Down here in my country, Iran, we have this tradition of inventing
sacred things out of thin air. A considerable proportion of "the divine
and the sacred" spilled all over the globe began with that frailty of ours
:-D

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Hmmm, my question was not about new ideological war "GNU vs Plan9". ))
I think that my bad English does not allow me to ask my question in
correct form, so i will show some sample

For example, in Linux i have some big application.
This application using autotools, so if a want to port it, for example
on different OS (of course if this OS has autotools) or hardware all i
need is go throw sources and put something like:
#ifdef RUN_IN_CYGWIN
// some specific code
#endif
After that i need to add extra tests in configure and autotools will
do all magic for me
The main trouble is that all sources has really many pieces of #ifdef
code, so it could be very painful to drop out "portability in GNU
way". But it's ok, until that is a only way.

Ok, for me "porting" to plan9 looks like:
1. Drop out autotools from project
2. Replace all OS specific code to Plan9 equivalent
3. Replace all libs to it's equivalent for plan9
4. and so on

Main trouble in 1 step. Because after that i couldn't post in project
mail list, "Hey gays, i have create Plan9 port of your application,
please check it out and put in CVS trunk". If i "port" some
application in that way, that mean that I've start new one, "from
scratch" and just copy & paste some code from original project (

I hope that i have logical mistakes in my example, and you show me
that, because if not it could be very sad )



2008/2/3, Eris Discordia :
> On Sun, 03 Feb 2008 00:30:38 -0000, Rob Pike wrote:
>
> >> An alternative interpretation is that the facts are skewed by the Bell
> >> Labs reality distortion field. The syllogism goes something like this:
> >>
> >> All things not made at Bell Labs are bad
> >> GNU is not made at Bell Labs
> >> Therefore, GNU is bad
> >>
> >
> > If you think about what the letters of GNU stand for, you might
> > appreciate
> > that the forms are in mutual opposition. They provide completely
> > different
> > approaches to software. "Good" and "Bad" are value judgments. If
> > you think GNU is the right way to build things, Plan 9 is probably not
> > for you, and vice versa.
> >
> > -rob
>
> Is that "the" Rob Pike? "The R?"
>
> If so, please accept me humble reverence, sire! Hallowed be thy practice
> (of programming)!
>
> P. S. Down here in my country, Iran, we have this tradition of inventing
> sacred things out of thin air. A considerable proportion of "the divine
> and the sacred" spilled all over the globe began with that frailty of ours
> :-D
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>

> Main trouble in 1 step. Because after that i couldn't post in project
> mail list, "Hey gays, i have create Plan9 port of your application,
> please check it out and put in CVS trunk".

There's no cure for this. The touted portability of the autotools is
restricted to the GNU environment and the moment you step outside of
it, this is what occurs. It's a philosophy that has turned into a
religion largely by losing its focus or, if you prefer, shifting its
objective.

Plan 9 becomes the proof thereof, if autotools were as successful as
claimed, it ought to be trivial to port them to a different platform.
It isn't, nor is it necessary. In porting the code for libtiff and
geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools,
png, gd and eventually libtiff and geotiff. The sum total of these
mkfiles is probably less than two thousand lines. But it is
impossible to feed these back to the developers, because they do not
fit into their philosophical scheme.

As another example, check out graphviz. From version 1 to version 2
(I think) they moved from a custom configurator to the autotools.
Beside totally losing Plan 9 portability in the bargain, it is my
impression that they spent more effort on the autotools details than
in improving graphviz itself.

++L

Thanks, this is very similar to my thoughts.

So if i want port some big linux application to Plan9 i need start new
project and copy parts of code from original one. From one side it is
sad, because it's very ugly development model (for example if original
project will be update, i need update my project too, so there are two
"targets" for every update). On another hand i could concentrate on
new Pla9 techniques and create more powerful analogous of linux
software.

thanks for replies )

2008/2/3, lucio@proxima.alt.za :
> > Main trouble in 1 step. Because after that i couldn't post in project
> > mail list, "Hey gays, i have create Plan9 port of your application,
> > please check it out and put in CVS trunk".
>
> There's no cure for this. The touted portability of the autotools is
> restricted to the GNU environment and the moment you step outside of
> it, this is what occurs. It's a philosophy that has turned into a
> religion largely by losing its focus or, if you prefer, shifting its
> objective.
>
> Plan 9 becomes the proof thereof, if autotools were as successful as
> claimed, it ought to be trivial to port them to a different platform.
> It isn't, nor is it necessary. In porting the code for libtiff and
> geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools,
> png, gd and eventually libtiff and geotiff. The sum total of these
> mkfiles is probably less than two thousand lines. But it is
> impossible to feed these back to the developers, because they do not
> fit into their philosophical scheme.
>
> As another example, check out graphviz. From version 1 to version 2
> (I think) they moved from a custom configurator to the autotools.
> Beside totally losing Plan 9 portability in the bargain, it is my
> impression that they spent more effort on the autotools details than
> in improving graphviz itself.
>
> ++L
>
>

> So if i want port some big linux application to Plan9 i need start new
> project and copy parts of code from original one. From one side it is
> sad, because it's very ugly development model (for example if original
> project will be update, i need update my project too, so there are two
> "targets" for every update). On another hand i could concentrate on
> new Pla9 techniques and create more powerful analogous of linux
> software.

Eventually, you'd think the autotools will fade, but reality sometimes
turns out illogical. I think the "Plan 9 Way" will only become
dominant if there is a major change to the present status.

Strangely, no one criticises the Windows development tools...

++L

> Strangely, no one criticises the Windows development tools...
I do, it's horrible and even more, i just don't know such words on
English, to describe all my feelings about windows build system )))

Perhaps i do not known it very well, but i have some experience of
development under windows, and that experience told me do not do such
mistake (development under windows) once again ))

2008/2/3, lucio@proxima.alt.za :
> > So if i want port some big linux application to Plan9 i need start new
> > project and copy parts of code from original one. From one side it is
> > sad, because it's very ugly development model (for example if original
> > project will be update, i need update my project too, so there are two
> > "targets" for every update). On another hand i could concentrate on
> > new Pla9 techniques and create more powerful analogous of linux
> > software.
>
> Eventually, you'd think the autotools will fade, but reality sometimes
> turns out illogical. I think the "Plan 9 Way" will only become
> dominant if there is a major change to the present status.
>
> Strangely, no one criticises the Windows development tools...
>
> ++L
>
>

You don't need to do all that if you know what libraries your program
depends on. Libraries like pdcurses, libtiff, zlib, etc. have been
ported to APE, so once you have them installed, all you need to do is
run the configure file and then make from within ape/psh. However, if
you need autoconf/automake before a configure file, you're out of luck.

On Feb 3, 2008, at 3:44 AM, Filipp Andronov wrote:

> Hmmm, my question was not about new ideological war "GNU vs Plan9". ))
> I think that my bad English does not allow me to ask my question in
> correct form, so i will show some sample
>
> For example, in Linux i have some big application.
> This application using autotools, so if a want to port it, for example
> on different OS (of course if this OS has autotools) or hardware all i
> need is go throw sources and put something like:
> #ifdef RUN_IN_CYGWIN
> // some specific code
> #endif
> After that i need to add extra tests in configure and autotools will
> do all magic for me
> The main trouble is that all sources has really many pieces of #ifdef
> code, so it could be very painful to drop out "portability in GNU
> way". But it's ok, until that is a only way.
>
> Ok, for me "porting" to plan9 looks like:
> 1. Drop out autotools from project
> 2. Replace all OS specific code to Plan9 equivalent
> 3. Replace all libs to it's equivalent for plan9
> 4. and so on
>
> Main trouble in 1 step. Because after that i couldn't post in project
> mail list, "Hey gays, i have create Plan9 port of your application,
> please check it out and put in CVS trunk". If i "port" some
> application in that way, that mean that I've start new one, "from
> scratch" and just copy & paste some code from original project (
>
> I hope that i have logical mistakes in my example, and you show me
> that, because if not it could be very sad )
>
>
>
> 2008/2/3, Eris Discordia :
>> On Sun, 03 Feb 2008 00:30:38 -0000, Rob Pike
>> wrote:
>>
>>>> An alternative interpretation is that the facts are skewed by
>>>> the Bell
>>>> Labs reality distortion field. The syllogism goes something
>>>> like this:
>>>>
>>>> All things not made at Bell Labs are bad
>>>> GNU is not made at Bell Labs
>>>> Therefore, GNU is bad
>>>>
>>>
>>> If you think about what the letters of GNU stand for, you might
>>> appreciate
>>> that the forms are in mutual opposition. They provide completely
>>> different
>>> approaches to software. "Good" and "Bad" are value judgments. If
>>> you think GNU is the right way to build things, Plan 9 is
>>> probably not
>>> for you, and vice versa.
>>>
>>> -rob
>>
>> Is that "the" Rob Pike? "The R?"
>>
>> If so, please accept me humble reverence, sire! Hallowed be thy
>> practice
>> (of programming)!
>>
>> P. S. Down here in my country, Iran, we have this tradition of
>> inventing
>> sacred things out of thin air. A considerable proportion of "the
>> divine
>> and the sacred" spilled all over the globe began with that frailty
>> of ours
>> :-D
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>

No one remembers the Windows development tools!

Actually, I have a clear memory of Visual Studio 2005 Express, as I
used to develop in C#. That system was one of the (cough - only -
cough) good things Microsoft made.

On Feb 3, 2008, at 7:49 AM, lucio@proxima.alt.za wrote:

>> So if i want port some big linux application to Plan9 i need start
>> new
>> project and copy parts of code from original one. From one side it is
>> sad, because it's very ugly development model (for example if
>> original
>> project will be update, i need update my project too, so there are
>> two
>> "targets" for every update). On another hand i could concentrate on
>> new Pla9 techniques and create more powerful analogous of linux
>> software.
>
> Eventually, you'd think the autotools will fade, but reality sometimes
> turns out illogical. I think the "Plan 9 Way" will only become
> dominant if there is a major change to the present status.
>
> Strangely, no one criticises the Windows development tools...
>
> ++L
>

On Feb 3, 2008 2:55 AM, Pietro Gagliardi wrote:
> Circular cause and consequence is funny. Let me add to this list:
> - jpg
> - png
> - tiff
> - PostScript
> - TeX (tpic)
> - HTML
> - Mahjongg, sokoban, sudoku, tetris (games/4s)
> - SPARC, MIPS, x64
> - MP3, PCM, OGG (PAC was made at Bell Labs)
> - SoundBlaster 16
>
> Let me put it this way:
> GNU software is good, except for GNU development tools, which,
> except for the gcc program itself, are mediocre and break
> compatibility (try using a Bell Labs makefile with GNU make).
>

I'd add to it the fact that autotools source files are hard to make, so
many people who are to lazy to do it properly just put the famous
(in)sanity check and checks for libs they use. The effect?

A simple C program that doesn't rely on anything except for example libpng
will check for C, C++, FORTRAN 77 compilers, check if those are from
GCC and various other things.

Imagine my surprise when I had seen a configure script (for EmacsLisp
utility) that only checked for Emacs version
and few EmacsLisp files it used - a rare thing IMHO, when >80% of
configure running time is for checking for not used
software.

"CPU cycles are cheap, programmer time is expensive" <--- This doesn't
mean that total laziness is appropriate.

The best thing about autotools is I think the scheme of running
configure - AFAIK mplayer doesn't even use configure for it's script,
instead
they use their own, which looks the same to end user. And saves a lot
of time :-)

--
Paul Lasek

On 3 Feb 2008, at 00:17, Robert William Fuller wrote:
> An alternative interpretation is that the facts are skewed by the
> Bell Labs reality distortion field. The syllogism goes something
> like this:
>
> All things not made at Bell Labs are bad
> GNU is not made at Bell Labs
> Therefore, GNU is bad

Hello children. Today's word is "ad hominem". Can you say "ad
hominem"?

"We are the knights who say 'NIH'". Not.

Nobody's mentioned the antecedents of autoconf&co.
other than genealogically.

The criticism has been (IMO) well-reasoned.

If the appraisals appear somewhat vituperative at times,
that is probably because the writers thereof constitute some of the
sorry
band of unfortunates (myself included) who have been persuaded by
circumstance
to engage in bootless battle with the autoconf hydra.

We eagerly await ingenious and novel counter-arguments explicating the
intrinsic intellectual beauty and universal utility of a so-called
portability system
consisting of 10K+SLOCs of convoluted, inscrutable and non-portable
configuration scripts
intertwined with a twisty maze of twisted #ifdefs.

DaveL

That someone had the time and the will to do something like this?

On Feb 3, 2008, at 10:01 AM, dave.l@mac.com wrote:

> On 3 Feb 2008, at 00:17, Robert William Fuller wrote:
>> An alternative interpretation is that the facts are skewed by the
>> Bell Labs reality distortion field. The syllogism goes something
>> like this:
>>
>> All things not made at Bell Labs are bad
>> GNU is not made at Bell Labs
>> Therefore, GNU is bad
>
> Hello children. Today's word is "ad hominem". Can you say "ad
> hominem"?
>
> "We are the knights who say 'NIH'". Not.
>
> Nobody's mentioned the antecedents of autoconf&co.
> other than genealogically.
>
> The criticism has been (IMO) well-reasoned.
>
> If the appraisals appear somewhat vituperative at times,
> that is probably because the writers thereof constitute some of the
> sorry
> band of unfortunates (myself included) who have been persuaded by
> circumstance
> to engage in bootless battle with the autoconf hydra.
>
> We eagerly await ingenious and novel counter-arguments explicating the
> intrinsic intellectual beauty and universal utility of a so-called
> portability system
> consisting of 10K+SLOCs of convoluted, inscrutable and non-portable
> configuration scripts
> intertwined with a twisty maze of twisted #ifdefs.
>
> DaveL

> because something had to be used to compile Plan 9 itself, etc and I
figure it's not being done as a cross-compiler.

I'm sorry my new friend but I think that's the funniest 9fans post I've
ever seen, how ... but .... surely you ..... aw come on

To redeem myself I shall offer this link to one of the other C compilers
that exist in the world :
http://plan9.bell-labs.com/magic/man2html/1/2c

And when you thought it couldn't get better, from the top of
http://www.comeaucomputing.com

"Bursting With So Much Language Support It Hurts!"

Most fortune-worthy line ever.

uriel

On Feb 4, 2008 12:52 PM, wrote:
> > because something had to be used to compile Plan 9 itself, etc and I
> figure it's not being done as a cross-compiler.
>
> I'm sorry my new friend but I think that's the funniest 9fans post I've
> ever seen, how ... but .... surely you ..... aw come on
>
> To redeem myself I shall offer this link to one of the other C compilers
> that exist in the world :
> http://plan9.bell-labs.com/magic/man2html/1/2c
>
>