Frequently when a new Ubuntu release is done, reports flare up all over the internet that people have all kinds of hardware issues with the new release.

I had the same problem when installing jaunty. What I wanted to try was go back to an older kernel and see if that helped at all, but only 2.6.28-11 was installed, only 2.6.28-11 was available in the software channels and installing a package from Ubuntu archive didn't work.

Why don't we ship new releases with more than one kernel option? I can't say for certain that booting 2.6.27 would have helped me, but I would have liked the opportunity.

Compilation of kernel in a Linux system makes it better adjusted to the given hardware and consequently speeds up the system. Also, many Linux newcomers have heard many times that there are people compiling their Linux kernels to achieve greater efficiency. Some of them would like to do it too, but without any programming background and knowledge of Linux internals they have no chance of succeeding.

A good start is to set the default value of max_sectors to 128.

This value dictates how much data Ubuntu tries to send to a USB device in one usb packet. Putting more data in a packet reduces overhead and improves transfer rate. Currently the default is 240 (about 120k/request) and there are many devices out there that cannot at all handle this much data at once, and some that occasionally glitch with this setting. The incompatible devices range from cheap USB-IDE adapters, through GPS devices to mainstream WD external hard drives. To find ample examples, just search for "usb max_sectors" in the Ubuntu or Linux kernel bug tracker database.

Windows uses a 64k maximum request size, which is equivalent to a max_sectors setting of 128 -- the value I'm proposing. Presumably, reputable manufacturers will check that their device works reliably with Windows, but they may not verify Linux compatibility all that thoroughly.

I believe changing the default setting to 128 instead of the current 240 would only yield a marginal loss of performance but would eliminate major difficulties that many inexpert users face when they try to use low-end USB storage devices.

The default 32Bit kernel is only allowes to allocate less than 4GB RAM.

It would be great if users had a kernel boot parameter, one that they could use in order to disable modules which cause problems.

Example:
disablemodules=module1,module2,module3,moduleN

This will be very useful when specific modules cause kernel panics (and do not allow further booting). A lot of people cannot even boot to the LiveCD because of such kernel panics and have to search for workarounds or alternative distributions.

Modify the kernel to analyze a program when loading it, then to modify the code JIT to use the GPU when mathematically intense.

On Mac OS X if there is a kernel panic, the GUI is ignored and white over black text is strewn across the screen describing what has happened and what caused it. Then the system freezes. On Ubuntu... it freezes, and you have no clue on the planet as to why. That, is bad. This would be oh so simple to do. Please, do it! This would definitely help everyone who has a kernel panic. Another possibility would be to kill all the user-apps that are running, then show a dialog box displaying what has happened. The dialog box would have one button: restart. This way they could read it, then move on just like they would have to anyways.

I believe that Ubuntu is great in many ways, however graceful it is with all other things... it needs help with kernel panics. What happens when the kernel panics? The caps lock key flashes. Now, what happens on Mac? It doesn't flash the caps lock key at you. It tells you what went wrong. Solving a kernel panic right now is extremely hard, implementing this would be a great addition to the entire Ubuntu community. And to everyone who says this is a waste of resources or it is not possible... i have had over a hundred full on kernel panics (yes, the caps key was flashing) in the last year. The kernel flashes the caps key, it is just as capable of writing on the screen. All the unsaved data is already gone, who cares what the kernel writes on the screen?

There should be different kernels for different laptops. For example a kernel specificly for the Aspire One, or the EEE PC. This would increase the battery life of laptops and would increase the performance of already underperforming laptops, or netbooks. This would coax the most performance and battery life out of laptops.

Most computers these days have thermal, voltage, etc. sensors which can report data to sensord and the system. Moreover, those computers usually have firmware built-in thresholds for such sensors: if the kernel detects one of those thresholds has been triggered, it will initiate a graceful shutdown.

I reckon that such ACPI signals mean the computer is in danger, and thus that it should power off ASAP. However, I think the kernel should try to hibernate instead of shutting down just like that, since the current behavior is quite surprising can make users lose work.

My proposal waters down to the following:
1/ An ACPI threshold is triggered and detected by the kernel
2/ The display is automatically switched to a free console VT, with the something along the lines of: "WARNING: your computer is being shut down to prevent it suffering damage. The following condition has been reported: (human readable explanation of the problem here). The system is trying to save your work to disk and will then power off"
3/ The system starts the hibernation routine, giving it 5 secs to freeze everything and actually start writing things to disk
4/ If the hibernation routine is not able to start in that time, X is killed, filesystems are unmounted as cleanly as possible and the computer powers off

An important point is 2/: the fact that the computer can tell you something is wrong with its systems instead of just powering down without explanation (and post-mortem analysis of dmesg) is very important. Moreover, getting out of X (and maybe Compiz and such) will probably relieve pressure off the GPU. Possible warning messages would be:
-Thermal: "The temperature of your CPU has exceeded 120 ºC (whatever ºF)"
-Voltage: "The +12V supply is too unstable (outside a ±10% safety range) and could damage components"
-etc