>
>> > ksh won't be our /bin/sh. It's not going to be on Intel, and I've used
>> > that as rationale for lots of things. I might as well at least be
>> > consistent. ksh will be put into the ap series, just like it is in the
>> > Intel distribution. So you can use it, but it won't be the /bin/sh.
>>
>> Ok, this clarifies at least a lot of things for me. Having lots
>> of shells availables is a good point, changing the default one's
>> a bad.
>
>Right. People familar with the Intel distribution would have troubles
>when moving to the Alpha port because of the different shell.
>
I'll agree on this, people in Linux to tend to expect bash as the shell.
>> Well, just as I said to Octave just before, please, give me more
>> examples (and real ones, not ones linked with gcc/binutils/glibc(*))
>> of bash failures, as I haven't seen only one, since, say...
>> -r--r--r-- 1 root root 1342563 Jun 5 1997 bash-2.01.tar.gz
>>
>> say mid-97, according to my local gnu mirror :)
>>
>> i've used it on a variety of architectures, alpha, sparc, and of
>> course intel (even s390 recently!), and i've never had a real
>> problem with it.
>
>I don't have the luxury of playing with bash2 built using anything other
>than GNU tools. On the Alpha port, bash2 fails attempting a "make
>menuconfig" on the kernel, as well as when using installpkg. To me, that
>pretty much makes it unsuitable for daily use.
>
>However, I will say that I've had no troubles with bash2 on NEXTSTEP 3.3,
>though I haven't done very much scripting there.
>
Right on! Bash2 does have a lot of issues when you try to compile things. I run
into issues with it on Tru64 and Solaris, which is why I don't use it.
NeXTSTEP.. cool.. not too many people have a cube or slab these days.
>> (*) yes, I really do not like gcc > egcs 1.1.2, binutils > 2.9
>> and glibc > 2.1.3, which have really prove themselves to be
>> reliable. glibc 2.2 is cripped with bugs, as any new software
>> release is, and I can't understand why it's already in slack.
>> isn't slack motto "stability and reliability" ?!? that's what I'm
>> waiting from it, not "using cutting-edge technology". I do not
>> want the latest kernels, neither latest glibc or binutils. just
>> include ones that have prove themselves to be what I need, that
>> is, stable and reliable. This, of course, is a comment for intel
>> and alpha arch, and i should probably cc: patrick. hm. let's
>> discuss it here a little more before sending him conclusions :)
>
>Well, you've probably seen all the issues I had when trying to build glbc
>2.2 and gcc 2.95.2 on the Alpha. It's pretty well-known that gcc 2.95.2
>is a poor compiler on Alpha. And glibc-2.2 had major build issues
>(sometimes libm would get built properly, sometimes not). That's why I am
>staying back at the older versions until they get the bugs worked out of
>the new releases.
>
>As far as binutils, I don't work at nearly a low enough level to know when
>there's a bad version of them out. I cannot speak for Patrick's exact
>reasons for moving to the latest versions of the toolchain. You would
>probably have to ask him directly.
>
>But don't worry about me moving to the latest gcc or glibc any time soon.
>There are some very serious issues with those packages on the Alpha, and
>they'll need to get resolved before I work on that stuff again.
Agreed! Until things are stable with gcc and glibc, there is little point in
using the *current* versions. Since gcc and egcs are being merged.. there is a
lot of breakage. In NetBSD land, they spend a lot of time modifying the compiler
to have the features that work and to prune the ones that don't. There are a lot
of issues with it on the Alpha and the Ultra Sparc. It's too bad that a lot of
the utils and programs out there are not 100% portable without having to play
with the options and coding.
******************************************************
* Octave J. Orgeron * Specializing in : *
* Unix Systems Administrator * Solaris/Tru64/Linux *
* Sun Microsystems, Inc. * Certified Solaris *
* octave@sun.com * Systems Administrator *
******************************************************
This archive was generated by hypermail 2b30 : Fri May 09 2003 - 10:00:02 PDT