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
