[mythtv-users] Ubuntu Edgy -> Feisty upgrade report

[Brian J. Murrell]

On Tue, 2007-01-05 at 22:12 -0600, Brian Wood wrote:
> 
> I should not have to live on the "bleeding edge" in order to get the
> latest security or bug fixes on a kernel that can run MythTV, but it
> seems that to get them I must do so. (2.4 can't run most Myth-related
> drivers).

2.6.everything is most certainly not the bleeding edge.  And you should
not have to worry about what version of kernel you are on as long as
your vendor supports all of the devices you want to use and are
providing maintenance and security fixes.  If they don't, find another
vendor who is or complain to your vendor.

> The change renders incorrect many many tutorials, WiKis, howtos, guides,
> published books etc.

Oh?  So we are talking about material written at a level that does not
assume the user understands their /dev/{h,s}d* devices and only
acknowledges IDE devices but ignores users of SCSI devices?  I would
posit that such material is as bad as the software of a message or two
ago and should die quickly anyway.  If the material is written for a
user that is not expected to know that their devices are /dev/hd*
or /dev/sd* and does not acknowledge SCSI devices with examples
of /dev/sd*, it's very badly written!

> There is no way to tell from those documents that
> the information they contain is likely to have changed.

But again, I posit that if the documents refer to /dev/hd* in more than
just passing and don't offer the /dev/sd* information for SCSI users,
then they were badly written.

> The effort to correct all of that documentation vastly exceeds the work
> to change the kernel itself. The change might seem trivial but it can
> render a system unusable.

So automobiles should have never been outfitted with electric starters
and done away with the crank, because some documentation might be wrong
or need updating?  That's your logic.

> The change could have been made in such a way as to not confuse and
> confound anyone trying to RTFM.

Oh yes.  We should write to LKML and tell them not to make any more
improvements in the kernel that could possibly make any already written
documentation obsolete.

> The "old way" of doing things would not have created this problem.

Sure it would have.  At some point the development kernel would have
rolled over into the stable kernel and everyone's /dev/hd* would have
become /dev/sd* -- no different that his has just done -- and people
would still be whining about how they had no warning of it and that all
of the documentation out there is now obsolete, etc. etc.

Brian, why don't you give up on twisting this one in every direction you
can trying to be right about it.  Progress is never (and should never)
going to be halted simply because some people don't like change and
documentation will need updating.

If you can't handle the pace of change, then you shouldn't be playing on
the leading edge of technology with such things as multi-media.  Wait a
few years for things to stabilize when you can be sure there won't be
further progress and change.

As far as I'm concerned, bring on the change!  I am willing to take and
deal with the instability of playing with leading edge technologies.
 
b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20070502/adb578a2/attachment.pgp