[nSLUG] What kernel for inotify?
aa056 at chebucto.ns.ca
Fri Sep 16 08:55:40 ADT 2005
Quoting Dop Ganger <nslug at fop.ns.ca>:
> On Thu, 15 Sep 2005, George White wrote:
> > Is anybody using iNotify (/dev/inotify) yet?
> Not so much using it as using Beagle (http://beaglewiki.org/), which
> requires it.
I'm using Beagle without inotify, so the requirement isn't strick.
> > What kernel are you using?
> 2.6.12-cko2, self compiled. I suppose I really ought to look into updating
> to a newer version, since software suspend seems to be having issues with
> fans on ACPI...
Not to mention the thrill of the unknown as you work out which of the 100's or
bugs in the new version apply to you. Scanning the list of bugs in the Fedora
fc4 kernel the vast majority are related to IDE, USB, or ACPI issues. These are
all areas where the hardware is diverse and often non-conforming to the
"standards" such as they are. Looking at the discussions of USB support it
seems than you are much better off if you have current USB 2 hardware. Looking
that the discussions of IDE support will certainly encourage you to make sure
your next system uses SCSI disks.
With the 2.6.12.x kernels in FC4 my biggest issue has been the time it takes
udev to create a new /dev/ttyUSBn entry (e.g., after plugging in a USB device).
Nobody talks much about the relationship between the user community and the
developers. As a user you want a stable kernel now and also next year. If you
don't take some risks now by using a newer kernel and reporting problems you
reducing your chances that next year's kernel will work for you. Given the
diversity of hardware and user needs, unless you work in a highly structured
environment you can't assume there are very many people running a similar
"profile". It would be interesting to know things like the average number of
bugs users are "living with", how many of these were previously reported, how
many only apply to hardware more than 6 months old, etc.
George N. White III
Head of St. Margarets Bay, Nova Scotia
More information about the nSLUG