Re: Hows Alphadebian doing?
> 1.) The time is wrong
Works fine on my box. I think it was an install option (I'm not 100%
sure).
> 2.) The installation is much too difficult
> 3.) There are no CDs (except the ones we made here with our own script)
It's not released yet, so why mass produce a CD now?
>
> And we already wrote a script to create alpha CDs... But we only have
> alphapc 164sx with ARC consoles and so we would need help for building
> others... But nobody seems to be interested in these things.. (but this has
> already been discussed on #debian, debian-devel and debian-cd)
>
Wouldn't the same CD be used for most alphas, just different boot disks?
>
> unaligned traps aren't bad...
I disagree, just because the kernel fix's it, doesn't make it ok.
Program's that assume 32 bits and use pointers in funky ways are broken,
even though they appear to work fine. If I dereference a NULL pointer,
should the kernel say "Bad memory access" and keep running? No, it seg
faults. Now that may seem a little extreme for an example, but it's all
along the same lines. Do we let the kernel fix something that we should?
That's a morallity question that software engineers must ask them self.
Don't get me wrong, it's nice that it does fix it (saves us time), but I
don't like them. I think that DU dumps core on unaligned traps. My guess
would be to force you to fix the error.
>>I have been using it to burn audio CD's with cdrecord and wav2cdr with
no
>>problem, when I used RedHat the same source it used to give unaligned
>>traps all the time.
>
> And I don't think that it was the same source because if it's the same
> source there would be unaligned traps... maybe the debian kernels don't tell
> the user about unaligned traps... but they happen if it's the same source!
It was from the exact same tar file that I backed up before installing
Debian. My guess would be a Library call was giving the unaligned trap.
Someone wrote a while back how scanf was causing one. RedHat 5.1 uses
older libs. Sometimes things aren't as simple as they may seem, so to say
the same source will do the same thing on 2 different setups isn't
safe to assume. I never said the problem was in the source.
I just wrote a little program to see if the kernel generates a trap and it
does.
Paul
Reply to: