Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: yesss, sound in 2.0.36 | Date | Wed, 25 Nov 1998 13:26:50 +0100 (MET) |
| |
"A month of sundays ago Alan Cox wrote:" > > I'd still be grateful for a hint as to where these functions are snagged > > from. There's a lot of matches against lseek in the source, luke. > > Use 2.0.36 , or extract the relevant bits from the 2.0.36 diff
Yeah .. sorry, I didn't mean to imply that people shouldn't be using your 2.0.36. Just the opposite, it's superb work. Very well done. Everyone putting a new kernel in their machine should put in a 2.0.36 right now! I can't emphasize that enough.
But I did this to understand the patches - i.e. for interest, not to foul up your lifework :-). It would have been very uninteresting to just ftp and click make.
The modular sound patches are great. Excellently orthogonal to the rest of the kernel sources (I could go on at length!). But I'm not changing kernels until I am forced to.
I'm sure the situation of many system admins is approximately the same as mine. I take new or upgraded drivers, including sound, and back port them as best I can to my installed kernel base. I don't want any changes in kernel semantics here, good or bad. That you have improved things markedly in the late 2.0.3* series is great! Wonderful! But it's a change, and therefore potentially deadly to maintenance of the existing installed application base, therefore I'm actively avoiding following it as though it were a plague bearer.
I'll only change when significantly many applications start needing it and it becomes easier to change the kernels than change the applications (corrective maintenance) or it starts offering functionality that I need and don't have (perfective maintenence) or it starts offering protection that I need and don't have (preventive maintenance). I reckon we're about a hair away from making the kernel upgrade here. Three years holding the same kernel down is enough. But I have a list about 100 long of tasks that are of pressing urgency before I can even get to that stage.
Maybe it's interesting to see what the "more pressing" list looks like. Mmm ..
the first few items on the list deal with physical errors in nets. Such as hunting the reason why an entire subnet drops every night at 11-12pm. Then there is testing of new hardware (about 2 machines a week). Solution of physically misconfigured things - lots of machines dual boot dos to do networky things with students learning, and you can imagine .. and fixing of old, combined with salvage operations. I see about 10 broken disks listed, 5 broken network cards, a few broken vga cards. Then there are problems to resolve with some scsi cards that don't seem to like being actively terminated .. and labs being physically reconfigured, etc. etc.
Then I see a whole slew of basic software configuratuon tasks that have never been done right, such as configuring the keyboards so students can actually use them. Then there's installation and support of new software that's needed urgently for courses (e.g. JWS - nicked from the solaris ix86 version and seemingly somewhat incompatible with ld.so.1.9.9 but works well with 1.9.5).
Dropping a bit further down the list, essentially I see tasks like making the software base uniform, and making sure everyone has the same kernel and modules, checking suid and sticky permissionsu, and so on. Further down I see tasks like automating things like that (shucks, guess that'll be me. cfengine here we come). Getting the new user setup _right_, blah blah blah
Well, I'll give up having scanned half way through the pending list. What I mean is, no way can I afford to experiment in any way with something as fundamental as switching the kernel everywhere. And if I don't do it everywhere, it creates a maintenance nightmare. I am _still_ switching to the latest libc and ld.so. Heck no, I forgot. I had to downgrade ld.so again everywhere because of the JWS thing. And it also broke netscapes plugins here. Now that caused howls!
(but my TP now makes lovely sounds! Thanks :-)
-- Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |