I have a 33.6k (but the server is SO loaded I barely can make it over 1Kb/s)
And I think it's not that hard to download those 11 megs once every, say,
year? I mean, you aren't downloading 2.1.89, 2.1.90, 2.1.91, etc, full
kernels are you? Patch and diff are your friends :)
> we all know the possibility of something screwing up failure a download
> increases geometrically with time. It's also kind of hard to explain to
You have the reget command in ftp if something screws up.
> people, "yea, Linux is a nice, sleek, unburdended system, you get to
> compile your own kernel, no bloat with stuff you don't need, but you have
> to keep this 40 meg source tree lying around in case you want to upgrade
You don't have to keep the source. You only need the header files.
> your kernel or tweak some feature". Hell, even W95 doesn't copy every
> single darn driver on the CD when you install it "just in case" like the
> current Linux source tree does. Don't have a SCSI subsystem? Too bad,
> you have to wait an extra ten minutes downloading for all those people
> that do!
And, if you ever have a SCSI subsystem, you will have a kernel with SCSI
support for just ten more minutes. Hardware are like rming files.. "hm,
whats this thing doing here.. I guess I'm never going to need a driver for
that.. rm driver" Everytime I've done that, sooner or later I ended going
back to get that silly driver.
> like highlevel scsi, file system, sound driver, and the _really common_
> stuff like IDE, ext2, sound blaster (maybe). A four meg core kernel + a
> couple megs of drivers beats out 11 - 12 megs any day.
Except that you download a full kernel every day ;) The splitting that
I don't feel like a too bad idea might be the arch stuff..
ObBug:
>> cat /proc/interrupts
>> CPU0
>> 0: 393142 XT PIC timer
>> 1: 11098 XT PIC keyboard
>> 2: 0 XT PIC cascade
>> 7: 0 XT PIC soundblaster
> Someone has broken something lower than the sound driver, no IRQ 7's are
> being delivered. Perhaps Ingo or someone who hit the IRQ layer can
Well, sound doesnt play here either, mikmod just stops at the very
beggining. In my case, IRQs are being delivered.. well, at least the first
ones (around 2-3). After that it just hangs there:
access("/dev/dsp", W_OK) = 0
open("/dev/dsp", O_WRONLY) = 3
ioctl(3, 0xc004500a, 0x8064660) = 0
ioctl(3, 0xc0045005, 0xbffff794) = 0
ioctl(3, 0xc0045003, 0xbffff790) = 0
ioctl(3, 0xc0045002, 0xbffff78c) = 0
ioctl(3, 0xc0045004, 0x8064660) = 0
...
ioctl(3, 0x8010500c, 0xbffff78c) = 0 | doing these calls over and over
write(3, "", 0) = 0 |
The funny thing is that if you keep trying again and again, you will
finally succeed in playing the .mod file :) SB16 here, compiled as module.
Kinda like "please play this, will you?" "no" "yes" "no!" "yes!" until
someone gets tired and gives up ;)
Btw, If anyone knows how to play .wav files with mikmod without having a
module playing in the background, please let me know!
____/| Ragnar Hojland (tech.support@redestb.es) Fingerprint 94C4B
\ o.O| 2F0D27DE025BE2302C
=(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822
U chaos and madness await thee at its end." hkp://keys.pgp.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu