Not many distros do this, and I support the idea that there should be an easy GUI tool to do this once Ubuntu is installed as well, but if the installer could give you the option of compiling and installing a custom kernel right off the bat, I think many people's perceptions of how fast the OS can be "out of the box" would be improved. Plus, it's just nice to think the installer could do the hard work for you, and your first boot of a fresh install would be a little customized and snappier already. Perhaps if someone could develop a simple gui tool for compiling new kernels within the OS, that same code could be tied into the installer.

Many new and intermediate Ubuntu users may have problems configuring a kernel, building it with the correct options, installing it, and updating their bootloader. Would a GUI solution for this be feasible?

Extra information: this may sound familiar. Last year someone proposed a similar idea, but during installation.

The pcspkr module is incredibly annoying and completely useless for the vast majority of Ubuntu users. The first thing I find myself doing on any new Ubuntu installation, mine or otherwise, is to blacklist this module.

Many people know the age-old debate on Monolithic vs Micro kernel and many references can be found on the web.

I also quite sure that everybody recognise that theoretically and conceptually microkernels are better for security, reliability, ease to maintain and develop, while monolithic kernels have a point only on velocity and multithreading management.

The GNU Hurd project is born much time ago but has always encountered some difficulties and it still far from being usable for "end-user oriented" OS.

As it is stated in the first goals of the Ubuntu project, Ubuntu is born to bring new users to Debian, attempting to remedy to Debian's long time for develop-release cycle.

Debian already has a GNU/Hurd port. The goal is to sustain this particular project, "the Ubuntu way"

The standard for linux sensors is lm-sensors. The best operating system for a linux server is Ubuntu. Fancier server-class machines which are now getting very cheap have IPMI for management. Without support for IPMI sensors, generally only CPU and HDD temp sensors can be read. For example, there are numerous Dell and IBM servers with IPMI now available on ebay and via other used outlets for around $200. Other distributions (e.g. RedHat) integrate this patch already.

http://bmcsensors-26.sourceforge.net/


Following is an illustrative example from my IBM eServer 325 (2xOpteron 246 - I paid $189 with 1GB ECC and 120GB IDE.)

$ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +45.0°C

k8temp-pci-00cb
Adapter: PCI adapter
Core0 Temp: +40.0°C


$ sudo ipmitool sdr
Planar Temp 1 | 26 degrees C | ok
Planar Temp 2 | 29 degrees C | ok
CPU 2 Temp | 37 degrees C | ok
CPU 1 Temp | 41 degrees C | ok
Planar 12V | 12.47 Volts | ok
CPU 2 VCore | 1.55 Volts | ok
CPU 2 2.5V | 2.54 Volts | ok

[....]

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

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.

Recently we upgraded to 12.04 from 11.10, kubuntu 32 bit. And lost google-earth in the process (OS freezes). There's a bug report on it but its not fixed yet. So to make things a bit easier why not retain a coupla previous kernels within the repositories? That way what worked prior to updates/upgrades will probably work again (if it happens to be a kernel issue like this one).

One may require some type of "Regress" checkbox within the package maintainers (synaptic, muon, whatever)... or a new source list could be implemented to make the prior kernel(s) available.

Of course would not normally regress unless a specific app critical to normal usage went bust from a subsequent kernel update (such as was my (and many others) situation).

I'm fortunate to have several systems. I've noticed that the standard generic kernels have one common feature amongst all the system's I've loaded it on. They run approximately 60% of full potential and even seems to fatigue on moderate system load.

When you are travelling and do not have access to a power outlet for recharging your telephone, camera or other mobile devices, usually one can use a laptop to charge such a device via USB.

Unfortunately, if you are not using the laptop, a lot of power will be consumed by the disks, screen, CPU, fans, etc. while you are only interested in power being available at the USB ports.

This can be achieved by building a special kernel that will shut down all hardware that is not needed for offering power via USB (and FireWire/IEEE1394). The kernel will disable the disks, screen, CPU, fans, etc. leaving only the power at afore mentioned ports. The laptop can be shut down by holding the power button for 10 seconds (this is hard wired and does not need the kernel or CPU).

Implementing this idea will allow for highly energy efficient recharging of devices like telephones, cameras and other mobile devices via your laptop.