Survey responses

Posted Jul 10, 2006 3:05 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Interesting survey. Just that the memory gets fuzzy...

Posted Jul 10, 2006 3:16 UTC (Mon) by kirkengaard (subscriber, #15022) [Link]

Posted Jul 10, 2006 3:28 UTC (Mon) by cventers (subscriber, #31465) [Link]

The biggest difficulty I'm aware of here is that it is still sometimes
hard to get your hands on hardware documentation. If I could personally
get some of the docs necessary, I might be able to take a better stab at
the problem.

So I would say that interaction with hardware vendors remains our biggest
problem.

Posted Jul 10, 2006 9:19 UTC (Mon) by job (subscriber, #670) [Link]

I've also had stability issues with some of the releases, which aren't really any identified bugs so I can't put them in here.

On my desktop machine my USB flash reader hasn't been working reliably since I switched from devfs to udev, only sometimes does the device node even exist. It may be a problem with Gentoo rather than udev, I haven't had time to look into it yet.

Posted Jul 10, 2006 10:47 UTC (Mon) by mgh (subscriber, #5696) [Link]

Posted Jul 10, 2006 14:11 UTC (Mon) by kleptog (subscriber, #1183) [Link]

For example, I recently found several bugs in the r128 DRI driver. Not the kernel portion mind you (though there are still some flaky bits) but in the user space library using it. Still kind of irritating when that breaks on you.

I wonder how many issues are caused by people combining the kernel with versions of userspace libraries that the developers didn't expect?

Posted Jul 10, 2006 15:56 UTC (Mon) by jamesm (subscriber, #2273) [Link]

Posted Jul 10, 2006 16:54 UTC (Mon) by Lovechild (subscriber, #3592) [Link]

I take it the developers feel that I couldn't be trusted to not fuck up my DVD burner so it got disabled all together.

Aside that one issue and the fact that Reiser4 has yet to be merged (which would cause considerable less frustration amongst the users I talk to), I find the new kernel development methodology much more pleasing as a user.

The fact that I no longer have to wait 2 years for an unstable kernel tree to stabilise to the point where it can be considered "stable" but really isn't for several releases to come, due to lack of testing is brilliant.

The kernel has definately improved in both stability and functionality. Take the .17 release, coupled with updates to mesa and x.org I finally have working stable hardware acceleration using the r300 driver.

Posted Jul 10, 2006 17:27 UTC (Mon) by joey (subscriber, #328) [Link]

To be fair, I probably also missed a dozen or more kernel bugs that didn't affect me very much, and were fixed quickly. It seems easier to remeber bugs like the kernel no longer recognising a machine's PCI bus at all, especially when they're still not fixed after 9 months. (http://bugs.debian.org/332962) I also have the joy of running 2.6 on a variety of old non-x86 hardware and so encountering lots of other such breakage.

Posted Jul 10, 2006 18:29 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]

I run, or administrate about 10 machines, mainly desktops. None of the desktops ever have uptime exceeding about 2 months. I always unplug USB devices with some trepidation (even USB mass storage), and quite often experience X server crashes which take down the whole system. This inevitably happens when I have left the machine unattended for a week, and cannot physically reset it!
[A software watchdog, and panic=60 doesn't help much]

The servers are pretty solid in normal use, although not absolutely.

In my view, Linux is no longer sufficiently stable. [I had 500 days uptime on a 2.4.19 kernel in a server]. There are (at least) the following general problems:

1)When the kernel crashes, i.e. locks completely, requiring a reset, there is no way to get diagnostic info. Why can we use, say, the floppy drive for debug after a panic? What happened to the idea of running a second copy of the kernel designed to take control after a panic, and dump diagnostics to file?

2)There still exist unkillable processes, or unmountable filesystems.
kill -9 should be able to terminate a process, even if it is in the "D" state. Otherwise, a reboot is required to solve the problem; worse, you can't reboot remotely, since the kernel hangs just before the end of the shutdown.

3)Unplugging a USB device which is still in use (eg a USB NIC, or a USB sound card) is a nearly guaranteed way to get a crash. It shouldn't happen!
[In this example, I specifically exclude mounted filesystems on USB.]

I am led to believe that this is due to poor driver design; we have just comissioned a USB driver for a USB I/O device, and this can be repeatedly hot-(un)plugged even while it is active, without causing any trouble at all. So, why not sound or networking?

On a related note, when you try to unmount a filesystem, and get a "filesystem busy" error, or when you try to rmmod a module and get "module in use", there needs to be a way to find out what is using it, and, if desired, to kill the process.

4)X server crashes should never take down the entire system. But they often do, especially when using 3D accel. This applies with both non-free (nvidia) drivers and free drivers (eg xorg's ati driver for the r128)

5)Most importantly, the class of people such as myself (technical users, who are not kernel developers) make up the majority of the Linux community. We own most of the hardware, and experience most of the more subtle bugs. Yet, as a resource, we go untapped, since there is very little we can do to debug a problem with our hardware. This is a dreadful waste of most of the community! Is there any way to automate debugging/diagnostics so that we can be of more help?

Regards,

Richard

Posted Jul 10, 2006 20:46 UTC (Mon) by landley (subscriber, #6789) [Link]

Lots of the questions about bugs are that way, where I'm thinking "the
info provided by answering these questions can't possibly be useful" as
I'm filling them in...

Posted Jul 11, 2006 2:01 UTC (Tue) by jsedwards (guest, #38952) [Link]

Posted Jul 11, 2006 5:55 UTC (Tue) by dilinger (subscriber, #2867) [Link]

Posted Jul 13, 2006 3:15 UTC (Thu) by richardfish (subscriber, #20657) [Link]

A good question to capture this might be:

"Assuming you do not have dedicated testing hardware, how nervous are you
about trying out -rc1 kernels?"
1. "No way in h*** am I doing that!"
2. "Only after making a fresh backup, and a few hours to kill"
3. "I cross my fingers while rebooting"
4. "No worries"

-Richard

Posted Jul 13, 2006 7:40 UTC (Thu) by PaulDickson (subscriber, #478) [Link]

Posted Jul 13, 2006 15:25 UTC (Thu) by MisterIO (subscriber, #36192) [Link]

Posted Jul 14, 2006 14:51 UTC (Fri) by ranmachan (subscriber, #21283) [Link]

Now that I think of it I remember a third bug, where wpa_supplicant just fails if I add the wireless interface (ipw2200) into a bridge. I guess I should report that last one (or at least verify if this is still the case with a bleeding-edge kernel).