Re: Why not use GCC 3.0?
On Thu, 7 Mar 2002, Jerome Warnier wrote:
> I understand... though I will look carefully at the reasons invoked not
> to do it. The "alternatives" is a very powerful way to do such things
> indeed.
> Bloating them would not make anything easier.
It's a long, drawn-out story. I actually like the gcc-defaults solution,
personally.
> My opinion was that the machine I'm talking about has been sold by
> Digital "as-is". The Mylex controller was in there. And all disks are
> attached to it. If this machine has no Mylex controller support, it is
> unusable...
> I wondered why this still happened today, and I suppose a number of
> these have been sold, why is nobody else complaining?
Then again, we're not DEC :-P If it was a matter of Compaq (soon to be
HPaQ?) saying that they're not going to work on it, that would be one
thing (I suppose that IS one thing since nobody's done anything about it
on their side), but SCSI cards are fairly cheap and most Alphas of age
don't have original equipment in them anymore anyway. I believe that
myself and the rest of Debian tries to support as much hardware as
possible generally, but we just can't support absolutely everything on
every arch, regardless of whether or not it's built-in equipment that's
affected. A good example of "probably will never be supported built-in
equipment" is the modem on my G4 Tibook. The machine is sold that way,
and some of the older models' modems are supported, but this model's will
probably never be so. In this case, it's not a compiler bug (soft modem),
but you get the picture. Re the DAC960, I don't think anyone in the Alpha
world pretended that those cards were rock-solid and fully supported under
linux...quite the contrary, actually...so I don't think it's totally
unreasonable, given the amount of time that we've had problems with them,
their firmware, and the driver, to tell people to change their SCSI board
to something else. Sure, not the best solution, but what more can I do?
> Just a question of capitilizing the few users...
> I'm ready (and willing) to help, I'm not too bad, I have a strong
> experience with various systems... but I'm not programmer.
> I could even submit good bug reports, if only I knew how to do it
> without frustrating anybody.
I'll get with you off-list and give you a utility or two and some
hints. Do you know any programming languages at all? A patch always is
the best, but most maintainers are happy enough when you can just narrow
down a bug to one or two functions (which can be done with very little
programming knowledge in some cases, assuming you learn about gdb).
> This Netatalk thing is a good example. How do I do to report a solution
> to an already existing bug #, but forwarded to upstream maintainers?
> I even have some solution and am willing to help!
If the bug is marked forwarded, all correspondence to that bug number will
be forwarded as well. So, if you'd like, you can write directly to the
bug report and it'll get passed upstream automatically.
> If only they all understood the Open Source spirit!
Tell me about it. Most of the time, though, they somehow seem to think
that a pre-compiled product that they give away is a "product" that
carries a certain amount of IP value. In most cases, though, these
"products" aren't rocket science to recreate or reverse-engineer, so it's
kinda dumb to think of them as carrying some innate value. My biggest
problem is when they won't release the board firmware code at all (not
even NDA) for someone to recompile in native format and/or try to resolve
endian or 32/64-bit issues....or even when they won't tell you how to
manipulate the registers of the card to put the board in a certain
state. I usually end up getting marketing info rather than technical docs
when I ask :-P
> If it was just a question of playing with build arguments, I could do it
> myself. But it needs playing with packages, and I'm not ready to do so,
> nor do I know where to look...
Write to John and see if he's had time to follow up on the report. He
apparently had a list of things to try already in mind. A side-note,
compiling with -Wall is deceptive since it does NOT turn on all of the
warning options. I'll dig out my list of good ones for porting and send
them to you...
> I read many times that those "unaligned traps" had a huge impact on
> performance, don't you notice anything?
Not really. I use my laptop more than any other computer in my house, so
performance issues there are quite noticable. Mostly, though, it's hard
to lean on any one machine more than the others when you have 10+ machines
in your house ;-) I read my mail on my Alpha and serve some lightweight
databases, but that's about it. My i386 does some PHP/web stuff for me,
my sparc has it's tasks, etc for mips, hppa, m68k, and so forth. I think
if I used the Alpha as my desktop and/or for everything, I would notice
more, but I don't tax any of my machines much (nor see consoles), so I
don't notice anything but kernel-oops-level problems.
C
Reply to: