> > 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.
> 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.
> (*) 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.
--
Chris Lumens - chris@slackware.com - KG6CIH
@n=(-42,-85,-83,-19,65,2,-10,-10,-15,-3,2,-10,73,-4,8,-4,2,79,8,17,15,7,14,2);
print map{chr(-$n[$i++]+ord)} sort(split(//,'place random string here')),"\n";
This archive was generated by hypermail 2b30 : Fri May 09 2003 - 10:00:02 PDT