Re: なし

[turnbull@example.com (Stephen J. Turnbull)]

As long as I'm here:

MERRY CHRISTMAS to all on the list, and to all your families!

>>>>> "Joe" == Joe Marchak <j_marcha@example.com> writes:

    Joe> Hi ...  I'm using kernel 1.3.3, and sound works fine on DOOM
    Joe> etc, but for some reason "workman" won't recognize audio CD's
    Joe> any more.  It used to work with 1.2.8 ... Anyone know what
    Joe> may be wrong?

Somebody, I think it was Jim Tittsler (but it might have been Rainer
Mager) mentioned a couple of weeks back that some driver got broke on
his system in the 1.3.xx series, and that it finally came back to life
with 1.3.4x.  I recall that it resurrected workman.

As to "what may be wrong," if I were a true cranky wizard, I'd say "If
you don't know, you shouldn't be using the 1.odd.x series!!"  :-)
Seriously, nobody much cares if "toys" like workman get broke by the
development kernel series until they get to prerelease stage.
Development kernels are for adding new features and optimizing old
ones.  Sometimes they're as stable as a rock, and sometimes they sink
like a stone.  Single-digit revisions of a development series are
particularly bad because they tend to be feature-creatures, with
interactions that would make Godzilla-vs-Kong look like a
kindergartener's asobi-kenka.  ("Prerelease stage" can be recognized by
the fact that if you don't have a T1 directly connected to your
machine, you can't FTP the current kernel source before Linus releases
a new version.  Since they're only coming out at about once a week, I
suspect it will be a while.  :-)

In general, if you want everything to work the way it always did,
including the bugs :-), stick to the 1.even.x series.

One thing that often works, especially with cranky hardware-related
proggies like workman, is to recompile the program against the new
kernel includes and libraries.  As anyone who has ever used the DOS
"setver" program knows, having ordinary programs check the kernel
revision is just a pain in the ass, and makes upgrading really
annoying.  But any program that gets close to the hardware is going to
risk getting broken by optimizations in new kernels.  Those programs
ought to check the kernel revision, but often don't.

Those steadily increasing benchmarks don't come for free, you know,
and it's not just the skull sweat of the hackers who build the
programs.  Often these optimizations change calling sequences; then
you get something obvious like a SIGSEGV.  Other times the defines get
changed, or library or kernel routines get changed internally.  This
will change side effects that the programs depend on, often in ways
the authors don't realize were dependencies.  Then the program fails
silently, and the wizards are also silent about what went wrong.

If you need a new feature from the current development series, or want 
to just keep up with the Tittslers, I recommend a strategy of keeping
three kernels around.  First, a recent stable kernel (1.even series).
Second, the most recent development kernel that has worked well for
you.  Third, the current development kernel.

By the way, I want to express my thanks to the guys like Jim who are
keeping up with the kernel developments.  It's nice to have a personal
recommendation as to what's working and what's broken!

-- 
                            Stephen J. Turnbull
Institute of Socio-Economic Planning                         Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tennodai 1-1-1, Tsukuba, 305 JAPAN                 turnbull@example.com